VitalPBX + SBC : sécuriser l’infrastructure voix

VitalPBX est un éditeur logiciel basé au Panama et aux États-Unis dont l’IP-PBX fonctionne sous Linux et Asterisk. Il est commercialisé selon un modèle freemium avec une édition Enterprise payante et une édition Multi-Tenant destinée aux ISP et MSP. Il est déployé dans plus de 100 pays, avec une adoption forte dans l’hôtellerie, les centres de contact, l’éducation et les entreprises de petite et moyenne taille. L’interface web de VitalPBX et ses modules complémentaires Sonata Suite (Sonata Switchboard pour les réceptionnistes, Sonata Recording pour l’enregistrement conforme des appels, Sonata Stats pour l’analyse des files d’attente, Sonata Dialer pour les campagnes d’appels sortants) s’appuient sur Asterisk, offrant aux opérateurs une plateforme téléphonique complète sans écriture de code de plan de numérotation.

VitalPBX est également un client de longue date de TelcoBridges. Confronté à l’économie des scanners SIP qui cible tout déploiement Asterisk exposé à Internet, VitalPBX a sélectionné ProSBC pour son propre système interne et l’a recommandé à son réseau de partenaires. Le cofondateur et PDG Rodrigo Cuadra a résumé cette décision dans l’étude de cas publiée : VitalPBX avait besoin d’un véritable contrôleur de session en bordure (SBC) capable de défendre contre les scanners SIP, de prendre en charge le transfert d’enregistrement et le transfert d’abonnement pour les postes distants, et de fonctionner comme un B2BUA afin que la signalisation et le média puissent être contrôlés proprement. ProSBC répondait à ces trois exigences à un prix compatible avec le modèle commercial freemium-to-paid de VitalPBX.

Cet article couvre ce qui change lorsque ProSBC est placé devant VitalPBX : les deux topologies de déploiement en production (jonction SIP vers les opérateurs et accès distant pour les travailleurs à distance), ce que le transfert d’enregistrement et le transfert d’abonnement apportent concrètement, comment le SBC interagit avec les outils de sécurité natifs de VitalPBX, et ce que l’édition Multi-Tenant implique pour l’architecture du SBC. La configuration détaillée étape par étape pour les deux topologies se trouve dans la documentation officielle d’interopérabilité ProSBC pour VitalPBX.

Les deux topologies de production pour VitalPBX + ProSBC

Un déploiement de type FreePBX avec « un PBX, une jonction opérateur » est la topologie VitalPBX la plus simple, mais c’est rarement celle que les clients utilisent en production. La base installée de VitalPBX se concentre sur deux configurations, toutes deux documentées directement dans la documentation officielle d’interopérabilité VitalPBX de TelcoBridges. Le rôle du SBC diffère légèrement dans chacune, et les deux topologies coexistent souvent sur le même serveur VitalPBX.

Topologie 1 : jonction SIP de VitalPBX vers un ou plusieurs ISP

VitalPBX termine les extensions en interne et route les appels sortants vers un ISP ou un opérateur via une jonction SIP. Sans SBC, cette jonction existe directement entre VitalPBX et les adresses de signalisation de l’opérateur, ce qui signifie que VitalPBX doit gérer directement les exigences de transport, de codecs, d’en-têtes et d’authentification de l’opérateur. Ajoutez un second opérateur pour le basculement ou le routage au moindre coût, et VitalPBX doit gérer simultanément deux jeux d’exigences SIP différentes.

Avec ProSBC en bordure, chaque opérateur dispose de son propre NAP avec son propre profil SIP, sa liste de codecs et ses règles d’en-têtes. VitalPBX ne voit qu’un seul NAP interne et cesse de se soucier de la normalisation par opérateur. L’ordonnancement des routes sur le SBC détermine quel opérateur achemine chaque appel, et la défaillance d’un opérateur déclenche un basculement automatique sans que VitalPBX ne s’en aperçoive.

Topologie 2 : accès des travailleurs à distance vers VitalPBX depuis l’Internet public

La seconde topologie est celle que VitalPBX a identifiée dans l’étude de cas comme le facteur déterminant pour la sécurité : des bureaux distants et des utilisateurs en télétravail enregistrant leurs extensions via l’Internet public. Sans SBC, ces extensions s’enregistrent directement auprès de VitalPBX sur UDP/5060 ou TLS/5061, ce qui signifie que le listener SIP de VitalPBX est exposé à tous les scanners SIP de l’Internet public. En l’espace d’une heure après la mise en service, les tentatives de scan arrivent.

