SIP Trunk Security Best Practices

Understanding SIP Trunk Security Risks

SIP (Session Initiation Protocol) trunks replace traditional PRIs and phone lines, connecting your IP-PBX to the PSTN. While offering cost savings and flexibility, SIP trunks introduce new security challenges that require careful management.

Why SIP Trunks Are Targeted

Attackers target SIP trunks for several reasons:

• Direct toll access — Compromised trunks enable free international calling
• High call volume — Trunks support many simultaneous calls for rapid fraud
• Anonymous access — Internet-facing services can be attacked from anywhere
• Automated scanning — Tools like SIPVicious make discovery trivial

Unsecured SIP endpoints are typically discovered and attacked within 24-48 hours of deployment. Automated scanning tools continuously probe for vulnerable systems.

Common Attack Vectors

Attack Type	Description	Impact
Credential brute force	Dictionary attacks against SIP authentication	Account compromise, toll fraud
Caller ID spoofing	Falsifying FROM headers for fraud/vishing	Reputation damage, regulatory issues
Registration hijacking	Stealing valid registrations	Call interception, impersonation
Denial of service	Flooding with SIP INVITE/REGISTER	Service outage
Eavesdropping	Capturing unencrypted SIP/RTP traffic	Privacy breach, data theft
Man-in-the-middle	Intercepting and modifying SIP messages	Call redirection, fraud

SIP Authentication Security

Digest Authentication

SIP Digest authentication is the minimum requirement. Never operate trunks without authentication:

# Asterisk SIP trunk with digest auth
[trunk-provider]
type=peer
host=sip.provider.com
username=your_account_id
secret=YourStrongPassword123!
fromuser=your_account_id
fromdomain=sip.provider.com
insecure=port,invite    ; Only if required by provider
qualify=yes
context=from-trunk
disallow=all
allow=ulaw
allow=alaw

Password Requirements

SIP passwords face constant brute force attacks. Require:

• Minimum length — 16+ characters recommended
• Complexity — Mixed case, numbers, special characters
• Uniqueness — Never reuse passwords across trunks or systems
• Regular rotation — Change every 90 days or after personnel changes

# Generate strong SIP passwords
import secrets
import string

def generate_sip_password(length=24):
    """Generate a cryptographically secure SIP password."""
    alphabet = string.ascii_letters + string.digits + "!@#$%^&*"
    return ''.join(secrets.choice(alphabet) for _ in range(length))

# Example: "Kj9#mNp2xQ&vL5sW!aR7cYz3"

IP-Based Authentication

Combine digest auth with IP restrictions for defense in depth:

# FreePBX/Asterisk IP-based restrictions
[trunk-provider]
type=peer
host=sip.provider.com
; Only accept from provider's IP ranges
permit=192.0.2.0/24
permit=198.51.100.0/24
deny=0.0.0.0/0
; Still require digest auth
username=your_account_id
secret=YourStrongPassword123!

Transport and Media Encryption

TLS for SIP Signaling

Transport Layer Security (TLS) encrypts SIP signaling, preventing eavesdropping and tampering:

# Asterisk TLS configuration
[general]
tlsenable=yes
tlsbindaddr=0.0.0.0:5061
tlscertfile=/etc/asterisk/keys/asterisk.pem
tlscafile=/etc/asterisk/keys/ca.crt
tlscipher=HIGH:!aNULL:!MD5:!DSS
tlsclientmethod=tlsv1_2

[trunk-provider]
type=peer
transport=tls
host=sip.provider.com
port=5061

Certificate Management

Proper certificate handling is critical:

• Use trusted CAs — Production certs from recognized authorities
• Verify provider certs — Enable certificate verification
• Monitor expiration — Set alerts for certificate renewal
• Secure private keys — Restrict file permissions (600)

