ddos-defense-research - Defensive research and practical examples for DDoS

项目说明

DDoS Defense Research

<p align="center">
<img src="assets/hero.svg" alt="DDoS Defense Research banner" width="100%">
</p>

!Scope
!Format
!Language
!Examples

> A practical, defensi repository about Distributed Denial of Service
> attacks: how they work at a high level, how to detect them, and how to design
> systems that keep serving real users under pressure.

Persian : README.fa.md

O

<p align="center">
<img src="assets/cards/architecture.svg" alt="Architecture card" width="31%">
<img src="assets/cards/detection.svg" alt="Detection card" width="31%">
<img src="assets/cards/mitigation.svg" alt="Mitigation card" width="31%">
</p>

<p align="center">
<img src="assets/cards/examples.svg" alt="Examples card" width="31%">
<img src="assets/cards/case-studies.svg" alt="Case studies card" width="31%">
<img src="assets/cards/lab.svg" alt="Defensive lab card" width="31%">
</p>

<p align="center">
<img src="assets/icons/cdn.svg" alt="CDN icon" width="56">
<img src="assets/icons/waf.svg" alt="WAF icon" width="56">
<img src="assets/icons/rate-limit.svg" alt="Rate limit icon" width="56">
<img src="assets/icons/cache.svg" alt="Cache icon" width="56">
<img src="assets/icons/autoscaling.svg" alt="Autoscaling icon" width="56">
<img src="assets/icons/logging.svg" alt="Logging icon" width="56">
<img src="assets/icons/nginx.svg" alt="Nginx icon" width="56">
<img src="assets/icons/nestjs.svg" alt="NestJS icon" width="56">
<img src="assets/icons/redis.svg" alt="Redis icon" width="56">
<img src="assets/icons/cloudflare.svg" alt="Cloudflare icon" width="56">
</p>

What This Repository Is

This repository is a defensi reference. It contains architecture
notes, detection checklists, diagrams, case studies, and implementation examples
for DDoS mitigation.

It is not an attack toolkit. There are no traffic generators, exploit scripts,
botnet instructions, or step-by-step offensi here.

Portfolio Value

| Repository state | Resume value | This repository |
|---|---|---|
| Text-only README | Medium | Covered by the Persian and English articles |
| README + diagrams | Good | Three S plus diagram documentation |
| README + diagrams + real configs | Very good | Nginx, Cloudflare, NestJS, and Redis examples |
| E above + safe local lab | Excellent | Docker-based defensive lab under lab/ |

GitHub Repository Metadata

GitHub repository metadata is edited from the repository page, not from a normal
Markdown file. Use these in the right-side About panel:

Description: Defensi and practical examples for DDoS detection, mitigation, and resilient web architecture.

Website:

Topics: ddos, cybersecurity, defensi, nginx, nestjs, redis, cloudflare, web-security

Social preview image: assets/social-preview.png

Setup notes are also tracked in .github/REPOSITORY_SETUP.md.

Repository Map

Executi

DDoS is an a problem before it is a tooling problem. A large attack
can exhaust bandwidth, packet processing capacity, connection tables, TLS
handshake capacity, application workers, queues, caches, databases, or a single
expensi.

Mature defense is layered:

1. Absorb hostile traffic at the edge before it reaches the origin.
2. Reduce the cost of each request with caching, rate limits, queues, and
graceful degradation.
3. Detect abnormal behavior quickly with baselines, metrics, logs, and clear
incident runbooks.

Architecture At A Glance

!DDoS-resilient architecture

The most important architectural rule is simple: do not let the public internet
talk directly to your origin unless that is an explicit and controlled design
choice. For most web systems, origin traffic should pass through DNS, CDN, WAF,
rate limiting, and load balancing layers first.

More diagrams:

asset gallery

DDoS-resilient traffic path

Detection and response flow

Mitigation layers

Defensi: rate limits, cache, autoscaling, logging

DDoS Attack Types, Theoretical View

| Category | Target | Typical pressure point | Defensi |
|---|---|---|---|
| | Network capacity | Bandwidth, packets per second, upstream links | Anycast, CDN, scrubbing, ISP filtering |
| Protocol / state exhaustion | Network and transport state | TCP backlog, connection tables, TLS CPU | SYN protection, connection limits, TLS offload |
| Application layer | Web/API logic | RPS, workers, database, cache misses | WAF, bot management, rate limits, caching |
| Multi- | Several layers at once | Network, edge, app, data tier | Layered defense and incident coordination |
| Ransom DDoS | Business continuity | A, trust, operational pressure | Prepared runbooks, provider escalation, e handling |

Detection

Good detection starts with a baseline. If normal traffic is unknown, abnormal
traffic becomes a guess.

!Detection and response flow

Signals Worth Monitoring

