Redis 又上热搜了。每次有人在安全群里喊Redis被批量打穿的时候评论区总会出现同一个问题我就是装了Redis怎么判断自己中没中招说实话这个问题挺难回答因为很多人连自己的Redis已经成了攻击者的肉鸡都没察觉——端口6379开着、requirepass没配、bind 127.0.0.1还躺在注释里这类情况我每隔一段时间就能在生产环境里撞见一次。这篇文章我打算换个角度聊不堆CVE编号而是把Redis漏洞这件事从头到尾拆开它为什么隔三差五出现在漏洞报告和热搜词里、真实攻击者是怎么一步步得手的、我们做防御的人应该如何复现和验证这条链路、最后生产环境到底该怎么加固才能把自己从漏洞重灾区里拎出来。无论你是运维、开发还是刚入门的安全新人顺着这条线走一遍你至少能搞清楚一个核心问题Redis的安全水位到底是靠什么撑起来的。1. 为什么Redis总出现在漏洞榜上设计基因里的几道暗门Redis被点名不是一两年的事了。从早期爆出的未授权访问到后面的主从复制RCE再到各种配合弱口令的批量扫描事件它的漏洞体质其实和它的出身有直接关系。1.1 未授权访问被当成默认值的裸奔模式Redis诞生的时候主要跑在内网开发者默认使用它的人都是可信的。所以你会发现早期的Redis配置非常简单安装完不做任何设置它就会监听在所有网卡上任何能连到6379端口的客户端都可以直接执行命令根本不需要认证。这个设计放在那个年代没毛病但放到现在的公网环境里就等于是开着门不锁就出门。后来官方也意识到问题加了protected-mode yes这个受保护模式。注意这个保护模式只在Redis监听了本机回环地址127.0.0.1或者没有任何显式bind配置的时候才生效。如果运维手滑把bind 0.0.0.0写在配置里或者干脆用默认配置不做任何bind受保护模式在部分场景下是可以被一些手法绕过的。更不用说一堆老版本压根没有这个机制——很多还在生产环境跑着的Redis 3.x、4.x默认配置依然是全网裸奔。1.2 主从复制机制功能特性如何被改造成攻击跳板主从复制本意是好的主库把数据同步到从库实现读写分离和高可用。攻击者看中的恰恰是这条链路。Redis 4.0开始支持通过MODULE LOAD加载外部模块这本来是为了扩展功能比如加一些自定义数据结构和命令。但2019年前后被公开利用的主从复制RCE思路就是把这两个特性串起来了攻击者先让受害Redis执行SLAVEOF指向自己控制的恶意Redis服务器然后通过主从同步把一个编译好的恶意模块文件写进受害Redis的数据目录再通过MODULE LOAD加载这个模块。模块一加载等于攻击者拿到了一条直接执行系统命令的通道。这个思路之所以经典是因为它把Redis的高可用功能直接变成了远程命令执行入口。后来官方在新版本里做了一些限制但大量存量老实例仍然暴露在风险中。1.3 弱口令与公网暴露大多数漏洞事件的共性前提抛开那些花哨的利用链我更愿意说一个扎心的事实我所处理过的大部分Redis失陷事件根因根本不是0day而是公网暴露弱口令。用测绘工具在公网扫一下6379端口出来的结果能让你头皮发麻。再配合常见弱密码字典跑一遍能拿到权限的实例数量相当可观。这也是为什么每次Redis相关漏洞被热炒的时候总会有一种论调说这不是Redis的漏洞是使用方式的问题。这话有道理但从防御角度看只要还有大量裸奔实例存在Redis就始终是攻击者眼里性价比极高的目标。2. 一次RedTeam视角的复现记录从端口扫描到权限落地说再多理论不如完整走一遍复现流程。这里我以防御和检测为目的把攻击链还原出来——不是说教你怎么打而是让你知道攻击者到底会做什么、每一步留下什么痕迹。读到后面你会发现几乎所有步骤都有对应的日志和特征。2.1 情报收集确认目标是不是裸奔的Redis攻击者第一步不是上来就打而是做资产测绘。这里常用的就是nmap这类扫描工具探测目标IP的6379端口是否开放再通过服务指纹确认是不是Redis。nmap -p 6379 -sV --script redis-info 目标IP如果返回的信息里有redis_version、redis_mode:standalone这些字段目标基本可以被判定为Redis服务。还有一种更隐蔽的方式直接用redis-cli去连如果能连通并执行INFO那就是连认证都不需要直接裸奔。这个阶段的特征是网络层和端口层的探测——很多防守方压根不会关注这个环节的日志。2.2 未授权访问验证三种常见的直连探测方式拿到目标后攻击者一般会先用客户端直连验证权限。常见的验证方式有三种redis-cli -h 目标IP -p 6379直接连敲INFO看返回。用redis-cli执行CONFIG GET dir如果返回了路径说明当前用户有配置读取权限。用可视化客户端比如AnotherRedisDesktopManager这类工具连接测试反正一键直连特别直观。我在做应急响应的时候判断一个Redis是不是未授权基本也是用这三种方式来复验。这里值得多说一句执行INFO能拿到connected_clients、used_memory、role这些关键信息——如果role显示的不是master而是slave那就要高度警惕了很可能已经被攻击者挂到了他们的恶意主库上。2.3 主从复制利用加载恶意模块的过程还原主从复制利用的过程看起来并不复杂攻击者在自己服务器上起一个Redis实例作为恶意主库。在受害Redis上执行SLAVEOF 攻击者IP 攻击者端口让受害Redis变成从库。恶意主库通过主从同步机制把攻击者预先准备好的恶意.so文件同步到受害Redis的数据目录。在受害Redis上执行MODULE LOAD /路径/恶意模块.so加载模块。模块注册一个新命令比如system.exec攻击者直接调用这个命令执行系统命令。这里的核心逻辑在于主从同步不仅能同步RDB数据文件攻击者还可以让受害Redis把同步下来的文件保存成任意文件名包括二进制模块文件。同步完成后MODULE LOAD只是最后一脚。我复现这一步的时候通常用Docker搭两套Redis一套当攻击者的恶意主库一套当受害从库整个过程跑下来不到五分钟。但就是这个不到五分钟的操作能让攻击者稳稳拿到服务器的命令执行权限。2.4 利用后的痕迹这些特征能帮你发现攻击既然我们做防御就要知道这些操作会留下什么痕迹Redis日志里会出现SLAVEOF、MODULE LOAD、CONFIG SET dir这类命令记录如果开了loglevel notice或warning大部分会落在日志里。ROLE和INFO replication会显示role:slave而且master_host、master_port指向陌生IP。用MODULE LIST能看到当前加载的模块如果出现不认识的模块名基本可以实锤被入侵。数据目录下可能出现非RDB/AOF后缀的陌生文件比如exp.so、pwn.so之类。我每次做入侵检测培训都强调一点Redis不是只能存字符串它还可以被用来藏模块文件。所以检查的时候别只盯着key列表看还得看文件系统、看模块列表、看复制状态。3. 实战加固清单把Redis从漏洞重灾区拉回安全水位复现完攻击链接下来的重头戏是加固。很多文章喜欢把加固写成一条条命令贴出来就完事但我觉得更值钱的是搞清楚每一层防线到底挡的是攻击链的哪一步。下面按网络层、认证层、命令层、运行层四层来说。3.1 网络层bind、防火墙与最小暴露面绝大多数Redis沦陷案例第一步都是因为端口暴露到了不该暴露的地方。网络层加固是最便宜、效果最好的一步也是我建议你第一个去做的。在redis.conf里最关键的几项配置bind 127.0.0.1 ::1 protected-mode yes port 6379如果Redis只给本机应用用bind只留本机回环地址就行。如果有多台业务服务器需要访问就bind到内网网卡IP不要用0.0.0.0。同时配合云安全组或本地防火墙只放行来源业务IP的6379端口。注意一个细节protected-mode yes不是万能的它和bind联合使用才有意义。如果你bind了内网IP但没有防火墙规则内网里其他机器一样能访问。所以网络层的完整语义是监听地址限制访问来源 防火墙兜底限制来源IP。3.2 认证与权限从requirepass到ACL的演进早期Redis只有一个全局密码就是requirepass。后来从Redis 6.0开始引入了ACLAccess Control List可以给不同用户分配不同的权限和命令集。这是加固上一个很大的进步因为你再也不用担心一个人知道密码所有命令都能敲的问题。基础配置长这样requirepass 你的强密码_至少16位以上 # ACL配置示例Redis 6 user default off user application on Pssw0rd_Prod123 ~cache:* read write -flushall -flushdb -keys -shutdown -config这里我给了一个比较实用的ACL示例默认用户关掉单独建一个application用户给业务用只允许读写cache:*前缀的key并且把危险命令全部排除掉。这样即使密码泄露攻击者拿到一个受约束的账户能做的事情也极其有限。关于密码强度别再用redis123、123456这种了。我在复盘攻击事件时见过太多被字典秒破的案例——弱口令在公网环境里基本等于开门揖盗。3.3 危险命令治理禁用、重命名与指令白名单Redis里有一批命令在业务正常使用中根本用不到但对攻击者来说却非常关键。典型的几个CONFIG攻击者靠它改配置、开同步、调目录。EVAL/EVALSHALua脚本执行通道常被用来做数据破坏或信息探测。KEYS全库key枚举容易导致数据泄露和性能问题。FLUSHALL/FLUSHDB一键清空数据勒索和恶作剧的最爱。SHUTDOWN直接打停服务。SLAVEOF/REPLICAOF主从复制入口主从复制RCE的关键命令。处理方式有两种一种是直接禁用在redis.conf里加rename-command CONFIG rename-command SLAVEOF rename-command REPLICAOF rename-command EVAL rename-command EVALSHA rename-command FLUSHALL rename-command FLUSHDB rename-command SHUTDOWN rename-command KEYS 另一种是重命名成复杂名字让攻击者猜不到rename-command CONFIG 6f9a2c1b74d8e3f5a1c0重命名命令的风险是如果客户端代码里用了原生命令名重命名后会导致业务报错。所以这条要谨慎评估。禁用命令则更直接只要业务确认用不到就明文禁用。我的经验是先开审计日志跑一周看看业务实际调用了哪些命令再决定禁谁。不要为了安全把业务搞挂了那也是一种事故。3.4 运行环境容器隔离、低权限账号与监控告警最后一道防线是运行环境本身很多加固文章会漏掉这部分。首先是账号权限。不要用root跑Redis单独建一个系统用户然后把数据目录的权限锁死useradd -r -s /sbin/nologin redis chown -R redis:redis /var/lib/redis其次是容器隔离。用Docker跑Redis是一种比较推荐的部署方式哪怕被攻击者拿到Redis权限默认情况下也只是容器内的权限。当然要小心如果你用--privileged跑容器或者把宿主的根目录直接挂进去那隔离就等于破功了。然后是监控告警。起码要盯几个指标connected_clients有没有突然暴涨、INFO replication里的角色有没有从master变成slave、进程CPU占用有没有异常飙升。再配合命令审计日志出了问题能第一时间定位。很多公司是Redis被种了挖矿脚本、CPU100%才发现那就已经晚了一步了。4. 溯源与应急当生产Redis真的被打穿我如何定位和止损前面讲的是怎么防这一节说已经被打穿了怎么办。我做应急响应有一个原则先止损再取证最后才是修复。顺序错了很可能连证据都没保住。4.1 发现异常日志里那些不该出现的命令最典型的告警信号是从redis.log里看到陌生命令。比如这样一个日志片段M 12:43:01.598 * SLAVEOF 192.168.1.100:12345 M 12:43:02.114 * CONFIG SET dir /var/lib/redis M 12:43:02.335 * MODULE LOAD /var/lib/redis/exp.so这三条命令连在一起基本可以定性这是一次利用主从复制加载恶意模块的入侵。比这个更隐蔽的还有通过CONFIG GET *偷配置、批量读key做数据窃取、写入异常key作为后续反弹shell的标记。但要注意默认情况下Redis的日志级别是notice很多命令并不会记录。所以遇到疑似入侵第一件事就是把日志级别临时调高CONFIG SET loglevel debug不过这只是在临时补救真正的长期方案是开启审计日志或者在应用层做命令拦截。除了日志还有一个很实用的检测方法MONITOR命令可以实时打印所有执行过的命令。如果Redis已经被入侵、但攻击者的持久化连接还挂着敲一下MONITOR能看到他在干什么。不过MONITOR本身就消耗性能线上实例慎用应急时可以短暂开启。4.2 溯源链路从恶意模块回推攻击入口止损之前要先想清楚一件事攻击者是从哪进来的是未授权直连、弱口令爆破、还是走应用层打进来的方向错了后面很可能白忙活。我的溯源顺序一般是先看redis-cli能不能免密连上。如果能那就是未授权访问入口问题基本实锤。看redis.log里有没有来自陌生IP的连接记录和危险命令记录。日志里一般能看到Accepting client connection这样的连接记录。看MODULE LIST和文件系统里有没有陌生模块文件。模块文件的编译时间、文件名往往能提供线索。看系统层面连向6379端口的来源IP配合防火墙和云安全组日志交叉比对。这里有个容易被忽略的点攻击者不一定是从公网进来的也可能从内网横向移动过来的。如果这台Redis绑定的内网IP但日志里出现了内网其他机器的IP那问题可能不只是Redis本身而是内网别的主机已经失守了。这种情况要做的是全内网排查而不是只修Redis。4.3 止损步骤隔离、清敌、保留证据、恢复业务一次完整的Redis应急响应我习惯按这个顺序操作隔离先用防火墙或安全组把来源IP封了再把6379端口对外的访问临时切断。必要的时候直接把实例停机。这一步是为了阻止攻击者继续操作。保留证据把redis.log、redis.conf、数据目录下的可疑模块文件、进程快照都复制出来存到专门的地方。别在原始环境里直接删文件那会让取证变得很被动。清敌打开redis-cli把攻击者加载的恶意模块卸载掉恢复主从复制状态删除恶意写好的key和计划任务。命令大致是MODULE UNLOAD exp.so REPLICAOF NO ONE CONFIG SET dir /var/lib/redis CONFIG SET dbfilename dump.rdb注意卸载模块之前要确认模块名用MODULE LIST查看。有些恶意模块会注册多个命令卸载得干净一点。改密与加固立刻设置或更换requirepass启用ACL禁用危险命令修改bind和防火墙规则。一句话把前面加固清单里的内容全部做一遍。恢复业务确认没有遗留后门之后再重新开放端口恢复业务流量。别急着把Redis加回集群先在低流量状态下观察一段时间确认没有异常连接再放量。我在实际项目里遇到过一种情况攻击者不仅在Redis里加载了模块还在系统里写了一个定时任务每五分钟重新执行一次恶意脚本。也就是说只要你没有清理系统层面的后门Redis恢复之后很快会被二次入侵。所以应急响应千万别把视野局限在Redis本身系统级排查同样要做。crontab -l、/etc/ld.so.preload、SSH authorized_keys、启动项这些都要过一遍。5. 安全之外的延伸从漏洞看Redis日常使用中的隐雷Redis漏洞本身聊完了但我觉得有义务再说几句日常使用中容易被忽略的隐雷。它们严格来说不是漏洞但一旦炸了比漏洞还难受。5.1 缓存治理穿透、击穿、雪崩与漏洞的概念混淆Redis最常见的应用场景是缓存。缓存穿透、缓存击穿、缓存雪崩这三个术语很多人分不清但它们在运维眼里都是事故级别的存在。穿透请求的key在缓存里没有每次都打到数据库数据库扛不住。击穿一个热点key过期的一瞬间大量请求同时打到数据库。雪崩大量key同时过期或者Redis直接宕机流量全部打到数据库数据库跟着垮掉。这些虽然不是安全漏洞但处理不好造成的业务损失比一些漏洞还大。对应手段也很成熟穿透用布隆过滤器 空值缓存击穿用互斥锁 逻辑过期雪崩用随机过期时间 高可用集群。如果你把这些和漏洞话题混在一起讨论很容易分散精力——安全加固和缓存治理是两件事都要做但要分开做。5.2 分布式锁锁住的是资源不是安全另一个高频词是Redis分布式锁。网上关于分布式锁的文章汗牛充栋但大部分人没意识到分布式锁本身就是一把双刃剑。它解决的是并发资源互斥的问题不是安全问题。我见过很多团队拿Redis做分布式锁为了防止误删他人锁加了唯一标识为了防止持有锁的线程挂了没释放给锁加了过期时间。这套机制已经比较成熟了但有一个容易翻车的地方主从模式下如果主库宕机从库晋升为主库后锁的信息可能还没同步过去导致两个客户端同时拿到锁。正规的解法是RedLock算法或者干脆用ZooKeeper、etcd这类强一致性组件来做分布式锁。这已经超出Redis漏洞的范畴了但既然热词里出现了分布式锁我还是想提醒一句Redis适合做缓存做分布式锁要慎重尤其在主从和哨兵场景下它的安全边界并没有你想象的那么清晰。5.3 可视化工具与运维习惯最后一个环节的隐患最后聊一个容易被忽略的环节——可视化客户端。Redis Desktop Manager、AnotherRedisDesktopManager这类工具确实好用但如果你在办公电脑上装一个直接连生产Redis还开启了保存密码功能那风险就不只是Redis本身了而是整个办公网的安全边界。我见过不止一次开发同学拿RDM连着生产Redis顺手把连接配置导出到了本地文件后来这台笔记本中了木马Redis的用户名密码全部被翻出来攻击者拿着这些凭据直接进了生产库。所以运维习惯也是安全的一部分——生产环境的凭据要集中管理不要散落在个人终端上。写在最后的个人经验回到开头那个问题怎么判断自己的Redis中没中招其实没有一个万能答案因为攻击者的手法一直在变。但有一点是确定的如果你连我的Redis绑定了哪些IP、谁有权限访问、日志在哪里看、有没有告警这几个问题都答不上来那你大概率还处于裸奔状态。我个人的习惯是每季度做一次Redis安全自检敲一遍INFO看详情看一次MODULE LIST查一遍redis.log里的危险命令记录顺手改一次高权限密码。这套动作看着简单但确实帮我挡掉了不少风险。最后再分享一个小技巧新装Redis之后先把rename-command CONFIG 和rename-command SLAVEOF 配上业务需要再放开不需要就让它一直禁着——大多数业务根本没机会用到这些命令但它们往往是攻击者最爱用的入口。