RTPBleed et Asterisk : les appels d’Asterisk sous écoute

Asterisk souffre d’un problème assez grave permettant à un attaquant d’écouter simplement vos conversations. Une attaque de l’homme du milieu (man-in-the-middle), sans être vraiment au milieu d’ailleurs, permet de redirriger les flux RTP assez facilement.

Asterisk souffre d’un problème assez grave permettant à un attaquant d’écouter simplement vos conversations. Une attaque de l’homme du milieu (man-in-the-middle), sans être vraiment au milieu d’ailleurs, permet de rediriger les flux RTP assez facilement.

L’annonce a été faite il y a quelques jours (31/08/2017). Il s’agit en fait d’un vieux bug datant de 2011 qui a été réintroduit au premier trimestre 2013. Le premier report annonçant la régression date de mai dernier ainsi que le patch (fournit pour test). L’annonce officielle a été faite le 31 août dernier.

Quelles sont les versions vulnérables ?

Toutes les versions d’Asterisk entre la 11.4.0 à la 14.6.1 sont malheureusement touchées.

Dans quel cas le serveur Asterisk est vulnérable ?

Quand le serveur Asterisk fonctionne avec des postes derrière un routeur NAT, il est nécessaire de mettre en oeuvre des actions afin de router correctement les paquets voix. Le protocole SIP s’appuie sur le protocole RTP afin de transporter la voix et le protocole SDP afin que les user-agents (UA) puissent négocier entre eux des éléments comme les codecs, adresses et ports. Ces éléments sont échangés en clair sur le réseau.
Pour permettre ces négociations, le serveur Asterisk est configuré (fichier sip.conf) avec les options nat=yes et strictrtp=yes. De plus, ces options sont configurées ainsi par défaut !

Comment exploiter la faille ?

Un attaquant doit envoyer des paquets RTP au serveur Asterisk sur un port alloué pour recevoir un flux RTP. Si le serveur est vulnérable, alors le serveur Asterisk répond à l’assaillant en relayant les paquets RTP du destinataire véritable. Il est ensuite aisé avec des outils comme Wireshark de décoder le flux audio.

