We’ve just been asked to document what we do when we are approached by someone whose Magento website has been compromised. While Magento is great, just as with any other software system there are bad guys out there looking to exploit it and sometimes they do find a chink in the armour. A successful website hack attack is for many people the start of a really bad day, but for us at SteamDesk it can make for an interesting few hours as we work out what has gone wrong, how to fix it, and what we can do to stop it from happening again. One of our clients asked me to write up an overview of what we do. It all begins like this…
When someone new approaches us to do a one-off repair job we start with the following routine:
1. Take a copy of the current site and database so that we could examine it on our servers using suitable tools.
2. Compare your site with a “bare” reference copy of the same Magento version.
a. This will let us identify whether code modifications have been made correctly (e.g. within private theme folders) or incorrectly (changes to the Magento core files).
b. Check patch history, ensure that the site is up to date with the latest security patches.
3. Identify and list any third party components that have been installed. Disable/remove any that can be identified as having been installed but not put into use. Try to get source code (with matched version numbers) for each of the components to compare against. (This is often not possible because developers do not always archive older versions of their components, especially if it is a paid-for extension).
4. Using the reference copies we would make further comparisons to identify hacked/compromised files in the Magento source and/or independent “Trojan” files that have been dropped into the website.
5. Check for and remove “hidden” admin users which exist in the database but because of hacked code are not shown in the Magento admin panels.
6. Apply new, strong passwords to all admin users (most Magento break-ins are attributed to guessable admin passwords).
7. Relocate the entire Magento admin panel away from its standard /admin address, moving it to a non-standard address on the server to prevent “drive-by hacking”. (We would also do this for various other parts of a standard Magento system).
9. Attempt to install any necessary security patches and/or upgrade the Magento version. (But we would not attempt an upgrade from a Magento 1.x site to Magento 2.x, there is not a reliable, simple upgrade mechanism to do this).
10. When we were confident that the site was “cleaned” we would re-deploy it to your live server.
What we really like is to impress someone with our dedication so they become a “retainer client”. We charge from £200/month to act on retainer for which we would also do the following:
1. Create a source code repository for your site so that we could compare the current site against previous versions as time goes on.
2. Set up notifications from scanning service such as those provided by MageReport.com to warn of site problems.
3. Routinely review the security of your system, applying “hardening” guidelines and proactively watching for signs of intrusion (both attempted and successful).
4. Set up and maintain a reference copy of your site on our development servers ready for patch-testing (we never patch a live site until we have tested the patch on a development copy).
5. Monitor the Magento notification services so that we are ready to apply security patches as soon as they are announced.
6. Provide up to 4 hours of maintenance or development work every month as part of the retainer fee.
7. Besides having the reference copy of your Magento installation in our source code repository, if necessary we would also set up off-site nightly/weekly/monthly backups of your site’s database and product image assets.
8. Provide on-call priority support during office hours. (Mon-Fri 9am-5pm excluding public holidays).
The list above isn’t set in stone – we adapt to meet the demands of the ever-changing security environment. It’s one of the more interesting things about being technical web developers, and to my mind the principle reason why you should always contract your designers separately from your developers. It’s a sad fact that most of the broken sites we come up against got that way because a client contracted for a new website direct with a design company who produced flashy visuals but then sub-contracted the actual development work to the cheapest company they could find…