DDoS攻击流程与防御实战：从流量特征到应急响应

这两年“DDoS”这个词的讨论热度一直没降过，但真要问一句它到底是怎么运作的、攻击流程分几步，不少干了好几年运维的人也说不太全。市面上的资料要么太理论，上来就丢协议栈，要么太零散，教你几个命令就没了下文。这篇文章我不打算念概念，而是按实际处置攻击事件的思路来拆解，从流量特征、排查手段、防御配置这几个角度讲清楚，目标是让你看完之后，再遇到服务突然卡死、带宽被打满这类事情，心里能有一个清晰的应对顺序。

无论你是刚接触安全的零基础新人，还是要做技术方案选型的负责人，这篇文章都适用。前半部分偏认知，帮你建立起对DDoS攻击流程的完整理解；中段讲实操，给了可以直接抄的监控和排查命令；后半段是防御体系搭建和真实事件复盘。内容比较多，建议先收藏再细看。

1. 先搞清楚DDoS攻击的本质与完整攻击流程

1.1 一句话理解DDoS：不是撬锁进门，而是把大门堵死

很多初学者有个误区，觉得DDoS攻击和数据库注入、弱口令爆破一样，是黑客在“找漏洞破门而入”。这个理解方向就错了。DDoS的核心逻辑是：我不需要进入你的系统，我只需要让你的系统无法为正常用户提供服务。

打个比方，你家饭店本来营业得好好的，突然来了一千个人堵在门口，只站着不消费，也不走，真正的顾客进不来。你的后厨、服务员、座位全空转，但营业收益归零。这就是DDoS——分布式拒绝服务。攻击者不在乎你的程序有没有漏洞，他们的目标是耗尽你的网络带宽、连接数、CPU处理能力，让服务器没有余力响应正常请求。

理解这个本质非常重要，它决定了防御思路。既然是堵门，防御的核心思路就是“如何不让这些闲杂人等堵住门口”，要么在门口提前设卡过滤掉可疑人员，要么把门口扩大让正常顾客绕路进来，要么直接把饭店搬到一个不怕堵的位置。

1.2 攻击流程拆解：一次典型攻击是怎么展开的

站在防御者的角度，看清攻击者的“作战流程”，才能知道自己的防线该设在哪一层。一次完整的攻击行为，通常分四个阶段。

第一阶段是信息搜集与目标分析。攻击者需要确定目标网站或服务器的IP地址、开放端口、使用的Web服务软件、带宽大小、是否有CDN或高防在前面挡着。这个阶段一般不会产生流量攻击，攻击者在暗处悄悄摸排，防御方很难感知。比较头疼的是“源站IP泄露”问题，很多高防方案都因为源站地址被挖出来而失效。

第二阶段是攻击资源准备。体积型攻击需要大量的流量，攻击者会先搭建或租用可以由一台控制端统一指挥的僵尸网络（被植入后门的设备集群），或者直接购买现成的“攻击服务”。这个阶段也不打流量，但攻击资源已经在暗处集结完毕。

第三阶段是流量编排与发包。控制端下发指令，成千上万台僵尸设备同时向目标发送精心构造的数据包。这里有两种典型思路：一种是纯流量型，直接把带宽打满，让正常的TCP握手都无法完成；另一种是协议漏洞型，利用TCP协议握手机制中的漏洞，用极小的流量撬动服务器极大的资源消耗。

第四阶段是持续消耗与动态绕过。攻击者不会傻傻地用一个姿势打到底。当你封了一批IP，他会换一批新IP；当你开启了CDN防护，他会尝试直接打源站IP；当你加了WAF拦截规则，他会换一种没那么规则的流量特征。防御与攻击的对抗，在这个阶段会拉长到几小时甚至几天。

需要强调的是，这里分析的是攻击行为模式，目的是让你理解“对手在做什么”，而不是教你如何发起攻击。真正有价值的防御知识，恰恰建立在对这些行为特征的认识之上。

1.3 三类最常见的攻击类型对比

虽然DDoS的变种很多，但万变不离其宗，绝大部分攻击都能归到下面三种类型里。

