Comparer un honeypot SIP avec APIBAN
Après avoir exploré plus de quatre années de trafic SIP, j’ai confronté les sources observées par mon honeypot avec la liste active d’APIBAN. Le recouvrement historique est faible, mais il augmente fortement lorsqu’on se rapproche de la fin de la collecte.
APIBAN est un service de liste de blocage spécialisé dans le trafic SIP. Il collecte des adresses vues comme indésirables par des honeypots distribués, puis expose ces IP pour aider des serveurs VoIP à les bloquer avant qu’elles ne génèrent du scan, de l’énumération ou des tentatives d’appel. Sa documentation indique qu’une adresse reste active pendant sept jours, puis doit être observée de nouveau pour être réactivée.
Dans les trois premiers articles, j’ai présenté l’expérience, puis les comportements observés : bruteforce REGISTER, tentatives INVITE, User-Agents trompeurs, sources longues durées, identifiants SIP et signatures Nmap. Pour cette comparaison, j’utilise un export actualisé de 57 970 adresses IP distinctes, dont la dernière observation date du 9 septembre 2026.
Recouvrement par temps et par type de trafic
La photographie APIBAN téléchargée le 9 septembre 2026 contenait 1 952 adresses IPv4 actives dans le jeu SIP utilisé pour cette comparaison. J’ai comparé cette liste avec trois fenêtres du honeypot, puis avec deux sous-ensembles : les sources REGISTER et les sources du couple nm -> nm2, toutes méthodes confondues. Ce dernier ensemble inclut principalement des OPTIONS, ainsi que quelques INVITES et un REGISTER.
| Type de source | Historique complet | 30 derniers jours | 7 derniers jours |
|---|---|---|---|
| Toutes méthodes | 1,10 % 636/57 970 | 26,05 % 192/737 | 56,22 % 113/201 |
REGISTER | 0,12 % 54/46 347 | 28,47 % 39/137 | 75,00 % 27/36 |
Sur les sept derniers jours, APIBAN retrouve 56,22 % des sources toutes méthodes confondues et 75,00 % des sources REGISTER. Les fenêtres diffèrent : 737 IP sur 30 jours contre 201 sur 7 jours, dont respectivement 137 et 36 sources REGISTER.
L’autre sens donne un repère complémentaire : parmi les 1 952 IP actives dans APIBAN ce jour-là, 636 avaient déjà été vues par mon honeypot, soit 32,58 % de la liste. Cela ne veut pas dire que mon capteur aurait dû voir le reste : les honeypots ne partagent ni la même adresse, ni la même région, ni exactement le même comportement SIP.
Les IP observées pendant plus de quatre ans
L’export local recense 39 IP dont la première et la dernière observation sont séparées de plus de quatre ans. Parmi elles, 4 figurent dans la photographie APIBAN, soit 10,26 %.
Ce résultat montre qu’une petite partie de ces adresses longues durées figure encore dans la liste active APIBAN au moment de la comparaison. Il ne prouve cependant pas que la même machine ou le même acteur les a utilisées pendant quatre ans.
Une rotation est plausible à deux niveaux :
- les scanners peuvent répartir leurs campagnes entre de nombreuses adresses et faire évoluer leur infrastructure ;
- les opérateurs peuvent réattribuer une même IP publique à différents abonnés ou serveurs au fil du temps.
À l’inverse, certaines adresses peuvent appartenir longtemps à un hébergeur, un service de mesure ou une infrastructure disposant d’IP fixes. Dans cette base, les IP ayant les durées les plus longues ont surtout envoyé quelques requêtes OPTIONS très espacées. Cela ressemble davantage à une sonde périodique ou à la réutilisation d’un même fingerprint qu’à quatre années de bruteforce continu.
Ce que je retiens
Comparer tout l’historique à une liste active donne seulement 1,10 % de recouvrement et raconte peu de choses. En revanche, le taux atteint 56,22 % sur les sept derniers jours, et 75,00 % pour les sources REGISTER de cette même période.
La comparaison montre donc deux choses : les capteurs indépendants recoupent bien une partie des mêmes sources, et la synchronisation temporelle est essentielle pour mesurer correctement ce recouvrement.
Dans cet instantané, le recouvrement atteint 56,22 % des sources récentes et 75,00 % des sources REGISTER. APIBAN apporte un signal complémentaire pour filtrer une partie du bruit SIP, mais ces proportions ne mesurent ni la part de requêtes bloquées ni la présence de chaque IP dans la liste au moment exact où elle a contacté le honeypot.
Les données enregistrées ne sont pas parfaites. Elles ont été collectées avec un objectif assez simple au départ, puis explorées après coup, avec les limites que cela implique : agrégation par signature, fenêtres temporelles imparfaites, et comparaison APIBAN décidée seulement à la fin. Malgré ça, c’était vraiment intéressant de fouiller cette base et de voir émerger des comportements cohérents.
Si une V2 du honeypot voit le jour, l’objectif sera de conserver davantage de contexte utile, et de mesurer le délai d’apparition d’une IP dans la liste, sa durée de présence et la part exacte du trafic déjà connue au moment où elle atteint le serveur.
Notes méthodologiques
- Jeu APIBAN utilisé :
sip, 1 952 IPv4 actives. - Export local du honeypot : 57 970 IP distinctes.
- Les fenêtres de 30 et 7 jours sont calculées à partir de la dernière observation disponible.
- Pour
REGISTER, le filtre utilise la dernière observation de cette méthode. - Les compteurs
hitsétant agrégés sur toute la vie d’une signature, les fenêtres comparent des ensembles d’IP, pas un nombre exact de requêtes reçues pendant ces seules périodes. - Aucune adresse IP brute n’est publiée dans l’article.