The network I have just inherited has a single home-type (Seagate) NAS drive which is used as a data backup each night at midnight.

As this company experienced a virus attack recently (before my time) - I want to do all I can to preserve data security until something better is in place.

This drive is connected directly to the main network, and the servers back up to it. It stays on and accessible during the day but nobody connects to it.

Would it be a good idea to fit a power socket timer to turn it on before the backup starts and off (for example) 3 hours later, giving ample time for the backup, but rendering it completely immune to attack during the business day.

(I want to get an LTO-6 fitted ASAP, plus cloud storage as a "belt-n-braces" approach)


The General Idea Is Good

The general notion of making your backups inaccessible to malware is solid. There are multiple ways of going about doing that and it doesn't necessarily have to involve turning your backup drive off.

So it isn't a bad idea to make the drive, or at least the specific directories where the backups are stored, inaccessible.

Malware Masquerades as You

Here's the thing about malware. If you get malware on your computer, it gets to run with all the same permissions that you have, since it is running in your security context.

If you, personally (or any other user on your network) have write access to your backups, and you get malware, that malware also has write access to your backups. So, for example, ransomware could encrypt your backups and make them useless to you.

Run Your Backup Job In a Separate Service Account

If your backup job is running from a different account, and that account is the only one with write access to the backups, then even if you inadvertantly install ransomware, it cannot change your backups. This is regardless of whether the backup drive is turned on or off.

More Considerations...

Also consider that if you just power your backup drive down abruptly, you could lose data that is in cache on the drive, but hasn't been written permanently to disk yet.

And, finally, consider that if you do have malware and your account has write access to the backup directories, then your backups become vulnerable when the drive powers up to run the backups, even though the drive is powered down for part of the day.

Either way, using a service account for running your backups, and denying write access to your backup repository to every other account including your own (or especially including your own) is a good practice.

  • 1
    I second the idea of using a service account for backup jobs. You can tweak its permissions specifically for backing up, disallow Interactive use (logging in on console) and Network use (logging in via RDP). This means that even with the account login information, it would be difficult for a hacker to exploit. If you make this a domain backup account, it will work on all systems that need it. Secondly, I recommend using a virtual container (VMware, VirtualBox) to test your backups - restore them as a Virtual Disk and see if they're affected, without sacrificing an entire system. – George Erhard Mar 23 '17 at 17:35
  • +1, but that mean the OP got a NAS with NTFS support, not all NAS are that way, so usually the NAS finish as a open volume if not set correctly. – yagmoth555 Mar 23 '17 at 17:49
  • If by 'open volume' you mean a drive with minimal read/write/exec permissions, yes. But, consider that if a service account is performing the backups, only that service account needs to 'mount' the external NAS drive. All other accounts leave it as an un-advertised network location. This should protect such a drive from a user-level malware attack. – George Erhard Mar 23 '17 at 17:59
  • Many NAS today has the option to poweroff and poweron during some periods :) – Orphans Mar 24 '17 at 15:48
  • 1
    Those users WILL start doing it if they want their backups to be safe from ransomware. :) – Craig Mar 28 '17 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.