Denial of Service Mitigation Questions

Technical knowledge of denial of service attack types and vectors including volumetric attacks, protocol and state exhaustion attacks, and application layer attacks. Ability to design detection and mitigation approaches such as traffic classification and filtering, rate limiting, behavior and anomaly detection, network level mitigation using anycast and scrubbing centers, routing controls including border gateway protocol based mitigations, and on prem versus cloud based scrubbing service trade offs. Design for operational resilience through geographic distribution, rapid failover, traffic engineering, capacity planning, and cost benefit analysis of mitigation choices. Familiarity with incident response playbooks, monitoring and metrics for detection and mitigation effectiveness, and approaches to evolve detection against novel attack patterns.

MediumTechnical

29 practiced

What specific metrics and dashboards would you build to monitor the effectiveness of active DDoS mitigations? List at least eight metrics across network, transport, and application layers, and suggest thresholds or SLOs (for example, acceptable increases before escalation) and key visualizations to include on an incident dashboard.

Sample Answer

**Approach (brief)** As a Network Engineer I’d instrument metrics across network, transport and application layers to detect attack onset, measure mitigation effectiveness, and guide escalation. Each metric has an SLO/threshold and an incident dashboard visualization.

**Metrics & SLOs**

Network layer- Bandwidth utilization (ingress/egress per POP) — SLO: < 80% baseline; alert at +20% above baseline. Viz: stacked area per region + anomaly band.- Packet loss rate (core links) — SLO: < 0.5%; alert > 1%. Viz: time-series with per-link heatmap.- SYN/ICMP/UDP packet rate (pps by protocol) — SLO: within baseline ±30%; alert if sustained spike > 3x baseline for 1 min. Viz: multi-series pps chart + top-talkers.

Transport layer- Connection attempts / new sessions per second (SYN rate) — SLO: < 2x baseline; alert > 5x. Viz: histogram + CDF of source IPs.- Active flows and flow churn — SLO: flow count within baseline ±40%; alert on sudden spike. Viz: flow count timeseries + flow-age distribution.- TCP retransmit and RTO rate — SLO: retransmit rate < 2%; alert > 5%. Viz: stacked line showing retransmit vs normal traffic.

Application layer- HTTP 5xx rate and error latency — SLO: 5xx < 1% of requests; alert if +0.5% absolute increase. Viz: error-rate bar, request latency percentile lines (p50/p95/p99).- Requests per second (RPS) by endpoint and client geolocation — SLO: RPS within capacity; alert on sudden concentrated spikes. Viz: heatmap (endpoint × region) and top client IPs.

**Additional items**- Source IP uniqueness (distinct /24s) — alert if many sources spike (botnet). Viz: gauge + world map.- Mitigation telemetry (WAF rules hit, ACL drops, scrubbing center throughput) — SLO: drops correspond to attack traffic; alert if mitigation capacity saturated. Viz: flow pipeline diagram with counters.

**Incident dashboard**- Top: global summary (bandwidth, pps, 5xx rate, mitigation capacity)- Middle: protocol breakdown, top offending IPs/subnets, geolocation map- Bottom: timelines for mitigation actions, rule hits, and RCA notes- Controls: quick links to block/unblock IPs, throttle, and escalate thresholds

Rationale: combine high-fidelity telemetry (pps, packet loss) with business-facing signals (5xx, latency) so mitigation both protects infrastructure and preserves customer experience.

HardTechnical

29 practiced

Provide a concise nftables or iptables configuration snippet that rate-limits new HTTP connections to 200 new connections per second per source IP with a burst of 400, dropping connections that exceed this. Explain limitations of this approach under high-cardinality distributed attacks and the impact on conntrack tables.

Sample Answer

**nftables snippet (recommended)**

bash

table inet filter {
  set http_rate_limit {
    type ipv4_addr
    flags timeout
    timeout 10s
    elements = { }
  }

  chain input {
    type filter hook input priority 0;
    tcp dport 80 ct state new meter @http_rate_limit { ip saddr limit rate 200/second burst 400 packets } accept
    # drop everything else (or continue other rules)
    drop
  }
}

