Feature request - Enable Host Management UI via VBR

[petesteven]

have had a few instances (currently again, due to an incorrectly specified subnet mask...) where I needed to access the host management/TUI of one or more components.

To activate host management, I have to go through the TUI, but this may not be accessible because ILO/iDRAC is unplugged (security). In addition, the passwords, some of which are 50 characters long, are a nightmare to enter.

It would be ideal if host management could be temporarily activated via the web UI of the VBR server. Of course, this would then have to be secured via veeamso.

But this would be a real added value for the customer and for us!

[Dima P.]

Hello Peter,

Thank you for the feature request. We will note it and discuss with the RnD team!

[pma]

Hi Peter,

Thank you for sharing your example; it’s clear. However, the suggestion to enable the WEB interface on a remote hardened repository with approval from the VSA security officer doesn’t align with our current security framework. This approach conflates different security contexts, effectively making the VSA security officer a global security officer. As a result, any compromise of their account would have far-reaching consequences, amplifying the risk posed by potential attackers. Additionally, it’s not feasible on Windows VBR where veeamso is unavailable.

If we were to move this process to a cross-platform VBR layer - multi-admin approval feature - the protection against deep attacks would still be insufficient if VBR was compromised, making it essentially equivalent to enabling the WEB UI by default on hardened repository appliances.

On a positive note, our application security team is currently validating the Host Manager WEB attack surface, and initial findings indicate strong security. This may make it more practical to enable WEB access by default, with the option for users to disable it manually. However, there could still be concerns if users choose to disable the WEB interface themselves.

Do you think the solution of keeping the web interface accessible at all times would satisfy your requirements, or do you anticipate any potential concerns with this approach?

[petesteven]

Hi Maksim,
Okay, I can understand that, given the current security level, you’re concerned that managing this centrally via the VBR poses a security risk. However, if the Veeam user has to authenticate with a password and MFA, it would obviously be much more secure. But of course, security comes first.

From a security perspective and in terms of how customers feel about security, I don’t think it’s a good idea for the web interface to remain permanently enabled. Even if it would, in a sense, fulfill my request. We’ve always argued that after installation, only Veeam’s base ports are used (and even those are only opened dynamically), and that the repository is otherwise invisible on the network. If the WebUI is permanently enabled, that argument falls apart. In that case, I’d prefer the option from my request: introducing a button to enable and disable it.

[pma]

Hi Peter,

Given the sensitivity and the numerous components at play, it is essential that we evaluate both the complexity and potential risks of this feature with our application security team. At this stage, I am unable to provide an estimated timeline for its delivery.

Additionally, a quick thought: since users must authenticate with both a password and MFA to access Host Manager – which is the default configuration – doesn’t a feature that enables WEB HM access behind MFA essentially equate to “WEB HM enabled with mandatory MFA” from a marketing standpoint?

I acknowledge that, with the option where WEB is enabled by default, an attacker would need to compromise two sets of credentials (one for VBR and another for Host Manager of the hardened repository). However, implementing a global feature that requires root permissions to configure the web interface introduces a new attack surface. This change might broaden the potential for exploits, if VBR credentials are compromised – a scenario directly undermines the safeguards that the hardened repository was specifically designed to prevent.

[petesteven]

Hi Maksim,

i don't understand what you mean with this:
Additionally, a quick thought: since users must authenticate with both a password and MFA to access Host Manager – which is the default configuration – doesn’t a feature that enables WEB HM access behind MFA essentially equate to “WEB HM enabled with mandatory MFA” from a marketing standpoint?

[pma]

Hi Peter,

My point was the following:

Your suggestion is: “Activate the Host Management Web interface remotely via VBR, requiring the Veeam user to authenticate using a password and MFA.”
My suggestion is: “Enable the Host Management Web interface permanently and require users to authenticate using a password and MFA to sign in to Host Management.”
In both cases, we enforce the same authentication requirements, which provides an equivalent security level from a practical standpoint.

Also, enabling the Host Management Web interface permanently comes at essentially no cost compared to implementing the proposed feature request.

That said, I do acknowledge this argument:

We’ve always argued that after installation, only Veeam’s base ports are used (and even those are only opened dynamically), and that the repository is otherwise invisible on the network. If the WebUI is permanently enabled, that argument falls apart.

While this doesn’t materially change the real security posture, I agree it could be a significant consideration in compliance-driven environments.
For that reason, I’ve added this feature to the backlog for consideration in a future release.

[petesteven]

Great, thanks a lot!