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

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

根据 GuardiCore 研究人员的说法，针对 MySQL 的一系列攻击可以追溯到 2 月 12 日。所有跟踪都归因于属于荷兰网络托管公司 Worldstream (109.236.8< @8.20）。

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

信息大概是这样的，你可以检查你的数据库或日志是否包含以下信息。

然后他们要求数据库所有者支付 0.2 个比特币（价值 200 美元），以便数据库所有者可以访问数据。上述所有的敲诈事件，虽然不是同一团伙发起的，但基本上都是这样的套路。

下面的网站是一个接受支付的网站，已经取得了这么高的知名度。

安全研究员 Victor Gevers 敦促不要支付，不要支付，因为数据可能根本没有得到黑客的支持。

为什么会遭受比特币勒索？一方面，攻击者安全意识薄弱，没有采取必要的安全防范措施，有的甚至基本裸奔。不要笑。早些年，很多大医院的Oracle数据库都可以直接用system/oracle登录。另一方面，利用产品中的漏洞，称为 SQL 注入比特币勒索事件，就是其中之一。虽然目前的比特币勒索案数据库在安全意识上都被忽视，这给了黑客可乘之机，但一个接一个的成功也从另一个方面表明，数据库安全教育任重道远。

安利，邹德宇开发的DPM已经可以检测到Oracle和MySQL的比特币漏洞。当然，安全攻防一直在升级，牛博的伟大产品也在于不断的迭代升级。

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

MySQL 中的密码安全策略

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

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

如果是在批处理任务中，还是会有很多限制。为每个服务器设置不同的密码是不切实际的。这是不现实的。有几种策略可供选择：一种是只限制本地密码登录，这种使用比较常见，另一种是修改源代码。腾讯等大公司在源代码层关闭了这个警告。第三个对于应用控制尤为重要，即通过域名解析，MySQL中的用户由两部分组成：user@host，如下图，与Oracle等数据库有明显区别。如果为了省事把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配置的，已经在MySQL5.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

纱

资源管理器默认端口：8088

JobTracker 默认端口：50030

TaskTracker 默认端口：50060

色调

色调默认端口：8080

对于 ElasticSearch 的安全防范比特币勒索事件，白帽辉给出以下建议：

增加了验证，官方推荐和认证的是盾牌插件。网络里也有免费插件，可以使用elasticsearch-http-basic、searchguard插件。

使用 Nginx 构建反向代理，并配置 Nginx 对 Elasticsearch 进行身份验证。

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

使用 1.7.1 及以上。在1.7.1以上的版本中，还没有相关的漏洞。

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

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

对于 CouchDB 安全预防措施，White Hat 的建议是：

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

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

做好网络隔离。不要启用外部网络访问。

当然，还有 Redis。张东红先生提供了以下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 表示将开发“真实用户”来区分普通用户和管理员用户权限。普通用户将被禁止运行某些命令，例如 config。一年后，另一位网友最近曝光了 Redis 的 CSRF 漏洞。好在这一次，Redis 的作者在最新版本 3.2.7 中修复了它。解决办法是针对 POST 和 Host 的关键字：进行特殊处理，记录日志，断开链接，避免后续 Redis 合法请求的执行。

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

参考链接：