Worum geht’s?

Wer einen Port ins Internet aufmacht, merkt schnell: Man ist nie allein. Scanner klopfen rund um die Uhr an, Bots probieren Passwörter durch, irgendwer will immer irgendwas. Das weiß man theoretisch. Ich wollte mir aber einmal selbst einen Eindruck verschaffen: Was kommt eigentlich auf einem ganz normalen privaten Anschluss an – einem, der nirgendwo öffentlich steht, keine Website hostet und den eigentlich niemand kennt? Und was machen Angreifer, wenn sie glauben, sie hätten es geschafft?

Genau dafür gibt es Honeypots: Systeme, die absichtlich verwundbar aussehen, Angreifer anlocken und dabei alles mitschreiben. Echte Daten liegen darauf nicht – der ganze Zweck ist, angegriffen zu werden.

Meine Wahl fiel auf T-Pot von der Telekom. T-Pot ist keine einzelne Falle, sondern ein ganzer Zoo: Dutzende Honeypots in Docker-Containern, die alle möglichen Dienste vorspielen – SSH, Telnet, RDP, Webserver, Datenbanken, sogar Drucker. Dazu kommen Auswertung mit Kibana und eine animierte Angriffskarte. Alles in einem install.sh.

Voraussetzungen

• Hypervisor: Proxmox VE, der Honeypot läuft als eigene VM
• VM: 4 vCPU, 16 GB RAM (ohne Ballooning), 256 GB Platte – das entspricht den Mindestanforderungen von T-Pot für eine vollständige Installation („Hive“)
• Betriebssystem: Debian 13 netinst, nur SSH-Server und Standard-Werkzeuge
• T-Pot: Installation per install.sh aus dem GitHub-Repo der Telekom, Stand Oktober 2026
• Firewall: FortiGate mit eigenem DMZ-Netz
• Proxmox-Snapshots vor und nach der Installation

Warum eine VM und kein eigener Mini-PC? Snapshots, schnell wegwerfbar, kein zusätzliches Gerät. Und ich wollte den Honeypot bewusst nicht auf dieselbe Kiste setzen wie andere Dienste, die im Ernstfall weiterlaufen sollen.

Umsetzung

Schritt 1: Eine DMZ, die ihren Namen verdient

Ein Honeypot ist per Definition ein System, das man Angreifern zum Fraß vorwirft. Er darf also auf keinen Fall Zugriff auf den Rest des Heimnetzes haben. Deshalb bekommt er ein eigenes Netz, eine DMZ (demilitarisierte Zone): ein Netzsegment, das von außen erreichbar ist, aber nicht nach innen darf.

Die Regeln auf der FortiGate, sinngemäß:

Die Management-Oberfläche von T-Pot liegt auf hohen Ports: 64295 für SSH, 64297 für die Weboberfläche. Die sind nur aus meinem Client-Netz und über VPN erreichbar. Port 22 gehört ab der Installation dem SSH-Honeypot – wer sich nach dem Setup gewohnheitsmäßig per ssh auf Port 22 verbindet, landet in der Falle und nicht auf dem System.

Zwei Entscheidungen, über die ich länger nachgedacht habe:

• Kein Traffic-Log auf der Regel „Internet → Honeypot“. Sonst flutet der Honeypot mein zentrales Log-System. T-Pot protokolliert ohnehin alles selbst.
• Kein IPS auf dieser Regel. Ein Intrusion Prevention System würde genau die Angriffe blocken, die ich sehen will.

Die Regeln aus der DMZ heraus loggen dagegen voll. Wenn der Honeypot plötzlich anfängt, selbst Verbindungen aufzubauen, die nicht nach Updates aussehen, will ich das wissen.

Schritt 2: Portweiterleitung auf der FortiGate – mit Central NAT

Damit der Honeypot von außen erreichbar ist, braucht es Portweiterleitungen, auf der FortiGate VIPs (Virtual IPs) genannt. Ich habe TCP 1–64000 und den UDP-Bereich weitergeleitet, mit einer Ausnahme für einen UDP-Port, den mein VPN braucht.

