Redis数据库遭恶意清空？根源分析与彻底加固指南

首先需要明确一个核心判断：Redis数据被反复清空，极大概率是FLUSHALL或FLUSHDB这类高危命令遭到了远程恶意执行。问题的根源通常不在于Redis数据库本身，而在于其配置不当——例如直接暴露在公网、使用了弱密码甚至空密码，或者服务器已被植入定时任务后门。当务之急，绝不仅仅是进行数据恢复，而是必须立即切断攻击入口，并彻底清除系统中可能已存在的后门程序。

Redis 被恶意清空，大概率是 FLUSHALL 或 FLUSHDB 被远程执行了

如果您发现数据呈现“每天定时消失”的规律，但某个特定Key（例如攻击者留下的ssh-rsa公钥）却始终存在，这恰恰排除了数据自动过期或内存淘汰机制导致的可能性。这种“选择性清空”现象，正是人为操作或恶意脚本反复执行清库命令留下的典型痕迹——那个被特意保留的Key，往往就是攻击者为维持持久化访问而预留的后门凭证。

因此，后续的所有安全加固动作必须聚焦于源头防御：

• 禁用危险命令：首当其冲是禁用FLUSHALL和FLUSHDB，它们是清空数据库的主力命令。此外，CONFIG、DEBUG、KEYS等可能带来安全风险或导致性能问题的命令也应考虑禁用或重命名。
• 收紧网络暴露：Redis默认监听地址为0.0.0.0:6379。这意味着，只要6379端口对外开放且未设置强密码，就等于将数据库直接暴露在黑产扫描器的“热门目标”列表中，极易遭受攻击。
• 警惕默认配置：在使用宝塔面板等便捷运维工具时，一个常见的失守原因就是安装后未及时修改默认安全配置——既未限制监听地址，也未设置强密码，甚至直接允许外网访问，留下了巨大的安全隐患。

在宝塔面板里禁用危险命令：直接修改 redis.conf 配置文件

在宝塔面板中修改Redis配置，最稳妥的路径是：进入【软件商店】→ 找到已安装的Redis实例 → 点击【设置】→ 选择【配置文件】选项卡。务必通过面板提供的界面进行修改，避免直接手动编辑启动脚本或改动系统级配置，以免造成服务无法启动等异常问题。

在打开的配置文件中，找到类似# rename-command FLUSHALL ""的注释行，取消注释并进行修改。核心的安全配置示例如下：

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command DEBUG ""
rename-command KEYS ""

这里需要特别注意：将配置值设为""（空字符串）表示彻底禁用该命令。如果出于某些特殊兼容性考虑，希望重命名而非完全禁用（例如改为FLUSHALL_BAK），则格式应为rename-command FLUSHALL FLUSHALL_BAK。不过，从安全加固的角度而言，对于非必要的高危命令，直接禁用通常是更彻底、更推荐的选择。

修改完成后，点击【保存】按钮，并进入【服务】管理页面重启Redis服务以使配置生效。如何验证禁用是否成功？通过redis-cli命令行工具连接数据库后，尝试执行FLUSHALL命令，如果返回(error) ERR unknown command `FLUSHALL`这样的错误信息，就说明防护已经成功生效。

强制 Redis 只监听内网：修改 bind 和 protected-mode 参数

仅仅禁用危险命令还不够，必须将Redis服务锁定在安全的网络环境中。宝塔面板的默认配置通常不会主动限制bind监听地址，而protected-mode（保护模式）也仅在配置了密码时才真正起作用。因此，以下几项配置必须协同设置，形成多层防御：

• 绑定内网地址：将bind 127.0.0.1修改为bind 127.0.0.1 172.16.0.0/12（如果您使用的是阿里云、腾讯云等云服务商的内网，其私有网段通常是172.16.x.x或10.x.x.x；如果不确定具体网段，为求稳妥可只保留127.0.0.1，仅允许本机访问）。
• 开启保护模式：确保protected-mode yes已开启（宝塔新版默认如此，但老版本可能为no，务必检查确认）。
• 设置强密码：通过requirepass your_strong_password指令设置一个高复杂度、高强度的密码，彻底告别123456、admin或空密码这种“形同虚设”的危险配置。
• 删除危险绑定：仔细检查配置文件中是否存在类似# bind 0.0.0.0这种允许任意IP连接的危险写法，务必将其删除或注释掉。

完成上述修改并重启Redis服务后，可以进行一个简单的连通性测试：在服务器本地执行redis-cli -h 127.0.0.1 -p 6379 ping，应能收到PONG响应；而尝试从外网使用telnet命令连接您的服务器公网IP的6379端口，连接应该超时或被直接拒绝，这证明网络层面的访问限制已生效。

检查定时任务和可疑进程：清理已存在的后门

在堵住配置漏洞的同时，必须彻底清理“战场”，确认服务器是否已被攻击者控制。攻击者得手后，为了维持持久化访问或持续进行破坏，常常会植入各种后门。典型手段包括通过crontab定时任务每小时或定期执行一次redis-cli FLUSHALL，或者利用wget、curl从远程服务器下载并运行恶意脚本。

因此，以下系统排查步骤不可或缺：

• 审查系统定时任务：执行crontab -l命令，并检查/etc/crontab及/etc/cron.d/等目录下的文件，仔细排查是否存在包含redis-cli、wget、curl、陌生域名或.sh脚本的可疑任务行。
• 排查可疑系统进程：运行ps aux | grep -E "(redis|wget|curl|sh)"，重点关注那些执行路径并非/usr/bin/redis-server的Redis相关进程，以及异常的下载或脚本执行进程。
• 检查系统登录日志：查看lastb | head -20了解近期失败的登录尝试，并通过grep "Failed password" /var/log/secure*搜索系统是否存在密码爆破记录，判断服务器是否曾遭受暴力破解攻击。
• 清除SSH后门公钥：如果在Redis中或系统里发现残留的ssh-rsa AAAAB3NzaC1yc2E...这类不明公钥，它很可能已被写入~/.ssh/authorized_keys文件中，务必立即手动将其删除，并考虑更换SSH密钥对。

这一步至关重要却常被忽略：即使已经按照上述步骤加固了Redis配置，如果系统中潜伏的定时任务后门未被清除，数据依然会每天准时“消失”。所以，正确的安全加固顺序必须是：先彻底清理后门，再实施配置加固，从而形成一个完整、有效的安全防护闭环，真正解决Redis被恶意清空的问题。