Quelles sont les actions de mitigation envisageable ?

  • La première recommandation est de ne pas transporter les flux SIP et RTP sur internet en clair, mais d’utiliser un tunnel VPN. Si cela n’est pas possible pour diverses raisons bonnes ou mauvaises, voici d’autres solutions :
  • application du patch fournit par Asterisk (https://raw.githubusercontent.com/kapejod/rtpnatscan/master/patches/asterisk/too-short-rtcp-bugfix.diff) qui actuellement limite la fenêtre temps de l’attaque aux toutes premières millisecondes.
  • éviter l’option nat=yes si possible
  • chiffrer les flux RTP avec SRTP (je vous invite aussi à chiffrer les flux SIP et à utiliser le protocole de transport TCP uniquement pour ce dernier afin de fiabiliser les échanges au lieu de l’UDP)
  • ajouter une option de configuration à vos peers SIP afin de prioriser les paquets RTP venant de l’adresse IP apprises au travers de l’échange initial effectué via le protocole SIP.

Par ailleurs, si vos postes IP et vos fournisseurs de trunk SIP utilisent des adresses IP fixes et connues, la mise en oeuvre d’une règle sur votre firewall bloquant l’accès aux ports UDP 10000 à 20000 (ports RTP utilisés par défaut par un serveur Aterisk) uniquement à partir de ces adresses apporte une protection suffisante.

Comment vérifier si mon serveur Asterisk est vulnérable ?

L’outil rtpnatscan permet de tester votre serveur Asterisk.

Références :

Nouvelle version d’Astlinux 1.2.2 supportant Asterisk 13

Astlinux 1.2.2 vient de sortir. Découvrez les nouveautés d’un IPBX Asterisk embarqué et sécurisé prêt à l’emploi.

L’équipe d’Astlinux vient de sortir une nouvelle version. En dehors des habituelles corrections de bugs ou autres correctifs de sécurité (glibc « GHOST » et OpenSSL), mises à jour (noyau 3.2.66 et Asterisk) et améliorations de l’interface web, la grande nouveauté vient de la prise en charge de Asterisk 13 incluant la stack PJSIP. Toutes les versions d’Astlinux 1.2.2 (version d’Asterisk 1.8 , 11 et 13) intègrent aussi l’application de monitoring monit.

FritzBox : fonctionnalités avancées de VoIP / SIP

Modification avancée des paramètres VoiP des routeurs FritzBox : codec, VAD, détection des silences …

Certaines FritzBox fournissent un service de standard téléphonique (IPBX). Vous pouvez raccorder une ligne analogique, numérique ou SIP à votre équipement ainsi que des postes SIP, analogique, numérique ou DECT. Les services fournis permet de répondre aux attentes des TPE sans aucun problème.

Il peut parfois être utile d’accéder aux paramètres avancées non accessibles via l’interface web. Nous allons voir comment. Tout d’abord, vous devez vous connecter via telnet à votre FritzBox. Si vous ne savez pas comment faire, je vous invite à lire ce post : comment activer le service telnet de ma FritzBox.

La configuration se fait dans un seul fichier, /var/flash/voip.cfg

Pour éditer ce fichier, il faut utiliser nvi :

nvi /var/flash/voip.cfg

Bien entendu, il ne faut modifier les éléments de ce fichier que si vous savez ce que vous faites. Une mauvaise manipulation pourrait rendre inopérant les services de téléphonie de votre FritzBox.

Nous allons voir comment modifier les codecs et l’ordre de ceux-ci. Pour cela, il faut localiser les 2 lignes suivantes :

use_audiocodecs = no;
audiocodecs = "PCMA", "PCMU", "G726-32", "G726-40", "G726-24";

C’est la configuration par défaut. La première variable (use_audiocodecs) avec une valeur à « yes » permet de dire à la FritzBox d’utiliser les codecs listés dans audiocodecs dans l’ordre de préférence indiqué. Par défaut, la FritzBox utilise le codec selon l’ordre annoncé par l’opérateur. Nous pouvons forcer les priorités ainsi :

use_audiocodecs = yes;
audiocodecs = "G729", "PCMA", "PCMU", "G726-32", "G726-40", "G726-24";

Après avoir réalisé ces modifications, il faut arrêter, puis redémarrer le daemon VoIP :

voipd -s
voipd

Maintenant, il est possible d’utiliser le codec G11 en priorité afin d’avoir une meilleure qualité audio.

Nous allons voir comment activer la détection de silence et la fonction VAD (voice activity detection). Vous pourriez avoir besoin de ces fonctions si votre ligne dispose d’un débit limité.

A la fin du fichier voip.cfg , vous avez la variable rtpstream :

rtpstream {
    voice_activity_detection {
        vad_enabled = vadenabled_no;
        vad_threshold = 10000;
        }
        plc {
            in_the_stack = yes;
        }
        jitter {
            auto_on = yes;
            in_ms = 50;
            in_packets = 0;
        }
        rtcp_enabled = yes;
        silence_detection = no;
}

Que vous allez modifier comme suit :

rtpstream {
    voice_activity_detection {
        vad_enabled = vadenabled_yes;
        vad_threshold = 10000;
        }
        plc {
            in_the_stack = yes;
        }
        jitter {
            auto_on = yes;
            in_ms = 50;
            in_packets = 0;
        }
        rtcp_enabled = yes;
        silence_detection = yes;
}

La valeur du threshold étant à adapter selon votre environnement (faites des tests).

Je vous laisse découvrir les différents paramètres.

PyFreeBilling : comment démarrer

Vous souhaitez utiliser PyFreeBilling, Softswitch VoIP opensource basé sur FreeSwitch, mais vous ne savez pas par où commencer. Après avoir suivi la documentation d’installation sur un serveur Ubuntu 14.04 LTS 64 bits, je vous encourage à lire cet article intitulé : PyFreeBilling : quick start .

Vous souhaitez utiliser PyFreeBilling, Softswitch VoIP opensource basé sur FreeSwitch, mais vous ne savez pas par où commencer. Après avoir suivi la documentation d’installation sur un serveur Ubuntu 14.04 LTS 64 bits, je vous encourage à lire cet article intitulé : PyFreeBilling : quick start .

Pour ceux qui ne connaissent pas encore PyFreeBilling, vous disposez d’un serveur permettant d’interconnecter des clients SIP avec des fournisseurs VoIP,  établir des règles de routage, définir des grilles tarifaires, facturer les clients et fournir un extranet à ces mêmes clients.

PyFreeBilling a été conçu pour supporter une montée en charge importante et fiabilité.

La solution avance assez vite, la nouvelle version étant attendue pour la fin de l’année.

Freeswitch : sortie de la version stable 1.4 (la 1.4.4 pour être précis)

Sortie de la version stable 1.4 de Freeswitch, célèbre plate-forme de téléphonie VoIP et TDM open source.

L’équipe de Freeswitch vient de libérer la première version stable de la branche 1.4, la 1.4.4, les autres étant des versions beta.

Les nouveautés sont nombreuses, les principales étant :

  • WebRTC
  • Séparation de la stack RTP du SIP
  • Suppression de nombreuses librairies tierces
  • Support des nouvelles versions de librairies comme SQLite, OpenSSL …
  • Optimisation du code apportant une plus grande stabilité et fiabilité.

La branche 1.2 va être déclarée en fin de vie. Aussi, je vous invite à tester vos applications avec la branche 1.4 dès maintenant et de planifier les migrations.

Pour ma part, PyFreeBilling est compatible avec la branche 1.4 depuis quelques mois déjà, donc ceux qui veulent migrer leur version de FreeSwitch peuvent le faire sans arrière pensée.

[PyFreeBilling] version 1.3

La nouvelle version du logiciel open source (GPL) de facturation et de routage VoIP basé sur Freeswitch, PyFreeBilling vient de sortir. La grosse nouveauté est la gestion des numéros entrants (SDA ou DID).

Je vous laisse découvrir les autres news sur le site du projet.

Pyfreebilling : lancement du site

Le site de Pyfreebilling , softswitch voip et plateforme de facturation pour l’activité d’opérateur Wholesale vient d’être lancé. Vous y trouverez une présentation du projet, des screenshots (je vais en ajouter d’autres, pas d’inquiétude), le détail des mise à jour et très important la licence du projet (GPL v3). Une section blog a aussi été créée et bien entendu un lien vers le repo bitbucket.

Et maintenant, ben c’est la nouvelle mise à jour, la 1.3 (vous avez le détail sur le site 😉 )

Howto : comment utiliser Sipp pour tester la montée en charge de votre serveur SIP ?

Après le précédent guide détaillant l’installation de sipp sur debian/centos, il est temps maintenant d’apprendre à utiliser ce fabuleux outil.

Le scénario du jour (sur sipp, nous avons la possibilité de créer de nombreux scenarii ce qui apporte une grande richesse à cet outil open source) a pour but de tester la montée en charge de votre tout nouveau serveur SIP que ce soit un Asterisk, un Freeswitch, un Kamailio, un Opensips ou tout autre solution libre ou propriétaire.

Voici le schéma du test, SIPP et le proxy SIP étant installés sur 2 serveurs différents :

Sipp UAC —> Proxy SIP —> Sipp UAS

Sipp Client :

./sipp -sf uac_pcap.xml -d 10000 -s 0917000000 10.254.254.249:5060 -l 10000 -mi 10.254.254.9 -i 10.254.254.9 -mp 6000 -r 1

Explication de la commande :

  • -sf uac_pcap.xml : exécute le scénario contenu dans le fichier xml
  • -d 1000 : définit la durée de l’appel en ms (durée de l’instruction pause du script pour être précis)
  • -s 0917000000 : définit le username de la requête URI 10.254.254.249:5060 : serveur à tester avec le port d’écoute SIP
  • -l 10000 : nombre max d’appels simultanés
  • -mi 10.254.254.9 : adresse IP locale pour le flux média
  • -i 10.254.254.9 : adresse IP de l’interface locale d’écoute -mp 6000 : port local RTP echo (défaut : 6000)
  • -r 1 : nombre d’appels par seconde

Sipp Serveur :

./sipp -sf uas.xml -p 5062 -i 192.168.52.221 -mi 192.168.52.221 -mp 7000

La configuration de votre proxy SIP est à adapter en conséquence : les 2 comptes SIP (client et serveur) et la table de routage des appels.

Bon test.

Comment résoudre une mauvaise qualité de communication VoIP ?

Vous avez déployé une solution de VoIP et vous rencontrez des problèmes de qualité. Alors, que les communications doivent être d’une qualité équivalente au numéris ou proche (dans le cas de compression), vous subissez des blancs, de l’écho, une voix métallique voir même des coupures de communications.

Table des matières

Introduction

Dans l’article, je vais considérer que le site dispose d’un câblage informatique de qualité suffisante et que le matériel déployé est de bonne qualité (switch, routeur, IPBX, postes téléphoniques, passerelles …).

Déterminer l’origine des problèmes

Il va être important dans un premier de temps de déterminer si le problème vient des communications externes ou si le problème intervient aussi sur les communications sur le même site. Si les appels entre 2 postes IP (important) sur le même site (avec l’IPBX en local si nous ne sommes pas en centrex) sont dégradés, il va falloir dans un premier temps résoudre ce problème. Pour cela, il faut vérifier quelques paramètres cruciaux :

  1. quel est le codec utilisé : le codec a une influence sur la qualité perçue. si on a un PABX, utilisez le G711 voire G722 (codec large bande permettant de mieux reproduire la voix). En mode centrex, il peut être souhaitable d’économiser la bande passante, alors le G729 sera le codec de choix.
  2. le mode peer to peer activé : si oui, le flux RTP reste sur le réseau local en mode centrex, la connexion se faisant de poste à poste. Le WAN n’intervient donc pas dans le flux voix en dehors de la signalisation (qui peut-être considéré dans un premier temps comme négligeable d’un point de vue bande passante si on le compare aux flux RTP). Sinon, pour un appel entre 2 postes sur le même site, nous avons 1 appel sortant et 1 appel entrant sur le site, il y a donc un impact sur le WAN.
  3. la fonction VAD (Voice Activity Detection) est-elle activée ? cette fonctionnalité intéressante permet de limiter la bande passante d’une communication en supprimant les paquets incluant les silences. Suivant les réglages, l’économie peut-être importante. Cette fonction est inutile en local, et doit-être désactivée. Elle est difficile a bien paramétrer, et en cas d’erreur les mots seront coupés, les communications pouvant devenir inaudibles.
  4. un VLAN voix a t’il été paramétré appliquant la CoS voix aux flux concernés ?
  5. vérifier que les équipements sont bien à jour, car une version firmware peut avoir un défaut expliquant le problème.

En général, les problèmes sont surtout rencontrés lors des appels externes. En effet, la bande passante est alors plus limitée, les communications passent parfois sur internet et le lien est aussi parfois partagé avec d’autres flux.

VoIP via internet

Je ne conseillerai jamais assez de ne pas transporter la voix sur internet. Internet n’a pas été conçu pour transporter des flux temps réels et ne sait pas garantir la qualité (cela ne veut pas dire que cela ne marche pas). De plus, la sécurité sera aussi difficile à assurer. Je vous laisse imaginer ce que je pense des offres de trunk SIP via internet. Il suffit d’aller voir la liste des failles de sécurité pour prendre peur, mais ce n’est pas le sujet du jour, mais d’un prochain article.

Autres informations essentielles

En plus des questions posées plus haut, il faut aussi obtenir d’autres informations :

  1. Nombre d’appels simultanés externes
  2. Bande passante du lien haut débit (en IP)
  3. Le lien est-il dédié à la voix ? si non, quels sont les mécanismes qui prioritisent la voix sur les autres flux ?
  4. Les flux voix empruntent ils internet ou restent sur le réseau de l’opérateur ?
  5. En mesurant les flux sur le lien, vous pourrez vérifier si le lien est saturé, si les règles sont bien appliquées ou si le lien souffre de perte de paquets ou de gigue.

Quelques pistes

Ne connaissant pas vos cas particuliers, je ne peux pas allez beaucoup plus loin, mais si vous avez des connaissances réseaux suffisantes et en répondant aux questions ci-dessous, vous avez toutes les billes pour trouver la source du problème. Pour vous aider un peu plus, on peut obtenir des informations intéressantes en écoutant la qualité de la voix.

  • Vous avez des blancs en court de communication, il faut regarder du côté de la VAD si elle est activée. Ensuite, cet effet peut-être causé par de la perte de paquet ou une gigue trop importante du lien WAN. Cela peut aussi être dû à une règle de QoS mal définie.
  • Vous avez des bruits ou des craquements. Ils sont souvent causés par une congestion du LAN ou du WAN.
  • Vous avez une voix de robot, regardez du côté de la perte de paquet dûe à une gigue trop importante. (reste à trouver la source de cette gigue).
  • Vous avez de l’écho. Cela est dû à un problème de réglage de l’echo canceller du PABX ou de la gateway.

J’écrirai prochainement un article détaillé sur les symptômes et les causes qui s’y rattachent.

Asterisk peut-il remplacer votre PABX ?

Lors de projet de renouvellement de leur PABX, beaucoup de personnes se pose la question de l’opportunité de migrer sur une solution open source comme Asterisk. La principale motivation étant de réaliser des économies, de récupérer l’exploitation en interne et de l’intégrer au sein de l’infrastructure informatique.

Table des matières

Historique

Asterisk a été créé en 1999 par Mark SPENCER (un gars exceptionnel que j’ai eu l’occasion de rencontrer plusieurs fois). Le code du logiciel est distribué en open source sous la licence GPL. Le site du projet est tout simplement www.asterisk.org

Présentation d’Asterisk

Asterisk est un logiciel permettant de mettre en oeuvre un PABX, c’est à dire de relier entre eux des téléphones de technologies différentes et des trunks. Les trunks sont des accès opérateurs, comme les accès numéris, analogique ou SIP. Asterisk est compatible avec tous les postes IP compatibles avec la norme SIP, IAX et SCCP. On peut aussi connecter des postes analogiques et des postes sans fil via des gateways. Une gamme impressionnante de carte permet de se raccorder aux réseaux des opérateurs.

Nous l’avons vu, au niveau des périphériques, l’offre est très importante et n’a pas à pâlir des solutions payantes concurrentes. Mais, car il y a un gros mais, quand vous installez Asterisk, vous n’obtenez pas un PABX. Vous avez une excellente base, mais sans programmation, il vous ne pouvait pas passer un appel. Afin de construire votre PABX, il vous faudra programmer toutes les fonctions dont vous avez besoin. C’est là que se situe toute la difficulté, car à moins de maîtriser les langages de programmation propre à Asterisk, vous arriverez juste à émettre et à recevoir des appels, mais sûrement pas à faire des interceptions et encore moins mettre en oeuvre la fonction patron-secrétaire. La mise en oeuvre de fonctionnalités évoluées et une intégration parfaite avec les postes nécessitent une excellente expertise. Vous remarquerez aussi que je n’ai pas parlé de fiabilité et de stabilité. Installer Asterisk pour une personne maîtrisant linux, n’est pas une chose compliquée notamment sur Centos. Sécuriser et fiabiliser cette même installation est autrement plus complexe, notamment quand le volume d’appels à traiter est assez important.

Les avantages d’Asterisk

Asterisk a pourtant des avantages à faire valoir par rapport aux PABX du marché. Quand vous achetez un PABX, vous ne pouvez installer que les postes du constructeurs, avec Asterisk vous avez le choix. Vous aurez (ou votre intégrateur) juste à adapter les scripts en conséquence. Vous n’avez plus de limite dans les programmations souhaitées et dans les circuits d’appels, problèmes par contre souvent rencontrés avec les PABX. Vous restez aussi maître des coûts d’évolution, en effet il n’y a pas de licences par utilisateurs, ou de cartes à ajouter. Il faudra par contre surveiller le dimensionnement du serveur.

Et la sécurité ?

J’ouvre un chapitre sur la sécurité. Le monde du PABX m’a souvent étonné par l’ignorance des risques associés. Combien d’entreprises ont vu leur PABX piratés ? mieux, combien se sont aperçues du piratage (en dehors de la facture) ?

Les PABX sont rarement en dernière version logicielle essentiellement pour des questions de coûts ou d’ignorance. Le parc est donc en production avec des failles de sécurité et des bugs non corrigés. Mais connaissez vous la liste des bugs et des failles de la version que utilisez chaque jour ? les hackers oui. Avec Asterisk, vous connaissez les bugs, vous pouvez ainsi mettre en place les procédures nécessaires pour les corriger ou les contourner, appliquer le dernier patch.

Le second point de la sécurité concerne les communications IP. A ce jour, Asterisk ne sait pas crypter les flux RTP (mais c’est en cours), mais peu de solutions constructeurs le proposent. Ceux qui ont ce besoin de part leur activité doivent garder cela en mémoire et bien étudier les fiches techniques des constructeurs afin de vérifier si ce point du cahier des charges est parfaitement rempli.

Asterisk est une solution logicielle qui demande de la maintenance logicielle. Souvent cet effort est oublié par les entreprises quand elles intègrent une solution open source. Et pourtant, cette maintenance va garantir la sécurité, la stabilité et l’évolutivité de votre PABX.

Alors, puis-je installer Asterisk dans mon entreprise ?

L’objectif de l’article étant de répondre à la question : puis-je installer Asterisk dans mon entreprise?

La réponse est oui.

Ai-je un intérêt financier à le faire ?

Cela va dépendre de votre expertise, de la taille de votre entreprise et de votre cahier des charges. Il existe des intégrateurs qui ont développé à partir d’Asterisk des PABX soit en mode licence soit en mode appliance (serveur + Asterisk + scripts). Pour les entreprises aux besoins standardisés et sans expertise, cette alternative peut permettre de réaliser des économies tout en bénéficiant des avantages d’Asterisk.

Il faut vérifier tout de même que la solution ne devient pas closed source (vous vous retrouverez dans le cadre d’un PABX constructeur).

Conclusion

En conclusion, je vais parler de mes propres expériences. Je travaille sur Asterisk depuis 2001 et j’ai donc suivi l’évolution impressionnante du projet. J’ai réalisé des intégrations pour des centres d’appels, des entreprises multi site et du centrex. J’utilise aussi Asterisk pour combler des lacunes de PABX en place. Le projet est extrêmement puissant et ouvre des possibilités infinies à qui sait les exploiter. 😉