# Secure certificate file permissions
chmod 600 /etc/asterisk/keys/asterisk.pem
chmod 644 /etc/asterisk/keys/ca.crt
chown asterisk:asterisk /etc/asterisk/keys/*

SRTP for Media Encryption

SRTP (Secure Real-time Transport Protocol) encrypts voice media:

# Enable SRTP on trunk
[trunk-provider]
type=peer
transport=tls
encryption=yes          ; Require SRTP
encryption_taglen=32    ; 32-bit auth tag (more secure)

# For Asterisk 18+
[endpoint-trunk]
type=endpoint
transport=transport-tls
media_encryption=sdes   ; SDES key exchange
media_encryption_optimistic=no  ; Require encryption

Protocol Selection

Protocol	Port	Security	Use Case
SIP/UDP	5060	None	Avoid - legacy only
SIP/TCP	5060	None	Avoid - no encryption
SIP/TLS	5061	Signaling encrypted	Good - with SRTP
SIP/WSS	443	WebSocket over TLS	WebRTC applications

Network-Level Security

Firewall Configuration

Implement strict firewall rules for SIP traffic:

# iptables rules for SIP security

# Allow SIP from known provider IPs only
iptables -A INPUT -p udp --dport 5060 -s 192.0.2.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 5060 -s 192.0.2.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 5061 -s 192.0.2.0/24 -j ACCEPT

# Allow RTP media range (common: 10000-20000)
iptables -A INPUT -p udp --dport 10000:20000 -j ACCEPT

# Block all other SIP traffic
iptables -A INPUT -p udp --dport 5060 -j DROP
iptables -A INPUT -p tcp --dport 5060 -j DROP
iptables -A INPUT -p tcp --dport 5061 -j DROP

# Log dropped packets for analysis
iptables -A INPUT -p udp --dport 5060 -j LOG --log-prefix "SIP-BLOCKED: "

Session Border Controllers (SBC)

SBCs provide comprehensive SIP security at the network edge:

• Topology hiding — Mask internal network structure
• Protocol normalization — Fix malformed SIP messages
• Rate limiting — Throttle excessive requests
• Media anchoring — Force media through secure path
• DoS protection — Absorb and filter attacks

For enterprise deployments, an SBC is essential. Options include:

• Kamailio/OpenSIPS — Open source, highly configurable
• AudioCodes — Hardware and virtual appliances
• Oracle SBC — Enterprise-grade (formerly Acme Packet)
• Ribbon SBC — Cloud and on-premise options

Network Segmentation

Isolate VoIP infrastructure from general network traffic:

• Dedicated VLAN — Separate voice traffic from data
• QoS policies — Prioritize voice traffic
• Firewall between segments — Control inter-VLAN traffic
• Management network — Separate admin access from voice traffic

Intrusion Detection and Prevention

Fail2Ban Configuration

Block repeated authentication failures automatically:

# /etc/fail2ban/jail.local
[asterisk]
enabled = true
filter = asterisk
action = iptables-allports[name=ASTERISK, protocol=all]
         sendmail[name=Asterisk, dest=security@example.com]
logpath = /var/log/asterisk/security
maxretry = 3
bantime = 86400    # 24 hours
findtime = 300     # 5 minute window

# Custom filter for SIP registration failures
# /etc/fail2ban/filter.d/asterisk.local
[Definition]
failregex = SECURITY.* SecurityEvent="FailedACL".*RemoteAddress=".*?/(?P<host>\d+\.\d+\.\d+\.\d+)/.*"
            SECURITY.* SecurityEvent="InvalidAccountID".*RemoteAddress=".*?/(?P<host>\d+\.\d+\.\d+\.\d+)/.*"
            SECURITY.* SecurityEvent="ChallengeResponseFailed".*RemoteAddress=".*?/(?P<host>\d+\.\d+\.\d+\.\d+)/.*"
            SECURITY.* SecurityEvent="InvalidPassword".*RemoteAddress=".*?/(?P<host>\d+\.\d+\.\d+\.\d+)/.*"

Real-Time Monitoring

Monitor SIP activity for anomalies:

# SIP trunk monitoring script
def monitor_sip_activity():
    metrics = {
        'registration_failures': count_recent_failures(),
        'concurrent_calls': get_active_calls(),
        'international_calls': get_intl_calls_last_hour(),
        'new_source_ips': detect_new_ips()
    }

    alerts = []

    # Alert thresholds
    if metrics['registration_failures'] > 10:
        alerts.append({
            'type': 'brute_force_attempt',
            'severity': 'high',
            'action': 'investigate_immediately'
        })

    if metrics['concurrent_calls'] > NORMAL_PEAK * 1.5:
        alerts.append({
            'type': 'unusual_call_volume',
            'severity': 'medium',
            'current': metrics['concurrent_calls'],
            'baseline': NORMAL_PEAK
        })

    if metrics['international_calls'] > INTL_THRESHOLD:
        alerts.append({
            'type': 'excessive_international',
            'severity': 'high',
            'action': 'review_call_logs'
        })

    return alerts

Log Analysis

Enable comprehensive logging for security analysis:

# Asterisk logging configuration
# /etc/asterisk/logger.conf
[logfiles]
security => security
messages => notice,warning,error
full => notice,warning,error,debug,verbose

# Enable security logging
# /etc/asterisk/asterisk.conf
[options]
security_log = security

Caller ID Security

Preventing Caller ID Spoofing

Control what caller IDs can originate from your trunk:

• Whitelist valid DIDs — Only allow owned numbers as caller ID
• Validate at trunk level — Check caller ID before sending to carrier
• STIR/SHAKEN attestation — Sign calls for authentication
• Provider policies — Work with carrier to enforce restrictions

# Dialplan caller ID validation
[outbound-calls]
; Validate caller ID is in our allowed list
exten => _1NXXNXXXXXX,1,NoOp(Outbound call from ${CALLERID(num)})
same => n,Set(VALID_CID=${ODBC_CHECK_VALID_DID(${CALLERID(num)})})
same => n,GotoIf($["${VALID_CID}" = "1"]?proceed)
same => n,Set(CALLERID(num)=${DEFAULT_OUTBOUND_CID})
same => n,Log(WARNING,Invalid caller ID ${CALLERID(num)} replaced with default)
same => n(proceed),Dial(SIP/${EXTEN}@trunk-provider)

STIR/SHAKEN Implementation

STIR/SHAKEN provides cryptographic call authentication:

• Full attestation (A) — You control the caller ID and the call
• Partial attestation (B) — You originated the call but don't verify caller ID
• Gateway attestation (C) — You're passing through the call

Work with your trunk provider to ensure proper STIR/SHAKEN signing for outbound calls and verification for inbound calls.

SIP Trunk Security Checklist

Choosing a Secure Trunk Provider

When selecting a SIP trunk provider, evaluate security capabilities:

Capability	Required	Questions to Ask
TLS/SRTP support	Yes	Is encryption available? Any additional cost?
Fraud monitoring	Yes	What fraud detection is included?
Spending limits	Yes	Can I set daily/monthly spending caps?
Geographic restrictions	Yes	Can I block high-risk destinations?
Real-time CDRs	Recommended	How quickly are call records available?
STIR/SHAKEN	Recommended	Is attestation provided for outbound calls?
24/7 support	Recommended	What are response times for security issues?

Security Incident Response

Detecting a Compromise

Signs your SIP trunk may be compromised:

• Unusual call volumes — Especially after hours or to international destinations
• Registration from unknown IPs — Endpoints registering from unexpected locations
• Failed authentication spikes — Brute force attempts in progress
• Carrier fraud alerts — Provider notifying of suspicious activity
• Customer complaints — Receiving calls appearing to be from your numbers

Response Steps

1. Isolate — Disable compromised trunk immediately
2. Assess — Review logs to determine scope and entry point
3. Notify — Contact carrier about fraudulent traffic
4. Remediate — Reset credentials, patch vulnerabilities
5. Restore — Re-enable trunk with enhanced security
6. Review — Document incident and update security measures

Frequently Asked Questions

Do I need TLS encryption on my SIP trunk?

Yes, TLS encryption is strongly recommended for all SIP trunks. Without TLS, SIP signaling travels in clear text, exposing credentials during authentication, call details, and making man-in-the-middle attacks possible. TLS with SRTP provides end-to-end encryption for both signaling and media. Most carriers support TLS on port 5061 at no additional cost.

What is an SBC and do I need one?

A Session Border Controller (SBC) sits at the edge of your network, providing security, protocol normalization, and traffic management for VoIP. For small deployments (under 50 extensions), a properly configured PBX with firewall may suffice. For enterprise deployments, an SBC is essential for features like topology hiding, DoS protection, and centralized policy enforcement. Open source options like Kamailio offer SBC functionality at lower cost.

How can I protect against SIP brute force attacks?

Implement multiple layers of protection: First, use strong passwords (16+ characters, high entropy). Second, configure IP allowlisting to only accept connections from known endpoints. Third, deploy Fail2Ban to automatically block IPs after repeated failures. Fourth, use your carrier's IP ranges to limit trunk access. Finally, consider an SBC for advanced rate limiting and attack detection.

How quickly should I be alerted to suspicious SIP activity?

For critical security events like repeated authentication failures or calls to high-risk destinations, alerts should trigger within minutes. Toll fraud can accumulate thousands of dollars in charges per hour, so rapid detection is essential. Configure real-time monitoring with immediate alerting via SMS, email, or messaging platforms. Establish on-call procedures for after-hours response.