Skip to content
Durcissement système et OS hardening : sécuriser vos serveurs

Durcissement système et OS hardening : sécuriser vos serveurs

CE QU’IL FAUT RETENIR

Le durcissement système (OS hardening) constitue le socle technique indispensable pour neutraliser 80 % des vecteurs d’attaque élémentaires ciblant les infrastructures Linux et Windows. Cette démarche abaisse le niveau de risque opérationnel en fermant les accès superflus tout en verrouillant la configuration d’usine des machines.

  • Réduction de 70 % des services réseau non essentiels installés par défaut afin de supprimer les portes d’entrée non surveillées.
  • Alignement recommandé sur les référentiels officiels de l’ANSSI (niveaux élémentaire à renforcé) et du CIS (Benchmarks Level 1 et 2).
  • Mise en œuvre systématique du principe du moindre privilège, du contrôle d’accès obligatoire (SELinux ou AppArmor) et de la journalisation centralisée.

L’efficacité d’un projet de hardening repose sur un arbitrage permanent entre le niveau de protection ciblé et le maintien de la compatibilité applicative des serveurs en production.

Qu’est-ce que le durcissement système (OS hardening) ?

Le durcissement système, ou OS hardening, rassemble l’ensemble des techniques visant à sécuriser un système d’exploitation en réduisant sa surface d’attaque. Cette opération consiste à corriger les configurations par défaut, supprimer les composants inutiles et restreindre les autorisations au strict nécessaire.

Par défaut, la majorité des distributions Linux et des éditions Windows Server sont livrées avec des paramètres orientés vers la simplicité d’usage plutôt que la sécurité. Le durcissement transforme ces installations génériques en environnements étanches, capables de résister aux tentatives d’intrusion directes et au mouvement latéral au sein d’un réseau interne.

Les principes fondamentaux : minimisation, moindre privilège et défense en profondeur

La règle de minimisation impose de supprimer tout logiciel, bibliothèque ou service réseau qui n’est pas indispensable au fonctionnement de l’application hébergée. Moins un système contient de lignes de code et de services actifs, moins il présente de vulnérabilités exploitables.

Le principe du moindre privilège garantit que chaque utilisateur, processus ou service ne dispose que des autorisations strictement nécessaires à l’accomplissement de sa tâche. L’attribution des droits d’administration doit demeurer exceptionnelle, temporaire et strictement traçable.

La défense en profondeur complète ce dispositif en superposant plusieurs barrières de sécurité indépendantes. Si un attaquant parvient à contourner un premier niveau de contrôle, les couches sous-jacentes bloquent son progression.

Pourquoi le durcissement des systèmes d’exploitation est-il indispensable ?

Les cyberattaques modernes exploitent en priorité les erreurs de configuration et les services laissés à l’abandon sur des serveurs exposés. Sans durcissement préalable, un système connecté reste vulnérable à des attaques automatisées quelques minutes seulement après sa mise en ligne.

  • Neutralisation des identifiants par défaut : blocage des accès d’usine et suppression des comptes de démonstration souvent ciblés par les attaques par force brute.
  • Confinement des intrusions : limitation du périmètre d’action d’un logiciel malveillant en cas de compromission d’un service applicatif.
  • Respect des exigences de conformité : alignement obligatoire avec les normes réglementaires sectorielles telles que PCI-DSS v4.0, le RGPD ou la directive européenne NIS 2.
  • Réduction des coûts de maintenance : diminution du volume de correctifs d’urgence à appliquer en éliminant les logiciels inutilisés.

Les référentiels de sécurité : ANSSI et CIS Benchmarks

Pour mener un projet de durcissement sans repartir de zéro, les équipes d’administration s’appuient sur des standards internationaux reconnus. Selon l’Agence nationale de la sécurité des systèmes d’information (ANSSI), l’application méthodique de leurs guides de bonnes pratiques permet de bloquer la quasi-totalité des attaques ciblant les configurations d’origine.

