Crux Read real config, a distributed rate-limiter snippet, an HTTP/2 server setting, and a WAF log line — predict the security behaviour and pick the highest-leverage fix.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbit
◷ 14 min
Security incidents are diagnosed in config files, limiter code, and log lines — not in slide decks. Read each artifact, predict how it behaves under attack, and choose the fix a senior engineer would make first.
Goal
Practise the loop you run in every incident: read the artifact, find the gap between what it does and what the operator assumed, and reach for the highest-leverage change.
An ops engineer 'hardened' the host by growing the SYN backlog to 4096 and left tcp_syncookies=0. Under a spoofed SYN flood, what happens, and what is the highest-leverage fix?
Heads-up Backlog size is linear headroom; a flood sending millions of SYNs/sec saturates any fixed backlog in milliseconds. The structural fix is SYN cookies, not a larger table.
Heads-up More retries keeps spoofed half-open entries alive longer, worsening exhaustion. You want them gone faster, and cookies remove the slot entirely.
Heads-up SYN cookies are a fallback that engages only on backlog overflow and interoperate with normal clients; the real cost is a small hash computation per ACK, not broken NAT clients.
Snippet 2 — the distributed token bucket
-- per-request limiter, called on every API hitlocal count = redis.call("INCR", key)if count == 1 then redis.call("EXPIRE", key, window_seconds)endif count > limit then return DENYendreturn ALLOW
Quiz
Completed
This Redis-backed limiter runs on every request across a fleet of app servers. Under a 100k req/sec attack, what is the operational problem, and what is the standard mitigation?
Heads-up INCR is atomic in Redis — that is the reason it is used here. The issue is per-request network latency and Redis becoming a bottleneck, not atomicity.
Heads-up Setting EXPIRE on first increment is the correct fixed-window idiom; the window's TTL is established once per window. There is no leak.
Heads-up They are correct but not free — each decision costs a round-trip. At high request rates you mitigate with local counters plus periodic global sync.
Snippet 3 — the HTTP/2 server config
http2_max_concurrent_streams 128;# no limit on the rate of stream creation / resetkeepalive_requests 100000;
Quiz
Completed
This config caps concurrent streams at 128 but never limits the rate of stream creation. Why does it stay vulnerable to HTTP/2 Rapid Reset (CVE-2023-44487)?
Heads-up The attack deliberately stays under the concurrency cap by cancelling each stream instantly; the cost is in the create/reset churn the server still pays, which the cap never sees.
Heads-up Connection keepalive count is unrelated; Rapid Reset abuses stream lifecycle within a connection. The fix is bounding stream-creation/reset rate.
Heads-up Rapid Reset is an application-layer (L7) resource-exhaustion attack on the HTTP/2 stream state machine; server-side stream-rate limiting is exactly the mitigation vendors shipped in 2023.
Reading this WAF anomaly-scoring timeline (block when score ≥ threshold=5), which reading is correct?
Heads-up By 14:24 the p50 is 6.1 — above the threshold of 5 — and p99 is 28.5. The whole distribution has shifted into attack territory; this is not healthy traffic.
Heads-up Blocking 380k of a 450k/sec flood is the WAF working. The concern is the 70k that still pass given how high p99 is — a tuning gap, not a malfunction.
Heads-up The threshold is the anomaly-score cutoff (block when summed rule score ≥ 5), not a percentage of traffic.
Recap
Every defense is read in config and logs. A bigger SYN backlog is linear headroom; SYN cookies are the structural fix. A Redis limiter is correct but every decision is a round-trip — mitigate with a local fast path plus periodic sync. Concurrency caps do not stop Rapid Reset; you must bound stream-creation rate including resets. And a WAF anomaly log tells you, at a glance, whether the score distribution has shifted into attack territory and whether your threshold is letting traffic through. Read the artifact, find the gap between intent and behavior, fix the highest-leverage one first.