Durcissement Linux : 15 mesures prioritaires serveur

Un serveur Linux fraîchement déployé n’est pas durablement sécurisé parce qu’il démarre, répond en SSH et héberge une application. Le durcissement consiste à réduire, vérifier et surveiller les capacités réellement offertes par la machine : comptes pouvant administrer, services à l’écoute, logiciels installés, chemins de privilèges, données accessibles et traces disponibles après un incident. Cette approche va donc plus loin qu’un article général de sécurité : elle impose un ordre d’exécution, des contrôles de validation et une gestion explicite des compromis entre sécurité, disponibilité et exploitation.

Le principe directeur est celui du moindre privilège. Le NIST résume l’objectif ainsi : corriger les faiblesses connues et n’offrir à chaque utilisateur que les fonctions nécessaires, afin de donner le moins d’occasions possibles à un attaquant. L’ANSSI recommande également de vérifier méthodiquement les règles de configuration au moyen d’une liste de contrôle ; son guide de configuration GNU/Linux couvre notamment les services, les privilèges, le noyau et l’isolation. ([nvlpubs.nist.gov](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf?utm_source=openai))

Les 15 mesures ci-dessous visent un VPS ou un serveur dédié connecté à Internet. Elles doivent être adaptées à la distribution, à l’application et au plan de reprise. Avant toute modification distante, conservez une session d’administration ouverte, vérifiez l’accès à la console hors bande ou au panneau du fournisseur, documentez l’état initial et préparez un retour arrière. Une règle de sécurité qui coupe le seul accès administrateur ne constitue pas un durcissement réussi.

Priorité 0 : fermer les accès évidents avant de publier le service

Cette première séquence doit être réalisée avant, ou immédiatement après, l’exposition publique. Elle cible les vecteurs les plus directs : connexion distante, comptes d’administration, correctifs et ports réseau.

