Apps – VBR Partie 2 : Pratique

Nous considérons que le serveur Windows a été durci au préalable et que nous possédons un serveur à jour.

Nous avons également télécharger en amont les sources (iso) de Veeam Backup et Réplication.

Installation

Nous partons donc du principe que notre serveur Windows est déjà configuré et non joint à un domaine.

Les prérequis en termes de ressources doivent être les suivantes:

OS : WIN10, WIN11, WS 2012 à WS 2022
CPU : 4 cores (minimum)
RAM : 4 Go + 500 Mo pour chaque job tournant en parallèle
Disk : 10Go pour l’installation + 10 Go / 100 VMs pour le Guest Catalogue + 10 Go pour les logs
Network : 1 Gbps minimum

Bon, dans mon cas, je vais être un peu short en CPU, mais on va tenter quand même.

Il est important et c’est ce que je recommande, de dissocier le Guest Catalog et le Cache du disque système et de dédier une troisième partition pour les Logs.

/!\ Attention : Nous installerons VEEAM en tant qu’Administrateur local

Avant de lancer le setup, nous allons configurer quelques options sur notre SE qui sont de mon point de vu important.

Afin de ne pas saturer notre système de lettre lors du montage des disques des VMs que nous allons sauvegarder nous allons désactiver l’automount.

Pour se faire, ouvrir une invite de commande en tant qu’administrateur et dans l’utilitaire diskpart réaliser la commande automount disable, puis quitter l’utilitaire.

Par mesure de sécurité et afin de ne pas utiliser le compte .\Administrateur pour réaliser les sauvegardes, nous allons rétablir la visibilité des partages administratifs pour les utilisateurs de notre serveur.

Ouvrez l’éditeur de registre et ajoutez la valeur LocalAccountTokenFilterPolicy en définissant la valeur à 1.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Monter les deux disques de 10 Go chacun.

Sur le premier disque VEEAM, créez les répertoires :

VBRCatalog : Qui contiendra le Guest Catalogue. Ce dernier a pour but d’assurer l’indexation, des différents SE invités des VMs que nous allons protéger.
NFSDatastore : Qui va contenir le cache en écriture lors des opérations de restauration ou lors des action de vérification lors de la sauvegarde des VMs.

Sur le second disque Logs, créez le répertoire :

VBRLogs : Qui contiendra l’ensemble des logs de notre serveur VEEAM (jobs, installation, journaux d’upgrade, etc).

Nous sommes pas mal. Je pense que nous pouvons nous lancer sous les feux des projecteurs

Sélectionnez la première option

Charger une licence si vous en possédez une, dans le cas contraire vous partirez comme moi avec la version CE¹.

C’est parti pour un petit check des prérequis nécessaires au bon fonctionnement de VEEAM. Si des dépendances sont manquantes, de mémoire VEEAM vous invitera à les installer ou les installera pour vous. Il se peut que vous soyez inviter à reboot votre serveur.

Dans le cas d’un reboot, une fois authentifié, le wizard se lancera de nouveau. Inutile de spamer le launcher.

VEEAM vous le dira dans une warningbox qu’une instance est déjà en cours 🙂

Cette étape va vous demandez une grande concentration.

Deux choix s’offre à vous, réaliser une installation par défaut ou custom.

Dans notre cas, c’est une CUSTOM, il faudra cliquer en bas à gauche près du « Gear Icon » (un expression et reste d’une formation NUTANIX… 🙂 )

Laissez le compte LOCAL SYSTEL par défaut (recommended).

Depuis la version 12 de VEEAM, il est possible d’utiliser comme SGBD PostgreSQL en lieu et place de MSSQL Express.

Le pourquoi du comment de cette proposition est simple. Il y a malheureusement trop de contrainte à utiliser MSSQL dans ça version EXPRESS, surtout pour des bases de données dépassant les 10Go. Afin de s’affranchir des contraintes, PostgreSQL a été implémenté.

Je vous encourage fortement de passer sur PostgreSQL en lieu et place de MSSQL.

Ici, nous retrouvons la partie dédiée à nos répertoires créés plus tôt pour le cache (NFSDatastores) et le guest file catalog (VBRCatalog).

Nous ne touchons pas au chemin relatif à l’installation.

Laissons les ports par défauts pour les différents services.

C’est le moment d’aller chercher un café ou un cognac (XO de préférence).

Ta dam !

L’installation est terminée. On est pas bien là ? Paisible, à la fraîche, décontractés du guest… Et on backupera quand on aura envie de backuper.

Nous pouvons lancer le raccourcie sur le bureau et nous atteler à la configuration de notre VEEAM.

Configuration

La première chose que j’aime à faire sur un VEEAM qui sent le neuf, c’est de configurer les options ainsi que la sauvegarde de la configuration de ce dernier.

Dans le menu Options, deux onglets nous intéressent fortement, celui intitulé Security et E-mails Settings. Pour le reste, je laisse par défaut.

Pourquoi ? Premièrement parce que je n’ai pas de licence pour réaliser d’I/O Control, deuxièmement parce que les paramètres par défaut me vont et que je n’ai pas suffisamment de ressource pour l’instant pour transférer les logs vers un serveur SNMP ou SYSLOG.

Je n’ai pas de certificat à ajouter, j’ai toujours préférer laisser celui de VEEAM (autosigné) quand à la sécurité.

