Blog

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.

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

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.

Tout le monde est maintenant conscient de l’importance de délivrer ou utiliser un service web fortement sécurisé. Il est indispensable de protéger les données stockées dans les bases de données, valeurs inestimables, et assurer la confidentialité des échanges. L’utilisation d’un framework comme Django permet de partir sur des bonnes bases. Mais nous allons voir qu’il est nécessaire de paramétrer finalement celui-ci.

Comment sécuriser Django ?#

Je vais me servir d’un exemple concret, l’application PyFreeBilling dont je suis le créateur. PyFreeBilling est une application complète de VoIP (fonctionnalités de class 4 pour les connaisseurs) permettant à un opérateur télécom ou à une entreprise de services de connecter des clients et des fournisseurs, de router les appels, d’appliquer un tarif selon le type d’appel ainsi que l’ensemble des tâches nécessaires à cette activité. L’exemple est intéressant du point de vue de la criticité de l’application. Une solution de communications de VoIP doit-être fortement sécurisée. Les risques de fraudes, de divulgation d’informations ou de perte de services sont importants. Un serveur à peine déployée subit ses premières attaques au bout de quelques minutes ceci étant aidé par des frameworks permettant d’automatiser les attaques. L’interface de gestion de PyFreeBilling est développée avec le framework Django.

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 :