Honeypot64 Vorschau

Honeypot64 stellt Fallen-Dienste auf, die Angreifer aus dem Internet anlocken: SSH, Telnet, Web-Logins, Mail, FTP, Datenbanken, RDP, VNC, MQTT, SNMP, SIP und beliebige TCP-Ports. Jede Berührung wird erfasst und ausgewertet – wer anklopft, welche Zugangsdaten probiert werden und welche Web-Angriffe unterwegs sind. Auf Wunsch liest es dazu die Logs deiner echten Dienste und Syslog von Router und Firewall. Es läuft als Modul in Node64 oder als reiner Sensor ohne Oberfläche, auch auf einem kleinen Raspberry Pi.

So funktioniert es

Auf den Fallen-Ports läuft kein echter Dienst. Wer sie anspricht, tut das ungefragt – jede Verbindung ist deshalb verdächtig. Honeypot64 ist ein Low-Interaction-Honeypot:

• Logins werden angenommen und immer abgelehnt. Benutzername und Passwort werden erfasst.
• Es gibt keine Shell, es wird nichts ausgeführt und nichts heruntergeladen.
• Die Fallen bauen keine ausgehenden Verbindungen auf. Nach außen geht nur die optionale Meldung an ipv64.
• Limits je Quell-IP und insgesamt schützen die Node vor Überlast.
• Ist das Modul aus, ist kein Port offen und es läuft nichts.

Schnellstart

Zwei Wege, beide mit dem Profil Standard (18 Fallen). Lies vorher kurz Sicherheit und Portfreigabe – am besten läuft der Honeypot auf einem eigenen Gerät in einem abgetrennten Netz.

Variante A: reiner Sensor ohne Oberfläche

Für ein eigenes Gerät, etwa einen Raspberry Pi. Ein Befehl, fertig:

docker run -d --name honeypot64 --network host --restart unless-stopped \
  -e NODE64_MODE=honeypot -e NODE64_HONEYPOT_PROFILE=standard \
  -v honeypot64:/data ghcr.io/ipv64net/node64:latest

Damit sind alle Fallen des Profils offen. Den Zustand zeigt die Info-Seite http://<IP des Geräts>:9064/ – nur aus dem Heimnetz. Als Compose-Datei:

services:
  honeypot64:
    image: ghcr.io/ipv64net/node64:latest
    network_mode: host
    restart: unless-stopped
    environment:
      NODE64_MODE: honeypot
      NODE64_HONEYPOT_PROFILE: standard   # oder: minimal, full
      # NODE64_IPV64_KEY: DEIN_API_KEY    # optional: Meldung an ipv64 einschalten
    volumes:
      - honeypot64:/data
volumes:
  honeypot64:

Alle Fallen statt Standard: NODE64_HONEYPOT_PROFILE=full. Weitere Variablen unter Modus ohne Oberfläche.

Variante B: als Modul in Node64 mit Oberfläche

Die Oberfläche legst du auf einen ungewöhnlichen Port, damit 8080 für die Falle frei bleibt:

docker run -d --name node64 --network host --restart unless-stopped \
  -e NODE64_HTTP_PORT=18080 \
  -v node64-data:/data ghcr.io/ipv64net/node64:latest

1. http://<IP>:18080 öffnen und das Admin-Konto anlegen.
2. Einstellungen → Module → Modul Honeypot64 einschalten.
3. Honeypot64 → Einstellungen → Vorlage Standard (oder Voll) → Speichern. Erst jetzt öffnen sich die Fallen.
4. In der Übersicht prüfen, dass alle Dienste „offen“ sind.

Laufen auf derselben Node PROXY64 oder DNS64, lässt das Profil deren Ports weg (80/443 bzw. 53/853). Für alle Fallen-Ports nimmst du eine eigene Honeypot-Node.

Ports für die Portfreigabe

Diese Ports leitest du am Router an das Gerät mit dem Honeypot weiter:

Sicherheit und Portfreigabe

Ein Sensor, der nur im Heimnetz erreichbar ist, sieht fast nichts. Typische Freigaben sind 22, 23, 80, 443, 2222 und 3389 – jeweils an das Gerät mit dem Honeypot.

Einschalten

1. In Node64 unter Einstellungen → Module das Modul Honeypot64 einschalten (standardmäßig aus). Danach erscheint der Menüpunkt Honeypot64.
2. Im Reiter Einstellungen schaltest du im Dienste-Katalog die gewünschten Fallen ein – einzeln oder per Vorlage Minimal, Standard oder Voll – und speicherst. Mit der Voreinstellung Nur über PROXY64 öffnet der Honeypot gar keine eigenen Ports. Erst dann öffnet Honeypot64 Ports – vorher bleibt alles zu, auch beim ersten Einschalten.
3. Im Reiter Übersicht siehst du, welche Fallen offen sind und ob ein Port nicht geöffnet werden konnte.
4. Gib die gewünschten Ports am Router frei (siehe Sicherheit) und prüfe, dass die Ports die Node erreichen (siehe Ports).

Profile

In der Oberfläche sind die Profile die Vorlagen im Dienste-Katalog. Entspricht deine Auswahl genau einem Profil, wird sie als dieses Profil gespeichert – neue Dienste späterer Versionen kommen dann von selbst dazu; sonst als eigene Liste. Ports, die ein anderer Teil von Node64 schon offen hat, lässt ein Profil weg – siehe Ports.

Nur über PROXY64 ist die Voreinstellung, solange du noch nichts gespeichert hast; eine gespeicherte Vorlage oder eigene Auswahl bleibt. Schaltest du dazu Dienste im Katalog ein, wird daraus eine eigene Auswahl.

Dienste

In der Oberfläche wählst du die Dienste unter Honeypot64 → Einstellungen in einem Katalog aller Fallen, nach Gruppen geordnet (Fernzugriff, Web, Mail, Datenbanken, Router/IoT, Sonstiges):

