Redis

Redis 比较常见的是作为读缓存。读取数据的时候检查 Redis 是否存在，存在的话缓存命中，不需要访问后端存储。没命中的话从后端存储中获得，并同时存入 Redis。写数据的时候直接写入后端存储，清除 Redis 中对应的缓存或者更新成新的值。这种模型可以安全的随时删除缓存中的内容而不会造成数据丢失，因为最新的数据一定是写入到后端存储里了。 但如果系统的瓶颈出现在了写入这块，上面的模型就没法解决了。稍加修改可以得到写缓存的模型： 读的时候检查 Redis，如果 Redis 存在直接使用 Redis 中的数据，否则从后端存储中读取。 写的时候只写入 Redis，通过消息队列通知后台任务把 Reids 中缓存的内容保存到后端存储中。 后台任务监听消息队列，在把缓存内容保存成功之后从 Redis 中删除对应的内容。 任务队列可以使用 Redis 的 LIST 来实现，官方的 RPOPLPUSH – Redis 命令文档中已经很详细描述了如何实现一个可靠的消息队列。于是剩下的问题就是如何能保证安全的删除已经保存过的缓存？…

最近看到一篇文章详细说明了如何通过 Redis 获得 SSH 登录权限。简单来说就是如果 Redis 开放了外网端口访问，又没配置防火墙，也没有配置任何 Redis 的连接验证，而且还是用很高权限的用户在运行 Redis，就可以通过 dump 数据库把任意 key 注入到 authorized_keys 文件中，从而获得用户的 SSH 登录权限。条件很苛刻，但是很容易自动化，估计还是可以扫描到不少肉鸡的。 比较惭愧，最近部署的一台服务器就被该方法攻击了。主要原因是之前我已经书面说明了防火墙如何配置，所以想当然的认为拿到的机器已经配置好了。为了让 Redis 在内网内能访问，配置脚本中将监听的地址改成了 0.0.0.0，也没有配置连接验证，结果就是任何人都能连接上这个数据库。不过因为还是用的单独的 redis 用户运行，权限有限，攻击者并没有拿到 SSH 登录权限，只是把数据库清空了。所幸是测试服务器，数据库中的数据并不重要。 下面说明下我所了解的保护服务器安全的一些常识。