Veröffentlichungen

Honeypot-Webhooks: Senden Sie Erkennungen von Angriffen an eine beliebige API

12. Juni 2026 · Patrick Schlesinger

Der ReportedIP kann nun jeden erfassten Angriff an die von Ihnen bereits genutzten Tools weiterleiten. Mit Version 1.3.0 werden die Webhooks zu einem konfigurierbaren Router – wählen Sie die HTTP-Methode, die Header und den Body aus und senden Sie die Erkennungsergebnisse direkt an Ihr SIEM, Slack, Discord oder AbuseIPDB.

Falls Sie bereits einen Honeypot-Knoten betreiben, aktualisieren Sie auf Version 1.3.0 und richten Sie im Admin-Panel einen Endpunkt ein. Die vollständige Einrichtung ist in der Dokumentation zum Honeypot-Server beschrieben.

Was Honeypot-Webhooks leisten

Ein Webhook ist ein HTTP(S)-Endpunkt, der jedes Mal eine Anfrage erhält, wenn der Honeypot einen Angriff meldet. Diese Funktion wurde erstmals in Version 1.2.0 eingeführt, um Erkennungen an die ReportedIP und externe Sammler weiterzuleiten. Mit Version 1.3.0 können dieselben Erkennungen an beliebige HTTP-APIs weitergeleitet werden – beispielsweise an Splunk, Elastic, einen Slack- oder Discord-Kanal oder eine zweite Bedrohungsdatenbank.

Die Übermittlung erfolgt, nachdem die Antwort der Falle bereits an den Angreifer gesendet wurde, sodass das Hinzufügen eines Webhooks den Honeypot niemals verlangsamt. Jeder der 36 integrierten Analysatoren – SQL-Injection, XSS, Path Traversal, Brute-Force und die übrigen – kann einen solchen auslösen. Wenn eine einzelne Anfrage mehrere Analysatoren auslöst, werden die Erkennungen zu einer einzigen Übermittlung zusammengefasst, wobei die Kategorien zusammengeführt und der höchste Schweregrad zugewiesen wird.

Leite Erkennungen an eine beliebige API weiter, nicht nur an ReportedIP

Dies ist die wichtigste Neuerung in Version 1.3.0. Ein Webhook ist nicht mehr an ein festes JSON-Format gebunden. Jeder Endpunkt definiert nun seine eigene Anfrage, sodass er genau das Format verwenden kann, das die Ziel-API erwartet:

• HTTP-Methode — POST, PUT, PATCHoder GET.
• Benutzerdefinierte Header – jeweils einer pro Zeile, für API-Schlüssel und Authentifizierung; sie überschreiben die Standardwerte.
• Seitenformat — strukturiert json, URL-kodiert formoder eine frei gestaltbare benutzerdefinierte Vorlage.
• Platzhalter — {{ip}}, {{categories}}, {{severity}}, {{timestamp}} sowie die übrigen Felder für Anfragen und Erkennung, jeweils mit einem {{..._url}} (URL-kodiert) und {{..._json}} (JSON-escaped) Variante.

Integrierte AbuseIPDB-Zuordnung

Um Daten an eine zweite Datenbank zu übermitteln, musste man früher eine Übersetzungsschicht schreiben, da jeder Dienst seine Bedrohungskategorien unterschiedlich nummeriert. Die Version 1.3.0 enthält eine spezielle {{abuseipdb_categories}} Platzhalter, der ReportedIP (IDs 24–58) ihren nächstgelegenen „AbuseIPDB“-IDs zuordnet. Eine direkte Meldung an die „AbuseIPDB v2“-API wird zu einer einzeiligen Body-Vorlage:

POST https://api.abuseipdb.com/api/v2/report
Header:  Key: <your-abuseipdb-api-key>
Body (form):  ip={{ip}}&categories={{abuseipdb_categories}}&comment={{comment_url}}

