Veeam v11 et Immuabilité


Userlevel 7
Badge +7

Bonjour à tous,

Ces derniers temps, les attaques des infrastructures informatique sont devenues plus sophistiqués. Elles ont la capacité de crypter des données en direct et des machines virtuelles entières, mais elles ont également appris à supprimer ou à crypter les fichiers de sauvegardes . Si cela se produit et que vous ne disposez pas d'une sauvegarde hors ligne comme une bande ou une autre méthode d’externalisation vous risquez de vous retrouver dans une situation bien compliquée.

Veeam apporte une sécurité supplémentaire pour nos sauvegardes avec la fonctionnalité “Veeam Hardened Linux Repository”. 
L’immuabilité est désormais accessible à tous. 

Veuillez trouver ma procédure pas à pas juste ici → https://original-network.com/veeam-hardened-linux-repository-part-i/

N’hésitez pas si vous avez des questions.

Enjoy it ;)


9 comments

Userlevel 3
Badge +3

Merci pour le tuto. 

J’ajoute que bien évidemment il faut que le repository soit un serveur physique dédié et non une VM de l’infrastructure de virtualisation sinon c’est game over :sunglasses:

 

 

Badge

C’est un débat intéressant est-ce que les serveurs physiques sont mieux sécurisables que des VM ? Difficile à trancher quand même, on a malheureusement des exemples récents de serveurs physiques qui partent en poussière et vice er versa des hyperviseurs qui présentent des failles de sécurité très facilement exploitables. Pour moi des hyperviseurs sur un autre schéma de sécurité que l’infrastructure de virtualisation présente le même niveau de sécurité qu’un serveur Linux physique. Qu’en pensez-vous ?

Userlevel 4
Badge +4

Salut Philippe, super step by step d’un point de vue Veeam. Je rajouterai juste sur la partie “hardening” que l’os linux et sa configuration joue un role clé.

Notamment  :

  • En évitant que le compte Veeam reste dans les sudoers post install
  • Que la synchronisation de temps soit sur un serveur externe
  • Et que le password root soit fort en cas d’attaque via interface de management Idrac/Ilo etc

@jm.massou Pour répondre, un serveur physique linux sans accès SSH et hors domaine a beaucoup (beaucoup beaucoup) moins de vecteur d’attaque qu’une infra de virtu ou plusieurs admin se connect régulièrement avec des comptes dans des groupes du domaine et où un simple delete de la VM supprime toutes les données. Et par extension il faut sécurisé l’interface de la baie également (généralement simple login password et/ou domaine account).

Userlevel 3
Badge +3

C’est un débat intéressant est-ce que les serveurs physiques sont mieux sécurisables que des VM ? Difficile à trancher quand même, on a malheureusement des exemples récents de serveurs physiques qui partent en poussière et vice er versa des hyperviseurs qui présentent des failles de sécurité très facilement exploitables. Pour moi des hyperviseurs sur un autre schéma de sécurité que l’infrastructure de virtualisation présente le même niveau de sécurité qu’un serveur Linux physique. Qu’en pensez-vous ?

Alors mon propos initial portait sur le fait qu’il ne faut pas utiliser l’infra de virtualisation qu’on souhaite protéger….pour héberger ces repos. C’est bête mais certains l’ont fait.

Mais sinon, je rejoins les propos de Baptiste, il faut réduire au strict minimum la surface d’attaque

Badge

Alors mon propos initial portait sur le fait qu’il ne faut pas utiliser l’infra de virtualisation qu’on souhaite protéger….pour héberger ces repos. C’est bête mais certains l’ont fait.

Mais sinon, je rejoins les propos de Baptiste, il faut réduire au strict minimum la surface d’attaque

Merci pour l’éclaircissement ! En effet lorsqu’il n’y a qu’une seule forêt AD et qu’elle est compromise … il y a le feu partout ! 

Userlevel 7
Badge +7

Salut Philippe, super step by step d’un point de vue Veeam. Je rajouterai juste sur la partie “hardening” que l’os linux et sa configuration joue un role clé.

