Feature Request: Two-factor auth support for Veeam Console MFA 2FA

[randy.belbin]

Hey there Veeam team!

I'm currently playing around with Backup and Replication in my home lab and I have to say that so far, I'm pretty impressed. Truly great work!
On the 2FA front, I have to say that backups (should) contain every piece of critical and sensitive data that a company owns. It seems really silly to go through all the trouble of putting 2FA on servers only to have the backups accessible with just a password. File level browsing and restores are great until they make their way into the wrong hands.

I'll be the first one to admit that access to the Veeam Console should be very tightly controlled. As in the only access should be from an admin workstation which is protected with 2FA. However, I think it would be awesome to have native 2FA support in the console for that extra piece of mind or for those folks who can't properly segment their networks.

Now for the full disclosure part - I work for RSA and we have a phenomenal partner engineering team that would be more than happy to work with your devs to implement our REST APIs into your products. 2FA is quickly becoming ubiquitous or table stakes or whatever we want to call it and we'd love to help you make strong auth another awesome feature of the Veeam console.

[crackocain]

+1.

Actually great fit "Veeam Authenticator" app iOS and Android

[Escapo IT]

+1

[olavl]

+1 for MFA - integrate with Azure MFA, Google Auth, MS Auth, Duo etc.
+1 for console authentication with Radius/LDAPS

[Gostev]

@Olav I am just curios, are you using all these MFA systems at once?

For example, why would you use both MS Auth and Duo at the same time? We were just evaluating both for the internal use, and it seems like a binary choice: you either go with one or the other - not both.

Also, from the same evaluation I believe Azure MFA and MS Auth is the same thing, no?

Also, I believe Google MFA is for Google Accounts only - so, how are you using it for Windows infrastructure (logging on to Active Directory etc.)?

[olavl]

@Gostev: missed this post, but I'll throw in some thoughts now.

A Veeam customer should protect the console and repository through firewall, zoning etc. But having multiple MFA for console access should be part of a enterprise backup system in 2019.

I listed a couple of alternatives for MFA as an example, if Veeam will implement MFA for console and powershell access you might consider having multiple alternatives to suit your customers needs.
A Microsoft/Azure shop might be on Microsoft Radius or Azure MFA, some on Google Auth and others on Duo or Authy.

Using Google Authenticator requires the app installed on android or IOS, but logging in can be any account since you only add the code-generating to the Auth app. See panda/commvault for examples.

Some examples:

• https://www.pandasecurity.com/usa/suppo ... ?id=300156 - Panda supports Google Auth, Authy and HDE OTP

• https://documentation.commvault.com/com ... p=7887.htm - Commvault supports Google Auth, Comvault Token, email and desktop application.

• https://www.veritas.com/support/en_US/article.100043814 - "Veritas is planning on enhancing NetBackup's ability to work gracefully with MFA or 2FA authentication types in a future release of NetBackup."

[amarshall]

We have a client requesting this for Cloud Connect - it's a deal breaker for them, part of the requirements from global HQ for any Cloud/SaaS service. Either using an authenticater fob/app or OTP.

What are Veeams thoughts here? I didn't hear anything about any sort of MFA at VeeamON?

[ferrus]

Adding my name to the request for 2FA access for Veeam.
This should become more standard across most applications TBH - and since Veeam potentially holds ALL data for all applications ...

We use Google authenticator across all our 2FA systems. I don't believe the MS/Google authenticator apps are vendor locked at all.


One question though. From a security perspective, have you improved much by introducing 2FA to the console - when most actions are available through powershell?

[sswayd]

+1

[tomnewman]

+1

[ShawnKPERS]

+1

[riahc3]

Sure, we could RDP into our B&R server with 2FA

There you go; You have 2FA to the console already.

I dont understand why people have a unhealthy obsession with 2FA. Not everything needs 2FA and things can be put before that SHOULD require 2FA.

Are you going to want that UAC uses 2FA as well? Or Powershell commands?

[soncscy]

While I agree, keep in mind, often Security Requirements aren't a choice, they're a mandate. Think like PCI DSS which, thankfully, isn't too ridiculous in and of itself, but those tasked with enforcing it often haven't read the material, or lack the ability to understand what is being required.

Cargo Cult Security is an awful practice, but that doesn't mean that everyone doing it does so willingly; sometimes you just gotta check that box in order to get home by 6 pm that night. 2FA probably won't save most people if they're really hit by some new ransomware (hell, last time we had a site get hit, the local admin had 2FA enabled, and went ahead and authenticated something from an unknown process anyways figuring it was some cronjob he forgot about)

I always tell people, the biggest threats are craft hackers or cleverly disguised packages with malicious payloads; it's the emails that go "Hey Bob! Look at this!" and Bob blindly clicks through.

[skrause]

There you go; You have 2FA to the console already.

I dont understand why people have a unhealthy obsession with 2FA. Not everything needs 2FA and things can be put before that SHOULD require 2FA.

