The VSA "Stress Test": Breaking the Pre-Hardened Appliance
The Veeam Software Appliance ships pre-hardened. Most people take that at face value and move on. This article does not. We walk through what the VSA actually does under the hood - the OS baseline, the role separation model, the SSH gate, the root shell controls - and work through the attack surfaces an engineer would actually try to probe. The goal is to understand why the hardening holds, not just that it does.
The Foundation: JeOS on Rocky Linux with DISA STIG
The VSA runs JeOS - Just Enough Operating System - built on Rocky Linux. JeOS is not a stripped-down Rocky install you tune yourself. It is a purpose-built minimal image that contains only what Veeam's services require to run. No package manager exposed to normal admin workflows, no desktop environment, no services beyond the Veeam stack and the Host Management console, no unnecessary kernel modules loaded.
The DISA STIG hardening applied at build time covers the security baseline that the Defense Information Systems Agency specifies for government and defense systems. In practical terms this means: password policy enforcement (complexity, length, history), account lockout after three failed attempts via faillock, audit rules logging security-relevant events, filesystem mount options (nodev, noexec, nosuid on appropriate mounts), TCP hardening parameters, and a kernel configuration that restricts what unprivileged processes can do. This is not a courtesy checkbox - it is the same baseline defense contractors use for systems handling classified workloads.
SELinux runs in enforcing mode. This is the detail most people gloss over, but it is structurally significant. SELinux in enforcing mode means every process on the system runs with a security context. A process labeled as a Veeam service cannot access files or sockets that are not part of its allowed policy, even if it is running as root. Even if an attacker compromises a Veeam service process, SELinux constrains what that process can do to the rest of the system.
The root account on the VSA is disabled by default. There is no root password to brute force, no su to root from a shell, and no direct root SSH login path. Administrative access goes through veeamadmin (Host Administrator) and veeamso (Security Officer) - two separate accounts with different scopes, neither of which is root.
The Two-Role Model: veeamadmin and veeamso
The VSA creates two accounts during initial setup. veeamadmin is the Host Administrator - the account that configures network settings, manages backup infrastructure roles, deploys updates, and handles day-to-day appliance administration. veeamso is the Security Officer - a separate account whose sole purpose is to gate security-sensitive operations. The veeamso account can only log into the Host Management web UI. It cannot access the TUI, it cannot configure local users, and it has no operational backup administration capability.
The Security Officer account is optional during setup - you can skip it. If you do, the appliance loses the approval layer: SSH becomes available immediately, root shell access is permanent for the Host Administrator, and there is no second party required for sensitive operations. Configuring the Security Officer account is what activates the full security model. Skip it and you have a hardened OS but no dual-control enforcement.
Every deployment guide mentions it as optional. From a security posture standpoint it is not. Without the Security Officer account, a single compromised veeamadmin credential can enable SSH, request root shell access, and have permanent root - all without a second approval. Configure veeamso. Store its credentials offline. Treat it like a break-glass account.
Attack Surface 1: SSH
SSH is off by default. There is no SSH daemon listening, no port 22 open, nothing to connect to. This eliminates the entire class of network-based SSH attacks - brute force, credential stuffing, key compromise - before they can start. From a network perspective, the appliance is not reachable via SSH until an administrator explicitly turns it on.
Turning it on is not a one-step operation when the Security Officer is configured. The Host Administrator requests SSH access. The Security Officer receives the request and must approve it. Only after approval does the SSH daemon start and the port open. An attacker who has compromised the veeamadmin account cannot silently enable SSH - the Security Officer's approval is required, and that generates an event in the audit log that the Security Officer sees.
Even when SSH is enabled for legitimate troubleshooting, the attack surface is the veeamadmin account on a DISA STIG-hardened system with SELinux in enforcing mode. You are not landing in a root shell. You are landing in a constrained user session on a minimal OS with audit logging on every relevant action.
Attack Surface 2: Root Shell Access
Root shell access on the VSA is not a conventional Linux root session. Veeam's own product team is explicit about this: the shell you enter after root access is approved is a virtual, managed shell - not a true root shell. There is no sudo path, no su command, and no way to directly edit arbitrary system files even after the Host Administrator's root request is approved by the Security Officer. The elevated access is granted through the Host Management TUI's managed shell environment, not through an unrestricted terminal session.
The workflow: the Host Administrator submits a root access request through Host Management (web UI or TUI), the Security Officer approves it, and the elevated TUI shell becomes available. That session is granted for eight hours from first login, is not revoked by inactivity timeouts, and expires absolutely after the window closes. Every request, approval, and session is logged in the authorization event log. This is not the same as obtaining a Linux root shell where you can edit /etc/sudoers, modify SELinux policies, or install arbitrary packages.
The faillock policy adds another layer: three incorrect password attempts lock the account. Unlocking requires physical or out-of-band console access and a system reboot into single-user mode - because the root account is disabled, there is no other way to reset the faillock state. This means an attacker attempting to brute-force veeamadmin locks the account after three attempts and generates a recovery scenario that requires physical access to resolve.
Attack Surface 3: The Veeam Backup Services
The Veeam backup services run as non-privileged accounts. They do not run as root. An attacker who compromises a Veeam service process through a vulnerability in the backup software itself lands in a non-privileged context on a system where SELinux in enforcing mode constrains what that process context is permitted to do. The SELinux policy defines exactly which files, sockets, and system calls the Veeam service label is allowed to access. Access outside that policy is denied at the kernel level, not just at the application level.
This is the architectural difference between running Veeam on a general-purpose Windows server and running it on the VSA. On a Windows server, a compromised Veeam service process running as a local service account with broad file system access is a significant pivot point. On the VSA, the same compromise lands in a process context that is constrained by SELinux, on a JeOS with minimal installed surface, with no path to interactive shell escalation without going through the Security Officer approval flow.
Attack Surface 4: The Network Perimeter
The VSA exposes a minimal network surface. SSH is off by default. The Host Management web UI runs on HTTPS. The Veeam backup infrastructure communication runs on the Veeam transport port range. There is no WMI, no RPC dynamic port range, no Windows Firewall complexity - the network attack surface is what Veeam needs and nothing else. The firewall configuration is straightforward to audit because there is almost nothing to audit.
The DISA STIG baseline includes TCP hardening parameters - SYN cookies enabled, ICMP redirect acceptance disabled, source routing disabled, and IP forwarding disabled unless required. These are not dramatic security controls individually, but they close the passive network-level attack surface that general-purpose OS installs frequently leave open by default.
The Remaining Real Attack Vectors
The VSA's hardening is genuine and deep. That does not mean it is impenetrable. Understanding the real attack vectors is what makes the security posture useful rather than just reassuring.
The hypervisor layer is the most significant remaining vector. The VSA runs as a VM in most deployments. An attacker with hypervisor-level access - vCenter administrator, direct ESXi root, or access to the storage backing the VM - bypasses the entire OS hardening stack. They can snapshot the VM, mount the VMDK offline, extract credentials from the filesystem, or simply delete the VM and its storage. The VSA's hardening protects against network and credential attacks against the appliance itself. It does not protect against attacks at the hypervisor layer beneath it. This is why Veeam recommends that production deployments use physical hardware or at minimum ensure the hypervisor management plane is subject to equivalent access controls.
Physical console access is also a path around the hardening. As documented in Veeam's own KB: if you have physical console access, you can boot into single-user mode, mount the filesystem, and work around the root lockout. This is by design - you need a recovery path when accounts are locked. The control here is physical security of the hardware, not software controls on the appliance.
The Security Officer setup configuration matters more than most people realize. If you skip the Security Officer account during installation, you lose the approval layer entirely. SSH becomes immediately available, root shell access is permanent for veeamadmin, and the dual-control model does not exist. The hardened OS is still there, but the access control architecture that makes the hardening meaningful is absent. Deploy with veeamso configured. Always.
The VSA's hardening model assumes the hypervisor layer and physical hardware are out of the attacker's reach. If an attacker has vCenter admin credentials or physical access to the host, the OS-level controls become irrelevant. The VSA's security story is about protecting against credential compromise and network-based attacks at the application layer - not about defending against an attacker who already controls the infrastructure beneath it. Design your environment accordingly.
The Defense-in-Depth Stack
What the Stress Test Tells You
Working through the VSA's attack surfaces is not an academic exercise. It tells you where the real boundary of the security model is. The VSA is extremely well hardened against the credential-based and network-based attacks that compromise most backup environments. It is not a substitute for securing the hypervisor management plane or the physical infrastructure beneath it. Those are separate problems that require separate controls.
The practical conclusion for architects is: deploy the VSA on physical hardware where feasible, or on a hypervisor whose management plane is subject to equivalent access controls and monitoring. Configure the Security Officer account without exception. Ensure the veeamso credentials and TOTP seed are stored offline and are genuinely inaccessible from the backup network. Combine with 4-Eyes Authorization for the Veeam application layer. At that point the attack surface against the backup infrastructure is as small as it can reasonably be made.
- The VSA runs JeOS on Rocky Linux with DISA STIG hardening applied at build time and SELinux in enforcing mode. These are not cosmetic controls - SELinux provides kernel-level mandatory access control that constrains compromised process contexts regardless of user permissions.
- The root account is disabled. No root password exists. Elevated access after Security Officer approval is a virtual managed TUI shell - not a conventional Linux root session. su and sudo commands do not work via SSH. The managed shell is SO-approved, 8-hour maximum, and fully logged.
- SSH is off by default. Enabling it when the Security Officer is configured requires SO approval and generates an audit event. An attacker with compromised veeamadmin credentials cannot silently open SSH.
- The Security Officer account is technically optional but functionally essential. Without it, SSH is immediately available and the managed shell is permanently accessible for veeamadmin. Configure veeamso. Always.
- The real remaining attack vectors are the hypervisor management plane and physical console access - both of which bypass the OS hardening entirely. The VSA's model assumes those layers are controlled. Design your environment to ensure they are.
- Account lockout triggers after three failed login attempts via faillock. Recovery requires physical console access and a system reboot. Brute force attempts against veeamadmin lock the account immediately.