Crypto protection (ransomware) for repositories

[lando_uk]

Hi

I don't have any Shares for repositories, my repo's are proxies so the backups stay on the servers.

The only risk I see is the Admin shares - D$, E$ , F$ etc as a potential path to the VBK's, am I safe to disable these admin shares on the Veeam servers?

I know these shares would only be vulnerable if a domain admin got hit with some ransomware, which is unlikely but not impossible.

From a support case point of view, have any of you Veeam guys seen any backup files been targeted in the wild yet?

Thanks
Mark

[adrien.herve]

Mark,

For my point of view, it's not the only risk. It's highly possible that a CyptoLocker will success to infect a server by using a Windows breach. In this particular case it can infect your proxy and its local disk which is the repository of your backups too. For me it's necessary to have an off-line and maybe off-site backup with tape and/or cloud replication.
If this is not possible you can maybe try to enable a scheduled shutdown/power on your proxy by using the management card. In this case your backup server is only vulnerable when it's up & running, it will be down and not directly accessible the rest of the time.
Tell me if I'm wrong but I think you need to have admin shares enabled to install or upgrade your proxy from the backup server.

Adrien

[olafurh]

Hi,

It's easy just to disable SMB on the repository server it self without a reboot.

Get the current SMB status:
Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

Disable SMB
Set-SmbServerConfiguration -EnableSMB1Protocol $false
Set-SmbServerConfiguration -EnableSMB2Protocol $false


Olafur

[lando_uk]

I'm thinking we can limit the exposure using internal firewalls and access lists - limit how a future crypto-type worm can access the servers from. I think removing the D$, E$, F$ etc admin shares would be ok, as the B&R server probably used just C$ admin to update system files, I just need some clarification on that.

We have 1:2:3 system with offsites, so risk is low, but I'm mainly thinking how to make it bullet proof and build that into any future designs from day one.

[lando_uk]

It's easy just to disable SMB on the repository server it self without a reboot.

Thanks Olafur, I guess for those who use remote SMB shares for their repo's this script could be run before and after each job is run, so SMB is only available when a backup is running.

Maybe we need a Veeam hardening whitepaper...

[Moebius]

Maybe we need a Veeam hardening whitepaper...

I seem to remember that Luca Dell'Oca was working on such a white paper.

[dellock6]

I wrote my part, now it's in the hands of our solution architects. It may take some time as we decided to make it a full hardening guide.

[francs]

How about putting you repositories on Linux servers?
I'm talking about minimal linux installation with only the necessary ports opened for Veeam to use it.
No Samba, as the virus seems to scan for all network shares and encrypt them too.

As far as I understand it, when the Veeam server sends backups to a Linux repo the following happens:
- It starts a ssh shell
- Kicks of a perl script
- Data is send from the proxy to the linux server using a specified number of ports.
- This exchange of data between proxy and repo looks to be proprietary to Veeam. In other words it doesn't use something like SMB/CIFS.

To get to your repositories the virus will have to do the following:
- Infect your Veeam server and/or proxy
- It won't find any "normal" network shares it can infect
- Interrogate Veeam to find a list of repositories and their IP's.
- Somehow, find the credentials to the repos, stored in Veeam
- Use that to ssh to your linux repo and encrypt the files

So, how safe is Veeam's credential storage?

[ita-tomi]

You can also disable "File and Printer Sharing for Microsoft Networks" under NIC Properties. Or use Windows firewall and disable these services/ports, there are already defined rules for File and Printer Sharing.

[tinto1970]

i don't know if it was a good idea... but for the same reason i have moved my repo located in the DR site from windows to linux. I hope it's a bit safer.

Waiting to read the Hardening Guide from Luca

[Delo123]

Not sure if allowed here, but this helped us a lot securing things...

http://www.thirdtier.net/ransomware-prevention-kit/

[yasuda]

If you want to stick with Windows, how about taking your repository hosts off the domain? Veeam connects to their shares using local credentials, and those shares and admin shares will not be accessible to domain admins. We do this when we set up Veeam Endpoint Backup with backup to NAS shares. I read a good blog post by Veeam on protecting VEB backups from ransomware, and a lot of those ideas would be applicable to B&R. As Francs pointed out, you are depending on Veeam storing credentials safely, and you will be vulnerable to unpatched exploits (Badlock! 1 week to go), but the only protection I see would be air gapped or write-only backups.

You could disable and enable your SMB shares with Task Scheduler to limit access outside backup windows, and that would give a you a chance to catch the ransomware before backups start.

[superture]

I wrote my part, now it's in the hands of our solution architects. It may take some time as we decided to make it a full hardening guide.

What's the status on the guide pls?