Afin de garantir la sécurité de notre serveur, il est vivement recommandé dans le cas de la sauvegarde de système GNU Linux ou de présente de Linux sur le réseau de ne pas faire confiance aux équipements qui viendraient contacter le serveur de sauvegarde. Ces derniers seront mis automatiquement en « DMZ » et devront être approuvé manuellement par l’administrateur.

Nous pouvons choisir d’activer ou non la validation FIPS². Dans notre cas, nous n’avons pas de données critiques pour activer cette fonctionnalités et mes ressources sont restreintes dans mon LAB. Néanmoins, il est intéressant de savoir, qu’il est possible d’activer le contrôle en temps réel de la validation cryptographique des transactions et donc certifier que la sauvegarde est conforme.

Afin de ne pas saturer le disque système, je redirige sur une partition dédiée les logs VEEAM B&R et j’active la compression de ces derniers.

Le second onglet le plus important. Sans lui pas de notification et donc pas de visibilité sur la santé de nos sauvegardes ainsi que de la santé de notre serveur de sauvegarde.

La configuration est facilement compréhensible. Sachez toutefois que l’adresse mentionné ici recevra l’intégralité des rapports envoyés.

La sauvegarde de la configuration est un enjeu majeur car en cas de perte de notre serveur VEEAM il suffira de recharger la configuration pour retrouver notre VEEAM de nouveau opérationnel.

Par défaut, la configuration est sauvegardée sur le serveur lui-même. Mauvais idée si nous perdons le serveur. C’est pour ça cette trace de pneu couleur prune ? Toutefois notre serveur n’ayant pas encore de repo de monté, il faut mieux avoir une sauvegarde sur le serveur lui-même que rien. Il faudra toutefois penser à changer ce dernier une fois le repo ajouté.

Personnellement, je garde autant de configuration qu’il y a de jour dans le mois. J’aime également recevoir un petit rapport à 10h00 tous les jours m’indiquant que la configuration a été sauvegardé.

Point important, je chiffre ma sauvegarde. La configuration est sensible est donc en cas de fuite, je ne vous fait pas de dessin… Le mot de passe doit être différent des autres clés de chiffrements et doit être stocké dans un lieu sure. VEEAM recommande de le changer régulièrement. Personnellement l’aide d’un générateur de mot de passe est apprécié.

Sécurisation

Bien, nous avons notre serveur VEEAM fonctionnel et configuré. Toutefois, l’éditeur nous fournit un ensemble de bonne pratique de sécurité. Nous avons donc la possibilité de passer outre ou de nous attarder sur la sécurité de l’application.

Pour rappel et pour l’avoir dit précédemment (ou quitte à être gâteux avant l’âge), la sauvegarde représente un enjeu majeur et stratégique des organisations. Les chaines de sauvegarde et le respect des bonnes pratiques relatives à l’infrastructure de backup constituent le dernier bastion, rempart en cas de sinistre naturel ou criminel.

Networking

Les recommandations sont explicites, il nous suffit de n’autoriser que les flux sortant pour les protocoles et ports vers les destinations précises.

Ainsi, VEEAM recommande de n’autoriser que les ports tcp:80 et tcp:443 à destination :

Serveur de mise à jour : dev.veeam.com
Serveur de licence : authlok.veeam.com & vbr.butler.veeam.com

Il en est de même avec les serveurs de mise à jour Windows.

Là de nouveau se pose une question de sécurité. Dois je configurer le firewall du SE ou en amont sur mon Firewall ?

Si nous partons du postulat que nous avons une architecture 3 tiers avec un subnet dédié pour notre environnement de sauvegarde, les règles doivent être configurées sur le UTM³. Avec cette configuration, il n’est donc pas nécessaire de configurer le firewall windows de notre serveur de backup.

Dans le cas contraire ou n’avons pas de pare-feu, cela devient tout de suite plus complexe. Il sera nécessaire d’ajouter les policies directement sur notre SE. Sauf que, car sinon ça serait trop facile, le firewall Windows ne prend pas en charge la résolution des enregistrement DNS de type CNAME, mais uniquement des subnets, adresses IP…

Comment autorisons nous alors les *.windowsupdate.com et autres windowsupdate.com ?

A savoir que l’avantage d’un enregistrement de type CNAME est de répondre au changement des enregistrements de type A…

Oh p’tain t’es en train de nous dire qu’il faut se palucher toutes les ips et subnets à la main ? T’es un grand malade !

Malheureusement pour les enregistrements wildcard, pas d’autres solutions pour les enregistrement CNAME, nous pouvons toujours passer par nslookup ou Resolve-DNSName.

Ce qui nous donnerai

Toutefois, cela ne répond pas à la problématique d’un potentiel changement d’adresse IP lié à un enregistrement de type A ou CNAME. C’est pourquoi j’ai fait un nouvelle fois appel à ma feignantise, j’ai fait un script qui vient mettre à jour automatiquement les règles de firewall.

Mais pour le coup, je ne vais pas être totalement transparent et je vais garder certaines modifications pour moi 🙂 Peut-être que je partagerai ces points selon mon humeur. J’entends déjà les « Merci co****d », je répondrai, « Merci MONSIEUR co****d 🙂 »

Si dans le point précédent nous étions vigilant sur les flux sortants pour éviter une potentiel évasion de datas. Il convient d’être vigilant sur une potentiel intrusion.

Dans le cas du management de VEEAM par les produits VSPC ou VCC, il sera nécessaire d’autoriser les connexions entrantes et sortante sur les ports tcp:6179-6180 par défaut. Sans quoi, il sera difficile de manager le serveur VEEAM.

