Coturn : installation avec docker et Let’s Encrypt

Installation et paramétrage de Coturn avec docker, docker compose et let’s encrypt

Introduction

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.

Qu’est-ce que Coturn ?

COTURN est une implémentation libre et gratuite d’un serveur STUN et TURN. Coturn peut être facilement téléchargé à partir de son site web : https://github.com/coturn/coturn

Coturn peut-être installé via les packages de votre distribution, mais nous allons l’exécuter en tant que conteneur docker. Les avantages sont noubreux : le process d’installation est le même quelque soit les distributions, le déploiement peut se faire aisément quelque soit l’infrastructure sous-jacente et la mise à jour est simplifiée tout en étant rapide.

Quels sont les Pré-requis pour Coturn ?

  • Un serveur linux avec une adresse IP publique (il peut-être natté) avec à minima 2 vcpu, 2 Go de RAM et 20 Go de stockage (essentiellement pour l’OS et les logs)
  • Un nom de domaine personnalisé (optionnel, mais nécessaire pour utiliser le certificat et les connexions sécurisées)
  • Installation de Docker et docker compose

Comment installer COTURN avec Docker ?

Nous allons exécuter Coturn dans Docker au lieu de l’exécuter directement sur le serveur en utilisant docker compose.

Je pars du principe que docker est correctement installé en respectant les consignes du site officiel : https://docs.docker.com/engine/install/debian/

Je fais le choix de positionner toutes mes données et configurations de mes conteneurs dans /srv , mais libre à vous de changer le dossier en adaptant les commandes suivantes.

Tout d’abord, il faut créer le dossier mkdir /srv/coturn.

Puis créer un fichier docker-compose.yml en copiant le contenu ci-dessous et en adaptant la version de Coturn selon vos souhaits (je mets jamais latest pour maîtriser mes déploiements) :

version: '3'
services:
  coturn_server:
    image: coturn/coturn:4.6
    restart: always
    network_mode: "host"
    expose:
      - '3478'
      - '5349'
    logging:
      driver: "json-file"
      options:
        max-size: "200k"
        max-file: "10"
    volumes:
      - /srv/coturn/turnserver.conf:/etc/coturn/turnserver.conf:ro
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
      - /srv/coturn/cert.pem:/etc/turnserver/cert.pem:ro
      - /srv/coturn/privkey.pem:/etc/turnserver/privkey.pem:ro

Comment créer un certificat SSL pour Coturn ?

Let’s Encrypts certbot peut être utilisé pour générer rapidement des certificats SSL gratuits qui se renouvellent automatiquement avant l’expiration. D’autres sytèmes peuvent-être utilisés !

Certbot doit être installé à l’aide snap. Voici les commandes suivantes :

apt update
apt install snapd
snap install core
snap refresh core
snap install --classic certbot
ln -s /snap/bin/certbot /usr/bin/certbot

Après avoir installé certbot avec succès, vous pouvez générer un certificat à l’aide de la commande suivante (en remplaçant <DOMAIN> par votre nom de domaine) :

certbot certonly --standalone --preferred-challenges http -d <DOMAIN>

Nous demandons ici un certificat autonome.

Notez que les ports TCP 80 et 443 doivent-être ouvert et redirrigés vers la VM pour que la création et le renouvellement du certificat fonctionnent.

Actuellement, le certbot se renouvelle automatiquement par défaut

Pour s’assurer que les certificats soient lisibles par Coturn, nous allons ajouter un hook de renouvellement à la configuration de let’s encrypt.

Pour cela, nous allons créer un dossier $ mkdir -p /etc/letsencrypt/renewal-hooks/deploy puis un fichier coturn.
Puis, copier le contenu ci-dessous dans le fichier en remplaçant <DOMAIN> par votre domaine :

#!/bin/bash -e
for certfile in cert.pem privkey.pem ; do
    cp -L /etc/letsencrypt/live/<DOMAIN>/"${certfile}" /srv/coturn/"${certfile}".new
    chown turnserver:turnserver /srv/coturn/"${certfile}".new
    chmod 644 /srv/coturn/"${certfile}".new
    mv /srv/coturn/"${certfile}".new /srv/coturn/"${certfile}"
done
docker compose -f /srv/coturn/docker-compose.yml restart > /dev/null

Puis rendre ce fichier exécutable chmod 0755 /etc/letsencrypt/renewal-hooks/deploy/coturn

Puis on force la génération du certicat certbot renew --force-renewal

Créer l’utilisateur turnserver et l’affecter au groupe turnserver :

useradd turnserver
usermod - a -G turnserver turnserver

Nous indiquons à certbot qu’il doit redémarrer automatiquement le conteneur Coturn à chaque renouvellement du certificat. Cela permet de s’assurer que le certificat du serveur TURN est toujours à jour, mais présente l’inconvénient d’interrompre toutes les connexions TURN en cours.

Comment paramétrer COTURN ?

La configuration de Coturn se fait dans un fichier créé dans le dossier /srv/coturn.

Vous allez donc créer un fichier turnserver.com dans ce dossier et coller le contenu ci-dessous en adaptant votre domaine, vos adresses IP (si la VM porte directement une adresse IP publique, vous supprimez le / après cette adresse !) et le user/mdp de connexion.

# TURN server name and realm
realm=<DOMAIN>
server-name=<DOMAIN>

# Use fingerprint in TURN message
fingerprint

# IPs the TURN server listens to
listening-ip=0.0.0.0

# External IP-Address of the TURN server
external-ip=IP_ADDRESS_PUBLIC/IP_PRIVEE

# Main listening port
listening-port=3478

# Further ports that are open for communication
min-port=49152
max-port=65535

# Enable verbose logging
#verbose

# Specify the user for the TURN authentification
user=test:test123

# Enable long-term credential mechanism
lt-cred-mech

# SSL certificates
# From https://ssl-config.mozilla.org/ Intermediate, openssl 1.1.0g, 2020-01
cipher-list="ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"
cert=/etc/turnserver/cert.pem
pkey=/etc/turnserver/privkey.pem

# Do not allow an TLS/DTLS version of protocol
no-tlsv1
no-tlsv1_1
#no-tlsv1_2

# Block connections to IP ranges which shouldn't be reachable
no-multicast-peers

# SSL
tls-listening-port=5349

# Misc
no-cli

# Uncomment to disable TCP listener
#no-tcp

# Uncomment and adjust value for quota use
#user-quota=0
#total-quota=100

# Uncomment and adjust value for setting a maximum server capacity
#bps-capacity=0

Il est possible de sécuriser plus fortement la connexion au serveur Coturn et utilisant une base de données pour gérer les mots de passe des utilisateurs.

Ceci étant assez simple, je vous laisse ceci en exercice sachant que vous trouverez les infos nécessaires sur le github du projet : https://github.com/coturn/coturn/tree/master/docker

Comment lancer COTURN ?

Pour démarrer le conteneur Coturn, saisissez la commande docker compose -f /srv/coturn/docker-compose.yml up -d

Pour redémarrer Coturn, la commande est docker compose -f /srv/coturn/docker-compose.yml restart

Comment voir les logs ?

Pour voir les logs, la commande est docker compose -f /srv/coturn/docker-compose.yml logs -f

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.

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 ?

Table des matières

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.