Redis作为高频使用的内存数据库，默认提供的部分管理命令存在较高风险。如果攻击者拿到连接权限，或者开发人员误操作，就可能通过flushall、flushdb等命令直接清空数据，或用keys引发服务阻塞。rename-command是Redis原生支持的配置项，作用就是把指定命令重命名为其他名字，甚至彻底禁用，从而缩小攻击面并防止误用。
一、rename-command的基本工作机制
rename-command本质上是在Redis服务端对命令词进行映射替换。当客户端发送某个被重命名的原命令时，服务端已经不认识这个名字，会返回错误；只有使用配置里设定的新名字，才能执行对应逻辑。这种机制发生在命令解析的最前端，不依赖任何外部插件，因此兼容性和稳定性都比较好。
在redis.conf配置文件中，书写格式为rename-command 原命令名 新命令名。如果想彻底禁掉某命令，可以把新命令名设为空字符串，也就是两个引号之间没有任何内容。例如rename-command FLUSHALL ""就表示FLUSHALL被完全禁用，任何连接都无法调用。修改完成后必须重启Redis实例，运行中的实例不会动态加载这条变更。
二、常见需要重命名的危险命令
实际运维中，最该处理的是具备数据破坏能力或性能风险的命令。flushall会清空所有库的数据，flushdb清空当前库，keys在大数据量下会阻塞主线程，config可修改实例配置，debug可能让服务崩溃。这些命令平时业务代码基本用不到，却常成为入侵者的首选工具。
下面列出典型命令及推荐处理方式：
| 原命令 | 风险说明 | 推荐配置 |
|---|---|---|
| FLUSHALL | 清空全部数据库 | 重命名为随机串或禁用 |
| FLUSHDB | 清空当前数据库 | 重命名为随机串或禁用 |
| KEYS | 全量遍历导致阻塞 | 重命名为复杂字符串 |
| CONFIG | 可改配置暴露敏感信息 | 重命名为随机串 |
三、配置实例与操作步骤
假设我们要禁用flushall和flushdb，并把keys改为k__safe__list。打开redis.conf，在文件末尾追加以下内容：rename-command FLUSHALL ""、rename-command FLUSHDB ""、rename-command KEYS k__safe__list。注意新名字尽量无规律，不要使用公司名加日期这类易猜组合，否则防护效果会大打折扣。
保存后通过redis-cli shutdown nosave停止服务，再正常启动。启动后用redis-cli连接，执行flushall会提示错误，执行keys *也会报错，只有执行k__safe__list *才能列出键。若业务中有后台任务依赖原命令，要同步修改调用代码或脚本，否则会出现命令不存在的异常。
四、容易忽略的关联影响
很多团队改完配置才发现监控系统的探活脚本用了info或config命令，如果把这些也重命名，监控就会失效。因此操作前应当排查所有运维工具、巡检脚本、SDK封装层，确认它们使用的命令清单。对于确实要保留给内部使用的危险命令，可以只重命名而不禁用，并把新名字仅存放在受控的运维文档中。
另外，Redis集群模式下的从节点通常继承主节点配置，但某些自动化部署平台会在初始化时覆盖redis.conf，导致改名规则丢失。建议在配置管理系统中把rename-command段标记为不可覆盖，或在启动后通过巡检任务校验命令是否已被重命名，及时发现配置漂移。
五、与其他安全手段的配合
rename-command只是纵深防御中的一环，不能替代网络隔离和密码认证。即便命令被改名，若Redis端口直接暴露公网且无密码，攻击者也容易通过扫描或社工拿到新命令名。正确做法是绑定内网网卡、设置requirepass强密码、启用ACL账户体系，再把高危命令重命名，多层限制共同降低风险。
从经验看，小型业务常因图省事跳过这步，直到发生误删才补配置。大型系统则习惯在基线模板里内置rename-command规则，新实例上线即生效。无论规模大小，把危险命令关进笼子都是低成本高回报的必做项。
Redis安全rename-command命令重命名修改时间：2026-08-10 23:39:33