Forum archive
Drupal Oct 2014 Vun & TKBLM
Hello, I did not have time to patch my server during the small window that was recommended when the Oct 2014 critical sql injection bug was revealed. My server does not appear to be infected but of course you never know.
I want to make sure my server is put into an uninfected state. So would restoring from a TKBLM backup from just before the vulnerability went public be enough to roll back any potential malicious programs that may have been installed? I'm guessing no since TKBLM is kind of selective.
Conversely, would starting a fresh Drupal 7 instance that is fully patched and then using TKBLM to import the current state of my potentially infected server pose a risk of carrying over potential infections? I'm am guessing yes.
Thus is my best option to use a snapshot from the hub.turnkeylinux.org that predates the known explotation of the SQL vunerability? I would assume this is pretty failsafe but my only choice is a snapshot months before Oct and I would lose a lot of content. Incidentally, I cant get any of the content exporting modules to work as I get SQL errors upon enabling them and then they never show up in my admin config. (Makes me think I may have been compormised as Iv never had this problem)
Thanks
Replies (3)
No worries Bil :)
Reply 1Thanks!
Reply 2Thanks so much for the deatiled response Jeremy. I have TKLBAM backups and some snapshots that I can choose from. Unfort the last snapshot is quite a few months before Oct but I have daily TKLBAM that hopefully work.
To clarify, you think I should launch a new drupal instance, then pull over a pre 15 Oct TKLBAM backup from my current server, and then immedietly update this new druapl appliance to latest version.
This would be as opposed to just restoring my current server to a pre 15 Oct TKLBAM backup.
Thanks again!
My 2c...
Reply 3TBH I am not an expert in these things (i.e. Drupal security) but I know my way around TurnKey fairly well... So I'd like to think that I can provide you with an educated opinion but it isn't going to be conclusive nor should it be considered exhaustive or unquestionable.
So with the disclaimer out of the way; firstly I would suggest that you follow the advice of Drupal themselves. In other words launch a new (clean) instance of the Drupal7 appliance and restore your website to a backup from before 15 October 2014. Once you have done that then immediately update Drupal (or at least apply the security patch).
So to specifically answer your questions; restoring a pre 15 Oct TKLBAM backup would probably be adequate but would not provide 100% piece of mind. This is because as you state it is a selective backup and if files not included in the backup have been tampered with then they will remain untouched (and hence still compromised). Because of the way TurnKey is set up and TKLBAM is configured on a Drupal7 appliance it is probably likely that any files that may have been tampered with would probably be replaced, but personally they're not odds I'd like to gamble on (but then again I'm not much of a gambling man...)
I would patch Drupal immediately after restoring your backup not before. This is because your backup will probably contain files that need patching (that will overwrite files you had patched). I suspect that answers your next question, but to directly answer it: restoring a current TKLBAM backup would almost certainly carry over any infected files or data (assuming that your server had been compromised).
So the unfortunate reality is that the only way that you can give yourself the absolute best chance of not hosting an infected Drupal site is to restore your old backup. However, you mention snapshots rather than TKLBAM backups. TBH that confuses me a little as they aren't the same thing. A snapshot is basically a clone of the entire OS (that can be launched instantly as a new server - servers running on an EBS backed TKL Hub plan support this; as does many hypervisors/virtual computer software). Whereas a TKLBAM backup is a selective data backup (that needs to be restored to a server that exists already). Essentially it doesn't make that much difference for the purposes of my advice in this situation though, either way go for a pre 15th Oct backup...
So following being the bearer of bad news I also suggest that you read through the link I gave above, plus other relevant Drupal info: the original Drupal announcement and "Your Drupal site got hacked. Now what?".
Other thoughts that spring to mind:
Enabling daily TKLBAM backups. By default it will do monthly full backups and daily incrementals and keep them all forever. If you're worried about backup size growing too much, limit it to only keep a limited number of backups (this relates to full backups). Alternatively if storage usage is not such an issue for you then I'd recommend reducing the full backups to fortnightly (rather than monthly). This will make restores quicker and reduce the chances of data corruption. It is unlikely in AWS S3 storage but still possible and by reducing the timing between full backups you also reduce the backup chain length (the incremental backups rely on a chain of all the previous incremental backups back to the last full backup).
Also I would argue for a monthly (or more often) regime of backup testing (i.e. test your backups monthly by restoring to a clean instance). Whilst I have found TKLBAM to be impressively reliable nothing is ever perfect and IMO an untested backup is only marginally better than none at all. Murphy's Law dictates that the likelihood of an untested backup not working when you need it are high!
And finally a note about Drush. In case you weren't aware TurnKey Drupal7 has the awesome commandline tool 'drush' installed. It makes things like updates and installing new modules and themes really easy! If you are unfamiliar with it there are plenty of great resources online; e.g. here, here or here.
Assuming that you are using a TKLBAM backup then yes restore pre Oct 15 TKLBAM backup on a new Drupal instance.
Also my inclination would be to keep the old server running for now and manually migrate the post Oct 15 content i.e. copy/paste... Once you have everything you want off it then just destroy it.
Like I said though, I'd strongly suggest that you enable daily TKLBAM backups and keep at least 3 months worth (i.e. 3 sets assuming monthly full backups).