Durcir Debian/Ubuntu 22.04 LTS : Auditd, SSH, profils systemd et liste de contrôle

Dans cet article, il s’agit de la manière de durcir Debian/Ubuntu 22.04 LTS, en particulier avec auditd pour des logs d’audit à des fins forensiques, une configuration SSH robuste et des profils de sécurité systemd (systemd ist der Linux‑Init‑ und Service‑Manager). L’objectif est un guide pratique : prérequis, sources d’erreurs typiques, procédures de vérification, exemples de configuration concrets et stratégies de repli. La documentation s’adresse aux administrateurs, ingénieurs systèmes et opérateurs qui doivent exploiter des serveurs de production de manière fiable.

Durcir Debian/Ubuntu 22.04 LTS : pourquoi le durcissement des serveurs LTS est important

Debian/Ubuntu 22.04 LTS est une plateforme répandue pour les serveurs. LTS signifie Long Term Support et implique des mises à jour de sécurité sur une période prolongée ; cela ne protège toutefois pas contre les erreurs de configuration, les vecteurs d’attaque ou les exigences de conformité. Le durcissement réduit la surface d’attaque, améliore la traçabilité (audit) et facilite la réponse aux incidents.

Important : le durcissement n’est pas une action ponctuelle, mais un processus opérationnel. Les modifications doivent être testées, documentées et réversibles.

Aperçu : domaines d’intervention de cet article

• Configurer auditd et définir des politiques d’audit — pour la traçabilité et la conformité.
• Sécuriser SSH — authentification, gestion des clés, protocoles et contrôle des sessions.
• Profils de sécurité systemd (sandboxing) — granularité des services, réduction des privilèges et confinement des exploits.
• Exploitation matérielle : snapshots LVM, E/S disque, récupération au démarrage et dépannage.
• Centralisation des logs, transfert TLS et stratégies d’intégrité pour les données d’audit.
• Stratégies de vérification et de rollback ainsi qu’une checklist opérationnelle.

Auditd : principes, usages et scénarios typiques

Auditd est le démon d’audit Linux (auditd). Il collecte des événements pertinents pour la sécurité (p. ex. file access, execve, SELinux/Auditing Hooks) et produit des logs d’audit utilisés pour la forensique, la conformité (p. ex. ISO, PCI) et la détection d’intrusion. Auditd se distingue de syslog/journald : les événements d’audit sont plus structurés et moins sujets à perte pour des besoins probatoires.

Prérequis et décisions d’architecture

Avant l’installation, vérifiez l’espace disque, le chemin de log central (p. ex. serveur syslog/audit distant) et les ressources : auditd peut générer une charge d’E/S importante avec un grand nombre de règles. Décidez si les logs d’audit doivent rester locaux, être envoyés vers un serveur de logs distant (p. ex. rsyslog/ELK/Graylog) ou être transmis à un SIEM.

Installation et configuration de base

Installez et activez auditd :

sudo apt update
sudo apt install -y auditd audispd-plugins
sudo systemctl enable --now auditd

Par défaut, la configuration se trouve dans /etc/audit/auditd.conf. Les paramètres importants sont LogFile (chemin), max_log_file (rotation en Mo) et max_log_file_action (p. ex. rotate ou keep_logs). Pour les systèmes de production, il est recommandé d’utiliser une valeur conservatrice pour max_log_file et de mettre en place la redirection des logs.

# Beispiel: /etc/audit/auditd.conf (wichtige Zeilen)
log_file = /var/log/audit/audit.log
max_log_file = 200
max_log_file_action = rotate
space_left_action = SYSLOG
action_mail_acct = root

Règles d’audit : que doit contenir le jeu de règles ?

De bonnes règles d’audit se concentrent sur :

• Événements d’authentification (sshd, sudo, su)
• Modifications de /etc (fichiers de configuration)
• Binaires avec SUID/SGID
• Fichiers/répertoires critiques (p. ex. configurations d’applications, magasins de secrets)
• execve pour la surveillance des démarrages de processus sensibles (à utiliser avec prudence, car volumineux)

Exemple d’un fichier audit.rules :

# /etc/audit/rules.d/50-monitor.rules
# Authentication events (sshd, sudo)
-w /var/log/auth.log -p wa -k auth_changes

# /etc modifications
-w /etc/ -p wa -k etc_changes

# SUID/SGID binaries
-w /usr/bin/sudo -p x -k privileged

# Monitor sensitive config file
-w /etc/ssh/sshd_config -p wa -k sshd_config

# execve for specific users (example)
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_exec

