Protection against DDoS attacks 2026: a comparison of strategies, detection and checklist for SOC

Depov

Activist
ULTIMATE
SUPREME
PREMIUM
MEMBER
Joined
Feb 18, 2025
Messages
126
Reaction score
115
Deposit
0$
Morning. Grafana shows 340 Gbps inbound UDP traffic on the border routers of the fintech company, where six months ago adjusted echeloned protection. Ordinary baseline - 12 Gbps. The SOC-on-duty classifies NTP reflection/amplification of four ANS, in a couple of minutes switches traffic to a cloud scrupbin center. The channel was restored after another 20 minutes. And after another 20 minutes - the second altrate: WAF fixes 2400 rps on the authorization endpoint. The L7-vector started exactly when the team was dismantling a volumetric incident. For 55 minutes of partial downtime - unfinished transactions for millions of rubles and postmortem for a week.

According to industry reports for 2025, more than half of DDoS attacks are already multi-vector, and the largest botnets have millions of IP addresses. It is the second vector - the one that arrives while everyone cleans the first - breaks beautiful plans. Below is a comparison of the DDoS mitigation strategy 2026, correlation rules for SIEM and checklist so that SOC does not miss this second blow.
Business logic DDoS: why attack and how much it costs a simple
DDoS (distributed denial-of-service attack) is an impact-tactical technique in MITRE ATT&CK. Attackers use it not only in order to “put the site”. Four main motives in 2026:
1. Extortion (Ransom DDoS) - the attack begins with a threat, a ransom in cryptocurrency is required. The entry threshold decreased due to DDoS-as-a-Service platforms: according to Ideco, by 2024, commercial platforms appeared with support for multi-vector attacks for several hundred dollars. Literally - subscription is cheaper than Netflix.
2. The smoke screen - a volumetric attack distracts SOC, while in parallel there is a vulnerability operation or data extillation. According to Mandiant M-Trends 2025, exploits remain the most popular source of initial access (38% of incidents), and DDoS often masks this stage.
3. Hftactivism is a politically motivated attack on government services and critical infrastructure. According to the IBM X-Force Thread Intelligence Index 2025, 70% of the recorded incidents affected critical infrastructure.
4. Competitive sabotage - the failure of the services of a competitor during the peak period. Black Friday, sales, launching a new product is a classic window.
Financial damage consists of direct losses (unfinished transactions, SLA-fines) and indirect (reputation, outflow of customers, costs of incident response). For organizations processing personal data, DDoS with parallel leaks is fraught with negotiable fines. Anti-DDoS solutions for business are not an item of expenditure, but insurance. The question is which protection strategy against DDoS attacks to choose for a specific architecture and budget.
DDoS-techniques in terms of MITRE ATT&CK
For SOC engineer, the mapping DDoS technician on MITRE ATT&CK is the foundation of correlation rules and playbooks. In the matrix ATT&CK DDoS is sold in two techniques: Network Denial of Service (T1498, Impact) and Endpoint Denial of Service (T1499, Impact), with subtechnics for specific vectors.
1781474115072.png

T1583.005 (Botnet) - Resource Development tactics, a preparatory stage on the attacker's side. For the defender, he is invisible (botnet is not collected from you). But you can see the other - sensing queries: short bursts of different types of traffic to different ports. This is the phase of reconnaissance, the manned on T1595 (Active Scanning, Reconnaissance tactic). According to industry data, the number of such probing attacks in 2024-2025 increased markedly. SOC, which captures sensing and raises the readiness threshold in advance, receives a critical advantage in reaction time. The difference between "saw in 3 minutes" and "saw in 30 seconds" is the difference between downtime and regular workout.

