上千个MySQL数据库被黑客勒索，如何攻破？

据内部数据中心安全行业领导者 GuardiCore 称，数以千计的 MySQL 数据库已被勒索。 这是过去六个月频繁发生的数据库勒索事件的延续：

据 GuardiCore 研究人员称，针对 MySQL 的一系列攻击可以追溯到 2 月 12 日。 所有痕迹都归因于属于荷兰网络托管公司 Worldstream (109.236.88.20) 的单个 IP 地址。

攻击者使用一些黑客工具在互联网上搜索安全措施较差的数据库服务器，对其进行暴力破解，然后删除或移动数据，并创建一个PLEASE_READ用户和WARNING表，并在表中放入一小段信息.

信息大概是这样的，你可以查看一下你的数据库或者日志中是否有如下信息。

然后他们要求数据库所有者支付 0.2 个比特币（价值 200 美元），以便数据库所有者可以访问数据。 上述所有勒索事件虽然并非同一伙人所为，但基本上都是遵循这样的套路。

下面这个网站是一个接受支付的网站，居然做到了这么高的知名度。

安全研究员 Victor Gevers 呼吁，不要付钱，不要付钱，因为那些数据很可能根本没有被黑客备份。

为什么会遇到比特币勒索？ 一方面，攻击者安全意识薄弱，没有采取必要的安全防范措施，有的甚至基本裸奔。 别笑，早年很多大医院的Oracle数据库比特币漏洞，直接用system/oracle就可以登录了。 另一方面，利用产品漏洞，众所周知的SQL注入就是其中之一。 虽然目前的数据库比特币勒索案件都存在安全意识松懈，给黑客可乘之机，但接二连三的成功也从另一个侧面说明数据库安全教育任重而道远。

安利一下，邹德宇带领的DPM可以检测到Oracle和MySQL的比特币漏洞。 当然，安全攻防总是在升级，牛白产品的强大就在于不断的迭代升级。

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

MySQL 中的密码安全策略

1、其实在我们日常工作中，如果使用明文密码比特币漏洞，MySQL也会给出提示，在早期版本中，可以直接查看mysql.user获取加密后的密码。

警告：在命令行界面上使用密码可能不安全

如果是在批任务中，这其实会有很多约束。 为每个服务器设置不同的密码是不现实的。 有几种策略可以选择：一种是只限制本地密码登录，这个用的比较多，另一种是修改源码，腾讯等大公司在源码层把这个警告关掉。 三是应用的控制也尤为重要，即通过域名解析的方式，MySQL中的用户由两部分组成：user@host，如下图，与甲骨文和其他数据库。 如果为了图省事把host设置成%，那是一个潜在的隐患。

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

error.log: 2017-02-15T15:47:15.132874+08:001 【注意】为root@localhost生成临时密码：Y9srj

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

>从 mysql.user 中选择不同的插件；

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

|插件|

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

|mysql_native_password|

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

4、查看mysql密码相关的参数，会发现有一个参数

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

5、还有一点很多DBA需要习惯的，就是MySQL 5.7只会创建一个root账户，并且会自动生成一个临时密码的用户，不会再创建其他账户。 测试库在之前的版本中会默认生成，不会自动生成。 这种提升虽然很细微，但是却可以阻止一些侥幸的人。

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

MySQL无密码登录

而如果使用无密码方式登录，也是通过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

输入密码：

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

数据库安全基础

除了密码问题，还有哪些方面需要注意？ 这些是我们数据库安全的一些基本规则。

借用Oracle数据库安全文章的一张图，总结的比较全面。

我在此基础上简单做一些解释和补充。

检查数据库中的默认用户，最近添加了哪些用户，并注意它们。 网络层面，在系统层面做了一些基本的限制，比如防火墙权限控制，基本可以杜绝裸奔下的潜在问题。

管控用户权限，不管什么样的数据库，不管操作规范有多详细，如果没有泄漏控制，问题的源头就是问题的无底洞。

日志信息的管理和监控。 日志可以理解为系统的第三只眼。 如果有疑问，日志是比较客观的。

