Intégration SBC avec FreePBX : comment placer un contrôleur de session en bordure devant FreePBX

FreePBX est le PBX IP open source le plus largement déployé au monde. Il s’agit d’une couche d’interface graphique au-dessus d’Asterisk qui offre aux petites entreprises, aux MSP et aux ITSP une plateforme de téléphonie complète : postes, files d’attente, SVI, messagerie vocale, conférence, enregistrements et configuration des trunks SIP via une interface web. La plupart des serveurs FreePBX fonctionnent sur une VM cloud (Vultr, Linode, DigitalOcean, AWS) avec une IP publique et le SIP exposé à Internet par défaut.

Ce déploiement par défaut est aussi la raison pour laquelle FreePBX est l’une des cibles VoIP les plus intensément sondées sur l’Internet public. Les scanners automatisés connaissent les ports par défaut, les modules par défaut et les schémas de réponse par défaut. Un serveur FreePBX fraîchement installé accumule typiquement des milliers de tentatives de scan SIP dans la journée suivant sa mise en ligne, et un seul poste compromis peut générer suffisamment de fraude à la surtaxe pour atteindre 20 000 $ avant que le système de gestion des risques de l’opérateur n’alerte quelqu’un.

Un Session Border Controller (SBC) en bordure de réseau est ce qui élimine proprement cette exposition. Le SBC absorbe le trafic provenant de l’Internet public, normalise le SIP de l’opérateur en entrée, masque FreePBX de tout ce qui n’a pas sa place sur le chemin d’appel, et permet au PBX de se concentrer sur ce qu’il fait vraiment bien : les postes, les plans de numérotation et le contrôle d’appels. Cet article couvre ce que le SBC ajoute devant FreePBX, les comportements SIP spécifiques à Asterisk que le SBC doit gérer, comment le module commercial « Session Border Controller » de Sangoma s’y rapporte (et où il atteint ses limites), ainsi que l’approche de configuration pour un déploiement en production.

Ce qu’un SBC ajoute devant FreePBX

FreePBX exécute la pile SIP d’Asterisk. Les postes, files d’attente, SVI, messagerie vocale et la logique de plan de numérotation résident tous dans FreePBX. Pour un trunk unique vers un seul opérateur sur un réseau local privé sans exposition à Internet, cela suffit en soi. Le SBC devient nécessaire dès que le déploiement touche l’Internet public, termine plus d’un opérateur, ou achemine des appels soumis à une réglementation.

L’exposition à Internet que FreePBX hérite par défaut

La plupart des serveurs FreePBX fonctionnent sur des VM cloud avec une IP publique, et la plupart des fournisseurs de trunks SIP s’attendent à ce que le PBX soit joignable sur UDP/5060 ou TLS/5061 depuis les adresses de signalisation de l’opérateur. Le même port utilisé par l’opérateur est celui qu’utilise chaque scanner sur Internet. Le SBC absorbe toute cette exposition : l’IP publique appartient au SBC, le listener SIP réside sur le SBC, et FreePBX passe sur une interface privée que l’opérateur et les scanners ne voient jamais.

Basculement multi-opérateur et routage au moindre coût

FreePBX termine proprement un trunk par opérateur. Dès que le déploiement nécessite des opérateurs principal et secondaire, ou un routage par tarif entre trois fournisseurs, le SBC devient le cerveau du routage. Chaque opérateur se trouve derrière son propre NAP avec son propre profil SIP et son authentification, et l’ordonnancement des routes détermine quel opérateur achemine chaque appel. FreePBX continue de ne voir qu’un seul trunk de son côté.

Normalisation SIP entre Asterisk et l’opérateur

Asterisk a ses propres conventions concernant le SIP. L’opérateur a les siennes. Les deux ensembles de conventions correspondent rarement exactement. Les P-headers transportent des informations qu’un côté exige et que l’autre rejette, les formats Contact et From diffèrent, l’ordre d’offre des codecs varie, et les minuteurs de session se comportent différemment selon les fournisseurs. Le moteur de manipulation des en-têtes SIP du SBC normalise le segment opérateur sans rien changer à la façon dont Asterisk communique de son côté.

STIR/SHAKEN et authentification des appels

FreePBX ne dispose d’aucun mécanisme natif de signature STIR/SHAKEN. Pour les déploiements nord-américains, le contrôle d’attestation, l’intégration du service de signature et la politique de contournement en cas de panne appartiennent tous à la couche SBC. ProSBC s’intègre aux services de signature STIR/SHAKEN tels que TransNexus ClearIP et Neustar via SIP, avec l’ordonnancement des routes et le Reason Cause Mapping assurant la redondance lorsqu’un service de signature est injoignable. Les consultations CNAM et les recherches LNP s’intègrent au même moteur de routage.

