Blockierung auf Netzwerkebene

Diese Seite enthält die vollständige Anleitung zum Abwehren bekannter Angreifer auf der Netzwerkebene eines Linux-Servers : ein Blockiersatz pro exponiertem Dienst, der stündlich über die API aktualisiert, atomar in den Kernel eingeladen und portbezogen angewendet wird, sodass ein Web-Angreifer niemals jemanden aus dem SSH-Zugang aussperrt. Die Anleitung behandelt ipset mit iptables , native nftables , IPv6 sowie Cloud-Edge-Firewalls .

Alle folgenden Angaben setzen einen API Key mit Zugriff auf den Threat Feed (ab der „Contributor“-Stufe) sowie Root-Rechte auf dem Zielrechner voraus. Der /blacklist Endpoint unterliegt einer Funktionsbeschränkung, wird jedoch nicht auf Ihr Tageskontingent für Überprüfungen oder Reports angerechnet.

So funktioniert es

Dienstlisten und ihre Kategorien

Reports tragen IDs von Threat Categories. category akzeptiert eine durch Kommas getrennte Liste und gibt nur IP-Adressen zurück, die unter mindestens einer dieser Threat Categories gemeldet wurden. Der vollständige Katalog (58 Kategorien, IDs 1–58) ist auf der Seite „Threat Categories“ oder über GET /categories ohne Authentifizierung.

Gesamtwert category Wert für den web Menge:

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

Kategorie 18 (generische Brute-Force-Angriffe) erscheint in der ssh, mail und ftp Sammlungen absichtlich auf: Es umfasst Angriffe auf Anmeldedaten, die der Melder keinem bestimmten Protokoll zugeordnet hat, und die Sammlungen werden ohnehin pro Dienstport angewendet. Wenn Sie lieber eine einzige Blockiersammlung für alles verwenden möchten, lassen Sie category — die ungefilterte Liste ist die Obermenge aller fünf.

Die Anforderung

Authentifizierung über den X-Key Header statt des key Abfrageparameter, damit der Schlüssel nicht in Proxy- oder CDN-Protokollen landet.

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"

Wie groß die Listen werden

Jede Ebene wird serverseitig alle 15 Minuten neu generiert und mit bis zu 50.000 Einträgen zwischengespeichert, was zugleich die feste Obergrenze pro Antwort darstellt. Die Standard-Antwortgröße bleibt aus Gründen der Abwärtskompatibilität bei 10.000 – fordern Sie explizit mehr an mit limit=50000.

Kategoriefilter schränken die von Ihnen angeforderte Stufe ein, gehen jedoch nicht darüber hinaus – eine web Liste, die aus confidence=75 ist größer als dieselbe Liste, die aus confidence=90. Ab 50.000 Adressen sind Listendownloads nicht mehr das geeignete Mittel: Fragen Sie stattdessen die DNS / RBL Zone oder GET /check stattdessen pro Adresse abfragen, wodurch die gesamte Datenbank ohne jegliche Größenbeschränkung abgedeckt wird.

Warum ein Konfidenzgrad von 90 % die Anzahl der False Positives gering hält

Der Score ist kein Meldezähler. Eine IP benötigt mindestens 10 gültige Reports, um überhaupt 74 % zu erreichen, sowie mindestens 2 unabhängige Melder; Reports verfallen mit einer Halbwertszeit von 30 Tagen, sodass eine IP, die , fällt von selbst ab, und in die Whitelist aufgenommene Infrastruktur (Suchmaschinen, CDNs, Überwachungsdienste, Forschungsscanner) wird vor der Erstellung der Liste ausgeschlossen. Werte von 90 und darüber erfordern in der Praxis zahlreiche aktuelle Reports aus unabhängigen Quellen, die in der Regel durch Honeypot-Sensoren bestätigt werden. Sie können jeden Eintrag mit GET /check?ip=<ip>&verbose=trueüberprüfen, wodurch die vollständige Aufschlüsselung der Punktzahl zurückgegeben wird.

Betriebsregeln

