1. 从一次实战说起我为什么开始认真研究DDoS事情要从两年前的一次上线说起。当时某个产品刚做完压测自认为扛得住一定流量结果正式对外不到一周运营同事早上发来消息“后台监控曲线不对劲请求量突然翻了二十倍但PV没涨。”我登录服务器看了一眼Nginx日志里铺天盖地的都是同一个URLUser-Agent五花八门来源IP遍布全国但有一个共同特征——单个IP的请求频率极高而且请求的页面全是耗CPU的动态接口。那一刻我就意识到这不是正常流量是有人在打我们。后面查下来是同行竞争期间的一次恶意攻击。规模不算大峰值也就每秒几千请求但对当时只有几台小机器的团队来说已经足够把服务打到超时。从那天开始我花了大半年时间系统性地研究DDoS从原理到防御、从应急到复盘踩了不少坑也积累了一些自己的心得。这篇文章就是把这段时间的实践整理成一份相对完整的记录。不管你是运维、后端开发还是自己捣鼓小项目的独立开发者我都尽量用说人话的方式把DDoS这件事讲清楚——它是什么、怎么打、怎么防、真的遇到时怎么办。其中很多内容是基于我自己实际操作的补充和总结不是教科书式的理论堆砌希望能给你一些真正可落地的参考。2. DDoS不是一种攻击而是一类攻击的集合很多人一听到DDoS脑子里就浮现出“有人疯狂刷你服务器”的画面。这个理解没错但不够精确。DDoS的全称是分布式拒绝服务攻击拆开看有三个关键词分布式、拒绝、服务。分布式意味着攻击源不止一个而是成千上万个节点同时发起拒绝服务的核心目的不是偷数据、改文件而是让你的服务无法响应正常用户请求。这决定了DDoS的防御思路和传统安全攻击完全不同。你不需要防住黑客进入系统你需要防住的是海量垃圾流量把带宽打满、把连接耗尽、把CPU跑死。换句话说攻击者不追求攻破你只追求拖垮你。按攻击层面去分我习惯把DDoS分成三类网络层攻击典型的是SYN Flood、UDP Flood、ICMP Flood目标是打爆带宽或者打满防火墙会话表。传输层攻击比如TCP连接耗尽、SSL握手攻击目标是把服务器的并发连接资源榨干。应用层攻击比如HTTP Flood、慢速攻击、频繁请求某个高计算量接口目标是消耗CPU、数据库连接、业务逻辑处理能力。这里我特别想说一下应用层攻击。很多人买高防服务器觉得自己带宽足够大网络层攻击无所谓结果一遇到HTTP Flood就傻眼。原因很简单网络层攻击打的是管道的粗细应用层攻击打的是管道里货物的处理速度。就算你的带宽有100G如果应用层逻辑一个请求要查库三次、还要做一堆计算几十并发就能把数据库连接池打满。所以理解DDoS的第一件事就是先分清你面对的攻击属于哪一层。不同层级的防御手段完全不同买错了防护等于白花钱。3. 攻击者为什么能“借用”这么多机器打你DDoS最可怕的地方在于它的规模。单台机器就算再厉害也很难把一个大带宽打满但如果是几万台机器同时发包呢这就涉及到一个经常被误解的概念僵尸网络。攻击者控制的这些机器大多不是他自己的。常见来源有几类一是被植入木马的服务器和个人电脑攻击者通过漏洞批量控制后等待指令二是物联网设备比如摄像头、路由器、智能网关很多设备出厂默认口令没改被人抓去组成了肉鸡三是开放的DNS服务器、NTP服务器、Memcached等这些可以被用来做反射放大攻击。反射放大的原理值得单独拿出来说。攻击者伪造受害者的源IP向公网上大量开放服务发送一个小请求服务响应时把大结果发给受害者。响应的数据量是请求的几十倍甚至几百倍攻击者只需要很小的带宽就能驱动巨大的流量打到受害者身上。这就是为什么我们经常看到新闻报道某次攻击峰值达到几百G甚至上T——背后不一定是真正的僵尸网络有多大而是利用放大效应把流量“借”了出来。对我个人而言理解这一点最大的价值在于防御时不要试图去区分“哪个IP是攻击IP”因为攻击源可能遍布全球甚至很多合法IP也在参与。更好的思路是站在受害者的角度用流量特征和协议行为去做判断。4. 防御DDoS的标准姿势三层防线我自己做防御的框架可以简单概括为“清洗、限速、扩容”三个字。听起来简单但具体操作每一步都有讲究。4.1 第一层流量清洗把脏流量挡在门外流量清洗是目前最主流的商业防护方案。原理是在你的服务器前面架设一层专门的清洗设备或高防节点所有流量先经过它实时分析后把攻击流量过滤掉只把正常流量转发给你的源站。这里有个关键概念叫“回源”。清洗节点怎么判断一个请求是否正常标准做法是把请求的一些特征转发给源站试一下源站能正常应答就放行否则拦截。这有点像机场安检看起来每个旅客都要过一遍但真正耗时的检查只是针对可疑对象。实际使用中清洗方案的配置有几个要点CNAME接入把域名解析到高防IP由高防节点代理转发这样攻击流量先到高防被清洗后再回源。源IP保护不能让攻击者知道你的真实服务器IP否则他可以绕过高防直接打源站。常见做法是只允许高防IP访问源站或者用防火墙限制回源IP。防护阈值设置不是把所有流量都当攻击只有当流量超过设定阈值时才触发清洗。阈值设太低容易误杀正常业务设太高又起不到保护作用。我见过很多团队把高防买回来就完事了源站IP直接在DNS解析里暴露着结果攻击者一封TCP包直接打源站端口高防形同虚设。这是排第一位的低级错误。4.2 第二层应用层限制让业务自己扛一部分流量清洗可以扛住大流量但在应用层攻击面前单纯靠带宽清理是不够的。我们还需要在业务层面做一些手脚让攻击请求进不到真正消耗资源的逻辑里。这一层的做法比较灵活我在项目中常用这几个频控针对同一IP、同一Cookie、同一设备指纹设置访问频率上限超过阈值直接返回验证码或拒绝。核心是“正常用户不可能每秒请求一百次”。验证码对于高频风险操作比如登录、下单强制加入滑块或点击验证增加攻击成本。页面缓存对不涉及个人数据的页面尽量静态化或用CDN缓存动态请求尽量加一层Redis缓存减少回源到数据库的请求。请求特征拦截通过对User-Agent、Referer、请求头顺序等做规则匹配拦截明显的恶意请求。但注意这个方法只能对付初级攻击者会伪造请求头的黑客很容易绕过。我特别想强调频控的一个细节不要只做IP维度的限频。现在很多攻击者会用分布式IP池每个IP只发少量请求如果只按IP限制根本不起作用。我习惯的做法是组合维度IPUser-Agent、IPCookie、或者用JavaScript生成的访问Token做设备指纹识别。当然这需要在前端埋点算是一种成本略高的方案但实测效果比单纯IP限频好很多。4.3 第三层基础扩容把受害面降低这里说的扩容不是无限买机器而是合理规划冗余。比如带宽冗余至少保证日常峰值带宽的2至3倍冗余避免小规模攻击一打就断外网。连接数优化调整系统的文件描述符上限、TCP连接队列大小、Nginx的worker_connections让服务器在连接压力下能撑更久。多节点部署有条件就把业务部署在多地域或多可用区配合DNS轮询或全局负载均衡即便单一节点被打瘫也能切流量到其他节点。但我要泼一盆冷水扩容只是延缓被击倒的时间并不能根治DDoS。面对动辄几百G的大流量攻击你本地服务器再扩容也是杯水车薪。所以扩容的正确角色是“为清洗节点争取时间”而不是“硬抗攻击”。5. 遇到DDoS时的应急实战流程理论讲再多不如把一次真实的应急过程拆开看。以下是我自己在一次攻击中实际操作过的流程整理成了标准步骤适用于大部分人遇到的“中小规模攻击”。5.1 第一步确认攻击特征别自己吓自己看到监控突然报警第一反应不是急着开高防而是先确认这到底是不是DDoS。我通过下面几个维度快速判断流量曲线如果流量在一分钟内飙升同时正常业务量没有上升大概率是攻击。请求来源分布正常用户请求的IP是分散的如果某个IP段或某些地区占比异常或是大量IP使用相同UA就要警惕。业务指标CPU升高、数据库慢查询增多、接口响应时间大幅上升但不是因为某个功能上线或活动推广这多半也指向攻击。我遇到过好几次“假警报”比如某个爬虫脚本跑挂了疯狂重试或者某个业务接口没有做缓存被用户频繁刷新流量特征看起来也吓人但本质不是DDoS。确认清楚再动手能省下很多不必要的购买和配置成本。5.2 第二步先拉黑再溯源如果确认是攻击最快速有效的止损手段就是精确封禁。不要试图用防火墙一条一条封几千个IP那样效率太低而且容易误伤。我的做法是先根据Nginx访问日志用awk按IP统计请求次数找出前100个高频IP然后批量写入防火墙黑名单。这一步能在几分钟内干掉一部分明显攻击。同时开启SYN Cookie、限制单IP并发连接数这些内核参数能缓解连接耗尽型攻击。# 示例统计Nginx日志中请求次数前20的IP awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20如果你比较熟悉系统配置可以临时调整内核参数来增强抗压能力# 开启SYN Cookie缓解SYN Flood echo 1 /proc/sys/net/ipv4/tcp_syncookies # 增大TCP半连接队列长度 echo 1024 /proc/sys/net/ipv4/tcp_max_syn_backlog但这些只是应急真正的解药还是要靠流量清洗。5.3 第三步接入高防切换解析如果攻击规模超过了你本地服务器的承受能力就不要再硬扛了。赶紧把DNS解析切到高防IP或者直接在CDN控制台开启DDoS防护。切解析之前一定要确认高防回源地址填的是你的源站IP并且源站防火墙只允许来自高防节点的流量访问否则攻击者一旦拿到源IP绕过高防直接打源站前面做的全是白费。有一个细节容易忽略DNS解析有TTL缓存切换后可能15分钟到几小时才完全生效。在这个“生效窗口期”里攻击可能仍然直接打到你的服务器上。所以务必备份好防火墙规则随时准备继续用你手上的IP封禁来拖延时间等解析切完之后再松口气。5.4 第四步事后复盘把攻击变成防御经验攻击结束后别急着关掉日志赶紧复盘。我通常会统计这些信息攻击峰值流量和持续时间对比高防防护阈值的设置是否合理。攻击主要属于哪一层是SYN Flood还是HTTP Flood分析攻击者的手法。哪些防护规则生效了哪些规则形同虚设需要怎么调整。业务侧有没有被误伤正常用户是否受到牵连验证码和频控的阈值是否需要优化。这些数据如果收集保存好会是你后续优化防御策略最重要的依据。6. 各层级攻击的排查与应对速查表为了日常查阅方便我把常见的攻击类型、特征、应急预案整理成一个速查表。这是我实际工作中使用频率很高的一个表你可以直接参考攻击类型典型特征初步应对手段长期防御建议SYN Flood大量半连接请求TCP队列被打满开启SYN Cookie调整tcp_max_syn_backlog接入防火墙SYN代理或高防UDP Flood大量UDP小包或大包带宽跑满丢弃非业务端口UDP包限制单IP UDP流量使用高防流量清洗HTTP Flood请求频率高多为动态URLUA异常Nginx层做频控封禁异常UA和IPCDNWAF组合频控慢速攻击连接建立后长时间不发送数据缩短超时时间限制单连接最大请求数开启slowloris防护模块DNS反射放大流量来源指向DNS服务器端口多为53关闭无关DNS端口限速源端口53高防清洗源站隐藏这个表里我只列出了我在实践中遇到的几种典型场景。实际攻击往往混合多种手法比如先SYN Flood打一阵子再转HTTP Flood让你防御措施还没来得及调整就被打穿。所以平时多做演练到了关键时刻才能快速反应。7. 长期防御体系的构建思路应急手段解决的是“正在被打”的问题长期防御解决的是“以后怎么少被打、被打不怕”的问题。我自己的实践经验可以压缩成下面几个核心点。7.1 隐藏源站是第一优先级很多团队买了高防却依然被轻松打穿原因十有八九是源站IP泄露了。泄露渠道通常有三个DNS历史解析记录。攻击者可以通过第三方历史DNS查询到切换前源站的IP。网站子域名。很多业务有管理后台、测试子域、API接口直接解析到了源站而忘了加防护。邮件头、源代码、证书透明度日志等。某些信息会无意中包含真实IP。所以长期防御的第一步不是买设备、买带宽而是做一次源站信息梳理。把公网可以探测到的所有入口全部收敛确保只有高防节点能够访问源站。7.2 CDN和高防不是同一个东西很多新手会把CDN和高防混为一谈。CDN的核心是缓存加速虽然也带一些DDoS防护能力但主要针对的是静态资源和网络层攻击。如果你的业务大量动态请求、计算密集CDN的防护能力就会大打折扣。高防则是专门为抗流量攻击设计的具备更强的流量清洗能力。合理的方式是两者结合静态资源走CDN动态请求走高防并通过一个各域的入口统一管理。这样既能保证速度又能获得更强的抗D能力。7.3 防火墙规则和WAF规则要分层我看到很多团队把所有安全的希望寄托在一台防火墙设备上这是个很大的误区。防火墙擅长基于IP、端口、协议做粗粒度过滤但面对应用层攻击时它看不到请求内容自然无法精准拦截。所以我会建议在防火墙之上再加一层WAF用于HTTP请求的深度检测。WAF可以通过规则识别恶意Payload、SQL注入、XSS、恶意爬虫等应用层攻击特征与防火墙的流量过滤形成互补。7.4 监控预警比扛住攻击更重要有的团队直到用户反馈“网站打不开”才知道被攻击了这种被动局面非常危险。我强烈建议搭建一套基于流量和业务指标的多维度监控告警体系至少包含以下指标总入向带宽、出向带宽超过阈值自动告警。Nginx的活跃连接数、请求处理速率与历史基线做对比。业务接口的响应时间、错误率异常时触发通知。系统层指标CPU、内存、TCP连接数、SYN_RECV状态数量。通过监控数据可以把攻击识别缩短到秒级而不是靠用户投诉来发现问题。8. 工具选型与成本思考不同预算怎么选方案关于防御工具市面上有各种名称和方案价格也是天差地别。我根据自己的实践和观察把不同预算的选型建议整理一下供参考。如果只是一个个人博客或小型创业项目预算有限那可以考虑使用有基础防护的云服务商所提供的免费DDoS防护服务配合CDN把攻击流量分散。同时自己用脚本做简单的IP封禁和频控。这套组合能扛住一些小规模攻击但面对大流量攻击时仍会力不从心。如果是正式商业产品预算有一定余量那么直接购买专业的高防IP服务是性价比最高的选择。建议按照业务峰值流量的3倍左右去购买防护带宽同时配置源站保护。这部分费用看似昂贵但比起被攻击后业务中断、用户流失带来的损失其实是划算的。如果业务规模较大、对稳定性要求极高那就需要考虑自建或者采购更高级的流量清洗系统配合多地域牵引、Anycast等方案。这一层已经属于运营商级别的防护不是一般团队自己能搭建的需要专业的网络团队支撑。还有一个很多人会忽略的成本点是攻击流量不只是外部对源站的流量还包括你回源到高防的流量。有些高防服务按“清洗后回源流量”另外计费如果业务本身流量就大这是一笔不小的隐性成本。购买之前一定要看明白计费规则。9. 我踩过的几个坑希望你避开理论讲完分享一下我真实踩过的坑。以下每一个都损失过时间、金钱或者数据分享出来希望大家少走弯路。第一个坑只测防护带宽没测并发连接数。高防服务商宣称100G防护能力买回来也确实能扛住大流量但攻击手法是大量慢连接耗尽服务器连接资源。结果带宽没打满服务却已不可用。后来才明白防护能力不是只有一个“带宽”维度并发连接数、连接速率、应用层请求速率都需要关注。第二个坑切换高防后忘改源站安全组。当时确认攻击后光速买了高防、切了CNAME结果忘了把源站的入口限制为只允许高防回源。攻击者顺着旧的解析记录找到源站IP直接打源站端口高防完全没起到作用。自那以后我把“源站保护”写进了应急清单切换后必查。第三个坑过度依赖IP黑名单。早期遇到攻击时我习惯于不断往黑名单里塞IP结果黑白名单越加越长正常流量也受到影响甚至某省份的用户因为我们封的IP段过宽直接无法访问。现在我做限频和封禁的规则都是动态的优先使用验证码来拖慢攻击者而不再简单粗暴地封IP段。第四个坑忽视了业务自身的健壮性。有一次遇到应用层攻击攻击者专门请求一个需要大量计算和查库的报表接口这个接口本身没有做频控和缓存服务商的高防也只做了网络层清洗没有针对这个接口做防护。结果高防没报警业务却已经变慢到不可用。从那以后我把核心接口的限流、缓存、幂等等设计纳入了研发规范这其实比任何安全设备都更有效。10. 写在最后的个人体会做了这一轮DDoS的实践和研究我最大的感受是DDoS防御没有一劳永逸的银弹它是一个持续对抗、持续优化的过程。今天你用IP限频挡住了攻击者明天他就换分布式代理今天你买了高防扛住了大流量明天他就学精了改用低频慢速攻击绕过规则。但换个角度想防御方也不是完全被动。攻击者的成本是持续攻击你的成本是持续优化。只要你的体系能不断根据攻击特征迭代让攻击成本远高于你防御的成本对方就会慢慢放弃你。所以我建议所有正在做在线业务的朋友不用追求一步到位的安全等级而是先打好基础隐藏源站、搭建监控、基础限频、备份应急方案。这些东西花不了太多钱但能在真正被攻击时为你争取到足够的时间去启动更高一级的防护方案。最后再分享一个习惯我每隔一段时间会自己做一次DDoS攻防演练用测试工具模拟半分钟的小规模攻击检验防护规则是否有效、告警是否及时。每次演练都能发现一些平时想不到的问题。有空你也可以试试。