网站安全自查报告

上午十点，网站运维老张把一份扫描报告摔在我桌上。安全红色告警条目有十七条，自查其中三条高危，报告指向同一个IP段——那台挂着公司官网的网站云服务器。这已经是安全本月第三次了。

网站安全自查这事，自查听起来像走形式，报告真查起来全是网站窟窿。我们公司不算大，安全官网加一个客户登录系统，自查撑死五个页面，报告可攻击者不在乎你体量小。网站他们用脚本扫端口，安全扫目录，自查扫弱口令，一天能来几百次。上次漏洞是某个外包写的搜索框，SQL注入直接能拖库，客户手机号全在里面躺着。你说吓人不吓人。

自查的第一步，先看服务器日志。别嫌日志枯燥，那里头藏着所有试探的痕迹。我花了两个小时翻nginx的access.log，发现凌晨三点有连续请求，路径是/admin/login.php，尝试了四十多个密码组合。明摆着的暴力破解。我们压根没装防护插件，防火墙规则也放得宽，等于大门没锁，只挂了块“闲人免进”的牌子。

接着查端口。用netstat一看，开放了22、80、443，还有3306。MySQL端口居然对公网开放，这要是被爆破成功，整个数据库就是裸奔。我当场改了安全组策略，把3306封掉，只允许内网访问。老张在旁边嘀咕：“早该这么干了。”我没接话，因为我知道还有更麻烦的。

代码层面的问题更隐蔽。网站用的开源CMS，版本老得官方都停止维护了。后台编辑器有个上传漏洞，能直接传PHP木马。我们测试了一下，果然没过滤。吓得赶紧把上传目录的脚本执行权限关了，又加了一层WAF规则。说实话，WAF是云服务商送的，配置起来挺麻烦，但总比裸奔强。

数据备份这块，之前是每周手动打包一次，放在同一台服务器上。这等于把鸡蛋全放一个篮子里，服务器被勒索病毒加密，备份也跟着遭殃。我改成每天增量备份，推到对象存储里，异地保存。成本每月多花几十块，换来的是一夜安眠。

密码策略也是老大难。行政部同事的邮箱密码是“abc123456”，说了八百遍不改。这次自查我干脆强制开启双因素认证，登录后台必须扫验证码。有人抱怨麻烦，我直接甩出那份扫描报告：“你看看这些红字，哪个不比麻烦更刺眼？”

最后补了份应急预案。以前出事儿都是手忙脚乱，谁有空谁上，现在写清楚谁负责断网、谁负责查日志、谁联系云服务商。还演练了一次模拟攻击，从发现到封堵花了四十分钟，还是太慢。理想状态是十五分钟以内。

自查报告写完了，发给老板，他回了个“收到”。我知道这不算完，安全是持续对抗，不是一次检查就能高枕无忧。但至少今晚，我能睡个踏实觉——希望明天早上，扫描报告上别再冒新的红字。