DDoS protection for VoIP
and SIP infrastructure

Back to Blog

Why VoIP Infrastructure Is a Prime Target

Voice over IP has fundamentally replaced the PSTN for most businesses, but it introduced a class of vulnerabilities that traditional telephony never faced. VoIP traffic traverses the same IP networks as everything else, which means it competes for the same bandwidth, the same CPU cycles, and the same firewall state tables. Unlike a web application that can tolerate a few hundred milliseconds of latency without users noticing, voice calls degrade noticeably at 150ms of one-way delay and become unusable above 300ms. Jitter above 30ms causes audible distortion. Packet loss above 1% makes conversations unintelligible. This extreme sensitivity to network conditions makes VoIP infrastructure disproportionately vulnerable to DDoS attacks.

Attackers target VoIP infrastructure for several distinct reasons. Extortion is the most common: a threat actor demonstrates they can disrupt calls for a few minutes, then demands payment to stop. For a contact center handling thousands of concurrent calls, even five minutes of degradation translates to significant revenue loss and SLA penalties. Competitive sabotage is another motivation, particularly among UCaaS providers where a rival's outage drives customers to switch. Toll fraud cover is a more sophisticated use case: attackers flood the SIP infrastructure with garbage traffic to distract operations teams while simultaneously routing fraudulent international calls through compromised trunks. By the time anyone notices the toll fraud, the calls have already been completed and the charges are locked in.

The financial impact compounds rapidly. A mid-sized contact center with 500 agents losing call capacity for one hour faces direct costs in idle agent wages, lost sales conversions, SLA breach penalties, and customer churn. For telecom carriers, the impact extends to regulatory exposure: emergency services (E911) must remain reachable, and a DDoS that degrades 911 call routing creates liability that no amount of insurance fully covers.

SIP-Specific Attack Vectors

Standard volumetric floods (UDP, TCP SYN, DNS amplification) affect VoIP infrastructure the same way they affect any other service. But SIP introduces protocol-specific attack vectors that generic DDoS tools rarely understand.

INVITE Floods

The SIP INVITE method initiates a call. Each INVITE requires the receiving server to allocate resources: parse the SIP headers, perform a database lookup for the destination, check authentication and authorization, set up media path state, and potentially fork the request to multiple endpoints. An INVITE flood sends thousands of these requests per second, each consuming server resources regardless of whether the call is ever answered. The attack is particularly effective because SIP proxies and registrars must process each INVITE to determine if it is legitimate. Unlike a SYN flood where stateless SYN cookies can deflect the attack, SIP INVITE processing requires application-layer logic that cannot be offloaded to the kernel.

REGISTER Floods

SIP REGISTER requests bind a user agent (phone, softphone) to a location. Registration floods overwhelm the registrar with fake registration attempts, exhausting database connections and authentication processing capacity. When the registrar cannot keep up, legitimate phones lose their registration and become unreachable for incoming calls. This is particularly devastating for hosted PBX providers where tens of thousands of endpoints maintain active registrations.

SIP Scanning and Enumeration

Before launching a targeted attack, adversaries scan SIP infrastructure to discover valid extensions, identify server software versions, and map the topology. Tools like SIPVicious automate this process, sending OPTIONS and REGISTER probes across IP ranges. While scanning itself may not constitute a denial of service, high-rate scanning consumes resources and, more importantly, reveals the information needed to craft a targeted attack. Scanning traffic to UDP port 5060 is a reliable leading indicator that a more serious attack is being planned.

RTP Floods

The Real-time Transport Protocol carries the actual voice media. RTP typically runs on UDP ports in the range 10000 to 20000 (or a similar high-port range configured on the media server). An RTP flood targets these ports with garbage UDP packets, consuming media server CPU as the server attempts to process packets that do not belong to any active call. Because RTP traffic is UDP and the port range is well-known, this attack is trivial to execute. The media server cannot simply block all UDP to its RTP port range because that would kill all active calls.

Telephony Denial of Service (TDoS)

TDoS attacks are application-layer attacks that use valid SIP signaling to place enormous numbers of calls simultaneously. Each call consumes a trunk, a media port, and potentially an agent or auto-attendant slot. Because the calls use valid SIP, they pass through firewalls and session border controllers without triggering volumetric alarms. TDoS is especially effective against emergency call centers, government agencies, and any organization where incoming calls must be answered. The attack ties up all available lines, preventing legitimate callers from getting through.

Why Standard DDoS Tools Miss SIP Attacks

