Une installation Linux par défaut est pratique, pas sécurisée. Le durcissement d’un serveur Linux consiste à réduire la surface d’attaque d’un serveur et à resserrer sa configuration afin que le sondage inévitable venu d’internet ne trouve rien de facile à exploiter. Ce guide couvre les étapes de durcissement qui comptent le plus en 2026, dans un ordre de priorité sensé.

TL;DR

  • SSH est votre plus grande surface exposée : utilisez une authentification par clé, désactivez la connexion root et les mots de passe, et limitez le débit des connexions
  • Exécutez un pare-feu en mode refus par défaut et coupez chaque service et port dont vous n’avez pas besoin
  • Maintenez le système corrigé automatiquement, et appliquez un durcissement du noyau et des comptes
  • Utilisez SELinux ou AppArmor, activez l’audit des journaux et mesurez-vous au CIS Benchmark de votre distribution

1. Verrouiller SSH

SSH est la façon dont vous administrez le serveur et la façon dont les attaquants tentent d’entrer. Durcissez-le en premier.

  • Utilisez une authentification par clé et désactivez entièrement l’authentification par mot de passe (PasswordAuthentication no).
  • Désactivez la connexion root directe (PermitRootLogin no) ; connectez-vous en tant qu’utilisateur normal et utilisez sudo.
  • Restreignez les utilisateurs autorisés à se connecter en SSH.
  • Limitez le débit et bridez les tentatives d’échec répétées (par exemple avec fail2ban) pour émousser les attaques par force brute.
  • Gardez SSH sur une version maintenue et désactivez les chiffrements faibles et les protocoles obsolètes.

2. Exécuter un pare-feu en mode refus par défaut

  • Configurez le pare-feu (nftables, ufw, firewalld ou CSF) pour refuser par défaut et n’autoriser que les ports que vous servez réellement.
  • Exposez le minimum : généralement SSH (restreint), HTTP et HTTPS pour un serveur web, et rien d’autre.
  • Restreignez les ports d’administration à des adresses source connues ou à un VPN lorsque c’est possible.

3. Minimiser la surface d’attaque

  • Désinstallez ou désactivez les services et daemons que vous n’utilisez pas. Chaque service à l’écoute est un point d’entrée potentiel.
  • Auditez les ports ouverts (ss -tulpn) et confirmez que chacun est intentionnel.
  • Retirez les paquets et compilateurs inutiles des hôtes de production.

4. Maintenir le système à jour

  • Activez les mises à jour de sécurité automatiques (unattended-upgrades sous Debian/Ubuntu, dnf-automatic sur les systèmes de la famille RHEL).
  • Suivez les dates de fin de vie de votre distribution et mettez à niveau avant la fin du support. Faire tourner un système d’exploitation non pris en charge est un risque permanent.

5. Durcir les comptes et les accès

  • Imposez des politiques de mots de passe et de comptes robustes, et supprimez les comptes inutilisés.
  • Utilisez sudo avec le moindre privilège plutôt qu’un accès root partagé, et journalisez l’usage de sudo.
  • Définissez des valeurs umask par défaut raisonnables et verrouillez les permissions des fichiers sensibles.
  • Envisagez une authentification à deux facteurs pour les accès d’administration.

6. Appliquer un durcissement du noyau et du réseau

  • Ajustez les paramètres sysctl pour réduire le risque au niveau réseau (par exemple en désactivant le routage à la source IP et les redirections ICMP, et en activant le filtrage par chemin inverse).
  • Restreignez l’accès aux journaux et aux pointeurs du noyau, et activez les mitigations d’exploitation disponibles.
  • Désactivez les modules du noyau et les systèmes de fichiers inutilisés.

7. Activer le contrôle d’accès obligatoire

  • Gardez SELinux (famille RHEL) ou AppArmor (Debian/Ubuntu) activé et en mode enforcing.
  • Résistez à la tentation de le désactiver pour “faire marcher les choses” ; ajustez ou écrivez plutôt une politique. Le MAC contient les dégâts lorsqu’un service est compromis.

8. Journalisation, audit et intégrité des fichiers

  • Activez le daemon d’audit de Linux (auditd) pour enregistrer les événements pertinents pour la sécurité.
  • Centralisez les journaux hors de l’hôte afin qu’un attaquant ne puisse pas simplement les effacer.
  • Déployez une surveillance de l’intégrité des fichiers (par exemple AIDE) pour détecter les changements inattendus dans les fichiers système.
  • Examinez les journaux régulièrement, ou alimentez-en la surveillance et les alertes.

9. Se mesurer au CIS Benchmark

Le Center for Internet Security (CIS) publie des benchmarks de durcissement détaillés et spécifiques à chaque distribution. Utilisez le CIS Benchmark de votre système d’exploitation comme liste de contrôle objective et analyse des écarts ; il transforme “on pense que c’est durci” en une base de référence mesurable que vous pouvez auditer dans le temps.

Points clés à retenir

  • Commencez par SSH : clés uniquement, pas de connexion root, limitation de débit.
  • Pare-feu en mode refus par défaut et suppression de chaque service dont vous n’avez pas besoin.
  • Automatisez les correctifs et appliquez un durcissement des comptes, du noyau et du MAC (SELinux/AppArmor).
  • Activez l’audit des journaux et l’intégrité des fichiers, et évaluez-vous par rapport au CIS pour rendre le durcissement mesurable.

Obtenez un durcissement de serveur Linux par des experts

Durcir un seul serveur à la main est faisable ; le faire de manière cohérente sur tout un parc, sans casser les applications, c’est là que l’expertise porte ses fruits. Le service de durcissement de serveur Linux couvre le verrouillage SSH, l’architecture du pare-feu, le réglage du noyau, la politique SELinux/AppArmor, l’analyse des écarts CIS et un runbook de maintenance. Pour une présentation axée sur le pare-feu, le guide de sécurisation des serveurs Linux avec CSF , plus ancien mais toujours utile, couvre ConfigServer Security & Firewall en profondeur.

Foire aux questions (FAQ)

Quelle est l’étape de durcissement Linux la plus importante ? Verrouiller SSH : utilisez une authentification par clé, désactivez la connexion par mot de passe et la connexion root directe, et limitez le débit des tentatives échouées. SSH est le point d’entrée le plus fréquemment attaqué sur un serveur exposé à internet.

Dois-je désactiver SELinux ou AppArmor pour résoudre un problème ? Non. Désactiver le contrôle d’accès obligatoire supprime une couche majeure de confinement. Ajustez ou écrivez plutôt une politique pour autoriser le comportement légitime. Le maintenir en mode enforcing limite les dégâts si un service est compromis.

Qu’est-ce que le CIS Benchmark ? Un standard de durcissement détaillé et spécifique à chaque distribution, publié par le Center for Internet Security. Il vous donne une liste de contrôle objective pour vous configurer et auditer vos serveurs dans le temps, rendant le durcissement mesurable.

Ai-je encore besoin d’un pare-feu si mon hébergeur a un pare-feu réseau ? Oui, utilisez les deux. Un pare-feu basé sur l’hôte, en mode refus par défaut, protège le serveur même si les contrôles réseau sont mal configurés ou contournés, et il applique le principe de n’exposer que les ports que vous servez réellement.

À quelle fréquence un serveur durci doit-il être revu ? Régulièrement, car les configurations dérivent et de nouvelles vulnérabilités apparaissent. Revérifiez par rapport à votre base de référence CIS après des changements importants et selon un calendrier périodique, et gardez les mises à jour de sécurité automatiques activées entre-temps.