DDoS protection for live
streaming and media platforms

Back to Blog

Why Live Streaming Is Targeted

Live streaming platforms present a uniquely attractive target for DDoS attacks because the impact is immediate, visible, and impossible to hide. When a web application experiences degradation, the operator can display a maintenance page, queue requests, or serve cached content. When a live stream goes down, tens of thousands of viewers see it fail simultaneously, social media fills with complaints within seconds, and the damage to the brand is public and permanent. This visibility is exactly what attackers want, whether their goal is extortion, competitive sabotage, or political censorship.

Competitive sabotage during esports events is one of the most common motivations. Professional esports tournaments with prize pools exceeding $1 million attract millions of concurrent viewers. A competitor's stream going down during a tournament final drives viewers to alternative streams. Even a 60-second interruption can shift tens of thousands of viewers permanently. The financial incentive for sabotage is real, and the tools to execute it are cheap: booter services capable of generating 100+ Gbps floods cost less than $50.

Political censorship targets live streams of protests, political debates, and independent journalism. State-affiliated actors and hacktivists alike use DDoS to silence streams that broadcast content they oppose. During contested elections, live streams from independent monitors have been targeted with sustained multi-day attacks designed to keep them offline through the entire voting period.

Extortion during pay-per-view events is straightforward: the attacker contacts the streaming platform before a major event and demands payment, threatening to disrupt the stream during the main event. Pay-per-view events have fixed schedules and cannot be postponed. A boxing match or concert that was supposed to stream at 9 PM cannot be rescheduled to 10 PM because the DDoS is still active. The platform either pays, absorbs the attack, or loses the event. This time pressure makes pay-per-view platforms especially vulnerable to extortion.

The Unique Challenge of Real-Time Delivery

Live streaming has characteristics that make DDoS defense fundamentally harder than protecting typical web applications. The first challenge is bandwidth. A single live stream at 1080p 60fps with multiple quality tiers (1080p, 720p, 480p, audio-only) consumes 15 to 25 Mbps of outbound bandwidth from the origin server per CDN edge node pulling the stream. With 50 CDN edge nodes pulling simultaneously, the origin needs 750 Mbps to 1.25 Gbps of sustained outbound bandwidth during normal operations. This already-high legitimate bandwidth makes it harder to distinguish attack traffic from normal operations.

The second challenge is latency sensitivity. Unlike video on demand, where the player can buffer 30 seconds ahead and absorb network hiccups, live streams operate with buffers of 2 to 10 seconds. Any disruption longer than the buffer duration causes visible playback interruption for every viewer simultaneously. Low-latency streaming protocols (WebRTC, SRT in low-latency mode) reduce this buffer to under one second, meaning even brief network disruptions become visible.

The third challenge is the single point of failure at the origin. CDNs distribute viewer traffic across edge nodes worldwide, but every edge node ultimately pulls the stream from the origin server (or a small number of origin servers). If the origin goes down or becomes unreachable, no amount of CDN capacity helps. The edge nodes have nothing to serve. Within seconds, every viewer worldwide experiences a playback failure.

Attack Vectors for Streaming Infrastructure

Origin Server Floods

The most direct attack targets the origin server's IP address with a volumetric UDP or TCP SYN flood. If the attacker knows the origin IP (which is often discoverable through DNS history, SSL certificate transparency logs, or probing CDN bypass paths), they can flood the origin's uplink directly. The CDN is irrelevant in this scenario because the attack bypasses it entirely. A 10 Gbps UDP flood against an origin server on a 1 Gbps uplink saturates the link completely, killing both the stream and any management access to the server.

DNS Attacks on Streaming Domains

If the attacker cannot find the origin IP, they target the DNS infrastructure that resolves the streaming domain. A DNS flood or water torture attack against the authoritative DNS servers for stream.example.com prevents CDN edge nodes from resolving the origin's hostname, prevents viewers' browsers from resolving the player page, and prevents API calls from reaching the authentication backend. DNS attacks are particularly effective against streaming because the entire delivery chain depends on DNS working correctly.

UDP Floods Targeting Media Servers

Media servers that handle ingest (receiving the stream from the broadcaster) and transcoding often run on UDP-heavy protocols. SRT uses UDP. RTMP uses TCP, but many deployments front it with UDP-based SRT or RIST for better performance over lossy networks. A UDP flood targeting the ingest server's media ports disrupts the incoming stream at its source. If the broadcaster cannot push their stream to the ingest server, there is nothing for the CDN to deliver.

TCP State Exhaustion on Ingest Servers

Ingest servers that accept RTMP connections maintain TCP state for each incoming stream. A SYN flood or slow connection attack that exhausts the ingest server's TCP connection table prevents new streams from connecting. For platforms that host thousands of simultaneous streamers, an attack that fills the connection table with half-open connections takes every streamer offline simultaneously.

CDN Limitations for Streaming Protection

CDNs are essential for streaming delivery, but they provide incomplete DDoS protection. A CDN absorbs viewer-side traffic: millions of viewers pulling the stream from edge nodes never touch the origin. This protects the origin from legitimate demand, which is valuable. But CDNs do not protect the origin from direct attacks that bypass the CDN, and they do not protect the ingest infrastructure at all.

Most CDN-based DDoS protection is designed for HTTP/HTTPS traffic. It analyzes HTTP request patterns, applies WAF rules, and challenges suspicious clients with CAPTCHAs or JavaScript challenges. Streaming protocols do not fit this model. An RTMP ingest connection is a long-lived TCP connection carrying binary video data. A SRT ingest is a UDP stream. Neither can be challenged with a CAPTCHA. CDN DDoS protection at the viewer edge works well (blocking malicious viewers), but the real vulnerability is the infrastructure behind the CDN.

