60      技術社區[雲棲]

數千台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

而在密碼問題之外，還有哪些方麵需要注意呢，這也就是我們數據庫安全的一些基本法則。

借用文章裏的一個圖，總結相對全麵很多了。

我在這個基礎上簡單做一些說明和補充。

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

最後更新：2017-05-15 10:03:54

  上一篇：  Oracle 12cR2發布，金融行業準備大規模上了

  下一篇：  源代碼倉庫常見問題匯總