Durcissement de serveur : par où commencer (CIS, ANSSI)

Durcir un serveur, c’est réduire la surface, dans le bon ordre

Le durcissement serveur Linux consiste à fermer tout ce qui n’a pas de raison d’être ouvert : services inutiles, accès trop larges, configurations par défaut permissives. Le principe est simple — ce que vous fermez ne peut plus être exploité — mais la mise en œuvre demande de la méthode. Foncer dans une checklist de 200 lignes sans plan, c’est le meilleur moyen de casser une application en production.

Deux référentiels font autorité : les benchmarks CIS (Center for Internet Security) et les recommandations de l’ANSSI. Voici par où commencer, dans l’ordre qui maximise la sécurité tout en minimisant le risque de casse.

Étape 0 : capturer une baseline avant de toucher à quoi que ce soit

Avant le premier changement, photographiez l’état actuel du serveur : services qui écoutent, comptes, tâches planifiées, règles de pare-feu, versions de paquets. Sans cette baseline, vous ne saurez pas ce que vous avez changé ni comment revenir en arrière. C’est aussi ce qui vous permettra, plus tard, de détecter la dérive de configuration.

Étape 1 : l’accès — SSH et comptes

C’est la porte d’entrée. Dans l’ordre :

SSH par clé uniquement, désactivation de l’authentification par mot de passe et du login root direct.
Revue des comptes : suppression des comptes inutilisés, principe du moindre privilège, sudo journalisé.
fail2ban ou CrowdSec pour bloquer les tentatives de force brute.

Testez votre accès par clé avant de couper le mot de passe — l’erreur classique est de se verrouiller dehors.

Étape 2 : le réseau — pare-feu et exposition

Pare-feu en deny par défaut (nftables) : on n’ouvre que les ports réellement nécessaires.
Minimisation des services : tout daemon qui écoute sans raison est arrêté et désactivé. Un ss -tulpn honnête révèle souvent des surprises.

Étape 3 : le noyau et le système

sysctl durci (protections réseau, ASLR, restrictions ptrace).
Mises à jour de sécurité automatisées et gouvernées — un serveur durci puis jamais patché redevient vulnérable en quelques semaines.
auditd activé pour journaliser les événements sensibles, idéalement complété d’un enregistrement de session (tlog) pour la traçabilité.

Étape 4 : les conteneurs, si vous en avez

Le daemon Docker est une surface souvent oubliée : socket exposé, conteneurs en root, capabilities trop larges. Durcir l’hôte sans durcir Docker laisse une faille béante.

Étape 5 : tenir la baseline dans le temps

Le durcissement n’est pas un coup unique. La configuration dérive : un correctif, un nouveau service, un changement manuel oublié. C’est pourquoi on surveille l’écart par rapport à la baseline et on remédie au fil de l’eau. Un durcissement appliqué une fois puis oublié pendant six mois ne vaut pas grand-chose.

FAQ

CIS ou ANSSI, lequel choisir ? Les deux sont complémentaires. On applique les benchmarks CIS et les recommandations ANSSI selon le contexte, et on documente chaque écart assumé.

Le durcissement risque-t-il de casser mes applications ? C’est le risque, d’où l’importance de tester en préproduction et de garder un rollback. Le but est de réduire la surface, pas de couper vos services.

Quelle différence avec un antivirus ou un EDR ? Le durcissement est de la prévention (réduire la surface) ; un EDR fait de la détection et de la réponse. Ils se complètent, ils ne se remplacent pas.

En résumé

Commencez par capturer une baseline, sécurisez l’accès, fermez le réseau, durcissez le noyau et les conteneurs, puis surveillez la dérive. Dans cet ordre, vous gagnez le plus de sécurité pour le moins de risque. Si vous préférez confier la passe et le suivi à une équipe — testés en préproduction, rapport avant/après à l’appui — notre service de durcissement de serveurs CIS/ANSSI le fait à forfait fixe par serveur, baseline figée et dérive surveillée incluses.