redis版本为：7.2.4

背景

昨天刚完成Redis主从部署，今天通过redis客户端工具连接，发现redis被注入了一个不明key，如下图：

key为x，value看着像ssh公钥，第一反应是redis服务被攻击了（该redis服务部署在自己的服务器上，仅用于实践主从部署，且使用docker部署，应该不会影响宿主机，所以并没有很慌），马上连接服务器进行排查。

事件分析

通过ssh连接服务器发现正常连接上了，这里基本能判断宿主机未受影响。

由于redis使用docker部署，通过以下命令查询redis日志：

docker logs <container-id>

发现以下信息：

几个核心的信息简单说明一下：

1. redis已经检测到了可能的安全攻击，并主动中止攻击连接（这里攻击失败了）。
2. redis被转换为slave连接到攻击者主节点（攻击成功）。

总结一下就是我的redis master节点变成了攻击者的slave节点，由于slave节点会自动同步master节点信息，因此，攻击者可以通过在master节点上新增key实施攻击。

漏洞复现

以下内容来自Kimi（作为参考，未经验证）

1. 环境准备：攻击者需要准备一个攻击机和目标靶机。攻击机用于执行攻击，而靶机则是受害者的服务器，其中运行着 Redis 服务。

2. 写入公钥：攻击者在自己的攻击机上生成 SSH 密钥对，然后将公钥写入到 Redis 服务器的某个 key 中。例如，攻击者可以使用 redis-cli 工具将公钥写入到名为 xxx 的 key 中：

复制
cat /root/.ssh/id_rsa.pub | redis-cli -h 192.168.0.111 -x set xxx

这里 192.168.0.111 是靶机的 IP 地址，id_rsa.pub 是攻击者生成的公钥文件。

1. 配置 Redis：攻击者需要通过 Redis 客户端设置一些配置，以便将缓存中的数据保存到靶机的 /root/.ssh 目录下，并命名为 authorized_keys：

./redis-cli -h 192.168.0.111 config set dir /root/.ssh
./redis-cli -h 192.168.0.111 config set dbfilename authorized_keys
./redis-cli -h 192.168.0.111 save

这些操作会将 xxx key 中的数据（即公钥）保存到 /root/.ssh/authorized_keys 文件中。

1. SSH 登录：一旦公钥被写入到 authorized_keys 文件中，攻击者就可以使用对应的私钥通过 SSH 登录到靶机：

ssh -i /path/to/private_key root@192.168.0.111

这里 /path/to/private_key 是攻击者生成的私钥文件的路径。

以下内容来自ChatGPT（作为参考，未经验证）

了解攻击者可能如何将Redis主节点转变为从属节点有助于增强对潜在安全威胁的认识。这种攻击可能通过以下方式实现：

1. 未经授权的访问：

• 攻击者可能已经获得了对Redis主节点的未经授权访问权限。这可能是由于Redis服务器未设置密码，或密码过于简单，或者由于系统其他方面的漏洞，例如操作系统或网络安全漏洞，使得攻击者能够远程访问Redis主节点。

1. 利用Redis命令：

• 攻击者通过Redis的客户端工具（如redis-cli）连接到Redis主节点，并执行一系列的Redis命令来改变主节点的角色为从属节点。常见的命令可能包括：

  phpCopy code
  SLAVEOF <masterip> <masterport>
  
  

这个命令将主节点的角色更改为从属节点，并指定另一个节点作为主节点。通过这种方式，攻击者将自己的Redis节点设置为主节点的从属节点。

1. 重新启动Redis服务：

• 攻击者可能还会尝试重新启动Redis服务，以确保新的配置生效。一旦Redis重新启动，它将按照新的配置连接到指定的主节点，并开始接收来自主节点的复制数据。

1. 隐藏攻击行为：

• 为了掩盖他们的攻击行为，攻击者可能会删除或修改Redis的日志记录，以避免管理员察觉到异常。

通过这些步骤，攻击者可以将Redis主节点转变为从属节点，并获取对Redis数据的访问权限，这样他们就可以在从属节点上执行读取操作，甚至可能对数据进行更改。

请注意，这仅仅是一种可能的攻击方法，具体的攻击方式可能会因系统配置和漏洞情况而异。加强系统的安全性，包括设置密码保护、限制远程访问、定期审查系统配置和日志、以及及时应用安全更新等措施，是防范此类攻击的关键。

更多漏洞及复现步骤见Redis 常见漏洞利用方法总结

善后

由于redis服务部署后便没有维护，查日志才发现已经不是第一次被攻击了，有必要加强安全防护意识了。

为了防止此类攻击，可以采取以下安全措施：

1. 设置密码认证：为 Redis 服务设置一个强密码，确保只有授权的用户可以访问。
2. 绑定到内网 IP：不要将 Redis 服务绑定到公网 IP 或 0.0.0.0，而是应该只绑定到内网 IP 或使用 localhost。
3. 开启保护模式：Redis 4.x 版本引入了 protected-mode 配置项，开启此模式可以限制对 Redis 服务的访问。
4. 更改默认端口：更改 Redis 的默认端口，避免使用众所周知的端口，如 6379。
5. 使用 ACL：Redis 6.x 版本引入了 ACL（访问控制列表）功能，可以用来精细控制用户的权限。
6. 定期更新和打补丁：保持 Redis 服务的更新，及时应用安全补丁来修复已知的漏洞。
7. 监控和日志记录：开启 Redis 的日志记录功能，监控异常访问和操作，及时发现并响应安全事件。

通过上述措施，可以大大降低 Redis 服务遭受未授权访问和注入 SSH 密钥的风险。

由于我这边redis主要为了学习使用，为方便使用，仅实施了以下措施，各位可根据自己的需要实施以上措施

设置密码认证

修改redis.conf中requirepass配置项为强密码，如：

requirepass eZi@c#f2H@*oAwJ7wf5.

更改默认端口

修改redis.conf中port配置项，如：

port 27379

开启保护模式

默认已开启

protected-mode yes