Common SIP Security Risks and How to Reduce Them

SIP is an open, text-based protocol that was designed to work across the public internet. That openness is also what makes it a target. The good news is that the threats are well understood and the defences are mostly simple configuration choices. This guide lists the risks you are most likely to meet, explains how each one works, and gives a short set of actions to reduce it. RFC 3261 section 26 covers the formal threat model; this article translates it into everyday terms.

Scanning

What happens

Automated tools sweep large address ranges looking for anything that answers SIP on UDP 5060, and increasingly on TCP and on other ports. A scanner sends an OPTIONS or REGISTER request and records the response. A reply of any kind, even a 401 or 404, confirms that a SIP server is present. The scanner then moves on to enumerate extensions by watching how the server responds to different usernames.

How to reduce it

• Do not expose the SIP port to the internet unless you have to. Use a VPN or an allow-list.
• Configure the PBX to give the same response to unknown and known users so extension enumeration is harder. In Asterisk this is alwaysauthreject=yes for chan_sip; PJSIP behaves this way by default.
• Rate-limit or drop unsolicited traffic at the firewall.

For a detailed server-side walkthrough see how to protect a PBX from SIP scanning.

Brute force and credential guessing

What happens

Once a scanner finds a server and a list of likely extensions, it tries passwords. Weak PBX defaults, extension numbers used as passwords and short numeric PINs fall within minutes. The attempts arrive at high speed from many addresses.

How to reduce it

• Long, random, unique passwords on every extension.
• A separate auth username that does not match the extension number, where the PBX supports it.
• fail2ban or an equivalent tool that bans addresses after a few failures.
• Limit the number of registrations per account.

The full checklist is in how to secure a SIP account.

Toll fraud

What happens

Toll fraud is the usual end goal of scanning and brute force. With a working set of credentials, the attacker registers and places as many calls as possible to premium-rate or international destinations they control or are paid by. Often the owner only finds out when the trunk provider's invoice arrives.

How to reduce it

• Block international and premium-rate destinations on every outbound route that does not need them.
• Set spending caps with your SIP trunk provider.
• Restrict the hours in which certain routes are available.
• Review call detail records regularly. Night-time bursts to one foreign prefix are a classic sign.
• Limit call forwarding to external numbers, since attackers sometimes set forwarding through voicemail or feature codes rather than registering a device.

Eavesdropping

What happens

Plain SIP over UDP or TCP and plain RTP are both readable by anyone who can capture packets on the path. That includes a compromised Wi-Fi network, a hostile hotspot, or an upstream network segment. Captured signaling reveals who called whom. Captured RTP can be turned back into audio with freely available tools.

How to reduce it

• Use TLS as the SIP transport so the signaling is encrypted and the server is authenticated.
• Use SRTP so the audio is encrypted. RFC 3711 defines the protocol.
• Enable both together. With the common SDES key exchange the SRTP keys ride inside the SIP message, so SRTP without TLS protects little. See SIP over TLS vs SRTP.
• For roaming users, a VPN adds a second layer and works even with servers that cannot do TLS.

SIPdia supports TLS transport and an Encrypt audio setting of Off, Optional or Required. It requires a certificate from a public certificate authority for TLS.

Spoofed caller ID

What happens

The From header in a SIP request is supplied by the caller. Nothing in the base protocol checks it. An attacker can send a call that appears to come from a bank, a colleague or an internal extension. This is used for social engineering, voicemail access and bypassing allow-lists that filter on caller ID.

How to reduce it

• Never make security decisions based on caller ID alone.
• Have the PBX enforce or overwrite the outbound caller ID for internal extensions so an attacker who compromises one extension cannot pretend to be another.
• Ask your trunk provider what identity verification they perform on inbound calls. Some carriers sign the caller identity with STIR/SHAKEN, built on RFC 8224. That helps on calls between networks that take part, but coverage is incomplete and it says nothing about calls inside your own PBX.
• Train users that an internal-looking caller ID is not proof of anything.

Registration hijacking

What happens

RFC 3261 section 26 describes this directly. An attacker sends a REGISTER that replaces your contact address with theirs. From that moment, calls meant for you are delivered to the attacker. This works when the server accepts registrations without proper authentication, when credentials are weak, or when an unencrypted digest exchange is captured and the password is then cracked offline.

How to reduce it

• Require authentication for every REGISTER and INVITE.
• Use TLS so the digest exchange cannot be captured or replayed.
• Strong credentials, as above.
• Monitor the registration state of extensions. A phone that suddenly registers from a new country deserves a look.

SIP ALG problems

What happens

Many consumer and small-business routers include a SIP Application Layer Gateway. It inspects SIP packets and rewrites the IP addresses inside them to help traffic cross NAT. In practice ALGs often rewrite the wrong fields or alter headers in ways that break registration and calls. They cannot see inside TLS at all. The symptoms look like a security problem: calls fail, registrations drop, audio goes one way.

This is less an attack than a weakness, but a misbehaving ALG can also hide what is actually happening on your network and make it harder to spot real problems.

How to reduce it

• Turn off SIP ALG on the router. Many PBX vendors and SIP providers recommend this.
• Use TLS, which the ALG cannot modify, together with STUN and ICE in the client for NAT traversal.
• On the PBX, enable proper NAT handling instead of relying on the router.

The SIP ALG troubleshooting article covers symptoms and router-specific notes.

Weak PBX defaults

What happens

A fresh PBX installation is built for convenience. Depending on the distribution it may allow guest calls, accept any codec, answer on every interface, run an old software version and ship with a sample extension or two. Attackers know these defaults well.

How to reduce it

• Disable guest and anonymous calls. In Asterisk's legacy chan_sip driver this is allowguest=no. In PJSIP, do not define an anonymous endpoint unless you need one.
• Bind SIP to the interfaces that need it, not to every address.
• Remove sample extensions and change any default admin credentials.
• Keep the PBX and its operating system updated. The Asterisk versions page shows which release series still receive security fixes.
• Review the dial plan for routes you did not intend to create.

A quick priority list

If you only have an hour, do these in order:

1. Close the SIP port to the internet, or put fail2ban in front of it.
2. Replace every weak extension password.
3. Block international and premium routes you do not need.
4. Switch clients to TLS and SRTP.
5. Turn off SIP ALG on the router.
6. Update the PBX.

Next steps

Review the client-side settings in SIPdia on the security page and the TLS and SRTP feature page. For step-by-step server hardening, continue with how to protect a PBX from SIP scanning and how to secure a SIP account.