📍 Article principal : Asterisk + FreePBX en production pour PME ouest-africaine. Ce tutoriel se concentre sur la sécurisation d’un serveur Asterisk contre la fraude téléphonique et les attaques courantes en 2026.
Un serveur Asterisk exposé sur Internet sans précaution se fait pirater en quelques heures. Les bots qui balayent en permanence le port 5060 testent automatiquement les comptes SIP faibles, et dès qu’un compte est compromis, les attaquants déclenchent des centaines d’appels simultanés vers des destinations surtaxées (numéros premium en Somalie, Cuba, Lettonie, Congo). La facture peut dépasser 50 000 € en une seule nuit, et l’opérateur applique strictement le contrat : la PME paie. Ce tutoriel met en place les six couches de défense indispensables avant toute mise en production.
Prérequis
- FreePBX 17 ou Asterisk 21+ déjà installé et fonctionnel
- Trunk SIP opérateur configuré et testé (voir le tutoriel SIP trunk Sonatel/Orange CI)
- Accès root ou sudo au serveur Linux (Debian 12)
- Niveau : intermédiaire à avancé
- Temps estimé : 2 à 3 heures, à effectuer hors heures ouvrables
Étape 1 — Changer le port SIP par défaut et activer Fail2ban
Le port SIP standard 5060 reçoit des dizaines de milliers de tentatives d’authentification par jour sur n’importe quelle IP publique. La première mesure consiste à le déplacer sur un port non standard. Cela ne supprime pas le problème mais réduit drastiquement le bruit, ce qui rend la détection des vraies attaques plus simple.
Dans FreePBX, naviguer dans Settings → Asterisk SIP Settings → SIP Settings (chan_pjsip) et modifier le port d’écoute UDP de 5060 vers une valeur entre 5066 et 5099 (par exemple 5078). Penser à mettre à jour ce port côté téléphones IP via l’autoprovisioning ou manuellement. Côté opérateur, le port reste 5060 pour la registration vers le SBC.
FreePBX 17 inclut Fail2ban dans son installation Debian, mais il faut vérifier la jail Asterisk. Éditer /etc/fail2ban/jail.local avec une configuration adaptée :
[asterisk] enabled = true filter = asterisk action = iptables-allports[name=ASTERISK, protocol=all] logpath = /var/log/asterisk/security maxretry = 5 findtime = 600 bantime = 86400 [sshd] enabled = true maxretry = 3 findtime = 600 bantime = 86400
Le bannissement passe à 24 heures (86 400 secondes) après 5 tentatives échouées en 10 minutes. Pour une PME en production, on peut aller plus agressif : maxretry=3 et bantime=604800 (7 jours). Recharger Fail2ban et vérifier l’état :
systemctl restart fail2ban fail2ban-client status asterisk # Devrait afficher : Status for the jail: asterisk # Currently failed: X / Total failed: Y / Currently banned: Z
Sur un serveur exposé en production, observer en quelques heures plusieurs IP bannies. C’est normal et c’est le rôle de Fail2ban — il absorbe le trafic offensif automatiquement.
Étape 2 — Restreindre l’accès par ACL PJSIP
Fail2ban réagit aux tentatives échouées, mais idéalement on veut interdire totalement la connexion depuis des plages géographiques inutiles. PJSIP permet de définir une ACL (Access Control List) globale ou par endpoint qui rejette les paquets SIP avant même la phase d’authentification.
Si la PME opère uniquement au Sénégal, en Côte d’Ivoire et au Mali, on peut autoriser uniquement les plages d’IP de Sonatel/Orange et de quelques opérateurs internet locaux + l’IP de l’opérateur SIP trunk. Pour un déploiement avec des télétravailleurs, on autorise en plus les plages 4G mobiles locales.
Dans FreePBX, l’ACL globale se configure via Settings → Asterisk SIP Settings → Match (Permit) et Match (Deny). Pour une approche par endpoint plus fine, éditer directement /etc/asterisk/pjsip_custom.conf :
[acl_local_only] type=acl deny=0.0.0.0/0 permit=41.82.0.0/15 ; Sonatel Sénégal (exemple) permit=196.1.0.0/16 ; Orange CI (exemple - vérifier RIPE/AFRINIC) permit=10.0.0.0/8 permit=172.16.0.0/12 permit=192.168.0.0/16
Important : les blocs IP indiqués sont illustratifs. Récupérer les vrais blocs assignés à chaque opérateur via la base AFRINIC. Lier l’ACL aux endpoints des téléphones internes en référençant acl=acl_local_only dans la configuration de chaque endpoint.
Étape 3 — Activer SIP TLS et SRTP pour le chiffrement
Par défaut, SIP transite en clair sur UDP 5060 et le RTP en clair sur UDP 10000-20000. Toute personne qui intercepte le trafic peut écouter les conversations. Pour les communications sensibles (cabinets juridiques, médecine, finance), activer SIP-TLS sur 5061 et SRTP pour le RTP est obligatoire.
FreePBX 17 simplifie la génération des certificats. Aller dans Admin → Certificate Management → New Certificate → Generate Self-Signed Certificate pour un certificat interne, ou Generate Let’s Encrypt Certificate pour un certificat reconnu publiquement (le serveur doit être accessible en HTTP/80 pour la validation ACME).
Une fois le certificat généré, l’associer dans Settings → Asterisk SIP Settings → Certificate Manager. Activer TLS Enable sur le port 5061 et Media Encryption: SRTP via in-SDP. Côté téléphones IP, configurer le transport SIP en TLS et SRTP en mode obligatoire ou souhaitable selon le modèle.
Important : la plupart des opérateurs ouest-africains ne supportent pas encore SIP-TLS sur leurs SBC. Le chiffrement TLS s’applique donc uniquement aux extensions internes et aux télétravailleurs, pas au trunk vers l’opérateur. C’est acceptable car le trunk transite par un réseau opérateur contrôlé.
Étape 4 — Restreindre les destinations sortantes
La majorité des fraudes consistent à appeler des destinations surtaxées internationales. La parade la plus efficace consiste à interdire par défaut tout préfixe international et à autoriser uniquement les destinations dont la PME a réellement besoin.
Dans FreePBX, créer une route sortante international_restreint avec uniquement les patterns de destinations légitimes (par exemple France 0033X., Maroc 00212X., États-Unis 001X.). Toutes les autres routes sortantes (Afrique de l’Ouest, mobile local) restent permissives. Réordonner les routes pour que international_restreint capture en premier les préfixes 00.
Pour aller plus loin, le module Custom Extensions permet d’ajouter une logique dialplan dans extensions_custom.conf qui rejette tout préfixe non whitelisté via une macro avec GotoIf qui compare les 5 premiers chiffres composés (00033, 00212, 00001) et joue privacy-incorrect avec Hangup en cas de non-correspondance. Cette macro est ensuite appelée depuis chaque outbound route via PreDial Hook.
Étape 5 — Plafonds horaires et journaliers par extension
Même avec une whitelist stricte, un compte interne compromis peut générer des centaines d’appels vers la France ou les États-Unis et causer des dégâts. Le module Time Conditions de FreePBX combiné à un compteur AGI permet de plafonner le nombre d’appels par extension et par heure.
Une approche simple consiste à limiter le coût total horaire via une variable Asterisk persistante. Pour un usage standard, 30 appels sortants/heure et 100/jour par extension couvrent largement les besoins commerciaux légitimes. Au-delà, l’extension est temporairement bloquée et un email alerte l’administrateur. Un script Python AGI dans /var/lib/asterisk/agi-bin/check_call_limit.py consulte une base SQLite locale, incrémente le compteur et bloque si le seuil est atteint.
Étape 6 — Monitoring actif et alertes
La sécurité passive ne suffit pas : il faut surveiller activement les anomalies. Le module Reports de FreePBX donne une vue rétrospective, mais pour la détection en temps réel, on s’appuie sur le journal CDR et un script qui calcule le coût en cours de journée.
Une règle simple à mettre en place : déclencher une alerte email/SMS dès que le total des appels sortants payants de la journée dépasse un seuil (par exemple 30 000 XOF en équivalent minutes). Un cron toutes les 10 minutes interroge la base CDR avec une requête SQL SELECT SUM(billsec)/60 AS minutes_today FROM asteriskcdrdb.cdr WHERE calldate >= CURDATE() AND disposition = 'ANSWERED' AND dst LIKE '00%'. Si le seuil est dépassé, alerte immédiate.
Pour une supervision plus complète, intégrer Prometheus avec l’exportateur asterisk_exporter et Grafana — alerte si le nombre d’appels concurrents dépasse un seuil ou si le taux d’erreur SIP grimpe brutalement.
Détection d’anomalies par analyse CDR
Au-delà du simple plafond horaire, l’analyse statistique du journal CDR révèle les comportements anormaux avant qu’ils ne deviennent coûteux. Un script Python qui tourne toutes les heures peut détecter trois signaux faibles classiques. Premier signal : appels sortants vers une destination jamais utilisée auparavant par cette extension — un compte commercial qui appelait toujours en France et qui se met soudain à appeler en Lettonie est suspect. Deuxième signal : hausse brutale du nombre d’appels par minute sur une extension donnée, dépassant deux écarts-types par rapport à la moyenne historique. Troisième signal : appels nocturnes ou week-end depuis des extensions habituellement inactives en dehors des heures ouvrables.
L’implémentation se fait avec pandas et SQLAlchemy contre la base CDR : une lecture des CDR de la dernière heure, un groupby par src, un calcul de statistiques (count, sum(billsec), distinct(dst)), une comparaison à la baseline historique stockée en parallèle. Quand une extension dépasse les seuils, l’extension est désactivée automatiquement (asterisk -rx "pjsip endpoint <ext> deactivate") et un email/SMS d’alerte part vers l’admin. Un tableau de bord Grafana branché sur la même source visualise en continu l’activité par extension et permet la levée manuelle du blocage.
Hardening de l’OS Debian 12 hôte
La sécurité du serveur Asterisk dépend autant de l’OS sous-jacent que d’Asterisk lui-même. Quatre étapes complètent la sécurisation côté Linux. Premièrement, désactiver complètement la connexion SSH par mot de passe et n’autoriser que les clés Ed25519. Dans /etc/ssh/sshd_config : PasswordAuthentication no, PermitRootLogin no, AllowUsers admin, Port 22922 (port non standard). Recharger sshd et tester la connexion depuis une session séparée avant de fermer la session active.
Deuxièmement, activer les mises à jour automatiques de sécurité avec unattended-upgrades. Cela ferme automatiquement les CVE critiques sans intervention humaine — pour un serveur Asterisk exposé, c’est non négociable. Configurer dans /etc/apt/apt.conf.d/50unattended-upgrades pour limiter aux mises à jour de sécurité et envoyer un email récapitulatif quotidien.
Troisièmement, activer un firewall nftables minimal. Bloquer tout en entrée par défaut, autoriser uniquement les ports nécessaires (SSH custom, HTTPS pour FreePBX UI, SIP custom, RTP range). Refuser tout trafic sortant non sollicité — un attaquant qui prend le contrôle du serveur ne pourra pas exfiltrer en clair vers un C2 externe sans contournement. Quatrièmement, monitorer les modifications de fichiers système avec auditd ou AIDE : toute modification de /etc/asterisk/, /var/lib/asterisk/agi-bin/ ou des binaires Asterisk déclenche une alerte. Un attaquant qui modifie un script AGI pour ouvrir un backdoor est ainsi détecté en quelques minutes.
Test d’intrusion interne et red team
Au moins une fois par an, faire tester le serveur par un pentest externe ciblant spécifiquement les vecteurs VoIP. Les outils de référence : SIPVicious (énumération SIP), Asterisk-NG SIP Audit, Mr. SIP. Le test doit valider qu’aucun compte SIP par défaut ne reste actif, qu’aucun mot de passe ne se trouve dans un dictionnaire courant, que Fail2ban réagit dans les délais, que les logs sont effectivement chiffrés et inaltérables. Le rapport de pentest sert de preuve de diligence en cas de litige avec un opérateur ou un client.
Adaptation au contexte ouest-africain
Deux points à considérer spécifiquement. Premièrement, les attaquants ciblent les serveurs basés en Afrique en sachant que la facturation opérateur peut être plus difficile à contester localement : la rigueur sur les six couches de défense est non négociable. Deuxièmement, le support juridique en cas de fraude reste limité — la prévention est la seule réponse réaliste. Conserver tous les logs PJSIP, CDR et Fail2ban pendant au moins 12 mois (chiffrés) facilite les démarches en cas d’incident.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Fail2ban ne bannit rien malgré des attaques visibles | logpath incorrect ou format de log différent | Vérifier que /var/log/asterisk/security existe et est rempli, ajuster le filtre |
| Téléphones IP déconnectés après changement de port | Configuration côté téléphone non mise à jour | Mettre à jour l’autoprovisioning ou reconfigurer manuellement chaque poste |
| SRTP refusé par certains téléphones | Modèle ancien sans support SRTP | Désactiver SRTP pour ces postes ou les remplacer par des modèles récents |
| Trunk opérateur déconnecté après ajout d’ACL | IP du SBC opérateur non whitelistée | Ajouter explicitement l’IP/range du SBC dans la liste permit |
Sauvegarde des journaux et rétention conforme
Les journaux Asterisk, Fail2ban et CDR sont la première source de preuve en cas d’incident. Les conserver intacts pendant au moins 12 mois est une pratique professionnelle minimale. Configurer rsyslog pour expédier en temps réel les logs vers un serveur central séparé (Graylog, Loki, ou un simple S3 chiffré). Cela protège contre l’effacement par un attaquant qui aurait pris le contrôle local du serveur Asterisk — la chaîne de preuve reste intacte côté agrégateur.
Le format syslog facilite l’intégration avec un SIEM léger comme Wazuh ou un service managé. Une règle simple à activer : alerter dès que cinq IP sont bannies par Fail2ban dans la même minute (signe d’attaque distribuée), ou dès qu’une registration SIP réussit depuis une géolocalisation inhabituelle (intégration MaxMind GeoIP). Ces alertes restent actives même quand l’admin dort, ce qui est précisément le moment où les fraudeurs frappent.
Pour les déploiements critiques, prévoir un exercice annuel de simulation de fraude. Un consultant externe ou un membre désigné de l’équipe IT déclenche volontairement une attaque contrôlée — tentatives de bruteforce sur le port SIP, tentatives d’enregistrement avec credentials volés, simulation d’appels massifs vers une destination test. L’objectif est de mesurer le temps de détection, le délai d’alerte vers l’administrateur et l’efficacité des contre-mesures automatiques. Un rapport post-exercice identifie les points faibles et alimente le plan d’amélioration continue de la sécurité de la centrale téléphonique.
Pour aller plus loin
🔝 Retour à l’article principal : Asterisk + FreePBX en production pour PME ouest-africaine. Tutoriel précédent : configurer un SIP trunk Sonatel ou Orange CI.
Documentation Fail2ban officielle sur fail2ban.readthedocs.io, sécurité Asterisk sur docs.asterisk.org/Deployment/Security. Pour aller plus loin sur le chiffrement SRTP, lire la RFC 3711.