Un serveur Linux fraîchement installé expose déjà des services réseau, un compte root actif et des paramètres par défaut pensés pour la compatibilité, pas pour la sécurité. Chaque service en écoute, chaque port ouvert et chaque permission trop large représentent un point d’entrée potentiel. Protéger un système Linux commence par réduire cette surface d’attaque avant même de penser aux outils de détection.
Vérifier le noyau Linux réellement actif après une mise à jour
Appliquer les correctifs de sécurité du noyau ne suffit pas toujours. Tant que le système n’a pas redémarré, c’est l’ancienne version du noyau qui tourne en mémoire. Vous venez d’installer un patch critique, mais la version vulnérable reste active sans redémarrage.
Pour vérifier, comparez la sortie de uname -r avec le dernier noyau installé par votre gestionnaire de paquets. Si les deux diffèrent, le correctif n’est pas encore opérationnel.
Le live patching (proposé par certaines distributions) peut réduire les interruptions en appliquant des correctifs à chaud. Il ne couvre pas toutes les failles et ne remplace pas systématiquement un redémarrage complet. Sur un serveur de production, planifier un redémarrage après chaque mise à jour majeure du noyau reste la méthode la plus fiable. Plusieurs ressources compilent les alertes de sécurité récentes pour les distributions courantes, comme le site Hebdo Linux sur la sécurité qui référence les correctifs par distribution.
Les failles locales du noyau servent souvent à élever les privilèges après une première compromission. Un attaquant qui obtient un accès limité via une application web mal configurée peut exploiter un noyau non patché pour devenir root. Limiter les comptes locaux réduit ce risque d’escalade.
Configuration SSH durcie : au-delà du changement de port
Changer le port SSH par défaut ralentit les scans automatisés, sans plus. La vraie protection passe par la configuration du démon lui-même.
Avez-vous déjà regardé les logs d’authentification d’un serveur exposé sur Internet ? Des centaines de tentatives de connexion par heure visent le compte root avec des mots de passe courants. Désactiver l’accès root direct via SSH (PermitRootLogin no dans sshd_config) coupe ce vecteur d’attaque.
Voici les paramètres à vérifier en priorité dans votre configuration SSH :
- Authentification par clé publique uniquement : désactivez les mots de passe (
PasswordAuthentication no) une fois vos clés déployées, pour bloquer le brute force - Restreindre les utilisateurs autorisés avec la directive
AllowUsersplutôt que de laisser tous les comptes système tenter une connexion - Limiter les algorithmes de chiffrement aux plus récents en excluant les anciens (comme CBC) via
CiphersetMACs - Fixer un délai d’inactivité avec
ClientAliveIntervaletClientAliveCountMaxpour fermer les sessions abandonnées
Chaque paramètre modifié dans sshd_config nécessite un rechargement du service. Testez toujours depuis une seconde session ouverte pour éviter de vous verrouiller.
Gestion des services et réduction de la surface d’attaque Linux
Un système Linux standard active par défaut des services dont vous n’avez probablement pas besoin. Un serveur web n’a aucune raison de faire tourner un serveur d’impression ou un agent Bluetooth.
Listez les services actifs avec systemctl list-units --type=service --state=running. Chaque ligne représente un processus en écoute, un jeu de dépendances et un risque potentiel. Désactivez tout service que votre usage ne justifie pas.
La même logique s’applique aux ports réseau. Un ss -tlnp affiche les ports en écoute et le processus associé. Si un port ne correspond à aucun service légitime, c’est un reste d’installation à nettoyer.
Pare-feu et filtrage réseau
Un pare-feu bien configuré n’autorise que le trafic attendu. Sur les distributions récentes, nftables remplace progressivement iptables. Le principe reste identique : bloquer tout par défaut, puis ouvrir uniquement les ports nécessaires.
Un serveur web typique n’a besoin que des ports 80, 443 et de votre port SSH. Tout le reste se ferme. Cette approche « deny all, allow specific » transforme votre politique de sécurité réseau d’une passoire en filtre actif.
Droits d’accès et sudo : le principe du moindre privilège
Pourquoi ce principe ? Parce qu’un compte utilisateur compromis avec des droits larges donne à l’attaquant exactement ces mêmes droits. Configurer sudo avec précision limite les dégâts en cas d’intrusion.
Plutôt que d’ajouter un utilisateur au groupe sudo avec tous les droits, définissez dans /etc/sudoers (via visudo) les commandes spécifiques autorisées. Un administrateur de base de données n’a pas besoin de redémarrer le pare-feu.
- Attribuez à chaque rôle uniquement les commandes
sudodont il a besoin, pas un accèsALL=(ALL) ALL - Activez la journalisation des commandes
sudopour garder une trace de chaque action privilégiée - Vérifiez régulièrement les fichiers dans
/etc/sudoers.d/: des règles oubliées après un départ peuvent persister des mois
Un fichier sudoers trop permissif équivaut à ne pas avoir de séparation des privilèges. Auditez-le au moins une fois par trimestre.
Permissions des fichiers et répertoires sensibles
Les fichiers de configuration système (/etc/shadow, /etc/ssh/sshd_config, les clés privées) méritent des permissions strictes. Un chmod 600 sur les clés privées SSH et un chmod 640 sur /etc/shadow empêchent la lecture par des comptes non autorisés.
Lancez périodiquement une recherche des fichiers avec le bit SUID activé (find / -perm -4000). Ce bit permet à un programme de s’exécuter avec les droits de son propriétaire, souvent root. Chaque binaire SUID inutile est un vecteur d’escalade de privilèges en attente.
Le guide ANSSI-BP-028, publié par l’ANSSI et dédié aux recommandations de configuration d’un système GNU/Linux, détaille ces points avec des niveaux de durcissement adaptés au contexte (minimal, intermédiaire, renforcé). Adapter le niveau de durcissement au rôle réel du serveur évite de casser des applications en appliquant des restrictions trop strictes pour l’usage prévu. Les conteneurs, par exemple, peuvent dépendre de fonctions du noyau (comme les espaces de noms utilisateur non privilégiés) qu’une politique trop agressive désactiverait.
La sécurité Linux n’est pas un état figé. Les correctifs du noyau, la revue des services actifs, l’audit du fichier sudoers et la vérification des permissions forment un cycle à répéter. Un serveur durci en janvier avec des règles jamais revues en juin redevient une cible.
