Veeam B&R postgresql - let installer deploy it?

[newman]

Veeam B&R can deploy postgresql database upon install so the same operating system will run the database and the backup server component too. Did some research around MFA and found it too easy to alter the some database entries to elevate my/other user's rights and even turn of MFA for accounts completely. This is caused by the fact that if Veeam installs postgre that will use SSPI/SSO and Administrator in the hosing OS can get to the database without any further authentication.

While I do agree that security and integrity of the hosting Windows Server OS is crucial, some might think MFA enabled in Veeam will increase security level of the whole, however it is questionable. At this point I more likely suggest to deploy postresql to a different server and create a user in that database to let Veeam use it.

What is the general statement of Veeam to attacks toward its configuration database?

[Mildur]

Hi Peter

There are multiple methods to disable MFA. One of them is also posted in the forum.
But all methods require write access to the configuration database or local admin permissions on the backup server.

Therefore it's very important to protect your backup environment from any unauthorized access. As soon someone can access the operating system of the backup server with an account with local administrative permission, there is nothing he cannot do. Even if you use another server for the database, an attacker on the backup server itself will be able to export the SQL configuration and connect remotely from the backup server to the database server.

As a basic principle, no one should be able to login via any remote management tool directly to the backup server and server where the configuration database is hosted. For Maintenance tasks, deploy MFA for RPD and the local console. Also consider to put RDP access behind a firewall and only allow trusted people to access those systems. Helpdesk users can work with Enterprise Manager or Veeam backup console from a jump host. They don't need to access the backup server per RDP in normal cases (Recovery or backup troubleshooting).

Best,
Fabian

[Gostev]

It is important to always remember that "There's no protection against root". No architecture will protect you from hackers with admin privileges to a backup server (regardless of backup vendor) and it's a waste of time to try and come up with one.

At this point I more likely suggest to deploy postresql to a different server and create a user in that database to let Veeam use it.

This means ultimately your backup server will need to have the ability to extract stored database user credentials and connect to the database server with them. Which means hackers who are able to gain admin-level privilege to a backup server will likewise be able to do all the same. As such, separating configuration database gives nothing in terms of added security.

The only real and true protection is securing backup server access. This is done by disabling all remote access protocols (or blocking them in firewall) and leaving only backup console port accessible, as this connection is MFA-secured. So you're left only with a backup console and a physical console access, which makes remote take over of this server a really challenging task

[newman]

I think it is just about time for Veeam to deliver an appliance that has all the necessary security features inside and not just make the outer security related actions to someone else's problem. Securing the current solution requires Microsoft Windows Server knowledge, postgre knowledge, malware and virus protection knowledge and if not enough, make the management of those really hard - disable RDP and prevent all remote access to backup server besides console. Not every client is expert in all these areas leaving them vulnerable to literally anything.

The security onion is a good way thinking about this and I am sure many customers would like to have the whole as one.

This is not true in all vendor cases "admin privileges to a backup server (regardless of backup vendor)". In some cases many actions cannot be done without a second admin approving the particular option. Full reset of the solution also not possible - like deleting the database.

[Gostev]

You're completely wrong with your thinking there. Any account with root privileges can do anything at all on the system, completely ignoring the need of any additional approvals a particular software installed on the same system may have implemented.

Just ignore vendors' marketing for a moment and think about it as IT/Linux professional. You have:
- Root level access to the Linux-based appliance OS
- Some piece of software running on this OS that actually implements "second admin approval" for some of its functions.

How can this software possibly prevent an account with root privileges from doing anything at all on the appliance, like deleting something on that system, including the database?

I think you are possibly confusing OS-level admins with app-level admins (users and roles within particular applications).

"Second admin approval" can only work within the realm of this particular application itself, so only when you go through this application's UI and APIs. But hackers won't do this as with root-level access to the appliance OS, you couldn't care less that this application even exist.

[newman]

I think I am completely right here. If root is unknown, since you as vendor know that only - like many storage systems work - out in the field it is very hard to do harm. In my view it gives really a headache to secure Veeam as the "secure the OS and all other stuff however you want" approach is not really customer friendly. Don't get me wrong, I am working for a vendor and this is part of our job, but smaller clients in the SMB sector might not ask a partner to build a Veeam infra.

Veeam is solving just a part of the secure backup system hoping that all other areas will be handles properly. This is not complete and end to end.

[Gostev]

Root is easy to make "unknown" by asking some dedicated security person on the team to create credentials, store them in a safe and don't tell them to anyone... you don't need an expensive storage vendor for that

However, even if root is unknown, there are always periodic privilege escalation vulnerabilities. Including in those secure storage systems, well documented. And my main and only point above is, there's no protection against root. It's just marketing that tries to make you think otherwise, perhaps just to make you sleep better at night.

Veeam's strategy with the SMB sector has always been to have them consume backups as a service from our VCSPs though. Because you are right, they don't have data protection expertise and securing a backup appliance is a tiny portion of the whole story. It's not the reason for the vast majority of recovery failures we see in our support...