网站遭遇DDoS攻击如何快速应急防护

DDoS攻击发生时，最直观的感受就是网站无法访问、服务器响应缓慢甚至完全瘫痪。这时候不需要去纠结攻击者的动机，也不需要立刻去分析攻击类型，第一优先级永远是恢复业务可用性。最快的方法不是购买昂贵的清洗设备，而是立刻联系你的机房或云服务商，申请黑洞路由或流量清洗。几乎所有主流IDC和云厂商都提供免费的DDoS基础防护，一个工单或一通电话就能把攻击流量牵引到清洗中心，正常流量回注到你的服务器。这个过程快则几分钟，慢则半小时，比你自己在服务器上折腾防火墙规则有效得多。

如果你用的是裸金属服务器或自建机房，没有自带清洗能力，那么最快的方法是立刻购买DDoS高防IP。高防IP的原理是把你的公网IP隐藏起来，所有流量先经过高防机房，攻击流量被清洗后，正常请求才转发到源站。接入方式有两种：DNS解析切换和IP替换。DNS切换是把域名的A记录指向高防IP，生效时间取决于TTL，如果你的TTL设置得比较长，可以临时修改域名的NS服务器到支持秒级生效的DNS服务商，或者直接用高防IP提供的CNAME域名做跳转。IP替换则是直接把业务绑定到高防IP上，源站IP只允许高防回源地址白名单访问。这个过程从购买到配置完成，熟练的操作人员可以在10分钟内搞定。

在等待外部清洗生效的同时，服务器自身的防护措施能争取宝贵时间。Linux服务器上最直接的工具是iptables和ipset。面对CC攻击或HTTP Flood，单靠iptables逐条封禁IP效率太低，正确做法是限制单个IP的并发连接数和请求速率。比如用iptables的recent模块配合hashlimit，可以实现每个IP每分钟最多发起30个新连接，超过就丢弃。更高效的做法是用nginx的limit_req模块和limit_conn模块，在应用层直接返回503，减少后端PHP或数据库的压力。具体配置示例如下：

http {
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    
    server {
        location / {
            limit_req zone=req_limit burst=20 nodelay;
            limit_conn conn_limit 10;
        }
    }
}

这段配置的意思是每个IP每秒最多10个请求，突发允许20个，超过直接返回503，同时每个IP最多保持10个并发连接。这种限制对正常用户影响很小，但能有效挡住CC攻击。如果攻击量级已经大到nginx都扛不住，那就需要把限流下沉到内核层面，用iptables直接限制SYN包速率。

CDN不仅仅是加速工具，更是抵御DDoS的天然屏障。如果你的网站已经接入了CDN，攻击发生时首先要检查源站IP是否暴露。很多网站被直接打穿，原因是源站IP泄露，攻击者绕过了CDN直接攻击源站。检查方法很简单，用多地ping工具或在线DNS查询服务，看域名解析出来的IP是不是CDN的节点IP，如果不是，说明源站IP已经暴露。此时需要立刻更换源站IP，并在CDN控制台更新回源配置，同时确保源站只允许CDN的回源IP段访问。对于还没有接入CDN的网站，紧急接入CDN也是一种快速缓解手段，但要注意CDN的缓存策略，动态内容较多的网站需要配置好缓存规则，避免大量请求穿透到源站。

SYN Flood是最常见的DDoS攻击类型之一，攻击者发送大量伪造源IP的SYN包，耗尽服务器的半连接队列。Linux内核有几个参数可以快速调整来缓解这种攻击。首先是tcp_syncookies，开启后服务器在SYN队列满时不会直接丢弃新连接，而是用Cookie机制验证客户端的真实性。其次是tcp_synack_retries，减少SYN-ACK的重试次数，让半连接尽快超时释放。还有tcp_max_syn_backlog，适当增大SYN队列长度，但不要无限制增大，否则会消耗过多内存。具体调整命令如下：

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_synack_retries=2
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.ipv4.tcp_syn_retries=2
sysctl -w net.ipv4.tcp_fin_timeout=30