La question de l’autorisation du service TermService se pose. Il doit être désactivé mais est nécessaire pour la VCC. Il est donc nécessaire de penser en bon père de famille et de mesurer le rapport bénéfices/risques.

Il convient d’activer le chiffrement réseau sur notre réseau privé. Oui mais pourquoi faire donc dirait l’autre ?

Par défaut, le chiffrement réseau est actif pour les réseaux publiques. Toutefois, pour se prémunir d’une potentiel écoute sur notre bulle de sauvegarde (et autre subnet), activer le chiffrement des flux réseaux va permettre de chiffrer les connexions lors du transfert de données vers le service VEEAM Data Mover.

Ainsi lors de l’exécution d’un job de sauvegarde, les données seront chiffrés avant d’être envoyé transférées.

Là où ça devient intéressant c’est que nous pouvons activer ou non du Throttling :p Il est également possible de définir directement un subnet.

Attention néanmoins car cela peut engendrer une latence considérable sur le réseau. VEEAM recommande de désactiver l’option dans le cas de nombreux jobs ou d’équipements qui pourraient être vite « surchargés ».

Ce point est logique, mais pas utilisable pour tout le monde… Ah bon ? Oui, cette fonctionnalité n’est pas disponible dans la Community Edition. Toutefois il suffira de suivre le guide pour implémenter cette bonne pratique.

Il en sera de même pour la fonctionnalité 4-yeux (non je ne vise pas les personnes ayant des problèmes de vue… ou de JANNUS). La fonctionnalités Four Eyes Authorization (disponible uniquement en Entreprise Plus) permet de demander un double validation lors d’action de suppression. Ce qui en cas d’acte malveillant ou de compromission du server de backup de protéger les datas. A condition d’avoir au minima deux comptes de contrôles avec le profil Administrateur.

Par défaut, VEEAM utilise un certificat autosigné pour garantir le chiffrement des connections entre les composants de l’infrastructures de sauvegarde.

Il est possible d’installer un certificat tiers si besoin. Etant pour un usage interne sans publication, il n’est donc pas « gênant » d’utiliser le certificat autosigné.

Le classique des classiques, et je ne parle pas d’un burger signature de chez X ou Y ! Rare sont ceux qui ferment leurs sessions de travail, alors imaginer les sessions de la console VEEAM ?

Personnellement, lorsque j’interviens pour un dysfonctionnement de sauvegarde et que je me retrouve en direct sur un ordo, j’ai comme des envies de meurtres. Promis, je lance une résurrection après, puis je récidive 🙂

Nous pouvons donc et je recommande d’activer la déconnexion en cas d’inactivité pour assurer la sécurité sur la console d’administration.

Ici, deux cas de figure.

Le premier, vous n’avez pas fait d’installation personnalisée. Dans ce cas, vous allez directement Aux Six Roses vous en jeter un petit derrière la cravate. Dans le cas contraire, il va falloir revoir les ACLs⁴ des répertoires créés précédemment pour le VBRCatalog et le NfsDatastore.

Dans la logique, nous avons par défaut :

Si nous voulons éviter un potentiel escalade de privilège et d’exécutions de code malveillant, VEEAM recommande d’appliquer les droits suivants :

Compte	ACL	Scope
Administrators	Full control	This folder, subfolders and files
SYSTEM	Full control	This folder, subfolders and files
CREATOR OWNER	Full control	Subfolders and files only
Users	Read & Execute	This folder, subfolders and files

Lien

Ce qui nous donnerai par exemple :

Il convient de ne faire confiance à personne. C’est pourquoi dans le cas des machines LINUX (postes ou serveurs), il est important de ne pas faire confiance à ces équipements d’approuver manuellement ces derniers.

Ainsi il sera plus facile d’identifier un loup au milieu du troupeau.

Databases

Attention, ouverture d’une porte ouverte à grand coup de deltoide dans 3, 2, 1… BAM ! Naturellement tout le monde doit avoir accès à la base de données MSSQL Express ou PostreSQL avec ALL GRANT PERMISSIONS !

#ironie #seconddegres #commedisentlesjeunes

Bien sûr que non. L’accès au serveur de sauvegarde ou qui héberge le ou les bases de données doit être réglementé, sur le principe 3Tiers, avec compte nominatif. Les éléments contenu dans l’application autant que dans le SGBD sont sensibles et hautement critique.

Les questions que nous devons nous poser sont, qui doit avoir accès aux serveurs ? Avec quel niveau de permission ? Sur quelle période ?

Comme abordé précédemment, il est d’une importance cruciale de réaliser une sauvegarde de la configuration de notre serveur. Toutefois les informations contenus dans cette dernière sont critiques et doivent être chiffrées.

Toutes sans exceptions.

Backup Repository

Pour ce point, je pense avoir été suffisamment claire précédemment. Je vous invite à vous référer à l’article du site ou plus haut.

En somme, il suffit de suivre les bonnes pratiques de l’application de la sauvegarde.

On parle de sécurité et des bonnes pratiques logiques et logicielles, mais QUID de la sécurité physique des équipements ?

Bien souvent minimiser, c’est le drame quand on découvre que trois disques ont été arrachés du serveur de stockage, qu’un disque externe ou bande a été volé ou qu’un NAS a été victime du dernier spectacle d’HOUDINI…

