Guide de durcissement et zero trust pour Veeam : architecture, dépôts immuables Linux et contrôles natifs

HERMES

SCORE DE RÉSILIENCE HERMES ET NOTE DÉFENSIVE

Cible : Architecture durcie Veeam Hardened Repository et schéma d'isolation Zero Trust

Confiance : 99%

92 / 100

CRITIQUE

Mesure la pertinence opérationnelle réelle, la militarisation de l'exploit et la posture de menace active.

Décomposition des dimensions

Exploitabilité 18 / 20

Activité de menace 19 / 20

Militarisation 18 / 20

Exposition 18 / 20

Prévalence 18 / 20

Impact 20 / 20

Maturité de l'exploit 19 / 20

Potentiel d'attaque en chaîne 19 / 20

⚖️ Divergence & Justification opérationnelle

L'ingénierie défensive Hermes attribue un score de résilience de 92 à une architecture Veeam isolée hors domaine avec dépôts Linux immuables (LHR). Lorsqu'il est correctement déployé, le stockage immuable XFS empêche tout assaillant de supprimer, d'altérer ou de chiffrer les chaînes de sauvegarde, neutralisant ainsi le levier d'extorsion des ransomwares même en cas d'effondrement total de la forêt Active Directory.

🕸️ Graphe de connaissances connecté & Provenance

Veeam Backup & ReplicationCOMPOSANT

Nœuds connectés : 0

Règle non négociable : ne jamais joindre l'infrastructure de sauvegarde au domaine

L’erreur architecturale la plus dévastatrice constatée lors des interventions post-ransomware consiste à intégrer le serveur Veeam Backup dans le domaine Active Directory de production. Si un compte administrateur de domaine est compromis, le serveur de sauvegarde tombe instantanément. Les serveurs, proxys et dépôts Veeam doivent impérativement être isolés dans un groupe de travail (Workgroup) ou au sein d’une enclave de management dédiée hors bande.

Synthèse exécutive

Les groupes cybercriminels ciblent délibérément les dépôts de sauvegarde pour contraindre les organisations au paiement de rançons. Les défenses traditionnelles—telles que les listes de contrôle d’accès NTFS/ReFS ou les partages SMB Windows—n’offrent aucune résistance face à un attaquant détenant des privilèges administratifs.

Une cyber-résilience authentique exige une architecture de sauvegarde immuable et Zero Trust. Ce guide présente la méthodologie technique complète pour déployer des Linux Hardened Repositories (LHR) tirant parti de l’immutabilité au niveau des blocs du système de fichiers XFS (chattr +i), mettre en œuvre des identifiants à usage unique sans empreinte d’accès persistante, configurer le principe des quatre yeux (Four-Eyes) et imposer le MFA sur la console VBR.

---

1. Isolation architecturale : l’impératif hors domaine

Le plan de contrôle et le plan de stockage du système de sauvegarde doivent impérativement être découplés du plan d’identité des charges de travail qu’ils protègent.

Architecture vulnérable vs architecture résiliente :

 ❌ CONCEPTION VULNÉRABLE (Point de défaillance unique) :
 ┌─────────────────────────────────────────────────────────────┐
 │ Domaine Active Directory de production (domaine.local)      │
 │ ├── Contrôleurs de domaine                                  │
 │ ├── Postes de travail et serveurs de fichiers               │
 │ └── [!] Serveur Veeam (Membre du domaine AD)                │
 │       └── Admin de domaine compromis = Suppression totale   │
 └─────────────────────────────────────────────────────────────┘

 ✔️ CONCEPTION ZERO TRUST RÉSILIENTE (Plan de sauvegarde isolé) :
 ┌───────────────────────────┐      ┌──────────────────────────┐
 │ AD d'entreprise de prod   │      │ Enclave de sauvegarde    │
 │ (Non approuvé par Veeam)  │      │ (Workgroup / Red Forest) │
 │ ├── Contrôleurs de domaine│      │ ├── Serveur VBR local    │
 │ ├── Machines de production│      │ └── Dépôts LHR dédiés    │
 └─────────────┬─────────────┘      └────────────┬─────────────┘
               │                                 │
               └──────── Filtrage strict ────────┘
                        Micro-segmentation
                      (Aucune relation de trust)

Principes directeurs d’architecture (alignés ANSSI et CISA)

