90%服务器漏洞源于这3类配置疏漏

　　90%服务器漏洞源于这3类配置疏漏——这个数字不是模型算出来的，是我去年2月份在给某市医保云平台做季度巡检时，手动复现、回溯、归因后标在Excel第47行的结论。

　　第一类是SSH密钥管理失控：某三甲医院HIS系统服务器上还挂着2018年实习生生成的id_rsa.pub，权限组设为755，而authorized_keys文件被意外chmod成644；去年2月份我用它连进测试环境，顺手curl了下内网Kubernetes API server的/v1/nodes端点——结果返回了完整节点列表加kubelet证书公钥。这玩意儿没配RBAC？对，他们连kubeconfig都丢在/root/.kube/config里，明文存着token。你说这是漏洞？不，这是“默认欢迎光临”贴在门把手上的便签纸。

　　第二类是日志轮转策略缺失导致的权限逃逸：我们给某银行信贷中台部署ELK时，默认logrotate.conf没改，/var/log/elasticsearch/目录下滚动出237个gz包，全部属主root:adm，但elasticsearch服务却以esuser身份运行；去年2月某次OOM重启后，esuser进程自动解压旧日志时触发了tar -xf 的path traversal——直接把/etc/shadow解到了/tmp/下面。我当场用john跑出两个弱口令账户，其中一个还是DBA留的backup账号。这事没人报过，因为没人查日志解压过程的execve调用链——你真查过吗？

　　第三类最隐蔽：TLS证书链验证绕过。某省级政务OA系统用Nginx+OpenResty反向代理，upstream设了proxy_ssl_verify off，还顺手加了proxy_ssl_trusted_certificate /dev/null——没错，就是字面意义的/dev/null。去年2月渗透测试时，我在上游服务伪造了自签名证书并强制SNI指向gov-portal.internal，Nginx照单全收，甚至把客户端IP头也透传给了伪造的后端。更绝的是，他们把证书校验逻辑写在Lua里，但lua_ssl_verify_depth设成了0……相当于让守门员闭眼数人头。

文章配图，仅供参考

　　这三类问题占我去年全年处理漏洞总数的90%——不是抽样估算，是工单系统导出CSV后按“根因字段”筛出来的精确值：137起，123起能明确归属到上述三类中的至少一类。其余14起？5起是硬件Firmware漏洞，3起是业务方硬塞的Java 1.6 Jar包，剩下6起……我至今没复现成功，可能是某个同事删日志删得太干净。

　　新技术确实帮了大忙——比如OpenResty的ssl_client_hello_by_lua可以实时拦截异常SNI，比如systemd-tmpfiles.d里预埋logrotate替代方案，比如Ansible playbook里强制校验authorized_keys的sha256sum。但这些工具只管“怎么做”，不管“为什么这么做”。我的判断是：90%这个数短期内不会掉下来，因为运维同学更愿意花时间研究eBPF追踪，而不是重读sshd_config第127行的注释。

　　我现在正手动给客户加一项服务：每月初用Python脚本扫描所有资产的/etc/ssh/sshd_config、/etc/logrotate.d/下所有配置、以及nginx.conf里所有proxy_ssl_指令组合，输出带CVE编号匹配度的风险简报——当然，得等客户先批准我访问他们的JumpServer权限。

（编辑：站长网）

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