Einer sieht den Angriff.
Alle sind geschützt.
Honeypot64 stellt in Node64 Fallen auf – SSH, Web-Logins, Mail, Datenbanken, RDP und mehr. Wer dort anklopft, hat nichts Gutes vor. Auf Wunsch meldet deine Node das an ipv64.net. Aus den Meldungen vieler unabhängiger Sensoren entsteht die v64 Blocklist, und die schützt dann PROXY64, Firewalls und Router aller Nutzer.
Dein Sensor schützt alle – und alle schützen dich
Ein Angreifer probiert selten nur eine Adresse. Er scannt ganze Netze und versucht es bei Tausenden. Steht er bei einem Sensor in der Falle, kann er schon auf der Liste stehen, bevor er bei dir ankommt.
- Erfassen
Deine Fallen, Logs und PROXY64 sehen, wer anklopft – mit Art, Port, Zugangsdaten und Fingerabdruck des Werkzeugs. - Melden (Opt-in)
Alle 10 Minuten geht eine kompakte Meldung an ipv64.net. Private Adressen und deine eigene IP bleiben immer draußen. - Bewerten
ipv64 bewertet alle 30 Minuten. Auf die Liste kommt nur, wen mehrere unabhängige Accounts gemeldet haben. Ein einzelner Sensor kann niemanden sperren lassen. - Schützen
Die v64 Blocklist wirkt in PROXY64 und in Firewalls und Routern (nftables, pfSense, OPNsense, MikroTik …) – bei allen, die sie nutzen.
┌──────────────────────────────────┐ │ Honeypot64 auf vielen Nodes │ │ Fallen · Logs · Syslog · PROXY64 │ └────────────────┬─────────────────┘ │ Meldung alle 10 min (Opt-in) ▼ ┌──────────────────────────────────┐ │ ipv64.net │ │ Bewertung alle 30 min │ │ nur bei mehreren Accounts │ └────────────────┬─────────────────┘ │ v64 Blocklist ▼ ┌──────────────────────────────────┐ │ PROXY64 · Firewall · Router │ │ bei allen Nutzern │ └──────────────────────────────────┘
Was Honeypot64 kann
Ein leichter Low-Interaction-Honeypot: Er nimmt Logins an und lehnt sie immer ab. Es gibt keine Shell, nichts wird ausgeführt oder heruntergeladen. Dazu kommt alles, was aus Beobachtungen Schutz macht.
Fallen für alles, was Bots angreifen
SSH, Telnet, Web-Logins, FTP, SMTP, IMAP, POP3, MySQL, PostgreSQL, MSSQL, Redis, RDP, VNC, MQTT, MikroTik-API, SNMP und SIP – dazu beliebige TCP-Ports. Ein Katalog mit Schalter je Dienst, Vorlagen Minimal, Standard und Voll.
Köder für echte Geräte
Die Web-Köder beantworten die Login-Aufrufe von FRITZ!Box, OpenWrt, Firewalls und SSL-VPN, NAS, UniFi, Proxmox, Home Assistant, Grafana und mehr. Bots greifen die Adressen an, nicht die Optik.
Logs und Syslog
Der Log-Sensor liest die Logs deiner echten Dienste (sshd, nginx, Postfix, Proxmox, Nextcloud, Vaultwarden …) und nimmt Syslog von Router und Firewall an. Gespeichert werden nur IP, Art und Anzahl, nie Inhalte deiner Nutzer.
Hand in Hand mit PROXY64
Unbekannte Anfragen landen beim Köder statt bei der Standardseite, PROXY64 gibt seine Zugriffe an den Log-Sensor, und auffällige IPs sperrt es sofort für alle Hosts – ohne auf die Liste zu warten.
Firewall-Helfer
Als reiner Sensor trägt Node64 die v64 Blocklist per nftables direkt in die Firewall des Hosts ein – wie ein Firewall-Bouncer. Eigene Netze stellst du vorher frei.
Frühwarnung für dein Netz
Fällt eine Adresse aus deinem eigenen Netz als Angreifer auf – etwa ein gekapertes Gerät –, meldet dir die Node das. Deine DynDNS-IPs überwacht ipv64 automatisch.
Fingerabdrücke der Werkzeuge
JA4 bei TLS, HASSH bei SSH: So erkennst du dasselbe Angriffswerkzeug hinter wechselnden IPs – lokal in der Rangliste und gemeinsam in der Statistik von ipv64.
Klein genug für überall
Als Modul in Node64 oder ganz ohne Oberfläche als reiner Sensor: etwa 30–50 MB RAM, für amd64, arm64 und arm/v7 – vom Raspberry Pi bis zum MikroTik-Router.
Auswertung, API & Prometheus
Verlauf, Weltkarte und Herkunft nach Land, Ranglisten für IPs, Zugangsdaten, Pfade und Fingerabdrücke, farbig, was angegriffen wurde, die letzten Ereignisse mit Payload. Alles auch per JSON-API und als Metriken für Prometheus und Grafana.
Sieht aus wie das Original
Scanner prüfen, was sie vor sich haben. Deshalb gibt sich jede Falle je Port als echter Dienst aus – mit Banner, Kopfzeilen, Fehlerseiten, API-Antworten und Zertifikat wie beim Original: Proxmox VE, Webmin, Home Assistant, Grafana, NAS, Elasticsearch, nginx oder Apache, OpenSSH oder Dropbear, MySQL oder MariaDB, Telnet von BusyBox oder Linux.
- Je Sensor anders: Hostname, Versionen und Zertifikat leitet jeder Sensor aus seiner Kennung ab – stabil über Neustarts, aber nicht bei allen gleich. Kein fester Fingerabdruck, an dem Bots die Falle erkennen.
- Passender Standard je Port, frei wählbar in der Tabelle der Fallen-Dienste.
- Ohne Logos und nachgebaute Oberflächen – Bots greifen Adressen und Protokolle an, nicht die Optik.
Port Was der Scanner sieht
┌──────────────────────────────────────────────────────────┐
│ 22/tcp SSH-2.0-OpenSSH_9.2p1 Debian · Dropbear │
│ 23/tcp BusyBox oder Debian/Ubuntu-Login │
│ 3306/tcp MySQL 8.0 · MariaDB 10.11 / 11.4 │
│ 80, 443 nginx · Apache │
│ 8006/tcp Proxmox VE, mit PVE-Zertifikat │
│ 8123/tcp Home Assistant │
│ 3000/tcp Grafana │
│ 5000/5001 NAS │
│ 9200/tcp Elasticsearch 7.17 │
│ 10000/tcp Webmin │
└──────────────────────────────────────────────────────────┘
Hostname, Versionen, Zertifikat: je Sensor anders, stabil
Sieh, wer bei dir anklopft
Schon nach wenigen Stunden mit Portfreigabe füllen sich die Ranglisten – mit Passwörtern, die Bots wirklich probieren, und Pfaden, nach denen sie suchen.
Woher die Angriffe kommen: die Weltkarte der letzten 7 Tage. Ein Klick auf ein Land filtert die Ereignisliste.
Ranglisten der letzten 7 Tage: root:123456 ist auch 2026 noch der Klassiker. Die IPs im Bild stammen aus Beispielnetzen.
Dienste-Katalog: einschalten, was online sein soll. Ports, die PROXY64 oder DNS64 schon nutzen, erkennt Node64 von selbst.
Letzte Ereignisse mit Art, Zugangsdaten, Pfad und Fingerabdruck – filterbar nach Honeypot, Log und Syslog.
Honeypot64 und typische Alternativen
Große Honeypot-Plattformen zeigen viel, brauchen aber einen eigenen Server. Reine Log-Agenten sehen nur, was bei deinen Diensten ankommt. Honeypot64 verbindet beides – klein genug für das Gerät, das ohnehin läuft.
| Funktion | Honeypot64 | Honeypot-Plattform (z. B. T-Pot) | Log-Agent mit Community-Liste (z. B. CrowdSec) |
|---|---|---|---|
| Speicherbedarf | ca. 30–50 MB | mehrere GB | gering |
| Raspberry Pi, NAS, MikroTik-Router | amd64, arm64, arm/v7 | eigener Server empfohlen | |
| Fallen-Dienste (SSH, Web, Mail, Datenbanken …) | Low Interaction | sehr viele | nicht der Schwerpunkt |
| Logs echter Dienste und Syslog auswerten | nicht der Schwerpunkt | ||
| Gemeinsame Blockliste aus den Meldungen | v64 Blocklist | nicht von Haus aus | |
| Sperre im eigenen Reverse-Proxy | PROXY64, sofort | – | per Zusatzbaustein |
| Firewall-Helfer (nftables) | – | ||
| Weitere Module im selben Container | Healthchecks, PROXY64, DNS64, DynDNS64 | reiner Honeypot | reine Sicherheitsplattform |
Angaben zu den Alternativen nach allgemeinem Kenntnisstand für eine typische Installation; Funktionen können sich mit neuen Versionen ändern.
Häufige Fragen
Alles Weitere steht Schritt für Schritt in der Honeypot64-Doku.
Fallen nützen nur, wenn sie von außen erreichbar sind. Auf diesen Ports dürfen nie echte Dienste laufen – am besten nimmst du ein eigenes Gerät in einem abgetrennten Netz. Mehr zur Sicherheit
NODE64_MODE=honeypot) braucht der Sensor etwa 30–50 MB RAM und läuft auf amd64, arm64 und arm/v7. Für MikroTik RouterOS gibt es eine Anleitung für das Container-Paket.Stell eine Falle auf – und mach das Netz für alle sicherer
Node64 installieren, Honeypot64 einschalten, Fallen auswählen, Ports freigeben. Die Meldung an ipv64 schaltest du mit einem Klick dazu. Das öffentliche Image erscheint in Kürze.
Passend dazu: PROXY64 sperrt mit der v64 Blocklist und sofort nach Meldung des Honeypots, DNS64 filtert Schadhosts schon beim Namen.
