Apps – VEEAM Repo & Backup Hardened

Hardened, un bien vilain mot qui pourtant nous veux du bien. L’une des traductions littérales serait « endurcie ». Néanmoins nous interpréterons celui-ci sous le sens « d’immuable ».

Si hardened est un bien vilain mot, immuable ne vaut pas mieux. Et à chaque fois que j’ai évoqué ces termes à quelqu’un j’ai dû donner une définition.

Qui demeure inchangé, ne subit pas ou ne paraît pas subir de modification pendant un temps relativement long

Dictionnaire Larousse

Le titre de ce billet ainsi que les multiples appels du pied du précédent article technique sur VEEAM, ne laisse pas de doute quant au fil conducteur de ce feuillet technique.

Nous aborderons ici la sauvegarde dit immuable ou inaltérable pour répondre à l’un des bonnes pratiques et recommandations de la sauvegarde.

Prérequis

• SE : Ubuntu Server 20.04 LTS
• Apps : VEEAM B&R 12.1
• Autres :
  • Environnement GNU LINUX Durci
  • VEEAM B&R 12.1

Avant Propos

Le pourquoi du comment de la sauvegarde Immuable ou Hardened vient d’un constat. Avec l’évolution depuis 2015 des virus de nature cryptographique, les attaquants ne s’amusent plus à effacer toutes traces d’un SI (car c’est moins drôle de nous jours ce coup de HOCUS, POCUS) mais de chiffrer ce dernier de virer les sauvegardes et de tenir une situation de prise d’otage (sans permettre un syndrome de Stockholm) et de chantage à divulguer les données d’entreprise sur le Dark & Deep Web. Toutefois, les rançons demandées dans la grande majorité des cas sont indexées sur le CA des sociétés piègés ou de la nature critique des données extorquées…

Alors il y a bien des techniques, mécanismes pour assurer une sauvegarde hors ligne. L’une des plus vieilles à ma connaissance reste la sauvegarde sur bande (Tape). Même si cette dernière comme le langage COBOL était amené à mourir car dépassé par notre évolution technologique. Force est de constatée, que cette technologie reste l’un des mécanismes fiables pour assurer une sauvegarde hors ligne. Il y a bien la sauvegarde sur média externe (pour ne pas dire HDD) qui fonctionne très bien. Mais ce genre de solution, voyez vous, ça rentre parfaitement dans le cadre d’une PME ou d’un SI local (pour ne pas dire OnPremise) qui n’a pas un SI avec des fluctuations de stockage à la hausse. Pour résumer, comment assurer la sauvegarde déconnecté dans un datacenter ou une infrastructure qui peut être amené à grossir rapidement ?

Je vois (c’est mon point de vu. Si vous n’êtes pas d’accord, je suis prêt à échanger sur le sujet) les avantages et inconvénients suivants :

« Ouai mais qu’est ce que tu fais du Stockage Objet, des buckets toussa toussa ? C’est bien inaltérable non ? »

Oui et non. Je n’ai pas encore eu le loisir de jouer avec les stockages objets S3 ou d’autres technologies qui se base sur ce standard. Avant toutes choses, il est je pense important de se poser la question de la nature des données que nous souhaitons sauvegarder. Il y a des avantages et des inconvénients au type de sauvegarde en blocks et objets. Certains types de données sont plus favorables à l’un ou l’autre des technologies de sauvegarde. Bref, spoiler c’est un billet en réflexion et sur lequel je me dois de me motiver (à coup de grand coup de pied au c*l car je suis à l’ouest du néant en ce moment).

Bref, si nous rattrapons notre fil d’ariane, je vois dans une cloud privé un facilité à choisir la sauvegarde hardened sur un serveur dédié. Si le SI augmente et que nous devons ajouter des ressources des nœuds supplémentaires, j’ajoute un nouveau repo. Si mon SI diminue, je recycle mon serveur de repository pour un autre usage. Seul hic, cela demande de bonnes compétences en GNU/LINUX (mais cela est il vraiment un frein ? Les compétences ça s’acquiert non 🙂 ).