这些参数调整后立即生效，不需要重启服务。但要注意这只是缓解手段，面对大流量SYN Flood，最终还是需要上游的网络层清洗。

不是所有DDoS都是流量型攻击，很多攻击针对的是应用层的薄弱环节，比如数据库查询接口、搜索功能、API端点等。攻击者用较低的请求量就能把服务器资源耗尽。这类攻击的识别特征是请求URL高度集中、请求参数异常、User-Agent单一或为空。应急处理时，可以在nginx或Apache层面针对这些特征做临时封禁。比如发现某个API接口被频繁调用，直接对该URL路径做访问频率限制，或者在应用代码里加入临时开关，对该接口返回空数据。更精细的做法是用WAF（Web应用防火墙）的规则引擎，对请求头、请求体、参数做组合判断。现在很多云服务商的WAF都内置了DDoS防护模块，开启后能自动识别并拦截应用层攻击。

DNS本身也可能成为DDoS攻击的目标，DNS Query Flood会耗尽DNS服务器的处理能力，导致域名解析失败。如果你的域名DNS托管在普通注册商，抗攻击能力通常很有限。应急方案是把域名DNS迁移到专业的高防DNS服务商，这类服务商在全球有大量节点，能承受T级别的DNS查询攻击。迁移过程很简单，在域名注册商后台修改NS记录即可，但要注意NS修改有24到48小时的缓存生效期。为了缩短切换时间，可以提前把TTL值调低，或者在攻击发生时同时使用多个DNS服务商做冗余解析。另外，DNSSEC签名不会影响切换速度，但会增加解析复杂度，应急时可以暂时关闭。

当攻击量级超出所有防护手段的承载能力时，业务层面的降级是最后的保底手段。降级的核心思路是保证核心功能可用，牺牲非核心功能。比如电商网站可以暂时关闭搜索、推荐、评论等消耗资源的模块，只保留商品浏览和下单功能。静态化是另一个有效手段，把动态页面提前生成静态HTML，推到CDN或对象存储上，这样即使源站完全不可达，用户仍然能看到基本的页面内容。更极端的做法是切换到纯静态的公告页面，告知用户服务正在恢复中。这些降级方案需要提前准备好，攻击发生时一键切换，而不是临时开发。

在应急响应的同时，日志分析工作不能落下。通过分析nginx访问日志或流量采样数据，可以快速锁定攻击特征，包括攻击来源IP段、请求路径、请求频率、请求头特征等。用awk或goaccess等工具可以快速统计出高频IP和URL。例如统计访问量最高的前20个IP：

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

这些数据一方面可以用于即时封禁，另一方面也是后续报警和向有关部门举报的证据。需要注意的是，攻击来源IP很可能是傀儡机，封禁IP只能缓解，不能根除。真正的溯源需要结合攻击工具特征、控制端域名、样本分析等手段，这超出了应急响应的范畴，但保留完整的日志和流量样本是后续深入分析的基础。

一次成功的应急响应不代表问题彻底解决。攻击者可能会更换手法再次发起攻击，或者利用你防护体系中的新漏洞。应急结束后，需要复盘整个攻击过程，找出防护短板。常见的短板包括：源站IP未隐藏、CDN回源地址未做白名单、DNS防护能力不足、应用层接口未做频率限制、服务器内核参数未优化、缺乏自动化切换手段等。针对这些问题逐一加固，才能把下一次攻击的影响降到最低。另外，建立监控告警体系也很重要，流量异常升高、连接数激增、错误日志暴增等情况都应该触发告警，让运维人员能在攻击初期就介入处理，而不是等用户投诉才知道网站挂了。

DDoS防护本质上是一场不对等的对抗，攻击者只需要找到一个弱点，防守方却需要面面俱到。但通过合理的分层防护架构，结合云服务商的清洗能力、CDN的分散能力、服务器层面的限流策略、应用层的精准拦截，以及业务层面的降级方案，完全可以把DDoS攻击的影响控制在可接受范围内。关键在于平时做好预案，攻击时才能快速响应，而不是手忙脚乱地到处求救。