SIP Flood Protection: How to Detect
and Stop VoIP DDoS Attacks

Back to Blog

Why VoIP Is a Prime DDoS Target

Voice over IP infrastructure is one of the most attractive targets for DDoS attackers. The reason is simple: VoIP services have extremely low latency tolerance. A web server can absorb a few hundred milliseconds of delay and most users will not notice. A voice call cannot. Even 150 milliseconds of added jitter makes a conversation unintelligible, and packet loss above 1% causes audio dropouts that make the service unusable.

This means attackers do not need massive bandwidth to disrupt VoIP. A relatively modest flood targeting the right ports and protocols can take down a platform serving thousands of concurrent calls. The attack does not need to saturate a link. It just needs to overwhelm the SIP signaling layer or degrade RTP media quality enough that calls start failing.

VoIP providers also tend to expose well-known ports to the public internet by necessity. SIP typically runs on UDP port 5060 (unencrypted) or TCP/TLS port 5061 (encrypted). RTP media streams use dynamic UDP port ranges, often 10000 through 20000. These ports must be reachable for the service to function, which gives attackers a clear target map without any reconnaissance required.

SIP INVITE Floods

The SIP INVITE flood is the most common attack vector against VoIP infrastructure. The attacker sends a massive volume of SIP INVITE requests to port 5060, each one attempting to initiate a new call session. The SIP proxy or registrar must parse each INVITE, perform authentication lookups, check routing tables, and allocate resources for the potential call.

Even if the INVITE requests are malformed or unauthenticated, the SIP server still consumes CPU cycles processing and rejecting them. At high enough volumes, the server spends all of its processing power handling garbage INVITEs and can no longer process legitimate call setup requests. New calls fail. Existing calls may continue for a while (since RTP media flows directly between endpoints in many architectures), but any call that needs to be renegotiated, transferred, or terminated through the SIP proxy will fail.

A typical SIP INVITE packet is around 800 to 1200 bytes, depending on the headers included. An attacker generating 50,000 INVITE packets per second is only pushing roughly 40 to 60 Mbps of traffic. That is well below the bandwidth thresholds that most traditional DDoS detection systems trigger on. But for a SIP proxy handling a few thousand concurrent calls, 50,000 fake INVITEs per second is catastrophic.

What Makes INVITE Floods Hard to Detect

Traditional DDoS detection works by monitoring aggregate traffic volume: total packets per second or bits per second crossing a link or hitting a destination IP. The problem is that SIP INVITE floods often fall well below volumetric thresholds while still being devastating to the application layer.

Additionally, SIP INVITE traffic is expected on port 5060. A VoIP provider with thousands of registered endpoints will normally see a high volume of INVITE packets during peak calling hours. The attack traffic looks identical to legitimate traffic at the network layer. You cannot simply rate-limit all traffic to port 5060 without destroying the service for real users.

SIP REGISTER Storms

REGISTER storms target the SIP registrar rather than the call routing layer. Every SIP endpoint (desk phones, softphones, mobile apps, ATAs) periodically sends REGISTER requests to maintain its registration with the SIP server. This is normal behavior, and the registration interval is typically 60 to 3600 seconds depending on the provider's configuration.

An attacker can flood the registrar with forged REGISTER requests using spoofed or randomized credentials. Each REGISTER requires the server to perform a database lookup to validate the credentials, compute a digest authentication response, and update or reject the registration. Under a REGISTER storm, the database and authentication layer become the bottleneck.

The downstream effects are severe. Legitimate endpoints cannot re-register when their registration expires, so they gradually become unreachable. Inbound calls to those endpoints fail. The registrar's authentication database may become overloaded, affecting all services that depend on it. In multi-tenant environments, a REGISTER storm targeting one customer's range can degrade registration for every customer on the platform.

Some REGISTER storms also use valid but stolen credentials, making them even harder to distinguish from legitimate traffic. These attacks often originate from botnets that have harvested SIP credentials from compromised endpoints or configuration files.

RTP Media Stream Disruption

While SIP handles call signaling, RTP (Real-time Transport Protocol) carries the actual audio and video media. RTP streams use UDP on dynamic port ranges, and they are inherently vulnerable to disruption because UDP provides no congestion control or delivery guarantees.

Attackers can target RTP streams in several ways:

• Port range flooding: Sending a high volume of UDP traffic to the RTP port range (commonly 10000 to 20000) overwhelms the media gateway and degrades audio quality for all active calls simultaneously.
• RTP injection: If the attacker can guess or sniff the SSRC (synchronization source identifier) and sequence numbers of an active RTP stream, they can inject packets that cause audio artifacts, echo, or complete call disruption.
• Codec exhaustion: Sending RTP packets with computationally expensive codec payloads forces the media server to spend excessive CPU on transcoding, degrading all concurrent calls.

