Durcissement Système (Hardening) : Appliquer le guide de l’ANSSI pour sécuriser un serveur Linux en production

Pourquoi le durcissement (hardening) est indispensable en production

Un serveur Linux en production peut « marcher » pendant des années. Les services répondent, la charge tient, les déploiements passent. Et pourtant, il peut être franchement pas sûr.

La différence tient à un truc simple mais souvent ignoré : la surface d’attaque. Un serveur qui fonctionne accepte souvent trop de choses par défaut. Trop de paquets installés « au cas où ». Trop de ports en écoute. Trop de droits. Et, surtout, trop d’opérations manuelles faites dans l’urgence. La prod, c’est le royaume du compromis. Donc des erreurs humaines. Donc des failles.

Les risques typiques en prod Linux, on les voit partout :

• Élévation de privilèges après une première compromission (un service exposé, une mauvaise conf, une CVE).
• Mouvements latéraux : le serveur A sert de tremplin vers B, puis C, puis l’AD, puis le stockage.
• Ransomware : chiffrement, suppression des snapshots, sabotage des sauvegardes.
• Exfiltration : données clients, secrets applicatifs, clés API, dumps de base, journaux.

Le guide de l’ANSSI est utile parce qu’il pose une base pragmatique. Pas une liste magique de 400 options kernel à activer. Plutôt une approche « défense en profondeur », avec priorisation et logique. On réduit l’exposition, on limite les privilèges, on augmente la traçabilité, et on garde une configuration maîtrisée.

L’objectif de cet article, c’est ça : traduire l’esprit du guide en plan d’action concrète, vérifiable, et applicable sur un serveur Linux en production sans tout casser.

Ce que dit (vraiment) l’ANSSI : philosophie et périmètre du guide

Le guide ANSSI, si on le résume sans le trahir, repose sur quelques principes qui reviennent tout le temps :

• Réduction d’exposition : moins de services, moins d’entrées, moins de bavardage réseau.
• Moindre privilège : chaque compte, chaque service, chaque processus a juste ce qu’il faut. Pas plus.
• Traçabilité : savoir qui a fait quoi, quand, et depuis où. Et pouvoir le prouver.
• Configuration maîtrisée : éviter les réglages « à la main » non documentés. Reproductible, versionné.

Le périmètre n’est pas seulement l’OS. Ça couvre : le système, les services, le réseau, les comptes, la journalisation, les mises à jour, et la supervision. En clair, tout ce qui fait qu’un serveur ne devient pas un angle mort.

Avant de commencer, il y a des prérequis très terre à terre, mais indispensables :

• Un inventaire minimum.
• Un accès console ou ILO, IPMI, KVM, ou équivalent. Parce que quand SSH ne répond plus, il faut une porte de secours.
• Une fenêtre de maintenance, même courte, même fractionnée.
• Un plan de rollback : snapshot, sauvegarde, ou au moins un moyen de revenir en arrière rapidement.

Et il y a la notion de niveau, de priorité. Le bon réflexe : commencer par les mesures à fort impact et faible risque. Exemple : désactiver un service inutile, activer un pare-feu simple, renforcer SSH. Pas besoin de tout faire en une nuit.

Avant de durcir : cadrer le contexte (inventaire, menace, criticité)

Avant de « sécuriser », il faut savoir ce qu’on sécurise. Et contre qui. Sinon on applique des recettes, on se félicite, et on passe à côté.

Ce qu’il faut documenter, au minimum :

• Distribution et version (Debian 12, Ubuntu 22.04, Rocky 9, etc.).
• Rôle du serveur : web, API, base de données, bastion, worker, monitoring, etc.
• Flux réseau attendus : entrants, sortants, inter-systèmes.
• Comptes et usages : qui administre, qui déploie, quels comptes de service existent.
• Dépendances : NFS, LDAP, S3, Redis, cluster, outils de sauvegarde, agents divers.

Ensuite, l’exposition réelle : Internet ou intranet ? Accès admin via VPN ou ouvert au monde ? Présence d’EDR, de supervision, d’un outil de backup, d’un agent SIEM ? Tout ça change les choix, et parfois les contraintes.

Construisez un modèle de menace simple. Pas un roman. Juste :

• Qui attaque ? opportuniste Internet, concurrent, insider, prestataire, groupe ransomware.
• Comment ? brute force SSH, CVE web, vol de clé, supply chain, phishing puis rebond.
• Impact métier ? arrêt de service, fuite de données, fraude, perte d’intégrité, atteinte image.