三种类型最直观的区别可以这样记忆：体积型攻击是“用卡车拉沙子倒在你家店门口”，协议型攻击是“伪造一万个影子顾客排队却从不结账”，应用层攻击则是“几个真人轮流点单但就是不付款，把服务员全部耗住”。

真实世界的攻击往往不是单挑其中一种，而是组合上阵。有的攻击者先打体积型把防护设备挤爆，再切协议型突破内核资源，最后再上应用层精确打击。所以防御方案也必须分层部署，不能指望单点解决。

2. 攻击发生时如何快速识别：监控指标与排查命令

2.1 五类关键监控指标及其异常表现

很多团队的监控告警只覆盖CPU、内存、磁盘三项基础指标，等告警响了才发现业务已经挂了。实际上DDoS攻击的早期信号就藏在这些指标里，但你需要知道看什么以及怎么看。

第一类是带宽使用率。平时峰值只有100Mbps的服务器，突然跑到800Mbps甚至打满千兆端口，这是最典型的体积型攻击信号。带宽指标要通过交换机端口流量或云服务商的监控面板查看，服务器内部的iftop也能看，但注意它看到的是服务器网卡流量，云厂商的带宽数据往往更准确。

第二类是TCP连接状态分布。正常的服务器，ESTABLISHED连接数占绝大多数，SYN_RECV（半连接）数量很少。如果SYN_RECV突然冲到几万甚至几十万，说明有人在用SYN Flood攻击你——因为正常用户不会只发握手请求不完成连接。

第三类是CPU与内存的消耗模式。应用层攻击的特点是CPU使用率异常飙高，尤其是Web服务进程的CPU占用。如果发现Nginx或Tomcat进程CPU跑满，但数据库进程CPU正常，大概率是请求量太大导致业务逻辑层过载。

第四类是应用响应时间。从99分位延迟从200ms飙升到5秒以上，往往是攻击流量已经穿透了前面的网络防护，打到了应用层。这个指标比单纯的CPU更能反映用户体验。

第五类是日志与访问模式的异常。短时间内大量来自同一地区或同一网段的请求、请求路径集中在某个特定接口、User-Agent字段为空或高度统一，这些看起来是“业务增长”的现象，实际可能是程序化脚本在刷量。

2.2 现场排查的完整步骤与常用命令

当告警响起，不要慌，按照下面的顺序逐步排查，每一分钟都花在刀刃上。

第一步，先看系统负载和网络吞吐，确认“到底有没有被打”。

bash复制# 查看系统负载和CPU占用
top

# 查看网卡实时流量（每秒刷新）
sar -n DEV 1 5

# 查看网络连接统计
ss -s

如果top显示CPU用户态占用不高但load average异常，或者sar显示网卡流量飙到带宽上限，就说明流量已经打到服务器了。

第二步，查看TCP连接状态分布，判断是协议型还是应用层攻击。

bash复制# 统计各连接状态的数量
netstat -ant | awk '{print $6}' | sort | uniq -c | sort -n

# 只查看半连接数量（SYN_RECV）
netstat -ant | grep SYN_RECV | wc -l

如果SYN_RECV数量超过几千，而且持续增长，基本可以确认是SYN Flood。如果ESTABLISHED连接数量暴增到几十万，而CPU也跑满，更可能是应用层连接耗尽型攻击。

第三步，抓包看流量特征，锁定攻击类型。

bash复制# 抓取web端口的数据包，保存到文件（抓100秒）
tcpdump -i eth0 -nn port 80 -c 10000 -w /tmp/attack.pcap

# 查看抓到的包，分析源IP分布
tcpdump -nn -r /tmp/attack.pcap | awk '{print $3}' | sort | uniq -c | sort -n | head -20

抓包这一步很关键。如果源IP高度集中，说明攻击源有限，可以做IP封禁；如果源IP极度分散且每个IP请求数差不多，说明是僵尸网络，封IP没什么效果，需要走流量清洗方案。

第四步，联系云服务商或机房查看流量报表。大多数攻击在进入机房层面时，云厂商已经能观测到异常流量。他们会有一线巡检人员，可以协助你确认攻击是否还在持续、峰值流量多少、当前清洗策略是否生效。这一步别省，能让你少熬好几个小时。