• je Dienst ein Schalter, der Port (änderbar), bei http/https der Köder und der Zustand des Ports – frei, offen, Fehler oder „belegt von …“ (TCP und UDP getrennt: udp 161 und tcp 161 vertragen sich),
• die Knöpfe Minimal, Standard und Voll füllen den Katalog wie das Profil, Alle freien einschalten nimmt jeden freien Port dazu, Alle aus leert ihn, Nur über PROXY64 wählt die Vorlage ohne eigene Ports – gespeichert wird erst mit „Speichern“,
• unter Weitere Einträge läuft ein Dienst mehrfach, z. B. ssh auf 22 und 2200.

Unter Erweitert gibt es weiter die Textliste – je Zeile Dienst und Port, bei http/https optional ein Köder:

ssh 2222
telnet 2323
http 8081 wp-login
https 8443
smtp 587
imap 143
postgres 5432
rdp 3389
snmp 161

Fingerabdrücke: Bei HTTPS (und TLS an TCP-Ports) entsteht ein JA4-, bei SSH ein HASSH-Fingerabdruck des Angriffswerkzeugs. Er steht an jedem Ereignis, in einer eigenen Rangliste und geht mit der Meldung an ipv64. UDP: SNMP und SIP laufen über UDP – ohne Host-Netz veröffentlichst du die Ports mit /udp (-p 161:161/udp -p 5060:5060/udp).

Geräte-Logins: Die Web-Köder beantworten auch die Login-Aufrufe verbreiteter Geräte und Oberflächen – Router wie FRITZ!Box, Speedport und OpenWrt, Firewalls und SSL-VPN, NAS, UniFi, Home Assistant, Proxmox, Grafana, Jenkins, Webmin und Portainer. Sie antworten mit einer schlichten Ablehnung im passenden Format und erfassen die Zugangsdaten; das Gerät steht im Detail (device=…). Nachbauten der Herstellerseiten oder Logos gibt es bewusst nicht – Bots greifen die Adressen an, nicht die Optik.

Unbekannte Dienste, ungültige oder doppelte Ports und ein Köder bei einem anderen Dienst als http/https sind ein Fehler am Feld.

Dienst-Profile

Jede Falle gibt sich als ein bestimmter Dienst aus, damit Scanner sie richtig einordnen. Geändert wird nur, was die Falle sendet – erfasst wird bei jedem Profil dasselbe.

• Standard je Port: 8006 Proxmox VE, 10000 Webmin, 8123 Home Assistant, 3000 Grafana, 5000/5001 NAS, 9200 Elasticsearch, alle anderen Web-Ports nginx. Webserver-Profile (nginx, Apache) zeigen die Köder je Pfad; Anwendungen antworten wie das Original, etwa Proxmox auf /api2/json/… mit 401.
• Auswahl: In der Tabelle der Fallen-Dienste wählt die Spalte Profil das Profil je Zeile; vorausgewählt ist der Standard für Port und Köder. Das Feld Hostname der Fallen setzt den Hostnamen – leer wird er aus der Sensor-Kennung erzeugt.
• Jeder Sensor sieht anders aus: Hostname, Domain, Distribution, Versionsstände und Zertifikatsdaten leitet jeder Sensor aus seiner Sensor-Kennung ab – über Neustarts gleich, von Sensor zu Sensor verschieden. So lassen sich die Fallen nicht an einem festen Fingerabdruck erkennen.
• Im Modus ohne Oberfläche gelten die Standards je Port; abweichende Profile und den Hostnamen setzt du mit NODE64_HONEYPOT_PERSONAS und NODE64_HONEYPOT_HOSTNAME.

Ports

Honeypot64 prüft jeden Port über die Port-Verwaltung der Node. Ports, die schon ein anderer Teil offen hat – die Oberfläche von Node64, PROXY64 mit dem gemeinsamen Eingang 80/443 oder Streams, DNS64 (z. B. 53, 853) –, behandelt es so:

• Katalog: Der Port steht als „belegt von …“ da; ein Profil lässt ihn weg.
• Textliste und Modus ohne Oberfläche: Ein belegter Port ist ein Fehler.
• Für alle Fallen-Ports betreibst du Node64 nur mit Honeypot64 und der Oberfläche auf einem ungewöhnlichen Port – oder im Modus ohne Oberfläche.

Läuft auf dem Rechner ein fremder Dienst (z. B. der eigene SSH-Server auf 22), kann die Falle den Port nicht öffnen. Die Übersicht zeigt das als Fehler, die anderen Dienste laufen weiter. Lege den echten Dienst auf einen anderen Port oder lass den Port weg.

Docker

Die Fallen-Ports müssen den Container erreichen. Empfohlen ist das Host-Netz (network_mode: host): Nur so sieht Honeypot64 die echten Quell-Adressen. Mit Port-Weiterleitung (-p) im Bridge-Netz sehen manche Docker-Versionen statt der Angreifer die Adresse des Docker-Gateways.

Ports unter 1024 (22, 23, 80, 443 …) öffnet Node64 ohne Root über die Fähigkeit cap_net_bind_service, die das Image mitbringt. Nimmt der Container sie weg (--cap-drop, manche Podman-Einstellungen), bleiben diese Ports zu, die übrigen laufen weiter.

Port-Scan-Erkennung

Spricht eine Quelle innerhalb von 60 Sekunden mindestens 4 verschiedene Fallen-Ports an, erfasst Honeypot64 einen Port-Scan – einmal je Quelle und Zeitfenster, mit den berührten Ports. Die Erkennung ist standardmäßig an und lässt sich in den Einstellungen abschalten.

Limits

Damit ein Angreifer die Node nicht überlastet, gelten Grenzen für gleichzeitige Verbindungen:

Was darüber hinausgeht, wird verworfen und gezählt (Übersicht und node64_honeypot_dropped_total).

Speicher

Ereignisse liegen in der Datenbank der Node. Ältere Ereignisse und alles über der Obergrenze löscht Node64 stündlich, die ältesten zuerst.

Mit Ereignisse löschen leerst du die gespeicherten Daten, die Einstellungen bleiben. Die Einstellungen sind Teil von Export und Import.

