Catégorie : Voip

Configurer correctement les appels anonymes avec un asterisk

Pour certaines raisons, vous souhaitez émettre des appels sans présenter votre numéro à partir de votre serveur asterisk. Mais, en jouant sur le CallerID, vos appels sont toujours rejetés. La cause est simple : pour des raisons de traçabilité réglementaire, il faut que l’opérateur puisse tracer l’origine de l’appel. Il faut donc que votre numéro soit correctement indiqué dans les entêtes SIP.

Voici le code à intégrer (et modifier selon votre dialplan) pour vous conformer à la règlementation et éviter d’être rejeté :

exten => _X.,1,NoOp(Mon appel avec mon numero masqué)
exten => _X.,n,SIPAddHeader(P-Asserted-Identity: <sip:${CALLERID(num)}@${SYSTEMNAME}>) ;RFC3323
exten => _X.,n,SIPAddHeader(P-Preferred-Identity: <sip:${CALLERID(num)}@${SYSTEMNAME}>) ;RFC3325
exten => _X.,n,SIPAddHeader(Privacy: id)
exten => _X.,n,Set(CALLERID(num)=)
exten => _X.,n,Set(CALLERID(name)=Anonymous)
exten => _X.,n,Dial ...
exten => _X.,n,Hangup

Configuration de fail2ban selon les différentes versions d’asterisk

Fail2ban est un outil indispensable à installer sur ses serveurs asterisk. Il permet de bloquer de manière proactive les tentatives de scan et ainsi de protéger vos deniers. Mais selon la version d’asterisk, le filtre doit être configurer de manière différente.

Il faut ajouter au fichier jail.conf la partie le code suivant :

[asterisk-iptables]
# if more than 4 attempts are made within 6 hours, ban for 24 hours
enabled  = true
filter   = asterisk
action   = iptables-allports[name=ASTERISK, protocol=all]
              sendmail[name=ASTERISK, dest=, sender=]
logpath  = /var/log/asterisk/messages
maxretry = 4
findtime = 21600
bantime = 86400

et créer le fichier suivant :

filter.d/asterisk.conf

et copier le code suivant pour asterisk 1.4 et 1.6 :

# Fail2Ban configuration file
#
#
# $Revision: 251 $
#

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

#_daemon = asterisk

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>S+)
# Values:  TEXT
#

failregex = NOTICE.* .*: Registration from '.*' failed for '<HOST>' - Wrong password
            NOTICE.* .*: Registration from '.*' failed for '<HOST>' - No matching peer found
            NOTICE.* .*: Registration from '.*' failed for '<HOST>' - Username/auth name mismatch
            NOTICE.* <HOST> failed to authenticate as '.*'$
            NOTICE.* .*: No registration for peer '.*' (from )
            NOTICE.* .*: Host  failed MD5 authentication for '.*' (.*)
            NOTICE.* .*: Registration from '.*' failed for '<HOST>' - Device does not match ACL
            NOTICE.* .*: Registration from '.*" .* failed for '<HOST>' - Peer is not supposed to register
            VERBOSE.*SIP/<HOST>-.*Received incoming SIP connection from unknown peer

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

et pour la version 1.8, le code suivant :

# Fail2Ban configuration file
#
#
# $Revision: 251 $
#

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

#_daemon = asterisk

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>S+)
# Values:  TEXT
#
# Asterisk 1.8 uses Host:Port format which is reflected here

failregex = NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - Wrong password
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - No matching peer found
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - No matching peer found
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - Username/auth name mismatch
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - Device does not match ACL
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - Peer is not supposed to register
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - ACL error (permit/deny)
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - Device does not match ACL
            NOTICE.* .*: Registration from '".*".*' failed for '<HOST>:.*' - No matching peer found
            NOTICE.* .*: Registration from '".*".*' failed for '<HOST>:.*' - Wrong password
            NOTICE.* <HOST> failed to authenticate as '.*'$
            NOTICE.* .*: No registration for peer '.*' (from <HOST>)
            NOTICE.* .*: Host <HOST> failed MD5 authentication for '.*' (.*)
            NOTICE.* .*: Failed to authenticate user .*@<HOST>.*
            NOTICE.* .*: <HOST> failed to authenticate as '.*'
            NOTICE.* .*: <HOST> tried  to authenticate with nonexistent user '.*'
            VERBOSE.*SIP/<HOST>-.*Received incoming SIP connection from unknown peer

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