Et fixez des critères de succès. Des choses testables, pas des intentions :

• Une check-list de fin.
• Des preuves : extraits de configuration, commandes de validation, résultats de scan.
• Des tests de non régression applicative : endpoints, jobs, accès base, déploiement CI/CD.

1) Réduire la surface d’attaque : services, paquets, ports

Règle de base : tout ce qui n’est pas nécessaire est supprimé ou désactivé. Sinon, tôt ou tard, ça sera exploité.

Commencez par auditer ce qui tourne réellement.

Commandes utiles :

bash systemctl list-units --type=service --state=running systemctl list-sockets ss -lntup

Regardez les ports en écoute, et demandez-vous pour chacun : « qui s’y connecte, depuis où, et pourquoi ? »

Ensuite, désinstallez les paquets inutiles. C’est moins glamour que « durcir le kernel », mais souvent plus efficace. Moins de code, moins de CVE, moins d’angles morts.

• Retirer les outils legacy et les démons installés par défaut si inutiles.
• Limiter les dépôts. Sur un serveur prod, multiplier les sources, c’est multiplier les surprises.
• Éviter les compilations à la main dans /usr/local sans suivi. Si vous le faites, documentez. Vraiment.

Désactivez les services non requis. Exemples fréquents selon contexte : avahi, cups, rpcbind, bluetooth, postfix si non utilisé, serveurs de découverte réseau.

bash systemctl disable --now avahi-daemon 2>/dev/null || true systemctl disable --now cups 2>/dev/null || true systemctl disable --now rpcbind 2>/dev/null || true

Puis, pare-feu « deny by default ». C’est un pivot. Vous bloquez tout, vous ouvrez uniquement ce qui est nécessaire.

Selon distro et habitudes : nftables, ufw, firewalld. Peu importe l’outil, ce qui compte c’est la clarté et la cohérence.

Validation : test applicatif + scan de ports avant après.

bash nmap -sS -sV -p- <ip_du_serveur>

Ce scan, gardez-le. C’est une preuve, et c’est un point de comparaison pour les prochains changements.

2) Comptes, authentification et privilèges : appliquer le « moindre privilège »

Les comptes partagés, c’est pratique. Jusqu’au jour où il faut comprendre qui a fait une action. Ou révoquer un accès. Ou enquêter.

En prod, essayez de clarifier « qui fait quoi » :

• Admin système.
• Exploitation (run, incidents, redémarrages).
• Applicatif (déploiement, logs).
• Comptes de service (non interactifs).

Sudo doit être minimal, et traçable. Évitez le réflexe du grand fourre-tout : « ALL=(ALL) ALL ». Si vous ne pouvez pas tout granulariser d’un coup, faites au moins ça : restreindre, journaliser, et supprimer les exceptions dangereuses.

• NOPASSWD
• Activer la journalisation de sudo et l’envoyer en centralisation.

SSH : privilégier les clés plutôt que les mots de passe. Et protéger les clés côté client : passphrase, agent, stockage sécurisé. Une clé sans passphrase qui traîne sur un laptop, c’est une bombe à retardement.

Verrouillez ou expirez les comptes inutilisés. Supprimez les shells interactifs pour les comptes de service.

bash usermod -s /usr/sbin/nologin <compte_service> passwd -l <compte_inutile> chage -E 0 <compte_inutile>

/etc/shadow

3) Sécuriser SSH (le point d’entrée le plus courant)

Sur beaucoup de serveurs, SSH est la porte principale. Donc on le traite comme une entrée Internet, même s’il est « juste interne ». Les mouvements latéraux commencent souvent comme ça.

Côté serveur, base saine :

• Protocole 2 (c’est déjà la norme, mais autant être explicite).
• Désactiver l’auth par mot de passe si possible.
• Interdire root direct en SSH.
• Réduire les algorithmes faibles si votre parc le permet.

/etc/ssh/sshd_config

conf Protocol 2 PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes

ListenAddress

Protection brute force : fail2ban ou équivalent. Ce n’est pas une solution miracle, mais ça coupe le bruit et ça réduit les risques opportunistes.

MFA : possible via PAM + TOTP, ou plus simplement via un bastion avec MFA (souvent plus réaliste en prod). Le bastion devient le point de contrôle.

Et surtout, testez la compatibilité des automates avant de couper le mot de passe. Ansible, CI/CD, scripts legacy. Faites un inventaire, migrez vers des clés dédiées, puis basculez.

