Communiqués

Webhooks Honeypot : envoyez les détections d'attaques vers n'importe quelle API

12 juin 2026 · Patrick Schlesinger

Le serveur ReportedIP peut désormais transmettre chaque attaque détectée vers les outils que vous utilisez déjà. La version 1.3.0 transforme ses webhooks en un routeur configurable : choisissez la méthode HTTP, les en-têtes et le corps du message, puis envoyez les détections directement vers votre SIEM, Slack, Discord ou AbuseIPDB.

Si vous exploitez déjà un nœud honeypot, effectuez la mise à jour vers la version 1.3.0 et configurez un point de terminaison dans le panneau d'administration. La procédure complète est décrite dans la documentation du serveur honeypot.

À quoi servent les webhooks Honeypot ?

Un webhook est un point de terminaison HTTP(S) qui reçoit une requête chaque fois que le honeypot signale une attaque. Cette fonctionnalité a été introduite pour la première fois dans la version 1.2.0 afin de transmettre les détections à l'API ReportedIP et à des collecteurs externes. Avec la version 1.3.0, ces mêmes détections peuvent être transmises à n'importe quelle API HTTP : Splunk, Elastic, un canal Slack ou Discord, ou encore une deuxième base de données sur les menaces.

La transmission des résultats intervient après l'envoi de la réponse du piège à l'attaquant ; l'ajout d'un webhook ne ralentit donc jamais le honeypot. Chacun des 36 analyseurs intégrés (injection SQL, XSS, traversée de chemin, force brute, etc.) peut en déclencher un. Lorsqu'une seule requête active plusieurs analyseurs, les détections sont regroupées en une seule transmission, avec des catégories fusionnées et le niveau de gravité le plus élevé.

Redirigez les détections vers n'importe quelle API, et pas seulement vers ReportedIP

Voici la principale nouveauté de la version 1.3.0. Un webhook n'est désormais plus contraint à un format JSON fixe. Chaque point de terminaison définit désormais sa propre requête, ce qui lui permet de s'adapter au format attendu par l'API cible :

• Méthode HTTP — POST, PUT, PATCH, ou GET.
• En-têtes personnalisés — un par ligne, pour les clés API et l'authentification ; ils remplacent les valeurs par défaut.
• Format du corps — structuré json, encodé en URL form, ou un modèle personnalisé de forme libre.
• Espaces réservés — {{ip}}, {{categories}}, {{severity}}, {{timestamp}} et les autres champs de requête et de détection, chacun comportant un {{..._url}} (codé en URL) et {{..._json}} (version au format JSON).

Mappage AbuseIPDB intégré

Auparavant, pour communiquer avec une deuxième base de données, il fallait créer une couche de traduction, car chaque service numérote ses catégories de menaces différemment. La version 1.3.0 intègre un module dédié {{abuseipdb_categories}} marqueur de position qui associe ReportedIP (ID 24 à 58) à leurs ID AbuseIPDB correspondants. Un rapport direct à l'API AbuseIPDB v2 se résume alors à un modèle de corps d'une seule ligne :

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

Préréglages pour AbuseIPDB, Slack, Discord, et un JSON générique Préparez la méthode, les en-têtes et le corps — choisissez l'un d'entre eux, insérez votre clé ou votre URL, puis envoyez un test. Les tests d'envoi utilisent l'adresse IP de bouclage 127.0.0.1, de sorte que la vérification d'un webhook AbuseIPDB n'entraîne jamais l'envoi d'un véritable signalement concernant une adresse active.

Comment configurer un webhook

Les webhooks sont gérés dans le panneau d'administration sous Webhooks, stocké dans un honeypot_webhooks table que la migration de schéma étend automatiquement. Trois contrôles déterminent ce que reçoit chaque point de terminaison :

• Filtres par catégorie — limitent la diffusion aux identifiants de catégories de menaces spécifiques, mis en correspondance avec les mêmes catégories de menaces utilisées sur ReportedIP.
• Filtres d'analyseur — limiter la diffusion à certains moteurs de détection, par exemple SqlInjection.
• Clé secrète — facultative ; active la signature HMAC-SHA256 de la charge utile.

Si les filtres sont vides, toutes les détections sont transmises. Lorsque les deux filtres sont activés, le webhook se déclenche dès qu'un des deux est satisfait. Le panneau d'administration enregistre le dernier résultat, l'horodatage et un compteur d'échecs consécutifs pour chaque point de terminaison, ce qui permet de repérer d'un seul coup d'œil toute cible défaillante.

