Blocage au niveau du réseau

Cette page présente la procédure complète permettant de bloquer les attaquants connus au niveau de la couche réseau d'un serveur Linux : un ensemble de blocage par service exposé, actualisé toutes les heures via l’API, chargé dans le noyau de manière atomique, et appliqué au niveau du port afin qu’un attaquant Web ne puisse jamais empêcher l’accès à SSH. Elle couvre ipset avec iptables , nftables natif , IPv6 et les pare-feu en périphérie du cloud .

Tout ce qui suit suppose la possession d’une API Key avec accès au Threat Feed (niveau Contributor et supérieur) et des droits root sur la machine cible. Le /blacklist Endpoint est soumis à des restrictions de fonctionnalités mais n’est pas pris en compte dans votre quota quotidien de vérifications ou de rapports.

Fonctionnement

Listes de services et leurs catégories

Les rapports comportent des identifiants de catégorie de menace. category accepte une liste séparée par des virgules et renvoie uniquement les adresses IP signalées dans au moins l’une d’entre elles. Le catalogue complet (58 catégories, identifiants 1 à 58) est disponible sur la page « Threat Categories » ou via GET /categories sans authentification.

Valeur category valeur pour l’ web ensemble :

21,16,10,19,12,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58

La catégorie 18 (Brute Force générique) apparaît dans la ssh, mail et ftp ensembles : elle regroupe les attaques par identifiants que l’auteur du rapport n’a pas attribuées à un protocole, et les ensembles s’appliquent de toute façon par port de service. Si vous préférez utiliser un seul ensemble de blocage pour tout, omettez category — la liste non filtrée est le sur-ensemble des cinq ensembles.

La requête

Authentification avec l’ X-Key en-tête plutôt qu’au key paramètre de requête, afin que la clé ne figure pas dans les journaux du proxy ou du CDN.

curl -sS -H "X-Key: YOUR_API_KEY" \
  "https://reportedip.com/wp-json/reportedip/v2/blacklist?confidence=90&format=txt&limit=50000&category=22,18"

Taille des listes

Chaque niveau est régénéré côté serveur toutes les 15 minutes et mis en cache jusqu’à 50 000 entrées, ce qui correspond également à la limite maximale par réponse. La taille de réponse par défaut reste fixée à 10 000 pour des raisons de compatibilité ascendante — demandez explicitement davantage avec limit=50000.

Les filtres de catégorie restreignent le niveau que vous demandez, ils ne vont pas au-delà — une web liste constituée à partir de confidence=75 est plus longue que la même liste constituée à partir de confidence=90. Au-delà de 50 000 adresses, le téléchargement de listes cesse d’être la solution adaptée : interrogez plutôt la DNS / RBL Zone ou par adresse, ce qui couvre l’intégralité de la base de données sans aucune limite de taille GET /check par adresse, ce qui couvre l’intégralité de la base de données sans aucune limite de taille .

Pourquoi un niveau de confiance de 90 % permet de limiter les False Positives

Le score n’est pas un simple compteur de Reports. Une adresse IP a besoin d’au moins 10 Reports valides pour dépasser 74 % et d’au moins 2 signalants indépendants ; les Reports ont une demi-vie de 30 jours, de sorte qu’une adresse IP qui a cessé d'attaquer disparaît d’elle-même, et les infrastructures mises en liste blanche (moteurs de recherche, CDN, outils de surveillance, scanners de recherche) sont exclues avant la constitution de la liste. Dans la pratique, les scores de 90 et plus nécessitent de nombreux rapports récents provenant de sources indépendantes, généralement corroborés par des capteurs honeypot. Vous pouvez vérifier n’importe quelle entrée à l’aide de GET /check?ip=<ip>&verbose=true, qui renvoie la répartition complète du score .

Règles opérationnelles