CDN origin shielding (a mid-tier cache layer between edge nodes and the origin) reduces the number of direct connections to the origin but does not eliminate them. And origin shielding adds latency, which is counterproductive for low-latency streaming.

Protecting Ingest Infrastructure

The ingest layer is the most critical and least protected component of a streaming platform. It must accept incoming streams from broadcasters, which means it must be reachable on specific ports (1935 for RTMP, a configured range for SRT). Protecting ingest requires multiple strategies working together.

IP allowlisting: Restrict ingest server access to known broadcaster IPs. For platforms where broadcasters stream from fixed locations (studios, production facilities), this is straightforward. For platforms where broadcasters stream from mobile devices or home connections with dynamic IPs, this requires an authentication proxy that validates the broadcaster before revealing the actual ingest IP.

Ingest IP rotation: Assign each broadcaster a unique ingest IP that is generated at stream creation time and is only valid for the duration of the stream. The broadcaster receives the ingest endpoint via an authenticated API call. An attacker who does not have access to the API cannot discover the ingest IP. After the stream ends, the IP is returned to the pool and reassigned.

Network-level detection: Deploy monitoring on ingest servers to detect volumetric anomalies in real time. A Flowtriq agent on each ingest server tracks packets per second and bytes per second with one-second granularity. When an ingest server that normally handles 500 Mbps of incoming stream data suddenly receives 5 Gbps of UDP traffic, the agent detects the anomaly within seconds. This detection can trigger automated upstream mitigation via BGP FlowSpec or notify the NOC for manual intervention.

# Monitor ingest server network counters
# Track packets/sec and bytes/sec on the primary interface
while true; do
  T1=$(date +%s%N)
  R1=$(awk '/eth0:/{print $2,$3}' /proc/net/dev)
  sleep 1
  T2=$(date +%s%N)
  R2=$(awk '/eth0:/{print $2,$3}' /proc/net/dev)
  BYTES=$(($(echo $R2 | cut -d' ' -f1) - $(echo $R1 | cut -d' ' -f1)))
  PKTS=$(($(echo $R2 | cut -d' ' -f2) - $(echo $R1 | cut -d' ' -f2)))
  echo "$(date): ${BYTES} bytes/sec, ${PKTS} pps"
done

RTMP, SRT, and WebRTC Considerations

RTMP (Real-Time Messaging Protocol) runs over TCP on port 1935. It is the most common ingest protocol, used by OBS, Streamlabs, and most broadcasting software. Because it uses TCP, RTMP ingest servers are vulnerable to SYN floods and TCP state exhaustion attacks. SYN cookies at the kernel level mitigate the SYN flood component, but slow-read and slow-write attacks (analogous to Slowloris) can still exhaust connection slots by holding TCP connections open without sending stream data.

SRT (Secure Reliable Transport) runs over UDP with its own reliability layer. SRT is increasingly popular for professional broadcasting because it handles packet loss and jitter better than RTMP over long-distance connections. However, SRT's use of UDP makes it vulnerable to the same UDP flood attacks that target any UDP service. Because SRT runs on a configured port (typically 9000 or in the 9000-9999 range), an attacker who discovers the port can flood it directly. SRT's built-in handshake mechanism provides some protection against spoofed sources, but a volumetric flood that saturates the link upstream of the server bypasses any application-level protection.

WebRTC (Web Real-Time Communication) uses DTLS over UDP for media transport, with ICE/STUN/TURN for NAT traversal. WebRTC-based streaming platforms (used for sub-second latency applications like live auctions and interactive broadcasts) have a complex attack surface. TURN servers that relay media are UDP services vulnerable to volumetric floods. STUN servers can be abused as minor amplification reflectors. The signaling layer (typically WebSocket over HTTPS) is vulnerable to connection exhaustion. Protecting WebRTC streaming requires monitoring multiple protocol layers simultaneously.

Pre-Event Preparation Checklist

Major live events (esports tournaments, product launches, pay-per-view broadcasts, election coverage) are the highest-risk windows for streaming platforms. The following checklist should be completed before every major event:

• Origin IP hygiene: Verify that origin server IPs are not exposed in DNS history, certificate transparency logs, or application responses. Rotate origin IPs before high-profile events if there is any risk of exposure.
• CDN configuration audit: Confirm that CDN origin pull is configured to connect via authenticated origin shield, not directly to the origin IP. Test failover to a secondary origin.
• Ingest endpoint isolation: Assign fresh ingest IPs for the event. Distribute ingest credentials to broadcasters through a secure channel no more than 24 hours before the event.
• Detection thresholds: Review and tighten detection thresholds on all streaming infrastructure nodes. A threshold that is appropriate for normal daily traffic may be too permissive during a high-profile event when attack likelihood is elevated.
• Upstream coordination: Contact your transit provider and scrubbing service to notify them of the event schedule and expected traffic volumes. Pre-authorize emergency mitigation measures so that on-call NOC staff can activate them without management approval.
• Redundancy verification: Test failover from primary to secondary ingest, transcoding, and origin servers. Verify that DNS TTLs on streaming endpoints are low enough to allow rapid failover (60 seconds or less).
• War room staffing: Ensure network operations staff are actively monitoring during the event, not relying solely on automated alerting. Automated detection provides the first signal; a human must be ready to act on it.
• Communication plan: Prepare holding statements for social media and viewer-facing status pages. If an attack disrupts the stream, a rapid acknowledgment reduces panic and buys time for mitigation.

The best time to test your DDoS defense is before the event. The worst time to discover your origin IP is exposed is during a championship final with 500,000 concurrent viewers.

Back to Blog

Related Articles