La charge utile JSON par défaut

Si vous conservez le format JSON pour le corps de la requête, chaque requête contient Content-Type: application/json, un X-ReportedIP-Event en-tête (detection ou test), et — lorsqu'un secret est défini — un X-ReportedIP-Signature En-tête. Le corps regroupe le honeypot, la requête et une ou plusieurs détections :

{
  "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
    }
  ]
}

Vérification de la signature

Lorsqu'un secret est configuré, la signature est un HMAC-SHA256 sur le brut corps de la requête, envoyé sous la forme sha256=<hmac>. Calculez la même valeur de votre côté et comparez-la en temps constant :

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

C'est le même modèle que GitHub et Stripe utilisent pour leurs webhooks, ce qui facilite l'adaptation du code des récepteurs existants. Veillez à toujours hacher les octets bruts avant toute analyse JSON, sinon la resérialisation modifiera la signature.

Pourquoi cela est-il important pour les opérateurs de SOC et de laboratoires privés ?

Un honeypot ne vaut la peine que si l'on examine ce qu'il détecte. En obligeant les opérateurs à se connecter à un tableau de bord distinct, les détections du honeypot étaient isolées de tous les autres signaux de sécurité. Les webhooks flexibles comblent cette lacune : les attaques apparaissent dans le même interface que votre pare-feu, votre WAF et les journaux d'application, avec des champs structurés que vous pouvez corréler, utiliser pour déclencher des alertes ou transférer vers une liste de blocage — et désormais vers une deuxième base de données de réputation en une seule étape.

Cela correspond également à la manière dont ces nœuds sont déjà gérés. Si vous protégez un parc de serveurs — le type de configuration décrit dans la section consacrée à la sécurisation d'un cluster de serveurs avec ReportedIP —, un webhook permet à un seul honeypot d'alimenter un collecteur central auquel le reste du cluster a accès.

Notes de mise à jour : de la version 1.2.0 à la version 1.3.0

Ces trois versions ont été publiées le 12 juin 2026. La version 1.2.0 a introduit les webhooks et corrigé la détection IPv6 de Cloudflare, un faux positif de HeaderAnomaly sur des adresses IPv6 légitimes, ainsi que la gestion de la file d'attente des rapports en cas de rejets permanents de l'API.

La version 1.2.1 a été publiée sous forme de correctif : une entrée manquante dans le chargeur automatique provoquait une erreur HTTP 500 sur la page d'administration des webhooks immédiatement après la mise à jour. La version 1.3.0 a ensuite réorganisé la couche webhook pour intégrer le routeur flexible décrit ci-dessus, ajouté le mappage et les préréglages AbuseIPDB, regroupé plusieurs détections par requête et étendu la suite de tests à 363 tests. Si vous utilisez une version antérieure, passez directement à la version 1.3.0.

Foire aux questions

Le honeypot peut-il envoyer des rapports à AbuseIPDB ?

Oui. Utilisez le préréglage AbuseIPDB ou créez un webhook avec le form format du corps et le {{abuseipdb_categories}} placeholder, qui met en correspondance ReportedIP avec les identifiants AbuseIPDB. Ajoutez votre clé AbuseIPDB en tant qu'en-tête personnalisé et le honeypot enverra directement les données au point de terminaison de rapport v2.

Les webhooks ralentissent-ils le honeypot ?

Non. La requête est envoyée après que la réponse du piège a déjà été renvoyée à l'attaquant ; par conséquent, ce que voit l'attaquant n'est jamais retardé par la transmission du webhook.

Comment puis-je savoir si une charge utile provient bien de mon honeypot ?

Définissez une clé secrète pour le webhook. Chaque requête transmettra alors un X-ReportedIP-Signature en-tête contenant un HMAC-SHA256 du corps brut. Recalculez-le à l'aide de votre clé secrète et comparez-le en temps constant avant de faire confiance à la charge utile.

Téléchargez le serveur honeypot

Le serveur honeypot est open source (licence BSL 1.1, qui passera sous licence Apache 2.0 en 2030) et ne nécessite aucune dépendance externe : PHP 8.2, SQLite, c'est tout.

• Consultez la documentation du serveur honeypot: installation, configuration et référence complète des webhooks.
• Consultez la version 1.3.0 sur GitHub — journal des modifications et code source.
• Transformez les détections en liste noire — intégrez la liste noire de la communauté à votre périphérie.