Étiquette : sip

SIP – PFSense : Comment résoudre une perte d’enregistrement

Les postes sont localisés sur un site et passe par internet pour accéder au serveur de téléphonie VoIP SIP qui est situé derrière un PFSense.

Vous constatez un défaut d’enregistrement de vos téléphones SIP pendant plusieurs minutes, ceux-ci affichant un message « No service » ou « prov. server failed ».

Vous devez surement faire face à un timeout d’état de la table NAT du firewall PFSense. En effet, ce timeout doit-être inférieur à la fréquence de ré-enregistrement des postes SIP !

Les délais d’expiration UDP par défaut dans PFSense sont trop faibles pour certains services VoIP. Si les téléphones fonctionnent principalement, mais se déconnectent de manière aléatoire, il faut modifier les options d’optimisation du pare-feu sur les mettant sur « Conservateur » sous Système> Avancé, onglet Pare-feu / NAT.

Un système de keep-alive (ou autrement un ping SIP avec un message OPTION) ou une réinscription sur le poste téléphonique pendant une durée plus faible, environ 20 à 30 secondes, peut également aider, et est souvent une meilleure solution.

Auteur MathiasPublié le
Warning: Attempt to read property "taxonomy" on int in /home/clients/31a622dd92c1a859487837e76fc9404d/web/bdt/wp-content/mu-plugins/clean-tag-less-3-articles.php on line 17

Warning: Attempt to read property "taxonomy" on int in /home/clients/31a622dd92c1a859487837e76fc9404d/web/bdt/wp-content/mu-plugins/clean-tag-less-3-articles.php on line 17
Catégories How to / Guide, VoipÉtiquettes

PyFreeBilling : softswitch voip 2.0 démo

La version définitive 2.0 de PyFreeBilling approche. La version beta publique a été rendue disponible.

Qu’est-ce que PyFreeBilling ?

Le logiciel PyFreeBilling est une solution sous licence Open Source AGPL permettant de gérer une activité d’opérateur télécom VoIP : gestion des clients, gestion des fournisseurs, gestion des grilles tarifaires ventes et achats, routage des appels et gestion des balances et reporting.

Merci à Hichem Ghazouani qui a mis à disposition la version 2.0 en démo.

Vous trouverez le lien ci-dessous :

https://51.255.173.122/ ( customer )
https://51.255.173.122/extranet/ (admin )

username : ghvoip
password: demo123 ( pmerci de ne pas changer le mot de passe !)

À qui est destiné PyFreeBilling ?

PyFreeBilling dans sa version 2 est destiné aux opérateurs VoIP permettant de router les appels entrants et sortants de ses clients vers différents opérateurs-fournisseurs de manière sûre, souple et simple.

 

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 :

Nouveaux postes SIP Digium : D6x

Digium vient d’annoncer la sortie de nouveaux postes SIP, les D6x qui viennent compléter la gamme IP Phones de Digium. Les modèles sont au nombre de 3, le D60 étant l’entrée de gamme, le D62 le milieu de gamme avec port gigabit et le D65 représentant le haut de gamme.

Les prix annoncés sont les suivants : D60 – $139 USD, D62 – $189 USD, et D65 – $239 USD.

A voir maintenant leurs qualités face à des postes Yealink ou Snom ayant fait leurs preuves !

Source : New Digium IP Phones are Now Available

Règles iptables afin de bloquer les scanners SIP

Les serveurs SIP (Asterisk, FreeSwitch … mais aussi les serveurs propriétaires) sont constamment scannés par des automates ou des humains avec pour seule idée, découvrir une faille à exploiter. En effet, les enjeux financiers sont importants.
Je partage avec vous ce jour, un script iptables pour bloquer les scanners SIP (à adapter notamment les ports si vous utilisez des différents de 5060).

iptables -N SIPDOS

iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “sundayddr” –algo bm –to 65535 -m comment –comment “deny sundayddr” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “sipsak” –algo bm –to 65535 -m comment –comment “deny sipsak” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “sipvicious” –algo bm –to 65535 -m comment –comment “deny sipvicious” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “friendly-scanner” –algo bm –to 65535 -m comment –comment “deny friendly-scanner” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “iWar” –algo bm –to 65535 -m comment –comment “deny iWar” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “sip-scan” –algo bm –to 65535 -m comment –comment “deny sip-scan” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “User-Agent: sipcli” –algo bm –to 65535 -m comment –comment “deny sipcli” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “User-Agent: Nmap NSE” –algo bm –to 65535 -m comment –comment “deny Nmap NSE” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “User-Agent: VaxSIPUserAgent” –algo bm –to 65535 -m comment –comment “deny VaxSIPUserAgent” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “From: sipp <sip:” –algo bm –to 65535 -m comment –comment “deny sipp” -j SIPDOS

iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “sundayddr” –algo bm –to 65535 -m comment –comment “deny sundayddr” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “sipsak” –algo bm –to 65535 -m comment –comment “deny sipsak” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “sipvicious” –algo bm –to 65535 -m comment –comment “deny sipvicious” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “friendly-scanner” –algo bm –to 65535 -m comment –comment “deny friendly-scanner” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “iWar” –algo bm –to 65535 -m comment –comment “deny iWar” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “sip-scan” –algo bm –to 65535 -m comment –comment “deny sip-scan” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “User-Agent: sipcli” –algo bm –to 65535 -m comment –comment “deny sipcli” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “User-Agent: Nmap NSE” –algo bm –to 65535 -m comment –comment “deny Nmap NSE” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “User-Agent: VaxSIPUserAgent” –algo bm –to 65535 -m comment –comment “deny VaxSIPUserAgent” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “From: sipp <sip:” –algo bm –to 65535 -m comment –comment “deny sipp” -j SIPDOS

iptables -A SIPDOS -j LOG –log-prefix “firewall-sipdos: ” –log-level 6
iptables -A SIPDOS -j DROP

Si vous avez des idées pour l’améliorer, toutes les suggestions sont les bienvenues, l’idée étant de faciliter la sécurisation des serveurs SIP au plus grand nombre.

Mises à jour :

  • 4 août 2016 : ajoût de règles + correction typo suite au commentaire de Ztur

PyFreeBilling disponible en italien

Grâce à l’excellent travail de Vito, PyFreeBilling est entièrement traduit en italien. Un grand merci à lui. Une traduction en français et espagnol est en cours.

Howto : comment configurer monit pour surveiller FreeSwitch

Guide détaillant la procédure de configuration de mont pour surveiller FreeSwitch et être alerter en cas de panne.

Il est essentiel de surveiller les services que nous déployons au sein de nos entreprises ou pour nos clients. Je vais vous présenter aujourd’hui comment superviser FreeSwitch avec Monit.

Monit est un outil léger open source (licence AGPL) permettant de superviser et de gérer les systèmes Unix. Il est capable d’exécuter des actions en cas de détection de défaillance.

Monit est disponible sous forme de paquet dans la plupart des distributions. L’installation sur un système basé sur Debian est très simple :

apt-get install monit

pour Centos, ce n’est pas plus compliqué :

yum install monit

La première chose à faire est de vérifier que la variable « START » a bien la valeur yes dans le fichier /etc/default/monit afin de permettre à Monit de démarrer.

Ensuite, la configuration centrale de Monit se fait au sein du fichier monitrc localisé sous /etc/monit. Dans ce fichier, vous pouvez notamment modifier l’adresse email qui recevra les alertes.

Ensuite, les configuration sont dans le répertoire /etc/monit/conf.d . Nous allons créer un fichier nommé freeswitch et y ajouter les lignes suivantes :

check process freeswitch with pidfile /usr/local/freeswitch/run/freeswitch.pid
  start program = "/etc/init.d/freeswitch start"
  stop program  = "/etc/init.d/freeswitch stop"

Nous allons simplement vérifier que FreeSwitch est bien démarré et si ce n’est pas le cas, nous demandons à Monit de le démarrer.

