Comment les Session Border Controllers protègent les réseaux vocaux

Chaque trunk SIP, chaque IP-PBX et chaque connexion UCaaS exposée à l’internet public constitue une surface d’attaque. La fraude tarifaire coûte à elle seule plus de 10 milliards de dollars par an à l’industrie des télécommunications, selon la Communications Fraud Control Association (CFCA). Les attaques par déni de service distribué (DDoS) contre les infrastructures VoIP peuvent mettre une organisation entière hors ligne en quelques minutes. Et sans chiffrement, le trafic vocal circule en clair, lisible par quiconque dispose d’un analyseur de paquets sur le chemin réseau.

Un Session Border Controller (SBC) est l’élément réseau conçu pour se positionner en périphérie d’un réseau vocal et défendre contre ces menaces. Mais la « sécurité SBC » n’est pas une fonctionnalité unique. Il s’agit d’un ensemble de couches de défense complémentaires qui protègent la signalisation, les médias et l’infrastructure réseau principale contre des catégories d’attaques distinctes.

Ce guide détaille les cinq couches de sécurité qu’un SBC correctement déployé fournit, explique pourquoi les pare-feu traditionnels ne peuvent pas remplacer un SBC pour le trafic vocal, et couvre les capacités de sécurité configurables qui distinguent les SBC modernes des équipements statiques hérités.

Pourquoi les réseaux vocaux ont besoin d’une sécurité dédiée

Le trafic voix sur IP (VoIP) utilise une architecture de protocoles fondamentalement différente de celle du trafic web. SIP gère la signalisation (établissement d’appel, libération, enregistrement), tandis que RTP transporte le média audio réel. Ces deux protocoles utilisent des ports différents, des mécanismes de transport différents et des structures d’en-têtes différentes, et les deux nécessitent une protection.

Les pare-feu réseau traditionnels opèrent sur la couche réseau (adresses IP) et la couche transport (ports TCP/UDP). Ils peuvent bloquer ou autoriser le trafic en fonction de l’IP source/destination et du numéro de port, mais ils ne peuvent pas inspecter ni comprendre les messages SIP qui transitent par ces ports. Un pare-feu ne peut pas distinguer un INVITE SIP légitime d’un flot de requêtes REGISTER malveillantes conçues pour submerger votre registrar. Il ne peut pas détecter qu’un message SIP tente d’acheminer un appel vers un numéro international surtaxé via vos trunks.

Certains pare-feu offrent une fonctionnalité de passerelle de couche application SIP (ALG), mais le SIP ALG est réputé pour causer plus de problèmes qu’il n’en résout : réécriture des en-têtes SIP de manière à interrompre les flux d’appels, interférence avec la traversée NAT et création d’un comportement de routage imprévisible. La plupart des ingénieurs VoIP désactivent le SIP ALG comme première étape de dépannage.

La surface d’attaque d’un réseau vocal couvre trois plans : le plan de signalisation (messages SIP), le plan média (flux audio RTP) et le plan de gestion (interfaces d’administration web, API, SNMP). Un SBC fournit une sécurité spécialisée sur ces trois plans.

Les cinq couches de sécurité d’un SBC

La sécurité SBC peut être envisagée comme une architecture de défense en profondeur. Chaque couche répond à une catégorie de menace spécifique, et les cinq couches fonctionnent ensemble pour créer une posture de sécurité complète.

Couche 1 : chiffrement de la signalisation avec SIP sur TLS

Le Session Initiation Protocol (SIP) a été conçu sans chiffrement intégré. Par défaut, les messages SIP circulent sur UDP ou TCP en clair, exposant les métadonnées d’appel (qui appelle qui, depuis quelle adresse IP, avec quelles informations d’identification) à quiconque surveille le réseau.

Transport Layer Security (TLS) chiffre le canal de signalisation SIP. Lorsque SIP fonctionne sur TLS, tous les messages de signalisation entre le SBC et ses pairs sont chiffrés, empêchant l’écoute clandestine et les attaques de type « homme du milieu » lors de l’établissement des appels.

Le TLS mutuel (mTLS) va plus loin en exigeant que les deux côtés de la connexion présentent des certificats valides. Cela empêche les équipements non autorisés d’établir des connexions SIP avec votre SBC, même s’ils connaissent l’adresse IP et le port corrects. Le TLS mutuel est particulièrement important pour les environnements réglementés et pour la majorité des systèmes de téléphonie SIP exposés à l’internet public, y compris Microsoft Teams Direct Routing, qui impose le TLS pour toutes les connexions SBC.

ProSBC prend en charge SIP sur TLS (configurable par Network Access Point), permettant le chiffrement de la signalisation pour chaque groupe de trunks de manière indépendante. Vous pouvez ainsi imposer le TLS sur les connexions d’interconnexion tout en maintenant le SIP non chiffré pour les points de terminaison internes qui ne le prennent pas en charge.