Ce code fonctionne pour asterisk 10 et 11 même si je bosse sur une amélioration.

Howto : comment utiliser Sipp pour tester la montée en charge de votre serveur SIP ?

Après le précédent guide détaillant l’installation de sipp sur debian/centos, il est temps maintenant d’apprendre à utiliser ce fabuleux outil.

Le scénario du jour (sur sipp, nous avons la possibilité de créer de nombreux scenarii ce qui apporte une grande richesse à cet outil open source) a pour but de tester la montée en charge de votre tout nouveau serveur SIP que ce soit un Asterisk, un Freeswitch, un Kamailio, un Opensips ou tout autre solution libre ou propriétaire.

Voici le schéma du test, SIPP et le proxy SIP étant installés sur 2 serveurs différents :

Sipp UAC —> Proxy SIP —> Sipp UAS

Sipp Client :

./sipp -sf uac_pcap.xml -d 10000 -s 0917000000 10.254.254.249:5060 -l 10000 -mi 10.254.254.9 -i 10.254.254.9 -mp 6000 -r 1

Explication de la commande :

  • -sf uac_pcap.xml : exécute le scénario contenu dans le fichier xml
  • -d 1000 : définit la durée de l’appel en ms (durée de l’instruction pause du script pour être précis)
  • -s 0917000000 : définit le username de la requête URI 10.254.254.249:5060 : serveur à tester avec le port d’écoute SIP
  • -l 10000 : nombre max d’appels simultanés
  • -mi 10.254.254.9 : adresse IP locale pour le flux média
  • -i 10.254.254.9 : adresse IP de l’interface locale d’écoute -mp 6000 : port local RTP echo (défaut : 6000)
  • -r 1 : nombre d’appels par seconde

Sipp Serveur :

./sipp -sf uas.xml -p 5062 -i 192.168.52.221 -mi 192.168.52.221 -mp 7000

La configuration de votre proxy SIP est à adapter en conséquence : les 2 comptes SIP (client et serveur) et la table de routage des appels.

Bon test.

HowTo : comment installer Sipp sur centos / debian afin de tester les performances de votre serveur de téléphonie SIP ?

Introduction

Vous venez de finir d’intégrer votre nouveau serveur de téléphonie SIP, de finir le développement d’une nouvelle application SIP. Il est maintenant essentiel de savoir si elle va pouvoir tenir la montée en charge ? Encore une fois, un outil open source vous apporte une solution performante : SIPP .

Présentation de SIPP

SIPP est une application permettant de générer au travers de scenarii des appels vers un serveur SIP ainsi que de recevoir des appels. Vous pourrez ainsi connaître la capacité de votre système en terme du nombre d’appels maximum qu’il peut supporter, le nombre de nouveaux appels par seconde et bien d’autres statistiques SIP.

Installation de SIPP

Voyons maintenant comment l’installer.

Installation du serveur Centos / Debian

L’objectif de ce guide n’étant pas l’installation pas à pas d’un serveur Centos / Debian, je suppose que vous venez d’installer un nouveau serveur tout propre avec le CD Netinstall (j’ai toujours préféré une installation de base minimaliste, et de n’installer que le strict nécessaire).

Installation des dépendances

Les pré requis de SIPP sont les suivants :

  • compilateur C++
  • librarie Curses
  • OpenSSL
  • libnet et libcap (pour le support RTP)

Après vous être connecté sur votre serveur, nous allons installer les différentes dépendances :

-> Centos

yum install make gcc gcc-c++ ncurses ncurses-devel openssl libnet libpcap libpcap-devel  gsl gsl-devel

