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

Enregistrement DNS de type CAA

Introduction

Défini en 2013 par la RFC6844, le CAA est un type d’enregistrement DNS qui permet aux propriétaires de sites de préciser quelles autorités de certification (CA) sont autorisées à émettre des certificats contenant leurs noms de domaine.

Quel est l’intérêt

Par défaut, chaque autorité de certification publique est autorisée à émettre des certificats pour tout nom de domaine dans le DNS public, à condition qu’elle valide le contrôle de ce nom de domaine.

L’enregistrement CAA offre aux détenteurs de domaines un moyen de réduire ce risque d’une émission de certificat non souhaitée en intégrant une étape de confirmation/refus aux autorités de certification dans leurs processus d’émission de certificat.

L’intérêt d’un tel système prend tout son sens suite à l’essor des certificats générés « à la volée ». Ces types de certificat sont émis sans aucune vérification sur le titulaire du domaine. Il est aisé de demander un certificat pour n’importe quel domaine.

L’enregistrement CAA permet donc au propriétaire d’un nom de domaine de spécifier les autorités de certification qu’il autorise à émettre un certificat.

Notez que l’utilisation de DNSSEC pour authentifier les enregistrements CAA est fortement recommandée mais non requise (RFC 6844, section 4.1). Du point de vue sécurité, vous devez absolument utiliser le DNSSEC pour obtenir une requête/réponse authentique des CA à votre serveur DNS.

Enfin, cet enregistrement n’est pas encore obligatoire, mais je vous encourage à le mettre en oeuvre avant de personnes malveillantes n’utilisent cet oubli à leur avantage.

Principe de fonctionnement

Quand une autorité de certification reçoit une demande de certificat, elle vérifie le domaine afin de déterminer si un enregistrement de type CAA existe. Si un enregistrement existe et que la CA est bien autorisée, alors l’autorité de certification génère le certificat. Si l’enregistrement CAA spécifie une CA différente, alors la génération du certificat est refusée. A ce jour, si l’enregistrement CAA n’existe pas, alors la CA est autorisée à générer le certificat.

Structure d’un enregistrement CAA

Chaque enregistrement CAA est constitué d’un octet « flag » et d’une paire étiquette-valeur appelée une propriété.

Plusieurs propriétés peuvent être associées au même nom de domaine en publiant plusieurs enregistrements CAA à ce nom de domaine.

Un seul « flag » est défini: le « issuer critical » est représenté par le bit le plus significatif de l’octet. S’il est activé (c’est-à-dire que l’entier résultant est égal ou supérieur à 128) l’autorité de certification qui n’est pas à même de comprendre ou de mettre en œuvre l’étiquette de cet enregistrement doit refuser de délivrer un certificat pour le domaine.

Outre le « flag », trois mots clés sont définis:

  • issue : autorise une autorité (via son nom de domaine spécifié dans le champ « value ») à délivrer des certificats pour le domaine sur lequel l’enregistrement pointe
  • issuewild : est similaire à issue et vise les émissions de certificats wildcard
  • iodef : indique un moyen pour les autorités de signaler une demande de certificat ou un souci avec celle-ci

Pour interdire l’émission d’un certificat, il faut spécifier « ; » comme valeur pour le mot clé issue ou issuewild.

Exemple de mise en oeuvre

Qui prend en charge l’enregistrement CAA ?

Si vous voulez publier un enregistrement CAA, le logiciel (ou le fournisseur) de DNS de votre domaine doit prendre en charge le CAA.
Le site https://sslmate.com/caa/support vous indique quels logiciels et fournisseurs DNS prennent en charge la CAA. En France, les 2 principaux fournisseurs, Gandi et OVH, supportent le CAA.

Mise en oeuvre

Pour illustrer notre exemple, nous allons utiliser le domaine example.com et l’autorité de certification Let’s Encrypt.
Le nom de domaine d’identification de Let’s Encrypt pour la CAA est letsencrypt.org.

Si votre fournisseur est répertorié, vous pouvez utiliser le générateur d’enregistrements CAA de sslmate pour générer un ensemble d’enregistrements CAA répertoriant les CA que vous souhaitez autoriser.

Voici les captures :

Enfin, vous publiez votre politique CAA en ajoutez les enregistrements CAA suivants au DNS de votre domaine. Votre DNS doit être hébergé par un service qui prend en charge la CAA.

Plusieurs formats sont rencontrés :
– générique (utilisé par Google Cloud DNS, Route 53, DNSimple, et les autres services DNS hébergés) :

Name Type Value
example.com. CAA 0 issue ";"
0 issuewild "letsencrypt.org"
0 iodef "mailto:support@example.com"
  • standard (utilisé par BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0) :
