Protecting VoIP Infrastructure from DDoS:
SBCs, Media Gateways, and Cloud PBX

Back to Blog

The VoIP Attack Surface

A modern VoIP platform is not a single server. It is a multi-tier architecture where each component serves a distinct function, exposes different ports, and has different failure characteristics under DDoS attack. Protecting a VoIP platform requires understanding what each component does, how it can be attacked, and what happens to the overall service when that component is overwhelmed.

Most VoIP architectures include some variation of the following components:

• Session Border Controller (SBC): The network edge device that handles all inbound and outbound SIP signaling. It performs access control, topology hiding, protocol normalization, and often TLS termination for encrypted SIP.
• SIP Proxy / Registrar: Handles call routing logic and endpoint registration. Maintains the location database that maps SIP URIs to current endpoint IP addresses.
• Media Gateway: Converts media between different transport protocols (RTP to SRTP, different codecs, PSTN interworking). Handles the actual audio and video streams.
• Media Relay / TURN Server: Facilitates media flow for endpoints behind NAT or restrictive firewalls. Relays RTP streams between endpoints that cannot establish direct media paths.
• API Endpoints: REST or WebSocket APIs used for provisioning, call control, CDR retrieval, and integration with external systems. Increasingly common in cloud PBX and CPaaS platforms.
• Registration / Authentication Server: Validates SIP credentials and manages endpoint authentication. May be a dedicated service or integrated into the SIP proxy.

Each of these components has a different traffic profile, different capacity limits, and different attack vectors. A monitoring strategy that treats them all the same will miss attacks that target specific components.

Session Border Controllers: The Front Line

The SBC sits at the network edge and is the first component to receive inbound traffic. It is designed to handle high volumes of SIP signaling, but it has finite capacity. When the SBC fails, the entire platform goes dark for external callers.

Attack Vectors Against SBCs

SBCs are typically targeted with SIP INVITE floods, malformed SIP packet attacks, and TLS handshake exhaustion. A SIP INVITE flood overwhelms the SBC's call processing engine. Malformed SIP packets exploit parsing vulnerabilities or force the SBC to spend excessive CPU on error handling. TLS handshake floods target the SBC's encrypted SIP port (5061) because asymmetric cryptography is computationally expensive, and each new TLS handshake costs significantly more CPU than a plaintext SIP transaction.

Monitoring Strategy

Deploy Flowtriq on the router or switch upstream of your SBCs. This gives you visibility into traffic before it reaches the SBC, which is critical because once the SBC is overwhelmed, it cannot reliably report its own status. Monitor the following per-port baselines:

• UDP/5060: Plaintext SIP signaling. Baseline should reflect your normal call setup rate with appropriate diurnal variation.
• TCP/5061 and TLS/5061: Encrypted SIP. Monitor both connection rate (new TCP SYNs) and data volume. A TLS exhaustion attack shows as a spike in new connections with minimal data exchange per connection.
• ICMP: ICMP floods targeting the SBC IP can overwhelm the kernel network stack even if the SBC application ignores ICMP.

SIP Proxy and Registration Servers

The SIP proxy handles call routing decisions, and the registrar maintains the endpoint location database. In many deployments, these functions run on the same server (Kamailio, OpenSIPS, and similar platforms combine proxy and registrar roles). These servers are typically behind the SBC and not directly exposed to the internet, but they can still be attacked through the SBC if the SBC's access control is not filtering effectively.

Attack Vectors

REGISTER storms are the primary threat. Each REGISTER request requires a database lookup and authentication computation. Under a REGISTER storm, the authentication backend becomes the bottleneck. If the backend is a shared database (MySQL, PostgreSQL, Redis), the overload can affect other services that depend on the same database.

Call routing exhaustion is another vector. The attacker sends INVITE requests with destination URIs that trigger complex routing lookups, such as least-cost routing calculations, number portability database queries, or forwarding chain resolution. The goal is to maximize the CPU cost per INVITE by exploiting routing logic complexity.

Monitoring Strategy

Monitor the traffic between the SBC and the SIP proxy on whatever internal network they communicate over. Even though this is internal traffic, Flowtriq can build baselines for the internal SIP signaling rate and detect when the SBC is forwarding an abnormal volume of requests. A spike in internal SIP traffic when external traffic is also elevated is a strong indicator that the SBC's access control is not adequately filtering the attack.

Media Gateways and Transcoding

Media gateways handle the heavy lifting of audio and video processing. They receive RTP streams, transcode between codecs, mix conference audio, and route media between endpoints. Media gateways are CPU-intensive by design and have relatively tight headroom compared to signaling components.