4) Mises à jour et gestion des vulnérabilités : durcir, c’est maintenir

Le hardening sans maintenance, c’est du décor. Un serveur « durci » mais non patché redeviendra vulnérable très vite.

Mettez en place un processus de patch management :

• Une cadence (hebdo, bimensuelle, mensuelle).
• Un cycle de validation (préprod si possible).
• Une fenêtre de maintenance.
• Un plan de reboot. Parce que kernel et bibliothèques critiques, ça demande parfois un redémarrage.

Les mises à jour de sécurité automatiques peuvent aider, selon distribution et tolérance au risque. Mais avec garde-fous : redémarrages planifiés, monitoring, et communication. L’automatique qui reboote à 14 h, c’est non.

Surveillez les annonces de sécurité (distro, upstream). Priorisez les CVE exploitées. Pas toutes les CVE.

Ajoutez un scan régulier : OpenVAS, Greenbone, ou un outil plus léger comme Lynis pour la configuration.

bash lynis audit system

Et évitez la dérive de configuration : dépôts maîtrisés, pinning raisonnable si nécessaire, images « golden » si vous êtes dans une logique d’industrialisation.

5) Configuration système : noyau, sysctl et protections mémoire

Les réglages sysctl utiles existent, mais l’important c’est de rester lisible et testé. Un fichier sysctl incompréhensible, c’est une dette.

Quelques réglages fréquents, dans l’esprit ANSSI :

• Durcissement réseau (anti spoofing, redirections).
• Réduction de fuite d’infos kernel.
• Restrictions sur ptrace et dmesg.

/etc/sysctl.d/99-hardening.conf

conf net.ipv4.conf.all.rp_filter=1 net.ipv4.conf.default.rp_filter=1 net.ipv4.conf.all.accept_redirects=0 net.ipv4.conf.default.accept_redirects=0 kernel.dmesg_restrict=1 kernel.kptr_restrict=2 kernel.yama.ptrace_scope=1 kernel.randomize_va_space=2

/tmp/var/tmp/dev/shm

Attention, certains réglages impactent le debugging, le monitoring, ou des applis legacy. Documentez chaque changement, et testez. Un durcissement qui coupe l’observabilité, c’est un mauvais durcissement.

6) Système de fichiers et permissions : verrouiller ce qui compte

C’est souvent là que les compromissions s’installent. Un répertoire world writable, une clé privée lisible, un SUID oublié.

/tmp/var/tmp/dev/shm

• nodev
• nosuid
• noexec

/etc/fstab

fstab tmpfs /dev/shm tmpfs defaults,nodev,nosuid,noexec 0 0

/etc/var/log

Audit SUID/SGID :

bash find / -xdev -perm -4000 -type f 2>/dev/null find / -xdev -perm -2000 -type f 2>/dev/null

L’objectif n’est pas de tout supprimer aveuglément. Mais d’identifier ce qui est non nécessaire sur ce serveur précis.

Fixez une umask adaptée (souvent 027 ou 077 selon contexte) et contrôlez les ACL si vous en utilisez. Les ACL, c’est puissant, mais ça peut aussi cacher des droits inattendus.

Chiffrement : LUKS est pertinent pour les données au repos, surtout si risque de vol de disque, d’accès physique, ou environnements mutualisés. Mais en prod, la gestion de clé est le vrai sujet : déverrouillage au boot, HSM, TPM, procédure d’urgence. Ne le faites pas « juste pour cocher une case ».

7) Réseau : filtrage, segmentation et exposition minimale

Le pare-feu local, c’est votre dernière barrière quand le réseau amont est mal configuré. Gardez des règles simples, lisibles, versionnées. Oui, dans Git si possible.

Segmentation : isolez les rôles. Une base de données ne devrait pas accepter des connexions depuis n’importe quel subnet. Un serveur admin ne devrait pas parler à tout.

Désactivez les services et ports non utilisés, limitez l’ICMP si nécessaire, et évitez les réponses trop bavardes. Mais attention : casser complètement ICMP peut casser la PMTUD et créer des bugs réseau pénibles. Allez-y finement.

Sécurisez DNS et NTP. Utilisez des sources fiables. Évitez les résolveurs ouverts. Sur un serveur, la résolution DNS est un composant de sécurité, pas un détail.