Mein Gerät arbeitet mit Central NAT, und da gibt es eine Eigenheit, über die ich gestolpert bin:

• Die VIPs gehören nicht in die Firewall-Regel. Als Ziel trägt man die echte interne Adresse des Honeypots ein.
• Die VIPs sind aktiv, sobald sie existieren. Ohne passende Regel greift zwar das implizite „Deny“ – trotzdem lohnt es sich, das im Kopf zu haben.

Die Regel „Internet → Honeypot“ habe ich erst aktiviert, als alles andere getestet war.

Schritt 3: Debian und T-Pot installieren

Die VM bekommt ein minimales Debian 13, eine feste IP in der DMZ (bei mir im Beispiel 10.0.99.10), öffentliche DNS-Server und einen normalen Benutzer mit sudo. Root-Login ist gesperrt.

Vor der Installation ein Snapshot, dann T-Pot:

git clone https://github.com/telekom-security/tpotce
cd tpotce
./install.sh

Der Installer fragt den Typ ab – ich habe Hive gewählt, also die Vollinstallation mit allen Honeypots und der Auswertung auf einer Maschine. Danach: Neustart, Snapshot, fertig.

Fertig? Nicht ganz.

Schritt 4: Die Docker-Falle

Nach der Installation kam ich von meinem PC aus nicht mehr an die Management-Ports. Kein „Connection refused“, sondern einfach Timeout.

Die Firewall war schnell entlastet: Mit diagnose debug flow sah ich, dass die Pakete erlaubt und korrekt in die DMZ geroutet wurden. Danach kamen nur noch wiederholte SYN-Pakete mit derselben Sequenznummer – die VM hat schlicht nie geantwortet. Auf der VM selbst lauschten sshd und die Weboberfläche brav auf ihren Ports.

Die Lösung fand ich mit einem einzigen Befehl auf der VM:

ip route get 192.168.68.20

192.168.68.20 dev br-1a2b3c4d5e6f src 192.168.64.1

Die VM wollte die Antwort an meinen PC in eine Docker-Bridge schicken statt zum Gateway.

Der Grund: T-Pot legt rund 25 Docker-Netze an, und Docker vergibt deren Subnetze standardmäßig aus seinem Pool 192.168.x.0/20. Eines davon war 192.168.64.0/20 – das reicht von 192.168.64.0 bis 192.168.79.255. Und mittendrin lag mein Client-Netz. Aus Sicht der VM war mein PC also „lokal“ hinter einer Docker-Bridge.

Die Lösung: Docker einen Adressbereich geben, den es im Heimnetz garantiert nicht gibt, und die Netze neu anlegen lassen.

{ "default-address-pools": [ { "base": "172.16.0.0/12", "size": 24 } ] }

Das kommt nach /etc/docker/daemon.json. Danach:

sudo systemctl stop tpot
sudo systemctl restart docker
sudo docker network prune -f
sudo systemctl start tpot
ip route get 192.168.68.20

Jetzt geht die Route wieder über das Gateway der DMZ, und das überlebt auch Neustarts – inklusive des täglichen Auto-Reboots, den T-Pot von Haus aus macht.

Ein kleiner Trick am Rande: Solange ich nicht per SSH auf die VM kam, habe ich über den QEMU Guest Agent von Proxmox aus gearbeitet. Damit lassen sich Befehle direkt in der VM ausführen, ganz ohne Netzwerk und ohne Konsole:

qm guest exec <VMID> -- bash -c 'ip route get 192.168.68.20'

Schritt 5: Scharf schalten

Mit funktionierendem Management-Zugang habe ich die Regel „Internet → Honeypot“ aktiviert. Ab da war der Honeypot live.

Zwei Dinge, die T-Pot von Haus aus mitbringt und die man kennen sollte:

• Täglicher Neustart: Nachts stoppt T-Pot seine Dienste, räumt Container und Images auf und startet neu.
• Datenweitergabe: Standardmäßig schickt T-Pot die gesammelten Angriffsdaten an den Sicherheitstacho der Telekom. Das lässt sich abschalten. Ich habe es angelassen – genau dafür ist so eine Community ja da.

Was kam an?

Kurz gesagt: viel. Über den Tag verteilt waren es mehrere tausend Angriffe – die genaue Zahl weiß ich nicht mehr, und mit der VM sind auch die Auswertungen verschwunden. Was mir aber im Kopf geblieben ist: Der Löwenanteil ging auf SSH und RDP. Logisch eigentlich – wer eine Fernwartung erwischt, hat im besten Fall gleich den ganzen Rechner.

Woher die Angriffe kamen, lasse ich hier bewusst weg. Eine Länderliste sagt wenig darüber aus, wer wirklich dahintersteckt – Angreifer nutzen gern fremde Server und gekaperte Geräte irgendwo auf der Welt – und lädt eher zu falschen Schlüssen ein.

Die Mail vom Provider

Knapp zwei Wochen nach dem Start bekam ich Post vom Sicherheitsteam meines Providers. Nicht eine Mail, sondern mehrere – für verschiedene Dienste: SSH, RDP, SNMP und mein Favorit: ein offener IPP-Druckdienst auf Port 631. Bei IPP war es sogar schon die wiederholte Warnung.

Sinngemäß: An meinem Anschluss sei ein Dienst öffentlich erreichbar, das sei ein Sicherheitsrisiko, ich solle die Software aktualisieren, den Zugriff auf interne Netze beschränken oder ein VPN nutzen.

Der Witz daran: Ich habe gar keinen Drucker im Internet. Das war T-Pot, der genau so tat, als hätte ich einen. Die Scanner, auf die sich Provider stützen, haben also genau das gefunden, was der Honeypot ihnen vorgaukeln sollte – einen scheinbar verwundbaren Rechner. Man könnte sagen: Mein Honeypot war zu gut.

Für mich war damit klar: Das ist es nicht wert. Ein Provider, der wiederholt Sicherheitswarnungen schickt, kann im Zweifel auch den Anschluss einschränken. Und mein Internetanschluss ist im Alltag deutlich wichtiger als ein Experiment.

Der Rückbau

Ich bin in drei Schritten vorgegangen:

1. Sofort die Tür zu: Regel „Internet → Honeypot“ deaktiviert und gelöscht, die Portweiterleitungen gelöscht und bestehende Verbindungen zum Honeypot auf der Firewall beendet. Danach war von außen wieder nur der eine VPN-Port erreichbar.

2. VM weg: Die VM samt Snapshots und Festplatte gelöscht:

   qm destroy <VMID> --purge --destroy-unreferenced-disks 1
   

3. Aufräumen: Alle übrigen Regeln und Objekte für die DMZ auf der FortiGate entfernt, inklusive des Interfaces. Nichts soll herumliegen, was später jemand für eine aktive Regel hält.

Nach dem Abschalten: Die Liste vergisst nicht

Spannend wurde es noch einmal nach dem Rückbau. Solange der Honeypot lief, hat meine Firewall von außen kaum etwas geblockt – fast alles wurde ja an den Honeypot durchgereicht, und für diese Regel hatte ich das Logging bewusst abgeschaltet. In meinem Grafana-Dashboard sah das aus wie ein ruhiger Anschluss: eine Handvoll geblockter Verbindungen pro halbe Stunde.

Zum Vergleich: In den Tagen vor dem Honeypot hat die Firewall rund 20 000 eingehende Verbindungsversuche am Tag geblockt. Das ist das ganz normale Hintergrundrauschen, das jeder Anschluss im Internet abbekommt – ein paar Dutzend bis ein paar Hundert pro Messintervall, mit gelegentlichen Spitzen, wenn mal ein Scanner vorbeikommt.

