Node64 im Homelab: Honeypot liest das Caddy-Log mit und überwacht zehn Dienste

Wir haben am 6. November 2026 Node64 auf dem Caddy-Gateway unseres Homelabs gestartet. Der Honeypot öffnet dort keinen einzigen Port, er liest das Zugriffslog von Caddy, so wie es CrowdSec auch tut. Daneben laufen zehn Prüfungen, deren Ergebnis im selben Dashboard steht. Hier steht, wie wir das aufgebaut haben, was schon läuft und was wir noch nicht belegen können.

Was Node64 ist

Node64 ist ein quelloffener Container von ipv64.net mit mehreren Modulen: Prüfungen für Dienste und Zertifikate, ein Honeypot, ein Reverse Proxy, ein DNS-Filter und ein DynDNS-Dienst. Er läuft als einzelnes Programm, speichert in einer SQLite-Datei und steht unter Apache 2.0. Wir nutzen davon nur die Prüfungen und den Honeypot, und beides lokal ohne Konto.

Die Lizenz haben wir in der Datei LICENSE im Repository gelesen. Der Stand dort: 17 Sterne, 3 Forks, letzter Push am 5. November 2026, die Version 1.0.0 erschien am 4. November. Das Projekt ist also sehr jung, und wir behandeln es entsprechend als Versuch.

So ist es aufgebaut

Node64 läuft als Container im selben Docker-Projekt wie Caddy und CrowdSec auf dem Gateway. Der Web-Zugang hängt hinter dem Caddy-Eintrag (trusted), einer Liste erlaubter Absender-Adressen. Alle anderen Adressen bekommen eine leere Antwort. Das haben wir von außen mit einem Server geprüft, der nicht auf der Liste steht: Antwort 200 mit null Bytes.

Das Log kommt über ein Verzeichnis, das wir schreibgeschützt in den Container einhängen. Zwei Dinge mussten wir dafür ändern. Caddy schreibt sein Log sonst mit dem Modus 0600, den der Container nicht lesen darf. Die Caddy-Dokumentation beschreibt dafür die Option mode, bei uns steht jetzt 0640. Außerdem tritt der Container der Gruppe des Caddy-Benutzers bei.

Die Einstellung im Honeypot heißt "Nur über PROXY64", das Profil ohne eigene Fallen-Dienste. Die Meldung an ipv64 steht auf "aus", und es ist kein API-Key hinterlegt. Laut Dokumentation sendet Node64 ohne Key nichts, solange man es nicht ausdrücklich einschaltet.

Was ein Honeypot ist

Ein Honeypot ist ein Dienst oder eine Auswertung, die nur dazu da ist, Angriffe sichtbar zu machen. Niemand mit einem legitimen Anliegen ruft sie auf. Jeder Treffer ist deshalb verdächtig und zeigt, welche Adressen, Pfade und Zugangsdaten Angreifer ausprobieren. Er schützt nicht von selbst, er liefert Frühwarnung und Material für Sperrlisten.

Was lief am 6. November 2026

In der Programmoberfläche Healthchecks 2.52.2 entstanden zwölf Prüfungen. Zehn laufen, zwei sind wieder gelöscht.

Eigene Messung vom 6. November 2026, Messträger: Alpine-Linux-Container auf dem Homelab-Gateway, Node64 1.0.1, Honeypot64 0.19.0.

Die zwei gelöschten Prüfungen galten den DNS-Servern im Firmennetz. Von dort antwortet nichts auf Anfragen aus dem Homelab, auch SSH nicht. Das ist die Firewall zwischen den Zonen und so gewollt. Die Prüfung auf diese Server gehört in einen Monitor im Firmennetz.

Die letzte Zeile der Tabelle ist die Verbindung der beiden Teile. Sie fragt die Programmschnittstelle des Honeypots ab und gilt als ausgefallen, sobald dort mindestens ein Treffer steht. Ein Alarm braucht danach nur noch einen Benachrichtigungskanal, den wir noch nicht eingerichtet haben.

Was wir noch nicht belegen können

Der Log-Sensor hat nach dem Start 73 Zeilen gelesen, kurz danach 278, die Datei ist also erkannt und wächst im Takt des Betriebs. Treffer hatte er bis zum Schreiben dieses Beitrags null. Wir haben zum Test von einer erlaubten Adresse /.env und /wp-login.php auf unserer Webseite ab, beide Anfragen lieferten 404, und der Honeypot meldete trotzdem keinen Treffer. Mögliche Gründe sind eine Schwelle für wiederholte Anfragen oder eine Ausnahme für bekannte Adressen. Die Dokumentation sagt dazu nichts Genaues, und weitere Tests von unserer eigenen Adresse wollten wir nicht wiederholen, weil CrowdSec am selben Gateway Scan-Muster sperrt. Wir warten deshalb auf echten Scan-Verkehr aus dem Internet und berichten, ob und was er findet.

Offen ist außerdem, wie sich das Update verhält. Wir haben das Image nicht mehr an einen Digest gebunden, damit der nächtliche Update-Lauf es mit den anderen Containern erneuert. Bricht eine neue Version etwas, hilft nur das Zurücksetzen auf den alten Digest.

Dazu passt

Wie wir Zugriffe am Gateway sperren, steht im Beitrag CrowdSec statt fail2ban. Den Reverse Proxy selbst beschreibt Caddy als Reverse Proxy mit HTTPS ab Werk. Weitere Themen zu Absicherung und Datenschutz finden Sie im Bereich Security und Datenschutz. Wenn Sie so einen Aufbau für Ihr Netz suchen, schauen Sie bei unseren IT-Leistungen vorbei.

Danke

Danke an Prox IT und das Team hinter ipv64.net und Node64. Sie veröffentlichen das Projekt unter Apache 2.0, beschreiben in der Dokumentation genau, was gemeldet wird und was nicht, und lassen sich komplett ohne Konto betreiben.

Weiterführende Quellen

Primärquellen

• Node64, Honeypot64-Dokumentation: node64.de
• Node64, Quellcode und Lizenz Apache 2.0: github.com/ipv64net/node64
• Node64, Änderungsprotokoll mit Version 1.0.0: node64.de
• Caddy, Direktive log mit der Option mode: caddyserver.com

Eigene Messung

• Alle Werte in diesem Beitrag stammen vom 6. November 2026 aus unserem Homelab. Herstellerangaben zu Leistung oder Erkennungsrate haben wir nicht übernommen.