```html

网站防御

去年三月，一个做跨境电商的网站防御朋友半夜给我打电话，说网站打不开了。网站防御我登上服务器一看，网站防御/etc/nginx/ 下的网站防御配置文件被改得面目全非，首页被替换成一张嚣张的网站防御黑色图片，上面用红色大字写着“你的网站防御数据在我手里”。他没做任何备份，网站防御数据库被锁，网站防御最后付了0.5个比特币才拿回数据。网站防御那晚之后，网站防御我把他所有服务器的网站防御SSH端口从22改成了高位端口，关掉了密码登录，网站防御只留密钥。网站防御这事儿让我彻底明白：网站防御不是网站防御买几个插件、装个WAF就完事，它是一整套从代码到运维的肌肉记忆。

很多人以为防御就是防黑客入侵。其实大部分网站挂掉，压根不是被“攻破”的。我见过太多案例——一个日活几百的小论坛，因为图片上传接口没做类型校验，被人传了个.php的伪装图片，然后整个服务器变成挖矿肉鸡。流量一跑满，CPU直接飙到100%，网站自然打不开。这种漏洞听起来低级，但每年OWASP Top 10里，失效的访问控制、加密失败、注入攻击永远排在前几位。防御的第一层，就是把所有用户输入当成带刺的玫瑰——你欣赏它，但得戴手套。参数化查询、输出转义、文件白名单，这些老生常谈的东西，真做到位了，能挡住八成以上的自动化扫描器。

说到扫描器，我上个月在日志里看到一个IP，两小时内发了四千多次请求，路径从 /wp-admin 到 /.env 再到 /phpmyadmin，典型的批量扫描。我顺手封了那个C段，但没完——它后来又换了代理IP继续试。这种时候，光靠防火墙规则不够，得用点“脏”办法。比如给登录页面加个隐藏字段，正常用户看不见也不会填，机器人却会傻乎乎地填上；或者把登录失败后的响应时间随机延迟几百毫秒，让暴力破解的成本高到不划算。这些小伎俩不优雅，但管用。

“防御不是造一堵墙，而是让攻击者觉得翻你这堵墙不划算。”

我自己的博客跑在一台1核1G的VPS上，用了Cloudflare的免费套餐，加上Nginx的limit_req模块限制单IP请求频率。有次一个爬虫疯狂抓取，CF那边自动触发了5秒盾，我这边日志干干净净。但别迷信CDN——如果你的源站IP暴露了，攻击者直接打源站，CDN就成了摆设。所以源站防火墙只放行CF的IP段，其他全DROP，这是基本操作。还有，数据库千万别监听0.0.0.0，只绑127.0.0.1，密码别用root123。我见过一个线上环境，MySQL的root密码是空的，而且端口对外开放，这跟把保险柜钥匙插在门上有什么区别。

代码层面的防御更磨人。比如一个简单的评论功能，你得考虑：用户提交的内容里有没有<script>？长度有没有限制？频率有没有限制？提交太快是不是机器人？存储时要不要转义？输出时要不要编码？这一串问题下来，写十行代码得花二十分钟思考。但值得。我维护过一个老系统，因为历史原因用了拼接SQL，后来加了个中间件，把所有进入数据库的字符串强制转义，虽然性能掉了5%，但再也没出过注入事件。有时候防御就是拿一点性能换安心，看你怎么选。

最后说个反直觉的观察：很多网站被黑，不是因为技术不行，而是因为没人管。一个三年前的项目，开发跑了，运维换了，服务器还在跑着老版本WordPress，插件列表里躺着五六个已知漏洞。攻击者甚至不需要“攻”，只需要“捡”。所以定期更新、定期备份、定期看日志，这三件事比任何高级WAF都实在。我现在的习惯是每周一早上泡杯咖啡，花二十分钟扫一遍所有站点的访问日志和错误日志，看到可疑的404或500就追一下。这二十分钟，比事后花两天救火划算得多。

网站防御这事，说到底是个持续对抗的过程。没有银弹，没有一劳永逸。你多堵一个洞，攻击者就得多绕一段路。绕得烦了，他们就去搞隔壁那个连备份都没做的站了。现实就是这么残酷，但也这么简单。

```