Are you going to want that UAC uses 2FA as well? Or Powershell commands?

My Backup system which gives access to literally ALL of my sensitive data isn't something that should have 2FA?

Veeam created the remote console for a reason, having to stop using it because I need 2FA instead of it being integrated into the product is what the request is about.

[JamesMcG]

+1. Come on, all arguments aside there's no reason Veeam shouldn't have this as an option.

[Gostev]

My Backup system which gives access to literally ALL of my sensitive data isn't something that should have 2FA?

But so do your domain controllers and Domain Admin accounts. Do they have 2FA enabled for every logon? And I'm not necessarily talking about modern factors everyone is so excited about lately. For example, smart cards have been around for as long as I remember myself, and are not uncommon among Veeam users.

And if you do use 2FA on accounts used for managing other equally sensitive parts of your infrastructure, then what exactly prevents you from enabling 2FA on Veeam administrator accounts too?

[Gostev]

Come on, all arguments aside there's no reason Veeam shouldn't have this as an option.

The main question here is how useful this option will be in the real world. I would hate to postpone other, potentially more valuable features to build a lonely steel door in the park - if you know what I mean. Which is why it is so important for me to ensure we're not wasting time on building a "checkbox feature".

The main argument against is that implementing 2FA in the backup console alone is useless, because hackers can use the same compromised Veeam admin account to connect directly to the backup server instead (via KVM, RM, RDP, WMI, PowerShell, etc). So, until your implement 2FA for the actual backup server, there's no point to individually secure different remote access methods that can potentially be used. Because a chain is only as strong as the weakest link.

However, as soon as you do implement 2FA for the backup server, securing individual management methods is no longer required at all. Does it make sense?

In other words: what is the point of installing a bunker door in the fence, when a door made of fence's material will provide equal overall protection? However, in these circumstances, the whole area should definitely be surrounded by a proper stone wall with the manned checkpoint (2FA for the backup server).

[skrause]

The issue is that I can run the remote console on a system (like my workstation) where I use a different account to log into the backup console. I can easily set up 2FA on the server itself (and I do for the vast majority of our server infrastructure) that isn't the issue, really.

Right now, it is a situation where if someone wants 2FA on the application administration they need to have the users RDP into a system protected by 2FA rather than be able to have it integrated into the remote console which can be run from anywhere.

Of course, I may move that direction anyway simply due to wanting to limit network access (even more) to the backup infrastructure, but it would still be nice to see Veeam implement some form of 2FA on the application interfaces for B&R, Enterprise Manager, and maybe even VeeamONE.

There are other features that I would consider a much higher priority though

[unsichtbarre]

I am also -1 on this.

Two-factor is an infrastructure/directory issue and should be implemented at that level! It's just like overly complex passwords and password aging (ideas disproved recently by NIST), implementing two-factor at the level of an application that should ideally run UNDER a two-factor authentication DIRECTORY will lead to all kinds of problems and unwanted loss of data. Even allowing it is a BAD IDEA!

Here's my vision/fear (from the service provider/support perspective): If customers are able to enable two-factor directly on Veeam they will. Inevitably situations will occur where the authorized user is unavailable - or worse yet (think hurricane Sandy), where the two-factor SYSTEM is unavailable. Sure, there are always around - but do you want to be able to rapidly recover/fail-over your data or many authentication-based steps away from even starting the recovery process?

Don't lock the lock!

[tstarken]

We have non-domain joined repositories so that if we are compromised a hacker would not gain credentials to connect to the off-domain repository. However, all this is for not if a hacker could simply log into the Veeam Console and remove backup data through the console which has the stored credentials to the off-domain storage. Please - we need 2FA to secure the console to prevent this from happening. Only other option is tapes, but the amount of data that we have would take days to write vs. drive write speed on our NAS.

[Gostev]

Hello, did you consider installing Veeam on Windows 10, and using its built-in 2FA? Because even if the console is locked out with 2FA, there is still PowerShell and internal APIs that can be used to remove backup data. Which is exactly why it is important to lock down the machine as a whole (as opposed to individual apps). Thanks!

[rteglgaa]

Just read through this article:

https://www.bleepingcomputer.com/news/s ... ainst-you/

...and it had me wondering... Why isn't MFA used in SAN management software, Veeam Backup software, etc.? In other words: systems that tend to hold all your data. Seems like logic to me, that systems like that was protected against credential theft of admins. Does anyone disagree?

I would sure like to sure it as an added security feature in an upcoming Veeam version. We use Sophos Central as anti-virus solution, and they have it incorporated on the management interface for all admin accounts.

/Rasmus

[olavl]

Discussed before a few times, example:
veeam-backup-replication-f2/feature-req ... 37867.html

[oscaru]