Je passe volontairement sur les serveurs car ces derniers doivent être dans un local dont l’accès et strictement réglementé.

La sécurité des composants est relativement large. Elle commence par la redondance énergétique pour parer à toutes coupures d’alimentation éventuelles (onduleur), d’une température et hydrométrie contrôlé (climatisation). Les équipements doivent être inaccessible (baie fermée à clef). Les disques doivent être si possible en position verrouillé dans les slots (serveur ou NAS). Les serveurs ou NAS attachés à la baie ou mobilier.

Les médias amovibles ou bandes doivent être stockés en lieu sure. Les données doivent être chiffrées dans tous les cas pour ce prémunir de vol ou de perte éventuelle.

« Jean-Mi, t’as encore laissé une VHS à la machine à café. Ah non c’est ma bande… »

L’accès au média de stockage (SAN, NAS, Serveur, CLOUD…) doivent être sous contrôle et revu périodiquement. Même si le contenu des données sauvegardées sont chiffrées (cf point plus haut).

Il convient d’autoriser uniquement l’authentification Homme et machines. Le cloisonnement et une part essentielle de la sécurité. Elle s’applique de la plus basse couche du modèle OSI (physique) jusqu’à son plus haut niveau (application).

Ainsi, l’accès aux repositories de sauvegardes doivent être restreint à l’essentiel depuis le serveur de sauvegarde comme sur le reste du SI, jusque sur les partages.

Comme pour la sauvegarde de la configuration, il convient de chiffrer l’ensemble des chaines de sauvegarde. L’objectif étant de se prémunir d’un vol physique ou logique des données.

De nouveau, les mots de passes servant au chiffrement doivent être différent et changer au minimum une fois par an.

J’ai par exemple, pris l’habitude de dédié une passphrase complexe par type de jobs. Ainsi, ma sauvegarde et chiffré avec un mot de passe différent de ma copie (externalisation), un mot de passe différent de mon hardened et de ma configuration.

Le chiffrement des flux réseaux SMB doit être actif et l’authentification doit être requis et ce pour éviter l’utilisation du protocole d’authentification NTLMv2⁵. Bien que celui ci soit déprécié depuis 2010 par Microsoft, il est rare que celui-ci soit désactivé sur les SI.

L’immuabilité est maintenant devenu un standard pour se prémunir des attaques de type rançonlogiciel et de la suppression des chaines de sauvegarde. C’est pourquoi il devient nécessaire de configurer les repositories soient avec les technologies :

Hardened (immuabilité native)
Stockage S3 (stockage objet, mais peut on vraiment parler de vrai immuabilité ?)

Bref, comme toutes choses évoluent avec le temps, l’immuabilité va devenir le standard de demain.

Néanmoins cela ne protège pas d’une suppression physiques des LUNs⁶ et autres volumes ou « d’arrachage physique » des disques sur les médias.

La sauvegarde offline ou hors-ligne si nous souhaitons appliquer la loi AllGood consiste à se prémunir de la corruption logique ou physique des supports contenant les sauvegardes du SI de production et de garder une sauvegarde inaccessible puisque déconnectée.

Plusieurs possibilités dans ce cas, soit le bon vieux jeu de rotation sur média externe (HDD) incluant le chiffrement des chaines de sauvegarde. Ce qui est je pense le meilleur compromis pour les PMEs et MEs. Où dans le cas d’hébergement une sauvegarde sur bande (Tape) avec serveur rotatif.

Je note un bémol sur le Tape storage. L’un des points bloquant restent la durée de vie des robots et la capacité de stockage des bandes. Dans le cas d’un Cloud Provider (comprendre fournisseur d’hébergement privé), le stockage peut vite évoluer à la hausse et donc cela peut devenir contraignant concernant le capacité de stockage et son évolutivité. Néanmoins, le Tape storage reste l’un des moyens les plus fiables et sécurisés pour une sauvegarde hors-ligne (point de vu personnel, à vous de me triquiter).

Pour se point, je renvoie au guide général de la sécurité (ici). Normalement et dans la logique, une grande partie est traitée dans le cadre du durcissement d’une SE Windows et dans les points de recommandations VEEAM qui sont abordés dans la partie suivante.

En règle générale, je dirai qu’il ne faut pas prendre pour argent comptant les acquis et de se remettre en question en permanence pour garantir un niveau de sécurité le plus élevé possible sans pour autant être trop restrictif. Il faut tout de même pouvoir bosser de temps en temps. 🙂

Security & Compliance Analyser

Comme j’ai du déjà le dire précédemment, depuis la version 12, VEEAM à mis à disposition un petit outil dans la console qui permet de vérifier si les bonnes pratiques et recommandations sont appliqués à l’environnement ainsi qu’à l’application. C’est une nouvelle fois super en terme de MCO⁷. Naturellement, un guide existe et une nouvelle fois, je ne compte pas paraphraser toute la section qui aborde le sujet. Mais il convient de s’y attarder un petit peu. 🙂 Pour le reste => Lien.

L’outil aborde deux sections de sécurité. La première concerne l’environnement de sauvegarde et la seconde la configuration du produit. Pour plus de simplicité nous distinguerons les deux sections dans un module « accordéon« .

Une fois la console VEEAM démarré et que nous sommes authentifiés, dans le bandeau, sélectionnez l’application Security & Compliance Analyser

Ce qui nous donne une jolie petite windows avec le résultat de l’analyse de sécurité de notre système. Si le système n’a pas été durci vous devriez avoir l’affichage suivant.

