par , 05/05/2017 à 14h30 (2111 Affichages)
Bonjour,
Suite à la nouvelle vague d'e-mails malveillant contenant une variante de Locky, je me décide à sortir un petit billet sur une mesure de prévention simple trouvée sur le net, mais à mon avis insuffisamment bien exploitée.
Intro
Loin d'être LA solution, puisque cela ne protège que partiellement les fichiers exposés à certaines souches de ransomwares ; ceux qui modifient les extensions des fichiers qu'ils cryptent.
Le réel avantage, c’est que la mise en œuvre peut se faire en transparence sur vos serveurs de fichiers Windows.
Vous ne vous heurterez donc pas aux utilisateurs récalcitrants.
Néanmoins, cela n’empêche pas d’informer et de continuer la sensibilisation.
![:arrow:](https://www.developpez.net/forums/images/smilies/icon_arrow.gif)
Avant de commencer, assurez-vous d'avoir des serveurs de fichiers correctement gérés via la méthode AGDLP de Microsoft
(voir ici).
L'Idée
Il existe bon nombre de tutos sur internet permettant d'éviter l'enregistrement des extensions de ransomwares connus, sur vos serveurs, via FSRM.
Le problème est que les souches permettent de créer des centaines de variantes, et qu'il est juste impossible de tenir correctement à jour cette liste, ne sachant par quelle extension nous allons être mangés.
Sur le principe du moindre privilège, il est préférable de fonctionner par "white liste".
La pratique
Assurez-vous d'avoir le service de rôle FSRM d'installé, sinon installez le.
Pour mettre en oeuvre la solution, il faut interdire toutes les extensions (*.*), sauf celles permises au sein de votre SI.
Pour récupérer les extensions à mettre en whitelist, vous pouvez utiliser un script permettant de faire l’inventaire des extensions présentent sur votre serveur de fichiers, et ainsi générer un" groupe de fichiers" directement dans FSRM:
1 2 3 4 5 6 7
|
$l=@()
$i = gci -Recurse -File -Force -Path $Path -ErrorAction SilentlyContinue | ?{($_.Attributes -notmatch "Hidden") -and ($_.Extension -like "*.*")}
foreach ($o in $i) {
if ($l -notcontains ($e=('*'+ $o.Extension +'*'))) {$l += $e}
}
} |
cela peut prendre du temps, cela dépend des données présentes sur votre serveur de fichiers.
![:arrow:](https://www.developpez.net/forums/images/smilies/icon_arrow.gif)
Pour plus de sécurité vous pouvez faire cela sur une VM isolée, cela permettra de faire au passage une restauration complète de votre sauvegarde, et ainsi valider son intégrité.
Si vous redirigez le dossier "mes documents" de vos utilisateurs, vous ne devriez normalement pas avoir accès à leurs données personnelles.
Pour récupérer les extensions vous pouvez toujours essayer d'utiliser une restauration de sauvegarde et bidouiller les droits...
Le plus simple reste à rappeler à vos utilisateurs que ces fichiers ne font pas partit de la politique de sauvegarde, et que les dossiers professionnels doivent être enregistrés dans les partages prévus à cet usage.
La commande suivante créera un nouveau groupe de fichiers bloquant tous les fichiers à l'exception des extensions déjà présentent sur votre serveur:
New-fsrmFileGroup -Name RansomWare -IncludePattern "*" -ExcludePattern $l
La dernière commande servira à créer le nouveau filtre de fichiers avec notre whitelist.
Je vous conseil dans un premier temps de faire un filtre passif, afin de vous assurer que tout est en ordre.
Ensuite, une fois la période de validation que vous aurez définie passée, vous pourrez passer en actif.
C'est toujours possible en commande PS:
1 2
| #Supprimez l'option -Active pour rester en mode passif
New-FsrmFileScreen -Path $Path -IncludeGroup $Name -Active |
Le script complet
Create-FsrmWhiteList.zip
Conclusion
Comme je l'ai rappelé en introduction, cela ne représente qu'un petit maillon d'une protection, mais il est facile de mettre cette solution en place.
Et puis comme le dit le proverbe :
"une chaîne n'est pas plus forte que sont maillon le plus faible"
L'important dans ce billet, c'est aussi de voir plus loin que le fait d'utiliser FSRM.
Il faut intégrer l'idée de gérer exclusivement ce dont nous avons vraiment besoin, et d'exclure le reste.
Sur une nouvelle implémentation par exemple; Il est important de définir les types de fichiers qui seront pris en compte par le besoin, et intégrer votre filtre "by design", à la mise en place du serveur.
Le principe du "least privilège" ne ce réduit pas aux serveurs de fichiers, mais devrais s'appliquer à l'ensemble du SI (dans la mesure du possible), afin d'en améliorer la sécurité.
Je rappelle aussi que le meilleur moyen de se protéger est de sensibiliser les utilisateurs, et en cas de catastrophe d'avoir des sauvegardes récentes.
Si vous avez des remarques ou des améliorations à porter à cet article (ou au script), vous pouvez en faire part en commentaire ou par message privé.
En vous remerciant d'avoir pris le temps de me lire.
Benjamin.F