Durcissement Linux et Windows par minimisation de surface

Durcir un système ne consiste pas à empiler des outils de sécurité jusqu’à ce que la supervision devienne un arbre de Noël. Il consiste à retirer les capacités inutiles, puis à contrôler explicitement celles qui restent. Le compromis central est brutal : on gagne des chemins d’attaque en moins, on paie une discipline d’exploitation plus stricte et des exceptions documentées.

→ Lire l’explication complète de la marmotte

Surface d’attaque : retirer avant de filtrer

La surface d’attaque est l’ensemble des interfaces par lesquelles un système accepte une action : ports réseau, services locaux, comptes, pilotes, interpréteurs, tâches planifiées, mécanismes d’administration et fichiers de configuration modifiables. Un service installé mais arrêté reste une dette : une mise à jour peut le réactiver, un administrateur peut le démarrer, ou une dépendance peut l’exposer. Le désinstaller est la décision correcte quand aucune fonction métier ne le justifie.

Le filtrage réseau ne remplace pas la suppression. Bloquer un service vulnérable par pare-feu réduit son exposition distante, mais laisse son code, ses bibliothèques et ses privilèges sur l’hôte. Une compromission locale, un mouvement latéral ou une erreur de règle suffit à rendre ce service atteignable. Ouvrir un port seulement depuis le réseau d’administration reste nécessaire, mais appeler cela une réduction de surface sans retirer le reste relève de la présentation PowerPoint.

L’inventaire doit distinguer quatre états :

installé et exposé ;
installé mais non exposé ;
installé mais désactivé ;
absent.

Seul le dernier état retire réellement une capacité. Sur Linux, recenser les paquets, unités systemd, sockets activables, règles sudo, tâches cron et services à l’écoute. Sur Windows, examiner rôles, fonctionnalités, services, pilotes, tâches planifiées, règles du pare-feu Windows Defender et partages. L’inventaire des identités et des protocoles d’authentification complète ce travail, notamment avec les recommandations de durcissement NTLM et de désactivation des binds LDAP en clair.

Une image système minimale est préférable à une installation généraliste nettoyée après coup. Sur Linux, partir d’une image serveur sans interface graphique, compilateur ni outils de diagnostic permanents. Sur Windows Server, installer uniquement les rôles requis et préférer Server Core lorsque les outils d’administration et l’application le supportent. Le gain est double : moins de code exécutable et moins de correctifs urgents. Le prix est connu : l’investigation locale devient moins confortable, ce qui impose des outils d’administration distants et des journaux exploitables.

Linux : services, privilèges et noyau

Sur Linux, systemd est un point de contrôle majeur. Désactiver une unité ne suffit pas toujours : une unité socket peut démarrer le service à la demande, une dépendance peut l’activer, et un paquet peut recréer sa configuration. Pour un service interdit par la politique d’architecture, masquer l’unité avec systemctl mask, désinstaller le paquet puis vérifier l’absence de socket associé. Les directives de confinement détaillées dans la page Systemd et durcissement des services doivent compléter cette suppression, pas la remplacer.

Le principe du moindre privilège impose de supprimer les démons exécutés en root lorsqu’un compte dédié suffit. Un service doit disposer d’un identifiant système sans shell interactif, de répertoires détenus par cet identifiant et de capacités Linux limitées. Les capacités découpent certains privilèges historiquement réservés à root, par exemple l’ouverture de ports inférieurs à 1024 avec CAP_NET_BIND_SERVICE. Elles réduisent l’impact d’une compromission, mais ne transforment pas un processus vulnérable en licorne blindée.

Le noyau doit refuser les comportements rarement nécessaires sur un serveur. Désactiver le transfert IP si l’hôte n’est pas routeur, les redirections ICMP (Internet Control Message Protocol), le chargement automatique de modules inutiles et les systèmes de fichiers non utilisés. Les montages temporaires doivent porter nodev, nosuid et, quand l’application le permet, noexec. Attention : noexec n’empêche pas l’exécution via un interpréteur lisant un fichier, comme python /tmp/payload.py. Il bloque un chemin, pas l’imagination humaine.

Les mécanismes Mandatory Access Control, c’est-à-dire contrôle d’accès obligatoire, comme SELinux (Security-Enhanced Linux) ou AppArmor, apportent une frontière supplémentaire entre un service compromis et le système. SELinux en mode permissif ne protège rien, il collecte des refus. Le mode enforcing est requis après une phase d’apprentissage bornée et revue. Une politique qui autorise tout pour faire disparaître les alertes est un pare-feu dessiné au feutre sur une porte coupe-feu.

Windows : rôles, identités et interfaces d’administration

