Un système Linux fraîchement installé n’est pas un système sécurisé. Les distributions grand public livrent des configurations pensées pour fonctionner vite, pas pour résister à une tentative d’intrusion. Renforcer la sécurité de votre système Linux au quotidien repose sur quelques gestes précis, répétés régulièrement, qui réduisent la surface d’attaque sans transformer votre poste en forteresse inutilisable.
Sandboxing systemd : confiner chaque service Linux individuellement
La plupart des guides de sécurité Linux parlent de comptes utilisateurs et de permissions de fichiers. Moins abordé : le confinement des services eux-mêmes. Un serveur web ou un gestionnaire de bases de données tourne souvent avec des droits bien plus larges que ce dont il a besoin.
Vous avez déjà remarqué qu’un service compromis peut lire des fichiers qui n’ont rien à voir avec sa fonction ? C’est exactement ce que le sandboxing systemd corrige. Trois directives changent la donne :
- ProtectSystem=strict monte le système de fichiers racine en lecture seule pour le service concerné, ce qui empêche toute modification en dehors des dossiers explicitement autorisés.
- PrivateTmp=true attribue un répertoire temporaire isolé au service, invisible des autres processus. Un attaquant qui accède au /tmp du service ne voit pas celui du système.
- NoNewPrivileges=true bloque toute escalade de privilèges après le démarrage du service, même si un binaire setuid est présent dans le chemin d’exécution.
Ces options se configurent dans le fichier unit du service, section [Service]. Après chaque modification, redémarrez le service puis vérifiez son fonctionnement normal. Une directive trop restrictive peut bloquer un accès légitime à un socket ou un fichier de configuration.
Pour approfondir cette approche et d’autres méthodes de durcissement, les conseils de sécurité de Hebdo Linux détaillent plusieurs scénarios adaptés aux postes de travail comme aux serveurs.
Vérifier l’état réel de SELinux et AppArmor sur votre système
Avoir SELinux ou AppArmor installé ne signifie pas que ces mécanismes protègent quoi que ce soit. Pourquoi ce point est si souvent négligé ? Parce que la présence d’un module de sécurité dans le noyau donne une fausse impression de protection.
Un module de sécurité inactif ne protège aucun processus. Sur une distribution comme Ubuntu, AppArmor est présent par défaut, mais tous les profils ne sont pas en mode « enforce ». Certains tournent en mode « complain », qui se contente de journaliser les infractions sans les bloquer.
Commandes de vérification concrètes
Pour AppArmor, la commande aa-status affiche la liste des profils chargés et leur mode. Chaque profil en mode « complain » est une porte ouverte. Pour SELinux, sestatus indique si le mode est « enforcing », « permissive » ou « disabled ».
Contrôler ces états fait partie des vérifications quotidiennes utiles. Un script lancé par cron ou un timer systemd peut envoyer une alerte si le mode passe en permissive après un redémarrage ou une mise à jour du noyau. Ce type de régression silencieuse est fréquent lors des montées de version.
Correctifs Linux : vérifier que la mise à jour est réellement active
Installer un correctif ne suffit pas. Après une mise à jour du noyau, votre machine peut continuer à tourner sur l’ancien noyau tant qu’elle n’a pas redémarré. Le gestionnaire de paquets affiche « à jour », mais le système reste vulnérable.
Vérifiez le noyau actif après chaque mise à jour critique. La commande uname -r affiche la version du noyau en cours d’exécution. Comparez-la avec la dernière version installée, visible via votre gestionnaire de paquets. Si les deux diffèrent, un redémarrage est nécessaire.
Gestion des correctifs sur un serveur en production
Sur un serveur, le redémarrage n’est pas toujours immédiat. Documentez l’écart entre le noyau installé et le noyau actif. Certaines distributions proposent un mécanisme de « live patching » qui applique des correctifs au noyau sans redémarrage, mais ce mécanisme ne couvre pas tous les types de vulnérabilités.
Un point souvent oublié : les entrées de démarrage alternatives. Si votre chargeur d’amorçage conserve d’anciens noyaux, un redémarrage accidentel sur une entrée obsolète réintroduit les failles corrigées. Nettoyez régulièrement les anciens noyaux de votre liste de démarrage après avoir confirmé la stabilité du nouveau.
Réduire la surface réseau exposée au quotidien
Chaque port ouvert est un point d’entrée potentiel. Sur un poste de travail Linux, des services comme CUPS (impression), Avahi (découverte réseau) ou un serveur SSH peuvent écouter sans que vous en ayez conscience.
La commande ss -tlnp liste tous les ports en écoute avec le processus associé. Passez cette liste en revue :
- Un service que vous n’utilisez pas (Avahi sur un poste sans imprimante réseau, par exemple) se désactive via
systemctl disable --nowsuivi du nom du service. - Un serveur SSH exposé sur le port standard (22) bénéficie d’une restriction par clé publique plutôt que par mot de passe. Désactivez l’authentification par mot de passe dans
/etc/ssh/sshd_configavecPasswordAuthentication no. - Le pare-feu nftables (ou iptables selon votre distribution) doit définir une politique par défaut de rejet du trafic entrant, avec des exceptions explicites pour les seuls services nécessaires.
Moins de services en écoute signifie moins de surface d’attaque à surveiller. Ce tri prend quelques minutes et réduit considérablement le risque d’exploitation à distance.
La sécurisation d’un système Linux n’est pas un événement ponctuel. Confiner les services, vérifier que les modules de sécurité sont actifs, confirmer que les correctifs tournent réellement et fermer les ports inutiles forment un cycle court. Répété chaque semaine, ce cycle couvre la majorité des vecteurs d’attaque courants sur un poste ou un serveur Linux.