Contrôle egress (sortant) : plus mature, mais très efficace contre l’exfiltration et le C2. Même sans tout bloquer, vous pouvez déjà limiter : seulement DNS vers vos resolvers, NTP vers vos serveurs, HTTP(S) sortant uniquement vers des dépôts connus, etc. À faire progressivement, sinon ça casse des choses « invisibles ».

8) Journalisation, audit et traçabilité : pouvoir enquêter vite

Sans logs, vous êtes aveugle. Et le jour d’un incident, ça devient très concret.

Objectifs : détection, investigation, conformité, preuves. Ça implique :

• Rétention et rotation.
• Permissions correctes.
• Horodatage fiable (NTP).
• Centralisation.

Côté journald rsyslog : configurez la rétention, évitez que /var explose, protégez l’accès. Et surtout, centralisez vers un SIEM, ELK, Wazuh, ou même un syslog distant. L’idée : ne pas perdre les traces si la machine est compromise.

Auditd : utile pour tracer des actions sensibles. Pas besoin de tout auditer. Visez :

• Actions sudo.
• /etc
• Accès à des fichiers clés (selon contexte).
• Changements de comptes, groupes, clés SSH.

Alertes basiques mais utiles :

• Connexions SSH suspectes (pays, IP rares, échecs massifs).
• Ajout d’un utilisateur au groupe sudo.
• sshd_config
• Redémarrage inattendu de services critiques.
• Pic de logs d’authentification.

9) Contrôles d’accès renforcés : SELinux AppArmor et confinement

Le contrôle d’accès obligatoire (MAC), c’est un gros morceau. Mais c’est aussi un des meilleurs moyens de limiter l’impact d’une faille applicative. Si votre service web se fait exploiter, MAC peut empêcher l’accès à des fichiers, empêcher des exec, limiter les dégâts.

Choix selon distro :

• SELinux : RHEL, CentOS, Alma, Rocky.
• AppArmor : Ubuntu, Debian (souvent plus simple à démarrer).

Le bon déploiement, c’est progressif. D’abord en mode observation (permissive ou complain), on collecte, on corrige, puis on renforce en enforcing.

NoNewPrivilegesPrivateTmpProtectSystemProtectHomeRestrictAddressFamilies

Isolation quand possible : containers, VM, comptes dédiés, et parfois chroot pour des cas spécifiques. Ce n’est pas une obligation, mais c’est une stratégie de réduction de blast radius.

10) Sauvegardes et reprise : la sécurité qui sauve vraiment le jour J

Le hardening ne remplace pas une stratégie de sauvegarde. Et en ransomware, ce n’est pas le firewall qui vous sauve. C’est la restauration.

Mettez en place la règle 3-2-1 :

• 3 copies des données.
• 2 supports différents.
• 1 copie hors site, et si possible offline ou immuable.

Testez les restaurations. Pas juste « backup succeeded ». Testez un vrai restore, mesurez RTO et RPO. Faites-le régulièrement, sinon le jour où vous en avez besoin, ça ne marche pas. Classique.

Protégez les identifiants et clés de sauvegarde. Le compte backup ne doit pas avoir des droits d’admin partout. Limitez, segmentez, et surveillez.

Surveillez aussi : échecs, volumes anormaux, suppression suspecte, changements de politique de rétention.

Comment appliquer tout ça sans casser la prod : méthode en 5 étapes

Une méthode réaliste, qui tient en prod, ressemble à ça.

Étape 1 : baseline et mesures rapides

Inventaire, scan de ports, sauvegarde d’état. Puis : suppression de services inutiles, SSH renforcé, pare-feu minimal. Vous gagnez déjà beaucoup.

Étape 2 : durcissement progressif

Sysctl, options de montage, permissions, revue SUID SGID. Un lot à la fois. Tests applicatifs à chaque lot. Si vous ne testez pas, vous faites de la sécurité théorique.

Étape 3 : traçabilité et supervision

Centralisation logs, auditd, alertes essentielles, NTP fiable. Vous rendez le serveur « enquêtables ». Ce mot existe pas, mais vous voyez l’idée.

Étape 4 : confinement

SELinux ou AppArmor, puis durcissement systemd service par service. D’abord observation, puis enforcement.

Étape 5 : industrialisation

Ansible, scripts, images, baseline de configuration. Revue périodique. Versionnez la config. Écrivez un changelog. Prévoyez rollback et fenêtre à chaque changement. Ça paraît lourd. Mais c’est ça qui évite les nuits blanches.