Sous Windows, chaque rôle active des services, des règles de pare-feu, des fournisseurs d’authentification et parfois des composants web. Installer Internet Information Services (IIS) pour servir un seul endpoint ne justifie pas les modules d’administration, les exemples, WebDAV (Web Distributed Authoring and Versioning) ou les fonctionnalités de compatibilité non employées. La désinstallation doit viser les composants et non se limiter à arrêter les services.

Les services Windows nécessitent une revue de trois propriétés : compte d’exécution, privilèges et type de démarrage. Un service applicatif ne doit pas tourner sous LocalSystem par défaut. Ce compte possède des droits étendus sur l’hôte et un contexte machine exploitable sur le domaine. Utiliser un compte de service dédié, idéalement un gMSA (group Managed Service Account) lorsque l’application est intégrée à Active Directory, évite la gestion manuelle d’un mot de passe de service. Cela ne dispense pas de contrôler les droits locaux, les droits sur les partages et les délégations Kerberos.

Remote Desktop Protocol (RDP) doit être absent lorsqu’aucune administration graphique ne le requiert. S’il est nécessaire, imposer Network Level Authentication (NLA), restreindre l’accès à un bastion d’administration, désactiver la redirection de lecteurs et de presse-papiers selon le besoin, puis journaliser les ouvertures de session. L’exposition directe de RDP à Internet reste une mauvaise décision, même sous prétexte qu’un mot de passe compte vingt caractères et une rune elfique.

Windows Defender Application Control (WDAC) ou AppLocker réduit l’exécution de binaires, scripts et installateurs non autorisés. WDAC offre une frontière plus robuste car son contrôle intervient plus tôt dans le chargement du code ; AppLocker reste plus accessible mais dépend davantage de services système et de la couverture des règles. Le choix dépend de la capacité à signer les logiciels internes, à maintenir un catalogue d’applications autorisées et à gérer les exceptions. Sans cette gouvernance, une liste blanche devient vite une collection d’exceptions fossilisées.

Les macros Office, Windows Script Host et PowerShell doivent être limités selon les usages réels. La politique d’exécution PowerShell n’est pas une frontière de sécurité : elle se contourne et sert surtout à empêcher les accidents. La défense repose sur la restriction d’exécution, la journalisation Script Block, l’Antimalware Scan Interface (AMSI) et la limitation des privilèges. Ces contrôles détectent et freinent, ils ne garantissent pas qu’un administrateur compromis ne puisse pas exécuter du code signé ou autorisé.

Exemple reproductible : neutraliser un service Linux inutile

L’exemple suivant retire le serveur d’impression CUPS (Common Unix Printing System) d’un serveur Linux qui n’imprime pas. La commande est adaptée aux distributions Debian et Ubuntu. Avant exécution, valider qu’aucune application locale ne dépend de son socket ou de son interface d’administration.

# Vérifier si le service, le socket et le port d'administration existent.
systemctl status cups.service cups.socket --no-pager
ss -ltnp | grep ':631' || true

# Empêcher tout démarrage manuel ou indirect avant suppression.
sudo systemctl disable --now cups.service cups.socket
sudo systemctl mask cups.service cups.socket

# Retirer le code, les dépendances devenues orphelines et la configuration résiduelle.
sudo apt purge -y cups cups-daemon
sudo apt autoremove --purge -y

# La vérification attendue ne doit plus retourner ni unité ni écoute sur 631/TCP.
systemctl list-unit-files | grep -E '^cups' || true
ss -ltnp | grep ':631' || true

Le masquage avant purge est utile pendant la fenêtre d’intervention, mais il ne remplace pas la purge. Après mise à jour de l’image ou reconstruction de l’hôte, le contrôle doit vérifier l’état désiré automatiquement. Un durcissement appliqué une fois à la main est une décoration, pas un contrôle.

Attaques connues et contre-mesures opérationnelles

La minimisation de surface réduit surtout les opportunités de découverte et d’exploitation : balayage de ports, exploitation de services oubliés, élévation de privilèges via pilotes ou programmes setuid, mouvement latéral via protocoles historiques et persistance par tâche planifiée. Elle ne corrige pas une vulnérabilité dans le code métier ni un compte administrateur volé.

Les principaux échecs viennent d’une suppression partielle. Désactiver SMBv1 (Server Message Block version 1) est requis, mais conserver des partages anonymes ou des permissions trop larges sur SMBv3 conserve un chemin de mouvement latéral. Désinstaller Telnet ne protège pas une interface web d’administration exposée sans authentification forte. Retirer les compilateurs limite certains scénarios post-compromission, mais un attaquant peut déposer un binaire déjà compilé. Chaque contre-mesure doit viser une technique précise, jamais une impression de sécurité.

La journalisation doit couvrir les changements de service, l’installation de paquet ou de fonctionnalité, les élévations de privilèges, les ouvertures de session et les modifications de règles réseau. Les journaux locaux ne survivent pas nécessairement à une compromission administrateur. Expédier les événements vers une plateforme distincte, avec horodatage synchronisé et rétention définie, est indispensable. Les fondations d’architecture cybersécurité doivent prévoir cette collecte avant le durcissement, sinon le premier incident révélera que le serveur parfaitement fermé ne raconte rien.