1. Absence totale d’adhésion au domaine : le serveur VBR, les proxys et les dépôts doivent fonctionner comme des systèmes autonomes en Workgroup ou être rattachés à une forêt d’administration étanche (“Red Forest”).
2. Identifiants administratifs locaux dédiés : chaque machine de sauvegarde doit posséder un mot de passe administrateur local unique, généré aléatoirement et conservé dans un coffre-fort hors-ligne. Les mots de passe ne doivent en aucun cas correspondre à ceux de la production.
3. Isolation des hyperviseurs : les interfaces d’administration des hyperviseurs (VMware vCenter / ESXi, Hyper-V) ne doivent autoriser les connexions qu’en provenance exclusive de l’adresse IP et des ports du serveur de sauvegarde.

---

2. Le cadre de résilience moderne 3-2-1-1-0

La règle classique 3-2-1 ne suffit plus à contrer les tactiques de double extorsion. La défense d’entreprise impose la mise en œuvre de la règle d’or 3-2-1-1-0 :

Élément de la règle	Exigence technique de mise en œuvre	Menace neutralisée
3 Copies	1 copie primaire de production + 2 copies de sauvegarde sur des infrastructures distinctes.	Perte accidentelle, panne matérielle.
2 Médias distincts	Stockage sur disque (XFS) + Stockage objet (S3/Blob) ou bande hors-ligne (LTO).	Défaillance matérielle, corruption de firmware.
1 Copie hors-site	Réplication vers un second centre de données ou une région cloud distante.	Sinistre physique sur le site principal.
1 Copie immuable	Linux hardened repository (LHR) avec immutabilité XFS ou verrouillage S3 Object Lock.	Destruction par ransomware, sabotage interne.
0 Erreur de restauration	Vérification automatisée via Veeam SureBackup (démarrage en bac à sable et validation).	Sauvegardes corrompues, altération silencieuse.

---

3. Ingénierie du Linux hardened repository (LHR)

Le Linux Hardened Repository constitue la pièce maîtresse du dispositif immuable de Veeam. Il transforme un serveur physique Linux standard en équipement WORM (Write Once, Read Many).

Fonctionnement de l'immutabilité du Linux Hardened Repository (LHR) :

 ┌─────────────────────────────────────────────────────────────┐
 │ Serveur de sauvegarde Veeam (Control Plane Windows)         │
 └──────────────────────────────┬──────────────────────────────┘
                                │
                                │ Flux TCP Data Mover
                                │ (Ports TCP 2500-3300)
                                ▼
 ┌─────────────────────────────────────────────────────────────┐
 │ Serveur physique Linux (Ubuntu 22.04 / 24.04 LTS, RHEL 9)   │
 │                                                             │
 │ ┌─────────────────────────────────────────────────────────┐ │
 │ │ Démon Veeam Data Mover (veeamtransport)                 │ │
 │ │ - Exécuté avec un compte de service non-root            │ │
 │ │ - Interagit avec le système de fichiers via XFS Reflink │ │
 │ └────────────────────────────┬────────────────────────────┘ │
 │                              │ Positionne l'attribut        │
 │                              │ chattr +i pour la durée      │
 │                              ▼ de rétention configurée      │
 │ ┌─────────────────────────────────────────────────────────┐ │
 │ │ Point de montage du système de fichiers XFS             │ │
 │ │ (/mnt/veeam_immutable)                                  │ │
 │ │ - Formaté avec : mkfs.xfs -b size=4096 -m reflink=1     │ │
 │ │ - Le noyau de l'OS applique le verrouillage immuable    │ │
 │ │ - Même root ne peut supprimer ou modifier les fichiers  │ │
 │ └─────────────────────────────────────────────────────────┘ │
 └─────────────────────────────────────────────────────────────┘

Serveur physique vs serveur virtuel

Le LHR doit être installé sur un serveur physique bare-metal. Déployer un LHR sur une machine virtuelle hébergée sur VMware ESXi ou Hyper-V expose l’infrastructure à une suppression directe du disque virtuel (.vmdk) ou des instantanés par tout attaquant ayant compromis l’hyperviseur, contournant ainsi l’immutabilité de l’OS invité.

Guide de déploiement pas-à-pas du LHR

