14.1 Threats
A SIP server on the Internet usually gets its first scan within hours of going online, often within minutes. Most attacks are not clever; they are automatic, constant, and aimed at money. RFC 3261 names the goals:
“Attackers may wish to steal services, eavesdrop on communications, or disrupt sessions.”Read the section ↗
| Attack | What the attacker does | What it costs |
|---|---|---|
| Eavesdropping | Captures SIP and RTP on the path | Who called whom; the call itself |
| Scanning | Sends REGISTER or OPTIONS to thousands of extensions | A list of real users to attack |
| Password guessing | Answers the 401 again and again with common passwords | A working account |
| Registration hijack | Registers its own Contact with a stolen password | The user’s incoming calls |
| Toll fraud | Calls premium-rate or international numbers on your account | Money: often thousands in one weekend |
| Flooding | Sends more requests than the server can handle | Real calls fail |
| Identity forgery | Writes a false caller identity | Victims trust the wrong caller |
“An attacker that successfully impersonates a party authorized to change contacts associated with an address-of-record could, for example, de-register all existing contacts for a URI and then register their own device as the appropriate contact address, thereby directing all requests for the affected user to the attacker's device.”Read the section ↗
“Any SIP UAS that represents a valuable service (a gateway that interworks SIP requests with traditional telephone calls, for example) might want to control access to its resources by authenticating requests that it receives.”Read the section ↗
The map below shows atlanta.example’s network. Each coral path is one attack. Turn on the defences, one at a time, and see which paths close. Some attacks need two defences together; some need a stolen password, so they close when both ways to steal one are closed.
Attack surface map
What an attacker can reach in atlanta.example
- SIP
- RTP
- Open attack
- Closed
12 of 12 attacks open
Reading the signalingOpen
- The attacker
- Captures SIP on the Wi-Fi, the access network, or a hacked router.
- The cost
- Learns who calls whom and when, user names, and the digest exchange.
- Closed by
- TLS for SIP
RFC 3261 §26.2.1 · Transport and Network Layer Security
“Transport or network layer security encrypts signaling traffic, guaranteeing message confidentiality and integrity.”
Read the section ↗No single defence closes everything. TLS alone closes two attacks of twelve. The rest of this module goes through the defences.
14.2 TLS, SIPS, certificate checks, and mutual TLS
TLS: hop by hop
TLS encrypts SIP between two hops and lets the client check who the server is. The Via shows it: SIP/2.0/TLS, usually on port 5061.
“Transport or network layer security encrypts signaling traffic, guaranteeing message confidentiality and integrity.”Read the section ↗
Proxies must read and change headers, so SIP cannot be encrypted end to end. Each hop is protected separately, and the user agents must trust the proxies in the middle:
“Proxy servers must therefore be trusted, to some degree, by SIP UAs. To this purpose, low-layer security mechanisms for SIP are recommended, which encrypt the entire SIP requests or responses on the wire on a hop-by-hop basis, and that allow endpoints to verify the identity of proxy servers to whom they send requests.”Read the section ↗
“TLS only allows SIP entities to authenticate servers to which they are adjacent; TLS offers strictly hop-by-hop security.”Read the section ↗
TLS from Alice’s phone to Proxy A says nothing about the hop from Proxy B to Bob. Every proxy and registrar must support TLS:
“Proxy servers, redirect servers, and registrars MUST implement TLS, and MUST support both mutual and one-way authentication.”Read the section ↗
SIP over TLS, or SIPS?
There are two ways to use TLS, and they mean different things:
sip: URI sent over TLS |
sips: URI |
|
|---|---|---|
| Meaning | Use TLS on this hop if you can | TLS on every hop up to the target domain |
| When TLS fails | The request may continue on TCP or UDP | The request fails |
| Common use | Phones to their provider; most trunks | High-security networks that must refuse plain SIP |
“If one wants to use "best-effort TLS" for SIP, one just needs to use a SIP URI, and send the request over TLS.”Read the section ↗
“When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS;”Read the section ↗
Even SIPS cannot promise TLS on the last hop to the phone:
“Thus SIPS cannot guarantee that TLS usage will be truly end-to-end.”Read the section ↗
Certificate checks: is this really biloxi.example?
Encryption without a certificate check stops passive eavesdroppers, but not an attacker in the path: it can present its own certificate and read everything. The client must check that the certificate names the SIP domain it wanted:
“Then, the client MUST compare the original domain portion of the SIP AUS used as input to the RFC 3263 [8] server location procedures to the SIP domain identities obtained from the certificate.”Read the section ↗
“Certificates received in the authentication process SHOULD be validated with root certificates held by the client; failure to validate a certificate SHOULD result in the failure of the request.”Read the section ↗
Note what the client compares: the domain of the URI, biloxi.example, not the host name that DNS returned, sip1.biloxi.example. DNS is not trusted; the certificate is. A certificate for the host only does not prove that the host serves the domain. Pick a certificate and follow the rules:
Certificate check · RFC 5922
Is this server really biloxi.example?
- Proxy A resolves
sips:bob@biloxi.example - DNS (SRV, A) gives
sip1.biloxi.example 203.0.113.11:5061 - The server's certificate must name
biloxi.example
Certificatesigned by a trusted CA
What RFC 5922 asks for: the SIP domain as a sip URI in subjectAltName.
| Value | RFC 5922 §7.1 |
|---|---|
URI:sip:biloxi.example | SIP domain identity biloxi.example |
DNS:sip1.biloxi.example | ignored: the certificate has a sip URI |
CN=sip1.biloxi.example | ignored: the certificate has subjectAltName |
Authenticated
Identities found: biloxi.example
The certificate names biloxi.example, the domain of the URI. The server is authenticated for biloxi.example.
RFC 5922 §7.3 · Client Behavior
“Then, the client MUST compare the original domain portion of the SIP AUS used as input to the RFC 3263 [8] server location procedures to the SIP domain identities obtained from the certificate.”
Read the section ↗| RFC 5922 rule | Example |
|---|---|
A sip URI in subjectAltName is the preferred identity |
URI:sip:biloxi.example |
DNS names count only if there is no sip URI identity |
DNS:biloxi.example |
| A URI with a user part names a person, not a domain | URI:sip:bob@biloxi.example is ignored |
| The CN only if there is no subjectAltName at all | Old certificates |
| Whole names only: no suffixes, no wildcards | *.biloxi.example does not match |
“Implementations MUST NOT match suffixes. For example, "foo.example.com" does not match "example.com".”Read the section ↗
“For example, a valid certificate for "example.com" does not imply that the owner of that certificate has any relationship at all to "subname.example.com".”Read the section ↗
RFC 3261 §26.3.2.1 was looser: it allowed a certificate for “a host within the atlanta.com domain”. RFC 5922 updates RFC 3261 and requires the domain itself. So a provider must buy certificates for its SIP domains, not only for its servers:
“When assigning certificates to authoritative servers, a SIP service provider MUST ensure that the SIP domain used to reach the server appears as an identity in the subjectAltName field, or for compatibility with existing certificates, the Subject field of the certificate.”Read the section ↗
Mutual TLS on trunks
Between a phone and its provider, only the server has a certificate; the phone proves who it is with digest (Module 13). Between servers — a company and its carrier, two providers — both sides present a certificate. This is mutual TLS, and it replaces “trust anything from this IP address”, which a forged source address can fool:
“For these reasons, mutual authentication is mostly used in server-to-server communications (e.g., between SIP proxies, or between proxies and gateways or media servers), and in environments where using certificates on both sides is possible (e.g., high-security devices used within an enterprise).”Read the section ↗
“For example, if the server is an inbound proxy that has peering relationships with the outbound proxies of other specific domains, the server might allow only connections authenticated as coming from those domains.”Read the section ↗
14.3 Edge protection: SBC, topology hiding, rate limits, blocking
Most attacks arrive at the edge, so most defences live there. RFC 3261 suggests a “bastion host” in front of the SIP servers; today it is usually an SBC (Module 3):
“These bastion hosts can also take the brunt of denial-of-service attacks, ensuring that SIP hosts within the administrative domain are not encumbered with superfluous messaging.”Read the section ↗
| Defence | What it does | Closes |
|---|---|---|
| Topology hiding | Replaces inside addresses in Via, Record-Route, Contact, and SDP with the SBC’s own | Mapping the inside network |
| Rate limits | Limits requests per second from each source, and in total, for example with the Kamailio pike module | Flooding, fast scans |
| Blocking after failed logins | Blocks a source address after a few failed challenges, for example with fail2ban | Password guessing |
| Same answer for every user | Answers 401 for unknown users too, never 404 | Scanning |
| Challenge every outgoing call | 401 or 407 for any request that would cost money | Calls without a password |
| Call limits | Limits calls per account, destinations, and night-time international calls | The size of a toll-fraud bill |
“By default, most SBCs are either Media-relay or Media-aware B2BUAs and replace the Contact URI; remove the Via and Record-Route headers; modify Call-ID, To, From, and various other headers; and modify SDP.”Read the section ↗
“The following SIP headers, when generated by a user agent, can directly or indirectly reveal identity information about the originator of a message: From, Contact, Reply-To, Via, Call-Info, User-Agent, Organization, Server, Subject, Call-ID, In-Reply-To and Warning.”Read the section ↗
A proxy should answer an unauthenticated request cheaply. A stateful challenge with retransmissions costs memory, and an attacker with a forged Via can aim the retransmissions at someone else:
“UAs and proxy servers SHOULD challenge questionable requests with only a single 401 (Unauthorized) or 407 (Proxy Authentication Required), forgoing the normal response retransmission algorithm, and thus behaving statelessly towards unauthenticated requests.”Read the section ↗
“Attackers can create bogus requests that contain a falsified source IP address and a corresponding Via header field that identify a targeted host as the originator of the request and then send this request to a large number of SIP network elements, thereby using hapless SIP UAs or proxies to generate denial-of-service traffic aimed at the target.”Read the section ↗
Moving SIP from port 5060 to another port cuts the noise from simple scanners, but it is not a defence: a full port scan finds it in minutes.
14.4 Trust domains: PAI and Privacy
Anyone can write anything in From (Module 7). A network that has authenticated the caller says so in P-Asserted-Identity. That claim is only worth something inside a trust domain: a set of elements that agree how they authenticate users and whom they trust.
“Nodes in such a Trust Domain are explicitly trusted by its users and end-systems to publicly assert the identity of each party, and to be responsible for withholding that identity outside of the Trust Domain when privacy is requested.”Read the section ↗
PAI is plain text, with no signature. Its only protection is that elements accept it only from members of the trust domain:
“Furthermore, since the asserted identities are not cryptographically certified, they are subject to forgery, replay, and falsification in any architecture that does not meet the requirements of [5].”Read the section ↗
So the element at the edge of the trust domain must check every PAI that comes in from outside, and a phone must ignore PAI from an element it does not trust:
“If the proxy received the message from an element that it does not trust and there is a P-Asserted-Identity header present which contains a SIP or SIPS URI, the proxy MUST replace that SIP or SIPS URI with a single SIP or SIPS URI or remove this header field.”Read the section ↗
“However, if a User Agent Server receives a message from a previous element that it does not trust, it MUST NOT use the P-Asserted-Identity header field in any way.”Read the section ↗
In practice, the trust domain is a list of peers in the SBC or proxy configuration: “PAI is accepted from the carrier’s trunk and from our own proxies; from everyone else, it is removed”. Privacy: id asks the trust domain to remove PAI before the call leaves it (Module 7). The chain is only as strong as its weakest member:
“This information is secured by transitive trust, which is only as reliable as the weakest link in the chain of trust.”Read the section ↗
14.5 Media security and caller identity
TLS protects SIP, not the voice. RTP is a separate stream, and without SRTP anyone on the path can record it (Module 18):
“Attackers might attempt to modify SDP bodies, for example, in order to point RTP media streams to a wiretapping device in order to eavesdrop on subsequent voice communications.”Read the section ↗
The two are linked. With the common SDES method, the SRTP keys travel in the SDP, in a=crypto lines. Without TLS for SIP, the keys are readable, and SRTP protects nothing. DTLS-SRTP, used by WebRTC, exchanges its keys on the media path instead.
PAI only works inside a trust domain. Between carriers, caller ID needs a signature that any network can check: STIR/SHAKEN adds an Identity header with a signed token (RFC 8224; Module 28).
| Protects | Signaling | Media | Caller identity |
|---|---|---|---|
| Mechanism | TLS, hop by hop | SRTP | PAI in a trust domain; STIR/SHAKEN between networks |
| Module | 14, 19 | 18 | 7, 14, 28 |
Common mistakes
A PBX open on port 5060 with weak extension passwords
A PBX is reachable from the whole Internet on UDP 5060, and the extension passwords are 1234, the extension number, or the factory default. Scanners find it within hours and guess the passwords within days. Then, usually on a Friday night, the calls start: premium-rate and international numbers, on many channels at once. The digest is correct, the PBX works exactly as configured, and the bill arrives on Monday.
Call flow · toll fraud
Toll fraud through a PBX with a weak password
- SIP
- ⚠Problem
At 02:00 on a Saturday, the attacker calls a premium-rate number through the PBX, as extension 101.
All steps as text
- Attacker → PBX: INVITE. At 02:00 on a Saturday, the attacker calls a premium-rate number through the PBX, as extension 101.
- PBX → Attacker: 401 Unauthorized. The PBX asks for credentials. So far, everything works as designed.
- Attacker → PBX: ACK. The attacker acknowledges the 401.
- Attacker → PBX: INVITE. It answers the challenge with the password of 101: 1234, found by guessing last night. Problem: The digest is correct: the password is weak, not the protocol.
- PBX → Carrier gateway: INVITE. The PBX accepts the credentials and starts a call on its SIP trunk, as extension 101.
- Carrier gateway → PBX: 200 OK. The premium-rate number answers. The carrier starts billing the company.
- PBX → Carrier gateway: ACK. The PBX confirms the call to the carrier.
- PBX → Attacker: 200 OK. The PBX answers the attacker. The attacker profits from each minute of the premium-rate call.
- Attacker → PBX: ACK. The call runs all weekend, often on dozens of channels at once.
“Any SIP UAS that represents a valuable service (a gateway that interworks SIP requests with traditional telephone calls, for example) might want to control access to its resources by authenticating requests that it receives.”Read the section ↗
Remember: long random SIP passwords; block sources after failed logins; accept registrations only from the networks your phones use, where you can; limit calls per account and to expensive destinations. Watch for many 401s from one address — that is a scan or a guessing attack in progress.
Different replies for known and unknown users (404 and 401)
A registrar that answers 404 Not Found to a REGISTER for an extension that does not exist, and 401 to one that exists, tells a scanner which extensions are real. The scanner then guesses passwords only for real users, which is much faster.
Broken
Broken: 404 for unknown users, 401 for real ones
- SIP
- ⚠Problem
A scanner on the Internet tries extension 100. User-Agent: friendly-scanner is a common scanning tool.
All steps as text
- Attacker → PBX: REGISTER. A scanner on the Internet tries extension 100. User-Agent: friendly-scanner is a common scanning tool.
- PBX → Attacker: 401 Unauthorized. The PBX challenges: extension 100 exists.
- Attacker → PBX: REGISTER. It tries 101.
- PBX → Attacker: 404 Not Found. The PBX answers 404 Not Found: there is no extension 101. Problem: The PBX tells the scanner that 101 does not exist.
- Attacker → PBX: REGISTER. And 102. A real scan tries thousands of numbers in a few minutes.
- PBX → Attacker: 401 Unauthorized. Another 401. The scanner now knows that 100 and 102 exist, and 101 does not.
Remember: challenge every request without credentials, whether the user exists or not. After a failed digest, answer the same way for unknown users and wrong passwords. Many PBXs have a setting for this, such as alwaysauthreject in Asterisk’s older chan_sip driver.
TLS for signaling, but RTP without encryption
The phones register over TLS, the Via says TLS, and the padlock icon is on. But the SDP still offers plain RTP. Anyone on the path cannot read the SIP, but can record every call.
m=audio 49170 RTP/AVP 0 8 plain RTP: readable by anyone on the path
m=audio 49170 RTP/SAVP 0 8 SRTP
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVzThe reverse also happens: SRTP with SDES keys over plain UDP or TCP. The a=crypto line carries the key in the clear, so anyone who captures the INVITE can decrypt the media.
Remember: check the m= line, not the Via. Encrypted media needs RTP/SAVP (or UDP/TLS/RTP/SAVP for DTLS-SRTP), and SDES keys need TLS for the signaling. Turn on SRTP alone in the attack map above and see which path stays open.
Accepting PAI from an untrusted source
An SBC or proxy that passes on P-Asserted-Identity from any source lets anyone choose the caller ID that phones and carriers treat as verified. Attackers use this for fraud calls that show a bank’s number, and for calls that bypass billing or call blocking.
Broken
Broken: Proxy A passes on a forged PAI
- SIP
- ⚠Problem
The attacker calls Alice. It writes its own P-Asserted-Identity: the number of Alice's bank.
All steps as text
- Attacker → Proxy A: INVITE. The attacker calls Alice. It writes its own P-Asserted-Identity: the number of Alice's bank.
- Proxy A → Alice: INVITE. Proxy A forwards the INVITE with the forged PAI. Alice's phone trusts Proxy A, so it trusts the PAI. Problem: Proxy A passes on a PAI from outside the trust domain.
- Alice → Proxy A: 180 Ringing. Alice's phone rings and shows the bank's number as a network-verified caller.
- Proxy A → Attacker: 180 Ringing. Proxy A removes its Via and forwards the 180.
Remember: at the edge of the trust domain, remove PAI (and P-Preferred-Identity) from every request that does not come from a configured, authenticated peer. Then add PAI yourself, from the identity that you authenticated.
Summary
- Most attacks on SIP are automatic and aim at money: scanning, password guessing, registration hijack, and toll fraud. Eavesdropping, flooding, and identity forgery complete the list.
- TLS encrypts SIP hop by hop. A
sip:URI over TLS is best effort; a SIPS URI requires TLS on every hop up to the target domain. - The client checks that the certificate names the domain of the URI, as RFC 5922 requires: a
sipURI or DNS name in subjectAltName, whole names only, no wildcards. Servers check each other with mutual TLS. - The SBC at the edge hides the inside topology, limits rates, and blocks sources after failed logins. Answer 401 for every user, never 404, so scanners learn nothing.
- P-Asserted-Identity is trusted only from members of the trust domain; the edge removes it from everyone else.
- TLS does not protect the voice: use SRTP, and keep SDES keys inside TLS. Between networks, caller ID needs STIR/SHAKEN.