Sécuriser ses serveurs avec CrowdSec et Wazuh

Un serveur exposé sur Internet reçoit ses premières tentatives de connexion SSH dans les minutes qui suivent sa mise en ligne. Ce n'est pas personnel : des robots balaient en permanence toutes les adresses existantes. La question n'est donc pas de savoir si quelqu'un va frapper à la porte, mais ce qui se passe quand il frappe, et ce qui se passe s'il entre.

CrowdSec et Wazuh répondent chacun à l'une de ces deux questions. Ils sont libres, matures, et forment un duo que nous déployons chez la plupart de nos clients.

01Le videur et la caméra

CrowdSec est le videur : il se tient à l'entrée, reconnaît les fauteurs de troubles à leur comportement (vingt mots de passe faux en une minute, un balayage de chemins d'administration) et les refoule. Il connaît aussi les têtes déjà signalées par des milliers d'autres videurs dans le monde.

Wazuh est la caméra de surveillance, avec quelqu'un derrière l'écran : il observe l'intérieur des machines, remarque qu'un fichier système a changé, qu'un compte a été créé à 3 h du matin, qu'un paquet installé porte une faille connue.

L'un sans l'autre laisse un angle mort. CrowdSec seul ne voit rien de ce qui passe sous son radar, une connexion légitime avec un mot de passe volé par exemple. Wazuh seul voit tout, mais trop tard pour empêcher les attaques de masse, et noie l'équipe sous des alertes que CrowdSec aurait tuées dans l'œuf.

02CrowdSec, comment ça marche

CrowdSec sépare la détection de la sanction, et c'est ce qui le rend si souple :

• L'agent lit les journaux, les découpe avec des parsers et les confronte à des scénarios : « plus de cinq échecs d'authentification SSH en trente secondes », par exemple.
• L'API locale (LAPI) enregistre les décisions : telle adresse, bannie pour quatre heures.
• Les bouncers appliquent les décisions : au niveau du pare-feu nftables, dans Nginx, chez Cloudflare. Un bouncer peut tourner sur une autre machine que l'agent.
• L'API centrale partage, de façon anonymisée, les adresses bannies par toute la communauté, et vous renvoie en échange une liste de blocage préventive.

Les parsers et scénarios sont regroupés en collections par logiciel : une pour Nginx, une pour SSH, une pour WordPress, une pour Postfix, etc. On installe la collection du service à protéger, et l'essentiel est fait.

03Installer CrowdSec

Sur Debian ou Ubuntu, depuis le dépôt officiel. Le script d'installation ajoute le dépôt et sa clé, il n'installe rien d'autre.

curl -s https://install.crowdsec.net | sh
apt update
apt install crowdsec

# l'installateur detecte les services presents et installe leurs collections
cscli collections list

cscli collections install crowdsecurity/nginx

