據内部資料中心安全的行業上司者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注入就是其中一種。雖然目前比特币勒索案例的資料庫，都是疏于安全意識給了黑客可乘之機，但接二連三連環得手，也從另一個側面說明資料庫安全教育任重而道遠。
針對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
資料庫安全的基本法則
而在密碼問題之外，還有哪些方面需要注意呢，這也就是我們資料庫安全的一些基本法則。
我在這個基礎上簡單做一些說明和補充。
檢查資料庫中的預設使用者，哪些是近期額外多出來的，做到心中有數。網絡層面，系統層面做一些基本的限制，比如防火牆權限控制，這個基本能夠杜絕哪些裸奔下的潛在問題。
控制使用者的權限，不管是哪類資料庫，哪怕操作規範多細緻，滴水不漏，權限上做不到管控，問題的源頭就是問題的無底洞。
日志資訊的管理和監控。日志可以了解是系統的第三隻眼睛，如果存在疑問，日志是相對客觀的。
敏感資訊要加密，例如：姓名、電話、身份證号碼、銀行賬号、使用者密碼等，包括：敏感資料的屏蔽、資料脫敏、資料加密三個方面。
漏洞處理，系統，網絡，資料庫的漏洞總是會有，這個就需要補充完善了。
而縱觀我們常見的一些黑客事件，其實很多都不是軟體本身支援得不夠好，而是某些方面使用者太放得開或者監管不力。
比如從去年的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動态，及時更新版本。
原文釋出時間為：2017-03-01
本文來自雲栖社群合作夥伴dbaplus