Avec ProSBC en bordure, l’extension distante s’enregistre auprès du SBC, le SBC transmet le REGISTER à VitalPBX sur une interface privée, et le SBC relaie les NOTIFY en retour. Le PBX ne voit jamais les scanners. Le SBC absorbe les scans, applique la protection contre le balayage d’enregistrement et la limitation de débit, et ne transmet que le trafic correspondant à une extension légitime et un schéma d’authentification valide. Les abonnements pour la présence BLF et l’indication de message en attente empruntent le même canal, de sorte que la console opérateur et les voyants des postes téléphoniques continuent de fonctionner pour les agents distants.

La plupart des déploiements VitalPBX en production utilisent les deux topologies sur le même serveur. Un seul ProSBC gère les deux : des NAP côté opérateur d’un côté, des NAP côté extensions distantes de l’autre, avec VitalPBX au milieu sur une interface privée.

Un seul ProSBC gère les deux topologies de déploiement simultanément : des NAP côté opérateur pour la jonction SIP, des NAP côté extensions distantes pour les travailleurs répartis, avec VitalPBX et la Sonata Suite sur une interface privée au milieu. Cliquez pour agrandir.

Le transfert d’enregistrement et le transfert d’abonnement sont ce qui fait fonctionner les extensions distantes

Lorsque VitalPBX a évalué les SBC, le transfert d’enregistrement et le transfert d’abonnement ont été identifiés comme des exigences nommées, pas comme des options secondaires. La raison est structurelle : sans eux, la topologie de travail à distance ne fonctionne tout simplement pas.

Un SIP REGISTER provenant d’une extension distante est ce qui indique au PBX « je suis l’extension 1023, je suis actuellement joignable à cette adresse IP publique et ce port, veuillez m’envoyer les INVITE ». Si le SBC se contente de terminer le SIP en bordure sans transmettre le REGISTER à VitalPBX, le PBX ne sait jamais que l’extension existe et les appels entrants n’aboutissent nulle part. Le transfert d’enregistrement est le mécanisme qui rend le SBC transparent pour l’enregistrement : le terminal distant s’enregistre auprès de l’adresse publique du SBC ; le SBC réinitie le REGISTER vers VitalPBX depuis l’interface privée du SBC ; VitalPBX accepte l’enregistrement comme s’il provenait du réseau interne ; le SBC conserve la correspondance et l’utilise pour router les INVITE entrants vers le bon terminal public.

Le transfert d’abonnement remplit la même fonction pour les dialogues SUBSCRIBE/NOTIFY. La console Sonata Switchboard s’appuie sur la présence BLF pour afficher quelles extensions sont en communication. Les postes téléphoniques et les softphones utilisent les abonnements d’indication de message en attente pour allumer le voyant de messagerie vocale. Les déploiements hôteliers utilisent les abonnements d’événements de dialogue pour les intégrations de statut de chambre. Si le SBC bloque ou supprime le trafic SUBSCRIBE à la frontière, chacune de ces fonctionnalités s’éteint pour les terminaux distants tout en continuant de fonctionner pour les terminaux sur le LAN, ce qui constitue le pire type de panne partielle à diagnostiquer.

ProSBC gère les deux modes de transfert nativement et par NAP, le même NAP acheminant les enregistrements, les abonnements et la signalisation d’appel pour un locataire ou un groupe d’extensions donné.

Qu’en est-il du pare-feu intégré et des modules complémentaires de VitalPBX ?

VitalPBX est livré avec un module pare-feu intégré et intègre Fail2ban par défaut. Les deux sont présents dans l’édition Community, et les deux remplissent un rôle utile. Le module pare-feu offre à l’opérateur une interface graphique pour les règles iptables ; Fail2ban surveille le journal de sécurité d’Asterisk et bannit les adresses IP source après des échecs d’authentification répétés. Pour un déploiement monosite avec un opérateur connu sur un LAN privé et sans travailleurs à distance, ces deux outils couvrent l’essentiel des besoins d’un petit opérateur.

La situation change dès que le déploiement touche l’Internet public. Les outils intégrés de VitalPBX partagent le même système d’exploitation, la même pile réseau du noyau et le même CPU que le PBX. Une attaque au niveau SIP qui arrive en volume sature les trois simultanément. Fail2ban ne se déclenche qu’après qu’Asterisk a déjà écrit quelque chose dans le journal, ce qui signifie que le trafic a déjà atteint le parseur SIP, a été comparé à une extension et a été rejeté, chacune de ces étapes consommant du CPU aux volumes de scan. Les attaques par messages malformés, les inondations OPTIONS et les blocages de transactions de type slow-loris ne produisent jamais le 401 ou 403 que Fail2ban surveille, de sorte que le PBX se dégrade silencieusement tandis que le journal de sécurité reste muet. Le module pare-feu opère aux couches 3 et 4, sans visibilité sur le fait qu’un paquet entrant soit un REGISTER d’une extension légitime ou une sonde d’un scanner.

