Durcir un serveur Linux : étapes sûres et vérifications avant production

Durcir un serveur Linux, c’est réduire son exposition sans casser les services dont il dépend. Il ne faut pas empiler des réglages de sécurité à l’aveugle : une règle SSH trop stricte, un service désactivé ou un montage rendu non exécutable peut interrompre une application légitime. La démarche fiable est progressive : inventorier, limiter une catégorie d’accès, vérifier, documenter un retour arrière, puis passer à la suivante.

Ce guide se concentre sur le système Linux. La protection du VPS public, la configuration HTTPS et le déploiement applicatif ont leurs propres guides. Un environnement réglementé ou une donnée sensible exige une analyse de risque et des référentiels adaptés.

Ce que vous allez apprendre

Vous allez établir une base de configuration, réduire les comptes et services inutiles, protéger l’administration distante, appliquer les correctifs, améliorer les journaux et tester la restauration. Chaque étape inclut un contrôle ; une mesure qui n’est pas vérifiée est une hypothèse, pas un niveau de sécurité.

Prérequis

• Accès console d’hébergeur et deux sessions d’administration indépendantes.
• Inventaire des applications, ports, comptes de service et tâches planifiées.
• Sauvegarde récente, plus une procédure de restauration au moins partiellement testée.
• Fenêtre de maintenance et personne pouvant valider le fonctionnement applicatif.
• Documentation de la distribution et de ses paquets de sécurité.

Conservez toujours un chemin de retour avant de modifier l’accès réseau ou l’authentification. Une mesure qui vous bloque hors du serveur n’est pas une amélioration exploitable.

1. Établir une base et un inventaire

Relevez version du système, noyau, paquets exposés, ports ouverts, comptes humains et comptes de service. Identifiez ce qui démarre au boot et les tâches planifiées. Ajoutez un propriétaire à chaque service : si personne ne sait pourquoi un démon est présent, il doit être examiné avant toute exposition ou mise à jour majeure.

Ne partez pas d’une liste générique de paquets à supprimer. Une dépendance peut être nécessaire à un agent, une base, un proxy ou un outil de récupération. Préférez désactiver progressivement ce qui n’est pas requis, avec une vérification fonctionnelle après chaque changement.

Vérification : archivez l’inventaire dans votre documentation d’exploitation, puis comparez-le après les changements. Toute différence de service, port ou utilisateur doit être expliquée.

2. Réduire les comptes et privilèges

Séparez les administrateurs des comptes applicatifs. L’application doit tourner avec un utilisateur dédié, sans droits sudo par défaut et avec accès seulement à ses répertoires. Désactivez les comptes non utilisés selon les procédures de votre distribution ; ne supprimez pas un compte de service avant d’avoir confirmé ses dépendances.

Établissez une politique d’administration : qui possède une clé, qui peut élever ses privilèges, comment un accès est retiré et quelle trace est conservée. Retirez les accès individuels quand ils ne sont plus nécessaires plutôt que de partager une même clé ou un même compte.

Vérification : testez le compte applicatif : il doit démarrer le service prévu, mais échouer à lire les secrets d’administration ou à modifier les fichiers système. Vérifiez qu’un compte désactivé ne peut plus ouvrir de session.

3. Protéger l’administration distante

Utilisez une authentification forte pour les accès distants et limitez les comptes autorisés. Les clés SSH doivent être protégées, renouvelées si nécessaire et associées à une personne ou à une fonction identifiable. Désactivez les méthodes non utilisées uniquement après avoir vérifié le nouveau parcours dans une seconde session. Évitez l’administration quotidienne directement en root : l’élévation contrôlée rend les actions plus traçables.

Le port SSH n’est pas une frontière de sécurité à lui seul. La priorité est de limiter les identités, les origines réseau lorsque c’est possible, les tentatives répétées et les privilèges disponibles après connexion.

Vérification : ouvrez une nouvelle session avec la clé autorisée, puis testez l’échec d’un compte ou d’une méthode interdits avant de fermer votre accès de secours.

4. Réduire les services et le réseau

N’exposez que les ports nécessaires au service public. Une base de données, une interface de cache, un dashboard ou un port de développement n’a pas besoin d’être Internet-facing pour fonctionner avec une application locale. Utilisez le pare-feu et l’écoute locale pour exprimer cette intention ; une seule couche mal configurée ne doit pas rendre le service public.

