Honeypot-Webhooks: Angriffserkennungen an jede beliebige API senden
Version 1.3.0 des ReportedIP Honeypot Server, erschienen am 12. Juni 2026, macht aus den Webhooks einen konfigurierbaren Router, der jede erkannte Attacke an eine beliebige HTTP-API schickt. Jeder Endpunkt legt Methode, Header und Body selbst fest, damit landen Erkennungen ohne zusätzlichen Code in einem SIEM, in Slack, Discord oder bei AbuseIPDB.
Aktuell ist Version 1.4.1 vom 15. September 2026, und alles hier Beschriebene funktioniert dort unverändert. Installation und die vollständige Feldliste finden Sie in der Honeypot-Server-Dokumentation.
Was leisten Honeypot-Webhooks?
Ein Webhook ist ein HTTP- oder HTTPS-Endpunkt, der eine Anfrage erhält, sobald der Honeypot einen Angriff erkennt, der zu den Filtern des Webhooks passt. Die Funktion kam mit Version 1.2.0 und einem festen JSON-Format für Logging- und SIEM-Systeme. Version 1.3.0 öffnete sie für jede API: Splunk, Elastic, einen Slack- oder Discord-Kanal oder eine zweite Abuse-Datenbank.
Der Honeypot verschickt Webhooks erst, nachdem die Antwort der Falle beim Angreifer angekommen ist. Ein langsamer oder defekter Endpunkt verzögert also nie, was der Angreifer sieht. Zum Start von 1.3.0 liefen in der Erkennung 36 Analyzer, von SQL-Injection und Cross-Site-Scripting bis zu Path Traversal und Brute Force. Seit Version 1.3.10 sind es 40, und jeder davon kann einen Webhook auslösen.
Wie schicken Sie Honeypot-Erkennungen an eine beliebige API?
Bis Version 1.2.1 war jede Zustellung ein JSON-POST. Seit 1.3.0 legt jeder Webhook seine Anfrage selbst fest:
- HTTP-Methode:
POST,PUT,PATCHoderGET. Eine GET-Anfrage hat keinen Body, die Daten stehen dann in der URL. - Eigene Header: einer pro Zeile, für API-Schlüssel und Authentifizierung. Sie überschreiben die Standard-Header.
- Body-Format: strukturiertes
json, URL-kodiertesformoder ein freiescustom-Template. - Platzhalter: 13 Felder wie
{{ip}},{{categories}},{{severity}}und{{timestamp}}, nutzbar im Body und in der URL. Jedes Feld gibt es zusätzlich als{{..._url}}(URL-kodiert) und{{..._json}}(JSON-maskiert).
Schlägt eine Anfrage bei mehreren Analyzern an, erhält jeder Webhook trotzdem nur eine Zustellung. Die Platzhalter-Felder führen die Kategorien zusammen, übernehmen den höchsten Schweregrad und verbinden die Kommentare. Das JSON-Format listet jede Erkennung einzeln auf.
Die Zuordnung für AbuseIPDB ist eingebaut
Jede Threat-Datenbank nummeriert ihre Kategorien anders, deshalb brauchte ein zweiter Report bisher eigenen Übersetzungscode. Der Platzhalter {{abuseipdb_categories}} übernimmt diese Zuordnung: Die IDs 1 bis 23 sind auf beiden Plattformen identisch, ReportedIP-Kategorien ab 24 werden auf das nächstliegende AbuseIPDB-Gegenstück übersetzt. In 1.3.0 deckte die Zuordnung die IDs 24 bis 58 ab. Seit Version 1.3.7 umfasst sie auch die Honeypot-Kategorien 59 bis 63. Ein Report an den AbuseIPDB-Report-Endpunkt sieht so aus:
POST https://api.abuseipdb.com/api/v2/report
Key: <your-abuseipdb-api-key>
Accept: application/json
ip={{ip_url}}&categories={{abuseipdb_categories}}&comment={{comment_url}}Vier Vorlagen füllen die Anfrage aus
Das Webhook-Formular bietet vier Schnellvorlagen (Quick Presets). Jede füllt URL, Methode, Header und Body-Template aus. Danach tragen Sie Ihren eigenen API-Schlüssel oder Ihre Webhook-URL ein.
| Vorlage | Methode | Body-Format |
|---|---|---|
| Generic JSON | POST | json |
| AbuseIPDB | POST | custom |
| Slack | POST | custom |
| Discord | POST | custom |
Der Test-Button schickt eine Zustellung mit der Loopback-Adresse 127.0.0.1. Abuse-Datenbanken lehnen diese Adresse ab, ein Test des AbuseIPDB-Webhooks erzeugt also nie einen Report gegen einen echten Host.
Wie richten Sie einen Webhook ein?
Webhooks verwalten Sie im Admin-Panel des Honeypots unter Webhooks. Das Update auf 1.3.0 erweitert die gespeicherten Webhook-Einstellungen selbst, eine manuelle Migration ist nicht nötig. Drei Einstellungen bestimmen, was ein Endpunkt erhält:
- Kategorie-Filter: IDs aus der Liste der Bedrohungskategorien, die überall bei ReportedIP gilt.
- Analyzer-Filter: Namen einzelner Erkennungsmodule, zum Beispiel
SqlInjection. - Secret: optional. Es versieht jede Anfrage mit einer HMAC-SHA256-Signatur.
Sind beide Filter leer, wird jede Erkennung zugestellt. Sind beide gesetzt, löst eine Erkennung den Webhook aus, sobald sie zu einem der beiden passt. Das Panel zeigt für jeden Endpunkt den letzten Status, dessen Zeitpunkt und die Zahl der Fehlschläge in Folge, eine erfolgreiche Zustellung setzt diese Zahl zurück. Die Webhook-Referenz beschreibt jedes Feld.
Wie sieht das Standard-JSON-Payload aus?
Im Format json trägt jede Anfrage Content-Type: application/json, einen Header X-ReportedIP-Event mit dem Wert detection oder test und, wenn ein Secret gesetzt ist, einen Header X-ReportedIP-Signature. Der Body gliedert sich in Honeypot, Anfrage und eine oder mehrere Erkennungen:
{
"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", "WP Database Injection"],
"comment": "SQL injection attempt detected: ...",
"severity": 85
}
]
}Die Signatur auf der Empfängerseite prüfen
Die Signatur ist ein HMAC-SHA256 über den unveränderten Request-Body mit Ihrem Secret als Schlüssel (RFC 2104) und kommt als sha256=<hex> an. Berechnen Sie denselben Wert auf Ihrer Seite und vergleichen Sie beide in konstanter Zeit:
$expected = 'sha256=' . hash_hmac('sha256', $rawBody, $secret);
$valid = hash_equals($expected, $_SERVER['HTTP_X_REPORTEDIP_SIGNATURE'] ?? '');Hashen Sie die Rohdaten vor jedem JSON-Parsing. Ein geparster und neu kodierter Body kann sich in Leerzeichen oder Schlüsselreihenfolge unterscheiden, dann passt die Signatur nicht mehr. GitHub signiert seine Webhooks im selben Format sha256=, vorhandener Empfängercode braucht also nur einen anderen Header-Namen.
Warum Honeypot-Erkennungen an ein SIEM schicken?
Ein Honeypot nützt nur, wenn jemand sieht, was er fängt. Ohne Webhooks lagen seine Erkennungen in einem eigenen Admin-Panel, getrennt von allen anderen Sicherheitssignalen. Mit Webhooks landen sie neben Firewall-, WAF- und Anwendungslogs als strukturierte Felder, die Sie korrelieren, für Alarme nutzen oder in eine Sperrliste übernehmen können. Dieselbe Erkennung kann gleichzeitig an ReportedIP und an AbuseIPDB gehen.
Webhooks passen auch zu Server-Flotten. Betreiben Sie mehrere Server, wie in der Anleitung zum Absichern eines Server-Clusters beschrieben, kann ein einzelner Honeypot einen zentralen Collector beliefern, aus dem der Rest des Clusters liest.
Was hat sich in den Versionen 1.2.0 bis 1.3.0 geändert?
Die Versionen 1.2.0, 1.2.1 und 1.3.0 erschienen alle am 12. Juni 2026. 1.2.0 führte die Webhooks ein und behob drei Probleme: In der Client-IP-Erkennung fehlten die IPv6-Bereiche von Cloudflare, der Header-Analyzer hielt legitime IPv6-Adressen für Loopback, und Reports, die die API endgültig abgelehnt hatte, blockierten die Report-Warteschlange.
1.2.1 war ein Hotfix für einen HTTP-500-Fehler auf der Webhooks-Seite direkt nach dem Update, verursacht durch einen veralteten Autoloader. 1.3.0 baute die Zustellung zum oben beschriebenen Router um, ergänzte die AbuseIPDB-Zuordnung und die Vorlagen, fasste mehrere Erkennungen pro Anfrage zusammen und brachte die Testsuite auf 363 Tests.
Seitdem hat 1.3.1 noch am selben Tag Hilfetext und Vorlagen auf der Webhooks-Seite korrigiert, 1.3.3 die Honeypot-Kategorien 59 bis 63 ergänzt und 1.3.7 die AbuseIPDB-Zuordnung an die korrigierten Kategorienamen angepasst. Wenn Sie noch eine ältere Version betreiben, aktualisieren Sie direkt auf 1.4.1.
Häufige Fragen zu Honeypot-Webhooks
Kann der Honeypot an AbuseIPDB melden?
Der Honeypot meldet über seine eingebaute Vorlage an AbuseIPDB. Die Vorlage setzt den Report-Endpunkt, ein eigenes Body-Template und den Platzhalter {{abuseipdb_categories}}, der ReportedIP-Kategorien in AbuseIPDB-IDs übersetzt. Tragen Sie Ihren eigenen AbuseIPDB-API-Schlüssel in den Key-Header ein, senden Sie einen Test, und jede passende Erkennung geht an beide Datenbanken.
Machen Webhooks den Honeypot langsamer?
Die Zustellung verzögert nie die Antwort, die ein Angreifer sieht, weil der Honeypot Webhooks erst nach der Antwort der Falle verschickt. Ein langsamer Endpunkt kann die Falle deshalb nicht über das Zeitverhalten verraten. Eine fehlgeschlagene Zustellung erhöht nur den Fehlerzähler im Admin-Panel, Erkennung und Meldung an ReportedIP laufen wie gewohnt weiter.
Woran erkenne ich, dass ein Payload von meinem Honeypot stammt?
Ein Secret am Webhook belegt die Herkunft einer Anfrage. Ist ein Secret gesetzt, trägt jede Anfrage einen Header X-ReportedIP-Signature mit einem HMAC-SHA256 über den unveränderten Body. Ihr Empfänger berechnet denselben Wert mit demselben Secret und vergleicht beide in konstanter Zeit. Eine Anfrage ohne passende Signatur verwerfen Sie.
Den Honeypot Server holen
Der Quellcode des Honeypot Server ist offen einsehbar (Source-Available) unter der Business Source License 1.1 und wechselt am 1. März 2030 zu Apache 2.0. Sie dürfen ihn produktiv für Ihre eigene Infrastruktur betreiben, ihn aber nicht als gehosteten Dienst für andere anbieten. Er braucht PHP 8.2 mit SQLite und cURL und keine externen Pakete.
- Honeypot-Server-Dokumentation: Installation, Konfiguration und die Webhook-Referenz.
- ReportedIP-Produkte: das Hive-Plugin, die API, der Blacklist-Feed und die kostenlosen Tools, darunter der Honeypot.
- Community-Blacklist: gemeldete Angreifer als Sperrliste für Ihre Firewall nutzen.