# /etc/crowdsec/acquis.d/nginx.yaml
filenames:
  - /var/log/nginx/*.log
labels:
  type: nginx

systemctl reload crowdsec

apt install crowdsec-firewall-bouncer-nftables

# la cle d'API est normalement inscrite automatiquement ; sinon :
cscli bouncers add pare-feu-local
# puis la reporter dans /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
systemctl restart crowdsec-firewall-bouncer

Avant d'aller plus loin, protégez-vous de vous-même. Un administrateur qui se trompe trois fois de mot de passe depuis le bureau serait banni comme n'importe qui.

name: captainadmin/nos-adresses
description: "Adresses d'administration a ne jamais bannir"
whitelist:
  reason: "reseaux d'administration"
  ip:
    - "203.0.113.10"
  cidr:
    - "10.0.0.0/8"

systemctl reload crowdsec
cscli metrics          # lignes lues, parsees, scenarios declenches
cscli decisions list   # adresses actuellement bannies
cscli alerts list      # historique des detections

# test : se bannir soi-meme depuis une adresse jetable, puis lever le ban
cscli decisions add --ip 198.51.100.7 --duration 5m --reason test
cscli decisions delete --ip 198.51.100.7

04CrowdSec sur tout un parc

Sur un seul serveur, tout tourne en local. Sur un parc, nous centralisons : une API locale unique reçoit les détections de tous les agents, et chaque bouncer applique les décisions de tout le parc. Une adresse qui attaque le serveur web est alors bannie aussi de la messagerie et des nœuds Proxmox, avant même d'avoir essayé.

cscli lapi register --url https://crowdsec.interne.exemple.fr:8080
# couper l'API locale de l'agent : dans /etc/crowdsec/config.yaml
#   api.server.enable: false
systemctl restart crowdsec

cscli machines list
cscli machines validate nom-de-la-machine

05Wazuh, comment ça marche

Wazuh est une plateforme de détection et de réponse, issue d'OSSEC. Elle se compose d'un serveur (le manager, qui analyse), d'un moteur d'indexation (dérivé d'OpenSearch, qui stocke et cherche) et d'un tableau de bord. Sur chaque machine surveillée tourne un agent léger, qui remonte :

• Les journaux, analysés par plusieurs milliers de règles : élévation de privilèges, création de compte, échecs répétés, arrêt d'un service de sécurité.
• L'intégrité des fichiers : qui a modifié /etc/passwd, un binaire système, la configuration Nginx, et quand.
• L'inventaire et les vulnérabilités : paquets installés confrontés aux bases de vulnérabilités, avec leur gravité.
• La conformité : évaluation de la configuration face à des référentiels comme les benchmarks CIS.

06Installer Wazuh

Pour un parc de PME, quelques dizaines d'agents, l'installation tout-en-un sur une machine virtuelle dédiée suffit. Comptez au minimum 4 vCPU, 8 Go de mémoire et 50 Go de disque, et surveillez ce dernier : c'est lui qui sature en premier.

# relever la version 4.x courante sur documentation.wazuh.com
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
bash ./wazuh-install.sh -a

# le mot de passe administrateur s'affiche a la fin ; le noter dans le coffre-fort

# depot Wazuh : suivre la procedure officielle, puis
WAZUH_MANAGER="wazuh.interne.exemple.fr" apt install wazuh-agent
systemctl daemon-reload
systemctl enable --now wazuh-agent

<syscheck>
  <frequency>43200</frequency>
  <directories realtime="yes" check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories realtime="yes" report_changes="yes">/etc/nginx,/etc/ssh</directories>
  <ignore>/etc/mtab</ignore>
</syscheck>

07Les faire travailler ensemble

La règle est simple : un seul outil bannit. Wazuh sait lui aussi bloquer des adresses par réponse active ; si les deux le font, ils se marchent sur les pieds et les débogages deviennent pénibles. Nous laissons le blocage à CrowdSec, plus fin et collaboratif, et utilisons Wazuh pour voir et comprendre.

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/crowdsec.log</location>
</localfile>

Les bannissements apparaissent alors dans la chronologie de Wazuh, à côté du reste. Le jour d'un incident, on lit l'histoire complète au même endroit : l'adresse a été bannie du serveur web à 2 h 14, mais une connexion SSH réussie était arrivée d'ailleurs à 2 h 09.

08Le quotidien, là où tout se joue

L'installation prend une journée. L'exploitation, elle, ne s'arrête jamais, et c'est là que la plupart des déploiements échouent : un Wazuh que personne ne regarde est une caméra qui filme une pièce vide.

1. Réglez le bruit dès la première semaine. Les premières alertes sont souvent des comportements normaux de votre parc. Chaque faux positif mérite une règle d'exception, sinon les vraies alertes se noient.
2. Envoyez seulement le critique sur les téléphones. Niveau 12 et plus dans Wazuh, par exemple, vers ntfy ou la messagerie de l'astreinte. Le reste se lit en revue.
3. Une revue hebdomadaire. Une demi-heure : bannissements inhabituels, vulnérabilités critiques nouvelles, modifications de fichiers inexpliquées.
4. Un rapport mensuel lisible. Combien d'attaques bloquées, quelles failles corrigées : c'est ce qui rend visible un travail qui, sinon, ne se voit pas.

09Les pièges classiques