C’est dans la version 12.2 que le point N°12 et N°13 font leurs apparitions. Toujours plus de sécurité, encore plus !

Bon, on s’y met ? 😀

Backup Infrastructure Security

Pour des raisons de sécurité il convient de ne pas activer le service de Connexion du bureau à distance. De cette façon, nous nous assurons que sur notre infrastructure, PERSONNE ne pourra accéder au serveur de sauvegarde en dehors de l’accès physique ou local.

Toutefois (car il y a un toutefois), le service doit ou peux rester actif dans le cas où le serveur de sauvegarde est connecté à une VCC⁸. Dans ce cas de figure, il est possible à l’équipe de gestion des sauvegardes ou SysAdmin de se connecter au serveur via RDP⁹ de manière sécurisé depuis le serveur VCC vers le serveur de sauvegarde (port tcp:[6179:6180]).

Nous ferons abstraction du cas de la VCC et désactivons le service.

> Set-Service -Name TermService -StartupType Disabled

Le nom est équivoque. Ce service permet lorsqu’il est actif, de permettre aux utilisateurs de modifier la base de registre à distance sur les machines (ordinateurs ou serveurs).

Le risque ainsi que l’impact sont assez conséquent pour ignorer ce service et ne pas l’activer.

> Set-Service -Name RemoteRegistry -StartupType Disabled

Le service WinRM¹⁰ est également aussi sensible que les deux services précédent. Puis qu’il permet d’administrer à distance les machines sur lequel il est actif. Donc un accès au serveur de sauvegarde…

On coupe !

> Set-Service -Name WinRM -StartupType Disabled

Ca parait évident, mais sachez que beaucoup pour ne pas dire TROP de SysAdmin désactive ce dernier sur l’ensemble de tous les profils. Oui car il est plus facile de désactiver le parefeu que de faire une régle InBound ou OutBound…

Personnellement, j’ai constaté à maintes et maintes reprises ce cas de figure sur des serveurs applicatifs. D’ailleurs, si nous ouvrons une parenthèse, je pose la question qui est responsable de la vulnérabilité d’un serveur applicatif ?

L’éditeur qui a installé et qui fait assure le MCO du logiciel ?
Le prestataire ou l’équipe informatique ?

L’éditeur vous dira, que ce n’est pas lui qui gère le réseau et le système et le prestataire ou l’équipe informatique vous diront que c’est applicatif et qu’ils ne touchent pas au système pour ne pas créer de dysfonctionnements quant aux dépendances systèmes et les applications en place. A méditer… Je clôture cette parenthèse après avoir semer le doute. (Pour ceux qui commence à flipper, je répondrai « De rien »).

> Set-NetFirewallProfile -Name Public -Enabled $true
> Set-NetFirewallProfile -Name Private -Enabled $true
> Set-NetFirewallProfile -Name Domain -Enabled $true

C’est une fonctionnalité super pratique sur nos postes utilisateurs car il permet de répondre à notre fénéantise. Cette fonctionnalité permet de garder en cache les mots de passe.

Pratique ne veux pas dire sécurisé comme le disait un collègue.

Donc le risque de retrouver un mot de passe en clair ou juste masqué sur un serveur de sauvegarde revient à aller aux p***s sans capote(s) et pleurer d’avoir attrapé une chaude p***e des familles. Alors, qu’est ce qu’on fait ? On désactive naturellement.

The value of the HKLM\System\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential registry key is set to 0.
Veeam Backup & Replication 12
User Guide for VMware vSphere

Le WPAD¹¹… Il permet à toutes machines de localiser de manière automatique le fichier de configuration d’un serveur mandataire. Ce fichier de configuration est critique car en cas d’altération de celui-ci par un individu malveillant, ce dernier se placerai entre les ressources et le serveur mandataire (MitM¹²).

L’utilité d’une telle fonctionnalité sur notre serveur de sauvegarde n’est pas utile. Ca dégage.

> Set-Service -Name WinHttpAutoProxySvc -StartupType Disabled

The value of the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\DisableWpad registry key is set to 1.
Veeam Backup & Replication 12
User Guide for VMware vSphere

Ce point est assez logique. Il convient désactiver les protocoles de chiffrements obsolètes.

Toutefois, suivant les SEs (récent) certains de ces protocoles ne sont pas présents. Logique, pourquoi installer des protocoles qui sont obsolètes ? Sauf si nous les avons déployés manuellement pour un usage spécifique. De mon point de vu, il est difficilement justifiable sur un serveur de sauvegarde jugé hautement critique.

Ce point est donc difficilement atteignable sans « tricher ».

Par exemple sur un serveur WS 2016, les protocoles TLS 1.0, TLS 1.1, SSL 3.0 n’ont pas d’entrée dans la base de registre tout comme les clés de registre Server et Client.

De ce fait, le status Unable to detect apparaitra en Warning. C’est dommage.

Pour obtenir le statut en Success, il conviendrait donc de créer les clés de registre ainsi que les valeurs attendu.

WSH¹³ est un ancien système d’exécution de code. Il est normalement plus ou peu utilisé car remplacé par Powershell ou le framework .NET. Néanmoins, laissé ce dernier actif permettrai d’exécuter du code et d’altérer le système en accédant à des composants COM/ActiveX. Il n’est donc pas nécessaire de garde ce dernier actif.

The value of the HKLM\SOFTWARE\Microsoft\Windows Script Host\Settings\Enabled registry key is set to 0.
Veeam Backup & Replication 12
User Guide for VMware vSphere

