One of my co-workers got me thinking on this today so I thought I would write something up and get it out. This is like some of the other things I do (like vSphere Best Practices) where I hope that comments and suggestions show up that help me improve this.
This is about securing your backups from easy exploit such as CryptoLocker type malware, or even insider theft.
- If you have a private and non – routing management network you access with a Jumpbox it is a good place to put your Veeam infrastructure but you need to design carefully. If you don’t have a private network like this – and I know less and less people are doing that – maybe don’t start doing it just for Veeam.
If you are not on a private network your Veeam server should be in the Active Domain. This may not seem reasonable or logical, but it does mean your AD GPO can help secure and manage the server(s) and that is good. It means you will have better audits too. Some people will not have it in the domain so that different credentials are necessary to access it.
- Your Veeam servers, whether they been on a primate network and accessed via a jumpbox should not be in the AD, and should in fact be using local accounts that few people have access to.
- Make sure the Veeam server has enabled properly, and configured the Windows firewall.
- Make sure you keep the OS patches current and the OS level modern!
- Your anti-malware should be properly configured for a Veeam server and properly managed too.
- Hopefully your corporate firewall does good malware protection and if not it certainly should.
- Any SMB / NFS / Linux destinations should have ACL security that has ONLY the service account defined that Veeam will use to connect to it with access No admin, and no other access. This will help protect against malware accessing your local or network backups. Update: another idea might be to not use SMB, but let Veeam move the data and that might be more secure – especially if you really limit access to it.
- Put a password on your Configuration backup. Make sure it goes to one of those SMB destinations that are well protected.
- Any and all passwords that Veeam uses should be complex and very hard to remember.
- The destinations – like the SMB share should be patched regularly and maintained properly.
- Passwords that Veeam use are encrypted inside of Veeam.
- You can also further protect your Veeam server using normal security processes that is already in use on your Group Policy like Microsoft Hardening Guides. But the fact you have limited access to your SMB is very powerful.
- Store the passwords in a secure location. That means no Excel, Word, post it notes. The best option today is to use 1Password for Teams but there are other tools that can be used to generate, protect and audit passwords (I have used this one and it worked just fine).
- Veeam can do end to end encryption. I do not suggest turning that on unless you think about it first. Do you really need it? It will not help with malware attacks but it will for the insider issues.
- If you are using a dedupe appliance, try to make sure it is not using SMB or CIFS but rather something else. Malware could in fact follow an SMB connect down to a deduple appliance and ruin your day. So a proprietary connection to the dedupe appliance would mean that would not happen.
- Remove the Domain Users group from your Veeam server Users group. This can help secure things by making man in the middle attacks harder.
- Make sure you know what account(s) are in the local admin group of your Veeam servers.
- Make sure that SQL is using SQL accounts for the access and databases.
- Make sure the Veeam service account is not in AD but a local account.
Much harder, as it costs money, but try and put all or your most important virtual machines in a backup copy job where the destination is the cloud (like this). This is very good protection. Malware or inside scumbag’s will have a very difficult time getting access to those VMs! This is the best because there is different credentials and an API for access in the cloud and that makes it harder for malware or bad guys to exploit.
Generally speaking, treat your Veeam environment as a tier 1 app. So complex passwords and least access for people. And put as much of your protected VMs into the cloud.
I hope that this helps and let me know if you have questions or comments. Some background info came from Luca in this article. And yes, I suspect he will write the official security stuff as he is one serious smart dude.
I do think that Veeam will get something official and likely more detailed at some point in the future, and I quite look forward to it. But in the meantime I hope that this helps and let me know if you have questions or comments.
- 6/18/17 – added in about using local accounts for SQL and Veeam. Also changed the part about using GPO to secure your service. I have thought a lot about that and think better to use local accounts and not have any Veeam servers in AD. This will help with ransomeware and potentially internal human organized threats as well.
- 7/18/16 – added the comment about removing domain users from users, and making sure you know what is in the local admin group.
- 6/27/16 – updated re the comment about dedupe appliances.
- 5/6/16 – added the comment about not using SMB but using Windows or Linux and letting Veeam move the data. That is more secure, especially if you do the permissions so only Veeam has access.
=== END ===