Couche 2 : chiffrement des médias avec SRTP

Le chiffrement de la signalisation protège les métadonnées d’appel, mais l’audio vocal réel circule séparément via le Real-time Transport Protocol (RTP). Sans chiffrement des médias, un attaquant capable de capturer des paquets RTP peut reconstituer l’intégralité de la conversation.

Le Secure RTP (SRTP) chiffre le flux média. Un SBC qui prend en charge le SRTP peut fonctionner selon deux modes : relais SRTP, où il transmet les médias chiffrés sans les déchiffrer (préservant le chiffrement de bout en bout), et conversion RTP vers SRTP, où il accepte le RTP non chiffré d’un côté et le chiffre en SRTP vers l’autre. Cette capacité de conversion est essentielle dans les environnements mixtes où certains points de terminaison prennent en charge le SRTP et d’autres non.

ProSBC offre une prise en charge native du SRTP, incluant le relais SRTP et la conversion RTP vers SRTP, permettant aux opérateurs d’imposer le chiffrement des médias même lors de la connexion d’équipements hérités ne prenant en charge que le RTP à une infrastructure moderne exigeant le SRTP.

Couche 3 : contrôle d’accès et filtrage du trafic

Le chiffrement protège le contenu des communications légitimes. Le contrôle d’accès détermine qui est autorisé à communiquer.

Les capacités de contrôle d’accès d’un SBC comprennent généralement des listes de contrôle d’accès (ACL) basées sur les adresses IP qui autorisent ou bloquent des adresses et des plages spécifiques, un filtrage des numéros appelants et appelés qui bloque le trafic vers ou depuis des numéros de téléphone spécifiques, et des contrôles d’enregistrement qui limitent les équipements pouvant s’enregistrer via le SBC.

La granularité de ces contrôles est déterminante. Un SBC qui ne prend en charge que des ACL globales vous oblige à appliquer les mêmes règles à chaque trunk. Un SBC qui prend en charge les ACL par groupe de trunks vous permet d’appliquer des politiques différentes à différents opérateurs, segments de clientèle ou régions géographiques.

ProSBC implémente un blocage dynamique avec mise en liste grise basée sur des pourcentages. Vous pouvez le configurer pour bloquer 100 % des appels provenant d’un acteur malveillant connu, ou bloquer un pourcentage configurable provenant d’une source suspecte pendant que vous enquêtez. Son contrôle d’accès fonctionne à la fois au niveau global et par NAP (Network Access Point), et il inclut une protection contre le balayage d’enregistrements SIP pour détecter et bloquer les attaques d’inondation d’enregistrements avant qu’elles ne consomment les ressources du système.

Couche 4 : atténuation des attaques DoS et DDoS

Une attaque par déni de service contre un réseau vocal n’a pas besoin d’être sophistiquée pour être efficace. Un flot de SIP INVITE (des milliers de requêtes d’établissement d’appel par seconde provenant d’adresses IP usurpées) peut épuiser la capacité de sessions d’un SBC, la mémoire d’un registrar ou la puissance de traitement d’un IP-PBX.

L’atténuation DoS et DDoS au niveau du SBC fonctionne en appliquant des limites de débit par IP source, par groupe de trunks et par type de message. Lorsqu’un SBC détecte qu’une source envoie des messages SIP à un débit dépassant les seuils configurés, il peut limiter, interroger ou bloquer cette source, le tout sans affecter le trafic légitime des autres sources.

L’avantage principal de la gestion du DoS au niveau du SBC (plutôt qu’au niveau du pare-feu réseau) est la connaissance du protocole. Le SBC comprend qu’une rafale de 500 messages SIP REGISTER provenant d’une seule IP en 10 secondes est anormale, même si chaque message individuel est une requête SIP valide qu’un pare-feu laisserait passer sans question.

ProSBC inclut des règles de protection DoS et DDoS intégrées, configurables par groupe de trunks (NAP). Cette granularité par NAP signifie que vous pouvez définir des seuils agressifs sur les trunks exposés au public tout en maintenant des limites plus souples sur les connexions internes de confiance.

Couche 5 : prévention de la fraude tarifaire et du spam

La fraude tarifaire est l’attaque la plus dommageable financièrement contre les réseaux vocaux. Les attaquants accèdent à un trunk SIP ou un PBX (par le vol d’identifiants, le détournement d’enregistrement ou la manipulation de messages SIP) et acheminent des appels via des numéros internationaux surtaxés qu’ils contrôlent. La victime reçoit la facture ; l’attaquant perçoit la part de revenus du service surtaxé.

Un SBC combat la fraude tarifaire par de multiples mécanismes : blocage des appels vers des plages de numéros surtaxés connus, application de limites d’appels simultanés par trunk, détection de schémas d’appels anormaux (comme un pic soudain de trafic international à 3 h du matin) et intégration avec des bases de données externes de détection de fraude pour un score en temps réel.

