Durcissement de l'Infrastructure Linux pour Systèmes en APAC

La plupart des systèmes Linux en production fonctionnent bien plus près de leur configuration par défaut que quiconque ne veut l’admettre. Les documents de durcissement existent, souvent rédigés pour un audit il y a des années, mais les serveurs ne s’y conforment pas. C’est dans l’écart entre « socle documenté » et « configuration réelle » que les attaquants s’installent de façon fiable.

Le durcissement Linux est la discipline qui consiste à résorber cet écart, et à le faire d’une manière qui survit au déploiement suivant.

Les valeurs par défaut sont un point de départ, pas une posture #

Une installation Linux par défaut privilégie la compatibilité, pas la sécurité. Elle embarque des services que vous n’utilisez pas, des fonctions du noyau dont vous n’avez pas besoin et une journalisation suffisante pour un poste bureautique mais pas pour un hôte de production compromis. Le durcissement est le processus qui transforme cette machine généraliste en machine dédiée à un usage précis.

Le gros du travail se répartit en quelques catégories :

• Optimisation du noyau et sysctl : protections réseau (par exemple ignorer les redirections ICMP, activer le filtrage des routes source), restrictions du système de fichiers et protections mémoire comme la randomisation de l’espace d’adressage.
• Minimisation des services : désactiver et retirer ce que l’hôte ne fait pas tourner, pour qu’il n’y ait rien à exploiter qui ne soit utilisé.
• Contrôle d’accès obligatoire (MAC) : SELinux ou AppArmor pour contraindre ce qu’un processus peut faire, même compromis.
• Durcissement systemd et conteneurs : retrait des capabilities, blocage de l’accès aux raw sockets et restriction des syscalls par profils seccomp.
• Audit et journalisation : capturer les événements qui comptent, expédiés hors de l’hôte pour qu’un attaquant ne puisse effacer ses propres traces.

Les CIS Benchmarks demeurent la codification la plus pratique et largement reconnue de ces contrôles, et OpenSCAP automatise autant leur application que leur audit.

La configuration en tant que code, sinon elle n’existe pas #

Un guide de durcissement qui vit dans un wiki est une liste de vœux. Un durcissement qui vit dans le code (un rôle Ansible, une image Packer, une politique d’admission Kubernetes) est un fait. Quand le socle est du code, trois choses changent :

1. Il est reproductible. Chaque nouvel hôte hérite du socle, pas seulement ceux que quelqu’un a pensé à configurer.
2. Il est testable. Un scan de conformité dans CI fait échouer le build quand une configuration dérive.
3. Il est revisable. Une modification du socle est une pull request, avec la même discipline de revue que le code applicatif.

Voilà la différence entre le durcissement comme événement annuel et le durcissement comme propriété de la plateforme.

L’immuabilité comme état final #

La conclusion logique est l’infrastructure immuable : les hôtes et conteneurs ne sont jamais corrigés sur place, seulement remplacés. Une nouvelle image est construite, scannée et déployée ; l’ancienne est détruite. La dérive de configuration devient impossible parce qu’il n’y a rien qui puisse dériver : le système en exécution est un artefact de build.

L’infrastructure immuable se marie naturellement avec le durcissement en tant que code. Vous ne maintenez pas un socle ; vous compilez la sécurité dans l’image. Et quand une vulnérabilité apparaît, la solution est un rebuild, pas une session SSH à minuit.

Au-delà de l’hôte #

Le durcissement ne s’arrête pas au système d’exploitation. La même discipline s’étend vers l’extérieur dans plusieurs directions, chacune avec ses propres modes de défaillance.

Les conteneurs héritent de tout, puis ajoutent leurs propres risques. Une image conteneur construite sur une couche de base non durcie transporte chaque faiblesse de niveau hôte dans chaque pod qui l’exécute. La solution est en amont : images de base minimales, scannées en CI, exécutées en non-root avec systèmes de fichiers en lecture seule, capabilities retirées et profils seccomp restreignant les syscalls dont le workload a réellement besoin. Le profil seccomp par défaut bloque déjà beaucoup ; un profil taillé sur le comportement syscall observé bloque ce qui reste. Les politiques d’admission Kubernetes imposent tout cela à l’échelle de la flotte, si bien qu’un déploiement non conforme n’est jamais planifié du tout.

Les environnements OT relèvent les enjeux. Dans les contextes industriels et de technologie opérationnelle, le durcissement entre en collision avec la disponibilité comme l’informatique de bureau ne le voit jamais. Un contrôle CIS mal appliqué sur un système de gestion technique du bâtiment, un réseau PLC de ligne de production ou un segment d’appareils hospitaliers ne produit pas une constatation : il produit une interruption, parfois avec des conséquences de sécurité physique. Le durcissement OT inverse donc la séquence habituelle : supervision passive et inventaire d’abord, changements pendant des fenêtres de maintenance avec plans de retour arrière, et contrôles pilotés sur des miroirs de production avant de toucher quoi que ce soit de réel. Là où l’informatique demande « ce système est-il sûr ? », l’OT doit demander « pouvons-nous le sécuriser sans l’arrêter ? »

La détection de dérive ferme la boucle. Les socles se dégradent par changement routinier : un ingénieur ouvre un port pour déboguer, un installeur réactive un service, un correctif urgent ne revient jamais dans le code. Sans détection, l’hôte durci d’aujourd’hui est celui devenu mou de l’an prochain. Le schéma qui fonctionne : scans de configuration quotidiens comparant hôtes et images vivants au socle codifié, avec des constatations routées comme alertes vers leurs responsables plutôt que rangées dans un rapport trimestriel que personne ne lit. Une dérive détectée en un jour est un ticket ; détectée en un an, c’est une investigation d’incident.

Un hôte durci derrière un rôle IAM cloud trop permissif, ou dans un pipeline de conteneurs non scanné, reste exposé. La posture durable traite le socle des hôtes, la chaîne de build des conteneurs, la configuration cloud et les frontières d’identité comme une surface continue, supervisée comme telle.

Notre Durcissement Linux & Infrastructure livre des socles sous forme de code et une détection de dérive automatisée, et notre Évaluation de la Configuration et de l’Architecture passe en revue la couche cloud et identité autour de l’hôte. Pour une vision complète, planifiez une session d’ingénierie et de scoping.