Comment sécuriser Django, framework python

Comment sécuriser une application web avec le framework python Django ?

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.

Pourquoi sécuriser Django ?

La sécurisation de l’interface d’administration est essentielle. Elle permet de gérer a création et la suppression de comptes SIP, la modification de mots de passe, l’augmentation des limites comme le nombre d’appels simultanés ou le volume d’appels journaliers. Un système d’anti-fraude peut ainsi être facilement détourné, un compte utilisateur pirate créé et des routes créées. Un assaillant peut aussi récupérer les données des accès opérateurs ou la base clients.

Les risques

Je vais maintenant présenter les types d’attaque les plus courantes et puis montrer comment avec Django mettre en oeuvre des solutions afin de limiter le risque.
L’OWASP est une communauté spécialisée dans la sécurité des applications web. Ils proposent notamment des outils afin de tester la sécurité des applications web. Un projet va particulièrement nous intéresser : OWASP Application Security Verification Standard (ASVS) . Je vous engage notamment à lire les cheatsheets mises à disposition.
Voici le top ten des risques définis par l’OWASP (les liens conduisent à la page détaillant chaque item) :

Mise en oeuvre des contre-mesures

Maintenant que nous avons identifié les risques et nous avons une base documentaire solide sur laquelle nous appuyer, nous allons voir les contre-mesures pour sécuriser Django.

Les injections

Tout d’abord, nous allons voir les injections SQL. Django fournit un ORM qui permet de se protéger de ce risque en échappant les variables avant de soumettre la requête à la base de données. A la condition, de ne pas utiliser la fonction RawSQL permettant d’utiliser du code SQL natif. Dans ce cas, c’est au développeur de valider les variables utilisées dans la requête !
Attention : l’ORM ne dispense pas de valider les variables, c’est une bonne pratique !

L’authentification

Nous allons retrouver plusieurs sous parties.
Tout d’abord, nous allons voir comment se protéger des attaques par brute force.
Pour se protéger des attaques que subissent constamment les pages de login, les attaques par brute force, j’utilise le package django-axes . Il permet de bloquer une adresse IP après un nombre prédéfini de tentatives infructueuses. La configuration par défaut est très satisfaisante, mais je vous invite à lire la documentation de django-axes afin de tuner votre configuration selon vos souhaits, notamment si vous avez besoin de whitelister quelques adresses IP.
Toutes les tentatives sont accessibles via l’interface d’administration incluant les adresses IP, les navigateurs, les noms d’utilisateurs utilisés …
En complément, un honeypot est intégré afin de détecter les robots malveillants testant la page /admin, page identique à la vraie page de connexion ! Toute tentative est ainsi bloquée en amont. Pour cela, j’utilise le package django-admin-honeypot.
Le second point, concerne la robustesse des mots de passe. Très souvent les utilisateurs utilisent des mots de passe trop simples. Afin, de renforcer la complexité des mots de passe, Django intègre des validateurs de mots de passe, dont voici un exemple de configuration :
AUTH_PASSWORD_VALIDATORS = [
{
'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
},
{
'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
'OPTIONS': {
'min_length': 9,
}
},
{
'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
},
{
'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
},
]
Nous allons tout d’abord vérifier que le mot de passe n’est pas trop similaire avec un attribut de l’utilisateur, puis que la longueur minimum est de 9 (je suggère d’augmenter cette valeur), ensuite nous allons vérifier s’il ne fait pas partie d’une liste de mots de passe couramment utilisés et que le mot de passe n’est pas entièrement composé de chiffres. Par ailleurs, il est aussi possible d’intégrer son propre validateur en plus de ceux prédéfinis par Django.
Le stockage du mot de passe en base de données doit aussi être particulièrement surveillé.
Django ne stocke heureusement pas les mots de passe en clair dans la base de données, mais un hash de celui-ci. Nous avons la flexibilité d’utiliser les méthodes de hachage de notre choix, mais dans une liste réputée sécurisée. Par défaut, c’est l’algorithme PBKDF2 avec un hash SHA265.
PyFreeBilling utilise l’algorithme Argon2 étant réputé plus sécurisé.
Il est possible et souhaitable d’activer une double authentification (two-factor authentication). Dans PyFreeBilling, cette fonctionnalité est optionnelle, car selon le type de déploiement, la mise en oeuvre sera plus ou moins complexe. Mais je recommande très fortement la prise en considération de cette fonctionnalité qui va renforcer sensiblement l’application. Pour cela, l’application django que je recommande est django-two-factor-auth qui intègre de nombreux services. Je ne vais pas détailler ici la mise en oeuvre, un article entier serait nécessaire. Je vous encourage à lire la documentation qui est bien faite.