Chiffrement côté public

Asterisk prend en charge TLS et SRTP, et de nombreux déploiements FreePBX activent les deux pour le trafic interne des postes. Le SBC porte la même exigence de chiffrement côté opérateur et fait le pont entre les différences par segment. Un trunk côté opérateur en UDP/5060 avec RTP non chiffré peut coexister avec un trunk côté FreePBX en TLS/5061 avec SRTP, le SBC effectuant l’échange de clés indépendamment de chaque côté.

Scoring de fraude exécuté avant que l’appel n’atteigne FreePBX

La fraude à la surtaxe contre les déploiements PBX open source est une économie d’attaque bien établie. Le SBC évalue chaque appel en fonction du préfixe de destination, du tarif, de l’heure et de l’historique des schémas ; le trafic à haut risque est bloqué ou redirigé avant qu’Asterisk n’alloue un canal. La détection de fraude exécutée sur le SBC capture le schéma d’abus pour lequel le scoring de risque par appel est conçu : un poste compromis qui consomme des minutes internationales pendant la nuit.

Un seul ProSBC protège un ou plusieurs serveurs FreePBX, présentant une frontière publique contrôlée aux opérateurs et absorbant toute l’exposition côté Internet. Cliquez pour agrandir.

Le module « Session Border Controller » de Sangoma n’est pas la même chose

Sangoma vend un module commercial FreePBX sous le nom « Session Border Controller ». Il ajoute un filtrage SIP, une limitation de débit et des contrôles de signalisation au sein du serveur FreePBX. C’est une couche de durcissement utile pour le PBX lui-même, et pour un petit déploiement mono-site avec un seul opérateur et une liste blanche d’IP connues, il résout une partie du problème de bruit.

Ce qu’il ne peut pas faire, c’est assumer le rôle de SBC en bordure de réseau. Le module fonctionne à l’intérieur de FreePBX, sur le même hôte, derrière la même IP publique. Il n’y a ni terminaison B2BUA, ni frontière de chiffrement par segment, ni masquage de topologie vis-à-vis de l’opérateur, ni isolation entre la couche de sécurité et la couche de traitement des appels. Si une attaque SIP sature le module, elle sature FreePBX avec, car ils partagent le système d’exploitation, la pile réseau du noyau et le CPU.

Un véritable SBC est un équipement ou une VM distinct en bordure de réseau, avec sa propre IP publique, sa propre pile SIP et son propre domaine de défaillance. Il termine chaque dialogue SIP de chaque côté, en recrée un nouveau de l’autre côté, et contrôle chaque en-tête, codec et choix de transport entre les deux. Ce rôle ne peut pas être rempli par un module fonctionnant à l’intérieur du PBX qu’il est censé protéger. La suite de cet article porte sur le déploiement d’un véritable SBC, tel que ProSBC, entre FreePBX et l’opérateur.

Pourquoi Fail2ban et iptables ne suffisent pas

Chaque administrateur FreePBX connaît Fail2ban. Il analyse le journal de sécurité d’Asterisk, repère les échecs d’authentification répétés depuis une IP source, et ajoute une règle iptables bloquant cette IP pendant une durée configurable. Pour le brute-forcing SSH, c’est exactement le bon outil. Pour les attaques SIP sur un PBX exposé à Internet, il présente trois lacunes structurelles.

Le timing réactif est la première lacune, car Fail2ban ne se déclenche qu’après qu’Asterisk a déjà enregistré quelque chose. Le trafic a déjà atteint le PBX, a été analysé, associé à un poste et rejeté. Chacune de ces étapes consomme du CPU. Un taux de scan de 100 requêtes par seconde par source, multiplié par les centaines d’IP sources qu’un scanner coordonné utilise, suffit à pousser la charge au-delà du seuil où Asterisk peut encore traiter les appels légitimes.

Les défaillances silencieuses surviennent quand les schémas d’attaque SIP ne déclenchent jamais de 401 ou 403. Les messages SIP malformés, les en-têtes surdimensionnés, les blocages de transaction de type slow-loris et les floods OPTIONS ne passent jamais à l’étape d’authentification. Ils monopolisent les ressources du parseur SIP sans produire la ligne de journal que Fail2ban surveille, et le PBX se dégrade silencieusement tandis que Fail2ban ne signale rien.

L’aveuglement de couche 3 constitue la troisième lacune, car iptables voit l’IP et le port, mais pas la méthode SIP ni le contenu. La limitation de débit SIP-aware nécessite d’inspecter le message SIP lui-même : limiter les INVITE par source indépendamment des REGISTER, appliquer un seuil différent à un opérateur connu qu’à une source inconnue, et distinguer un pic légitime d’un sondage coordonné. iptables ne peut pas faire cela. La protection SBC contre les attaques DoS SIP le peut, car elle analyse la couche SIP et applique des politiques par méthode, par source, par groupe de trunks et par seuil global.

