Summary of Anti-ransomware measures

[McKITGuys]

Hi all,

I have read some of the *long* posts here about ransomware but usually come away "foggy" with just the amount of info. So instead I watched one of the Veeam webinwars regarding ransomware and that helped "a bit" (the webinar was more of an overview and short on details). I would like to have a very short "to-do" list for myself and the other IT admins.

So can I propose this list and then please have others either add to it or clarify it or say "not worth doing". I realize that the "magic bullet" is probably the last item but would like to enable as many worthwhile measures as possible:

1) all admins use accounts with lower level privileges for everyday work and use a 2nd privileged account for server work
2) Veeam processes use unique credentials (-not- general admin logins etc)
3) Admins logging into Veeam console should use their creds, not general admin creds
4) there should not be any shares open from production servers to the Veeam backup servers
5) for admins, they should not save their admin credentials when logging in via RDC to servers (does this matter? - can a ransomware object fish out the credentials and use them to open up an RDC session to a server?)
6) copy Veeam backups to media that gets disconnected ("air-gapped") such as rotatable external drives or tape

Anything else? We are not a big company so maybe some of those at larger companies have already figured out the policies needed and can help us out.

Thanks.

[DeadEyedJacks]

I'd also add
Restrict access to backup repositories to connections from specific known IP addresses only. i.e. the servers actively involved in backup and restore processes.

Restrict interactive login to the backup servers, backup admins to use a nominated backup management server with the Veeam console installed, not their regular general purpose system.

Depending on the scale of your environment and budget;
Put internal firewalls between end user networks, server networks and backup networks using separate IP ranges and VLANs.

Basically put some physical / logical separation between your users, admins, servers and storage where ever and whenever possible.

[McKITGuys]

Thanks. A few follow up questions if I could:

I'd also add
Restrict access to backup repositories to connections from specific known IP addresses only. i.e. the servers actively involved in backup and restore processes.

Restrict interactive login to the backup servers, backup admins to use a nominated backup management server with the Veeam console installed, not their regular general purpose system.

Follow up: should the backup admins use their "admin credentials" (i.e. not their everyday credentials but the one they have with Domain Admin rights) to access the "Veeam Management Server" or should we create a "VeeamAdmin<xxuser>" (e.g. VeeamAdmin-Joe") account for each backup admin i.e. a separate account only used to access the Veeam backup servers.
- if so, a few follow on questions from that:
a) okay to create a domain account? okay to give it membership in the Domain Admins group?
b) or should it be a local account on each of our Veeam backup servers so even harder to get into? If a local account, make it part of the local Administrators group or is there another group that would confer enough rights to "get things done" in Veeam?

So I just need some direction on what credentials would be "really good" without being so restrictive that it makes life difficult. Thanks.

[DeadEyedJacks]

We don't give system administrators Domain Admin rights at all...
There's no requirement to be a Domain Admin to operate Veeam Backup.

Veeam Backup service has the credentials it needs to access protected resources, (Again not Domain Admin rights), stored within configuration database in an encrypted format.
There's no need to expose these credentials to system operators.

We've placed SysAdmin accounts into one of three Active Directory groups which match and are nested into the predefined Veeam role groups on the backup servers.

Hope this helps

[ssjgogeta]

a) Avoid having your backup repositories on Network Shares (like SMB/CIFS) which are accessible from your production network;

b) If there is no choice but to use SMB/CIFS for backup repositories, use hidden shares (ending in '$') locked down with the appropriate Share/NTFS permissions;

c) Network Segmentation! Firewall(s) between end-user networks and your backup infrastructure;

d) User education to combat Malware which primarily enters the network via the email system;

e) Applocker / Software Protection Policies.

f) Good luck.

[CarlMcDade]

This kind of reiterates the points you've made, but Rick put this post together:

https://www.veeam.com/blog/tips-to-prev ... orage.html

Cheers

[CarlMcDade]

Hello,

Recently a new customer of mine had told me a story about been a victim of a ransomware attack, and this unfortunately had encrypted his online Veeam Backups. As this is a hot topic ( i know there is some other posts about this subject) i wanted to highlight a couple of articles to help bring this back into focus:

This article is from Rick, on seven top tips to help you protect your backps:

https://www.veeam.com/blog/tips-to-prev ... orage.html

Below is an article i have written, demonstrating a use case for Veeam Cloud Connect to also help.

https://carlmcdade.com/2017/04/10/using ... ndsomware/

Whether you're a customer, partner or service provider. Give these a read and spread the education around this piece.

Thanks for reading

[bgalante]

Hi,

I'm reading about ransomware etc on the forums. I've been hit with one before so I want to be proactive.

Is there a best practice doc, or a doc that explains different methods to implement offline backups?

Right now, I backup to a NAS share, then the backups are replicated to a vsphere at my DR site. I understand if someone gains acess to my veeam console they can delete everything. I'm trying to understand, is securing access to the B&R console the main goal, or.. how else is the offline backup accomplished.

I do also have some backups going to a cloud connect server, but thats vulnerable to if someone gets inthe console.

Thanks for any info!

[DaveWatkins]

Offline or Air-gapped backups are exactly that.

The common options are tape that is then removed from the drive/library and placed is a controlled environment, or rotated HDD's that are physically disconnected and again placed in a controlled environment.

This isn't so much to combat someone having access to your Veeam Console, although it will certainly cover that too. This is primarily to combat ransomware and other automated destructive operations. If a determined hacker actually got to your Veeam console, you have no way to know how long they have had that access so simply restoring from tape isn't really an option anyway. You'd build from scratch and import your data manually at that point

[CarlMcDade]

Hello,

Here's a few links for you which may help you:

This thread is a collection of measures other users are doing to help protect their backups from ransomeware:

veeam-backup-replication-f2/summary-of- ... 42046.html

Two important links within that thread for me:

Ricks seven steps is an important post to read through:

https://www.veeam.com/blog/tips-to-prev ... orage.html

Ive put this one together on how using Veeam Cloud Connect can help you with this:

https://carlmcdade.com/2017/04/10/using ... ndsomware/

[shaun_ec]

We use VEEAM cloud connect for our offsite backups, but looking to secure the local backups onsite.

We have a VEEAM server with a Fibre HBA connected to our backup SAN. Looking to secure this repository by setting the file permissions. VEEAM seems to need the SYSTEM user to be granted access to the repository else the backups fail with access denied. Looking to setup a local account and assigning only this account access to the backup repositories.

1) If I change the VEEAM services to start-up using this new local account. Will VEEAM still need the SYSTEM user to be granted access to the repository
2) What is the minimum permissions that is needed to be assigned to this account?

[ChrisSnell]

Having a true air-gap is of course the best protection to take. However, as mentioned in a post above, using a non SMB/NFS share is a great step locally too. Veeam's Data Mover allows for just this. By using an appliance, such as from ExaGrid, Veeam customers can use the Data Mover and ensure that the only route in to the backup shares is through the Veeam GUI, a big leap in protection compared to a public share.

[McKITGuys]

We don't give system administrators Domain Admin rights at all...

We've placed SysAdmin accounts into one of three Active Directory groups which match and are nested into the predefined Veeam role groups on the backup servers.

Hope this helps

I realize this is an old thread but re-reading it - which groups do you put your sys admins into on your backup servers - are these pre-defined either local groups or AD groups? Likewise, would really like to tighten up the rights our admins have and would like to do it via predefined AD groups instead of a "roll your own" setting of permissions on OU's - care to share which AD group seems to work for "everyday" admin. It started off years ago with one admin who just used "administrator" which of course was in Domain Admins; but then there got to be a 2nd admin and now a 3rd...

[DeadEyedJacks]

Only ever put AD groups into Local groups, not user accounts.

Create role based AD groups for admins and lock domain admins / administrator account down, break glass for emergencies only.

Takes time / planning and buy-in from staff...

[jmmarton]

I know this is an old thread, but for anyone who sees this prior to VeeamON, there is a great session on ransomware that will be at VeeamON 2018 entitled "18 tips to prevent ransomware attacks for 2018." There will be many great tips and tricks in this session!

(Shameless plug--I am co-presenting this session with Mr. Vanover).

Joe