Checklist finale (résumé actionnable) pour un serveur Linux durci selon l’esprit ANSSI

Checklist courte, vérifiable.

• Ports ouverts minimaux (scan nmap avant après, archivé).
• Pare-feu actif en « deny by default » et règles documentées.
• PermitRootLogin noPasswordAuthentication no
• Comptes : pas de comptes partagés, comptes inutilisés verrouillés, comptes de service sans shell interactif.
• NOPASSWD
• Mises à jour : processus de patch, suivi des paquets critiques, reboots planifiés.
• sysctl -a | grep ...
• /tmp /var/tmp /dev/shm
• Permissions revues sur secrets et configs, audit SUID SGID fait et justifié.
• Logs : rotation, rétention, NTP OK, centralisation vers un système externe.
• Audit : auditd actif sur actions sensibles, alertes basiques en place.
• MAC : SELinux ou AppArmor déployé progressivement, idéalement en enforcing sur les services exposés.
• Backups : règle 3-2-1, restauration testée, droits du compte backup limités.

Preuves attendues, concrètes :

• /etc/ssh/sshd_config/etc/sudoers.d/*/etc/sysctl.d/*/etc/fstab
• ss -lntupsystemctl --type=service --state=runningnmap
• Rapports Lynis, scans vulnérabilité, tickets de remédiation associés.
• Logs centralisés visibles côté SIEM, et exemples d’alertes.

Rythme de revue conseillé :

• Mensuel : patchs, scan, vérification services exposés.
• Trimestriel : droits, comptes, clés SSH, règles pare-feu.
• Annuel : modèle de menace, architecture, segmentation, stratégie de reprise.

Conclusion simple : le hardening, c’est un processus continu. Pas une configuration magique qu’on applique une fois puis qu’on oublie. Et le guide ANSSI, au fond, pousse exactement ça : réduire, limiter, tracer, maintenir. Puis recommencer.

Questions fréquemment posées

Pourquoi le durcissement (hardening) est-il indispensable pour un serveur Linux en production ?

Le durcissement est essentiel car un serveur Linux peut fonctionner longtemps sans problème apparent tout en étant vulnérable. Sans durcissement, la surface d'attaque est trop large : services inutiles actifs, ports ouverts, droits excessifs et opérations manuelles non maîtrisées augmentent les risques d'élévation de privilèges, mouvements latéraux, ransomware ou exfiltration de données.

Quels sont les principes clés du guide ANSSI pour le durcissement des serveurs Linux ?

Le guide ANSSI repose sur quatre principes fondamentaux : réduction d'exposition (moins de services et de points d'entrée), moindre privilège (chaque compte/service/processus a juste ce qu'il faut), traçabilité (savoir qui fait quoi, quand et où), et configuration maîtrisée (réglages reproductibles et versionnés).

Quels prérequis doivent être réunis avant de commencer le durcissement d’un serveur Linux ?

Avant de durcir un serveur, il faut disposer d’un inventaire minimal, d’un accès console ou équivalent (ILO, IPMI, KVM) pour ne pas dépendre uniquement de SSH, planifier une fenêtre de maintenance même courte, et prévoir un plan de rollback via snapshot ou sauvegarde pour revenir en arrière rapidement si besoin.

Comment cadrer le contexte avant de sécuriser un serveur Linux en production ?

Il faut documenter la distribution et sa version, le rôle précis du serveur (web, base de données…), les flux réseau attendus, les comptes utilisateurs et services existants ainsi que leurs usages, les dépendances techniques. Il est aussi important d’identifier l’exposition réelle (Internet ou intranet) et les outils déjà en place (VPN, EDR, SIEM).

Quelle approche adopter pour prioriser les mesures de durcissement selon le guide ANSSI ?

La priorité est donnée aux mesures à fort impact et faible risque : désactiver les services inutiles, activer un pare-feu simple, renforcer la sécurité SSH. Il n’est pas nécessaire de tout faire en une seule fois ; il vaut mieux avancer progressivement avec des actions vérifiables et maîtrisées.

Quels sont les risques typiques auxquels un serveur Linux en production non durci peut être exposé ?

Les risques courants incluent l’élévation de privilèges suite à une compromission initiale (via service exposé ou vulnérabilité), les mouvements latéraux permettant à un attaquant d’accéder à plusieurs systèmes critiques, les attaques par ransomware ciblant chiffrement et sabotage des sauvegardes, ainsi que l’exfiltration de données sensibles comme secrets applicatifs ou bases.