网站遭遇DDoS攻击应急处置完整流程

网站遭遇DDoS攻击时，最忌讳的是盲目重启服务器或者干等机房处理。攻击流量一旦打满带宽，重启只会让业务中断时间更长，而且攻击者看到目标掉线往往会加大力度。正确的第一步是确认攻击类型和当前影响范围，而不是急着恢复。登录服务器如果已经卡顿甚至无法连接，立刻通过云服务商或机房的带外管理通道（IPMI、VNC、云控制台）进入系统，先执行top、netstat -anp | grep SYN_RECV | wc -l、iftop这类命令，快速判断是带宽被打满、连接数耗尽还是CPU资源被攻击请求拖垮。如果是云主机，直接看监控面板的入方向流量和PPS，比在系统里折腾更快。

确认是DDoS后，马上联系机房或云服务商，要求接入高防IP或清洗设备。这一步不要犹豫，自己用iptables封IP基本没用，因为攻击源通常是伪造的或者分布式的。云服务商一般有自动检测和清洗能力，但默认阈值可能太高，需要人工报障要求立即介入。同时把域名解析的TTL提前改短，比如改成300秒，方便后续快速切换解析。如果业务有备用线路或备用服务器，在攻击持续期间可以先把核心接口切到备用环境，但要注意数据库同步和会话状态，避免用户登录态丢失。

DDoS不是单一攻击，常见的有SYN Flood、UDP Flood、CC攻击、DNS放大攻击等。SYN Flood的特征是服务器上大量SYN_RECV状态的连接，半连接队列被打满。临时缓解可以开启内核参数syncookies：sysctl -w net.ipv4.tcp_syncookies=1，并调大半连接队列。UDP Flood主要打带宽，服务器本身可能负载不高，但带宽占满后正常请求进不来，这种情况只能依赖上游清洗，自己没法在服务器上解决。CC攻击是模拟真实请求打应用层，比如大量请求某个搜索接口或动态页面，导致后端数据库或应用服务器过载。CC攻击需要从应用层和访问频率上做限制，而不是只靠防火墙。

如果是CC攻击，先看访问日志里是否有大量相同URL、相同User-Agent或者某个IP段的请求。用nginx或Apache的limit_req模块限制单IP请求频率，同时配合fail2ban自动封禁异常IP。但要注意，如果攻击源IP是真实且分散的，封IP效果有限，反而可能误伤正常用户。更有效的是在前端加一层缓存，把动态请求尽量静态化，或者临时把高频接口改成返回缓存数据。对于登录、注册、验证码这类接口，可以临时开启图形验证码或行为验证，增加攻击成本。

高防IP的原理是把攻击流量引到清洗节点，过滤后再把正常流量回源到真实服务器。切换时先把域名解析指向高防IP，同时在源站防火墙只允许高防节点的回源IP访问80和443端口，其他来源一律拒绝。这一步非常关键，否则攻击者直接绕过CDN或高防打源站，高防就白接了。源站防火墙可以用iptables或云安全组设置白名单，只放行高防服务商提供的回源IP段。

如果业务已经在使用CDN，确认CDN是否自带DDoS防护能力，很多CDN节点本身能扛住一定量的攻击。攻击发生时检查CDN控制台是否有攻击告警，开启“攻击缓解”或“强制缓存”功能，把回源频率降低。对于动态接口，可以设置CDN的“等待回源”和“智能限速”，减少源站压力。同时把源站IP隐藏好，历史解析记录里如果暴露过源站IP，攻击者可能直接绕过CDN打源站，这种情况需要更换源站IP或者使用高防IP作为源站入口。

在等待清洗生效期间，服务器上可以做一些临时加固。下面这些命令适用于Linux系统，能缓解部分攻击压力：

# 开启SYN Cookie防护
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.ipv4.tcp_synack_retries=2

# 限制单IP并发连接数（需要iptables的connlimit模块）
iptables -I INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j DROP

# 限制单IP新建连接速率
iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 1 --hitcount 20 -j DROP

# 丢弃无效的TCP包
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

这些规则只能减轻小规模攻击，大规模流量攻击时服务器上的iptables基本无效，因为流量在到达服务器之前已经把带宽占满了。所以服务器层加固只是辅助，核心还是要靠上游清洗。另外，如果网站用了nginx，可以调整worker进程数和连接数上限，避免连接数耗尽导致正常请求无法处理。nginx配置里worker_connections可以临时调大，但不要超过系统文件描述符限制。

攻击期间用户访问会变慢或打不开，这时候需要在页面层做降级处理。如果网站有静态化能力，把首页、列表页、详情页全部切到静态文件，减少后端动态计算。对于搜索、推荐这类高消耗接口，临时关闭或者返回空结果，并给前端一个友好提示。用户登录和下单流程如果受影响，可以开启排队机制或者限流，保证已经进入流程的用户能完成操作，而不是全部超时。

同时要在外部渠道发布公告，比如官方社交媒体、邮件通知，说明服务正在遭受攻击，正在紧急处理。不要隐瞒，用户遇到打不开的情况会自己猜测，主动说明反而能减少投诉。如果攻击持续超过半小时，准备一个静态的公告页面，把主域名解析到这个页面，告诉用户稍后再试。这个页面可以放在对象存储或另一个机房，避免主站完全不可访问时用户什么信息都看不到。

攻击停止后不要马上放松，先检查服务器是否有被入侵的痕迹。有些DDoS攻击是敲诈勒索的前奏，攻击者可能同时尝试植入后门。检查/var/log/auth.log、/var/log/secure里的登录记录，看是否有异常IP登录成功，检查crontab是否有陌生定时任务，检查网站目录是否有最近修改的可疑文件。如果发现异常，立即备份当前数据，重新部署干净环境，并修改所有密码和密钥。

长期防护方面，第一是隐藏源站IP，所有对外服务都走CDN或高防，源站只允许回源IP访问。第二是配置弹性带宽或自动扩容，云主机可以开启按量计费的带宽上限，避免攻击时带宽瞬间打满。第三是建立监控告警，对入方向流量、连接数、PPS、5xx错误率设置阈值，超过阈值自动通知值班人员。第四是准备应急预案文档，把这次处理过程记录下来，包括联系人、操作步骤、命令和注意事项，下次再遇到可以直接照做，不用重新摸索。

最后要明确一点：DDoS攻击无法完全避免，只能提高攻击成本和降低影响。把基础防护做好，攻击来临时能快速切换和降级，攻击结束后能快速恢复并排查隐患，这就是一套完整的应急处置能力。不要指望某一种设备或服务能彻底解决所有DDoS，真正的防护是分层级的：上游清洗、CDN缓存、服务器加固、应用限流、业务降级，每一层都要有准备。