Blocklisten einbinden: nftables, iptables, pfSense, OPNsense, MikroTik und mehr

So bindest du die IP-Blocklisten von IPv64.net in deine Firewall, deinen Server oder Reverse-Proxy ein: Linux mit nftables oder iptables/ipset, pfSense, OPNsense, MikroTik, Palo Alto, FortiGate, Sophos, nginx, CrowdSec und Node64. Diese Seite ist der Integrationsleitfaden von IPv64.net; die frühere Adresse https://ipv64.net/v64_blocklist_integration_guide leitet hierher weiter. Die Linux-Skripte sowie die Beispiele für nginx und CrowdSec sind mit den echten Listen getestet.

Bevor du loslegst

Eine Blocklist verwirft allen Verkehr aus den gelisteten Netzen. Probiere sie zuerst auf einem Testsystem, behalte einen zweiten Zugang zum Gerät (Konsole, VPN) und beginne mit einer Liste mit wenigen Fehlalarmen – Spamhaus DROP (spamhaus_drop) oder FireHOL Level 1 (firehole_l1). Welche Liste wofür taugt, steht unter Welche Liste für wen?.

1. Liste wählen
   Die ID der Liste findest du in der Übersicht, z. B. firehole_l1, all_notor oder v64.
2. Adresse bilden
   IPv4 und IPv6: https://ipv64.net/blocklists/ipv64_blocklist_<id>.txt, nur IPv4: …/ipv64_blocklist_v4_<id>.txt, nur IPv6: …/ipv64_blocklist_v6_<id>.txt, MikroTik: …/v64_mikrotik_v4_<id>.rsc und …_v6_<id>.rsc. Je Zeile steht eine Adresse oder ein Netz (CIDR), ohne Kommentare.
3. Intervall festlegen
   Höchstens alle 30 Minuten abrufen; alle 1 bis 6 Stunden reicht. Für den Live-Stand der v64 Blocklist siehe Live-Stand mit Listen-Token.
4. Richtung wählen
   Die meisten Listen sperrst du eingehend nach Absender (Source). Spamhaus DROP und Feodo Tracker lohnen sich zusätzlich ausgehend (Destination), die DoH-Server-Liste nur ausgehend.

Liste wählen

Jede Liste gibt es in drei Varianten (IPv4 und IPv6, nur IPv4, nur IPv6) und als MikroTik-Importdatei; die Adressen stehen oben unter Adresse bilden. Die Listen werden mehrmals täglich neu erzeugt. Länder- und Kontinentlisten stehen auf der Listenseite und unter Länder- und Kontinentlisten. Für Skripte nennt die index.json jede Liste mit Anzahl, Stand, Quelle, Lizenz und Dateinamen (siehe index.json). Alle Listen im Detail: Alle Listen im Überblick.

Quellen, Fehlalarme und Bedingungen

IPv64.net fasst öffentliche Listen zusammen und bereinigt sie: Alles wird in Netze umgewandelt, Doppelte, enthaltene Netze und reservierte Bereiche fallen weg. Die Einträge selbst stammen aus diesen Projekten:

• Spamhaus DROP
• FireHOL Level 1
• blocklist.de
• DShield (SANS ISC) (CC BY-NC-SA 2.5, nicht für kommerzielle Zwecke)
• Tor Project
• abuse.ch Feodo Tracker (CC0)
• Emerging Threats
• CINS Army
• IPsum (Unlicense)
• DoH-IP-blocklists (GPL-3.0)
• Honeypot64 (IPv64.net, CC BY 4.0): v64 Blocklist
• Cloud-Netze, wie veröffentlicht von Cloudflare, AWS und Google Cloud
• KI-Crawler: die Adresslisten der Betreiber und ai.robots.txt (MIT), siehe KI-Crawler
• Herkunft (country_ranges.txt.gz): DB-IP.com (CC BY 4.0, Namensnennung „IP-Länderdaten: DB-IP.com“), Länderlisten aus den Daten der regionalen Registrierungsstellen, siehe Länder- und Kontinentlisten

Lizenz, Fehlalarme und Größe jeder Liste stehen in der Übersicht. Ist eine deiner Adressen fälschlich gelistet, beantragst du die Löschung beim jeweiligen Projekt; mit der nächsten Aktualisierung verschwindet sie auch aus den IPv64-Listen. Für die v64 Blocklist beantragst du die Freigabe in der IP-Auskunft (siehe Freigabe). Die Listen sind kostenlos nutzbar; bitte beachte die Bedingungen der Quellprojekte und verlass dich nicht allein auf sie.

