Sécuriser ses services Linux et Docker : Guide pratique du durcissement avec Systemd

Lorsque l'on audite un serveur Linux avec des outils comme systemd-analyze security, on se retrouve rapidement face à une liste de services qualifiés d'UNSAFE.

Si ce rapport peut effrayer, il nécessite une lecture nuancée, en particulier sur un serveur hébergeant des moteurs de conteneurisation.

Ce tutoriel détaille la méthodologie pour analyser ces scores, durcir intelligemment les services éligibles, et éviter les pièges classiques avec Docker.

Comprendre l'outil et la notion de score

La commande systemd-analyze security évalue le niveau d'exposition des services gérés par systemd sur une échelle de 0.0 (cloisonnement maximal) à 10.0 (aucun durcissement activé).

• Le piège des scores élevés : De nombreux services système ou logiciels tiers (comme SSH, Fail2ban ou les agents de surveillance) affichent par défaut un score de 9.6 UNSAFE. Cela signifie simplement qu'ils n'utilisent pas les options avancées de sandboxing de systemd (comme ProtectSystem, PrivateTmp, ou NoNewPrivileges).
• La réalité opérationnelle : Un score élevé ne constitue pas une faille de sécurité active, mais représente une absence de défense en profondeur. En cas de compromission, un attaquant aura un accès plus large au système hôte.

Identifier les services prioritaires à durcir

Inutile de chercher à obtenir un score de 0.0 sur l'intégralité du système. Certains services nécessitent des privilèges inhérents à leur rôle (manipulation du noyau, des cgroups ou du réseau brut).

Concentrez vos efforts de durcissement sur :

1. Les points d'entrée réseau : Le service SSH (ssh.service) en tête de liste.
2. Les outils d'analyse et de défense : Fail2ban, CrowdSec ou les démons antivirus, qui manipulent des fichiers sensibles et des logs.
3. Les services utilitaires isolés : Les gestionnaires d'impression, de ventilation ou de rapports (ex: clients NUT, Smartmontools).

Exemple de durcissement propre pour un service (ex: SSH)

Ne modifiez jamais directement les fichiers d'origine. Utilisez les fichiers de surcharge (drop-ins) :

sudo systemctl edit ssh.service

Insérez les directives suivantes, enregistrez et quittez :

[Service]
NoNewPrivileges=yes
PrivateTmp=yes
ProtectHome=read-only
ProtectSystem=full
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes

Appliquez ensuite les changements :

sudo systemctl daemon-reload
sudo systemctl restart ssh.service

Vérification : Assurez-vous que le service est bien actif avec sudo systemctl status ssh.service.

Le cas particulier de Docker et Containerd

C'est l'écueil le plus fréquent lors du durcissement systemd : appliquer des restrictions globales sur docker.service ou containerd.service.

• Pourquoi cela bloque : Docker interagit directement avec le noyau Linux pour créer des espaces de noms (namespaces), gérer les interfaces réseau virtuelles et piloter les runtimes OCI (runc).

Des directives systemd trop agressives cassent ces mécanismes et empêchent le lancement des conteneurs (problèmes d'exécution de binaires, erreurs runc create failed).

• La bonne stratégie :
  • Laissez docker.service et containerd.service avec leurs configurations par défaut (ou un durcissement très léger validé par l'éditeur).
  • Déplacez la sécurité au niveau des conteneurs directement dans vos fichiers docker-compose.yml.

Sécuriser ses conteneurs Docker (La vraie alternative)

Plutôt que de durcir le démon hôte au risque de paralyser vos stacks, appliquez le principe du moindre privilège directement dans la configuration de vos services conteneurisés :

services:
  mon_application:
    image: mon-image:latest
    restart: unless-stopped
    # Empêche l'élévation de privilèges à l'intérieur du conteneur
    security_opt:
      - no-new-privileges:true
    # Supprime toutes les capacités du noyau superflues
    cap_drop:
      - ALL
    # Si l'application le permet, passez la racine en lecture seule
    read_only: true
    volumes:
      - donnes_persistantes:/var/www/html/storage

Vérification : Utilisez docker ps pour valider que vos stacks démarrent correctement, et examinez les logs de vos conteneurs en cas de refus d'accès pour ajuster les volumes en écriture.

Conclusion

Le durcissement d'un serveur Linux est un équilibre entre sécurité proactive et stabilité opérationnelle.

Si systemd offre des leviers puissants pour isoler les services classiques du système, la conteneurisation moderne exige de porter l'effort de sécurité au cœur des configurations de déploiement (Docker Compose).

En cloisonnant vos applications par conteneur et en limitant les privilèges au strict nécessaire, vous réduisez considérablement la surface d'attaque sans risquer de casser l'infrastructure globale.