ashman70 wrote:I have a couple of questions:
1. If you use an account that is only used to login to the Veeam backup server, is not a member of the domain admin group and there are no shares on your Veeam backup server. How can any ransomeware delete your backups? Unless of course it gets onto your network and sniffs credentials, but is it then logging onto computers with those sniffed credentials, or only deleting files in shares its accessing using those sniffed credentials?
2. If you have a VMWare host that you are replicating to, are your replicas safe from this kind of ransomware attack? Obviously a VM that's had files encrypted or deleted will replicate with those said files encrypted or deleted but previous replicas should be fine, no?
1. Theoretically that might work, but it has some issues in practice. Namely, if your B&R server is accessible, human beings being lazy, they'll likely remote into it (keylogger can grab this) from time to time to do restores. Once the attacker has access to the B&R server, they just tell it to delete all the data and you're hosed. Additionally, since B&R has domain credentials, it must be storing them somewhere and the attacker could theoretically pull them out (encrypted or not, they have to be decrypted by B&R for use, so there's potentially a way to get B&R to give them up or give up the decryption key because that has to be somewhere too).
2. Remember this whole discussion started because Ransomware isn't just about low hanging fruit anymore, we have actual documented instances of breaches where the attacker has bided their time to gather credentials and enough data to know where to strike to do the most damage. Veeam B&R will let you simply delete a replica from disk using a right-click, so if it is compromised, game over for replicas too.
evander wrote:I setup File Server Resource Manager (FSRM) on my Veeam copy job top level folder. I followed a different route to other suggestions on this thread and instead of trying to prevent known ransomware extensions on the drive I blocked ALL files and made an exception just for Veeam files. In this way I don't have to continuously update with new file extensions as they become available.
Many ransomware attacks will encrypt the file and change the extension. Changing the extension in this scenario will fail as FSRM will block it.
I suppose the Veeam files could still be deleted but I would rather try and recover a deleted file than an encrypted file, right?
Different ransomware strains do things differently. Some will create a new copy of a file during encryption and then delete the old one when completed, and these might be stopped by blocking file extensions, but others will encrypt in-place and rename after the fact. In case of those, all you're doing is preventing the file from being renamed, making it hard to identify which files were hit; the data is still encrypted.
If you're doing FSRM, make sure you're taking advantage of its ability to send alerts. I personally use it to run scripts as well as alerting me. That way, under the right conditions, it will take automated action to limit the damage.
hercous wrote:
Hi,
thanks for very insteresting posts! But how do you configure that "offline" backup server only for outbound connection? Veeam Backup Copy Jobs are managed by the Veeam backup server or not?
Regards
I haven't had time to dig into it, so I might be missing something, but here's how I'm thinking of doing it: The "offline" server would sit on a private VLAN completely separate from all your other network resources, or (as in my case) it could be connected to its own private physical interface on the storage hardware (A NAS in my case). Let's call this private network B, and your normal network A. Using either a hardware firewall, or Windows firewall if you can't swing that, configure rules like so:
Inbound (From A to B): Deny all.
Outbound (From B to A): Allow only to storage hardware.
Firewalls are smart enough to understand that a connection allowed from B to A will have to be able to receive reply packets that match the socket from B to A (and only if B initiated the conversation), but otherwise will deny all attempts to talk to A from B.
On the "offline" server, install a new instance of Veeam B&R. This "Veeam Environment" will not be connected to your regular Veeam infrastructure, meaning anyone who manged to compromise that wouldn't even know it existed, which is a bonus. Add your storage as a new backup repository on the "offline" B&R server. If I understand the workings correctly, which hopefully someone can clarify, you can then import backups from your storage and run Backup Copy jobs on those backups to the local storage in the server (or an "offline" NAS that goes with this new server). As I understand it, you won't require any licenses for this since you only need to license for servers you back up or replicate from.
The sticking point in this plan, I think, is if Backup Copy jobs can work under these conditions, which I haven't yet tested.
) you will certainly find good mechanisms to defend your system. If you consider backup to a VBR repository, then you can do backup copy jobs of that data to a repository that supports rotating drives. 
. But I do agree certainly that you do not want to take that change and have as much defense systems or layers (and don't forget the air-gap) as possible as it is getting worse and worse.