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.