Pourquoi cela fonctionne : auditd installe des hooks noyau qui génèrent des événements même en cas de modifications par root. Quand cela échoue : des règles execve trop larges entraînent rapidement des journaux volumineux et des problèmes de performance. Testez les règles progressivement dans un environnement de test.

Centralisation et intégrité

Transférez les logs d’audit vers un serveur de logs central ou un SIEM. Veillez au chiffrement du transport (TLS) et aux contrôles d’intégrité (p. ex. rotation des logs signée ou stockage en écriture unique). Pour la recherche forensique à court terme, les journaux locaux sont utiles, mais à long terme ils doivent être stockés dans des dépôts centraux consultables.

Redirection des logs d’audit avec rsyslog via TLS

auditd lui‑même a des capacités distantes natives limitées ; une approche éprouvée consiste à conserver le journal audit localement et à laisser rsyslog surveiller le fichier (module imfile), puis à l’envoyer de façon sécurisée via TLS vers un serveur Rsyslog/SIEM central. Cela sépare la collecte (auditd) du transport (rsyslog) et permet la reprise en cas de problèmes réseau.

# /etc/rsyslog.d/10-audit-imfile.conf (Client)
module(load="imfile")
input(type="imfile"
      File="/var/log/audit/audit.log"
      Tag="audit"
      Severity="info"
      PersistStateInterval="200")

