So, Norway is under attack. Since we announced that we would continue supporting Ukraine, some threat actor have decided to launch DDoS attacks against some of our most commonly used public services.
“The reason for the attack: On August 23, Norway and Ukraine signed a new defence and security cooperation agreement focused on drones. Under the agreement, Norway will continue strengthening Ukraine’s defence capabilities through the Nansen Support Programme..
At the same time, there are bunch of experts posting articles about how they should use DDoS protection and XYZ without giving ANY context or DETAILS on HOW they should fix it and what is available of functionality, hence my frustration and hence this blog post….
And just an FYI, much of the DDoS attacks have been the same for many years, the biggest different is the HTTP DDoS attacks which now tends to target specific frameworks.
Now I have written about DDoS attacks before, they come in many shapes and forms… but the main purpose of any DDoS attack is to disrupt the availability of a service. You can kinda think of DDoS as rush hour, many many cars stuck in traffic on the same road and not getting to the destination. This is what happens to an application or service when a DDoS attack is happening, that legitimate users are not able to access the application or service.
Many view DDoS as some BIG attack! well the truth is that A 100 Mbps attack is enough to overwhelm a server or website running so doesnt have to be many..
But first let us understand what DDoS attack is, hence the name DISTRIBUTED Denial of Service attack… Or just flooding the network with traffic. With the focus on the keyword Distributed! distributed it means that the source is from MANY MANY multiple coordinated sources, so starting to block based IP lists is not the right approach since you will be putting in IP addresses all day long (However if you want to can get DDoS threat feed from Cloudflare if you are working for an ISP https://developers.cloudflare.com/ddos-protection/botnet-threat-feed/)
DDoS attacks worldwide examples seen from NetScout and their sensor network.
While a (Denial of Service) DoS attack can be from fewer sources and acting more like legitimate traffic when you look at the logs. Can be just HTTP GET/POST commands, but the more efficent ones tend to target frameworks (WordPress) or other actions which put a lot of strain on the backend servers
So what kind of DDoS attacks are we seeing? Well the best source out there right now is Cloudflare and their service RADAR. Now Cloudflare protect[s] more than 20% of the of all worldwide HTTP traffic (https://blog.cloudflare.com/500-tbps-of-capacity/) , so I tend to belive that they have decent insight into the traffic flow on a global scale.
https://radar.cloudflare.com/security
So some statistics if we look back for the last 6 months focusing on Norway as a target.
- 90% of attacks are under 10 minutes, but more and more stretching over 3 hours (still counts for <2% of the traffic)
- 65% of Layer 3/4 attacks are UDP based
- 21% of Layer 7 attacks are being carried by Microsoft/Azure networks
- <50 of the Layer 7 based attacks are coming from Microsoft as source (Azure)
If you want to get a better overview on the current state of things, Cloudflare has a great blogpost summarizing what is going on a global perspective
–> https://blog.cloudflare.com/ddos-threat-report-2026-h1/
And also a great list of the most common attack-vectors
But what are the different DDoS attacks?
- TCP floods: ACK, SYN, and RST floods overwhelm connection handling. SYN-ACK reflection redirects responses toward a spoofed victim.
- Network floods: UDP, ICMP, GRE, ESP, and QUIC floods consume bandwidth or packet-processing capacity.
- TCP/protocol abuse: Out-of-state TCP and protocol-violation attacks send unexpected or invalid traffic to exhaust inspection and state-tracking systems.
- Reflection and amplification: CHARGEN, DNS, DTLS, mDNS, NetBIOS, QOTD, SIP, SNMP, and SSDP services are abused to generate reflected and sometimes amplified traffic toward the victim.
- DNS floods: Query floods overwhelm DNS processing; garbage floods use malformed or meaningless requests; NXDOMAIN floods repeatedly request nonexistent names.
- Randomized DNS attacks: Water Torture and random-prefix attacks generate unique subdomains to bypass caches. DNS laundering relays such traffic through legitimate recursive resolvers, making filtering harder.
- Carpet bombing: Distributes traffic across many IP addresses or endpoints instead of concentrating it on one target.
- HTTP floods: Large volumes of apparently valid web requests exhaust application or server capacity.
- Cache busting: Uses unique URLs or query strings to bypass caches and force repeated work at the origin.
- HTTP/2 Continuation flood: Sends improperly terminated header fragments, potentially exhausting CPU or memory.
- HTTP/2 Rapid Reset and MadeYouReset: Repeatedly abuse HTTP/2 stream resets, forcing servers to start and discard work until resources are exhausted.
- Slow-connection attacks: Slowly transmit incomplete HTTP requests to hold connections and server resources open.
- TLS/SSL exhaustion and negotiation attacks: Trigger excessive cryptographic negotiations or related processing to consume CPU and connection capacity.
So many different flavours, but the majority is either TCP SYN, UDP or regular HTTP Flood.
As seen in the screenshot below, as an example of a TCP based DDoS attack, when looking at the raw packets (PCAP file) of a SYN Flood attack you dont see much, you can see some metadata being added to the header of the packet.
We have also had different amplification attacks with DTLS (both on RDP and Citrix) –> https://msandbu.org/rdp-ddos-amplification-attack/ and here –> https://msandbu.org/citrix-netscaler-ddos-and-deep-dive-dtls-protocol/
These attacks were possible mostly because of improper implementation of the DTLS protocol in the networking stack of these products. (So the way to protect against reverse DTLS attacks is adding the Hello Cookie in the protocol implementation) And then we have HTTP based attacks which are more aimed at getting the web server to use all available CPU/Memory available with what appears to be legitimte traffic while TCP/UDP based attacks is focusing on using as much bandwidth as possible.
So these attacks are annoying, and especially when public services are the target, what can we do to protect ourselves against these different attacks, when they are coming from across the globe?
To handle volumetric attacks which are the most common, the most efficient method is Anycast routing. Anycast network routing is able to route incoming connection requests across multiple data centers. When requests come into a single IP address associated with the Anycast network, the network distributes the data based on some prioritization methodology.
So traffic to a specific IP which host is service is routed to the closest PoP of the provider (CDN or Cloud Provider) so this means that we can process and also block traffic at the edge.
So what can we use to get DDoS protection against volumetric attacks? These are some of the providers and features.
- AWS: CloudFront and AWS Shield
- Microsoft Azure: Azure Front Door and Azure DDoS Protection
- Google Cloud: Cloud CDN, Cloud Load Balancing and Cloud Armor
- Cloudflare: Cloudflare CDN and Magic Transit
- Akamai: Akamai CDN and Prolexic
- Fastly: Fastly CDN and DDoS Protection
Wait…Does that mean I need to move my apps or service to the cloud as well? No.. Services can run anywhere, for instance Cloudflare just requires to manage the domain then you point to either a public IP or a private IP, Azure just create an Azure Front Door profile, add the application origin, configure a custom domain and point its CNAME to Front Door.
The good part about if you are using Azure Front Door as a way to load balance and make your services globally available, it also supports only HTTP and HTTPS protocols and with a valid Host header for each request. This behavior helps prevent common DDoS attack types such as volumetric attacks that use various protocols and ports, DNS amplification attacks, and TCP poisoning attacks.
These features are useful if you find yourself as a target of attacks which are <2 million RPS (Requests per second) against your services.
And to handle this you NEED to have a provider that has a global network, there is a reason why cloud providers handle these type of attacks and do not get affected by them…. (https://blog.cloudflare.com/defending-the-internet-how-cloudflare-blocked-a-monumental-7-3-tbps-ddos/)
So instead of writing a bunch of text for al vendors I decided to go with a table format.
Layer 3/4 (network & transport)
Should also mention that I added Citrix Netscaler here, since it is a product I have worked with a while, even wrote a book about it! But for instance many of the providers have built in TCP SYN Cookie enabled by default that can handle TCP SYN fllood attacks, only as long as it managed the bandwidth…
| Product | Model | Flood & protocol mitigation | Non-HTTP (TCP/UDP) |
|---|---|---|---|
| Citrix NetScaler (or any other ADC) | Self-managed appliance/VPX in your own path. With dedicated HW Accelerator chips can handle absurd amount of SSL sessions. | Detect: static thresholds you configure · Mitigate: SYN cookies (on by default), connection & rate limits, Surge Protection queueing · Tune: fully manual, and bad against volumetric attacks (especially UDP) | Full L4 proxy for any TCP/UDP service |
| Azure Front Door | Multi-tenant PaaS anycast edge, 192 POPs; infrastructure protection included free | Detect: platform-automatic, not customer-visible · Mitigate: anycast dispersion across POPs; non-HTTP dropped at edge · Tune: n/a just wait… | HTTP/HTTPS only, valid Host header required |
| Azure DDoS Protection | Free infrastructure protection → IP Protection $199/IP/mo → Network Protection $2,944/mo (100 IPs, then $29.50/IP). Attaches to public IPs on VNet resources | Detect: always-on ML traffic profiling per public IP · Mitigate: scrubbing of volumetric & protocol floods · Tune: adaptive real-time tuning, automatic; metrics and mitigation reports exposed | Protocol-agnostic, protects the public IP |
| Akamai | Prolexic Routed (BGP/GRE), Prolexic Connect, or IP Protect (anycast) | Detect: flow monitoring at 32 anycast scrubbing centers, always-on or on-demand · Mitigate: proactive mitigation controls pre-agreed per customer · Tune: SOC managed; zero-second SLA for always-on + pre-agreed vectors only | Protocol-agnostic, protects the public IP |
| AWS | Shield Standard (free) / Shield Advanced | Detect: always-on flow monitoring; Advanced adds health-based detection · Mitigate: deterministic packet filtering, priority traffic shaping at edge · Tune: automatic also advanced allows custom mitigations | Via NLB / Global Accelerator / EIP |
| Google Cloud | Always-on at Google Front Ends. Cloud Armor for better visibility and tuning of rules. | Detect: always-on at GFE · Mitigate: GFE proxy terminates and absorbs SYN floods before any policy evaluates · Tune: none at L3/4 | Via network LB / Cloud Armor network policies |
| Cloudflare | Anycast reverse proxy + Magic Transit / Spectrum | Detect: autonomous edge sampling + per-customer Adaptive DDoS traffic profiles · Mitigate: in-line drop at every anycast POP · Tune: managed rulesets with adjustable sensitivity; full adaptive rules need the Advanced DDoS add-on | Spectrum (TCP/UDP proxy) |
Next we have layer 7 attacks…So what are the features I can use to protect against it?
1: Challenge / Browser verification:
Issues a challenge the client must complete before the request reaches the origin. Classic JS challenges require the client to execute JavaScript, which filters simple scripted floods — but headless browsers (Puppeteer, Playwright) execute JS fine, so modern implementations use managed challenges that pick among methods: non-interactive proof-of-work, client-signal checks, TLS/browser fingerprint validation, or an interactive CAPTCHA as a last resort.
2: Rate limiting
Caps how many HTTP requests per client over a time window. The threshold matters less than the key: per-source-IP limiting fails against a distributed botnet where each host sends a plausible low rate….
3: Caching
Anything served from edge cache never reaches your origin, so a large share of an L7 flood costs you nothing. Not marketed as a DDoS feature, but tuning cache-control correctly is frequently worth more than any rule you write. Only available where the product is a caching CDN.
4: Client reputation
A behavioural risk score per client derived from activity observed across the vendor’s whole platform (Often as part of managed firewall rules or threat feeds)
5: Geo-blocking
Blocks or challenges traffic by source country. Cheap and easy, and only useful when your legitimate audience is genuinely regional and the botnet isn’t. Modern botnets span consumer ISPs worldwide including your own country, so this trims the tail rather than stopping the attack.
6: Priority queueing / graceful degradation
Doesn’t stop the attack but keeps you partially available during one by prioritising known-good sessions and or queueing the rest.
7: WAF managed rulesets / anomaly scoring
OWASP CRS and vendor equivalents. Less about raw volume, more about request-exhaustion attacks that hammer expensive endpoints (WordPress) search, login, checkout, report generation at rates too low to trip a rate limiter.
Mostly all of these features are available from CDN or Cloud Providers. The best often is to have a set of capabiltiies that can protect from both of these types of attacks. However DDoS attacks are still pretty much the same they have been for a long time. Sure they “hit” harder, some of them use new vulnerabilities in protocols, and the amount of endpoints is a bit bigger. However the methods to protect against these are still much the same as it has been for the last years.