凌晨三点值班手机响了。业务群里的截图一张接一张官网打不开、App请求全部超时、客服电话被打爆。我登录跳板机看了一眼流量图公网出口那条曲线直接拉成一条垂直的直线——从日常的每秒几十兆瞬间冲到每秒上百G。这不是我第一次处理DDoS攻击也不会是最后一次。DDoS攻击全称Distributed Denial of Service分布式拒绝服务攻击。这个名词在安全圈已经被反复讲过无数遍但每年依然有大量公司被它打得措手不及。原因很现实上手门槛极低攻击成本可以压得很低但防御成本却高得吓人而且攻击来源分布在全球各地溯源和封禁都极其困难。对刚入门的运维、开发和安全同学来说与其上来就背一堆术语不如先搞懂DDoS攻击流程——攻击者在每个阶段做了什么、为什么这么做、我们该在哪个环节挡住他。这篇内容就按这个思路来先讲清楚原理和类型再拆解攻击流程接着逐个分析三种核心攻击手法的识别与防御最后给出一条从零基础到能独立应急的实操路径。先说明一点此文只讲防守和合规实验不教任何攻击实操。所有压测和模拟内容请在自有环境或获得书面授权的环境中进行。未经授权对任何公网目标发起流量测试都是非法行为这一点没有商量余地。1. DDoS攻击的本质与危害1.1 什么是DDoS用一次事件讲明白DDoS攻击说白了就是你家店铺门口本来客流正常突然来了一帮人把门口堵死真顾客进不来店员也出不去生意彻底瘫痪。网络世界里的“堵门者”是一大群被控制的计算机、服务器、摄像头、路由器它们在同一时间向目标服务器的IP地址或域名发起海量请求把目标的带宽、连接表、CPU、内存全部占满。理解DDoS的关键在于“分布式”三个字。传统DoS攻击是一台电脑打一台服务器打死就死打不死就没办法。而DDoS是成千上万台设备协同作战分布在世界各地你封掉一批IP攻击者还能再换一批。更麻烦的是大量请求的源IP是伪造的或不断变化的你很难靠“拉黑某个IP”来解决问题。一次真实的DDoS攻击通常会有几个明显信号入口带宽瞬间打满、负载均衡器连接数暴涨、后端服务器CPU飙升、监控图上出现一个诡异的尖峰。如果攻击规模够大运营商层面的“黑洞”机制会被触发——上游直接把你的IP从路由中撤销等于把整个业务从公网上摘掉。那不只是网速变慢而是彻底断网。1.2 三种攻击路径与常见手法对比从攻击发生的网络层次来看DDoS攻击可以分成三类网络层攻击、传输层攻击、应用层攻击。它们的原理、打击目标和识别难度完全不同。攻击层面代表手法主要消耗资源识别难度网络层ICMP Flood、UDP Flood、反射放大带宽、流量清洗设备转发能力较低流量特征明显传输层SYN Flood、TCP连接耗尽协议栈内存、连接表、并发连接数中等特征可识别应用层HTTP Flood、慢速攻击、CC攻击CPU、数据库连接、业务接口容量高与正常流量难以区分网络层攻击是最“粗暴”的它不管你的应用是什么就是往你的带宽里面灌垃圾流量。传输层攻击稍有技术含量专门针对TCP握手机制让服务器把资源消耗在处理无效连接上。应用层攻击是现在的主流打法攻击者伪造出看起来完全正常的HTTP请求一个真人操作浏览器是什么样子它就模拟什么样子传统防火墙很难拦截。这三种路径经常混合使用。攻击者先来一波大流量把网络堵住再同时打应用层接口让清洗设备既要抗流量又要做应用过滤两边同时承压。防御方如果只懂堵一个维度很容易被声东击西。1.3 影响范围不只是网站卡顿那么简单很多人以为DDoS的损失就是“网站打不开的那几个小时”实际影响要大得多。最直接的是业务收入损失电商大促期间每中断一分钟都是真金白银游戏业务每次掉线都伴随用户流失支付和API服务被打停甚至会影响一整条供应链。DDoS还有一个非常容易被忽略的危害——它经常被用作烟雾弹。攻击者用大规模流量掩盖真正的入侵行为防守方所有精力都被引流到“抗流量”上忽略了正在发生的敏感数据窃取或后门植入。我处理过不止一个案例事后复盘才发现DDoS发生的同时一台数据库服务器已经被横向渗透。所以在应急响应时流量攻击只是表象必须同步排查是否伴随失陷和入侵痕迹。此外还有品牌信任层面的损失。用户不会管你是被攻击还是自己故障他们只知道“这家系统不稳定”。连续被攻击几次之后客户和合作伙伴都会产生疑虑。这也是为什么现在稍微正经一点的企业都会把抗D能力当作基础设施建设的一部分而不是出了事再临时找方案。2. DDoS攻击流程拆解从踩点到持续对抗2.1 侦察与信息收集先找到你的命门任何一次有组织、有规模的DDoS攻击都不是心血来潮直接开打。攻击者会先做侦察搞清楚目标到底有哪些资产、哪些IP对公网开放、是否有CDN兜底、源站IP能不能被挖出来。常见的侦察手段包括查询域名解析历史记录很多公司早期把源站IP直接暴露在DNS记录里搜索证书透明日志通过SSL证书反查IP暴力枚举子域名找到没有接入CDN的二级域名查看邮件头有些企业发信服务器与源站在同一IP段甚至同一台机器扫描开放端口确认哪些服务可以直接被攻击。这些手段在合规的渗透测试中同样会出现防守方必须用攻击者视角做“暴露面自查”把所有可能暴露源站的信息都收敛起来。这个阶段往往是整个攻防中防守方唯一的主动防御机会。如果对方通过DNS历史记录拿到了源站IP那就算你买了再贵的高防攻击流量也能绕过CDN直打源站清洗设备形同虚设。我见过太多这样的案例高防和CDN都配好了结果一封营销邮件的图片链接直接暴露了源站IP前功尽弃。2.2 火力组织僵尸网络与反射放大侦察完成之后攻击者需要组织“火力”。DDoS攻击的火力来源主要有两类僵尸网络和反射放大服务器。僵尸网络是大量被恶意软件控制的主机可能是用户的PC、企业服务器也可能是海量存在弱口令和已知漏洞的IoT设备比如摄像头、路由器、智能电视。这些设备被植入控制程序之后会等待攻击者下达指令在某一个时间点同时对目标发起流量。由于设备分布极广来源IP五花八门防守方无法通过简单封禁IP解决。反射放大攻击则是另一种更“取巧”的思路。攻击者伪造受害者的IP地址向互联网上大量开放的UDP服务发送一个很小的请求包这些服务会把响应包发送到伪造的源地址也就是受害者那里。比如NTP服务的monlist请求大约只有几十字节响应却能达到几百甚至几千字节放大几十倍历史上memcached服务曾经实现过几万倍的放大效果。也就是说攻击者只需要很小的上行带宽就能让受害者承受巨大的下行流量。对防守方来说反射放大最难办的在于流量来自大量正常服务的“无辜响应”你没法把全球的NTP服务器都封掉。这也是为什么容量型DDoS攻击的防御本质上是一场“资源不对称”的战争——你能做的只有两条路要么让上游帮你抗要么从源头上减少这类开放服务的暴露。2.3 攻击战术与时间线复盘侦察和备弹都完成之后攻击者并不一定会直接开足马力打过来。成熟的攻击者会先放一小波流量试探目标有没有防护、防御策略是什么然后针对性地调整手法。实际处置中我总结过三类典型战术节奏。第一种是脉冲式攻击流量每隔几分钟突然峰值爆发一下持续时间不长但反复出现目的是持续消耗应急人员的精力。第二种是混合攻击前面说的三种层次一起上让清洗设备同时应对大流量和复杂应用逻辑很容易出现某个环节被打崩。第三种是慢速持续攻击流量不大但一直不停拖住你的带宽和连接池让正常业务始终处于“勉强能用但很难受”的状态。如果把一次攻击完整地拉成时间线大概是这样时间节点事件00:00流量监控显示入口流量逐步爬升但还低于告警阈值00:08入口带宽接近上限部分用户开始反馈“网页打开慢”00:15CDN与高防清洗自动触发大部分流量型攻击被吸收00:22攻击者调整策略转向应用层接口发起HTTP Flood00:30后端服务CPU升高监控告警触发应急人员开始介入00:45全链路上限速配合WAF规则拦截异常请求业务逐步恢复01:10攻击停止开始留档、抓包、复盘这段流程想表达的是DDoS攻击不是一个瞬间动作而是一个持续对抗的过程。防御方如果只在流量被打满时才开始想办法就已经慢了一步。真正的抗D能力是提前知道自己的暴露面在哪、设备承受极限是多少、每一步操作由谁执行。3. 三种核心攻击手法原理防御者必须认识的敌人3.1 SYN Flood最经典也最头疼的半连接攻击TCP连接建立靠三次握手客户端发SYN服务器回SYN-ACK客户端再回ACK连接建立。问题就出在服务器收到SYN之后会为这个“半连接”分配资源并进入SYN_RECV状态等着客户端的最后一步确认。SYN Flood就是利用了这个机制。攻击者发送大量带有伪造源IP的SYN包服务器收到后回应SYN-ACK但由于源IP根本不存在永远不会收到ACK于是这些半连接一直占着服务器资源。当半连接队列被塞满之后真正的用户再来建立TCP连接就进不来了。你可以把它理解为一家餐厅被大量只订座却不来吃饭的客人刷爆了排号系统真正排队的顾客反而无法入座。防御SYN Flood最有效的手段之一是开启TCP SYN Cookie。开启后服务器不再为每个半连接分配完整资源而是用加密算法生成一个序列号作为“cookie”返回给客户端只有客户端的ACK验证通过后才真正建立连接。对于Linux系统可以直接配置# 开启TCP SYN Cookie sysctl -w net.ipv4.tcp_syncookies1 # 调整半连接队列长度 sysctl -w net.ipv4.tcp_max_syn_backlog2048在实际排查中如果你发现服务器上大量连接处于SYN_RECV状态而且数量还在持续增长基本可以怀疑是SYN Flood。此时除了开启SYN Cookie还要联系上游做流量清洗因为光靠单机优化扛不住超大流量。3.2 反射放大攻击小入口打成大风暴反射放大攻击是当前流量型DDoS的绝对主力。原理我在前面讲过攻击者伪造受害者的源IP向互联网上大量UDP服务发送小请求服务回复的大响应全打在受害者头上。这里有个关键点要想明白为什么攻击者要选UDP服务因为TCP要经过三次握手源IP没法轻易伪造你发出去的请求会被真实的服务端拒收。而UDP是无状态的数据包发出去就不管了服务端只看包里的源IP字段就回复给了攻击者可乘之机。容易被利用的服务有很多DNS、NTP、SSDP、memcached、CLDAP等。它们的放大倍数从几十倍到几千倍不等。一个简单的计算逻辑是攻击者如果有10Gbps的上行带宽经过100倍的放大就能让受害者承受1Tbps的流量这种体量几乎可以打垮任何没有高防的普通机房。防守端能做的有限但很重要。第一是在自己管理的网络里关闭不需要对公网开放的UDP服务别让自己变成攻击的“帮凶”第二是在网络边界部署源地址校验策略减少伪造源IP的流量进入公网第三是给目标服务配上足够带宽的流量清洗能力让反射放大流量在清洗中心被吸收掉。识别特征也很明显入向流量突然暴涨、同一时间大量来源不同的UDP包打到同一个端口、包大小异常。3.3 应用层攻击最难识别的HTTP Flood与慢速攻击如果说前两种攻击是“用蛮力打人”应用层攻击就是“贴身毒针”它不依赖高带宽却能精准打穿业务系统。最常见的两类是HTTP Flood和慢速攻击。HTTP Flood模拟正常用户的浏览器行为向目标页面和接口发起大量GET或POST请求。这类请求单看每一个都可能是合法的来源IP也可能来自真实肉鸡和正常用户混在一起传统防火墙根本判断不出来。防御手段需要结合动态基线学习一段时间内正常访问的QPS、请求路径分布、参数特征出现明显偏离时启动人机识别、客户端验证、限速等动作。这里有一个常见的Nginx层基础限速配置模板可以拦截掉一部分低成本的刷量请求http { limit_req_zone $binary_remote_addr zonereq_limit:10m rate10r/s; server { listen 80; server_name yourdomain.com; location / { limit_req zonereq_limit burst20 nodelay; proxy_pass http://backend; } } }慢速攻击的代表是Slowloris。它不发送大量请求而是建立连接后只发请求头的一小部分然后慢慢吞吞地“挤牙膏”让服务器一直等它传完。服务器维持这种不完整的连接是有上限的连接池被占满后正常用户请求也连不进来。防这东西的核心是调短超时时间、限制单IP并发连接数、在七层代理层做会话管理。识别时要注意连接数很多但每个连接的速率都很低Keep-Alive时间被拉到很长明显不符合正常人浏览网页的行为模型。应用层攻击的复杂性在于“像用户”本质是一场对抗检测器的猫鼠游戏。没有一劳永逸的规则必须结合业务做接入层防护、人机识别和后端限流层层设防。4. 零基础到精通的防御实操路径4.1 基础安全卫生先收敛攻击面不少公司一上来就买高防、买清洗却把源站IP和保护范围漏得干干净净防护自然形同虚设。防御DDoS的第一步不是堆资源而是把不必要的攻击面收起来。先做三件事。第一关掉一切不需要对公网开放的服务和端口尤其是容易被反射利用的UDP端口DNS、NTP、SNMP、memcached等没必要对外就不监听第二把对外服务的入口统一收口主域名全部走CDN或者高防源站只允许CDN的回源IP访问用防火墙或安全组做白名单第三自查信息泄露把历史DNS记录、证书日志、子域名、邮件头全部排查一遍确保没有任何途径能查到源站的真实IP。还有个很容易忽略的点源站IP不要和其他服务共用。很多人把网站源站和邮件服务器、监控服务器放在同一台机器或同一个IP上攻击者只要从邮件头或其他渠道拿到这个IP就能绕过所有前端防护直接打过来。合规的做法是源站和内网管理、业务运维通道彻底隔离公网只留必要的出入口。4.2 搭建自己的DDoS实验环境想要真正理解DDoS攻击流程纸上谈兵远远不够。我强烈建议你在隔离的虚拟网络里搭一个最小实验环境亲手做一次“模拟攻击与防御”的演练这比看十篇文档都有用。实验环境很简单用虚拟机开两台机器一台部署Nginx和一个简单Web服务作为“目标”另一台作为“客户端”执行压测。虚拟网络设置为仅主机模式确保流量不出物理机不会对公网产生任何影响。客户端压测可以用wrk、ab这类性能压测工具。注意这些工具本身是给性能测试用的但在本地实验环境中它们能很好地模拟高并发场景。# 目标机器启动简单服务 docker run -d -p 80:80 nginx:alpine # 客户端机器压测 wrk -t4 -c200 -d30s http://192.168.56.101/我建议你边压测边观察几个指标目标机的CPU使用率、内存占用、TCP连接状态、Nginx活跃连接数。反复几次之后你脑子里会建立起一个清晰的印象并发连接数升到多少时系统开始变卡CPU先是哪个进程被打满连接表占用多少就开始异常。这些数据就是日后你做容量规划和应急判断的底数。还要加一个“暂停”训练在压测进行中手动执行tcpdump抓包再打开Wireshark看TCP握手过程理解SYN、SYN-ACK、ACK的交互。只有真正看过正常握手和异常半连接的区别你才能一眼认出攻击流量长什么样。4.3 引入云高防与流量清洗自建防护能扛住中小规模的攻击但面对几十G甚至几百G的流量冲击单机房、单台设备的方案根本顶不住。大带宽的价格摆在那里普通公司不可能为了防一次攻击买几百G的独享带宽。所以现实的做法是自建防护做基础过滤云高防和流量清洗中心扛大流量。云高防的原理大致两条。一种是DNS引流把业务的域名解析切到高防IP所有流量先到达清洗中心清洗后再通过专线或隧道转发给源站。另一种是BGP引流适合有自有AS和IP段的情况把整个网段路由公告切到清洗中心攻击流量被牵引过去过滤之后再回注。对大多数中小企业来说直接用高防IP加CDN的组合就够用。选择高防方案时有几个容易踩的坑。第一不要只盯着防御峰值买要看清洗能力是否足够以及清洗策略能不能满足业务类型比如有没有针对UDP反射的专业清洗第二一定要测试切换时间DNS引流通常有几分钟的生效延迟BGP引流快一些但这个时间差必须在业务可接受的范围内第三注意高防IP被攻击时是否可能触发“黑洞”一些高防会在流量超过阈值后直接把IP封黑洞等于是“断臂求生”如果业务不能接受就要配置更高规格的套餐或分线路容灾。4.4 应急响应流程与常态化演练即使防护做得再好也要做好被攻击的准备。我处理过几十次DDoS事件最常见的失败原因根本不是技术不行而是没有预案、没有明确的处置权限、不知道先联系谁。一份可用的应急流程至少要包含几个环节确认告警、判断攻击类型和规模、联系机房或云厂商、切换防护策略、封禁异常来源、留档取证、恢复业务、复盘改进。流量攻击的处置窗口非常短每一步都最好提前定好责任人。我的习惯是准备一张表格里面写好每个人的电话、备份人、高防管理后台账号权限、机房联系电话平时锁在值班流程文档里战时直接拿出来执行。定期演练也非常重要。每季度选一个低峰时段在测试环境模拟一次攻击和切换流程让轮值的运维和安全人员实际操作一遍。只有练过才能在真实攻击来临时保持冷静。现实中太多团队是第一次被攻击时还在群里问“高防控制台密码在哪”这种场景见过一次就不想再见第二次。5. 常见问题与排查技巧实录5.1 页面访问变慢流量图异常先看什么收到“网站很卡”的反馈不要急着登录服务器敲命令。先看一眼时间维度的监控曲线分清是持续升高还是突然暴增。突然暴增大概率是攻击持续升高可能是业务高峰或代码问题。我的排查顺序是先看出口带宽和网络流量是否打满再看四层连接数和SYN_RECV状态最后看Nginx和应用日志。先排除网络层和传输层再处理应用层这样可以避免被假象误导。如果入口带宽类指标正常但请求响应很慢问题往往出在后端应用、数据库或缓存别把什么锅都甩给DDoS。5.2 大量SYN_RECV和大量TIME_WAIT分别说明什么SYN_RECV在正常业务中很少大量堆积。如果几百甚至几千个连接长时间停在SYN_RECV状态几乎可以断定是SYN Flood立刻确认是否开启tcp_syncookies同时联系上游清洗。TIME_WAIT是正常情况TCP连接关闭后都要在这个状态停留一段时间但数量巨大时也值得关注。它通常说明短连接请求非常多比如负载均衡到后端的连接频繁建立与断开或者后端响应过慢导致连接迟迟无法关闭。这种情况要做的是调整连接复用、提高后端处理速度而不是误判为攻击。5.3 明明上了CDN为什么源站还是被打到了源站IP暴露是最常见的“防御失灵”原因。查一下是否有子域名没有接入CDN历史DNS记录里有没有源站IP邮件头、证书日志、第三方合作方页面代码里是否泄露了真实IP。很多公司源站被人轻易扫出来就是因为营销邮件用源站域名发信邮件头里直接把服务器IP透露了出去。解决方法也很直接源站安全组只放行CDN回源IP段任何非CDN来源的访问全部拒绝把源站和其他业务彻底剥离开定期用信息泄露监测工具做扫描发现暴露源站的信息立即清理。5.4 高防IP都被打穿了怎么办流量超过高防清洗能力时高防厂商可能触发黑洞这时候不是“继续加钱”就能立刻解决的。第一步先做减法按地理位置封禁攻击来源集中的区域按用户代理和请求特征封禁明显的异常流量在源站层面再叠加一层限流。先让业务回到可用状态再考虑升级套餐或切换清洗线路。更稳妥的做法是提前设计冗余。比如同时使用两个高防服务商或者业务多机房异地部署通过DNS和负载均衡调度流量。攻击一般集中在某个IP或线路冗余架构能把影响圈在局部不会整条业务线一起瘫痪。5.5 几个值得长期坚持的好习惯防御DDoS不是一次性的采购而是持续投入的过程。我建议团队长期维护三类资产监控基线和告警阈值至少要有一年的流量、连接数、CPU趋势数据阈值设置才能合理压测记录每次在测试环境做完压测都记录当时的系统极限指标日志留存网络层抓包和应用层访问日志至少保留90天事后溯源和复盘都靠它。最后说句实在话处理过这么多次DDoS事件我最深的体会是真正让人崩溃的往往不是那个峰值流量数字而是突发攻击时找不到责任人、没有预案、不敢拍板切换流量。技术方案是可以买的但组织能力和流程习惯必须自己长期练。如果你现在还在零基础阶段不用着急啃那些复杂的攻防框架。先搭个实验环境把TCP握手、SYN Flood、HTTP请求这些基础概念亲手验证一遍再把自己的业务资产盘一遍找出所有可能暴露源站的口子最后写一份简单但可执行的应急预案哪怕只有一页纸也比事到临头开电话会议强得多。DDoS攻击会一直存在但通过扎实的基础训练和提前规划你真的可以做到“它打它的我稳我的”。