记一次Redis被攻击的事件，Redis攻击事件
最近几个月非常忙，所以很少有时间写博客，这几天终于闲了一些，于是就在整理平时的一些笔记。恰好这几天Redis服务器发生了问题，就记录一下。
我司有两款分别是2B和2C的App，类似于阿里旺旺的卖家版和买家版，里面有一个聊天的功能模块。双方可以通过这个功能聊天。内部通讯使用了环信，只是将本地账号和环信账号进行了关联。其他的信息，比如用户基本信息，好友关系，群组关系等存在Redis中，为防止Redis出现问题导致数据丢失（尽管配置了持久化），同时使用消息队列将数据写入SQLServer中进行了冗余。这是一种Redis的典型使用场景，从速度和效率上满足要求。
线上环境一直运行正常，但是在上周日（一个本该休息的日子），领导打电话过来说线上环境的用户登录不了，无法聊天，没有群相关信息。我想估计是Redis出现了问题，让领导不要着急，先让运维看看服务是否还在运行，不行的话，把Redis重启一下，因为之前设置过持久化，数据应该不会丢失。于是继续陪夫人吃饭，看电影。
到了晚上，还是打电话过来说有问题，没办法只有来公司一趟。打开机器用RedisClient连Linux环境上的Redis，发现里面的数据全没了，只有几个新注册的孤零零的用户在里面，我当时惊呆了，以为是运维那边没搞好，是重启的整个服务器而不是重启的Redis，可能是Redis没有及时保存把数据给弄丢了。看到现象之后跟领导电话告知目前的现象和建议的解决方案，在授权下，重新把用户相关数据从SQLServer同步到了Redis中，关键的数据还好没丢失，然后让测试简单测试了一下，一切正常就没有太在意。而且由于Redis是安装在Linux上的，是由运维同事维护的，出问题了我这边也查不了，于是就回去了。
但是事情远没有那么简单，星期一的时候，领导又打电话过来说聊天又不能用了，比较急说要赶紧处理，我说好，于是不紧不慢的收拾好出门去公司。心里非常不爽，前段时间加班太猛，周一周二全公司开发都调休放假的。就我一个开发的来到公司，打开远程又发现Redis里面的数据全没了。于是又从SQLServer把数据同步到了Redis里，然后检查代码，把除了和聊天相关之外的其他逻辑，比如Redis定时同步服务相关的可能会影响到的地方都暂停了。因为前段时间做了一次重构，担心是代码导致数据丢失，搞完了之后就回去了。
然而好景不长，消停了一天没出问题。今天早上过来上班，领导走过来语重心长的说，聊天又登不上了，上去一看，Redis里面的数据又没了。正好运维的同事也在，也就一起找下存在的漏洞和可能的原因。
原因
前几天无意在微博上看到了乌云平台发的一条漏洞信息：
public static bool DeleteGroup(string groupId)
{
lock (lockDeleteGroup)
{
bool result = true;
using (RedisHelper redis = new RedisHelper(HOST, PORT))
{
var group = redis.GetWhereObj<GroupTable>(GROUPTABLE, x => x.GroupId == groupId);
group.Is_Deleted = true;
result = redis.Update<GroupTable>(GROUPTABLE, x => x.GroupId == groupId, group);
}
return result;
}
}
后面为了安全考虑，需要给Redis设置个密码，于是下载了最新版本的4.0的ServiceStack.Redis，这个是商业化版本的，使用中发现，是有限制的，在其下载页面最下角也有说明：
private static ConnectionMultiplexer _redis;
private static IDatabase _db;
private static IServer _server;
private static bool needSave = false;
private void Init(string host, int port, string pwd, int database)
{
var options = ConfigurationOptions.Parse(host + ":" + port);
options.SyncTimeout = int.MaxValue;
options.AllowAdmin = true;
if (!string.IsNullOrEmpty(pwd))
{
options.Password = pwd;
}
if (_redis == null)
_redis = ConnectionMultiplexer.Connect(options);
if (_server == null)
_server = _redis.GetServer(host + ":" + port);
if (_db == null)
_db = _redis.GetDatabase(database);
needSave = false;
}
这里面，可以直接对options对象设置Password属性。于是对该对象进行了包装，后面使用Redis可以这样，在构造函数里边传入PWD即可，比如下面判断用户是否存在的接口：
public static bool HasShopUser(string userName) { bool hasUser = false; ShopUserEntity userEntity; userEntity = null; using (RedisHelper redis = new RedisHelper(HOST, PORT, PWD)) { userEntity = redis.GetShopUserInfo(userName); } if (userEntity != null) { hasUser = true; } return hasUser; }
在替换Redis客户端访问类的时候，顺便对之前Redis里面的数据结构进行了一次重构，经过这次重构，速度提升很明显。于是，于是就直接弄到正式环境然后就把设置密码这个事情给忘记了。
当然，部署有Redis的Linux服务器也按照漏洞建议做了登陆限制和修复。
总结
其实这是一个很低级的错误，访问Redis没有设置密码（当然也可能是Redis所在的Linux服务器本身没有对登录做限制），也感谢有乌云这么好的一个平台，能够及时发现系统的问题和漏洞，避免出现更大的损失。作为一个码农其实不应该抱有这样的侥幸心理，就像墨菲定律说的那样“会出错的，终将会出错“ 。最后，希望这篇文章能给大家一个提醒和一些帮助。