简介这份源码资源面向安全工程师、后端开发者及网络安全爱好者聚焦在线教育平台遭遇DDoS攻击的真实案例提供从攻击原理到防御落地的完整参考。资源包共3个文件以html页面、inscode配置与gitignore文件为主压缩包约7KB体量轻便便于快速查阅与本地复现。内容围绕带宽耗尽、协议资源耗尽与应用层耗尽三类攻击展开并给出基础防护、高防IP与清洗服务、动态带宽调度、CDN流量分发、限流熔断降级及高可用架构等全链路防御思路帮助读者理解攻击全貌并掌握可落地的应对策略。目前已有298人学习适合需要构建抗DDoS能力、补齐安全防护短板的开发者参考也可作为团队安全演练与架构优化的辅助材料。1. DDoS攻击防御实战从被流量打崩到守住业务入口凌晨两点监控群突然炸了——某公司对外API的响应时间从80ms飙到12s带宽曲线几乎垂直拉满运维第一反应是“业务量暴涨”第二反应是“完了被打了”。这不是电影桥段而是很多中小团队第一次遭遇DDoS时的真实写照。DDoS攻击防御实战要解决的核心问题很朴素当海量垃圾流量涌向你的入口时怎么让正常用户还能进来、让业务不崩、让账单不失控。它适合后端工程师、运维、SRE以及任何需要把服务暴露到公网的人。这篇笔记不讲空泛概念而是按“先看懂攻击面、再搭最小可复现防御、最后调参和排错”的路径把源码级实现拆开讲清楚。你不需要一开始就上高防机房但必须知道每一层能挡什么、挡不住什么。2. 先分清对手DDoS的四种常见打法与你的防御边界2.1 流量型、协议型、应用型、反射型打法完全不同很多人把DDoS当成一个东西结果用错药。常见做法是先按OSI层次分四类流量型UDP Flood、ICMP Flood靠体积压垮带宽协议型SYN Flood、ACK Flood消耗连接表应用型HTTP Flood、慢速攻击伪装成正常请求打后端反射放大DNS/NTP反射借第三方把流量放大几十倍。这四类的防御点完全不同流量型要在边缘清洗协议型要在内核和连接队列做文章应用型必须看业务语义反射型则要限制暴露面。我一般会先画一张表把“攻击类型 → 主要消耗资源 → 第一道防线 → 兜底手段”列清楚再决定代码写在哪一层。比如SYN Flood如果你只在Nginx层做限流内核的SYN队列早就满了根本轮不到Nginx处理。所以源码级防御的第一步不是写业务代码而是确认内核参数和边缘策略。2.2 单机防御的极限为什么只靠一台机器扛不住单机防御的上限由三个硬指标决定网卡带宽、内核包处理能力、连接跟踪表大小。一块千兆网卡理论峰值约125MB/s遇到10Gbps的UDP Flood包还没进应用层网卡和中断就已经饱和。更隐蔽的是conntrack表默认nf_conntrack_max在不少发行版上是65536SYN Flood几秒钟就能塞满之后所有新连接被丢弃表现为“服务器没死但谁也连不上”。所以单机方案适合做“第一层过滤”和“应用层精细限流”但不要指望它扛住大流量。常见做法是单机负责识别和丢弃明显异常包把干净流量放给后端真正的体积型攻击交给上游清洗或云厂商的高防IP。源码防御的价值在于“低成本挡住小规模攻击”和“为大流量争取响应时间”。2.3 最小可复现防御栈iptables 内核参数 应用层限流下面给出一套可以在测试机复现的最小防御栈。它不追求扛住T级攻击但能让你在本地把“识别异常→丢弃→限流→记录”的链路跑通。第一步调整内核参数缓解SYN Flood和连接表压力# /etc/sysctl.d/99-ddos.conf # 开启SYN CookiesSYN队列满时用cookie应答防止队列耗尽 net.ipv4.tcp_syncookies 1 # 增大SYN队列和accept队列给突发连接留缓冲 net.ipv4.tcp_max_syn_backlog 8192 net.core.somaxconn 8192 # 扩大连接跟踪表并缩短空闲连接超时加快回收 net.netfilter.nf_conntrack_max 262144 net.netfilter.nf_conntrack_tcp_timeout_established 600 # 降低TIME_WAIT占用允许复用 net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_fin_timeout 15执行sysctl -p生效。参数说明tcp_syncookies是SYN Flood的后悔药但注意它只在队列满时启用正常连接不受影响nf_conntrack_max要结合内存算每条跟踪记录约300字节262144条约占75MB内存小的机器别照抄。第二步用iptables做基础速率限制和异常包丢弃# 限制单个IP对新连接的速率超过则丢弃注意这是粗粒度生产要配合白名单 iptables -N SYN_FLOOD iptables -A SYN_FLOOD -p tcp --syn -m limit --limit 100/s --limit-burst 200 -j RETURN iptables -A SYN_FLOOD -p tcp --syn -j DROP iptables -A INPUT -p tcp --syn -j SYN_FLOOD # 丢弃非法TCP标志组合如NULL、XMAS扫描 iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP # 限制ICMP速率防止ICMP Flood iptables -A INPUT -p icmp -m limit --limit 10/s -j ACCEPT iptables -A INPUT -p icmp -j DROP逻辑说明SYN_FLOOD链先放行低于阈值的SYN超过的直接DROP。--limit 100/s表示平均每秒100个新SYN--limit-burst 200是突发上限。这个阈值对单机小服务够用但对NAT后的办公网会误伤所以生产环境要先把公司出口IP加白名单。第三步应用层用令牌桶做细粒度限流。以Python为例写一个可复用的限流中间件import time from collections import defaultdict class TokenBucket: def __init__(self, rate, capacity): self.rate rate # 每秒补充的令牌数 self.capacity capacity # 桶容量即突发上限 self.tokens capacity self.last time.time() def allow(self): now time.time() # 按时间差补充令牌最多补到capacity self.tokens min(self.capacity, self.tokens (now - self.last) * self.rate) self.last now if self.tokens 1: self.tokens - 1 return True return False # 按IP维护桶实际生产要加过期清理防止内存膨胀 buckets defaultdict(lambda: TokenBucket(rate20, capacity40)) def check_request(ip): if not buckets[ip].allow(): return False, 429 Too Many Requests return True, OK参数说明rate20表示每个IP平均每秒20个请求capacity40允许短时突发到40。这个值要按业务调整登录接口可以更低如5/s静态资源可以更高。注意defaultdict会无限增长生产环境必须加LRU或定时清理否则限流器本身变成内存泄漏点。2.4 把防御接进请求链路从入口到业务的无缝衔接限流器写好了关键是接在哪。常见做法是在反向代理层如Nginx的limit_req做第一道应用层做第二道。Nginx配置示例# 定义限流区按IP10MB共享内存约存16万个IP状态 limit_req_zone $binary_remote_addr zoneperip:10m rate20r/s; server { location /api/ { limit_req zoneperip burst40 nodelay; limit_req_status 429; proxy_pass http://backend; } }burst40允许突发40个请求nodelay表示突发请求立即处理而不是排队。这样应用层拿到的已经是相对干净的流量令牌桶只作为兜底。两层配合的好处是Nginx用C实现性能损耗小应用层能结合用户身份做更细的策略比如VIP用户单独放行。3. 源码级实现把防御逻辑写成可测试的模块3.1 用滑动窗口替代固定窗口解决临界突刺固定窗口限流有个经典问题窗口边界处可能通过两倍流量。比如限制每秒100次第1秒最后10ms来100次第2秒前10ms又来100次实际200次都放过了。滑动窗口能缓解这个问题。下面是一个基于Redis的滑动窗口实现import time import redis r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) def sliding_window_allow(key, limit, window1): key: 限流键如 frate:{ip} limit: 窗口内最大请求数 window: 窗口大小秒 now time.time() pipe r.pipeline() # 移除窗口外的旧记录 pipe.zremrangebyscore(key, 0, now - window) # 当前窗口内请求数 pipe.zcard(key) # 加入本次请求score用时间戳保证有序 pipe.zadd(key, {str(now): now}) # 设置过期避免冷key常驻内存 pipe.expire(key, window 1) _, count, _, _ pipe.execute() return count limit逻辑说明用Redis有序集合存请求时间戳每次先删旧记录再计数。zremrangebyscore和zcard在同一个pipeline里执行减少往返。参数上limit和window要按接口定短信验证码接口可以limit1, window60查询接口可以limit100, window1。注意Redis本身可能成为瓶颈高并发下建议用本地滑动窗口Redis定期同步或者直接用Redis的CL.THROTTLE模块。3.2 连接数限制比请求数更早发现异常有些攻击不靠高QPS而是靠大量慢连接占满连接表。这时候请求数限流没用要看并发连接数。Linux可以用ss统计但实时防御要在代码里做。下面是一个基于iptables connlimit和ss监控的组合方案# 限制单IP对80端口的并发连接数不超过50 iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 --connlimit-mask 32 -j REJECT # 监控脚本每10秒统计一次超过阈值告警并记录TOP IP while true; do ss -nt state established ( sport :80 ) | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -rn | head -5 sleep 10 doneconnlimit-above 50表示超过50个并发连接就拒绝--connlimit-mask 32按单个IP算。这个值对普通用户足够但如果有用户走代理池可能误伤。监控脚本的输出要接入告警因为connlimit是硬拒绝调太低会影响正常用户。3.3 日志与取证被打了要知道谁打的、打了多久防御不只是挡还要留证据。下面是一个结构化日志模块记录每个被限流请求的IP、时间、路径和触发规则import json import logging from datetime import datetime logger logging.getLogger(ddos) handler logging.FileHandler(/var/log/ddos_block.log) logger.addHandler(handler) logger.setLevel(logging.INFO) def log_block(ip, path, rule, count): record { ts: datetime.utcnow().isoformat(), ip: ip, path: path, rule: rule, # 触发的规则名如 sliding_window 或 connlimit count: count, # 当前窗口计数或连接数 } logger.info(json.dumps(record))日志按行JSON存储方便后续用jq或ELK分析。关键字段是rule和count能帮你判断是误伤还是真攻击。比如某个IP在sliding_window规则下count稳定在limit附近可能是正常高频用户如果count瞬间冲到几千基本可以确定是攻击源。取证数据还可以用来向上游申请清洗或报警。4. 避坑与排查那些让防御失效的细节4.1 坑一只调了应用层内核先崩了现象Nginx限流配置正确但攻击一来服务器直接失联SSH都连不上。原因SYN Flood打满内核SYN队列或者conntrack表溢出包根本到不了应用层。解决先按2.3节调内核参数再用dmesg | grep -i syn flood和conntrack -S确认。如果nf_conntrack: table full出现说明nf_conntrack_max太小要调大并缩短超时。4.2 坑二限流阈值照抄博客把正常用户挡了现象上线限流后客服反馈部分用户频繁429。原因阈值没结合业务。比如某接口正常用户每秒3-5次但博客示例写20/s看似宽松实际NAT后的公司出口几百人共享一个IP20/s根本不够。解决先跑一周观察日志用P99值定阈值再留2-3倍余量。对已知出口IP加白名单或者按用户ID而非IP限流。4.3 坑三Redis限流器自己成了单点现象攻击时Redis响应变慢限流判断超时请求全部放行或全部拒绝。原因限流逻辑强依赖Redis而Redis没做高可用或连接池太小。解决本地加一层令牌桶做快速判断Redis只做跨机同步或者用Redis Cluster并设置合理的socket_timeout超时后走降级策略如放行但记录日志。降级策略要提前想清楚是宁可放过还是宁可错杀。4.4 坑四日志写太多磁盘先满了现象被攻击时防御日志暴增几小时写满磁盘服务因无法写日志而崩溃。原因每个被限流请求都写文件且没做轮转。解决用logrotate按小时轮转限制保留份数高频规则只记录聚合统计如每分钟每IP计数不记录单条。或者把日志直接推到远端本地只留最近1小时。4.5 坑五忘了防御自己的管理端口现象攻击者打不动业务端口转而打SSH或数据库端口导致运维通道被占满。原因防御策略只覆盖了80/443。解决管理端口只对跳板机开放用iptables -A INPUT -p tcp --dport 22 -s 跳板机IP -j ACCEPT加默认拒绝。数据库端口同理不要暴露到公网。5. 进阶技巧把防御做成可观测、可回滚的闭环5.1 用压测验证防御阈值而不是等真攻击防御配置最怕“看起来对一打就穿”。我一般会写一个轻量压测脚本在测试环境模拟SYN Flood和HTTP Flood观察系统在阈值附近的行为。比如用hping3发SYN包用ab或wrk发HTTP请求同时监控ss -s、conntrack -S和限流日志。重点看三个指标正常请求的成功率、被限流请求的比例、系统资源CPU、内存、连接表的拐点。如果压测时正常请求成功率低于99%说明阈值太紧如果资源先于限流触发而耗尽说明内核参数或硬件是瓶颈。压测脚本示例仅测试环境使用# 模拟SYN Flood持续30秒每秒1000包 hping3 -S -p 80 --flood --rand-source -d 120 目标IP # 同时用wrk压正常请求观察成功率 wrk -t4 -c100 -d30s --latency http://目标IP/api/health注意--rand-source会伪造源IP只在隔离测试网用。压测后要清理iptables规则避免残留影响。5.2 防御策略的灰度与回滚限流规则上线不能一把梭。常见做法是先用log模式跑一周只记录不拦截观察会命中哪些IP、频率如何。确认误伤可控后再切到block模式。回滚要快把规则写成配置文件用nginx -s reload或发送信号热加载避免重启服务。应用层限流器可以加一个开关通过配置中心动态调整rate和capacity攻击过去后逐步放宽。5.3 一个具体技巧用布隆过滤器挡掉已知恶意IP如果攻击源IP相对固定可以用布隆过滤器在内存里做O(1)判断比查Redis快得多。Python示例from pybloom_live import BloomFilter # 容量100万误判率0.1% bf BloomFilter(capacity1000000, error_rate0.001) def add_malicious(ip): bf.add(ip) def is_malicious(ip): return ip in bf布隆过滤器的特点是“宁可错杀不可放过”——它说不在的IP一定不在说在的IP可能误判。所以适合做第一层快速过滤命中后再查精确黑名单确认。误判率0.1%意味着1000个正常IP里可能有1个被误拦对大多数业务可接受。更新策略是定期从日志里提取高频攻击IP批量加入过滤器。这套方案我用了两年多最大的教训是防御不是配一次就完事而是跟着业务和攻击手法一起演进。每次被攻击后我都会把新的攻击特征加进日志分析调整阈值再压测一遍。希望帮到你。本文还有配套的精品资源点击获取