1. Stündliche Abfrage, zeitlich versetzt. Fünf Listen einmal pro Stunde entsprechen 120 Anfragen pro Tag. Senden Sie nicht alle fünf Anfragen in derselben Sekunde.
2. Senden Sie den ETag zurück. Speichern Sie den ETag Antwort-Header pro Liste und geben Sie ihn als If-None-Match; eine unveränderte Liste wird 304 Not Modified mit leerem Hauptteil. Das Tag deckt genau die von Ihnen angeforderte Variante ab, einschließlich des Kategoriefilters ; verwenden Sie daher pro Liste eine eigene Tag-Datei.
3. Bei Fehlern niemals leeren. Bei jedem anderen Status als 200 oder 304 behalten Sie den vorherigen Satz bei und versuchen Sie es in der nächsten Stunde erneut. Eine Firewall, die sich selbst leert, weil ein Abruf zeitlich abgelaufen ist, ist schlimmer als eine leicht veraltete.
4. Führen Sie eine Plausibilitätsprüfung der Größe durch. Lehnen Sie die Übernahme einer Liste ab, die drastisch geschrumpft ist. Das untenstehende Skript lehnt alles ab, was unter einem listenbezogenen Mindestwert liegt, wodurch abgeschnittene und leere Antworten abgefangen werden.
5. Trennen Sie IPv4 und IPv6. Der Feed enthält beides. Ein für eine Familie erstelltes „ipset“ lehnt Adressen der anderen Familie ab, daher benötigt jede Liste zwei Sätze.

Synchronisierungsskript (ipset)

Ein Skript bedient alle fünf Listen; der Listenname ist das einzige Argument. Es führt bedingte Abrufe durch, überprüft die Größe und überträgt das Ergebnis atomar in den Live-Satz. Die Einträge werden ipset restore in einem einzigen Durchlauf statt pro ipset add pro IP, wodurch die Aktualisierung von 10.000 Einträgen deutlich unter einer Sekunde bleibt.

#!/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"

Machen Sie das Skript ausführbar und weisen Sie ihm einen gestaffelten stündlichen Zeitplan zu:

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

iptables-Regeln

Installieren Sie diese einmal, beispielsweise in Ihrer Firewall-Bootstrap-Datei. Jede Regel gleicht ihr eigenes Set an ihren eigenen Ports ab. ip6tables spiegelt dieselben Regeln auf die -v6 Sets.

# 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

Native nftables

Auf nftables-Systemen (Debian 12, RHEL 9 und neuere Versionen verwenden dies standardmäßig) können Sie ipset vollständig überspringen. Benannte Sets befinden sich innerhalb des Regelsatzes, und eine inet Tabelle enthält IPv4 und IPv6 nebeneinander, und nft -f wendet eine gesamte Datei als eine einzige Transaktion an – Leeren und Neubefüllen in ein und demselben atomaren Schritt, ohne temporären Satz und ohne Austausch.

Einmalige Einrichtung

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

Aktualisierungsschritt

Ersetzen Sie den ipset-Block des Synchronisierungsskripts durch diesen. Alles andere – bedingtes Abrufen, Größenprüfung, Familientrennung, Protokollierung – bleibt unverändert.

# 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 -

Speichern Sie den Regelsatz wie gewohnt, zum Beispiel:

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

IPv6

Der Feed liefert IPv4 und IPv6 in derselben Liste zurück. IPv6 macht derzeit nur einen geringen Anteil davon aus – Angreifer nutzen nach wie vor überwiegend v4 –, doch dieser Anteil ist nicht gleich Null und stellt den Teil der Liste dar, der wächst. Daraus ergeben sich zwei Regeln:

• Mischen Sie niemals Familien in einem „ipset“. Ein family inet Satz lehnt jede v6- Adresse mit der Meldung „Element kann dem Satz nicht hinzugefügt werden: Es gehört nicht zur Familie des Satzes“ ab, und eine naive Schleife bricht die gesamte Aktualisierung bereits bei der ersten v6-Zeile ab. Das obige Skript teilt den Hauptteil vor dem Laden auf, sodass ein v6-Eintrag den v4-Satz niemals zerstören kann.
• Führen Sie eine explizite v6-Übereinstimmung durch. iptables Regeln erkennen IPv6-Datenverkehr nicht. Ohne die entsprechenden ip6tables (oder einer inet nftables-Tabelle) umgeht ein Angreifer mit funktionierendem IPv6 ein perfekt gepflegtes Block-Set.

Das Blockieren einer einzelnen v6-Adresse ist für sich genommen unzureichend – eine /64-Zuweisung verschafft einem Angreifer praktisch unbegrenzte Adressen. Behandeln Sie v6-Einträge als Hinweis auf das umgebende Präfix: Bei anhaltendem Missbrauch blockieren Sie das /64 mit einem hash:net Set (ipset) oder einem Set mit flags interval (nftables) und behalten Sie die adressspezifische Liste für alle anderen Fälle bei.

Cloud- und Edge-Firewalls