Fail2ban reste utile dans l’architecture FreePBX-plus-SBC : il demeure sur le PBX comme défense pour les interfaces de gestion (SSH, l’interface d’administration FreePBX). Le SBC prend en charge la défense SIP en bordure de réseau.

Comportements SIP spécifiques à Asterisk que le SBC doit gérer

FreePBX est l’interface graphique. Asterisk est ce qui parle réellement SIP. Chaque particularité côté FreePBX est un comportement d’Asterisk que le SBC doit gérer proprement.

Identification des endpoints chan_pjsip

Les versions actuelles de FreePBX utilisent par défaut chan_pjsip, le pilote de canal moderne basé sur PJSIP. chan_pjsip identifie les requêtes entrantes par rapport à un endpoint configuré, et la méthode d’identification doit correspondre à ce que le SBC envoie. Les modes courants sont l’identification par IP source, par nom d’utilisateur d’authentification ou par un en-tête personnalisé. Si FreePBX attend une identification par IP et que le SBC envoie les requêtes depuis une adresse NAT-traduite, Asterisk rejette l’INVITE sans qu’aucune logique de plan de numérotation ne s’exécute. La correction est simple mais précise : configurer l’endpoint trunk FreePBX pour identifier par l’adresse réelle d’envoi du SBC, ou basculer le mode d’identification vers l’authentification par nom d’utilisateur et provisionner les identifiants des deux côtés.

Réécriture Contact et Via

Asterisk utilise sa propre adresse d’interface dans les en-têtes Contact et Via des INVITE sortants. Sur une VM cloud derrière une IP publique, cette adresse est souvent une adresse privée RFC 1918 vers laquelle l’opérateur ne peut pas router de retour. Asterisk dispose de ses propres paramètres pour l’annonce d’adresse externe, mais l’architecture plus propre consiste à laisser le SBC gérer le masquage de topologie pour tout le trafic sortant. FreePBX utilise son adresse locale ; le SBC la réécrit vers l’adresse publique du SBC avant que le message n’atteigne le réseau.

Discordances de méthode DTMF

FreePBX utilise par défaut le RFC 2833 (DTMF hors bande dans le flux RTP). Certains opérateurs envoient du SIP INFO. Certains équipements anciens envoient encore du DTMF dans la bande. Asterisk peut être configuré pour chacune des trois méthodes par endpoint, mais la négociation devient fragile quand l’opérateur et FreePBX ne s’accordent pas sur la méthode en usage. Le SBC traduit entre les méthodes DTMF par segment, de sorte que l’opérateur et FreePBX voient chacun la méthode attendue.

Gestion des REINVITE et du direct media

Le comportement par défaut d’Asterisk est de conserver les médias sur le serveur, mais l’option de négocier le direct media entre les endpoints existe et peut interagir de manière problématique avec le NAT, les attentes de l’opérateur quant au contrôle du chemin RTP, et l’ancrage média du SBC. Le schéma le plus propre consiste à désactiver le direct media sur l’endpoint trunk FreePBX qui communique avec le SBC, afin que le SBC conserve le contrôle total des médias et qu’il n’y ait qu’un seul chemin pour le RTP plutôt que deux.

Minuteurs de session et re-INVITE

Asterisk implémente les minuteurs de session SIP (RFC 4028) et peut être configuré pour les exiger, les accepter ou les refuser par endpoint. Une politique de minuteur discordante entre Asterisk et l’opérateur produit des coupures silencieuses en cours d’appel, qui 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 minuteur de session cohérente sur le segment opérateur sans nécessiter de modifications de la configuration de l’endpoint FreePBX.

Approche de configuration : FreePBX, SBC, opérateur

Les menus spécifiques diffèrent selon les fournisseurs de SBC, mais la logique d’intégration est la même sur tout SBC B2BUA.

FreePBX pour les MSP : un SBC, plusieurs locataires

Les MSP qui exploitent FreePBX en tant que service géré pour de nombreux clients PME rencontrent un problème de montée en charge spécifique : chaque instance FreePBX est son propre PBX exposé à Internet, avec sa propre surface d’attaque, ses propres identifiants opérateur et sa propre obligation STIR/SHAKEN. Durcir cinquante serveurs PBX individuellement représente cinquante fois le travail de durcir un seul.