Réduisez également les sorties non nécessaires pour les workers qui traitent du contenu non fiable. Une restriction réseau n’élimine pas les risques applicatifs, mais elle rend plus difficile l’exfiltration accidentelle ou la connexion à une destination inattendue.

Vérification : testez les ports depuis un réseau externe, puis testez les communications légitimes depuis l’application. Une règle réussie doit fermer ce qui est inutile sans casser ce qui est documenté.

5. Gérer correctifs et intégrité

Appliquez les mises à jour de sécurité suivant le cycle de votre distribution. Suivez les avis de sécurité pertinents et planifiez les redémarrages nécessaires. Les mises à jour automatiques peuvent convenir à certains environnements, mais elles doivent être accompagnées d’une alerte et d’un contrôle des services après l’opération.

Épinglez ou vérifiez les sources de paquets selon la politique de votre équipe. N’ajoutez pas un dépôt tiers pour résoudre rapidement une dépendance sans en comprendre le mainteneur, les signatures, les mises à jour et le plan de retrait. La chaîne d’approvisionnement est aussi une surface d’attaque.

Vérification : après un correctif, contrôlez les services essentiels, l’espace disque et les logs d’erreur. Consignez la version et le changement, puis vérifiez qu’une version de retour est connue si l’application régresse.

6. Journaliser, sauvegarder et tester le retour

Collectez les événements d’administration, les erreurs de service, les changements de configuration et les tentatives d’authentification pertinentes. Appliquez une rétention et un accès limité, car les journaux peuvent contenir des identifiants ou des informations sensibles. Ne transformez pas la journalisation en collecte illimitée de données utilisateur.

Sauvegardez les configurations nécessaires et testez un retour sur une machine isolée. Un rollback peut consister à restaurer un fichier de configuration, redémarrer un service ou revenir à une image connue ; documentez précisément ce qui doit être réversible. Le test doit éviter d’envoyer des notifications ou webhooks de production.

Vérification : réalisez un exercice de retour arrière sur une modification non critique. Mesurez le temps et notez les actions manuelles : elles sont les premières candidates à l’automatisation ou à la documentation.

Problèmes fréquents et solutions

Le serveur devient inaccessible après une règle SSH. Utilisez la console, revenez à une configuration connue et refaites le changement avec une seconde session de test.

Un service nécessaire a été désactivé. Restaurez-le à partir de l’inventaire, documentez sa dépendance et cherchez une réduction de privilèges plutôt qu’une désactivation totale.

Les logs deviennent illisibles ou sensibles. Réduisez le niveau de détail, masquez les champs secrets, séparez les accès et ajustez la rétention.

Une mise à jour casse l’application. Utilisez la release et la configuration identifiées, puis examinez la compatibilité avant de reproduire le correctif dans un test.

FAQ

Faut-il appliquer tous les réglages de durcissement ?

Non. Les contrôles doivent correspondre aux services et au risque. Une règle non comprise peut créer une panne ou une fausse assurance.

Changer le port SSH suffit-il ?

Non. L’authentification, les comptes autorisés, les privilèges et la surveillance sont plus importants.

Comment savoir quels services supprimer ?

Par l’inventaire et la validation des propriétaires. Désactivez d’abord de façon réversible et testez le comportement applicatif.

Le durcissement remplace-t-il les sauvegardes ?

Non. Il réduit la probabilité de certains incidents ; la sauvegarde et la restauration réduisent leur impact.

À quelle fréquence revoir la configuration ?

Après un changement majeur, un incident, l’ajout d’un service ou selon un calendrier de maintenance documenté.

Conclusion

Durcir un serveur Linux est une discipline d’exploitation : inventaire, privilèges minimaux, services réduits, mises à jour contrôlées et reprise testée. Avancez une couche à la fois, conservez un retour arrière et vérifiez chaque résultat depuis le point de vue d’un utilisateur comme d’un administrateur.

Sources et limites

Sources primaires : ANSSI — recommandations de sécurité relatives à un système GNU/Linux, CISA — Securing Web Servers et OWASP Linux Hardening Cheat Sheet. Les réglages dépendent de la distribution, des services et du risque. Ce guide ne remplace pas une analyse de sécurité ou un référentiel applicable à votre organisation.