Multi-vector attack from postmortem at the beginning of the article - combination T1498.002 (NTP reflection) on L3/L4 and T1499.003 (Application Exhaustion Flood) on L7. If SIEM is set to adjust these two techniques as a single incident, the reaction time is reduced multiple times.
DDoS MILAC Strategy: Comparison of 2026 Approaches
Selection criteria
The Russian-speaking market already has a detailed DDoS protection comparison of services according to 180 criteria (anti-malware.ru, 2026). Here the task is another: to compare architectural strategies to counter DDoS at the network level, because it is the choice of strategy that determines the decision class. Not "which vendor is better," but "what approach fits your architecture."

Four approaches: cloud traffic scrupbing, on-premise appliance, a hybrid model "three layers" (detectic + on-network filtering + upstream/edge scrupbbing, as described by Kentik), and BGP blackholing as an emergency measure.

In the category of cloud scrubbing in the Russian market: DDoS-Guard, StormWall, CURATOR.ANTIDDOS (Qrator), Kaspersky DDoS Protection, Garda Anti-DDoS. In the on-premise segment: Arbor Sightline/TMS (NETSCOUT), Radware DefensePro, F5 BIG-IP AFM. Cloudflare Magic Transit and AWS Shield Advanced are available, but with data localization clauses.
Trade-off: cloud protection vs on-premise vs hybrid
1781474097341.png

On-premise appliance will choke at a volumetric attack that exceeds the capacity of the channel. Arbor for several hundred thousand dollars is useless at 500 Gbps on the 10 Gbps channel - arithmetic is merciless. BGP blackholing is formally “working”, but the attacker achieves the goal: legitimate traffic is also blocked. Cloud scrubbing depends on the vendor - if its scrupbing center is overloaded or my disconfigured, you do not control it. Every approach has a hole, and honesty in this is the first step towards normal architecture.

Behavioral Detection (behavioral-based mitigation), described by Radware, is built on deviations from normal traffic patterns - not static thresholds, but an ML-model trained on a specific client baseline. Such models are built into Radware DefensePro and Arbor Sightline. For cloud providers, the behavioral detection is on the side of the scrupbing center: you get the result, but do not manage the model. In one of the projects, this became a problem - the model on the side of the provider began to cut legitimate traffic after changing patterns due to a marketing campaign.

A separate headache for automatic systems - pulse wave DDoS: a series of short powerful bursts with pauses. Each burst may not reach the auto-date threshold, but the total load disables the service. According to Ideco, pulse wave is gaining popularity since 2025. The classic rate limiting does not save here - you need an analyst on a sliding window.
When to choose
• Channel less than 10 Gbps, budget is limited – cloud protection against DDoS closes volumetric vector without capital costs. For most web projects, this is enough for the eyes.
• Latency is critical (fintech, VoIP, gameng) - hybrid: on-premise inline filtering + cloud scrupbbing as a failure at volumetric > canal capacity. More expensive, but 5-30 ms added delay for the HFT platform is unacceptable.
• Volumetric exceeds the channel, there is no cloud scrupbing - BGP blackholing / RTBH on separate IP via upstream. The extreme measure: the attacker actually achieved the denial of service for this IP. But at least the rest of the infrastructure is alive.
• You need the complete visibility of L7 - on-premise appliance or WAF with DDoS module. Cloud solutions see L7 only if they are given a TLS certificate – which means that a third party will decrypt your traffic.
The best DDoS filters of the 2026 are not necessarily the most expensive. For most scenarios, cloud scrupbing + competent rate configuration of rate limiting at the level of nginx/nftables covers the main risks. The remaining 20% are case cases with strict requirements for latency, or compliance or when the attack goes from inside the perimeter (this is lower).
Detection at DDoS: WAF and DDoS protection in SIEM
Most DDoS protection tools work at the network level. But the SOC team must see the DDoS incident in SIEM - not only the fact of attack, but the context: parallel events, anomalies on L7, attempts to operate under the noise. WAF and DDoS protection work in bundle, and SIEM is their intersection point.