Wenn der Datenverkehr ein CDN oder einen Cloud-Edge erreicht, bevor er Ihren Kernel erreicht, spart eine Sperrung an dieser Stelle Bandbreite und schont die Verbindung. Die Liste ist dieselbe; lediglich die Bereitstellung unterscheidet sich.

Cloudflare

Verwalten Sie eine benutzerdefinierte IP-Liste auf Kontoebene und verweisen Sie in einer benutzerdefinierten WAF-Regel darauf. Der Bulk-Endpoint ersetzt alle Einträge in einem einzigen Aufruf – dies entspricht demselben Prinzip des „Atomic Swap“ wie ipset swap. Benutzerdefinierte Listen akzeptieren einzelne Adressen und CIDR-Bereiche (IPv4 /8–/32, IPv6 /12–/128); wie viele Einträge und Listen Ihnen zur Verfügung stehen, hängt von Ihrem Tarif ab; überprüfen Sie daher Ihr Kontingent, bevor Sie eine Liste mit 10.000 Einträgen hochladen.

# 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")"

Anschließend übernimmt eine einzige benutzerdefinierte WAF-Regel die Blockierung, zum Beispiel (ip.src in $rip_web) mit der Aktion „Blockieren“. Da die Regel aus einem einzigen Ausdruck besteht, hat die Listengröße keinen Einfluss auf die Anzahl der Regeln.

AWS

Verwenden Sie einen WAF-IP-Satz, keine Sicherheitsgruppen oder Präfixlisten: Ein IP-Satz fasst bis zu 10.000 Adressen oder CIDR-Bereiche und wird von einer einzigen Regel referenziert, während Einträge in Sicherheitsgruppen und Präfixlisten einzeln auf die ressourcenbezogenen Regelkontingente angerechnet werden und diese weit vor Erreichen der 10.000er-Marke erschöpft sind. Adressen müssen in CIDR-Notation vorliegen, daher benötigen einzelne IP-Adressen ein /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' ')

Andere Anbieter

Hetzner Cloud, Azure-NSGs, GCP-Firewall-Richtlinien und die meisten verwalteten Firewalls begrenzen die Anzahl der Regeln oder CIDRs pro Richtlinie deutlich unter 10.000. Wenn die Obergrenze erreicht ist, behalten Sie die Liste edge Liste (DDoS, Port Scans, Exploited Hosts – die kleinste und eindeutigste Gruppe) und führen Sie die Servicelisten im Kernel auf dem Host aus, wo die Größe der Liste keine Rolle spielt.

Überprüfen Sie, ob es funktioniert

# 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

Bevor Sie auf „DROP“ umstellen

• , setzen Sie Ihre eigenen Adressbereiche, Verwaltungsnetzwerke sowie Überwachungs- und Backup-Systeme zunächst in der Firewall auf die Whitelist – unabhängig von diesem Feed. Eine ACCEPT Regel, die über den Set-Regeln platziert wird, reicht aus.
• Führen Sie jede Liste 48 Stunden lang im reinen Protokollierungsmodus aus (-j LOG anstatt -j DROP, oder log anstelle von drop in nftables) und lesen Sie nach, was blockiert worden wäre.
• Führen Sie jeweils nur eine Liste ein. Beginnen Sie mit ssh: Diese weist das deutlichste Angriffssignal und den geringsten Wirkungsradius auf.
• Behalten Sie die Überprüfung der Mindestgröße bei. Sie ist die einzige Schutzmaßnahme, die verhindert, dass eine fehlerhafte Antwort Ihren Schutz zunichte macht.
• Sollte jemand melden, blockiert worden zu sein, sind die Nachweise für jede Adresse öffentlich einsehbar unter https://reportedip.com/ip/<ip>/, und die Entfernung aus der Liste erfolgt über IP Delisting.

Fehlerbehebung

Bitte melden Sie uns

Die Nutzung der Liste erfolgt in eine Richtung. Die Angriffe, die Ihr eigener Server registriert, können wieder in die Liste zurückfließen: Eine vorgefertigte fail2ban-Aktion übermittelt jede Sperre an POST /report mit der Threat Category, die zum „Jail“ passt. Reports belasten ausschließlich Ihr tägliches Berichts-Kontingent, niemals das Prüfkontingent, und jeder Bericht stärkt die von Ihnen abgerufenen Listen. Siehe den fail2ban-Integrationsleitfaden.

Kurzübersicht

Zuletzt aktualisiert: 13. August 2026 · Betreut vom ReportedIP-Team