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

　　去年元旦那晚真够我喝一壶的。凌晨三点半，监控突然炸了，好几台机器的磁盘IO直接飙到99%，告警短信跟放鞭炮似的往我手机里钻。我原以为又是哪个开发手滑把日志级别调成DEBUG了，结果冲到机房一看——好家伙，日志文件把/var分区撑爆了，连sshd都起不来，SSH直接断连。

　　当时我第一反应是去捞备份日志，结果翻遍/var/log/audit/，发现最近三个月的审计日志全没了。开发小王在群里喊：“我上周清过日志啊，用crontab跑了个rm -rf .log！”我盯着屏幕直犯懵——他清的是/var/log/messages，可高危漏洞的痕迹全在audit.log里啊！这孙子连auditd和rsyslog都分不清，还敢在生产环境玩定时任务？

文章配图，仅供参考

　　更绝的是，我后来翻系统日志，发现审计日志的轮转配置根本没生效。logrotate的配置文件里写着“daily rotate 7”，可实际执行时，因为/var分区空间不足，日志根本没轮转，直接被小王的定时任务给删了。我蹲在机房里改配置，机房空调吹得我后颈发凉，屏幕上还开着三个终端窗口——一个在查logrotate文档，一个在骂小王，还有一个在等df -h的输出。

　　其实这事儿最让我火大的，是“优胜劣汰”这四个字。我们运维天天盯着磁盘空间、告警阈值、备份策略，可开发们呢？他们觉得日志就是垃圾，清得越干净越好。上次跟开发主管吵了一架，他说：“日志占空间，影响性能，你们运维就不能优化优化？”我反问他：“那要是漏洞被删了，你负责？”他回：“不是有安全扫描吗？”我差点把键盘摔他脸上——安全扫描能扫出已经被删的日志？

　　后来我查了数据，发现90%的高危漏洞确实藏在日志盲区里。比如那个“未授权访问”，攻击者先用弱口令试了十几次，成功登录后删了自己的访问记录，再把审计日志清空。整个过程不到五分钟，可留下的痕迹全在audit.log里——如果它没被删的话。还有那个“SQL注入”，攻击者用分号分割语句，结果被WAF拦了，但拦截记录在/var/log/nginx/error.log里——如果它没被轮转掉的话。

　　其实我们不是没想过办法。我提过用ELK集中存储日志，结果开发说“太复杂，影响性能”；我建议把审计日志单独挂盘，结果采购说“成本太高”；我甚至想过写个脚本，每天把audit.log同步到另一台机器，结果测试时发现同步脚本自己把源文件删了——那晚我盯着空荡荡的/backup/audit/目录，泡面都没吃完，窗外天都快亮了。

　　现在想想，这事儿本来能避免。如果小王没手滑改crontab，如果logrotate配置没写错，如果开发们能多看两眼日志，如果安全部能早点发现审计日志的盲区……可现实是，我们总在“优化性能”和“保留证据”之间摇摆，最后被漏洞钻了空子。就像你明明知道下雨要带伞，可就是懒得拿，结果淋得透湿，还怪天气不好。

　　下一步我打算把审计日志单独挂个1T的SSD，再写个脚本监控日志文件的变化，发现异常直接发邮件给开发主管。至于小王，我已经把他从crontab的权限组里踢出去了——虽然他还在群里喊“运维太事儿逼”，但至少这次，我不会再让他碰生产环境的日志了。

（编辑：站长网）

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