Veeam Hardening & Zero Trust Guide: Architecture, Linux Hardened Repositories, and Native Controls

HERMES

HERMES RESILIENCE SCORE & DEFENSIVE RATING

Target: Veeam Hardened Repository & Zero Trust Enterprise Isolation Blueprint

Confidence: 99%

92 / 100

CRITICAL

Measures real-world operational relevance, exploit weaponization, and active threat posture.

Dimension Breakdown

Exploitability 18 / 20

Threat Activity 19 / 20

Weaponization 18 / 20

Exposure 18 / 20

Prevalence 18 / 20

Impact 20 / 20

Exploit Maturity 19 / 20

Attack Chain Potential 19 / 20

⚖️ Divergence & Operational Rationale

Hermes Defensive Engineering rates a hardened, out-of-domain Veeam architecture with Linux Hardened Repositories (LHR) at 92 resilience score. When implemented correctly, immutable XFS storage completely prevents attackers from deleting, tampering with, or encrypting backup chains, neutralizing the leverage of ransomware syndicates even during total Active Directory domain collapse.

🕸️ Connected Knowledge Graph & Provenance

Veeam Backup & ReplicationPRODUCT

Connected Nodes: 0

Non-Negotiable Rule: Never Domain-Join Backup Infrastructure

The single most catastrophic architectural error observed in enterprise ransomware incidents is joining the Veeam Backup Server to the production Active Directory domain. If a Domain Admin account is compromised, the backup server is compromised automatically. Veeam servers, proxies, and repositories must reside in an isolated workgroup or a dedicated out-of-band management enclave.

Executive Summary

Modern ransomware operators specifically target backup repositories to force ransom payments. Traditional protection mechanisms—such as NTFS/ReFS access control lists or storage arrays accessible via Windows SMB shares—offer zero resistance against attackers who acquire administrative privileges.

True cyber resilience demands an immutable, zero-trust backup architecture. This guide provides an end-to-end engineering blueprint for deploying Linux Hardened Repositories (LHR) utilizing XFS block-level immutability (chattr +i), enforcing single-use credentials that leave no persistent network access footprint, configuring Four-Eyes Authorization, and activating mandatory console MFA.

---

1. Architectural Isolation: The Out-of-Domain Imperative

The control and storage planes of your backup system must be decoupled from the identity plane of the workloads they protect.

