Hardening de Serveur Linux: CIS Benchmark Applique Sans Casser la Prod

Appliquer le CIS Benchmark complet d'un coup sur un Debian 12 qui sert 40 000 requetes par minute reste le moyen le plus rapide de transformer un vendredi en incident sev 1. Chez Basilisk, on a vu plus d'une equipe lancer le playbook ansible-lockdown brut en production et decouvrir a 3h du matin que le controle 5.2.16 avait desactive le compte qui orchestrait le backup Postgres. Le hardening serieux n'est pas copier 380 controles d'un PDF: c'est choisir les 60 qui valent le risque, les rejouer en staging sous la meme charge, et cabler la telemetrie pour savoir combien de minutes vous tenez avant impact client. Cet article est le runbook qu'on utilise sur de vrais engagements.

Pourquoi <em>tout d'un coup</em> echoue

Un PDF CIS Benchmark liste le Level 1 (conservateur) et le Level 2 (agressif) separement, mais la plupart des equipes aplatissent les deux en une seule liste de taches et les appliquent en une unique execution de gestion de configuration. Le probleme n'est aucun controle individuel, c'est la combinatoire: 380 changements simultanes signifient que lorsqu'une regression apparait, vous ne pouvez plus bissecter. Vous savez que quelque chose a casse, mais pas laquelle des 380 lignes. C'est exactement comme ca qu'on finit a 3h du matin en git revert de tout le playbook au lieu d'un correctif chirurgical.

Le second piege est le sophisme d'idempotence. Beaucoup de remediations CIS ne sont pas vraiment idempotentes quand l'etat de depart differe de ce que la tache suppose. Une tache qui reecrit /etc/pam.d/common-auth suppose un stack par defaut precis. Si l'hote a deja un module SSSD ou Kerberos, la nouvelle ligne se place dans le mauvais ordre et vous bloquez tout login federe. Le correctif est toujours le meme: petits lots, validation entre chaque lot, et un chemin de rollback documente avant d'ecrire la premiere ligne.

Les quatre buckets

Le point de depart correct consiste a separer les controles en quatre buckets avant de toucher au moindre serveur. Bucket 1: kernel et boot (sysctl, GRUB, modules), faible risque applicatif et gain eleve. Bucket 2: reseau et firewall (nftables, IPv6, ICMP), risque moyen si vous n'avez pas cartographie tous les ports. Bucket 3: authentification, PAM et SSH, ou se logent la plupart des incidents post-hardening. Bucket 4: auditd, syslog et integrite avec AIDE, risque operationnel quasi nul.