Un SBC en bordure est un équipement ou une VM distinct(e), sur sa propre adresse IP publique, avec sa propre pile SIP et son propre domaine de défaillance. Il analyse chaque message SIP au niveau de la couche SIP, applique une politique par méthode et par source, et absorbe tout le bruit avant qu’il n’atteigne VitalPBX. Le pare-feu de VitalPBX et Fail2ban restent sur le PBX et protègent le plan de gestion (SSH, l’interface d’administration VitalPBX, les interfaces web Sonata) ; le SBC prend en charge le plan SIP en bordure de réseau. Les deux couches se complètent ; aucune ne remplace l’autre. La page Protection contre les attaques DoS SIP au niveau du SBC couvre les mécanismes de la couche SIP de manière plus approfondie.

Ce qui change pour la Sonata Suite lorsque le SBC est en bordure

Sonata Switchboard, Sonata Recording, Sonata Stats et Sonata Dialer partagent tous une propriété structurelle : ils lisent et écrivent dans le même moteur Asterisk avec lequel le SBC s’apparie désormais côté interne. Aucun d’entre eux ne communique en SIP avec l’opérateur ou le terminal distant directement. Cette séparation est ce qui rend l’ajout d’un SBC propre plutôt que perturbateur.

Les indicateurs BLF et de présence de Sonata Switchboard continuent de fonctionner tant que le SBC transmet correctement les abonnements entre le terminal distant et VitalPBX. Sonata Recording capture le média côté Asterisk de l’appel ; parce que ProSBC est un B2BUA et que le média est ancré sur chaque segment indépendamment, le module Recording voit le même flux média qu’auparavant, quel que soit le profil de chiffrement sur le segment opérateur. Sonata Stats consomme les CDR Asterisk et les statistiques de files d’attente, qui sont entièrement internes au PBX et non affectés par le SBC. Sonata Dialer initie les appels sortants ; le SBC gère la normalisation côté opérateur et la signature pour ces appels dans le même chemin qu’il utilise pour tout autre trafic sortant.

Le principe architectural est celui qui a permis à VitalPBX de recommander ProSBC à ses clients dans l’étude de cas : le SBC se positionne proprement en dehors du périmètre du PBX, termine le SIP de chaque côté en tant que B2BUA, et ne nécessite aucune modification de la configuration interne de VitalPBX, de Sonata ou des modules Asterisk sous-jacents. Le PBX reste le PBX. La Sonata Suite reste la Sonata Suite. Le SBC est la nouvelle frontière publique.

VitalPBX MT et un seul SBC pour de nombreux locataires

L’édition Multi-Tenant de VitalPBX héberge des locataires isolés sur une seule instance, chacun avec ses propres extensions, jonctions, IVR, périmètre d’administration et (avec les modules appropriés) modules Sonata. Les ISP et les fournisseurs de services gérés l’utilisent pour fournir un PBX hébergé à de nombreux clients finaux depuis une seule plateforme. La topologie produite est structurellement identique au modèle multi-locataire qu’un MSP exploite avec une instance VitalPBX MT et de nombreux locataires derrière.

Un seul ProSBC en bordure consolide la couche SBC de la même manière que VitalPBX MT a consolidé la couche PBX. Chaque locataire obtient son propre NAP sur le SBC partagé, avec ses propres règles de routage, son propre mappage opérateur, sa propre politique de sécurité et son propre profil d’attestation STIR/SHAKEN. ProSBC prend en charge jusqu’à 1 024 NAP par serveur, ce qui offre une marge suffisante pour des nombres de locataires dépassant ce que la plupart des installations VitalPBX MT hébergeront réellement. La complexité côté opérateur reste sur le SBC une seule fois ; le routage par locataire sur le SBC reflète la configuration par locataire sur VitalPBX MT de manière univoque.