Linux: nftables oder iptables/ipset

Für Linux-Server und Linux-Router stellt IPv64.net zwei fertige Skripte bereit. Beide laden die gewählte Liste für IPv4 und IPv6, tauschen sie in einem Schritt aus und lassen bei einem fehlgeschlagenen Download die alte Liste aktiv. Als Parameter bekommen sie die ID der Liste (Standard: firehole_l1).

nftables (empfohlen)

Für aktuelle Debian-, Ubuntu-, Fedora- und Proxmox-Systeme und die meisten Linux-Router. Das Skript legt eine eigene Tabelle inet ipv64 an und ersetzt sie bei jedem Lauf vollständig. Deine übrigen Regeln bleiben unberührt. Es filtert Verkehr an den Host selbst (input) und weitergeleiteten Verkehr (forward), also auch an Docker-Container und Hosts hinter NAT. Die Skripte für nftables, ipset, nginx und CrowdSec hat IPv64.net mit den echten Listen getestet.

Einrichten (als root):

apt install -y nftables curl
curl -fsSo /usr/local/sbin/ipv64-blocklist-nft.sh https://ipv64.net/blocklists/tools/ipv64-blocklist-nft.sh
chmod +x /usr/local/sbin/ipv64-blocklist-nft.sh
/usr/local/sbin/ipv64-blocklist-nft.sh firehole_l1

Alle 4 Stunden und nach einem Neustart aktualisieren (cron):

cat > /etc/cron.d/ipv64-blocklist <<'EOF'
17 */4 * * * root /usr/local/sbin/ipv64-blocklist-nft.sh firehole_l1 >/dev/null
@reboot      root sleep 30 && /usr/local/sbin/ipv64-blocklist-nft.sh firehole_l1 >/dev/null
EOF

Prüfen und entfernen:

nft list chain inet ipv64 input     # Zähler zeigen verworfene Pakete
nft delete table inet ipv64          # Blocklist komplett entfernen

