Denial of Service (DoS), in plain English

What this is

A Denial-of-Service vulnerability is any bug, misconfiguration, or protocol weakness that lets an attacker make your service unavailable to legitimate users. Unlike data theft or remote code execution, the goal isn’t access; it is to take you offline. The operational impact ranges from a few minutes of degraded performance to a complete outage that lasts as long as the attack does.

DoS issues fall into four categories that look different but share the same outcome:

Volumetric / network-layer DDoS. Many sources flood your network with traffic until your bandwidth or packet-processing capacity gives up. UDP amplification (DNS, NTP, memcached), reflection attacks, and modern carpet-bombing botnets fit here.
Protocol-level DoS. A single, valid-looking request exploits a weakness in a protocol implementation to consume disproportionate resources. HTTP/2 Rapid Reset (CVE-2023-44487) is the textbook recent example: each individual stream is cheap, but the rate of RST_STREAM cancellations exhausts the server’s worker pool.
Application-layer / algorithmic DoS. A bug in your code lets a small amount of attacker input do a large amount of server work. Catastrophic regex backtracking (ReDoS), quadratic JSON parsers, hash-collision attacks on input dictionaries, “billion laughs” XML expansion all live here.
Resource exhaustion via legitimate features. No bug at all, just an expensive feature with no rate limit: the password-reset endpoint that triggers an email per call, the “export to PDF” job, the search endpoint that allocates 100 MB per query.

Why attackers run DoS

Pure availability attacks rarely get the attention that breaches do, but they happen for concrete reasons:

Extortion. “Pay this bitcoin amount or we keep you offline”. Ransom DDoS campaigns target retail, payments, and gaming whenever business depends on uptime.
Competitive sabotage. Particularly common in gaming, gambling, and ticketing during high-traffic events.
Smokescreen. A loud network-layer attack draws on-call attention while a quieter intrusion runs in parallel.
Hacktivism and protest. Public-facing services of governments, media, and named companies during politically charged events.
Accidental. A legitimate user submits a query that triggers a quadratic code path; same outage, no malicious actor required.

Concrete examples worth knowing

HTTP/2 Rapid Reset, CVE-2023-44487. Disclosed October 2023 after Cloudflare, AWS, and Google absorbed record-breaking attacks. A single client opens streams and immediately resets them, generating server work without consuming its own quota. Patched in nginx, Apache, Envoy, Go’s net/http, and others within a week. Anything still on an unpatched build remains vulnerable.
ReDoS via catastrophic regex backtracking. A regex like ^(a+)+$ evaluated against an input of 30 as followed by ! takes seconds to fail. Attacker submits the string in a profile field validated by that regex; one HTTP request pegs a CPU. The Cloudflare 2019 outage was this pattern, with the regex inside a WAF rule.
Slowloris and friends. Old, but still works against default-configured Apache: open many TCP connections, send the request line and one header per minute, never the final blank line. The server keeps each connection alive waiting for the request to complete.
XML billion laughs / quadratic blowup. A 1 KB XML document with nested entity references expands to gigabytes during parsing. Defaults in older XML parsers are still vulnerable.
Hash-collision attacks. Carefully chosen JSON keys all hash to the same bucket, turning the O(1) hash-map lookup into O(n²). Mitigated by hash-randomisation in modern languages but still surfaces in legacy stacks.

How attackers run a DDoS

The economics drive the shape of the attack. Protocol-level and application-layer DoS need almost no infrastructure: one VPS, one exploit script, a vulnerable target. Volumetric DDoS scales by renting capacity from a booter / stresser service, by harvesting botnet capacity from compromised IoT devices, or by abusing UDP amplifiers (open DNS resolvers, exposed memcached). Modern attacks combine layers: a volumetric flood to absorb mitigation capacity, plus an application-layer attack against the origin once defenders are stretched.

Recovery is operational. While the attack runs, the team is rate- limiting, blocking ASNs, scaling the WAF, and coordinating with the upstream provider. The cost of an hour offline (lost orders, SLA penalties, customer-support load) is the real damage.

How it gets fixed

Defence in depth, applied before you need it:

Network / volumetric layer:

Sit behind a CDN or DDoS-protection provider whose absorption capacity exceeds plausible attack sizes. Cloudflare, Fastly, AWS Shield, Bunny, Akamai. The economics of small SMEs paying for this are generally favourable: bandwidth at scale is cheap for the provider and unaffordable for individual operators.
Validate the configuration. A CDN that protects only the public domain while the origin IP is reachable directly is no defence. Origin firewalls should accept traffic only from the CDN’s published address ranges.

Protocol / application layer:

Patch promptly when protocol-level DoS CVEs are disclosed (HTTP/2 Rapid Reset, RangeSmash, etc.). These typically require nothing more than a server upgrade.
Set sensible request limits in your reverse proxy: header size, body size, idle timeout, request rate per IP. Defaults in nginx, Apache, Caddy, and Traefik are reasonable starting points but rarely tuned for the actual application.
Audit user-influenced regex for catastrophic backtracking patterns. Use re2 (Go), re2-wasm in Node, or test regexes with eslint-plugin-redos. Set a wall-clock timeout on regex evaluation if your runtime allows.
Set timeouts on every external call. A blocked downstream service shouldn’t be able to exhaust your worker pool. Circuit breakers (Hystrix, resilience4j, Polly) are the explicit pattern.

Application architecture:

Rate-limit expensive endpoints per identifier (account, IP, API key). Token-bucket implementations are widely available.
Make heavy operations asynchronous. PDF rendering, large exports, image processing belong in a queue with a bounded worker pool, not on a request thread.
Cache aggressively. A cached response at the edge serves attacker traffic without ever reaching your origin.

How blueredix surfaces DoS issues

The scanner reports CVEs in third-party software whose description names a denial-of-service vulnerability, and flags exposed amplifier-prone services (open DNS resolvers, memcached on UDP, NTP monlist) on your network surface. We do not run live DoS testing against your services. Generating real traffic at the volume needed to verify the bug would itself be the attack; that is engagement-scoped pentesting work.