Pour ce billet, je vais tricher un peu. N’ayant pas de repo physique sur mon lab (et que mon lab tiens à mon poste perso), nous partirons d’un serveur virtuel qui « jouera » le rôle de notre repo physique.

Ce dernier sera sur un SE¹, Ubuntu Server 20.04 LTS² durci préalablement selon le guide de recommandation de l’ANSSI³. Un disque pour la sauvegarde est dédié, monté et formaté en XFS⁴.

Euh Question M’sieur GUIGUI ! Toi qui nous rabache du RHEL matin, midi et soir. Pourquoi d’un coup tu pars sur un Ubuntu ? Ca t’a pris comme un envie de ch**r de changer de distrib ?

A cette question, je répondrai tendrement qu’il s’agit simplement et tout bonnement des prérequis de l’éditeur VEEAM. Sinon, la question n’aurait pas eu lieu :rhel: (pour ceux qui ont connu le :noel: ).

Fin de l’avant propos, place à la lecture du menu avant de mettre un coup de fourchette.

Théorie

Attaquons donc ce menu qui nous fait tant de l’oeil. La première question que nous nous devons de poser est « Qu’est ce que l’immuabilité ? » et la seconde question, « Comment fonctionne t’elle ? »

Introduction à l’ i-mmuabilité

L’immuabilité au sens UNIX du texte existe depuis le 16 Janvier 1996. Cette commande est présente dans le paquet E2fsprogs de la release 1.02. (Si je me fourvoie, merci de me le dire car j’ai du mal à trouver l’histoire de cette dernière…).

Cette commande permet de définir des attributs complémentaires sur les systèmes de fichiers dont notamment l’immuabilité des fichiers.

Pour manipuler ces attributs, nous pouvons utiliser l’ensemble des commandes suivantes :

• chattr
• lsattr
• getattr
• setxattr

Observons ci dessous l’ensemble des commandes suivantes :

$ sudo chattr +i test.txt
$ sudo lsattr test.txt
$ sudo rm -Rf test.txt
$ sudo chattr -i test.txt
$ sudo lsattr test.txt
$ sudo rm -Rf test.txt

J’ai appliqué l’attribut d’immutabilité sur le fichier test.txt et surprise, même en élevant mes droits, je ne suis pas autorisé à supprimer le document. Cela ne sera possible qu’en retirant l’attribut. Nous tenons le début de notre mécanisme.

Ouvrez le GUILLEMARD « 

Je pense après une courte nuit de réflexion que je dédierai un article sur les attributs étendus car il y a énormément de matière sur le sujet. De plus, j’ai ouvert the PANDORAS BOX (toi aussi tu te souviens des jours anciens des LANs sur AoM ? Petit canaillou de cheater va) et je me dois de boire jusqu’à la lie ce module et l’éventail des fonctionnalités qu’il propose.

«  Fermez le GUILLEMARD

Mais alors comment cette fonctionnalité va t-elle être pilotée par notre serveur VEEAM ?

V-immutability-M

Là deux possibilités. Either you speak and read english and you can directly jump to the Veeam hardened guide. Ou alors on peut regarder ensemble ma compréhension du sujet.

Après tout, je n’ai eu que 5/20 au BAC en LV1 Anglais, ça promet d’être sympa 🙂 (Si si et j’ai même pas été au rattrapage ! Et il est content…)

Bref, nous verrons plus bas lors du déploiement que lorsque nous ajoutons notre Serveur Ubuntu en tant que Single Use Credential nous allons déployer les rôles :