Mit dem Abschalten war die Durchreiche weg – und alles, was vorher im Honeypot gelandet war, prallte jetzt an der Firewall ab. Wie schnell das ging, zeigt mein Dashboard minutengenau: Um kurz vor zwei Uhr nachts habe ich die Weiterleitung gelöscht – und ab dieser Minute prasselten die Blocks herein, bis zu zehn pro Sekunde. In den ersten zehn Minuten waren es schon rund 2 200 geblockte Versuche, ohne Anlaufzeit, als hätten die Scanner nur darauf gewartet. In den ersten gut zweieinhalb Tagen nach dem Abschalten hat die Firewall rund 900 000 eingehende Verbindungsversuche geblockt: knapp 600 000 über TCP, gut 300 000 über UDP. Das sind grob 350 000 am Tag – etwa das Siebzehnfache von vorher.

Und so sieht der Moment des Abschaltens aus der Nähe aus – bis kurz vor zwei Uhr nichts, dann ging es los:

Der Grund liegt auf der Hand: Nach knapp zwei Wochen, in denen meine IP brav auf alles geantwortet hat, steht sie offensichtlich auf den Listen von Scannern und Angreifern als „lohnendes Ziel“. Die klopfen jetzt weiter an, auch wenn niemand mehr aufmacht. Ein Honeypot hinterlässt also Spuren, die länger halten als der Honeypot selbst.

Stolperfallen & Learnings

Docker und 192.168er-Heimnetze vertragen sich schlecht. Docker nimmt sich standardmäßig Subnetze aus 192.168.x.0/20, und die können echte Netze im Heimnetz überdecken. Auf jedem Docker-Host im Heimnetz setze ich ab jetzt default-address-pools – und zwar bevor der erste Container läuft.

Wenn die Firewall „erlaubt“ sagt, liegt es oft am Ziel. diagnose debug flow hat mir viel Suchen an der falschen Stelle erspart. Pakete gehen raus, keine Antwort kommt zurück – dann lohnt der Blick auf die Routen des Zielsystems.

Central NAT tickt anders. VIPs gehören nicht in die Regel, Ziel ist die echte Adresse. Wer vom klassischen Modus kommt, sucht da schnell an der falschen Stelle.

Kein IPS und kein Traffic-Log auf der Eingangsregel – aber volles Log auf allem, was rausgeht. Der Honeypot soll angegriffen werden. Spannend wird es, wenn er selbst anfängt, Verbindungen aufzubauen.

Ein Honeypot am Privatanschluss fällt auf. Er beantwortet die ganze öffentliche IP, sieht für Scanner wie ein schlecht gewartetes System aus und landet damit in den Berichten, die Provider auswerten. Das ist eigentlich gut so – die Sicherheitsmeldungen funktionieren. Nur eben auch für mich. Wer das ausprobieren will: vorher mit dem Provider reden oder gleich einen eigenen Server mit eigener IP nehmen.

Ein Honeypot hat Nachwirkungen. Nach dem Abschalten bleibt die IP auf den Listen der Scanner, und die Firewall hat danach deutlich mehr zu tun als vorher.

Fazit

Ich habe einiges gelernt – über DMZ-Regeln, Central NAT, Docker-Netze und darüber, wie schnell man im Internet auffällt. Nur aufgeschrieben habe ich zu wenig: Die genauen Zahlen sind mit der VM verschwunden. Abgebrochen habe ich trotzdem gern: Eine Sicherheitswarnung vom Provider nach der anderen ist kein Zustand, den man für ein Experiment am Hausanschluss riskieren sollte.

Was als Nächstes kommt

• Wenn ich es noch einmal mache, dann nicht mehr zu Hause, sondern auf einem eigenen Server mit eigener IP – und diesmal mit Notizen und Screenshots von Anfang an.
• Die Erkenntnisse zur DMZ und zu Docker-Netzen fließen in die anderen Dienste in meinem Homelab ein.