Avant de lancer Monit, vérifier bien que la syntaxe des fichiers de configuration est bonne avec la commande :

monit -t

Vous devez obtenir une belle réponse « Control file syntax OK ».

Nous allons maintenant compléter notre test afin de s’assurer que le process SIP est toujours fonctionnel. Pour cela, nous allons ajouter les lignes suivantes à notre fichier :

check host fs_server with address 127.0.0.1
   if failed port 5060 type udp protocol sip
      with target "localhost:5060" and maxforward 6
   then alert

En cas de dysfonctionnement, Monit vous enverra un mail d’alerte (attention à bien configurer votre mail et serveur dans le fichier monitrc).

Il possible de pousser aussi la supervision plus loin, selon le taux d’utilisation de votre machine, vérifier les process, les fichiers de log … et l’usage de la solution M/Monit permet un monitoring de vos serveurs centralisé simplement.

SIP : comment débugger ?

Introduction

Votre nouveau serveur VoIP est en place. Mais pour une raison que vous ignorez vos appels ne fonctionnent pas comme prévus. Pas de panique, je vais vous présenter quelques outils en ligne de commande qui vont vous aider à déterminer la source du problème. En effet, le protocole SIP n’est pas toujours aussi simple à l’usage que dans la théorie. Les informations fournies par les systèmes de téléphonie Open Source (Asterisk, Freeswitch, Yate …) ou propriétaires ne sont pas toujours d’une grande aide (manque de lisibilité, de souplesse …).

Pourquoi des outils en ligne de commande : l’installation est simple et très rapide, fonctionnent sur toutes les distributions linux, et l’information souhaitée est facilement et rapidement accessible. Il est tout à fait possible d’utiliser ces outils afin de sauvegarder les informations collectées dans un fichier afin de réaliser des analyses plus fines avec des logiciels intégrant une interface graphique, comme le renommé Wireshark.

Pré requis

Vous vous êtes assuré de la bonne configuration de vos comptes SIP (du moins sur le papier), que le routage (diaplan) est correctement fait et que les appels sont possibles (droits d’accès à la route bien affectés, balance financière positive …). Si pour vous, vous ne voyez pas de loup à cette étape, nous allons entrer dans le dur.

Procédure

Je vais maintenant vous expliquer comment trouver de manière efficace la source du problème. Nous allons du plus général vers le plus détaillé. Tout d’abord, vérifier que les échanges de messages SIP se passent comme prévus (je ne vais pas les rappeler ici, je vous laisse ressortir vos cours. J’écrirais peut-être un de ces jours un article les détaillants) : enregistrement, établissement d’un appel, raccroché de l’appel. Si une des étapes est manquantes, il va falloir trouver des informations détaillées. Nous allons voir ces étapes dans le paragraphe suivant.

Comment tracer les messages SIP

Nous allons dans un premier temps vérifier que les messages SIP échanger sont conforment. Nous n’avons pas besoin de tout le détail, juste du type de message SIP (100, 180, 407, 404 …). On va ainsi pouvoir voir très simplement à quelle étape le problème se pose. Le serveur distant souhaite que le compte soit enregistrer avant d’autoriser un appel (merde, on m’avait dit que c’était une authentification par IP ?), le serveur distant vous répond par un bon 404 ? …

Pour cela, je vais utiliser tshark, outil renommé de tout bon administrateur linux. Il utilise la librairie pcap pour capturer le traffic de l’interface déclarée (avec l’option -i) et affiche (ou enregistre dans un fichier avec l’option -w) les informations décodées de paquets capturés. Les fichiers de capture créés peuvent être lus par Wireshark.

Nous allons utiliser toute la puissance de filtrage de tshark afin de trouver l’information souhaitée. Par exemple, il faut vérifier que l’invite correspond bien au format attendu.

tshark -i eth0 -R "ip.addr==78.x.y.10 and sip.CSeq.method eq INVITE" (-V)