Attack Vectors

RTP port range flooding is the most direct attack. Media gateways listen on wide UDP port ranges (commonly 10000 to 20000 or even wider) for RTP media. An attacker flooding this port range with UDP traffic forces the gateway to inspect and discard each packet, consuming CPU that should be used for legitimate media processing.

Codec exhaustion attacks send RTP packets with computationally expensive codec payloads. If the media gateway attempts to decode or transcode these packets, each attack packet consumes significantly more CPU than a typical G.711 or Opus packet.

Monitoring Strategy

Media gateways have the most variable traffic patterns of any VoIP component. A gateway handling 1,000 concurrent calls generates substantially different traffic than the same gateway during off-peak hours. Flowtriq's per-port baselines handle this automatically, but you should ensure the baseline learning period captures at least one full business week to account for weekday/weekend and peak/off-peak variations.

# Flowtriq per-component monitoring configuration
# Deploy agents on edge routers feeding each component tier

SBC Tier (router: edge-sbc-01)
  Monitor: UDP/5060, TCP/5061, ICMP
  Baseline: 7-day rolling, per-port
  Auto-mitigation: FlowSpec to upstream, preserve registered endpoint IPs

Media Gateway Tier (router: edge-media-01)
  Monitor: UDP/10000-20000 (aggregate), per-gateway IP
  Baseline: 7-day rolling, per-IP per-port-range
  Auto-mitigation: FlowSpec source-block, preserve active RTP flows

Registration Server Tier (internal switch: sw-core-01)
  Monitor: Internal SIP traffic between SBC and registrar
  Baseline: 7-day rolling
  Auto-mitigation: Alert NOC (no auto-FlowSpec on internal segments)

API Tier (router: edge-api-01)
  Monitor: TCP/443, TCP/8443
  Baseline: 7-day rolling, per-endpoint
  Auto-mitigation: FlowSpec rate-limit, preserve authenticated sessions

Media Relays and TURN Servers

Media relays and TURN servers are necessary for endpoints behind NAT or restrictive firewalls. They relay RTP streams between endpoints that cannot establish direct media paths. These servers handle high volumes of UDP traffic by design, making it difficult to distinguish attack traffic from legitimate relayed media.

The key monitoring metric for media relays is the ratio of allocated sessions to traffic volume. A TURN server with 500 allocated sessions should be handling a predictable amount of RTP traffic per session. If the total traffic volume spikes without a corresponding increase in allocated sessions, the excess traffic is likely attack traffic rather than legitimate relayed media.

Flowtriq monitors the overall traffic profile per relay server IP and detects when traffic deviates from the per-session baseline. This works even without application-layer session awareness because the network traffic patterns are sufficiently distinctive.

Cloud PBX and API Endpoint Protection

Modern cloud PBX platforms and CPaaS (Communications Platform as a Service) providers expose REST APIs for call control, provisioning, and real-time events. These API endpoints are increasingly targeted by DDoS attacks, both as a way to disrupt the management plane and as a way to exhaust shared infrastructure resources.

API endpoints face HTTP flood attacks (high-rate GET/POST requests), credential stuffing against authentication endpoints, and WebSocket exhaustion for real-time event APIs. These attacks may use valid API keys stolen from compromised customer applications, making them harder to distinguish from legitimate API traffic.

Flowtriq monitors TCP traffic to API ports (typically 443 or custom ports) and builds baselines for connection rates, request rates, and traffic volume. A spike in new TCP connections to your API endpoint without a corresponding increase in legitimate API usage is an early indicator of an HTTP flood or credential stuffing attack.

VoIP Runbook Examples

A well-documented runbook transforms your DDoS response from reactive scrambling into a structured process. Here are three runbook templates tailored to VoIP-specific scenarios:

Runbook 1: SIP Flood on SBC

1. Trigger: Flowtriq alert on UDP/5060 deviation > 5x baseline on SBC-facing router
2. Auto-mitigation: Flowtriq pushes FlowSpec rules blocking top-5 source /24 networks while preserving traffic from registered endpoint subnets
3. NOC action: Verify auto-mitigation is effective (check if SBC call processing has recovered). If attack continues above threshold, escalate to upstream transit provider with Flowtriq PCAP evidence
4. Customer communication: If call quality was affected for more than 60 seconds, post update to status page via webhook integration
5. Active call preservation: Flowtriq's source-based blocking ensures existing calls are not disrupted. Verify by checking concurrent call count on the SBC management interface
6. Post-incident: Review full incident in Flowtriq dashboard within 24 hours. Update FlowSpec whitelist if any legitimate sources were affected