La prévention du spam et des appels automatisés suit un schéma similaire : le SBC interroge des bases de données de réputation externes avant d’admettre un appel, et achemine ou bloque en fonction du score de risque retourné.

ProSBC répond à la fraude tarifaire et au spam grâce à plusieurs capacités intégrées. Son API de routage Ruby configurable permet aux opérateurs d’implémenter une logique de détection de fraude personnalisée qui inspecte plus de 100 paramètres d’appel par appel et s’exécute avant le routage. Il s’intègre avec SecureLogix pour le score de risque de spam, YouMail pour l’évaluation du risque d’appels automatisés, et TransNexus ClearIP pour la détection combinée de fraude et la vérification STIR/SHAKEN. La fonctionnalité de mise en liste grise basée sur des pourcentages permet aux opérateurs de limiter le trafic suspect sans le bloquer complètement, ce qui est utile lorsqu’une source est en zone grise et que le blocage total affecterait les appelants légitimes.

Masquage de topologie : la fonction de sécurité silencieuse du SBC

L’une des fonctions de sécurité les plus importantes qu’un SBC fournit est aussi la moins visible : le masquage de topologie. Chaque message SIP contient des en-têtes Via, Contact et Record-Route qui révèlent les adresses IP internes, les noms d’hôte et l’architecture réseau. Sans masquage de topologie, un attaquant externe peut cartographier votre réseau interne simplement en examinant les réponses SIP.

Une architecture Back-to-Back User Agent (B2BUA) est l’élément clé d’un masquage de topologie efficace. Contrairement à un proxy SIP, qui transmet les messages SIP et ajoute son propre en-tête Via tout en préservant les en-têtes d’origine, un B2BUA termine intégralement la session SIP d’un côté et en initie une entièrement nouvelle de l’autre. Toutes les informations du réseau interne sont ainsi supprimées et remplacées avant qu’un message SIP ne quitte le réseau.

ProSBC implémente une architecture B2BUA complète, fournissant un masquage de topologie intégral qui dissimule les adresses IP du réseau interne aux parties externes et vice versa. Il ne s’agit pas d’une option configurable qui pourrait être accidentellement désactivée. C’est une propriété inhérente de la conception B2BUA.

Sécurité configurable : pourquoi les règles statiques ne suffisent pas

Les listes de contrôle d’accès statiques et les limites de débit fixes suffisaient lorsque les menaces VoIP étaient peu sophistiquées. Les opérations de fraude tarifaire actuelles utilisent des adresses IP rotatives, des identifiants SIP d’apparence valide et des schémas d’appels conçus pour rester juste en dessous des seuils de détection statiques.

Un SBC configurable permet aux opérateurs d’implémenter une logique de sécurité adaptative qui interroge les systèmes externes en temps réel, applique des règles personnalisées basées sur le contexte complet de chaque appel, et évolue à mesure que les menaces changent, sans nécessiter de mises à jour du micrologiciel ni de tickets de support fournisseur.

L’API de routage Ruby de ProSBC offre cette configurabilité grâce à une architecture de chaîne de filtres. Les scripts de routage étendent une classe de base et définissent des méthodes before_filter, after_filter et after_remap_filter qui s’exécutent à différentes étapes du traitement d’appel. Dans ces filtres, les opérateurs peuvent interroger des services HTTP externes (bases de données de fraude, services de réputation de numéros, systèmes de logique métier internes), inspecter n’importe lequel des plus de 100 paramètres d’appel disponibles dans le moteur de routage, et prendre des décisions de routage ou de blocage basées sur les résultats combinés.

Un opérateur ProSBC peut ainsi implémenter une logique telle que : « Pour chaque appel provenant du NAP “carrier-x” avec une destination correspondant à des schémas internationaux surtaxés, interroger TransNexus ClearIP pour obtenir un score de fraude. Si le score dépasse le seuil configuré, bloquer l’appel et consigner l’événement. Si le score est modéré, acheminer l’appel mais fixer une durée maximale de 60 secondes. » Ce type de logique décisionnelle contextuelle et multi-sources est impossible avec des ACL statiques seules.

STIR/SHAKEN : authentification de l’identité de l’appelant au niveau du SBC

L’usurpation de l’identité de l’appelant est à la fois une menace de sécurité et une préoccupation réglementaire. STIR/SHAKEN (Secure Telephone Identity Revisited / Signature-based Handling of Asserted information using toKENS) est le cadre industriel pour la vérification cryptographique que le numéro de l’appelant n’a pas été usurpé.

Le SBC joue un rôle central dans STIR/SHAKEN : en tant que SBC d’origine, il s’intègre à un service de signature pour attacher un en-tête Identity cryptographique aux appels sortants ; en tant que SBC de terminaison, il vérifie l’en-tête Identity sur les appels entrants et agit en fonction du niveau d’attestation.