+1
As a Cloud Connect service provider, I think that 2FA would still give a chance to customers to have its data untouched by cybercriminals (at least in their Cloud Connect Copy) with stolen credentials and access to things like powershell to delete backup data on local repos (as it is common in attacks these days). We know that Insider Protection does not completely protect customers from smart attackers doing targeted attacks. 2FA can make Cloud Connect an almost "Air-Gapped" solution.

I remember @Gostev writing recently about one horror story of one attacker that even deleted tapes from the LTO library attached to the Veeam Server (It was even kind of funny to read that the criminal actually google things like "how to delete tapes in Veeam" from the same Veeam server)

And yes! I have read about Duo, and of course also this https://www.veeam.com/wp-beat-ransomwar ... ation.html

But I still think, having 2FA in the Veeam Console would be a great feature and a great DIFERENTIATOR that adds value to customer and helps positioning Veeam against other availability solutions.

[thecaptainwtf]

So I've an idea where it can be configured so a secondary form of authentication be needed in order to perform high level operations such as deleting data, changing job settings like retention/encryption etc.

Example, If I want to delete data, Must enter MFA password, or set it so it can be compatible with google OTP where the code is constantly rotating.

Also limitations on behaviors allowed within the console would be useful as well, Jobs can only run X amount of times per X hours to prevent potentially malicious actors from just continuously running jobs to overwrite good data with bad data by running enough jobs to overwrite the retention period if your period is set to points not days if they're not able to delete data.

While little things like this may not be the for sure way to protect people from data loss, still gives them more of a fighting chance not to mention not all organizations have access to really knowledgeable IT resources, like ones that may be on the payroll or utilize an MSP to be able to configure jobs leveraging object storage with immutability or some people aren't aware that you can use CC providers w/ insider protection enabled but even then once again still not a guarantee.

[Gostev]

Please see my response above. If you want the real protection against malicious actors, you need to secure the entire backup server with something like Duo (which is super easy to implement, and is free for up to 10 users). More importantly, it will provide the real protection, and not just the feeling of it from seeing 2FA on the console: "I have 2FA on the console so my backups must be safe".

[jticyber]

I haven't used Veeam in a few years and just started a trial with a Cloud Connect service provider and was very surprised to find 2FA missing, so I found this thread and just finished reading it...

So it seems like some people think protecting RDP on the host server with 2FA protects the whole thing from password attacks...which of course isn't true (although +1 for protecting RDP with Duo)...but even if you put 2FA on the console - that doesn't solve the whole problem.

The console and the agent use the same credentials to connect to the server. If the agent could still authenticate without 2FA, someone with those credentials could still to anything an agent could do with your backups. If that account's setup for a read-only agent, that means an attacker could still start/stop jobs and do a file-level restore. If the agent has full admin access - they can then of course modify, delete, etc.

Re-tooling the agent/server comms to use a more modern authentication mechanism that doesn't use a user's credentials is probably a heavy lift, but what about certificates? It looks like the agents can validate the server's certificate, but not the other way...if the agent had a certificate, the server could validate it before doing anything which would prevent a bad actor from having their way using a stolen password. Has this been considered? Configuration would still probably be a pain...

Otherwise, like some others have rightly suggested, a partial mitigation could be using firewalls to restrict access to the Veeam servers by IP address, etc...which probably doesn't sound good or exciting for service providers who have MSPs serving SMBs with agents deployed places that don't have static IPs...

I've always loved Veeam as a backup platform, and at first glance using a Cloud Connect service provider seemed like an easy way for people to get on Veeam, but as a security consultant I'm going to have a hard time endorsing this as an application that can be safely used on the public internet without putting the whole thing inside a VPN tunnel, especially for customers who are in sensitive sectors (healthcare, financial, gov) or bound by regulations.

[Gostev]

Your concerns appear to come from lack of knowledge the Cloud Connect capabilities - both in general, and in particular for agent backup. You certainly don't need a VPN with Cloud Connect, and you never use the same credentials for the console and for the agent. Plus, there are features in Cloud Connect like Insider Protection and support for immutable backups. But there's just too much to unveil here, and it would be a complete off-topic since this discussion (and this forum) is not about the Cloud Connect infrastructure. We have the dedicated (and very active) private forum for the Cloud Connect service providers with lots of real-word knowledge collected. If you are a registered Veeam VCSP, then just apply to the corresponding forum user group, and you will be granted the access automatically with the weekly script. Thanks!

[jticyber]

@Gostev thanks for the quick reply.

I was just trying to help illustrate why people are asking for additional protection for access to the console like 2FA...and of course you don't NEED a VPN with Cloud Connect, but if a customer requires security controls that aren't there, it's a potential mitigation.

Re: using the same credentials - maybe my VCSP isn't following best practices for credentials, so I've raised that with them. In the meantime, they've already responded and said 2FA's on its way in an upcoming release, so that's great news.

[Gostev]

For the Veeam Service Provider Console, yes indeed it's coming. For web UI access protection specifically, built-in MFA is a perfect fit.