Protéger un NAS contre les rançongiciels

Un rançongiciel est un logiciel malveillant qui chiffre les données d'une organisation pour exiger une rançon contre la clé de déchiffrement. Le NAS est une cible de choix : il concentre les fichiers de tous les services, et ses copies sont exactement ce qui permettrait de restaurer sans payer. Protéger un NAS, c'est limiter ce qu'un compte volé peut chiffrer, mettre les snapshots et les copies hors d'atteinte d'un attaquant même administrateur, durcir l'administration et détecter le chiffrement en cours. Ce chapitre décrit les modes d'attaque, puis ces protections sur TrueNAS, et la restauration après un incident. Le cours Cybersécurité : les fondamentaux présente les rançongiciels en général.

Comment un rançongiciel atteint un NAS

Le troisième mode n'a rien de théorique : en 2022, les campagnes DeadBolt ont chiffré des milliers de NAS de particuliers et de PME dont l'interface était accessible depuis Internet. La parade est simple et absolue : l'interface d'administration d'un NAS n'est jamais exposée sur Internet, et le NAS est tenu à jour.

Les groupes criminels préparent leurs attaques pendant des jours : ils cherchent d'abord les sauvegardes et les détruisent, puis chiffrent. Une protection n'a de valeur que si elle résiste à un attaquant qui a déjà les droits d'administrateur du domaine.

Couche 1 : limiter ce qu'un compte peut chiffrer

Un rançongiciel lancé par un poste ne peut chiffrer que ce que le compte de l'utilisateur a le droit de modifier. Le moindre privilège est donc la première protection :

• les droits sont donnés à des groupes précis, jamais à everyone@ ni à tous les utilisateurs du domaine (chapitre 5) ;
• la plupart des salariés n'ont que la lecture sur les archives : seuls les agents qui déposent les scans ont le droit de modification ;
• les comptes d'administration ne servent jamais à travailler au quotidien, et ne montent pas de lecteurs réseau.

Le partage verrouillé dans le temps. Pour des données qui ne doivent plus changer une fois déposées, comme les bons de livraison scannés, TrueNAS propose l'objectif Time Locked Share : un fichier passe en lecture seule par SMB après un délai de grâce (Grace Period), par exemple une heure après son dépôt. Un rançongiciel arrivé un mois plus tard ne peut plus modifier les archives. La documentation précise les limites : la protection ne joue que par SMB (pas pour un accès local ou par un autre partage sur le même chemin), et elle ne prétend pas satisfaire les exigences réglementaires d'un stockage à écriture unique.

Couche 2 : des snapshots hors d'atteinte des utilisateurs

Les snapshots sont la meilleure arme contre un chiffrement par un poste : ils sont en lecture seule, et un client SMB ne peut ni les modifier ni les supprimer, même avec le contrôle total sur le partage. Seul un administrateur de TrueNAS supprime des snapshots, depuis l'interface. Un rançongiciel qui chiffre \\srv-nas\Archives chiffre le dataset, pas ses snapshots : le retour au snapshot de l'heure précédente annule tout.

La fréquence des snapshots fixe la perte maximale de données, le RPO : avec des snapshots horaires, on perd au plus une heure de travail. Leur rétention fixe la profondeur de retour : un attaquant discret qui chiffre lentement pendant trois semaines impose de remonter à plus de trois semaines, d'où l'intérêt des snapshots quotidiens gardés un an.

Couche 3 : isoler l'administration du NAS

Si l'attaquant obtient l'administration du NAS, il supprime les snapshots. Il faut donc que les identifiants volés dans le domaine ne donnent pas l'administration de TrueNAS.

Les principes de l'administration sécurisée (bastion, comptes à privilèges, modèle en tiers) sont développés dans les cours Authentification et Cybersécurité des infrastructures.

Couche 4 : des copies que l'attaquant ne peut pas atteindre

Les copies doivent survivre à la compromission complète du siège : domaine et srv-nas.