Most DDoS detection tools are built around TCP/HTTP traffic patterns. They understand SYN floods, HTTP request rates, and TCP connection state exhaustion. SIP traffic looks fundamentally different. SIP signaling runs primarily over UDP on port 5060 (unencrypted) or TCP/TLS on port 5061 (encrypted). A spike in UDP traffic to port 5060 might trigger a generic UDP flood alarm, but the detection system has no understanding of what constitutes normal SIP traffic versus attack SIP traffic.

Consider the difference between a legitimate registration storm and an attack. When a hosted PBX provider reboots a SIP proxy, thousands of endpoints simultaneously re-register, causing a burst of REGISTER traffic that looks identical to a REGISTER flood from a volumetric perspective. A SIP-unaware detection system triggers a false alarm. Conversely, a low-rate INVITE flood at 200 requests per second might fly under the radar of a system that only monitors aggregate bandwidth, even though 200 INVITE requests per second is enough to overwhelm a mid-range SIP server's call setup capacity.

The traffic patterns are also unique in their asymmetry. A single SIP INVITE generates a cascade of related messages: 100 Trying, 180 Ringing, 200 OK, ACK, and eventually BYE. This means the packet count from the server side is always a multiple of the inbound request rate. Detection systems that measure bidirectional traffic ratios for TCP connections have no model for this SIP-specific pattern.

Session Border Controller Limitations

Session Border Controllers (SBCs) are the primary security appliance for VoIP networks. They sit at the network edge and handle SIP normalization, topology hiding, NAT traversal, and basic rate limiting. Most SBCs include some form of DDoS protection: per-source rate limits on SIP methods, call rate throttling, and IP blacklisting.

However, SBCs have fundamental limitations as DDoS defense. First, they are inline devices with finite processing capacity. A volumetric flood that saturates the link upstream of the SBC renders its filtering capabilities irrelevant because the traffic never reaches the SBC's inspection engine. Second, SBC rate limiting is typically per-source-IP. A distributed attack from a botnet with thousands of source IPs keeps each individual source below the rate limit while the aggregate traffic overwhelms the SBC. Third, SBCs operate at the SIP layer and have limited visibility into RTP-layer attacks. An RTP flood targeting media servers behind the SBC may not trigger any SBC alarm because the SBC is not in the RTP media path (most SBCs can operate in either B2BUA mode where they relay media, or proxy mode where media flows directly between endpoints).

The most critical limitation is that SBCs are themselves targets. An SBC that is busy processing a flood of malformed SIP messages has reduced capacity for legitimate traffic. In a sufficiently large attack, the SBC becomes the bottleneck rather than the defense.

Practical Defense for VoIP Infrastructure

SIP-Aware Rate Limiting

Effective rate limiting for SIP must operate at the method level, not just the packet level. INVITE requests should have a separate rate limit from REGISTER requests, OPTIONS probes, and BYE messages. This granularity allows the system to throttle call setup floods without affecting existing calls or registration maintenance. Rate limits should be applied per source IP and per source subnet to handle both single-source and distributed attacks.

# nftables: SIP method-aware rate limiting on the SBC host
# Limit INVITE from any single source to 20/sec (generous for legitimate use)
nft add rule inet filter input udp dport 5060 \
  @ih,0,32 0x494e5649 \
  meter sip_invite { ip saddr limit rate 20/second burst 30 packets } accept

# Limit REGISTER from any single source to 5/sec
nft add rule inet filter input udp dport 5060 \
  @ih,0,32 0x52454749 \
  meter sip_register { ip saddr limit rate 5/second burst 10 packets } accept

# Global SIP rate limit as a backstop
nft add rule inet filter input udp dport 5060 \
  meter sip_global { ip saddr limit rate 100/second burst 200 packets } accept
nft add rule inet filter input udp dport 5060 drop

RTP Monitoring and Anomaly Detection

Monitoring RTP requires tracking the expected media sessions against actual traffic on the RTP port range. When a call is established, the SDP negotiation specifies which ports will carry media. Any RTP traffic arriving on ports that do not have an active media session is suspicious. Additionally, monitoring the packet rate on active RTP ports provides early warning: a legitimate G.711 call generates approximately 50 packets per second in each direction. If a single RTP port suddenly receives 10,000 packets per second, that is an RTP flood, not a phone call.

Deploying Detection on SBC and Media Servers

Detection agents should be deployed on every node in the voice path: the SBC itself, SIP proxies, registrars, and media servers. Each node has different baseline traffic patterns and different attack surfaces. The SBC sees all signaling traffic and is the best vantage point for detecting INVITE and REGISTER floods. Media servers see RTP traffic and are the best vantage point for detecting RTP floods. SIP proxies see the internal routing of calls and can detect anomalies in call distribution patterns.