1. Inventorier l’exposition réelle. Relevez l’adresse IP, les interfaces, les ports TCP et UDP en écoute, les unités systemd actives, les paquets installés et les comptes disposant d’un shell. La question utile n’est pas seulement « quel pare-feu est installé ? », mais « quel processus écoute sur quelle interface, pour quel besoin métier ? ». Conservez cet inventaire comme référence avant chaque changement. Le sous-système netfilter du noyau Linux sert à décider du devenir du trafic entrant ou traversant le serveur : le filtrage ne remplace donc pas la nécessité de supprimer les services inutiles. ([ubuntu.com](https://ubuntu.com/server/docs/security-firewall/?utm_source=openai))
2. Créer un compte nominatif d’administration et sortir du compte root. Chaque administrateur doit utiliser un compte personnel, avec une élévation de privilèges limitée aux tâches justifiées via sudo. Évitez les comptes partagés : ils empêchent d’attribuer correctement une action. Révisez les membres des groupes d’administration, les règles sudo et les clés SSH autorisées à chaque départ ou changement de rôle. Le moindre privilège ne signifie pas retirer arbitrairement les droits ; il signifie donner le minimum nécessaire, puis contrôler régulièrement que ce minimum reste pertinent. ([ubuntu.com](https://ubuntu.com/server/docs/explanation/security/security_suggestions/?utm_source=openai))
3. Durcir SSH avec des clés et une politique d’accès explicite. Déployez d’abord une clé publique pour chaque administrateur, dans son compte nominatif, puis testez une nouvelle connexion avant de désactiver l’authentification par mot de passe. Dans sshd_config, interdisez la connexion directe de root avec PermitRootLogin no et limitez les identités autorisées avec AllowUsers ou AllowGroups si cela correspond au modèle d’exploitation. La documentation OpenSSH indique qu’AllowUsers restreint la connexion aux noms correspondant aux motifs spécifiés ; elle documente aussi PermitRootLogin et PasswordAuthentication. Ne changez pas le port SSH comme substitut à l’authentification forte : cela peut réduire du bruit, mais ne remplace ni les clés, ni le filtrage, ni la surveillance. Après modification, validez la syntaxe avec sshd -t puis rechargez le service seulement après avoir conservé une session fonctionnelle. ([man.openbsd.org](https://man.openbsd.org/OpenBSD-6.2/sshd_config.5?utm_source=openai))
4. Appliquer les mises à jour disponibles et définir une cadence. Sur les systèmes utilisant APT, apt update actualise l’index des paquets et apt upgrade applique les mises à jour disponibles selon les règles du gestionnaire. Réservez une fenêtre de maintenance pour les composants critiques, notamment le noyau, et vérifiez si un redémarrage est demandé. Sur Ubuntu, unattended-upgrades peut appliquer automatiquement des mises à jour de sécurité ; la documentation indique que le mécanisme est déclenché par des unités systemd et que son activité est journalisée dans /var/log/unattended-upgrades. L’automatisation réduit le délai d’exposition, mais elle ne dispense pas de suivre les résultats, les redémarrages et les redémarrages de services. ([ubuntu.com](https://ubuntu.com/server/docs/how-to/software/automatic-updates/?utm_source=openai))
5. Mettre en place une politique de pare-feu restrictive. Autorisez explicitement les flux nécessaires et refusez le reste en entrée. Pour un serveur web simple, cela peut se limiter à SSH depuis des adresses d’administration connues, puis aux ports du frontal web public ; une base de données, un moteur de cache, une interface d’administration ou un export de fichiers ne doivent pas être rendus publics par défaut. UFW peut simplifier la configuration sur Ubuntu, tandis que les environnements Red Hat s’appuient couramment sur firewalld ou nftables. Testez la politique depuis un réseau externe et depuis les réseaux privés concernés, car une règle correcte sur le papier peut casser une sonde, un proxy inverse ou une sauvegarde. ([ubuntu.com](https://ubuntu.com/server/docs/security-firewall/?utm_source=openai))

Priorité 1 : réduire la surface d’attaque et contenir les abus

Après avoir sécurisé la porte d’entrée, le travail consiste à réduire ce qui peut être attaqué et à empêcher qu’une compromission limitée devienne immédiatement une prise de contrôle complète.

6. Désinstaller ou désactiver les services inutiles. Un composant non installé ou non démarré n’offre pas de port, de configuration ni de vulnérabilité exploitable sur cette machine. Examinez les unités activées au démarrage, les sockets systemd, les tâches planifiées, les agents installés par l’image du fournisseur et les démons de développement. Désactivez précisément ce qui n’est pas requis, plutôt que de supprimer à l’aveugle des dépendances de l’OS. Le NIST rattache directement la limitation des fonctionnalités disponibles à la réduction des opportunités de compromission. ([nvlpubs.nist.gov](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf?utm_source=openai))
7. Ajouter Fail2Ban comme couche de ralentissement, pas comme contrôle principal. Fail2Ban est conçu pour limiter les tentatives d’authentification par force brute à partir de l’analyse de journaux et de l’application de bannissements. Activez un jail SSH adapté aux journaux effectivement produits par la distribution, définissez une durée de bannissement cohérente et prévoyez une liste d’exclusion pour les réseaux d’administration légitimes. Vérifiez ensuite le statut avec fail2ban-client status et contrôlez qu’une règle de pare-feu est réellement créée lors d’un test maîtrisé. Fail2Ban ne corrige pas une clé volée, un mot de passe divulgué ou une vulnérabilité SSH : il complète les clés, la restriction réseau et les mises à jour. ([manpages.ubuntu.com](https://manpages.ubuntu.com/manpages/resolute/man1/fail2ban.1.html?utm_source=openai))
8. Restreindre les privilèges locaux et les permissions sensibles. Passez en revue les répertoires de déploiement, secrets applicatifs, fichiers de configuration, clés privées, scripts cron et exécutables modifiables par des utilisateurs non attendus. Évitez que le compte du service web puisse modifier le code de l’application, les unités systemd ou les fichiers d’administration. Séparez si possible comptes de déploiement, comptes de service et comptes de sauvegarde. Les permissions Unix restent indispensables, mais une couche de contrôle d’accès obligatoire peut réduire les interactions non autorisées entre processus et fichiers : SELinux est présenté par Red Hat comme une mise en œuvre de contrôle d’accès obligatoire ajoutant une couche de protection. ([docs.redhat.com](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/using_selinux/index?utm_source=openai))
9. Maintenir SELinux en mode enforcing lorsque la distribution l’utilise. Sur les distributions qui livrent SELinux, ne le désactivez pas pour régler rapidement un incident de déploiement. Le mode enforcing applique effectivement la politique chargée ; le mode permissive journalise les refus sans bloquer les opérations. Utilisez donc permissive temporairement et de façon ciblée pour diagnostiquer un problème, analysez les refus, corrigez les contextes ou règles nécessaires, puis revenez à enforcing. Cette discipline évite de transformer une difficulté de configuration en suppression permanente d’une barrière de confinement. ([docs.redhat.com](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/using_selinux/index?utm_source=openai))
10. Sécuriser les montages et l’espace temporaire. Analysez les systèmes de fichiers séparément : données applicatives, journaux, répertoires temporaires et zones de dépôt n’ont pas les mêmes besoins. Selon le cas d’usage, les options noexec, nodev et nosuid réduisent l’exécution, l’usage de périphériques ou les élévations via bits setuid sur un point de montage. Elles ne doivent toutefois pas être appliquées machinalement : certains outils et applications nécessitent des comportements que ces options empêchent. Testez en préproduction, documentez chaque exception et vérifiez les options réellement montées après redémarrage. Le chiffrement LUKS, administré par cryptsetup, protège les volumes chiffrés lorsque les supports sont hors ligne ; il ne protège pas les fichiers déjà accessibles sur un système démarré et déverrouillé. ([man7.org](https://www.man7.org/linux/man-pages/man8/cryptsetup-luksFormat.8.html?utm_source=openai))

Priorité 2 : rendre le serveur observable et récupérable

Un système durci mais opaque laisse l’équipe découvrir une compromission trop tard. Les mesures suivantes organisent les preuves, l’alerte et la capacité à restaurer réellement le service.

11. Centraliser et protéger les journaux. Vérifiez que les journaux système, SSH, applicatifs, pare-feu et proxy sont bien produits, horodatés et soumis à une rotation compatible avec la capacité disque. Expédiez-les vers une plateforme distincte lorsque l’architecture le permet : un attaquant ayant obtenu des privilèges sur le serveur ne doit pas pouvoir effacer toutes les traces locales sans difficulté. Surveillez au minimum les erreurs d’authentification, les changements de configuration, les redémarrages inattendus, l’élévation de privilèges, les règles de pare-feu et les échecs de sauvegarde. ([docs.redhat.com](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/security_hardening/security_hardening?utm_source=openai))
12. Activer un audit ciblé avec auditd. L’audit système Linux permet d’enregistrer des événements pertinents selon des règles prédéfinies, y compris la date, le résultat et l’identité associée à l’événement. Commencez par les changements sur les fichiers de comptes, sudo, SSH, unités systemd, règles de pare-feu et outils d’installation de logiciels. Une règle trop large peut produire un volume ingérable ; une règle ciblée doit répondre à une question d’investigation concrète. Red Hat recommande notamment de placer les journaux d’audit sur un point de montage séparé dans les environnements exigeants et d’empêcher l’écrasement des journaux avec l’action keep_logs. ([docs.redhat.com](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/security_hardening/security_hardening?utm_source=openai))
13. Superviser la sécurité et la disponibilité, avec alerte actionnable. Mesurez la disponibilité du service public, l’espace disque, la mémoire, la charge, l’expiration des certificats, l’état des sauvegardes, les erreurs d’authentification et le retard de correctifs. Une alerte sans destinataire, sans seuil justifié ou sans procédure de traitement produit seulement du bruit. Définissez pour chaque alerte un propriétaire, une gravité, une action immédiate et une escalade. Le contrôle des mises à jour automatiques est particulièrement important : Ubuntu précise que les opérations unattended-upgrades sont journalisées, ce qui permet de surveiller leur bon déroulement plutôt que de supposer qu’elles ont réussi. ([ubuntu.com](https://ubuntu.com/server/docs/how-to/software/automatic-updates/?utm_source=openai))
14. Construire des sauvegardes séparées, chiffrées et testées. Une sauvegarde est une capacité de restauration, pas la simple existence d’un fichier sur le même serveur. Appliquez une stratégie avec plusieurs copies, sur des supports ou services distincts, dont au moins une copie hors site ou hors ligne selon le risque. La CISA relaie la stratégie 3-2-1 : trois copies des données, sur deux types de supports, avec une copie conservée hors site. Chiffrez les sauvegardes lorsqu’elles contiennent des données sensibles, séparez les identifiants de sauvegarde des identifiants d’administration courante et limitez ce compte à l’écriture ou à l’accès strictement nécessaire. Surtout, réalisez régulièrement une restauration complète dans un environnement isolé, avec mesure du temps et vérification de l’intégrité applicative. ([cisa.gov](https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-165a?utm_source=openai))
15. Formaliser un cycle de vérification et de changement. Le durcissement n’est pas une commande unique exécutée le jour du déploiement. Créez une baseline versionnée : règles SSH, politique de pare-feu, comptes autorisés, services attendus, configuration de journalisation, agents de supervision et politique de sauvegarde. Auditez régulièrement l’écart entre cette référence et le serveur réel, puis corrigez les dérives par une procédure revue et réversible. L’ANSSI met à disposition Actionnable Linux, un rôle Ansible destiné à décliner certaines recommandations de son guide ; l’outil peut aider à industrialiser, mais ne remplace ni l’analyse de risque ni la validation de compatibilité avec vos applications. ([anssi-fr.github.io](https://anssi-fr.github.io/actus.html?utm_source=openai))

Une méthode d’exploitation plutôt qu’une liste de cases à cocher

Ces 15 mesures gagnent en efficacité lorsqu’elles sont appliquées dans un ordre rigoureux : inventorier, fermer les accès non nécessaires, sécuriser l’administration, corriger, filtrer, journaliser, sauvegarder, tester, puis répéter. Il est plus utile de disposer d’un SSH par clés limité à des comptes nominatifs, d’un pare-feu vérifié, de correctifs suivis et d’une restauration testée que d’empiler des réglages noyau mal compris.

Enfin, adaptez le niveau de contrôle à la valeur de l’actif. Un serveur de production contenant des données clients, une plateforme d’administration ou un nœud d’infrastructure exige des restrictions plus fortes qu’un environnement de test isolé. Mais dans les deux cas, l’exigence de base reste identique : savoir ce qui est exposé, qui peut agir, ce qui a changé et comment restaurer. C’est cette traçabilité opérationnelle qui fait passer un serveur Linux d’une installation fonctionnelle à une infrastructure réellement durcie.