Comment sécuriser un serveur Windows avec CrowdSec ?

I. Présentation

Dans ce tutoriel, nous allons voir comment la solution open source CrowdSec peut nous aider à protéger un serveur sous Windows en bloquant les attaques informatiques de différents types : brute force sur la connexion "Bureau à distance" (RDP), scan d'un site Web IIS, etc... 

Ce n'est pas la première fois que je vous parle de CrowdSec, car c'est une solution qui monte clairement en puissance depuis plusieurs mois. Par contre, c'est la première fois que je vous parle de CrowdSec sur Windows et pour cause la version Alpha est disponible ! Une version stable devrait voir le jour prochainement, mais en attendant, n'hésitez pas à tester de votre côté et à remonter les éventuels bugs aux équipes de CrowdSec (il y a un Discord à disposition).

Pour le moment, CrowdSec est capable de surveiller les services suivants :

• RDP et SMB pour les attaques brute force (exemple : tentative de connexion malveillante sur un partage de fichiers)
• IIS pour les attaques HTTP/HTTPS notamment les scans de sites à la recherche de vulnérabilités
• SQL Server pour les attaques brute force
• Pare-feu Windows pour les scans réseau

Note : cette version Windows supporte la majorité des services déjà pris en charge sur Linux puisque les journaux sont générés selon les mêmes formats. Par exemple, Nginx va générer les mêmes journaux sous Linux et sous Windows.

Avant de rentrer dans le vif du sujet, voici les liens vers mes autres articles CrowdSec :

• Comment protéger son serveur Linux des attaques avec CrowdSec ?
• Comment bloquer les attaques sur son serveur Web "Apache + PHP" avec CrowdSec ?
• Comment protéger son site WordPress avec CrowdSec ?

II. L'objectif du jour

Aujourd'hui, nous allons nous intéresser à deux cas de figure :

• Le blocage d'une attaque brute force sur une connexion RDP (à partir du client "Bureau à distance" de Windows, par exemple)
• Le blocage d'un scan d'un site web hébergé sur un serveur IIS

Pour mon lab', je vais utiliser :

• Une machine à protéger avec CrowdSec : un serveur virtuel sous Windows Server 2022 (mais vous pouvez utiliser une autre version de Windows) hébergé sur le Cloud Azure
• Une machine qui sert à simuler des attaques : un serveur virtuel sous Kali Linux avec quelques outils (une machine Kali Linux via WSL fonctionnera aussi)

III. Mise en place de CrowdSec sur Windows

Commençons par télécharger les sources d'installation de CrowdSec. Vous pouvez obtenir les packages d'installation sur le GitHub officiel de CrowdSec :

• CrowdSec pour Windows - GitHub
• Bouncer Firewall pour Windows - GitHub

A. Installation de CrowdSec sur Windows