Voreinstellungen für AbuseIPDB, Slack, Discordund ein allgemeines JSON Füllen Sie die Methode, die Header und den Text im Zielfeld vorab aus – wählen Sie eine Option aus, geben Sie Ihren Schlüssel oder Ihre URL ein und senden Sie einen Test. Bei Testübermittlungen wird die Loopback-IP verwendet 127.0.0.1Daher führt die Überprüfung eines AbuseIPDB-Webhooks niemals zu einer tatsächlichen Meldung gegen eine aktive Adresse.

So richten Sie einen Webhook ein

Webhooks werden im Admin-Bereich unter Webhooks, gespeichert in einer honeypot_webhooks Tabelle, die die Schemamigration automatisch erweitert. Drei Steuerelemente legen fest, welche Daten die einzelnen Endpunkte erhalten:

• Kategoriefilter – Beschränken die Auslieferung auf bestimmte Bedrohungskategorie-IDs, die den in ReportedIP verwendeten Bedrohungskategorien zugeordnet sind.
• Analysatorfilter — die Zustellung auf bestimmte Erkennungsmodule beschränken, zum Beispiel SqlInjection.
• Geheimer Schlüssel – optional; aktiviert die HMAC-SHA256-Signatur der Nutzlast.

Sind die Filter leer, wird jede Erkennung übermittelt. Sind beide Filter gesetzt, wird der Webhook ausgelöst, sobald einer davon zutrifft. Das Admin-Panel erfasst pro Endpunkt das letzte Ergebnis, den Zeitstempel und einen Zähler für aufeinanderfolgende Fehler, sodass ein defektes Ziel auf einen Blick erkennbar ist.

Die Standard-JSON-Nutzdaten

Wenn Sie das JSON-Body-Format beibehalten, enthält jede Anfrage Content-Type: application/json, ein X-ReportedIP-Event Kopfzeile (detection oder test) und – wenn ein Geheimnis festgelegt ist – ein X-ReportedIP-Signature Kopfzeile. Der Hauptteil fasst den Honeypot, die Anfrage und eine oder mehrere Erkennungen zusammen:

{
  "event": "detection",
  "generated_at": "2026-06-12T14:00:00+00:00",
  "honeypot": {
    "name": "reportedip-honeypot-server",
    "version": "1.3.0",
    "host": "your-honeypot.example.com",
    "profile": "wordpress"
  },
  "request": {
    "ip": "203.0.113.50",
    "method": "POST",
    "uri": "/wp-login.php",
    "user_agent": "sqlmap/1.7"
  },
  "detections": [
    {
      "analyzer": "SqlInjection",
      "categories": [16, 45],
      "category_names": ["SQL Injection", "Code Injection"],
      "comment": "SQL injection attempt detected: ...",
      "severity": 85
    }
  ]
}

Überprüfung der Signatur

Wenn ein Schlüssel konfiguriert wird, handelt es sich bei der Signatur um einen HMAC-SHA256 über den roh Anfragetext, gesendet als sha256=<hmac>. Berechnen Sie denselben Wert auf Ihrer Seite und vergleichen Sie ihn in konstanter Zeit:

$expected = 'sha256=' . hash_hmac('sha256', $rawBody, $secret);
$valid = hash_equals($expected, $_SERVER['HTTP_X_REPORTEDIP_SIGNATURE'] ?? '');

Dies ist dasselbe Muster, das GitHub und Stripe für ihre Webhooks verwenden, sodass bestehender Empfängercode leicht angepasst werden kann. Hash die Rohdaten immer vor der JSON-Analyse, da sonst die Reserialisierung die Signatur verändert.

Warum dies für SOC- und Homelab-Betreiber von Bedeutung ist

