数千台MySQL数据库遭黑客比特币勒索，该怎么破？

据内部数据中心安全的行业领导者GuardiCore公司爆料，数千台MySQL数据库遭到勒索。这是近半年内，不断频发的数据库勒索事件的延续：

• 国内Oracle数据库遭“恶作剧”比特币勒索；

• 2017年1月11日报道3.3万台Mongo数据库实例被勒索，有些数据库直接被删除，国内受害者众多；

• 2017年1月13日报道3.5万个ElasticSearch CCluster被勒索，被删除数据大小至少450TB；

• 2017年1月19日报道1万+台Hadoop和CouchDB被勒索；

• 2017年2月24日报道数千台MySQL数据库被勒索。

根据GuardiCore研究人员，针对MySQL的一系列攻击最早可以追溯到2月12日。所有的追踪都归因到一个IP地址，属于荷兰的网站托管公司Worldstream（109.236.88.20）。

攻击者们通过一些黑客工具在网上搜索那些安全措施做得比较差的数据库服务器，暴力破解，然后删除数据、或者腾挪掉数据，并创建一个PLEASE_READ用户和WARNING表，在表里放上一小段信息。

信息大概是这个样子，你可以检查下你的数据库或者日志中是否含有下面这样的信息。

然后他们要数据库所有者支付0.2个比特币（价值200美元），这样数据库所有者就能访问数据了。上述所有勒索事件，虽然不是同一拨人发起，但基本都是这么个套路。

下面这个网站是接受付款的网站，竟然已经做到了如此高调。

安全研究人员Victor Gevers呼吁，不要支付，千万不要支付，因为那些数据很可能黑客压根就没有给你备份。

为什么会遭遇比特币勒索？一方面被攻击者安全意识薄弱，没有做好必要的安全防范，有的甚至基本就是裸奔。不要笑，早些年，很多大医院的Oracle数据库，用system/oracle是可以直接登录的。另一方面，利用了产品的漏洞，大家所熟知的SQL注入就是其中一种。虽然目前比特币勒索案例的数据库，都是疏于安全意识给了黑客可乘之机，但接二连三连环得手，也从另一个侧面说明数据库安全教育任重而道远。

安利一下，邹德裕同学主导研发的DPM已经可以检测Oracle和MySQL的比特币漏洞了。当然，安全攻防永远在不断升级，牛掰的产品厉害也在于不断迭代升级。

针对MySQL这个问题，我们从密码策略设置方面入手，来总结下数据库安全的一些细则。

1、 其实在我们日常工作中，如果使用了明文密码，MySQL也会给出提示，而且在早期版本是可以直接查mysql.user得到加密后的密码的。

Warning: Using apassword on the command line interface can be insecure

如果在批量任务中，这个其实还是会有很多牵制，不能对每一台服务器都设定不同的密码，这个也不大现实，这就有几种策略可以选择：一种是只限定本地可以无密码登录，这个使用相对普遍一些，另外一种就是修改源码，腾讯这些大厂是在源码层将这个warning关闭。第三种就是对于应用的控制也尤其重要，那就是通过域名解析的方式，MySQL中的用户是由user@host两部分共同组成，如下图所示，这个和Oracle等数据库会有鲜明的差别，如果为了省事就设置host为%就是一个潜在的隐患。

2、在MySQL 5.7开始会在初始化后随即生成一个初始密码，可以在初始化日志中查找。内容类似下面的形式：

error.log:2017-02-15T15:47:15.132874+08:001 [Note] A temporary password is generated for root@localhost: Y9srj<>

3、在mysql.user中默认值为mysql_native_password，不再支持mysql_old_password。

>select distinct plugin from mysql.user;

+-----------------------+

|plugin                |

+-----------------------+

|mysql_native_password |

+-----------------------+

4、如果查看MySQL密码相关的参数，就会发现存在一个参数

default_password_lifetime，默认参数值为0，可以设置这个参数来控制密码的过期时间。生产系统中可以根据实际情况来进行设定。

5、还有一点对于很多DBA来说需要习惯，那就是MySQL 5.7中只会创建一个root账号，就自动生成临时密码的用户，不再创建其他的账号，之前的版本中会默认生成的test库也不会自动生成了，这个改进虽然很细微，但却能够杜绝心怀侥幸的一些人。

6、而在此基础上如果需要更高一级的安全策略，MySQL 5.7版本提供了更为简单SSL安全访问配置，并且默认连接就采用SSL的加密方式。如果用户的数据传输不是通过SSL的方式，那么其在网络中就是以明文的方式进行传输，这在一定程度上会给别有用心的人带来可乘之机。

而如果使用无密码的模式来登录，也通过mysql_config_editor来配置，在MySQL 5.6已经发布该特性。

mysql_config_editor的命令提示如下，可以看出可使用的选项还是相对比较简单的。

我们直接可以通过一个命令来完成配置，制定这个无密码登录的别名为fastlogin

[mysql@oel1 ~]$ mysql_config_editor set--login-path=fastlogin --user=root --host=localhost --password--socket=/u02/mysql/mysqld_mst.sock
Enter password: 

配置完成之后，会在当前路径下生成一个隐藏文件.mylogin.cnf

而在密码问题之外，还有哪些方面需要注意呢，这也就是我们数据库安全的一些基本法则。

借用Oracle数据库安全面面观文章里的一个图，总结相对全面很多了。

