Un système Linux, même réputé robuste, n’est pas immunisé par défaut contre les attaques. La sécurité Linux repose sur un ensemble de configurations, de règles d’accès et de mécanismes de surveillance qui doivent être activés et maintenus manuellement. Sans intervention, un serveur ou un poste fraîchement installé expose des services inutiles, des ports ouverts et des comptes aux permissions trop larges.
Priorisation des correctifs kernel : le vrai défi de la sécurité Linux
Les concurrents répètent tous qu’il faut mettre à jour son système. Le conseil reste valable, mais la réalité a changé. En 2024, le noyau Linux a enregistré 3 108 CVE, soit une hausse d’environ 79 % par rapport aux 1 736 CVE de 2023, selon la base NVD du NIST.
Cette explosion n’indique pas une dégradation du code. Elle résulte de l’amélioration des outils d’analyse automatisés, dont certains exploitent l’intelligence artificielle pour scanner les quelque 40 millions de lignes du noyau. Depuis février 2024, le noyau Linux est devenu sa propre autorité de numérotation CVE (CNA), ce qui accélère la déclaration de chaque faille détectée.
Pour un administrateur, appliquer aveuglément chaque correctif publié revient à courir après un flux quasi continu de mises à jour. La bonne approche consiste à trier les CVE par score CVSS et par exposition réelle du système. Une faille critique sur un module réseau chargé en production mérite un correctif immédiat. Une vulnérabilité sur un pilote matériel absent de la machine peut attendre le prochain cycle de maintenance.
Pour suivre ces évolutions et comprendre leur impact concret, les informations de sécurité sur Hebdo Linux détaillent régulièrement les correctifs kernel et les alertes associées aux distributions majeures.
Réduction de la surface d’attaque sur un serveur Linux
Le durcissement système (hardening) vise à supprimer tout ce qui n’a pas de raison d’exister sur la machine. Chaque service actif, chaque port ouvert et chaque paquet installé représente un point d’entrée potentiel pour un attaquant.
Services et paquets inutiles
Après une installation standard, plusieurs services tournent sans que personne ne les ait demandés : serveur d’impression (CUPS), Avahi pour la découverte réseau locale, ou encore un agent de messagerie (Postfix, Exim). Sur un serveur de production, ces composants n’ont aucune utilité et élargissent la surface d’attaque. La commande systemctl list-unit-files –state=enabled permet d’identifier précisément ce qui démarre automatiquement.
Désactiver un service ne suffit pas toujours. Si le paquet reste installé, une réactivation accidentelle ou une exploitation locale reste envisageable. Supprimer le paquet entier est la méthode la plus fiable.
Configuration réseau et pare-feu
Un pare-feu correctement configuré constitue la première barrière entre le réseau et les services internes. Sur les distributions récentes, nftables remplace progressivement iptables. La logique reste identique : bloquer tout le trafic entrant par défaut, puis ouvrir uniquement les ports nécessaires.
- Autoriser le port 22 (SSH) uniquement depuis des adresses IP connues, jamais depuis l’ensemble d’internet.
- Fermer les ports liés aux bases de données (3306 pour MySQL, 5432 pour PostgreSQL) sur l’interface publique et ne les exposer que sur l’interface locale ou un réseau privé.
- Activer la journalisation des paquets rejetés pour détecter les tentatives de scan.
Contrôle des utilisateurs et escalade de privilèges
La gestion des comptes utilisateurs détermine qui peut faire quoi sur le système. Un compte root utilisé au quotidien reste l’une des erreurs les plus courantes, y compris sur des machines administrées par des profils techniques.
Sudo doit remplacer toute connexion directe en root. Chaque commande exécutée via sudo est journalisée avec l’identité de l’utilisateur, ce qui crée une trace d’audit exploitable en cas d’incident. Le fichier /etc/sudoers permet de restreindre les commandes autorisées par utilisateur ou par groupe.
Au-delà de sudo, les modules de contrôle d’accès obligatoire comme SELinux (distributions Red Hat, Fedora) ou AppArmor (Ubuntu, Debian) ajoutent une couche de restriction par processus. Même si un attaquant compromet un service, le module l’empêche d’accéder à des fichiers ou des répertoires en dehors du périmètre défini par la politique de sécurité.
- Appliquer le principe du moindre privilège : chaque utilisateur ne dispose que des droits nécessaires à sa tâche.
- Désactiver les comptes inutilisés plutôt que de les laisser dormants avec un mot de passe faible.
- Configurer une expiration automatique des mots de passe via chage pour forcer un renouvellement périodique.
- Vérifier régulièrement les fichiers /etc/passwd et /etc/group pour repérer les comptes ou groupes inattendus.
Journalisation et détection des comportements anormaux sur Linux
Un système peut être compromis pendant des semaines sans que personne ne s’en aperçoive si les logs ne sont ni centralisés ni surveillés. La journalisation ne sert pas uniquement à l’analyse post-incident : bien exploitée, elle permet de détecter une intrusion en cours.
Le journal systemd (journalctl) centralise les événements système, mais sa rotation par défaut peut effacer des traces avant qu’elles ne soient analysées. Exporter les logs vers un serveur distant (via rsyslog ou syslog-ng) garantit qu’un attaquant ayant obtenu un accès root ne puisse pas supprimer ses propres traces localement.
Pour aller plus loin, des outils comme auditd permettent de surveiller des événements précis : modification d’un fichier de configuration sensible, ajout d’un utilisateur, changement de permissions sur un répertoire critique. Chaque règle d’audit génère une entrée horodatée exploitable pour reconstituer la chronologie d’un incident.
La combinaison d’un pare-feu strict, d’un contrôle d’accès granulaire et d’une journalisation exportée couvre les trois axes de la sécurité Linux : prévention, restriction et détection. Négliger l’un de ces axes revient à laisser une porte ouverte, même si les deux autres sont verrouillés.
