未授权访问漏洞修复建议

某天深夜，未授问漏安全工程师老周收到告警：内网一台MongoDB数据库被勒索，权访数据被删光，洞修留下一个比特币地址。复建查日志发现，未授问漏数据库端口直接暴露在公网，权访且未开启认证——任何人连上去都是洞修管理员。这不是复建孤例。根据漏洞情报平台统计，未授问漏未授权访问常年稳居企业高危漏洞前三，权访Redis、洞修Elasticsearch、复建Docker API、未授问漏Jenkins，权访每个组件都是洞修重灾区。修复这件事，比想象中紧急，也比想象中简单。

先说最直接的一招：给服务加认证。别嫌麻烦。Redis的requirepass配一个强密码，MongoDB开启auth模式，Elasticsearch装上X-Pack或Search Guard。很多开发者为图本地调试方便，把密码留空或写死成123456，上线时忘了改。我见过某金融公司测试环境Redis裸奔半年，里面存着几万条用户手机号，还好只是内网，不然后果没法想。密码别用默认的，也别用公司名加年份这种套路，生成一个随机串丢进密码管理器，成本几乎为零。

光有密码不够，绑定IP才是硬道理。大多数未授权访问漏洞的根源，是服务监听了0.0.0.0。改配置，让Redis只监听127.0.0.1或内网网卡地址。如果业务需要跨服务器访问，用防火墙或安全组限制来源IP，白名单里只放业务服务器。比如Jenkins，很多团队图省事，把--listen-address设成0.0.0.0，结果任何人访问http://IP:8080都能直接执行构建脚本。改成内网IP后，攻击面瞬间缩了一半。

还有个经常被忽略的点：组件版本太老。老版本Redis有个CONFIG SET命令漏洞，攻击者连上后能写crontab反弹shell。这玩意儿2016年就被曝光了，但直到2023年，Shodan上还能扫到几万台未修复的实例。别偷懒，用自动化工具定期扫描组件版本，Nessus或OpenVAS都行，发现低于安全版本的直接升级。升级前先看官方变更日志，有些大版本改动会破坏兼容性，比如Redis 6.0之后默认开启了ACL，老脚本可能连不上，得提前适配。

说完技术手段，聊点管理上的细节。很多企业有资产台账，但台账更新不及时。新上线的服务没人录入，安全团队根本不知道还有这么个Redis在跑。建议把“未授权访问检测”写进上线流程的checklist，用脚本自动探测新开端口，发现未认证服务直接拦截。另外，定期做攻防演练，让红队去试着重放未授权访问漏洞，别总在PPT上谈风险。我认识一家电商公司，每季度搞一次内部渗透测试，专门打这些老漏洞，打下来一个奖励红队成员两千块，比任何安全培训都管用。

最后提醒一句：修复完不等于万事大吉。未授权访问漏洞经常和弱口令、默认配置混在一起出现，你修好了Redis，可能旁边还有个Docker API端口开着。用nmap扫一遍全网的0.0.0.0监听，把结果拉出来逐个过。安全这事儿，本质上是跟懒惰作斗争，你多花十分钟改配置，攻击者就得花十小时找别的路。