MFA V12

[Ciso_2021]

Hi guys,

i may not payed attention to the MFA, but i was wondering.
let say we have MFA activated on the VEEAM Gui of the only users, but if the VEEAM server is compromissed, they can still delete the local storage, either of it D or E.

i understand this could be handy if your backup storage is else where, like ISCI / Extern Storage.

is there a to configure this for a local VEEAM, not in the Domain ?

Thank you

[ronnmartin61]

If the server was compromised yes of course they could just delete backup files from the volumes mounted to the server. It really wouldn't matter if they were direct-attached or iSCSI, etc. MFA does not require AD domain membership

[Gostev]

If you're logged on to the server as admin you could just format the volume itself. No 3rd party app installed on the server can somehow prevent this, including Veeam.

You really want to have your backups stored on an immutable or air-gapped media. With Veeam, you have many options including hardened repositories, object storage, rotated drives or tape.

[Ciso_2021]

When we have a Remote SMB storage, which is accessible only thought the VEEAM App.
if i understand correctly only the direct mounted disks can be formated / encrypted by a ransomware attack.
example, the SMB network which is added to the VEEAM server. it won't be attacked / deleted?
we are looking for a only back hardened repo cannot seems to find the right one for a right price.
is de MFA on VEEAM VM intergrated or only to launch the VM Console ?

[Moopere]

@cisco_2021

> if i understand correctly only the direct mounted disks can be formated / encrypted by a ransomware attack.
example, the SMB network which is added to the VEEAM server. it won't be attacked / deleted?

No this is not right. I've seen ransomware reach out across SMB networks to anything the compromised account has access to.

[Regnor]

An attacker will also be able to access the SMB share if the backup server gets compromised. This means he will be able to delete or encrypt your backups, for example.

MFA will only protect access of the Veeam Console but not the backup server itself.

[Ciso_2021]

what i am trying to say, is if the there no mapped SMB network on the server attached. so no H or K disk mapped.
but the SMB is only added as a repo in the veeam, which won't be launched because the console is protect with MFA.
the smb need to be access by a username and password.
there is no way the attacker can by pass the MFA console to access the smb connection between the veeam and extern smb server ?

[albertwt]

@Ciso_2021,

If the root password or the admin password is compromised, then the backup can be removed or deleted anyway.

[Gostev]

MFA is not a replacement for immutable backup storage no matter how you spin it. While you can and should harden the backup server access (by the way, V12 includes the built-in Best Practices Analyzer that will help you do that), keep in mind the attacker can and will just attack a NAS box behind the file share directly. Because popular low-end NAS devices typically have a huge attack surface - I mean, just look at the release history of their security patches.

[Ciso_2021]

Thank you guys for your answers.
i am not talking about NAS, but Windows 2022 SMB share server which is else where and only accessed by VEEAM user over the VPN.
of course when the share user password is compromissed i understand it can / could be deleted when the attacker knows the subnet the share is on.

immutable media is only a online backup or can be made on a Windows / Centos on Prem ?

[soncscy]

Hi Julien,

> the smb need to be access by a username and password.
>there is no way the attacker can by pass the MFA console to access the smb connection between the veeam and extern smb server ?

Think like an attacker for a moment. They don't want to use a UI because to use any UI, that requires low latency and good connection, so everything is just some shell returning information typically. Ransomware hackers will "sit" in an environment for weeks or longer, but they're monitoring everything without the conveniences of modern computing.

What you should understand from this is that MFA won't help you in this situation. If the share is accessible from the Veeam server or some component the hacker has access to, all they need to do is run Get-SMBConnection repeatedly and catch that the Veeam server/component has a connection. Once they have that, they can figure out ways to compromise the share with AD accounts they pulled, or just pull the passwords from Veeam.

MFA is both good and bad I guess; I push back against it being a check-list item for my clients because they put too much stock into MFA and don't get how to use it effectively and what MFA protects against.

If you're in a position for it, plan for immutable repositories; you can spin up a (physical) Ubuntu server pretty fast without deep linux knowledge and the defaults for Veeam should avoid any pitfalls you might encounter even if you're not familiar with Linux.

But don't bank on SMB and MFA to protect from a ransomware attack. It is provenly simple to pwn both.

[Ciso_2021]

@soncsy your answer is well explained thank you so much.
ubuntu server is the idea what we are going to use soon with 12TB as immutable media.
are there any tutorials out there to use ubuntu as a immutable storage?
the tutorial i have found so is this one https://www.veeam.com/blog/installing-u ... itory.html
can we use this on a vmware esxi or it need to be on a physicall server ?

i am trying to understand, if the veeam is comrpomissed, you are dead.
if we follow up the beste practise, the veeam will be as secure as possible, of course nothing is not hackable.



Thank you

[albertwt]

@Ciso_2021,

Have you followed through with the steps created by Mr. @Gustav veeam-backup-replication-f2/build-an-im ... 79074.html ?

[Ciso_2021]

Thank you Albert.
i already deployed one and i am working on testing it,

[benf]

Would be nice to get Immutable backups on Windows. But in the meantime, this is something we did that hopefully helps.

#1 - We stood up Windows 2022 servers for BU storage. They are NOT domain joined and each one uses custom user/password for logins.
#2 - We put these servers behind their own Firewall segment and vlan. Only the ports required for Veeam are accessible from the Veeam servers
#3 - We have MFA on those Windows logins (Duo) and accessible remotely only from our management network.

It makes restore a pain since all these devices in our backup strategy are not 'domain joined' they are all stand-alone WinFW on, seperate vlans and firewalls between them.

Locking down the Veeam 'App' is going to simply add another layer of protection. We do have immutable backups when we roll out to our S3 provider.

Hopefully that helps if you want/need to stick with Windows for now. If anyone has major 'holes' they see in this, I am all ears. (Outside of running it in Windows). BTW the reason we went with Windows is in our testing ReFS volumes seem to do a much better job on performance, encryption, rolling up images etc than anything else. Could have been misconfigured in linux but that's where we ended up.

[pybfr]

Being able to delete backups from Veeam is a major hole in my book, that exactly what the hardened repo has been designed to prevent.
As for XFS, yes there was probably an issue with your setup, since XFS is every bit as fast as ReFS and probably more robust…

[benf]

Thanks! I put a link to this thread back to our engineers to re-review. I don't disagree and even though we can get immutable back from S3, why lose 7 days if the issue came about.

[fspadaro]

Thank you Albert.
i already deployed one and i am working on testing it,

H,
To improve security you also can change the default ntp service in Ubuntu using chrony:

Improve NTP Security With Chrony as Client on Ubuntu

https://www.veeam.com/blog/securing-har ... tacks.html

This client it's helpful for NTP attack.