**iptables (conntrack + hashlimit)**

bash

# requires xt_hashlimit
iptables -N HTTP_LIMIT
iptables -A INPUT -p tcp --dport 80 --syn -m conntrack --ctstate NEW -j HTTP_LIMIT
iptables -A HTTP_LIMIT -m hashlimit --hashlimit-name http_per_src --hashlimit-above 200/sec --hashlimit-burst 400 --hashlimit-mode srcip --hashlimit-htable-expire 10000 -j DROP
iptables -A HTTP_LIMIT -j ACCEPT

**Why this works**- Limits NEW TCP connects per source IP to 200/sec with 400 burst (packets treated as connection attempts).- nftables' meter is efficient and in-kernel; iptables uses hashlimit module.

**Limitations & operational impacts**- High-cardinality distributed attacks (many source IPs) bypass per-src limits because each IP stays under the threshold — aggregate load still saturates CPU/NIC/firewall.- Conntrack table growth: tracking many NEW connections (even dropped after SYN) consumes conntrack entries and memory; risk of table exhaustion and kernel dropping legitimate flows.- CPU overhead: per-packet accounting (hashlimit/nft meter) increases cycle cost under high PPS.- Spoofing and ephemeral port tricks can reduce effectiveness.

**Mitigations**- Combine with SYNPROXY or TCP SYN cookies to avoid conntrack state for half-open connections.- Use upstream DDoS scrubbing, network ACLs, rate-limit by /24 aggregates, BGP blackholing, or eBPF/XDP for very high PPS.- Monitor conntrack size and tune nf_conntrack_max, timeouts, and hashing.

MediumTechnical

30 practiced

How would you detect and mitigate slow HTTP attacks (for example, Slowloris or HTTP/2 slowstreams) that keep connections open while sending data very slowly? Describe network and application indicators, three mitigation strategies that minimize false positives, and side effects of each strategy.

Sample Answer

**Approach summary**Detect slow-HTTP attacks by combining network-layer telemetry (connection duration/packet timing) with application-layer metrics (request progress, headers/body bytes/sec). Mitigate using layered controls tuned to avoid false positives.

**Indicators**

- Network-level - Very long TCP connection durations with near-zero throughput - Many simultaneous connections from few IPs or /24s - Small keepalive packets, low ACK rates, long inter-packet gaps- Application-level - HTTP requests that never reach Content-Length or send body bytes extremely slowly - Large number of half-complete requests in worker queues (thread/worker exhaustion) - Abnormally low requests-per-second but high concurrent connections

**Three mitigation strategies (minimize false positives + side effects)**

1) Adaptive per-connection idle/read timeouts- How: enforce minimum bytes-per-second and max inter-byte gap with sliding window; exempt authenticated/long-polling endpoints via ACLs.- Minimizing false positives: whitelist known clients, increase thresholds for mobile/slow networks.- Side effects: may drop legitimate slow clients (mobile, high-latency links) if thresholds too strict; need careful tuning.

2) Connection-rate and concurrency limits with source aggregation- How: limit concurrent connections per IP and per subnet; use token buckets and progressive penalties (e.g., 429 + backoff).- Minimizing false positives: use subnet-aware limits, higher caps for known proxies/CDNs; allow burst recovery.- Side effects: shared NATs/CDNs may hit limits; risk of denying service to many users behind a single IP.

3) Terminate and validate at edge (reverse proxy/WAF) with active probes- How: put nginx/HAProxy or cloud WAF in front to early close slow streams and validate via lightweight challenge (e.g., HTTP/2 SETTINGS, TLS renegotiation avoidance).- Minimizing false positives: issue graceful 503 with Retry-After and track client behavior before blacklisting.- Side effects: increased CPU at edge, possible performance hit; complexity in handling legitimate long-lived connections (websockets, SSE).

Choose a layered mix: edge termination + adaptive timeouts + IP-rate controls, with monitoring/alerts to iteratively tune thresholds.