# TLS forwarding (Auszug)
*.* action(type="omfwd" Target="logs.example.internal" Port="6514" Protocol="tcp" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name" StreamDriverPermittedPeers="logs.example.internal")

Sur le serveur Rsyslog/SIEM central, mettez en place des certificats serveur, la vérification des certificats clients et des règles de pare‑feu appropriées. Vérifiez qu’en cas d’interruption réseau, la surveillance de fichier met bien en tampon et reprend.

Durcir SSH : authentification, clés, protocole et règles d’exploitation

SSH reste le protocole d’accès standard pour l’administration Linux. Les vulnérabilités proviennent de clés faibles, de configurations par défaut, de connexions root ouvertes et d’une absence de contrôle des sessions. Un SSH durci protège contre le vol d’identifiants et les accès latéraux.

Mesures préventives

Règles de base :

• Désactivez la connexion root via SSH ; utilisez sudo avec suivi d’audit.
• Autorisez uniquement des algorithmes de chiffrement modernes (p. ex. Ed25519, ECDSA), désactivez les chiffrements obsolètes.
• Limitez les tentatives d’authentification et déployez Fail2ban ou des mécanismes de protection similaires.
• Utilisez une architecture bastion/jump‑host plutôt qu’un accès SSH direct depuis Internet.

Optimisations concrètes de sshd_config

Éditez /etc/ssh/sshd_config. Voici un ensemble minimal recommandé :

# /etc/ssh/sshd_config (Auszug)
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
AllowUsers adminuser
ClientAliveInterval 300
ClientAliveCountMax 2
PermitEmptyPasswords no
KexAlgorithms curve25519-sha256@libssh.org
HostKey /etc/ssh/ssh_host_ed25519_key
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com
LogLevel VERBOSE

Explication : PasswordAuthentication no oblige l’authentification par clés ; PermitRootLogin no empêche les accès directs en root ; LogLevel VERBOSE génère des événements d’audit exploitables (et doit être corrélé avec auditd). Quand cela échoue : si tous les administrateurs n’ont soudainement plus de clé — prévoyez des transitions et des comptes de test.

Gestion des clés et rotation

Organisez les clés de façon centralisée (p. ex. via une SSH CA ou un Identity Management). SSH Certificate Authority (SSH CA) permet des certificats éphémères au lieu d’authorized_keys permanents. La rotation est importante : vérifier et révoquer régulièrement les clés existantes lorsque du personnel change.

# Beispiel: ssh-keygen für Ed25519
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""

# Signieren eines Nutzerkeys mit einer SSH-CA (Kurzbeispiel)
ssh-keygen -s /etc/ssl/ssh/ca_key -I user-cert -n username -V +52w user_key.pub

systemd‑Sicherheitsprofile: Dienst‑Sandboxing und sichere Unit‑Konfiguration

systemd offre de nombreuses options de sécurité au niveau des units : ProtectSystem, ProtectHome, PrivateTmp, NoNewPrivileges, CapabilityBoundingSet, usw. Ces paramètres réduisent les privilèges d’un service et limitent l’impact en cas de compromission.

Principe de base : moindre privilège pour les services

Chaque service ne reçoit que les droits dont il a réellement besoin. Les systemd‑Drop‑ins (Directory: /etc/systemd/system/.d/*.conf) sont un moyen sûr de gérer des modifications sans modifier le fichier fourni par le paquet.

Exemple: systemd Drop‑In zur Härtung einer Web‑Service‑Unit

# /etc/systemd/system/myweb.service.d/hardening.conf
[Service]
PrivateTmp=true
ProtectSystem=full
ProtectHome=yes
NoNewPrivileges=true
RESTrictAddrFamilies=AF_INET AF_INET6 AF_UNIX
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
ReadOnlyPaths=/etc/myweb
# Optional: Limit CPU/Memory
MemoryMax=500M
CPUQuota=70%

Pourquoi cela fonctionne : ProtectSystem=full rend /usr et /boot en lecture seule pour le service ; PrivateTmp isole les fichiers temporaires ; NoNewPrivileges empêche SetUID/execve après une élévation de privilèges. Quand cela échoue : certaines applications nécessitent un accès en écriture à /usr ou à des répertoires tmp globaux ; testez les Drop‑ins progressivement.

Tests et déploiement canari

Utilisez des Canary‑Hosts ou des rollouts à faible charge. Pour les modifications systemd, il est recommandé :

1. Créer le Drop‑in
2. Exécuter systemctl daemon-reload
3. Redémarrage dans une fenêtre de maintenance
4. Surveiller le temps de démarrage, les événements OOM et les erreurs spécifiques à l’application

sudo systemctl daemon-reload
sudo systemctl RESTart myweb.service
journalctl -u myweb.service -f

Matériel: LVM‑Snapshots, Disk‑I/O und Boot‑Recovery

La couche matérielle influence fortement le durcissement et l’exploitation : des partitions pleines, des latences d’I/O élevées ou un périphérique de démarrage défaillant peuvent rendre inefficaces les mesures de durcissement ou empêcher des rollback critiques. Voici quelques domaines d’action et étapes de dépannage éprouvés.

Planification de l’espace et monitoring

Les logs d’audit augmentent. Prévoyez des partitions dédiées ou des volumes LVM pour /var/log et /var/log/audit. Surveillez l’espace libre, l’utilisation des inodes et l’I/O avec des outils simples :

# freien Speicher prüfen
df -h /var/log
# I/O Belastung beobachten
iostat -xz 1 10
# Top Prozesse nach I/O
iotop -oPa

Piège fréquent : logrotate désactivé ou défaillant → partition de logs pleine → services bloqués.

Snapshot LVM comme option de rollback

Avant des modifications importantes (systemd‑Drop‑ins, déploiement SSH massif, mise à jour des règles d’audit), créez un snapshot LVM du volume concerné. Les snapshots permettent un rétablissement rapide sans le temps d’un RESTore complet de sauvegarde.

# Beispiel: Snapshot anlegen (root-Volume lv_root im vg0)
sudo lvcreate --size 2G --snapshot --name root_snap /dev/vg0/root

# Änderungen durchführen ...

# Snapshot zurückspielenvia lvconvert (oder Mount snapshot und rsync zurück)
sudo lvconvert --merge /dev/vg0/root_snap
# Danach Neustart erforderlich
sudo reboot

Attention : les snapshots consomment de l’espace ; sous forte charge d’écriture ils croissent rapidement et peuvent remplir le volume. Des snapshots invalides impactent les performances.

Récupération au démarrage et accès hors‑bande

Vérifiez que l’IPMI/iLO/DRAC ou la console du fournisseur fonctionne. Sans accès hors‑bande, il est difficile d’intervenir en cas de verrouillage (par ex. SSH). Documentez les comptes de secours et conservez les clés de secours séparément de l’automatisation centrale.

NTP/chrony et intégrité des horodatages

Une horloge cohérente est critique pour l’audit et la forensic. Utilisez chrony ou systemd‑timesyncd, validez les pairs NTP et mettez en place des alertes en cas de dérive. Des horodatages divergents compliquent la corrélation des journaux.

# Chrony Status prüfen
chronyc tracking
chronyc sources -v

# systemd-timesyncd Status
timedatectl status

Contrôles, supervision et pièges typiques

Avant toute modification, vérifiez l’état de base : version du kernel, paquets installés, services actifs et règles d’audit en vigueur. Les pièges typiques sont :

• Règles auditd excessivement larges → explosion des journaux
• sshd_config trop RESTrictive → administrateurs bloqués
• RESTrictions systemd qui bloquent l’accès légitime aux fichiers/sockets
• Absence de centralisation des journaux → perte de données forensiques
• Absence de console hors‑bande → RESTauration difficile

Commandes de vérification essentielles

# auditd Status und Regeln
sudo systemctl status auditd
sudo auditctl -l

# SSH Überprüfen
sshd -t
sudo systemctl reload sshd

# systemd-Unit check
systemd-analyze blame
systemctl status myweb.service
journalctl -u myweb.service -n 200

# Disk und Snapshotchecks
lvs -a
df -h /var/log
iostat -xz 1 5

Stratégies de rollback et accès d’urgence

Prévoyez une option de retour pour chaque modification. Pour les changements SSH, il est recommandé d’avoir un compte administrateur parallèle avec accès par clé, qui n’est pas lié aux nouvelles règles, ou une console hors‑bande (iLO, DRAC, IPMI). Pour les modifications systemd, conservez le drop‑in en tant que fichier avec identification de version et créez des snapshots (LVM/LUKS) ou des sauvegardes du système avant les changements critiques.

# Beispiel Rollback systemd: Drop-in entfernen und daemon neu laden
sudo rm /etc/systemd/system/myweb.service.d/hardening.conf
sudo systemctl daemon-reload
sudo systemctl RESTart myweb.service

Checklist pratique avancée : étape par étape

Cette checklist est destinée au déploiement en production. Testez chaque étape dans un environnement de staging.

1. Sauvegarder : effectuer des sauvegardes à jour du système et des configurations, snapshot si possible.
2. Vérifier l’espace & I/O : /var/log sur un volume séparé, mettre en place la supervision.
3. auditd : installer, définir des règles de base, réaliser des tests locaux.
4. Journaux : configurer l’imfile‑monitoring et le transfert TLS vers le système central de journaux, et vérifier TLS.
5. SSH : activer l’authentification par clé, désactiver RootLogin, créer des comptes de test et stocker une clé d’urgence.

Sicherheits‑Betriebswissen und Wartung

La maintenance signifie : revues périodiques des règles, vérification de la rétention des logs et exercices d’incident. Les règles d’audit évoluent avec le comportement des services ; effectuez des vérifications après les releases et les mises à jour majeures. Mettez en place des tests automatisés pour sshd_config (sshd -t checks) et le démarrage des unités systemd dans la CI/CD pour les changements d’infrastructure. Prévoyez également des revues de capacité pour les volumes de logs et les ressources de snapshots.

Konkrete Troubleshooting‑Szenarien

Auditd erzeugt hohe I/O‑Last

Cause : des règles execve trop génériques ou la surveillance de répertoires très actifs. Mesure immédiate : désactiver les règles progressivement, vérifier le write‑back vers un serveur de logs central, ne mettre auditd en pause qu’en cas d’urgence. À long terme : règles d’échantillonnage, monitoring ciblé des processus et filtrage.

Admins ausgesperrt nach sshd_config Änderung

Rollback : accès via Out‑of‑Band ou console, ou étape d’audit pour reproduire : RESTauration de /etc/ssh/sshd_config depuis une sauvegarde et systemctl RESTart sshd. Pour prévenir : maintenir toujours une clé de repli sur un utilisateur de secours dédié, qui n’est pas géré par l’automatisation.

Service startet nicht nach systemd Drop‑in

Vérifiez journalctl -u pour des erreurs concernant les RESTrictions appliquées (p. ex. Permission denied sur des chemins). Retirez temporairement le drop‑in, reload et RESTart pour RESTaurer le service. Utilisez strace ou les logs spécifiques aux erreurs si nécessaire.

Fazit

Renforcer Debian/Ubuntu 22.04 LTS signifie plus que des modifications de configuration isolées : c’est un concept d’exploitation par paliers. auditd fournit la traçabilité, un SSH durci sécurise les accès, les profils de sécurité systemd limitent les risques au niveau des services, et des mesures matérielles/opérationnelles assurent la disponibilité. Testez chaque modification de manière contrôlée, planifiez les rollbacks et intégrez le durcissement dans votre processus de lifecycle (Release, Monitoring, Review). Ainsi vous réduisez les risques d’indisponibilité et établissez une base de sécurité maintenable.

Empfohlene nächste Schritte

• Mettre en place un cluster de test et automatiser les étapes de vérification.
• Intégration des logs d’audit dans un SIEM et alerting avec transmission sécurisée par TLS.
• Documentation des drop‑ins systemd, des procédures de snapshot LVM et des politiques de gestion des clés.

Une mise en œuvre structurée réduit les risques opérationnels et facilite le respect des exigences de conformité.

La configuration d’auditd et les profils de sécurité systemd sont également importants pour ce sujet. L’article remet ces aspects en perspective de manière claire et montre ce qui compte au quotidien.