Prévention des attaques DoS SIP : comment un SBC stoppe les attaques par inondation avant qu’elles n’atteignent votre réseau voix

Dans le monde de la voix, il n’existe pas de panne silencieuse. Lorsqu’un réseau tombe, tout le monde le sait immédiatement. Il n’y a ni dégradation progressive ni cache de secours sur lequel s’appuyer : les appels échouent tout simplement. Les clients n’entendent que le silence ou une tonalité d’occupation rapide, les centres d’appels s’éteignent et les revenus s’arrêtent immédiatement. Cette visibilité totale est précisément la raison pour laquelle les infrastructures SIP constituent une cible de choix pour les attaques DoS. Les attaquants savent qu’inonder une plateforme voix provoque une crise immédiate et mesurable, et ils comptent sur le fait que vous serez bien plus concentré à restaurer le service qu’à remonter à la source.

L’ampleur de la menace s’accélère clairement ; Cloudflare a rapporté avoir bloqué 20,5 millions d’attaques DDoS au premier trimestre 2025 seulement, soit une augmentation vertigineuse de 358 % d’une année sur l’autre. Les infrastructures VoIP restent en plein dans la ligne de mire, car les attaques par inondation SIP sont conçues pour exploiter les mécanismes fondamentaux du protocole. Chaque INVITE oblige un serveur à allouer des ressources pour un dialogue, chaque REGISTER déclenche une recherche d’identifiants et les messages malformés mettent constamment à l’épreuve la résilience de l’analyseur syntaxique. Le cœur du problème est qu’un pare-feu réseau standard considère généralement tout cela comme du trafic UDP générique sur un seul port, sans aucun moyen réel de distinguer un établissement d’appel légitime d’une attaque malveillante.

Un contrôleur de session en bordure (SBC) est le seul élément réseau conçu spécifiquement pour inspecter, limiter le débit et bloquer le trafic SIP au niveau de la couche applicative. Ce guide couvre chaque grand type d’attaque par inondation SIP, explique comment un SBC détecte et atténue chacun d’entre eux, et fournit des recommandations d’architecture de déploiement pour construire des réseaux voix résilients face aux DoS.

Pourquoi les infrastructures SIP sont particulièrement vulnérables

Comprendre pourquoi le protocole SIP est une cible DoS aussi efficace nécessite d’examiner sa conception. SIP a été conçu pour la fiabilité et l’interopérabilité dans des réseaux de confiance, pas pour des environnements hostiles.

SIP est un protocole textuel et à état. Chaque appel commence par une transaction INVITE qui crée un dialogue, et le serveur doit suivre l’état de ce dialogue à travers l’établissement, la sonnerie, la réponse et la libération. Ce caractère à état signifie que chaque message entrant consomme des ressources serveur : des cycles CPU pour l’analyse, de la mémoire pour l’état de dialogue, et des recherches en base de données pour le routage et l’authentification. Contrairement aux requêtes web sans état qui peuvent être absorbées par un CDN ou un répartiteur de charge, l’état d’appel SIP est en temps réel et sensible à la latence. Même quelques secondes de délai de traitement se traduisent par des appels échoués et des enregistrements perdus.

SIP fonctionne généralement sur UDP. Sans la poignée de main à trois voies de TCP, il n’existe aucun mécanisme intégré pour vérifier que l’adresse IP source d’un paquet SIP est authentique. L’usurpation d’adresse IP source est triviale, ce qui signifie que les attaquants peuvent générer un trafic d’inondation semblant provenir de milliers d’adresses différentes simultanément, déjouant la simple limitation de débit par IP.

Le mécanisme d’enregistrement amplifie le problème. Les terminaux SIP (téléphones, softphones, jonctions) doivent périodiquement envoyer des messages REGISTER pour maintenir leur connexion. Chaque requête REGISTER oblige le serveur à rechercher les identifiants, les valider et répondre. Ce traitement d’authentification est intensif en CPU et cible généralement le composant le plus contraint de l’architecture : le registrar.

Enfin, le plan média ajoute une surface d’attaque supplémentaire. Le protocole RTP (Real-time Transport Protocol) transporte l’audio voix réel sur des plages de ports alloués dynamiquement, ce qui signifie que les pare-feu doivent laisser de larges plages de ports ouvertes pour permettre le passage du trafic média. Ces ports ouverts deviennent des points d’entrée pour des inondations média qui consomment de la bande passante et de la capacité de traitement sans jamais établir un appel légitime.

La combinaison d’un traitement d’appels à état, du transport UDP, d’une authentification coûteuse en ressources et d’une allocation dynamique de ports fait des infrastructures SIP une cible DoS idéale.