Un seul SBC en bordure de réseau élimine ce problème. Chaque locataire FreePBX obtient son propre NAP sur le SBC partagé, avec ses propres règles de routage, son propre mapping opérateur et sa propre politique de sécurité. Le SBC gère la complexité côté opérateur une seule fois, présente une frontière publique contrôlée pour tous, et les serveurs FreePBX par locataire passent sur des interfaces privées où leur surface d’attaque est le réseau interne du MSP plutôt que l’Internet public. Le même modèle convient aux ITSP qui fournissent du PBX hébergé à de nombreux clients finaux, et aux opérateurs de centres de contact qui terminent plusieurs campagnes adossées à FreePBX. La page SBC pour les MSP couvre le schéma multi-locataire en détail.

Ce qu’il faut rechercher dans un SBC pour FreePBX

• L’architecture B2BUA est le minimum requis ; un proxy ne peut ni terminer le dialogue ni réécrire librement les en-têtes, ce qui est précisément le travail qu’une bordure FreePBX nécessite.
• Un positionnement agnostique du PBX est important car le SBC doit traiter FreePBX comme un simple NAP amont, afin que la couche SBC survive à un changement de PBX vers 3CX, NetSapiens ou PortaOne ultérieurement.
• Des règles de transport, de codecs et d’en-têtes par NAP donnent à chaque opérateur et à chaque locataire son propre profil, avec un transport indépendant (UDP, TCP, TLS) et des listes de codecs par groupe de trunks.
• Une intégration STIR/SHAKEN ouverte laisse le choix du partenaire de service de signature au client plutôt qu’au fournisseur de SBC ; ProSBC s’intègre à TransNexus ClearIP et Neustar via SIP, le modèle de déploiement en production, sans verrouillage sur l’un ou l’autre.
• La flexibilité cloud et virtualisation couvre AWS, Azure, VMware, KVM/Proxmox ou bare metal, pour qu’un déploiement cloud-natif côtoie un FreePBX hébergé en cloud, ou qu’un déploiement virtualisé fonctionne sur le même hyperviseur qu’un FreePBX on-premises.
• L’évaluation en libre-service signifie qu’une licence lab gratuite et permanente est disponible pour valider l’intégration avec votre configuration FreePBX réelle avant tout engagement commercial.
• La capacité de groupes de trunks à l’échelle des locataires devient le facteur décisif pour les MSP servant plus d’une poignée de locataires FreePBX depuis un seul SBC ; ProSBC supporte jusqu’à 1 024 NAP par serveur.

Sécurité à la bordure FreePBX

FreePBX inclut les modules de sécurité de Sangoma, Fail2ban et le journal de sécurité d’Asterisk. Le SBC les complète avec des défenses en couches qui opèrent avant que le trafic n’atteigne FreePBX, ce qui est la position architecturale correcte pour la protection SIP.

• Protection contre le scan d’enregistrement SIP : détecte les schémas de scan, bloque automatiquement la source et ne transmet jamais le sondage à FreePBX.
• Atténuation DoS et DDoS : applique une limitation de débit SIP-aware par IP source, par groupe de trunks et par méthode SIP, ce qu’iptables et Fail2ban ne peuvent pas faire.
• Détection de fraude à la surtaxe : évalue chaque appel sur le préfixe de destination, le débit d’appels, l’heure et l’historique des schémas, avec intégration optionnelle à TransNexus et YouMail pour des flux gérés.
• Masquage de topologie : l’IP publique du SBC est la seule adresse que l’opérateur voit, et la topologie sous-jacente de l’opérateur n’atteint jamais FreePBX.
• Blacklisting et greylisting dynamiques : automatisent la réponse aux abus détectés, incluant le greylisting par pourcentage de ProSBC pour une réponse graduée pendant l’investigation.

Le modèle complet de sécurité SBC couvre les cinq couches plus en détail.

Questions fréquentes

Conclusion

FreePBX est un PBX IP open source performant avec une vaste base installée. Ses forces résident dans les postes, les files d’attente, le SVI, la flexibilité du plan de numérotation et l’écosystème de modules FreePBX. Sa faiblesse, structurelle, est que le déploiement typique se trouve sur une VM cloud avec une IP publique et absorbe directement tout le poids des abus SIP provenant d’Internet. Le SBC est ce qui corrige cela sans réécrire le fonctionnement de FreePBX.

Les caractéristiques décisives lors de l’évaluation d’un SBC pour FreePBX sont l’architecture B2BUA pour un contrôle complet des en-têtes et du chiffrement, la politique de transport et de codecs par NAP pour que chaque opérateur et chaque locataire obtienne le bon profil, un modèle STIR/SHAKEN ouvert pour que le choix du service de signature reste le vôtre, un positionnement agnostique du PBX pour que le SBC survive à tout changement de PBX, et l’évaluation en libre-service pour confirmer que l’intégration fonctionne avec votre FreePBX réel avant de signer quoi que ce soit.