Name Type Value
example.com. IN CAA 0 issue ";"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:support@example.com"
  • legacy RFC 3597 (utilisé par BIND <9.9.6, NSD <4.0.1, Windows Server 2016) :
Name Type Value
example.com. IN TYPE257 \# 8 000569737375653B
example.com. IN TYPE257 \# 26 0009697373756577696C646C657473656E63727970742E6F7267
example.com. IN TYPE257 \# 33 0005696F6465666D61696C746F3A737570706F7274406578616D706C652E636F6D

Résolution des problèmes

Comment vérifier

Commande DIG

Une requête de test avec dig montre les enregistrements :

$ dig @1.1.1.1 celea.org caa +dnssec +multi +noauthority +noadditional

; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 celea.org caa +dnssec +multi +noauthority +noadditional
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45743
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;celea.org. IN CAA

;; ANSWER SECTION:
celea.org. 1800 IN CAA 0 iodef "mailto:mathias@celea.org"
celea.org. 1800 IN CAA 0 issuewild "letsencrypt.org"
celea.org. 1800 IN CAA 128 issue "letsencrypt.org"
celea.org. 1800 IN RRSIG CAA 13 2 1800 (
20210520000000 20210429000000 7209 celea.org.
9CmiaEqazRE272NDI8SgfY4iaWFI+Du13j0bTDWAzsCn
H6Y4dI7VT2UfG/vWNuLdUPSpXGkhwee0MOSMoQJcFA== )

;; Query time: 96 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: ven. mai 07 17:43:20 CEST 2021
;; MSG SIZE rcvd: 258

Services en ligne

Vous pouvez aussi utiliser un service en ligne https://caatest.co.uk/ :

Erreur CAA liée au fournisseur DNS

Avant l’émission d’un certificat, l’autorité de certification vérifie les enregistrements CAA. Parfois des erreurs sont renvoyées même pour des domaines n’ayant pas défini d’enregistrements CAA. Lorsqu’une erreur est obtenue, la CA ne peut pas savoir si elle est autorisée à émettre un certificat pour le domaine concerné. En effet, des enregistrements CAA pourrait être présents interdisant l’émission, mais qui ne sont pas visibles à cause de l’erreur.

Certains fournisseurs DNS qui ne sont pas familiers avec la CAA répondent initialement aux rapports de problèmes par « Nous ne prenons pas en charge les enregistrements CAA ». Votre fournisseur DNS n’a pas besoin de prendre spécifiquement en charge les enregistrements CAA. Il doit seulement répondre par une réponse NOERROR pour les types de requêtes inconnus (y compris le CAA). Renvoyer d’autres opcodes, y compris NOTIMP, pour les types de requête inconnus est une violation de la RFC1035, et doit être corrigé.

SERVFAIL

L’erreur les plus courantes rencontrée est SERVFAIL. Le plus souvent, cela indique un échec de la validation DNSSEC.
Si vous obtenez une erreur SERVFAIL, votre première étape devrait être d’utiliser un débogueur DNSSEC comme dnsviz.net. Si cela ne fonctionne pas, il est possible que vos serveurs de noms génèrent des signatures incorrectes uniquement lorsque la réponse est vide. Et les réponses CAA sont le plus souvent vides.

Si vous n’avez pas activé DNSSEC et que vous obtenez un SERVFAIL, la deuxième raison la plus probable est que votre serveur de noms faisant autorité a renvoyé NOTIMP, ce qui est une violation de la RFC1035. Il devrait plutôt renvoyer NOERROR avec une réponse vide. Si tel est le cas, contactez de votre fournisseur DNS.

Enfin, les SERVFAILs peuvent être causés par des pannes au niveau de vos serveurs de noms faisant autorité. Vérifiez les enregistrements NS de vos serveurs de noms et assurez-vous que chaque serveur est disponible.

Timeout

Parfois, les requêtes CAA n’aboutissent pas. Même après plusieurs tentative, le serveur de noms faisant autorité ne répond pas. Le plus souvent, cela se produit lorsque votre serveur de noms est protégé par un pare-feu mal configuré qui rejette les requêtes DNS avec des QTYPES inconnus. Contactez alors votre fournisseur DNS.

Les champs QTYPE apparaissent dans la partie question d’une requête. Les QTYPES sont un sur-ensemble de TYPEs, donc tous les TYPEs sont des QTYPEs valides

Surveillez votre domaine

Même si vous publiez un enregistrement CAA, une autorité de certification non conforme peut ignorer vos enregistrements CAA. Utilisez Cert Spotter pour surveiller les journaux de Certificate Transparency afin d’être averti si cela se produit.

Navigateurs sécurisés et respectueux de la confidentialité

