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

　　去年十一月那波攻防演练，我原以为又是哪个新框架的零日漏洞，结果扒开日志——好家伙，90%的入侵路径全是配置疏漏。更离谱的是，这三类问题我三年前就在安全群里喊过，现在还有人踩坑。器械区镜子上有道划痕，斜着从左肩到右胯，那天老张深蹲时杠铃片蹭的，他非说是镜子质量差，可那镜子是去年刚换的德国货。

　　第一类是权限配置代偿。有个生产环境的Redis，密码设成"admin123"就算了，还开了外网访问。攻击者扫到端口后，直接用默认密码登录，把数据库拖了个底朝天。我查配置时发现，运维为了方便远程管理，在/etc/redis.conf里把"bind 127.0.0.1"注释掉了，注释符号还是手敲的空格——那行代码缩进都不对齐，明显是临时改的没改回来。更绝的是，同机房的MySQL实例，root密码居然和Redis一样，这哪是配置疏漏，这是把钥匙插门上还贴了"请自取"的纸条。

　　前台在煮咖啡，机器咕嘟咕嘟响，我闻着味儿过去，她正用手机刷安全证书的考试题。"你说这证书有用吗？"她举着手机问我。我瞥了眼屏幕，题目是"如何防止SQL注入"，答案选项里有"转义特殊字符"和"使用预编译语句"——这俩都对，但选哪个都救不了刚才那个Redis。跑步机电机的嗡声突然变大，估计是老王又在冲极限重量，他总说"泵感"比安全重要，上次把杠铃片甩到墙上，砸出个拳头大的坑，地胶上到现在还有块黑印。

　　第二类是补丁管理掉秤。有个Web服务器，CVE-2021-44228的漏洞补丁都出半年了，运维还没打。攻击者用Log4j2的远程代码执行，直接在服务器上开了个反向Shell。我查补丁记录时发现，运维的消课流程有问题——他先把补丁下载到本地，再手动上传到服务器，结果有次上传错了版本，导致服务崩溃，从此就再也不敢打补丁了。"卡平台期了？"我问他。他挠挠头："不是，是怕打补丁把业务打挂了。"更衣室的门关不严，风一吹就"咣当"响，他说话时门正好被吹开，露出里面堆着的私教课合同。

　　第三类是日志配置卡平台。有个API网关，访问日志只保留7天，攻击者在第8天发起攻击，等我们发现时，日志已经被轮转掉了。我查配置时发现，logrotate的规则里，maxage参数设成7，而size参数设成1G——这意味着只要日志文件不超过1G，就会一直保留，但实际运行中，日志增长速度远低于1G/天，所以maxage成了摆设。饮水机旁堆的一次性杯，有个被踩扁了，杯口还沾着口红印，估计是哪个女会员训练时喝水，随手把杯子扔地上，被后来的人踩到了。"这日志配置，跟会员体测似的。"我对旁边的会籍说，"测了等于没测，数据全白瞎。"

　　我原以为这些问题是小公司才会犯，结果在某大厂的攻防演练里，也发现了同样的配置疏漏——他们的Kubernetes集群，默认ServiceAccount有cluster-admin权限，攻击者通过一个Pod，直接提权到集群管理。更讽刺的是，这个集群的审计日志里，明明记录了所有权限变更操作，但日志服务器没开索引，查个记录要等半小时，等查到时，攻击者早就跑路了。深蹲架旁的手机突然震动，是运维的钉钉消息，我瞥了眼屏幕，标题是"生产环境告警"，内容是"CPU使用率超过90%"——这警报来得太晚，攻击者可能已经把数据传走了。

　　为什么说"优胜劣汰"能站住？因为这些配置疏漏，本质是运维的"懒癌"和"侥幸心理"在作怪。权限配得太松，是因为怕麻烦；补丁不打，是因为怕出事；日志不留，是因为怕占空间。但安全这事，最怕的就是"怕"——你怕麻烦，攻击者就怕你不麻烦；你怕出事，攻击者就怕你不出事；你怕占空间，攻击者就怕你不占空间。我见过最离谱的案例，是个金融公司的数据库，密码居然写在配置文件的注释里——运维说"这样方便记忆"，结果攻击者直接grep注释，把密码挖出来了。

文章配图，仅供参考

　　现在的问题是，这三类配置疏漏，就像健身里的"顽固脂肪"，怎么减都减不掉。权限配置代偿，得靠自动化工具管；补丁管理掉秤，得靠持续集成/持续部署（CI/CD）流程卡；日志配置卡平台，得靠日志分析平台实时监控。但这些工具和流程，都需要人去配，而人，恰恰是最不可控的因素——就像会员训练，教练再怎么指导，他要是偷懒，照样没效果。

　　所以我的结论是：90%的服务器漏洞源于三类配置疏漏，这数据可能有点夸张，但方向没错。要解决这问题，得从"人"下手——要么用工具代替人，减少人为错误；要么用制度约束人，让运维不敢偷懒。至于效果如何？看明年攻防演练的结果吧。要是还这么多配置问题，我可能得考虑转行去卖补剂了——至少补剂不会因为配置疏漏被攻击。

（编辑：应用网_阳江站长网）

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