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

　　我越来越觉得“服务器安全审计：90%漏洞源于三大配置疏漏”是错的。

　　去年六月份，我在某省政务云做渗透复测，甲方运维组长老周蹲在机房门口啃冷包子，嘴里还叼着半截没点着的烟——他刚被通报说“SSH未禁用密码登录、Nginx暴露版本号、Redis绑定0.0.0.0”，这仨，正是那“三大配置疏漏”的标准答案。我当场点头，转身就写了整改单。结果三天后蓝队扫出个CVE-2023-27536，利用点根本不在配置里，在Spring Boot Actuator的/metrics接口上，而那个接口压根没开——它只是被某个测试分支打了个快照，偷偷挂在了生产环境的jar包里，连Dockerfile都带了构建时注入的test-profile。老周把包子袋揉成团砸进垃圾桶：“谁他妈还去翻三个月前的CI日志？”

　　我原以为漏洞总得有个落脚点：要么配错了，要么开多了，要么关少了。结果呢？上周审计某支付中台，我们盯着JVM参数调优表看了两小时，连-Xss都逐行核对过，最后发现漏洞是Kafka消费者组里的一个死循环重试逻辑——它每失败一次就往ELK写一条DEBUG日志，而logback.xml里配的是，HTTP超时设成了0。线程池满了，健康检查探针直接失联，整个服务实例被轮询剔除，但下游又没熔断，于是三十七个订单重复扣款。开发小李拍大腿：“哎哟，忘了删调试用的Appender，我以为打包时会被maven-profile过滤掉……”

文章配图，仅供参考

　　你查配置？它不走配置。你扫端口？它不开新端口。你验证书？它压根不走HTTPS。它就在classloader里安着家，在spring.factories里报备，在META-INF/services/里留条缝。去年七月，我们团队写了个自动检测jar包内嵌配置项的工具，跑十七个站，其中九个在application-prod.yml里干干净净，可lib目录下有个commons-configuration2-2.8.1.jar，里面META-INF/maven/org.apache.commons/commons-configuration2/pom.properties写着build.timestamp=2021-04-12T08:23:17Z——这时间戳一查，就知道是三年前某次本地编译后误传进来的快照版，它自带一个PropertyConverter，能把${env:HOME}解析成root用户的家目录路径，而那个路径下恰好有.ssh/id_rsa.pub……这事后来没人提，因为审计报告里根本没法归类：它不算配置错误，不算代码缺陷，不算依赖漏洞——它就是个时间戳污染事件。

　　（顺带一提，那个运维老周现在管着三个地市的等保测评，上个月还在群里甩截图，说某厂商交付的堡垒机后台有个/jsp/test.jsp，里面new File("/proc/cpuinfo").listFiles()……我回了个“？”，他补了句：“他们测试环境这么写的，上线也没动。”）

　　“三大配置疏漏”能活下来，靠的不是准，是优胜劣汰——它筛掉的是连ssh_config都不会看的人，留下的是真会翻conf.d的人；它淘汰的是改完nginx.conf就重启的人，留下的是敢进strace看epoll_wait阻塞在哪的人。但它解决不了的问题，比它定义的问题多。比如财务系统凌晨三点突然告警说数据库连接数爆了，DBA查慢SQL查到天亮，最后发现是前端埋点SDK把用户token拼进了URL，CDN缓存键里含了authorization header，缓存雪崩后，Java应用里的HikariCP连接池死锁——这个死锁触发链里没有一行配置是错的，所有yaml、xml、properties全合规，可它的线程栈顶堆着三个LockSupport.park，其中一个正在等ThreadLocalMap里一个早该GC却还活着的LoggerContext引用。这玩意儿你让安全扫描器怎么配规则？

　　所以我说它错，不是因为它没用。它是新手村任务，是门槛上的垫脚石。但它被当成主干道用了。主流说法把配置当漏洞源，其实是把责任推给最显眼、最容易归因、最方便写进《整改通知书》的东西。就像去年十月，我帮某银行复盘那次RCE，最终根因是Dubbo泛化调用时用的TypeUtils.compatibleType方法，接收了一个由外部可控的String[]参数，而这个数组长度刚好绕过了ArrayList的扩容阈值判断，导致后续序列化时触发了一个已废弃但未删除的Fastjson 1.2.24的反序列化gadget……可审计报告首页还印着红字：“建议：关闭Dubbo服务端的generic开关”。——关了，漏洞还在，只是换了个姿势发作。

　　（对了，开发小李上月转岗去做SRE了，今天早上给我发消息问：能不能用eBPF hook住Java虚拟机的ClassLoader.defineClass，只拦截那些包含“log4j”且路径含“/target/”的class字节码？我没回。这事我也可能就运气好。）

　　再说个细的：我们测过一台物理机，内核4.19.245，selinux enforcing，iptables全开，SSHD强制密钥认证，systemd-journald加密日志——但/var/log/audit/audit.log属组是wheel，权限640，而devops组里有三个人，其中一人uid是0，gid是999，他昨天改过一次ansible playbook，加了一行copy模块，dest设成/var/log/audit/。你去审配置？它每一行都在最佳实践手册第7页。可audit.log本身，正以二进制形式躺在一个SFTP账户的下载目录里，那个账户连FTP都不走，走的是OpenSSH自带的sftp-server，而sftp-server的ChrootDirectory配置项，在openssh 8.9p1里有段注释写着“注意：若父目录非root所有，则chroot可能失效”。

　　所以别再拿“三大疏漏”当尺子量世界了。它量的是配置文档，不是系统行为；它卡的是人工流程，不是机器状态。漏洞不长在/etc里，它长在git blame里没写的那行注释里，在Jenkins流水线里被disable掉的单元测试里，在外包同学删掉的一行logger.warn(“debug mode on”)后面悄悄多出来的if(true) {}里。

（编辑：站长网）

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