Flawed vs. Resilient Backup Architecture:

 ❌ VULNERABLE DESIGN (Single Point of Failure):
 ┌─────────────────────────────────────────────────────────────┐
 │ Production Active Directory Domain (domain.local)           │
 │ ├── Domain Controllers                                      │
 │ ├── Workstations & File Servers                             │
 │ └── [!] Veeam Backup Server (Domain-Joined)                 │
 │       └── Compromised Domain Admin = Complete Backup Erasure│
 └─────────────────────────────────────────────────────────────┘

 ✔️ RESILIENT ZERO TRUST DESIGN (Isolated Backup Plane):
 ┌───────────────────────────┐      ┌──────────────────────────┐
 │ Production Corporate AD   │      │ Isolated Backup Enclave  │
 │ (Untrusted by Backup Plane│      │ (Workgroup / Red Forest) │
 │ ├── Domain Controllers    │      │ ├── VBR Server (Local)   │
 │ ├── Production Workloads  │      │ └── Dedicated LHR Hosts  │
 └─────────────┬─────────────┘      └────────────┬─────────────┘
               │                                 │
               └──────── Strictly Filtered ──────┘
                         Micro-Segmentation
                         (No Domain Trust)

Architectural Guiding Principles (ANSSI & CISA Aligned)

1. No Domain Membership: The VBR backup server, proxies, and storage nodes must operate as standalone Workgroup systems or reside inside a dedicated, non-trusted administrative forest (“Red Forest”).
2. Dedicated Local Administrative Credentials: Each backup host must maintain unique, randomly generated local administrator passwords stored in an offline, air-gapped vault. Under no circumstances should local credentials match production machine passwords.
3. Hypervisor Isolation: The management network interfaces of hypervisors (VMware vCenter / ESXi, Hyper-V) must only accept connections from the backup server’s dedicated IP and port.

---

2. The Modern 3-2-1-1-0 Resilience Framework

The traditional 3-2-1 backup rule is insufficient to counter modern double-extortion ransomware operations. Enterprise defense mandates adherence to the 3-2-1-1-0 golden rule:

Rule Element	Technical Implementation Requirement	Threat Mitigated
3 Copies	1 primary production copy + 2 backup copies on distinct infrastructure.	Accidental loss, hardware failure.
2 Distinct Media	Disk-based backup (XFS) + Object storage (S3/Blob) or offline tape (LTO).	Media degradation, firmware corruption.
1 Off-Site Copy	Replicated to a secondary data center or cloud region.	Physical disaster, geographic outage.
1 Immutable Copy	Linux Hardened Repository (LHR) with XFS immutability or S3 Object Lock.	Ransomware destruction, malicious insider.
0 Restore Errors	Automated testing via Veeam SureBackup (sandbox VM boot and verification).	Corrupted backup chains, undetected bitrot.

---

3. Engineering the Linux Hardened Repository (LHR)

The Linux Hardened Repository is the cornerstone of Veeam’s immutable architecture. It transforms a standard Linux physical server into a WORM (Write Once, Read Many) appliance.

Linux Hardened Repository (LHR) Immutability Architecture:

 ┌─────────────────────────────────────────────────────────────┐
 │ Veeam Backup Server (Windows Control Plane)                 │
 └──────────────────────────────┬──────────────────────────────┘
                                │
                                │ Data Mover TCP Stream
                                │ (TCP Ports 2500-3300)
                                ▼
 ┌─────────────────────────────────────────────────────────────┐
 │ Physical Linux Server (Ubuntu 22.04 / 24.04 LTS, RHEL 9)   │
 │                                                             │
 │ ┌─────────────────────────────────────────────────────────┐ │
 │ │ Veeam Data Mover Daemon (veeamtransport)                │ │
 │ │ - Runs as non-root unprivileged service account         │ │
 │ │ - Interacts with file system using XFS Reflink engine   │ │
 │ └────────────────────────────┬────────────────────────────┘ │
 │                              │ Sets chattr +i attribute     │
 │                              │ for specified retention days │
 │                              ▼                              │
 │ ┌─────────────────────────────────────────────────────────┐ │
 │ │ XFS Filesystem Mountpoint (/mnt/veeam_immutable)        │ │
 │ │ - Formatted with: mkfs.xfs -b size=4096 -m reflink=1    │ │
 │ │ - Operating System kernel enforces immutable flag       │ │
 │ │ - Even root cannot unlink or modify files while +i set │ │
 │ └─────────────────────────────────────────────────────────┘ │
 └─────────────────────────────────────────────────────────────┘

Physical vs. Virtual Considerations

Defenders must deploy LHR as a bare-metal physical server. If LHR is deployed as a virtual machine on VMware ESXi or Hyper-V, any threat actor who gains access to the hypervisor management console can simply delete the virtual disk (.vmdk) or snapshot the VM, completely bypassing the OS-level immutability.

Step-by-Step LHR Deployment Guide

1. OS Installation & Minimal Footprint: Install a minimal distribution of Ubuntu Server 22.04/24.04 LTS or RHEL 9. Do not install graphical interfaces, web servers, or unnecessary third-party packages.
2. XFS Filesystem Formatting with Reflink: Format the backup storage volume using XFS with fast-cloning (reflink) support enabled:

   # Format dedicated storage block device (e.g., /dev/sdb)
   sudo mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sdb
   
   # Create mount point and configure fstab
   sudo mkdir -p /mnt/veeam_immutable
   echo "UUID=$(sudo blkid -s UUID -o value /dev/sdb) /mnt/veeam_immutable xfs defaults,noatime 0 0" | sudo tee -a /etc/fstab
   sudo mount -a

3. Dedicated Non-Root User Provisioning: Create an unprivileged service account for Veeam transport services:

   sudo useradd -m -s /bin/bash veeamsvc
   sudo passwd veeamsvc
   sudo chown -R veeamsvc:veeamsvc /mnt/veeam_immutable
   sudo chmod 700 /mnt/veeam_immutable

4. Grant Sudo Rights for Deployment (Temporary): The Veeam Backup Server requires temporary sudo access during the initial deployment to install the transport daemon:

   echo "veeamsvc ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/veeamsvc

5. VBR Server Deployment with Single-Use Credentials: In the Veeam console:
   • Navigate to Backup Infrastructure > Managed Servers > Add Server > Linux.
   • Select Single-use credentials for hardened repository.
   • Input the veeamsvc username and password. Veeam connects over SSH, installs veeamtransport, registers the service, and automatically purges the stored credentials from VBR memory.
6. Post-Deployment Lock-Down (Crucial): Once deployment is complete, immediately remove sudo permissions and disable SSH:

   # Remove temporary sudo permissions
   sudo rm -f /etc/sudoers.d/veeamsvc
   
   # Disable and stop SSH server to prevent network shell access
   sudo systemctl stop ssh
   sudo systemctl disable ssh
   
   # Verify immutable attributes on backup files
   lsattr -l /mnt/veeam_immutable/

---

4. Native VBR Security Controls (v12 / v13)

Veeam Backup & Replication includes several built-in defensive features that must be explicitly activated in enterprise deployments.

Four-Eyes Authorization (Two-Person Rule)

Under normal operations, an administrator who accesses the VBR console can delete backup chains or shorten retention policies. The Four-Eyes Authorization feature enforces the two-person rule:

Four-Eyes Authorization Workflow:

 [Admin 1: Compromised Account] ── Attempts to Delete Backup ──► [VBR Control Plane]
                                                                        │
                                                                   Action Held
                                                                   in Pending State
                                                                        │
 [Email / Alert Triggered] ─────────────────────────────────────────────┘
          │
          ▼
 [Admin 2: Security Approver] ──── Must Authorize Request Within 24h
                                   (Separate Credentials + MFA)
                                   If Denied: Action Aborted, Alert Fired

• Protected Actions: Deleting backups from disk, removing backup repositories, shortening retention periods, disabling immutability, or deleting secondary backup copies.
• Implementation: Enabled via Main Menu > Users and Roles > Security Settings > Enable Four-Eyes Authorization. Assign separate security approver roles.

Mandatory Console Multi-Factor Authentication (MFA)

Introduced to prevent credential-stuffing and stolen credential reuse on the VBR console:

• Enforces Time-Based One-Time Password (TOTP) generation via Google Authenticator, Microsoft Authenticator, or YubiKey.
• Protects interactive console access, PowerShell snap-in sessions, and REST API authentication tokens.

Veeam Security & Compliance Analyzer

Veeam includes an integrated automated auditing engine that checks current configuration against established hardening baselines:

• Audits backup server domain membership.
• Verifies immutability settings on all repositories.
• Checks whether backup encryption is active.
• Flags insecure default ports and alerts on outdated Veeam builds.

---

5. Host Firewall & Network Micro-Segmentation

The following scripts demonstrate how to lock down network access to the VBR host and the Linux Hardened Repository.

Windows Firewall (PowerShell VBR Lock-Down)

# PowerShell: Lock down VBR host to authorized management subnets only
$AuthorizedAdminSubnet = "10.100.50.0/24"
$BackupProxySubnet     = "10.100.60.0/24"

# 1. Enable Windows Firewall across all profiles
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

# 2. Block all inbound traffic by default
Set-NetFirewallProfile -Profile Domain,Public,Private -DefaultInboundAction Block

# 3. Restrict Veeam Management Port (9401)
New-NetFirewallRule -DisplayName "Veeam-Control-9401-Restricted" `
    -Direction Inbound -Protocol TCP -LocalPort 9401 `
    -RemoteAddress $AuthorizedAdminSubnet -Action Allow

# 4. Restrict MountService (6172) and ThreatHunter (6175) to Proxy/Admin Subnets
New-NetFirewallRule -DisplayName "Veeam-MountService-6172-Restricted" `
    -Direction Inbound -Protocol TCP -LocalPort 6172 `
    -RemoteAddress $BackupProxySubnet -Action Allow

New-NetFirewallRule -DisplayName "Veeam-ThreatHunter-6175-Restricted" `
    -Direction Inbound -Protocol TCP -LocalPort 6175 `
    -RemoteAddress $BackupProxySubnet -Action Allow

# 5. Allow Data Mover Dynamic Streams between Proxies and Repositories (2500-3300)
New-NetFirewallRule -DisplayName "Veeam-DataMover-2500-3300" `
    -Direction Inbound -Protocol TCP -LocalPort 2500-3300 `
    -RemoteAddress $BackupProxySubnet -Action Allow

Linux UFW Firewall (LHR Host Lock-Down)

#!/usr/bin/env bash
# Lockdown UFW script for Linux Hardened Repository (LHR)
set -euo pipefail

VBR_SERVER_IP="10.100.50.15"
PROXY_SUBNET="10.100.60.0/24"

# Reset UFW rules
sudo ufw --force reset
sudo ufw default deny incoming
sudo ufw default deny outgoing

# Allow outbound DNS and NTP
sudo ufw allow out 53/udp
sudo ufw allow out 123/udp

# Allow Data Mover connection from VBR Server
sudo ufw allow from "$VBR_SERVER_IP" to any port 6162 proto tcp comment 'Veeam Transport Daemon'

# Allow Data Streams from Backup Proxies (Ports 2500-3300)
sudo ufw allow from "$PROXY_SUBNET" to any port 2500:3300 proto tcp comment 'Veeam Data Mover Stream'

# Deny all SSH access permanently
sudo ufw deny 22/tcp comment 'Block SSH'

# Enable firewall
sudo ufw --force enable
sudo ufw status verbose

---

6. Enterprise Hardening Audit Checklist

Use this audit matrix to perform regular verification of your Veeam backup posture:

Hardening Requirement	Verification Method	Status	Compliance Impact
Backup Server Out-of-Domain	Run (Get-WmiObject Win32_ComputerSystem).PartOfDomain	Must return $false	Prevents AD domain compromise propagation
Linux Hardened Repository Immutability	Run lsattr /path/to/backup.vbk	Must include i flag	Prevents ransomware deletion or encryption
SSH Disabled on LHR	Run systemctl is-active ssh	Must return inactive	Prevents remote network shell intrusion
Single-Use Deployment Credentials	Verify no stored credentials in VBR database	Verified empty	Prevents lateral movement from compromised VBR
Four-Eyes Authorization Active	Check VBR Users and Roles menu	Enabled	Blocks rogue single-user backup purge
MFA Enforced on Console	Attempt console login without TOTP	Blocked	Mitigates credential reuse and stuffing
KMS Backup Encryption Enabled	Inspect backup job configuration	AES-256 active	Protects backups during offsite exfiltration
SureBackup Verification Active	Review SureBackup job completion logs	Daily verification	Guarantees zero restore errors

---

7. Master Series Navigation & Related Intelligence

Part 1: Architecture & Threat Actors VBR components, data mover channels, and threat campaigns (Akira, FIN7, Qilin).

Part 2: Vulnerability Matrix & Exploitation Deep Dive Technical dissection of CVE-2024-40711, CVE-2023-27532, CVE-2024-29849, and CVE-2026-44963.

Part 4: DFIR Forensic Investigation & Database Triage ProgramData log triage, SQL database querying, and DPAPI credential decryption forensics.

Active Directory Security Masterclass Investigate Kerberoasting, AS-REP roasting, and DCSync credential harvesting.