• Transport : (veeamtransport) pour le service datamover (port tcp/6162)
• Installer : (veeamdeploymentsvc) pour déployer l’ensemble des composants et permettre de maintenir à jour les différents composants (ports tcp/2500

Toutefois, c’est lorsque nous déclarerons notre repository en tant que Hardened repository que cela va devenir intéressant. Car c’est à ce moment que nous allons définir les paramètres de gestion de l’immuabilité sur une période minimum de 7 jours (promis je reviendrai un jour sur la magie du nombre 7). Bref une fois configuré, voilà les services les plus importants.

• VEEAM Data Mover : Ces ce dernier qui va communiquer avec notre serveur VEEAM et récupérer les paramètres de temps quant aux datas qui doivent être inaltérables. Une fois les informations en sa possession, il réalise une passe décisive au service ci dessous VEEAM Immutability Service (veeamimmureposvc), comme la passe décisive de Djorkaeff à Thuram à la 47eme minutes du match France-Croatie en 1998 (Souviens toi du 12 Juillet 1998 !).
• VEEAM Immutability Service : Va aller mettre une patate à Jean-Pierre… Promis j’arrête, Bah Pourquoi ?… Tu vas la fermer ta grande gu***e !! Ce service va vérifier sur les chaque fichiers de backup toutes les 20 minutes les attributs immuables jusqu’à ce que le date de fin soit atteinte. Ce service est un sous service de VEEAM Data Mover.

A partir de la version 12.1.0.2131, le mécanisme change avec un control, détection sur un potentiel décalage de temps.

Lorsque le VEEAM Immutability Service démarre, un fichier timeLog va être créé sous /etc/veeam/immureposvc/. Ce fichier sera mis à jour toutes les 10 minutes.

Oui mais que se passerai t-il si la valeur du moveTime ou accelerationTime dépasse 24 heures ?

Par sécurité, les données relatifs aux opérations de rétentions seront bloqués. Un message d’avertissement remontera dans la session du job de sauvegarde. Ce qui est rassurant. Oui mais voilà, comment j’unlock la situation ? Ba en suivant le KB mon gars…

Architecture

Dans les recommandations et l’un des prérequis de l’implémentation d’un repository hardened est d’avoir un équipement dédié sans surcouche de virtualisation. Nous parlons donc de serveur et non pas d’hyperviseur.

En dehors des bonnes pratiques de configuration d’un serveur, je ne m’intéresserai qu’à la partie réseau. La configuration de la partie ILO/IDRAC/IPMI ne sera pas abordée. Pourquoi ? car je n’en ai pas envie et surtout je n’ai pas les moyens de le mettre en œuvre sur mon lab. Peut être un jour dans un autre article.

Au vu de la criticité de ce que nous souhaitons mettre en place, il nous faut dissocier la partie management de la partie sauvegarde.

Avec des équipements d’infrastructures adéquates et selon la volumétrie de datas à sauvegarder, l’agrégation d’interfaces est nécessaire. Au minima SFP+⁵, au maximum FC⁶. Assurer les performances réseaux sont un fait, toutefois si le stockage ne suit pas et génère un goulot d’étranglement (bolteneck), cela ne sert pas à grand chose.

Réseau

Bien entendu, si notre Firewall gère les liaisons supérieurs à 1 Gbits/s, il y a un intérêt de faire un VLAN dédié à l’immuabilité dissocié de la sauvegarde. Dans le cas contraire et assurer de bonne performance, il conviendra de rester dans le même subnet et de passer par commutation.

Encore une fois, si nous avons de la micro segmentation, cela facilitera grandement les choses sur un même subnet. Dans le cas contraire, il sera nécessaire de définir les règles côté repo selon les interfaces, sources et destinations avec les ports et protocoles autorisées à transiter.

Lors de la configuration du repository et donc sans restriction les flux réseaux sont les suivants :

Une fois les ressources push du serveur VEEAM vers le serveur hardened (tcp:22), le service VEEAM Installer se charge d’installer et de déployer les composants (tcp:6160). Une fois les dépendances installées, la sauvegarde se déroulera à travers le service VEEAM Data Mover (tcp:6162) ainsi que le service Mount Server (tcp:2500-3000).

Soit au final nous n’avons besoin que des flux suivants :

Ok, ça c’est pour VEEAM, mais niveau serveur physique, il n’y a pas des choses à faire ?

Bien vu l’aveugle. Il sera nécessaire d’autoriser les protocoles :

Users & Permissions

Dans l’idée, il convient d’utiliser un compte utilisateur pour la sauvegarde veeam. Ce dernier aura la charge de quelques services. Ce compte ne doit en aucun cas être membre du groupe SUDO. Il l’est uniquement lors du déploiement et lors du MCO logiciel. Ensuite les droits doivent lui être retirés.

Il en va de même que l’accès au répertoire qui va contenir les sauvegardes doivent avoir des droits restreints à notre seul et unique utilisateur VEEAM que ce soit en tant qu’utilisateur et groupe.

Les droits devant être défini sur 700.

Mouai, c’est enfoncer une porte ouverte non ? Ouai ba j’ai vu des SysAdmins faire des choses à la limite de faire voir des choses terribles à un petit garçon.

Il en va de soi, mais le sticky bit on oublie. Perso, je ne comprends qu’elle serait l’utilité du sticky bit. Mais bon, si VEEAM le précise, c’est bien que certains SysAdmins ont essayés.

Chaînes, maillons, et immutabilité

Pour assurer l’immuabilité des données de nos chaines, le mécanisme qui sera utilisé sera le même que pour la Foreward Incremental avec automatiquement une active full ou une syntetic full.

Pourquoi ? Une petit schéma s’impose.

Partons du principe que nous définissions le nombre de point d’immuabilité à 7 jours. Avec une synthétique full hebdomadaire tous les dimanches.

Sauf que voilà, il y a un problème. Le premier point immuable est une full et le dernier point avant la dernière full est une incrémental (Sunday to Saturday). L’immuabilité étant défini à 7 jours les points sont donc inaltérables tant que l’échéance du dernier point incrémental n’est pas atteint. Si la full est supprimée les incréments ne sont pas utile. Donc nous devons attendre de nouveau 7 jours pour supprimer la première chaine et la création d’une troisième full.

Nous avons pas 7 points inaltérables mais 13 points.

Une fois la full réalisée le 3 dimanches nous passons à 14 points. C’est à ce moment là, une fois la full terminée et rendu inaltérable que les 6 premières points de la chaine se verront retirés l’attribut d’immuabilité puis les maillons seront supprimés (Le principe, se base sur le Grand-Père, Père et fils).

Et puis on recommence.

Donc nous avons un minimum de 7 points de rétention et un maximum de 13 points.

Un point sur lequel je n’ai toutefois pas encore fait de test, reste le traitement de l’externalisation (backup copy). Le principe de GFS doit alors être configuré. J’essaierai plus tard.

Je pense que maintenant nous avons toutes les informations requises pour passer à la pratique. Il n’est pas impossible que certaines parties ne soient pas toutes à fait complètes. Il est difficile de tout couvrir et de ne rien oublier. Mais on peut toujours échanger pour toutes questions.

Pratique

Configuration Repository

$ sudo useradd usr.veeam
$ sudo passwd usr.veeam

$ sudo usermod -aG sudo usr.veeam

$ sudo gpasswd -d usr.veeam sudo

$ sudo gdisk /dev/sdX
   * n
   * 1
   * Paramètres par défaut
   * 8300
   * w
   * y

$ sudo mkfs.xfs /dev/sdX1

$ sudo mkdir /mnt/veeam
$ sudo mkdir /mnt/veeam/hardened_repository
$ sudo mount -o rw /dev/sdX1 /mnt/veeam/hardened_repository

$ sudo chmod 700 -R /mnt/veeam/hardened_repository
$ sudo chown usr.veeam:usr.veeam /mnt/veeam/hardened_repository

Si je n’ai rien omis, nous pouvons passer à la suite et toutes les étapes devraient bien se passer. Dans le cas contraire, je vous autorise à me donner une grande tape sur l’épaule, promis je vous dirai merci pour ne pas m’en reprendre une dizaine.

Intégration dans VEEAM

Ajout du serveur Linux

1 – Scream my Name !

Dans l’onglet Backup Infrastructure, sélectionnez ajouter un serveur. Puis ajouter un nouveau serveur Linux.

Comme ci-dessous vous avez deux possibilités. Soit vous ajoutez l’IP de votre repo (absence de serveur DNS dans mon cas et flemme d’aller faire une surcharge dans le fichier host juste pour le lab) ou d’ajouter le nom DNS. Ayant plusieurs repositories, j’aime bien mettre une petite description (surtout en l’absence de nom DNS).

2 – Linux Credential (une fois seulement)

Dans la partie SSH Connection, nous n’avons pas d’entrée dans le gestionnaire de mot de passe de notre VEEAM. Et nous ne voulons surtout pas que nos informations d’authentifications soient stockées (Sinon à quoi faire du hardened ?).

Cliquons donc sur Add et sélectionnons la dernière proposition « Single-use credentials« . Normalement vous devriez avoir l’écran ci-dessous.

Si vous avez fait les choses proprement, vous renseignez le login de votre compte utilisateur propre à VEEAM avec son petit mot de passe. Dans mon cas svc.veeam et password1234 ou azerty1234. Cochez la case d’élévation de privilège ainsi que la case « Use su if sudo fails » et là, renseigner le mot de passe du compte root.

Toujours si vous avez bien fait les choses, le compte svc.veeam est à ce moment un compte membre du groupe sudo. Donc un utilisateur à privilège le temps de l’installation. Si ce n’est pas le cas, ajoutez le :

$ sudo usermod -aG sudo svc.veeam

Pour le fun, essayer de mettre en compte utilisateur le compte root. Normalement, VEEAM devrait exprimer votre nom indien avec sa main « Dresser avec le Majeur« . 🙂

3 – Actions Review

Si vous êtes là c’est que le serveur VEEAM arrive à pu initier la connexion en SSH avec notre futur repository immuable.

Les composants transport et installer vont être déployés. Ces derniers ne sont pas déjà présent sur le serveur. Pour le moment pas un faux pas !

Passons à l’étape suivante.

4 – Jamais du premier coup 😉

Bon ba nous voilà comme un con sur un quai de gare un jour de grève à la SNCF… Ca ne fonctionne pas BORDEL ! (Pourquoi tu n’as pas censurer l’injure ? Parce que je suis frustré d’avoir durci une saloperie de système GNU/LINUX dans l’état de l’art et d’avoir des erreurs de ce type. Je suis pas une base de loisir MERDE !)

Monsieur, Calmez vous ! Oui, c’est bon. Pas de castagne. LINUX et VEEAM sont sympa car ils nous donnent gentiment le message d’insulte que l’un donne à l’autre. C’est alors qu’en bon copain nous allons arrondir les angles pour que VEEAM et notre repo LINUX puissent fleurter ensemble.

L’une des mesures de sécurité que j’applique sur mes systèmes GNU en terme de durcissement est d’interdire l’exécution sur la partition /var et /tmp. Donc un petit remove de l’argument noexec et un remount des partitions et c’est repartie comme en 40 ! (Il y a quelques choses d’autres à faire mais je le garde pour moi).

On relance un Previous, puis un Next pour relancer le déploiement. Là, à la surprise générale, l’installation se déroule sans accro.

Alors elle est pas belle la vie ?

5 – Congratulations

L’installation est terminée. Les composants ont bien été déployées nous avons ci-dessous le récapitulatif.

Toutefois, nous devons remettre en l’état les quelques points de sécurité que nous avons assouplis pour permettre l’arrimage de notre repository Hardened LINUX à notre serveur VEEAM.

• Retirer l’utilisateur svc.veeam du groupe sudo
• Rétablir les arguments noexec sur les partitions /var, /tmp
• Rétablir les paramètres que l’auteur a vraiment décider de ne pas divulger

Ajout du repository

1 – Quels types choisir ?

Choisissons le type de repository pour déclarer notre repo hardened, soit Direct Attached Storage.

2 – Linux Hardened Repository

Dans les choix, j’hésite vraiment sur l’option pour notre type de repo. Peut-être la réponse numéro 3, Linux (Hardened Repository) ?

3 – Scream my Name (Again)

On note le nom de notre repo. Tachons donc de rester logique et de choisir un nom dans le standard des repositories. Pour ma part REPO_HARDENED_01. Comme j’aurais pu avoir un REPO_SVG_01 ou REPO_EXT_01. Soignons pragmatique Père UBU par ma chandelle verte !

4 – Server Selection

Le serveur ayant été ajouté précédemment nous avons le listing de chacune des partitions présentent et montée.

Dans la liste (5ème positions) nous retrouvons bien notre partition sous /mnt/veeam/hardened_repository monté sur /dev/sdb1.

5 – Choix du repository (Path)

Sélectionnons la partition qui nous intéresse.

Activons ensuite les paramètres de clonage rapide sur les volumes XFS. Je défini la durée de l’immuabilité sur 14 jours (le minimum étant 7 jours). Je limite le nombre de tâche parallélisé à 4.

Dans les options avancées, j’ai pour habitude d’activer l’alignement des blocks pour améliorer les performances quant à la sauvegarde et à la restauration malgré une légère hausse du CPU.

J’active également le paramètre d’utiliser le paramètre per machine backup files car il améliore les performances de stockage pour les équipements qui bénéficient de flux important d’I/O. Ce qui tombe bien est notre cas.

Les deux autres options ne doivent pas être cochés, puisque nous n’avons pas de support rotatif et l’option de décompression n’est pas compatible avec la sauvegarde immuable.

6 – Where is the mount Server ?

De nouveau nous avons un petit récapitulatif des rôles à ajouter ou déjà présent sur notre repo.

• Transport
• vPower NFS
• Mount Server

Il est possible de cocher la case de recherche de chaine existante. Ce n’est pas notre cas.

7 – Applying

Nous appliquons la configuration de notre repo. Deux avertissements toutefois. Dû au durcissement de mon SE GNU/LINUX. Toutefois rien de bien méchant car on regarde l’avertissement lié au service de déploiement.

8 – Petit Résumé

Encore une fois, le petit récapitulatif nous informant que le repo a bien été créé.

Backup Job & Tests

Pour ce point, je ne vois pas de grand intérêt à décrire comme créer un jobs de backup. C’est pourquoi j’irai à l’essentiel, un en mot un seul, pour être succinct, sans détour et fioriture, bref j’irai droit au but…

Pourquoi cette entrée en matière dans cette partie ? Simplement car cela dépend de la source sur laquelle le serveur de sauvegarde se base.

• VMWare VCenter
• VMWare ESXi
• NUTANIX Prism Element
• NUTANIX Prism Central
• MICROSOFT HyperV
• VEEAM Backup Agent
• etc

La liste pourrait s’allonger comme un jour sans pain au vu du nombre de point d’entrée OnPremise et Cloud.

Dans mon cas et sur mon petit environnement de lab, ça sera sur un job de sauvegarde pour du VEEAM Backup Agent pour Windows (en Guest Processing) d’un serveur local.

Backup

Nous considérons qu’un compte d’administration est déjà présent pour la sauvegarde est durci dans les règles de l’art et que le serveur source se trouve dans la bonne configuration pour être sauvegardé.

1 – Storage

Dans la partie Storage de notre job (peut importe le type), il nous suffit de sélectionner notre repository hardened.

Le nombre de point de rétention doit être en adéquation avec la politique d’immuabilité en place comme décris dans la partie théorique. Dans mon cas 14 jours.

2 – Storage GFS

La sauvegarde hardened se base sur le principe GFS⁷. Effectivement et comme une nouvelle fois expliqué précédemment, il n’est pas possible et cela n’a pas de sens de faire de la RI⁸ mais bien FI⁹.

Je défini donc de réaliser une full backup synthétique de manière hebdomadaire, le 7 jour de la semaine, 7 jour où le Seigneur exténué (comme moi d’ailleurs) d’avoir travaillé si dure les 6 jours précédents de prendre un jour de repo. Et comme la sauvegarde est là pour nous prémunir de tout aléas

Les premiers seront les derniers, et les derniers seront les premiers

Marc 10:31

Nous pouvons faire confiance à Saint Marc. Amen.

Laissons notre job tourner et admirer les performances et actions en cours.

Tests

Une fois le job terminé avec succès. L’une de nos grandes questions que nous devons nous poser en tant que SysAdmin (et que n’importe quel client, chef d’entreprise doit se poser) est « Comment s’assurer que la chaine de sauvegarde est bien inaltérable, immuable ? »

Le plus simple, c’est de supprimer la chaine de sauvegarde ou l’une des ressources protégées. Normalement, dans la boite de dialogue se préparant à l’exécution de la suppression, vous devriez avoir un violent message d’avertissement vous informant que NON, VEEAM ne veut pas. Mais comme VEEAM n’est pas si en désaccord avec votre volonté de supprimer le backup, il vous donne toutefois la date d’échéance où il sera possible de supprimer la chaine si et seulement si le job est désactivé naturellement.

Si nous voulons allés plus loin, c’est du côté repo qu’il faudra contrôler que l’attribut d’immutabilité est bien positionné sur nos fichiers. Un petit coup de lsattr et le tour est joué.

Altérer l’inaltérable ?

Super cette sauvegarde immuable ! Avec ça, nous sommes paré à toutes éventualités contre la suppression et altération de nos chaines de sauvegarde.

Sauf que ce n’est pas tout à fait vrai. Désolé de vous mettre un stop. En haut de ce billet, j’ai insisté sur la topologie et l’architecture. Tout va reposer sur cette dernière pour ne pas altérer le contenu de votre repository hardened.

Avant de rentrer plus dans les explications, je rappel dans le contexte que le système GNU est durci. Le compte utilisateur dédié à la sauvegarde n’a pas de droit d’élévation, le daemon ssh est désactivé.

Allez, faut y aller, oui mais où ? Maintenant rentrons dans le vif du sujet.

En me connectant directement à mon repo en console ou en direct. Regardons nos différents maillons de chaines pour notre job. J’ai deux full. Pourquoi ? Parce que je suis un abruti qui lors du la configuration de mon job, j’ai oublié de chiffrer ma chaine. M’en rendant compte après coup, j’ai donc corrigé ce petit détail. Sauf que activer le chiffrement d’un job implique forcément de repartir sur un full. Merdouille non ?

Alors comment faire pour supprimer le premier maillon .vbk qui est indépendant de mon second .vbk ?

• Je suis patient et j’attends 28 jours
• Je supprime le point au niveau système et je clean ma configuration

Pour le coup je ne serai pas patient et je vais donc contourner l’immuabilité.

1. Je liste uniquement les maillons de la chaine qui sont des fulls (.vbk) afin d’identifier le point que je souhaite faire disparaitre
2. Etant en root, je retire l’attribut d’immuabilité sur le fichier
3. Je liste de nouveau les attributs des maillons de la chaine qui sont des fulls (.vbk) pour vérifier que c’est bon
4. Je supprime le fichier
5. Je liste de nouveau les attributs des maillons de la chaine qui sont des fulls (.vbk) pour vérifier que je n’ai plus qu’un fichier vbk

Nous nous déconnectons de notre console. Et regardons notre chaine côté VEEAM Ordo.

Là j’ai été un vite en besogne car j’ai déjà nettoyer la configuration. Mais notre point remontait comme inaccessible car nous l’avons supprimé (petite icone rouge et police en italique). Mais une fois nettoyé, nous avons 4 points en lieu et place de 5.

Donc il est possible d’altérer l’inaltérable sous certaines conditions.

Conclusion

La sauvegarde immuable ou hardened est vraiment une solution indispensable des organisations. Cette dernière ne doit pas être négligé. Malheureusement et c’est là un triste constat les organisations et entreprises pour des raisons de coût néglige cette protection supplémentaire.

« J’ai déjà une sauvegarde et une externalisation, je ne risque rien. Mon Service interne est parano ou Mon prestataire informatique me prend pour une vache à lait »

Ce sentiment de puissance, de confiance et d’invincibilité pourtant ne tiens qu’à un fil et c’est lorsque ça tourne mal qu’il nous reste plus qu’à pleurer en regardant comme Loth, sa femme pétrifié de sel (Genése 19:26). Attention, la facture est salée.

Toutefois, l’implémentation d’un tel système nécessite des aptitudes avancées pour les systèmes LINUX/GNU ce qui peut représenter un frein à la mise en place de ce dernier. Notamment sur la partie durcissement. A cela peut s’ajouter des budgets ainsi que des ressources limitées sur l’infrastructures ne permettant pas d’assurer cette fonctionnalité.

Il reste à moindre cout l’usage et l’implémentation d’une sauvegarde sur disque externe. Cependant je pense que cette solution est moins performante, plus espacée dans le temps, moins adapté à l’évolution du SI et soumis au risque humain (oublie, corruption, etc). Mais cela reste une solution.

Encore une fois la question de curseur se pose sur le rapport bénéfices risques. Qu’est ce que je suis prêt à accepter pour mon organisation ? Il suffit d’avoir frôlé la banque route ou d’avoir dans ces connaissances un patron qui a perdu son entreprise ou sauver de peu son business pour se sentir concerné.

Ouai mais tu nous as démontré que ce n’était pas inaltérable à 100%. Tu ne serais pas en train de nous refourguer une solution pour éviter le bug de l’an 2000 ?

Oui je conçois et l’ai démontré. Nulle solution n’est parfaite est sécurisé à 100%. Toutefois les opérations pour retirer l’immuabilité nécessite de passer plusieurs mécanismes de sécurités et le risque bien de présent est minime voir nul. Disons que si un individu malveillant s’attaque à la sauvegarde immuable, normalement l’équipe interne ou le service IT seront informés car c’est le point d’entrée le plus complexe à infiltrer. Et donc, cet individu aura pris le temps de mettre un joyeux bor**l sur l’ensemble de notre infra au préalable.

Nous pourrions également dire que 7 jours ou 14 jours d’immuabilité c’est peu. Et pourtant il faut voir cette sauvegarde comme l’as dans la manche qui nous sortira de l’échec et compromission de notre sauvegarde et externalisation. C’est une sauvegarde certes, mais la dernière carte à jouer. Sincèrement, vous SysAdmin/DSI persuadez votre DG, DAF ou PDG d’implémenter cette fonctionnalité.

Rare image d’échange entre un DAF avec un DSI/SysAdmin concernant le budget informatique

Vous DG, DAF ou PDG, écoutez votre SysAdmin/DSI et permettez lui de passer des nuits tranquilles loin des valium, tranxène, nembutal (ouai je sais ça faut beaucoup de référence à HFT, mais je suis dans ma période de vilain garnement 🙂 ).

Le mot de la fin

Consonnes, Voyelles. Je demande un 50/50 sur une garde sans. Risquez comme opération, mais ça passe et vous partez avec Maïté car votre préféré c’est le rondelé.

Erwan GUILLEMARD

Sources

• Définition Immuable
• VEEAM B&R 12.1 – Hardened Guide
• Linux – chattr
• E2fsprogs

Je remercie LLU, d’avoir su me mettre sur la voie et d’avancer sur ce sentier.

1. SE : Système d’Exploitation ↩︎
2. LTS : Long Time Support ↩︎
3. ANSSI : Agence National de Sécurité des Systèmes d’Informations ↩︎
4. XFS : X File System ↩︎
5. SFP+ : Small Form-Factor Pluggable+ (10 Gb/s) ↩︎
6. FC : Fiber Channnel ↩︎
7. GFS : Grand Father, Father, Son ↩︎
8. RI : Reverse Incremental ↩︎
9. FI : Forward Incremental ↩︎