多媒体服务器安全审计：90%漏洞源于3个忽视配置

　　凌晨三点半，告警响的那一刻，我盯着屏幕上的漏洞扫描结果，泡面在键盘边凉透了。九台多媒体服务器，八十七个高危漏洞——开发那边刚拍胸脯保证“绝对没改过配置”，可扫描报告里明晃晃写着：90%的漏洞，全他妈是三个被忽视的配置项搞出来的。我原以为这种低级错误早该绝迹了，结果翻去年日志，好家伙，同样的坑，去年摔过五次，今年还能再摔八次。

　　第一个坑是证书过期。多媒体服务器跑的是自签证书，运维手册里写着“有效期三年”，可实际呢？三台机器的证书是2023年生成的，两台是2024年，剩下四台——我他妈根本查不到生成记录。开发说“反正内网用，过期也没事”，结果扫描器直接报“证书链不完整”，攻击者能中间人劫持流媒体传输。更绝的是，其中一台机器的证书私钥还明文存着，路径就在/etc/ssl/private/下，连权限都没设——我查日志发现，这私钥是2022年某个实习生传的，传完就离职了，没人删。

文章配图，仅供参考

　　第三个坑是日志轮转。多媒体服务生成日志特别猛，每小时能写2G，可九台机器里，只有两台开了logrotate，剩下的七台——日志文件把/var/log盘撑爆了三次。第一次宕机是凌晨一点，磁盘使用率100%，服务直接挂；第二次是开发自己删日志，结果删错了文件，服务起不来；第三次是我半夜爬起来手动清理，删到一半，电话响了——是媳妇，问我“孩子发烧了，你什么时候回来？”我盯着屏幕上还在滚动的“rm -rf /var/log/media/”，手一抖，差点把根目录删了。

　　其实这些坑，扫一眼配置文件就能发现。可问题是，谁他妈扫配置文件啊？运维天天忙着处理告警、扩容磁盘、备份数据，开发天天催着上线新功能，安全审计？那是“有空再说”的事。我翻了下今年的安全培训记录，九个人里，只有两个人参加了“配置审计”课程，剩下的全选的“容器安全”或“API防护”——更时髦，更“有技术含量”。

　　跟开发吵了一架。他们说：“这些配置又不是我们改的，肯定是运维没维护好。”我说：“那证书私钥明文存着，是运维干的吗？Nginx配置写错，是运维干的吗？”他们不说话了，低头刷手机。过了一会儿，主管进来说：“先别吵了，先把漏洞补上，客户等着要报告呢。”我打开vim，开始改配置文件，窗外天快亮了，机房的空调吹得我胳膊起鸡皮疙瘩。

　　我原以为“优胜劣汰”是自然规律，可在这行，低级错误反而活得最久。去年我提过要上配置审计工具，领导说“太贵，先手动查”；今年我写了个脚本，能自动检测证书过期、端口开放和日志轮转，结果开发说“脚本会误报，别用”；现在好了，九台机器，八十七个漏洞，客户要索赔，领导要追责——可追谁呢？追那个离职的实习生？追那个忘了改Nginx配置的开发？还是追我这个“没及时发现”的运维？

　　下一步我打算把脚本再改改，加几个更狠的检测项——比如检测私钥是否明文存储，检测端口是否对外开放，检测日志文件是否超过10G。可我知道，就算改了也没用，因为没人会定期跑这个脚本，就像没人会定期检查证书有效期一样。除非哪天真的被攻击了，数据泄露了，客户投诉了，领导才会拍桌子说：“必须上配置审计！”可到那时候，黄花菜都凉了。

　　其实这事本来能避免。如果开发改端口的时候，能多看一眼Nginx配置；如果运维巡检的时候，能多扫一眼证书有效期；如果领导能多批点预算，买个配置审计工具——可没有如果。就像我泡面没吃完，媳妇电话没接完，漏洞没补完一样——这行就是这样，永远在补漏洞，永远在救火，永远在为别人的疏忽买单。

（编辑：站长网）

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