Denis Braux

Sécuriser un serveur de sauvegarde Samba contre les ransomwares grâce à Btrfs et Proxmox

Les partages réseau Samba (CIFS) sont des cibles privilégiées pour les ransomwares : dès qu’un poste Windows infecté dispose des droits d’écriture sur un lecteur réseau, le pire arrive. Les fichiers sauvegardés sont chiffrés, voire supprimés.

Dans cet article, nous détaillons la mise en place d’une solution de sauvegarde résiliente pour notre infrastructure. En séparant l’accès réseau Samba des mécanismes de protection du système de fichiers Btrfs, nous obtenons une protection anti-ransomware étanche et automatisée.

1. Le principe d’isolation (Le cœur de la sécurité)

Pour empêcher un ransomware de détruire les sauvegardes historiques, le partage réseau ne doit jamais avoir accès aux snapshots.

       [ Client Windows / Samba ]
                   │
                   ▼ (Accès réseau / Port 445)
┌─────────────────────────────────────────────────────────┐
│ LXC Samba (Conteneur Proxmox)                           │
└──────────────────┬──────────────────────────────────────┘
                   │  Points de montage séparés
                   ▼
┌─────────────────────────────────────────────────────────┐
│ Hôte Proxmox (Noyau Linux / Btrfs)                      │
│                                                         │
│  ├── /mnt/samba-data      ──> Subvolume @data           │
│  │   (Accessible par Samba : Espace de travail live)    │
│  │                                                      │
│  └── /mnt/samba-snapshots ──> Subvolume @snapshots      │
│      (INACCESSIBLE à Samba : Snapshots en lecture seule)│
└─────────────────────────────────────────────────────────┘
  • Le subvolume @data contient les données actives. Il est monté dans le conteneur LXC et partagé sur le réseau.
  • Le subvolume @snapshots est monté uniquement sur l’hôte Proxmox. Le conteneur Samba ne connaît même pas son existence.
  • Résultat : Même si un pirate ou un ransomware prend le contrôle total du conteneur Samba ou des fichiers partagés, il lui est physiquement impossible de modifier ou de supprimer les snapshots stockés sur l’hôte.

2. Déploiement étape par étape

Étape 1 : Préparation du stockage Btrfs

On formate la partition dédiée en Btrfs et on crée la structure de subvolumes isolés.

Bash

# 1. Formatage du disque de stockage
mkfs.btrfs -f /dev/sdb1

# 2. Montage temporaire pour créer la structure
mkdir -p /mnt/btrfs-root
mount /dev/sdb1 /mnt/btrfs-root

# 3. Création des deux subvolumes distincts
btrfs subvolume create /mnt/btrfs-root/@data
btrfs subvolume create /mnt/btrfs-root/@snapshots

umount /mnt/btrfs-root

Étape 2 : Configuration du montage automatique (/etc/fstab)

On monte chaque subvolume à son emplacement dédié dans le fichier /etc/fstab de l’hôte Proxmox :

Extrait de code

# Subvolume pour les données partagées
UUID=595e8bfe-d30c-4634-b876-1c4b97a0d1f7  /mnt/samba-data       btrfs  subvol=@data,defaults,noatime      0  2

# Subvolume isolé pour l'archivage des snapshots
UUID=595e8bfe-d30c-4634-b876-1c4b97a0d1f7  /mnt/samba-snapshots  btrfs  subvol=@snapshots,defaults,noatime 0  2

On applique le montage :

Bash

mkdir -p /mnt/samba-data /mnt/samba-snapshots
systemctl daemon-reload
mount -a

3. Automatisation des snapshots et rotation (30 jours)

Grâce au mécanisme Copy-on-Write (CoW) de Btrfs, la création d’un snapshot est instantanée et ne consomme aucun espace disque au moment de sa création. L’espace supplémentaire n’est utilisé que lorsque des fichiers sont modifiés ou supprimés dans le volume principal.

Nous planifions deux tâches nocturnes dans la Crontab de l’hôte Proxmox :

  1. 02h00 : Prise de snapshot en lecture seule (-r).
  2. 02h30 : Purge automatique des snapshots datant de plus de 30 jours (via l’option -ctime qui contrôle l’âge de création des métadonnées).

Bash

# Injection propre dans la crontab
(crontab -l 2>/dev/null | grep -v "samba-snapshots" ; \
 echo "0 2 * * * btrfs subvolume snapshot -r /mnt/samba-data /mnt/samba-snapshots/snap-\$(date +\%Y\%m\%d)" ; \
 echo "30 2 * * * find /mnt/samba-snapshots/ -maxdepth 1 -name 'snap-*' -ctime +30 -exec btrfs subvolume delete {} \;" \
) | crontab -

4. Procédure de reprise après sinistre (PRA)

Si un poste client infecte le partage Samba et chiffre l’ensemble des données sur /mnt/samba-data, la procédure de restauration d’urgence se déroule en 4 étapes simples :

  1. Isoler l’infection : Couper immédiatement le partage réseau en arrêtant le conteneur Samba (pct stop 110).
  2. Effacer les données corrompues : Nettoyer le volume live (rm -rf /mnt/samba-data/*).
  3. Restaurer depuis le dernier snapshot sain :Bashcp -a /mnt/samba-snapshots/snap-AAAAMMJJ/* /mnt/samba-data/
  4. Redémarrer le service : Une fois le client infecté nettoyé, relancer le conteneur (pct start 110).

Conclusion

En combinant la flexibilité d’un partage Samba classique avec la puissance des subvolumes Btrfs administrés à l’extérieur du conteneur, nous obtenons une solution de sauvegarde hautement disponible, légère en ressources et immunisée contre les attaques par chiffrement réseau.