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.

Sparrow : Wazo PBX sur Raspberry Pi

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.

J’aime bien la définition de Wazo :

Wazo Platform is an Open Source project writen in python who gets the best from Asterisk and Kamailio to build a telecom platform.

Sparrow peut fonctionner sur n’importe quel système avec une architecture armhf. Il est néanmoins recommandé 2 Go de RAM et une carte SD rapide industrielle d’une taille d’au moins 16 Go. Attention au volume des messages de logs, des backups et surtout des messages vocaux, le chiffre annoncé étant un minimum !

La dernière version est basée sur Wazo 20.01. C’est la seconde version de Sparrow, la première release datant du 3 janvier 2020.

L’ensemble des fonctionnalités de Wazo Platform sont disponibles sous Sparrow  sauf le codec OPUS qui n’est pas fonctionnel. Mais cela n’impactera que les applications WebRTC. De plus, du fait des faibles ressources d’une carte raspberry PI, les capacités de transcodage sont fortement limitées. Veillez bien à correctement configurer vos paramètres SIP.

Le process d’installation est assez simple. Après avoir installé la distribution Raspbian en version minimale (basée sur debian Buster, les dernières releases de Wazo ne supportant plus Jessie mais uniquement Buster), l’installation se déroule en quelques simples lignes de commandes. Le process prend du temps, profitez en pour prendre un bon café et marcher un peu !

Je n’ai pas eu le temps de faire des tests de performances, mais on peut facilement estimer que pour une petite entreprise équipée de 1 ou 2 T0 (2 à 4 appels simultannés) ou une utilisation en homelab, le Raspberry sera suffisament performant.

La documentation est accessible ici : https://sparrow.b5.pm/docs

et le repo github : https://github.com/benasse/sparrow

Merci Benoit Stahl pour ce superbe travail qui met en valeur la force d’une communauté Open Source.

Vidéo d’installation et de déploiement d’une instance WAZO UC en moins de 3 minutes

Découvrez dans notre courte vidéo comment installer et déployer une solution UC en moins de 3 minutes avec la console de gestion Wazo Portal sur AWS.

 

2019-11-19: Critical FreePBX Security Vulnerability

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.

Routage SIP asynchrone : performance et montée en charge chez 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.

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.

Bonne lecture : Kamailio routing with rtjson and http_async_client

Sortie de Wazo Platform 19.13

La team Wazo vient d’annoncer la sortie de Wazo Platform 19.13.

Wazo Platform est une suite d’outils permettant de construire une infrastructure de communication IP programmable de classe opérateur. La suite est publiée en opensource, le code étant disponible sur le repo github de Wazo.

L’idée de fournir une solution de communication libre permettant de concevoir et de construire un système de communication adapté aux besoins spécifiques de chaque entreprise.

Les briques techniques sont construites autour de projets libres comme Asterisk, Kamailio, PostgreSQL et s’appuient fortement sur le langage de programmation python.

Pour ceux qui ne me connaissent pas, je travaille sur ce fabuleux projet, donc si vous avez des questions, n’hésitez pas.

Lien de la news : Introducing Wazo Platform 19.13

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 :

freeswicth ansible role 2.0 just released

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.

Vous le trouverez dans la galaxy ansible : https://galaxy.ansible.com/mwolff44/freeswitch-mw/

N’hésitez pas à me faire des retours.

Note : le repo officiel est hébergé par framagit : https://framagit.org/mwolff44/freeswitch-mw/ même si une copie existe sur github pour ansible-galaxy.

 

Modifications :

  • 12/04/2017 : v2.1 : mise à jour du kernel via les backports (performance) / installation de locales spécifiques / installation de paquets complémentaires – Ces 3 fonctions sont désactivées par défaut.