VoIP

Les regex sont des outils très puissants pour valider des formats et extraire des parties de chaines de caractères. Voici une regex très utile dans le domaine de la téléphonie permettant de valider si le numéro appelé ou présenté respecte le format internationnal E.164 :

^\+[1-9][0-9]{5,14}$

Voici un exemple d’utilisation en langage Rust :

// include the latest version of the regex crate in your Cargo.toml
extern crate regex;

use regex::Regex;

fn main() {
  let regex = Regex::new(r"(?m)^\+[1-9][0-9]{5,14}$").unwrap();
  let string = "+3390123456789";

  // result will be an iterator over tuples containing the start and end indices for each match in the string
  let result = regex.captures_iter(string);

  for mat in result {
    println!("{:?}", mat);
  }
}

et en golang :

Un serveur STUN est utile dans le processus de découverte de l’adresse IP publique à la fois pour les terminaux SIP mais surtout les applications WebRTC.

Le WebRTC nécessite une connexion directe entre les pairs, mais souvent une connexion directe ne peut pas être établie notamment à cause du NAT et un serveur TURN est donc nécessaire.

Dans cet article, nous allons expliquer comment vous pouvez exécuter votre propre serveur STUN/TURN en utilisant l’implémentation du serveur STUN/TURN open source, c’est-à-dire Coturn.

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.

Le jeune projet Sparrow propose un build non officiel de l’architecture armhf de plateforme Wazo. Il vous permet d’héberger un système téléphonique VoIP Open Source complet et programmable sur un Raspberry Pi. Un autre projet qui semble maintenant peu maintenu permettait d’installer un système Xivo ou Wazo (mais en 18.03) sur Raspberry, Raspvivo.

J’apprécie particulièrement cette architecture, car elle permet de manière efficace et avec une faible consommation de faire fonctionner des services performants. Dans la même veine, mais j’en parlerai dans un autre article, j’ai fait fonctionner la plateforme de class 4 de Wazo sur un cluster Kubernetes à base de cartes Raspberry.

Une vulnérabilité de sécurité critique découverte dans FreePBX permet l’exécution de code à distance sans authentification. Les serveurs FreePBX en version 14 ou 15 sont automatiquement mises à jour. Par contre, les serveurs fonctionnant en version 12 ou 13 doivent-être mises à jour manuellement. Assurez-vous que votre serveur FreePBX est mis à jour avec les dernières versions !

La vulnérabilité est corrigée dans:

• (Version 12 inconnue pour le moment)
• 13.0.197.14
• 14.0.13.12
• 15.0.16.27

Je me permets de vous rappeler qu’il est essentiel de tenir à jour ses serveurs et d’autant plus dans la VoIP qui est une cible particulièrement intéressante pour les assaillants ! Plus de détails sur la vulnérabilité sont disponibles sur le wiki de FreePBX.

Je vous partage un article écrit par Fabio de la team Wazo. L’objectif de Wazo Platform est de proposer une solution télécom flexible, facile à configurer et performante pour les opérateurs. Le composant clé de la solution est le routeur SIP basé sur le projet Kamailio, le serveur SIP open-source de premier plan. L’objectif est, tout en offrant une grande flexibilité et une grande facilité de configuration, d’éviter tout compromis sur les performances.

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 ?

Je viens de publier la nouvelle version du role ansible permettant une installation / mise à jour automatisée de FreeSwitch avec plusieurs bonus optionnels comme fail2ban, sngrep …

Le role est fait pour fonctionner exclusivement avec Debian Jessie. J’intégrerai Stretch le moment venu.

Contrairement à la version précédente, l’installation se fait à partir des paquets fournis par la team FreeSwitch (je suis leurs recommandations).

L’utilisation est présentée dans le README.

L’équipe de FreeSwitch vient de publier les paquets pour Ubuntu 14.04 LTS et 16.04 LTS. Une excellente nouvelle pour les utilisateurs d’Ubuntu. L’installation est maintenant simplifiée. Pour Ubuntu 16.04 LTS, voici les commandes à taper pour installer la dernière version stable de FreeSwitch :

wget -O - https://files.freeswitch.org/repo/ubuntu-1604/freeswitch-unstable/freeswitch_archive_g0.pub | apt-key add -

echo "deb http://files.freeswitch.org/repo/ubuntu-1604/freeswitch-unstable/ xenial main" > /etc/apt/sources.list.d/freeswitch.list

# you may want to populate /etc/freeswitch at this point.
# if /etc/freeswitch does not exist, the standard vanilla configuration is deployed
apt-get update && apt-get install -y freeswitch-all

Pour Ubuntu 14.04 LTS :

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 :