One drawback to the otherwise awesome sauce of the do-it-yourself web is that you’re also responsible for fixing it yourself when something goes wrong — call it the FIY corollary to the DIY web.
For example, what happens if the bad guys attack your website?
In some cases your web hosting service may be able to help, but most of the time undoing the damage is your responsibility. Websites are attacked every day; well-tested though they may be, frameworks and publishing tools inevitably have security flaws and eventually you may be bitten by one. Or it might not even be the tools that end up being the problem, it might be something far less obvious. Developer Martin Sutherland’s server was recently hacked because one file on a shared server had the wrong file permissions.
Sutherland’s write-up of how he discovered and fixed the attack on his server is well worth a read and makes an excellent primer on how to handle being hacked. While Sutherland’s situation may be specific to the attack that his site suffered, his diagnostic steps make an excellent starting point even if you use a completely different publishing system. (Sutherland uses Movable Type.)
Sutherland’s strategy (once he realizes he’s been hacked) is to scan through all the files on his server to see which ones had recently been changed. He then filters that list, ignoring files that should have changed (log files, etc.) and narrowing it down to suspicious file changes.
How much this approach will tell you if your own site has been hacked depends on what the attacker has done and what your server setup looks like, but it should help you get moving in the right direction. Read through the full post for the specific command line tools Sutherland uses to inspect his files. If you’re not comfortable on the command line or don’t have shell access to your server you may be able to use something like Exploit Scanner (if you’re using WordPress) or a similar tool for your publishing system.
Once you know what happened and which files were affected it’s just a matter of rolling back the changes using your backups. You do have backups right? As Sutherland writes, “it’s not a matter of if something goes wrong, it’s a matter of when.” Remember: backups are only useful if you have them before you need them.
We sincerely hope your site is never hacked, however, it does happen all too frequently. As Sutherland’s write-up illustrates, one of the keys to making sure that you recover quickly is to have good backups. Do yourself a favor and spend a few minutes creating an automated backup system before something goes wrong. Now excuse me while I go make sure my
pg_dump cron script is running properly.