Ransomware-Resilient Linux Samba Server Server

Question

Imaginez le scénario suivant:

• Les fichiers sont conservés sur un serveur Linux et des clients les accèdent via Samba.
• L'une des machines clientes est infectée par Ransomware, qui crypte tout dans la portée de l'utilisateur connecté, y compris des fichiers sur les actions du serveur.

Je suis curieux de savoir s'il existe des solutions (en dehors des sauvegardes régulières) qui permettraient une récupération complète et facile de ces attaques.

Un design approximatif que j'avais à l'esprit serait basé sur une sorte de gestion d'instantané/de la version:

• Chaque fois qu'un fichier est modifié ou supprimé, conservez une copie de l'ancienne version autour d'un endroit.
• Ces versions précédentes seraient en lecture seule pour les utilisateurs ordinaires, les protégeant contre toute altération de tout type de ransomware en cours d'exécution sur les machines clientes.
• Les versions précédentes seraient disponibles via un chemin spécial, par ex. une version précédente de /home/john/path/to/file.odt serait dans /home/john/path/to/~snapshot/20161120_163242/file.odt.
• Une sorte de mécanisme pour rétablir des actions entières à un état antérieur.
• En option, heuristiques qui détectent une activité suspecte (par exemple, un grand nombre de fichiers en cours de lecture, de nouveaux fichiers de taille similaire créés et des fichiers d'origine étant supprimés, ou une modification à grande échelle des fichiers) et déclencher des actions appropriées (alertant l'accès à l'écriture de l'administrateur. ).
• La protection ne doit pas nécessairement s'appuyer uniquement sur des caractéristiques particulières de ransomware connues - Bien que ceux-ci puissent fonctionner contre ces chevaux de Troie particuliers, ils pourraient facilement être totalement inutiles contre les futurs ransomware mis en œuvre d'une manière différente.

Y a-t-il un logiciel qui fait ce genre de chose, fonctionne sur Linux et est FOSS?

Answer 1

J'ai lu quelques choses depuis, et j'ai trouvé la conception suivante - non encore testée dans la pratique, mais cela ferait probablement ce que je veux.

Fond

La "technologie d'activation" derrière cette configuration est BTRFS , dont nous exploitons trois caractéristiques:

• Copie-on-écriture (vache): Lorsque les fichiers sont copiés, BTRFS ne duplique pas le point de fichier de charge utile - la même région sur le disque et une copie vraie n'est créée que si l'un des deux fichiers est modifié. Cela rend la duplication des fichiers très faciles et légers.
• Subvolumes: Ce sont des volumes dans un volume. Les sous-volumes sont intrinsèquement montés avec leurs volumes parents (apparaissant sous forme de répertoires réguliers) ou montés à leur droit.
• Snapshots: Un instantané est une copie d'une sous-volume et en soi une sous-volume. En raison de la nature de la vache de BTRFS, les frais généraux sont minimes. Si la sous-visuelle étant instantanée a des sous-volés enfants, ceux-ci ne seront pas inclus (si cela est souhaité, instantanez-les individuellement). Les instantanés peuvent être lus/écrits ou en lecture seule. Dans ce dernier cas, ils sont immuables même s'ils font partie d'un support de lecture/écriture.

Installer

• Créez un volume BTRFS pour contenir toutes les actions de fichiers. (Comme FHS désigne /srv En tant que racine des données utilisateur spécifiques à un service, le point de montage pourrait être quelque chose comme /srv/samba ou /srv/file.) Montez-le avec l'option noatime (ceci garantit que les lectures simples ne modifient pas les métadonnées du fichier, minimisant davantage les frais généraux des instantanés).
• Pour chaque partage de fichiers, créez une subvolume BTRFS. Ils peuvent avoir les mêmes attributs de montage que leur parent et n'ont donc pas besoin d'être montés séparément.
• Exécuter un périodique (nuit, horaire, selon vos besoins), Cronjob crée des instantanés en lecture seule (importants!) Des sous-volés, en tant que sous-volés de ce dernier. Par exemple, l'instantané quotidien d'aujourd'hui de /srv/file/joe va dans /srv/file/joe/snapshot/daily-20180317. Le script peut éventuellement supprimer des instantanés qui passent un certain âge. Un échantillon peut être trouvé ici .
• Si possible, prenez les actions supplémentaires suivantes:
  • Des comptes privilégiés séparés (par exemple ceux avec Sudo autorisations) des comptes utilisés pour accéder aux actions réseau
  • Restreindre la capacité des utilisateurs ordinaires à exécuter des commandes sur le système (interdire les connexions Shell ou restreindre les commandes au minimum).
  • Verrouillez le compte root (appliquer l'utilisation de sudo).
  • Exiger le mot de passe de l'utilisateur pour des opérations privilégiées.

Mécanisme d'action

Un outil de ransomware crypter tout à sa portée ne serait pas simplement capable de chiffrer les instantanés. Il aurait besoin de:

• Soyez conscient qu'il fonctionne contre une part de réseau (il y a des crypto-chevrots connus qui cryptez le stockage en nuage également, ce n'est donc pas un véritable obstacle).
• Sachez que les fichiers sont servis sur un disque BTRFS et être capable de détecter sa structure de sous-volume.
• Évaluer ses privilèges sur le serveur pour désordre avec BTRFS Subvolumes (par exemple pour supprimer des instantanés ou les remplacer par des écrits en lecture-écriture) -C'est notre principale raison de la séparation des comptes d'utilisateurs de partage de fichiers provenant de celles privilégiées.