Les quatre types d’attaques par inondation SIP

Les attaques par déni de service SIP se répartissent en quatre catégories, chacune exploitant un aspect différent du protocole. Une défense efficace doit toutes les couvrir.

Inondations INVITE

L’inondation INVITE est l’attaque DoS SIP la plus courante. L’attaquant envoie des volumes massifs de messages SIP INVITE à la cible, chacun demandant au serveur d’établir un nouvel appel.

Chaque INVITE oblige le serveur récepteur à analyser les en-têtes SIP, rechercher les règles de routage, allouer de la mémoire pour un dialogue d’appel et tenter de transférer la requête au saut suivant. Même si les appels n’aboutissent jamais (et lors d’une attaque, c’est généralement le cas), le traitement de chaque transaction INVITE consomme du CPU et de la mémoire. À un volume suffisant, le serveur épuise sa capacité de traitement et ne peut plus gérer les requêtes légitimes d’établissement d’appel.

Les inondations INVITE sont particulièrement efficaces parce que les serveurs SIP sont conçus pour être généreux avec les ressources lors de l’établissement d’appel. Le protocole suppose que si un INVITE arrive, un véritable appelant attend. Il n’existe pas de moyen léger de rejeter un INVITE sans le traiter au moins partiellement.

Lorsque les IP sources sont usurpées (ce qui est courant sur UDP), le simple blocage par IP devient inefficace, car l’attaque semble provenir de milliers d’adresses uniques.

L’impact est immédiat : les appelants légitimes reçoivent des signaux d’occupation, n’entendent que le silence ou obtiennent des erreurs de temporisation. Si la cible est une jonction SIP reliant une entreprise à son opérateur, tous les appels entrants et sortants de cette organisation s’arrêtent.

Inondations REGISTER

L’inondation REGISTER cible le sous-système d’authentification. L’attaquant envoie de grands volumes de requêtes SIP REGISTER, généralement avec des identifiants aléatoires ou invalides, au SBC ou au registrar.

Chaque message REGISTER oblige le serveur à effectuer une recherche d’identifiants et un cycle de challenge/réponse d’authentification. Cela est plus coûteux en calcul par message que le traitement d’un INVITE, car cela implique des requêtes en base de données et, dans de nombreuses implémentations, un calcul d’authentification digest.

Les inondations REGISTER peuvent servir un double objectif : l’objectif principal est l’épuisement des ressources (refuser le service aux utilisateurs légitimes tentant de s’enregistrer), mais l’inondation peut simultanément fonctionner comme une attaque de bourrage d’identifiants si de vrais noms d’utilisateur sont inclus avec des mots de passe en force brute.

L’impact cible spécifiquement le plan d’enregistrement. Les terminaux légitimes qui ne parviennent pas à s’enregistrer perdent leur présence sur le réseau, ce qui signifie qu’ils ne peuvent plus recevoir d’appels entrants et peuvent ne pas être en mesure de passer des appels sortants. Pour les organisations dont les travailleurs à distance dépendent de l’enregistrement SIP pour la connectivité softphone, une inondation REGISTER peut déconnecter silencieusement l’ensemble du personnel distant.

Inondations OPTIONS et BYE

Les messages SIP OPTIONS sont des sondes keepalive légères. Les serveurs sont censés y répondre rapidement, ce qui en fait un vecteur efficace d’épuisement des ressources avec un effort minimal de la part de l’attaquant. Une inondation OPTIONS ne fera pas forcément planter un serveur, mais elle dégrade les performances en consommant la capacité de traitement des transactions qui serait autrement utilisée pour de vrais appels.

Les inondations BYE sont plus ciblées et plus perturbatrices. En envoyant de faux messages BYE référençant des identifiants de dialogue d’appels actifs, un attaquant peut interrompre des appels légitimes en cours. Si l’attaquant peut observer ou deviner les valeurs de call-ID (qui sont parfois prévisibles), il peut déconnecter sélectivement des appels spécifiques ou parcourir une plage de valeurs possibles pour perturber toutes les sessions actives.

Les inondations OPTIONS provoquent une dégradation progressive des performances. Les inondations BYE provoquent des déconnexions d’appels actifs, immédiatement visibles par les utilisateurs finaux et pouvant être confondues avec une instabilité réseau plutôt qu’une attaque active.

Attaques par messages SIP malformés

Plutôt que de submerger le serveur par le volume, les attaques par messages malformés ciblent l’analyseur syntaxique SIP lui-même. L’attaquant envoie des messages SIP avec des en-têtes délibérément cassés, des champs surdimensionnés, des encodages de caractères invalides ou des structures syntaxiquement impossibles.

