Conseil indépendant · Systèmes & cybersécurité
Sécurisation et hardening de serveurs Linux
Réduisez la surface d'attaque de vos serveurs Linux sans appliquer aveuglément une checklist incompatible avec vos services.
- TPE, PME & équipes IT
- France entière à distance
- Périmètre et livrables définis
Votre contexte
Pourquoi durcir un serveur Linux en service ?
Le durcissement efficace part des usages, des dépendances et du modèle de menace. Il combine configuration du système, isolation, droits, réseau, mises à jour et capacité de diagnostic.
Un serveur installé avec ses réglages par défaut expose souvent plus que nécessaire : SSH ouvert à tous, services inutiles en écoute, comptes jamais révisés. Le durcissement corrige ces écarts un par un, en vérifiant après chaque changement que les applications répondent toujours.
Points analysés et travaillés
- Services, paquets, comptes et privilèges réellement nécessaires
- SSH, sudo, PAM, permissions et secrets
- Pare-feu hôte, exposition réseau et protections du noyau
- Mises à jour, intégrité, journaux et détection
- Tests applicatifs, mesure d'impact et retour arrière
État des lieux
Audit d'un serveur Linux existant
Tout commence par un état des lieux : ce qui tourne, ce qui écoute, qui peut se connecter et avec quels droits. Rien n'est modifié à cette étape.
L'audit s'appuie sur la lecture de la configuration, sur des outils de contrôle comme Lynis et sur les recommandations de l'ANSSI ou les benchmarks CIS, utilisés comme base de comparaison et non comme une liste à appliquer telle quelle.
Points contrôlés
- Version du système, support et correctifs en attente
- Services actifs et ports en écoute
- Comptes, groupes, clés SSH et règles sudo
- Permissions des fichiers sensibles et des secrets
- Journaux, rotation et envoi vers la supervision
Accès
Durcissement SSH, comptes et privilèges
SSH est la porte d'entrée de l'administration. Il est réservé à l'authentification par clé, fermé au compte root et limité aux utilisateurs qui en ont besoin. Une double authentification par code TOTP peut être ajoutée via PAM, pour SSH comme pour sudo.
Les règles sudo sont écrites au plus près des besoins, les comptes techniques n'ont que les droits de leur service et les accès inutilisés sont retirés. Pour centraliser les accès privilégiés, voir le bastion d'administration.
Exposition
Pare-feu, services exposés et segmentation
Chaque service qui écoute doit avoir une raison de le faire. Les services inutiles sont désactivés, les autres liés à la bonne interface. Le pare-feu de l'hôte, en nftables, n'autorise que les flux attendus, y compris en sortie pour les serveurs sensibles.
Les services systemd peuvent être isolés par leurs options de confinement et, selon la distribution, par des profils AppArmor. Le serveur s'inscrit enfin dans une segmentation réseau plus large, avec une administration séparée des flux publics.
Côté réseau
- Ports ouverts vérifiés depuis l'intérieur et depuis Internet
- Politique de pare-feu refusant par défaut
- Filtrage en sortie pour les serveurs sensibles
- TLS à jour sur les services exposés
Détection
Journalisation et détection
Un serveur durci doit aussi signaler ce qui lui arrive. Les journaux système et d'authentification sont conservés, envoyés vers une supervision centralisée et reliés à des alertes utiles : connexion inhabituelle, élévation de privilèges, modification d'un fichier sensible.
Selon le contexte, auditd, Wazuh ou Fail2ban complètent le dispositif. Le choix des alertes est détaillé sur la page supervision et détection d'incidents.
Dans la durée
Maintenance et maintien du niveau de sécurité
Le durcissement se dégrade avec le temps : nouveaux paquets, comptes ajoutés, règles temporaires oubliées. Les mises à jour de sécurité sont suivies et appliquées selon un calendrier, et un contrôle périodique compare l'état réel à la référence documentée.
Ce suivi peut être assuré par votre équipe grâce au guide fourni, ou confié dans le cadre d'une infogérance de serveurs Linux.
Méthode
Durcir sans casser la production.
Chaque réglage est relié à un service, testé puis documenté. Une session d'administration de secours reste ouverte pendant l'intervention, pour ne jamais perdre la main sur le serveur.
- 01
Relever
État initial des paquets, services en écoute, comptes, règles sudo, pare-feu et journaux, sans rien modifier.
- 02
Comparer
Écarts mesurés face aux recommandations ANSSI et CIS, triés selon vos usages réels.
- 03
Appliquer
Changements par lots, sauvegarde préalable, test des services après chaque lot et retour arrière prêt.
- 04
Contrôler
Nouveau relevé après durcissement, preuves de test et guide pour maintenir le niveau atteint.
Livrables
Ce que vous récupérez concrètement.
Le niveau de détail dépend du périmètre, mais chaque mission doit permettre de décider, d'agir et de reprendre le travail sans dépendance artificielle.
- 01État initial et écarts prioritaires
- 02Paramètres de durcissement appliqués ou proposés
- 03Preuves de tests après changement
- 04Guide de maintenance et surveillance
Questions fréquentes
Avant de démarrer.
Le durcissement peut-il casser une application ?
Un réglage appliqué sans analyse, oui. C'est pourquoi chaque changement est relié à un service, testé sur un périmètre réduit puis généralisé, avec un retour arrière prêt en cas d'effet inattendu.
Vous appuyez-vous sur un référentiel ?
Oui. Les recommandations de l'ANSSI et les benchmarks CIS servent de base de comparaison. Les mesures retenues sont ensuite choisies selon vos usages, et les écarts assumés sont documentés avec leur justification.
Quelles distributions sont couvertes ?
Debian et Ubuntu en priorité. Pour une autre distribution Linux, la faisabilité est vérifiée lors du cadrage.
Le durcissement rend-il le serveur conforme à un référentiel ?
Pas automatiquement. Les recommandations ANSSI et CIS servent de point de comparaison, et les écarts restants sont documentés avec leur justification. Une conformité se démontre par des preuves, pas par un script.
Faut-il réinstaller les serveurs ?
Non. Le durcissement s'applique aux serveurs existants. Une réinstallation n'est proposée que si le système n'est plus maintenu ou si son état ne permet plus d'en garantir l'intégrité.
Comment protégez-vous les accès confiés ?
Les accès sont individuels, limités au strict nécessaire et révoqués à la fin du besoin. Les secrets ne sont pas placés dans les livrables et les opérations importantes restent traçables.
Première étape
Présentez-moi l'existant et le résultat attendu.
Je vous réponds avec une première lecture technique, les informations manquantes et la meilleure manière de cadrer la suite.