Aller au contenu principal
qaryon

Sécuriser ses trunks SIP en 2026 : guide pratique pour intégrateurs

Toll fraud, STIR/SHAKEN, mTLS, hardening SBC — les menaces évoluent, vos trunks SIP doivent suivre. Guide concret avec configurations et checklist.

sipsécuritévoipsbctelecom

La fraude sur trunks SIP a coûté 38,95 milliards de dollars en 2023 selon la CFCA. En 2026, les attaques se sont sophistiquées : DDoS ciblés sur les registrars, brute-force sur les credentials SIP, exploitation des failles de configuration des SBC. Pour un intégrateur télécom qui déploie des infrastructures voix chez ses clients, la sécurité du trunk SIP n'est plus un sujet optionnel — c'est une responsabilité contractuelle.

Cet article détaille les mesures concrètes que nous appliquons sur les projets qaryon, de la couche transport à la conformité réglementaire.

Le paysage des menaces en 2026

Les attaques sur l'infrastructure SIP suivent trois vecteurs principaux :

Toll fraud — Un attaquant compromet un compte SIP ou exploite un trunk mal sécurisé pour router des appels internationaux premium. Le client découvre le problème sur sa facture mensuelle, souvent plusieurs milliers d'euros trop tard.

Registration hijacking — L'attaquant intercepte ou forge des requêtes REGISTER pour rediriger les appels entrants vers ses propres endpoints. Sans authentification mutuelle, un simple sniff du réseau suffit.

DDoS sur l'infrastructure SIP — Des volumes massifs de requêtes INVITE ou OPTIONS saturent le SBC ou le proxy SIP, rendant le service indisponible. Contrairement au DDoS HTTP, les solutions de mitigation classiques (CDN, WAF) ne protègent pas le trafic SIP/UDP.

Couche transport : TLS et SRTP obligatoires

La première ligne de défense est le chiffrement du transport. En 2026, déployer un trunk SIP en UDP clair est une faute professionnelle.

# Configuration Kamailio — Forcer TLS sur les trunks
listen=tls:0.0.0.0:5061

modparam("tls", "method", "TLSv1.2+")
modparam("tls", "verify_certificate", 1)
modparam("tls", "require_certificate", 1)
modparam("tls", "private_key", "/etc/kamailio/tls/server.key")
modparam("tls", "certificate", "/etc/kamailio/tls/server.crt")
modparam("tls", "ca_list", "/etc/kamailio/tls/ca.pem")

Points critiques :

  • TLS 1.2 minimum — TLS 1.0 et 1.1 sont obsolètes et vulnérables. Forcez TLS 1.2 ou 1.3 sur tous les endpoints.
  • Vérification mutuelle (mTLS) — Le require_certificate à 1 impose que le client présente également un certificat. Sans mTLS, n'importe qui peut établir une connexion TLS vers votre SBC.
  • SRTP pour le media — TLS protège la signalisation, mais les flux RTP (la voix) circulent sur un canal séparé. Activez SRTP avec échange de clés via SDES ou DTLS-SRTP.
# AudioCodes SBC — Profil de sécurité media
SRTPMode: RequireSRTP
SRTPOfferedSuites: AES_CM_128_HMAC_SHA1_80
DTLSMode: Enabled

Authentification et contrôle d'accès

Credentials SIP robustes

Les credentials par défaut ou faibles restent le vecteur d'attaque numéro un. Nos règles :

  • Mots de passe aléatoires de 32+ caractères — Générés automatiquement, jamais choisis manuellement.
  • Rotation trimestrielle — Automatisée via API du provider ou script de provisioning.
  • IP ACL en complément — L'authentification digest ne suffit pas. Restreignez les sources autorisées par IP.
# iptables — Restreindre l'accès SIP aux IP connues
iptables -A INPUT -p udp --dport 5060 -s 203.0.113.10 -j ACCEPT
iptables -A INPUT -p tcp --dport 5061 -s 203.0.113.10 -j ACCEPT
iptables -A INPUT -p udp --dport 5060 -j DROP
iptables -A INPUT -p tcp --dport 5061 -j DROP

Rate limiting sur le SBC

Un SBC correctement configuré limite le nombre de requêtes par source et par seconde. C'est la mesure la plus efficace contre le brute-force et les scans SIP :

# Kamailio — Rate limiting avec pike et htable
modparam("pike", "sampling_time_unit", 2)
modparam("pike", "reqs_density_per_unit", 30)
modparam("pike", "remove_latency", 4)

route[REQINIT] {
    if (!pike_check_req()) {
        xlog("L_WARN", "Blocked SIP flood from $si\n");
        exit;
    }
}

Avec cette configuration, une source envoyant plus de 30 requêtes par tranche de 2 secondes est automatiquement bloquée pendant 4 secondes. Ajustez les seuils selon le volume légitime de votre infrastructure.