Notamment  :

  • En évitant que le compte Veeam reste dans les sudoers post install
  • Que la synchronisation de temps soit sur un serveur externe
  • Et que le password root soit fort en cas d’attaque via interface de management Idrac/Ilo etc

@jm.massou Pour répondre, un serveur physique linux sans accès SSH et hors domaine a beaucoup (beaucoup beaucoup) moins de vecteur d’attaque qu’une infra de virtu ou plusieurs admin se connect régulièrement avec des comptes dans des groupes du domaine et où un simple delete de la VM supprime toutes les données. Et par extension il faut sécurisé l’interface de la baie également (généralement simple login password et/ou domaine account).

 

Yes effectivement le durcissement du serveur est ultra important, d’ailleurs je suis entrain de rédiger la partie deux de mon post, qui parlera de cet aspect. (Mise en place de MFA, désactivation interface de management, sécurisation physique ...)

Il faut penser sont environnement de sauvegarde secure by design tout en gardant une structure simple à gérer. Il est préférable d’avoir son environnement Veeam isolé sur une infrastructure dédiée et éviter par exemple d’intégré le serveur VBR au sein du domaine de l’entreprise.

Userlevel 7
Badge +8

Personnellement je vois pas trop l’intérêt de mettre le dépot de sauvegarde sur un hyperviseur hormis rajoute une couche de risque et de gestion qui n’est pas forcément utile…

Le BR sur une infra complètement isolée et dédié est un débat aussi de cout d’exploitation au quotidien mais aussi matériels.

En tout cas c’est une bonne initiative, je lirais les billets du blog avec plaisir! Je monte également de mon coté un sobr consistant sur xfs de plusieurs PBs, j’essaierais d’apporter mes retours :) 

Userlevel 7
Badge +7

Personnellement je vois pas trop l’intérêt de mettre le dépot de sauvegarde sur un hyperviseur hormis rajoute une couche de risque et de gestion qui n’est pas forcément utile…

Le BR sur une infra complètement isolée et dédié est un débat aussi de cout d’exploitation au quotidien mais aussi matériels.

En tout cas c’est une bonne initiative, je lirais les billets du blog avec plaisir! Je monte également de mon coté un sobr consistant sur xfs de plusieurs PBs, j’essaierais d’apporter mes retours :) 

Hello,
Il est possible de mutualiser sur un ESX par exemple les différents rôles typiquement si l’on veut faire en plus de la sauvegarde de la réplications. 

Salut Philippe, super step by step d’un point de vue Veeam. Je rajouterai juste sur la partie “hardening” que l’os linux et sa configuration joue un role clé.

Notamment  :

  • En évitant que le compte Veeam reste dans les sudoers post install
  • Que la synchronisation de temps soit sur un serveur externe
  • Et que le password root soit fort en cas d’attaque via interface de management Idrac/Ilo etc

@jm.massou Pour répondre, un serveur physique linux sans accès SSH et hors domaine a beaucoup (beaucoup beaucoup) moins de vecteur d’attaque qu’une infra de virtu ou plusieurs admin se connect régulièrement avec des comptes dans des groupes du domaine et où un simple delete de la VM supprime toutes les données. Et par extension il faut sécurisé l’interface de la baie également (généralement simple login password et/ou domaine account).

 

Yes effectivement le durcissement du serveur est ultra important, d’ailleurs je suis entrain de rédiger la partie deux de mon post, qui parlera de cet aspect. (Mise en place de MFA, désactivation interface de management, sécurisation physique ...)

Il faut penser sont environnement de sauvegarde secure by design tout en gardant une structure simple à gérer. Il est préférable d’avoir son environnement Veeam isolé sur une infrastructure dédiée et éviter par exemple d’intégré le serveur VBR au sein du domaine de l’entreprise.

Salut @Stabz , article très intéressant ! 
As-tu avancé sur la partie 2 de ton post pour la sécurisation du serveur physique, interface de management.. ? Ca m’intéresserait beaucoup !

Comment