一次 VPS 被 DDOS 拖垮的排查过程

2025.7.7 杂七杂八 1360
33BLOG智能摘要
上周三凌晨3点15分,作者的VPS因DDOS攻击导致服务器负载100%、网络中断。攻击主要集中在UDP 53端口,疑似利用东南亚物联网设备发起。攻击持续23分钟,流量峰值达1.2Gbps,攻击前一周网站评论区曾出现可疑JS代码。作者在应急失败后只能关闭服务器。事后他全面升级了安全配置,包括Nginx防护、iptables规则、关闭非必要端口、使用Cloudflare代理及部署自动封禁脚本。他反思认为,即便个人网站也需重视安全防护。
— 此摘要由33BLOG基于AI分析文章内容生成,仅供参考。

凌晨3点的夺命连环Call:我的VPS是如何被DDOS拖垮的

一次 VPS 被 DDOS 拖垮的排查过程

上周三凌晨3点15分,我被一阵急促的手机铃声惊醒。迷迷糊糊中看到监控系统发来的告警短信:”服务器负载100%,网络中断”。作为一个常年把”高可用”挂在嘴边的运维,这一刻真是啪啪打脸…

第一阶段:以为是日常抽风

第一反应是SSH连上去看看,结果发现连登录都费劲。通过服务商的控制台看到CPU曲线直接顶到了天花板,网络流量更是夸张地突破了500Mbps——要知道我这个1核1G的小鸡平时流量连5Mbps都不到。

# 勉强连上后看到的景象
$ top
load average: 15.32, 14.89, 12.45
%Cpu(s): 99.7 us,  0.3 sy

这时候我还天真地以为是什么进程崩溃了,直到发现iftop里密密麻麻的国外IP,才意识到事情不简单。

第二阶段:手忙脚乱的应急响应

我的应急方案简直是个教科书式的反面教材:

  1. 先尝试用iptables封IP,结果规则还没加完SSH就断了
  2. 想启用Cloudflare,发现DNS记录压根没设代理
  3. 服务商的控制台里找DDoS防护,发现最便宜的套餐都要$99/月

最后只能祭出终极方案——关机保平安。你们能想象凌晨4点蹲在卫生间,用手机热点操作关机的心酸吗?

第三阶段:事后的技术复盘

第二天冷静下来后,通过服务商的流量分析发现了几个关键点:

  • 攻击持续了23分钟,峰值达到1.2Gbps
  • 80%流量集中在UDP 53端口(DNS放大攻击)
  • 肉鸡主要来自东南亚的物联网设备

最讽刺的是,被攻击的只是个个人博客。后来查日志才发现,攻击前一周有人在评论区留了段可疑的JS代码,估计是那时候就被盯上了。

第四阶段:现在的防御方案

交完这次学费后,我的安全配置全面升级:

# Nginx层防护
limit_req_zone $binary_remote_addr zone=antiddos:10m rate=30r/m;

# iptables基础规则
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 30 -j REJECT

另外还做了三件事:1) 全站走Cloudflare代理 2) 关闭所有非必要端口 3) 设置了基于异常的自动封禁脚本。现在想想,当初觉得”小网站没人攻击”的想法真是太年轻了。

写在最后

这次经历给我上了生动的一课:安全防护就像买保险,平时觉得浪费钱,出事时才后悔没早准备。下次再有人跟我说”个人网站要什么防护”,我一定要把这篇血泪史甩给他看。

顺便问问各位同行:你们遇到DDoS时有什么骚操作?欢迎在评论区分享你的战(翻)斗(车)经历~

评论

  • 凌晨三点处理DDOS也太惨了吧,代入感很强已经开始生气了 😤

  • 同款1核1G小鸡用户瑟瑟发抖,马上去检查防火墙规则

  • 曾经也被UDP53端口攻击过,后来直接关闭了所有不用的UDP端口,建议试试

  • 这段经历写得很有教育意义,特别适合web安全入门的新手看

  • 半夜关机的场景真实又心酸,建议提前准备好应急预案再睡觉

  • 我有个更惨的经历,被攻击的时候正在团建,结果所有人都看到我蹲在厕所回消息

  • 同求靠谱的抗DDOS方案,Cloudflare免费版够用吗?