凌晨3点的夺命连环Call：我的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时有什么骚操作？欢迎在评论区分享你的战（翻）斗（车）经历~