Securing Admin area

Hello guys.

I have done many modifications to my cart on the core and all other files. All changes were made in 4 years of usage of the cart, plus plugins added, free and purchased.

I have tried to upgrade to the latest version in two occasions and it turned out so wrong that I had to go back to 1.38a (my backups) on both attempts.

I tried all I could and even purchased a software for file comparisons (beyond compare) in an attempt to locate all the changes in the text files, but it was a nightmare of hundreds of lines of code differences.

The thing is that for all those 4 years, my store has worked and still is working perfectly as it is and probably will keep that way for the rest of its existence.

My only concern are hack attempts in the most vulnerable area it has right now, the admin login page. I guess it allows for brute force attacks because there is no delay between attempts, no captcha or no count on the login attempts to block the IP temporarily after, let's say, 5 attempts.

Is there any modification, free or paid to protect the admin area in v1.3.8a? A captcha in the admin login would be nice, but a counter of login attempts with IP blockage would be perfect. If there is no plugin or modification for this, does anyone know a trustworthy freelancer or developer that can do it?

My cart is v1.3.8a and it is been run in a SSL enabled server:

Server OS: Linux 2.6.18-408.8.2.el5.lve0.8.61.3
Database: MySQL 5.5.30-cll
Apache/2.2.23 (Unix)
PHP Version: 5.2.17 (Zend: 2.2.0)

Thank you for your suggestions.

You can wait until your host upgrades their php to a version that 1.3.8a will not operate on

For now, if you have a relatively static IP address
Can check here several days in a row
http://whatmyip.org

You can create a .htaccess file placed in your admin folder with the following

order deny,allow
deny from all
allow from 127.0.0.1
allow from xx.xxx.xxx.xxx

enter your IP address in the red area
Upload it using FTP
If your IP changes in the future - Use FTP and change the file

The way I read it you are willing to pay somebody to do the work, if thats the case why not just have them upgrade your store to the current version?

Thank you for your feedback guys.

@Kobra: You made my day with the first comment.

About your suggestion about editing the htaccess file, that's a good one. I am thinking of implementing what you suggested, but instead of putting my plain IP, I will put a subnet mask to allow the whole IP range covered by my ISP. All hacking attempts come from outside my Country (Puerto Rico) and my ISP only covers part of the Country, filtering the whole internet down to about several hundred thousands of users. That will decrease the risk largely and I will not need to be constantly editing my htcaccess file.

Thank you for that!

@Trees2wood: Yes, I've been thinking about it, but I am reluctant about someone doing it and having access to everything, instead of only building some type of plugin or script that could be adapted to what I need in the admin area, which is something I would gladly pay for. Thank you for your suggestion, it also appreciated.

Best regards

Glad that you found it useful

BUT the vulnerabilities are not totally through the admin

Yes, I know. Among them, the admin area was the most vulnerable at this time in my case.

I just did what you suggested, with a subnet mask allowing strictly my ISP's IP range only and tested it.

Worked like magic. I tried to go to the admin area with several private proxies and access was denied. Only my ISP IPs are allowed now.

Once again, thank you so much for the nice idea.

Best wishes.

zilog357:

I tried all I could and even purchased a software for file comparisons (beyond compare) in an attempt to locate all the changes in the text files, but it was a nightmare of hundreds of lines of code differences.

A common mistake I've known people to make, is trying to compare their V1.3.x file base with the V1.5.x distribution files. It will be a nightmare.

What you need to do (if applicable) is do a compare between your site and the V1.3.x distribution files, and applying just those changes to the V1.5.x file base.
You'll find the list is a lot shorter, and most of the differences you do find will probably make a whole lot more sense as they'll serve to remind why the changes were made in the 1st place.

If this isn't applicable, please excuse the interruption.

Cheers
Rod

PS. > zilog357:

@Kobra: You made my day with the first comment.

Just to be clear, Kobra wasn't kidding. We see a lot of forced V1.3.8 upgrades as a result of host initiated PHP upgrades.