服务器安全审计：90%漏洞源于3类配置疏漏

　　去年八月那波安全审计，我原以为能挖出什么高级货，结果翻烂了三十多台服务器的日志，发现九成漏洞都是配置疏漏——就三类，权限过松、补丁滞后、日志绕过，跟去年前年大前年的报告一个德行。开发在群里嚷嚷“怎么又是这些”，我直接甩了份近五年的审计报告过去：优胜劣汰啊，攻击者又不傻，专挑最省事的漏洞打，谁还跟你玩花活？

　　就说权限那事儿，有台数据库服务器的/data目录，权限给到了777，我查配置的时候风扇一直在转，屏幕上的行数跳得跟心跳似的。问了运维，他说“之前备份脚本报错，临时改的，后来忘了改回来”——临时改的能留半年？更离谱的是，这目录下存着用户密码的哈希值，虽然不是明文，但攻击者要是拿到，彩虹表一跑，直接撞库。开发后来跟我吵：“我们程序里加了盐，撞不出来的！”我反手甩了份撞库工具的GitHub链接：“盐是死的，字典是活的，你当攻击者都是吃素的？”

　　外卖凉了的时候，我正盯着第二类问题：补丁滞后。有台Web服务器，OpenSSL版本还是1.0.2，漏洞编号CVE-2016-2107，2016年的老漏洞！我问运维：“这补丁没打？”他说：“打了，但重启失败，怕影响业务，就回滚了。”我查了下，重启失败是因为业务方的某个脚本写了死路径，补丁后的OpenSSL路径变了，脚本报错。业务方路过问了句“好了没”，我指了指屏幕：“你们脚本写的死路径，补丁打不上，漏洞留着过年？”他“哦”了一声，走了——后来也没改，说是“优先级不高”。

　　第三类更隐蔽：日志绕过。有台应用服务器，Nginx的access_log开了，但error_log没开，攻击者通过POST请求传了个畸形参数，服务器返回500错误，但日志里没记录。我查配置的时候，开发在旁边嘟囔：“500错误不是客户端的问题吗？记录它干啥？”我差点笑出声：“500是服务器内部错误，攻击者专挑这种接口试漏洞，你不记录，等被黑了连入口都不知道！”他撇撇嘴：“那开error_log会不会影响性能？”我指了指磁盘IO监控：“你见过哪台服务器的IO被打满是因为日志？倒是补丁不打、权限乱给，分分钟被扫爆。”

　　窗外天黑了，我还在翻另一台服务器的配置。这台的MySQL开了远程访问，但bind-address没限制，理论上能被任何IP连。我问运维：“这不怕被扫？”他说：“我们有防火墙，只放行了内网段。”我查了防火墙规则，确实只放了内网，但MySQL的user表里有个用户，host字段是‘%’，密码还是弱口令。我原以为防火墙能兜底，结果配置和权限是两码事——攻击者要是拿到内网某个机器的权限，直接就能连MySQL，防火墙形同虚设。开发后来补了句：“我们程序里限制了IP，数据库层不用管。”我直接怼：“程序能防住内网渗透？等攻击者拿到shell，第一件事就是扫数据库！”

　　值班的时候跟领导吐槽这事儿，他说：“配置问题都是运维的锅，跟开发没关系。”我差点把咖啡喷出来：“权限是开发写的SQL建的表，补丁是运维打的但业务方不让重启，日志是两边都没重视——这锅怎么分？”他沉默了两秒：“那以后审计重点查这三类？”我摇摇头：“查没用，得改。但改要动业务方的脚本、开发的习惯、运维的流程，谁愿意配合？”他叹了口气：“先出个报告吧，至少让上面知道。”

　　现在的问题是，这三类配置疏漏，说小不小，说大不大——权限过松可能泄露数据，补丁滞后可能被远程执行，日志绕过可能掩盖攻击路径。但为什么年年审计年年有？因为改起来麻烦：要协调业务方停机、要测试补丁兼容性、要调整日志策略，哪样都不轻松。我原以为技术问题能靠技术解决，结果发现，九成的漏洞，根源都在“人”——怕麻烦的人、侥幸的人、不重视的人。

文章配图，仅供参考

（编辑：站长网）

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