Si vous souhaitez capturer l’ensemble du traffic SIP d’une adresse ip spécifique et d’un port spécifique :

tshark -i eth0 -R "ip.addr==78.x.y.10 and port==5060" -z sip,stat

Un autre outil fort utile peut être utilisé, j’ai nommé tcpdump.

tcpdump est un analyseur de paquet. Il utilise libpcap, une librairie C/C++ afin de capturer les paquets.  Vous devez avoir les droits de super utilisateur afin de pouvoir l’utiliser.

Nous allons voir le détail de la commande à utiliser :

-i eth0 — le nom de l’interface à écouter

-n — afin de ne pas résoudre les hostnames

host 1.2.3.4 — filtre le traffic sur cette adresse IP (peut être remplacé par net pour capturer un réseau ex : net 1.2.3.0/24)

proto udp — en général on utilise de l’udp

-w /tmp/file.pcap — pour enregistrer la capture dans un fichier. Mais comme on souhaite avoir le retour en console, on ne vas pas ajouter cette option.

Vous trouverez le détail des options de la commande de tcpdump sur cette page.

Conclusion

Nous venons de voir de manière simple comment débugger un chance SIP entre 2 machines. Vous pouvez utiliser la capture afin de l’importer dans un GUI comme Wireshark afin de réaliser des recherches plus poussées, afficher une vue graphique des échanges ou générer des statistiques.

Il est aussi possible d’utiliser d’autres outils comme ngrep. Je vous présenterai dans un prochain article l’outil HOMER.

Comment sécuriser le SIP d’un serveur asterisk ?

Comme convenu lors de mes voeux, voici mon premier article technique de 2012 touchant la sécurité informatique et plus précisément comment sécuriser le SIP d’un serveur asterisk.

Je ne vais pas vous rappeler l’intérêt (quand on touche au portefeuille, on comprend de suite beaucoup plus vite) de bien sécuriser son serveur de téléphonie. Asterisk est de plus en plus déployé en entreprise, apportant une flexibilité et des fonctionnalités pour un coût incomparable. Asterisk sait gérer plusieurs protocoles de communications dont le SIP. Nous allons voir dans cet article comment sécuriser le SIP.

Cet article est « presque » indépendant de la version d’Asterisk (les différences seront indiquées), ceci étant d’autant plus important que pour des questions de stabilité ou de compatibilité de code, beaucoup de solutions n’ont pas migré vers la dernière version stable. On trouve couramment en production des 1.4 .

Du point de vue SIP, Asterisk est un B2BUA. Un B2BUA (back-to-back user agent) est un élément logique du réseau dans les applications SIP. Il intervient entre les deux terminaisons d’un appel et divise la communication en deux appels indépendants. Tous les messages de controls passent par le B2BUA, ce qui lui permet d’intervenir lors de l’appel afin de lancer si nécessaire des applications comme l’interception, l’enregistrement, la diffusion de messages … Par contre asterisk n’est pas un proxy SIP. Il intègre quelques unes des fonctions (routage des appels, serveur registrar), mais gère de manière incomplète l’ensemble des messages SIP. Ce n’est tout simplement pas son job.

Afin de protéger notre serveur asterisk, il est judicieux de mettre en frontal un proxy SIP comme Opensips ou Kamailio. Ainsi, toutes les requêtes SIP seront dirigées vers l’interface publique du Proxy SIP. Cela va nous permettre ainsi d’isoler Asterisk. De plus, nous obtenons une architecture plus évolutive (load balancing ou fail over entre 2 serveurs asterisk synchronisés) et plus résistante aux attaques de déni de services. Un proxy SIP a été construit pour supporter un grand nombre de requêtes SIP, ce qui n’est pas le cas d’un serveur Asterisk.

Nous allons ainsi pouvoir paramétrer de manière précise comment notre proxy va répondre aux demandes selon leurs profils, bannir des adresses IP qui auraient un comportement anormal, et détecter des attaques selon des dictionnaires. On peut aussi bannir par défaut des IP selon leur origine géographique, ce qui est très utile si vos clients ne sont qu’en France ou en Europe par exemple.

