Comment protéger un serveur Microsoft Exchange avec CrowdSec ?

I. Présentation

Dans ce tutoriel, nous allons voir comment sécuriser un serveur de messagerie Microsoft Exchange avec le pare-feu collaboratif CrowdSec ! Le fait d'installer CrowdSec sur un serveur Microsoft Exchange va permettre de se protéger contre les attaques courantes, mais également contre les nouvelles menaces.

Par exemple, je pense à la faille de sécurité ProxyNotShell qui a fait parler d'elle en octobre 2022 : CrowdSec est capable de détecter les tentatives d'exploitation et de bloquer les adresses IP malveillantes, grâce au fait qu'il existe une collection pour IIS et les attaques basées sur les protocoles HTTP/HTTPS. On peut également citer des cas plus classiques : un brute force sur l'interface du webmail d'Exchange.

De par sa fonction, un serveur Exchange sera plus ou moins exposé sur Internet selon l'architecture de votre SI (par exemple, la présence ou non d'un reverse proxy). Toutefois, il a besoin de pouvoir communiquer vers l'extérieur et d'être joignable depuis l'extérieur pour envoyer et recevoir les e-mails à destination des boîtes aux lettres de vos utilisateurs.

Ce même serveur sera aussi joignable par l'intermédiaire d'un Webmail qui permet aux utilisateurs de consulter leurs e-mails à partir d'un navigateur. Ceci implique la présence d'un serveur Web IIS, qui héberge à la fois le Webmail et le Centre d'administration d'Exchange. D'ailleurs, lorsqu'il y a la compromission d'un serveur Exchange dans le cadre d'une cyberattaque, cela passe majoritairement par les accès HTTP/HTTPS : d'où l'intérêt de se protéger.

Cet article fait office de suite à mon premier article sur l'installation d'un serveur Exchange Server 2019. Pour l'installation de Microsoft Exchange Server en lui-même, je vous invite à lire mon précédent tutoriel :

• Tutoriel - Installation de Microsoft Exchange Server 2019

En complément, je vous encourage aussi à restreindre l'accès au Centre d'administration Exchange :

• Tutoriel - Désactiver les accès externes au Centre d’administration Exchange

II. Mise en place de CrowdSec sur Windows

A. Installation de l'agent CrowdSec

J'ai déjà évoqué l'installation de CrowdSec sur Windows dans un précédent article, mais il s'agissait de la version Alpha. Désormais, l'agent CrowdSec pour Windows est disponible en version stable, ce qui signifie qu'il est prêt pour être mis en place en production.

Note : si vous avez mis en place la version alpha sur votre serveur, vous devez procéder à une désinstallation de CrowdSec avant d'installer cette nouvelle version.

Tout d'abord, vous devez télécharger le package MSI sur le dépôt GitHub officiel de CrowdSec.

• Télécharger CrowdSec pour Windows

Lors de l'installation, le package MSI de CrowdSec va réaliser les actions suivantes :

• Installation de CrowdSec en lui-même
• Intégration de la collection Windows (les détails sont disponibles ici)
• Inscription de l'instance CrowdSec avec l'API Central
• Inscription du service CrowdSec au sein de Windows (démarrage automatique)

Une fois que c'est fait, démarrez l'installation. Il suffit de suivre les étapes sans apporter de modifications... Ensuite, comptez 2 minutes environ pour l'installation de l'agent.

Dès que l'agent CrowdSec est en place, nous avons accès à la ligne de commande "cscli" qui permet de manager son instance CrowdSec en ligne de commande.

Pour lister les collections actuelles :

cscli collections list

Pour lister les bouncers actuels (aucun par défaut) :

cscli bouncers list

B. Installation de la collection IIS

Sur Windows, CrowdSec met en place nativement la collection "crowdsecurity/windows", mais ce n'est pas suffisant pour protéger notre serveur Exchange. Nous devons ajouter la collection pour IIS, ce qui va implicitement ajouter deux autres collections permettant de détecter les attaques Web.

Cette collection s'installe à partir de cette commande :

cscli collections install crowdsecurity/iis

Quelques secondes plus tard, nous pouvons lister les collections installées afin de constater la présence des nouvelles collections.

D'ailleurs, pour justifier ce que je disais en introduction au sujet de la vulnérabilité ProxyNotShell, nous pouvons regarder le détail de la collection "crowdsecurity/http-cve". Ici, on peut constater la présence d'un scénario de détection nommé "crowdsecurity/CVE-2022-41082" correspondant à cette vulnérabilité.

cscli collections inspect crowdsecurity/http-cve

Passons à l'étape suivante.

C. Installation du bouncer firewall Windows

Nous devons mettre en place le bouncer "firewall" pour Windows, sinon les attaques seront détectées, mais pas bloquées. Cliquez sur le lien ci-dessous, puis sur le bouton "Download" afin de télécharger le package MSI.

• Télécharger le bouncer firewall pour Windows

L'installation s'effectue en quelques clics : il suffit de suivre l'assistant.

Une fois que c'est terminé, la commande ci-dessous permettra de visualiser la présence du bouncer.

cscli bouncers list

Passons à l'étape suivante.

D. Ajouter la prise en charge des logs IIS

Pour que CrowdSec s'intéresse aux journaux générés par IIS, et par extension correspondant aux accès sur les portails OWA et ECP d'Exchange, nous devons lui indiquer les chemins vers les fichiers journaux à analyser.

Vous devez modifier le fichier suivant :

