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

　　去年一月份那会儿，运维突然在群里吼了一嗓子，说某台核心服务器的监控炸了——CPU直接顶满，内存蹭蹭往上涨，风扇转得跟直升机似的，我盯着屏幕上的行数跳了俩小时，外卖都凉透了还没敢动筷子。后来一查，好家伙，是某个中间件的默认配置没改，直接开了调试模式，把所有请求日志全往磁盘写，写爆了俩分区。这事儿当时没觉得多稀奇，直到上周跟几个老运维吃饭，他们说现在查漏洞，十有八九都是那三类配置问题——权限放太宽、默认配置没动、版本升级没同步参数。我原以为他们夸张，结果翻了下近三年的安全通报，还真是这么回事。

　　第一类最常见的是权限配置，说白了就是“该关的门没关”。比如去年有个项目，开发为了方便测试，给数据库账户开了所有表的读写权限，结果上线后忘了收，被扫漏洞的脚本抓了个正着。更离谱的是，有次我查日志发现，某个内部工具的API接口居然用了HTTP明文传输，连个Basic Auth都没加——开发说“反正是内网，没事”，结果运维误操作把内网端口映射到了公网，差点酿成大祸。这类问题最气人的是，明明花五分钟就能改，但总有人觉得“麻烦”“没必要”，等出事了才拍大腿。我上次跟一个开发吵了一架，他非说“权限收太紧会影响效率”，我直接甩了监控截图：“你这接口被爬虫刷了三万次，效率是高了，服务器都快跪了。”他这才闭嘴去改配置。

　　第二类是默认配置的坑，尤其是那些“开箱即用”的中间件。比如Redis，默认配置里没有密码，也没有限制IP访问，我见过好几个项目直接拿默认配置上生产，结果被黑客扫进去当肉鸡。还有MySQL，默认的max_connections设得特别低，业务高峰期一上来就报“Too many connections”，开发还以为是代码问题，折腾了半个月才发现是参数没调。最绝的是某次升级，新版本的Nginx默认开了某个实验性功能，结果跟旧版的Lua模块冲突，直接导致服务崩溃——运维在群里骂了半小时“谁他妈写的升级文档”，后来发现是官方文档里没标清楚。这类问题就像地雷，平时藏得好好的，一踩就炸，而且炸完还不知道是谁埋的。

　　第三类是版本升级时的参数丢失，这个最隐蔽。比如我们之前用Kafka，从0.10升到2.0，配置文件格式变了，但运维图省事，直接复制了旧版的参数过去，结果有几个关键参数（比如log.retention.hours）在新版里被移除了，系统默认用了更短的保留时间，导致三个月的数据全丢了。等发现的时候，业务方已经找上门来，领导在会议室拍桌子：“数据丢了你们负责？”我查了半天日志，最后在某个角落里找到一行小字：“Deprecated configuration 'log.retention.hours' ignored”——合着系统早就提醒了，就是没人看。这类问题就像温水煮青蛙，平时没感觉，等出事了才发现，原来早就烂透了。

文章配图，仅供参考

　　其实这些配置问题，说到底就是“懒”和“侥幸”。开发懒得改默认配置，运维懒得查升级文档，业务方懒得等安全审核——大家都觉得“没事，出不了大事”，结果真出事了，又互相甩锅。我原以为“90%漏洞源于配置疏漏”是安全部门为了推责任编的，结果翻了这么多案例，发现还真是这么回事。优胜劣汰的道理在这儿特别明显：那些认真改配置、查文档、做备份的团队，漏洞就是少；那些图省事、靠运气、等出事的团队，漏洞就跟韭菜似的，割了一茬又一茬。

　　现在的问题是，怎么让这些人重视起来？光靠安全培训没用，他们听的时候点头，回去该咋干还咋干；光靠罚钱也没用，业务方会哭穷，领导会妥协；光靠自动化工具也没用，工具能检测配置错误，但检测不了人的侥幸心理。我上次提了个方案，说以后上线前必须让运维和安全双签，结果开发说“这样会拖慢进度”，领导说“先试试，不行再改”——现在试了三个月，漏洞确实少了，但开发天天抱怨“流程太复杂”。我也不知道这方案能撑多久，说不定哪天领导一拍脑袋，又给改回去了。毕竟，在效率面前，安全永远是第二位的——除非真出事了。

（编辑：我爱制作网_池州站长网）

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