1. Effectuez des requêtes toutes les heures, de manière échelonnée. Cinq listes par heure correspondent à 120 requêtes par jour. Ne lancez pas les cinq requêtes dans la même seconde.
2. Renvoyez l’ETag. Enregistrez l’ ETag en-tête de réponse par liste et renvoyez-le en tant que If-None-Match; une liste inchangée répond 304 Not Modified avec un corps vide. L’ETag correspond exactement à la variante que vous avez demandée, y compris le filtre de catégorie ; conservez donc un fichier d’ETag par liste.
3. Ne jamais vider la liste en cas d’échec. Pour tout statut autre que 200 ou 304, conservez l’ensemble précédent actif et réessayez l’heure suivante. Un pare-feu qui se vide parce qu’une requête a expiré est pire qu’un pare-feu légèrement obsolète.
4. Vérifiez la taille. Refusez d’appliquer une liste dont la taille a considérablement diminué. Le script ci-dessous rejette tout ce qui est inférieur à un minimum par liste, ce qui permet de détecter les réponses tronquées et vides.
5. Séparer les adresses IPv4 et IPv6. Le flux contient les deux. Un ipset créé pour une famille rejette les adresses de l’autre ; chaque liste nécessite donc deux ensembles.

Script de synchronisation (ipset)

Un seul script gère les cinq listes ; le nom de la liste est le seul argument. Il effectue la récupération de manière conditionnelle, valide la taille et transfère le résultat dans le live set de manière atomique. Les entrées sont chargées ipset restore en un seul passage plutôt que par ipset add par adresse IP, ce qui permet de réaliser la mise à jour de 10 000 entrées en bien moins d’une seconde.

#!/bin/sh
# /usr/local/sbin/reportedip-sync.sh <ssh|mail|web|ftp|edge>
# Fetches one service list and swaps it into its ipset atomically.
set -u

API_KEY="YOUR_API_KEY"
BASE="https://reportedip.com/wp-json/reportedip/v2/blacklist?confidence=90&format=txt&limit=50000"
STATE="/var/lib/reportedip"
LIST="${1:-}"

# CATS = category filter, MIN = smallest plausible list size (refuse below this)
case "$LIST" in
  ssh)  CATS="22,18"                  ; MIN=1000 ;;
  mail) CATS="11,7,17,18"             ; MIN=500  ;;
  web)  CATS="21,16,10,19,12,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58" ; MIN=500 ;;
  ftp)  CATS="5,18"                   ; MIN=500  ;;
  edge) CATS="4,14,20"                ; MIN=1000 ;;
  *) echo "usage: $0 ssh|mail|web|ftp|edge" >&2 ; exit 2 ;;
esac

mkdir -p "$STATE"
BODY=$(mktemp) ; HEAD=$(mktemp)
trap 'rm -f "$BODY" "$HEAD" "$BODY.v4" "$BODY.v6"' EXIT
ETAG="$STATE/etag-$LIST"

if [ -s "$ETAG" ]; then
  CODE=$(curl -sS -o "$BODY" -D "$HEAD" -w '%{http_code}' --max-time 60 \
         -H "X-Key: $API_KEY" -H "If-None-Match: $(cat "$ETAG")" "$BASE&category=$CATS")
else
  CODE=$(curl -sS -o "$BODY" -D "$HEAD" -w '%{http_code}' --max-time 60 \
         -H "X-Key: $API_KEY" "$BASE&category=$CATS")
fi

case "$CODE" in
  200) : ;;
  304) logger -t reportedip "[$LIST] unchanged (304)" ; exit 0 ;;
  *)   logger -t reportedip "[$LIST] HTTP $CODE - keeping previous set" ; exit 1 ;;
esac

# The feed carries both families; ipset needs them in separate sets.
grep -E '^[0-9]+(\.[0-9]+){3}$' "$BODY" > "$BODY.v4" || true
grep -E '^[0-9a-fA-F:]+:[0-9a-fA-F:]*$' "$BODY" > "$BODY.v6" || true

COUNT=$(wc -l < "$BODY.v4")
if [ "$COUNT" -lt "$MIN" ]; then
  logger -t reportedip "[$LIST] only $COUNT IPv4 entries (min $MIN) - keeping previous set"
  exit 1
fi