Meldung an ipv64

Ab Version 0.2.0 kann Honeypot64 seine Beobachtungen an ipv64.net melden. Dort fließen die Meldungen vieler unabhängiger Sensoren zusammen; daraus soll die v64 Blocklist entstehen.

• Einschalten: unter Honeypot64 → Einstellungen der Schalter An ipv64 melden. Standardmäßig aus. Er braucht den ipv64-API-Key der Node.
• Takt: alle 10 Minuten (mit kleinem Zufallsversatz), komprimiert. Gemeldet wird der Zeitraum seit der letzten erfolgreichen Meldung. War ipv64 nicht erreichbar, holt die Node bis zu 7 Tage nach. Wer die Meldung einschaltet, beginnt bei null – nichts aus der Zeit davor wird nachgeschickt.
• Lebenszeichen: Gibt es keine Ereignisse, geht trotzdem eine kurze Meldung ohne Quellen, damit ipv64 aktive Sensoren zählen kann.

Die Zugangsdaten stammen ausschließlich von Angreifern, die sich an den Fallen versucht haben – nie aus deinen echten Diensten. Den Zustand siehst du in der Übersicht und in den Einstellungen: letzte Meldung, letzter Fehler, nächster Versuch, gemeldete Quell-IPs heute und seit dem Start sowie Quellen, die ipv64 zuletzt nicht übernommen hat, mit Grund. Per API steht er unter GET /api/honeypot/status im Feld report.

Log-Sensor und Syslog

Neben den Fallen kann Honeypot64 Logs echter Dienste lesen und Syslog von Routern und Firewalls annehmen. So kommen die Angriffe dazu, die wirklich bei deinen Diensten ankommen. Mitgelieferte, versionierte Regeln (z. B. sshd/bruteforce@1) schlagen erst ab einer Schwelle an – etwa bei mehreren fehlgeschlagenen Logins in wenigen Minuten –, denn echte Logs enthalten auch Vertipper legitimer Nutzer. Eine erfolgreiche Anmeldung derselben IP setzt den Zähler zurück. Der Log-Sensor liest nur, schreibt nichts und baut keine Verbindungen auf. Läuft PROXY64 auf derselben Node, kann es seine Zugriffe direkt an den Log-Sensor geben, unbekannte Anfragen an den Web-Köder leiten und gemeldete Angreifer sofort sperren.

Eingestellt wird alles unter Honeypot64 → Einstellungen → Log-Sensor und Syslog: Dateien mit Format, Vorschläge für gängige Pfade per Knopf, Syslog-Port und erlaubte Absender. Daneben steht der Zustand je Datei und des Syslog-Empfängers, z. B. „keine Leserechte – Container braucht --group-add 4“. Kein Profil schaltet den Log-Sensor ein; wie bei den Fallen öffnet das Modul nichts, bevor die Einstellungen einmal gespeichert sind.

Was gespeichert und gemeldet wird

Aus echten Logs speichert Honeypot64 nur IP, Art, Dienst, Port, Anzahl, Zeitraum und Regel – und meldet nur das an ipv64, wenn die Meldung an ist. Nie Benutzernamen, Passwörter, Pfade, User-Agents oder andere Inhalte: Das wären deine Nutzer, Mitarbeitenden oder Kunden. Proben wie Zugangsdaten stammen ausschließlich aus dem Honeypot. Jede Quelle trägt ihren Sensor (honeypot, log oder syslog); ipv64 gewichtet Honeypot höher als Log und Syslog. Private und reservierte Absender bleiben lokal.

Logs einbinden

