2023年某金融公司的授权安全巡检中，工程师发现一台内网Redis服务器竟能通过公网直接连上，访问且无需任何密码。漏洞更让人后背发凉的授权是，这台服务器上还残留着攻击者写入的访问恶意crontab任务——一条定时反向Shell的指令。这并非电影情节，漏洞而是授权真实存在的、因Redis未授权访问漏洞引发的访问安全事故。

Redis是漏洞一款广泛使用的内存数据库，默认绑定在127.0.0.1，授权只允许本机访问。访问但当运维人员将其部署到公网或内网可达地址时，漏洞若未开启认证或设置了弱口令，授权任何能访问该端口的访问客户端都能直接执行Redis命令。攻击者利用这一点，漏洞可以写入SSH公钥、计划任务甚至WebShell，从而获取服务器控制权。整个过程可能只需要几秒钟。

这个漏洞能造成多大危害？我见过一个案例，某创业公司把Redis当作缓存层，配置里没设置requirepass，也没限制访问来源。结果某天早上，整个数据库被清空，只剩一条名为“yourdata_is_backup_please_contact_me”的键。对方勒索0.5个比特币。业务中断了整整两天，损失远超赎金。这类攻击在自动化扫描工具的帮助下，几乎是无差别打击。

为什么这个老生常谈的问题至今仍在发生？根本原因在于很多开发者默认Redis“只是内部工具”，忽略了它可能暴露在不可信网络中。另一个常见误区是，认为设置了bind 0.0.0.0就万事大吉，却忘了防火墙规则可能形同虚设。我甚至见过某云厂商的默认安全组规则放行了6379端口，用户一启动Redis就裸奔在公网上。

防护思路其实并不复杂。最直接的办法是修改Redis配置文件，启用requirepass设置强密码——但记住，这只能防住弱口令扫描，挡不住内网横向渗透。更稳妥的做法是彻底禁止公网访问，用防火墙或安全组只允许特定IP连接。如果业务必须跨网络访问，务必通过VPN或SSH隧道。此外，以低权限用户运行Redis进程，并禁用CONFIG命令（rename-command CONFIG ""），能有效限制攻击者利用漏洞后的提权操作。

别指望靠运气。我检查过不少系统，发现一个规律：凡是暴露在公网的Redis，被扫描到只是时间问题，慢则几周，快则几小时。攻击者不会挑三拣四，他们用批量工具扫整个网段，发现开放6379就尝试空密码或弱密码，命中率出奇地高。有些老练的攻击者还会在写入后门后删除日志，让追踪变得异常困难。

说个反直觉的事实：很多被攻击的Redis实例其实并非业务必需。有些是为了临时测试开的，用完忘了关；有些是监控工具自带的，管理员根本不知道它在监听。所以，排查资产比加固配置更重要——你连自己有多少台Redis都不知道，谈何防护？

最后提醒一句，Redis 6.0以后引入了ACL机制，可以更细粒度地控制用户权限。如果你还在用老版本，升级到支持ACL的版本，至少能避免“一登录就是root权限”的尴尬。安全没有银弹，但把基础配置做对，就能挡掉九成以上的攻击。