# IPv4: build a scratch set, fill it in one restore pass, swap it in.
ipset create "rip-$LIST"     hash:ip family inet maxelem 65536 -exist
ipset create "rip-$LIST-tmp" hash:ip family inet maxelem 65536 -exist
{ echo "flush rip-$LIST-tmp" ; sed "s|^|add rip-$LIST-tmp |" "$BODY.v4" ; } | ipset restore -exist
ipset swap "rip-$LIST-tmp" "rip-$LIST"
ipset destroy "rip-$LIST-tmp"

# IPv6: same pattern, own family. Skipped when the list has no v6 entries.
ipset create "rip-$LIST-v6" hash:ip family inet6 maxelem 65536 -exist
if [ -s "$BODY.v6" ]; then
  ipset create "rip-$LIST-v6-tmp" hash:ip family inet6 maxelem 65536 -exist
  { echo "flush rip-$LIST-v6-tmp" ; sed "s|^|add rip-$LIST-v6-tmp |" "$BODY.v6" ; } | ipset restore -exist
  ipset swap "rip-$LIST-v6-tmp" "rip-$LIST-v6"
  ipset destroy "rip-$LIST-v6-tmp"
fi

awk 'tolower($1) == "etag:" { print $2 }' "$HEAD" | tr -d '\r' > "$ETAG"
logger -t reportedip "[$LIST] updated: $COUNT IPv4, $(wc -l < "$BODY.v6") IPv6"

Rendez-le exécutable et attribuez-lui une planification horaire échelonnée :

chmod 750 /usr/local/sbin/reportedip-sync.sh

# /etc/cron.d/reportedip
7  * * * * root /usr/local/sbin/reportedip-sync.sh ssh
17 * * * * root /usr/local/sbin/reportedip-sync.sh mail
27 * * * * root /usr/local/sbin/reportedip-sync.sh web
37 * * * * root /usr/local/sbin/reportedip-sync.sh ftp
47 * * * * root /usr/local/sbin/reportedip-sync.sh edge

Règles iptables

Installez-le une seule fois, par exemple dans votre fichier de configuration initiale du pare-feu. Chaque règle correspond à son propre ensemble sur ses propres ports. ip6tables réplique les mêmes règles sur les -v6 ensembles.

# IPv4
iptables -I INPUT -p tcp --dport 22 -m set --match-set rip-ssh src -j DROP
iptables -I INPUT -p tcp -m multiport --dports 25,465,587,110,995,143,993 \
         -m set --match-set rip-mail src -j DROP
iptables -I INPUT -p tcp -m multiport --dports 80,443 \
         -m set --match-set rip-web src -j DROP
iptables -I INPUT -p tcp --dport 21 -m set --match-set rip-ftp src -j DROP
iptables -I INPUT -m set --match-set rip-edge src -j DROP

# IPv6
ip6tables -I INPUT -p tcp --dport 22 -m set --match-set rip-ssh-v6 src -j DROP
ip6tables -I INPUT -p tcp -m multiport --dports 25,465,587,110,995,143,993 \
          -m set --match-set rip-mail-v6 src -j DROP
ip6tables -I INPUT -p tcp -m multiport --dports 80,443 \
          -m set --match-set rip-web-v6 src -j DROP
ip6tables -I INPUT -p tcp --dport 21 -m set --match-set rip-ftp-v6 src -j DROP
ip6tables -I INPUT -m set --match-set rip-edge-v6 src -j DROP

Nftables natif