L’objectif est de déclencher une vulnérabilité de l’analyseur syntaxique : un débordement de tampon, une fuite mémoire, une exception non gérée ou un comportement indéfini dans la pile SIP. Si l’analyseur syntaxique plante, l’ensemble du service SIP tombe. Même s’il ne plante pas, un analyseur syntaxique qui consomme des ressources excessives en tentant de traiter une entrée malformée peut être exploité pour une attaque DoS à faible volume qui échappe totalement à la limitation de débit.

Cette catégorie inclut les attaques de « fuzzing » où des outils automatisés génèrent des milliers de variantes de messages malformés pour découvrir des bugs exploitables dans l’analyseur syntaxique. Un seul payload de fuzzing réussi peut être plus dommageable qu’une inondation volumétrique, car il ne nécessite parfois qu’un seul message pour faire planter la cible.

L’impact va de l’instabilité du service (fuites mémoire causant une dégradation progressive) à la défaillance complète du service (crash de l’analyseur syntaxique), en passant par des brèches de sécurité potentielles si la vulnérabilité de l’analyseur syntaxique permet l’exécution de code.

Comment un SBC stoppe les attaques par inondation SIP

Un SBC fournit cinq mécanismes distincts de détection et d’atténuation des attaques DoS SIP. Ces mécanismes opèrent à différentes couches et se complètent mutuellement pour créer une posture de défense en profondeur.

Limitation de débit avec connaissance SIP

La protection DoS la plus fondamentale d’un SBC est la limitation de débit au niveau de la couche applicative, qui comprend les types de messages SIP. Contrairement à un pare-feu, qui ne peut limiter le trafic que par adresse IP et numéro de port, un SBC peut définir des limites de débit indépendantes pour chaque méthode SIP.

Cela signifie qu’un opérateur peut configurer des seuils distincts pour les messages INVITE, les messages REGISTER, les messages OPTIONS et les autres méthodes SIP. Une jonction SIP d’opérateur légitime pourrait envoyer 500 INVITE par seconde aux heures de pointe, mais ne devrait jamais envoyer 500 REGISTER par seconde. La limitation de débit avec connaissance SIP peut bloquer l’inondation REGISTER tout en laissant le trafic INVITE s’écouler normalement.

Les limites de débit peuvent être appliquées à plusieurs niveaux. Les limites par IP source plafonnent le trafic depuis toute adresse d’origine individuelle. Les limites par groupe de jonctions (configurées par Network Access Point dans ProSBC) plafonnent le trafic total de chaque connexion opérateur, quelle que soit la distribution des IP sources. Les limites globales protègent la capacité de traitement propre du SBC en dernier recours.

L’avantage clé par rapport à la limitation de débit au niveau réseau est la précision. Un pare-feu qui limite tout le trafic UDP vers le port 5060 bloquera les appels légitimes en même temps que le trafic d’attaque. Un SBC qui ne limite que les messages REGISTER provenant de sources non fiables tout en autorisant le trafic INVITE des pairs opérateurs connus préserve le service pendant une attaque.

Validation de protocole et filtrage des messages

Chaque message SIP qui atteint le SBC passe par un moteur de validation de protocole avant d’être autorisé à atteindre le cœur du traitement d’appels. Le SBC vérifie le message par rapport à la spécification SIP (RFC 3261 et normes associées), en contrôlant que les en-têtes sont correctement formés, que les champs obligatoires sont présents, que les longueurs de champs sont dans les limites, et que la structure globale du message est syntaxiquement valide.

Les messages qui échouent à la validation sont rejetés immédiatement. Ils n’atteignent jamais le moteur de traitement d’appels, la logique de routage ou le registrar. Cela élimine toute la catégorie des attaques par messages malformés et d’exploitation de l’analyseur syntaxique en une seule couche.

Au-delà de la validation stricte, le moteur de normalisation SIP du SBC peut corriger les problèmes de formatage courants provenant de terminaux légitimes mais non conformes. Cette double fonction, rejeter les malformations malveillantes tout en corrigeant les non-conformités bénignes, signifie que la couche de validation améliore simultanément la sécurité et l’interopérabilité.

Liste de blocage dynamique et classification de confiance

Les listes de contrôle d’accès (ACL) statiques sont un point de départ, mais elles nécessitent une maintenance manuelle et ne peuvent pas réagir aux attaques en temps réel. La liste de blocage dynamique automatise la réponse.

