Le durcissement système, angle mort des politiques de sécurité

Dans la plupart des organisations, la sécurité se voit. Elle a un pare-feu nouvelle génération, un SIEM avec des tableaux de bord, un EDR déployé sur le parc, un audit de code annuel et un pentest dont le rapport circule jusqu'au comité de direction.

Et en dessous de tout cela, il y a quelques centaines de serveurs Linux installés il y a trois ans, en configuration par défaut, que personne n'a jamais ouverts autrement que pour y déployer une application.

Le durcissement des systèmes d'exploitation est la couche la moins financée, la moins outillée et la moins mesurée de la chaîne. C'est aussi celle sur laquelle tout le reste repose.

Pourquoi personne ne veut s'en occuper

Ce désintérêt n'est pas de la négligence. Il a des causes structurelles, et il faut les nommer avant de proposer quoi que ce soit.

Le durcissement ne se démontre pas. Un EDR affiche des alertes bloquées. Un WAF compte les requêtes rejetées. Un serveur correctement durci ne produit rien : il ne se passe simplement pas d'incident. Personne ne fait de slide sur une absence d'événement.

La responsabilité est diluée. Le RSSI définit une politique mais ne touche pas aux machines. L'équipe système applique ce qu'on lui demande mais son objectif de performance est la disponibilité, pas la surface d'attaque. Entre les deux, le durcissement tombe dans l'interstice : tout le monde le juge nécessaire, personne ne le porte.

La peur de la régression est légitime. « On ne va pas toucher à ça, ça tourne. » Ce réflexe est rationnel : un sysctl mal choisi ou un point de montage en noexec peut effectivement arrêter une application en production le vendredi soir. Le problème n'est pas la prudence, c'est qu'en l'absence de méthode, la prudence se transforme en immobilisme définitif.

Il n'y a pas de fin de projet. Un pentest se termine. Un déploiement d'antivirus se termine. Un référentiel de durcissement, lui, dérive dès le lendemain de son application : un paquet installé, un chmod 777 de dépannage, une règle sudoers ajoutée en urgence. Sans mesure continue, l'effort initial s'évapore en quelques mois.

Ce que contient réellement une installation par défaut

Une distribution Linux est optimisée pour que les choses fonctionnent, pas pour qu'elles résistent. C'est un choix de conception parfaitement défendable de la part des éditeurs — mais il laisse au moment de la mise en service un écart substantiel entre l'état livré et l'état souhaitable.

Sur une installation standard, on retrouve régulièrement :

• des services actifs dont personne n'a l'usage sur le rôle de la machine ;
• une politique d'authentification SSH permissive, souvent héritée d'une configuration copiée entre serveurs sur plusieurs générations ;
• des points de montage sans nosuid, nodev ou noexec sur les zones inscriptibles par tous ;
• aucune journalisation d'audit système, donc aucune capacité d'investigation a posteriori ;
• des paramètres noyau réseau laissés à leur valeur par défaut ;
• des règles sudo accordées largement parce que c'était plus rapide au moment du besoin ;
• des binaires setuid hérités que plus aucun processus métier n'utilise.

Un premier constat s'établit en quelques commandes :

# Services actifs et leur utilité réelle sur ce rôle
systemctl list-units --type=service --state=running

# Ce qui écoute sur le réseau, et par quel processus
ss -tulpnH

# Binaires setuid/setgid présents sur le système
find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -printf '%M %u %p\n' 2>/dev/null

# Options de montage effectives
findmnt -no TARGET,OPTIONS

Aucune de ces commandes ne modifie quoi que ce soit. Elles produisent pourtant, sur un parc jamais audité, une liste de constats qui suffit généralement à débloquer un budget.

Sortir du mythe « le durcissement casse la production »

L'objection est réelle. La réponse ne consiste pas à la balayer, mais à changer la manière de procéder. Quatre principes suffisent à rendre le durcissement exploitable en environnement de production.

1. Mesurer avant d'agir

On ne durcit pas un parc qu'on ne connaît pas. La première livraison d'une démarche de hardening n'est pas un changement de configuration : c'est un état des lieux chiffré, par machine et par rôle, positionné face à un référentiel.

Deux outils suffisent à démarrer, en lecture seule :

# Audit générique du système
lynis audit system --quiet

# Évaluation face à un profil CIS via OpenSCAP
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results /tmp/resultats.xml \
  --report /tmp/rapport.html \
  /usr/share/xml/scap/ssg/content/ssg-debian13-ds.xml

Le rapport HTML produit est directement utilisable en réunion : il donne un pourcentage de conformité, une liste de règles en échec et la justification de chacune.

2. Travailler par paliers, pas en bloc

Appliquer un profil CIS niveau 2 d'un seul coup sur un serveur applicatif est le meilleur moyen de provoquer l'incident qui enterrera la démarche pour cinq ans. Le découpage réaliste ressemble plutôt à :

Chaque palier est validé en préproduction, mesuré, puis promu. Le palier 4 n'est pas systématiquement atteint sur toutes les machines, et ce n'est pas un échec : c'est une décision de risque documentée.

3. Automatiser pour rendre l'opération idempotente et réversible