Un navigateur sécurisé et respectueux de la vie privée est essentielle. Il est notre point d’entrée sur la toile, et il se doit de protéger notre navigation. Mais un navigateur sécurisé est important car ils présentent une importante surface d’attaque et peuvent être compromis par différentes techniques. Les navigateurs disposent aussi de nombreuses informations privées (historique de navigation, identifiant / mot de passe, informations auto complétées …). Ils peuvent aussi transmettre vos informations de localisation géographique, vos paramètres (logiciels, matériels …). Le choix et la mise à jour régulière d’un navigateur est essentiel.

Je vous partage une liste non exhaustive de navigateur répondant aux critères de sécurité et de respect de la vie privée. Vous pouvez proposer d’autres (avec quelques informations) en commentaire.

Tor Browser

Le navigateur Tor est une version renforcée de Firefox qui utilise également le réseau Tor par défaut (mais cela peut être désactivé).

https://www.torproject.org/

Firefox (modifié)

Firefox est un excellent navigateur pour la confidentialité et la sécurité après avoir effectué quelques modifications. Sa personnalisation (paramètres et extensions) peut vous donner le niveau de sécurité et de confidentialité appréciable.

https://www.mozilla.org/fr/firefox

Iridium

Iridium est un navigateur basé sur Chromium configuré pour la confidentialité et la rapidité. Je vous encourage à lire le wiki qui détaille les différences en terme de sécurité et de confidentialité avec Chromium : https://github.com/iridium-browser/tracker/wiki

https://iridiumbrowser.de/

Brave

Brave est un navigateur basé sur chrome qui est très axé sur la confidentialité. Par défaut, il bloquera les publicités et les trackers. Il est également personnalisable, rapide et doté d’une protection intégrée contre le fingerprinting.

https://brave.com/

Gnu IceCat

GNU IceCat est un autre fork de Firefox, créé par les personnes du projet de logiciel libre GNU. IceCat répond à la définition de «logiciel libre» et inclut également certains modules complémentaires (notamment GNU LibreJS. Plus d’infos https://www.gnu.org/philosophy/javascript-trap.html ) et des paramètres par défaut afin de renforcer la vie privée (Https-Everywhere et SpyBlock).

https://www.gnu.org/software/gnuzilla/

Cette liste n’est pas exhaustive. Par exemple, j’aime bien le navigateur Vivaldi, mais sans extensions et réglages appropriés, il ne peut répondre aux critères et son code n’est pas disponible.

Firefox : le chant du cygne

Les statistiques d’utilisation de Firefox ne sont pas bonnes. Des choix contestables, des performances parfois juste acceptables et une stratégie pour le moins incompréhensible.

Mais une dernière partie de ses soutiens risque de quitter le navire. Ces utilisateurs utilisent Firefox pour améliorer le respect de la vie privée et disposer d’une certaine garantie concernant la neutralité du net.

Hors voilà que Firefox prône la censure. De quel droit un éditeur ou même un acteur privé se permet de censurer qui que ce soit. Le fait de bloquer une personne une organisation ne doit-être le fait que d’une décision de justice. J’ai perdu confiance dans Firefox. Adieu Firefox !

Quelles informations les entreprises technologiques géantes collectent-elles auprès de vous?

quelles informations les entreprises technologiques géantes collectent-elles auprès de vous?

Jean-Baptiste Kempf, Videolan, parle de startup nation – à écouter

Comment envoyer des SMS à partir d’un Raspberry ?

Une carte Raspberry peut-être utilisée pour de nombreux cas d’usage et nous allons l’utiliser pour envoyer des SMS.

Philippe vous a préparé un article détaillé expliquant la mise en oeuvre avec une carte GSM Nadhat et une Rapsberry 3B+ sous Debian : Raspberry et SMS

Et un autre article sur ce même sujet mettant en jeu Node-RED pour ajouter un peu de programmabilité : Envoyer un SMS sur changement d’état d’une GPIO

Bonne lecture et bon développement

OpNSense : configurer WireGuard VPN en vidéo

Une vidéo très bien faite expliquant l’installation et la configuration pas à pas du VPN Wireguard sur le firewall OPNSense.

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.

Fermeture des commentaires

La gestion des commentaires étant une activité demandant du temps du fait du nombre trop important de spammer, j’ai pris la décision de supprimer les commentaires de mon blog.

Je souhaite aussi migrer le blog en pages statiques pour réduire mon empreinte carbone (et plein de petits trucs sympas, une meilleure sécurité …) et les commentaires devaient être externalisés ou supprimés. Je les ai supprimé n’étant pas un fan de système de type Disqus.

Par contre, certains échanges étant intéressant, j’ai ouvert une communauté reddit pour cela : https://www.reddit.com/r/blog_des_telecoms