Le SBC surveille les schémas de trafic de chaque IP source en temps réel. Lorsqu’une source dépasse les seuils configurés (par exemple, 50 tentatives REGISTER échouées en 10 secondes, ou 200 INVITE par seconde sans appels aboutis), le SBC ajoute automatiquement cette source à une liste de blocage. Le trafic ultérieur provenant de la source bloquée est rejeté au niveau de la couche réseau sans consommer de ressources de traitement applicatif.

ProSBC étend ce mécanisme avec le greylisting basé sur un pourcentage. Plutôt que de prendre une décision binaire bloquer/autoriser, un opérateur peut configurer le SBC pour ne laisser passer qu’un pourcentage du trafic provenant d’une source suspecte. Par exemple, bloquer 90 % du trafic d’une plage IP tout en laissant passer 10 % pour surveillance. C’est particulièrement utile pendant la phase d’investigation d’un DDoS suspecté, lorsque l’opérateur n’est pas encore certain que la source de trafic est malveillante ou s’il s’agit d’un opérateur légitime subissant un pic de trafic.

La classification de confiance ajoute une couche supplémentaire. Les pairs opérateurs connus peuvent être classifiés comme fiables, bénéficiant de limites de débit plus élevées et contournant certaines vérifications. Les sources inconnues ou provenant de l’internet public sont classifiées comme non fiables et soumises à un examen plus strict. Le SBC peut reclassifier dynamiquement les sources en fonction de leur comportement, promouvant les sources bien comportantes et rétrogradant les sources abusives.

Protection contre le balayage d’enregistrement SIP

Les inondations d’enregistrement méritent une détection dédiée en raison de leur impact disproportionné sur le sous-système d’authentification. ProSBC inclut un moteur de protection contre le balayage d’enregistrement SIP spécialement conçu pour surveiller le trafic REGISTER de manière spécifique.

Ce moteur distingue le comportement d’enregistrement légitime (périodique, timing prévisible, identifiants valides) des schémas d’attaque (trafic en rafale, tentatives d’identifiants séquentiels, noms d’utilisateur aléatoires ou invalides). Les terminaux SIP légitimes se réenregistrent à des intervalles configurés (généralement de 60 à 3600 secondes) avec des identifiants cohérents. Les scanners d’enregistrement et les outils d’inondation génèrent des rafales de messages REGISTER avec des identifiants variés ou séquentiels à des débits qu’aucun terminal légitime ne produirait.

Lorsque le moteur de détection identifie un schéma de balayage ou d’inondation d’enregistrement, il bloque la source avant que le trafic n’atteigne le registrar. Cela protège le composant le plus contraint en ressources de l’architecture sans affecter le trafic d’enregistrement légitime des terminaux connus.

Masquage de topologie comme prévention DoS

Le masquage de topologie est souvent abordé comme une fonctionnalité de confidentialité ou de sécurité, mais c’est aussi un mécanisme direct de prévention DoS.

Un SBC fonctionnant comme B2BUA (Back-to-Back User Agent) termine chaque session SIP du côté externe et en ré-émet une nouvelle du côté interne. Les parties externes ne voient jamais les adresses IP, les noms d’hôtes ou la topologie réseau des serveurs SIP internes, des passerelles média ou des systèmes PBX.

Cela compte pour la prévention DoS car un attaquant ne peut pas cibler ce qu’il ne peut pas voir. Sans le SBC, un attaquant qui découvre l’adresse IP d’un PBX ou registrar interne peut l’inonder directement, contournant toutes les défenses périmétriques. Avec le SBC en mode B2BUA, tout le trafic externe se termine au SBC lui-même, et l’infrastructure interne est architecturalement inaccessible depuis Internet.

L’architecture B2BUA complète de ProSBC (et non un simple proxy SIP) crée une rupture totale dans le dialogue SIP entre les réseaux externe et interne. Les messages SIP du côté interne sont des transactions entièrement nouvelles générées par le SBC, pas des copies transférées des messages externes. Un attaquant inondant l’interface externe du SBC ne peut pas injecter de messages malformés ou de fausses requêtes BYE dans les segments d’appel internes, car ces segments sont des sessions SIP indépendantes entièrement contrôlées par le SBC.

Pourquoi un pare-feu réseau ne peut pas remplacer un SBC pour la protection DoS SIP

Les pare-feu réseau et les SBC remplissent des rôles complémentaires, et aucun ne remplace l’autre. La distinction est importante car les organisations qui s’appuient uniquement sur un pare-feu pour la sécurité VoIP présentent une lacune significative dans leur défense DoS.