Les sauvegardes doivent inclure les configurations de sécurité : politiques locales, règles de pare-feu, listes de paquets autorisés, unités systemd, stratégies Windows et certificats de service. Restaurer seulement les données sur un système reconstruit depuis une image de référence est préférable à restaurer un disque entier. Une restauration bloc à bloc réimporte aussi les comptes, tâches et binaires qui justifiaient l’incident. Le désastre aime les sauvegardes complètes, elles lui évitent de recommencer.

Exploitation : exceptions, correctifs et contrôle de dérive

Toute exception doit avoir un propriétaire, un motif, une date de révision et un test de présence. Un port temporaire sans échéance devient structurel avec la régularité d’une dette technique, c’est-à-dire très vite et avec beaucoup de conviction. L’exception doit être appliquée par configuration déclarative, versionnée et revue, jamais par une commande isolée dans un terminal.

Le patch management ne se négocie pas contre la minimisation de surface. Réduire les composants diminue le nombre de correctifs, mais les composants restants doivent être maintenus. Fixer des fenêtres de mise à jour, tester les mises à niveau du noyau, des pilotes et des agents de sécurité, puis vérifier le redémarrage réel des services concernés. Un binaire mis à jour en mémoire continue d’exécuter son ancienne version jusqu’au redémarrage.

Le contrôle de conformité doit comparer l’état observé à une base de référence : paquets autorisés, versions minimales, services actifs, ports écoutés, comptes locaux, droits d’administration et règles de filtrage. Les outils d’automatisation ne remplacent pas la revue architecturale : ils appliquent très efficacement une mauvaise liste si celle-ci est mauvaise. La configuration doit aussi être corrélée aux identités et à l’architecture réseau, car un compte privilégié sans restriction d’origine annule rapidement un durcissement local bien exécuté.

🐝 Ce qui arrive si on s’en passe

Sans minimisation de surface, l’hôte conserve toutes ses capacités par défaut et chaque installation devient une base de départ différente : deux serveurs censés être identiques divergent, et la comparaison à un état de référence n’a plus de sens. La charge de correctifs suit le nombre de composants présents, y compris ceux que personne n’utilise, ce qui allonge les fenêtres de mise à jour et rend les arbitrages de criticité ingérables. Le bruit d’exploitation augmente aussi : ports ouverts sans propriétaire, tâches planifiées héritées d’une image générique, comptes de service aux droits jamais justifiés. Lors d’une investigation, distinguer un binaire légitime d’un binaire déposé devient coûteux, faute de liste courte attendue. La reprise en pâtit : reconstruire depuis une image dont le contenu n’est pas défini reproduit la configuration qui a permis l’intrusion.

🦫 Explication de la marmotte 🍫

Durcir un ordinateur consiste à décider précisément ce qu’il doit faire, puis à retirer ou bloquer ce qui ne sert pas. On commence par inventorier les programmes installés, les services qui attendent des demandes sur le réseau, les comptes capables d’agir et les fonctions d’administration. Chaque élément absent ne peut pas être utilisé pour attaquer la machine.

Sur un système Linux, on retire les programmes inutiles, on limite les droits des services et on interdit certains comportements du système quand ils ne sont pas nécessaires. Un programme qui sert à publier un site web ne doit pas pouvoir modifier tous les fichiers ni devenir administrateur. Sur un système Windows, on installe seulement les fonctions nécessaires, on évite de faire tourner les services avec des droits très élevés et on restreint les programmes autorisés à se lancer.

Le filtrage du réseau complète ce travail : seuls les services attendus peuvent recevoir des connexions, depuis les endroits prévus. Mais bloquer un accès ne retire pas le programme concerné, donc il faut aussi le désinstaller quand il est inutile.

Le durcissement peut échouer si une mise à jour réactive une fonction, si une exception oubliée ouvre un accès, ou si un compte administrateur est volé. Il faut donc enregistrer les changements, envoyer les journaux sur une autre machine, vérifier régulièrement la configuration et reconstruire les systèmes depuis une base connue après un incident.

Pages voisines

La citent

Durcissement Linux et Windows par minimisation de surface

Elle cite

: les deux pages se citent l’une l’autre.

Durcissement Linux et Windows par minimisation de surface

Durcissement Linux et Windows par minimisation de surface

Surface d’attaque : retirer avant de filtrer

Linux : services, privilèges et noyau

Windows : rôles, identités et interfaces d’administration

Exemple reproductible : neutraliser un service Linux inutile

Attaques connues et contre-mesures opérationnelles

Exploitation : exceptions, correctifs et contrôle de dérive

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines