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.

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. Faites le 4 d'abord, puis le 1, puis le 2, et gardez SSH et PAM pour la fin. 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.

Pour inventorier l'etat actuel, utilisez openscap-scanner avec le profil xccdf_org.ssgproject.content_profile_cis_level2_server du projet ComplianceAsCode. Sur un Ubuntu 24.04 propre vous verrez 110 a 140 controles en fail, c'est normal. 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.

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. 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. 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.

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.

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. Envoyez via auditd-plugin 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.

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.

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 (point release Debian, upgrade LTS) 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.