Le Center for Internet Security (CIS) publie également des guides ultra-détaillés appelés CIS Benchmarks, mis à jour continuellement pour l’ensemble des systèmes d’exploitation du marché. Ces documents définissent des paramètres précis, testés et mesurables.

Référentiel Organisme éditeur Public et contexte d’usage Niveaux de recommandation
Guide de recommandations ANSSI ANSSI (France) Administrations publiques et entreprises européennes Niveaux Minima, Intermédiaire, Renforcé et Haut
CIS Benchmarks Center for Internet Security (USA) Secteur privé international et OIV Level 1 (pratique) et Level 2 (haute sécurité)
NIST SP 800-123 NIST (USA) Organisations gouvernementales et fédérales Cadre général de sécurisation des serveurs
DISA STIG Ministère de la Défense (USA) Infrastructures critiques et militaires Exigences strictes sans compromis applicatif

Étapes pratiques pour durcir vos systèmes Linux et Windows

La mise en œuvre du durcissement exige une méthodologie structurée par étapes, applicable aussi bien lors d’un déploiement neuf que sur un parc existant.

1. Réduire la surface d’attaque et désactiver les services inutiles

La première mesure consiste à identifier et stopper tous les processus d’arrière-plan inutiles. Pour appliquer cette règle et désactiver services inutiles securite, un audit des ports d’écoute réseau s’impose.

  • Sous Linux, identification des services actifs via ss -tulpn puis désactivation définitive avec la commande systemctl disable --now <nom_du_service>.
  • Suppression des composants obsolètes et dangereux comme les serveurs FTP non chiffrés, Telnet, RSH ou Rexec au profit de SSH.
  • Sous Windows Server, désactivation des rôles non requis (comme les services d’impression ou la télémétrie) via PowerShell et fermeture des flux SMB v1.

2. Renforcer la gestion des utilisateurs, des accès SSH et des privilèges

Le contrôle des accès reste la pierre angulaire de la sécurité. Appliquer un hardening linux guide implique de verrouiller la gestion des identités locales et la prise de main à distance.

  • Interdiction de la connexion directe en compte root sous SSH via la directive PermitRootLogin no dans le fichier de configuration /etc/ssh/sshd_config.
  • Suppression totale de l’authentification SSH par mot de passe au profit exclusif de clés cryptographiques robustes (type Ed25519 ou RSA 4096 bits).
  • Encadrement strict des privilèges d’administration via sudo, en limitant les commandes autorisées et en imposant une réauthentification toutes les 5 minutes.
  • Nettoyage périodique des comptes d’utilisateurs locaux inactifs depuis plus de 90 jours.

3. Sécuriser les mots de passe et la politique de mise à jour

Pour sécuriser installation windows ou Linux, les politiques d’authentification et le maintien à jour du système doivent être configurés dès l’installation.

  • Imposition d’une longueur minimale de mot de passe fixée à 14 caractères intégrant majuscules, chiffres et symboles via les modules PAM sous Linux ou les stratégies GPO sous Windows.
  • Mise en place d’un mécanisme de verrouillage automatique des comptes après 5 tentatives d’authentification infructueuses.
  • Configuration des mises à jour de sécurité automatiques pour les correctifs critiques (utilisation de unattended-upgrades sous Debian/Ubuntu ou de WSUS sous Windows Server).
  • Activation de la protection des identifiants mémoire Windows Defender Credential Guard sous Windows Server.

4. Activer la journalisation et la centralisation des logs

Un système durci doit conserver la mémoire de chaque événement important afin de permettre l’analyse post-incident et la détection d’intrusions.

  • Activation du démon auditd sous Linux pour surveiller les accès aux fichiers sensibles tels que /etc/passwd, /etc/shadow et /etc/sudoers.
  • Configuration de la politique d’audit avancée Windows pour enregistrer le détail des événements d’ouverture de session (codes 4624 et 4625).
  • Routage synchrone et chiffré des journaux d’événements vers un serveur SIEM distant via le protocole Syslog-ng ou rsyslog configuré en TLS.