Ein Honeypot macht sich nur dann bezahlt, wenn jemand sieht, was er abfängt. Da die Administratoren sich in ein separates Dashboard einloggen mussten, wurden die Erkennungen des Honeypots von allen anderen Sicherheitssignalen getrennt angezeigt. Flexible Webhooks schließen diese Lücke: Angriffe werden im selben Übersichtsfenster wie Ihre Firewall, WAF und Anwendungsprotokolle angezeigt, mit strukturierten Feldern, die Sie korrelieren, als Warnmeldung ausgeben oder an eine Sperrliste weiterleiten können – und nun im selben Schritt auch an eine zweite Reputationsdatenbank.

Das passt auch zu der Art und Weise, wie diese Knoten derzeit betrieben werden. Wenn man eine Serverflotte schützt – also eine Konfiguration, wie sie unter „Sichern eines Serverclusters mit ReportedIP beschrieben wird –, kann ein einzelner Honeypot über einen Webhook Daten an einen zentralen Sammler übermitteln, auf den der Rest des Clusters zugreift.

Versionshinweise: 1.2.0 bis 1.3.0

Alle drei Versionen wurden am 12. Juni 2026 veröffentlicht. Mit Version 1.2.0 wurden Webhooks eingeführt und die Cloudflare-IPv6-Erkennung korrigiert, ein Fehlalarm bei „HeaderAnomaly“ für legitime IPv6-Adressen behoben sowie die Behandlung von dauerhaften API-Ablehnungen in der Berichtswarteschlange optimiert.

1.2.1 wurde als Hotfix veröffentlicht: Ein fehlender Autoloader-Eintrag führte unmittelbar nach dem Update zu einem HTTP-500-Fehler auf der Webhooks-Verwaltungsseite. Mit 1.3.0 wurde die Webhook-Schicht dann zu dem oben beschriebenen flexiblen Router umgestaltet, das AbuseIPDB-Mapping und Voreinstellungen wurden hinzugefügt, mehrere Erkennungen pro Anfrage wurden zusammengeführt und die Testsuite auf 363 Tests erweitert. Wenn Sie eine frühere Version verwenden, aktualisieren Sie direkt auf 1.3.0.

Häufig gestellte Fragen

Kann der Honeypot Meldungen an AbuseIPDB senden?

Ja. Verwenden Sie die Voreinstellung „AbuseIPDB“ oder erstellen Sie einen Webhook mit dem form Körperformat und das {{abuseipdb_categories}} Platzhalter, der ReportedIP den „AbuseIPDB“-IDs zuordnet. Fügen Sie Ihren „AbuseIPDB“-Schlüssel als benutzerdefinierten Header hinzu, und der Honeypot sendet die Daten direkt an den v2-Berichts-Endpunkt.

Verlangsamen Webhooks den Honeypot?

Nein. Die Anfrage wird erst gesendet, nachdem die Trap-Antwort bereits an den Angreifer zurückgesendet wurde; daher wird das, was der Angreifer sieht, niemals durch die Zustellung des Webhooks verzögert.

Woher weiß ich, dass eine Nutzlast tatsächlich von meinem Honeypot stammt?

Legen Sie ein Geheimnis für den Webhook fest. Jede Anfrage enthält dann ein X-ReportedIP-Signature Header, der einen HMAC-SHA256 des Rohtextes enthält. Berechnen Sie diesen mit Ihrem geheimen Schlüssel neu und vergleichen Sie ihn in konstanter Zeit, bevor Sie der Nutzlast vertrauen.

Laden Sie den Honeypot-Server herunter

Der Honeypot-Server ist Open Source (BSL 1.1, Umstellung auf Apache 2.0 im Jahr 2030) und kommt ohne externe Abhängigkeiten aus – PHP 8.2, SQLite, fertig.

• Lies die Dokumentation zum Honeypot-Server – Installation, Konfiguration und die vollständige Webhook-Referenz.
• Die Version 1.3.0 auf GitHub anzeigen – Änderungsprotokoll und Quellcode.
• Erfasste Einträge in eine Sperrliste umwandeln – die Community-Sperrliste in Ihr Edge-System einspeisen.