-> Debian

apt-get install make gcc g++ automake autoconf libncurses5-dev python build-essential openssl libpcap-dev libssl-dev libnet1-dev libgsl0-dev gsl-bin libgsl0ldbl

Installation des sources de SIPP

Passons au téléchargement et à l’installation des sources de SIPP (à l’heure de l’écriture de l’article, la dernière version stable est la 3.2) :

cd /usr/src
wget http://sourceforge.net/projects/sipp/files/sipp/3.2/sipp.svn.tar.gz
tar -zxvf sipp.svn.tar.gz

Compilation et installation

Avant de lancer la compilation, nous allons modifier 2 fichiers.

Dans un premier temps, on se positionne dans le répertoire de sipp :

cd /usr/src/sipp.svn

Le premier afin d’activer la notion de limites aux scenarii. Pour cela, il faut éditer le fichier scenario.hpp et ajouter après la ligne :

#include

cette ligne :

#include

Ensuite, nous allons activer le support GSL. Pour cela, il faut éditer le fichier local.mk et dé-commenter les lignes (sauf la première, c’est un commentaire !).

Nous allons maintenant passer à l’étape de compilation et installation (ce n’est pas bien compliqué):

make pcapplay_ossl

Voilà, c’est fini.

Conclusion

Vous avez maintenant installé la dernière version stable de SIPP dans le répertoire suivant : /usr/src/sipp.svn .

Vous pouvez maintenant jouer vos différents scénario :

  • en tant que UA serveur :
    ./sipp -sn uas
  • en tant que UA client :
    ./sipp -sn uac IP_address

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.

Comment résoudre une mauvaise qualité de communication VoIP ?

Vous avez déployé une solution de VoIP et vous rencontrez des problèmes de qualité. Alors, que les communications doivent être d’une qualité équivalente au numéris ou proche (dans le cas de compression), vous subissez des blancs, de l’écho, une voix métallique voir même des coupures de communications.

Introduction

Dans l’article, je vais considérer que le site dispose d’un câblage informatique de qualité suffisante et que le matériel déployé est de bonne qualité (switch, routeur, IPBX, postes téléphoniques, passerelles …).

Déterminer l’origine des problèmes

Il va être important dans un premier de temps de déterminer si le problème vient des communications externes ou si le problème intervient aussi sur les communications sur le même site. Si les appels entre 2 postes IP (important) sur le même site (avec l’IPBX en local si nous ne sommes pas en centrex) sont dégradés, il va falloir dans un premier temps résoudre ce problème. Pour cela, il faut vérifier quelques paramètres cruciaux :

  1. quel est le codec utilisé : le codec a une influence sur la qualité perçue. si on a un PABX, utilisez le G711 voire G722 (codec large bande permettant de mieux reproduire la voix). En mode centrex, il peut être souhaitable d’économiser la bande passante, alors le G729 sera le codec de choix.
  2. le mode peer to peer activé : si oui, le flux RTP reste sur le réseau local en mode centrex, la connexion se faisant de poste à poste. Le WAN n’intervient donc pas dans le flux voix en dehors de la signalisation (qui peut-être considéré dans un premier temps comme négligeable d’un point de vue bande passante si on le compare aux flux RTP). Sinon, pour un appel entre 2 postes sur le même site, nous avons 1 appel sortant et 1 appel entrant sur le site, il y a donc un impact sur le WAN.
  3. la fonction VAD (Voice Activity Detection) est-elle activée ? cette fonctionnalité intéressante permet de limiter la bande passante d’une communication en supprimant les paquets incluant les silences. Suivant les réglages, l’économie peut-être importante. Cette fonction est inutile en local, et doit-être désactivée. Elle est difficile a bien paramétrer, et en cas d’erreur les mots seront coupés, les communications pouvant devenir inaudibles.
  4. un VLAN voix a t’il été paramétré appliquant la CoS voix aux flux concernés ?
  5. vérifier que les équipements sont bien à jour, car une version firmware peut avoir un défaut expliquant le problème.