Le protocole de partage de ressource (SMB¹⁴) dans sa version 1.0 est faillible car il n’inclus les mécanismes de sécurité que nous connaissons maintenant et donc il est facilement sujet au MitM.

La seule explication plausible pour voir ce dernier actif resterait l’usage d’une vieille application ne supportant pas le protocole dans sa version 3. Comme toujours il n’a rien à faire sur un serveur de sauvegarde et combien même ça serait le cas pour un très très vieux équipements jouant le rôle de repository, il y aurait un trou dans la raquette. Les calculs sont pas bon Kévin !

> Set-SmbServerConfiguration -EnableSMB1Protocol $Status

LLMNR¹⁵ pour les intimes, protocoles de résolution de noms. Ce dernier offre la possibilité d’effectuer localement la résolution de noms. Dans le cas d’un échec de résolution DNS, ce dernier peut être amené à être utilisé. Soit, il est facilement exposé au MitM et aux poisoning.

Il est préférable de le désactiver.

The HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\EnableMultiCast registry key exists. The value of the key is set to 0.
Veeam Backup & Replication 12
User Guide for VMware vSphere

Si nous reprenons le point numéro 9, il convient d’activer et de forcer l’usage du protocole SMBv3 si et seulement si nous sommes amenés à utiliser ce dernier. Néanmoins, il vaut mieux prévenir que guérir. Surtout si nous sommes plusieurs à intervenir sur l’infrastructure de sauvegarde. Et un oublie et vite arrivé malheureusement…

La configuration de celui-ci se fait par l’activation du chiffrement des Data, l’activation de la signature de sécurité et nécessitant une signature de sécurité.

> Set-SmbServerConfiguration -RequireSecuritySignature $true
> Set-SmbServerConfiguration -EncryptData $true
> Set-SmbServerConfiguration -EnableSecuritySignature $true

Si nous nous basons sur la page technet, Microsoft recommande de protéger le service LSASS¹⁶ afin d’offrir « une protection renforcée pour le processus de l’autorité de sécurité locale (LSA) afin d’empêcher toute injection de code qui pourrait compromettre les informations d’identification« .

VEEAM se basant sur cette recommandation (présente depuis WIN 8.1 et WINDOWs Server 2012) d’activer le Lock UEFI ainsi que le secure BOOT. C’est pas déconnant et il fallait y penser. <3

The value of the HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL registry key is set to 1 or 2.
Veeam Backup & Replication 12
User Guide for VMware vSphere

Afin de réduire encore davantage l’exposition de notre serveur de sauvegarde, il est recommandé de désactiver NetBios sur l’ensemble des interfaces. L’objectif est d’éviter une possible fuite de données depuis un répertoire partagé.

Par défaut et pour l’avoir vérifier, ce dernier est à 0 (soit actif). Comme nous l’avons fait pour LLMNR au point N°10, il convient de désactiver ce dernier est définissant la valeur à 2.

The value of HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID}\NetbiosOptions registry keys is set to 2.
Veeam Backup & Replication 12
User Guide for VMware vSphere

Normalement, si nous avons bien suivit toutes les étapes, nous devrions avoir le résultat suivant.

Sauf que voila, ça fait tâche de voir un Warning quant aux points de contrôles des protocoles SSL/TLS obsolètes. Il faudrait dans ce cas, que le contrôle ne se porte pas uniquement sur les valeurs de clés de registres mais également sur les clés de registres elles mêmes.

Ainsi, si nous trichons en créant les clés de registres manquantes et ajoutons les valeurs attendus, nous obtenons un 100%.

Est ce pourtant bien de la triche ? Je répondrai que non car aucun point n’a été supprimé ou masqué et que l’ensemble des recommandations de sécurité propres à l’infrastructure de sauvegarde a été implémenté.

De nature feignante et devant dans le cadre de mon activité professionnel déployer fréquemment des environnements VEEAM, j’ai décidé de scripter cette partie. Cette dernière sera disponible plus bas.

Product Configuration

Ce point de controle vient vérifier si oui ou non la recommandation du 1 média hors-ligne ou immuable est implémenté. Pour rappel rien n’est imposé mais recommandé. A défaut de configurer et d’administrer un repo hardened (ce qui peut représenter un investissement) selon la taille du SI, une simple sauvegarde sur disque externe avec rotation suffit.

Je ne rentrerai pas dans le détail de la configuration ici. Un billet sera dédié à l’implémentation d’un stockage hardened (immuable).

Ouai parce que même par gourmandise, je comprends parfaitement que vous lecteurs commencez à avoir des remontés quant à la longueur de cet article…

Une fonctionnalité intéressante mais non par réellement importante à mon sens. Je m’explique. La fonctionnalité de protection contre la perte des mots de passe stockés sur notre serveur de sauvegarde peuvent être perdu en cas de dysfonctionnement de ce même serveur et donc d’accès aux données.

Nos chaines de sauvegardes étant chiffrées, difficile de déchiffrer ces dernières si le mot de passe est perdu… C’est pourquoi pour des raisons de sécurité et de faciliter de gestion il est recommandé d’implémenter un VEEAM Backup Manager.

Il permet de manager plusieurs serveur VEEAM
Il stocke une copie des mots de passes et donc protège d’une perte ou suppression des éléments secrets

