Quelles listes d’IP malveillantes utiliser pour sécuriser un serveur ?

Un serveur accessible depuis Internet reçoit rapidement des requêtes qui n’ont rien à voir avec ses visiteurs habituels. Des robots parcourent en permanence le Web à la recherche de fichiers .env, de dépôts .git, de sauvegardes oubliées, de fichiers de configuration accessibles ou de vulnérabilités connues dans WordPress et d’autres applications.

Des outils comme CrowdSec, Fail2ban ou ModSecurity permettent de détecter une partie de ces comportements et de bloquer une adresse IP lorsqu’elle devient suspecte. Les listes d’IP malveillantes permettent d’ajouter une protection en amont. Elles regroupent des adresses qui ont déjà été observées en train de scanner ou d’attaquer d’autres serveurs. Lorsqu’une de ces IP arrive ensuite sur votre infrastructure, elle peut être bloquée immédiatement sans attendre qu’elle reproduise le même comportement chez vous.

Il existe de nombreuses blocklists publiques, mais elles ne surveillent pas toutes les mêmes attaques, ne conservent pas les adresses pendant la même durée et ne sont pas forcément adaptées à votre serveur web.

Pour vérifier leur intérêt, j’ai comparé plusieurs listes publiques avec trente adresses IP qui avaient déjà été bannies sur mon propre serveur après des comportements hostiles.

Une blocklist permet de bloquer certains scanners avant leur première requête

Lorsqu’une adresse IP tente d’accéder à /.env, /.git/config, à des sauvegardes ou à plusieurs chemins associés à des vulnérabilités connues, il est peu probable que votre serveur soit sa première cible. Ces scanners parcourent une quantité considérable de sites et de serveurs. Certains utilisent des VPS spécialisés dans ce type d’activité, tandis que d’autres s’appuient sur des instances temporaires louées chez Google Cloud, Microsoft Azure, DigitalOcean ou d’autres fournisseurs légitimes.

Il serait évidemment disproportionné de bloquer l’ensemble d’un hébergeur parce que quelques machines sont utilisées pour effectuer des scans malveillants. Une blocklist récente permet justement d’être beaucoup plus précis en ne bloquant que les adresses qui ont été observées comme abusives.

Cette protection ne remplace pas les autres mécanismes de sécurité. Le serveur doit toujours être capable de détecter lui-même une attaque inconnue, car une nouvelle machine peut commencer à scanner Internet avant même d’avoir été signalée dans une quelconque base de réputation.

Une blocklist est donc surtout intéressante pour éliminer une partie du bruit connu avant qu’il n’atteigne l’application.

J’ai comparé les listes avec des IP bannies sur mon serveur

Plutôt que de comparer uniquement les descriptions fournies par les différents services, j’ai utilisé 30 adresses IP bannies sur un serveur web après des comportements clairement suspects. Ces machines recherchaient des fichiers sensibles ou d’autres ressources qui ne devraient jamais être demandées par un visiteur normal.

J’ai ensuite recherché les mêmes adresses dans plusieurs blocklists publiques afin de déterminer si les scanners observés sur mon serveur étaient également connus ailleurs.

AbuseIPDB a retrouvé 16 de ces 30 adresses, soit 53,3 %. Blocklist.de Apache en contenait 14, soit 46,7 %, GreenSnow 11, soit 36,7 %, et IPsum niveau 4 seulement 4. CINS Army ne contenait aucune des trente IP au moment du test.

Ces résultats sont naturellement temporaires puisque le contenu des listes évolue. Une adresse présente aujourd’hui peut être supprimée demain et une nouvelle adresse peut apparaître quelques minutes après avoir commencé à scanner Internet.

L’intérêt du test était surtout de vérifier si mes propres détections correspondaient à ce que d’autres systèmes observaient indépendamment. C’était clairement le cas.

1. AbuseIPDB retrouve plus de la moitié des IP testées

AbuseIPDB repose en grande partie sur des signalements effectués par différents utilisateurs et systèmes. Son fonctionnement permet d’attribuer un niveau de confiance à une adresse selon les informations disponibles. Il est alors possible de ne retenir que les IP dont le score est suffisamment élevé.

Sur mon échantillon, une sélection à très haut niveau de confiance a retrouvé 16 des 30 adresses testées, soit 53,3 %. C’est le taux de correspondance le plus élevé parmi les sources généralistes que j’ai comparées.

La majorité de ces adresses étaient toutefois déjà présentes dans Blocklist.de ou GreenSnow. AbuseIPDB a ajouté trois IP supplémentaires que ces deux listes n’avaient pas retrouvées, ce qui a fait passer la couverture cumulée de 19 à 22 adresses sur 30.

Une adresse signalée une seule fois ne doit pas nécessairement être traitée de la même manière qu’une IP observée quotidiennement en train de scanner des centaines de serveurs. Plus le niveau de confiance demandé est élevé, plus la liste devient restrictive.

AbuseIPDB peut être intéressant en complément, mais je le considère moins spécialisé que Blocklist.de Apache pour un serveur web. Son intérêt principal est d’élargir la couverture avec des adresses déjà fortement signalées ailleurs plutôt que de remplacer une liste directement orientée vers les attaques HTTP.

2. Blocklist.de Apache retrouve près d’une IP testée sur deux

Parmi les listes que j’ai pu comparer directement, Blocklist.de Apache est celle qui correspondait le mieux aux attaques observées sur mon serveur. 14 de mes 30 adresses y étaient présentes au moment du test. Près d’une IP sur deux que mon système avait bannie était donc également connue par cette source.