Sur les systèmes nftables (Debian 12, RHEL 9 et versions plus récentes l'utilisent par défaut), vous pouvez ignorer complètement ipset. Les ensembles nommés résident au sein du jeu de règles, et un inet table contient les adresses IPv4 et IPv6 côte à côte, et nft -f applique l’intégralité d’un fichier en une seule transaction — vidage et remplissage en une seule étape atomique, sans ensemble temporaire ni échange.

Configuration unique

nft add table inet reportedip
nft add chain inet reportedip input '{ type filter hook input priority -10 ; policy accept ; }'

for l in ssh mail web ftp edge ; do
  nft add set inet reportedip "rip-$l"    '{ type ipv4_addr ; }'
  nft add set inet reportedip "rip-$l-v6" '{ type ipv6_addr ; }'
done

nft add rule inet reportedip input tcp dport 22 ip  saddr @rip-ssh  drop
nft add rule inet reportedip input tcp dport 22 ip6 saddr @rip-ssh-v6 drop
nft add rule inet reportedip input tcp dport '{ 25, 110, 143, 465, 587, 993, 995 }' ip  saddr @rip-mail drop
nft add rule inet reportedip input tcp dport '{ 25, 110, 143, 465, 587, 993, 995 }' ip6 saddr @rip-mail-v6 drop
nft add rule inet reportedip input tcp dport '{ 80, 443 }' ip  saddr @rip-web drop
nft add rule inet reportedip input tcp dport '{ 80, 443 }' ip6 saddr @rip-web-v6 drop
nft add rule inet reportedip input tcp dport 21 ip  saddr @rip-ftp drop
nft add rule inet reportedip input tcp dport 21 ip6 saddr @rip-ftp-v6 drop
nft add rule inet reportedip input ip  saddr @rip-edge drop
nft add rule inet reportedip input ip6 saddr @rip-edge-v6 drop

Étape de mise à jour

Remplacez le bloc ipset du script de synchronisation par ceci. Tout le reste — récupération conditionnelle, vérification de la taille , séparation par famille, journalisation — reste inchangé.

# Single transaction: both families flushed and refilled, or nothing changes.
{
  echo "flush set inet reportedip rip-$LIST"
  echo "flush set inet reportedip rip-$LIST-v6"
  [ -s "$BODY.v4" ] && printf 'add element inet reportedip rip-%s { %s }\n' \
      "$LIST" "$(paste -sd, "$BODY.v4")"
  [ -s "$BODY.v6" ] && printf 'add element inet reportedip rip-%s-v6 { %s }\n' \
      "$LIST" "$(paste -sd, "$BODY.v6")"
} | nft -f -

Enregistrez le jeu de règles de la manière habituelle, par exemple :

nft list ruleset > /etc/nftables.conf
systemctl enable nftables

IPv6

Le flux renvoie les adresses IPv4 et IPv6 dans la même liste. IPv6 n’en représente aujourd’hui qu’une petite part — les attaquants utilisent encore principalement la version v4 — mais elle n’est pas nulle, et c’est la partie de la liste qui augmente. Deux règles en découlent :

• Ne mélangez jamais les familles dans un même ipset. Un family inet ensemble rejette toute adresse v6 avec le message « L'élément ne peut pas être ajouté à l'ensemble : il n'appartient pas à la famille de l'ensemble », et une boucle naïve interrompt toute la mise à jour dès la première ligne v6. Le script ci-dessus sépare le corps avant le chargement, de sorte qu'une entrée v6 ne peut jamais corrompre l'ensemble v4.
• Effectuez une correspondance v6 de manière explicite. iptables règles ne détectent jamais le trafic IPv6. Sans les règles de correspondance ip6tables (ou une inet table nftables), un attaquant disposant d’un IPv6 opérationnel contourne un ensemble de blocage parfaitement entretenu.

Bloquer une seule adresse v6 est inefficace en soi — une attribution /64 donne à un attaquant un nombre d’adresses pratiquement illimité. Traitez les entrées v6 comme un indicateur du préfixe environnant : en cas d’abus prolongé, bloquez le /64 à l’aide d’un hash:net ensemble (ipset) ou un ensemble avec flags interval (nftables), et conservez la liste par adresse pour tout le reste.

Pare-feu cloud et périphériques

Si le trafic atteint un CDN ou une périphérie cloud avant d’atteindre votre noyau, le bloquer à ce niveau permet d’économiser la bande passante et la connexion. La liste est la même ; seule la mise en œuvre diffère.

Cloudflare

Gérez une liste d’adresses IP personnalisée au niveau du compte et référencez-la depuis une règle personnalisée du WAF. Le point d’endpoint en masse remplace tous les éléments en un seul appel, ce qui repose sur le même principe d’échange atomique que ipset swap. Les listes personnalisées acceptent des adresses individuelles et des plages CIDR (IPv4 /8–/32, IPv6 /12–/128) ; le nombre d’éléments et de listes dont vous disposez dépend de votre forfait, alors vérifiez votre quota avant de pousser une liste de 10 000 entrées.

# Replace all items of an existing list (returns an async operation id)
curl -sS -X PUT \
  "https://api.cloudflare.com/client/v4/accounts/$CF_ACCOUNT_ID/rules/lists/$CF_LIST_ID/items" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data "$(jq -R -s 'split("\n") | map(select(length > 0) | {ip: .})' < "$BODY.v4")"

Ensuite, une seule règle personnalisée du WAF se charge du blocage, par exemple (ip.src in $rip_web) avec l’action « Block ». Comme la règle ne comporte qu’une seule expression, la taille de la liste n’a pas d’incidence sur le nombre de règles.

AWS

Utilisez un ensemble d’adresses IP WAF, et non des groupes de sécurité ou des listes de préfixes : un ensemble d’adresses IP peut contenir jusqu’à 10 000 adresses ou plages CIDR et est référencé par une seule règle, tandis que les entrées des groupes de sécurité et des listes de préfixes sont comptabilisées individuellement dans les quotas de règles par ressource et atteignent leur limite bien avant 10 000. Les adresses doivent être en notation CIDR, les adresses IP uniques nécessitent donc un /32.

LOCK=$(aws wafv2 get-ip-set --scope REGIONAL --name rip-web --id "$IPSET_ID" \
        --query 'LockToken' --output text)

aws wafv2 update-ip-set --scope REGIONAL --name rip-web --id "$IPSET_ID" \
  --lock-token "$LOCK" \
  --addresses $(sed 's|$|/32|' "$BODY.v4" | head -n 10000 | paste -sd' ')

Autres fournisseurs

Hetzner Cloud, les NSG d’Azure, les politiques de pare-feu GCP et la plupart des pare-feu gérés limitent le nombre de règles ou de plages CIDR par politique bien en dessous de 10 000. Lorsque cette limite est atteinte, réservez la marge pour la edge liste (DDoS, Port Scan, Exploited Hosts — l’ensemble le plus restreint et le plus clair) et exécutez les listes de services dans le noyau de l’hôte, où la taille de l’ensemble n’a aucun coût.

Vérifiez que cela fonctionne

# How many entries are live right now?
ipset list rip-ssh | head -n 8
nft list set inet reportedip rip-ssh | head -n 8

# Is a specific IP in the set?
ipset test rip-ssh 1.2.3.4

# What did the last sync do?
journalctl -t reportedip --since "2 hours ago"

# Are packets actually hitting the rule?
iptables -L INPUT -v -n --line-numbers | grep -i match-set

Avant de passer en mode DROP

• Whitelist d’abord vos propres plages d’adresses, réseaux de gestion, systèmes de surveillance et de sauvegarde à la liste blanche du pare-feu — indépendamment de ce flux. Une ACCEPT règle placée au-dessus de l’ensemble des règles suffit.
• Exécutez chaque liste en mode « journalisation uniquement » pendant 48 heures (-j LOG au lieu de -j DROP, ou log au lieu de drop dans nftables) et examinez ce qui aurait été bloqué.
• Déployez une liste à la fois. Commencez par ssh: elle présente le signal d’attaque le plus clair et le rayon d’impact le plus restreint.
• Conservez la vérification de taille minimale. C’est la seule protection qui empêche une mauvaise réponse d’effacer votre protection.
• Si quelqu’un signale avoir été bloqué, les preuves concernant n’importe quelle adresse sont publiques à l’adresse https://reportedip.com/ip/<ip>/, et la suppression de la liste s’effectue via IP Delisting.

Dépannage

Faites-nous part de vos retours

L'utilisation de la liste est un processus unidirectionnel. Les attaques détectées par votre propre serveur peuvent y être réinjectées : une action fail2ban prête à l'emploi envoie chaque bannissement POST /report avec la Threat Category qui correspond à la « jail ». Les rapports ne décomptent que de votre quota quotidien de rapports, jamais du quota de vérification, et chaque rapport renforce les listes que vous récupérez. Consultez le guide d’intégration de fail2ban.

Référence rapide

Dernière mise à jour: 13. août 2026 · Maintenu par l’équipe ReportedIP