未授权访问漏洞解决

凌晨两点，未授问漏我盯着监控大屏上那条刺眼的权访告警记录——某台测试服务器的Redis端口，从境外IP连续发来三次CONFIG SET命令。洞解攻击者已经拿到了root权限，未授问漏只是权访还没把数据拖走。这场景我见过太多次了，洞解每次都是未授问漏同一个原因：有人把服务裸奔在公网上，连个密码都没设。权访

未授权访问，洞解说白了就是未授问漏你的服务默认信任了所有连接。Redis、权访MongoDB、洞解Elasticsearch、未授问漏Docker，权访这些工具为了开发方便，洞解出厂配置都把自己当成了“内网专属”，结果被搬到公网上，就成了人人可进的菜市场。我见过最离谱的一次，某电商平台的Kibana面板直接暴露，用户订单、手机号、住址全在页面上挂着，连登录框都没有。运维说“以为只有内网能访问”，可云服务器的安全组规则里，赫然写着/0。

解决这事儿，第一步永远是把服务绑到内网IP上。别嫌麻烦，改一行配置的事。Redis就在redis.conf里把bind 127.0.0.1换成内网地址，MongoDB改net.bindIp，Elasticsearch改network.host。这一步做完，公网上的扫描器就再也摸不到你的端口了。但光这样还不够——内网也未必安全，隔壁部门被攻破后横向移动到你服务器上的案例，我一年能碰上三次。

第二步，必须开启认证。别用弱密码，别用默认密码。Redis的requirepass、MongoDB的auth开关、Elasticsearch的X-Pack，全都配上强密码。有人嫌麻烦，说“我内网IP已经绑了，攻击者进不来”。那你想想，你的办公电脑是不是也在内网？某个员工点了钓鱼邮件，机器被控，攻击者顺着内网扫一圈，发现你Redis没密码，直接FLUSHALL清空数据再写个勒索信——这种事我处理过，受害者恢复数据的费用够买十台服务器了。

第三步，防火墙规则要精准。安全组别图省事开大段端口，只放行业务需要的IP。比如你的应用服务器是10.0.0.5，那就只让10.0.0.5访问6379端口，其他全拒。云平台的安全组、本机的iptables、ufw，三层防线都设上。别信“默认拒绝”的配置，很多云厂商的默认安全组就是全放行，你得自己动手改。

还有个小细节，很多人忽略——版本升级。Redis 3.x时代有个著名的EVAL命令漏洞，不需要密码就能执行任意代码。后来官方加了requirepass默认开启，但老版本依然裸奔。你查查自己的服务版本，如果是两年前装的，大概率有已知的未授权漏洞。升级到最新稳定版，顺便把默认配置里的危险项（比如Redis的protected-mode）确认一遍。

最后说个真实教训。上个月有个客户，自认为上面三步都做了，结果还是被入侵。排查半天，发现是他们的监控脚本用了redis-cli -h 127.0.0.1，但脚本里写的密码是明文，还放在了一个可被读到的日志文件里。攻击者没走Redis，直接读日志拿密码，从合法通道进来了。所以记住：认证信息别硬编码，用环境变量或密钥管理服务。安全这事儿，永远在细节里翻车。

别等告警响了才动手。现在就去检查你的服务配置文件，看看bind是不是0.0.0.0，requirepass是不是空着。改完记得重启服务，再拿nmap扫一遍外网端口，确认该关的都关了。花半小时，省下的是整个数据库被拖走的代价。

(责任编辑：时尚)