1. Installation minimale de l’OS : Installer une distribution minimale d’Ubuntu Server 22.04/24.04 LTS ou RHEL 9. Ne pas installer d’environnement graphique, de serveur web ou de paquets superflus.
2. Formatage du volume XFS avec reflink : Formater le volume de stockage dédié avec le support du clonage de blocs rapides (reflink) :

   # Formatage du périphérique de stockage dédié (ex. /dev/sdb)
   sudo mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sdb
   
   # Création du point de montage et configuration de 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. Création du compte de service non privilégié : Créer un utilisateur de service dédié pour exécuter les composants de transport Veeam :

   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. Attribution temporaire des droits sudo (déploiement initial) : Le serveur Veeam nécessite des privilèges root temporaires pour déployer le démon de transport :

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

5. Déploiement depuis la console VBR avec identifiants à usage unique : Dans la console Veeam :
   • Naviguer vers Backup Infrastructure > Managed Servers > Add Server > Linux.
   • Cocher l’option Single-use credentials for hardened repository.
   • Saisir les identifiants de veeamsvc. Veeam établit la connexion SSH, installe veeamtransport, enregistre le service et détruit immédiatement le mot de passe de sa mémoire.
6. Verrouillage post-déploiement (critique) : Dès la fin de l’installation, révoquer les droits sudo et désactiver SSH :

   # Suppression immédiate des droits sudo temporaires
   sudo rm -f /etc/sudoers.d/veeamsvc
   
   # Arrêt et désactivation du service SSH pour bloquer tout accès réseau interactif
   sudo systemctl stop ssh
   sudo systemctl disable ssh
   
   # Vérification de la présence des attributs immuables sur les fichiers
   lsattr -l /mnt/veeam_immutable/

---

4. Contrôles de sécurité natifs VBR (V12 / V13)

Veeam Backup & Replication intègre plusieurs mécanismes défensifs intégrés qui doivent être activés en production.

Principe des quatre yeux (four-eyes authorization)

En temps normal, un compte administrateur accédant à la console VBR peut supprimer des sauvegardes ou réduire la durée de rétention. L’option Four-Eyes Authorization rend obligatoire une double validation :

