服务器安全审计：90%高危漏洞藏于日志盲区

　　去年高考期间，我蹲在机房里查收录——不是查百度，是查服务器日志。空调坏了三天，风扇声盖不住隔壁装修的电钻，嗡——嗡——嗡——，跟心跳一个节奏。我手边烟灰缸里斜插着半截没抽完的中南海，烟丝早灭了，只剩一股陈年焦油味。

　　那天下午三点十七分，群里突然弹出一条消息：“老张你站怎么快照回退到五月了？”发信人是阿哲，他截图发过来，页面标题还是“2023高考作文押题汇总”，可快照时间写着5月12日。我点开自己后台，索引量曲线像被谁用橡皮擦掉下半截——掉了一半。不是缓慢下滑，是断崖。我原以为是百度又在压站群泛化词，结果把蜘蛛UA全拉出来筛一遍，发现三台IP地址带182.140.开头的机器，连续四天零点到两点疯狂抓/admin/log/xxx.php，但这个路径根本没在robots.txt里声明，也没被任何页面链接过。

　　我翻了CDN日志，翻了nginx access.log，翻了fail2ban的封禁记录……全空。不是没记录，是记录里压根没它。就像你盯着公交站牌看一小时，可那辆该死的车根本不在调度表上。我让实习生小陈去扫一遍/var/log/下的所有子目录，她回我：“张哥，/var/log/apache2/下面有个叫apache2-20230607-backup.log的文件，权限是600，owner是www-data，但创建时间是6月7号凌晨0:03。”我说“打开”，她说“打不开，二进制乱码”。我又让她cat -A前二十行，出来一堆^@^@^@……中间夹着一行：GET /wp-content/plugins/wp-super-cache/wp-cache-phase2.php?x=… HTTP/1.0

　　这个我敢打包票——那不是正常缓存调用，是带shell参数的伪请求。真正在跑的是另一个日志文件，藏在/tmp/.X11-unix/下，名字伪装成.X0-lock，chmod 000，连root ls -la都看不见，得用stat /tmp/.X11-unix/.X0-lock才漏出mtime和ctime差了七分钟。这玩意儿根本不写入常规日志流，它只往/dev/null写两行，再把结果塞进rsyslog的journald缓冲区尾部，等系统每小时rotate一次，就把那段吞掉。所以你看access.log干干净净，waf规则一条没触发，防火墙日志连个毛都没报。

　　阿哲昨天在群里发了个捂脸表情包，配文：“快照又退到六月了，这次连title都变成‘Not Found’”。我没回。因为我知道，他那站前端看着好好的，但nginx配置里有个if ($args ~ "eval\\(") { rewrite ^(.)$ /404.html break; } ——可攻击者早把eval换成base64_decode和gzinflate嵌套三层，参数名改成_x001f_yy99，绕过所有关键词正则。更绝的是，他服务器开了php-fpm的slowlog，但日志路径写成/../tmp/slow.log，而tmp目录挂载时加了noexec。等于你开了个黑匣子，还顺手把舱门焊死了。

　　说到焊死——去年我帮客户改版，把整站从HTTP迁HTTPS，中间顺手关了旧版Apache的ErrorLog。理由特别实在：“反正没人看，占磁盘”。结果三个月后，某天凌晨三点服务器CPU冲到98%，top里飘着六个/usr/bin/python3进程，每个都在往/data/www/static/下写.php文件，而那个目录的属组早就改成nobody，php-fpm配置里却没限制open_basedir。查error_log？没有。查access_log？全是404。查syslog？只有systemd启动记录。最后靠df -h才发现/data分区用了99%，进去ls -lSh | head -5，排第一的是个3.2G的error_20230608.log.gz——它不在logrotate配置里，没人管，没人删，没人设size limit，它就躺在那儿，一边记着木马写的每一行exec()调用，一边默默等着哪天被tar打包上传到境外VPS。

　　我以前做站群那会儿，半夜起来巡检，习惯性敲tail -f /var/log/auth.log。有次看到一串ssh登录失败，IP是192.168.3.11，用户名试了mysql、ftp、admin、test……试到第十七个的时候，它停了。五分钟后，同一IP成功登陆，用的是刚在论坛泄露的某个CMS后台弱口令（那个CMS我当年自己也用过）。登进去干的第一件事，就是把/var/log/auth.log里前面十七行删了，手法干净利落。但删不掉lastb -a的记录——lastb读的是/var/log/btmp，而那个文件默认不可读，root都得加sudo。所以你以为删干净了？其实只是你眼瞎了。

　　阳台的衣服没收。雨停了半小时，但衣服还在滴水，一滴滴砸在楼下邻居晒的辣椒酱瓶子上，砰、砰、砰。小陈刚才打电话说，“张哥，客户王总说，如果今天内不解决快照问题，就终止SEO服务协议”。我说“嗯”。她说“王总助理刚发来微信，问我们是不是用了黑帽技术”。我没回。王总自己站的友链页上，挂着三百七十二个词，其中二百一十三个是带“高考答案”“志愿填报系统”的锚文本，全是批量生成的。上个月我还提醒他降权风险，他说“流量涨了，先不管”。现在好了，他首页友链失效三十一个，其中七个域名已经指向博彩站——被人黑了都不知道，只当是对方换站了。

　　我翻了翻自己电脑桌面上的notepad++，标签页还开着：/etc/rsyslog.conf，/etc/logrotate.d/nginx，还有个叫“log_blind_spot”的txt，里面记着十二种绕过标准日志捕获的路径组合，最新一条是：/dev/shm/.log_$$（$$是bash PID），每次写完立即unlink，再用inotifywait监听/mnt/ssd/log/下的rename事件触发伪造条目——这玩意儿甚至不走syslog，不碰磁盘，纯内存刷写，重启即焚。你用journalctl查不到，用grep查不到，用logwatch查不到。它就在你眼皮底下，可它不给你看见的机会。

文章配图，仅供参考

　　所以说90%高危漏洞藏于日志盲区，不是玄学。是优胜劣汰。活下来的攻击者，早就不往access.log里写了；活下来的运维，早就不只盯着nginx那几行了；活下来的站长，也早该明白：排名掉下去那天，八成不是算法变了，是你日志里漏掉了一个本该响的警报。至于到底是哪次更新的事我说不准——是PHP 8.1的opcache优化？还是云服务商偷偷升级了底层kvm的libvirt？还是那天我误删了logrotate的一个include？我懒得查了。

　　明天先把手上那批页面删一半试试。删完立刻重跑日志采集脚本，别等明天了，现在就去。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!