Une conséquence spécifique du modèle MT est que l’isolation des compromissions compte. Un seul locataire compromis sur un PBX multi-locataire est un événement bien plus grave qu’une seule extension compromise sur un PBX mono-locataire, car l’attaquant voit alors les identifiants de jonction par locataire, le routage par locataire et les CDR par locataire. L’évaluation de la fraude à la taxation par NAP, la limitation de débit par NAP et la signature STIR/SHAKEN par NAP du SBC fonctionnent toutes indépendamment par locataire, ce qui signifie qu’une compromission dans l’extension d’un locataire ne peut pas générer de trafic frauduleux via les jonctions des autres locataires. La page SBC pour MSP couvre le modèle SBC multi-locataire de manière plus approfondie.

Cas verticaux : hôtellerie, centre de contact, éducation

VitalPBX connaît une adoption particulièrement forte dans trois secteurs verticaux où le SBC en bordure résout un problème spécifique au secteur.

Hôtellerie : les déploiements exploitent des intégrations PMS avec le PBX pour l’enregistrement des clients, le statut des chambres, les appels de réveil et la facturation par chambre. Les téléphones de chambre sont des extensions ; les postes de travail de l’arrière-guichet et du PMS sont sur le même réseau ou un réseau de confiance adjacent. Le rôle du SBC est de maintenir les jonctions opérateur propres et les interfaces de gestion à distance verrouillées, tout en laissant les téléphones de chambre s’enregistrer en interne sans traverser la frontière publique. La fraude à la taxation contre les PBX hôteliers est un schéma d’attaque bien établi ; l’évaluation de la fraude par appel au niveau du SBC détecte la salve de numéros surtaxés en dehors des heures de bureau avant que la réception de l’hôtel ne la découvre le lendemain matin.

Centre de contact : ces configurations combinent VitalPBX avec Sonata Switchboard, Sonata Stats et Sonata Dialer à petite et moyenne échelle. Le déploiement combine des agents internes (qui peuvent être sur le LAN ou distants) et du trafic opérateur sortant qui doit satisfaire l’attestation STIR/SHAKEN en Amérique du Nord. Le SBC gère les deux : le transfert d’enregistrement pour les agents distants, et la signature STIR/SHAKEN par appel via un partenaire comme TransNexus ClearIP, Neustar ou d’autres pour chaque appel sortant.

Éducation : les déploiements couvrent les écoles et les campus utilisant VitalPBX pour les téléphones de classe, la diffusion et la notification d’urgence, souvent avec un routage E911 via un ISP régional. Le SBC maintient l’interconnexion opérateur propre et absorbe le trafic de scan SIP qui atteindrait autrement directement le PBX via l’adresse IP publique de l’école. Lorsque plusieurs campus partagent un seul PBX, l’isolation par NAP du SBC offre à chaque campus son propre routage et sa propre frontière de sécurité sur la même instance.

Mécanismes de la couche Asterisk pertinents à la frontière du SBC

VitalPBX est une interface web soignée par-dessus Asterisk, et chaque interaction avec le SBC se produit au niveau de la couche SIP d’Asterisk sous-jacente. Cinq comportements d’Asterisk reviennent systématiquement à la frontière du SBC et méritent attention lors de l’intégration.

L’identification des endpoints chan_pjsip est le premier comportement à maîtriser. Les versions actuelles de VitalPBX utilisent par défaut chan_pjsip, le pilote de canal moderne basé sur PJSIP, et le mode d’identification côté VitalPBX (par adresse IP source, par nom d’utilisateur d’authentification ou par en-tête personnalisé) doit correspondre à ce que le SBC envoie, sinon Asterisk rejette l’INVITE avant l’exécution de toute logique de plan de numérotation. Décidez du mode une seule fois lors de la planification et documentez-le ; le reste de l’intégration en découle.

La réécriture des en-têtes Contact et Via est importante car Asterisk utilise sa propre adresse d’interface dans les en-têtes Contact et Via des INVITE sortants. Sur une VM cloud avec une IP publique, cette adresse est souvent une adresse privée RFC 1918 que l’opérateur ne peut pas router en retour. Le schéma le plus propre laisse le SBC gérer le masquage de topologie afin que l’adresse locale d’Asterisk n’atteigne jamais l’opérateur ni le terminal distant.

La traduction de méthode DTMF devient nécessaire lorsque l’opérateur envoie des SIP INFO alors qu’Asterisk utilise par défaut RFC 2833 (DTMF hors bande dans le flux RTP), ou lorsque des équipements anciens envoient encore des DTMF intra-bande. Le SBC traduit entre les méthodes par segment, de sorte que l’opérateur et VitalPBX voient chacun la méthode qu’ils attendent.

