Console Password

[MattCutt]

Hi there,
We are running Veeam Backup on a dedicated server in workgroup. We also have an offsite repository. The account we run require admin rights. My issue is that if a third party manages to get onto this server with admin rights, they can delete the local repository and also open Veeam and delete the offsite repository. There needs a way to actually password protect the Veeam Console App. We deal with other backup products and they have a console password. Even though you have admin rights, when you are open the app, you are still prompted to enter a password. I think Veeam needs to offer something like this. Or have other people used a third party to encrypt/ protect the console app? Cheers!

[HannesK]

Hello,
and welcome to the forums.

There needs a way to actually password protect the Veeam Console App

that would not help... powershell can also delete backups. Separation of duty needs to be done at a different point. Depending on what your third party really has to manage, it might help to give them only restore operator permissions, or switch to Enterprise Manager with more granular role based access control.

https://helpcenter.veeam.com/docs/backu ... ml?ver=100
https://helpcenter.veeam.com/docs/backu ... ml?ver=100

Best regards,
Hannes

[Vitaliy S.]

Another way to address that would be to review your offsite repository options. For example, you could target your offsite backups to a Veeam service provider and ask them to enable this option. In this case even if backups are deleted, they will still be stored in "the recycle bin" for the defined number of days. Hope it helps!

[MattCutt]

Thanks guys. When I say third party, I mean Mr Bad Guy ie hacker. I understand we could use a veeam service provider but this is extra cost to the customer. If the hacker can’t access the program as it is password protected via a strong complex password, then they won’t know that a off-site repository exists and would not be able to delete it. Currently if they manage to get admin rights then they can open the console, see that there is an off-site repository and then delete it. Would be great to have an option in Veeam to enable a console password. Well that’s my thought anyway

[HannesK]

that would not help... powershell can also delete backups.

please remember... the console is just one of many ways to access the data. I did not mention direct access to the repository. Someone who is local admin can always dump all credentials (the software vendor is not relevant)

We don't want to make customers "feel safe" while the risk is still the same.

[MattCutt]

Hi Hannesk,
Where is the path of the off-site repository kept? Registry or configuration files? So if they don’t have access to the console they can still work out where the off-site repository resides?

[Regnor]

A console password won't stop the hacker if he's already admin on your server; he would install a keylogger, enter/alter the Veeam Database, look at the network connection, extract credentials and so one. I think you would still lose the fight if someone has enough time or knowledge.

[MattCutt]

Hi Regnor,

Yep you definitely have a point there! Will just continue to harden the backup server as much as possible. Is there a plan to have an azure repository with Veeam with out having to use cloud connect? For example Altaro has it, and the bucket cannot be accessed at all through the program, only through Azure Portal.

[HannesK]

Hello,
Azure and Amazon / S3 compatible is already possible today.

Please check out the FAQ and the linked section of the user guide post338749.html#p338749

only through Azure Portal.

well, Azure buckets can be accessed via API directly (that's the way your they write backups to Azure)... I just need to dump the credentials from your backup software

Best regards,
Hannes

[MattCutt]

Thanks for that! So looks like air gap solution is definitely the only solution then to be safe

[AlexHeylin]

you could target your offsite backups to a Veeam service provider and ask them to enable this option. In this case even if backups are deleted, they will still be stored in "the recycle bin" for the defined number of days.

Vitaliy - are you able to say under exactly which circumstances this will / will not protect the backups?
From what I've been able to find out about this technically it seems to have heavy dependance on the job settings, which in this case the attacker would be able to change to remove / severely alter the data. As VSCP we asked about this setting and were given a whole load of requirements on the tenant side, which there's no way to enforce from SP to side to prevent accidental / deliberate changes which will breach the prerequisites.
I've submitted a bunch of enhancement requests about this whole feature. See cloud-connect-backup-f43/sp-policy-to-m ... 67228.html also.

It's interesting, and sad, to note that "backup to VCSP CC with bin enabled" is not a recommended option in the Protecting against ransomware with Veeam minisite.

[AlexHeylin]

The one bit of good news I have here is that using a separate VBR server, in a workgroup, with the firewall blocking virtually all inbound connections does work fine for Veeam. Just make sure you set the Domain, Private, and Public policies equally strictly just in case someone / Windows changes the connection "type" when you're not looking.

[Vitaliy S.]

Hey Alex,

You're right, insider protection all alone is not the answer against hacker attacks, however, it does give another way of protecting backups. Insider protection together with AIR gapped backups (be it tape or something else) can be a good alternative to immutable storage given there is an appropriate infrastructure for that. Yes, I read your post in the VCSP forums, so thanks for the feedback!

As for the lowering retention policy question, there is an extra logic that does not delete backups immediately. See this post from Vladimir in the VCSP private forums > Insider Protection. Questions

Thanks!

[AlexHeylin]

Thanks Vitaliy,

I've given that post a read, and unless I'm missing something it seems to be an admission that CC bin isn't really that robust, and the only "supported" ways for a VCSP to ensure the data is protected are S3 immutability (very costly compared to our local storage) and tape (in 2020 we're still having to rely on strips of rusty plastic which we physically move!?).

