shawaj, on 03 June 2011 - 09:27 PM, said:
.....am i correct in thinking i do not need to do 2, 4 and 8 with my 2.3.1 version?
In 2.3.1 you do not need to do anything as it is basically a secure package in that to date there have been no serious security issues reported about it other than the issue I raised somewhere else about malformed admin strings could be used to coerce an admin to log into their own site via the link. But that is less of an issue it seems than any of the previous security issues from earlier versions of osCommerce.
osC_Sec was designed for users of osCommerce who persist in using versions earlier than 2.3.1. It has in it some of the patches from 2.3.1 including the $PHP_SELF patch to the admin bypass exploit. So 2 and 8 (which are actually both in osC_Sec) are not a necessity to 2.3.1, only a necessity to earlier versions.
But what you will find is that because osCommerce was heavily attacked and still is being heavily assaulted by attackers, a lot of your site bandwidth will be consumed dealing with bogus requests trying to exploit these old security holes that are no longer relevant to osCommerce 2.3.1
Because osC_Sec kills those requests before the page can load, it will reduce your bandwidth consumption quite considerably. An example of this is on one of my honeypot sites where I have set osC_Sec to just prevent an attack but not ban the IP address. The attack itself comes in groups of up to 20 repeated requests in a matter of a few seconds. My guess is that the tools being used work in a hammering motion. So while 2.3.1 is patched against the attempts, thats 20 page loads that resulted in the server redirecting the user to the login page as it should. But that is a lot of wasted resources on your website just because you are using osCommerce.
So having a security script that catches the first attempt and adds the IP address to a ban list can reduce the resources being used up on your website, considerably....even if all it is doing is that....reducing a 20 requests attack to a few bytes of data transferred.
To use osC_Sec in that manner, set all the settings to 0 including emails except for the banipaddress setting and osC_Sec will work purely as a bandwidth saver for 2.3.1
- Stop Oscommerce hacks dead in their tracks with osC_Sec
(see discussion here
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Ignore this link
- just a honeypot
site to test my ideas out for osC_Sec and allow the site to be picked up by attackers.
- Fix the admin login bypass exploit here
- Pareto Security
: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes