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.

PfSense : exporter la configuration client OpenVPN

Présentation de PFSense

PFSense est une appliance de sécurité réputée que j’apprécie tout particulièrement. PFSense permet, entre autres fonctions, de jouer le rôle de serveur VPN (IPSEC, PPTP, L2TP et OPENVPN).

Choix du serveur VPN

Je conseille d’utiliser OpenVPN de part sa simplicité (versus IPSEC), sa possibilité de fonctionner un peu n’importe où (même via des réseaux très strict, il suffit de bien configurer les ports) et sa sécurité (versus PPTP et L2TP). Par contre, l’intégration de la configuration pour les utilisateurs mobiles n’est pas toujours simple, notament face à la multitude des systèmes d’exploitations.

Configuration des terminaux

Vous trouverez, grâce à la vivante communauté de PFSense, un package facilitant les exports de configuration, que ce soit vers les ordinateurs sous windows, Linux et MacOSX, mais aussi vers les terminaux mobiles et tablettes comme Android et IOS ( une application Openvpn pour IOS est disponible sur le store US depuis quelques semaines. Peut-être bientôt en Europe, ainsi plus besoin de rooter son idevice afin de profiter d’OpenVPN).

Client Android

Je peux vous conseiller un client Android de qualité qui ne nécessite pas de rooter votre terminal. Il s’agit de FeatVPN . Une version est disponible sur le google store, mais il est recommandé d’installer la version disponible sur leur site web. Faites bien attention de choisir le bon apk selon votre version d’Android.

Procédure d’installation

Apres avoir téléchargé la configuration pour votre utilisateur sous Android sur votre ordinateur via l’interface web de PFSense, il faut copier ce fichier sur la carte SD de votre téléphone ou tablette.

Ensuite, il faut lancer votre FeatVPN, sélectionner « Tunnels », puis le bouton « Add », aller dans la partie « Configuration » et cliquer sur « Load ». Il faut ensuite choisir le fichier que nous venons de copier sur la carte SD. La configuration se fait tout seul. Je vous conseille fortement de ne pas stocker votre mot de passe sur votre terminal Android, car en cas de perte ou de vol, votre réseau sera accessible le temps que vous révoquiez le certificat utilisateur.

Conclusion

Plus de raison de ne plus sécuriser l’accès à votre infrastructure loin de vos bases, PFSense et OpenVPN vous apportent une solution fiable, performante et pérenne.

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.

Howto : comment renforcer la sécurité du réseau sous linux avec sysctl ?

Il est essentiel de sécuriser ses machines sous linux. Il y a plusieurs étapes indispensables à suivre. Aujourd’hui, nous allons voir comment sysctl va nous aider.

En modifiant un seul fichier de conf, nous allons renforcer la protection réseau :

  • protection contre l’ IP Spoofing
  • protection contre les scans
  • amélioration des logs pour permettre des traitements avec des outils tiers comme fail2ban
  • paramétrages divers

Nous allons éditer le fichier /etc/sysctl.conf et ajouter ou décommenter les lignes suivantes :

# IP Spoofing protection 
net.ipv4.conf.all.rp_filter = 1 
net.ipv4.conf.default.rp_filter = 1

# Ignore ICMP broadcast requests 
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Disable source packet routing 
net.ipv4.conf.all.accept_source_route = 0 
net.ipv6.conf.all.accept_source_route = 0 
net.ipv4.conf.default.accept_source_route = 0 
net.ipv6.conf.default.accept_source_route = 0

# Ignore send redirects 
net.ipv4.conf.all.send_redirects = 0 
net.ipv4.conf.default.send_redirects = 0

# Block SYN attacks 
net.ipv4.tcp_syncookies = 1 
net.ipv4.tcp_max_syn_backlog = 2048 
net.ipv4.tcp_synack_retries = 2 
net.ipv4.tcp_syn_retries = 5

# Log Martians 
net.ipv4.conf.all.log_martians = 1 
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Ignore ICMP redirects 
net.ipv4.conf.all.accept_redirects = 0 
net.ipv6.conf.all.accept_redirects = 0 
net.ipv4.conf.default.accept_redirects = 0 
net.ipv6.conf.default.accept_redirects = 0

# Ignore Directed pings 
net.ipv4.icmp_echo_ignore_all = 1

Vous sauvegardez et quittez. Il faut ensuite recharger sysctl pour la prise en compte des modifications :

sysctl -p

Et voilà !

HowTo : comment faire des recherches sur google anonymement ?

Chaque fois que vous faites une requête de recherche via google, google trace tous vos faits et gestes. Vous souhaitez malgré tout continuer à profiter de l’exhaustivité de la base de données de google tout en protégeant votre vie privée. Oui, c’est possible. Il y a un site pour ça : startpage.com .

Ils s’engagent dans leur charte à n’enregistrer aucune donnée personnelle, ni l’adresse IP du terminal et n’enregistre aucun cookie. Les requêtes via leur serveur se font via une connexion cryptée et sécurisée.

Startpage appartient à une société de droit hollandais. Le moteur de recherche a obtenu plusieurs prix : 1er prix du label européen de la protection de la confidentialité (European Privacy Seal) décerné par l’autorité de certification Europrise et désigné meilleur métamoteur de recherche par Search Engine Watch en 2000, 2002 et 2004.

Sortie de la version 2.0.2 de PFSense, appliance de sécurité open source de référence

La nouvelle version de PfSense est disponible, la 2.0.2 , en attendant la très attendue 2.1. Cette version corrige 3 failles de sécurité FreeBSD. Je vous engage à upgrader en urgence votre Firewall préféré.

A noter aussi, les corrections de bugs touchant IPSEC et OPENVPN. Vous trouverez la liste complète des fixes sur le blog officiel.

PfSense est une appliance de sécurité open source basée sur FreeBSD, performante et complète. Vous avez besoin d’un firewall, d’un serveur VPN, d’un portail captif … (de nombreux packages complètent les fonctionnalités), je vous engage à découvrir cette superbe solution. Une solution basée sur des boitiers Soekris peut parfaitement faire office de firewall/VPN/Proxy pour les particuliers, télétravailleurs ou PME, et sans rougir des solutions propriétaires onéreuses.

Quel algorithme de chiffrement symétrique (symmetric cipher) choisir ?

Vous souhaitez installer OpenVPN, OpenPGP, OpenSSH ou une autre solution nécessitant l’utilisation d’un algorithme de chiffrement symétrique. Mais entre AES, Blowfish ou DES vous ne savez pas lequel choisir. Voici un comparatif afin de vous aider à choisir.

Un chiffrement symétrique utilise la même clé pour chiffrer et déchiffrer contrairement au chiffrement asymétrique qui utilise des clés différentes (en fait 2 clés : une clé publique, servant au chiffrement, et une clé privée, servant à déchiffrer).

Un rappel de la réglementation en vigueur en France me semble nécessaire. Toute information chiffrée par un algorithme à clef symétrique ne doit pas utiliser de clé supérieure à 128 bits (« service de confidentialité » défini par les décrets du 17 mars 1999, avec une clef de 128 bits).

Pour commencer, je ne vais présenter que les algorithmes le plus souvent rencontrés (la liste des algorithme étant existant étant très longue) : IDEA, TripleDES (DES est exclu du fait de sa lenteur et du fait de la possibilité d’une attaque systématique dans un temps raisonnable), CAST-5, blowfish et AES.

Avant de rentrer plus dans le détail, la solidité d’un algorithme dépend fortement de la taille de la clé. Une clé est une donnée qui permet de chiffrer et de déchiffrer une information après traitement par un algorithme. Par exemple, en 1997, une recherche exhaustive de clé de l’algorithme DES a été réussie. DES est basée sur des clés de 56 bits, soit 2 puissance 56 possibilités !

IDEA est un algorithme breveté par la société Suisse Mediacrypt et depuis tombé dans le domaine public (en 2011 en Europe) est dérivé de l’algorithme PES. Il até présenté la première fois en 1991. Il utilise des blocs de 64 bits avec une clé de 128 bits. Depuis la société, a présenté en 2005 son successeur FOX breveté sous le nom IDEA NXT (clé 128 bits/blocs 64 bits ou clé 256 bits/blocs 128 bits).

Publié en 1979, 3DES ou Triple DES a été développé par Walter Tuchman en enchainant 3 traitements successifs de l’algorithme DES. Il utilise 3 clés DES de 56 bits sur des blocs de 64 bits. Il est vulnérable aux attaques de type « rencontre au milieu ». De ce fait, il est admis qu’il fournit une sécurité effective de 112 bits seulement. 3DES est largement utilisé dans l’industrie électronique.

CAST5 ou CAST-128, a été conçu en 1996 utilise des clés allant de 40 à 128 bits pour des blocs de 64 bits. Il est notamment validé par le gouvernement canadien et est utilisé par défaut dans de nombreux produits.

Blowfish est aussi présent dans de nombreuses solutions (par défaut dans OpenVPN par exemple). Présenté en 1993, c’est un algorithme de référence avec AES. Un des gros points forts de Blowfish réside sans sa légèreté qui lui permet d’être utilisé dans le domaine de l’embarqué. A noter, que son créateur, Bruce Schneier, recommande d’utiliser son successeur Twofish.

AES est le standard issu du concours lancé en 1997 par le NIST (National Institute of Standards and Technology). C’est le standard par défaut du gouvernement US. Comme Blowfish, il n’y a pas d’attaque connue contre cet algorithme (hormis par brute force, mais difficilement réalisable en l’état actuel de la technologie).

IDEA3DESCAST-5BLOWFISHAES (128-192-256)
Date de publication19921979199619931998
Dérivé dePESDESSQUARE
Taille des clés (bits)12856, 112 ou 168de 40 à 128, multiple de 8 bits. Par défaut 128 bits.de 32 à 448, multiple de 8 bits. Par défaut 128 bits.128-192-256
Taille de bloc (bits)6464646464-128-128
StructureAdd-Rotate-Xor 8,5 toursSchéma de FeistelSchéma de Feistel – 12 ou 16 toursSchéma de Feistel – 16 toursSubstitution, permutation – 10, 12 ou 14 tours selon la taille de la clé.
VarianteFOX (breveté)CAST-256TWOFISH
Commentaires sur la sécuritéAttaque par collisions possiblesSelon la taille de la clé, des exploits existent.Aucune attaque réalisable connueAucune attaque réalisable connueAucune attaque réalisable connue
Sécurité (/5)44555
Performance (/5)21454
CommentairesIDEA était soumis au brevet jusqu’en 2011 en Europe.La taille de la clé dépend de l’option choisie : 1, 2 ou 3Aussi appelé CAST-128Empreinte mémoire très faible et très performant.Certifié par la NSA.

Il existe plusieurs versions AES128, AES192 et AES256. le chiffre définissant la longueur de la clé.

En conclusion, les 3 algorithmes les plus sécurisés sont CAST-5, AES et Blowfish dont à ce jour, aucune attaque réalisable n’est connue. J’ai une petite préférence pour Blowfish de par sa performance.

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.