En général, les problèmes sont surtout rencontrés lors des appels externes. En effet, la bande passante est alors plus limitée, les communications passent parfois sur internet et le lien est aussi parfois partagé avec d’autres flux.

VoIP via internet

Je ne conseillerai jamais assez de ne pas transporter la voix sur internet. Internet n’a pas été conçu pour transporter des flux temps réels et ne sait pas garantir la qualité (cela ne veut pas dire que cela ne marche pas). De plus, la sécurité sera aussi difficile à assurer. Je vous laisse imaginer ce que je pense des offres de trunk SIP via internet. Il suffit d’aller voir la liste des failles de sécurité pour prendre peur, mais ce n’est pas le sujet du jour, mais d’un prochain article.

Autres informations essentielles

En plus des questions posées plus haut, il faut aussi obtenir d’autres informations :

  1. Nombre d’appels simultanés externes
  2. Bande passante du lien haut débit (en IP)
  3. Le lien est-il dédié à la voix ? si non, quels sont les mécanismes qui prioritisent la voix sur les autres flux ?
  4. Les flux voix empruntent ils internet ou restent sur le réseau de l’opérateur ?
  5. En mesurant les flux sur le lien, vous pourrez vérifier si le lien est saturé, si les règles sont bien appliquées ou si le lien souffre de perte de paquets ou de gigue.

Quelques pistes

Ne connaissant pas vos cas particuliers, je ne peux pas allez beaucoup plus loin, mais si vous avez des connaissances réseaux suffisantes et en répondant aux questions ci-dessous, vous avez toutes les billes pour trouver la source du problème. Pour vous aider un peu plus, on peut obtenir des informations intéressantes en écoutant la qualité de la voix.

  • Vous avez des blancs en court de communication, il faut regarder du côté de la VAD si elle est activée. Ensuite, cet effet peut-être causé par de la perte de paquet ou une gigue trop importante du lien WAN. Cela peut aussi être dû à une règle de QoS mal définie.
  • Vous avez des bruits ou des craquements. Ils sont souvent causés par une congestion du LAN ou du WAN.
  • Vous avez une voix de robot, regardez du côté de la perte de paquet dûe à une gigue trop importante. (reste à trouver la source de cette gigue).
  • Vous avez de l’écho. Cela est dû à un problème de réglage de l’echo canceller du PABX ou de la gateway.

J’écrirai prochainement un article détaillé sur les symptômes et les causes qui s’y rattachent.

Asterisk peut-il remplacer votre PABX ?

Lors de projet de renouvellement de leur PABX, beaucoup de personnes se pose la question de l’opportunité de migrer sur une solution open source comme Asterisk. La principale motivation étant de réaliser des économies, de récupérer l’exploitation en interne et de l’intégrer au sein de l’infrastructure informatique.

Historique

Asterisk a été créé en 1999 par Mark SPENCER (un gars exceptionnel que j’ai eu l’occasion de rencontrer plusieurs fois). Le code du logiciel est distribué en open source sous la licence GPL. Le site du projet est tout simplement www.asterisk.org

Présentation d’Asterisk

Asterisk est un logiciel permettant de mettre en oeuvre un PABX, c’est à dire de relier entre eux des téléphones de technologies différentes et des trunks. Les trunks sont des accès opérateurs, comme les accès numéris, analogique ou SIP. Asterisk est compatible avec tous les postes IP compatibles avec la norme SIP, IAX et SCCP. On peut aussi connecter des postes analogiques et des postes sans fil via des gateways. Une gamme impressionnante de carte permet de se raccorder aux réseaux des opérateurs.

