Cloud Connect and Cryptolockers

[ejleipold]

So, how secure is Cloud Connect against crypto locker attacks?

As in, is it enough of an airgap that the crypto locker wouldnt be able to get across it to encrypt the backups?

[HannesK]

Hello,
it depends who the people are, that write the ransomware.

There are two levels of protection with cloud connect
1) it's a protocol that normal ransomware cannot talk to (well, if your enemies have high budget, they might be able to program something special for Veeam Cloud connect)
2) the service provider can turn on "insider protection". That means, data will be kept for some days, no matter what happens.

So as long as you are not attacked by some highly developed intelligence apparatus, I would say it's secure.

Best regards,
Hannes

[ejleipold]

Yeah that's what I thought, cool, thanks.

[AlexHeylin]

To add a note of caution to this - if the attacker gains admin login on the VBR server (which if it's in a domain they most likely will) the can use the GUI (and most likely PowerShell) to delete all the backups from the VCC repo. This leaves you entirely reliant on "insider protection". Make SURE you understand how to set this up properly, and TEST that it works as you expect.
Do not assume it'll be OK with any old settings. Don't assume just ticking the "keep deleted items for x days" box is ALL you need to do - it is not. There are prerequisites in job / copy job setup too. If they're not met, Veeam will warn you by default but the job will not fail and you may not be able to recover from it.

[ejleipold]

Yeah I was more just concerned about the automatated crypto lockers.

[AlexHeylin]

I've been parachuted into two situations to deal with aftermath and investigation of cryptolocker attack. Yes, the operation of the cryptolocker itself is automated - but it's usually the last thing they do. They've usually had domain admin rights in the network for some time, and could easily tamper with / delete backups in that time either manually or by code. Plus the APIs / PowerShell available to drive Veeam make it inevitable that someone will add this directly to cryptolocker code at some point.

Think about it like this - they break in to a building, live there for a while making a mess and stealing everything that's worthwhile. Then when they're ready they set fire to the place on their way out - then stand outside with a "handy" fire truck hoping you'll pay them to put the fire out.

While we're discussing this - the cryptolocker prevention of "eject this drive" in local USB backups can be useful, but is not foolproof. It's fairly trivial to make the OS remount the drive so the backups can be accessed / wiped. I wrote proof of concept code for it because I got bored one evening.

[dalbertson]

I would tend to agree with @AlexHeylin as you should design for the worst case scenario as a SP. it’s also always best practice to not have the Veeam servers part of the domain for these types of reasons. Is it really worth the risk just to have domain login into a veeam server?

[AlexHeylin]

For the record - I've opened a support case [ID# 04180993] requesting specific documentation on how to configure this & enforce it working to guarantee it will work should an attack happen. I've also requested that VBR CC / VSPC has a metric for this providing protection which can be reported / alerted on.