服务器安全审计：90%风险藏于日志盲区

　　三个月之前，我蹲在客户机房里看日志，空调吹得后颈发凉，笔记本散热口卡着半截咖啡渣——那会儿谁都不知道问题出在哪，只知道凌晨三点二十七分，审计平台弹了条红框告警：“SSH 登录异常峰值”，可查了二十来分钟，/var/log/auth.log 里连个失败记录都没有。

　　我原以为是日志轮转搞鬼，结果翻到 /var/log/journal/ 目录下发现 systemd-journald 居然关了持久化，所有 SSH 记录只存在内存里，断电就清空——而他们用的云厂商镜像默认这么配，文档里写得比蚊子腿还细，藏在“推荐配置”章节第八次折叠项底下。

　　张工站我旁边啃苹果，咔嚓一声咬下去，说：“哎，你们审计系统不是连 journalctl 都能拉吗？”我敲了句 journalctl -u sshd -S "2024-04-12 03:25:00"，返回空——他笑：“哦，时间格式你没加时区偏移。”我补了个 +08:00，出来了。六十七条密码爆破尝试，IP 源全是同一个 AWS 小号，伪装成合法跳板机流量，混在 nginx access.log 的正常请求里，每小时刷三次，一次不多、一次不少。

　　但 auditd 模块压根没开，SELinux 是 disabled，/etc/audit/rules.d/ 下只有个空文件夹叫 “placeholder”，创建日期是去年十一月十七日——我问运维老李这谁建的，他扒拉两下耳机线说：“甲方上个月提的需求，说‘先占个位’。”

　　我调了三台机器做对比：A 机跑审计脚本，B 机同步打日志，C 机纯旁路抓包；结果 A 和 B 日志差了四千一百六十二条事件，全集中在凌晨三点前后——因为 cron 在那个时间点顺手 reload 了 rsyslog，而 rsyslog.conf 里有行 $ActionFileDefaultTemplate RSYSLOG_ForwardFormat，把 journal 数据一并转发到远程 syslog 服务器……可那台服务器磁盘满两个月了，队列积压着，没人看。

　　对，就是那个绿色指示灯一直亮着的“正常运行中”状态机柜，它后面堆着三叠旧工单打印纸，最上面那张印着“日志归档服务延迟告警已忽略”，签名人是上周离职的实习生。

　　我最后打开 /var/log/messages，搜 keyword “sshd”，出来八条，全是“connection closed by authenticating user”，但 IP 地址字段全被替换成了“”——后来才知道是客户自己写的 logrotate 脚本加了 awk 处理逻辑，理由是“防止日志泄露敏感字段”，却忘了匹配规则里漏掉了 port 字段的括号逃逸，导致整个 inet_addr 结构被截断。反正，修完之后再跑审计，原来标为“低危”的五处登录行为，其中四处直接升成“高危”，一处连源 IP 都追不回来。

　　我也不知道为啥非得把 auth.log 和 journal 分开存；我也不知道为什么 auditd 默认关着还敢标“符合等保二级”。（楼下便利店新换了冷柜，贴膜还没撕完，反光里能照见我头发根出的汗）

　　那天收工前，我把 journalctl 命令写进监控脚本，跑通了；可第二天早会上，安全组王总监指着大屏说：“上次审计漏报，不是因为日志盲区，是模型训练数据不够新。”我说嗯，没吭声。他手机屏幕亮了一下，微信弹出一条：“王总，备份脚本昨晚上又没触发，tape drive 报错 E71。”

文章配图，仅供参考

　　有谁碰到过这个吗？

（编辑：航空爱好网）

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