Nous l’avons vu, au niveau des périphériques, l’offre est très importante et n’a pas à pâlir des solutions payantes concurrentes. Mais, car il y a un gros mais, quand vous installez Asterisk, vous n’obtenez pas un PABX. Vous avez une excellente base, mais sans programmation, il vous ne pouvait pas passer un appel. Afin de construire votre PABX, il vous faudra programmer toutes les fonctions dont vous avez besoin. C’est là que se situe toute la difficulté, car à moins de maîtriser les langages de programmation propre à Asterisk, vous arriverez juste à émettre et à recevoir des appels, mais sûrement pas à faire des interceptions et encore moins mettre en oeuvre la fonction patron-secrétaire. La mise en oeuvre de fonctionnalités évoluées et une intégration parfaite avec les postes nécessitent une excellente expertise. Vous remarquerez aussi que je n’ai pas parlé de fiabilité et de stabilité. Installer Asterisk pour une personne maîtrisant linux, n’est pas une chose compliquée notamment sur Centos. Sécuriser et fiabiliser cette même installation est autrement plus complexe, notamment quand le volume d’appels à traiter est assez important.

Les avantages d’Asterisk

Asterisk a pourtant des avantages à faire valoir par rapport aux PABX du marché. Quand vous achetez un PABX, vous ne pouvez installer que les postes du constructeurs, avec Asterisk vous avez le choix. Vous aurez (ou votre intégrateur) juste à adapter les scripts en conséquence. Vous n’avez plus de limite dans les programmations souhaitées et dans les circuits d’appels, problèmes par contre souvent rencontrés avec les PABX. Vous restez aussi maître des coûts d’évolution, en effet il n’y a pas de licences par utilisateurs, ou de cartes à ajouter. Il faudra par contre surveiller le dimensionnement du serveur.

Et la sécurité ?

J’ouvre un chapitre sur la sécurité. Le monde du PABX m’a souvent étonné par l’ignorance des risques associés. Combien d’entreprises ont vu leur PABX piratés ? mieux, combien se sont aperçues du piratage (en dehors de la facture) ?

Les PABX sont rarement en dernière version logicielle essentiellement pour des questions de coûts ou d’ignorance. Le parc est donc en production avec des failles de sécurité et des bugs non corrigés. Mais connaissez vous la liste des bugs et des failles de la version que utilisez chaque jour ? les hackers oui. Avec Asterisk, vous connaissez les bugs, vous pouvez ainsi mettre en place les procédures nécessaires pour les corriger ou les contourner, appliquer le dernier patch.

Le second point de la sécurité concerne les communications IP. A ce jour, Asterisk ne sait pas crypter les flux RTP (mais c’est en cours), mais peu de solutions constructeurs le proposent. Ceux qui ont ce besoin de part leur activité doivent garder cela en mémoire et bien étudier les fiches techniques des constructeurs afin de vérifier si ce point du cahier des charges est parfaitement rempli.

Asterisk est une solution logicielle qui demande de la maintenance logicielle. Souvent cet effort est oublié par les entreprises quand elles intègrent une solution open source. Et pourtant, cette maintenance va garantir la sécurité, la stabilité et l’évolutivité de votre PABX.

Alors, puis-je installer Asterisk dans mon entreprise ?

L’objectif de l’article étant de répondre à la question : puis-je installer Asterisk dans mon entreprise?

La réponse est oui.

Ai-je un intérêt financier à le faire ?

Cela va dépendre de votre expertise, de la taille de votre entreprise et de votre cahier des charges. Il existe des intégrateurs qui ont développé à partir d’Asterisk des PABX soit en mode licence soit en mode appliance (serveur + Asterisk + scripts). Pour les entreprises aux besoins standardisés et sans expertise, cette alternative peut permettre de réaliser des économies tout en bénéficiant des avantages d’Asterisk.

Il faut vérifier tout de même que la solution ne devient pas closed source (vous vous retrouverez dans le cadre d’un PABX constructeur).

Conclusion

En conclusion, je vais parler de mes propres expériences. Je travaille sur Asterisk depuis 2001 et j’ai donc suivi l’évolution impressionnante du projet. J’ai réalisé des intégrations pour des centres d’appels, des entreprises multi site et du centrex. J’utilise aussi Asterisk pour combler des lacunes de PABX en place. Le projet est extrêmement puissant et ouvre des possibilités infinies à qui sait les exploiter. 😉