DDoS防护实战：从攻击场景到CDN、WAF与API防护体系搭建

DDoS防护API防护CDN

于 2026-10-01 04:06:04 修改

·本内容遵循CC 4.0 BY-SA版权协议

1. 从真实攻击面出发：DDoS防护的认知重构

聊DDoS防护之前，我想先抛一个观点：绝大多数团队对DDoS的理解，还停留在“流量大了就加带宽”的阶段。这个认知在2015年之前或许够用，但放到今天，攻击者早就不跟你拼流量峰值了。他们打的是你的业务逻辑、你的API接口、你的连接状态表，甚至是你的运维人员注意力。

我经历过一次典型的混合攻击：攻击者先用小规模UDP反射把监控告警拉满，运维团队忙着看流量图的时候，真正的杀招是针对登录接口的慢速POST请求——每个请求只占几百字节，但持续占用后端数据库连接池。等我们反应过来，数据库连接已经耗尽，整个业务停了将近四十分钟。这次教训让我彻底改变了对DDoS防护的认知框架。

所以这篇文章，我想从典型攻击场景入手，把DDoS这件事拆开揉碎，讲清楚不同层面的攻击长什么样、怎么识别、防护重点在哪里。涉及到的关键词包括DDoS、API防护、CDN、WAF，也会聊到内网攻防防护和爬虫防护的交叉地带。无论你是刚接触安全运维的新手，还是已经有一定经验但想系统梳理防护体系的从业者，这篇内容应该都能给你一些可以直接落地的参考。

提示：本文讨论的所有攻击场景和防护手段，均基于公开的攻防演练环境和合规的安全测试框架，目的是帮助读者理解防护原理、提升防御能力。

2. DDoS攻击的典型场景拆解

2.1 流量型攻击：最“笨”但最直接的方式

流量型DDoS是最容易被理解的一类攻击。攻击者通过控制大量分布式节点，向目标IP发送海量数据包，把带宽打满，让正常用户根本挤不进来。常见的子类型包括UDP洪水、ICMP洪水、DNS放大、NTP放大等。

这类攻击的特点很鲜明：流量曲线陡增、协议特征明显、源IP高度分散。我见过最夸张的一次，入口流量从平时的200Mbps直接飙到40Gbps，整个机房的上联链路瞬间饱和。但说实话，这种攻击反而是最好防的——因为它的“噪音”太大了，任何有基本流量清洗能力的CDN或云清洗中心都能识别。

防护重点在于：带宽冗余 + 流量清洗 + Anycast分散。如果你的业务面向公网，前置CDN几乎是标配。CDN节点天然分散，攻击流量会被分散到各个边缘节点，单点压力大幅降低。再配合云清洗服务，把恶意流量在骨干网层面丢弃，源站基本无感。

但这里有个坑：很多团队以为上了CDN就万事大吉，结果攻击者直接找源站IP。源站IP泄露的途径太多了——历史DNS记录、邮件头、SSL证书透明度日志、甚至GitHub上不小心提交的配置文件。所以源站IP隐藏是流量型防护的第一道门槛，后面我会详细讲怎么排查和加固。

2.2 连接型攻击：打的是你的状态表

连接型攻击比流量型“聪明”得多。它不追求带宽峰值，而是利用TCP协议的状态机机制，大量消耗服务器的连接跟踪表、半连接队列等资源。典型的如SYN Flood、ACK Flood、FIN Flood。

SYN Flood的原理很简单：攻击者发送大量SYN包但不完成三次握手，服务器为每个半连接分配资源并等待超时。当半连接队列满了，正常用户的SYN包就被丢弃了。这种攻击的流量可能只有几百Mbps，但足以让一台配置不错的服务器拒绝服务。

我实测过一台默认配置的Nginx服务器，在每秒约8万个SYN包的冲击下，半连接队列在十几秒内就被打满。防护手段包括：开启SYN Cookie、调大半连接队列、缩短SYN超时时间、部署连接型清洗设备。

这里有个经验：net.ipv4.tcp_syncookies=1 是必须开的，但光开这个不够。net.ipv4.tcp_max_syn_backlog 和 net.core.somaxconn 这两个参数要根据业务并发量合理调整。我一般会把 tcp_max_syn_backlog 设到65535，somaxconn 设到32768，再配合 tcp_synack_retries=2 减少重试次数。这些参数在Linux内核文档里都有说明，但很多运维手册不会告诉你具体设多少合适。

