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

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 :

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.