Durcir un serveur Linux avant la mise en production, checklist

Une installation Linux par défaut est pensée pour démarrer partout, pas pour résister à quoi que ce soit : authentification SSH (Secure Shell) par mot de passe, aucun filtrage entrant, /tmp exécutable, aucune trace des commandes privilégiées. Cette checklist, écrite pour Debian 12 ou 13 (les équivalents RHEL, Red Hat Enterprise Linux, sont indiqués quand ils diffèrent), s’exécute dans l’ordre, car chaque étape protège la suivante. La position défendue : un durcissement qui n’est pas vérifié par un outil en fin de parcours n’est qu’une intention.

→ Lire l’explication complète de la marmotte

Prérequis et ordre des opérations

Avant de commencer : un accès console hors bande (IPMI, Intelligent Platform Management Interface, console de l’hyperviseur ou du fournisseur cloud), une paire de clés Ed25519 générée sur le poste d’administration, et la liste des ports que le service métier doit réellement exposer. Sans console hors bande, la moindre faute de frappe dans le pare-feu transforme le serveur en brique distante. Vingt ans de métier apprennent que la règle drop qui coupe la session SSH en cours est toujours appliquée un vendredi soir, depuis la seule machine qui n’avait pas d’accès console.

L’ordre compte : accès SSH d’abord (tant qu’une session est ouverte, on peut encore corriger), puis pare-feu, puis réduction des services, mises à jour, noyau, montages, audit, et le scan en dernier.

Étapes 1 à 4 : SSH par clé, nftables, services et mises à jour

Étape 1, SSH par clé uniquement. Créer un compte d’administration membre d’un groupe ssh-admins, y déposer la clé publique, tester une connexion par clé depuis une seconde session, puis seulement couper le mot de passe. sshd -t valide la syntaxe avant tout rechargement. Désactiver PasswordAuthentication sans désactiver KbdInteractiveAuthentication laisse souvent le mot de passe passer par PAM (Pluggable Authentication Modules) : les deux directives vont ensemble.

Étape 2, pare-feu à politique restrictive. nftables est le cadre natif ; ufw et firewalld n’en sont que des surcouches. Politique drop en entrée, ouverture explicite de SSH depuis le seul réseau d’administration et des ports métier. La segmentation au niveau du réseau, qui complète ce filtrage local, est traitée dans la section réseaux.

Étape 3, services et ports inutiles. ss -tulpn liste ce qui écoute, systemctl list-unit-files --state=enabled ce qui démarre. avahi-daemon, cups, rpcbind n’ont rien à faire sur un serveur : systemctl disable --now puis mask, pour qu’une dépendance ne les ressuscite pas.

Étape 4, mises à jour de sécurité automatiques. Le paquet unattended-upgrades (sur RHEL : dnf-automatic) applique les correctifs de sécurité. Il ne redémarre rien par défaut : un noyau corrigé mais non chargé ne corrige rien. needrestart signale les services à relancer ; le redémarrage du noyau doit entrer dans une fenêtre planifiée.

Script de durcissement reproductible

Le bloc suivant applique les étapes 1, 2, 5, 6 et 7. Il se lance en root, depuis une session SSH par clé déjà validée, avec un accès console disponible.

# Étape 1 : SSH par clé seule, pas de root, groupe autorisé explicite
cat > /etc/ssh/sshd_config.d/10-durcissement.conf <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AuthenticationMethods publickey
AllowGroups ssh-admins
MaxAuthTries 3
EOF
sshd -t && systemctl reload ssh      # "sshd" sur RHEL

# Étape 2 : nftables, entrée fermée par défaut, SSH depuis l'admin seulement
cat > /etc/nftables.conf <<'EOF'
flush ruleset
table inet filtre {
  chain entree {
    type filter hook input priority 0; policy drop;
    iif lo accept
    ct state established,related accept
    ct state invalid drop
    ip saddr 10.0.50.0/24 tcp dport 22 accept
    tcp dport 443 accept
    meta l4proto { icmp, ipv6-icmp } accept
  }
}
EOF
nft -c -f /etc/nftables.conf && systemctl enable --now nftables

# Étape 5 : noyau, pas de routage, SYN cookies, pas de redirections ICMP
# (Internet Control Message Protocol) ni de routage par la source
cat > /etc/sysctl.d/90-durcissement.conf <<'EOF'
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.unprivileged_bpf_disabled = 1
EOF
sysctl --system

# Étape 6 : /tmp et /dev/shm sans exécution, sans setuid, sans périphérique
echo 'tmpfs /tmp     tmpfs defaults,nodev,nosuid,noexec,size=1G 0 0' >> /etc/fstab
echo 'tmpfs /dev/shm tmpfs defaults,nodev,nosuid,noexec 0 0' >> /etc/fstab
mount -o remount /dev/shm; mount /tmp

# Étape 7 : auditd, commandes exécutées en root par un humain, fichiers sensibles
apt-get install -y auditd
cat > /etc/audit/rules.d/50-privileges.rules <<'EOF'
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k cmd_root
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
-w /etc/ssh/sshd_config.d/ -p wa -k sshd
-e 2
EOF
augenrules --load

