Securing a SIP Trunk Against Toll Fraud: Concrete Controls for Outbound Call Centers

How SIP Toll Fraud Works in Practice

Attackers scan the internet for SIP endpoints on port 5060. A basic SIPVicious scan can probe 65,000 IP addresses in under an hour. When they find a SIP proxy or SBC that responds to OPTIONS or REGISTER, they attempt to authenticate using leaked credential lists or brute force over dictionary combinations. A successful authentication grants them the ability to originate calls at your expense — typically high-cost international destinations where the attacker earns a termination kickback (International Revenue Share Fraud, IRSF).

A compromised SIP trunk can generate $10,000–$50,000 in fraudulent call charges in a weekend before anyone notices. The charges are yours. Carriers typically do not absorb fraud losses unless you can demonstrate a specific technical failure on their side.

The surface attack is straightforward to close. The controls below are non-optional for any outbound call center running a SIP trunk.

Control 1: Restrict SIP to Carrier IP Ranges

Do not expose port 5060 to the internet. Restrict inbound SIP signaling to your carrier's published IP ranges at the firewall level. No rule, no response — the scanner gets nothing.

On a Linux firewall with nftables:

`` table inet filter { chain input { type filter hook input priority 0; ip saddr { <carrier_ip_1>, <carrier_ip_2> } udp dport 5060 accept udp dport 5060 drop ip saddr { <carrier_ip_1>, <carrier_ip_2> } udp dport 10000-20000 accept udp dport 10000-20000 drop } } ``

Obtain the current carrier IP ranges from your custom SIP integration documentation and update the rules whenever the carrier adds new PoPs. This single control eliminates the majority of automated scanning attacks.

Control 2: Rate-Limit Authentication Attempts

If SIP registration is in use (digest auth), an attacker who can reach port 5060 can attempt authentication. Rate-limit REGISTER and INVITE attempts by source IP at the SBC level, not just the firewall.

On Kamailio, add a pike module entry to drop IPs exceeding 30 requests per second:

``` loadmodule "pike.so" modparam("pike", "sampling_time_unit", 2) modparam("pike", "reqs_density_per_unit", 30) modparam("pike", "remove_latency", 4)

request_route { if (!pike_check_req()) { sl_send_reply("503", "Service Unavailable"); exit; } ... } ```

On FreeSWITCH, the mod_esl fail2ban integration or the native auto-ban-blacklist-duration parameter in the sofia profile handles this:

``xml <param name="max-auth-validity" value="3"/> <param name="auto-ban-blacklist-duration" value="300"/> ``

After 3 failed authentication attempts from one IP, that IP is silenced for 300 seconds. Adjust max-auth-validity to 5 for legitimate NAT environments where multiple users share one IP.

Control 3: Concurrent Channel and CPS Caps

Even if an attacker authenticates, a concurrent call cap limits their blast radius. Configure a per-account simultaneous channel limit and a calls-per-second (CPS) rate limit on the carrier side.

If your floor has 50 seats running at a 3:1 dial ratio, the legitimate peak is 150 concurrent channels. Set the carrier-side cap at 170 — 13% above the legitimate peak — and the SBC-side cap at 160. Any legitimate spike will hit the SBC cap first, allowing a brief alert before the carrier cap kicks in.

CPS limits prevent rapid-fire call storms. A legitimate predictive dialer with 50 agents will rarely exceed 5–10 CPS. Set a CPS cap of 15–20 per account. Exceeding 20 CPS while 150 channels are already up is not a legitimate dialing pattern and should trigger an alert, not just a 503.

When provisioning on UnlimCall's flat-rate network, specify your expected peak concurrent channels during setup — this becomes the basis for the hard cap on our side.

Control 4: Geo-Block High-Risk Destination Prefixes

Identify which countries your outbound campaigns actually call. If you call US, Canada, and UK only, block outbound routing to all other country codes at the SBC level. IRSF attacks almost universally target premium-rate destinations in Eastern Europe, West Africa, Pacific Islands, and the Caribbean — country codes your legitimate campaigns never need.

On FreeSWITCH, add a dialplan condition to reject calls to specific country code prefixes:

``xml <condition field="destination_number" expression="^(00|011)?(243|225|966|962|252)"> <action application="reject" data="CALL_REJECTED"/> </condition> ``

On a carrier with a self-service portal, configure a "permitted destination" allowlist at the account level — only the country codes you need. UnlimCall supports caller ID provisioning across 33 markets, but you can restrict active routing to a subset of those markets.

Control 5: Real-Time Spend Monitoring and Hard Caps

For call centers on per-minute billing, a sudden spike in call volume to high-cost destinations generates charges before anyone reviews the CDRs. For flat-rate seats, the fraud risk is lower (you are paying per seat, not per minute), but fraudulent calls still consume concurrent channels that legitimate agents need, and the carrier may bill overage if fraudulent volume exceeds the seat cap.

Configure alerts on:

• Concurrent channel count exceeding 110% of typical peak
• CPS exceeding the configured rate limit
• Any call to a destination prefix outside your permitted list
• Authentication failures: more than 5 per minute from any source IP

Most SBCs support SNMP traps or syslog output for these events. Feed them to any monitoring system (Grafana, PRTG, LibreNMS) and page on breach. Resolution time matters — a 15-minute alert-to-action window limits exposure significantly versus a next-morning email report.

What STIR/SHAKEN Does Not Protect Against

STIR/SHAKEN provides attestation that the caller ID on an outbound call is legitimate — it authenticates the calling number, not the SIP endpoint placing the call. A compromised SIP credential can still generate authenticated STIR/SHAKEN calls if it uses a number that your account is legitimately authorized to attest. STIR/SHAKEN is available for US/CA on UnlimCall's network; it is a deliverability tool, not a fraud prevention control.

Toll fraud prevention is entirely a function of the controls above: IP restriction, rate limiting, channel caps, geo-blocking, and spend monitoring.