數據庫遭遇.dewar或者.devos結尾的勒索病毒加密的恢復

1，devos勒索病毒說明
phobos勒索病毒家族的一款變種勒索病毒近期頻繁出現，該病毒會將文件後綴篡改成dewar或者devos，該病毒很是狡猾，近期就有一個客戶服務器上的Oracle數據庫遇到了該病毒。加密文件以下：

經過對底層存儲數據的解析，發現該病毒有以下特色：

1. 會對服務器上後綴名爲dbf、mdf、ibd的文件進行全加密。
2. 對其餘類型的文件進行破壞，破壞規則爲從文件頭部開始清空256k，而且每間隔10g清空256k。

該病毒很是狡猾，會判斷文件類型，專門對數據庫數據文件進行全加密，這也讓從加密的數據文件中抽取數據變成了一件不可能的事情，惟一的解決方法，就是找***解密。

在對加密文件分析過程當中，咱們發現該病毒並不會對rman備份文件或者expdp/exp的dmp文件進行全加密，這類文件會從文件頭部開始清空256k，而且每間隔10g清空256k。這讓咱們的恢復產生了一些起色，能夠經過rman備份或者dmp文件進行恢復。在本次案例中咱們就是利用被加密後的文件來恢復客戶的數據庫。

2，利用RMAN備份還原數據庫
諮詢了客戶是否有備份，客戶防患意識很是好，按期對數據庫作了rman備份。

2.1 分析RMAN加密後的文件
截取備份片前1G簡單經過dd分析一下：

[root@test ~]# dd if=rman_1G.bak bs=8192 count=32|od -x
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
32+0 records in
32+0 records out
262144 bytes (262 kB) copied, 0.00326108 s, 80.4 MB/s

不出所料前256k確實被清空了。並且每隔10g還會清空256k(固然這裏咱們只截取了1g來分析)。

[root@test ~]# dd if=rman_1G.bak bs=8192 count=1 skip=129|od -x|head -1  
0 records in
0 records out
bytes (8.2 kB) copied, 6.2713e-05 s, 131 MB/s
a238 0000 0081 0040 d899 ed66 0da3 0401
[root@test ~]# dd if=rman_1G.bak bs=8192 count=1 skip=130|od -x|head -1  
0 records in
0 records out
bytes (8.2 kB) copied, 4.6691e-05 s, 175 MB/s
a238 0000 0082 0040 d899 ed66 0da3 0401
[root@lx ~]# dd if=rman_1G.bak bs=8192 count=1 skip=131|od -x|head -1 
0 records in
0 records out
bytes (8.2 kB) copied, 8.2504e-05 s, 99.3 MB/s
a238 0000 0083 0040 d899 ed66 0da3 0401

查看備份片後面一些的block發現塊類型爲0x38，當時有一種不良的預感，該備份非常壓縮的備份集。這給整個恢復帶來了很是大的難度。

rman備份默認採用basic壓縮，測試使用的壓縮算法爲bzip2，有了此信息後，咱們能夠經過手動的方式將加密後的壓縮文件進行解密。

3，還原的思路和過程
通過長達幾個小時的分析研究，終於比較完美的實現了恢復，數據恢復95%以上達到了客戶的要求。大體過程以下：

1. rman_backup_uncompres.exe d:\backup % d:\backupuncompres
2. 使用odu工具對解壓的備份片把數據文件抽取出來
3. 使用odu工具對抽取出來的數據文件進行數據抽取
4. 將odu抽取文件導入新建數據庫

4，注意事項1，生產環境中必定要作數據庫備份。2，備份文件不能存放在數據庫所在服務器上。3，搭建數據庫容災環境，而且作好容災環境的安全控制。