Skip to main content
qaryon

Securing your SIP trunks in 2026: a practical guide for integrators

Toll fraud, STIR/SHAKEN, mTLS, SBC hardening — threats evolve, your SIP trunks must keep up. Hands-on guide with configurations and checklist.

sipsecurityvoipsbctelecom

SIP trunk fraud cost $38.95 billion in 2023 according to the CFCA. By 2026, attacks have grown more sophisticated: targeted DDoS on registrars, brute-force against SIP credentials, exploitation of SBC misconfigurations. For a telecom integrator deploying voice infrastructure at client sites, SIP trunk security is no longer optional — it's a contractual responsibility.

This article details the concrete measures we apply on qaryon projects, from the transport layer to regulatory compliance.

The 2026 threat landscape

Attacks on SIP infrastructure follow three main vectors:

Toll fraud — An attacker compromises a SIP account or exploits a poorly secured trunk to route international premium calls. The client discovers the issue on their monthly bill, often several thousand euros too late.

Registration hijacking — The attacker intercepts or forges REGISTER requests to redirect incoming calls to their own endpoints. Without mutual authentication, a simple network sniff is enough.

SIP infrastructure DDoS — Massive volumes of INVITE or OPTIONS requests overwhelm the SBC or SIP proxy, causing service outages. Unlike HTTP DDoS, standard mitigation solutions (CDN, WAF) don't protect SIP/UDP traffic.

Transport layer: mandatory TLS and SRTP

The first line of defense is transport encryption. In 2026, deploying a SIP trunk over cleartext UDP is professional negligence.

# Kamailio configuration — Force TLS on 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")

Critical points:

  • TLS 1.2 minimum — TLS 1.0 and 1.1 are obsolete and vulnerable. Enforce TLS 1.2 or 1.3 on all endpoints.
  • Mutual verification (mTLS) — Setting require_certificate to 1 forces the client to present a certificate as well. Without mTLS, anyone can establish a TLS connection to your SBC.
  • SRTP for media — TLS protects signaling, but RTP streams (the actual voice) travel on a separate channel. Enable SRTP with key exchange via SDES or DTLS-SRTP.
# AudioCodes SBC — Media security profile
SRTPMode: RequireSRTP
SRTPOfferedSuites: AES_CM_128_HMAC_SHA1_80
DTLSMode: Enabled

Authentication and access control

Strong SIP credentials

Default or weak credentials remain the number one attack vector. Our rules:

  • Random passwords of 32+ characters — Auto-generated, never manually chosen.
  • Quarterly rotation — Automated via provider API or provisioning script.
  • IP ACL as complement — Digest authentication alone is insufficient. Restrict authorized sources by IP.
# iptables — Restrict SIP access to known IPs
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 on the SBC

A properly configured SBC limits the number of requests per source per second. This is the most effective measure against brute-force and SIP scanning:

# Kamailio — Rate limiting with pike and 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;
    }
}

With this configuration, a source sending more than 30 requests per 2-second window is automatically blocked for 4 seconds. Adjust thresholds based on your infrastructure's legitimate traffic volume.

STIR/SHAKEN: regulatory compliance

The STIR/SHAKEN framework (Secure Telephone Identity Revisited / Signature-based Handling of Asserted information using toKENs) is now mandatory in the United States and gaining ground in Europe. Its principle: cryptographically sign the caller's identity to certify it hasn't been spoofed.

In practice for an integrator:

  1. Obtain an STI certificate from a certified authority (STI-CA).
  2. Configure signing on the outbound SBC or SIP proxy.
  3. Configure verification on the inbound SBC to validate incoming calls.
  4. Recertify annually — STI certificates have limited validity periods.
// Example SIP Identity header (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"
  }
}

The attestation level (attest) indicates the confidence degree:

  • A (Full) — The provider verified the caller's identity and authorizes use of the number.
  • B (Partial) — The provider verified the identity but not the authorization for this specific number.
  • C (Gateway) — The provider received the call from a gateway and cannot verify the origin.

SBC hardening checklist

The SBC is the endpoint exposed to the internet. Its hardening is critical:

| Measure | Priority | Impact | |---------|----------|--------| | Disable unused protocols (H.323, MGCP) | High | Reduces attack surface | | Restrict allowed codecs | Medium | Prevents exploitation via exotic codecs | | Enable SIP anomaly detection | High | Blocks malformed requests | | Log all authentication attempts | High | Detects scans and brute-force | | Separate management and media interfaces | High | Prevents admin access from the internet | | Update firmware quarterly | High | Patches known CVEs | | Set alerts on INVITE failure rate | Medium | Early fraud detection | | Restrict international destinations | High | Limits toll fraud impact |

Destination restrictions

The most immediately effective measure against toll fraud: block international prefixes the client doesn't use.

# AudioCodes SBC — Premium destination blocking
IPOutboundManipulation:
  - Name: "Block Premium"
    SourcePrefix: "*"
    DestinationPrefix: "00899,00900,001900,00976"
    Action: Reject
    RejectReason: 403

If a client never calls Africa or the Caribbean, block those prefixes. Fraud systematically targets premium-rate destinations. A preventive block avoids bills of tens of thousands of euros.

Real-time monitoring

Security is not a state — it's an ongoing process. Preventive measures must be complemented by active monitoring:

  • CDR analysis — Analyze Call Detail Records in real time to detect anomalous patterns (nighttime call spikes, unusual destinations, abnormally long durations).
  • Fail2ban for SIP — Automatically block IPs after N failed authentication attempts.
  • Centralized SNMP/syslog — Aggregate logs from all SBCs and proxies on a monitoring platform (Grafana + Loki, ELK).
# Fail2ban — Filter for 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

Securing a SIP trunk in 2026 requires a layered approach: transport encryption (TLS/SRTP), strong authentication (mTLS + IP ACL), regulatory compliance (STIR/SHAKEN), SBC hardening, and continuous monitoring. No single measure is sufficient.

For an integrator, these skills are a commercial differentiator. A client who suffers €50,000 in SIP fraud doesn't renew their contract. A client whose infrastructure is audited, hardened, and monitored becomes an ambassador.

At qaryon, SIP security is an integral part of every deployment engagement. Not optional. Not phase 2. From the very first trunk configured.

qaryon — Consulting, audit and training in unified communications. Get in touch.