2.3 应用层攻击：最隐蔽也最致命

应用层DDoS是我最头疼的一类。它模拟正常用户行为，请求的都是合法页面或接口，单看每个请求都没问题，但频率和并发量远超正常水平。比如：

高频调用登录接口，试图撞库或耗尽数据库连接
大量请求搜索接口，每个请求都触发复杂的数据库查询
慢速POST攻击，用极低速率发送HTTP Body，长期占用Worker进程
API接口被恶意爬虫高频调用，消耗后端计算资源

这类攻击的流量可能只有几十Mbps，传统流量清洗设备根本识别不了。你必须从应用层行为入手，结合WAF、速率限制、人机验证等手段来防护。

我处理过一次针对API接口的攻击：攻击者用分布式的代理节点，每个节点每秒只发3-5个请求，但总共动用了上千个节点。单IP速率限制完全失效，因为每个IP的请求频率都不高。最后是通过API调用量基线分析 + 行为特征建模才识别出来——正常用户的API调用有固定的时间分布和参数模式，而攻击流量虽然分散，但在统计特征上仍然有迹可循。

2.4 反射放大攻击：借刀杀人的经典套路

反射放大攻击利用的是UDP协议的无连接特性。攻击者伪造目标IP，向开放的DNS、NTP、Memcached、SSDP等服务发送小请求，这些服务会返回大得多的响应，全部涌向目标。放大倍数从几倍到几万倍不等，Memcached反射甚至能达到50000倍。

这类攻击的防护难点在于：攻击流量来自合法服务器，你没法直接封禁。你总不能把全网的DNS服务器都拉黑吧？所以防护重点在于：

与上游ISP和云清洗厂商联动，在骨干网层面做流量清洗
关闭不必要的UDP服务，减少自身被利用作为反射源的风险
对关键业务做Anycast分散，降低单点压力

注意：如果你自己运维DNS或NTP服务，一定要确认没有开放递归查询或monlist功能。我见过不少团队因为一台配置不当的内部DNS服务器，导致整个出口带宽被反射流量打满。

3. 防护体系的核心组件与选型逻辑

3.1 CDN：不只是加速，更是第一道防线

很多人把CDN当成静态资源加速工具，但在DDoS防护体系里，CDN的价值远不止于此。它天然具备分布式边缘节点、流量分散、源站隐藏三大特性，是抵御流量型和应用层攻击的第一道屏障。

选CDN做防护时，我关注这几个点：

节点数量和分布：节点越多、分布越广，攻击流量被分散得越彻底。但要注意，有些CDN厂商的节点是虚标的，实际可用的清洗节点可能只有几个。
清洗能力：是否具备T级以上的DDoS清洗能力，是否支持应用层CC防护。
回源策略：是否支持回源鉴权、回源IP白名单、回源速率限制。这决定了攻击者能不能绕过CDN直接打源站。
日志和报表：能否提供详细的访问日志和攻击报表，方便事后溯源和策略调优。

我个人的经验是：不要把鸡蛋放在一个篮子里。主CDN + 备用CDN + 自建源站防护，三层架构虽然复杂，但可用性最高。主CDN被打穿时，DNS切换备用CDN，源站还有WAF和速率限制兜底。

3.2 WAF：应用层防护的核心抓手

WAF是应用层DDoS防护的核心组件。它工作在HTTP/HTTPS层，能识别SQL注入、XSS、CC攻击、恶意爬虫等应用层威胁。但WAF的选型和使用有很多门道。

先说选型。市面上的WAF分三类：云WAF、硬件WAF、软件WAF（如ModSecurity）。云WAF部署简单、规则更新快，但流量要经过第三方节点，有延迟和隐私顾虑；硬件WAF性能好、可控性强，但成本高、规则维护麻烦；软件WAF灵活、成本低，但需要自己调优规则，对运维能力要求高。

我目前的主力方案是云WAF + 自建ModSecurity双层防护。云WAF做第一层粗筛，拦截明显的恶意流量；ModSecurity做第二层细筛，针对业务特点定制规则。两层之间用回源鉴权串联，确保只有经过云WAF的流量才能到达源站。

再说使用。WAF最怕的就是误杀和漏杀。误杀正常用户，业务受损；漏杀攻击流量，防护失效。我的做法是：

新规则先开观察模式，记录匹配日志但不拦截
分析日志，确认误杀率在可接受范围内
逐步切换到拦截模式，同时保留白名单机制
定期回顾规则命中情况，清理无效规则