我在这个基础上简单做一些说明和补充。

1. 检查数据库中的默认用户，哪些是近期额外多出来的，做到心中有数。网络层面，系统层面做一些基本的限制，比如防火墙权限控制，这个基本能够杜绝哪些裸奔下的潜在问题。

2. 控制用户的权限，不管是哪类数据库，哪怕操作规范多细致，滴水不漏，权限上做不到管控，问题的源头就是问题的无底洞。

3. 日志信息的管理和监控。日志可以理解是系统的第三只眼睛，如果存在疑问，日志是相对客观的。

4. 敏感信息要加密，例如：姓名、电话、身份证号码、银行账号、用户密码等，包括：敏感数据的屏蔽、数据脱敏、数据加密三个方面。

5. 漏洞处理，系统，网络，数据库的漏洞总是会有，这个就需要补充完善了。

而纵观我们常见的一些黑客事件，其实很多都不是软件本身支持得不够好，而是某些方面用户太放得开或者监管不力。

比如从去年的PLSQL Dev的黑客赎金事件，导致一些用户的Oracle数据库会莫名抛出错误，提示支付比特币来修复，潜伏期有多长，1200多天，一个数据库能够经历3年以上已然是一个相对成熟的系统了。而事情的原因则和有些同学使用了盗版的PLSQL Dev(即绿色版)有关，你说这个锅是否由Allround Automations公司来背？

其他数据库暂时还没有现成的一套工具防范，我们逐个把必要的建议罗列一下。

对于MongoDB的比特币安全防范，没有工具，云栖社区给出了安全Checklist：

• 开启鉴权功能：基于用户名和密码完成。

• 基于角色的访问控制：除root角色之外，还有很多预先定义的内建角色，如只读数据库角色等。

• 内部鉴权：内部鉴权的用户名是__system，鉴权数据库是local数据库。

• Sharding集群的鉴权：Sharding集群的鉴权和副本集鉴权有一定的区别：副本集在Mongod上鉴权，Sharding集群在Mongos上进行鉴权。

当然，开启鉴权势必会带来性能的开销，这是因为鉴权通常需要客户端和服务端进行一些网络交互以及CPU计算。但是与安全相比，这点开销还是应该消耗的。

对于Hadoop，相对而言要简单得多，一个是启用Kerberos，一个是关闭不必要的端口。

对于ElasticSearch的安全防范，白帽汇给出了这样一些建议：

1. 增加验证，官方推荐并且经过认证的是shield插件。网络中也有免费的插件，可以使用elasticsearch-http-basic，searchguard插件。

2. 使用Nginx搭建反向代理，通过配置Nginx实现对Elasticsearch的认证。

3. 如果是单台部署的Elasticsearch，9200端口不要对外开放。

4. 使用1.7.1以上的版本。在1.7.1以上版本目前还没有爆出过相关漏洞。

5. 另外Elasticsearch的官方也有其他产品与Elasticsearch配合紧密的，这些产品也存在漏洞，企业如果有使用其他相关产品存在漏洞也要进行修复，如Logstash，Kibana。

6. 加强服务器安全，安装防病毒软件，使用防火墙，网站安装WAF.并对数据库、系统、后台使用的服务设置复杂的密码，建议设置16位的大小写字母+特殊字符+数字组合。

对于CouchDB的安全防范，白帽汇的建议是：

1. 为CouchDB设置复杂密码（字符串，数字，特殊字符），并且长度超过16位。

2. 修改默认的用户名，CouchDB默认用户名为admin，请对其进行修改。

3. 做好网络隔离。不开启外网访问。

当然还有Redis，在最新一期的DBAplus Newsletter中，张冬洪老师提供了如下的Redis资讯：

在2015年12月份的时候， Redis暴出了一个可以利用漏洞获取Redis服务器的root权限，大体情况是：

Redis 默认情况下，会绑定在0.0.0.0:6379，这样将会将Redis服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法，可以成功将自己的公钥写入目标服务器的/root/.ssh 文件夹的authotrized_keys文件中，进而可以直接登录目标服务器。

临时解决办法是：

1）配置bind选项，限定可以连接Redis服务器的IP，并修改Redis的默认端口6379。

2）配置AUTH，设置密码，密码会以明文方式保存在redis配置文件中。

3）配置rename-commandCONFIG “RENAME_CONFIG”，这样即使存在未授权访问，也能够给攻击者使用config指令加大难度。

此漏洞暴出来后，Redis作者Antirez表示将会开发“real user”，区分普通用户和admin用户权限，普通用户将会被禁止运行某些命令，如config。事隔一年之后，近期又有网友暴漏了Redis的CSRF漏洞，不过这次好在Redis作者在最新发布的3.2.7已经进行了修复，解决方案是对于POST和Host:的关键字进行特殊处理记录日志并断开该链接避免后续Redis合法请求的执行。

漏洞总是不可避免，但是从Redis的使用和管理的角度是不是应当规避一些不必要的风险，尽可能的让Redis运行在一个安全的生产环境中呢？答案不言而喻，下面简单列举几点供参考：

• 内网访问，避免公网访问；

• 设置访问权限，禁用危险命令；

• 限制Redis服务器登录权限，修改Redis配置的一些默认参数；

• 定期扫描漏洞，关注Redis动态，及时更新版本。

原文发布时间为：2017-03-01

本文来自云栖社区合作伙伴DBAplus