C:\ProgramData\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" qui se caractérise par la présence du caractère wildcard (*) : "C:\inetpub\logs\LogFiles\*\*.log". Cette valeur va permettre à CrowdSec de trouver et lire les fichiers de logs situés dans l'arborescence "C:\inetpub\logs\LogFiles\" et de les analyser. Ce qui signifie que si vous utilisez un autre chemin, voire même un autre volume pour les logs, vous devez adapter cette valeur.

Au-delà du chemin vers les fichiers journaux, ce bloc de configuration que l'on vient d'ajouter contient un paramètre nommé use_time_machine. Il est important, car 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, ceci évite de faux positifs.

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. Cette opération s'effectue en PowerShell avec cette commande :

Restart-Service crowdsec

La mise en place de CrowdSec est terminée ! Maintenant, nous allons tester notre système de protection !

III. Le serveur Exchange est-il protégé ?

A. Brute force sur OWA - Webmail Exchange

Pour réaliser une attaque par brute force sur OWA, il y a plusieurs méthodes envisageables. Bien sûr, on peut le faire manuellement pour tester, mais on peut aussi utiliser quelque chose d'un peu plus automatisé pour simuler une attaque de type brute force. Ainsi, on va utiliser un script Bash nommé "OWA BRUTE" qui exécute Hydra (un outil offensif compatible avec de nombreux protocoles pour tester l'authentification à un service, un équipement, etc.) avec des paramètres spécifiques correspondants à Outlook Web Access.

Le script est disponible sur GitHub à l'adresse suivante :

• GitHub - OWA BRUTE

Tout d'abord, nous devons installer Hydra et Git. Le premier est un prérequis pour utiliser le script et réaliser notre attaque, tandis que le second va servir à cloner le dépôt GitHub pour récupérer le script Bash (vous pouvez aussi faire un copier-coller du script dans un fichier...).

sudo apt-get update
sudo apt-get install hydra git

Une fois que c'est fait, on clone le projet GitHub dans "/home/florian" :

cd /home/florian/
git clone https://github.com/p0dalirius/owabrute

Puis, on crée un fichier "users.txt" dans lequel on indique quelques noms d'utilisateurs. On peut aussi imaginer que l'on récupère une liste sur Internet.

nano /home/florian/owabrute/users.txt

Dans le même esprit, on crée un fichier "passwords.txt" avec les mots de passe à tester.

nano /home/florian/owabrute/passwords.txt

Ensuite, on se positionne dans le répertoire de OWA BRUTE pour ajouter les droits d'exécution sur le script Bash.

cd /home/florian/owabrute/
chmod +x owabrute.sh

Il ne reste plus qu'à lancer l'attaque en ciblant "mail.domaine.fr" puis en utilisant nos fichiers créés précédemment.

./owabrute.sh -d mail.domaine.fr -u ./users.txt -p ./passwords.txt

On peut voir que le script va tester chaque combinaison, tour à tour. Au final, il indiquera s'il a réussi ou non à trouver une combinaison valide. Toutefois, CrowdSec va intervenir....

En effet, si je regarde du côté de mon serveur Exchange, je peux voir qu'il y a une nouvelle adresse IP bloquée à cause d'un brute force ("crowdsecurity/windows-bf"). L'agent CrowdSec a correctement bloqué l'adresse IP à l'origine de cette attaque.

Puisqu'ici nous sommes là pour faire des tests, nous pouvons débloquer notre adresse IP manuellement :

cscli decisions delete --ip X.X.X.X

Passons à une seconde démonstration.

B. Scan Web sur OWA

Dans le cas où un individu cherche à scanner votre serveur Web, en l'occurrence ici IIS utilisé par Exchange, il peut s'appuyer sur divers outils dont Nikto qui sert à analyser le niveau de sécurité d'un serveur Web. Pour cet exemple, OWA sera analysé avec l'outil Nikto : nous verrons si CrowdSec détecte ce qu'il se passe sur le serveur IIS...

Tout d'abord, installons cet outil :

sudo apt-get update
sudo apt-get install nikto

Puis, on lance le scanne à destination du webmail :

nikto -h https://mail.domaine.fr/owa

L'analyse va durer plusieurs minutes...

...Sauf qu'au bout d'un moment, CrowdSec va se rendre compte que ce client Web effectue des actions suspectes et il va décider de le bloquer. Dans l'exemple ci-dessous, on peut voir la raison "http-sensitive-files" ce qui signifie que le client a essayé d'accéder à des fichiers sensibles.

Dans ce second exemple, où l'on a effectué une action totalement différente en comparaison de la première tentative, CrowdSec est également parvenu à détecter nos actions malveillantes.

IV. Conclusion

Nous venons de voir comment mettre en place l'agent CrowdSec sur Windows de manière à protéger un serveur de messagerie Microsoft Exchange ! Ici, j'ai pris l'exemple d'Exchange Server 2019, mais cela s'applique aussi aux versions précédentes. Avec ces deux exemples rapides, mais concrets, nous avons pu voir l'efficacité de CrowdSec !

Je profite de cet article pour vous rappeler l'existence de la console CrowdSec qui vous permet de suivre les alertes remontées par un ou plusieurs agents CrowdSec à partir d'une console en mode Web. Pour en savoir plus sur la mise en place et l'ensemble des fonctionnalités, consultez cet article :

• Prise en main de la console CrowdSec

Florian BURNEL Co-founder of IT-Connect

Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.

See Full Bio