2.3 别把业务波动误判成攻击：三条区分经验

我见过不少团队在业务高峰期间把正常流量当成攻击来“防御”，结果误杀了真实用户，人财两失。判断是不是攻击，不能只看“量大了”，要看“质变”。

第一条经验是看时间曲线是突发还是渐变。攻击流量通常在几十秒甚至几秒内突然飙升，曲线几乎是90度垂直向上；而业务高峰通常是平缓上升，随着用户活跃时间慢慢爬升。如果凌晨三点带宽突然飙升，那绝对不会是用户自然行为。

第二条经验是看来源IP分布。正常的用户访问来自全国乃至全球各地，分布比较分散；攻击流量往往集中在某个IP段、某个地区IDC段，或者IP分布极其规律（比如递增序列）。在日志里抽样看几百条访问记录，来源情况一目了然。

第三条经验是看请求内容是否有规律。攻击流量为了追求效率，通常是重复的固定请求，比如反复请求同一个URL、同一个参数，或者UA字段都指向同一个工具库。正常用户会浏览不同页面，点击不同链接，行为自然多元。

把这三条经验放在一起判断，基本能避开“狼来了”的误判。如果实在拿不准，还有一个土办法：在服务器上临时拉一条iptables规则拒绝某个可疑IP段的访问，观察整体流量曲线是否明显回落。回落了就是流量来源，没动静就说明它不是主力。

3. 防御体系怎么搭：从托底到精细化的四层配置

3.1 第一层：网络与系统基础加固（免费但必须做）

很多团队一上来就上高防IP，反而忽略了系统自身的基础加固。其实这一层不需要花钱，只需要正确配置内核参数，就能抵御相当一部分小规模攻击。

以Linux服务器为例，针对SYN Flood最有效的内核配置是开启SYN Cookie，同时调大半连接队列和减小SYN重试次数。

text复制# /etc/sysctl.conf 追加以下配置

# 开启SYN Cookie，防止SYN Flood耗尽连接表
net.ipv4.tcp_syncookies = 1

# 增大半连接队列长度
net.ipv4.tcp_max_syn_backlog = 8192

# 减少SYN重试次数，让被占用的资源尽快释放
net.ipv4.tcp_syn_retries = 2

# 开启TIME-WAIT端口复用，提高新建连接的效率
net.ipv4.tcp_tw_reuse = 1

# 设置TCP快速回收（仅确认无NAT问题时开启）
net.ipv4.tcp_tw_recycle = 0

修改完成后执行 sysctl -p 生效。注意tcp_tw_recycle在现代内核中存在诸多争议，容易导致NAT环境下丢包，建议保持为0，不要盲目照搬老文章里的配置。

Web服务层面，也需要调整两个关键参数：连接超时和最大并发数。以Nginx为例：

nginx复制# 缩短连接超时时间，让攻击者挂着的连接尽快释放
keepalive_timeout 10;
client_header_timeout 5;
client_body_timeout 10;
send_timeout 5;

这些参数的意思是：客户端如果5秒内没发送完请求头，服务器就主动断开。慢速攻击（Slowloris）就是利用默认的60秒超时来长期占用连接，把超时调短后，它的攻击成本会大幅上升。

3.2 第二层：入口处的流量调度与清洗

基础加固只能解决小规模攻击，当攻击流量达到Gbps级别，系统本身已经扛不住了，这时候必须在入口处把流量“洗”一遍再放进来。

目前最主流的方案是DNS解析到高防IP或CDN节点。高防机房拥有几十Gbps甚至上百Gbps的带宽冗余，并且部署了专业的流量清洗设备。当攻击流量到达高防机房的入口时，设备会通过流量特征识别、数据包深度检测、行为分析等手段，把攻击流量过滤掉，把正常流量转发回源站。

使用这套方案的核心注意事项是：源站IP绝不能暴露。如果攻击者拿到了源站IP，可以直接绕过清洗设备打源站，所有防护配置瞬间作废。常见的泄露途径有DNS历史解析记录、邮件投递的原始IP头、SSL证书信息泄露等。用高防方案之前，先自查这几项，别等被打穿了才后悔。

