據內部數據中心安全的行業領導者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**](http://www.yunweipai.com/go?_=1ae1aa43f8aHR0cDovL2RiYXBsdXMuY24vbmV3cy0yMS04OTctMS5odG1s)已經可以檢測Oracle和MySQL的比特幣漏洞了。當然，安全攻防永遠在不斷升級，牛掰的產品厲害也在于不斷迭代升級。 **針對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中的無密碼登陸** 而如果使用無密碼的模式來登錄，也通過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 **數據庫安全的基本法則** 而在密碼問題之外，還有哪些方面需要注意呢，這也就是我們數據庫安全的一些基本法則。 借用[**Oracle數據庫安全面面觀**](http://www.yunweipai.com/go?_=76b1d40332aHR0cDovL2RiYXBsdXMuY24vbmV3cy0xMC0xMzUtMS5odG1s)文章里的一個圖，總結相對全面很多了。  我在這個基礎上簡單做一些說明和補充。 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，一個是關閉不必要的端口。** HDFSNameNode默認端口：50070SecondNameNode默認端口：50090DataNode默認端口:50075Backup/Checkpoint Node默認端口：50105YARNResourceManager默認端口：8088JobTracker默認端口：50030TaskTracker默認端口：50060HueHue默認端口：8080 **對于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中**](http://www.yunweipai.com/go?_=6c1cbcb155aHR0cDovL2RiYXBsdXMuY24vbmV3cy0yMS0xMDc2LTEuaHRtbA%3D%3D)**，張冬洪老師提供了如下的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動態，及時更新版本。