Minimum set of sources for DDoS-correlation:
• NetFlow/sFlow from border routers - volume, packages, ports, ACN sources
• Logs WAF - rate per endpoint, HTTP codes of response, geoIP
• Logs firewall - donness, state exhaust tableion
• Anti-DDoS Alherts - If You're Using Cloudy or On-premise Scrubbing
If there is at least one source, you have a blind spot. In practice, most often forget about NetFlow: there are WAF-logs, scrupbbing ailets come, but what is happening on routers - silence.

Pseudod Code Rules for Rebet/amplification Detection (not valid Sigma - adapt condition to a specific SIEM: EQL for Elastic, KQL for Sentinel, CorrLang for MaxPatrol SIEM, Sigma v2 correlation block):
YAML:

# Example to demonstrate the concept—adjusting thresholds based on the baseline
title: DDoS Reflection Amplification Suspected
logsource:
category: netflow
detection:
selection:
dst_port: [53, 123, 389, 1900, 11211]
condition: >
selection AND
sum(bytes_in) over 5m > baseline_avg_5m * 10
level: high
tags:
- attack.impact
- attack.t1498.002


Ports 53 (DNS), 123 (NTP), 389 (CLDAP), 1900 (SSDP), 11211 (Memcached) are classic reflection-ups. According to Shadowserver and Open Resolver Project, millions of DNS and NTP servers are powered to operate in re-attacks on the Internet. Threshold value baseline_avg_5m * 10 - tenfold exceeding the average in 5 minutes - the starting point. Calibrate for your traffic profile: the streaming service and the corporate portal baseline differs in order.
Correlation: DDoS as a smokescreen
Critical rule: if volumetric DDoS-alert (T1498) coincides in time with any of the events below - these are P1, without options:
• Unable growth of failed login issues on VPN/SSH
• New IP in the administrative panel
• Uncharacteristic SQL requests from the application server
• Alert from EDR (CrowdStrike Falcon, SentinelOne, Kaspersky EDR Expert) on hosts in DMZ
In Elastic, MaxPatrol SIEM, KUMA, it is implemented through tempor correlation: two aerates in a window of 30 minutes = escalation. This is how the L7-vector in the case was found from the beginning of the article - the WAF-alert automatically correlated with the volumetric-incident. Without this rule, the second vector would be spotted in 20 minutes, not by 3.

During the incident, it is useful to enrich source-IP through AbuseIPDB (API endpoint /api/v2/check) Recommended threshold - abuseConfidenceScore > 75. Free quota: 1000 requests per day - with a massive DDoS, this is not enough, but it will be enough to check the Top-100 IP by traffic. Categories #4 (DDoS Attack) and #17 (Spoofing) are two markers to look at. Traffic from known bulletproof-hosting (Datacamp and similar ASN) - an additional signal for filtration.
Checklist: how to protect yourself from DDoS attacks at the network level
Numbered checklist for a network engineer or inclusion in the audit report.

Adjustments to the environment: GNU/Linux-server with nftables (core 4.14+), access to the configuration of the border router (BGP-session), configured collection of NetFlow/sFlow in SIEM.
1. Implement BCP38/BCP84 filtering at the boundary of the network - block outgoing traffic with fake source addresses. According to NIST, the deployment of anti-spoofing - cycle: configuration, performance analysis, monitoring and verification. For edge-flow: urRPF strict mode ( ip verify unicast source reachable-via rxon Cisco IOS).
2. Configure rate limiting to nftables to protect against volumetric attacks:
Bash:
# nftables: rate limiting SYN flood + UDP amplification
nft add table inet ddos_filter
nft add chain inet ddos_filter input \
'{ type filter hook input priority 0; }'
nft add rule inet ddos_filter input \
tcp flags syn limit rate over 100/second burst 50 packets drop
nft add rule inet ddos_filter input \
udp dport '{ 53, 123, 1900 }' \
limit rate over 500/second burst 200 packets drop
 
Top Bottom