Exposition de données sensibles

Il est essentiel de s’assurer qu’aucune donnée sensible ne puisse être interceptée.
Tout d’abord la mise en oeuvre du protocole HTTPS afin de garder confidentielles les données échangées est indispensable.
Par défaut, Django autorise les échanges via le protocole HTTP, mais pour des raisons évidentes, l’accès à l’interface d’administration de PyFreeBilling est forcée en HTTPS.
Pour cela nous allons forcer le navigateur l’utilisation du protocole HTTPS en activant l’entête HTTP Strict Transport Security ou HSTS.
Django définit cet en-tête pour vous sur toutes les réponses HTTPS si vous définissez le réglage SECURE_HSTS_SECONDS à une valeur entière différente de zéro.
Voici les paramètres correctement configurés :
  • SECURE_HSTS_SECONDS = 15768000 # 6 mois
  • SECURE_HSTS_INCLUDE_SUBDOMAINS = True
  • SECURE_HSTS_PRELOAD = True
Définissez aussi le paramètre SECURE_SSL_REDIRECT sur True, ainsi toutes les demandes non SSL seront redirigées de manière permanente vers SSL.
Ensuite, nous allons intégrer des entêtes HTTP afin d’activer des paramètres de sécurité embarqués dans les navigateurs modernes (et oui, il faudrait bloquer les vieux navigateurs troués comme de vieux torchons).
Anti-click jacking :
Le principe est d’interdire l’affichage d’une page de notre interface d’administration dans une frame. Django possède nativement les protections, mais qu’il faut activer correctement via les variables suivantes :
Tout d’abord il faut activer le middleware « django.middleware.clickjacking.XFrameOptionsMiddleware » afin d’ajouter l’entête X-FRAME-OPTIONS à toutes les réponses.
Par défaut, la valeur de l’entête X-Frame-Options est à SAMEORIGIN, mais il est possible de forcer à DENY ce qui est fait pour l’administration de PyFreeBilling. Ainsi, on interdit au navigateur d’intégrer nos pages dans une iFrame.
Entête CSP :
Les entêtes Content Security Policy ou CSP permet de contrôler la manière dont les ressources sont inclues dans la page.
Afin de gérer ces entêtes, le package django-csp est utilisé (https://github.com/mozilla/django-csp). Il permet de paramétrer très finement nos ressources.
Tout d’abord nos devons activer le middleware « csp.middleware.CSPMiddleware » et ensuite définir les valeurs souhaitées pour les paramètres.
Le choix fait pour PyFreeBilling est de n’utiliser aucune ressources externes pour des raisons de sécurité, mais aussi afin de pouvoir fonctionner sans accès internet (c’est le cas de certains clients). Le paramétrage des entêtes CSP est ainsi simplifié. Pour comprendre en détail les différentes valeurs, je vous engage à lire les spécifications CSP puis la documentation de django-csp.
Protection XSS :
Définissez le paramètre SECURE_BROWSER_XSS_FILTER sur True afin d’activer les protections de filtrage XSS du navigateur.
Entête X-Content-Type-Options :
Enfin, il est avisé d’empêcher le navigateur de déterminer le type de fichier en ajoutant un entête X-Content-Type-Options. Pour cela Django dispose d’une variable (à False par défaut) qu’il faut passer à True : SECURE_CONTENT_TYPE_NOSNIFF (https://docs.djangoproject.com/en/2.1/ref/settings/#secure-content-type-nosniff)

XML entités externes

Je ne vais pas traiter de cette partie, n’utilisant pas ce type de fonctions dans PyFreeBilling. Si vous souhaitez l’utiliser, vous devez soit écrire le code ou utiliser une librairie. Je vous invite à lire la documentation associée et utiliser les éléments de filtrage proposés nativement par Django.
Vous pouvez apporter des éléments en commentaire du présent article pour les futurs lecteurs (je compléterais à l’occasion cette partie)

Broken accès control

Django propose de base une gestion des utilisateurs et des groupes d’utilisateurs. Des décorateurs permettent de définir l’accès à une ressource donnée avec des droits différents : lecture, modification, création … .
Il est aussi possible de définir plus finement l’accès. Un package très utilisé est django-braces.
D’autres plugins permettent de gérer plus finement par objet ou par certains attributs. Dans tous les cas, c’est de la responsabilité du développeur d’utiliser correctement ces outils et de tester les accès suivant les différents typologies d’utilisateurs.

Mauvaises configuration de sécurité

C’est l’objet de l’article de pointer sur les points d’attention lors du paramétrage d’un projet Django. Il existe des outils afin de valider que rien n’a été oublié.
Je vous en propose 2 :
FreesScan de Qualys qui va permettre de tester en profondeur votre site avec un rapport  précis. Il va tester les certificats et la configuration du serveur web. Voici la note obtenue par un déploiement de PyFreeBilling de base sous docker :
Tous les éléments ne sont pas testés, mais ça permet de valider rapidement notre déploiement.
Et l’Observatory, outil de Mozilla permettant de vérifier de nombreux points de sécurité : il valide la sécurité des en-têtes OWASP, les meilleures pratiques TLS et effectue des tests tiers à partir de SSL Labs, High-Tech Bridge, des en-têtes de sécurité, du préchargement HSTS, etc. Il est particulièrement complet et aussi très instructif.

Cross-Site Scripting (XSS)

C’est une des failles visant le navigateur des utilisateurs. Nous allons voir comment des paramètres Django vont pouvoir nous prémunir contre elles, sachant que les outils automatisées savent les détecter et les exploiter !
Nous avons déjà vu dans la section « exposition de données sensibles » en ajoutant des entêtes HTTP en ajoutant des paramètres nous protégeant de failles XSS. Nous allons voir comment nous protéger du vol de sessions.
Il s’agit de bloquer l’accès à un code javascript exécuté dans le navigateur par un assaillant au cookie de session . Pour cela, nous allons forcer l’envoi de l’entête httpOnly transmise avec le cookie.

Les sessions sont gérées par le middleware : ‘django.contrib.sessions.middleware.SessionMiddleware’, et l’activation de l’entête est faite par la variable SESSION_COOKIE_HTTPONLY (https://docs.djangoproject.com/en/2.1/ref/settings/#std:setting-SESSION_COOKIE_HTTPONLY).
Explication de la team django : ‘It’s recommended to leave the SESSION_COOKIE_HTTPONLY setting on True to prevent access to the stored data from JavaScript.’
Afin de renforcer la sécurité des cookies, nous allons modifier 2 paramètres :
Enfin, nous allons forcer l’échange de cookies uniquement via une connexion HTTPS : la configuration par défaut est à False. Pour forcer l’échange via HTTPS, il faut mettre SESSION_COOKIE_SECURE à True.
La doc de référence de Django pour les sessions : https://docs.djangoproject.com/en/2.1/topics/http/sessions/

Insecure Deserialization

Je vais faire la même remarque que pour le traitement de document XML.

Utiliser des composants incluant des vulnérabilités connues

Django étant un framework python, vous avez plusieurs outils vous permettant d’être notifié quand une dépendance est mise à jour. Mais surtout, certains outils peuvent envoyer une notification quand une dépendance utilisée contient une faille de sécurité. J’utilise PyUp pour cela. Ils annoncent surveiller 173 000 dépendances python !

Si votre projet utilise aussi du code qui n’est pas écrit en python, ce qui est souvent le cas comme du javascript, d’autres outils existent. Pour ce javascript, npmjs ou Retire.js pourront vous être très utiles. Retire.js propose même des extensions pour Chrome et Firefox !

OWASP dispose aussi d’un outil pouvant être intégré dans votre Jenkins préféré appelé OWASP Dependency Check. Il supporte actuellement les langages Java, .NET, Ruby, Node.js, Python et partiellement C++.

Insufficient Logging&Monitoring

Il est en effet essentiel de logger les erreurs mais surtout de les traiter. Django propose des outils de génération de logs poussés. Une section dédiée à la génération de logs liés à la sécurité : https://docs.djangoproject.com/en/2.1/topics/logging/#django-security.

Pour un gros projet, un outil comme Sentry qui s’intègre parfaitement avec Django est un très intéressant.

Et pour surveiller votre application Django, les packages de monitoring sont listés dans https://djangopackages.org/grids/g/monitoring/

Conclusion

Nous avons vu au cours de cette article que la sécurisation d’une application web est une tâche complexe nécessitant de bien connaître les risques. Un framework puissant comme Django, à condition de bien le maîtriser, nous facilite la tâche.

Et pour finir, je vais vous partager un dernier truc afin d’améliorer la sécurité de notre projet Django : restreindre l’accès à toutes ou certaines URL à une ou plusieurs adresses IP.

Pour cela, le package django-iprestrict est l’outil adéquate. Afin de bloquer/autoriser l’accès à partir de région ou pays, geoip2 sera utilisé. Tout d’abord, il faut activer le middleware « iprestrict.middleware.IPRestrictMiddleware ». Le paramétrage se fait ensuite dans l’interface d’administration.

Et surtout pour sortir sécuriser Django correctement, sinon tous vos efforts auront été vains, assurez-vous d’utiliser un SECRET_KEY long, aléatoire et unique !

Si vous avez des remarques ou des packages intéressants à partager afin d’améliorer la sécurité d’un projet Django, les commentaires sont à votre disposition.

 

Hiawatha, serveur web sécurisé, utilise mbed TLS

Hiawatha, serveur web sécurisé, utilisent maintenant mbed TLS. Explication de ce changement.

Lors de la Release 9.12, Hiawatha, un serveur web sécurisé open source,  a annoncé utiliser maintenant mbed TLS au lieu de PolarSSL. En effet, ARM a acquis PolarSSL qui a été renommé mbed TLS. Juste un changement de nom ? (malheureux, car comment perdre de la renommée, mais ce n’est que mon humble avis). En fait non, car des changements sont intervenus au niveau du code ce qui a pour conséquence une perte de compatibilité avec les anciennes versions de PolarSSL. Hiawatha ne supporte plus que les versions de mbeb TLS à partir de la version 1.3.10.
Attention lors de vos mises à jour, même si l’impact doit être nul d’après le mainteneur.

Par ailleurs, les nouvelles versions des paquets debian sont disponibles comme d’habitude grâce à Chris sur le site files.tuxhelp.org. Enfin, si vous recherchez un package pour votre Raspberry PI préférée, c’est par ici : https://files.intermezzo.net/hiawatha_raspi/

Par ailleurs, je suis curieux de connaître le retour d’expérience d’utilisateurs de Hiawatha ainsi que les raisons de leur choix. Postez un message en commentaire !

Sécurité des iPBX : responsabilité des intégrateurs

Je viens d’avoir un appel téléphonique d’un responsable d’une société qui vient de subir une fraude sur son installation téléphonique. Alerté par son opérateur, Orange pour ne pas le citer, il vient de subir des appels frauduleux pour un montant dépassant les 10k euros. Juste de quoi vous gâcher la journée.

L’opérateur ayant fait le nécessaire (suppression des appels à l’étranger), il cherche maintenant à savoir qui va payer cette facture bien salée. Et pour cela, il faut chercher le responsable, qui a fait la boulette. Un détournement des accès téléphoniques, un employé malintentionné ou une faille du système téléphonique.

Après un audit des accès téléphoniques de l’iPBX, cette hypothèse est rapidement écartée comme la seconde (les montants en jeu sont trop importants). Il reste donc l’hypothèse malheureusement la plus courante, une faille sur le système téléphonique.

Seul un audit permettra de déterminer quelle faille a été exploitée, et si cette faille est la conséquence d’une négligence dans la programmation et la maintenance du standard téléphonique. Malheureusement un certain nombre d’installateurs téléphoniques ou intégrateurs prennent la sécurité des équipements et des systèmes à la légère. Pour preuve, la non application des matchs de sécurité sur certains parcs de PABX pourtant reconnus vulnérables, ou la mise en oeuvre d’architecture dont la conception même fragilise toute l’infrastructure informatique de la société cliente.

Il est grand temps que le petit monde de la téléphonie (installateurs, éditeurs, constructeurs …) adopte des pratiques strictes en terme de sécurité. Et pour commencer, la mise à disposition des patchs de sécurité devrait être gratuit (ce n’est pas encore le cas de tous les constructeurs) et le déploiement des mises à jour de sécurité inclu au contrat de maintenance en incluant des SLA (délai de déploiement de la mise à jour maximum garanti …). Une veille technique devrait aussi faire partie de ces contrats avec une information claire diffusée au client.

Les intégrateurs ou installateurs privés en tant que professionnels reconnus sont responsables devant la loi du respect des bonnes pratiques. Laisser un mot de passe par défaut ou faible est un exemple simple, mais qui engage la responsabilité du prestataire. Comme le fait de ne pas avoir répondu aux solicitations de son client lui demandant de mettre à jour le système, ou le fait d’avoir programmé le système en ignorant les règles de sécurité connues.

Les attaques se faisant de plus en plus nombreuses, j’espère qu’à la fois les clients (ceux qui refusent de mettre à jour leur système et qui refusent tout contrat d’infogérance) et les professionnels prennent plus sérieusement en compte ces risques.

Téléphone SIP Snom : alerte de sécurité

Une alerte de sécurité vient d’être publiée ce jour sur le site Security Focus concernant les téléphones SIP de la marque SNOM. Les alertes sont de type critique. Si vous utilisez ces téléphones dans votre entreprise ou chez vos clients, je vous invite à lire de manière attentive cette alerte et d’apporter les correctifs nécessaires.

L’alerte touche les téléphones de bureau des gammes 3xx, 7xx et 8xx .

Les vulnérabilités touchent l’implémentation du serveur web implanté dans le téléphone, donc potentiellement toutes les actions utilisant ce serveur.

Les téléphones peuvent être compromis complètement par une attaque externe et il est possible de faire :

  • ajouter une backdoor au système, backdoor qui restera même si le téléphone est remis à 0 (reset)
  • activer à distance le microphone du téléphone afin d’écouter la pièce où est situé le téléphone
  • récupérer les conversations réalisées via le téléphone en installant un sniffer
  • rediriger les appels vers des numéros spéciaux avec pour conséquence une facture fortement alourdie.
  • utiliser le téléphone comme point d’entrée pour attaquer le réseau interne

La recommandation est terrible : ne pas utiliser le téléphone tant qu’un nouveau firmware ne vienne corriger les failles découvertes !

It is highly recommended by SEC Consult not to use this product until a
thorough security review of the firmware has been performed by security
professionals and all identified issues have been resolved.

Si vous voulez quand même utiliser ces téléphones, qui sont des produits de qualité, il faut respecter des règles strictes (règles qui devraient être mis en place dans tous les cas, quelque soit le téléphone) :

  • ne pas exposer l’interface web à l’extérieur de votre réseau, mais uniquement à des machines de confiance
  • ne pas réaliser d’auto-provisioning via un réseau externe non chiffré et bloquer la configuration via le serveur de Snom (provisioning.snom.com) – Ce provisioning est réalisé via le protocole HTTP non chiffré
  • ne pas exposer le port 5060 à l’extérieur de votre réseau sans avoir mis en place un filtrage

Pour conclure, si vous utilisez le client OpenVPN embarqué dans le téléphone, je vous engage à bien lire cette note de sécurité du wiki de Snom, et de réaliser au plus vite la mise à jour de vos téléphones.

Pourquoi installer DenyHosts sur son serveur ?

Il existe plusieurs de manière de bloquer les vilains assaillants essayant de se connecter à votre serveur en SSH. Vous pouvez utiliser Fail2ban, iptables mais aussi DenyHosts. Alors, pourquoi absolument installer DenyHosts ?

DenyHosts se différencie de Fail2ban sur plusieurs points :

  • il ne s’occupe que du ssh alors que Fail2ban sait bloquer un grand nombre de services se basant sur l’authentification par mot de passe et ayant la capacité de logguer les essais infructueux dans le bon fichier de log
  • le mode de blocage est différent, Fail2ban utilise iptables alors que DenyHosts utilise TCP Wrappers (leurs actions étant différentes, on comprend qu’ils sont complémentaires)
  • synchronisation entre plusieurs DenyHosts : vous avez plusieurs serveurs, et grâce à cette fonction dès qu’un de vos serveurs subis une attaque, tous vos serveurs blacklistent cette IP
  • partage des IP blacklistées via www.denyhosts.net, vous envoyez vos IP blacklistées, mais vous pouvez aussi recevoir les IP blacklistées par les autres utilisateurs (vous pouvez définir des seuils)

Vous aurez compris que DenyHosts, Fail2ban et iptables correctement configurés doivent cohabiter sur vos serveurs.

Je ne vais pas vous détailler l’installation et la configuration de DenyHosts, le fichier de conf /etc/denyhosts.conf est parfaitement commenté.

Si vous hésitez sur la valeur d’un paramètre, je vous invite à poster un message.

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. 😉

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.