Les attaques par force brute comptent parmi les menaces les plus courantes visant les serveurs accessibles depuis Internet. Elles sont généralement automatisées, persistantes et peu coûteuses à lancer. Un attaquant n’a pas besoin de connaître précisément une entreprise avant de tester un démon SSH, un point de terminaison RDP, un panneau de contrôle, une base de données ou une interface d’administration à distance avec des milliers d’identifiants volés ou devinés.
De nombreuses tentatives échouent et présentent peu de risques immédiats. Le danger apparaît lorsqu’une tentative réussit, notamment lorsqu’un mot de passe a été réutilisé, qu’un ancien compte reste actif ou qu’un service est exposé sans authentification multifacteur. Les échecs de connexion répétés doivent donc être considérés comme des informations de sécurité utiles, et non comme un simple bruit de fond provenant d’Internet.
Ce guide explique comment reconnaître les attaques par force brute contre les serveurs, quels contrôles permettent de les réduire, dans quels cas les stratégies de blocage peuvent échouer et que faire lorsqu’un attaquant parvient à entrer.
À quoi ressemble une attaque par force brute contre un serveur
Une attaque par force brute consiste à tenter d’obtenir un accès en essayant de nombreux mots de passe, noms d’utilisateur ou combinaisons d’identifiants. Les campagnes modernes utilisent souvent le credential stuffing plutôt que des devinettes aléatoires : l’attaquant teste des paires de noms d’utilisateur et de mots de passe récupérées lors de fuites précédentes. Le password spraying adopte une approche différente en essayant un mot de passe courant sur de nombreux comptes, ce qui permet d’éviter les verrouillages individuels de comptes.
SSH et RDP sont des cibles fréquentes, car ils fournissent un accès administratif direct. D’autres services exposés peuvent être tout aussi importants :
- Services d’hébergement web et panneaux de contrôle des serveurs
- Passerelles VPN et portails d’accès à distance
- Administration de messagerie et interfaces de webmail
- Écouteurs de bases de données tels que MySQL, PostgreSQL ou Microsoft SQL Server
- Pages de connexion aux applications et points de terminaison d’API
- Consoles de virtualisation, de sauvegarde et de supervision
L’activité peut provenir d’une seule adresse, d’une liste tournante de serveurs cloud ou d’une vaste plage d’adresses IP. Une attaque distribuée peut ne produire que quelques tentatives par adresse tout en générant un grand nombre d’échecs au total. C’est pourquoi l’examen d’une seule règle de pare-feu ou du journal d’un seul serveur est souvent insuffisant.
Comment détecter les tentatives de connexion automatisées
Commencez par les journaux d’authentification
Les journaux d’authentification sont le premier endroit à consulter. Sous Linux, les événements SSH apparaissent généralement dans le journal système ou le journal d’authentification. Les administrateurs Windows doivent examiner les événements RDP et les autres événements pertinents dans l’Observateur d’événements ou sur une plateforme centralisée de journalisation Windows. Les panneaux de contrôle, les produits VPN et les bases de données tiennent généralement leurs propres journaux d’audit.
Recherchez des tendances plutôt que des événements isolés :
- Des dizaines ou des centaines de connexions échouées sur une courte période
- Des tentatives visant de nombreux noms d’utilisateur, y compris des noms inexistants
- Des tentatives répétées contre des comptes privilégiés tels que root, administrator ou des comptes de service
- Des connexions arrivant à intervalles réguliers depuis des adresses qui changent
- Une authentification réussie immédiatement après une longue série d’échecs
- Des connexions à des heures inhabituelles, depuis des pays inhabituels ou via des réseaux inconnus
- De nouveaux comptes, des mots de passe modifiés, de nouvelles clés SSH ou une appartenance à des groupes modifiée
Une seule connexion échouée ne constitue pas un incident. En revanche, une série d’échecs sur plusieurs systèmes, surtout lorsqu’elle est suivie d’une réussite, mérite une enquête. Les équipes qui évaluent les outils de détection et de blocage peuvent comparer les approches à l’aide de ces ressources sur la détection de la force brute contre les serveurs et Fail2ban, mais elles doivent valider tout outil dans leur propre environnement avant de déployer des blocages automatiques.
Utilisez les alertes et les signaux réseau
La collecte des journaux n’est utile que si une personne ou un système les examine. Les alertes peuvent reposer sur des seuils, par exemple dix connexions SSH échouées en cinq minutes, mais les règles fondées uniquement sur des seuils peuvent manquer un password spraying lent. Une meilleure supervision associe les événements d’authentification aux adresses sources, aux noms d’utilisateur, à la géolocalisation, à la criticité des ressources et aux connexions réussies.
La télémétrie réseau peut apporter un contexte supplémentaire. Surveillez toute augmentation soudaine des tentatives de connexion vers les ports d’administration, les poignées de main TCP répétées qui n’aboutissent jamais, les analyses de plusieurs services ou le trafic sortant inhabituel après une connexion suspecte. Un serveur compromis peut commencer à communiquer avec une infrastructure de commande et de contrôle, à analyser les systèmes internes ou à transférer des données.
La supervision centralisée est particulièrement importante pour les agences qui gèrent plusieurs environnements clients. Un tableau de bord unique ou une plateforme de gestion des informations et des événements de sécurité facilite la détection d’une même plage IP, d’un même schéma de noms d’utilisateur ou d’une campagne de password spraying sur plusieurs serveurs. Les alertes doivent parvenir à une personne capable d’agir et contenir suffisamment de détails pour éviter que les intervenants aient à parcourir des journaux bruts pendant un incident.
Renforcer SSH et les autres services exposés
Utilisez une authentification forte
Lorsque cela est possible, désactivez l’authentification SSH par mot de passe et exigez des clés cryptographiques individuelles. Chaque administrateur doit disposer d’un compte et d’une clé distincts, l’accès privilégié étant obtenu par une élévation contrôlée plutôt qu’au moyen d’identifiants root partagés. Protégez les clés privées avec des phrases secrètes et stockez-les de manière sécurisée. Supprimez rapidement les clés lorsqu’un membre du personnel ou un fournisseur n’a plus besoin d’accéder au système.
Pour RDP, les VPN et les panneaux de contrôle, utilisez l’authentification multifacteur partout où le produit la prend en charge. Privilégiez les méthodes résistantes à l’hameçonnage lorsqu’elles sont disponibles, en particulier pour les comptes administrateurs. L’authentification multifacteur ne rend pas un service vulnérable inoffensif, mais elle réduit considérablement la valeur d’un mot de passe volé.
Les politiques de mots de passe restent importantes pour les services qui exigent des mots de passe. Utilisez des identifiants longs et uniques, un gestionnaire de mots de passe et des comptes distincts pour l’administration, les applications et les bases de données. Ne laissez jamais les identifiants par défaut des fournisseurs en place. Désactivez les comptes inactifs et vérifiez que les comptes de service ne disposent pas d’un accès interactif inutile.
Réduisez l’exposition
L’interface d’administration la plus sûre est celle qui n’est pas accessible publiquement. Lorsque cela est possible sur le plan opérationnel, limitez l’accès à SSH, RDP et aux bases de données à un VPN, un réseau privé, un bastion ou des plages d’adresses IP d’administrateurs définies. Un écouteur de base de données n’a généralement aucune raison d’accepter des connexions depuis Internet public.
Modifier le port SSH par défaut peut réduire les analyses opportunistes, mais ce n’est pas en soi un contrôle de sécurité. Les attaquants peuvent rapidement découvrir les ports non standard. Considérez cette mesure comme une réduction du bruit, et non comme une protection. Les contrôles les plus solides sont la restriction réseau, l’authentification moderne, l’application des correctifs et la supervision.
Appliquez les mises à jour de sécurité aux systèmes d’exploitation, aux panneaux de contrôle, aux VPN et aux applications. Supprimez les services qui ne sont plus nécessaires et vérifiez que les interfaces d’administration n’ont pas été exposées accidentellement après une migration ou une modification du pare-feu. Renforcez l’hôte conformément à une configuration de référence documentée, puis réexaminez-la régulièrement au lieu de supposer qu’une configuration ponctuelle restera correcte.
Techniques de blocage et de limitation du débit
Pare-feu et filtrage au niveau du fournisseur
Les pare-feu hôtes peuvent restreindre les ports d’administration, limiter les réseaux sources et rejeter le trafic avant qu’il n’atteigne l’application. Les pare-feu réseau ou le filtrage au niveau du fournisseur peuvent absorber ou supprimer le trafic indésirable plus tôt, ce qui est utile lorsqu’une attaque génère suffisamment de connexions pour consommer les ressources du serveur.
Les contrôles au niveau du fournisseur ne remplacent pas la sécurisation des comptes. Ils peuvent aussi être moins précis que les contrôles tenant compte des applications, notamment lorsque de nombreux clients légitimes partagent une plage d’adresses. Définissez les réseaux d’administration approuvés et maintenez une voie d’accès d’urgence afin qu’une règle incorrecte ne bloque pas les personnes chargées de la corriger.
Blocage de type Fail2ban
Des outils tels que Fail2ban surveillent les journaux et ajoutent des règles temporaires au pare-feu après un nombre défini d’échecs. Ils sont pratiques pour SSH et les autres services dont les formats de journaux sont cohérents. La durée du blocage, le seuil d’échecs et la liste des adresses ignorées doivent être déterminés à partir du comportement observé, plutôt que copiés sans vérification.
Les blocages temporaires offrent généralement un meilleur équilibre que les blocages permanents. Ils ralentissent les tentatives répétées, réduisent le bruit dans les journaux et laissent aux administrateurs le temps de réagir sans créer une liste de refus toujours plus longue. Assurez-vous que l’outil de supervision continue de fonctionner après la rotation des journaux, le redémarrage des services et les modifications du système d’authentification.
Limitation du débit et contrôles des comptes
La limitation du débit peut être mise en œuvre au niveau d’un proxy inverse, d’un pare-feu, d’une application ou d’un fournisseur d’identité. Elle est particulièrement utile pour les pages de connexion web et les API, lorsqu’un service doit rester accessible publiquement. Les délais progressifs, les défis CAPTCHA et l’authentification multifacteur basée sur le risque peuvent réduire l’automatisation sans refuser l’accès à chaque utilisateur après une seule erreur.
Les verrouillages de comptes exigent davantage de prudence. Un verrouillage strict peut empêcher les essais sur un compte, mais un attaquant peut verrouiller délibérément tous les comptes employés lors d’une campagne de password spraying. Préférez des verrouillages courts et progressifs ou une limitation du débit, et créez un processus de récupération administrative testé. Ne vous reposez jamais sur une politique de verrouillage comme seule défense d’un compte privilégié.
Compromis et angles morts courants
Le blocage par adresse IP est facile à comprendre, mais il présente des limites. Les adresses peuvent être partagées par des bureaux, des réseaux mobiles, des plateformes cloud ou des systèmes NAT de niveau opérateur. Bloquer une plage entière peut affecter des utilisateurs légitimes, tandis que bloquer des adresses individuelles peut avoir peu d’effet contre une campagne distribuée. Les règles de géolocalisation peuvent également créer des faux positifs pour le personnel en déplacement et les fournisseurs distants.
Les faux positifs sont plus qu’un simple désagrément. Un système de supervision, un opérateur de sauvegarde ou un administrateur d’urgence bloqué peut retarder la reprise. Conservez si nécessaire une liste d’autorisation pour les voies d’administration approuvées, mais protégez-la soigneusement et examinez-la régulièrement. N’autorisez pas une vaste plage dynamique simplement parce qu’elle a été associée à un utilisateur légitime par le passé.
Les attaques distribuées nécessitent des contrôles axés sur l’identité. Si le même compte est ciblé depuis plusieurs réseaux, le blocage des sources ne résoudra pas le problème. Une authentification multifacteur forte, des identifiants uniques, la désactivation de l’authentification par mot de passe et une détection centralisée constituent des réponses plus durables. Recherchez des tendances liées au nom d’utilisateur, à l’appareil, à l’application et aux horaires, et pas seulement à l’adresse IP.
Comment enquêter sur une attaque suspectée
Commencez par préserver les preuves. Notez l’hôte concerné, le fuseau horaire, les entrées de journal pertinentes, les adresses sources, les comptes ciblés et les blocages automatiques déjà appliqués. Exportez les journaux avant qu’ils ne soient écrasés. Évitez de redémarrer ou de nettoyer prématurément le serveur s’il existe une possibilité réaliste de compromission ; les preuves volatiles et les connexions actives peuvent être importantes.
Déterminez ensuite si l’activité a échoué ou si un compte a été utilisé. Recherchez les connexions réussies proches des tentatives échouées et vérifiez la source, la méthode d’authentification et l’heure. Contrôlez ensuite les éléments suivants :
- Nouveaux comptes locaux ou de domaine et appartenances inattendues à des groupes
- Nouvelles clés SSH autorisées, tâches planifiées, tâches cron ou entrées de démarrage
- Modifications des règles de pare-feu, des paramètres d’accès à distance ou des politiques de sécurité
- Processus, ports en écoute et connexions sortantes inattendus
- Fichiers web, binaires, scripts et fichiers de configuration modifiés
- Accès inhabituel aux données, téléchargements, téléversements ou élévations de privilèges
Comparez l’hôte à une configuration de référence fiable ou à un standard de déploiement connu. Examinez les journaux du fournisseur d’identité, du VPN, du pare-feu, des points de terminaison et du cloud, en plus de ceux du serveur. Faites tourner les identifiants et révoquez les sessions dès qu’il existe un soupçon raisonnable d’exposition. Si le système traite des données réglementées, des informations clients ou des opérations critiques, suivez le processus de gestion des incidents de l’organisation et envisagez les obligations de notification légales, réglementaires et contractuelles.
Bloquer une tentative ne signifie pas répondre à une compromission
Une règle de pare-feu ou un blocage Fail2ban traite une connexion observée. Cela ne supprime pas un attaquant qui s’est déjà authentifié. Une connexion réussie transforme un trafic gênant en incident de sécurité potentiel.
En cas de compromission suspectée, isolez le serveur du réseau tout en préservant les preuves nécessaires et en maintenant une voie d’administration contrôlée. Ne vous contentez pas de supprimer un compte suspect avant de remettre l’hôte en ligne. Un attaquant peut avoir créé une persistance, volé des identifiants ou modifié des binaires. La réponse la plus sûre consiste à déterminer l’étendue de l’incident, à reconstruire le système depuis une source fiable lorsque cela est approprié, à corriger la faille initiale, à renouveler les secrets et à surveiller étroitement les services restaurés.
La récupération dépend également de sauvegardes propres et utilisables. Les sauvegardes doivent être isolées des identifiants habituels du serveur et de son plan d’administration, car un attaquant disposant d’un accès administrateur peut tenter de les supprimer ou de les chiffrer. Safenix fournit des sauvegardes hors site pour les serveurs professionnels contrôlés par le client. Les données sont chiffrées à l’aide d’une clé que Safenix ne détient jamais, stockées en Allemagne et conservées de manière immuable pendant la durée de rétention choisie. Il s’agit d’un contrôle de récupération, et non d’un remplacement du renforcement ou de la réponse aux incidents : le client reste responsable du contrôle du serveur protégé et de la décision concernant sa restauration.
Environnements VPS, serveurs dédiés et hébergement mutualisé
Les contrôles dont vous disposez dépendent fortement de la personne qui contrôle le système d’exploitation et la frontière réseau. Un VPS généralement administré par le client donne accès au système d’exploitation, au pare-feu et à la configuration des services. Un administrateur peut ainsi imposer les clés SSH, désactiver la connexion par mot de passe, installer une supervision hôte et restreindre le trafic d’administration, dans les limites de la plateforme du fournisseur.
Un serveur dédié offre généralement un contrôle plus direct de l’hôte, de l’architecture réseau et de l’isolation des charges de travail, même si les responsabilités exactes dépendent toujours du contrat et du modèle de gestion. Un serveur administré peut limiter certaines modifications tout en fournissant une assistance opérationnelle. Documentez cette répartition des responsabilités avant qu’un incident ne survienne.
L’hébergement mutualisé est différent. Le fournisseur contrôle l’hôte, le système d’exploitation, la configuration du serveur web et la frontière de sécurité entre les clients. Les clients peuvent modifier certains paramètres de l’application, mais ils ne peuvent généralement pas installer Fail2ban, modifier les règles du pare-feu hôte, désactiver SSH pour la plateforme ou consulter tous les journaux d’authentification. Les conseils concernant les contrôles de sécurité d’une infrastructure VPS gérée par le client par rapport à un hébergement mutualisé doivent donc être interprétés selon les accès effectivement fournis.
Safenix protège les serveurs contrôlés par le client. Il ne vend pas de plan de sauvegarde pour un site web fonctionnant sur un hébergement mutualisé, et un site en hébergement mutualisé ne doit pas être présenté comme couvert par un service de sauvegarde de serveurs Safenix. Pour un hébergement mutualisé, le client doit utiliser les options de sauvegarde et d’export proposées par l’hébergeur, ou déplacer la charge de travail vers une infrastructure où l’organisation dispose du contrôle nécessaire.
Une routine opérationnelle pratique
La défense contre la force brute fonctionne mieux comme une routine opérationnelle que comme un simple paramètre. Au minimum, examinez régulièrement les services exposés et les comptes privilégiés. Testez les alertes au moyen de simulations autorisées, confirmez que les blocages expirent comme prévu et vérifiez que les administrateurs peuvent toujours accéder à une voie d’urgence.
- Tenez un inventaire des services accessibles depuis Internet, de leurs responsables et des réseaux d’administration approuvés.
- Examinez les tendances des authentifications échouées et réussies, et pas seulement la dernière alerte.
- Utilisez des clés SSH, l’authentification multifacteur, des comptes uniques et le principe du moindre privilège pour l’administration.
- Appliquez les correctifs aux systèmes d’exploitation et aux applications exposées, et supprimez les services inutiles.
- Centralisez les journaux et rendez les alertes exploitables pour l’équipe chargée de la réponse.
- Testez la restauration des sauvegardes et confirmez que les données de récupération sont isolées des identifiants du serveur.
- Documentez les contacts d’escalade, les étapes de préservation des preuves et les procédures de reconstruction.
Les attaques automatisées continueront à sonder les services exposés, mais elles ne doivent pas nécessairement devenir une crise. Réduisez d’abord l’exposition, rendez l’authentification difficile à exploiter, utilisez le blocage comme couche mesurée et surveillez les signes indiquant qu’une tentative s’est transformée en connexion réussie. Lorsque la frontière est franchie, passez sans délai du blocage à la réponse aux incidents et à la récupération.