Le durcissement d’un serveur Linux consiste à réduire les possibilités dont dispose un attaquant pour entrer sur un serveur, y agir et y maintenir sa présence. Il ne s’agit pas d’une simple modification de configuration ni d’un produit que l’on peut activer. C’est une succession de décisions concernant les éléments exécutés par le serveur, les personnes qui peuvent y accéder, les connexions réseau acceptées, l’enregistrement de l’activité et la rapidité avec laquelle les faiblesses sont corrigées.
Pour les agences et les entreprises, le durcissement doit être effectué avant la mise en production d’un serveur. Un serveur nouvellement installé peut contenir des comptes par défaut, des services en écoute, des permissions trop larges et des interfaces d’administration pratiques lors de l’installation, mais inutiles en fonctionnement normal. Chaque composant superflu augmente la surface d’attaque et crée un paramètre supplémentaire à maintenir.
Ce guide présente une base pratique pour le durcissement de serveurs Linux sur des VPS et des serveurs dédiés contrôlés par le client. Les commandes exactes varient selon les distributions, notamment Debian, Ubuntu, Rocky Linux, AlmaLinux et d’autres. Considérez donc les exemples comme des concepts de configuration et non comme des instructions à copier-coller. Testez les changements sur un système hors production, conservez une voie de récupération hors bande et documentez les modifications effectuées.
Commencer par une installation minimale et connue
Le serveur le plus sûr est généralement celui qui en fait le moins. Commencez avec une distribution Linux prise en charge et une installation minimale qui ne comprend que les composants du système d’exploitation et les outils nécessaires à la charge prévue. Un serveur web, un serveur de bases de données, un serveur applicatif et un nœud de supervision n’ont pas besoin des mêmes paquets ni des mêmes services.
Notez la version du système d’exploitation, les sources des dépôts, les paquets installés, les services activés, les interfaces réseau et les rôles prévus. Cet inventaire constitue une base de référence. Sans lui, un administrateur peut ne pas remarquer qu’un paquet a été ajouté, qu’un service s’est mis à écouter ou qu’une configuration a dérivé.
Supprimer ce dont la charge de travail n’a pas besoin
Examinez les paquets installés et supprimez les logiciels inutiles. Il peut notamment s’agir d’agents de transfert de courrier non utilisés, d’anciens utilitaires réseau, de composants graphiques, de compilateurs et d’outils d’administration temporaires. Ne supprimez pas un paquet simplement parce que son nom ne vous est pas familier : vérifiez d’abord si un autre service en dépend et s’il est nécessaire aux mises à jour, à la supervision ou à la récupération.
Désactivez les services qui ne correspondent pas au rôle du serveur. Un service installé mais inutile peut tout de même exposer un port réseau, traiter des données non fiables ou contenir une vulnérabilité. Une interface d’administration inutilisée est particulièrement risquée, car elle peut conserver ses paramètres par défaut tout en recevant peu d’attention.
Sur les distributions basées sur systemd, les administrateurs examinent généralement l’état des services avec des outils tels que systemctl et inspectent les sockets en écoute avec ss. L’objectif n’est pas de raccourcir la liste des services à tout prix. Il est de faire en sorte que chaque service exécuté soit intentionnel, placé sous la responsabilité de quelqu’un et couvert par un processus de mise à jour et de supervision.
Mettre en place un processus de mise à jour rapide
Les logiciels non corrigés sont l’un des moyens les plus fiables pour les attaquants d’exploiter une faiblesse connue. Le durcissement d’un serveur Linux couvre donc le système d’exploitation, le noyau, les paquets installés, les environnements d’exécution, les serveurs web, les bases de données, les images de conteneurs et les applications. Un serveur peut disposer d’un pare-feu soigneusement configuré et être tout de même compromis par un service vulnérable qui accepte un trafic réseau légitime.
Abonnez-vous aux notifications de sécurité de la distribution et des principaux composants logiciels que vous exploitez. Définissez qui examine les avis, comment leur gravité est évaluée et dans quels délais les mises à jour sont appliquées. Les vulnérabilités critiques exposées sur Internet peuvent nécessiter une intervention d’urgence, tandis que les changements moins risqués peuvent suivre une fenêtre de maintenance planifiée.
Trouver l’équilibre entre rapidité et contrôle des changements
Les mises à jour de sécurité automatiques peuvent réduire la durée d’exposition, mais elles peuvent aussi introduire des problèmes de compatibilité. Elles conviennent souvent à certains paquets de sécurité du système d’exploitation, à condition que les administrateurs disposent d’une supervision, de procédures de retour arrière et d’un moyen de gérer les redémarrages. Pour les piles applicatives aux dépendances strictes, un processus de mise à jour contrôlé peut être plus sûr.
Documentez ce compromis. Une politique peut stipuler que les correctifs de sécurité sont appliqués dans un délai défini, que les redémarrages du noyau ont lieu pendant une fenêtre de maintenance convenue et que les mises à jour d’urgence peuvent déroger à la planification normale. L’essentiel est d’éviter un processus informel dans lequel les mises à jour dépendent du fait que quelqu’un pense à se connecter.
Après une mise à jour, vérifiez que les services ont redémarré correctement, que les certificats restent disponibles, que les dépendances applicatives fonctionnent et que le serveur communique avec le système de supervision. Un correctif qui laisse un service critique à l’arrêt est techniquement installé, mais opérationnellement inefficace.
Utiliser des utilisateurs distincts et le principe du moindre privilège
Le principe du moindre privilège limite les dommages causés lorsqu’un compte, un processus ou une application est compromis. Les utilisateurs doivent recevoir uniquement les accès nécessaires à leurs responsabilités, et uniquement pendant la durée nécessaire. Évitez les comptes administrateur partagés, car ils rendent l’attribution des actions difficile et favorisent la réutilisation des identifiants.
Créez des comptes nominatifs pour les administrateurs et des comptes de service distincts pour les applications. Une application web ne devrait normalement pas s’exécuter avec les privilèges root, et un processus de base de données ne devrait pas pouvoir écrire dans des répertoires applicatifs sans rapport avec son activité. Les comptes de service devraient utiliser des shells non interactifs lorsque cela est pertinent et ne devraient pas appartenir à des groupes d’administration, sauf exigence précise et documentée.
Examinez régulièrement les utilisateurs, les appartenances aux groupes, les répertoires personnels, les shells de connexion, les clés SSH et les données de dernière connexion. Supprimez les comptes des personnes ayant quitté le projet, renouvelez les accès lorsque les responsabilités changent et désignez un responsable pour chaque compte privilégié. Les accès temporaires doivent faire l’objet d’un processus d’expiration plutôt que de devenir permanents par inadvertance.
Contrôler sudo avec attention
sudo est plus sûr que de donner le mot de passe root à chaque administrateur, mais une règle sudo trop large peut presque équivaloir à un accès root sans restriction. Accordez les permissions administratives à des utilisateurs nommément désignés ou à des groupes étroitement gérés. Lorsque c’est possible, autorisez des commandes précises plutôt qu’un préfixe de commande sans restriction, et évitez les règles permettant à un utilisateur de modifier des fichiers de configuration arbitraires ou d’exécuter un shell par l’intermédiaire d’un autre programme.
Exigez une authentification pour les actions privilégiées, sauf raison opérationnelle documentée. Conservez l’activité sudo dans des journaux centralisés et recherchez les horaires, commandes ou comptes inhabituels. Soyez vigilant avec les scripts : un script autorisé qui lit des données contrôlées par l’utilisateur, recherche un chemin non sûr ou appelle un autre programme sans chemin absolu peut fournir une voie indirecte vers une élévation de privilèges.
Le moindre privilège peut ralentir la réponse à un incident s’il est conçu sans procédures d’urgence. Les administrateurs doivent documenter la manière d’obtenir un accès élevé lors d’une panne, l’identité de la personne qui l’approuve et la façon dont cet accès est examiné ensuite. Des contrôles de sécurité que personne ne peut utiliser pendant un véritable incident tendent à être contournés lorsque la pression augmente.
Renforcer SSH sans perdre l’accès
SSH constitue souvent le principal moyen d’administration d’un serveur Linux. Son durcissement doit donc être réfléchi et testé. Avant de modifier la configuration du démon, ouvrez une deuxième session d’administration et conservez un accès par console ou au niveau du fournisseur si la plateforme le propose. Validez la nouvelle configuration avant de redémarrer le service.
Utilisez des clés SSH plutôt que l’authentification par mot de passe pour les accès administratifs. Les clés rendent les attaques automatisées contre les mots de passe faibles moins efficaces, en particulier lorsqu’elles sont protégées par une phrase secrète et gérées avec un agent ou un processus de gestion des secrets approuvé. Protégez les clés privées comme des identifiants : ne les stockez pas dans des dossiers partagés, des dépôts de code ou des postes de travail non gérés.
Pour un serveur contrôlé par le client, une base SSH comprend généralement :
- Désactiver la connexion directe de root via SSH.
- Désactiver l’authentification par mot de passe après avoir testé l’accès par clé.
- Limiter l’accès SSH à des utilisateurs nommés ou à un groupe d’administration.
- Utiliser une version actuelle du protocole SSH et des algorithmes cryptographiques pris en charge.
- Limiter l’accès à un réseau d’administration, un VPN ou des adresses sources précisément définies lorsque cela est possible.
- Définir des délais raisonnables pour les connexions et l’authentification.
- Enregistrer les événements d’authentification réussis et échoués.
Modifier le port SSH peut réduire le bruit généré par les scanners rudimentaires, mais ce n’est pas une frontière de sécurité. Cela ne doit jamais remplacer l’authentification par clé, les restrictions d’accès et les mises à jour. De même, les outils qui bloquent automatiquement les tentatives de connexion répétées peuvent aider contre le trafic par force brute, mais ils risquent de bloquer des administrateurs légitimes si les seuils et les sources de confiance sont mal définis.
Désactiver la connexion root et tester la récupération
La connexion directe de root supprime la traçabilité et offre une cible de grande valeur à un attaquant. Définissez PermitRootLogin sur no dès qu’un autre compte d’administration a été testé. Le test doit inclure une nouvelle connexion avec la clé prévue, l’accès sudo, l’accès depuis le réseau d’administration habituel et la procédure d’accès d’urgence.
Ne fermez pas la session existante avant d’avoir confirmé la nouvelle voie d’accès. Une petite erreur de syntaxe, un nom de groupe incorrect ou une règle AllowUsers trop restrictive peut bloquer toute l’équipe. Le durcissement SSH n’est réussi que lorsqu’il améliore la sécurité sans supprimer la capacité d’administrer et de récupérer le serveur.
Appliquer une configuration de pare-feu restrictive par défaut
La configuration du pare-feu réduit le nombre de chemins réseau qui atteignent un service. Une base pratique consiste à refuser par défaut le trafic entrant non sollicité, à n’autoriser que les ports nécessaires et à permettre le trafic sortant selon la charge de travail et la politique de l’organisation. La politique adaptée dépend du service : un serveur web public peut nécessiter HTTP et HTTPS, tandis qu’une base de données ne devrait généralement accepter des connexions que depuis des hôtes applicatifs définis.
Utilisez le pare-feu de l’hôte comme une couche supplémentaire, même lorsqu’un fournisseur cloud ou la périphérie du réseau fournit également un filtrage. Plusieurs couches peuvent limiter l’impact d’une erreur à un endroit, mais elles doivent être documentées afin que les administrateurs comprennent où une connexion est autorisée ou refusée. Parmi les outils courants de pare-feu Linux figurent nftables, firewalld et les interfaces propres aux distributions.
Pour chaque règle autorisée, notez :
- Les réseaux ou hôtes sources autorisés.
- Le port de destination et le protocole.
- Le responsable du service et sa finalité métier.
- Le caractère temporaire ou permanent de la règle.
- La manière dont la règle sera examinée et supprimée.
Une règle telle que « autoriser le port de la base de données depuis n’importe où » crée une large voie d’attaque, même si la base exige un mot de passe. Limitez autant que possible les services d’administration aux réseaux de confiance. Si les administrateurs distants doivent accéder au serveur depuis des emplacements variables, envisagez un VPN, un bastion contrôlé ou une autre voie d’accès gérée plutôt que d’exposer chaque port d’administration sur Internet.
Testez les changements du pare-feu depuis un emplacement externe approuvé et depuis le réseau applicatif. Confirmez que le trafic requis fonctionne et que le trafic non autorisé est rejeté. Testez également après un redémarrage, car un pare-feu qui n’est pas persistant peut laisser le serveur exposé après une maintenance.
Protéger les fichiers, les secrets et les données applicatives
Des permissions de fichiers sécurisées empêchent un compte ou un service de lire ou de modifier les données d’un autre service. Commencez par la propriété. Les fichiers système doivent normalement appartenir à root ou au compte système approprié, tandis que les répertoires applicatifs ne doivent être accessibles en écriture que là où l’application doit réellement écrire.
Évitez les permissions larges telles que 777 pour les répertoires ou les fichiers. Elles permettent à chaque utilisateur local et à chaque processus compromis de lire, modifier ou exécuter du contenu. Les fichiers de configuration contenant des identifiants de base de données, des clés API ou des certificats privés doivent être lisibles uniquement par le compte ou le groupe qui en a besoin. Les clés SSH privées doivent disposer de permissions restrictives et ne doivent pas être placées dans des répertoires accessibles depuis le web.
Séparez autant que possible le code, la configuration, les téléversements, les journaux et les fichiers temporaires. Le contenu téléversé par les utilisateurs ne doit pas être automatiquement exécutable. Les racines documentaires des serveurs web ne doivent pas contenir de secrets de déploiement, de métadonnées de contrôle de version, d’archives de sauvegarde ou de fichiers d’environnement. Si une application doit écrire des téléversements, donnez-lui un répertoire dédié et envisagez des contrôles empêchant l’exécution des scripts téléversés.
Gérer les secrets de manière volontaire
Ne placez pas de mots de passe dans l’historique du shell, les tickets, les dépôts de code ou des scripts improvisés. Utilisez un gestionnaire de secrets ou un autre mécanisme contrôlé adapté à l’organisation. Faites tourner les identifiants lorsque des collaborateurs quittent l’équipe, lorsqu’une exposition est suspectée et selon le niveau de risque du système. Notez les services qui dépendent de chaque secret afin que sa rotation ne provoque pas une interruption.
Les permissions de fichiers ne remplacent pas le chiffrement. Si un attaquant obtient un accès root, les limites de permissions locales peuvent ne plus protéger les données. Elles restent importantes, car de nombreux incidents commencent avec un compte applicatif moins privilégié, un identifiant utilisateur volé ou un processus local trop permissif.
Isoler les services et réduire les déplacements latéraux
L’isolation des services limite ce qu’un composant compromis peut atteindre. Exécutez chaque service majeur avec son propre compte et limitez son système de fichiers, son accès réseau et ses capacités Linux. Selon la charge de travail, l’isolation peut utiliser les options de sandboxing de systemd, des conteneurs, des machines virtuelles, des contrôles d’accès obligatoires tels que SELinux ou AppArmor, des mécanismes de type chroot et la segmentation réseau.
L’isolation doit correspondre à la menace et aux capacités opérationnelles de l’équipe. Un conteneur ne constitue pas automatiquement une frontière de sécurité complète, et une politique complexe que personne ne comprend peut être moins sûre en pratique qu’une conception plus simple et bien supervisée. Maintenez également à jour l’hôte, le moteur de conteneurs, les images et les composants d’orchestration.
Pour les applications exposées sur Internet, séparez le niveau public des bases de données et des services internes. N’autorisez que les connexions nécessaires entre l’application et la base de données. Empêchez un processus web compromis d’établir des connexions sortantes arbitraires lorsque la charge de travail le permet. Cela peut limiter le trafic de commande et de contrôle et rendre plus difficile l’extension d’une exploitation vers d’autres systèmes.
Documentez les dépendances entre les services avant d’appliquer l’isolation. Des politiques trop restrictives peuvent interrompre les mises à jour, la résolution DNS, la synchronisation horaire, la transmission des journaux ou les contrôles d’état. Le compromis oppose une réduction de l’étendue des dommages à l’effort supplémentaire nécessaire pour tester, exploiter et dépanner ces frontières.
Enregistrer l’activité et surveiller les changements
Un durcissement sans visibilité laisse les administrateurs incapables de déterminer si les contrôles fonctionnent. Activez les journaux d’authentification, d’élévation de privilèges, de services et de pare-feu. Collectez également les journaux applicatifs et ceux du serveur web, en veillant toutefois à ne pas enregistrer les mots de passe, les jetons de session ou d’autres données sensibles.
Transférez autant que possible les journaux importants hors du serveur. Un attaquant disposant d’un accès administrateur peut supprimer ou modifier les preuves locales. La journalisation centralisée facilite également la corrélation des événements entre les serveurs, par exemple une connexion suspecte suivie de la création d’un compte et d’une connexion sortante inhabituelle.
Définissez des alertes pour les événements qui méritent une attention, plutôt que d’envoyer chaque message dans une boîte de réception que personne ne consulte. Les signaux utiles peuvent notamment inclure :
- Des échecs de connexion répétés suivis d’une connexion réussie.
- De nouveaux utilisateurs privilégiés, des changements d’appartenance à des groupes ou des clés SSH inattendues.
- Une activité root directe ou des commandes sudo inhabituelles.
- Des modifications des règles du pare-feu, de la configuration SSH ou des fichiers système critiques.
- Des ports en écoute inattendus ou des services démarrés au démarrage.
- Une utilisation anormale du processeur, de la mémoire, du disque ou du réseau sortant.
- La désactivation d’agents de sécurité, du transfert des journaux ou des contrôles de supervision.
La supervision doit avoir un responsable et un processus de réponse. Une alerte qui n’est ni examinée, ni triée, ni associée à une action n’est qu’un enregistrement. Établissez les habitudes normales de fonctionnement afin que l’équipe puisse distinguer un déploiement d’une modification de configuration inexpliquée.
Exécuter des contrôles automatisés de vulnérabilités et de configuration
Les vérifications manuelles sont utiles, mais irrégulières. Les scanners automatisés de vulnérabilités, les audits de paquets et les contrôles de configuration peuvent repérer des correctifs manquants, des services exposés, des paramètres cryptographiques faibles, des bibliothèques obsolètes et des écarts par rapport à la base approuvée. Exécutez-les régulièrement et après les changements importants, pas uniquement juste avant un audit.
Utilisez un processus fondé sur la gravité. Confirmez d’abord les résultats, car les scanners peuvent signaler des faux positifs ou mal interpréter un correctif rétroporté de la distribution. Désignez ensuite un responsable, une échéance de correction et les preuves de clôture. Une vulnérabilité qui ne peut pas être corrigée immédiatement doit avoir une mesure compensatoire documentée, comme une restriction réseau, la désactivation du service ou une supervision renforcée.
La gestion de configuration peut empêcher la dérive en définissant l’état attendu des utilisateurs, des paquets, des services, des règles de pare-feu et des permissions. Examinez les changements au moyen d’un contrôle de version ou d’un processus d’approbation équivalent. Évitez de stocker les secrets dans des dépôts de configuration ordinaires et veillez à ce que l’automatisation utilise elle-même des identifiants aux droits limités.
Avant la production, validez la base avec une check-list pratique de durcissement d’un serveur Linux et adaptez-la à la distribution, à la charge de travail et au profil de risque. Une check-list est un point de départ, pas une preuve de sécurité. L’administrateur doit toujours vérifier que les contrôles sont pertinents et que l’entreprise peut les exploiter.
Comprendre les VPS, les serveurs dédiés et l’hébergement mutualisé
Ces contrôles s’appliquent lorsque le client contrôle le système d’exploitation et la configuration du serveur, par exemple sur un VPS ou un serveur dédié géré par le client. Celui-ci peut normalement choisir la distribution, gérer les utilisateurs, configurer SSH, installer un pare-feu hôte, mettre à jour les paquets, isoler les services et décider de la gestion des journaux et de la supervision.
L’hébergement mutualisé est différent. Plusieurs clients utilisent un environnement géré par le fournisseur d’hébergement et ne peuvent généralement pas modifier le pare-feu de l’hôte, désactiver les services système, configurer le démon SSH, mettre à jour le système d’exploitation ou définir une isolation au niveau du noyau. Le fournisseur peut proposer ses propres contrôles de sécurité, mais ceux-ci ne sont pas équivalents au durcissement d’un serveur Linux contrôlé par le client.
Lorsque vous comparez des solutions d’hébergement, faites la distinction entre un VPS ou un environnement dédié contrôlé par le client et l’hébergement mutualisé et les autres solutions d’hébergement gérées. Ne supposez pas qu’une check-list de durcissement peut être appliquée à un site simplement parce qu’il fonctionne sous Linux. Si le client ne contrôle pas le serveur, les questions pertinentes sont les suivantes : que sécurise le fournisseur, que peut configurer le client, comment les incidents sont-ils traités et comment les données peuvent-elles être récupérées ?
Safenix protège les serveurs contrôlés par le client. Il ne fournit pas de plan de sauvegarde pour un site fonctionnant sur un hébergement mutualisé. Cette distinction est importante pour définir le périmètre d’une sauvegarde : identifiez le serveur réel, son système d’exploitation et le niveau d’accès disponible avant de choisir une méthode de récupération.
Le durcissement réduit les risques, mais ne garantit pas la récupération
Même un serveur correctement durci peut être compromis. Des identifiants peuvent être volés, une application peut contenir une vulnérabilité inconnue, un administrateur peut commettre une erreur destructrice, un utilisateur privilégié peut abuser de ses accès ou un rançongiciel peut chiffrer les données via un compte légitime. Le durcissement vise à réduire la probabilité et l’impact d’une compromission ; il ne rend pas le serveur indestructible.
La récupération doit donc faire partie du même plan de résilience. Conservez les sauvegardes séparément du serveur de production et des identifiants utilisés pour l’administrer. Si un attaquant peut supprimer, modifier ou chiffrer à la fois les données actives et leurs sauvegardes, le processus de sauvegarde peut exister sur le papier, mais échouer lors de l’incident qui compte.
Après avoir durci le serveur, protégez sa capacité de récupération grâce aux sauvegardes Safenix chiffrées et hors site pour les serveurs professionnels contrôlés par le client. Safenix stocke les données de sauvegarde en Allemagne, les chiffre avec une clé que Safenix ne détient jamais et les conserve de manière immuable pendant toute la durée de rétention. Ces propriétés répondent à des risques différents : le stockage hors site sépare les copies de sauvegarde des défaillances locales, le chiffrement protège la confidentialité et l’immuabilité contribue à empêcher la modification ou la suppression pendant la période de rétention définie.
La conception des sauvegardes nécessite toutefois des décisions de la part du client. Identifiez les serveurs et les données essentiels, la perte de données que l’entreprise peut tolérer, la vitesse à laquelle les systèmes doivent être remis en service et les dépendances nécessaires à une récupération fonctionnelle. Une sauvegarde des fichiers applicatifs sans la base de données, la configuration, les identifiants ou une procédure de reconstruction documentée peut ne pas permettre de rétablir un service opérationnel.
Tester la restauration, pas seulement la réussite des sauvegardes
La réussite d’une tâche de sauvegarde prouve que les données ont été écrites. Elle ne prouve pas que l’entreprise peut les restaurer. Planifiez des tests de restauration avec un serveur représentatif ou un environnement de récupération isolé. Vérifiez l’intégrité des fichiers, la cohérence de la base de données, les permissions, le démarrage de l’application, les changements DNS, les certificats et la capacité des utilisateurs à travailler normalement.
Consignez le résultat de chaque test, notamment le temps nécessaire, les problèmes rencontrés et les actions attribuées. Testez à la fois la récupération d’un petit fichier et la récupération complète d’un serveur ou d’un service lorsque cela est pertinent. Intégrez des scénarios tels qu’une suppression accidentelle, une panne du serveur, un rançongiciel et la perte du site d’hébergement principal.
Ne vous reposez pas sur la mémoire d’un seul administrateur. Stockez les procédures de récupération dans un emplacement où elles resteront disponibles pendant un incident serveur, tout en les protégeant contre les accès non autorisés. Elles doivent indiquer les contacts, les dépendances, la récupération des identifiants, l’ordre de récupération, les contrôles de validation et l’autorité habilitée à basculer de nouveau vers la production.
Documenter les compromis opérationnels
Les contrôles de sécurité interagissent toujours avec la disponibilité, les performances, les coûts et l’effort d’administration. Une base durcie doit expliquer ces décisions au lieu de les présenter comme des règles universelles. L’environnement est ainsi plus facile à exploiter et le prochain administrateur comprend pourquoi une exception existe.
Documentez au minimum :
- Les services et ports nécessaires, ainsi que leur responsable.
- Les utilisateurs et groupes disposant d’un accès administratif, la manière dont les clés sont délivrées et la façon dont les accès sont révoqués.
- La rapidité d’application des correctifs de sécurité et les moments où les redémarrages sont autorisés.
- Les paramètres du pare-feu, de SSH, de sudo et des permissions qui diffèrent de la base standard.
- La manière dont l’isolation des services affecte les déploiements, le dépannage et les performances.
- Les journaux conservés, leur destination et les responsables des alertes.
- La manière dont les vulnérabilités sont évaluées, hiérarchisées et clôturées.
- Les données sauvegardées, les exigences de rétention et le processus de restauration testé.
- Ce qui se passe si le serveur principal, les identifiants ou l’administrateur sont indisponibles.
Parmi les exemples de compromis figurent la désactivation de la connexion par mot de passe, qui améliore la résistance aux attaques par mot de passe, mais exige une gestion fiable des clés et une procédure d’accès d’urgence. Un pare-feu restrictif par défaut réduit l’exposition, mais peut interrompre une nouvelle intégration. Des mises à jour automatiques agressives réduisent la fenêtre de vulnérabilité, mais peuvent nécessiter de meilleurs tests et mécanismes de retour arrière. Une isolation forte des services limite les déplacements latéraux, mais accroît la complexité de configuration.
Les exceptions doivent avoir un responsable, une justification, une date d’expiration ou de réexamen et des contrôles compensatoires. Un accès temporaire au pare-feu qui reste en place pendant des années n’est plus une exception : c’est une infrastructure non documentée. Des examens réguliers doivent supprimer les comptes, paquets, services, ports et permissions obsolètes.
Une séquence pratique de durcissement avant production
Les équipes obtiennent souvent de meilleurs résultats en appliquant les contrôles dans un ordre reproductible :
- Définir le rôle du serveur, la classification des données, les dépendances et les exigences de récupération.
- Installer un système d’exploitation pris en charge avec le plus petit ensemble de paquets pratique.
- Appliquer les mises à jour actuelles et noter la base de versions obtenue.
- Créer des comptes d’administration nominatifs et configurer un accès sudo soigneusement limité.
- Installer et tester les clés SSH, puis désactiver la connexion directe de root et l’authentification par mot de passe lorsque cela est approprié.
- Supprimer les paquets inutiles et désactiver les services qui ne sont pas nécessaires.
- Configurer un pare-feu persistant, restrictif par défaut, avec des exceptions précisément limitées.
- Définir la propriété et les permissions des fichiers système, du code applicatif, des secrets, des téléversements et des journaux.
- Isoler les services et limiter leur accès au système de fichiers, au réseau et aux capacités.
- Activer la journalisation centralisée, la supervision et les alertes pour les changements d’authentification, de privilèges et de configuration.
- Exécuter les contrôles de vulnérabilités et de configuration, puis corriger ou documenter les résultats.
- Configurer des sauvegardes hors site et effectuer un test de restauration avant de déclarer le serveur prêt.
Reprenez la séquence après les changements importants. Le durcissement de la production n’est pas une cérémonie unique, car les paquets, les applications, les utilisateurs, les intégrations et les exigences métier évoluent. Un serveur sécurisé lors de son lancement peut présenter un profil de risque différent quelques mois plus tard.
Une base qui renforce la résilience
Le durcissement d’un serveur Linux est plus efficace lorsqu’il s’inscrit dans une discipline opérationnelle plus large. Les installations minimales réduisent les chemins d’attaque inutiles. Les mises à jour suppriment les faiblesses connues. Le moindre privilège limite ce qu’un compte compromis peut faire. Les contrôles SSH protègent l’administration, les pare-feu limitent l’exposition réseau et les permissions protègent les données contre les processus sans rapport. L’isolation limite les déplacements latéraux, tandis que la journalisation et la supervision améliorent la détection. Les contrôles automatisés aident l’équipe à repérer les dérives avant l’attaquant.
Aucun de ces contrôles ne supprime la nécessité d’une récupération testée. La prévention et la récupération répondent à des modes de défaillance différents. Durcissez le serveur pour rendre la compromission plus difficile, supervisez-le pour rendre l’activité suspecte visible et conservez des sauvegardes hors site protégées afin qu’un incident grave ne se transforme pas en perte définitive des données de l’entreprise.