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.

Vulnérabilité de la VoIP

Introduction

Alors que les attaques sur les systèmes de VoIP sont en constantes augmentation, les vulnérabilités observées augmentent elles aussi de manière exponentielle. (ne me faites pas dire ce que je n’ai pas dit, les systèmes traditionnels sont aussi soumis à des vulnérabilités qui sont d’autant plus facilement exploitées que tout le monde se croit à l’abri et qu’aucune procédure de sécurité n’est appliquée, même les plus essentielles et faciles à mettre en oeuvre – « comment ça, changer le mot de passe, 0000 comme mot de passe, c’est très bien mon bon mossieur !!! »).

On peut décomposer les attaques en 2 parties : les attaques au niveau du protocole et les attaques au niveau applicatif.

Les attaques protocolaires 

– l’écoute non souhaitée :

il est aisée de part la nature des flux (le média est transporté en RTP et la plus part du temps en non crypté) d’écouter les conversations. Cela pose un vrai problème de confidentialité.

La plus part des configuration par défaut n’utilise ni cryptage ni authentification.

– usurpation d’identité :

il est très aisé de présenter n’importe quel numéro, et donc se faire passer pour un autre

– détournement de compte SIP :

on retrouve en général 2 types d’authentification, soit par l’adresse IP, soit par un couple user / mot de passe. Grâce à la technique d’IP Spoofing, on peut détourner la première solution, et en sniffant le réseau on peut aisément récupérer les user/mdp. Il est essentiel de ne pas échanger les mots de passe en clair (utiliser md5) et d’utiliser SIPS (attention, tous les systèmes ne le prennent pas en compte).

– Replay :

en sniffant une conversation, on récupère les échanges de signalisation SIP. Il suffit de rejouer cet échange !

– Déni de service :

en générant de forte demande d’appels, d’authentification …

Les attaques applicatives

– les téléphones voip disposent d’une interface web de base souvent non protégée, permettant sa programmation à distance. L’assaillant après un scan et identification des terminaux, va pouvoir récupérer des informations essentielles (mots de passe, adresses …) et détourner à son profit les comptes.

– les téléphones et ipbx proposent des services qui parfois contiennent des failles de sécurité. Une fois exploitée, l’assaillant pourra prendre le contrôle de tout ou partie du système. Il faut bien s’assurer de bien patcher vos équipements.

– la configuration ne prenant pas suffisamment en compte la sécurité : mot de passe évident, compte basique, dialplan non sécurisé …

Conclusion

Ce n’est pas un exposé exhaustif des attaques touchant la VOIP, mais des principales attaques. Maintenant il ne vous reste plus qu’à vérifier votre protection. Bon courage.

Votre système téléphonique est-il bien protégé ?

On parle souvent d’intrusion des réseaux informatiques, de vol d’informations, de perte de données, d’indisponibilité d’applications suite à une attaque informatique. Tout le monde est conscient des vulnérabilité des solutions informatiques et les entreprises mettent en oeuvre les moyens nécessaires afin de se protéger. Mais qu’en est-il du système téléphonique d’entreprise ? Quels sont les risques et les conséquences d’une attaque ?

Historique

Commençons par un retour vers le passé, un peu d’histoire qui va nous permettre de comprendre l’étendue des risques encourus par les entreprises. Avant l’arrivée de la voix sur IP (VoIP) et du dialogue entre le téléphone et l’informatique communément appelé CTI, les flux voix étaient transportés par des protocoles propriétaires. Le niveau de compétences nécessaires afin de réaliser une intrusion était élevé. Peu d’attaques étaient possibles :

  • écoute des communications en se branchant sur les accès France Télécom.
  • prise en main à distance du système de téléphonie.

Cette dernière attaque est particulièrement dangereuse, car cela permet à l’attaquant de modifier le paramétrage de l’autocommutateur. Ainsi, grâce à des fonctionnalités embarqués dans le PABX, l’attaquant peut appeler au frais de la société attaquée des correspondant étranger à moindre frais. Il peut aussi faire de l’écoute discrète, enregistrer les communications, renvoyer les appels vers le service commercial vers un concurrent …

Quels sont les risques ?

Nous avons donc trois niveaux de risques :

  1. un risque financier
  2. un risque d’indisponibilité du système
  3. un risque d’espionnage

L’intrusion

Le risque d’intrusion par un accès à distance sur le PABX est très fort. En effet, le monde des installateurs privés n’est pas très au fait de la sécurité. Vous trouvez alors assez facilement les informations nécessaires. Le numéro d’accès est très souvent le numéro du standard. Sinon, un numéro de la séquence SDA assez facile à obtenir. Il suffit alors de scanner la plage de numéro. Il vous reste à trouver le mot de passe. Il faut savoir que pour des raisons pratiques, une partie des autocommutateurs sont toujours avec le mot de passe d’origine ou si le mot de passe a été changé, il n’est pas rare que tous les clients d’un même installateur privé est le même mot de passe. Dans tous les cas, le format des mots de passe est assez simple et n’est pas très difficile à casser. Enfin, chaque constructeur dispose d’un mot de passe dit super utilisateur qui n’est pas toujours très difficile à récupérer. De plus, il y a plusieurs niveaux d’utilisateurs : constructeur, administrateur, opérateur … Souvent, seul le mot de passe administrateur est changé. Il suffit de se connecter en opérateur et les droits sont en général suffisant pour faire des dégâts.

VOIP / CTI : des risques complémentaires

Avec la VoIP et le CTI, d’autres failles de sécurité interviennent. Les flux voix sont plus facilement interceptés et donc écoutés sans avoir à prendre la main sur le système. Il suffit alors de crypter les communications, mais qui le fait réellement ? De grands constructeurs ne l’implémentent même pas dans leur système et confie cette sécurisation à des tiers. Le CTI (protocole liant l’informatique à la téléphonie) ouvre deux possibilités supplémentaires : prendre possession du PABX, mais nous l’avons vu précédemment qu’il y a des méthodes plus simples, mais permet aussi d’entrer sur le réseau informatique. Je vous laisse imaginer, alors que vous aviez parfaitement sécurisé votre informatique, sans le savoir, vous avez laissé une porte grande ouverte via votre autocommutateur.

Conclusion

Un système téléphonique d’entreprise est avant tout un système informatique (serveur linux, windows ou dérivé d’unix) disposant des failles de sécurité qui doit entrer dans les process de sécurité informatique : gestion des accès externes rigoureux, politique de gestion des mots de pass, surveillance … d’autant plus que les risques sont au moins aussi importants que pour l’informatique.