De plus, Asterisk ne supporte les communications sécurisées (TLS) que depuis la version 1.8 (une version beta patchée 1.6 existe, mais il n’est pas conseillé de l’utiliser en production). Cela ajoute en plus une charge complémentaire sur le serveur. Dans notre schéma, les flux TLS seront gérés par le proxy SIP qui renverra un flux non crytpé à notre asterisk.

Voilà notre schéma :

SIP Channels (réseau public et privé) < —–> PROXY SIP < ——-> ASTERISK < ——> DAHDI, IAX …. channels (réseau privé)

Asterisk fonctionne en Realtime intégrant ainsi dans sa base de données les comptes utilisateurs SIP. Le proxy va vérifier les comptes et l’état des postes SIP dans cette base. L’authentification est gérée par le proxy SIP. Quand un appel arrive et qu’il est authentifié, le proxy le renvoie vers le serveur asterisk. Si l’utilisateur est est disponible (utilisateur interne ou externe via un trunk SIP opérateur), asterisk renvoie l’appel au proxy SIP qui renvoie l’appel au destinataire final.

Ainsi, lors d’une tentative d’attaque, le serveur asterisk est complètement isolé, et c’est le proxy SIP qui les gèrera.

Vulnérabilité de la VoIP

Introduction

Alors que les attaques sur les systèmes de VoIP sont en constantes augmentation, les vulnérabilités observées augmentent elles aussi de manière exponentielle. (ne me faites pas dire ce que je n’ai pas dit, les systèmes traditionnels sont aussi soumis à des vulnérabilités qui sont d’autant plus facilement exploitées que tout le monde se croit à l’abri et qu’aucune procédure de sécurité n’est appliquée, même les plus essentielles et faciles à mettre en oeuvre – « comment ça, changer le mot de passe, 0000 comme mot de passe, c’est très bien mon bon mossieur !!! »).

On peut décomposer les attaques en 2 parties : les attaques au niveau du protocole et les attaques au niveau applicatif.

Les attaques protocolaires 

– l’écoute non souhaitée :

il est aisée de part la nature des flux (le média est transporté en RTP et la plus part du temps en non crypté) d’écouter les conversations. Cela pose un vrai problème de confidentialité.

La plus part des configuration par défaut n’utilise ni cryptage ni authentification.

– usurpation d’identité :

il est très aisé de présenter n’importe quel numéro, et donc se faire passer pour un autre

– détournement de compte SIP :

on retrouve en général 2 types d’authentification, soit par l’adresse IP, soit par un couple user / mot de passe. Grâce à la technique d’IP Spoofing, on peut détourner la première solution, et en sniffant le réseau on peut aisément récupérer les user/mdp. Il est essentiel de ne pas échanger les mots de passe en clair (utiliser md5) et d’utiliser SIPS (attention, tous les systèmes ne le prennent pas en compte).

– Replay :

en sniffant une conversation, on récupère les échanges de signalisation SIP. Il suffit de rejouer cet échange !

– Déni de service :

en générant de forte demande d’appels, d’authentification …

Les attaques applicatives

– les téléphones voip disposent d’une interface web de base souvent non protégée, permettant sa programmation à distance. L’assaillant après un scan et identification des terminaux, va pouvoir récupérer des informations essentielles (mots de passe, adresses …) et détourner à son profit les comptes.

– les téléphones et ipbx proposent des services qui parfois contiennent des failles de sécurité. Une fois exploitée, l’assaillant pourra prendre le contrôle de tout ou partie du système. Il faut bien s’assurer de bien patcher vos équipements.

– la configuration ne prenant pas suffisamment en compte la sécurité : mot de passe évident, compte basique, dialplan non sécurisé …

Conclusion

Ce n’est pas un exposé exhaustif des attaques touchant la VOIP, mais des principales attaques. Maintenant il ne vous reste plus qu’à vérifier votre protection. Bon courage.