提示：WAF规则不是越多越好。我见过一个团队开了上千条规则，结果正常用户的请求被拦了30%。规则要精不要多，每条规则都要有明确的防护目标和验证记录。

3.3 API防护：被忽视的重灾区

API接口是应用层DDoS的重灾区，但很多团队的防护重心还在网页端，API接口几乎是裸奔状态。我梳理了几个API防护的核心要点：

第一，身份认证和鉴权。每个API请求都必须携带有效的Token或签名，匿名接口要严格限制调用频率。我见过不少团队的内部API直接暴露在公网，没有任何认证，攻击者扫到之后直接批量调用，后端数据库瞬间被打满。

第二，速率限制。按API Key、用户ID、IP、接口路径等多个维度做速率限制。单IP限制容易被分布式攻击绕过，所以要结合用户维度和接口维度。比如登录接口每分钟最多尝试5次，搜索接口每秒最多10次，超出就返回429状态码。

第三，参数校验和请求体大小限制。攻击者可能通过超大请求体、超长参数、畸形JSON等方式消耗后端资源。Nginx层面可以设置 client_max_body_size 和 client_body_timeout，应用层再做严格的参数校验。

第四，行为分析和异常检测。正常用户的API调用有固定的模式：调用时间分布、参数组合、请求频率、User-Agent特征等。通过基线建模，可以识别出偏离正常模式的异常调用。这块需要一定的数据积累和算法支持，但效果比单纯的规则匹配好得多。

3.4 内网攻防防护：别只盯着外网

聊DDoS防护时，大家习惯性地只看外网入口。但内网攻防防护同样重要——攻击者一旦突破边界，内网的DDoS攻击可能造成更大的破坏。比如：

内网横向移动时，攻击者可能用扫描工具高频探测内网资产，触发大量告警
攻击者可能控制内网主机作为跳板，对外发起DDoS攻击
内网DNS、NTP等服务被利用作为反射源

内网防护的重点在于流量基线、微隔离、异常检测。我一般会在核心交换机上做NetFlow采集，建立内网流量基线。一旦某个网段的流量模式偏离基线，就触发告警和自动阻断。同时用微隔离技术限制东西向流量，即使一台主机被控，也无法轻易扫描和攻击其他主机。

4. 实操：从零搭建一套可落地的DDoS防护体系

4.1 资产梳理与暴露面收敛

防护的第一步不是加设备，而是搞清楚自己有什么、暴露了什么。我见过太多团队连自己有多少个公网IP、多少个域名、多少个API接口都说不清楚，谈何防护？

我的做法是：

域名和IP梳理：用资产测绘工具扫描所有已知域名和IP段，确认每个资产的用途和负责人。
端口和服务梳理：对每个公网IP做全端口扫描，确认开放的服务是否必要。非必要的端口一律关闭。
API接口梳理：从代码仓库、API网关、Nginx配置中提取所有API接口，建立接口清单，标注认证方式、调用频率基线、敏感程度。
源站IP泄露排查：检查历史DNS记录、SSL证书透明度日志、邮件头、GitHub提交记录、第三方服务配置，确认源站IP是否泄露。如果泄露，考虑更换IP或启用CDN回源鉴权。

这一步看起来繁琐，但暴露面收敛是最有效的防护手段。你少暴露一个端口，攻击者就少一个入口。

4.2 CDN接入与源站加固

CDN接入的配置要点：

NGINX

# Nginx源站配置示例：只允许CDN回源IP访问

