Immutability

Veeam Hardened Repository is a WORM (Write Once, Read Many) storage solution built into Veeam Backup & Replication since version 11, based on Linux and using built-in xattr capabilities to enforce file immutability at the filesystem level. It has passed an external audit for WORM storage and meets the highest compliance standards, and supports the DISA STIG security profile.

Veeam Hardened Repository is a WORM (Write Once, Read Many) storage solution built into Veeam Backup & Replication since version 11, based on Linux and using built-in xattr capabilities to enforce file immutability at the filesystem level. It has passed an external audit for WORM storage and meets the highest compliance standards, and supports the DISA STIG security profile.

There are two ways to get one. Deploy it using Veeam Infrastructure Appliance - pre-configured and hardened out of the box specifically to operate as a Hardened Repository, with no manual work required. Or build it yourself, on the Linux distribution of your choice, following the official setup guides.

Regardless of which route you choose, here’s a checklist of configurations and parameters you should control.

Management Interfaces and Remote Access

Out-of-band management interfaces - IPMI, Dell iDRAC, HPE iLO, and equivalents - operate below the operating system and can override any protection the OS enforces, including immutability. If reachable, they let an attacker reset, reimage, or otherwise tamper with the system regardless of how well the Linux layer above is hardened. Restrict access to these interfaces with firewall rules and MFA where supported.

SSH deserves the same scrutiny. It’s necessary during initial deployment, but an SSH session with sufficient privileges is another path to the same low-level access. Disable SSH once setup is complete, and if it must remain available for maintenance, restrict it to key-based authentication and to the specific accounts that require it.

Account Model and RBAC

Removing the immutable attribute from a file requires root privileges - but root is not the only path to that capability. Any account with a sudoers entry broad enough to run the relevant commands, or to obtain an interactive root shell, has the same power regardless of what the account is named. Disabling the root account, as recommended by the DISA STIG profile, addresses one path. It does not address a permissive sudoers configuration that recreates the same access under a different name.

A repository should run with a deliberate separation of privilege: no interactive use of the root account, an administrative account scoped to the specific tasks it needs, and a service account limited to writing backup data, with no privileges beyond that. Review sudoers entries with the same care given to root access itself.

Patching

A repository exposed to known, unpatched vulnerabilities is not hardened, regardless of how well everything else is configured. Deployed as a Veeam Infrastructure Appliance, this is largely handled: updates are managed and applied automatically by Veeam Updater. On a self-built repository, patching is the operator’s responsibility, and it should not depend on someone remembering to do it - automate it, for example through Ansible or an equivalent configuration management tool, with updates checked and applied on a defined schedule.

Time Manipulation

Setting retention on immutable backups relies on the system clock. If an attacker can move the clock backward, an immutable file could, in principle, appear to have already reached the end of its retention period ahead of schedule. Standard NTP has no protection against this: it authenticates nothing, so a man-in-the-middle can feed a client false time data outright.

Veeam Backup & Replication and the Veeam Hardened Repository detect large timeshifts on their own, blocking retention operations and raising a warning without any configuration required. On top of that built-in protection, run NTP with authentication rather than the unauthenticated default - Network Time Security (NTS), standardized in RFC 8915, authenticates the time source using TLS and is the current recommended mechanism, having replaced the older Symmetric Key and Autokey methods, both of which carry known weaknesses.