Das Skript (https://ipv64.net/blocklists/tools/ipv64-blocklist-nft.sh), damit du vor dem Ausführen weißt, was es tut. Es lädt ipv64_blocklist_v4_<id>.txt und ipv64_blocklist_v6_<id>.txt, übernimmt nur Zeilen, die wie eine Adresse oder ein Netz aussehen, und schreibt die Sets bl4/bl6 mit den Ketten input und forward (Priorität −10):

#!/bin/sh
# IPv64.net blocklist for nftables (IPv4 + IPv6) - https://ipv64.net/v64_blocklist_integration_guide
# Usage: ipv64-blocklist-nft.sh [list]   (default: firehole_l1, see https://ipv64.net/v64_blocklists)
# Run as root. Replaces table "inet ipv64" atomically; on a failed download the old sets stay active.
set -eu
LIST="${1:-firehole_l1}"
BASE="https://ipv64.net/blocklists"
TMP="$(mktemp -d)"
trap 'rm -rf "$TMP"' EXIT

for v in 4 6; do
	curl -fsS --max-time 120 -o "$TMP/raw$v" "$BASE/ipv64_blocklist_v${v}_${LIST}.txt"
	# only keep lines that look like an address or network
	grep -E '^[0-9A-Fa-f:.]+(/[0-9]{1,3})?$' "$TMP/raw$v" > "$TMP/v$v" || true
done
if [ ! -s "$TMP/v4" ] && [ ! -s "$TMP/v6" ]; then
	echo "ipv64-blocklist: download empty, keeping the active sets" >&2
	exit 1
fi

elements() { # file -> "elements = { a, b, ... }" (nothing for an empty file)
	[ -s "$1" ] || return 0
	printf '\t\telements = { '
	paste -sd, "$1" | sed 's/,/, /g'
	printf ' }\n'
}

{
	echo "table inet ipv64"
	echo "delete table inet ipv64"
	echo "table inet ipv64 {"
	printf '\tset bl4 {\n\t\ttype ipv4_addr\n\t\tflags interval\n\t\tauto-merge\n'
	elements "$TMP/v4"
	printf '\t}\n\tset bl6 {\n\t\ttype ipv6_addr\n\t\tflags interval\n\t\tauto-merge\n'
	elements "$TMP/v6"
	printf '\t}\n'
	# drop traffic FROM listed networks to this host and to forwarded/NATed hosts (routers, Docker)
	printf '\tchain input {\n\t\ttype filter hook input priority -10; policy accept;\n\t\tip saddr @bl4 counter drop\n\t\tip6 saddr @bl6 counter drop\n\t}\n'
	printf '\tchain forward {\n\t\ttype filter hook forward priority -10; policy accept;\n\t\tip saddr @bl4 counter drop\n\t\tip6 saddr @bl6 counter drop\n\t}\n'
	echo "}"
} > "$TMP/ipv64.nft"

nft -f "$TMP/ipv64.nft"
echo "ipv64-blocklist: $LIST loaded ($(wc -l < "$TMP/v4") IPv4, $(wc -l < "$TMP/v6") IPv6 entries)"

iptables und ipset

Für Systeme, die noch iptables nutzen. Das Skript füllt je ein Set für IPv4 und IPv6 (ipv64-v4, ipv64-v6) per ipset restore, tauscht es ein und legt die DROP-Regeln nur einmal an: in INPUT, FORWARD und, falls vorhanden, in Dockers Kette DOCKER-USER.

apt install -y ipset iptables curl
curl -fsSo /usr/local/sbin/ipv64-blocklist-ipset.sh https://ipv64.net/blocklists/tools/ipv64-blocklist-ipset.sh
chmod +x /usr/local/sbin/ipv64-blocklist-ipset.sh
/usr/local/sbin/ipv64-blocklist-ipset.sh firehole_l1
echo '17 */4 * * * root /usr/local/sbin/ipv64-blocklist-ipset.sh firehole_l1 >/dev/null' > /etc/cron.d/ipv64-blocklist
echo '@reboot root sleep 30 && /usr/local/sbin/ipv64-blocklist-ipset.sh firehole_l1 >/dev/null' >> /etc/cron.d/ipv64-blocklist

Die @reboot-Zeile stellt Sets und Regeln nach einem Neustart wieder her; ipset-persistent ist dafür nicht nötig. Docker legt seine Ketten beim Neustart des Dienstes neu an – führe das Skript danach einmal erneut aus.

Das Skript (https://ipv64.net/blocklists/tools/ipv64-blocklist-ipset.sh). Es legt die Sets als hash:net mit bis zu 1.048.576 Einträgen an, füllt ein neues Set und tauscht es mit ipset swap gegen das aktive; ist der IPv4-Download leer, bricht es ab und lässt das aktive Set stehen:

#!/bin/sh
# IPv64.net blocklist for iptables + ipset (IPv4 + IPv6) - https://ipv64.net/v64_blocklist_integration_guide
# Usage: ipv64-blocklist-ipset.sh [list]   (default: firehole_l1, see https://ipv64.net/v64_blocklists)
# Run as root. Loads the list into a new set and swaps it in; on a failed download the old set stays active.
set -eu
LIST="${1:-firehole_l1}"
BASE="https://ipv64.net/blocklists"
TMP="$(mktemp -d)"
trap 'rm -rf "$TMP"' EXIT

for v in 4 6; do
	fam=inet; ipt=iptables
	[ "$v" = 6 ] && { fam=inet6; ipt=ip6tables; }
	set="ipv64-v$v"; new="ipv64-v$v-new"
	curl -fsS --max-time 120 -o "$TMP/raw" "$BASE/ipv64_blocklist_v${v}_${LIST}.txt"
	grep -E '^[0-9A-Fa-f:.]+(/[0-9]{1,3})?$' "$TMP/raw" > "$TMP/list" || true
	n=$(wc -l < "$TMP/list")
	if [ "$n" -eq 0 ] && [ "$v" = 4 ]; then
		echo "ipv64-blocklist: IPv4 download empty, keeping the active set" >&2
		exit 1
	fi
	ipset create -exist "$set" hash:net family "$fam" maxelem 1048576
	ipset destroy "$new" 2>/dev/null || true
	{ echo "create $new hash:net family $fam maxelem 1048576"; sed "s/^/add $new /" "$TMP/list"; } | ipset restore -exist
	ipset swap "$new" "$set"
	ipset destroy "$new"
	# rules only once: -C checks whether the rule exists already
	for chain in INPUT FORWARD; do
		$ipt -C "$chain" -m set --match-set "$set" src -j DROP 2>/dev/null || $ipt -I "$chain" -m set --match-set "$set" src -j DROP
	done
	# Docker publishes ports through DOCKER-USER, not INPUT
	if $ipt -nL DOCKER-USER >/dev/null 2>&1; then
		$ipt -C DOCKER-USER -m set --match-set "$set" src -j DROP 2>/dev/null || $ipt -I DOCKER-USER -m set --match-set "$set" src -j DROP
	fi
	echo "ipv64-blocklist: $set ($LIST) loaded with $n entries"
done

pfSense: URL-Tabelle als Alias

1. Alias anlegen
   Firewall › Aliases › URLs › Add: Type URL Table (IPs), Name z. B. IPv64_firehol, URL https://ipv64.net/blocklists/ipv64_blocklist_firehole_l1.txt, Aktualisierung 1 Tag. Speichern und Apply Changes.
2. Regel auf dem WAN
   Firewall › Rules › WAN › Add (Pfeil nach oben = ganz oben): Action Block, Address Family IPv4+IPv6, Protocol Any, Source: Single host or alias = IPv64_firehol, Destination any. Speichern und übernehmen.
3. Optional ausgehend
   Für Spamhaus DROP empfohlen: Firewall › Rules › LAN, Block-Regel ganz oben mit Destination = Alias. So erreichen befallene Geräte die gelisteten Netze nicht.

Große Listen (Länder) können Firewall Maximum Table Entries unter System › Advanced › Firewall & NAT überschreiten; erhöhe den Wert, wenn der Alias leer bleibt. Unter Diagnostics › Tables siehst du die geladenen Einträge. pfSense prüft URL-Tabellen einmal täglich, der Live-Stand der v64 Blocklist bringt hier also keinen Vorteil.

Das Paket pfBlockerNG beschreibt der Leitfaden nicht; die Textlisten lassen sich aber überall nutzen, wo eine URL mit einer Adresse oder einem Netz je Zeile erwartet wird.

OPNsense: Alias vom Typ URL Table

1. Alias anlegen
   Firewall › Aliases › +: Type URL Table (IPs), Name z. B. IPv64_firehol, Aktualisierung 0 Tage 4 Stunden, Inhalt https://ipv64.net/blocklists/ipv64_blocklist_firehole_l1.txt. Speichern und Apply.
2. Regel auf dem WAN
   Firewall › Rules › WAN › +: Action Block, Direction in, TCP/IP Version IPv4+IPv6, Protocol any, Source = IPv64_firehol, Destination any. Speichern, Regel ganz nach oben ziehen und übernehmen.
3. Optional ausgehend
   Auf dem LAN eine Block-Regel mit Destination = Alias.

Unter Firewall › Diagnostics › Aliases siehst du die geladenen Einträge und die letzte Aktualisierung.

MikroTik RouterOS 7

IPv64.net stellt für jede Liste fertige Importdateien bereit. Jede Datei entfernt zuerst ihre eigenen alten Einträge und trägt dann die aktuellen in die Adressliste IPv64-<id> ein. Das folgende Skript lädt die Dateien für IPv4 und IPv6, importiert sie und läuft per Scheduler alle 6 Stunden. Füge es im Terminal ein (Winbox › New Terminal):

/system script add name=ipv64-blocklist policy=read,write,test source={
  :foreach v in={"v4";"v6"} do={
    :local f ("ipv64-" . $v . ".rsc")
    /tool fetch url=("https://ipv64.net/blocklists/v64_mikrotik_" . $v . "_firehole_l1.rsc") dst-path=$f
    :delay 2s
    /import file-name=$f
    /file remove $f
  }
}
/system scheduler add name=ipv64-blocklist interval=6h start-time=startup on-event="/system script run ipv64-blocklist"
/system script run ipv64-blocklist
/ip firewall raw add chain=prerouting src-address-list=IPv64-firehole_l1 action=drop comment="IPv64 blocklist"
/ipv6 firewall raw add chain=prerouting src-address-list=IPv64-firehole_l1 action=drop comment="IPv64 blocklist"

• Die raw-Regeln verwerfen den Verkehr vor dem Connection-Tracking, für den Router und das LAN. Hast du weitere raw-Regeln, schiebe diese nach oben.
• Der Import großer Listen dauert einige Sekunden. Die Zahl der Einträge zeigt /ip firewall address-list print count-only where list=IPv64-firehole_l1.
• Für eine andere Liste ersetzt du firehole_l1 überall durch deren ID.
• Für den Live-Stand der v64 Blocklist nimmst du die URL ("https://ipv64.net/blocklists/live/<token>/v64_mikrotik_" . $v . "_v64.rsc"), den Listennamen IPv64-v64 und interval=30m.

Ältere Importdateien schrieben alle Listen in die gemeinsame Adressliste IPv64-Blocklist. Hast du solche Einträge noch, räumst du sie so auf:

/ip firewall address-list remove [find list=IPv64-Blocklist]
/ipv6 firewall address-list remove [find list=IPv64-Blocklist]

Honeypot64 selbst kannst du als Container auf MikroTik betreiben – siehe Node64-Doku: MikroTik RouterOS.

Firmen-Firewalls: Palo Alto, FortiGate, Sophos

Diese Firewalls laden eine Textliste selbst von einer URL. Die Schritte folgen der Herstellerdoku (PAN-OS 11.1, FortiOS 7.6, Sophos Firewall 21.5) und sind von IPv64.net nicht live getestet. Die Beispiele nutzen die v64 Blocklist; jede andere Liste geht genauso. Für den Live-Stand trägst du die Adresse mit deinem Listen-Token ein. Stelle das Aktualisierungsintervall auf 30 Minuten oder mehr – FortiGate aktualisiert ab Werk alle 5 Minuten.

Palo Alto Networks (PAN-OS): External Dynamic List

1. Liste anlegen
   Objects › External Dynamic Lists › Add: Name z. B. IPv64_v64, Type IP List, Source https://ipv64.net/blocklists/ipv64_blocklist_v64.txt, optional ein Certificate Profile mit der CA des ipv64.net-Zertifikats (Server-Prüfung), Check for updates Hourly. OK.
2. Regel anlegen
   Policies › Security › Add: im Reiter Source die Liste als Source Address (eingehend aus der Internet-Zone), Action Deny. Die Regel über die Allow-Regeln schieben. Für ausgehenden Verkehr die Liste in einer zweiten Regel als Destination Address nutzen.
3. Übernehmen
   Commit. Import Now an der Liste lädt sie sofort.

PAN-OS nimmt IPv4- und IPv6-Adressen, Bereiche und Netze. Alle IP-Listen zusammen dürfen auf den meisten Modellen 50.000 Adressen enthalten (150.000 auf PA-3200, PA-5200 und PA-7000); siehe List Capacities unter Objects › External Dynamic Lists. Ist der Server nicht erreichbar, nutzt die Firewall die zuletzt geladene Liste.

Fortinet FortiGate (FortiOS): IP-Adress-Feed

1. Feed anlegen
   Security Fabric › External Connectors › Create New, unter External Feeds (ältere Versionen: Threat Feeds) IP Address wählen: Name z. B. IPv64_v64, URL of external resource https://ipv64.net/blocklists/ipv64_blocklist_v64.txt, Refresh Rate 60 Minuten. OK.
2. Regel anlegen
   Policy & Objects › Firewall Policy: Regel vom WAN-Interface mit Source = Feed (Abschnitt IP ADDRESS FEED), Action DENY, über den Allow-Regeln. Für ausgehenden Verkehr eine Regel mit dem Feed als Destination.

Dasselbe in der CLI, dazu eine Local-in-Policy, die auch die FortiGate selbst schützt (VPN, Admin-Zugang); nimm eine freie Policy-Nummer:

config system external-resource
    edit "IPv64_v64"
        set type address
        set resource "https://ipv64.net/blocklists/ipv64_blocklist_v64.txt"
        set refresh-rate 60
        set server-identity-check full
    next
end
config firewall local-in-policy
    edit 100
        set intf "any"
        set srcaddr "IPv64_v64"
        set dstaddr "all"
        set service "ALL"
        set schedule "always"
    next
end

FortiOS nimmt IPv4- und IPv6-Adressen, Bereiche und Netze, je Zeile eine. server-identity-check prüft das Server-Zertifikat (Standard none).

Sophos Firewall: Third-party threat feeds

1. Feed anlegen
   Active threat response › Third-party threat feeds › Add: Name z. B. IPv64_v64, Action Block, Indicator type IPv4 address, External URL https://ipv64.net/blocklists/ipv64_blocklist_v4_v64.txt, Authorization No authentication, Validate server certificate an, Polling interval 1 hour (oder 30 Minuten). Speichern.
2. Laden
   Synchronize now lädt den Feed sofort; Treffer im Log prüfen.

Benötigt die Lizenz für Third-party threat feeds (Xstream Protection). Laut Sophos nehmen diese Feeds nur einzelne IPv4-Adressen, keine IPv6-Adressen, Bereiche oder Netze. Die Listen von IPv64.net enthalten Netze und schreiben einzelne Adressen als /32; ob Sophos diese Einträge annimmt, ist nicht getestet. XGS 87, 88 und 107 bieten als Polling interval nur 24 Stunden, 7 Tage oder 30 Tage.

Webserver und Reverse-Proxy: nginx und CrowdSec

nginx

Für einen Webserver oder Reverse-Proxy ohne Zugriff auf die Firewall. Das Modul geo prüft Netze effizient, auch bei Zehntausenden Einträgen. Gesperrte Clients bekommen HTTP 403.

1. Liste als geo-Datei holen (per cron, z. B. alle 4 Stunden):

curl -fsS https://ipv64.net/blocklists/ipv64_blocklist_blocklistde_all.txt \
  | awk '/^[0-9A-Fa-f:.]+(\/[0-9]+)?$/ {print $1" 1;"}' > /etc/nginx/ipv64-geo.conf.new \
  && [ -s /etc/nginx/ipv64-geo.conf.new ] && mv /etc/nginx/ipv64-geo.conf.new /etc/nginx/ipv64-geo.conf \
  && nginx -t -q && systemctl reload nginx

2. In der nginx.conf verwenden:

http {
    geo $ipv64_blocked { default 0; include /etc/nginx/ipv64-geo.conf; }
    server {
        # ...
        if ($ipv64_blocked) { return 403; }
    }
}

Hinter Cloudflare oder einem anderen Proxy richtest du zuerst real_ip_header ein, sonst sieht nginx die Adresse des Proxys. Fertige nginx-Bausteine für Angriffspfade und User-Agents von Angriffswerkzeugen gibt es als Text-Listen aus dem Honeypot.

CrowdSec

Du importierst die Liste als Entscheidungen (decisions); alle Bouncer (Firewall, nginx, Traefik …) setzen sie um. Die Entscheidungen laufen nach 6 Stunden ab, deshalb importierst du alle 4 Stunden per cron neu. Getestet mit CrowdSec 1.6:

curl -fsSo /tmp/ipv64.txt https://ipv64.net/blocklists/ipv64_blocklist_firehole_l1.txt \
  && cscli decisions import -i /tmp/ipv64.txt --format values --duration 6h --reason ipv64-blocklist

Live-Stand der v64 Blocklist mit Listen-Token

Die normalen Adressen liefern die v64 Blocklist als Tagesstand (bis zu 24 Stunden alt), frei für alle. Den Live-Stand aktualisiert IPv64.net alle 30 Minuten. Er steht Beitragenden zur Verfügung (einer deiner Honeypot64-Sensoren hat in den letzten 7 Tagen gemeldet) und allen Kontoklassen außer der kostenlosen (Free, auf ipv64.net teils „Standard“ genannt).

1. Token erzeugen
   Angemeldet unter Honeypot64 › Listen-Token (ipv64.net/honeypot/token.php). Das Listen-Token hat 32 Zeichen (Buchstaben und Ziffern), ist getrennt vom API-Key und berechtigt nur zum Abruf der Listen. Die Seite zeigt auch, ob du den Live-Stand bekommst.
2. Adresse eintragen
   Dieselben Dateinamen wie sonst, mit dem Token im Pfad – nur für die v64 Blocklist: ipv64_blocklist_v64.txt, ipv64_blocklist_v4_v64.txt, ipv64_blocklist_v6_v64.txt, v64_mikrotik_v4_v64.rsc und v64_mikrotik_v6_v64.rsc (MikroTik-Adressliste IPv64-v64).

https://ipv64.net/blocklists/live/DEIN_LISTEN_TOKEN/ipv64_blocklist_v4_v64.txt

• Das Token steht im Pfad, weil viele Firewalls keine Kopfzeilen mitschicken können. Es braucht keine Anmeldung; jede Firewall, die eine URL annimmt, kann es nutzen.
• Halte das Token geheim wie ein Passwort: nicht in Screenshots, Tickets oder weitergegebene Konfigurationen. Ist es bekannt geworden, erzeugst du ein neues; das alte gilt sofort nicht mehr.
• Rufe alle 30 Minuten oder seltener ab; häufiger ändert sich der Live-Stand nicht. Je Token (gilt für das ganze Konto, alle Nodes zusammen) sind höchstens 60 Abrufe in 5 Minuten erlaubt, sonst 429 mit Retry-After.

Wo die Firewall die URL ohnehin nur einmal täglich lädt (z. B. pfSense), bringt der Live-Stand keinen Vorteil.

Listen-Token per API

Programme holen das Token mit dem API-Key über die API v2: GET https://ipv64.net/api/v2/honeypot/list-token. Fehlt das Token, legt IPv64.net es an; ein vorhandenes bleibt unverändert (die Abfrage erzeugt kein neues). Die Antwort enthält token, live (ob dein Konto den Live-Stand gerade bekommt) und base, die Basisadresse für die Dateinamen:

curl -s -H "Authorization: Bearer DEIN_API_KEY" https://ipv64.net/api/v2/honeypot/list-token

{"data": {"token": "DEIN_LISTEN_TOKEN", "live": true, "base": "https://ipv64.net/blocklists/live/DEIN_LISTEN_TOKEN/"}}

So macht es auch PROXY64 in Node64. Fehler: 401 ohne gültigen API-Key, 429 bei zu vielen Anfragen.

Node64: PROXY64, Honeypot64 und Firewall-Helfer

Node64 ist der Heimnetz-Container von IPv64.net. Er nutzt die Blocklisten direkt, ohne dass du Adressen von Hand einträgst:

• PROXY64 (Reverse-Proxy): Unter PROXY64 → Zugriffslisten schaltest du die IPv64-Blocklisten per Klick für den ganzen Reverse-Proxy ein. Die Auswahl kommt aus der index.json, neue Listen erscheinen ohne Update. PROXY64 aktualisiert die Listen alle 30 Minuten; Ausnahmen legst du selbst fest. Die v64 Blocklist lädt PROXY64 live, sobald dein Konto berechtigt ist: Ohne Token von Hand holt es das Listen-Token selbst über den zentralen API-Key (Listen-Token per API); ein von Hand hinterlegtes Token geht vor. Details: Node64-Doku: ipv64-Blocklisten und Live-Listen mit Listen-Token.
• Honeypot64: Mit einem eigenen Sensor trägst du zur v64 Blocklist bei – und bekommst als Beitragender den Live-Stand. Der Sensor meldet mit dem API-Key deines Kontos alle 10 Minuten an IPv64.net. Ohne Konto geht es auch anonym (ohne API-Key) – dann zählt dein Sensor mit allen anderen anonymen zusammen wie ein Konto, und den Live-Stand gibt es nur mit Konto. Ein Sensor wechselt das Konto (anderer API-Key oder anonym ↔ mit Key) nur aus dem Netz seiner letzten Meldung oder nach 24 Stunden ohne Meldung – wer nur die Sensor-Kennung kennt, kann ihn nicht übernehmen. Einrichtung: Node64-Doku: Honeypot64, Meldung: Meldung an ipv64.
• Firewall-Helfer (nftables): Im Modus ohne Oberfläche trägt Node64 die v64 Blocklist oder andere Listen aus der index.json selbst in die nftables-Firewall des Hosts ein, mit Ausnahmen für eigene Adressen. Siehe Node64-Doku: Firewall-Helfer.

Ältere „v64 Blocker Nodes“

Auf IPv64.net gibt es noch die Seite v64 Blocker Nodes mit dem Status „still under development“. Das dort beschriebene Melden einzelner IPs über die API ist im aktuellen Code abgeschaltet. Beiträge zur v64 Blocklist laufen heute über Honeypot64-Sensoren; die Übersicht IPv64 Secure nennt die Blocker Nodes nicht mehr.

Testen und Fehlersuche

Ist die Liste geladen?

Wie viele Einträge eine Liste gerade hat und wann sie zuletzt erneuert wurde, steht in der index.json (count, updated) und auf ipv64.net/v64_blocklists.

Ist meine eigene IP gesperrt?

• v64 Blocklist: Die IP-Auskunft zeigt, ob und warum eine Adresse gelistet ist, und bietet die eigene Adresse direkt zur Prüfung an. Per API: curl https://ipv64.net/api/v2/threat/ip/192.0.2.10 (ohne API-Key mit strengem Limit je Client-IP). Ist die Adresse zu Unrecht gelistet, stellst du dort einen Freigabe-Antrag.
• Andere Listen: Die IP-Auskunft prüft nur die v64 Blocklist. Ob eine Adresse in einem geladenen Set steckt, prüfst du lokal, z. B. mit ipset test ipv64-v4 192.0.2.10 oder nft get element inet ipv64 bl4 '{ 192.0.2.10 }'. Fälschlich gelistete Adressen meldest du beim jeweiligen Quellprojekt; mit der nächsten Aktualisierung verschwinden sie auch aus den IPv64-Listen.
• Frühwarnung: Unter ipv64.net/honeypot/watch.php trägst du deine öffentlichen Netze ein und bekommst eine Mail, wenn eine Adresse daraus bei den Honeypot64-Sensoren auffällt – mit Dienst, Port und Art der Angriffe. Deine DynDNS-Adressen überwacht IPv64.net dort automatisch; für sie gibt es nur Treffer, wenn die Adresse auf der v64 Blocklist steht (ohne Port und Regel, letzte Sichtung nur auf den Tag).

Ich habe mich ausgesperrt

• Über die Konsole oder einen anderen Zugang die Sperre entfernen: nft delete table inet ipv64 bzw. die Regel aus dem ipset-Skript wieder löschen (iptables -D INPUT -m set --match-set ipv64-v4 src -j DROP, für IPv6 entsprechend mit ip6tables und ipv64-v6). Danach die Cron-Datei /etc/cron.d/ipv64-blocklist löschen, sonst kommt die Sperre beim nächsten Lauf zurück.
• Auf pfSense, OPNsense und den Firmen-Firewalls legst du für deine festen Adressen (Büro, VPN, Monitoring) eine Erlauben-Regel über der Block-Regel an.
• In Node64 trägst du eigene Adressen als Ausnahme ein (PROXY64) bzw. in NODE64_FIREWALL_ALLOW (Firewall-Helfer).

Typische Fehler

• „download empty, keeping the active sets“: Das nftables-Skript hat für IPv4 und IPv6 keine Einträge bekommen (beim ipset-Skript: für IPv4) und lässt die bisherige Liste aktiv. Ursache ist ein Netzwerkfehler, eine falsche ID – oder eine Liste, die gerade wirklich leer ist, was bei der v64 Blocklist vorkommen kann. Prüfe die Adresse mit curl -fsS https://ipv64.net/blocklists/ipv64_blocklist_v4_<id>.txt | head.
• Alias bleibt leer (pfSense): Liste größer als Firewall Maximum Table Entries – Wert erhöhen.
• Sperre wirkt nicht bei Docker: Docker veröffentlicht Ports über DOCKER-USER/FORWARD, nicht über INPUT. Beide Skripte filtern auch dort; nach einem Neustart von Docker das ipset-Skript erneut ausführen.
• nginx sperrt nicht oder sperrt alle: Hinter einem Proxy sieht nginx ohne real_ip_header nur die Adresse des Proxys.
• Live-Abruf liefert X-IPv64-List: daily: Dein Konto hat gerade keine Berechtigung für den Live-Stand (kein Sensor mit Meldung in den letzten 7 Tagen und Kontoklasse ohne Live). Du bekommst trotzdem den Tagesstand.
• 404 beim Live-Abruf: Token falsch, neu erzeugt oder gelöscht – Adresse mit dem aktuellen Token eintragen.
• 404 für v64_ssh, v64_web & Co.: Die Teillisten der v64 Blocklist gibt es nicht mehr, weder als Tagesstand noch live. Stelle auf v64 um (siehe Eine Liste: v64).
• 429: zu häufige Abrufe; Intervall auf 30 Minuten oder mehr stellen. Die Grenze gilt für alle Geräte deines Kontos zusammen. PROXY64 (ab 1.33.1) behält bei 429 den vorhandenen Stand ohne Fehlermeldung.
• Freigegebene Adresse noch gesperrt: Aus dem Live-Stand verschwindet sie mit der nächsten Bewertung (alle 30 Minuten), aus dem Tagesstand erst mit der nächsten Tagesaktualisierung – und aus deiner Firewall erst mit deren nächstem Abruf.

Weitere Hilfe gibt es im v64.tech-Forum und in den FAQ.

Fehler gefunden oder etwas fehlt? Schreibt uns im v64.tech-Forum. · Stand: 2026-11-02