server {

listen 443 ssl http2;

server_name api.example.com;

# CDN回源IP白名单

allow 203.0.113.0/24;

allow 198.51.100.0/24;

deny all;

# 回源鉴权Header校验

if ($http_x_cdn_auth != "your-secret-token") {

return 403;

}

location / {

proxy_pass http://backend;

proxy_set_header X-Real-IP $http_x_forwarded_for;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

关键点说明：

回源IP白名单：只允许CDN厂商的回源IP访问源站，其他IP一律拒绝。这样即使源站IP泄露，攻击者也无法直接访问。
回源鉴权：CDN回源时携带一个密钥Header，源站校验通过才响应。防止攻击者伪造回源请求。
真实IP传递：通过 X-Forwarded-For 传递真实客户端IP，方便后续日志分析和速率限制。

注意：回源IP白名单要定期更新。CDN厂商的回源IP段可能会变化，建议用自动化脚本定期拉取并更新Nginx配置。

4.3 WAF规则调优与CC防护配置

WAF规则调优是个细活。我以ModSecurity为例，分享几个核心配置：

APACHE

# ModSecurity核心配置

SecRuleEngine On

SecRequestBodyAccess On

SecResponseBodyAccess Off

# CC防护：单IP每分钟超过100次请求则拦截

SecAction "id:1001,phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR}"

SecRule IP:REQUEST_COUNT "@gt 100" "id:1002,phase:1,deny,status:429,msg:'CC Attack Detected'"

SecRule REQUEST_URI "@contains /api/login" "id:1003,phase:1,pass,setvar:ip.login_count=+1"

SecRule IP:LOGIN_COUNT "@gt 5" "id:1004,phase:1,deny,status:429,msg:'Login Brute Force Detected'"

这段配置做了两件事：全局CC防护（单IP每分钟超过100次请求拦截）和登录接口专项防护（单IP每分钟超过5次登录尝试拦截）。实际部署时，阈值要根据业务正常流量调整，不能照搬。

CC防护的另一个重点是人机验证。对于疑似攻击的流量，不要直接封禁，而是返回一个JavaScript挑战或验证码页面。正常用户浏览器会自动执行JS并携带Cookie重新请求，攻击脚本通常不具备这个能力。这种方式误杀率低，对用户体验影响也小。

4.4 速率限制与连接数控制

Nginx层面的速率限制配置：

NGINX

# 定义限速区域

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

limit_req_zone $http_authorization zone=user_limit:10m rate=50r/s;

limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

server {

# 连接数限制：单IP最多20个并发连接

limit_conn conn_limit 20;

location /api/ {

# 请求速率限制：单IP每秒10次，突发不超过20次

limit_req zone=api_limit burst=20 nodelay;

# 按用户维度限速

limit_req zone=user_limit burst=100 nodelay;

limit_req_status 429;

proxy_pass http://backend;

}

参数选择逻辑：

rate=10r/s：根据业务正常API调用频率设定。我一般会取P99值的1.5倍作为阈值。
burst=20：允许的突发请求数。设置太小会导致正常突发流量被误杀，太大则失去限速意义。
nodelay：突发请求立即处理，不排队。对于API接口，排队会导致超时，所以用 nodelay。
limit_conn 20：单IP并发连接数限制。正常浏览器并发连接一般在6-8个，设20已经比较宽松。

4.5 监控告警与应急响应

防护体系建好之后，监控告警是最后一道保险。我关注的指标包括：

指标	正常范围	告警阈值	说明
入口带宽	200-500Mbps	>1Gbps	流量型攻击的直观指标
新建连接数/秒	1000-5000	>20000	连接型攻击的典型特征
HTTP 5xx比例	<0.1%	>1%	应用层攻击或后端故障
API平均响应时间	<200ms	>1s	后端资源耗尽的信号
WAF拦截次数/分钟	<100	>1000	应用层攻击的间接指标

告警触发后，应急响应流程：

确认攻击类型：看流量曲线、连接数、WAF日志，判断是流量型、连接型还是应用层攻击。
启用应急预案：流量型攻击切换高防清洗；连接型攻击调整内核参数和WAF规则；应用层攻击启用严格速率限制和人机验证。
溯源和取证：保留攻击日志、流量抓包、WAF拦截记录，为后续溯源和报案提供依据。
复盘和优化：攻击结束后，复盘防护体系的薄弱环节，更新规则和配置。

5. 常见问题与排查技巧实录

5.1 源站IP泄露了怎么办

这是被问得最多的问题。源站IP一旦泄露，CDN的防护效果大打折扣。我的处理步骤：

确认泄露范围：用 dig、nslookup、在线DNS历史查询工具，确认哪些历史记录暴露了源站IP。
更换源站IP：如果业务允许，直接更换源站IP是最彻底的方案。更换后立即配置CDN回源鉴权和IP白名单。
如果无法更换：在源站前面加一层反向代理（如Nginx），只允许CDN回源IP访问。同时用iptables做源IP限速和连接数限制。
长期监控：部署蜜罐或扫描监控，一旦发现有人直接访问源站IP，立即告警。

提示：更换源站IP后，记得检查所有DNS记录、邮件配置、第三方服务回调地址，确保没有遗漏。

5.2 WAF误杀正常用户怎么排查

WAF误杀的典型表现：正常用户访问被拦截，返回403或验证码页面。排查步骤：

查看WAF拦截日志：找到被拦截的请求，确认是哪条规则触发的。
分析请求特征：对比正常请求和被拦截请求的差异，判断是规则太严格还是请求确实异常。
调整规则：如果是误杀，把规则改为观察模式，或者添加白名单。如果是正常业务特征被误判，考虑自定义规则放行。
验证效果：调整后持续观察一段时间，确认误杀率下降且攻击流量仍被拦截。

我踩过的一个坑：某次WAF规则更新后，所有包含 select 关键词的搜索请求都被拦截了。原因是SQL注入规则把正常的搜索参数也匹配了。后来把规则改成只匹配 select 出现在SQL语法位置的请求，误杀就消失了。

5.3 API接口被爬虫高频调用怎么防

爬虫防护和DDoS防护有重叠，但侧重点不同。爬虫通常追求数据抓取效率，请求频率高、参数规律性强。防护手段包括：

User-Agent和Referer校验：拦截明显异常的UA和空Referer请求。
请求参数签名：要求客户端对请求参数做签名，服务端校验签名有效性。爬虫很难伪造有效签名。
行为验证：对高频调用返回验证码或JS挑战。
数据混淆：对敏感数据做混淆或分页限制，增加爬虫抓取成本。
速率限制：按API Key和用户维度做精细限速。

我实测下来，参数签名 + 行为验证的组合效果最好。参数签名挡住了大部分低级爬虫，行为验证挡住了高级爬虫。两者结合，爬虫的抓取效率会下降90%以上。

5.4 内网出现异常流量怎么定位

内网异常流量的定位思路：

流量采集：在核心交换机做NetFlow或sFlow采集，获取内网流量全景。
基线对比：对比当前流量和历史基线，找出异常网段和主机。
主机排查：登录异常主机，检查进程、网络连接、计划任务、启动项，确认是否被植入恶意程序。
隔离和清除：确认被控主机后，立即网络隔离，清除恶意程序，修复漏洞。
横向排查：检查同一网段其他主机是否有类似异常，防止攻击者横向移动。

注意：内网排查时不要直接重启主机，否则可能丢失内存中的恶意程序证据。先做内存抓取和进程快照，再处理。

5.5 常见问题速查表

问题现象	可能原因	排查方向	解决措施
带宽突然打满	流量型DDoS	看流量曲线和协议分布	启用CDN清洗，联系ISP
连接数暴涨	SYN Flood	看半连接队列和SYN包速率	开启SYN Cookie，调大队列
API响应变慢	应用层DDoS	看API调用量和数据库连接	速率限制，WAF拦截
WAF拦截正常用户	规则误杀	看WAF拦截日志	调整规则，加白名单
源站被直接攻击	源站IP泄露	查DNS历史和证书日志	更换IP，回源鉴权
内网扫描告警	横向移动	看NetFlow和主机日志	隔离主机，排查恶意程序

6. 防护体系持续运营的几个心得

防护体系建好只是开始，持续运营才是关键。我分享几个实际运营中的心得。

第一，定期演练。每季度做一次攻防演练，模拟不同类型的DDoS攻击，验证防护体系的有效性。演练时要注意控制影响范围，别把生产环境打挂了。

第二，规则和配置的版本管理。WAF规则、Nginx配置、iptables规则，全部纳入Git管理。每次变更都有记录，出问题可以快速回滚。

第三，关注攻击趋势。攻击手法在不断进化，新的反射放大协议、新的应用层攻击模式层出不穷。定期看安全厂商的威胁情报报告，了解最新的攻击趋势和防护方案。

第四，别忽视人的因素。再好的防护体系，如果运维人员不熟悉应急流程，攻击来临时照样手忙脚乱。应急响应手册要定期更新，关键岗位要有人备份。

第五，成本和安全平衡。DDoS防护是要花钱的，带宽、清洗设备、WAF、人力，都是成本。根据业务的重要性和攻击风险，合理分配预算。不是所有业务都需要T级清洗，也不是所有业务都能承受长时间停服。

最后再分享一个小技巧：用蜜罐做早期预警。在公网部署几个低交互蜜罐，模拟常见服务（如Redis、MySQL、SSH）。攻击者扫描和探测时，蜜罐会先于真实业务收到攻击流量，给你争取几分钟的预警时间。这几分钟在应急响应中非常宝贵。

这个内容后续还可以这样扩展：针对云原生环境的DDoS防护、基于机器学习的异常流量检测、DDoS防护的合规要求等。每个方向都值得单独展开聊。