• La réplication tirée. nas-mrs vient chercher les snapshots de srv-nas ; srv-nas n'a aucun identifiant sur nas-mrs (chapitre 9). nas-mrs n'est pas joint au domaine, a ses propres comptes d'administration avec double authentification, et garde ses snapshots plus longtemps que la source (deux ans). Même un attaquant administrateur du domaine et de srv-nas ne peut pas l'atteindre.
• Le verrouillage d'objet. Le compartiment S3 qui reçoit la copie Cloud Sync est créé avec le verrouillage d'objet en mode conformité (Object Lock, compliance mode) et une rétention par défaut, par exemple 30 jours : pendant cette durée, personne, pas même le titulaire du compte, ne peut modifier ou supprimer une version d'objet. La tâche Cloud Sync reste en mode COPY. Si les fichiers chiffrés sont copiés, les versions saines restent intactes dans le compartiment.
• La copie hors ligne. Pour les données les plus précieuses, une copie sur disques ou bandes déconnectés, en rotation, reste la seule protection contre tout ce qui passe par le réseau (cours Sauvegarde et PRA).

Détecter un chiffrement en cours

Plus on détecte tôt, moins il y a de fichiers à restaurer. Quatre signaux, à remonter dans la supervision et le SIEM :

Réagir et restaurer

Quand l'alerte tombe (un utilisateur qui ne peut plus ouvrir ses fichiers, une note de rançon, une alerte du SIEM), l'ordre des actions compte.

