Veröffentlichungen

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

Juni 12, 2026 · Updated August 6, 2026 · Patrick Schlesinger

Der ReportedIP-Honeypot-Server kann nun jeden erfassten Angriff an die von Ihnen bereits verwendeten 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, führen Sie bitte ein Update auf Version 1.3.0 durch und konfigurieren Sie einen Endpoint im Admin-Panel. Die vollständige Einrichtung ist in der Dokumentation zum Honeypot Server beschrieben.

Was Honeypot Webhooks leisten

Ein Webhook ist ein HTTP(S)-Endpoint, der jedes Mal eine Anfrage empfängt, wenn der Honeypot einen Angriff meldet. Diese Funktion wurde erstmals in Version 1.2.0 eingeführt, um Erkennungen an die ReportedIP-API und externe Sammler weiterzuleiten. Ab 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 Trap-Antwort 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 Benachrichtigung zusammengefasst, wobei die Kategorien zusammengeführt und der höchste Schweregrad zugewiesen wird.

Leiten Sie die Erkennungen an eine beliebige API weiter, nicht nur an ReportedIP

Dies ist die wichtigste Änderung in Version 1.3.0. Ein Webhook ist nicht mehr an ein festes JSON-Format gebunden. Jeder Endpoint 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 Keys und Authentifizierung; diese überschreiben die Standardwerte.
• Textformat – strukturiert json, URL-kodiert formoder eine frei gestaltbare benutzerdefinierte Vorlage.
• Platzhalter — {{ip}}, {{categories}}, {{severity}}, {{timestamp}} sowie die übrigen Abfrage- und Erkennungsfelder, jeweils mit einer {{..._url}} (URL-kodierte) sowie {{..._json}} (JSON-escaped) Variante.

Integrierte AbuseIPDB-Zuordnung

Die Übermittlung an eine zweite Datenbank erforderte bisher das Erstellen einer Übersetzungsschicht, da jeder Dienst seine Threat Categories unterschiedlich nummeriert. Die Version 1.3.0 enthält einen speziellen {{abuseipdb_categories}} Platzhalter mit, der die „ReportedIP“-Kategorien (IDs 24–58) den am besten passenden „AbuseIPDB“-IDs zuordnet. Eine direkte Meldung an die „AbuseIPDB v2“-API lässt sich nun mit einer einzeiligen Body-Vorlage umsetzen:

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, Discord und ein generisches JSON-Ziel füllen die Methode, die Header und den Hauptteil bereits vorab aus – wählen Sie eine 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.1, sodass bei der Überprüfung eines AbuseIPDB-Webhooks niemals eine echte Meldung gegen eine aktive Adresse eingereicht wird.

So richten Sie einen Webhook ein

Webhooks werden im Admin-Bereich unter „Webhooks“ verwaltet und in einer honeypot_webhooks Tabelle gespeichert, die durch die Schemamigration automatisch erweitert wird. Drei Steuerelemente legen fest, welche Daten die einzelnen Endpoints erhalten:

• Kategoriefilter – Beschränken Sie die Übermittlung auf bestimmte Threat Categories-IDs, die den in ReportedIP verwendeten Threat Categories zugeordnet sind.
• Analyzer-Filter – beschränken die Übermittlung beispielsweise auf bestimmte Erkennungsmodule SqlInjection.
• Geheimer Schlüssel – optional; aktiviert die HMAC-SHA256-Signierung der Payload.

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

Die Standard-JSON-Payload

Wenn Sie das JSON-Body-Format beibehalten, enthält jede Anfrage Content-Type: application/jsoneinen X-ReportedIP-Event Header (detection oder test) sowie – sofern ein Geheimnis festgelegt ist – einen X-ReportedIP-Signature Header. Der Body 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 Geheimnis konfiguriert ist, handelt es sich bei der Signatur um einen HMAC-SHA256 über den Rohtext des Anfragetextkörpers, der wie folgt gesendet wird sha256=. 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. Führen Sie vor jeder JSON-Analyse stets einen Hash der Rohdaten durch, da sich andernfalls die Signatur bei der erneuten Serialisierung ändern würde.

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 Betreiber gezwungen waren, sich in ein separates Dashboard einzuloggen, wurden die Erkennungen des Honeypots getrennt von allen anderen Sicherheitssignalen angezeigt. Flexible Webhooks schließen diese Lücke: Angriffe werden im selben Übersichtsfenster wie Ihre Firewall, Ihre WAF und Ihre Anwendungsprotokolle angezeigt – mit strukturierten Feldern, die Sie korrelieren, als Warnmeldung ausgeben oder an eine Blocklist weiterleiten können – und nun im selben Schritt auch an eine zweite Reputationsdatenbank.

Dies passt zudem zu der Art und Weise, wie diese Knoten derzeit betrieben werden. Wenn Sie eine Serverflotte schützen – also eine Konfiguration, wie sie im Artikel „Sichern eines Serverclusters mit ReportedIP“ beschrieben wird –, ermöglicht ein Webhook, dass ein einzelner Honeypot Daten an einen zentralen Sammler übermittelt, aus dem der Rest des Clusters die Informationen abruft.

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, wobei ein falsch-positiver HeaderAnomaly-Befund bei legitimen IPv6-Adressen behoben sowie die Behandlung permanenter API-Ablehnungen in der Berichtswarteschlange optimiert wurde.

1.2.1 wurde als Hotfix nachgereicht: Ein fehlender Autoloader-Eintrag führte unmittelbar nach der Aktualisierung zu einem HTTP-500-Fehler auf der Webhooks-Verwaltungsseite. Mit Version 1.3.0 wurde die Webhook-Ebene dann in den oben beschriebenen flexiblen Router umgestaltet, das AbuseIPDB-Mapping sowie Voreinstellungen hinzugefügt, mehrere Erkennungen pro Anfrage zusammengeführt und die Testsuite auf 363 Tests erweitert. Falls Sie eine frühere Version verwenden, aktualisieren Sie bitte direkt auf 1.3.0.

FAQ

Kann der Honeypot Meldungen an AbuseIPDB übermitteln?

Ja. Verwenden Sie die Voreinstellung „AbuseIPDB“ oder erstellen Sie einen Webhook im form Body-Format und dem {{abuseipdb_categories}} Platzhalter erstellen, der die „ReportedIP“-Kategorien 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-Endpoint.

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.

Woran erkenne ich, dass eine Payload tatsächlich von meinem Honeypot stammt?

Legen Sie für den Webhook ein Geheimnis fest. Jede Anfrage enthält dann einen X-ReportedIP-Signature Header, der einen HMAC-SHA256-Hash des Rohtextes enthält. Berechnen Sie diesen mit Ihrem geheimen Schlüssel neu und vergleichen Sie ihn in konstanter Zeit, bevor Sie der Payload 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, das war’s.

• Lesen Sie die Docs zum Honeypot Server – Installation, Konfiguration und die vollständige Webhook-Referenz.
• Sehen Sie sich die Version 1.3.0 auf GitHub an – Changelog und Quellcode.
• Wandeln Sie Erkennungsergebnisse in eine Blocklist um – speisen Sie die Community Blacklist in Ihren Edge-Server ein.