Magento Security: The Fundamentals

Rhys Botfield | July 4th 2016

Magento is arguably the most popular e-commerce platform in the world so chances are that you’re going to have your store attacked, though not by some mysterious hacker behind a black screen with green writing. “Hackers” these days are likely just running generic automated attacks, waiting to see what site it breaks into. So since it’s just some boring robot hitting your site, following some simple good practices can brush off some malicious attacks like they’re dust. What are my top 5 tips to keep the bots at bay? I’m glad you asked …

1. Secure vulnerable URLs

So the first thing an attack will try do is navigate to “/admin/” or “/downloader/” on your website and try and guess your username and password. I shouldn’t need to mention having strong passwords, but although it’s common sense now it’s always surprising how often they are overlooked. Since their locations are set by default, they’ll need changing and/or restricting.

To change the admin panel URL you can easily just open the app/etc/local.xml file and look for the section containing <![CDATA[admin]]>. Just change the word ‘admin’ to whatever you want the admin URL stub to be and you’re done.

For the downloader URL, you can simply change the name of the downloader folder to any custom URL stub you would like.

To further protect them, you can deny any public access to these at the server level by denying all access to the locations unless it’s from your own IP address. (This only works if you have a Static IP Address.)

For Apache users you can use this in your .htaccess rewrite rules. Don’t forget to replace the word ‘admin’ with your new URL stub:

RewriteCond %{REQUEST_URI} ^/(index.php/)?admin/ [NC] RewriteCond %{REMOTE_ADDR} !^ RewriteRule ^(.*)$ http://%{HTTP_HOST}/ [R=302,L]

For nginx users you can add this to your site configuration file but don’t forget to replace the word ‘admin’ with your new URL stub:

location ~* ^/(index.php/)?admin { allow;  #Change to your own static IP deny all; }

2. Software Updates

Fortunately, vulnerabilities in code don’t remain vulnerable for long; Magento developers and the community are always working on patching security flaws in the core system and releasing them as “SUPEE” security patch scripts to run on the server. Most of the time people are pretty good at getting their Magento versions patched but some often forget that extensions need to be updated too. Out-of-date extensions are just as much a security hole as out-of-date Magento versions. Never hesitate to update your extensions and apply security patches.

3. SSL

Purchasing an SSL certificate to use HTTPS on your store is essential for any e-commerce website. You’re going to be handling some pretty sensitive data in a Magento site, such as credit card numbers, customer details, customer and admin passwords, etc. Without HTTPS, hackers can read that information in the packets of data being sent from the client to the server, so we need to encrypt it, and that’s where SSL comes in. Most hosting providers will offer SSL protection on your site so if you haven’t set one up already, contact your host and purchase one ASAP.

4. Permissions

Not all server setups are the same but most should have the same general rule: allow the PHP/server user to read and write files, allow the web-server group to read files, and everybody else should be denied access (or given read-only permissions). The only exceptions on this would be the var/ and media/ folders, which have much more relaxed permissions. This is usually something that the hosting provider would set up but you should still ensure the permissions are correct by logging via SSH and checking yourself. If you need to set the permissions back yourself, you can simply use all of these commands at the root of your Magento install (replace owner and group with the correct ones):

chown -r owner:group . find . -type d -exec chmod 750 {} \; find . -type f -exec chmod 640 {} \; find var/ media/ -type d -exec chmod 770 {} \; find var/ media/ -type f -exec chmod 660 {} \; chmod 550 mage

5. Shared Server vs VPS/Dedicated Server

There are so many reasons to dish out for that bit of extra assurance with virtual private servers or dedicated servers. The most important one, in my opinion, is that VPS/dedicated servers can help assure you that your website is PCI compliant, whereas it is very difficult to achieve that on a shared server. If you’re going to be accepting card payments directly on the website, it is crucial that you use a VPS or dedicated server that is PCI compliant.

Secondly there’s the fact that you are literally “sharing” the server with others, so if one website gets attacked and takes down the web-server, they all go down. Needless to say, you don’t really want to leave the fate of your site’s uptime in the hands of so many other people who may not be as safe and secure as you are.