L'ordre est volontairement contre-intuitif: le 4 d'abord, puis le 1, puis le 2, et gardez SSH et PAM pour la fin. Vous commencez la ou rien ne peut casser (l'audit), collectez de la telemetrie sur le comportement normal, puis durcissez le kernel, puis le reseau, et ne touchez a la couche d'auth qu'une fois verifie un second canal d'acces (console, gestion out-of-band, une seconde cle SSH sur un port separe). Si vous reprenez SSH, lisez Durcissement SSH 2026 : Algorithmes, Certificats et Bastion Hosts avant d'editer sshd_config car les algorithmes ont change en 2026.

Inventorier l'etat actuel avec OpenSCAP

Pour inventorier l'etat actuel, utilisez openscap-scanner avec le profil xccdf_org.ssgproject.content_profile_cis_level2_server du projet ComplianceAsCode. Un appel reel ressemble a oscap xccdf eval --profile cis_level2_server --results scan.xml --report scan.html /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml. Sur un Ubuntu 24.04 propre vous verrez 110 a 140 controles en fail, c'est normal et pas une raison de paniquer.

Exportez le rapport HTML, importez-le dans Jira en une epic par bucket, et estimez l'effort en points de risque plutot qu'en heures. L'astuce est de ne jamais appliquer une remediation sans lire le rationale: la moitie des recommandations CIS Level 2 cassent des workloads modernes. Desactiver usb-storage a du sens sur un bastion, pas sur un hote qui ecrit des dumps chiffres sur cle USB pour un transfert air-gap regulatoire. Traitez le scan comme un document vivant: relancez-le apres chaque lot et suivez la progression comme une courbe, pas un instantane.

Couche kernel et sysctl

La couche kernel rapporte enormement avec peu de risque si vous savez ce que vous tunez. kernel.kptr_restrict=2, kernel.dmesg_restrict=1, kernel.yama.ptrace_scope=2 et fs.protected_hardlinks=1 sont gratuits contre les fuites locales d'information et les races de symlink. Ajoutez net.ipv4.conf.all.rp_filter=1, net.ipv4.tcp_syncookies=1 et kernel.randomize_va_space=2, et deposez tout dans un /etc/sysctl.d/60-cis.conf versionne plutot que dans le sysctl.conf principal pour qu'une mise a jour de paquet n'ecrase pas vos changements.

En revanche kernel.unprivileged_userns_clone=0 casse Docker rootless, Podman, Bubblewrap et tout sandbox applicatif, donc si vous lancez des conteneurs ou utilisez les techniques de Sandbox d Applications sous Linux avec Bubblewrap, Firejail et Flatpak, laissez-le a 1 et documentez l'ecart formellement. Au boot, ajoutez un GRUB protege par mot de passe (CIS 1.4.x), Secure Boot avec modules signes et le blacklist des modules de systeme de fichiers inutilises (cramfs, udf, usb-storage). Pour les services tres exposes, passez SELinux en enforcing avec une politique targeted custom, comme detaille dans SELinux Sans Peur: Politiques Personnalisees pour Services Critiques avec un Nginx public en exemple complet.

Reseau et firewall avec nftables

Avant d'ecrire une seule regle de firewall, cartographiez chaque port en ecoute avec ss -tulpen et reconciliez-le avec le service attendu. Un ruleset nftables aligne CIS fonctionne avec default drop sur input et forward plus une allowlist explicite. L'auto-blocage le plus frequent survient quand on oublie le trafic loopback: sans iif lo accept, les sockets locaux, les health checks et le loopback de la base s'effondrent, et l'appli renvoie des timeouts opaques.

IPv6 est le piege silencieux. Beaucoup d'equipes durcissent proprement IPv4 et laissent toute la pile IPv6 ouverte, supposant qu'elle n'est pas routee. Soit vous desactivez IPv6 de facon coherente (net.ipv6.conf.all.disable_ipv6=1 plus le bootloader), soit vous refletez chaque regle IPv4 sur la famille inet de nftables. La couverture a moitie est pire que rien car elle cree un faux sentiment de securite. Testez chaque changement de regle avec une seconde session ouverte comme filet.

Auditd sans l'inondation de logs

Auditd devient presque toujours un goulot d'etranglement si vous copiez le ruleset CIS sans reflechir. Les regles par defaut generent 8 a 15 mille evenements par minute sur un hote moyen, remplissent /var/log en six heures et forcent journald a commencer a dropper. La recette Basilisk consiste a couper les regles execve pour les comptes de service connus (postgres, nginx, app) et garder le monitoring agressif uniquement pour uid 0, sudo et shells interactifs.

Reglez -b 8192 pour le backlog, --backlog_wait_time 0 contre les stalls kernel, et envoyez via audisp-remote ou un plugin auditd vers un pipeline Sigma comme decrit dans Threat Hunting avec Sigma et Elastic: De l'Indicateur a la Regle de Detection. Sinon vous fabriquez du bruit cher sans aucune detection actionnable cote consommateur. Mettez -e 2 (regles immuables) tout a la fin seulement, car cela verrouille tout changement de regle jusqu'au prochain reboot.

Un point souvent oublie: auditd et un logging execve complet coutent du CPU mesurable sur les services intensifs en syscalls. Sur un reverse proxy faisant des dizaines d'appels connect et openat par requete, un ruleset trop large peut ajouter 5 a 10 pour cent de latence p95. Mesurez-le explicitement dans le test de charge staging et traitez les regles d'audit comme partie du budget de performance, pas comme un extra gratuit. La bonne metrique n'est pas le nombre de regles, c'est les evenements par seconde en operation normale.

Validation sous charge reelle

La validation est ce que personne ne fait correctement. Montez un environnement miroir en LXD ou Proxmox avec le meme kernel, la meme glibc et les memes versions de services, puis rejouez 30 minutes de trafic reel capture par tcpdump avec k6 ou wrk. Appliquez les controles par lots de dix, relancez le test, comparez le p95 de latence et le taux d'erreur. Si la regression depasse 3% vous isolez par bissection quel controle est coupable.

Lancez aussi atomic-red-team avec des techniques mappees a MITRE ATT&CK pour confirmer que le hardening reduit vraiment la surface: la logique est celle de Adversary Emulation avec Caldera et MITRE ATT&CK en Lab d'Entreprise, mais ciblee sur la post-exploitation de l'hote durci. Si une technique reussit encore apres le hardening, vous avez un ecart mesurable au lieu d'une supposition.

Crypto disque et acces physique

Pour les serveurs qui touchent des donnees sensibles ou inaccessibles physiquement, completez le hardening avec un chiffrement disque resistant a la coercition et des backups verifies, selon la demarche de Crypto de Disque et Sauvegardes: VeraCrypt, LUKS et Strategie 3-2-1 Resiliente. LUKS2 avec Argon2id, cle scellee dans le TPM2 liee a PCR0+PCR7 et snapshot chiffre en stockage offsite resolvent le vol physique au datacenter.

Combine avec Secure Boot, modules signes et GRUB protege par mot de passe (controles CIS 1.4.x), vous portez le cout d'une attaque presentielle a un niveau rentable seulement contre des cibles tres specifiques. Un avertissement: une cle scellee dans le TPM sans passphrase de recuperation testee est une bombe a retardement. Le jour ou une mise a jour de firmware change les valeurs PCR, la machine ne boote plus, et sans passphrase stockee le disque est un dechet de donnees.

Checklist pratique

Avant de declarer un hote durci comme termine: (1) score OpenSCAP documente avant et apres; (2) un second chemin d'acces (console/OOB) verifie avant de toucher SSH; (3) tous les changements sysctl versionnes dans /etc/sysctl.d/; (4) nftables avec iif lo accept et comportement IPv6 teste; (5) auditd sous 3000 evenements par minute au repos; (6) test de charge staging avec moins de 3% de regression p95; (7) une execution atomic-red-team qui prouve les techniques fermees; (8) un chemin de rollback documente et repete une fois.

FAQ : Level 1 ou Level 2 ?

Pour des serveurs exposes a internet sans mandat strict de conformite, le Level 1 complet plus des controles selectionnes du Level 2 des buckets 1 et 4 est le meilleur point cout-benefice. Le Level 2 complet a du sens pour des workloads regules (PCI-DSS, exigences gouvernementales), mais seulement avec un registre d'exceptions documente pour les controles qui cassent votre workload specifique. Un Level 2 aveugle sur un hote de conteneurs est une panne avec certificat joint.

FAQ : a quelle frequence rescanner ? A chaque release majeure de l'OS (point release Debian, upgrade LTS) et au moins trimestriellement en scan automatise par cron dont le resultat alimente les memes dashboards que vos metriques. La derive est inevitable car les upgrades de paquet reinitialisent les defauts sysctl et les nouveaux services ouvrent de nouveaux ports.

FAQ : Ansible, script Bash ou baking d'image ? Pour une flotte, une golden image durcie (Packer plus la liste de controles revue, deployee de facon immuable) est plus robuste qu'une execution Ansible contre des hotes vivants, car la derive disparait quasiment. Ansible reste bon pour le premier cycle iteratif et pour les hotes qu'on ne peut pas reconstruire. Un pur script Bash sans idempotence est la pire option: il ne peut ni etre rejoue proprement ni annule de facon fiable. Quoi que vous choisissiez, la liste de controles elle-meme doit etre versionnee et revisable, pas enterree dans un wiki de runbook.

Takeaway pratique: tenez un tableur listant chaque controle CIS applique, la version du paquet au moment T, le resultat openscap avant/apres et le delta de latence mesure en staging. Rejouez ce tableur a chaque release majeure de l'OS parce que les defauts sysctl bougent et auditd ajoute des champs. Le hardening n'est pas un projet, c'est un processus: si dans six mois vous ne pouvez pas prouver par scan automatise que ces 60 controles sont toujours actifs sur l'hote, vous n'avez pas de hardening, vous avez de la foi.