凌晨三点被DDOS攻击惊醒的经历，让我对小VPS的安全配置彻底改观了——原来1核1G的小鸡也值得黑客大动干戈。特别是在发现攻击源居然是一周前评论区埋的JS炸弹时，那种”早知如此”的懊恼感简直刻骨铭心。现在我的安全策略完全变了，不再觉得”够用就好”，而是像强迫症患者一样死磕每个细节。说真的，与其等攻击来了手忙脚乱地封IP，不如提前把防火墙配置得像铜墙铁壁。
基础防御：从iptables到fail2ban的进化
过去我总以为iptables随便配几条规则就够了，直到看见那些攻击者像蝗虫一样源源不断地更换IP。现在我的iptables配置里，光是防SYN洪水攻击的规则就写了三层，还配合fail2ban实现动态封禁——任何IP如果五分钟内尝试SSH登录失败超3次，自动加入黑名单。有趣的是，这套组合拳实施后，系统日志里的破解尝试从日均200次骤降到个位数。
特别要提醒的是，千万别犯我当初的错误：udp/53端口默认开放简直是在邀请DNS放大攻击。现在我的端口开放策略严格遵循”最小权限原则”，连NTP服务都改用了限制性更强的配置。
Web应用层的隐形护甲
Nginx的limit_req和limit_conn模块成了我的新宠，它们就像流量调节器，能把CC攻击的杀伤力削弱八成。有个细节可能容易被忽略：在设置速率限制时，千万别用$remote_addr，改用$binary_remote_addr能节省十倍内存——这个坑我亲自踩过，当并发量上来时，内存消耗差异能到惊人的200MB vs 20MB。
评论系统现在是重点防护对象，所有用户提交内容都要经过三层过滤：先是Cloudflare的WAF规则，然后是自建的XSS检测脚本，最后还有一道正则表达式匹配特殊字符。虽然让评论显示延迟了0.5秒，但总比半夜被黑产团伙叫醒强。
监控与应急：宁可误杀不可放过
现在我养成了个新习惯：每周检查一次/var/log/secure，看着那些被fail2ban拦截的IP地址，莫名有种打地鼠的快感。监控系统也升级成了双保险：Zabbix负责性能指标，Prometheus专盯异常流量。有次凌晨两点，Prometheus检测到UDP流量突增，自动触发防护脚本时，我居然睡得出奇的香——这才是运维该有的状态啊。
最后分享个血泪经验：所有关键操作务必写在脚本里，并且测试过能用curl触发。那次半夜用手机敲iptables命令的经历，现在想起来手指还会抽筋。至于那些说”小网站不用防护”的论调，就让他们继续活在美好的幻想里吧，我们这些经历过暴风雨的，早就学会随时带伞了。
评论