EasyTechnical

38 practiced

Explain the differences between volumetric attacks and application-layer DoS attacks. If you had limited mitigation budget and tooling, which type would you prioritize defending against first and why? Include brief examples and how detection approaches (network-level telemetry vs application logs) differ.

MediumTechnical

33 practiced

Compare cloud scrubbing services versus on-premises scrubbing appliances for DDoS mitigation. Discuss trade-offs in capacity provisioning, cost model (always-on vs on-demand), latency, control over payload inspection, privacy/compliance, and operational overhead. Recommend an approach for a mid-sized SaaS company with a 1 Gbps baseline and a tight budget.

Sample Answer

**Quick summary**Compare cloud scrubbing (third‑party scrubbing centers / CDN-integrated DDoS mitigation) vs on‑premises scrubbing appliances across capacity, cost model, latency, payload control, privacy/compliance, and ops. Then recommend for a mid‑sized SaaS with 1 Gbps baseline and tight budget.

**Capacity provisioning**- Cloud scrubbing: virtually elastic; absorbs large volumetric attacks by leveraging provider backbone and peering. Good for unpredictable large spikes.- On‑prem: capacity limited to appliance throughput and uplink; requires significant overprovisioning (e.g., 5–10x baseline) to handle big attacks.

**Cost model**- Cloud: typically on‑demand or subscription; pay for mitigation events or committed plan. Lower upfront capex; variable opex can spike during attacks.- On‑prem: high capex for appliances and redundant links; predictable fixed cost but poor ROI if attacks are rare. Always‑on appliances incur licensing/support fees.

**Latency**- Cloud: potential redirection/proxying adds small additional RTT and possible path changes; well‑provisioned providers keep latency low but edge routing can impact geographies.- On‑prem: minimal added latency since traffic stays local; best for latency‑sensitive flows.

**Control over payload inspection**- Cloud: deep packet inspection often available but may limit custom parsing or proprietary protocol handling; encrypted traffic requires TLS termination at provider (privacy tradeoffs).- On‑prem: full control—can inspect arbitrary payloads, keep private keys in‑house, customize rules.

**Privacy / compliance**- Cloud: sending traffic (and TLS termination) to third party can be an issue for sensitive data or strict regulators; need contracts, SOC/ISO attestations, and possibly private peering.- On‑prem: better for strict compliance—data never leaves your control.

**Operational overhead**- Cloud: lower day‑to‑day ops; provider manages scaling, signatures, and global routing. Some integration and runbooks required.- On‑prem: high ops for maintenance, tuning, firmware, and manual scaling during attacks.

**Recommendation for a 1 Gbps baseline, tight budget (mid‑sized SaaS)**- Hybrid leaning cloud: primary cloud‑based scrubbing with a modest subscription/commitment tailored to 1 Gbps (e.g., 2–5 Gbps committed) plus burstable on‑demand protection. Use provider with edge POPs near customers and BGP/Anycast integration.- Rationale: avoids large capex, gives elastic capacity for rare large attacks, keeps latency acceptable, and minimizes ops burden. Mitigate privacy concerns by: - keeping TLS keys on your side where possible (e.g., use SNI‑based routing, or cloud provider offering BYOK/bring-your‑own‑TLS), - contractually requiring data handling controls and audits, - routing only HTTP/API traffic through scrubbing while keeping internal/private links on dedicated circuits or VPNs.- If you expect frequent targeted application‑layer attacks or strict compliance requiring in‑house inspection, add a smaller on‑prem appliance (or virtual NVA) for layered defense.

**Operational tips**- Implement clear failover BGP/Anycast playbooks, automated health checks, and test failover regularly.- Monitor cost exposure for on‑demand events; set alerts and caps.- Keep baseline capacity and WAF tuning current to reduce false positives and attack surface.

Unlock Full Question Bank

Get access to hundreds of Denial of Service Mitigation interview questions and detailed answers.

Join thousands of developers preparing for their dream job.