我被攻擊了
個人服務器去年底最後兩天被攻擊了，因爲一些事情拖着沒來得及處理，今天實在忍不住了，記錄一下被攻擊後發現以及修復的過程。
2019-12-30 23:39:44 雲盾預警訪問惡意IP 178.170.189.5
這一次預警中有一個關鍵字“kdevtmpfsi”
2019-12-31 04:19:19 雲盾預警礦池通信行爲 178.170.189.5
kdevtmpfsi
如何找到根源
kdevtmpfsi 僞裝的挺好，因爲它和一個系統進程的名字非常相似 kdevtmpfs ，一不小心研究的重心就偏移了。我現在的程序是以 docker 運行的，宿主機如果被攻擊了問題就嚴重了。
因爲本身不是專業運維，排雷全靠猜測。雲盾感知的 cms 可能存在安全漏洞，代碼掃描後沒有發現異常，到這裏我感覺問題可能就更嚴重了。
容器存在漏洞？容器也就運行了 nmp，會是哪一個容器出現問題了呢？有些手足無措。cpu 佔用高，docker 查看一下容器的 cpu 佔用呢？
top
使用 top 命名直接可以查看到下圖，kdevtmpfsi 差不多100%的CPU佔用，導致服務器完全被惡意程序佔用，我本身的服務難以正常運行。
container
cpu 被 kdevtmpfsi 挖礦程序佔用 100%。按照上面的定位到容器的問題，使用命令查看容器狀態 docker stats 獲得下圖。
看到是 redis 容器被利用了，使用命令 docker exec -it 容器ID /bin/bash 進入內部看看具體問題呢？CTRL+P+Q
使用命令 ls -lrt 可以看到最早下載的 kinsing 文件是去年30日，與最早告警時間也基本在同一天。通過搜索學習到這個文件是挖礦程序的手續進程，後續需要清理掉。
按照雲盾報警的情況我們看下文件是否存在 /tmp/kdevtmpfsi ，如果存在也需要清理掉才行。文件肯定是存在的，我還幹了一件事情就是 kill -9 ID，CPU 佔用明顯就降下來了 ，然後手動運行了一下這個程序，發現 CPU 直接就飆升了
它是如何做到的
問題找到了，只要殺掉當前進程以及守護進程，問題也就暫時解決了。沒有找到根源，問題還是可能被利用，繼續寫入挖礦程序，我們先思考一下漏洞在哪裏呢？
上面分析出來是因爲 redis 的漏洞導致的？想一下我們的 redis 是如何安裝的，我當初測試一個需要登錄才能使用的應用程序，登錄的方式是關注公衆號，然後獲取授權碼去解鎖使用。就使用 redis 存放了臨時 token ，安裝 redis 的時候直接就是裸奔在空氣中，沒有密碼。
可以使用命令檢測一下，例如我的公網 IP 是 110.110.110.110。 只需要使用命令 redis-cli -h 110.110.110.110 -p 6379 就直接可以連上我的 redis 服務了。
通過雲盾安全預警查看到《【漏洞預警】Redis 4.x/5.x 遠程命令執行高危漏洞》，解決這個問題的關鍵可以設置僅內網訪問 redis，特殊對外的 IP 使用密碼策略。
version: '3'
services:
# 使用 command 命令設置一下密碼
redis:
image: redis:5.0.7
command: ["redis-server", "--requirepass", "yourpassword"]
hostname: redis
networks:
- redis-net
volumes:
- redis-data:/data
networks:
redis-net:
volumes:
redis-data:安全放心上
長呼一口氣之後，想起了《亡羊補牢》的故事。