Gelesen wird über den Pfad im Container. Erlaubt sind nur Pfade unterhalb von /host/log (empfohlener Mount der Host-Logs), /var/log (Binary ohne Docker) und /data/logs (Logs anderer Container in einem gemeinsamen Volume). Muster wie /host/log/nginx/*access.log sind erlaubt, höchstens 32 Dateien. Rotation und Kürzen erkennt der Sensor.

• Mount: -v /var/log:/host/log:ro – nur lesend.
• Rechte: auth.log, secure und mail.log gehören meist der Gruppe adm (Debian/Ubuntu: GID 4). Das Image läuft nicht als root, also gibst du --group-add 4 mit.
• journald: Das Binärformat liest der Sensor (noch) nicht. Installiere rsyslog auf dem Host oder leite journald per Syslog an den Empfänger weiter.
• Logs außerhalb von /var/log (Nextcloud, Gitea, Home Assistant) bindest du einzeln ein, z. B. -v /srv/nextcloud/data/nextcloud.log:/data/logs/nextcloud.log:ro.

Beim normalen Node64-Container gilt dasselbe: Mount und --group-add 4 beim Container, die Dateien trägst du dann in der Oberfläche ein. Für den Modus ohne Oberfläche:

docker run -d --name honeypot64 --network host --restart unless-stopped --group-add 4 \
  -e NODE64_MODE=honeypot -e NODE64_HONEYPOT_PROFILE=standard -e NODE64_IPV64_KEY=DEIN_API_KEY \
  -e NODE64_HONEYPOT_LOGS=/host/log/auth.log=syslog,/host/log/nginx/*access.log=nginx \
  -e NODE64_HONEYPOT_SYSLOG_PORT=514 -e NODE64_HONEYPOT_SYSLOG_ALLOW=10.0.0.1,10.0.0.0/8 \
  -e TZ=Europe/Berlin \
  -v /var/log:/host/log:ro -v honeypot64:/data ghcr.io/ipv64net/node64

services:
  honeypot64:
    image: ghcr.io/ipv64net/node64
    network_mode: host
    restart: unless-stopped
    group_add: ["4"]          # Gruppe adm: auth.log lesen
    environment:
      NODE64_MODE: honeypot
      NODE64_HONEYPOT_PROFILE: standard
      NODE64_IPV64_KEY: DEIN_API_KEY
      NODE64_HONEYPOT_LOGS: /host/log/auth.log=syslog,/host/log/mail.log=syslog
      NODE64_HONEYPOT_SYSLOG_PORT: "514"
      TZ: Europe/Berlin
    volumes:
      - /var/log:/host/log:ro
      - honeypot64:/data
volumes:
  honeypot64:

Syslog

Der Empfänger hört auf UDP und TCP auf demselben Port, üblich ist 514 (RFC 3164 und RFC 5424). Wie bei den Fallen prüft die Port-Verwaltung, dass kein anderer Teil der Node den Port nutzt.

Zeitzone: Klassisches Syslog schickt die Uhrzeit ohne Zone. Setze -e TZ=Europe/Berlin, damit die Zeiten in der Ereignisliste stimmen.

Beispiele für einen Sensor unter 10.0.0.20 – Menünamen können je nach Version abweichen, und nicht jedes Gerät ist live getestet:

• MikroTik RouterOS:
  routeros

  /system/logging/action/add name=hp64 target=remote remote=10.0.0.20 remote-port=514 bsd-syslog=yes
  /system/logging/add topics=system action=hp64
  /system/logging/add topics=account action=hp64

• OPNsense: System → Einstellungen → Protokollierung → Ziele: neues Ziel, Transport UDP(4) oder TCP(4), Host 10.0.0.20, Port 514; Anwendungen z. B. Anmeldungen/Audit, Firewall, OpenVPN/IPsec.
• pfSense: Status → System Logs → Settings → Remote Logging: „Send log messages to remote syslog server“, Server 10.0.0.20:514, Inhalte System, Firewall und VPN.
• FortiGate:
  text

  config log syslogd setting
      set status enable
      set server "10.0.0.20"
      set port 514
  end

• Sophos Firewall: System services → Log settings: Syslog-Server hinzufügen (IP, Port 514, Format „Standard syslog protocol“), dann Authentifizierung, Firewall und VPN an diesen Server senden.
• UniFi (Network-App): Einstellungen → Control Plane → Integrations → Activity Logging (Syslog) bzw. „SIEM Server“: IP 10.0.0.20, Port 514.

Zusammenarbeit mit PROXY64

Läuft auf derselben Node PROXY64, kann Honeypot64 auch dort mitlesen und mitsperren. Eingeschaltet wird das in PROXY64 (Zugriffslisten → Honeypot64, je Punkt ein Schalter, Standard aus); gespeicherte Fallen-Dienste sind dafür nicht nötig, nur das laufende Modul. Mit der Vorlage Nur über PROXY64 ist der Köder automatisch eingeschaltet; PROXY64 zeigt dazu einen Hinweis.

• Köder für unbekannte Anfragen: Anfragen auf 80/443 ohne eingerichteten Host – nur IP oder fremde Domain – beantwortet der Web-Köder des Honeypots statt der Standardseite. Logins, Pfade, User-Agents und Fingerabdrücke werden erfasst (Detail via=proxy64).
• Als schädlich erkannte Anfragen an den Köder: Statt einer 403 beantwortet der Köder auch Anfragen, die PROXY64 sonst abweist – je Art ein Schalter: IPs der ipv64-Blocklisten, vom Honeypot gemeldete Angreifer, Exploit-Muster, KI-Bots und Scanner (alle Standard an) und Ländersperre (Standard aus). Überlast geht nie an den Köder. Nur für HTTP(S) und nur bei aktivem Köder – siehe PROXY64.
• Zugriffe auswerten: PROXY64 gibt je Anfrage nur Eckdaten an den Log-Sensor (IP, Host, Pfad ohne Abfrage, Status, abgelehnte Anmeldung). Die Regeln proxy64/exploit, proxy64/scan, proxy64/bad-useragent, proxy64/auth und proxy64/unknown-host ordnen sie ein; gemeldet wird wie bei echten Logs nur IP, Art und Anzahl.
• Sofort-Sperre: Fällt eine IP auf – Login- oder Exploit-Versuch, Port-Scan, eine Regel aus PROXY64 –, sperrt PROXY64 sie für die eingestellte Dauer (Standard 24 Stunden), ohne auf die v64 Blocklist zu warten. Private Adressen, vertrauenswürdige Proxys und Ausnahmen werden nie gesperrt.

Die Übersicht zeigt dazu eine eigene Zeile; Prometheus zählt node64_honeypot_proxy_*.

Zertifikat für Köder-Namen

Im Modul zeigen die HTTPS-Fallen mit Webserver-Profil (nginx, Apache) und die Mail-Fallen mit TLS – SMTPS 465, IMAPS 993, POP3S 995 – auf Wunsch ein gültiges Zertifikat aus der Zertifikatsverwaltung statt des selbst signierten. Ein Scanner sieht dann etwa auf 443 und 993 einen „echten“ Server mail.<domain>.

• Einstellen unter Honeypot64 → Einstellungen → Zertifikat für Köder-Namen: ein vorhandenes Zertifikat wählen oder neu anlegen – einzelne, glaubwürdige Namen (Standard mail, vpn, cloud, portal, höchstens 20, kein Wildcard) unter einer Domain deines ipv64-Accounts. Ausgestellt wird über Let's Encrypt per DNS-01 mit dem ipv64-API-Key; das Zertifikat erscheint in der Verwaltung mit „benutzt von Honeypot64“ und wird automatisch erneuert. Bis es da ist, bleiben die Fallen selbst signiert.
• DNS-Records optional: Mit einer öffentlichen IPv4/IPv6 der Node legt das Modul A/AAAA-Records an, mit einem Namen wie der DynDNS-Domain einen CNAME. Namen, die schon A, AAAA oder CNAME haben, bleiben unberührt.
• Profile, die auch im Original selbst signiert sind – Proxmox, Webmin, NAS, Grafana, Home Assistant, Elasticsearch und weitere –, bleiben selbst signiert. Unter Auch auf diesen Ports zeigen lassen sich einzelne Ports trotzdem zuweisen. Port 80 bleibt eine Falle, STARTTLS auf 25/587/110/143 gibt es weiterhin nicht.
• Angefragter Name (SNI): steht an jedem Ereignis. So siehst du, welche Bots die Namen aus den Certificate-Transparency-Logs kennen.
• Im Modus ohne Oberfläche gibt es keine Zertifikatsverwaltung; dort bleiben alle Fallen selbst signiert.

Anmeldung von Node64 überwachen

Solange Honeypot64 läuft, zählt es die Fehlversuche an der Anmeldung von Node64 selbst – Passwort, TOTP, Passkey, SSO ohne verknüpftes Konto sowie ungültige API- und MCP-Keys – je Quell-IP.

• Ab 5 Fehlversuchen in 10 Minuten (einstellbar: 2–100 Versuche, 1–1440 Minuten) entsteht genau ein Ereignis je IP und Zeitfenster: Regel node64/login@1, Art http:bruteforce – ohne Benutzernamen oder Passwörter.
• Dazu eine Benachrichtigung „Angriff auf die Anmeldung“ (höchstens eine alle 10 Minuten, abschaltbar), die Sofort-Sperre über PROXY64, wenn sie dort eingeschaltet ist, und die Meldung an ipv64, wenn sie an ist.
• Private, Loopback- und andere nicht öffentliche Adressen werden nur gezählt, nie gemeldet oder gesperrt. Das betrifft auch einen Reverse-Proxy vor der Oberfläche ohne NODE64_TRUST_PROXY.
• Die Übersicht zeigt die Zeile Angriffe auf die Node64-Anmeldung (24 Stunden, 7 Tage, seit dem Start).

Frühwarnung

Fällt eine Adresse aus deinem eigenen Netz als Angreifer auf – etwa ein gekapertes Gerät im Heimnetz oder ein Server –, sagt dir die Frühwarnung Bescheid. Im Reiter Frühwarnung hinterlegst du deine Netze bei ipv64 (IPv4 ab /16, IPv6 ab /32); die aktuellen DynDNS-IPs deines Accounts überwacht ipv64 automatisch.

• ipv64 prüft nach jeder Bewertung, ob eine dieser Adressen aufgefallen ist. Die Node holt Treffer alle 30 Minuten ab und meldet sie gebündelt über die Benachrichtigungen („Honeypot64 Frühwarnung“); dazu kommt eine Mail von ipv64.
• Netze ohne Nachweis melden nur IPs, die auf der v64 Blocklist stehen – die sind ohnehin öffentlich. DynDNS-IPs deines Accounts gelten als nachgewiesen und melden schon jede Sichtung.
• Braucht den zentralen API-Key der Node – nicht die Meldung an ipv64 und keinen eigenen Sensor. Der automatische Abruf läuft, solange das Modul an ist; sonst gibt es „Jetzt abrufen“.
• Grenzen je Account-Klasse: Standard 3 Netze, alle anderen Klassen 50.

Benachrichtigung

Auf Wunsch meldet Honeypot64 neue Angreifer – Quell-IPs, die bisher nicht aufgefallen sind. Damit dich das nicht überflutet, kommt höchstens eine gebündelte Meldung je Stunde mit der Anzahl und den ersten IPs. Sie geht über die Standardkanäle der Benachrichtigungen. Standardmäßig ist das aus.

Getrennt davon meldet die Überwachung der Node64-Anmeldung Angriffe auf die Anmeldung (Art honeypot_login, höchstens eine Meldung alle 10 Minuten).

Statistik

Die Übersicht unter Honeypot64 zeigt, wahlweise für 24 Stunden oder 7 Tage:

• die Fallen-Dienste mit Port, Zustand (offen oder Fehler mit Grund) und Verbindungen seit dem Start,
• Kennzahlen: Ereignisse, verschiedene Quell-IPs und Login-Versuche,
• den Verlauf der Ereignisse als Diagramm,
• Ranglisten: Quell-IPs, Arten, Ports, Dienste, Benutzernamen, Passwörter, Zugangsdaten (Paare), Pfade und User-Agents.

Eine Karte fürs Dashboard zeigt offene Fallen, Ereignisse, Quell-IPs, Login-Versuche und Dienste mit Fehler.

Karte auf der Startseite

Die Karte von Honeypot64 auf dem Dashboard zeigt für die letzten 24 Stunden die Ereignisse mit Trend gegenüber dem Vortag (▲ mehr in Rot, ▼ weniger in Grün), Quell-IPs, Login-Versuche, die drei häufigsten Herkunftsländer als Flaggen, den meistangegriffenen Dienst, offene und fehlerhafte Fallen, den Zustand der Meldung an ipv64 und – sobald PROXY64 etwas übergeben hat – die Anfragen über PROXY64.

Herkunft der Angreifer

Zu jeder Quell-IP zeigt Honeypot64 das Land: Flagge, Ländercode und den Namen als Tooltip – in der Ereignisliste, bei den Top-Quellen, in der Benachrichtigung über neue Angreifer und auf der Info-Seite des Modus ohne Oberfläche. Die Rangliste Herkunft nach Land zählt Ereignisse und verschiedene Quell-IPs je Land.

• Daten von ipv64.net, keine fremde GeoIP-Datenbank: Die Länderdatei entsteht täglich aus den Daten der Registrierungsstellen und kommt von ipv64.net. Geladen wird nur, solange Honeypot64 läuft – beim Start sofort aus dem Zwischenspeicher unter /data, danach täglich und nur bei Änderung.
• Nichts gespeichert: Das Land wird beim Auswerten nachgeschlagen, nicht an den Ereignissen gespeichert. Neue Daten gelten sofort auch für ältere Ereignisse. Private und reservierte Adressen haben kein Land.
• Ohne Daten geht alles weiter: Fehlt die Datei oder ist ipv64 nicht erreichbar, läuft Honeypot64 ohne Länder.
• Die Flaggen erscheinen auch unter Windows: Die Oberfläche bringt eine kleine Flaggen-Schrift mit (Twemoji, CC BY 4.0), die nur für Länderflaggen greift. Der Ländercode steht immer daneben.

Dazu zeigt die Übersicht farbig, was angegriffen wurde – je Dienst, Port und Art, aufgeteilt nach Login/Bruteforce, Exploit, Scan, Sondierung und Log/Syslog – und welche Köder und erkannten Geräte getroffen wurden.

Weltkarte

Über der Rangliste zeigt die Übersicht eine Weltkarte für den gewählten Zeitraum (24 Stunden oder 7 Tage). Länder mit Angriffen sind in fünf Stufen eingefärbt, das stärkste Land immer in der obersten; Länder ohne Angriffe bleiben grau. Der Tooltip nennt Flagge, Name, Ereignisse und Quell-IPs.

• Klick auf ein Land (oder seinen Namen in der Rangliste) filtert die Ereignisliste nach diesem Land, z. B. /honeypot?country=DE – auch ohne JavaScript. Das Kreuz am Länder-Abzeichen hebt den Filter wieder auf.
• Offline: Die Kartendaten (Natural Earth 1:110m, gemeinfrei) stecken in Node64; nachgeladen wird nichts. Sehr kleine Inselstaaten fehlen in diesem Maßstab, stehen aber in der Rangliste.
• Der Modus ohne Oberfläche zeigt dieselbe Karte für 7 Tage auf seiner Info-Seite.

Ereignisse

Unter Letzte Ereignisse steht jede Berührung mit Zeit, Quelle, Dienst, Art und Details, bei Web-Ködern mit der Seite. Die Payload siehst du als Text und als Hex. Honeypot64 ordnet jedes Ereignis einer Art zu:

Die Einordnung der Web-Angriffe dient nur der Auswertung. Honeypot64 ist keine Web Application Firewall und schützt keine echten Anwendungen.

API

Über die lokale API mit API-Key (Änderungen stehen im Audit-Log):

Prometheus

Die Kennzahlen stehen unter /api/metrics (siehe Prometheus), im Modus ohne Oberfläche auf der Info-Seite. Zähler laufen seit dem Start.

Beispiel für einen Alarm, wenn seit einer Stunde keine Meldung angekommen ist: time() - node64_honeypot_report_last_success_timestamp > 3600.

Modus ohne Oberfläche (reiner Sensor)

Node64 kann auch als reiner Sensor laufen: nur die Fallen-Dienste, keine Weboberfläche, keine anderen Module, keine Anmeldung. So sind 22, 80 und 443 frei für die Fallen, und es gibt keine Admin-Seite als Angriffsfläche. Eingestellt wird alles über Umgebungsvariablen. Den Zustand zeigen das Log, eine kleine Info-Seite und Prometheus auf einem eigenen Port. Der Sensor braucht etwa 30–50 MB RAM und läuft auf amd64, arm64 und arm/v7 (ältere Raspberry Pi, viele NAS).

Start

docker run -d --name honeypot64 --network host --restart unless-stopped \
  -e NODE64_MODE=honeypot -e NODE64_HONEYPOT_PROFILE=standard \
  -e NODE64_IPV64_KEY=DEIN_API_KEY \
  -v honeypot64:/data ghcr.io/ipv64net/node64

Ohne NODE64_IPV64_KEY bleiben alle Ereignisse lokal. Das öffentliche Image erscheint in Kürze. Beim Start steht im Log für jeden Dienst, ob er offen ist und, wenn nicht, warum (z. B. address already in use oder permission denied). docker stop schließt erst die Info-Seite, dann die Fallen, und schreibt gepufferte Ereignisse in die Datenbank.

Umgebungsvariablen

Info-Seite, /metrics und /health

Auf dem Info-Port (getrennt von den Fallen) antwortet ein kleiner Server, nur mit GET und HEAD:

Zugriff: Ohne Token nur aus privaten Netzen (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00::/7), CGNAT (100.64.0.0/10, z. B. Tailscale), Loopback und Link-Local. Es zählt allein die Absender-Adresse der Verbindung, Kopfzeilen wie X-Forwarded-For nicht. Mit NODE64_HONEYPOT_INFO_TOKEN ist die Seite zusätzlich von überall erreichbar – mit ?token=… oder Authorization: Bearer …; alles andere bekommt 403. Den Info-Port gibst du trotzdem nicht am Router frei.

scrape_configs:
  - job_name: honeypot64
    static_configs:
      - targets: ["honeypot.lan:9064"]
    # von außerhalb privater Netze: authorization: { credentials: "DEIN_TOKEN" }

Firewall-Helfer (nftables)

Im Modus ohne Oberfläche trägt Node64 auf Wunsch die v64 Blocklist in die Firewall des Hosts ein – wie ein Firewall-Bouncer. Was andere Sensoren gesehen haben, kommt dann gar nicht erst bei deinen Diensten an.

docker run -d --name honeypot64 --network host --cap-add NET_ADMIN --restart unless-stopped \
  -e NODE64_MODE=honeypot -e NODE64_IPV64_KEY=DEIN_API_KEY \
  -e NODE64_FIREWALL=nftables -e NODE64_FIREWALL_ALLOW=BUERO_IP,VPN_NETZ/24 \
  -e NODE64_IPV64_LIST_TOKEN=DEIN_LISTEN_TOKEN \
  -v honeypot64:/data ghcr.io/ipv64net/node64

• Eigene Tabelle: Node64 legt table inet node64 mit den Sets blocklist_v4 und blocklist_v6 und den Ketten input und forward an (vor den üblichen Filterregeln). Sie verwerfen nur Pakete, deren Absender auf der Liste steht; alles andere geht unverändert an deine vorhandene Firewall (ufw, firewalld, Docker). Anschauen mit nft list table inet node64.
• Listen: Standard ist die Gesamtliste v64; mit NODE64_FIREWALL_LISTS wählst du andere Listen aus der index.json, z. B. v64_ssh,v64_web oder auch fremde wie spamhaus_drop. Ohne Listen-Token gilt der Tagesstand, mit NODE64_IPV64_LIST_TOKEN (Token holen) die Live-Fassung.
• Aktualisierung: alle 30 Minuten, nur bei Änderungen. Die Sets werden in einer Transaktion ersetzt – es gibt keinen Moment ohne Schutz. Fehlt die Tabelle (z. B. nach nft flush ruleset), legt Node64 sie neu an. Die letzte Fassung liegt unter /data, damit der Schutz nach einem Neustart ohne Netz sofort steht.
• Nie gesperrt: private und reservierte Netze, bei IPv6 alles außerhalb von 2000::/3, die Adressen des Hosts selbst und NODE64_FIREWALL_ALLOW. Zu große Netze aus einer Liste (größer als /8 bzw. /16) werden verworfen.
• Beenden: docker stop löscht die Tabelle; mit NODE64_FIREWALL_KEEP=1 bleibt sie stehen.
• Zustand: auf der Info-Seite (Einträge, Fassung je Liste, letzte Prüfung, Fehler) und unter /metrics.

Rechte: --cap-add NET_ADMIN erlaubt dem Container, die Firewall zu ändern, --network host ist nötig, sonst schützt die Tabelle nur das Netz des Containers. Ohne NET_ADMIN startet Node64 mit NODE64_FIREWALL=nftables gar nicht. Nur Linux mit nftables im Kernel (auch Hosts, deren iptables über nftables läuft).

MikroTik RouterOS (Container)

Der Sensor kann direkt auf einem MikroTik-Router laufen: dasselbe Image, Modus ohne Oberfläche, Profil minimal (SSH 22, HTTP 80).

Voraussetzungen

• RouterOS 7; die Befehle gelten für 7.21 oder neuer.
• Paket container installiert (aus den „Extra packages“ der eigenen Version) und Container-Modus freigeschaltet – nach dem Befehl die Reset-Taste drücken (x86: Kaltstart):
  routeros

  /system/device-mode/update container=yes

• Architektur arm64, arm 32 Bit (linux/arm/v7) oder x86 (linux/amd64). Geräte mit EN7562CT (z. B. hEX Refresh) führen nur arm32v5-Images aus; dafür gibt es kein Image.
• Mindestens 256 MB RAM; der Sensor braucht etwa 30–50 MB.
• Ein externer Datenträger (USB, SATA oder NVMe); MikroTik rät für Container vom internen Speicher ab. Den Namen zeigt /disk print (unten disk1).

1. Netz für den Container

/interface/veth/add name=veth-hp64 address=172.17.0.2/24 gateway=172.17.0.1
/interface/bridge/add name=containers
/ip/address/add address=172.17.0.1/24 interface=containers
/interface/bridge/port/add bridge=containers interface=veth-hp64
/ip/firewall/nat/add chain=srcnat action=masquerade src-address=172.17.0.0/24 comment="Honeypot64 ausgehend"

Nach außen braucht der Sensor nur HTTPS zu ipv64 (Meldung). Damit niemand über den Sensor ins Heimnetz kommt, sperrst du neue Verbindungen vom Container ins LAN. Für LAN-NETZ setzt du dein LAN-Netz ein; die Regel muss vor Regeln stehen, die solchen Verkehr erlauben:

/ip/firewall/filter/add chain=forward src-address=172.17.0.0/24 dst-address=LAN-NETZ connection-state=new action=drop comment="Honeypot64 nicht ins LAN"

2. Fallen-Ports weiterleiten

/ip/firewall/nat/add chain=dstnat in-interface-list=WAN protocol=tcp dst-port=22 action=dst-nat to-addresses=172.17.0.2 to-ports=22 comment="Honeypot64 SSH"
/ip/firewall/nat/add chain=dstnat in-interface-list=WAN protocol=tcp dst-port=80 action=dst-nat to-addresses=172.17.0.2 to-ports=80 comment="Honeypot64 HTTP"

• dst-nat ändert nur das Ziel; der Sensor sieht die echten Quell-Adressen.
• Port 22 und 80 aus dem Internet landen danach beim Sensor, nicht mehr beim Router. Verwalte den Router nur aus dem LAN oder per VPN. Die Regeln greifen nur auf der Interface-Liste WAN.
• Die Info-Seite (9064) nicht weiterleiten. Aus dem LAN ist sie unter http://172.17.0.2:9064/ erreichbar; Prometheus fragt dort /metrics ab.
• Weitere Fallen (z. B. 23, 443) über NODE64_HONEYPOT_SERVICES und je Port eine dst-nat-Regel; jede Falle braucht etwas RAM.

3. Image

Bis das Image öffentlich ist, geht nur der Import als Datei. Auf einem PC mit Docker, Plattform passend zum Router (linux/arm64, linux/arm/v7 oder linux/amd64):

docker pull --platform linux/arm64 ghcr.io/ipv64net/node64:latest
docker save ghcr.io/ipv64net/node64:latest > node64.tar

node64.tar kopierst du auf den Datenträger des Routers (WinBox → Files, SFTP oder SCP), z. B. nach disk1/node64.tar. Später kann RouterOS das Image auch selbst laden (/container/config/set registry-url=https://ghcr.io tmpdir=disk1/tmp, dann remote-image=ipv64net/node64:latest statt file=…) – das braucht aber viel freien RAM; auf kleinen Geräten ist die Datei der sicherere Weg.

4. Umgebungsvariablen und Datenordner

/container/envs/add list=hp64-env key=NODE64_MODE value=honeypot
/container/envs/add list=hp64-env key=NODE64_HONEYPOT_PROFILE value=minimal
/container/envs/add list=hp64-env key=NODE64_IPV64_KEY value=DEIN_API_KEY
/container/envs/add list=hp64-env key=NODE64_HONEYPOT_RETENTION value=3d
/container/mounts/add list=hp64-data src=disk1/honeypot64/data dst=/data

• Ohne NODE64_IPV64_KEY bleiben die Ereignisse lokal. Exporte der Router-Konfiguration können den Key enthalten – solche Exporte nicht weitergeben.
• NODE64_HONEYPOT_RETENTION=3d ist optional und schont den Datenträger.
• Im Datenordner liegen Datenbank, SSH-Host-Schlüssel und Sensor-Kennung. Liegt er im Mount, bleiben sie bei einem Update erhalten.

5. Container anlegen und starten

/container/add name=honeypot64 file=disk1/node64.tar interface=veth-hp64 root-dir=disk1/honeypot64/root envlists=hp64-env mountlists=hp64-data logging=yes start-on-boot=yes memory-max=128M

Der Container startet nach dem Anlegen nicht von selbst. Warte, bis /container/print ihn nicht mehr beim Entpacken zeigt, dann:

/container/start honeypot64
/log/print where topics~"container"

Im Log steht für jeden Fallen-Dienst, ob er offen ist. Danach öffnest du aus dem LAN http://172.17.0.2:9064/. memory-max=128M begrenzt den RAM des Containers; braucht er mehr, beendet RouterOS den Prozess. Den meisten Platz brauchen die Ereignisse in /data (höchstens 200.000).

Ungeprüft

• Ports 22 und 80: Das Image läuft ohne Root und öffnet Ports unter 1024 über cap_net_bind_service. Ob RouterOS das im Container zulässt, ist nicht getestet. Meldet das Log „permission denied“, nimmst du hohe Ports und setzt sie per dst-nat um:
  routeros

  /container/stop honeypot64
  /container/envs/add list=hp64-env key=NODE64_HONEYPOT_SERVICES value="ssh:2222,http:8080"
  /ip/firewall/nat/set [find comment="Honeypot64 SSH"] to-ports=2222
  /ip/firewall/nat/set [find comment="Honeypot64 HTTP"] to-ports=8080
  /container/start honeypot64

• Schreibrechte in /data: nicht getestet. Falls nötig, den gestoppten Container mit /container/set [find name=honeypot64] user=0:0 als root laufen lassen oder ohne Mount betreiben – dann meldet ein neu angelegter Container mit neuer Sensor-Kennung.
• Registry ghcr.io und der Import per docker save sind nicht auf einem Router ausprobiert.
• Aktualisieren: Container stoppen, entfernen und neu anlegen (Daten im Mount bleiben). Der Befehl repull (ab 7.20) ist nicht getestet.
• Ältere RouterOS-Versionen: Vor 7.21 heißt der Parameter mounts= statt mountlists=; mehrere envlists und memory-max je Container gibt es erst ab 7.20. Was die eigene Version kennt, zeigt /container/add ?.
• IPv6 ist hier nicht beschrieben; die Weiterleitung gilt nur für IPv4.

Von der Meldung zur v64 Blocklist

ipv64 bewertet die Meldungen aller Sensoren alle 30 Minuten. Damit eine IP auf die Liste kommt, müssen sie mehrere unabhängige Beitragende gemeldet haben – gezählt werden Accounts, nicht Sensoren. Wie viele es sein müssen, hängt davon ab, wie viele Accounts gerade melden. Nie gelistet werden reservierte Netze, die Sensoren selbst, Infrastruktur von ipv64, große CDNs und freigegebene Adressen. Ohne neue Treffer fällt eine IP nach 14 Tagen wieder heraus.

Die Listen bekommt jeder vollständig (Lizenz CC BY 4.0); der Unterschied ist nur die Aktualität:

• In PROXY64 schaltest du die Listen per Klick ein; mit hinterlegtem Listen-Token lädt PROXY64 die Live-Fassung – siehe Live-Listen mit Listen-Token.
• Live-Fassung: Dein Listen-Token holst du angemeldet unter ipv64.net/honeypot/token.php.
• Firewalls wie pfSense, OPNsense oder MikroTik laden die Listen als Text-Adresse – siehe den Leitfaden zur v64 Blocklist. Die Anleitungen für Firmen-Firewalls folgen der Doku der Hersteller und sind nicht live getestet.
• IP-Auskunft: Warum steht eine IP auf der Liste? Unter ipv64.net/honeypot/ip.php und per API (GET https://ipv64.net/api/v2/threat/ip/{ip}) – mit Status, Vertrauenswert, Listen, Arten und Zeitraum.
• Freigabe: Steht eine eigene Adresse zu Unrecht auf der Liste, stellst du über die IP-Auskunft einen Freigabe-Antrag.
• Statistik: aktive Sensoren, Angriffe der letzten 24 Stunden, häufigste Ports und Arten, Größe der Listen sowie die häufigsten Benutzernamen, Passwörter, Pfade und User-Agents unter ipv64.net/honeypot/stats.php, per API GET https://ipv64.net/api/v2/threat/stats.
• Text-Listen: die häufigsten Passwörter, Benutzernamen, User-Agents und Angriffspfade der Angreifer – für Passwort-Richtlinien, Webserver und WAF. Sie stehen in der index.json der Blocklisten unter data (Kategorie honeypot-data, Lizenz CC BY 4.0).
• Passwortprüfung: Steht ein Passwort auf der Liste der Angreifer? Prüfen unter ipv64.net/honeypot/password.php oder per API GET https://ipv64.net/api/v2/threat/passwords/range/{prefix} – mit k-Anonymität wie bei „Have I Been Pwned“: Übertragen werden nur die ersten Zeichen des SHA-1-Hashs, nie das Passwort, und die Antwort ist aufgefüllt.
• Änderungs-Feed: GET https://ipv64.net/api/v2/threat/feed?since=… liefert nur die Änderungen der Listen seit einem Zeitpunkt – für eigene Werkzeuge und große Abnehmer. Mit API-Key, für alle Account-Klassen außer Standard und für Beitragende.
• Fingerabdrücke: Die häufigsten JA4- und HASSH-Fingerabdrücke aller Sensoren stehen in der Statistik und unter /threat/stats (top.fingerprints).

Fragen und Wünsche zu Honeypot64 gern ins Forum v64.tech.

Etwas unklar, fehlt etwas oder hast du eine Frage zu Node64? Frag im offiziellen Forum v64.tech.