The SIP trunk security checklist

Assume the trunk is being probed today - Any SIP service exposed to the internet receives a steady stream of INVITE and REGISTER attempts from scanners looking for a PBX that will place a call to a premium-rate destination without asking who is calling. This is not targeted; it is background radiation. The attackers' economics depend on finding one weak configuration among thousands, and the cost of that configuration is a bill for a weekend of calls to numbers you have never heard of. Every item below is intended to make your trunk not worth the scanner's time, and to make sure that if something does get through, the damage is bounded.

Encrypt signalling and media, and mean it - Run SIP over TLS 1.2 or later on port 5061 rather than UDP 5060, and negotiate SRTP for media. Encryption does two things: it stops credentials and call metadata travelling in clear text across networks you do not control, and it makes casual interception of conversations impractical. Configure the trunk to require SRTP rather than merely offer it, so a downgraded call fails instead of silently falling back to plain RTP. Validate the carrier's certificate against a real chain and pin the expected name; a trunk that accepts any certificate has TLS in name only.

Prefer IP authentication, harden registration where you must use it - The most robust trunk is one that accepts signalling only from a small set of the carrier's SBC addresses and only sends to them, with your own SBC or firewall doing the same in reverse. There is then no password to guess. Where you have dynamic addressing or a cloud PBX and must register, use long random credentials that were generated by a machine and are stored nowhere a human types them, rotate them if staff who knew them leave, and rate-limit failed registrations so a brute-force attempt is throttled after a handful of tries. Never reuse the trunk credential on a handset or a softphone.

Put a session border controller between the PBX and the world - The SBC is the control point where you can enforce all of this: which IPs may talk to you, which methods are allowed, how many sessions and how many new calls per second, what codecs are negotiated, and what internal topology is visible on the far side. It hides your PBX's identity, normalises malformed SIP that would otherwise reach a fragile parser, and gives you one place to log every attempt. A firewall with SIP application-layer inspection is a partial substitute; a router that forwards 5060 to the PBX is not.

Set limits that make an attack self-limiting - Ask your carrier for a maximum concurrent-call and calls-per-second limit on the trunk that reflects real usage with headroom, and mirror those limits on the SBC. Then set destination controls: block premium-rate and satellite prefixes you have no business calling, restrict international calling to the countries you actually deal with, and put tighter rules on out-of-hours traffic. Add a daily spend cap on the account with an alert well below it. A compromised endpoint that can only place a few calls at a time to a limited set of countries produces an incident, not a catastrophe.

Close the doors on the PBX itself - Most trunk fraud does not attack the trunk; it walks in through the PBX and uses the trunk. Disable unused extensions and remote-access features, enforce strong voicemail PINs and disable outbound dialling from voicemail menus, turn off call forwarding to external numbers by default and require justification to enable it, remove default administrator accounts, and patch the platform on the vendor's schedule. If the PBX has a web interface, it should not be reachable from the internet, full stop. The same applies to any conferencing bridge, IVR or auto-attendant that can transfer a caller to an arbitrary number.

Watch the traffic, and let the carrier watch it too - Log every call attempt with source, destination, duration and outcome, and review anomalies weekly at a minimum. Better, feed the CDRs into monitoring that alerts on unusual destinations, unusual hours or unusual volume in near real time. Then make sure your carrier is doing the same from their side. Dollu's fraud engine scores traffic per trunk against known IRSF ranges, velocity thresholds and pattern signatures, and blocks or throttles automatically; the value of that is highest when your own controls are already in place, because the carrier's view catches what slips past yours rather than replacing them.

Plan the response before you need it - Decide now who can suspend the trunk, how, and how quickly, and confirm the carrier's out-of-hours contact and expected response time in writing. Know how to rotate credentials, block a destination and drop the concurrent-call limit to one in a hurry. Keep the SBC and PBX configuration in version control so a compromised device can be rebuilt rather than cleaned. And after any incident, ask what control would have made it impossible rather than merely detectable, and add it.

The short version - TLS and SRTP on; IP authentication where possible and unguessable credentials where not; an SBC or SIP-aware firewall in front of the PBX; concurrent-call, CPS, destination and spend limits sized to the business; the PBX locked down like any other server; monitoring on both sides of the trunk; and a rehearsed way to shut it off. None of it is expensive, and all of it is cheaper than the bill for the alternative.