Flux d'approbation du principe des quatre yeux :

 [Admin 1 : Compte compromis] ── Tentative d'effacement de sauvegarde ──► [Plan de contrôle VBR]
                                                                                  │
                                                                           Action bloquée
                                                                           en attente
                                                                                  │
 [Déclenchement d'alerte email] ──────────────────────────────────────────────────┘
            │
            ▼
 [Admin 2 : Approbateur sécurité] ── Obligation de valider sous 24h
                                     (Identifiants distincts + MFA)
                                     Si refus : action annulée, incident déclenché

• Opérations protégées : suppression de sauvegardes sur disque, suppression de dépôts, réduction des périodes de rétention, désactivation de l’immutabilité et suppression de copies secondaires.
• Mise en œuvre : activable via Main Menu > Users and Roles > Security Settings > Enable Four-Eyes Authorization. Attribuer le rôle d’approbateur à un responsable de la sécurité distinct.

Authentification multifacteur obligatoire (MFA) sur la console

Introduite pour bloquer la réutilisation de mots de passe dérobés :

• Impose un jeton TOTP (Time-Based One-Time Password) via des applications d’authentification standard (Google Authenticator, Microsoft Authenticator) ou clés matérielles FIDO2/YubiKey.
• Sécurise les accès interactifs à la console, les sessions du module PowerShell et les jetons d’API REST.

Veeam security & compliance analyzer

Outil d’audit automatique intégré évaluant en continu la conformité de l’infrastructure face aux recommandations de durcissement :

• Vérifie la non-adhésion du serveur au domaine Active Directory.
• Contrôle l’état d’activation de l’immutabilité sur l’ensemble des dépôts.
• Alerte en cas de non-chiffrement des tâches de sauvegarde.
• Identifie les ports ouverts non nécessaires et les versions logicielles obsolètes.

---

5. Pare-feu d’hôte et micro-segmentation réseau

Les scripts ci-dessous illustrent comment restreindre drastiquement les flux vers le serveur VBR et le dépôt Linux immuable.

Pare-feu Windows (PowerShell VBR)

# PowerShell : verrouillage du pare-feu Windows du serveur VBR
$AuthorizedAdminSubnet = "10.100.50.0/24"
$BackupProxySubnet     = "10.100.60.0/24"

# 1. Activation du pare-feu sur tous les profils
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

# 2. Blocage de tout le trafic entrant par défaut
Set-NetFirewallProfile -Profile Domain,Public,Private -DefaultInboundAction Block

# 3. Restriction du port de gestion Veeam (9401)
New-NetFirewallRule -DisplayName "Veeam-Control-9401-Restricted" `
    -Direction Inbound -Protocol TCP -LocalPort 9401 `
    -RemoteAddress $AuthorizedAdminSubnet -Action Allow

# 4. Restriction des services MountService (6172) et ThreatHunter (6175)
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. Autorisation des flux Data Mover (2500-3300) entre proxys et dépôts
New-NetFirewallRule -DisplayName "Veeam-DataMover-2500-3300" `
    -Direction Inbound -Protocol TCP -LocalPort 2500-3300 `
    -RemoteAddress $BackupProxySubnet -Action Allow

Pare-feu Linux UFW (hôte LHR)

#!/usr/bin/env bash
# Script de verrouillage UFW pour Linux Hardened Repository (LHR)
set -euo pipefail

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

# Réinitialisation des règles UFW
sudo ufw --force reset
sudo ufw default deny incoming
sudo ufw default deny outgoing

# Autoriser la résolution DNS et la synchronisation NTP sortantes
sudo ufw allow out 53/udp
sudo ufw allow out 123/udp

# Autoriser le démon de transport Veeam depuis le serveur VBR
sudo ufw allow from "$VBR_SERVER_IP" to any port 6162 proto tcp comment 'Démon Veeam Transport'

# Autoriser les flux de données depuis les proxys (ports 2500 à 3300)
sudo ufw allow from "$PROXY_SUBNET" to any port 2500:3300 proto tcp comment 'Flux Veeam Data Mover'

# Bloquer définitivement tout accès SSH
sudo ufw deny 22/tcp comment 'Blocage SSH'

# Activation du pare-feu
sudo ufw --force enable
sudo ufw status verbose

---

6. Liste de contrôle pour l’audit de durcissement

Ce tableau permet aux équipes de sécurité de vérifier régulièrement la conformité du serveur Veeam :

Contrôle de sécurité	Méthode de vérification	Résultat attendu	Impact sur la sécurité
Serveur de sauvegarde hors domaine	Exécuter (Get-WmiObject Win32_ComputerSystem).PartOfDomain	Doit retourner $false	Empêche la propagation d’une compromission AD
Immutabilité du dépôt Linux LHR	Exécuter lsattr /chemin/vers/sauvegarde.vbk	L’indicateur i doit être présent	Bloque le chiffrement ou l’effacement hostile
SSH désactivé sur le LHR	Exécuter systemctl is-active ssh	Doit retourner inactive	Empêche l’accès shell distant par le réseau
Identifiants à usage unique	Vérifier l’absence d’identifiants mémorisés en base VBR	Aucun secret SSH stocké	Interdit le pivot depuis un serveur VBR compromis
Principe des quatre yeux activé	Consulter le menu Users and Roles de VBR	Actif avec approbateur	Bloque l’effacement unilatéral des dépôts
MFA imposé sur la console	Tenter une connexion sans jeton TOTP	Rejet de la session	Neutralise le rejeu de mots de passe volés
Chiffrement KMS des sauvegardes	Examiner la configuration des travaux	AES-256 activé	Protège les données en cas d’exfiltration externe
Validation automatisée SureBackup	Examiner les rapports des jobs SureBackup	Succès quotidien	Garantit l’absence d’erreurs de restauration

---

7. Navigation dans la série et renseignements connexes

Partie 1 : architecture et acteurs menaçants Composants VBR, flux Data Mover et campagnes d'attaquants (Akira, FIN7, Qilin).

Partie 2 : matrice des vulnérabilités et exploitation Décryptage technique de CVE-2024-40711, CVE-2023-27532, CVE-2024-29849 et CVE-2026-44963.

Partie 4 : investigation forensique DFIR Analyse des logs dans ProgramData, requêtes SQL forensiques et triage des dumps DPAPI.

Masterclass Sécurité Active Directory Investigation sur le Kerberoasting, AS-REP roasting et l'extraction de secrets DCSync.