| Layer | Signals |
|---|---|
| Network | bps, pps, dropped packets, upstream saturation |
| TCP/UDP | SYN rate, acti, reset rate, connection lifetime |
| TLS | handshake rate, failed handshakes, edge CPU |
| HTTP | RPS, status codes, path distribution, p95/p99 latency |
| CDN/cache | cache hit ratio, origin fetches, cache-bypass patterns |
| WAF | allowed, challenged, blocked, false positive rate |
| Application | CPU, memory, thread pool, queue depth, worker saturation |
| Database | connection pool usage, slow queries, lock waits |

Beha Indicators

Sudden traffic growth without a matching business event.

Unusual concentration on login, search, report, checkout, or upload routes.

Lower cache hit ratio with a sharp increase in origin requests.

High 4xx/5xx rates, timeout growth, or load balancer errors.

Many requests without valid sessions, normal na flow, or stable

browser fingerprints.

Suspicious ASN, country, IP reputation, user-agent, or JA3/JA4 distribution.

Mitigation Layers

!Mitigation layers

| Layer | Defensi |
|---|---|
| ISP / scrubbing provider | Absorb traffic that would saturate your network link |
| DNS / Anycast | Avoid DNS as a single point of failure |
| CDN | Cache public content and terminate traffic near users |
| WAF / bot management | Challenge or block suspicious application traffic |
| Rate limiting | Control request rate and request cost |
| Load balancer / gateway | Enforce connection limits and route traffic safely |
| Application | Apply backpressure, degrade gracefully, protect expensi |
| Data tier | Protect database and cache from direct request amplification |
| Obser / incident response | Detect, coordinate, tune, and learn after the event |

Practical Examples

The examples are intentionally defensive and production-oriented:

Nginx rate limiting: edge-side request and

connection controls.

NestJS rate limiting: API throttling with

route-le.

Redis-based rate limiter: shared limiter state

for multi-instance applications.

Cloudflare WAF and rate limit rules: edge

rules for login, admin, API, and suspicious traffic.

Defensive lab: a safe local layout for studying mitigation

configuration without targeting any public system.

Safe Local Demo

The lab can be started locally with Docker:

Then open and inspect how Nginx applies defensive edge
limits before traffic reaches the demo service. The lab is intentionally scoped
to local configuration study.

Defensi Principles

| Principle | Why it matters |
|---|---|
| Origin isolation | Attackers should not bypass CDN/WAF and reach the ser |
| Cache-first public paths | Static and public content should not consume origin capacity |
| Endpoint-aware limits | Login, export, search, and upload routes need stricter controls |
| Cost-based thinking | A cheap request and an expensi should not ha weight |
| Backpressure | The system should slow down predictably instead of collapsing suddenly |
| Graceful degradation | Non-critical features can be reduced to preserve core a |
| Provider escalation | Large attacks often require upstream help |
| Post-incident learning | Temporary rules must be re, removed, or made permanent carefully |

Historical Case Studies

Detailed notes live in case-studies.

| Case | Why it matters |
|---|---|
| Estonia 2007 | DDoS as a national resilience and coordination problem |
| Spamhaus 2013 | Amplification and open resol became globally |
| Mirai / Dyn 2016 | IoT botnets and DNS dependency risk entered the mainstream |
| GitHub 2018 | A major memcached amplification attack peaked around 1.35 Tbps |
| HTTP/2 Rapid Reset 2023 | Application-layer DDoS reached extreme request-per-second scale |
| Hyper- attacks 2025 | Defensi must evolve with rapidly growing attack scale |

Recommended deep reads:

GitHub 2018 memcached amplification

HTTP/2 Rapid Reset 2023

Operational Checklist

Before An Incident

[ ] In public IPs, DNS records, and forgotten subdomains.

[ ] Ensure origin servers only accept traffic from approved edge networks.

[ ] Put public web traffic behind CDN/WAF where appropriate.

[ ] Define cache policies for static and public content.

[ ] Add rate limits for login, registration, password reset, search, export,

checkout, and upload routes.

[ ] Monitor network, edge, application, cache, and database metrics.

[ ] Prepare an incident runbook with provider escalation contacts.

[ ] Test failover, degraded modes, and emergency WAF rules.

During An Incident

[ ] Classify the pressure point: network, protocol, TLS, HTTP, app, or data.

[ ] Protect the origin first.

[ ] Increase safe caching for public responses.

[ ] Apply scoped rate limits to expensive or abused endpoints.

[ ] Use WAF challenges for suspicious traffic instead of broad blocking when

false positives are likely.

[ ] Escalate to CDN, DDoS protection, or ISP pro when upstream capacity

is at risk.

[ ] Keep a timeline of decisions, rules, metrics, and user impact.

After An Incident

[ ] Review false positives and real-user impact.

[ ] Remo rules that are no longer needed.

[ ] Convert useful temporary rules into tested permanent controls.

[ ] Patch architectural weaknesses exposed by the incident.

[ ] Update the runbook, dashboards, and alert thresholds.

References

See references/README.md for the full source list.

项目信息

开发语言：未知

Star 数：20

技术要点

该项目属于防护思路方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Defensive research and practical examples for DDoS detection, mitigation, and resilient web architecture.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。