如果预算有限，也可以选择“轻量级CDN+源站防火墙”的组合，让CDN节点负责隐藏源站IP，然后在源站防火墙配置只允许CDN节点IP段访问。这样攻击流量直接打CDN节点，CDN有自己的抗DDoS能力，源站相对安全。当然，这个方案对HTTPS证书管理要求更高，需要做好在CDN和源站两侧的证书同步。

3.3 第三层：应用层的限流与规则拦截

比网络层更麻烦的是应用层攻击，因为它的流量特征和正常用户几乎一致，清洗设备很难在入口处将它识别出来。这一层必须在应用侧做精细化控制。

应用层限流的思路是“给每个用户设定行为上限”。以Nginx的limit_req模块为例，它可以实现“同一IP每秒最多N次请求”的限制：

nginx复制# 定义限流区域：每个IP每秒最多处理10个请求，超出后排队，缓冲区大小为20
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

# 在需要保护的location中使用
location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    proxy_pass http://backend_servers;
}

这里rate=10r/s的意思是每个IP每秒最多允许10个请求，burst=20表示允许瞬间突发20个请求排队，nodelay表示排队中的请求如果超出缓冲区直接返回503。这个阈值要根据自身业务评估，比如你的正常用户可能每秒只调用2~3次接口，定10r/s就是合理的；如果业务本身是高频接口，定10r/s就会误伤。

除了限流，WAF规则也是应用层防御的利器。开启WAF后，可以拦截特征明显的攻击请求，比如UA字段异常、URL包含恶意参数、请求频率远超人类行为规律等。注意WAF误报问题，部署后要观察几天真实业务流量，及时调整规则优先级。

还有一种比较实用的思路是“人机验证”。当检测到某IP的请求频率超过阈值时，返回一个JS挑战页面或滑动验证码，正常用户几秒钟就通过了，脚本化攻击却很难快速完成验证。这种方法对HTTP Flood的拦截效果非常突出，代价是正常用户体验稍微打折。

3.4 第四层：应急预案与团队协作

技术配置不等于防御体系，应急响应流程同样重要。很多团队在网络攻击发生时手忙脚乱，原因就是没有一个明确的作战手册。

一份可用的应急预案至少应该包含五个要素：明确的告警触发条件（如带宽超过70%持续3分钟）、应急小组人员名单与联系方式、分级响应策略（哪些攻击级别需要直接切高防、哪些需要封禁IP）、与云服务商/高防服务商的对接方式、事件结束后的复盘模板。

这里分享一个我自己的经验：每当有新服务上线，我会先做一次“模拟攻击演练”——在预发环境人为制造一次大流量请求，检验监控告警是否能准确触发、限流规则是否符合预期、应急响应流程是否顺畅。很多预案写得漂亮，一演练就露馅，早发现总比真被攻击时才发现强。

4. 一次模拟攻击事件的完整复盘（虚构案例）

4.1 事件时间线与处理动作

为了让你更直观地理解攻防过程，我用一个虚构案例来还原整个事件。某电商平台（暂称为模拟项目X）在一次促销活动当天，业务流量较平时上涨了3倍，监控团队正忙着盯容量规划，结果下午两点左右，攻击来了。

14:02，网络监控告警弹出“公网入口带宽已达1.2Gbps”，而业务真实的QPS增长只解释了0.3Gbps。监控值班人员立即启动应急预案。

14:05，运维工程师登录两台中游Nginx节点，执行了netstat -ant统计连接状态，发现SYN_RECV数量从基线200涨到了3.8万。同时查看top确认CPU还没达到瓶颈，判断这是一次“体积型+协议型”的混合攻击。

14:10，按预案启动高防切换，把DNS解析的TTL改小后，将域名切到高防IP。同时通知安全负责人拉群同步进展。