Les trois niveaux d’attestation indiquent la relation du fournisseur d’origine avec l’appelant : Attestation complète (A) signifie que le fournisseur a authentifié l’appelant et que celui-ci est autorisé à utiliser ce numéro ; Attestation partielle (B) signifie que le fournisseur sait d’où provient l’appel mais ne peut pas vérifier le droit de l’appelant à utiliser le numéro ; Attestation passerelle (C) signifie que l’appel est entré dans le réseau depuis une source non fiable.

Pour une analyse approfondie de l’implémentation STIR/SHAKEN, des niveaux d’attestation et des exigences de conformité FCC, consultez notre guide dédié STIR/SHAKEN.

Liste de vérification de sécurité SBC : évaluer un SBC pour la sécurité

Lors de l’évaluation d’un SBC pour les exigences de sécurité de votre réseau, utilisez cette liste de vérification pour assurer une couverture complète.

Exigence de sécurité	Ce qu’il faut rechercher	ProSBC
SIP sur TLS	Prise en charge TLS 1.2+, configurable par trunk, option TLS mutuel (mTLS)	TLS par NAP
SRTP	Prise en charge native du SRTP, conversion RTP vers SRTP, mode relais SRTP	Relais + conversion
Listes de contrôle d’accès	Granularité par groupe de trunks, basées sur IP et numéros, mises à jour dynamiques	Par NAP + liste grise
Protection DoS/DDoS	Intégrée (pas un module complémentaire), configurable par trunk, limitation de débit SIP	Intégrée par NAP
Masquage de topologie	Architecture B2BUA complète (pas un proxy SIP), réécriture complète des en-têtes	B2BUA complet
Prévention de la fraude tarifaire	Blocage des appels internationaux, limites d’appels simultanés, détection de schémas	API + intégrations partenaires
Configurabilité	API de script pour logique de routage/sécurité personnalisée, requêtes vers systèmes externes	API de routage Ruby
STIR/SHAKEN	Prise en charge de la signature et de la vérification, gestion des niveaux d’attestation	Via service de signature
Intégrations tierces	Intégrations partenaires nommées et validées pour la détection de fraude/spam	SecureLogix, YouMail, TransNexus
Haute disponibilité	HA 1+1 sans interruption de service, continuité de sécurité pendant le basculement	ProSBC+ HA 1+1

Sécurité SBC vs pare-feu traditionnel : pourquoi vous avez besoin des deux

Une question fréquente en planification de la sécurité réseau est de savoir si un pare-feu avec capacité SIP ALG peut remplacer un SBC. La réponse courte est non. Ils remplissent des fonctions complémentaires à différentes couches de la pile réseau.

Capacité	Pare-feu réseau	SBC
Filtrage IP/port	Configuration globale, extensibilité limitée	Par groupe de trunks
Inspection des messages SIP	SIP ALG uniquement, sans configurabilité	Complète, couche application
Manipulation des en-têtes SIP	Non	Oui
Gestion des médias RTP	Non	Oui
Terminaison TLS pour SIP	Non	Oui
Chiffrement/déchiffrement SRTP	Non	Oui
Limitation de débit SIP	Non	Oui
Détection de fraude tarifaire	Non	Oui
Masquage de topologie (B2BUA)	Non	Oui
Négociation de codecs	Non	Oui
STIR/SHAKEN	Non	Oui

Le déploiement recommandé est la défense en profondeur : le pare-feu réseau gère les attaques volumétriques au niveau réseau et applique les politiques d’accès IP générales aux couches réseau et transport, tandis que le SBC gère la sécurité SIP/RTP au niveau applicatif, les politiques de trafic et la détection des menaces spécifiques à la voix. Le pare-feu protège le SBC ; le SBC protège l’application vocale.

Sécuriser votre réseau vocal commence en périphérie

La sécurité SBC n’est pas une fonctionnalité unique à cocher sur un comparatif fournisseur. C’est une architecture de défense multicouche qui protège la signalisation, les médias, la topologie réseau et les revenus de l’entreprise contre des catégories de menaces distinctes. Les cinq couches (chiffrement de la signalisation, chiffrement des médias, contrôle d’accès, atténuation DoS/DDoS et prévention de la fraude tarifaire) fonctionnent ensemble comme une pile de défense en profondeur qu’aucun pare-feu traditionnel ne peut reproduire.

Les menaces modernes nécessitent plus que des règles statiques. Un SBC configurable avec des requêtes en temps réel vers des systèmes externes, un score de fraude par appel et une chaîne de filtres extensible donne aux opérateurs la capacité d’adapter leur posture de sécurité à mesure que les menaces évoluent, sans attendre les mises à jour du micrologiciel du fournisseur.