Exposer directement un serveur Asterisk à Internet, c’est lui faire encaisser de plein fouet les scans, les tentatives de fraude et les incompatibilités entre opérateurs. Un Session Border Controller (SBC) change la donne : placé en frontière de réseau, il filtre, protège et normalise le trafic SIP avant qu’il n’atteigne le PBX. Le logiciel libre de référence pour ce rôle est Kamailio, un proxy SIP capable d’encaisser des dizaines de milliers d’appels sur un serveur modeste. Ce tutoriel installe Kamailio devant Asterisk et active les protections essentielles d’un SBC.
Prérequis
- Un serveur Asterisk fonctionnel, qui sera placé derrière Kamailio.
- Un serveur Debian avec une adresse IP publique pour héberger Kamailio en frontière.
- Un accès root en SSH et des notions de SIP.
- Niveau : avancé. Temps estimé : 1 h 30. C’est le tutoriel le plus exigeant de la série.
À quoi sert vraiment un SBC
Le terme « SBC » recouvre plusieurs fonctions complémentaires, et les comprendre éclaire toute la configuration. La première est le filtrage de sécurité : le SBC reçoit le trafic SIP public, écarte les requêtes malveillantes et absorbe les attaques par saturation avant qu’elles n’atteignent le PBX. La deuxième est le masquage de topologie : il cache aux interlocuteurs externes l’architecture interne de votre réseau, ne présentant que sa propre adresse. La troisième est la normalisation : il répare les petites incompatibilités entre ce que produit un opérateur et ce qu’attend Asterisk. La quatrième est la répartition de charge : il peut distribuer les appels entre plusieurs serveurs Asterisk.
Kamailio assure toutes ces fonctions pour la signalisation. Un point essentiel à retenir d’emblée : Kamailio ne traite pas le média. Il manipule uniquement les messages SIP, à très haute vitesse. Le relais de la voix, lui, est confié à un composant séparé, rtpengine, que nous évoquerons. Cette séparation entre signalisation et média est ce qui rend Kamailio si performant.
Étape 1 — Installer Kamailio
Kamailio est désormais présent dans les dépôts officiels de Debian, mais pour disposer de la dernière version 6 et de tous ses modules, le dépôt officiel du projet est préférable. On ajoute la clé de signature et le dépôt correspondant à la version voulue, puis on installe Kamailio et ses modules utiles.
apt update
apt -y install kamailio kamailio-tls-modules kamailio-utils-modules
Cette commande installe le cœur de Kamailio ainsi que les modules pour le chiffrement TLS et les utilitaires courants. Selon vos besoins, d’autres paquets de modules existent (base de données, présence, etc.). Une fois l’installation terminée, le service est présent mais sa configuration par défaut ne fait rien d’utile pour notre cas : tout se joue dans le fichier de configuration que nous allons adapter.
Étape 2 — Comprendre kamailio.cfg
La configuration de Kamailio vit dans /etc/kamailio/kamailio.cfg. Ce fichier n’est pas une simple liste de réglages : c’est un véritable script de routage, écrit dans un langage propre à Kamailio, qui décide du sort de chaque message SIP reçu. On y trouve une section de définition des modules à charger (avec leurs paramètres) et un ou plusieurs blocs de routage qui s’exécutent à l’arrivée de chaque requête.
Cette nature programmable est la grande force de Kamailio, mais aussi sa difficulté : on ne « coche pas des cases », on écrit la logique. Pour un SBC devant Asterisk, le principe directeur est simple : valider la requête entrante, appliquer les protections, puis la relayer vers Asterisk. Abordez le fichier par petits incréments, en testant après chaque ajout, plutôt que de tout écrire d’un coup. Sauvegardez toujours une copie du fichier d’origine avant de le modifier.
Étape 3 — Relayer les appels vers Asterisk
La fonction de base de notre SBC est de transmettre à Asterisk le trafic qu’il a jugé légitime. Le module dispatcher est conçu pour cela : il maintient une liste de destinations — ici votre serveur Asterisk — et y achemine les requêtes, avec en prime la capacité de répartir la charge si vous ajoutez plusieurs serveurs plus tard.
On déclare le module et la passerelle vers Asterisk, puis, dans le bloc de routage, on appelle la fonction de sélection de destination avant de relayer. Le principe est qu’une requête validée par les étapes de sécurité est confiée au dispatcher, qui choisit le serveur Asterisk disponible et y envoie le message. Asterisk, de son côté, n’accepte alors le trafic que depuis l’adresse de Kamailio, ce qui ferme la porte à toute connexion directe depuis Internet. Cette configuration en deux temps — Kamailio public, Asterisk privé — est l’ossature même d’un déploiement protégé par SBC.
Étape 4 — Bloquer les attaques par saturation
Un serveur SIP exposé subit en permanence des vagues de requêtes automatisées. Le module pike détecte les sources qui envoient un trop grand nombre de requêtes en peu de temps et permet de les bannir temporairement, exactement comme un videur écarte celui qui tambourine à la porte. On le configure avec trois paramètres clés.
modparam("pike", "sampling_time_unit", 2)
modparam("pike", "reqs_density_per_unit", 30)
modparam("pike", "remove_latency", 120)
Le premier paramètre fixe l’unité de temps d’échantillonnage, le deuxième le nombre de requêtes tolérées par unité avant de considérer la source comme abusive, et le troisième la durée pendant laquelle une adresse repérée reste surveillée. Dans le bloc de routage, on interroge pike à chaque requête : si la source dépasse le seuil, on la bloque avant tout traitement. Ce simple réflexe écarte l’essentiel du trafic de scan et d’attaque, soulageant d’autant Asterisk.
Étape 5 — Masquer la topologie interne
Par défaut, les messages SIP exposent des informations sur le chemin qu’ils empruntent, révélant l’existence et l’adresse de votre Asterisk interne. Le module topoh, disponible dans Kamailio 6, chiffre ces informations de routage de sorte que l’extérieur ne voie que Kamailio. Pour un attaquant, l’infrastructure interne devient invisible : il ne peut s’en prendre qu’à la frontière, soigneusement durcie.
L’activation de topoh est légère côté configuration — charger le module et définir une clé de chiffrement — mais son effet sur la posture de sécurité est important. Combiné au filtrage de pike, il transforme votre Asterisk en serveur que l’extérieur ne sait même pas localiser, ce qui réduit considérablement la surface d’attaque exploitable. C’est une protection passive qui ne gêne en rien le fonctionnement légitime des appels.
Étape 6 — Confier le média à rtpengine
Puisque Kamailio ne touche pas à la voix, il faut un composant qui relaie le média entre l’extérieur et Asterisk, en particulier pour traverser le NAT. Ce rôle revient à rtpengine, un relais média performant qui s’installe à côté de Kamailio et dialogue avec lui. Kamailio, en traitant la signalisation, réécrit les informations média pour que le flux passe par rtpengine plutôt qu’en direct.
modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2223")
Ce paramètre indique à Kamailio comment joindre rtpengine, ici sur la machine locale. Dans le bloc de routage, on demande à rtpengine de prendre en charge le média à l’établissement de l’appel et de le libérer à la fin. Le résultat est une chaîne complète : Kamailio gère la signalisation et la sécurité, rtpengine relaie la voix, et Asterisk, à l’abri derrière eux, se concentre sur la logique d’appel. Chacun fait une chose et la fait bien.
Étape 7 — Démarrer et tester
Une fois la configuration en place, vérifiez sa validité avant de démarrer, car une erreur de syntaxe empêche Kamailio de se lancer. Kamailio offre un mode de vérification qui analyse le fichier sans démarrer le service.
kamailio -c -f /etc/kamailio/kamailio.cfg
systemctl restart kamailio
systemctl status kamailio
La première commande contrôle la configuration et signale toute erreur de syntaxe avec son numéro de ligne. Si elle ne renvoie pas d’erreur, on redémarre le service et on vérifie qu’il tourne. Testez ensuite un appel réel traversant Kamailio : il doit atteindre Asterisk et la voix circuler via rtpengine. Pour observer ce qui se passe, les outils de diagnostic SIP comme sngrep, présentés dans le tutoriel diagnostiquer la qualité d’appel SIP, sont précieux pour confirmer que le trafic suit bien le chemin attendu.
L’architecture cible et la bascule progressive
Avant de vous lancer, visualisez l’architecture finale, car elle guide chaque décision. Sur Internet, une seule adresse est exposée : celle de Kamailio, accompagnée de rtpengine pour le média. Derrière, sur un réseau privé inaccessible directement depuis l’extérieur, se trouve Asterisk, configuré pour n’accepter le trafic SIP que depuis l’adresse de Kamailio. Les opérateurs et les postes distants pointent vers Kamailio ; Asterisk ne voit plus jamais le trafic brut d’Internet. C’est ce cloisonnement qui fait toute la valeur de l’opération.
La bascule vers cette architecture mérite d’être progressive, car interposer un SBC devant un système en production n’est pas anodin. Une bonne méthode consiste à monter Kamailio en parallèle, à le tester d’abord avec un trunk ou un poste de test pointé vers lui, et à vérifier sur ce périmètre réduit que la signalisation et le média circulent correctement. Ce n’est qu’une fois ce chemin validé de bout en bout que l’on redirige progressivement le trafic réel vers le SBC. Conservez la possibilité de revenir en arrière tant que la nouvelle voie n’est pas éprouvée : un SBC mal réglé peut couper toute la téléphonie, et la prudence d’une migration par étapes évite de transformer une amélioration de sécurité en panne générale.
Gardez enfin à l’esprit que le SBC ne remplace pas les autres protections : il s’y ajoute. Les mots de passe d’extension robustes, la restriction des destinations internationales et le chiffrement restent nécessaires sur Asterisk. Le SBC constitue une première ligne de défense en frontière, pas une dispense des bonnes pratiques en profondeur. La sécurité d’une installation téléphonique se construit en couches, et Kamailio en est la plus extérieure, celle qui encaisse le premier choc.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Kamailio refuse de démarrer | Erreur de syntaxe dans kamailio.cfg | Lancer kamailio -c et corriger la ligne signalée |
| Appels qui n’atteignent pas Asterisk | Dispatcher mal configuré ou Asterisk filtre Kamailio | Vérifier la destination dispatcher et l’ACL d’Asterisk |
| Appel établi sans audio | rtpengine non sollicité ou arrêté | Vérifier le service rtpengine et le paramètre socket |
| Trafic d’attaque qui passe | pike non interrogé dans le routage | Appeler pike au début du bloc de routage |
| Topologie toujours visible | topoh non chargé | Charger et configurer le module topoh |
Tutoriels associés
- Le serveur protégé : revoir la sécurisation d’un PBX contre la fraude (principes transposables).
- Observer le trafic : diagnostiquer la qualité d’appel SIP avec sngrep et Homer.
Pour aller plus loin
- Retour au guide : Téléphonie IP avancée : 3CX, Issabel et softphones WebRTC.
- Documentation officielle : documentation Kamailio.
Questions fréquentes
Un SBC est-il nécessaire pour une petite installation ?
Pas toujours. En dessous d’une centaine de postes et avec un PBX bien sécurisé, on peut s’en passer. Le SBC devient utile pour masquer la topologie, absorber les attaques à grande échelle, répartir la charge ou résoudre des incompatibilités entre opérateurs.
Pourquoi Kamailio ne gère-t-il pas le média ?
C’est un choix d’architecture qui fait sa performance. En ne traitant que la signalisation, Kamailio reste extrêmement rapide. Le média, gourmand en bande passante, est confié à rtpengine, spécialisé pour ce rôle. Chaque composant est optimisé pour sa tâche.
Kamailio remplace-t-il Asterisk ?
Non, il le complète. Kamailio est un proxy SIP de frontière ; Asterisk est le moteur d’appel qui gère les extensions, les boîtes vocales, les files. On les associe : Kamailio en garde, Asterisk en cœur.
Peut-on mettre plusieurs Asterisk derrière un Kamailio ?
Oui, c’est même un usage classique. Le module dispatcher répartit les appels entre plusieurs serveurs Asterisk, ce qui apporte de la résilience et permet de monter en charge sans changer le point d’entrée public.
Kamailio fonctionne-t-il aussi devant FreePBX ou Issabel ?
Oui, car ces solutions reposent sur Asterisk. Le principe est identique : Kamailio en frontière publique, la distribution FreePBX ou Issabel en cœur privé, n’acceptant le SIP que depuis le SBC. La configuration côté Kamailio ne change pas.
Faut-il TLS entre Kamailio et Asterisk ?
Sur un réseau privé maîtrisé entre les deux serveurs, le SIP en clair peut suffire. Mais si Kamailio et Asterisk communiquent via un réseau non entièrement fiable, chiffrer ce segment en TLS ajoute une protection cohérente avec le chiffrement appliqué côté public.
Le SBC ralentit-il les appels ?
De façon négligeable pour la signalisation, que Kamailio traite à très grande vitesse. Le média transitant par rtpengine ajoute un saut réseau, mais l’impact sur la latence reste faible si le relais est correctement dimensionné et proche des participants.