Noyau, montages et audit : ce que chaque réglage garantit

tcp_syncookies ne bloque pas une inondation de paquets SYN (ouverture de connexion TCP, Transmission Control Protocol) : il évite que la file des connexions à moitié ouvertes se remplisse, au prix de certaines options TCP quand les cookies s’activent. ip_forward = 0 n’a de sens que si la machine n’est ni routeur ni hôte de conteneurs : Docker et les CNI (Container Network Interface) de Kubernetes le repassent à 1 et en ont besoin.

noexec sur /tmp empêche ./charge, pas bash /tmp/charge ni python3 /tmp/charge.py : c’est un ralentisseur, pas une barrière. Il casse aussi certains installateurs qui décompressent puis exécutent dans /tmp ; on le constate en recette plutôt qu’en production. nosuid a plus de valeur : un binaire setuid déposé là n’élève plus de privilège.

La règle execve filtrée sur auid trace ce qu’un humain lance après sudo, sans noyer le journal sous les processus système. -e 2 rend la configuration immuable jusqu’au prochain redémarrage : un attaquant devenu root ne peut plus désactiver l’audit à chaud, mais il peut toujours effacer /var/log/audit/. Les événements doivent donc partir vers un collecteur distant (greffon audisp ou agent de journalisation). La supervision de ces flux relève de l’architecture cyber.

Étape 8 : vérifier avec Lynis, sans chasser le score

lynis audit system produit un indice de durcissement et une liste de suggestions dans /var/log/lynis-report.dat. L’indice n’est pas un objectif : une partie des suggestions (compilateurs à retirer, bannière légale) n’a aucun effet sur la surface d’attaque réelle. Les tests à regarder en premier sont ceux qui concernent SSH, le pare-feu et les montages, c’est-à-dire la vérification des étapes précédentes. Chasser le 100/100, c’est optimiser un tableau de bord plutôt qu’un serveur ; le secteur a déjà suffisamment de tableaux de bord verts au-dessus de machines ouvertes.

Ce que cette checklist ne garantit pas : elle ne corrige aucune faille du service métier exposé sur le port 443, elle ne remplace ni la gestion des identités d’administration (voir identités) ni les sauvegardes, et elle se dégrade avec le temps. Relancer Lynis après chaque mise à jour majeure et comparer au rapport précédent.

🐝 Ce qui arrive si on s’en passe

Sans ce durcissement, un serveur exposé reçoit des tentatives d’authentification SSH automatisées dès ses premières heures en ligne : l’authentification par mot de passe laissée active transforme chaque compte faible en point d’entrée testable à volonté. Un pare-feu permissif expose des services d’administration jamais destinés au réseau public (bases de données, interfaces de supervision, agents de sauvegarde), et les correctifs non appliqués maintiennent ouvertes des failles dont le code d’exploitation circule déjà. L’absence d’options de montage restrictives permet d’exécuter un binaire déposé dans un répertoire temporaire inscriptible par tous, et un binaire setuid abandonné là devient une élévation de privilèges. Sans journalisation des actions privilégiées, une intrusion ne laisse ni horodatage, ni commande, ni identité d’appelant : la reconstitution après coup se limite à des suppositions, et la décision de réinstaller ou non reste sans appui factuel.

🦫 Explication de la marmotte 🍫

Un serveur neuf accepte des connexions à distance protégées par un simple mot de passe, que des programmes automatiques essaient de deviner en continu. La première étape remplace ce mot de passe par une clé : un fichier secret gardé sur l’ordinateur de l’administrateur, impossible à deviner. On la teste avant de couper l’ancien accès, sinon on se retrouve dehors. Ensuite, un filtre refuse toute connexion entrante, sauf celles explicitement autorisées. On arrête les programmes qui écoutent le réseau sans servir à rien, parce que chacun peut contenir un défaut. Les correctifs de sécurité s’installent automatiquement, mais certains ne prennent effet qu’après un redémarrage. On règle ensuite le cœur du système pour qu’il ne serve pas de relais entre réseaux et qu’il résiste aux avalanches de demandes de connexion jamais terminées. Les dossiers temporaires, où tout le monde peut écrire, sont montés de façon à refuser l’exécution directe des programmes et les droits spéciaux. Un journal enregistre chaque commande lancée avec les pleins pouvoirs ; il doit être copié sur une autre machine, car un intrus peut effacer la copie locale. Enfin, un outil de contrôle passe tout en revue et signale ce qui a été oublié.

Pages voisines

La citent

Durcir un serveur Linux avant la mise en production, checklist

Elle cite

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

Durcir un serveur Linux avant la mise en production, checklist

Durcir un serveur Linux avant la mise en production, checklist

Prérequis et ordre des opérations

Étapes 1 à 4 : SSH par clé, nftables, services et mises à jour

Script de durcissement reproductible

Noyau, montages et audit : ce que chaque réglage garantit

Étape 8 : vérifier avec Lynis, sans chasser le score

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines