Introduction
Ransomware attacks are top of mind for all IT professionals and backups are the last line of defense.
The single most important best practice is to make sure you can recover from your backups by:
-
Implementing immutability
-
Encrypting your backups
-
Verify recoverability
-
Have a recovery plan
-
Harden and limit access to your backup infrastructure, especially the repositories.
Ample security guidance can be found in Veeam's user guides and best practices.
Curated by Veeam Solutions Architect and Systems Engineers, Veeam has also published a library of Technical Security Blueprints to address joint Vendors configurations.
In this post, I would like to focus on Hardening and Limit Access to ObjectFirst repositories.
For those unfamiliar with ObjectFirst, it is a Veeam dedicated S3-Compatible Object Storage appliance that implements Out Of The Box Immutability (Ootbi) and leverages Veeam Smart Object Storage API.
My colleague, SteveF, has blogged about the SOS API and ObjectFirst.
Securing access to the Ootbi appliance
The ObjectFirst security blueprint is a good place to start, and I would recommend reading Securing Access to an AWS S3 repository.
-
The ObjectFirst user guide discuss securing access to the appliance by:
-
Implementing Physical Security
-
Enabling 2FA (web console access)
-
Disabling SSH
-
Restricting/Disabling IPMI access
-
IP Whitelisting (more on this below)
The "Settings>Security" section of the web interface is where you can configure most of these items.
-
Consider setting up a proxy server to control the appliance's internet access and ensure secure updates.
-
Use IAM policies to implement least privileges principle and to support multi-tenancy which is key for our VCSPs.
-
For Agent-based backups, leverage IAM/STS.
How to use the IP Whitelist
Getting IP Whitelisting right can be a bit tricky depending on the backup type and repository access permissions.
Keep reading if you want to know more.
What does IP Whitelist do? It only allows listed server access to the Ootbi Appliance.
Depending on how you declare your Ootbi repository, you may have to enter multiple IPs or possibly IP ranges.
The connection mode also affects how you can control Access Permissions within Veeam.
Please note that the Whitelist accepts single IPs or entire Subnets.
For subnets, you must use the CIDR format (/8, /16, /24 …). Decimal notation (aka 255.255.0.0) won't work!
Connection Type: Direct
In this mode, the processing proxy (NAS and VMs backups) acts as the gateway to the Object Storage.
Agent based backups will access Object Storage directly or via a gateway depending on the selected Access permissions.
Declaring the repository
At the very least you need to add the VBR server's IP to the Whitelist.
If you have specified your mount server and helper appliance, you should also add these Ips to the Whitelist as well.
Note: When left unspecified, the mount and helper roles get attributed to VBR.
Backup operations
Add all your VM proxies' IPs to the Whitelist.
For NAS backup, you should add all your General Purpose Proxies.
-
If you do not add your General Purpose Proxies, the mount server will act as the gateway to the object store.
-
If your mount server is left to the default settings (VBR) then your backup will fail.
With Agent backups there are multiple possible configurations
-
Agent Jobs managed by VBR or the Agent
-
Access permissions set by VBR through gateway server or leveraging IAM/STS.
Note: Shared credentials is not a safe method and should be avoided.
The only Access Permissions that works without adding Endpoint IP addresses to the Whitelist is "Provided by the backup server"
Repository backup maintenance operations
The Helper's IP must be added to the Whitelist.
Restore operations
The Mount Server's IP must be Whitelisted
Connection Type: Gateway(s)
In this mode, all traffic flows through the selected gateway(s)
Declaring the repository
You must Whitelist the Gateway(s) IP addresses and the VBR server IP address.
While technically only the Gateway IP is required, VBR needs to be able to communicate with the appliance to register it as an S3-integrated repository.
Be aware that if the VBR IP is not whitelisted, the repository will be declared as S3-compatible.
This can cause issue with the ObjectFirst internal load balancing.
Backup operations
For VM and NAS backup, you do not need to Whitelist any of the proxies, only the gateway(s) needs to be whitelisted.
For Agents Jobs where the Access Permissions are set to use the gateway server then only the gateway server needs to be whitelisted.
IAM/STS cannot be used when accessing the Object Storage via gateway(s).
Repository backup maintenance operations
The Helper's IP does not need to be added to the Whitelist.
Restore operations
The Mount Server's IP does not need to be Whitelisted
Summary
Thank you for reading. I hope you enjoyed this post!
In this post I covered the Hardening and Securing of an ObjectFirst repository and especially details for IP Whitelist and its caveats.
While specifying an object storage gateway(s) seems to be the easiest in terms of IP Whitelist, keep in mind that VBR always need to be Whitelisted for proper S3-Integrated operations to occur (Smart Object Storage API).
The downside of using gateway(s) is the lack of IAM/STS support for Agents.