Un pare-feu opère au niveau de la couche réseau (couche 3) et de la couche transport (couche 4). Il peut filtrer par adresse IP source et destination, type de protocole et numéro de port. Il peut appliquer des limites de débit au volume total de trafic provenant d’une source donnée. Certains pare-feu proposent une fonctionnalité SIP ALG (Application Layer Gateway), mais les SIP ALG sont largement reconnus comme source de problèmes importants pour les réseaux voix : réécriture des en-têtes SIP de manière à interrompre les flux d’appels, interférence avec la traversée NAT et routage imprévisible. La plupart des ingénieurs VoIP désactivent le SIP ALG comme première étape de dépannage.

Ce qu’un pare-feu ne peut pas faire, c’est inspecter les messages SIP au niveau de la couche applicative. Il ne peut pas distinguer un INVITE légitime d’une attaque par inondation. Il ne peut pas limiter le débit des messages REGISTER indépendamment des messages INVITE. Il ne peut pas détecter qu’un message SIP est malformé de manière à exploiter une vulnérabilité de l’analyseur syntaxique. Il ne peut pas identifier les schémas de balayage d’enregistrement. Il ne peut pas masquer la topologie interne du réseau face à la reconnaissance au niveau SIP.

L’architecture correcte utilise les deux. Un pare-feu (ou un service de nettoyage DDoS en amont) gère les attaques volumétriques de couche 3/4 : inondations TCP SYN, attaques par amplification UDP, inondations ICMP. Le SBC gère les attaques SIP au niveau applicatif qui traversent la couche réseau sans être détectées parce qu’elles utilisent des adresses IP valides, des ports valides et des paquets UDP correctement formés.

Pour les déploiements cloud, ce modèle en couches fonctionne particulièrement bien. Les fournisseurs cloud comme AWS et Azure incluent une protection DDoS au niveau réseau dans leur infrastructure. Un SBC fonctionnant sur ces plateformes bénéficie automatiquement de ce bouclier au niveau réseau, puis ajoute la protection SIP au niveau applicatif par-dessus, couvrant les deux catégories d’attaques sans obliger l’opérateur à construire une infrastructure de mitigation DDoS séparée.

Déployer un SBC pour une protection DoS maximale

Une prévention DoS efficace n’est pas seulement un ensemble de fonctionnalités. Elle dépend aussi de l’emplacement et de la manière dont le SBC est déployé.

Le SBC doit se situer en bordure de réseau, entre les connexions exposées à Internet ou aux opérateurs et l’infrastructure voix interne. Chaque connexion SIP externe doit se terminer au SBC. Les systèmes PBX internes, les registrars, les serveurs média et les ponts de conférence doivent être sur un segment réseau séparé sans exposition directe à Internet. Si un serveur SIP interne dispose d’une adresse IP publique accessible directement par des parties externes, la protection DoS du SBC est entièrement contournée pour ce serveur.

La haute disponibilité est essentielle pour la résilience DoS. Une configuration SBC active/veille 1+1 (comme l’option HA de ProSBC) garantit que si un nœud SBC est submergé ou nécessite un redémarrage, le nœud de veille prend le relais. Cela empêche une attaque DoS de se transformer en panne vocale totale. Pour les déploiements de classe opérateur, le SBC doit supporter une capacité de sessions suffisante pour absorber les pics de trafic sans atteindre les limites de ressources en conditions normales. ProSBC supporte jusqu’à 60 000 appels simultanés par serveur et 350 000 enregistrements de terminaux, offrant une marge significative au-dessus des charges d’exploitation typiques.

Pour les organisations confrontées à des campagnes DDoS persistantes ou sophistiquées, la distribution géographique ajoute une couche supplémentaire. Déployer des instances SBC dans plusieurs régions ou zones de disponibilité signifie qu’une attaque ciblant un point d’entrée géographique n’affecte pas les autres. Combiné avec la répartition de charge basée sur le DNS ou la redirection SIP, le trafic peut être redirigé d’un SBC sous attaque vers des instances saines.

Le point d’intégration entre la défense au niveau réseau et au niveau applicatif mérite une attention particulière. Si vous utilisez un service de nettoyage DDoS en amont (Cloudflare, AWS Shield ou similaire), ce service gère les attaques volumétriques en bordure de réseau. Le SBC gère les attaques spécifiques au SIP que le service de nettoyage laisse passer parce qu’elles ressemblent à du trafic UDP légitime. Ce modèle à deux niveaux offre une couverture complète : le service de nettoyage absorbe l’attaque brute en bande passante, et le SBC filtre l’attaque au niveau applicatif qui survit.

Foire aux questions