Sécuriser un serveur Linux : les étapes essentielles
En résumé : Au 5 septembre 2026, le durcissement minimal d’un serveur Linux consiste à installer les correctifs de sécurité, n’exposer que les ports indispensables, imposer des clés SSH et surveiller les échecs d’authentification. Commencez par ces contrôles, puis adaptez le CIS Benchmark à votre distribution et à la fonction du serveur. Ne copiez jamais une checklist sans tester l’accès et les services après chaque changement.
Après des années à déployer et maintenir des serveurs Linux, je privilégie une approche progressive. Chaque mesure doit réduire la surface d’attaque sans interrompre l’administration ni l’application hébergée.
Quel est le durcissement minimal d’un serveur Linux ?
Commencez par inventorier les comptes, les services actifs et les ports réellement nécessaires. Sauvegardez les configurations avant de les modifier et appliquez les changements un par un.
Le CIS Benchmark pour Ubuntu Linux fournit une référence de configuration issue d’un processus communautaire. Ce n’est pas une recette universelle : sélectionnez les recommandations compatibles avec le rôle du serveur, puis vérifiez leur effet.
Comment sécuriser l’accès SSH ?
Utilisez des clés SSH, interdisez la connexion directe de root et désactivez les mots de passe seulement après avoir testé l’accès par clé dans une seconde session. Sur Ubuntu, placez vos réglages dans un fichier de /etc/ssh/sshd_config.d/ afin de les séparer de la configuration fournie par le système :
# /etc/ssh/sshd_config.d/99-hardening.conf
PermitRootLogin no
PasswordAuthentication noValidez toujours la syntaxe avant de redémarrer le service. Gardez la session courante ouverte jusqu’à ce qu’une nouvelle connexion réussisse :
sudo sshd -t
sudo systemctl restart ssh.serviceChanger le port SSH peut réduire le bruit des robots, mais ne constitue pas une protection principale. La documentation OpenSSH d’Ubuntu détaille les fichiers de configuration, les clés et les précautions à prendre pour éviter une perte d’accès.
Comment limiter les services exposés avec un pare-feu ?
Appliquez une politique restrictive, puis ouvrez uniquement les services nécessaires. Pour un serveur web Ubuntu administré par SSH :
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseAdaptez ces règles à votre application avant d’activer le pare-feu. La documentation du pare-feu Ubuntu confirme que ufw est l’interface par défaut d’Ubuntu pour un pare-feu local et explique comment limiter une règle à une adresse ou à un réseau.
Comment automatiser les mises à jour de sécurité ?
Sur Ubuntu, unattended-upgrades applique automatiquement les mises à jour de sécurité et conserve ses journaux dans /var/log/unattended-upgrades :
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgradesContrôlez les origines autorisées et les redémarrages selon vos contraintes d’exploitation. La documentation Ubuntu sur les mises à jour automatiques précise aussi qu’un dépôt tiers ajouté au système n’est pas automatiquement inclus.
Quand faut-il installer Fail2ban ?
Fail2ban est utile lorsqu’un service exposé produit des journaux d’échecs d’authentification exploitables. Il peut alors mettre à jour les règles du pare-feu pour bloquer les adresses qui provoquent des échecs répétés :
sudo apt install fail2ban
sudo systemctl enable --now fail2banVérifiez que la prison correspondant à votre service est réellement active et que les journaux attendus sont disponibles. La fiche officielle du paquet Debian Fail2ban décrit son fonctionnement, ses filtres et sa prise en charge des pare-feu courants. Fail2ban complète les clés SSH et le pare-feu ; il ne les remplace pas.
Comment maintenir le durcissement dans le temps ?
Le durcissement initial perd de sa valeur sans suivi. Revoyez régulièrement les comptes, les ports ouverts, les services activés, les mises à jour en attente et les alertes d’authentification. Testez aussi la restauration des sauvegardes et documentez chaque exception à votre référence de sécurité.
Conclusion
La sécurité est un processus continu. Commencez par les mises à jour, un pare-feu restrictif, des clés SSH et une surveillance exploitable. Ajoutez ensuite les contrôles adaptés aux données, au niveau d’exposition et aux obligations de votre serveur, sans appliquer aveuglément une checklist générique.
Sources
Questions fréquentes
Quel est le durcissement minimal d’un serveur Linux ?
Appliquez les mises à jour de sécurité, limitez les services exposés avec un pare-feu, sécurisez SSH par clés et surveillez les tentatives de connexion. Adaptez ensuite une référence comme le CIS Benchmark au rôle réel du serveur.
Faut-il désactiver les mots de passe SSH ?
Oui, si chaque administrateur dispose d’une clé testée et d’un accès de secours. Validez la configuration et gardez votre session actuelle ouverte avant de redémarrer SSH afin d’éviter de vous verrouiller dehors.
Fail2ban remplace-t-il un pare-feu ?
Non. Le pare-feu limite les services accessibles, tandis que Fail2ban analyse les journaux et peut bloquer les adresses qui multiplient les échecs d’authentification. Les deux protections sont complémentaires.
Changer le port SSH suffit-il à sécuriser un serveur ?
Non. Un port différent peut réduire le bruit automatisé, mais il ne remplace ni les clés SSH, ni l’interdiction de la connexion root, ni le filtrage réseau et les mises à jour.