Anatomy of a SIP Flood
A SIP flood is conceptually simple: send enough SIP requests to a target that it can no longer process legitimate call signalling. In practice, the attack exploits specific properties of the SIP protocol that make it disproportionately expensive for the receiver to handle.
SIP is a text-based protocol. Every message must be parsed character by character to extract headers, validate syntax, and route the request. A single SIP INVITE message can be 800 to 1,500 bytes of structured text containing Via, From, To, Call-ID, CSeq, Contact, and SDP body headers. The receiving SBC or proxy must parse all of this, allocate session state, perform authentication lookups, and generate a response. The computational cost per message is orders of magnitude higher than handling a raw UDP packet.
This asymmetry is the core of the attack. The attacker generates SIP messages at wire speed using a simple packet generator. The target must perform expensive per-message processing. At 50,000 packets per second of SIP INVITE requests, even a well-provisioned SBC will exhaust its CPU parsing and processing messages before the network link saturates.
Flood Variants: OPTIONS, REGISTER, and INVITE
OPTIONS Floods
SIP OPTIONS requests are used for capability probing and keepalive monitoring. They are lightweight by design, but the server must still parse the request and generate a 200 OK response. Because OPTIONS requests do not create call state, they bypass many SBC security policies that only inspect INVITE transactions. Attackers exploit this by flooding the SBC with OPTIONS requests at rates exceeding 100,000 per second, consuming CPU on parsing and response generation without ever triggering call-level security controls.
REGISTER Floods
REGISTER floods target the authentication subsystem. Each REGISTER request triggers a digest authentication challenge, which requires the registrar to generate a nonce, wait for the client response, and perform a database lookup to validate credentials. Spoofed REGISTER requests with random credentials force the registrar to process authentication for endpoints that do not exist, filling the authentication pipeline and blocking legitimate registrations.
INVITE Floods
INVITE floods are the most resource-intensive for the target. Each INVITE creates a dialog, allocates media resources, triggers routing lookups, and may generate calls to downstream gateways. A flood of INVITEs can exhaust call state tables, media port pools, and downstream trunk capacity simultaneously. Even if the calls are never answered, the SBC must maintain the transaction state through the full timeout period.
# Typical SIP flood detection signatures Port: UDP 5060 or TCP 5060/5061 Rate: > 10,000 SIP requests/sec (baseline-dependent) Pattern: High ratio of single-method requests (e.g., 99% OPTIONS) Source: High source IP diversity with low registration state Headers: Randomized Call-ID, missing or malformed Via headers Payload: Repeated identical SDP bodies across different Call-IDs Timing: No inter-request delay (machine-gun pattern)
Why Firewalls and SBCs Struggle
The standard response to SIP floods is to rely on the Session Border Controller's built-in rate limiting or the network firewall. Both approaches have significant limitations at attack scale.
Firewall limitations: Traditional firewalls perform stateful packet inspection. They track UDP "connections" by source/destination IP and port tuples. A SIP flood from a botnet with 10,000 source IPs creates 10,000 separate state table entries, each below any per-source rate limit. The firewall sees each source as a low-rate sender even though the aggregate rate is devastating. Firewalls that attempt deep packet inspection of SIP at high packet rates either drop packets (causing legitimate call failures) or fail open (passing the flood through).
SBC limitations: SBCs are designed to process SIP, not to defend against floods. Their rate-limiting capabilities are built for traffic management, not DDoS defense. An SBC that rate-limits to 1,000 transactions per second to protect itself will also drop legitimate calls during an attack. The SBC cannot distinguish attack traffic from legitimate traffic when both use valid SIP syntax. Worse, the rate-limiting logic itself consumes CPU, and at extreme packet rates, the SBC's packet processing pipeline may collapse before the rate limiter can act.
The fundamental problem: firewalls operate at Layer 3-4 and cannot parse SIP efficiently at flood rates. SBCs operate at Layer 7 but are not sized for adversarial traffic volumes. Effective SIP flood defense requires a system that bridges both layers.
Detection: What to Look For
Detecting SIP floods requires monitoring multiple signals simultaneously. No single metric reliably distinguishes a SIP flood from a legitimate traffic spike. The combination of signals, however, creates a clear detection fingerprint.
- PPS on ports 5060/5061: The most direct signal. Baseline your normal SIP transaction rate and alert on deviations. A 5x increase in packets per second on port 5060 with no corresponding increase in successfully established calls is a strong flood indicator.
- Source diversity ratio: During normal operation, SIP traffic comes from a relatively stable set of source IPs (registered endpoints, peering partners, trunk providers). A sudden increase in unique source IPs sending SIP traffic indicates a distributed flood.
- Method distribution skew: Normal SIP traffic has a mixed distribution of methods (INVITE, ACK, BYE, REGISTER, OPTIONS). A flood typically uses a single method. If OPTIONS requests suddenly constitute 95% of SIP traffic when the baseline is 15%, that is an attack.
- Failed authentication rate: A spike in 401/407 authentication challenges with no subsequent valid credential responses indicates a REGISTER flood with spoofed credentials.
- Transaction completion ratio: Legitimate INVITEs produce a predictable ratio of 100 Trying, 180 Ringing, and 200 OK responses. A flood of INVITEs with near-zero 200 OK responses means none of the "calls" are completing.
Mitigation: nftables Rules That Target Patterns, Not Ports
Blocking port 5060 entirely will stop the flood and also kill your phone system. Effective mitigation must be surgical: drop attack traffic while passing legitimate SIP transactions. This requires pattern-based rules rather than port-based rules.
# nftables: rate-limit new SIP sources while allowing established peers
table inet sip_defense {
set trusted_sip_peers {
type ipv4_addr
flags interval
# Populate with known trunk/peer IPs
elements = { 203.0.113.0/24, 198.51.100.0/24 }
}
set new_sip_sources {
type ipv4_addr
size 65536
flags dynamic,timeout
timeout 60s
}
chain input {
type filter hook input priority -10; policy accept;
# Always allow trusted SIP peers
udp dport 5060 ip saddr @trusted_sip_peers accept
# Rate-limit unknown sources on SIP ports
udp dport 5060 ip saddr != @trusted_sip_peers \
add @new_sip_sources { ip saddr limit rate 20/second } accept
# Drop excess from unknown sources
udp dport 5060 ip saddr != @trusted_sip_peers drop
}
}
The key principle is allowlisting known SIP peers (trunk providers, registered endpoints, peering partners) and applying aggressive rate limits only to unknown sources. This preserves legitimate call traffic while throttling flood sources. The dynamic set automatically expires entries after 60 seconds, preventing state exhaustion on the firewall itself.
Port-Aware Detection with Flowtriq
Flowtriq's agent-based approach is purpose-built for this problem. The agent runs on the SBC or media gateway and classifies traffic by service port. It maintains separate baselines for SIP signalling ports (5060/5061), RTP media ports (dynamic range), and management interfaces. When a SIP flood hits, the agent detects the anomaly on the signalling ports specifically and triggers mitigation rules that target the attack without disrupting media streams on other ports.
Because the agent sees traffic at the server level, it detects low-rate application-layer SIP floods that network-level monitoring systems miss. A flood of 5,000 malformed REGISTER requests per second might not register as anomalous on a 10 Gbps link, but it will immediately spike the SBC's SIP transaction baseline and trigger an alert within seconds.
Stop SIP floods before calls drop. Flowtriq's port-aware detection identifies SIP-targeted attacks in seconds and applies surgical mitigation that preserves legitimate voice traffic. Learn about VoIP protection or calculate your DDoS risk.