对敏感信息进行加密处理，如：姓名、电话号码、身份证号码、银行账号、用户密码等，包括：敏感数据屏蔽、数据脱敏、数据加密。

漏洞处理，系统、网络、数据库的漏洞会一直存在，需要补充和完善。

纵观我们常见的一些黑客事件，其实很多并不是因为软件本身没有得到很好的支持，而是因为用户过于宽松或者在某些方面监管不到位。

比如去年的PLSQL Dev黑客勒索事件，部分用户的Oracle数据库会莫名其妙的抛出错误，提示支付比特币修复，潜伏期多长，1200多天，一个数据库能维持3个多年已经是一个比较成熟的系统了。 事件的起因是部分同学使用了盗版的PLSQL Dev（即绿色版）。 你以为这个锅是Allround Automations背的？

对于其他数据库，目前还没有现成的一套防范工具，所以我们会一一列出必要的建议。

对于MongoDB的比特币安全防护，目前还没有工具，云栖社区给出了一份安全检查表：

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

对于Hadoop，相对来说就简单多了，一是开启Kerberos，二是关闭不需要的端口。

硬盘文件系统

NameNode默认端口：50070

SecondNameNode 默认端口：50090

DataNode默认端口：50075

备份/检查点节点默认端口：50105

纱

ResourceManager默认端口：8088

JobTracker 默认端口：50030

TaskTracker 默认端口：50060

色调

色调默认端口：8080

对于ElasticSearch的安全防范，White Hat Hui给出了一些建议：

增加验证，官方推荐并认证了shield插件。 网上也有免费的插件，可以使用elasticsearch-http-basic和searchguard插件。

使用Nginx搭建反向代理，配置Nginx对Elasticsearch进行鉴权。

如果是单机部署Elasticsearch，不要对外开放9200端口。

使用 1.7.1 以上的版本。 1.7.1以上版本未暴露相关漏洞。

此外，Elasticsearch官方还有其他与Elasticsearch紧密合作的产品。 这些产品也有漏洞。 如果企业使用其他存在漏洞的相关产品，则必须进行修复，例如Logstash、Kibana。

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

关于CouchDB的安全保护，White Hat Exchange的建议是：

为CouchDB设置复杂的密码（字符串、数字、特殊字符），长度超过16个字符。

修改默认用户名，CouchDB默认用户名为admin，请自行修改。

做好网络隔离。 未启用互联网访问。

当然，还有Redis。 在最新一期的DBAplus Newsletter中，张东红先生提供了以下Redis信息：

2015年12月，Redis爆出一个漏洞，可被利用获取Redis服务器的root权限。 一般情况是：

默认情况下，Redis 绑定到 0.0.0.0:6379，这会将 Redis 服务暴露到公网。 如果不启用认证，则任何用户都可以在未经授权的情况下访问目标服务器。 Redis 并读取 Redis 数据。 攻击者可以在未授权的情况下使用Redis的相关方法访问Redis，并可以成功将自己的公钥写入目标服务器/root/.ssh文件夹下的authorized_keys文件中，然后直接登录目标服务器。

临时解决方法是：

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

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

3）配置rename-commandCONFIG“RENAME_CONFIG”，这样即使有未授权的访问，也可以让攻击者更难使用config命令。

在该漏洞被曝光后，Redis 作者 Antirez 表示将开发一个“真实用户”来区分普通用户和 admin 用户权限。 普通用户会被禁止运行某些命令，比如config。 时隔一年，近日有网友泄露了Redis的CSRF漏洞。 幸运的是，Redis 的作者在最新的 3.2.7 版本中修复了它。 处理日志记录并断开链接以避免后续Redis合法请求的执行。

漏洞总是不可避免的，但是从Redis的使用和管理的角度来看，我们是否应该避免一些不必要的风险，尽可能让Redis运行在安全的生产环境中呢？ 答案不言而喻，这里简单介绍几点供参考：

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

本文来自云栖社区合伙人DBAplus