How to Secure a SIP Account

A SIP account is a username, a password and a server address. Anyone who holds those three values can register as you, place calls that are billed to you, and receive calls meant for you. Securing the account means making the secret hard to obtain, limiting what an attacker can do with it, and encrypting the traffic so the secret and the conversation cannot be captured in transit. This guide walks through each layer in a sensible order.

Why do SIP accounts get attacked?

SIP servers are easy to find. Scanners sweep the internet for anything answering on UDP port 5060 and then try common extension numbers with common passwords. The goal is usually money: once an attacker can register, they route premium-rate or international calls through the account until the owner notices the bill. RFC 3261 section 26 describes the threat model in detail, including registration hijacking, impersonation of a server, and tearing down or modifying sessions. Every control below maps to one of those threats.

Use a long, random, unique password

The SIP password is the single most important control. Digest authentication in SIP hashes the password together with a server nonce, so the raw password does not cross the wire. But the hash can be captured and attacked offline, and online guessing is cheap when the server does not rate-limit. A short or dictionary password falls quickly in either case.

Guidelines that hold up well:

1. Generate the password with a password manager or a random generator. Do not type one by hand.
2. Aim for at least 16 characters, or longer if the PBX accepts it. Mixed character classes help, but length matters more.
3. Never reuse a password across extensions. If one is leaked, the others stay safe.
4. Never set the password equal to the extension number, the username, or the company name. Scanners try those first.

Store the password in the softphone's secure storage rather than in plain configuration files. SIPdia keeps the SIP password in the Apple Keychain on macOS and iOS.

Separate the auth username from the extension

On many PBX systems the extension number is public knowledge. It appears in company directories, in email signatures and in dial plans. If the extension number is also the authentication identity, the attacker already has half of what they need.

Asterisk's PJSIP driver lets the authentication username differ from the extension number, and some PBX front ends expose this as a separate field. In SIPdia the Username field holds the extension and the Advanced section has a separate Auth username field for the authentication identity. Where your PBX supports it, set the auth username to a random string on the PBX, then enter the same value in the app. A scanner that tries extension 201 with a thousand passwords never gets the username right, so none of the attempts can succeed.

Turn on TLS for signaling

Without TLS, every SIP message travels in clear text. That includes the digest challenge and response, the From and To headers that reveal who is calling whom, and the SDP body that carries media addresses and any SRTP keys. Anyone on the network path can read or alter these messages.

TLS encrypts the SIP connection between your client and the server, and it lets the client verify that it is talking to the real server rather than an impostor. RFC 3261 section 26 names TLS as the recommended transport-layer protection, and RFC 5630 clarifies how the sips URI scheme signals a requirement for secure transport.

To use TLS the server needs a certificate that the client trusts. SIPdia rejects self-signed certificates and requires one issued by a public certificate authority. If your PBX only has a self-signed certificate, either obtain a public one or run plain UDP or TCP over a VPN so the traffic is encrypted at a different layer. The TLS port is usually 5061; check common SIP ports if the server uses something else.

Turn on SRTP for audio

TLS protects signaling, not the voice stream. Audio travels as RTP on separate UDP ports, and plain RTP can be reconstructed into a listenable recording by anyone who captures it. SRTP, defined in RFC 3711, encrypts and authenticates each RTP packet.

The most common way to agree on SRTP keys in SIP is to place them in the SDP body of the INVITE and its answer, a method called SDES and described in RFC 4568. That only makes sense if the SDP itself is protected, which means SDES-keyed SRTP over an unencrypted SIP connection gives you very little. When keys travel this way, always pair SRTP with TLS.

In SIPdia the Encrypt audio setting has three values. Off sends plain RTP. Optional offers SRTP and falls back to plain RTP if the server does not support it. Required refuses to set up a call unless SRTP is negotiated. Choose Required when you know the server supports SRTP and you want a guarantee rather than a best effort. Read SIP over TLS vs SRTP for a deeper look at what each layer protects.

Limit where the account can register from

An attacker who has the credentials still needs to reach the server. Restricting network exposure removes that opportunity.

• IP allow-lists. If your users connect from known addresses, allow only those addresses to reach the SIP port. Asterisk supports permit and deny on chan_sip peers. In PJSIP the same options exist on each endpoint, contact_permit and contact_deny limit which addresses an endpoint may register, and a type=acl section filters all inbound SIP traffic.
• VPN. For roaming users, a VPN gives each device a predictable internal address and keeps the SIP port off the public internet entirely. This is the cleanest option for small teams.
• Session Border Controller or firewall. Larger deployments put a dedicated device in front of the PBX to filter and rate-limit SIP traffic.
• fail2ban. Where the server must stay reachable from the internet, fail2ban watches the PBX log for failed registrations and blocks the offending address after a few attempts. The Asterisk Security Event Logger documentation describes the security log that fail2ban can watch.

Also restrict the number of simultaneous registrations per account if the PBX allows it. One phone and one softphone rarely need more than two or three contacts.

Disable what you do not use

Each feature is a potential path for abuse. Common items to review:

• International and premium-rate dialing. If an extension never calls abroad, block it in the dial plan or outbound route.
• Call forwarding to external numbers. Attackers who gain access to a voicemail or feature-code system sometimes set forwarding to a premium number.
• Anonymous or guest SIP calls. Asterisk's allowguest should be off unless you have a specific reason.
• Unused codecs, transports and ports. Fewer open doors means fewer things to patch.

Rotate credentials and review access

Treat SIP credentials like any other password. Change them when an employee leaves, when a phone is lost, after any suspected compromise, and on a schedule you can actually keep. Keep a record of which device uses which account so a rotation does not leave a forgotten desk phone in a registration loop. Registration loops look like attacks in your logs and can trigger fail2ban against your own office.

Watch for toll fraud

Even with every control in place, keep an eye on the call detail records (CDRs). Signs worth investigating:

• Calls at night or on weekends from extensions that are normally idle.
• Short bursts of calls to the same foreign destination.
• Many failed registration attempts from one address.
• An extension registering from an unexpected country.

Set spending limits with your SIP trunk provider where possible. Many providers can cap daily spend or block high-risk destinations on request, and this often catches fraud before it becomes expensive.

A short checklist

1. Long random unique password, stored in secure storage.
2. Auth username different from the extension where the PBX supports it.
3. TLS transport with a public-CA certificate.
4. SRTP set to Required when the server supports it.
5. SIP port reachable only from known addresses or over a VPN.
6. fail2ban or equivalent on any internet-facing PBX.
7. International and premium routes blocked where not needed.
8. Credentials rotated on a schedule and after any incident.
9. CDRs reviewed for unusual patterns.

Next steps

Configure the transport and encryption settings described here in SIPdia using the TLS and SRTP feature page. For the server side, read how to protect a PBX from SIP scanning and the overview of common SIP security risks.