Lorsque le MSI est installé sur une machine Windows, il va permettre d'installer CrowdSec dans "C:\Program Files\CrowdSec\", mais aussi de télécharger la collection Windows, d'enregistrer l'instance auprès de l'API Centrale et de créer le service CrowdSec (afin qu'il démarre automatiquement en même temps que Windows).

Je ne vais pas m'attarder sur l'installation, car quelques clics suffisent pour en venir à bout.

B. Installation du bouncer Pare-feu Windows

Avant de lancer l'installation du bouncer, il faut que l'on installe une dépendance : .NET 6 Runtime. Sinon, l'installation du bouncer ne va pas se dérouler correctement. Par la suite, cette dépendance sera intégrée au package du bouncer pour que ce soit plus simple, mais je vous rappelle qu'il s'agit d'une version alpha.

Il est important de télécharger le ".NET Runtime" et non un autre élément, puis de bien prendre la version Windows au format "Installer". En l'occurrence en x64 dans la colonne "Installers" pour mon serveur Windows en 64 bits.

Télécharger - Framework .NET 6.0 depuis Microsoft.com

L'installation est également très simple, il suffit de suivre l'assistant...

Une fois que c'est fait, on peut enchaîner sur l'installation du bouncer "Windows Firewall" en exécutant le package correspondant. Suivez l'assistant afin de l'installer et nous en aurons terminé avec les installations de packages.

Ouvrez une console sur la machine Windows et listez les bouncers :

cscli bouncers list

La commande retourne "windows-firewall-bouncer", ce qui est une bonne nouvelle !

CrowdSec est prêt à l'emploi, nous allons pouvoir le tester dans différents cas de figure.

IV. Tester la protection CrowdSec

Pour tester l'efficacité de CrowdSec et voir sa capacité à protéger le serveur Windows, je vais prendre deux exemples :

• La protection d'un serveur Web "IIS"
• La protection de l'accès RDP (Bureau à distance)

A. CrowdSec et IIS

Avant de tester CrowdSec, on va s'intéresser au serveur IIS en lui-même, car il faut bien faire les présentations. C'est un serveur tout simple, avec le site par défaut et une page qui affiche un texte, le tout accessible sur une adresse IP publique en HTTP. En image, cela donne :

Quant aux logs de ce serveur IIS, ils sont stockés dans es fichiers de logs à l'emplacement par défaut.

Avec IIS, on peut stocker les logs dans des fichiers, dans l'observateur d'événements ou bien aux deux endroits. Pour connaître l'emplacement des logs du serveur, il faut ouvrir la console IIS, cliquer sur le serveur en haut à gauche, puis sur "Journalisation". Une fenêtre apparaît et il y a deux champs particulièrement intéressants :

• Répertoire : le chemin vers les fichiers journaux
• Destination des événements de journal

Voilà, vous en savez un peu plus sur la configuration de mon serveur IIS. Désormais, il est grand temps de passer à l'action.

Actuellement, CrowdSec n'est pas suffisamment configuré pour protéger notre serveur IIS. D'ailleurs, on peut le vérifier assez facilement... Tout d'abord, on va lister les décisions actives afin de voir les adresses IP actuellement bannies :

cscli decisions list

Tiens, il y a quelques adresses IP... Cela signifie que CrowdSec a déjà bloqué des attaques. Concernant la raison, on peut voir "windows-bf", ce qui correspond à du brute force Windows, en l'occurrence ici sur l'accès RDP, car je l'ai volontairement exposé sur Internet (pour le second test).

En revanche, depuis une machine distante, je peux scanner mon serveur IIS avec différents outils tels que Nikto sans être bloqué par CrowdSec !

nikto -h http://ip-publique-serveur-iis

Je tiens à vous rassurer : c'est normal. Il va falloir que l'on modifie la configuration de CrowdSec afin de lui indiquer où se situent les journaux de IIS, et lui faire comprendre qu'il doit surveiller ce service sur le serveur Web. Avant cela, nous devons installer la collection IIS sur le serveur grâce à cette commande :

cscli collections install crowdsecurity/iis

L'installation va s'effectuer en quelques secondes...

Vous pouvez vérifier que c'est OK grâce à la commande suivante :

cscli collections list

Ensuite, il faut modifier le fichier suivant :

C:\Program Files\CrowdSec\config\acquis.yaml

Afin d'ajouter les lignes suivantes à la suite :

---
use_time_machine: true
filenames:
  - C:\inetpub\logs\LogFiles\*\*.log
labels:
  type: iis

Vous pouvez voir la présence d'un chemin "dynamique" : "C:\inetpub\logs\LogFiles\*\*.log". Cette valeur va permettre à CrowdSec de trouver et lire les fichiers de logs situés dans "C:\inetpub\logs\LogFiles\W3SVC1" et de les analyser. Si vous utilisez un autre chemin, voire même un autre volume pour les logs, vous devez adapter cette valeur.

Dans le bout de code que l'on vient d'ajouter, il y a un paramètre sur lequel je souhaite attirer votre attention : use_time_machine. IIS n'écrit pas les logs en temps réel dans le fichier journal, mais il écrit les nouveaux événements en bloc, chaque minute. Grâce à ce paramètre, CrowdSec va lire la date et l'heure de chaque ligne pour se repérer et traiter les événements chronologiquement.

Par contre, si vous n'utilisez pas les fichiers de logs mais l'observateur d'événements, vous devez utiliser ce bout de code et non celui mentionné précédemment :

---
source: wineventlog
event_channel: Microsoft-IIS-Logging/Logs
event_ids:
  - 6200
event_level: information
labels:
  type: iis

Enregistrez le fichier acquis.yaml et vous pouvez le fermer. Pour finir, nous devons redémarrer le service CrowdSec, comme ceci :

Restart-Service crowdsec

Je vous propose que l'on revienne à la charge depuis l'hôte distant et Nikto.

nikto -h http://ip-publique-serveur-iis

Cette fois-ci, les choses se gâtent... Nikto affiche une erreur et il m'indique "can't connect (timeout)". Intéressant.

Sur le serveur IIS protégé par CrowdSec, je vais lister les décisions actives pour voir...

cscli decisions list

Tout s'explique : mon hôte distant est banni par CrowdSec ! On peut voir la raison "http-probing", ce qui signifie bien que l'attaque cible le service Web et donc IIS.

Mon hôte distant n'a plus accès à mon serveur, ce qui explique le "timeout" dans Nikto.

Puisque l'on utilise un bouncer qui s'appelle "Windows Firewall", on devrait en toute logique retrouver des informations sur les adresses IP bannies directement dans les règles de pare-feu Windows. C'est bien le cas, il y a plusieurs règles créées et gérées par CrowdSec. En recherchant dans l'une des règles, je suis parvenu à retrouver l'adresse IP de mon hôte distant depuis lequel j'ai émis le scan Nikto.

Quand une machine est bloquée, elle est totalement bloquée c'est-à-dire sur tous les ports et tous les protocoles.

Note : par défaut, une machine est bannie pour une durée de 4 heures, mais si vous souhaitez ajuster cette valeur, il suffit de modifier le paramètre "duration" du fichier "profiles.yaml". Pensez à redémarrer le service CrowdSec pour appliquer la modification.

B. CrowdSec et RDP

Parlons de notre second cas : la protection de l'accès RDP. Pour les raisons de cette démo, j'ai fait quelque chose de mal : j'ai publié mon serveur sur Internet, sur le port 3389 correspondant au port par défaut du protocole RDP. Ainsi, il est à la merci des bots en tout genre.... Ce qui explique pourquoi mon instance CrowdSec a rapidement banni quelques adresses IP (comme vu précédemment).

Pour effectuer un brute force RDP, on pourrait tout simplement ouvrir le client Bureau à distance de Windows et effectuer des tentatives en boucles. Pour que ce soit un peu plus cool, nous allons utiliser l'outil Crowbar. Nous avons le droit à un match : CrowdSec VS Crowbar. Crowbar est un outil pour faire du brute force qui supporte plusieurs services : RDP, OpenVPN, SSH et VNC.

Afin d'utiliser Crowbar sur ma machine où se situe Nikto et qui tourne sous Kali Linux, je dois installer le paquet :

sudo apt-get install crowbar

Ensuite, il ne reste plus qu'à cibler mon accès RDP de cette façon :

crowbar -b rdp -s <ip publique RDP>/32 -u florian -c MonMotDePasse1

La commande ci-dessus cible l'adresse IP publique de mon serveur, et va essayer l'utilisateur "florian" avec le mot de passe "MonMotDePasse1". Pour que ce soit plus réaliste, on peut utiliser un dictionnaire de mots de passe... Pour ce faire, je crée un petit dictionnaire "dico.txt" sur ma machine :

Puis, je repars à l'assaut de mon serveur en utilisant ce dictionnaire (l'option -c est remplacée par -C). Cette fois-ci, on va effectuer une réelle attaque brute force car Crowbar va tester tous les mots de passe de mon dictionnaire.