Le traitement des re-INVITE et du média direct peut interagir de manière problématique avec le NAT et l’ancrage média du SBC, même si le comportement par défaut d’Asterisk est de conserver le média sur le serveur. Le schéma le plus propre désactive le média direct sur l’endpoint de jonction VitalPBX qui communique avec le SBC, afin que le SBC conserve le contrôle complet du média.

La politique de minuterie de session sous RFC 4028 prévient les coupures silencieuses en milieu d’appel qui résultent d’une politique inadéquate entre Asterisk et l’opérateur. Ces coupures apparaissent comme aléatoires et intermittentes dans le journal complet d’Asterisk car la défaillance se produit un saut plus loin. Le SBC applique une politique de minuterie de session cohérente sur le segment opérateur sans nécessiter de modifications à la configuration de l’endpoint VitalPBX.

La documentation officielle d’interopérabilité ProSBC pour VitalPBX couvre les captures d’écran et les paramètres champ par champ pour chacun de ces points côté VitalPBX, dans les menus Network → Trunks et Settings → Technology Settings (PJSIP) du tableau de bord VitalPBX.

Approche de configuration pour VitalPBX + ProSBC

La configuration détaillée étape par étape se trouve dans la documentation officielle d’interopérabilité ProSBC pour VitalPBX, qui couvre les deux topologies de déploiement (jonction SIP et travailleurs à distance) avec des captures d’écran de chaque menu dans les deux produits. La logique d’intégration, à haut niveau, est la même sur tout SBC B2BUA :

Sécurité en bordure de VitalPBX

VitalPBX inclut son propre module pare-feu et sa configuration Fail2ban, qui restent tous deux en place après l’ajout du SBC. Le SBC ajoute les défenses qui doivent opérer avant que le trafic n’atteigne VitalPBX, ce qui est la position architecturale correcte pour la protection au niveau SIP.

• Protection contre le balayage d’enregistrement SIP : détecte les schémas de scan au niveau du SBC et bloque automatiquement la source, de sorte que les sondes n’atteignent jamais la pile PJSIP de VitalPBX.
• Atténuation DoS et DDoS : applique une limitation de débit sensible au SIP par adresse IP source, par NAP et par méthode SIP.
• Évaluation de la fraude à la taxation par appel : s’exécute sur chaque appel sortant en fonction du préfixe de destination, du tarif, de l’heure et de l’historique des schémas. Compatible avec les partenaires de l’Alliance TelcoBridges TransNexus et JeraSoft.
• Masquage de topologie : garantit que l’adresse IP publique du SBC est la seule adresse que l’opérateur et le terminal distant voient.
• Mise en liste de blocage et liste grise dynamiques : automatisent la réponse aux abus détectés et se combinent proprement avec le Fail2ban de VitalPBX pour le plan de gestion.
• Signature STIR/SHAKEN : s’exécute au niveau du SBC, puisque ni VitalPBX ni Asterisk n’effectuent nativement la signature STIR/SHAKEN. ProSBC s’intègre avec TransNexus ClearIP et Neustar via SIP.

Le modèle de sécurité SBC plus large couvre les cinq couches de sécurité en bordure de manière plus approfondie.

Questions fréquemment posées

Conclusion

VitalPBX est un IP-PBX complet basé sur Asterisk dont la base installée se concentre dans les topologies de déploiement que l’Internet ouvert pénalise le plus : les travailleurs à distance qui s’enregistrent à travers la frontière publique, l’hébergement multi-locataire de type ISP, et les secteurs verticaux (hôtellerie, centre de contact, éducation) où la fraude à la taxation et les abus par scanners SIP ont un coût financier réel. La réponse de VitalPBX à ce problème, lorsque l’entreprise y a été confrontée sur son propre système interne, a été de placer un SBC devant le PBX et de recommander la même architecture à sa base de clients.

Les fonctionnalités déterminantes lors de l’évaluation d’un SBC pour VitalPBX sont : l’architecture B2BUA pour le contrôle complet des segments de signalisation et de média, le transfert d’enregistrement et le transfert d’abonnement pour que la topologie de travail à distance fonctionne réellement, l’isolation de transport et de politique par NAP pour que la topologie de jonction SIP reste propre entre les opérateurs, l’isolation par locataire qui correspond au modèle de déploiement de l’édition Multi-Tenant, un modèle de partenaire STIR/SHAKEN ouvert pour que le choix du service de signature reste celui de l’opérateur, et une évaluation en libre-service pour que l’intégration puisse être confirmée sur un vrai VitalPBX avant tout engagement d’achat.