Quatre ans avec un honeypot SIP exposé sur Internet
Un serveur SIP public finit presque toujours par être découvert dès qu’il reste exposé sur Internet. Même avec des mots de passe corrects et des protections de type blocage automatique après trop d’échecs, ce n’est souvent qu’une question de temps avant que des scanners essaient des couples utilisateur/mot de passe, des extensions courantes ou des destinations internationales. Et quand un vrai PBX laisse passer des appels hors forfait ou vers l’international, l’addition peut vite devenir salée.
J’ai installé ce honeypot SIP comme une expérimentation personnelle, surtout par curiosité. Je voulais voir ce qui arriverait spontanément sur un service SIP exposé sur Internet. Après plusieurs années de fonctionnement, avant de réinstaller proprement le serveur, j’ai analysé les statistiques accumulées.
Les chiffres présentés ici proviennent d’une instance observée du 30 novembre 2021 au 9 septembre 2026. Les adresses IP et les identifiants SIP sont anonymisés ou agrégés. Le serveur ne relaie aucun appel et ne fournit aucun compte utilisable.
Pourquoi SIP attire autant de bruit
SIP, pour Session Initiation Protocol, sert à établir des sessions multimédias, le plus souvent des appels VoIP. Un serveur SIP exposé peut donc intéresser plusieurs types d’acteurs :
- ceux qui cherchent simplement à vérifier qu’un équipement répond ;
- ceux qui inventorient les services accessibles depuis Internet ;
- ceux qui testent des comptes ou des extensions ;
- ceux qui essaient de déclencher des appels sortants frauduleux.
Sur un vrai PBX, une requête REGISTER peut être parfaitement normale : elle permet à un téléphone ou à un softphone de s’enregistrer. Sur ce honeypot, aucune extension n’existe. Une rafale de REGISTER devient donc surtout un signal d’énumération ou de bruteforce.
Même logique pour INVITE : sur une infrastructure légitime, cette méthode initie un appel. Ici, elle ressemble plutôt à un test de routage : est-ce que ce serveur accepte d’appeler tel numéro ? est-ce qu’un préfixe international passe ? est-ce qu’une variante de présentation change la réponse ?
L’architecture de collecte
L’instance tient sur un VPS Debian hébergé chez OVHcloud. Kamailio reçoit les paquets SIP et extrait quelques attributs : adresse source, méthode SIP, User-Agent, identifiant appelant et numéro appelé. Une route dédiée calcule ensuite une empreinte MD5 de cette combinaison et écrit le résultat dans MariaDB.
La clé de déduplication correspond à cette combinaison :
IP source + méthode + User-Agent + From user + To user
Une nouvelle combinaison crée une ligne. Si la même combinaison revient, le honeypot incrémente hits et met à jour last_seen. Ce choix réduit fortement le stockage par rapport à une conservation de chaque paquet brut, tout en permettant de suivre la répétition d’un comportement.
Le modèle principal contient notamment :
| Champ | Rôle |
|---|---|
methode | Méthode SIP observée : REGISTER, INVITE, OPTIONS, etc. |
ip_address | Adresse source stockée sous forme numérique |
ua | En-tête User-Agent déclaré par le client |
from_uri_username | Identifiant appelant |
to_uri_username | Identifiant ou numéro ciblé |
hits | Nombre de répétitions de la même signature |
first_seen, last_seen | Première et dernière observation de cette signature |
hash | Empreinte unique de la signature |
Cette collecte ne voit pas tout ce qui a touché le serveur. Des protections réseau peuvent intervenir en amont, et Kamailio écarte les paquets qui ne ressemblent pas à du SIP exploitable. Les chiffres ci-dessous décrivent donc les requêtes reçues, reconnues et parsées, pas l’intégralité du bruit arrivé sur le port.
Ce que contient la base
Dans l’instantané analysé, la base contient :
- 48 721 111 requêtes reconnues comme SIP ;
- 12 634 617 signatures distinctes ;
- 57 970 adresses IP distinctes ;
- une plage d’observation allant du 30 novembre 2021 au 9 septembre 2026 ;
- environ 1,59 Go de données.
Une signature n’est pas nécessairement une requête : la colonne hits agrège les répétitions. En moyenne, une signature a donc été observée 3,86 fois.
Deux méthodes concentrent presque tout le trafic : REGISTER et INVITE.
| Méthode | Signatures | Requêtes | Part des requêtes |
|---|---|---|---|
| REGISTER | 5 771 958 | 33 392 795 | 68,54 % |
| INVITE | 6 353 732 | 14 506 866 | 29,78 % |
| ACK | 432 021 | 641 530 | 1,32 % |
| CANCEL | 60 408 | 95 907 | 0,20 % |
| OPTIONS | 12 920 | 76 443 | 0,16 % |
| BYE | 2 121 | 4 939 | 0,01 % |
| Autres | 1 457 | 2 631 | < 0,01 % |
REGISTER et INVITE représentent ensemble 98,31 % des requêtes observées. Ce n’est pas très surprenant : ce sont les deux gestes les plus intéressants pour un attaquant qui cherche soit un compte utilisable, soit une route d’appel exploitable.
Les méthodes SIP en pratique
REGISTER sert normalement à associer un utilisateur à un terminal. Sur ce honeypot sans compte, il indique généralement une phase de reconnaissance ou une tentative d’authentification. Avec 33 392 795 requêtes regroupées dans 5 771 958 signatures, il montre beaucoup de répétitions. Ce rapport entre signatures et hits est compatible avec des acteurs qui réessaient les mêmes combinaisons.
INVITE initie une session SIP, le plus souvent un appel. Les 14 506 866 requêtes INVITE observées évoquent l’exploration de routes téléphoniques : numéros internationaux, préfixes alternatifs et variations autour d’un même destinataire.
Les méthodes minoritaires apportent aussi du contexte. OPTIONS sert souvent à vérifier qu’un endpoint répond. ACK fait normalement partie du dialogue créé par un INVITE. MESSAGE transporte de la messagerie instantanée SIP. REFER demande à un endpoint d’initier une autre session et mérite une attention particulière lorsqu’il arrive d’Internet.
La longue traîne contient enfin des méthodes valides, des fautes comme INVATE ou ivite, et même des verbes étrangers à SIP comme HELLO, PING, TRACE ou SYNC. Ces anomalies sont utiles : elles trahissent des outils génériques, des parseurs approximatifs ou du trafic envoyé au mauvais protocole.
Ce que cette première photographie raconte
Cette base ne mesure pas “les attaques SIP sur Internet”. Elle mesure ce qui a atteint une adresse IP, un port, un transport et un comportement de réponse précis pendant un peu plus de quatre ans et demi.
Malgré cette limite, les ordres de grandeur sont parlants. Un simple serveur SIP, sans compte utilisable et sans capacité de relayer des appels, a tout de même reçu plus de 48 millions de requêtes exploitables. La majorité du trafic se concentre sur l’enregistrement de comptes et les tentatives d’appel, c’est-à-dire les deux surfaces les plus directement monétisables dans un contexte VoIP.
La suite de l’analyse consiste à regarder qui génère ce trafic : combien d’IP reviennent souvent, combien disparaissent aussitôt, ce que disent les User-Agents, et ce qu’on peut reconnaître dans les signatures de scan. C’est l’objet du deuxième article : Ce que les scanners SIP racontent d’eux-mêmes.
Notes méthodologiques
- Source principale : table MariaDB
honeypot.requests. - Comptage exact : 12 634 617 signatures, 48 721 111 requêtes agrégées et 57 970 IP distinctes.
- Première et dernière observations de l’instantané : 30 novembre 2021 et 9 septembre 2026.
- Les adresses IP et identifiants SIP ne sont pas publiés dans cet article.