RTP disruption is particularly insidious because it affects call quality rather than call setup. Users experience crackling audio, one-way audio, or dropped calls, and the root cause is not immediately obvious to the operations team. The SIP signaling layer continues to function normally, so monitoring systems that only track SIP health will not detect the problem.

UDP Amplification on VoIP Ports

VoIP infrastructure is also vulnerable to reflected amplification attacks that abuse UDP-based protocols. An attacker spoofs the source IP of the VoIP provider and sends requests to open reflectors (DNS, NTP, SSDP, memcached, CLDAP). The amplified responses flood the provider's network, consuming bandwidth and overwhelming the VoIP infrastructure.

What makes amplification attacks particularly dangerous for VoIP providers is that the reflected traffic arrives as UDP on ports that may overlap with the provider's RTP range. Filtering reflected traffic without also filtering legitimate RTP is extremely difficult without deep packet inspection or protocol-aware detection.

A common scenario: an attacker launches a DNS amplification attack that delivers 5 Gbps of reflected DNS responses to a VoIP provider. The provider's upstream link is 10 Gbps. At the network level, there is still 5 Gbps of available capacity. But the flood of UDP packets destined for ports in the RTP range causes the media gateways to spend all their processing power discarding garbage packets, and call quality collapses.

Why Traditional Rate Limiting Kills Legitimate SIP Traffic

The most common response to a SIP flood is to rate-limit traffic to port 5060. This is almost always the wrong approach, and it frequently causes more damage than the attack itself.

Consider a VoIP provider serving 5,000 registered endpoints. During peak hours, legitimate SIP traffic to port 5060 might reach 3,000 to 5,000 transactions per second as users make and receive calls, transfer calls, send presence updates, and re-register. If you set a rate limit of 2,000 packets per second to "protect" against a flood, you are dropping legitimate call setup requests during peak hours even when there is no attack.

Worse, rate limiting is typically applied uniformly. It does not distinguish between a burst of legitimate INVITE requests from a large customer PBX and a flood of malicious INVITEs from a botnet. The legitimate PBX traffic gets dropped right alongside the attack traffic, causing call failures for your largest customers first (because they generate the most traffic).

Blanket rate limiting also interacts badly with SIP retry logic. When a SIP endpoint sends an INVITE and does not receive a response (because the response was rate-limited), it retransmits the INVITE after a timeout, typically 500 milliseconds for UDP. This means rate limiting actually increases the total packet rate as legitimate endpoints retry, creating a feedback loop that makes the congestion worse.

Per-Port Baseline Detection with Flowtriq

Flowtriq takes a fundamentally different approach. Instead of applying static rate limits, Flowtriq builds per-port traffic baselines that learn the normal behavior of each port on each monitored IP. The system knows what "normal" looks like for port 5060 on your SIP proxy at 2 PM on a Tuesday versus 3 AM on a Sunday.

When traffic to port 5060 deviates significantly from the established baseline, Flowtriq raises an alert. The key distinction is that the baseline is dynamic. If your VoIP platform is growing and call volumes increase 10% month over month, the baseline adapts automatically. You do not need to manually adjust thresholds as your business scales.

Flowtriq also monitors per-protocol baselines within each port. A spike in UDP traffic to port 5060 while TCP/TLS traffic on 5061 remains normal is a strong indicator of a SIP flood (since legitimate SIP traffic increasingly uses TLS). The system can correlate these signals to classify the attack vector with high confidence.

# Example: Flowtriq alert for SIP INVITE flood
{
  "alert_type": "anomaly",
  "target_ip": "203.0.113.10",
  "target_port": 5060,
  "protocol": "UDP",
  "current_pps": 48750,
  "baseline_pps": 3200,
  "deviation": "15.2x",
  "classification": "SIP Flood",
  "top_sources": [
    {"ip": "198.51.100.0/24", "pps": 12400},
    {"ip": "192.0.2.0/24", "pps": 9800},
    {"ip": "172.16.0.0/16", "pps": 8300}
  ],
  "active_calls_affected": 4280,
  "recommendation": "flowspec_block_sources"
}

The alert includes the current traffic rate, the baseline for comparison, the deviation multiplier, the classified attack vector, top source networks, and the number of active calls on the affected infrastructure. This gives your NOC team everything they need to make an informed mitigation decision in seconds.

Auto-Mitigation That Preserves Active Calls

When Flowtriq detects a SIP flood, it can trigger automatic mitigation through FlowSpec rules pushed to your upstream routers. But unlike blanket rate limiting, Flowtriq's mitigation is surgical. The system identifies the source networks generating the attack traffic and creates FlowSpec rules that block or rate-limit only those sources.

Legitimate SIP traffic from your registered endpoints continues to flow unimpeded. Active calls are not affected. New calls from legitimate sources succeed normally. The attack traffic is dropped at the network edge before it reaches your SIP infrastructure.

For attacks originating from many distributed sources (like a botnet-driven INVITE flood), Flowtriq can apply a more nuanced mitigation strategy:

• Source-based FlowSpec rules for the highest-volume attack sources, blocking their traffic entirely at the router level
• Protocol-aware rate limiting that reduces UDP/5060 traffic from unknown sources while preserving traffic from known IP ranges (your registered endpoint subnets, peering partners, SIP trunk providers)
• Geographic filtering when the attack originates from regions where you have no legitimate endpoints or customers

The mitigation rules are automatically withdrawn when the attack ends. Flowtriq continuously monitors the traffic and removes FlowSpec rules once the traffic returns to baseline levels. This prevents stale rules from blocking legitimate traffic hours or days after the attack has stopped.

PCAP Capture with SIP Dissection

When Flowtriq detects a SIP-related attack, the agent automatically captures a PCAP sample of the attack traffic. Unlike generic packet captures, Flowtriq's VoIP-aware PCAP capture includes SIP header dissection that extracts the critical fields your team needs for analysis:

• SIP Method: INVITE, REGISTER, OPTIONS, ACK, BYE, or other methods in the flood
• From/To headers: Whether the attacker is using randomized or targeted SIP URIs
• User-Agent: Many SIP flood tools use distinctive or missing User-Agent strings
• Call-ID patterns: Sequential or randomized Call-IDs indicate different flood tools
• Authentication behavior: Whether the flood includes credentials or sends unauthenticated requests

The PCAP is available directly in the Flowtriq dashboard incident view. You can download it for analysis in Wireshark or share it with your upstream provider as evidence when requesting upstream filtering or null-routing assistance.

# SIP INVITE flood sample (from Flowtriq PCAP)
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 198.51.100.44:5060;branch=z9hG4bK-randomhex
Max-Forwards: 70
From: "Unknown" <sip:[email protected]>;tag=random123
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060>
Content-Length: 0

This example shows a typical SIP INVITE flood packet. Notice the missing Content-Type header and zero Content-Length (no SDP body), which is a strong indicator of a flood tool rather than a legitimate SIP client. The From URI uses a generic "attacker" username. Legitimate clients include proper SDP bodies with codec negotiation, and their User-Agent strings identify the client software. These details are immediately visible in Flowtriq's PCAP dissection view.

Building a VoIP-Specific Mitigation Runbook

Every VoIP provider should have a documented runbook for DDoS response that accounts for the unique requirements of voice traffic. Here is a framework based on what we see working well across Flowtriq customers:

1. Detection (0 to 30 seconds): Flowtriq detects anomaly on port 5060 or the RTP port range. Alert fires to your NOC channel (Slack, PagerDuty, or both).
2. Classification (30 to 60 seconds): NOC reviews the Flowtriq alert to determine the attack vector. Is it a SIP INVITE flood, REGISTER storm, RTP disruption, or volumetric UDP flood?
3. Active call preservation (immediate): Before applying any mitigation, verify that auto-mitigation rules are targeting only attack sources. Flowtriq's source-based FlowSpec rules handle this automatically.
4. Escalation (if needed): If the attack exceeds your link capacity, engage your upstream transit provider or DDoS scrubbing service. Provide the Flowtriq PCAP and source network summary.
5. Customer communication: If call quality is affected, update your status page. Flowtriq can trigger status page updates automatically through webhook integrations.
6. Post-incident review: After the attack ends, review the full incident in the Flowtriq dashboard. Document the attack vector, duration, peak volume, mitigation effectiveness, and customer impact.

Flowtriq's auto-mitigation can handle steps 1 through 3 without human intervention. For many attacks, the NOC team reviews the incident after it has already been mitigated, rather than scrambling to respond during the attack.

Deployment Considerations for VoIP Networks

VoIP networks have specific architectural patterns that affect how you deploy Flowtriq for optimal coverage:

SBC Monitoring

Session Border Controllers sit at the network edge and handle all inbound SIP traffic. Deploying Flowtriq on the router or switch feeding your SBCs gives you visibility into attack traffic before it reaches the SBC. This is critical because once the SBC is overwhelmed, it cannot report its own health status reliably.

Media Gateway Coverage

Media gateways handle RTP transcoding and routing. They process high volumes of UDP traffic by design, so detecting anomalies requires per-port baselines that understand the normal RTP traffic patterns for each gateway. A gateway serving 2,000 concurrent calls will have very different baseline traffic than one serving 200.

Multi-Site Architectures

Most VoIP providers operate multiple points of presence for geographic redundancy. Flowtriq deploys an agent on each site's edge router, and all traffic data flows to the central dashboard for unified monitoring. This means your NOC has a single view across all sites and can correlate attacks that target multiple locations simultaneously.

Flowtriq protects VoIP infrastructure with per-port baseline detection, surgical auto-mitigation, and SIP-aware PCAP capture. Plans start at $9.99/node/month with no per-attack surcharges or bandwidth overage fees. Start your free trial and have your SIP infrastructure monitored in under 10 minutes.

Back to Blog

Related Articles