Il convient toutefois de ne pas mutualisé le serveur manager avec le serveur de sauvegarde (cela n’a pas de sens et nous tombons vite dans le cas du serpent qui se mord la queue) et de déployer le rôle et les fonctionnalités sur un serveur dédié.

Dans mon cas et je n’ai qu’un seul serveur de sauvegarde (et surtout pas de licence), je n’ai pas d’intérêt à déployer ce rôle. Les éléments secret sont comme vous vous en doutez sont stockés dans un bloc-note nommé MOTDEPASSE_SAUVEGARDE.txt sur mon bureau utilisateur. :p

Mais c’est qu’il pense être comique le garçon ! (Oui mais Comic san MS)

Les éléments de confiance sont stockées dans un gestionnaire de mots de passe (type LastPass, KeyPass, Keeper, Dashlane etc…). Ainsi je ne mets pas tous mes oeufs dans le même panier.

Néanmoins, l’outil de contrôle lui ne sait pas tout ça. Et comme je n’ai pas les ressources nécessaire pour implémenter un VEEAM Backup Manager, j’accepte le point de non compliance, mais répond toutefois à ce dernier.

Le serveur de sauvegarde ainsi que l’ensemble des éléments propres à la sauvegarde ne doit pas être au domaine. Cette recommandation vise à garantir un niveau de sécurité plus important dans le cas où une compromission ou intrusion sur la bulle d’administration, management venait à avoir lieu.

Quitte à être sénile encore une fois, la sauvegarde doit être le dernier bastion et doit être imprenable.

Les notifications doivent être configurées. Pourquoi ? Je reçois déjà suffisamment de mail tous les jours.

Je dirais plusieurs raisons :

S’assurer que la sauvegarde de la configuration se fait bien sur la période indiquée et que cette dernière est valide
S’assurer que l’ensemble des tâches de sauvegardes (et de vérification) se déroulent sur la période indiquée et en succès
S’assurer que l’infrastructure de sauvegarde est saine

Les notifications permettent de garder et d’être garant du bon déroulement de la sécurité de son SI.

Merci Captain Obivious

Toutes les éléments protégés doivent répondre au minima à la règle des 3-2-1. Je passe mon tour sur le détail de ces points et vous laisse remonter plus dans dans ce billet sur la description de chaque point.

Un point qui me chagrine beaucoup… La Reverse Incremental (nous l’appellerons RI¹⁷) est déprécié au détriment de la Forward Incremental (nous l’appellerons FI¹⁸) ou de la Forward Forever Incremental (nous l’appellerons FFI¹⁹).

Il est déjà je pense important de comprendre les deux types de fonctionnement.

La RI garde en dernier point de sauvegarde (le plus récent) une full dans laquelle le dernier point d’incrément est ajouté. Le point d’incrément de la veille est donc relayé comme maillon précédent de la chaine et les blocks modifiées sont ajoutés dans la full.

Ce type de sauvegarde permet une restauration plus rapide et un gain de place sur le repository de stockage au détriment d’I/O plus élevés. Ce qui rend donc le processus de sauvegarde plus lent. Donc une baisse des performances possible.

A l’inverse, la FFI garde en premier point de sauvegarde (le plus ancien) une full dans laquelle va venir se déverser l’incrément de la veille. Ainsi le dernier point de sauvegarde est donc toujours un incrément.

Cela permet donc de limiter les I/O sur le repository est donc un gain de performance. Toutefois si l’un des incréments est corrompu, l’ensemble de la chaine peut être corrompu. Le seul moyen de prévention serait donc le SureBackup ou d’implémenter la sauvegarde FI avec du GFS²⁰.

L’inconvénient, c’est que nous nous retrouvons avec 3 fulls. Soit une consommation supplémentaire des ressources de stockage.

Personnellement j’ai une préférence pour la RI. Car le risque de corruption de chaîne est plus faible au détriment des performances (I/O) liés au repository tout en garantissant une optimisation de l’espace de stockage.

Je dirai que pour cette recommandation, il faut s’adapter au contexte dans lequel nous travaillons au quotidien. VEEAM recommande, mais tout dépendra de notre infrastructure ainsi que de l’activité de notre organisation et des ressources à notre disposition.

Je prendrai le temps dans un prochain article de faire un benchmark pour un même job de comparer les performances de chaque type de sauvegarde.

Cette recommandation part du postulat que nous ne devons faire confiance à aucun device linux. Dans le cas contraire, les équipements linux peuvent contacter en SSH le serveur de sauvegarde. Si la fonctionnalité d’approbation est activée, il sera nécessaire d’approuver les équipements afin que ces derniers puissent se connecter une fois leurs empreintes ajoutées.

Comme pour le point numéro 3 concernant la protection des mots de passe et des éléments sensible, il revient de sauvegarder la configuration de notre serveur de sauvegarde sur un emplacement autre que le serveur de sauvegarde.

Point logique, mais souvent négligé. Ainsi en cas de perte de notre serveur de sauvegarde (maj windows foireuse par exemple), il nous suffira de créer un nouveau serveur de sauvegarde puis de recharger la configuration précédente.

Et hop, le tour est joué.

L’ensemble des flux entre le serveur de sauvegarde et les proxys VEEAM doivent être chiffrés et ce même si nous sommes dans le même subnet.

Pourquoi ? Nous ne sommes pas à l’abris d’écoute ou d’interception des données lors de l’exécution des jobs de protection.

