Un serveur de sauvegarde n’est pas un composant comme les autres : c’est le dernier filet de sécurité de l’entreprise. Pour un opérateur de ransomware, neutraliser Veeam Backup & Replication avant de déclencher le chiffrement, c’est s’assurer que la victime ne pourra pas restaurer et devra payer. Supprimer les points de restauration, désactiver les jobs, voler les identifiants stockés, puis chiffrer la production : la séquence est devenue un standard dans les attaques modernes. Ce tutoriel propose un audit défensif d’un serveur Veeam sous Windows, orienté admins et RSSI. Il ne remplace pas un audit complet, mais couvre les contrôles à fort impact : version et correctifs, exposition réseau, comptes privilégiés, dépôts immuables, supervision, test de restauration et plan de réponse.
Travaillez avec un compte administrateur autorisé, en concertation avec l’équipe d’exploitation, et documentez chaque résultat dans un ticket ou un dossier de maintenance. L’audit n’a de valeur que s’il est tracé, daté et rejoué périodiquement. Un contrôle mensuel court vaut mieux qu’un grand chantier annuel qu’on repousse indéfiniment.
Pourquoi le serveur de sauvegarde est une cible prioritaire
Les groupes de rançongiciels ont compris que la sauvegarde est le pivot de toute négociation. Tant que la victime peut restaurer, elle garde un levier ; quand les sauvegardes disparaissent, le rapport de force bascule. C’est pourquoi la phase de reconnaissance d’une attaque cible désormais explicitement les consoles d’administration, les serveurs Veeam et les dépôts. Un serveur de sauvegarde concentre par nature des privilèges élevés : il doit lire l’ensemble des machines virtuelles, accéder aux hyperviseurs, aux bases de données et aux partages. Compromettre ce seul hôte offre donc une vue panoramique sur l’infrastructure et un chemin direct vers la destruction des points de restauration.
Dans une PME, ce risque est aggravé par la concentration des fonctions : un même serveur héberge parfois la console, le dépôt principal et des comptes de service réutilisés partout. Si cet hôte tombe, la stratégie de reprise tombe avec lui. L’enjeu de l’audit est donc d’identifier ces points uniques de défaillance et de vérifier qu’une compromission du serveur Veeam ne se traduit pas mécaniquement par la perte de toutes les sauvegardes. C’est cette résilience, et non le simple fait d’avoir « une sauvegarde », qui permet de refuser l’extorsion.
1. Identifier précisément la version et l’état des correctifs
Tout commence par une donnée factuelle : la version exacte de Veeam Backup & Replication et de ses composants. Une mention vague comme « Veeam 12 » ne permet pas de décider si un avis de sécurité s’applique à votre installation. Sur Windows, interrogez le registre des programmes installés, puis recoupez avec la console et les notes de publication de l’éditeur. L’objectif est d’obtenir un numéro de build précis, comparable aux avis publiés sur le portail de sécurité de Veeam et aux entrées éventuelles du catalogue des vulnérabilités activement exploitées de la CISA.
# Version exacte des composants Veeam installes
Get-ItemProperty HKLM:SoftwareMicrosoftWindowsCurrentVersionUninstall* |
Where-Object { $_.DisplayName -like '*Veeam Backup*' } |
Select-Object DisplayName, DisplayVersion, Publisher, InstallDate |
Sort-Object DisplayName
# Etat des mises a jour Windows recentes de l'hote
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 15La vulnérabilité d’un serveur de sauvegarde ne s’arrête pas au moteur central. Consoles distantes, proxies de sauvegarde, dépôts, agents et plug-ins applicatifs doivent suivre le même rythme de mise à jour. Tenez un inventaire de tous ces composants avec leur version, et abonnez-vous aux notifications de sécurité de l’éditeur. Quand un correctif critique sort, traitez-le comme un incident planifié : fenêtre de maintenance, sauvegarde de la configuration avant intervention, vérification après coup. Patcher tard, c’est laisser une fenêtre d’exploitation ouverte sur le composant le plus sensible du système d’information.
2. Réduire et vérifier l’exposition réseau
Un serveur Veeam ne doit jamais être joignable depuis Internet. Sa place est sur un réseau d’administration restreint, isolé de la bureautique et de la production, accessible uniquement par les machines et les comptes qui en ont strictement besoin. Cette segmentation limite la propagation latérale : même si un poste utilisateur est compromis, il ne doit pas pouvoir atteindre directement la console ou les dépôts. Commencez par cartographier la surface réelle, depuis l’hôte lui-même, en listant les ports en écoute et les processus associés.
# Ports en ecoute et processus proprietaires
Get-NetTCPConnection -State Listen |
Sort-Object LocalPort |
Select-Object LocalAddress, LocalPort, OwningProcess |
Format-Table -AutoSize
Get-Process -Id (Get-NetTCPConnection -State Listen).OwningProcess -ErrorAction SilentlyContinue |
Select-Object Id, ProcessName, Path |
Sort-Object ProcessName -Unique
# Confirmation depuis une machine d'administration (scan interne, non agressif)
nmap -sT -Pn -p 22,80,135,139,443,445,3389,9392,9398,9401,2500-3300 veeam.example.localConfirmez ensuite, depuis une machine d’administration autorisée, que seuls les ports attendus répondent. Restez sur un scan interne et mesuré : l’objectif est de comprendre la surface d’attaque, pas de stresser un serveur de production. Portez une attention particulière au RDP (3389) : un accès Bureau à distance ouvert largement est l’une des premières portes d’entrée des rançongiciels. Privilégiez un accès via bastion, restreint par pare-feu et protégé par authentification multifacteur. Tout port ouvert sans justification documentée est une dette de sécurité à fermer ou à filtrer.
3. Contrôler les comptes, privilèges et MFA
Les sauvegardes exigent des identifiants puissants : c’est inévitable, mais c’est aussi le maillon que les attaquants cherchent en priorité. Le risque explose quand les comptes sont partagés, jamais renouvelés, ou membres de groupes trop larges comme les administrateurs du domaine. Listez les administrateurs locaux de l’hôte Veeam, puis vérifiez que les comptes de service ne servent pas à ouvrir des sessions interactives — un comportement souvent révélateur d’un usage détourné ou d’une compromission.
# Administrateurs locaux de l'hote Veeam
Get-LocalGroupMember Administrators |
Select-Object Name, ObjectClass, PrincipalSource
# Dernieres ouvertures de session (journal Securite, 7 jours)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-7)} |
Select-Object TimeCreated,
@{n='Account';e={$_.Properties[5].Value}},
@{n='LogonType';e={$_.Properties[8].Value}} |
Sort-Object TimeCreated -Descending |
Select-Object -First 50Appliquez le principe du moindre privilège et segmentez les comptes par rôle : un compte dédié pour VMware ou Hyper-V, un pour les applications, un pour les dépôts, un pour l’administration humaine. Un compte de sauvegarde ne doit jamais devenir un passe-partout permanent. Activez l’authentification multifacteur partout où elle est disponible, à commencer par la console Veeam et les accès distants, et interdisez l’usage quotidien des comptes à hauts privilèges. Pensez aussi à la rotation régulière des secrets et à l’audit des identifiants stockés dans Veeam, qui sont une cible directe pour le vol de credentials.
4. Protéger les dépôts : immutabilité, air-gap et règle 3-2-1-1-0
La question structurante de tout audit de sauvegarde tient en une phrase : si le serveur Veeam est compromis, l’attaquant peut-il effacer toutes les sauvegardes ? Si la réponse est oui, votre reprise dépend d’un composant unique, et c’est trop fragile. La parade est la règle 3-2-1-1-0 : trois copies des données, sur deux supports différents, dont une copie hors site, une copie immuable ou hors ligne (air-gap), et zéro erreur vérifiée lors des tests de restauration. Cette discipline garantit qu’une attaque sur l’hôte de production ou sur la console ne suffit pas à détruire l’ensemble des points de restauration.
Concrètement, privilégiez des dépôts Linux durcis avec immutabilité, du stockage objet avec verrouillage (object lock / WORM), et des copies externalisées sur un système qui ne partage pas les mêmes identifiants. Vérifiez surtout que les dépôts ne sont pas exposés en partage SMB ouvert à l’ensemble du domaine : un repository accessible en écriture par de nombreux comptes devient une cible évidente. La séparation des accès est ici aussi importante que le chiffrement.
# Partages Windows locaux et autorisations associees
Get-SmbShare |
Select-Object Name, Path, Description, FolderEnumerationMode
Get-SmbShareAccess -Name '*' |
Sort-Object Name, AccountName
# Checklist immutabilite / air-gap a documenter :
# [ ] depot immuable actif (Linux hardened ou object lock)
# [ ] periode d'immutabilite >= retention critique
# [ ] une copie hors site
# [ ] une copie hors ligne / air-gap
# [ ] identifiants des depots distincts de la production5. Superviser les signaux faibles et alerter
Une attaque sur la sauvegarde laisse presque toujours des traces avant le chiffrement général : jobs soudainement désactivés, suppressions inhabituelles de points de restauration, échecs répétés, connexions depuis une machine inconnue, création de comptes, modification des politiques de rétention. Ces signaux faibles sont votre meilleure fenêtre de détection précoce. Configurez des alertes lorsqu’un job critique échoue plusieurs fois de suite, lorsque la configuration change, ou lorsqu’une suppression massive est demandée. Idéalement, remontez ces événements vers un SIEM ou un puits de logs centralisé, hors de portée du serveur Veeam lui-même.
Maintenez également une exportation régulière de la configuration Veeam vers un emplacement protégé et séparé. En cas de reconstruction d’urgence, cette sauvegarde de configuration fait gagner un temps précieux : jobs, planifications, dépôts et points de restauration peuvent être réimportés rapidement. Traitez-la comme un secret, car elle peut contenir des informations sensibles sur l’architecture et des références d’identifiants. La supervision n’a de sens que si quelqu’un lit les alertes : définissez clairement qui est notifié et selon quel délai de réaction.
6. Tester une restauration réelle, régulièrement
La seule sauvegarde digne de confiance est celle que vous avez déjà restaurée. Une sauvegarde jamais testée est une hypothèse, pas une garantie. Planifiez donc des tests périodiques, distincts de la production, et mesurez systématiquement le résultat. Le « 0 » de la règle 3-2-1-1-0 — zéro erreur — ne se vérifie que par la restauration effective. Ce test révèle aussi les dépendances oubliées : DNS, certificats, comptes de service, réseaux isolés, volumes manquants ou documentation obsolète, autant d’écueils qui transforment une reprise théorique en échec le jour J.
# Test de restauration minimal (cadence mensuelle conseillee)
# 1. choisir un job critique
# 2. restaurer un fichier, une VM de test ou une base non critique
# 3. verifier l'integrite applicative (donnees + services)
# 4. mesurer la duree, consigner erreurs et correctifs
# 5. confirmer que l'equipe de permanence sait ou trouver la procedure
# 6. archiver le compte rendu (date, perimetre, RTO/RPO observes)Ce rituel transforme une promesse en preuve et alimente vos objectifs de reprise (RTO/RPO) avec des chiffres réels plutôt que des estimations. Variez les scénarios au fil des mois : restauration granulaire de fichiers, restauration complète de machine virtuelle, bascule sur un site distant. Plus vous éprouvez la procédure dans des conditions proches de l’incident, plus vous réduisez l’incertitude quand survient une vraie crise.
7. Séparer sauvegarde et production, plan de réponse
La séparation entre l’environnement de sauvegarde et la production est une exigence défensive majeure. Le serveur Veeam, ses dépôts et ses comptes de service ne doivent pas partager le même périmètre d’authentification que les serveurs de production : idéalement, ils relèvent d’un domaine ou d’un tier d’administration distinct, de sorte qu’une compromission Active Directory côté production n’ouvre pas automatiquement les portes de la sauvegarde. Cette segmentation par niveaux (modèle de tiering administratif) limite drastiquement la capacité de l’attaquant à atteindre, en un seul mouvement, à la fois les données et leur copie de secours.
Préparez enfin un plan de réponse spécifique à la compromission des sauvegardes. Il doit répondre à des questions concrètes : qui isole le serveur Veeam et avec quelle autorité, comment vérifier l’intégrité des dépôts immuables, dans quel ordre restaurer, comment communiquer en interne et, le cas échéant, vers les autorités. Les guides de la CISA et de l’ANSSI fournissent des trames éprouvées pour bâtir ce plan. Un plan écrit, testé lors d’un exercice, et accessible hors ligne (car les documents en ligne peuvent eux aussi être chiffrés) fait la différence entre une crise maîtrisée et une paralysie totale.
Conclusion : faire de la sauvegarde un actif résilient
Durcir Veeam ne se résume pas à appliquer le dernier correctif. C’est une discipline complète : réduire l’exposition réseau, limiter les privilèges et imposer le MFA, rendre les dépôts immuables et hors ligne, superviser les changements, tester les restaurations et séparer sauvegarde et production. Les rançongiciels ciblent les sauvegardes précisément parce qu’elles conditionnent votre capacité à refuser l’extorsion. Version, ports, comptes, dépôts, alertes, restauration, segmentation : ces sept axes, audités régulièrement et documentés, font monter le niveau de résilience bien plus sûrement qu’un grand projet ponctuel vite oublié.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.