Checklist ultime de sécurisation d'un serveur Linux en production

Lorsqu'un administrateur système ou une équipe DevOps déploie un nouveau serveur Linux (qu'il s'agisse d'une instance Debian ou Ubuntu sur le cloud, d'un VPS hébergé ou d'une machine physique en datacenter), la configuration par défaut fournie par l'hébergeur ou l'installateur privilégie systématiquement la facilité d'accès et la polyvalence au détriment de la sécurité. Laisser un serveur dans cet état initial, même pendant quelques heures, revient à l'exposer à des vagues massives de scans automatisés et d'attaques par force brute orchestrées par des botnets à l'échelle mondiale.

Sécuriser un serveur Linux (processus que l'on nomme le *hardening*) ne se résume pas à installer un antivirus ou à appliquer un correctif à la volée. C'est une démarche méthodique, rigoureuse et structurée qui doit s'appliquer dès les premières minutes de mise en service et se maintenir tout au long du cycle de vie de l'infrastructure. Dans cet article complet, nous vous proposons une checklist technique exhaustive et pas à pas pour verrouiller vos serveurs Linux de production.

1. La phase initiale : Gestion des utilisateurs et isolation des privilèges

La toute première vulnérabilité d'un système fraîchement installé réside dans la gestion de ses comptes utilisateurs. Par défaut, de nombreux environnements encouragent l'utilisation directe du compte administrateur suprême (`root`) pour effectuer toutes les manipulations courantes, qu'il s'agisse de créer des dossiers, de modifier des fichiers de configuration ou de lancer des installations de paquets.

Cette habitude est extrêmement dangereuse. Si un attaquant parvient à compromettre votre session active ou à exploiter une faille applicative exécutée sous les privilèges de root, il obtient instantanément le contrôle total et absolu de la machine. La première règle d'or consiste à créer un compte utilisateur nominatif non privilégié et à confiner l'usage de root à sa plus simple expression.

# Créer un utilisateur administrateur dédié (remplacer 'admin-owl' par votre identifiant)
sudo adduser admin-owl

# Ajouter cet utilisateur au groupe sudo pour l'élévation de privilèges
sudo usermod -aG sudo admin-owl

Une fois votre utilisateur créé, configurez un outil d'élévation de privilèges comme `sudo` en exigeant systématiquement la saisie d'un mot de passe robuste, et désactivez la possibilité d'ouvrir une session interactive directe sur le compte `root` depuis le réseau.

2. Durcissement radical du service SSH

Le service SSH (Secure Shell) est la porte d'entrée principale et indispensable pour administrer un serveur Linux à distance. C'est pour cette raison qu'il constitue également la cible privilégiée des attaquants. Lisser le port 22 ouvert sur Internet avec une authentification autorisant les mots de passe est une invitation ouverte au piratage.

Le durcissement du service SSH repose sur trois piliers indissociables : l'abandon total des mots de passe au profit des clés cryptographiques, l'interdiction de connexion directe pour root, et éventuellement le déplacement du port d'écoute standard pour réduire le bruit des scans automatisés.

# Générer une paire de clés SSH robuste de type Ed25519 depuis votre poste client
ssh-keygen -t ed25519 -C "admin@owl-systems.com"

# Copier votre clé publique sur le serveur cible
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin-owl@votre_ip_serveur

Ensuite, connectez-vous au serveur avec votre clé et éditez le fichier de configuration du démon SSH (`/etc/ssh/sshd_config`) pour appliquer les directives de sécurité indispensables :

# Paramètres essentiels de durcissement dans /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

Ne redémarrez jamais le service SSH sans avoir vérifié dans un second terminal distinct que votre connexion par clé fonctionne parfaitement, sous peine de vous verrouiller définitivement hors de votre propre serveur.

3. Mise en place d'un pare-feu strict avec UFW

Un serveur ne doit accepter que les flux réseau strictement nécessaires à son rôle métier. Tout le reste doit être bloqué par défaut. Sous Debian et Ubuntu, l'outil **UFW (Uncomplicated Firewall)** simplifie la gestion des règles de filtrage en s'appuyant sur le noyau Linux.

Appliquez la politique du moindre privilège en interdisant tout trafic entrant par défaut, puis autorisez uniquement les ports requis (par exemple SSH, HTTP et HTTPS) :

# Configuration de la politique par défaut UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Autoriser les services légitimes
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Activer le pare-feu
sudo ufw enable

Si votre serveur héberge une base de données (MySQL, PostgreSQL, Redis), le port associé ne doit **jamais** figurer dans les règles d'ouverture publique : il doit rester confiné à l'interface de bouclage local (`127.0.0.1`) ou à un réseau privé virtuel (VLAN).

4. Automatisation de la riposte anti-bruteforce avec Fail2ban

Même après avoir désactivé l'authentification par mot de passe sur SSH, les robots malveillants continueront d'harceler votre port SSH en testant des milliards de connexions par force brute. Bien que ces attaques soient vouées à l'échec, elles polluent vos fichiers de journaux et consomment des ressources système inutiles.

L'installation de **Fail2ban** permet d'automatiser la protection. Le service analyse en temps réel les fichiers de logs (`/var/log/auth.log`) et dialogue directement avec votre pare-feu UFW pour bannir dynamiquement toute adresse IP accumulant un nombre suspect d'échecs d'authentification.

# Installation et activation de Fail2ban
sudo apt update && sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo systemctl enable --now fail2ban

5. Gestion rigoureuse des paquets et des mises à jour (Patch Management)

Un système d'exploitation n'est jamais figé : des failles de sécurité (CVE) sont découvertes chaque semaine dans les bibliothèques logiques et les noyaux Linux. Maintenir un parc à jour est une obligation vitale.

Configurez l'outil de gestion des paquets `apt` pour automatiser l'application des correctifs de sécurité critiques, et auditez régulièrement la liste des paquets installés pour supprimer tout logiciel superflus qui augmenterait inutilement la surface d'attaque de la machine.

# Installer le paquet de gestion des mises à jour automatiques de sécurité
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Une politique de mise à jour proactive et planifiée réduit de manière drastique la fenêtre d'opportunité des attaquants exploitant des vulnérabilités connues.

6. Durcissement du système de fichiers et des permissions

Le stockage et l'arborescence des fichiers sur le disque doivent faire l'objet d'une attention particulière :

• **Cloisonnement des partitions :** Séparez les répertoires sensibles (`/var`, `/tmp`, `/home`) sur des partitions logiques distinctes pour éviter qu'une saturation de l'espace disque par un fichier de log ou un cache ne bloque l'ensemble du système d'exploitation. • **Permissions strictes :** Assurez-vous que les fichiers de configuration sensibles (comme `/etc/passwd` ou les fichiers de configuration web contenant des identifiants de base de données) disposent de permissions en lecture restreinte (640 ou 600). • **Sécurisation de /tmp :** Montez le répertoire temporaire avec les options `noexec`, `nosuid` et `nodev` pour empêcher l'exécution de scripts malveillants par des processus non privilégiés.

7. Supervision, intégrité et audit final

La sécurisation d'un serveur Linux n'est pas une action ponctuelle à usage unique, c'est un processus dynamique. Une fois le durcissement initial achevé, vous devez mettre en place les outils nécessaires pour surveiller l'intégrité de votre machine en continu :

• **FIM (File Integrity Monitoring) :** Utilisez des outils comme Wazuh ou Aide pour détecter immédiatement toute modification non autorisée sur les fichiers système critiques. • **Supervision externe :** Installez des sondes de monitoring (Prometheus, Uptime Kuma) pour suivre la charge, l'espace disque et la validité des certificats TLS. • **Audits réguliers :** Soumettez périodiquement votre configuration à des scripts d'audit automatisés (comme `Lynis`) pour identifier les dérives de configuration au fil du temps.

# Lancer un audit de sécurité automatisé du système avec Lynis
sudo apt install lynis -y
sudo lynis audit system

En appliquant rigoureusement cette checklist de sécurisation post-installation, vous éliminez la quasi-totalité des risques d'intrusion automatisée et dotez votre infrastructure d'un socle technique robuste, pérenne et prêt à affronter les exigences de la production moderne.