crowbar -b rdp -s <ip publique RDP>/32 -u florian -C ~/dico.txt

Visiblement, il n'est pas parvenu à se connecter...

Par contre, il s'est fait repérer par CrowdSec ! Du coup, l'adresse IP publique utilisée par l'hôte Crowbar est bannie à son tour !

cscli decisions list

Pour détecter les attaques par brute force sur l'hôte Windows, CrowdSec regarde l'observateur d'événements de la machine, et plus particulièrement les événements avec l'ID 4625 du journal sécurité. En effet, une ouverture de session en échec génère un événement de ce type.

Fin de partie : le grand gagnant de ce duel est CrowdSec !

Note : en complément de la protection assurée par CrowdSec, je vous recommande d'activer le verrouillage des comptes de l'Active Directory comme je l'expliquais dans un précédent article.

V. Conclusion

Nous venons de voir, au travers de ces deux exemples, l'intérêt de mettre en place un outil de sécurité tel que CrowdSec sur un serveur Windows afin d'augmenter le niveau de sécurité. Le portage de CrowdSec sur Windows s'annonce prometteur et l'outil fonctionne bien même s'il ne s'agit que d'une version alpha.

Même si j'ai simulé des attaques provenant de l'extérieur et que tous les serveurs Windows ne sont pas publiés sur Internet (surtout en RDP comme je l'ai fait), CrowdSec peut très bien vous protéger contre une attaque qui émane de l'intérieur de votre réseau local. Sinon, pour en revenir à IIS, CrowdSec peut s'avérer très utile pour protéger les applications qui utilisent ce serveur Web comme c'est le cas du webmail d'Exchange (Outlook Web Access).

Article rédigé en collaboration avec CrowdSec.