Blocklist.de propose plusieurs listes correspondant à différents types de services. Certaines concernent SSH, la messagerie ou FTP, tandis que la liste Apache se concentre davantage sur des comportements liés aux serveurs web.

Elle conserve des adresses récemment signalées pour des attaques contre des serveurs HTTP et différents comportements associés. La liste est régulièrement régénérée et les adresses qui ne sont plus observées finissent par en disparaître.

Pendant mon test, certaines de mes IP apparaissaient également aux côtés de nombreuses autres adresses appartenant au même petit réseau. Cela montre que mon serveur n’avait pas simplement rencontré quelques machines isolées. D’autres systèmes observaient au même moment des scanners provenant des mêmes infrastructures.

Pour un serveur web exposé publiquement, Blocklist.de Apache est donc une source particulièrement intéressante à tester sur votre serveur.

3. GreenSnow complète Blocklist.de

GreenSnow a retrouvé 11 de mes 30 adresses. Le chiffre est inférieur à celui obtenu avec Blocklist.de Apache, mais les deux listes ne contenaient pas exactement les mêmes machines.

Plusieurs adresses absentes de Blocklist.de étaient présentes chez GreenSnow. C’était le cas de plusieurs instances cloud appartenant à une même série que mon serveur avait identifiée comme hostile. En réunissant les deux sources, 19 de mes trente IP étaient présentes dans au moins une liste. Cela représente 63,3 % de mon échantillon.

GreenSnow surveille différents comportements comme les scans de ports, certaines attaques observées par ModSecurity et différentes tentatives contre des services accessibles sur Internet.

Son périmètre est donc plus large que celui de la liste Apache de Blocklist.de, ce qui explique qu’elle puisse détecter des machines différentes.

Dans cette configuration, les deux listes se complètent.

CrowdSec permet de combiner les détections locales avec des listes externes

CrowdSec est particulièrement intéressant pour ce type de configuration puisqu’il peut continuer à analyser les journaux du serveur tout en utilisant des informations provenant d’autres sources.

Une adresse inconnue qui commence à rechercher des fichiers sensibles peut toujours être détectée localement par CrowdSec ou ModSecurity. En parallèle, une IP déjà identifiée par une blocklist peut être bloquée immédiatement sans attendre qu’elle répète le même comportement.

Les allowlists sont indispensables avant d’importer plusieurs milliers d’adresses

Lors de mon premier import de Blocklist.de Apache, le fichier contenait un peu plus de 10 000 adresses. Certaines correspondaient pourtant à des infrastructures que mon serveur doit explicitement accepter.

Plusieurs adresses Cloudflare apparaissaient dans la liste, ainsi que des IP appartenant à des robots que j’avais déjà déclarés comme fiables. CrowdSec les a ignorées automatiquement grâce aux allowlists présentes sur le serveur. Ce comportement est essentiel.

Une liste de réputation externe ne connaît pas votre architecture. Elle peut considérer une adresse comme suspecte alors que cette même adresse est indispensable au fonctionnement de votre infrastructure. Le problème est particulièrement important lorsqu’un site se trouve derrière Cloudflare ou un autre reverse proxy.

Bloquer une adresse utilisée par le proxy peut empêcher de véritables visiteurs d’accéder au site alors que leur propre IP n’est même jamais directement visible par le serveur. Les plages officielles du CDN, les outils de supervision, certains crawlers et les autres services indispensables doivent donc être protégés avant l’import d’une blocklist.

Une adresse IP malveillante peut redevenir légitime demain

Un attaquant peut louer une machine virtuelle pendant quelques heures, effectuer plusieurs milliers de scans puis supprimer cette instance. L’adresse IP pourra ensuite être réattribuée à un autre client qui n’a aucun rapport avec les attaques précédentes. Le même phénomène existe sur certaines connexions résidentielles, avec les VPN, les proxies et différentes infrastructures mutualisées.

Une bonne blocklist doit donc évoluer régulièrement. Lorsqu’une adresse n’est plus considérée comme malveillante par la source, elle doit également pouvoir disparaître du système de blocage de votre serveur.

Importer une liste une seule fois puis conserver indéfiniment toutes ses adresses est une mauvaise approche. Quelques mois plus tard, certaines de ces IP peuvent avoir complètement changé d’utilisation. La fraîcheur de la liste est au moins aussi importante que son nombre d’adresses.

Une rotation régulière permet de retirer les anciennes IP

Je n’ai pas choisi d’importer Blocklist.de une seule fois puis de conserver toutes ses adresses. La liste est récupérée régulièrement et chaque décision possède une durée limitée. Lorsqu’un nouveau fichier est disponible, il est d’abord vérifié puis importé. L’ancienne version n’est retirée qu’une fois le nouvel import terminé correctement.

Cette organisation permet de conserver une protection active même si un téléchargement échoue temporairement.

Elle permet aussi de suivre naturellement les changements effectués par la source. Lorsqu’une IP disparaît de Blocklist.de, elle n’est plus renouvelée sur mon serveur et sa décision finit elle aussi par expirer. À l’inverse, une adresse toujours présente dans la liste continue d’être bloquée lors des rotations suivantes.

Ce fonctionnement évite d’accumuler indéfiniment des milliers d’anciennes décisions qui ne correspondent plus à la réputation actuelle des adresses.