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

　　去年八月，我在现场——不是坐在会议室听PPT，是蹲在IDC机柜旁，盯着三台灰度服务器的串口屏，手里捏着运维刚递来的热咖啡，已经凉透了。

文章配图，仅供参考

　　问题出在那条被毙的标题上。不是内容违规，不是SEO埋词太硬，是它触发了一次没记录的日志截断：/api/v3/audit/log?mode=detail&ref=20230817-4489（这个ID我背得出，因为第八次重启后它还躺在curl命令里没删干净）。

　　我原以为是Nginx upstream timeout——毕竟502报错太眼熟了，像老同事打呼噜，听着烦但不致命。结果抓包一看，请求压根没进nginx，卡在syslog-ng的socket缓冲区里，而/var/log/secure最后一行停在八月十七号凌晨两点十七分，之后空白十九小时。

　　空白不是没日志，是日志在写，但没落盘。syslog-ng配置里有一行buffer(1024)，可实际buffer用了四千多字节，溢出后静默丢弃——连ERROR都不打。我们查了三天，最后发现是rsyslog和syslog-ng共存时，/dev/log这个sock被后者劫持，前者还在往旧路径塞数据，塞进去就蒸发。（我后来查过Linux内核文档，3.10以后这个行为是明确未定义的，但没人告诉运维手册要撕掉那页）

　　最怪的是监控告警全绿。Zabbix只盯/var/log/messages大小，只要文件在增长就不报警；ELK pipeline里grok pattern写死了“[INFO]”“[WARN]”，而那段被截掉的日志里只有纯JSON，连方括号都没有——所以它被当作了无效输入，直接丢进dead_letter_queue，queue本身也没配容量告警。

　　甲方张工那天下午三点二十二分站我身后，指甲敲着机柜门：“你们测性能，总得知道log写到哪了吧？”我说“知道啊，在/var/log/app/”。他笑了一下：“可你不知道它是不是真写了进去。”——这句话我到现在都记得清，因为他说完就掏出手机订了回程高铁票，头都没回。

　　我后来翻过所有相关配置备份，二十来分钟，手指冰凉。那个buffer(1024)是三年前一个实习生加的，注释写着“防爆内存”，而真实情况是：当时上线压力测试峰值QPS四百，系统日志量其实每秒就三百条左右，根本用不上缓冲——但没人动它，就像没人动墙上贴了五年的“安全操作规程”，纸边都卷起来了。

　　有谁碰到过这个吗？就是——某条关键业务链路崩了，排查时发现不是代码漏校验、不是SQL慢、不是缓存击穿，而是日志自己把证据嚼碎咽下去，还擦了嘴，连渣都不吐。（对了，我昨天又试了下，把buffer调成65536，问题消失；但没人敢在生产环境改，因为去年十一月改过一次ulimit -n，导致服务启动延迟四十七秒，被风控组追着问了两周）

　　反正……我也不知道为什么非得设这个buffer。

（编辑：航空爱好网）

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