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

　　昨晚凌晨三点半，三台机器同时告警响得跟放鞭炮似的，我原以为又是哪个开发手滑把流量打满了，结果一查日志——好家伙，又是SSH端口裸奔。这月第三次了，开发那边还搁那儿扯“我们测试环境不用管安全”，我直接把监控截图甩群里：“优胜劣汰懂不懂？现在不搞配置安全，等被扫成肉鸡的时候，老板可不会听你解释这是测试环境。”

　　其实这90%的锅，真得扣在三类配置上。第一类最离谱：默认配置不改。去年迁移那批新机器，我特意让运维小王把MySQL的root密码从空改成随机字符串，结果上周扫漏洞发现，三台机器的root还能直接登录——小王说“我以为自动化脚本会改”，脚本作者说“我以为运维会手动改”，最后发现是脚本里有个注释掉的配置行没删干净。现在那三台机器的日志里全是海外IP的暴力破解记录，我盯着屏幕看了五分钟，泡面都凉透了也没敢动鼠标。

　　第二类更气人：权限乱给。上个月跟开发吵了一架，他们非要在生产环境装个调试工具，说“就临时用用”，我死活不让开端口。结果第二天发现，有个开发用root账号在/tmp下建了个目录，权限给成777，说是为了“方便同事传文件”。当天晚上就被扫出个任意文件上传漏洞，攻击者直接往那目录里塞了个挖矿脚本。我查日志的时候，发现攻击IP里有个是开发自己的笔记本——他可能到现在都不知道，自己成了内鬼。

　　第三类最隐蔽：证书过期。这事儿说起来都丢人，上周三台负载均衡的证书过期了，导致部分用户访问报错。我原以为监控会告警，结果一看配置，告警阈值设的是“提前7天”，而证书是“提前30天”到期——等监控响的时候，证书已经过期三天了。更绝的是，备份证书的目录权限被改过，只有root能读，而我当时用的运维账号没加sudo权限。那天我在机房待到天亮，屏幕上的命令行闪得眼睛疼，最后还是找同事用他的账号把证书换上的。窗外天都亮了，我才想起来晚饭还没吃。

　　其实这些配置问题，说白了就是“懒”和“侥幸”。开发觉得“反正有运维兜底”，运维觉得“反正有监控告警”，结果谁都没兜住。我见过最夸张的案例，是有个同事把防火墙规则写成“允许所有IP访问22端口，除了几个已知的攻击IP”——结果攻击者换个IP就进来了，他还纳闷“怎么监控没报”。后来查日志发现，那几条规则根本没生效，因为他把“deny”写成了“denny”，拼写错误导致规则被忽略。这事儿我到现在都没敢告诉他，怕他当场辞职。

　　但话说回来，这些配置问题也不是无解。比如SSH端口，我现在直接让自动化脚本随机生成一个五位数的端口，改完还把22端口封掉——开发要是再抱怨“连接不上”，我就让他们自己查脚本。权限管理更简单，直接上最小权限原则，谁要开777就让他找CTO签字。证书过期这事儿，我现在用crontab每天跑个脚本，提前30天就开始发邮件警告，谁不看邮件谁背锅。

文章配图，仅供参考

　　现在我看着监控里的告警，心里直发毛。这三类配置问题，就像三颗定时炸弹，不知道哪天就炸了。我原以为只要监控够全、流程够严就能避免，结果发现，最靠谱的还是得从根儿上改——让开发知道，配置安全不是运维的事儿，是每个人的事儿。就像我上周在群里说的：“现在不搞配置安全，等被扫成肉鸡的时候，别怪我没提醒过你们。”

　　下一步我打算把这三类配置问题写成检查清单，每次上线前让开发和运维一起过一遍——谁漏了谁背锅。其实这事儿本来能避免，就是大家都觉得“别人会管”，结果谁都没管。现在好了，告警响的时候，谁也别想跑。

（编辑：站长网）

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