Leitfaden

Kostenlosen Honeypot-Sensor einrichten: Angreifer auf dem eigenen Server erfassen

Ein systemd-Dienst in einem Befehl, 64 fertige Decoys, die Sandbox des Dienstes, der Weg der Daten und die Beitragenden-Stufe.

IP-DB-Team 7 Min. Lesezeit 10× gelesen 0 Kommentare

Findet ein Angreifer Ihren Server, sucht er zuerst nach offenen Türen: ein paar Passwörter auf 22, ein RDP-Versuch auf 3389, ein Redis ohne Passwort auf 6379, eine alte SMB-Lücke auf 445. Die meisten dieser Versuche gehen an Ports, die Sie nicht nutzen — und weil dort nichts lauscht, hinterlassen sie keine Spur. Der Angriff hat stattgefunden, Sie haben ihn nie gesehen.

Genau diese Lücke füllt ein Honeypot-Sensor: Er stellt realistisch aussehende Scheindienste auf unbenutzte Ports, hält fest, wer was versucht hat, und gibt das in den gemeinsamen Bedrohungs-Pool. Die Installation ist ein Befehl, sie kostet nichts, und Sie bekommen zweierlei: Sichtbarkeit, wer Ihren Server abtastet, und die Beitragenden-Stufe für Ihr Konto.

Was ein Sensor tut — und was nicht

Er tut: Auf freien Ports zeigt er eine gefälschte Exchange-Anmeldeseite, ein FortiGate-Panel, ein MySQL-Greeting oder einen Telnet-Prompt; er liest die Anfrage, markiert bekannte Exploit-Muster und meldet „diese Adresse hat auf diesem Port das versucht".

Er tut nicht: Passwörter, Benutzernamen oder Request-Bodies speichern oder senden. Die Decoys führen keine Befehle aus, schreiben keine Dateien, öffnen keine Shell — es ist kein „High-Interaction"-Honeypot, bei dem sich ein Angreifer tatsächlich anmeldet. Ein Ereignis besteht aus einem Tag und einem Zeitstempel.

Das ist bewusst so: High-Interaction-Honeypots sind Pflegearbeit und ein echtes Risiko. Hier geht es nicht darum, den Angreifer zu studieren, sondern die scannende Adresse zu erkennen.

Installation in einem Befehl

Voraussetzungen: ein Linux-Server mit systemd, Python 3.6 oder neuer, eine öffentlich erreichbare IP und ein kostenloser API-Schlüssel, den Sie im Dashboard in einer Minute anlegen.

# Installation: Schlüssel ersetzen curl -fsSL https://ip-db.com/sensor/install.sh | sudo bash -s -- --key IHR_API_SCHLUESSEL

Der Befehl richtet einen gehärteten systemd-Dienst (ipdb-sensor) ein, der auf Ports lauscht, die Ihr Server nicht belegt. Wenn Sie einer Pipe nicht blind vertrauen wollen — und das sollten Sie nicht —, lesen Sie das Skript vorher; die SHA-256-Summe des Downloads wird bei der Installation geprüft:

curl -fsSL https://ip-db.com/sensor/install.sh | less curl -fsSL https://ip-db.com/sensor/SHA256SUMS

Die wichtigsten Optionen:

OptionWirkung
--name web-01Name des Sensors im Dashboard (Standard: Hostname)
--profiles @edge,exchangeWelche Decoys laufen
--ports 23,3389,6379Zusätzliche rohe TCP-Ports
--ignore 198.51.100.0/24Eigene Monitoring- und Büroadressen nie melden
--fail2banSperren aus dem fail2ban-Log mitlesen
--status / --upgrade / --uninstallStatus, Upgrade, Entfernen

Welche Fallen sollen aufgehen?

Der Sensor bringt 64 fertige Decoy-Profile mit, und Sie müssen sie nicht einzeln auswählen: Bündel mit @ sind thematische Gruppen.

BündelInhaltFür wen
@classicFTP, Telnet, SSH, RDP, MySQL, Redis, MongoDB, VNC…Standard; auf jedem Server sinnvoll
@recommendedExchange, FortiGate, GlobalProtect, NetScaler + KlassikerDie real am häufigsten gescannte Mischung
@edgeFortiGate, Ivanti, Cisco ASA, F5, SonicWall, pfSense…Scans auf Edge-Geräte und VPNs
@webWordPress, phpMyAdmin, cPanel, Plesk, Tomcat…Hosting- und Webserver
@devopsJenkins, GitLab, Grafana, Docker, Kubernetes, etcd…CI/CD und interne Werkzeuge
@mail · @databases · @remote · @iotMail-, Datenbank-, Remote- und IoT-GruppenMaschinen mit klarer Rolle

Wählen Sie Ports, die Sie nicht nutzen: Kann der Sensor einen Port nicht binden, überspringt er das Decoy stillschweigend. Welches Decoy auf welchem Port läuft, zeigt der Baukasten auf der Honeypot-Seite — er baut den Installationsbefehl aus Ihrer Auswahl.

Mit welchen Rechten der Dienst läuft

Die Installation braucht einmal sudo; der Dienst selbst läuft nicht als root, sondern als temporärer unprivilegierter Benutzer von systemd (DynamicUser) mit einer einzigen Berechtigung: Ports binden (CAP_NET_BIND_SERVICE). Das Dateisystem ist schreibgeschützt, /tmp privat, Geräte gibt es nicht, erlaubt sind nur IPv4/IPv6- und systemd-Notify-Sockets, Systemaufrufe sind gefiltert und der Speicher ist auf 96 MB begrenzt. Der gesamte Code ist eine einzige Python-Datei ohne Abhängigkeiten — lesbar kurz, auch das mit Absicht.

Prüfen, ob er läuft

# Status und laufendes Log sudo systemctl status ipdb-sensor journalctl -u ipdb-sensor -f

Im Log stehen die geöffneten Decoys, die wegen belegter Ports übersprungenen und der erste Versand. Ereignisse gehen gesammelt einmal pro Minute hinaus, die ersten Einträge im Dashboard können also eine Minute brauchen. Ihre Sensoren, die gesehenen Adressen und die Ereigniszahlen stehen unter Meine Sensoren.

Auf Cloud-Servern prüfen Sie die Security Group: sperrt die Firewall des Anbieters die Ports, erreicht kein Scanner den Sensor und die Seite bleibt leer. Normal ist, schon in den ersten Stunden Ereignisse zu sehen — das Internet ist kein stiller Ort.

Was mit den Daten passiert: die Zwei-Konten-Regel

Eine Adresse, die Ihr Sensor sieht, landet nicht direkt auf der Blockliste. Für den Sensor-Pool muss sie in den letzten 7 Tagen von Sensoren aus mindestens zwei verschiedenen Konten und zwei verschiedenen Netzen gesehen worden sein. Ein einzelner Sensor kann niemanden auf die Liste setzen — damit ein falsch konfigurierter Scan oder ein böswilliger Nutzer den Pool nicht verunreinigt.

Was in den Pool kommt, steht in den offenen Datensätzen und über die API allen zur Verfügung. Der Scan, den Ihr Server abfängt, wird so zur Sperre in der Firewall eines anderen — und nur dadurch ist die Liste überhaupt etwas wert.

Die Gegenleistung: Beitragenden-Stufe

Ein kostenloses Konto darf 1.000 Abfragen am Tag, ein Konto mit bestätigter E-Mail 10.000. Bestätigte Konten mit einem aktiven Sensor (oder einer Shield-/WordPress-Installation) kommen auf 30.000 am Tag. Die Stufe wird berechnet, nicht vergeben: Sie gilt, solange der Sensor in den letzten 7 Tagen gemeldet hat, und fällt von selbst weg, wenn er schweigt. Keine Zahlung, kein Tarif, keine „Enterprise-Edition".

Häufige Fehler

  • Eigene Scanner melden. Tastet Ihr interner Schwachstellenscan jede Woche alle Ports ab, nehmen Sie Ihre Bereiche mit --ignore heraus.
  • Den Port eines echten Dienstes wählen. Läuft auf 22 SSH, geht das SSH-Decoy nicht auf. Verschieben Sie es (ssh:2222) oder lassen Sie das Bündel weg.
  • Hinter NAT installieren. Auf einer von außen unerreichbaren Adresse sieht ein Honeypot nichts; ohne Portweiterleitung gehört der Sensor auf eine Maschine mit öffentlicher IP.
  • Mit der kritischen Maschine anfangen. Technisch ist es sicher, aber die erste Installation auf einem Randserver und ein Tag Log-Lesen ist die bessere Gewohnheit.

Upgrade und Deinstallation

# aktualisieren curl -fsSL https://ip-db.com/sensor/install.sh | sudo bash -s -- --upgrade # vollständig entfernen curl -fsSL https://ip-db.com/sensor/install.sh | sudo bash -s -- --uninstall

Die Deinstallation entfernt Dienst, Unit und Verzeichnis; es bleiben nur die vergangenen Ereignisse in Ihrem Dashboard. Das Konto bleibt unberührt, lediglich die Beitragenden-Stufe fällt nach 7 Tagen weg.

Häufige Fragen

Bringt ein Honeypot-Sensor meinen Server in Gefahr?

Die Decoys führen keine Befehle aus, schreiben keine Dateien und öffnen keine Shell: Sie lesen die Anfrage, antworten realistisch und markieren das Ereignis. Der Dienst läuft nicht als root, sondern als temporärer unprivilegierter Benutzer von systemd (DynamicUser); seine einzige Berechtigung ist das Binden von Ports, das Dateisystem ist schreibgeschützt und der Speicher auf 96 MB begrenzt. Trotzdem ist eine Randmaschine der bessere erste Host als Ihr kritischer Datenbankserver.

Belegt er Ports, die ich schon nutze?

Nein. Der Sensor versucht jeden Port zuerst zu binden; ist er belegt, überspringt er das Decoy und schreibt es ins Log. Läuft auf 22 echtes SSH, bleibt das SSH-Decoy stillschweigend aus — lassen Sie den Port frei oder verschieben Sie das Decoy (etwa ssh:2222).

Wie viel sendet er, und verbraucht das mein Kontingent?

Ereignisse gehen gesammelt einmal pro Minute hinaus und zählen nicht gegen Ihr täglentliches Abfragekontingent: Melden und Abfragen sind getrennte Zähler. Im Gegenteil — ein aktiver Sensor hebt Ihr Konto in die Beitragenden-Stufe.

Landet eine Adresse, die ein Sensor sieht, direkt auf der Blockliste?

Nein. Für den Sensor-Pool muss eine Adresse in den letzten 7 Tagen von Sensoren aus mindestens zwei verschiedenen Konten und zwei verschiedenen Netzen gesehen worden sein. Ein einzelner Sensor kann keine Adresse auf die Liste setzen — damit ein falsch konfigurierter Scanner oder ein böswilliger Nutzer den Pool nicht verunreinigt.

Um Ihre Website mit denselben Daten zu schützen, lesen Sie die Shield-Installation, für WordPress den Plugin-Leitfaden und zur Bewertung den Beitrag zum Reputationswert.

Teilen

Kommentare 0

Teile eine Frage, Erfahrung oder Korrektur — registriert oder anonym.

Noch keine Kommentare. Schreib den ersten.

Nur Text, keine Links. Kommentare erscheinen sofort und können moderiert werden. Anmelden, um registriert zu kommentieren