Flowtriq's agent is particularly well suited for this deployment model. At $9.99 per node per month, deploying agents on an SBC, two SIP proxies, and four media servers costs less than $70/month and provides per-node visibility across the entire voice path. The agent tracks UDP kernel counters every second, which captures both SIP signaling anomalies on port 5060/5061 and RTP floods on the media port range without requiring deep packet inspection of call content.

Detecting SIP Floods via Kernel Counters

SIP flood detection does not always require parsing SIP messages. Kernel-level UDP counters provide a fast, lightweight signal. On a SIP proxy that normally processes 500 UDP packets per second on port 5060, a sudden jump to 50,000 packets per second is unambiguous. The Udp InDatagrams counter in /proc/net/snmp captures all inbound UDP, while iptables or nftables counters on port 5060 specifically isolate SIP signaling traffic.

# Track SIP-specific packet rates using nftables counters
nft add counter inet filter sip_in
nft add rule inet filter input udp dport 5060 counter name sip_in accept

# Poll the counter every second to compute PPS
while true; do
  C1=$(nft list counter inet filter sip_in | awk '/packets/{print $2}')
  sleep 1
  C2=$(nft list counter inet filter sip_in | awk '/packets/{print $2}')
  echo "SIP PPS: $((C2 - C1))"
done

# Monitor UDP NoPorts counter — spikes indicate flood to unused ports
watch -n 1 "awk '/^Udp:/{getline;print \$4}' /proc/net/snmp"

Network-Level Defenses

Beyond host-level detection, VoIP providers should implement network-level controls. Access control lists on edge routers should restrict SIP traffic (UDP/TCP 5060, TLS 5061) to known peer networks and customer subnets. SIP traffic from the open internet should only be accepted on designated ingress points with robust rate limiting. RTP port ranges should be restricted to source IPs that have active SIP sessions, though this requires integration between the SBC and the edge firewall.

For providers with their own AS numbers, BGP FlowSpec rules can surgically filter attack traffic at the network edge. A FlowSpec rule that drops UDP traffic to port 5060 from a specific source prefix acts in seconds and does not require changes to host-level firewall rules. Flowtriq can trigger these FlowSpec announcements automatically when a SIP flood is detected, providing sub-second automated mitigation.

The Business Impact of Every Second

For telecommunications providers and UCaaS platforms, call quality degradation is not an abstract metric. It is directly measurable in customer churn. Industry data consistently shows that subscribers who experience repeated call quality issues are three to five times more likely to switch providers within 90 days. For a carrier with 100,000 subscribers, a DDoS event that degrades call quality for even 10% of subscribers can trigger a churn cascade that costs millions in lost recurring revenue.

The detection speed matters more for VoIP than for almost any other workload. A web application can absorb 30 seconds of degraded response times with minimal user impact. A voice call that experiences 30 seconds of packet loss or jitter has already failed. The caller has hung up, the customer is frustrated, and the damage is done. Detection must happen in seconds, and mitigation must engage within seconds after that. This is why kernel-level monitoring with per-second granularity, as Flowtriq provides, is essential for voice infrastructure.

A single dropped call costs less than a penny in direct infrastructure terms, but a pattern of dropped calls during a DDoS event can cost a carrier thousands of subscribers. The math always favors investing in detection.

Building a VoIP DDoS Defense Checklist

Protecting VoIP infrastructure requires a layered approach that addresses volumetric, protocol-specific, and application-layer attacks simultaneously. The following checklist covers the essential elements:

• Deploy detection agents on every SBC, SIP proxy, registrar, and media server node
• Configure per-method SIP rate limits (INVITE, REGISTER, OPTIONS) at both the SBC and the host firewall level
• Restrict SIP port access (5060/5061) to known peer networks and customer subnets at the edge router
• Monitor RTP port ranges for traffic that does not correspond to active media sessions
• Establish baseline metrics for SIP PPS, concurrent registrations, and call setup rate during normal operations
• Configure automated mitigation (BGP FlowSpec, upstream blackhole communities) that can engage within seconds of detection
• Test your DDoS response plan with simulated SIP floods at least quarterly
• Maintain out-of-band communication channels for your NOC that do not depend on the VoIP infrastructure being protected
• Document your upstream transit provider's DDoS mitigation capabilities and escalation procedures

Back to Blog

Related Articles