数以千计的 MySQL 数据库被比特币黑客勒索，如何破解？

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

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

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

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

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

以下网站是一个接受付款的网站，并且取得了如此高的知名度。

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

你为什么会遇到比特币勒索？一方面，攻击者的安全意识薄弱，不需要，有的甚至基本裸奔。不要笑。早些年，很多大医院的Oracle数据库都可以直接用system/oracle登录。注射就是其中之一。虽然目前的比特币勒索案数据库在安全意识上都被忽视，给黑客提供了可乘之机，但该系列的成功也从另一个方面表明，数据库安全教育任重道远。

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

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

MySQL 中的密码安全策略

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

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

如果是在批处理任务中，这实际上会有很多限制。不能为每台服务器设置不同的密码，这也不会。实际上有几种策略可供选择：一种是只限制本地无密码登录，比较常见，另一种是修改源代码。腾讯等大公司在源代码层关闭了这个警告。第三个对于应用控制尤为重要，即通过域名解析，MySQL中的用户由两部分组成：user@host。如下图所示，这与Oracle等数据库不同。如果为了省事把host设置为%，那就是潜在的隐患。

2、在MySQL6.0@>7中，初始化后会立即生成一个初始密码，可以在初始化日志中找到。内容类似如下：

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

6.2@>mysql.user中的默认值为mysql_native_password，不再支持mysql_old_password。

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

+——————––+

|插件|

+————————+

|mysql_native_password |

+——————––+

6.3@>如果查看MySQL密码相关的参数，会发现有一个参数

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

6.4@>还有一点是很多DBA需要习惯的，就是在MySQL中只会创建一个root账号6.0@>7，并且会自动生成临时密码。创建其他账号，之前版本默认生成的测试库不会自动生成。虽然这种改进很微妙，但可以阻止一些幸运的人。

6.6@>在此基础上，如果需要更高级别的安全策略，MySQL 6.0@>7版本提供了更简单的SSL安全访问配置，默认连接使用SSL加密方式。如果用户的数据不通过SSL传输比特币被破解，在网络上以明文形式传输，一定程度上会给别有用心的人带来机会。

MySQL 中的无密码登录

而如果你使用无密码方式登录，也是通过mysql_config_editor配置的，已经在MySQL 6.0@>6中发布。

mysql_config_editor的命令提示符如下，可以看出可用的选项比较简单。

6.9@>

我们可以通过一个命令直接完成配置，并将这个无密码登录的别名制定为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，一是关闭不必要的端口。

HDFS

NameNode 默认端口：50070

SecondNameNode 默认端口：50090

DataNode默认端口：50075

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

纱线

ResourceManager 默认端口：8088

JobTracker 默认端口：50030

TaskTracker 默认端口：50060

色调

Hue 默认端口：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。在最新一期的DBAplus Newsletter中，张东红先生提供了以下Redis信息：

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

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

临时解决办法是：

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

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

3）配置rename-commandCONFIG“RENAME_CONFIG”，即使存在未授权访问，攻击者也很难使用config命令。

这个漏洞出来后，Redis作者Antirez表示将开发“真实用户”来区分普通用户和admin用户权限。普通用户将被禁止运行某些命令，例如 config。一年后，另一位网友最近曝光了 Redis 的 CSRF 漏洞。幸运的是，这一次，Redis 的作者在最新版本 3.2.7 中修复了它。解决办法是针对POST和Host的关键字：进行特殊处理，记录日志，断开链接，避免后续Redis合法请求的执行。

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

参考链接：