Runbook 2: RTP Port Range Flood on Media Gateways

1. Trigger: Flowtriq alert on UDP/10000-20000 aggregate deviation > 3x baseline on media gateway segment
2. Auto-mitigation: FlowSpec source-block for identified attack sources. Rate-limit UDP from unknown sources to the port range while preserving traffic from SBC source IPs (which is where legitimate RTP originates in most architectures)
3. NOC action: Monitor call quality metrics (MOS scores if available) to assess customer impact. If media gateways are still degraded after source blocking, consider activating standby gateway capacity
4. Customer communication: Proactively notify enterprise customers with dedicated media gateways if their gateway is affected
5. Post-incident: Analyze whether the attack targeted specific gateway IPs or the entire media tier. Review media gateway capacity planning

Runbook 3: TDoS / Automated Call Flood

1. Trigger: Flowtriq alert on elevated new flow creation rate to port 5060 with high source diversity and inverted signaling-to-media ratio
2. Auto-mitigation: Source network rate-limiting via FlowSpec for the highest-volume originating networks. Geographic filtering if the attack originates from regions outside your service area
3. NOC action: Review PCAP for SIP INVITE patterns (caller ID diversity, User-Agent strings, presence of SDP body) to confirm TDoS vs. flash crowd. Contact SIP trunk providers if attack is transiting their networks
4. Regulatory check: If the attack targets emergency services trunks (911 connectivity), initiate FCC NORS reporting process and notify local PSAP coordinators
5. Post-incident: File IC3 report with PCAP evidence. Review SIP access control rules to determine if additional filtering at the SBC layer would reduce future exposure

Status Pages for Voice Service Customers

VoIP customers are extremely sensitive to service disruptions. A web application that loads slowly is frustrating. A phone system that drops calls is a business emergency. Your status page strategy for voice services needs to reflect this urgency.

Flowtriq integrates with status page platforms (Statuspage, Instatus, Cachet, and custom solutions) through webhook notifications. When Flowtriq detects an attack that affects call quality, it can automatically update your status page component status from "Operational" to "Degraded Performance" or "Partial Outage."

For VoIP providers, we recommend separate status page components for:

• SIP Signaling: Reflects the health of your SBC and SIP proxy tier. If new calls cannot be established, this component shows as degraded.
• Voice Quality: Reflects the health of your media gateway tier. If calls are connected but audio quality is poor, this component shows as degraded while SIP Signaling may still show operational.
• API / Management: Reflects the health of your provisioning and call control APIs. This may be degraded independently of voice services.
• Per-region components: If you operate multiple PoPs, separate components per region let customers quickly determine if their location is affected.

Automated status page updates ensure your customers learn about issues from your status page rather than from their own users calling to complain. This builds trust and reduces support ticket volume during incidents.

Deploying Flowtriq Across a Multi-Tier VoIP Architecture

Here is a practical deployment guide for a typical three-tier VoIP architecture:

Step 1: Identify Monitoring Points

For each tier (SBC, media gateway, API), identify the router or switch where you can deploy the Flowtriq agent. The agent needs to see traffic before it reaches the component it is protecting. For edge-facing components, this is the upstream edge router. For internal components, this is the core switch or router connecting the component to the rest of the network.

Step 2: Deploy Agents

Install the Flowtriq agent on each monitoring point. The agent runs as a lightweight daemon that captures NetFlow/sFlow/IPFIX data from the router or uses eBPF-based packet sampling on Linux-based routers and switches. Installation takes under 5 minutes per node.

Step 3: Baseline Learning

Allow 7 days for the baseline engine to learn normal traffic patterns for each port and IP combination. During this period, Flowtriq operates in monitor-only mode and does not trigger auto-mitigation. You can review the baseline data in the dashboard to verify that the baselines are converging correctly.

Step 4: Configure Auto-Mitigation Rules

Define per-tier mitigation rules that account for VoIP-specific requirements. At minimum, configure FlowSpec source-blocking for the SBC tier and media gateway tier, with whitelists for registered endpoint subnets and SIP trunk provider IPs.

Step 5: Integrate Alerting and Status Pages

Connect Flowtriq to your NOC alerting channels (Slack, PagerDuty, email) and your status page platform. Configure severity routing so that critical alerts page the on-call engineer while info events go to the monitoring channel.

Protecting a VoIP platform from DDoS requires per-component monitoring that understands the unique traffic patterns of each architectural tier. Flowtriq delivers this with per-port baselines, surgical auto-mitigation, and VoIP-aware alerting. Plans start at $9.99/node/month. Start your free trial and deploy across your entire VoIP architecture today.

Back to Blog

Related Articles