1. 干安全这些年DDoS 这道坎到底怎么迈做线上业务的人几乎都躲不过 DDoS 这一关。它不是那种需要多高深技巧的入侵手法却总能用最粗暴的方式把人搞得焦头烂额带宽被打满、机房黑洞、服务全挂、老板连环夺命 call。我经历过几次从凌晨两点鏖战到天亮的应急也做过完整的防护体系改造这篇总结是把攻击原理、防御架构、应急动作、监控告警这些环节放在一起重新捋一遍尤其把检测与对抗过程中那些文档里不写、但实际踩过的坑记录下来给正在搭防护方案、准备做攻击演练或者被攻击搞得睡不着觉的同行一个参考。这篇内容不局限于某一套商业产品而是把思路拉回到本质层面DDoS 到底在打什么、有哪些典型打法、防御应该分几层、紧急情况下先做什么动作以及平时怎么通过监控和演练保证关键时刻不掉链子。无论你是运维、研发还是安全岗哪怕对网络的认知还停留在“ping 得通就算通”的程度也可以跟着这条路把防御体系建起来。2. 攻击原理拆解不懂攻击手法防御就是空中楼阁2.1 四层攻击的经典套路SYN Flood 与 UDP Flood 的运作机制防御之前必须先搞明白攻击在打什么。拿最经典的 SYN Flood 来说TCP 建立连接要经历三次握手客户端发 SYN服务端回 SYNACK客户端再回 ACK连接才建立。攻击者干了什么事呢它发大量 SYN 包然后故意不回最后一个 ACK服务端手里的半开连接越积越多连接表被打满正常用户再来握手就被直接丢弃。这类攻击消耗的是服务端的连接资源和内存即使网络带宽没满业务也可能已经“假死”。UDP Flood 则是另一个思路攻击者用大流量 UDP 包砸向目标端口近源带宽被灌满或者反射放大把流量放大几十倍后再砸过来。像 DNS、NTP、SSH 这类协议如果没做加固一秒就能变成攻击者的“帮凶”。我见过最典型的一种情况是攻击流量只有几个 G但全砸在数据库服务器的某个 UDP 端口上应用层直接被拖垮这就是没有按端口和协议做精细化防护的典型教训。2.2 七层攻击的隐蔽性HTTP Flood 与 CC 攻击为什么难防四层攻击靠流量大小说话七层攻击则靠“像人”来伪装。HTTP Flood也叫 CC 攻击攻击者模拟真实浏览器请求不断刷新某个查询接口、翻页接口、登录接口每个请求看起来都合法单看 QPS 也不算离谱但积少成多应用服务器的线程池、数据库连接池就被拖死了。这类攻击最麻烦的地方在于它不需要很大的带宽一个几百人的僵尸网络就能让一台配置不错的服务器起不来。还有更刁钻的慢速攻击建立连接后不完整发送请求头或者一点点地吐数据把服务器连接长期占着不放。连接数上限一到正常用户连不上这就是 Slowloris 一类的原理。我最早接触这类攻击时第一反应是查流量大小结果带宽根本没满后来才意识到问题出在连接层的“慢性消耗”上。防御七层攻击必须在 Web 层做请求速率限制、会话合法性校验、人机识别等多维度的配合单靠大带宽解决不了。2.3 看清攻击的三个维度流量型、连接型、资源消耗型把常见攻击归一下类能帮助你在应急时快速判断对策。流量型攻击的核心特征是“大”目标是填满链路带宽或者设备转发能力典型如 UDP Flood、ICMP Flood连接型攻击的核心特征是“多”目标是用海量连接占满状态表典型如 SYN Flood、慢速攻击资源消耗型的核心特征是“慢”和“杂”目标是耗尽应用层线程、CPU、数据库连接典型如 HTTP Flood 和复杂查询滥用。实际操作中攻击很少按教科书来很多是混合型的先来一波流量型把入口带宽打高趁你手忙脚乱清洗时再补一波慢速连接型攻击同时穿插着打几个高计算量的接口。这也是为什么我一直强调防御必须分层单靠防火墙或者单靠高防 IP 都不够层与层之间还得能协同感知和联动否则只是把问题从一个环节推到了另一个环节。3. 防御架构设计从“硬扛”到“层层设防”3.1 三道防线的思路边界清洗、中间分流、本地加固我见过不少团队做防护只买了一台高防服务器或者只在防火墙里加了几条限速策略效果自然不好。成熟的 DDoS 防御应该是“纵深防御”至少三道防线第一道是边界清洗层部署在 IDC 入口或云厂商的清洗设备旁路负责把超大流量攻击挡在门外。核心能力是流量牵引和回注当检测到攻击超过一定阈值时把流量牵引到清洗设备过滤后再把干净流量回注到真实服务器。第二道是中间分流层比如 CDN 或负载均衡负责分散压力把用户请求分摊到多个节点攻击者面对的不再是一个孤立的源站而是一个分布式的入口矩阵。第三道是本机加固层在服务器和 Web 应用层面做连接限制、请求速率限制、系统参数调优处理漏网之鱼。三层防线各司其职又彼此兜底。边界清洗管“大流量”中间分流管“分散压力”本地加固管“精细防护”。没有哪一层能单独应付所有攻击但合在一起大部分攻击都会被挡在第一道或第二道门外。3.2 高防 IP、CDN 与自建清洗的选型对比关于方案选型很多人纠结到底是买高防 IP 还是 CDN或者自己搭建一套流量清洗系统。我的结论是看业务类型和预算没有绝对的好坏只有合不合适。高防 IP 适合源站 IP 需要隐藏、流量型攻击偏多的业务比如游戏、金融、政企门户。它的优势是防御能力大、接入简单、支持 TCP/UDP 全协议转发缺点是带宽成本高、部分高防 IP 的线路质量不稳定。CDN 更适合网站、App 接口这类可以被缓存的业务优势是节点多、抗流量能力强、还能加速访问缺点是四层协议支持有限、动态请求防护效果依赖配置。自建清洗则适合有能力有团队的大厂用 BGP 引流 自研检测引擎做精细化清洗但从零到成熟往往需要大半年不是小团队能轻易啃下来的。我建议中小团队走“CDN 高防 IP”组合的路线静态资源走 CDN 缓存动态请求回源时走高防 IP同时把源站 IP 封死只允许白名单回源。这种做法成本可控效果也有保障。3.3 容量规划与冗余设计留足缓冲才有还手之力很多业务平时没被攻击时觉得带宽够用就行。真被打时才发现机房入口带宽上限就是 200M攻击流量一上来瞬间打满物理断网。容量规划的核心原则是正常业务峰值的带宽使用不超过总带宽的三分之一留出至少两倍以上的冗余应对突发流量。冗余不只指带宽也包括服务器资源。比如入口带宽 1G正常峰值用到 300M攻击来了 800M清洗设备还能扛一阵如果正常峰值已经到 900M攻击流量哪怕只有 200M也会直接把链路打瘫。CPU、内存、连接数也一样日常使用峰值超过 70% 就要重视该扩容扩容该限流限流否则攻击等同于“顺手补刀”。说实话这个道理谁都懂但真到预算审批时不少人还是抱着“应该不会被打”的心态结果真出了事代价往往是宕机几小时起步。4. 实战部署与核心参数抄作业级别的配置方案4.1 紧急止血内核参数和 iptables 的快速调整被攻击时没有时间从容搭架构最先要做的是止血。Linux 服务器上几个内核参数调整立竿见影net.ipv4.tcp_max_syn_backlog加大半连接队列长度net.ipv4.tcp_synack_retries减少 SYNACK 重试次数net.ipv4.tcp_abort_on_overflow在队列满时直接丢弃新连接而不是等待超时。这些参数组合起来能有效缓解 SYN Flood 对连接表的消耗。iptables 层面可以做三件事。第一限制单 IP 并发连接数-m connlimit --connlimit-above 100 -j REJECT第二限制单 IP 新建连接速率-m recent --name suspicious --update --seconds 60 --hitcount 60 -j DROP第三直接丢弃明显非法的包比如伪造源 IP 或者异常标志位的包。注意这类规则要在尽量靠前的位置生效避免 CPU 浪费在无效匹配上。还有一点REJECT会回 ICMP 包可能被反射放大利用紧急情况下用DROP更稳妥虽然客户端体验稍差但保命要紧。4.2 接入高防和 CDN 的流程与回源配置细节买好高防 IP 后接入流程并不复杂但细节决定成败。核心步骤是把域名解析切到高防 IP源站防火墙只放行高防的回源 IP 段并在源站上绑定白名单。这个白名单一定要谨慎配置既要保证高防能回源又不能放得太宽。如果用了 CDN 和高防的组合架构上要遵循“CDN - 高防 - 源站”的链路顺序源站 IP 绝不能裸奔在公网 DNS 上。我在实践中发现一个高频失误源站 IP 被打了紧急买了高防 IP结果高防的回源 IP 没有加进源站白名单流量全部被源站防火墙丢弃业务直接“假成功”了几十分钟排查才发现是白名单漏配。这个坑值得单独提醒回源白名单配好后一定要做一次完整的连通性测试用curl -H Host: yourdomain.com https://回源IP/验证一下能不能正常拿业务响应。4.3 基于 Nginx 的 CC 攻击防护配置实践对七层攻击Nginx 层面的配置能做很多事。limit_req_zone是请求速率限制按 IP 维度做每秒请求数限制比如limit_req_zone $binary_remote_addr zonereq_limit:10m rate10r/s;超过速率的请求直接返回 503。limit_conn_zone是并发连接数限制配合limit_conn指令控制单 IP 的连接数防止慢速连接占满 worker。更接近生产实践的做法是分接口配置不同阈值。登录接口可以放宽一些但要加验证码查询类接口收紧速率静态资源直接上 CDN 缓存跟源站没关系。我习惯的做法是先用正常流量压测跑出每个核心接口的 QPS 基线然后按基线的 2 到 3 倍设置速率上限避免误杀正常用户。同时Nginx 日志里要记录$request_time和$upstream_response_time方便事后分析哪些请求特别耗时、来自哪些 IP。需要特别留意的坑限流阈值设得太死高峰期误杀正常用户限流阈值设得太宽攻击流量又能穿透。没有一劳永逸的配置需要根据监控曲线持续调整。4.4 应急响应 SOP从发现攻击到恢复业务的完整动作清单团队里一定要有书面的应急响应 SOP否则攻击一来各干各的反而乱成一团。我总结的流程是“一观察、二牵引、三加固、四恢复”。发现异常后先观察 3 到 5 分钟确认攻击特征是流量型还是连接型还是应用型判断攻击源 IP 段、目标端口、请求类型。其次立刻执行牵引动作把域名切到高防或者把流量引到清洗设备这一步的目标是让真实源站脱离攻击面。第三在源站上做加固加白名单、调内核参数、启用限流防止清洗回注的流量里混着漏网攻击。第四等监控指标恢复平稳后再逐步恢复服务的完整功能比如放开校验码、恢复大文件下载等不要一次性全部放开。每个环节都要有明确负责人和联系电话还要有备份方案比如高防 IP 本身挂了怎么办、域名解析服务被攻击了怎么办。建议每季度做一次模拟攻击演练不要只在纸面上过 SOP真刀真枪跑一遍才能发现问题演练时用一小段测试流量模拟攻击验证清洗链路和告警链路是否畅通。5. 检测与监控体系建设看不见的攻击怎么提前发现5.1 流量基线与行为画像先知道“正常”长什么样没有基线就谈不上检测异常。很多人第一次接触 DDoS 时满脑子是“抓异常流量”但实际做下来发现最难的不是抓异常而是定义“什么是正常”。每个业务的流量模型不一样游戏业务晚高峰和凌晨的低谷差异非常大电商大促期间的流量曲线更是平日的几十倍。建基线的过程是采集至少一个月的历史监控数据按天、按小时、按业务模块分别统计带宽、QPS、连接数、请求延迟的分布区间。有了这些数据后设置动态阈值比如带宽超过历史均值的三倍、或者 QPS 超过 P95 值两倍时触发告警。我推荐用滑动窗口而不是固定阈值的方式来做基线判断因为业务本身有周期性和季节性固定阈值很容易在大促期间频繁误报又在攻击确实来临时因为阈值太高而漏报。5.2 告警分级与自动化处置从“人肉盯”到“系统响应”监控体系建好了告警也不能一层不变。我把 DDoS 告警分为三级P1 是业务已经开始受影响或带宽已经打满需要立即人工介入P2 是流量异常但业务还能撑住需要关注意向判断P3 是轻微抖动还不确定是不是误报只是记录观察。分级的意义在于别把每一个小抖动都搞得全员戒备狼来了喊多了真出事时反而没人紧张。自动处置方面可以做一些浅层的联动脚本比如带宽连续五分钟超过阈值时自动把域名解析切到高防 IP某 IP 的并发连接数超限时自动加入防火墙黑名单。这种脚本不需要太复杂但必须在可控范围内测试过几轮最怕的是自动化规则误伤正常流量比如把某个 NAT 出口 IP 封了导致一整个办公区域的用户全部断连。所以自动处置规则的阈值一定要保守宁可漏一点也不要误杀一片。5.3 日志关联分析从单点指标到全局视角检测 DDoS 不能只看带宽和 QPS 这两项指标还要把多个数据源串起来。源站 Nginx 日志、负载均衡的访问日志、防火墙的会话记录、高防的防御报表、云监控的流量图这些数据单独看都只能反映一个侧面放在一起才能还原攻击全貌。比如单纯看带宽图发现有异常峰值不配合源站的访问日志分析你很难判断这波流量是打某个特定接口的还是分布式地打满整个服务器的。再比如一分钟内来自同一 C 段的大量请求、请求路径高度集中、User-Agent 异常统一这些特征单独看可能不起眼组合起来基本可以断定是攻击行为。我习惯把日志导入到分析系统里按源 IP 维度做聚合按请求路径做 TopN 统计按时间维度做频率变化曲线辅助判断攻击的规模和意图。这个环节既是技术活也是经验活多看看历史攻击的日志特征对快速判断非常有帮助。6. 常见问题与排查技巧实录6.1 问题速查表异常现象与可能原因对照把这些年遇到的典型问题整理成一张速查表排查时按图索骥效率会高很多异常现象可能原因优先排查动作带宽打满但 CPU 正常流量型攻击UDP/ICMP Flood检查流量组成牵引到清洗设备CPU 高但带宽很低应用层攻击CC/HTTP Flood查看 Nginx 日志限流并封禁异常 IP连接数耗尽且大量 TIME_WAITSYN Flood 或慢速攻击调内核参数限制单 IP 连接数丢包严重且有大量回源失败高防回源被绕过或白名单配错检查源站防火墙白名单隐藏真实 IP部分地区用户访问不了高防线路故障或被黑洞确认高防的防护能力切换备用线路这个表只是一个起点真实场景往往更复杂。排查时先定位攻击类型再针对性地做动作不要上来就重启服务器或者重启应用那样不仅解决不了问题反而让攻击者觉得你慌了。6.2 误封正常用户与漏防攻击的平衡技巧误封和漏防是防御里最难调的一对矛盾。阈值严了高峰期正常用户被限流或封禁投诉立刻铺天盖地阈值松了攻击流量穿透防护源站直接崩掉。我调试下来有几个可行的技巧第一不要把单 IP 作为唯一的封禁维度配合 UA、Cookie、验证码行为、JS 挑战等多因子识别对可疑 IP 做拦截而不直接封禁。第二封禁动作分层先对异常流量进行延迟处理或者弹验证码确认是攻击后再升级为封禁这样能避免一次误杀。第三设置自动解封时间对于临时性误判的 IP比如办公网络的出口 IP自动封禁若干小时后自动解封给正常用户留一条回头路。这些细节看起来不起眼但实际体验差异巨大。6.3 混合型攻击的应对经验与复盘要点混合型攻击是防御体系真正的压力测试。有一次实际案例中攻击者在流量型攻击被高防挡住之后立刻切到应用层对一个报表接口发起高频请求同时用大量慢速连接占住源站的连接池。我们第一反应是流量图没再飙升以为攻击已经被挡住了直到业务监控显示接口响应时间暴涨才发现问题。复盘时总结了几条经验防御不能只看带宽指标应用层指标同等重要清洗设备要能够自动识别“前面攻击已缓解但后面有新攻击特征出现”的态势变化应急期间要多看全局看板不要盯着一两个指标。复盘清单里我通常包含这几项攻击开始和结束时间、攻击类型和规模、防御动作和生效时间、业务受损时长和范围、改进事项和负责人。每一次攻击都是宝贵的经验来源但前提是你真的做了复盘而不是事后大家各自散场等下一次被打时再重复踩坑。7. 个人体会与最后一点建议做了这么多年的 DDoS 防御最大的感受是这一仗永远没有“打完了”的时间点只有持续完善、持续演练的过程。攻击手法在不断进化防御体系也得跟着跑前阵子还流行大流量打满带宽过阵子就变成了慢速低流量精准消耗应用层资源不变的是“发现问题、加固调整、演练验证”这个循环。技术本身不复杂难的是坚持把它当作常态化工作来做而不是只有被打时才想起来要准备。另外我想特别建议大家在安全投入上算一笔长期的账不要拿“业务还没到那个规模”当借口。DDoS 防御不是等到被打得满地找牙才去考虑的事而是在业务上线第一天就应该预留的容量和策略。哪怕先用最简单的 CDN 套一层做好源站 IP 的隐藏和访问控制也能让绝大多数中小规模的攻击者望而却步。先活下来再谈壮大这个道理放在安全建设上也一样适用。