Durcir un serveur exposé : la liste minimale qui change tout
Un serveur exposé reçoit des tentatives d’intrusion dans l’heure qui suit sa mise en ligne. La bonne nouvelle : la quasi-totalité vise des services qui n’avaient aucune raison d’être accessibles.
Équipe RGAIX · · 7 min de lecture
Commencer par fermer, pas par surveiller
La première mesure n’est pas un outil de détection : c’est l’inventaire de ce qui écoute sur le réseau. Une base de données, une interface d’administration ou un tableau de bord de supervision accessibles publiquement sont des portes ouvertes, quelles que soient les règles derrière.
- Lister les ports réellement ouverts depuis l’extérieur, pas ceux de la configuration.
- Placer tout ce qui peut l’être derrière un proxy inverse ou un tunnel.
- Réserver l’accès d’administration à un VPN ou à des adresses connues.
- Ne laisser publics que les services qui doivent l’être : web, et rien d’autre par défaut.
Les accès : clés, comptes séparés, révocation
L’authentification par mot de passe sur un accès distant doit être désactivée. Chaque personne dispose de sa propre clé et de son propre compte : c’est ce qui permet de révoquer un accès sans coordination générale, et de savoir qui a fait quoi.
Prévoyez la sortie autant que l’entrée. La question « que se passe-t-il si cette clé fuite ce soir ? » doit avoir une réponse en une commande, pas en une réunion.
Limiter ce qui passe malgré tout
| Mesure | Ce qu’elle arrête | Ce qu’elle n’arrête pas |
|---|---|---|
| Limitation par adresse | Force brute, balayages massifs | Attaque ciblée et lente |
| Bannissement automatique | Répétition depuis une même source | Sources distribuées |
| Filtrage géographique | Bruit de fond régional | Proxys et VPN |
| Mises à jour régulières | Exploitation de failles connues | Vulnérabilités non publiées |
Aucune ligne ne suffit seule. Leur intérêt est cumulatif : elles réduisent le bruit jusqu’à rendre visibles les tentatives qui méritent une attention humaine.
Rendre les journaux exploitables avant d’en avoir besoin
Des journaux conservés uniquement sur la machine concernée disparaissent avec elle. Une copie hors du serveur, avec une rétention suffisante, est ce qui distinguera une investigation d’une supposition.
Vérifiez aussi que l’adresse réelle du visiteur arrive jusqu’à l’application : derrière un proxy mal configuré, tous les accès semblent provenir d’une même adresse interne, et toute analyse devient impossible.
Contrôler depuis l’extérieur, régulièrement
Un durcissement se vérifie depuis Internet, pas depuis la configuration. Un balayage mensuel des ports ouverts et un contrôle des certificats suffisent à détecter la dérive : un service temporairement exposé pour un test, et jamais refermé.
La meilleure protection reste la surface qu’on n’expose pas. Tout le reste consiste à surveiller ce qu’on n’a pas pu fermer.
Pages liées
Cloud privé, serveurs & architecture
Concevoir, exploiter et faire durer votre plateforme.
Découvrir l’offre ↗À LIRE ENSUITERéponse à incident : collecter les preuves avant de nettoyer
Nettoyer un serveur compromis sans chercher le vecteur garantit de recommencer. L’ordre des gestes compte plus que leur rapidité.
Lire l’article ↗À LIRE ENSUITESEA : relier le budget média aux demandes réellement utiles
Un compte publicitaire optimisé sur les mauvaises conversions dépense efficacement pour un résultat inutile.
Lire l’article ↗Parlons de ce qui vous bloque.
Une urgence, un profil à trouver ou un projet à structurer : commençons par votre besoin.