2FA - word from Gostev

[JonJR]

Just reading this week's "Word" and I had a few thoughts:

As I explained before in a few two-factor authentication (2FA) related Veeam forum threads, adding this feature to the Veeam console itself makes little sense, and is best compared to putting a vault-grade door into a chain link fence - considering that the hacker can always connect directly to the backup server instead. In other words, what you really want to protect with 2FA is your backup server itself.

I would certainly agree that you need 2FA on your backup server (and proxy servers & in fact any Windows or Linux server)- we use Duo as suggested in the post. Also on any computer the Veeam backup console is installed on, we have a policy that mandates that it has 2FA (again using Duo). But this isn't something we can totally enforce and an attacker could just install the B&R console on any computer they have obtained access to and then access the Veeam server (firewall rules wiling). If the Veeam console had 2FA it would add another layer of protection - somebody could do a lot of mischief with "just" Console access.

Looking at our other management consoles; vCenter does MFA with tokens and v7 does ADFS which can be MFA'ed, we use Jamf for our Macs, again this does SAML with MFA - I get these are both web consoles so it's a different scenario, but a brief Google tells me that Commvault has 2FA on it Commcell Console, no longer familiar (thank god) so don't know the rationale behind it.

Finally, I can see that this could be a regulatory step at some point in the future, where we have to 2FA all the things regardless of the effectiveness of it.

[rhys.hammond]

I agree, native 2FA on the Veeam console is a good thing.

I've had good results with customers leveraging the windows firewall on the VBR server itself to restrict port 9392 to only machines with Duo installed.
Just remember that VBEM also uses port 9392 to collect information from VBR so the server running VBEM also needs to be on the allowed list.

[rteglgaa]

I totally agree. MFA on the console is definitely something we would want as well. We use the remote console a lot as well.

[Wocka]

Not Veeam related, but there was also the line

"Windows 10 support 2FA natively, however many customers use Windows Server, which does not provide such feature natively, thus requiring 3rd party 2FA software. "

Can anyone point me in this direction as everything I have seem required Azure AD for this to work.

Regards

[Gostev]

You need to use the Microsoft Account for this. There are many guides/videos available, just google for "Windows 10 2FA".

[jraymond]

I just wanted to chime in. I brought the mention of 2FA on the backup server to the boss and we went one step further. We decided to use Dou 2FA on all 22 of our servers. Set up a group of only admins that are allowed to use 2FFA and the server can no longer be logged onto unless you are enrolled in Duo and are in the Admin group. Great suggestion!! Thanks!

[evilaedmin]

What if the vector is remote powershell and someone does a (psuedocode):

Code: Select all

Get-VbrRestorePoint | findstorage() | DeleteFile() 

[SvenP]

I totally agree, 2FA for the console would be great (even better combined with SAML and/or LDAP authentication on the VBR server instead of local users/groups). And while you're at it: it should be usable without administrator credentials on the machine. My guess is, you are using it for updating the console and mouting during restore. Services could do those parts IMHO.

[rhys.hammond]

What if the vector is remote powershell and someone does a (psuedocode):

Code: Select all

Get-VbrRestorePoint | findstorage() | DeleteFile() 

To my understanding, MFA isn't going to prevent remote PowerShell attack vectors so 'online /accessible' backups managed by Veeam will be deleted.
CC-B with insider protection, immutable s3 buckets, tape, etc being some of the best choices to reduce the impact of such an attack.

The big question is can we prevent powershell being remotely executed and would it affect any Veeam services that might rely on it.
I haven't tested myself but it certainly seems possible to block remote access to session configurations with Disable-PSRemoting, disabling the WinRM service, deleting the listener, disabling firewall exceptions, or setting the value of the LocalAccountTokenFilterPolicy to 0.

https://4sysops.com/wiki/disable-powers ... ion=535052