在平时参与内网安全评估和红队演练的时候我几乎每次都会碰到几台跑着 Redis 的服务器。标题里的“内网提权 | Redis 提权”本质上是安全圈里一条特别经典的攻击链条攻击者从网络侧拿到 Redis 的未授权访问或弱口令访问再利用 Redis 的配置能力和持久化能力把风险一步步放大成目标机器上的高权限 shell。这个套路火了很多年热度一直没降原因是它门槛低、见效快、还特别容易出现在真实的生产环境里。这篇文章我会从“为什么 Redis 会成为内网里最显眼的目标”讲起拆开这条链路的原理然后落地到具体的安全评估流程、加固清单和标准检测希望能给做运维、开发的同事以及蓝队和刚接触安全评估的朋友一些可以直接参考的整理思路。先把立场说清楚这篇文章的视角是授权安全测试和防御加固。所有分析都是为了让系统管理员和安全团队知道风险在哪里、怎么排查、怎么修而不是教人对真实业务系统动手。想拿这些技术做非法的事后果自行承担。1. 为什么 Redis 一直是内网里绕不开的提权目标1.1 部署量太大安全注意力又不够Redis 作为内存数据结构存储高性能、丰富的数据结构、分布式锁、缓存能力都很强几乎是现代应用架构里的标配。很多业务系统一到高峰期就把热点数据塞进 Redis或者在微服务架构里用它做消息订阅、计数器和排行榜。部署量一大安全边界就开始变得模糊。最常见的情况是开发环境为了方便直接bind 0.0.0.0忘记配密码或者运维把 Redis 单纯当成“缓存工具”没有意识到它也暴露在网络上。等到内网被人拿下一台机器顺手一扫描发现一批 Redis 开放着 6379 端口后续动作就很难收住了。1.2 Redis 提权到底是什么“提权”这里说的 Redis 提权和传统意义上“从低权限用户提成 root”还不完全一样。它更像是一个组合拳攻击者原本只有“未授权访问 Redis”的能力经过命令交互、配置修改、文件写入等一系列操作后拿到主机 shell 甚至 root 权限。整个过程里可能没有用到任何内核 CVE也没有破解系统密码而是把 Redis 本身的合法功能变成了“跳板”。这也是它容易被人低估的原因——很多人觉得 Redis 只是一个数据库怎么会和提权扯上关系。Redis 提权最核心的敏感点有三个可以执行CONFIG GET/SET一类的命令让它修改运行期配置。可以控制 Redis 的持久化行为把内存中的数据写到指定路径。Redis 进程本身的运行权限以及目标机器上其他目录的写权限直接决定了最终效果能走到多深。如果 Redis 以 root 身份运行那后果会更严重。因为这相当于攻击者已经拿到了一个“任意文件写入”的入口剩下的只是找位置的问题。1.3 为什么 Redis 的默认配置容易失控Redis 是个高可用、高性能的服务设计初衷是给受信任的内部系统用的所以早期版本默认没有鉴权机制。虽然后来加入了protected-mode但很多老教程和存量环境并没有跟上调整。常见的失控配置有监听地址是0.0.0.0等于向整个内网暴露。protected-mode被迫关闭或者因为配置文件写法不对导致保护没有生效。requirepass为空或密码强度极弱。用 root 用户启动 Redis或者通过 systemd 脚本不小心挂在了高权限用户下。这些问题单独看好像都“不影响业务”但叠加在一起就是一条非常顺畅的提权链路。2. 把思路拆开Redis 提权链路究竟在利用什么2.1 命令面哪些能力会被对手当武器Redis 的命令体系很丰富键值操作、服务器配置、数据持久化、复制、Lua 脚本、消息订阅等都有对应命令。在安全评估里我最关注的是下面几类能力因为它们直接影响文件系统和进程权限CONFIG SET可以让 Redis 在运行期改变配置比如dir和dbfilename。如果防御策略只做过启动时参数校验运行期改动就容易被忽略。SAVE/BGSAVE把内存数据落盘。攻击者可以通过控制写入内容的顺序和路径配合落盘机制制造出特殊文件。EVAL/EVALSHA执行 Lua 脚本。某些版本还会涉及加载动态库之类的更深层利用但前提通常也是先拿到命令执行权。DEBUG等调试命令在老版本里也出现过风险不过现在多数发行版把这类命令默认折叠了。这些能力的共同特点是它们本来是给开发者和运维用的便利功能。比如CONFIG SET dir本身没什么问题DBA 完全可能临时调整持久化目录来做数据迁移。但一旦这个东西落在未授权访问者手里它就成了攻击者控制文件写入位置和内容的关键工具。2.2 持久化机制为什么“写文件”会成为可能Redis 做缓存或数据库必须考虑持久化。RDB 快照是定期把内存数据按二进制格式落盘AOF 日志是追加式记录写操作。二者有一个共同点它们要把数据写到服务器本地文件系统上。RDB 文件虽然是二进制块但攻击者可以精心构造特定的键值内容让 RDB 里出现一段可以被目标程序“当作其他格式读入”的数据。举例说如果攻击者把一段 WebShell 代码作为键值写进 Redis再用CONFIG SET dir把落盘目录切换到 Web 站点根目录接着用CONFIG SET dbfilename把落盘文件名改成.php结尾最后执行SAVE那段代码就会被持久化成一个“看似正常的脚本文件”。如果 Web 服务的执行引擎恰好会解析该目录下的 PHP 文件那这台机器就等于多了一个后门入口。换个说法可能更好理解Redis 给了你控制“写入内容”的入口也给了你控制“写入位置”的入口而 Redis 里的键值可以是非结构化的文本那剩下的就是找到一处能被程序读取执行的位置。2.3 真正决定成败的是文件系统与权限错配很多人在复盘时会把锅都甩给 Redis其实只对了一半。真正决定攻击能否落地的是目标机器上的目录权限、服务权限和文件系统挂载方式。比如Redis 能写但 Web 根目录只读WebShell 路线就走不通。Redis 能以 root 写 cron 目录但如果 cron 服务禁止从/var/spool/cron/读新增任务或者目标环境不允许出网反弹 shell 就会失败。SSH 目录虽然有写权限但如果没有开启公钥登录或者StrictHostKeyChecking配置太严SSH 公钥路线也会失效。所以我们在做安全评估时几乎会把环境判断放在“能不能利用”之前。光知道有什么漏洞还远远不够关键是这个环境配不配合。3. 三条经典落地路径的条件、风险与对应加固接下来我把业界最常说的三条落地路径拆开。每一条我都会说清楚它需要什么条件、通常出现在什么场景、以及防御方应该怎么堵。3.1 WebShell 写入路径这条路径最出名也最直观。核心思路是把恶意内容写到 Web 服务能解析的目录让访问者请求该恶意文件即可执行。需要满足的条件大概是这些Redis 与 Web 程序在同一台服务器。Web 根目录对 Redis 运行用户有写权限。Web 服务能解析对应扩展名的脚本比如 PHP、JSP 等。攻击者能探测到 Web 根目录的具体路径比如/var/www/html、/usr/share/nginx/html。防御方最容易忽略的是“目录权限”。很多团队配 Web 服务时因为历史原因居然让运行 Web 的用户和运行 Redis 的用户同组或者干脆是同一个用户。这就等于人为打开了写目录的门。加固建议非常直接把 Redis、Nginx/Apache、Web 应用运行用户全部分开做到独立账号、独立目录、最小权限。3.2 Cron 计划任务路径这条路径在 Linux 环境里更“暴力”核心是往/var/spool/cron/或者/etc/cron.d/下写文件让系统按计划任务执行指令。它常见于内网不能直接访问 Web 服务的场景或者 Web 目录权限缩得很紧的场景。需要注意几个条件Redis 进程权限足够高至少能写入对应 cron 目录。管理员或服务用户能创建自己名下的 cron 文件。目标机器支持出网连接反弹 shell 才能真正建起来。如果只能在内网里横向那反弹地址也要写成内网中转机。我在评估中见过不少团队认为“只要把 Web 目录权限改了就安全”结果 Redis 还是以 root 在跑导致 cron 路径依然畅通。所以我会建议把 cron 目录的写权限也纳入重点监控定期检查/var/spool/cron/和/etc/cron.d/下面有没有新增的可疑文件。这个动作成本很低收益却很高。3.3 SSH 公钥写入路径第三条路径是往/root/.ssh/或其他用户的authorized_keys里写入攻击者自己的公钥然后直接用私钥远程登录。它最大的优势是稳定性高。只要 Redis 能写到.ssh目录SSH 又开了公钥登录攻击者就能在任意时间建立连接不需要等待 Web 请求或者 cron 周期。这个路径在加固空间上其实很明确严格限制 Redis 运行用户的文件系统写权限。对.ssh目录做木马扫描式监控一旦发现authorized_keys被修改立刻告警。生产服务器尽量关闭 root 远程登录改用普通用户加 sudo。3.4 为什么不同版本也会影响结果Redis 版本和漏洞利用的关系也值得提一嘴。老版本如 2.x、3.x 时代很多命令没有 ACL 限制而且默认保护更弱。新版本加了用户名密码体系、命令分类、路径限制等能力确实难打一些。但我说句公道话版本不是决定性因素。配置错误才是。即使 Redis 4.0 或 5.0只要配置留了口子上述三条路径照样能走通。4. 一次安全评估流程的真实视角4.1 从端口扫描到高危判定每次碰到内网 Redis我的排查顺序几乎都是固定的这套顺序在授权的安全评估中非常实用从扫描结果里选出开在 6379、6380、6381 等端口的机器。用redis-cli或等价客户端连上去先发PING、INFO server这类无害命令确认真的是 Redis。检查是否设置了requirepass是否开启了protected-mode。在安全前提下尝试CONFIG GET dir、CONFIG GET dbfilename观察自己能否读到服务运行信息。用ps查看 Redis 启动用户判断权限高度。在授权范围内确认关键目录的写权限比如 Web 目录、cron 目录、.ssh目录。如果条件满足就在临时环境或者严格控制步骤的前提下验证其中一条链路是否成立。验证结束后立刻清理现场还原被临时写入的任何文件并做好记录。把验证结果整理成整改清单交给对应业务团队。跟进修复情况确保配置变更真正生效。这里我想特别强调第 5 步和第 8 步因为很多人都在这两步上吃亏。权限判断如果不做你可能只知道“Redis 有风险”却不知道风险能大到什么程度。清理动作如果不做评估完毕后的服务器上留下来测试用的临时文件下次安全检查时反而成了新疑点这是评估规范的大忌。4.2 为什么验证链路要“点到即止”很多刚入行的朋友会问既然条件都满足了为什么不直接打出一条 shell 看看我的意见是在商业安全评估或者内部红队项目里验证链路最好“点到即止”。目的是证明风险存在而不是把生产服务器搞得一团糟。验证 WebShell 路径时可以在受控目录里写入一个无害的测试文件确认文件能生成、能被访问就行没必要真写一个后门进去。验证 cron 路径时可以临时写文件再立刻删除而不是真的等任务触发。这样做有两个实际好处一是避免对业务产生干扰二是把风险在评估阶段就留在“已证明、未破坏”的范围内。4.3 评估报告里最应该出现的结论复盘时我会把结论分为三层配置层有没有未授权访问、弱密码、绑定地址过宽。权限层Redis 进程是否高权限运行、文件系统目录权限是否错配。检测层是否有日志记录、告警规则能否发现异常写入。这三层写清楚之后业务团队才知道先改什么、后改什么。否则一份报告列 20 个问题运维看了头都大。5. 运维侧容易犯错的几个坑内网 Redis 出问题十有八九不是技术太深而是基础配置太松。下面这些坑我在实际环境里见过太多次了。5.1 用 root 直接跑 Redis最常见的坑就是 systemd 脚本里没指定Userredis或者干脆为了“省事”用redis-server手动起在 root 下。这样一旦 Redis 被写入相当于攻击者拿到了 root 级写入能力。几乎每次评估遇到高危 Redis背后都能翻到 root 运行的影子。正确做法是创建专门低权限用户比如redis并让 Redis 的数据目录、日志目录都归属这个用户。即使 Redis 被入侵写文件能力也局限在低权限范围内后续提权难度会大很多。5.2 protected-mode 被误关Redis 的protected-mode不是说开就绝对安全至少可以挡住一部分“随手扫描”的自动化攻击。但问题在于很多老教程为了让局域网内其他机器能连直接把protected-mode no写进配置却忘了配密码。这等于把门闩卸了还挂了个“欢迎光临”的牌子。防御建议很简单如果必须允许远程连接那就必须bind指定可信网段并设置强requirepass。两者缺一不可。5.3 防火墙策略放太宽有些环境虽然没有把 Redis 绑到0.0.0.0但防火墙规则写的是整段内网网段放行。内网一旦有一台机器被攻破攻击者很容易横向移动。更稳妥的方式是只允许应用服务器的特定网段访问 Redis其他网段一律拒绝。配合安全组或防火墙规则能显著收敛攻击面。5.4 容器和宿主机目录打通现在很多业务用 Docker 跑 Redis容器挂载宿主机目录这事本身很常见。但如果为了“方便”把整个宿主机根目录或者敏感目录挂了进去一旦 Redis 被写入攻击者等于获得了宿主机写文件的跳板。建议只挂载容器运行所需的最小目录并且把容器内用户的权限压到最低。5.5 Redis 日志没有被集中采集多数 Redis 部署日志是写到本机文件里的而且没有接日志平台。这意味着即使发生了异常连接、异常命令管理员也不会在第一时间看到。更严重的是攻击者如果执行了CONFIG SET等命令系统里可能只留下非常少的痕迹。建议把 Redis 日志、系统登录日志、Web 访问日志统一接入集中告警重点对“CONFIG SET”“全量写盘”“异常端口连接”等行为做规则匹配。6. 加固与检测对蓝队和运维最直接的建议6.1 落地八条加固清单结合上面的坑下面这份清单是我在给客户做加固建议时常用的你可以直接抄作业。绑定网卡把 Redis 的bind设成回环地址或具体业务网段不监听0.0.0.0。开启保护确保protected-mode yes生效并确认没有不一致的配置覆盖它。设置强密码为requirepass设置独立高强度密码不要用公开默认密码。独立用户运行创建专用低权限用户启动 Redis禁止 root 启动。命令收敛用 Redis ACL 或rename-command把CONFIG、EVAL等高风险命令改名或禁用。目录隔离Redis 的数据目录、日志目录单独划分降低与 Web 目录共享权限概率。最小挂载容器环境避免把宿主机敏感路径挂载进 Redis 容器。日志告警Redis 日志纳入集中管理关键命令与异常连接要触发告警。Redis 6 之后的 ACL 体系已经非常成熟我强烈建议使用。它可以把不同业务的连接分成只读用户、普通读写用户、管理用户而不是所有人都拿着全量命令权限。这样就算某个业务被攻击也未必能直接执行CONFIG SET。6.2 检测思路怎么发现有人正在搞事检测端最有效的三招我总结一下文件层监控对 Web 目录、cron 目录、.ssh目录做文件实时监控比如 Linux 下利用 inotify 系列能力或者直接用商业主机安全 Agent。一旦出现新增文件、修改文件立刻告警。网络层监控盯住 6379 端口的连接来源。正常业务连接的来源 IP 应该是固定的应用服务器如果出现大量来自未知来源的扫描连接或者异常登录连接立刻排查。命令层审计在 Redis 侧开启命令日志或者审计能力重点记录CONFIG、EVAL、SAVE、BGSAVE等敏感命令。配合告警可以第一时间发现“有人在试图写路径”。这些检测手段不需要很重的架构一台跳板机加简单的日志采集脚本就能先跑起来。关键是让“有人已经在碰 Redis”这件事不再无声无息。6.3 快速排查命令先把家底摸清如果你是运维不熟悉这块可以先跑下面几条命令把基本盘看清楚# 查看 Redis 监听地址 ss -antlp | grep 6379 # 查看 Redis 进程以什么用户运行 ps -eo user,group,comm,args | grep redis # 查看 Redis 当前配置 redis-cli -a 你的密码 CONFIG GET bind redis-cli -a 你的密码 CONFIG GET protected-mode redis-cli -a 你的密码 CONFIG GET requirepass # 查看 Redis 数据落盘目录 redis-cli -a 你的密码 CONFIG GET dir这几条命令本身是无害的只是让管理员确认当前状态。如果发现bind是0.0.0.0、requirepass为空、进程用户是 root那就别管版本多新先当成高危环境处理。6.4 对已经中招的机器怎么处理如果不幸发现 Redis 已经被人利用过流程应该是先隔离机器保留内存镜像和磁盘副本再查 cron、.ssh、Web 目录里有没有异常文件同时回看 Redis 日志和系统登录日志。清理时要做得彻底删掉恶意文件、重设所有密码、修改 Redis 配置并在至少一个完整业务周期里保持观察。这里我不建议直接“格式化重装”草草了事除非你确认该机器上没有任何需要复盘的分析价值。7. 常见问题与误区快查7.1 误区一protected-mode 开了就安全protected-mode主要挡的是“没有任何配置且没有访问控制时来自外部的盲目攻击”。如果管理员显式配置了bind并且为某些网段提供服务而又不小心留了弱密码它并不会阻止攻击者。保护模式只是第一道闸不是万能锁。7.2 误区二改个端口就能避免被扫把端口从 6379 改成别的只能降低被“常规扫描”命中的概率雷达照样能识别协议特征。而且很多自动化扫描工具会做全端口指纹识别改端口在真正有耐心的攻击者面前意义不大。核心还是配置和权限。7.3 误区三Redis 跑在容器里宿主机就安全只要容器挂载了宿主机目录或者容器以 privileged 模式运行边界就非常脆弱。容器隔离本质上是为了资源和进程隔离不等于安全边界。在评估中见到过不少系统Redis 在容器里跑但因为挂载问题依然能直接影响宿主机。7.4 误区四内网环境风险低这个说法现在越来越靠不住了。内网被突破的例子很多而且一旦对方进了内网Redis 这种高价值目标就会首当其冲。内网不等于安全区内网访问控制同样要部署。建议把内网 Redis 也当作公网服务来加固。7.5 问题Redis 日志里没有命令审计怎么办老版本 Redis 默认没有完整的命令审计这是客观事实。如果暂时不能升级可以靠系统层面的日志补充比如数据库的 slow log、系统的auditd、文件目录监控等。我在安全评估里最依赖的不是某一条日志而是多种日志之间的交叉验证。只要目录监控和网络连接监控做了即便 Redis 自身缺少审计也能及时发现异常。我个人在实际评估里最深的体会是Redis 提权并不需要多高深的技术也不需要多复杂的漏洞它更像一面镜子把环境里的权限错配、配置松懈和检测盲区全照出来。所以防御方与其天天追着新 CVE 跑不如先把 Redis 这类基础组件的底线守住。配置收敛权限隔离日志能看异常能告警做到这四件事大部分 Redis 提权风险就根本不成立。最后再分享一个评估项目中养成的小习惯每改动一次 Redis 配置我都会立刻用CONFIG GET或者redis-cli -a验证一遍并保存基线。很多安全问题不是“没配置”而是“配置了但没生效”这个细节在排查时尤其容易踩希望你能重视起来。
在平时参与内网安全评估和红队演练的时候我几乎每次都会碰到几台跑着 Redis 的服务器。标题里的“内网提权 | Redis 提权”本质上是安全圈里一条特别经典的攻击链条攻击者从网络侧拿到 Redis 的未授权访问或弱口令访问再利用 Redis 的配置能力和持久化能力把风险一步步放大成目标机器上的高权限 shell。这个套路火了很多年热度一直没降原因是它门槛低、见效快、还特别容易出现在真实的生产环境里。这篇文章我会从“为什么 Redis 会成为内网里最显眼的目标”讲起拆开这条链路的原理然后落地到具体的安全评估流程、加固清单和标准检测希望能给做运维、开发的同事以及蓝队和刚接触安全评估的朋友一些可以直接参考的整理思路。先把立场说清楚这篇文章的视角是授权安全测试和防御加固。所有分析都是为了让系统管理员和安全团队知道风险在哪里、怎么排查、怎么修而不是教人对真实业务系统动手。想拿这些技术做非法的事后果自行承担。1. 为什么 Redis 一直是内网里绕不开的提权目标1.1 部署量太大安全注意力又不够Redis 作为内存数据结构存储高性能、丰富的数据结构、分布式锁、缓存能力都很强几乎是现代应用架构里的标配。很多业务系统一到高峰期就把热点数据塞进 Redis或者在微服务架构里用它做消息订阅、计数器和排行榜。部署量一大安全边界就开始变得模糊。最常见的情况是开发环境为了方便直接bind 0.0.0.0忘记配密码或者运维把 Redis 单纯当成“缓存工具”没有意识到它也暴露在网络上。等到内网被人拿下一台机器顺手一扫描发现一批 Redis 开放着 6379 端口后续动作就很难收住了。1.2 Redis 提权到底是什么“提权”这里说的 Redis 提权和传统意义上“从低权限用户提成 root”还不完全一样。它更像是一个组合拳攻击者原本只有“未授权访问 Redis”的能力经过命令交互、配置修改、文件写入等一系列操作后拿到主机 shell 甚至 root 权限。整个过程里可能没有用到任何内核 CVE也没有破解系统密码而是把 Redis 本身的合法功能变成了“跳板”。这也是它容易被人低估的原因——很多人觉得 Redis 只是一个数据库怎么会和提权扯上关系。Redis 提权最核心的敏感点有三个可以执行CONFIG GET/SET一类的命令让它修改运行期配置。可以控制 Redis 的持久化行为把内存中的数据写到指定路径。Redis 进程本身的运行权限以及目标机器上其他目录的写权限直接决定了最终效果能走到多深。如果 Redis 以 root 身份运行那后果会更严重。因为这相当于攻击者已经拿到了一个“任意文件写入”的入口剩下的只是找位置的问题。1.3 为什么 Redis 的默认配置容易失控Redis 是个高可用、高性能的服务设计初衷是给受信任的内部系统用的所以早期版本默认没有鉴权机制。虽然后来加入了protected-mode但很多老教程和存量环境并没有跟上调整。常见的失控配置有监听地址是0.0.0.0等于向整个内网暴露。protected-mode被迫关闭或者因为配置文件写法不对导致保护没有生效。requirepass为空或密码强度极弱。用 root 用户启动 Redis或者通过 systemd 脚本不小心挂在了高权限用户下。这些问题单独看好像都“不影响业务”但叠加在一起就是一条非常顺畅的提权链路。2. 把思路拆开Redis 提权链路究竟在利用什么2.1 命令面哪些能力会被对手当武器Redis 的命令体系很丰富键值操作、服务器配置、数据持久化、复制、Lua 脚本、消息订阅等都有对应命令。在安全评估里我最关注的是下面几类能力因为它们直接影响文件系统和进程权限CONFIG SET可以让 Redis 在运行期改变配置比如dir和dbfilename。如果防御策略只做过启动时参数校验运行期改动就容易被忽略。SAVE/BGSAVE把内存数据落盘。攻击者可以通过控制写入内容的顺序和路径配合落盘机制制造出特殊文件。EVAL/EVALSHA执行 Lua 脚本。某些版本还会涉及加载动态库之类的更深层利用但前提通常也是先拿到命令执行权。DEBUG等调试命令在老版本里也出现过风险不过现在多数发行版把这类命令默认折叠了。这些能力的共同特点是它们本来是给开发者和运维用的便利功能。比如CONFIG SET dir本身没什么问题DBA 完全可能临时调整持久化目录来做数据迁移。但一旦这个东西落在未授权访问者手里它就成了攻击者控制文件写入位置和内容的关键工具。2.2 持久化机制为什么“写文件”会成为可能Redis 做缓存或数据库必须考虑持久化。RDB 快照是定期把内存数据按二进制格式落盘AOF 日志是追加式记录写操作。二者有一个共同点它们要把数据写到服务器本地文件系统上。RDB 文件虽然是二进制块但攻击者可以精心构造特定的键值内容让 RDB 里出现一段可以被目标程序“当作其他格式读入”的数据。举例说如果攻击者把一段 WebShell 代码作为键值写进 Redis再用CONFIG SET dir把落盘目录切换到 Web 站点根目录接着用CONFIG SET dbfilename把落盘文件名改成.php结尾最后执行SAVE那段代码就会被持久化成一个“看似正常的脚本文件”。如果 Web 服务的执行引擎恰好会解析该目录下的 PHP 文件那这台机器就等于多了一个后门入口。换个说法可能更好理解Redis 给了你控制“写入内容”的入口也给了你控制“写入位置”的入口而 Redis 里的键值可以是非结构化的文本那剩下的就是找到一处能被程序读取执行的位置。2.3 真正决定成败的是文件系统与权限错配很多人在复盘时会把锅都甩给 Redis其实只对了一半。真正决定攻击能否落地的是目标机器上的目录权限、服务权限和文件系统挂载方式。比如Redis 能写但 Web 根目录只读WebShell 路线就走不通。Redis 能以 root 写 cron 目录但如果 cron 服务禁止从/var/spool/cron/读新增任务或者目标环境不允许出网反弹 shell 就会失败。SSH 目录虽然有写权限但如果没有开启公钥登录或者StrictHostKeyChecking配置太严SSH 公钥路线也会失效。所以我们在做安全评估时几乎会把环境判断放在“能不能利用”之前。光知道有什么漏洞还远远不够关键是这个环境配不配合。3. 三条经典落地路径的条件、风险与对应加固接下来我把业界最常说的三条落地路径拆开。每一条我都会说清楚它需要什么条件、通常出现在什么场景、以及防御方应该怎么堵。3.1 WebShell 写入路径这条路径最出名也最直观。核心思路是把恶意内容写到 Web 服务能解析的目录让访问者请求该恶意文件即可执行。需要满足的条件大概是这些Redis 与 Web 程序在同一台服务器。Web 根目录对 Redis 运行用户有写权限。Web 服务能解析对应扩展名的脚本比如 PHP、JSP 等。攻击者能探测到 Web 根目录的具体路径比如/var/www/html、/usr/share/nginx/html。防御方最容易忽略的是“目录权限”。很多团队配 Web 服务时因为历史原因居然让运行 Web 的用户和运行 Redis 的用户同组或者干脆是同一个用户。这就等于人为打开了写目录的门。加固建议非常直接把 Redis、Nginx/Apache、Web 应用运行用户全部分开做到独立账号、独立目录、最小权限。3.2 Cron 计划任务路径这条路径在 Linux 环境里更“暴力”核心是往/var/spool/cron/或者/etc/cron.d/下写文件让系统按计划任务执行指令。它常见于内网不能直接访问 Web 服务的场景或者 Web 目录权限缩得很紧的场景。需要注意几个条件Redis 进程权限足够高至少能写入对应 cron 目录。管理员或服务用户能创建自己名下的 cron 文件。目标机器支持出网连接反弹 shell 才能真正建起来。如果只能在内网里横向那反弹地址也要写成内网中转机。我在评估中见过不少团队认为“只要把 Web 目录权限改了就安全”结果 Redis 还是以 root 在跑导致 cron 路径依然畅通。所以我会建议把 cron 目录的写权限也纳入重点监控定期检查/var/spool/cron/和/etc/cron.d/下面有没有新增的可疑文件。这个动作成本很低收益却很高。3.3 SSH 公钥写入路径第三条路径是往/root/.ssh/或其他用户的authorized_keys里写入攻击者自己的公钥然后直接用私钥远程登录。它最大的优势是稳定性高。只要 Redis 能写到.ssh目录SSH 又开了公钥登录攻击者就能在任意时间建立连接不需要等待 Web 请求或者 cron 周期。这个路径在加固空间上其实很明确严格限制 Redis 运行用户的文件系统写权限。对.ssh目录做木马扫描式监控一旦发现authorized_keys被修改立刻告警。生产服务器尽量关闭 root 远程登录改用普通用户加 sudo。3.4 为什么不同版本也会影响结果Redis 版本和漏洞利用的关系也值得提一嘴。老版本如 2.x、3.x 时代很多命令没有 ACL 限制而且默认保护更弱。新版本加了用户名密码体系、命令分类、路径限制等能力确实难打一些。但我说句公道话版本不是决定性因素。配置错误才是。即使 Redis 4.0 或 5.0只要配置留了口子上述三条路径照样能走通。4. 一次安全评估流程的真实视角4.1 从端口扫描到高危判定每次碰到内网 Redis我的排查顺序几乎都是固定的这套顺序在授权的安全评估中非常实用从扫描结果里选出开在 6379、6380、6381 等端口的机器。用redis-cli或等价客户端连上去先发PING、INFO server这类无害命令确认真的是 Redis。检查是否设置了requirepass是否开启了protected-mode。在安全前提下尝试CONFIG GET dir、CONFIG GET dbfilename观察自己能否读到服务运行信息。用ps查看 Redis 启动用户判断权限高度。在授权范围内确认关键目录的写权限比如 Web 目录、cron 目录、.ssh目录。如果条件满足就在临时环境或者严格控制步骤的前提下验证其中一条链路是否成立。验证结束后立刻清理现场还原被临时写入的任何文件并做好记录。把验证结果整理成整改清单交给对应业务团队。跟进修复情况确保配置变更真正生效。这里我想特别强调第 5 步和第 8 步因为很多人都在这两步上吃亏。权限判断如果不做你可能只知道“Redis 有风险”却不知道风险能大到什么程度。清理动作如果不做评估完毕后的服务器上留下来测试用的临时文件下次安全检查时反而成了新疑点这是评估规范的大忌。4.2 为什么验证链路要“点到即止”很多刚入行的朋友会问既然条件都满足了为什么不直接打出一条 shell 看看我的意见是在商业安全评估或者内部红队项目里验证链路最好“点到即止”。目的是证明风险存在而不是把生产服务器搞得一团糟。验证 WebShell 路径时可以在受控目录里写入一个无害的测试文件确认文件能生成、能被访问就行没必要真写一个后门进去。验证 cron 路径时可以临时写文件再立刻删除而不是真的等任务触发。这样做有两个实际好处一是避免对业务产生干扰二是把风险在评估阶段就留在“已证明、未破坏”的范围内。4.3 评估报告里最应该出现的结论复盘时我会把结论分为三层配置层有没有未授权访问、弱密码、绑定地址过宽。权限层Redis 进程是否高权限运行、文件系统目录权限是否错配。检测层是否有日志记录、告警规则能否发现异常写入。这三层写清楚之后业务团队才知道先改什么、后改什么。否则一份报告列 20 个问题运维看了头都大。5. 运维侧容易犯错的几个坑内网 Redis 出问题十有八九不是技术太深而是基础配置太松。下面这些坑我在实际环境里见过太多次了。5.1 用 root 直接跑 Redis最常见的坑就是 systemd 脚本里没指定Userredis或者干脆为了“省事”用redis-server手动起在 root 下。这样一旦 Redis 被写入相当于攻击者拿到了 root 级写入能力。几乎每次评估遇到高危 Redis背后都能翻到 root 运行的影子。正确做法是创建专门低权限用户比如redis并让 Redis 的数据目录、日志目录都归属这个用户。即使 Redis 被入侵写文件能力也局限在低权限范围内后续提权难度会大很多。5.2 protected-mode 被误关Redis 的protected-mode不是说开就绝对安全至少可以挡住一部分“随手扫描”的自动化攻击。但问题在于很多老教程为了让局域网内其他机器能连直接把protected-mode no写进配置却忘了配密码。这等于把门闩卸了还挂了个“欢迎光临”的牌子。防御建议很简单如果必须允许远程连接那就必须bind指定可信网段并设置强requirepass。两者缺一不可。5.3 防火墙策略放太宽有些环境虽然没有把 Redis 绑到0.0.0.0但防火墙规则写的是整段内网网段放行。内网一旦有一台机器被攻破攻击者很容易横向移动。更稳妥的方式是只允许应用服务器的特定网段访问 Redis其他网段一律拒绝。配合安全组或防火墙规则能显著收敛攻击面。5.4 容器和宿主机目录打通现在很多业务用 Docker 跑 Redis容器挂载宿主机目录这事本身很常见。但如果为了“方便”把整个宿主机根目录或者敏感目录挂了进去一旦 Redis 被写入攻击者等于获得了宿主机写文件的跳板。建议只挂载容器运行所需的最小目录并且把容器内用户的权限压到最低。5.5 Redis 日志没有被集中采集多数 Redis 部署日志是写到本机文件里的而且没有接日志平台。这意味着即使发生了异常连接、异常命令管理员也不会在第一时间看到。更严重的是攻击者如果执行了CONFIG SET等命令系统里可能只留下非常少的痕迹。建议把 Redis 日志、系统登录日志、Web 访问日志统一接入集中告警重点对“CONFIG SET”“全量写盘”“异常端口连接”等行为做规则匹配。6. 加固与检测对蓝队和运维最直接的建议6.1 落地八条加固清单结合上面的坑下面这份清单是我在给客户做加固建议时常用的你可以直接抄作业。绑定网卡把 Redis 的bind设成回环地址或具体业务网段不监听0.0.0.0。开启保护确保protected-mode yes生效并确认没有不一致的配置覆盖它。设置强密码为requirepass设置独立高强度密码不要用公开默认密码。独立用户运行创建专用低权限用户启动 Redis禁止 root 启动。命令收敛用 Redis ACL 或rename-command把CONFIG、EVAL等高风险命令改名或禁用。目录隔离Redis 的数据目录、日志目录单独划分降低与 Web 目录共享权限概率。最小挂载容器环境避免把宿主机敏感路径挂载进 Redis 容器。日志告警Redis 日志纳入集中管理关键命令与异常连接要触发告警。Redis 6 之后的 ACL 体系已经非常成熟我强烈建议使用。它可以把不同业务的连接分成只读用户、普通读写用户、管理用户而不是所有人都拿着全量命令权限。这样就算某个业务被攻击也未必能直接执行CONFIG SET。6.2 检测思路怎么发现有人正在搞事检测端最有效的三招我总结一下文件层监控对 Web 目录、cron 目录、.ssh目录做文件实时监控比如 Linux 下利用 inotify 系列能力或者直接用商业主机安全 Agent。一旦出现新增文件、修改文件立刻告警。网络层监控盯住 6379 端口的连接来源。正常业务连接的来源 IP 应该是固定的应用服务器如果出现大量来自未知来源的扫描连接或者异常登录连接立刻排查。命令层审计在 Redis 侧开启命令日志或者审计能力重点记录CONFIG、EVAL、SAVE、BGSAVE等敏感命令。配合告警可以第一时间发现“有人在试图写路径”。这些检测手段不需要很重的架构一台跳板机加简单的日志采集脚本就能先跑起来。关键是让“有人已经在碰 Redis”这件事不再无声无息。6.3 快速排查命令先把家底摸清如果你是运维不熟悉这块可以先跑下面几条命令把基本盘看清楚# 查看 Redis 监听地址 ss -antlp | grep 6379 # 查看 Redis 进程以什么用户运行 ps -eo user,group,comm,args | grep redis # 查看 Redis 当前配置 redis-cli -a 你的密码 CONFIG GET bind redis-cli -a 你的密码 CONFIG GET protected-mode redis-cli -a 你的密码 CONFIG GET requirepass # 查看 Redis 数据落盘目录 redis-cli -a 你的密码 CONFIG GET dir这几条命令本身是无害的只是让管理员确认当前状态。如果发现bind是0.0.0.0、requirepass为空、进程用户是 root那就别管版本多新先当成高危环境处理。6.4 对已经中招的机器怎么处理如果不幸发现 Redis 已经被人利用过流程应该是先隔离机器保留内存镜像和磁盘副本再查 cron、.ssh、Web 目录里有没有异常文件同时回看 Redis 日志和系统登录日志。清理时要做得彻底删掉恶意文件、重设所有密码、修改 Redis 配置并在至少一个完整业务周期里保持观察。这里我不建议直接“格式化重装”草草了事除非你确认该机器上没有任何需要复盘的分析价值。7. 常见问题与误区快查7.1 误区一protected-mode 开了就安全protected-mode主要挡的是“没有任何配置且没有访问控制时来自外部的盲目攻击”。如果管理员显式配置了bind并且为某些网段提供服务而又不小心留了弱密码它并不会阻止攻击者。保护模式只是第一道闸不是万能锁。7.2 误区二改个端口就能避免被扫把端口从 6379 改成别的只能降低被“常规扫描”命中的概率雷达照样能识别协议特征。而且很多自动化扫描工具会做全端口指纹识别改端口在真正有耐心的攻击者面前意义不大。核心还是配置和权限。7.3 误区三Redis 跑在容器里宿主机就安全只要容器挂载了宿主机目录或者容器以 privileged 模式运行边界就非常脆弱。容器隔离本质上是为了资源和进程隔离不等于安全边界。在评估中见到过不少系统Redis 在容器里跑但因为挂载问题依然能直接影响宿主机。7.4 误区四内网环境风险低这个说法现在越来越靠不住了。内网被突破的例子很多而且一旦对方进了内网Redis 这种高价值目标就会首当其冲。内网不等于安全区内网访问控制同样要部署。建议把内网 Redis 也当作公网服务来加固。7.5 问题Redis 日志里没有命令审计怎么办老版本 Redis 默认没有完整的命令审计这是客观事实。如果暂时不能升级可以靠系统层面的日志补充比如数据库的 slow log、系统的auditd、文件目录监控等。我在安全评估里最依赖的不是某一条日志而是多种日志之间的交叉验证。只要目录监控和网络连接监控做了即便 Redis 自身缺少审计也能及时发现异常。我个人在实际评估里最深的体会是Redis 提权并不需要多高深的技术也不需要多复杂的漏洞它更像一面镜子把环境里的权限错配、配置松懈和检测盲区全照出来。所以防御方与其天天追着新 CVE 跑不如先把 Redis 这类基础组件的底线守住。配置收敛权限隔离日志能看异常能告警做到这四件事大部分 Redis 提权风险就根本不成立。最后再分享一个评估项目中养成的小习惯每改动一次 Redis 配置我都会立刻用CONFIG GET或者redis-cli -a验证一遍并保存基线。很多安全问题不是“没配置”而是“配置了但没生效”这个细节在排查时尤其容易踩希望你能重视起来。