1. Stopper l'hémorragie. Identifier le compte et le poste à l'origine des écritures (audit SMB) ; désactiver le compte dans l'annuaire, isoler le poste du réseau. Si la source est inconnue, passer le partage en lecture seule (Export Read-Only) ou arrêter le service SMB : mieux vaut une heure d'indisponibilité que des milliers de fichiers chiffrés de plus.
2. Préserver les preuves. Prendre un snapshot de l'état chiffré et lui poser une retenue : il servira à l'enquête (date de début, fichiers touchés, note de rançon). Ne rien supprimer.
3. Trouver le dernier snapshot sain. Le snapshot qui précède la première écriture malveillante (journal d'audit, taille des snapshots). Le cloner pour vérifier que les fichiers s'ouvrent.
4. Restaurer. Retour arrière du dataset vers ce snapshot si rien de légitime n'a été écrit depuis ; sinon, restauration sélective des dossiers chiffrés depuis le clone. Si srv-nas lui-même est compromis, reconstruire le NAS et restaurer depuis nas-mrs ou le compartiment S3.
5. Remettre en service et déclarer. Réactiver le partage, vérifier avec les utilisateurs, documenter l'incident. Si des données personnelles sont touchées, qu'elles aient été chiffrées (donc indisponibles), modifiées ou copiées, l'organisation doit notifier la CNIL dans les 72 heures, sauf si la violation ne présente pas de risque pour les personnes ; un dépôt de plainte est conseillé : les obligations sont détaillées dans le cours Cybersécurité : les fondamentaux.

Exercices

Exercice 1 sur 4 Le poste infecté Réussi À revoir

Lundi à 7 h 40, le poste de Paul Martin, comptable, exécute un rançongiciel arrivé par une pièce jointe. Paul est membre de GG_Comptables, donc de DL_Archives_L (lecture sur Archives) et de DL_Compta_M (modification sur le partage Compta de srv-fichiers).

1. Que peut chiffrer le rançongiciel sur srv-nas ? Et sur srv-fichiers ?
2. Quelles données sont les mieux protégées, et grâce à quoi ?

Voir la réponseMasquer la réponse de l'exercice 1

1. Sur srv-nas, rien dans Archives : le compte de Paul n'y a que la lecture, et le rançongiciel agit avec ses droits. Sur srv-fichiers, il peut chiffrer tout le partage Compta, où le compte a le droit de modification (plus les dossiers du poste lui-même).
2. Les archives, grâce au moindre privilège (lecture seule pour la comptabilité) et, en dernier recours, aux snapshots horaires. Pour Compta, la restauration passera par les clichés instantanés de srv-fichiers ou par la sauvegarde. Le compte de Paul doit être désactivé et son poste isolé tout de suite.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 L'administrateur du domaine compromis Réussi À revoir

Un attaquant a obtenu le mot de passe d'un administrateur du domaine. Pour chaque configuration de srv-nas, dis s'il peut supprimer les snapshots des archives.

1. Le groupe Admins du domaine est membre des administrateurs de TrueNAS.
2. Les administrateurs de TrueNAS sont des comptes locaux avec double authentification, et l'interface n'est accessible que depuis le VLAN 99.
3. Même configuration qu'en 2, mais adm-amercier utilise le même mot de passe que son compte du domaine, et la double authentification n'est pas activée.

Voir la réponseMasquer la réponse de l'exercice 2

1. Oui : les identifiants volés donnent directement l'administration du NAS. Il supprime les snapshots, puis chiffre.
2. Non, en l'état : les identifiants du domaine ne donnent aucun droit sur TrueNAS, l'interface n'accepte que les adresses du VLAN 99 (Allowed IP Addresses), et un mot de passe local seul ne suffit pas sans le second facteur. (Il pourrait chercher à compromettre le poste d'administration : d'où le bastion et la surveillance.)
3. Oui, probablement : la réutilisation du mot de passe annule la séparation des comptes, et sans second facteur, un mot de passe connu suffit dès que l'attaquant atteint le VLAN 99. Les copies de nas-mrs (réplication tirée, hors domaine) restent alors la dernière ligne de défense.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Cas type E7 : la réponse à incident Réussi À revoir

Mardi, 8 h 15 : des salariés signalent des fichiers .lock illisibles dans \\srv-nas\Archives. L'audit SMB montre 52 000 renommages entre 2 h 04 et 2 h 58, tous faits par le compte svc-scan depuis 192.168.10.140, le serveur de numérisation de l'entrepôt. Les snapshots horaires ne tournent que de 8 h à 19 h ; le dernier snapshot quotidien date de minuit.

1. Quelles sont tes trois premières actions, dans l'ordre ?
2. Vers quel snapshot restaurer, et quelle perte de données en résulte ?
3. Quelle mesure aurait empêché ce chiffrement, ou au moins réduit la perte ?

Voir la réponseMasquer la réponse de l'exercice 3

1. Désactiver le compte svc-scan dans l'annuaire et isoler 192.168.10.140 du réseau (l'attaque peut reprendre) ; prendre un snapshot de l'état actuel du dataset et lui poser une retenue, pour l'enquête ; prévenir le responsable et lancer la procédure d'incident (aucune suppression, aucun redémarrage du serveur compromis, dont la mémoire et les journaux sont des preuves).
2. Le snapshot quotidien de minuit, le dernier antérieur à 2 h 04, après l'avoir cloné pour vérifier qu'il est sain. Perte : les scans déposés entre minuit et 2 h 04 (s'il y en a), à redemander au serveur de numérisation ou à rescanner une fois celui-ci reconstruit. (Entre 2 h 58 et 8 h 15, rien de légitime n'a été écrit par svc-scan, isolé depuis.)
3. Time Locked Share sur Archives : les fichiers déposés passent en lecture seule par SMB après le délai de grâce, et svc-scan n'aurait pu chiffrer que les scans de la dernière heure. Également : des droits du compte svc-scan limités à l'ajout de fichiers dans un dossier de dépôt (pas la modification de tout le partage), et des snapshots horaires 24 h sur 24, qui auraient réduit la perte à moins d'une heure.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Vrai ou faux ? Réussi À revoir

Justifie chaque réponse.

1. « Avec des snapshots horaires, un rançongiciel ne peut rien contre nos données. »
2. « Un compartiment S3 en mode SYNC protège contre le chiffrement des fichiers. »
3. « Poser une retenue sur tous les snapshots les rend immuables. »

Voir la réponseMasquer la réponse de l'exercice 4

1. Faux. Les snapshots résistent à un chiffrement par un compte utilisateur, mais un attaquant qui obtient l'administration du NAS les supprime, et la perte du pool les emporte. Ils n'empêchent pas non plus le vol des données (double extorsion).
2. Faux. En mode SYNC, Cloud Sync reproduit l'état de la source : les fichiers chiffrés remplacent les fichiers sains dans le compartiment. Il faut le mode COPY avec un compartiment versionné, et le verrouillage d'objet pour que les versions saines ne puissent pas être supprimées.
3. Faux. Un administrateur peut lever la retenue puis supprimer le snapshot. Elle protège contre la rétention automatique et les fausses manœuvres, pas contre un attaquant administrateur.

Tu avais trouvé ?

Oui, j'avais bonPas encore