Learn Veeam - Hardening & Ransomware Protection

#Introduction

With all workloads protected, there is one brutal question: what happens if attackers target your backup infrastructure instead? Modern ransomware no longer only encrypts production data — they hunt for backups and destroy them so victims are forced to pay. In episode 13 we build the last line of defense: hardening and ransomware protection.

The core principle: a backup must be the final target that attackers cannot touch. Immutability, least privilege, and isolation are the three pillars for that.

#Hardening the Veeam Infrastructure

#Least-Privilege Credentials

Don't use a domain admin or root account for all connections. Apply the least-privilege principle:

Hypervisor: an account with a backup-only role (e.g. Backup Operator in vSphere, a PVE user with limited rights).
Guest credentials: dedicated backup accounts (not full administrators) for application-aware processing.
Service accounts: VBR accounts with the minimum rights needed.

From the console, configure them in Manage Credentials; use different accounts for different roles — don't use one almighty account for everything.

#TLS and Port Lockdown

Enable TLS 1.2+ for all Veeam communication (server ↔ proxy/repo, console ↔ server).
Limit ports to what is needed (full details in episode 14).
Never expose VBR to the internet; access the console via VPN/jump host.

#Console and Service Protection

The VBR console supports multi-factor authentication (MFA) for user accounts — enable it. Make sure Veeam services run with accounts that have no excessive rights, and that access logs are monitored.

#Immutable Repositories

#The Immutability Concept

An immutable repository guarantees that written backups cannot be changed or deleted for a certain period — even by the VBR admin or an infected account. Two main implementations:

#Hardened Linux Repositories

Veeam "hardens" the Linux server: backup files are made read-only at the file system level (using chattr +i / the immutable attribute technique), so changes and deletions are rejected during the immutability window. An important requirement: the repo must live on a dedicated Linux server, not on the same VBR server (an attacker who controls the VBR server must not control the repo).

Check immutable attributes on backup files

lsattr /backups/WebServer-01/*.vbk
# ------i----------  /backups/...vbk   ('i' flag = immutable)

#S3 Object Lock

For object storage, enable Object Lock (compliance/legal hold mode) on the bucket: objects cannot be deleted during the specified period, locked at the object level. Veeam supports this on S3-compatible storage that implements Object Lock (AWS S3, Wasabi, MinIO, etc.).

Important

Immutability is only useful if the repo is separate from the VBR server. Putting an immutable repo on the same server as VBR is like handing the attacker the key to the vault. The correct pattern: VBR on server A, a hardened Linux repo on an isolated server B, S3 lock in the cloud — each with different credentials.

#Veeam CyberDCR: Active Ransomware Protection

Veeam CyberDCR (Data Center for Ransomware Recovery) is v13's feature set for actively fighting ransomware:

Ransomware Detection — detects ransomware activity in guests (VSS, suspicious processes) and flags backups suspected of infection.
Malware Detection — scans restore points to find malware before restore; the backup is then marked Infected.
Cleanroom Recovery — an isolated recovery environment where suspected backups are restored and cleaned before returning to production — breaking the "restore → re-infection" cycle.

Cleanroom Recovery flow

Suspected backup ──▶ Cleanroom (isolated) ──▶ scan & cleanup ──▶ clean restore to production

#Alerting

All detections must reach admins as fast as possible: set up email notifications in the console (Settings → Notifications) and integrate with Veeam ONE (episode 20) for real-time alarms:

Configure global email notifications

Set-VBRSMTP -SMTPServer "smtp.lab.local" -EmailAddress "backupadmin@lab.local"

#A Layered Defense Plan

The complete defense order:

Segregation: repos separate from VBR; separate networks.
Immutability: hardened Linux repo + S3 Object Lock.
Least privilege: minimal accounts for each role.
Detection: CyberDCR (Ransomware + Malware Detection), alerting.
Recovery: Cleanroom + routine drills (3-2-1-1-0 from episode 7).

Tip

Hardening is an ongoing process, not a one-time checklist. Follow the Veeam Security Best Practices in the help center and patch regularly (episode 17 covers the release model). Attackers upgrade their attacks every week — your defenses must keep updating too.

#Verification

After this episode, make sure:

Least-privilege credentials are installed on all connections.
The hardened Linux repository is active; lsattr shows the i flag.
Object Lock is enabled on the S3 bucket (if using a capacity tier).
Email notifications are configured and tested.
(Optional) One Malware Detection scan ran successfully.

#Closing

Key takeaways:

Hardening: least privilege, TLS 1.2+, port lockdown, MFA, separate repos.
Immutable repositories: hardened Linux (flag i) or S3 Object Lock.
Veeam CyberDCR: Ransomware Detection, Malware Detection, Cleanroom Recovery.
Alerting: email + Veeam ONE for real-time detection.
Layered defense: segregation → immutability → least privilege → detection → recovery.

In the next episode, episode 14, we will cover network & ports — port 9392 (default backup, customizable), 443/902 for hypervisors, SMB 445, firewall & segmentation, the rule against exposing Veeam to the internet, using VPN, and MFA for the console. Your network architecture will become safer and clearer!