Si cela est fait correctement (c'est-à-dire au moins une des trois conditions préalables est suffisamment coûteuse pour un attaquant), qui augmente considérablement la barre.

Si les logiciels malveillants frappent, ce qui suit va arriver:

• Les fichiers peuvent être cryptés mais l'instantané reste non affecté. L'objectif du point de récupération est égal au temps entre les shapes, c'est-à-dire au plus, les modifications apportées depuis le dernier instantané seront perdues. Cela peut être contré en augmentant la fréquence de l'instantané (par exemple de quotidiennement à plusieurs fois par jour, horaire ou même plusieurs fois par heure).
• En raison de la nature de la vache de BTRFS, le cryptage d'un fichier prendra un espace supplémentaire. Si le disque est proche de la capacité, il peut être à court d'espace avant la fin du cryptage. Cela peut empêcher le cryptage des fichiers restants (le comportement exact dépend du cheval de Troie, alors ne comptez pas dessus).

Suppléments

Sauvegardez votre système régulièrement - les instantanés se complètent simplement. Bien que les instantanés soient utiles si vous devez récupérer de la corruption de données causée par des logiciels défectueux, des erreurs utilisateur ou certaines actions malveillantes, elles sont inutiles si votre disque va mal.

Cette configuration pourrait être complétée davantage en détectant une activité suspecte et en déclenchant des contre-mesures.

Les indications d'activité suspecte sont:

• Les fichiers étant écrasés à grande échelle, apparemment systématiques (bien que certains chevaux de Troie ne se produisent qu'après certains types de fichiers)
• Entropie élevée dans le contenu des fichiers écrasés (test simple: l'espace enregistré sur la compression est proche de zéro, bien que certains chevauchants crypter uniquement des parties du fichier, ce qui serait plus difficile à détecter de cette façon)
• Modifications apportées aux fichiers que vous ne vous attendriez pas normalement à changer (comme les photos de vacances de quelques années il y a quelques années, ou même des matières d'horizons créées, à ce sujet moins efficace, cependant, si le Trojan n'augit que ces fichiers seulement après avoir crypté la plupart des le reste)

Les actions potentielles incluent:

• Déclencher une alerte afin que l'administrateur puisse y étudier.
• Bloquer l'accès à l'accès à la part, pour l'utilisateur, à partir de l'adresse IP suspecte, pour l'ensemble du serveur, pour un groupe de serveurs, pour tous les serveurs que vous jugez appropriés, ce qui empêchera le Troie de poursuivre ses travaux, au détriment du blocage. quelques utilisations légitimes.
• Si l'accès à l'écriture de blocage est impraticable, accélérez la largeur de bande au serveur (éventuellement de manière sélective), ce sera au moins ralentir le processus de cryptage tout en permettant une utilisation légitime de continuer, même si des performances réduites.
• Désactiver la rotation de la capture instantanée - s'il s'agit d'une attaque et que cela se déroule depuis un certain temps, vous ne pourrez peut-être pas récupérer tout à partir du dernier instantané, mais peut avoir besoin de revenir à temps.
• Si vous avez des procédures médico-légales en place, déclenchez-les comme appropriés. Cela inclura probablement des procédures pour préserver les preuves, telles que la désactivation de la rotation du journal ou la mise en œuvre plus détaillée.

Answer 2

Je pense que les sauvegardes sont votre seul pari sûr. Ce que vous suggérez comme une solution consiste essentiellement à faire une sauvegarde spéciale; Je vous suggère de garder plusieurs (au moins deux) sauvegardes complètes. Le problème est ensuite réduit à la détection de ransomware Travailler sur vos fichiers et de récupérer à partir de la dernière bonne sauvegarde. Vous pouvez utiliser des sauvegardes déduplicantes pour économiser de l'espace. L'avantage d'aller à la route de sauvegarde est que

1. vous introduisez moins de complexité (aucun système supplémentaire juste pour Ransomware)
2. vous améliorez la qualité de votre routine de sauvegarde - une fois que vous êtes automatisé des alertes et de la récupération, vous avez mis en place beaucoup de choses pour faire la récupération de la sauvegarde une brise. C'est bon pour une catégorie beaucoup plus large d'échecs que de ransomware.

Comme pour -détecter ransomware, c'est facile: les fichiers cryptés ressemblent à des données aléatoires, vous pouvez simplement faire des tests statistiques pour chaque fichier (une distribution égale d'octets? Non compressable à l'aide de ZIP? Etc.) et compter le numéro des fichiers qui ont l'air aléatoire.

Answer 3

Actuellement, votre principal ennemi est Holiday:

Cet article a des détails sur l'utilisation échecd2ban Pour faire ce que vous voulez en détectant les notes de Ransom Serryy:

[Definition]

failregex = smbd * \.. \ IP = <Host> \ | * \ locky $.

. Smbd * \. \ IP = <Host> \ | * _ Locky_recover_instructions \ .txt $