被DDoS攻击了怎么办？实用应急处理与有效解决方案

怎么判断自己正在遭受DDoS攻击 🧐

很多站长第一次遇到DDoS时往往反应不过来，以为是服务器出了故障。以下几个典型现象可以帮你快速判断：网站突然完全无法打开或加载极慢、服务器远程连接频繁断开、流量监控面板显示带宽瞬间被打满、CPU和内存占用飙升到接近满载。

如果同时出现其中两个以上的症状，八成就是被DDoS盯上了。这时候最重要的一件事是——冷静，然后按步骤处理。

第一步：快速确认攻击规模与类型 🔍

登录服务器后，先用一条命令摸清当前的连接状况：

ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

这条命令的逻辑是：ss -ant列出所有TCP连接及其状态，awk '{print $1}'提取每行的第一列即连接状态字段（如ESTAB、SYN-RECV、TIME-WAIT等），然后通过sort排序、uniq -c去重计数、sort -rn按数量倒序排列。执行后你会看到每种状态对应的连接数量。

根据输出结果判断攻击类型：

• SYN-RECV数量过万 ➜ 正在遭受SYN Flood攻击，攻击者用伪造的半连接请求耗尽你的连接队列
• ESTAB数量异常暴涨 ➜ 大概率是CC攻击，大量假冒的"正常请求"在消耗应用层资源
• 服务器带宽直接被打满但连接数不高 ➜ 属于流量型攻击（UDP Flood、反射放大等），恶意数据包在网络层就已经堵死了入口

第二步：紧急止损操作 🚨

场景一：攻击规模尚可承受（服务器还能登录）

先把最活跃的攻击源找出来并封禁：

ss -ntp state established dst :80 or dst :443 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

该命令筛选出所有连接到80端口或443端口且状态为已建立的TCP连接，从中提取远程IP地址，统计各IP的连接数后取连接量最高的前20个。这些高连接数的IP就是当前最大的攻击源头。

对确认的攻击IP进行批量封禁：

while read count ip; do
    iptables -I INPUT -s "$ip" -j DROP
done <<< "$(ss -ntp state established dst :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | awk '$1>100')"

这段脚本自动化完成了整个封禁流程：先统计每个IP到80端口的活跃连接数，筛选出连接数超过100的IP（$1>100），然后逐个通过iptables将其加入DROP规则。-I INPUT确保规则插到链首优先匹配，所有来自这些IP的数据包会被立即丢弃。这比手动一个一个封要快得多，在攻击进行时效率至关重要。

场景二：攻击流量已经超出服务器带宽 ⚡

如果连SSH都登不上去了，说明恶意流量在网络层就已经把带宽吃光，本地任何操作都无济于事。此时需要从外部进行处置：

登录域名管理面板，将域名的A记录从源站IP切换到高防CDN提供的防护CNAME或IP上。这样所有流量会先经过清洗中心，攻击流量在边缘节点就被识别和丢弃，只有干净的正常请求才会被转发到你的源站。

如果暂时无法切换解析，可以联系机房或云服务商请求临时启用黑洞路由或流量清洗服务。

第三步：攻击期间的系统加固 🛡️

在初步遏制住攻击后，趁这个间歇把服务器的防御能力拉高一个档次。

内核层面的TCP防护参数：

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=65535
sysctl -w net.ipv4.tcp_synack_retries=1
sysctl -w net.ipv4.tcp_abort_on_overflow=1
sysctl -w net.core.somaxconn=32768

逐行解释：tcp_syncookies启用SYN Cookie机制，半连接队列溢出后不再给每个SYN分配资源，改为用加密算法校验对方是否为真实客户端，这是对抗SYN Flood的关键手段。tcp_max_syn_backlog将半连接队列深度提升到65535，给SYN Cookie启用前提供更大的缓冲。tcp_synack_retries降到1次，减少对伪造连接的无效重传等待。tcp_abort_on_overflow设为1后，当全连接队列溢出时直接向客户端发RST重置包而非默默丢弃，可以更快释放资源。somaxconn将监听队列上限提升到32768，保障高并发下正常连接的接入能力。

使用sysctl -w的好处是立即生效不用重启，适合攻击进行时的紧急调整。但请注意重启后会失效，稳定后应写入/etc/sysctl.conf进行持久化。

Nginx层快速启用请求限速：

# 在nginx.conf的http块中添加
limit_req_zone $binary_remote_addr zone=emergency:20m rate=15r/s;

# 在需要保护的server块或location中引用
limit_req zone=emergency burst=20 nodelay;
limit_req_status 444;

limit_req_zone创建一个名为emergency的限速区域，分配20MB共享内存用于记录各IP的访问频率，限制每个IP每秒不超过15个请求。burst=20允许突发排队20个请求，nodelay表示突发请求不延迟而是立即处理。重点在最后一行：limit_req_status 444——Nginx的444状态码是一个特殊响应，它会直接关闭连接不返回任何内容，相比默认的503错误页，444消耗的服务器资源几乎为零，在被CC攻击时可以显著降低Nginx的负载压力。

第四步：攻击平息后的长效防御 ✅

攻击总会结束，但如果不建立长效防线，下一波随时会来。

定期审查开放端口：

ss -tlnp | grep -v "127.0.0.1"

该命令列出所有对外监听的TCP端口（排除只监听本地回环地址的服务）。逐一确认每个端口背后运行的服务是否业务必需，不需要暴露的端口一律用防火墙关掉。攻击面越小，被盯上的概率就越低。

部署fail2ban自动封禁暴力行为：

apt install fail2ban -y

fail2ban是一款轻量的入侵防御工具，它持续监控系统日志文件（如SSH登录日志、Nginx访问日志），当检测到某个IP在短时间内出现大量失败的登录尝试或异常的请求模式时，自动调用iptables将该IP封禁一段时间。安装后几乎零配置就能生效，是性价比极高的防护手段。

建立监控告警体系 📊

在流量监控中设置告警阈值，当带宽利用率突破日常峰值的3倍、单IP连接数超过设定上限、或CPU负载异常飙升时，立即通过短信或即时通讯工具推送告警通知。做到攻击刚发起就能第一时间感知和响应，而不是等到用户投诉"网站打不开"才后知后觉。

核心要点回顾 📌

遭遇DDoS攻击的应对可以浓缩为四个动作：判断类型明确当前面对的是什么攻击、紧急封堵在本地能处理就先封IP限流、切换防护流量扛不住就立即上高防CDN、持久加固攻击平息后补齐短板建立常态化防御。记住一个原则：本地措施能应对中小规模攻击，但真正的大流量DDoS只有专业的分布式清洗平台才扛得住，提前做好接入准备远比临时抱佛脚靠谱得多。