Securing SIP: TLS, SRTP, ACLs and Fraud Prevention for Gateways

Securing SIP means encrypting signalling with TLS, encrypting audio with SRTP, and limiting who can reach your system with ACLs, strong credentials and rate limits. Then you monitor CDRs so that anything unusual is caught within minutes. Encryption protects privacy; access control and monitoring are what prevent toll fraud.

Any SIP service reachable from the internet is scanned constantly. Gateways, PBXs and trunks are attractive targets because a compromised account can place expensive calls on someone else’s bill. This guide covers the standards, the practical controls and a checklist you can use today.

The threats: scanners and toll fraud

Freely available tools scan the internet for SIP services on ports 5060 and 5061, then try common extension numbers and passwords. Once they find a working account or an open trunk, attackers typically place calls to premium-rate or high-cost international numbers — a pattern the industry calls International Revenue Share Fraud (IRSF). Attacks often start on weekends or overnight, when nobody is watching.

• Registration brute force — guessing extension passwords.
• Open relays — trunks or dial plans that accept unauthenticated INVITEs.
• Eavesdropping — capturing unencrypted signalling and RTP on untrusted networks.
• Denial of service — floods of REGISTER, OPTIONS or INVITE requests.
• Credential leaks — passwords in provisioning files, screenshots or old backups.

SIP over TLS (port 5061)

TLS encrypts and authenticates SIP signalling. RFC 3261 defines SIP over TLS and the sips: URI scheme, and RFC 5630 clarifies how SIPS should be used. By convention SIP over TLS listens on TCP port 5061.

• Use TLS 1.2 or TLS 1.3 (RFC 8446) and disable older versions.
• Use certificates from a trusted authority, or a private CA for device-to-server links, and verify hostnames.
• Remember that TLS protects signalling hop by hop: each proxy decrypts and re-encrypts. It does not encrypt audio.
• TLS also hides credentials and the numbers being dialled from anyone on the network path.

SRTP: encrypting the audio

SRTP (RFC 3711) adds encryption, message authentication and replay protection to RTP. The question is how the two ends agree on keys.

SDES vs DTLS-SRTP

SDES is widely supported by SIP trunks and IP phones, but it is only as safe as the signalling, so always pair it with TLS. DTLS-SRTP is required by WebRTC and keeps keys out of signalling entirely. ZRTP (RFC 6189) is a peer-to-peer alternative used by some softphones. When calls cross networks, a session border controller often terminates one scheme and starts another.

Access control: ACLs and allow-lists

Encryption does not stop an attacker who has a valid password. Access control limits who can even try.

• Firewall first — expose SIP ports only to the addresses that need them. For trunks, that is your provider’s published signalling IPs.
• SIP ACLs — allow-list source IPs per trunk and per account inside the SIP service as well, so a firewall mistake is not fatal.
• Separate trunk and user access — trunks from fixed IPs, users by registration, never an open “any IP” trunk.
• Restrict dial plans — allow only the destinations each account needs; block premium-rate ranges by default.
• Non-default ports reduce log noise from casual scans but are not a security control on their own.

Credentials, rate limits and network hardening

Strong credentials

SIP uses digest authentication. RFC 8760 adds SHA-256 and SHA-512/256 digest algorithms alongside the legacy MD5, so prefer them where both ends support them. Use long random passwords (16 or more characters), a different password per device, and authentication usernames that are not simply the extension number. Rotate credentials when staff leave or devices are replaced.

Rate limits

Limit requests per source IP, failed authentications per account, concurrent calls per account and calls per second per trunk. Rate limits turn a brute-force attack from thousands of guesses a minute into a handful, and they cap the damage if an account is compromised.

fail2ban and automatic blocking

fail2ban watches log files for repeated failures and adds temporary firewall bans. It works well for Asterisk-based systems. Combine it with block lists of known scanners, and make sure your own offices and your provider’s addresses are allow-listed so a misconfigured phone cannot lock out a whole site.

VPNs and network design

For remote sites and gateway PCs, a VPN or private overlay network keeps SIP off the public internet entirely. Put phones and gateways on their own VLAN, disable SIP ALG features on routers (they frequently rewrite SIP incorrectly and break NAT traversal), and keep management interfaces off the public internet.

Monitoring CDRs for fraud

Prevention will eventually miss something; monitoring limits the cost. Review CDRs in near real time and alert on:

• Calls to new countries or premium-rate ranges.
• Spend per hour above a threshold, especially outside business hours.
• Many short calls, or many simultaneous calls, from one account.
• A sudden change in ASR or ACD on a trunk.
• Registrations from unfamiliar countries or networks.

Automatic suspension at a hard spend limit is one of the most effective single fraud controls. Our guide to telecom billing covers limits and alerts in more detail.

SIP security checklist

How GSMCalls secures gateway trunks

GSMCalls trunks support UDP, TCP and TLS, with registration or IP authentication and per-trunk SIP ACLs, so only your PBX can send calls to your mobile lines. Gateway sites keep an encrypted connection to the cloud, and Smart Bridge phones stream audio directly to the platform with no PC to patch. CDRs, per-device minute profiles and alerts make unusual usage visible quickly. See features, connect it to FreePBX or Asterisk, or request a demo. New to the concept? Start with what a GSM gateway is.