Manage agent without SMB or RPC

[controlfreak]

I'm trying to manage an agent in a high security network zone. We do not allow SMB or RPC access into this zone. Is it possible for a veeam server in another zone to manage this agent without using RPC 135 or SMB 445? I don't need remote agent install or upgrade features, only pushing server type backup configuration jobs to the agent.


Thanks,

Control

[Dima P.]

controlfreak,

I am afraid this wont work. Maybe standalone agent deployment to a local smb repository will work instead? Thanks!

[controlfreak]

Hey Dima P,

Can we make this a feature request?

We have a high security zone with NERC CIP classified assets that must remain compliant to federal cyber security standards. One of the requirements is enforcing 2-factor authentication for interactive remote access. Allowing RPC and SMB to be initiated from the veeam server in the less secure zone to the high security zone creates a "compliance trap", because the veeam RPC/SMB traffic is exempt (not interactive) but a user could mistakenly browse to a protected asset in the secure zone (e.g. \\super-secure-system\c$) from the veeam server due to RPC/SMB being allowed for agent management. This user interactive remote access would be a compliance violation with the potential for extreme monetary penalties. Adding a veeam server into the high security zone adds a new classified asset with additional compliance overhead, so that's not our first choice. With regards to choice of protocols, SMB is often exploited, so we want to limit it's footprint on our network.

In our environment, other software agents in the high security zone always initiate the traffic outbound. We consider this to be more secure since the traffic initiates from within the secure zone. Maybe the veeam agent could check in with the veeam server at certain intervals and pull it's policy? We don't want to install or update directly from the veeam server, so we wouldn't need RPC/SMB inbound for this (and if we did, we would create a temporary firewall rule to enable only during install or upgrade work).

Other agents use encrypted and proprietary ports and protocols. Allowing these protocols to make inbound connections is preferred due to the reduced attack surface (no RCP/SMB vulnerabilities).

These agent systems in the secure zone already have outbound SMB access to our veeam repository servers, so transferring their backups to the repository is not an additional security concern.

We have user ID capabilities on our firewalls, but these features from our firewall vendor have not been reliable enough to use for production backup traffic.

This would be a great selling point for future NERC CIP customers too!

Thanks,

Control

[ctg49]

"Allowing RPC and SMB to be initiated from the veeam server in the less secure zone to the high security zone creates a "compliance trap", because the veeam RPC/SMB traffic is exempt (not interactive) but a user could mistakenly browse to a protected asset in the secure zone (e.g. \\super-secure-system\c$) from the veeam server due to RPC/SMB being allowed for agent management."

If you have an application-layer firewall (I assume you're referencing this above), or if the super-secure-system is Windows, could you build a firewall rule on the target machine which only permits the user account (done via an ipsec-based FW rule) of the VEEAM service account? Also, within Windows firewall at least, you can configure a rule at the program/service-level, only permitting SMB/RPC access to the agent, rather than explorer/the rest of the system.

Not sure if this is acceptable to an audit, though. If not, it should be!

[controlfreak]

Thanks for the suggestions, especially regarding the host firewall on the agent system. We have application and user aware network firewalls also, but the user agent ID is not always 100% perfect. Out plan is to use technical controls where we can make them work efficiently and user education to help mitigate the risk. For ultimate simplicity from the system admin perspective, having the agent initiate the connection outbound would be better, even if it still used RCP and SMB.

Using technical controls and user education will be acceptable in an audit as long as they work, but when it comes to Energy sector regulations, there are no warnings. Cases of non-compliance almost always result in significant monetary penalties for each day of non-compliance, even if the entity finds and resolves the non-compliance on its own.

Thanks again for the ideas ctg49!

[Dima P.]

Hi folks,

Sorry for keeping silence and thank you for updating the thread!

Control, Will it work if all the connections between agent and Veeam B&R are wrapped up in a single proprietary protocol (something similar to direct backup to cloud connect)? Cheers!

[controlfreak]

Hey Dima P,

Yes, that would completely resolve our concern with the current use of agent/server protocols.

Thanks,

Control

[Dima P.]

Thank you, consider you vote being added to this feature request. Cheers!

[controlfreak]

Thanks, Cheers to you!

[jmmarton]

Allowing RPC and SMB to be initiated from the veeam server in the less secure zone to the high security zone creates a "compliance trap", because the veeam RPC/SMB traffic is exempt (not interactive) but a user could mistakenly browse to a protected asset in the secure zone (e.g. \\super-secure-system\c$) from the veeam server due to RPC/SMB being allowed for agent management.

This can be mitigated by only allowing the Veeam service account specified in the protection group properties access to the machines in question for deployment. That way if a user logs in interactively to the Veeam server, his/her credentials would not allow access to the devices in the high security zone. That may address things for now until some sort of future enhancement addresses this.

Joe

[controlfreak]

Thanks Joe, that is how we are mitigating the risk currently.

[michaelsbak]

I'd like this too!

[e.rottier]

Will it work if all the connections between agent and Veeam B&R are wrapped up in a single proprietary protocol (something similar to direct backup to cloud connect)?

Heck yeah! This would be so good if implemented.

No more SMB open to cryptolockers or other malware nonsense!
Yes, I know there are other solutions like immutable storage and such, but reducing the attack platform on the Veeam system itself is worth implementing such a wrapper protocol.