5. Configurer le contrôle d’accès obligatoire (SELinux vs AppArmor)

Le contrôle d’accès traditionnel basé sur les permissions utilisateurs montre ses limites lorsqu’un service est compromis. L’utilisation de modules de contrôle d’accès obligatoire (MAC) au niveau du noyau garantit qu’un processus ne peut pas outrepasser ses prérogatives, même s’il s’exécute avec les droits d’administration.

Critère de comparaison SELinux AppArmor
Distributions principales Red Hat Enterprise Linux, Fedora, Rocky Linux Debian, Ubuntu, openSUSE
Méthode d’identification Basée sur des étiquettes d’objets (labels SELinux) Basée sur les chemins d’accès aux fichiers
Complexité de gestion Élevée, nécessite un apprentissage technique poussé Moyenne, profils de sécurité plus lisibles
Mode de fonctionnement par défaut Enforcing (bloque et journalise les violations) Enforce (bloque) ou Complain (journalise uniquement)

Outils d’audit de conformité et d’automatisation du hardening

Appliquer manuellement des centaines de règles de sécurité sur un parc informatique s’avère chronophage et source d’erreurs. Des outils spécialisés permettent de contrôler et d’automatiser le processus.

  • Lynis : outil d’audit open source pour Linux exécutant un scan complet du système en moins de 5 minutes et attribuant un score de durcissement global.
  • OpenSCAP : framework d’évaluation de conformité permettant de valider l’alignement d’un système par rapport aux profils officiels CIS ou PCI-DSS.
  • Ansible : moteur d’automatisation idéal pour déployer des rôles de hardening standardisés sur plusieurs centaines de serveurs en quelques secondes.
  • Rudder : solution de gestion continue de la conformité permettant de détecter immédiatement toute dérive de configuration par rapport au modèle cible.

Méthodologie : comment mener un projet de durcissement en entreprise

Le déploiement des règles de durcissement ne doit jamais interrompre les services applicatifs en production. Une approche rigoureuse en quatre phases garantit un passage à l’échelle sans impact opérationnel.

  • Phase 1 : Cartographie et audit initial : inventaire des actifs et réalisation d’un scan d’évaluation à l’aide de Lynis ou OpenSCAP pour mesurer l’écart par rapport au référentiel retenu.
  • Phase 2 : Élaboration de la configuration cible : rédaction des profils de durcissement adaptés au rôle de chaque serveur (serveur Web, base de données, contrôleur de domaine).
  • Phase 3 : Validation en environnement de recette : application des règles sur un banc de test durant 14 jours minimum afin d’identifier d’éventuels blocages applicatifs.
  • Phase 4 : Déploiement automatisé et audit continu : automatisation de l’application des configurations via un orchestrateur et contrôle régulier de l’absence de dérive.

FAQ sur le durcissement système (OS hardening)

Quelle est la différence entre un pare-feu et le hardening système ?
Le pare-feu contrôle et filtre le trafic réseau entrant et sortant selon des règles de port et d’adresse IP. Le hardening système est une démarche globale qui sécurise la totalité de l’OS, incluant la gestion des comptes, la configuration des services internes, les droits sur les fichiers et l’isolation des processus du noyau.

Le durcissement système risque-t-il de bloquer mes applications ?
Oui, si certaines règles sont appliquées sans phase de test préalable. Par exemple, restreindre les accès réseau d’un composant ou activer SELinux en mode strict sans adapter les profils peut bloquer un service légitime. C’est pourquoi une étape de recette sur un environnement hors production est indispensable.

À quelle fréquence faut-il réévaluer le durcissement d’un serveur ?
Le durcissement doit être réévalué en continu. Un audit automatisé hebdomadaire est recommandé pour vérifier l’absence de dérive. De plus, une révision complète du profil de sécurité doit intervenir à chaque mise à jour majeure du système d’exploitation ou lors de la parution d’une nouvelle version des référentiels ANSSI ou CIS.