數千臺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中的使用者是由[email protected]兩部分共同組成，如下圖所示，這個和Oracle等資料庫會有鮮明的差別，如果為了省事就設定host為%就是一個潛在的隱患。
2、在MySQL 5.7開始會在初始化後隨即生成一個初始密碼，可以在初始化日誌中查詢。內容類似下面的形式：
error.log:2017-02-15T15:47:15.132874+08:001 [Note] A temporary password is generated for [email protected]: Y9srj<pdn9lj< p=””>
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
[[email protected] ~]$ mysql_config_editor set–login-path=fastlogin –user=root –host=localhost –password–socket=/u02/mysql/mysqld_mst.sock
Enter password:
配置完成之後，會在當前路徑下生成一個隱藏檔案.mylogin.cnf
而在密碼問題之外，還有哪些方面需要注意呢，這也就是我們資料庫安全的一些基本法則。
我在這個基礎上簡單做一些說明和補充。
- 檢查資料庫中的預設使用者，哪些是近期額外多出來的，做到心中有數。網路層面，系統層面做一些基本的限制，比如防火牆許可權控制，這個基本能夠杜絕哪些裸奔下的潛在問題。
- 控制使用者的許可權，不管是哪類資料庫，哪怕操作規範多細緻，滴水不漏，許可權上做不到管控，問題的源頭就是問題的無底洞。
- 日誌資訊的管理和監控。日誌可以理解是系統的第三隻眼睛，如果存在疑問，日誌是相對客觀的。
- 敏感資訊要加密，例如：姓名、電話、身份證號碼、銀行賬號、使用者密碼等，包括：敏感資料的遮蔽、資料脫敏、資料加密三個方面。
- 漏洞處理，系統，網路，資料庫的漏洞總是會有，這個就需要補充完善了。
而縱觀我們常見的一些黑客事件，其實很多都不是軟體本身支援得不夠好，而是某些方面使用者太放得開或者監管不力。
比如從去年的PLSQL Dev的黑客贖金事件，導致一些使用者的Oracle資料庫會莫名丟擲錯誤，提示支付比特幣來修復，潛伏期有多長，1200多天，一個數據庫能夠經歷3年以上已然是一個相對成熟的系統了。而事情的原因則和有些同學使用了盜版的PLSQL Dev(即綠色版)有關，你說這個鍋是否由Allround Automations公司來背？
其他資料庫暫時還沒有現成的一套工具防範，我們逐個把必要的建議羅列一下。
對於MongoDB的比特幣安全防範，沒有工具，雲棲社群給出了安全Checklist：
- 開啟鑑權功能：基於使用者名稱和密碼完成。
- 基於角色的訪問控制：除root角色之外，還有很多預先定義的內建角色，如只讀資料庫角色等。
- 內部鑑權：內部鑑權的使用者名稱是__system，鑑權資料庫是local資料庫。
- Sharding叢集的鑑權：Sharding叢集的鑑權和副本集鑑權有一定的區別：副本集在Mongod上鑑權，Sharding叢集在Mongos上進行鑑權。
當然，開啟鑑權勢必會帶來效能的開銷，這是因為鑑權通常需要客戶端和服務端進行一些網路互動以及CPU計算。但是與安全相比，這點開銷還是應該消耗的。
對於Hadoop，相對而言要簡單得多，一個是啟用Kerberos，一個是關閉不必要的埠。
| HDFS | NameNode預設埠：50070 |
| SecondNameNode預設埠：50090 | |
| DataNode預設埠:50075 | |
| Backup/Checkpoint Node預設埠：50105 | |
| YARN | ResourceManager預設埠：8088 |
| JobTracker預設埠：50030 | |
| TaskTracker預設埠：50060 | |
| Hue | Hue預設埠：8080 |
對於ElasticSearch的安全防範，白帽匯給出了這樣一些建議：
- 增加驗證，官方推薦並且經過認證的是shield外掛。網路中也有免費的外掛，可以使用elasticsearch-http-basic，searchguard外掛。
- 使用Nginx搭建反向代理，通過配置Nginx實現對Elasticsearch的認證。
- 如果是單臺部署的Elasticsearch，9200埠不要對外開放。
- 使用1.7.1以上的版本。在1.7.1以上版本目前還沒有爆出過相關漏洞。
- 另外Elasticsearch的官方也有其他產品與Elasticsearch配合緊密的，這些產品也存在漏洞，企業如果有使用其他相關產品存在漏洞也要進行修復，如Logstash，Kibana。
- 加強伺服器安全，安裝防病毒軟體，使用防火牆，網站安裝WAF.並對資料庫、系統、後臺使用的服務設定複雜的密碼，建議設定16位的大小寫字母+特殊字元+數字組合。
對於CouchDB的安全防範，白帽匯的建議是：
- 為CouchDB設定複雜密碼（字串，數字，特殊字元），並且長度超過16位。
- 修改預設的使用者名稱，CouchDB預設使用者名稱為admin，請對其進行修改。
- 做好網路隔離。不開啟外網訪問。
在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動態，及時更新版本。
參考連結：
原文作者：楊建榮、楊志洪
原文出處：http://dbaplus.cn/news-11-1092-1.html