Un durcissement appliqué à la main sur cinquante serveurs n'est pas un durcissement, c'est cinquante configurations légèrement différentes. L'automatisation n'est pas ici un confort d'exploitation, c'est ce qui rend l'ensemble auditable et rejouable.

- name: Durcissement SSH — palier 2
  hosts: linux_servers
  become: true
  tasks:
    - name: Sauvegarde de la configuration courante
      ansible.builtin.copy:
        src: /etc/ssh/sshd_config
        dest: "/etc/ssh/sshd_config.bak-{{ ansible_date_time.iso8601_basic_short }}"
        remote_src: true
        mode: '0600'

    - name: Application des directives durcies
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: "^#?\s*{{ item.directive }}\b"
        line: "{{ item.directive }} {{ item.value }}"
        validate: '/usr/sbin/sshd -t -f %s'
      loop:
        - { directive: 'PermitRootLogin',        value: 'no' }
        - { directive: 'PasswordAuthentication', value: 'no' }
        - { directive: 'X11Forwarding',          value: 'no' }
        - { directive: 'MaxAuthTries',           value: '4' }
        - { directive: 'ClientAliveInterval',    value: '300' }
        - { directive: 'LoginGraceTime',         value: '60' }
      notify: reload sshd

  handlers:
    - name: reload sshd
      ansible.builtin.service:
        name: sshd
        state: reloaded

Trois éléments méritent l'attention dans cet exemple, indépendamment des directives elles-mêmes : la sauvegarde horodatée qui rend le retour arrière trivial, la clause validate qui refuse d'écrire une configuration syntaxiquement invalide, et le reload plutôt que le restart qui préserve les sessions établies. Ce sont ces détails, plus que le choix des paramètres, qui déterminent si une campagne de durcissement se déroule sans incident.

4. Mesurer la dérive

Le durcissement n'est pas un projet avec une date de fin, c'est un état à maintenir. Une exécution périodique du même audit, avec suivi de l'indicateur dans le temps, transforme un chantier ponctuel en processus. C'est aussi la seule manière de produire, en comité, la courbe qui justifie l'investissement de l'année suivante.

Les référentiels : s'appuyer sur l'existant

Il n'y a aucune raison d'inventer sa propre politique de durcissement. Trois corpus couvrent l'essentiel du besoin :

• Les CIS Benchmarks — des guides par distribution et par version, structurés en niveau 1 (applicable largement) et niveau 2 (environnements à forte contrainte). Chaque règle est accompagnée de sa justification, de sa procédure d'audit et de sa procédure de remédiation.
• Les guides de l'ANSSI — notamment les recommandations de configuration d'un système GNU/Linux, plus concises, plus directement lisibles, et directement recevables dans un contexte français.
• Le SCAP Security Guide — la traduction machine des profils précédents, exploitable par OpenSCAP pour l'évaluation automatisée.

Ces référentiels ne s'appliquent pas tels quels : ils se dérogent. Une règle écartée pour raison applicative documentée, avec sa mesure compensatoire, vaut infiniment mieux qu'une règle appliquée sans compréhension puis contournée en urgence trois semaines plus tard.

Ce que le durcissement rapporte réellement

Au-delà de la réduction de surface d'attaque, qui reste l'objectif premier, trois bénéfices sont régulièrement sous-estimés.

La capacité d'investigation. Un système sans auditd correctement configuré ne permet pas de répondre à la question « qu'est-ce qui s'est passé et quand ». Après un incident, c'est cette absence qui coûte le plus cher — en temps d'analyse comme en incertitude résiduelle sur le périmètre réellement compromis.

La conformité. Le durcissement système alimente directement plusieurs exigences réglementaires et normatives : la gestion des configurations sécurisées dans l'ISO 27001, les exigences de configuration des composants système de PCI-DSS, les mesures de sécurité des systèmes d'information attendues au titre de NIS 2. Un parc durci et mesuré transforme un chapitre d'audit pénible en démonstration de dix minutes.

L'homogénéité opérationnelle. Un référentiel de durcissement automatisé force à décrire ce qu'est un serveur « normal » dans l'organisation. Cette formalisation profite autant à l'exploitation qu'à la sécurité : elle réduit les configurations uniques, les serveurs « spéciaux » et la dette de connaissance concentrée sur une personne.

En pratique, par où commencer

Si le sujet n'a jamais été traité dans votre organisation, une séquence de démarrage tient en quatre étapes et quelques semaines :

1. 1Auditer sans rien modifier un échantillon représentatif — un serveur par rôle et par distribution. Objectif : un chiffre et une liste, pas une opinion.
2. 2Choisir un référentiel et acter le niveau visé par famille de serveurs. Cette décision appartient à la direction, pas à l'équipe technique.
3. 3Construire l'automatisation sur le palier 1, la valider en préproduction, la déployer. Le palier le moins risqué est aussi celui qui fait la démonstration que la méthode tient.
4. 4Réexécuter l'audit et publier l'écart. C'est ce delta, et lui seul, qui ouvrira la suite.

Le durcissement des systèmes restera probablement toujours moins visible que les couches qui le surplombent. Ce n'est pas une raison pour continuer à livrer en production des machines dans l'état exact où l'installateur les a laissées.

Une imprécision ou une erreur dans cet article ? Signalez-la nous, nous corrigeons et datons la mise à jour.