Retour à notre sauvegarde hardened ou immuable. Le repository qui va contenir, stocker nos données sauvegardées doit être un média physique et non pas une VM ou autres environnements conteneurisés.

La raison me semble évidente, nous n’allons pas sauvegarder des données et rendre ces dernières immuables sur une ressource virtuelle qui pourraient être supprimée en un clic ou une ligne de commande.

Oui mais toi c’est bien ce que t’as fait non ? Oui car je n’ai pas de repo. Toutefois, si on m’offre le repo physique, je vous promet que je valide ce point de recommandation #coeuraveclesmains

Par défaut, le traffic sortant vers internet est chiffré (TLS). Néanmoins, il est recommandé de chiffrer également le trafic sur le LAN entre la bulle de sauvegarde est les autres bulles (subnets). Ainsi, les données sensibles sont chiffrées lors des échanges de data.

Cela peut entrainer une baisse des performances et générer un goulot d’étranglement au niveau du réseau en gérant de la latence.

Nous retrouvons une nouvelle fois l’un des classiques des environnements GNU Linux concernant l’authentification. Il est préférable de ne pas utiliser l’authentification de base mais l’authentification par clé.

Toujours pour les mêmes raisons d’une potentielle attaque de MiTM le risque est donc plus faible.

Il est possible de faire démarrer et tourner les services VEEAM avec un compte local différent. Toutefois, il relève de la bonne pratique de laisser le compte System Local gérer ces derniers. Restons Simple, Standard et Sécurisé et évitons les Shit In, Shit Out et Shit Stay ! La règle des 3S 🙂

Qui dit configuration dit informations sensibles. Pour se prémunir d’une fuite du fichier de configuration, il convient une nouvelle fois de chiffrer cette dernière.

Un de mes anciens collègues criait toujours haut et fort (et je pense qu’il perpétue toujours cette transmission orale) que les mots de passes c’est comme les slips/culottes (pour la parité de la gente féminine dans l’IT) ça se changent !

Dans certains cas d’infrastructures complexes, il est difficile de changer un mot de passe sans générer un minimum d’impact. C’est pourquoi, le changement de mot de passe doit être pris comme un changement important.

VEEAM recommande un changement au minimum annuel, personnellement j’aime le faire semestriellement quand il me reste une once de temps.

Pour plus de sécurité de notre sauvegarde immuable et donc s’assurer que l’ensemble des données stockées sur ce dernier soient limitées en terme d’exposition. Il convient de désactiver le daemon SSH est d’activer ce dernier que lors de tâche de MCO.

Après si le repo immuable est dans un subnet différent avec des règles de par feu interlan strict, la désactivation du service n’est pas obligatoire. Personnellement, je dirai qu’il vaut mieux prévenir que guérir.

Chacun voit midi à sa porte.

Sur ce point là, je ne vais pas vous mentir, je suis Candide. Le guide recommande d’activer l’option de rétention pour les stockages objets.

Je n’utilise pas encore de stockage objets, mais cela ne serait tardé dans un prochain billet 🙂

Toujours dans la logique et la même dynamique. Ce n’est pas parce que c’est dans le cloud que c’est super secure, bien au contraire. Donc une nouvelle fois, nous nous devons de chiffrer les données sauvegardées et protégés sur les repos dans le « nuage ».

Une évidence, mais pas pour tous les SysAdmins… Si j’étais patron, je demanderai à mon responsable IT de me montrer la preuve que tout mon parc est à jour. S’il y a des gérants qui parcours cet article, vous pourriez être étonné du résultat quant à votre SI.

Personnellement, je n’aime pas implémenter la dernière mise à jour d’une solution dans l’immédiat et préfère soit garder une version d’écart ou attendre 3 à 4 semaines avant d’appliquer la dernière version/patch.

Ainsi, si une mise à jour vient à générer un dysfonctionnement, je ne suis pas impacté et laisse donc « les autres essuyer les plâtres ».

C’est très courageux comme démarchent, bravo.

Oui, je reconnais c’est pas super, mais quitte à sortir une excuse… Etant en permanence en flux tendu sur divers projets, il est compliqué en cas de dysfonctionnement de la sauvegarde d’être sur plusieurs front à la fois. Et comme la sauvegarde c’est priorité 0 si ce n’est -1. Je préfère qu’il n’y est pas de bug. J’ai une mention particulière et remercie chaudement les SysAdmins qui implémentent les dernières MAJs et vont remonter les bugs à ma place.

Partie 1 : Théorie
<—

Apps – VBR

CE : Community Edition ↩︎
FIPS : Federal Information Processing Standard ↩︎
UTM : Unified threat management ↩︎
ACLs : Access Control List ↩︎
NTLMv2 : Network Lan Manager Version 2 ↩︎
LUNs : Logical Unit Number ↩︎
MCO : Maintient en Condition Opérationnelle ↩︎
VCC : VEEAM CLOUD CONNECT ↩︎
RDP : Remote Desktop Protocol ↩︎
WinRM : Windows Remote Management ↩︎
WPAD : Web Proxy Auto-Discovery ↩︎
MiTM : Man In The Middle ↩︎
WSH : Windows Script Host ↩︎
SMB : Server Message Block ↩︎
LLMNR : Link-Local Multicast Name Resolution ↩︎
LSASS : Local Security Authority Subsystem Service ↩︎
RI : Reverse Incremental ↩︎
FI : Forward Incremental ↩︎
FFI : Forward Forever Incremental ↩︎
GFS : GrandFather – Father – Son ↩︎