14:25，高防服务商反馈“清洗任务已开启，入口流量回落至正常水平”。但业务还没恢复，应用监控显示商品详情页的P99响应时间从300ms涨到了4秒。查看Nginx日志发现，请求量确实降低了，但请求路径集中在“秒杀接口”，QPS高达正常值的20倍。判断攻击者见高防挡住了网络层，立刻切换策略，用囤积的僵尸网络打应用层。

14:40，安全团队在WAF上启用了“秒杀接口”的针对性规则：非登录用户的请求拦截率提高至40%，同IP请求频率超过5次/秒直接触发验证码。同时在后端服务上加了一层Redis限流器，保证单用户每秒最多请求3次。

15:10，攻击流量持续下降，各监控指标逐步回归到正常水位。复盘发现，整个攻击持续约70分钟，峰值流量5.2Gbps，应用层最高QPS达到2.4万，最终由于多层防御协同工作，数据库和核心支付系统未受影响。

4.2 复盘结论与可复用检查单

这个案例最值得学习的地方，在于攻击者在被高防拦截后迅速切换攻击方式，而防御方同样有层级化的应对策略。把它抽象成可复用的检查单：

• 监控告警必须分级：网络层告警、系统层告警、应用层告警分开看，不混在一起，否则定位问题会耗掉大量时间。
• 高防切换流程必须提前演练：DNS的TTL值、切换后的观测窗口、回切条件都要写清楚。
• 业务接口要区分“关键路径”和“非关键路径”：秒杀、登录、支付这类接口要单独设置更严格的限流，不能和普通浏览用同一套阈值。
• 攻击结束后不要立即恢复配置：攻击者可能观察你回切的动作，等待你放松警惕后再打一波。至少保持高防和WAF防护24小时再逐步回切。
• 记录所有关键操作的时间点和执行人：以便事后复盘，定位哪一步执行慢、哪一步决策有问题。

4.3 应急处理中容易踩的三个坑

第一个坑是急着封IP而不查流量。攻击流量大时，很多人第一反应是写脚本把当前高并发IP全部封掉。但伪造源IP的攻击者可以瞬间换一批IP，你封了十万个IP他还是一样打。正确做法是先抓包确认攻击类型，再决定封禁策略，顺序搞反了，纯粹白忙活。

第二个坑是源站IP已经泄露却不懂隐藏。很多团队在域名刚接入CDN时没有修改服务器防火墙规则，导致源站端口对全网开放。攻击者通过“端口扫描+历史DNS记录”就能摸到源站。正确做法是在接CDN或高防后，把服务器防火墙改成“只允许来自CDN节点IP段的流量进入”。

第三个坑是限流阈值拍脑袋。有的团队给所有接口统一设置每秒2次的限制，结果是正常用户频繁被503拦截，投诉率直线上升。限流阈值必须根据业务的实际QPS分布来确定，先观察一周的正常流量数据，再取一个“正常用户不会被误伤，但脚本攻击会明显触顶”的中间值。

5. 常见问题快速排查手册

6. 安全学习的正确姿势与一点个人体会

最后说点与技术无关但很要紧的内容。DDoS相关的知识，学它的目的是防御，而不是攻击。理解攻击流程、流量特征、协议漏洞，本质上是为了更好地保护自己的业务、用户和数据安全。拿着学到的技术去攻击别人的系统，不仅违法，而且对个人技术成长的危害远大于收益——真正值钱的能力，永远是在“如何快速恢复业务”“如何精准识别风险”这些防御向场景中磨出来的。

我自己刚接触这一行的时候也走过弯路。最早以为防御就是封IP，结果手动封了几百个IP，攻击一点没停，最后不得不硬着头皮联系机房做黑洞路由，业务中断了大半天。那次经历让我明白了一个道理：防御的核心不是和攻击者拼单点动作，而是把网络层、系统层、应用层配合起来，再叠加一个靠谱的外部清洗入口。这篇文章里的配置和检查单，建议你存在自己的知识库里，先在一台测试服务器上模拟一遍，等真正遇到攻击的时候，你会发现“心里有底”这四个字有多重要。

最后再分享一个小技巧：每季度或半年，选一个业务低峰期，主动做一次限流和清洗的演练。花一天时间换来的熟悉度，比起事发当天的熬夜查日志，划算太多。