When it comes to CC bin - I'm still confused, even though I opened a ticket asking for a single clear guide on how a VCSP who fully manages the tenant backups (but tenant has access to VBR) can ENSURE CC bin will protect the backups from internal attack at the tenant. Support basically said there's a bunch of prerequisites from the tenant side which the SP can't enforce or report against for compliance. So either it's not really fit for purpose (in which case please can it be made fit, see my several enhancement requests about this) or it is fit for purpose, but the documentation is lacking and your own staff don't understand it either.

If the changes I suggested aren't going to be made, or aren't required, it would be REALLY useful if Veeam could state very clearly in one document EVERYTHING required to ensure 100% that no attack at the tenant can compromise the backups in CC repo (for the given time period). The document should not mention tape or S3, as neither should be required to achieve something that's actually fairly simple - replying "Failed: Denied by policy" to some API requests. I get the impression even your own staff are confused about the prerequisites for this to work. Worryingly I've seen Veeam staff suggest that just turning the bin on is enough to ensure protection - which by my understanding is simply not true.

Telling a VCSP to send data to SP-local disk and also S3 in order to achieve this is not a solution. If S3 immutability is the best way to protect against insider attack, the tenant doesn't need the VCSP and could send directly to S3 themselves for a lot less money.

Is it possible to use a SP-side VTL to achieve immutability (from the tenant side), preferably moving backups to VTL so they're not duplicated on disk. If so, please can we have a document on how to use that strategy to ensure protection from inside attack at tenant?

Many thanks

[Vitaliy S.]

Hey Alex,

When it comes to CC bin - I'm still confused, even though I opened a ticket asking for a single clear guide on how a VCSP who fully manages the tenant backups (but tenant has access to VBR) can ENSURE CC bin will protect the backups from internal attack at the tenant. Support basically said there's a bunch of prerequisites from the tenant side which the SP can't enforce or report against for compliance

Do you have a case for me to take a look? Just want to review what our support team has advised you to do.

Telling a VCSP to send data to SP-local disk and also S3 in order to achieve this is not a solution. If S3 immutability is the best way to protect against insider attack, the tenant doesn't need the VCSP and could send directly to S3 themselves for a lot less money.

If we are talking about money only, then yes, it is cheaper, but Cloud Connect and cloud repositories are more than just a cloud storage customers can use. Here is a detailed thread on this: Cloud Connect vs Cloud Tier Copy Mode (private service provider forums)

Is it possible to use a SP-side VTL to achieve immutability (from the tenant side), preferably moving backups to VTL so they're not duplicated on disk. If so, please can we have a document on how to use that strategy to ensure protection from inside attack at tenant?

To use tapes, you need leverage tenant to tape functionality and offer this as additional service to your customers. There are no options from the tenant side to enable it, as tape infrastructure has be prepared by you.

Thanks!

[AlexHeylin]

Hi Vitaliy,

The case is case 04201110 - as I put in the subject of my request which I linked.

I know the benefits of using CC - but it's hard to justify (to the customer) using CC if to provide the protection we should be able to provide (insider attack) then the SP has to back-end to S3 anyway and incur that cost in addition to all the other costs for local storage, servers, and bandwidth etc. If the tenant goes to S3 directly they only incur S3 cost - that's not great for partners. We can offer our CC storage cheaper than S3, but not if we then have to buy S3 to offer proper protection.

I'll have a look at the tenant to tape option, when my brain is a bit fresher.

Many thanks

Alex

[YouGotServered]

@MattCutt,
If you really want to harden your Veeam infrastructure to prevent against any kind of attack, one of the best pieces of literature written on this was by Veeam's own Rick Vanover. Here is the whitepaper: https://www.veeam.com/wp-beat-ransomwar ... ation.html

I highly recommend reading that and taking time to come up with a good top-down approach, hitting every point feasible and possible. I read that article a few months ago and created an actionable technical procedure that we are in the process of rolling out systematically to all of our clients to provide them a high level of security with their backups. I may look into redacting it and posting it for the use of the community.

No one solution is perfect - the best solution is the strategic layering of multiple other solutions.

[Vitaliy S.]

The case is case 04201110 - as I put in the subject of my request which I linked.

Ah, thanks! Missed that for some reason.

I know the benefits of using CC - but it's hard to justify (to the customer) using CC if to provide the protection we should be able to provide (insider attack) then the SP has to back-end to S3 anyway and incur that cost in addition to all the other costs for local storage, servers, and bandwidth etc. If the tenant goes to S3 directly they only incur S3 cost - that's not great for partners. We can offer our CC storage cheaper than S3, but not if we then have to buy S3 to offer proper protection.

Yes, I agree and it's just the matter of additional services you can offer to a client. If I were a client, I would rather go to a partner I know than to a hyper-scaler to deal with my specific problem.

I'll have a look at the tenant to tape option, when my brain is a bit fresher.

Please do and let us know if you have any questions about how it works etc.