STIR/SHAKEN : la conformité réglementaire

Le framework STIR/SHAKEN (Secure Telephone Identity Revisited / Signature-based Handling of Asserted information using toKENs) est désormais obligatoire aux États-Unis et gagne du terrain en Europe. Son principe : signer cryptographiquement l'identité de l'appelant pour certifier qu'elle n'a pas été falsifiée.

En pratique pour un intégrateur :

  1. Obtenir un certificat STI auprès d'une autorité certifiée (STI-CA).
  2. Configurer la signature sur le SBC ou le proxy SIP de sortie.
  3. Configurer la vérification sur le SBC d'entrée pour valider les appels entrants.
  4. Recertifier annuellement — Les certificats STI ont une durée de validité limitée.
// Exemple de header SIP Identity (STIR/SHAKEN)
{
  "header": {
    "alg": "ES256",
    "ppt": "shaken",
    "typ": "passport",
    "x5u": "https://cert.example.com/sti-cert.pem"
  },
  "payload": {
    "attest": "A",
    "dest": { "tn": ["+33140000000"] },
    "iat": 1713100800,
    "orig": { "tn": "+33155000000" },
    "origid": "abc123-def456"
  }
}

Le niveau d'attestation (attest) indique le degré de confiance :

  • A (Full) — Le provider a vérifié l'identité de l'appelant et autorise l'usage du numéro.
  • B (Partial) — Le provider a vérifié l'identité mais pas l'autorisation sur ce numéro spécifique.
  • C (Gateway) — Le provider a reçu l'appel d'une passerelle et ne peut pas vérifier l'origine.

Hardening du SBC : la checklist

Le SBC est le point de terminaison exposé sur Internet. Son durcissement est critique :

| Mesure | Priorité | Impact | |--------|----------|--------| | Désactiver les protocoles non utilisés (H.323, MGCP) | Haute | Réduit la surface d'attaque | | Limiter les codecs autorisés | Moyenne | Empêche l'exploitation via codecs exotiques | | Activer la détection d'anomalies SIP | Haute | Bloque les requêtes malformées | | Journaliser toutes les tentatives d'authentification | Haute | Détection des scans et brute-force | | Séparer les interfaces management et media | Haute | Empêche l'accès admin depuis Internet | | Mettre à jour le firmware trimestriellement | Haute | Corrige les CVE connues | | Configurer des alarmes sur le taux d'échec INVITE | Moyenne | Détection précoce de fraude | | Restreindre les destinations internationales | Haute | Limite l'impact du toll fraud |

Restriction des destinations

La mesure la plus immédiatement efficace contre le toll fraud : bloquer les préfixes internationaux non utilisés par le client.

# AudioCodes SBC — Blocage des destinations premium
IPOutboundManipulation:
  - Name: "Block Premium"
    SourcePrefix: "*"
    DestinationPrefix: "00899,00900,001900,00976"
    Action: Reject
    RejectReason: 403

Si un client n'appelle jamais vers l'Afrique ou les Caraïbes, bloquez ces préfixes. La fraude vise systématiquement les destinations à tarification premium. Un blocage préventif évite les factures de plusieurs dizaines de milliers d'euros.

Monitoring en temps réel

La sécurité n'est pas un état — c'est un processus continu. Les mesures préventives doivent être complétées par un monitoring actif :

  • CDR analysis — Analyser les Call Detail Records en temps réel pour détecter les patterns anormaux (pic d'appels nocturnes, destinations inhabituelles, durées anormalement longues).
  • Fail2ban pour SIP — Bloquer automatiquement les IP après N tentatives d'authentification échouées.
  • SNMP/syslog centralisé — Agréger les logs de tous les SBC et proxys sur une plateforme de monitoring (Grafana + Loki, ELK).
# Fail2ban — Filtre pour Kamailio
[kamailio-auth]
enabled  = true
filter   = kamailio-auth
action   = iptables-allports[name=kamailio, protocol=all]
logpath  = /var/log/kamailio/kamailio.log
maxretry = 5
bantime  = 3600
findtime = 300

Conclusion

Sécuriser un trunk SIP en 2026 demande une approche en couches : chiffrement transport (TLS/SRTP), authentification forte (mTLS + IP ACL), conformité réglementaire (STIR/SHAKEN), durcissement du SBC, et monitoring continu. Aucune mesure isolée ne suffit.

Pour un intégrateur, ces compétences sont un différenciateur commercial. Un client qui subit une fraude SIP de 50 000 € ne renouvelle pas son contrat. Un client dont l'infrastructure est auditée, durcie et monitorée devient un ambassadeur.

Chez qaryon, la sécurité SIP fait partie intégrante de chaque mission de déploiement. Pas en option. Pas en phase 2. Dès le premier trunk configuré.

qaryon — Conseil, audit et formation en communications unifiées. Prendre contact.