記一次docker 容器被黑總結

前記

好久沒寫文章了，一是由於本身的知識較爲零散，另外一個就是比較懶了，大多都零碎記錄在了本地。

好久沒有登陸osc，登陸的時候發現帳號被凍結了，激活才能使用，這個安全功能給個贊，不過貌似存在郵件轟炸功能，可測，不表於此。

今天就簡單說下最近遇到的一次業務jenknis docker容器被黑後排查的故事。

初步分析

1. 進入主機，排查history文件，進程，系統命令，常見文件，網絡通訊等基本方面。
2. ps/netstat/psof等系統命令文件被替換、存在異常進程名、存在大量異常端口通訊、/tmp、/etc等目錄存在可疑文件。
3. 從以上等特徵初步分析爲gates系列木馬變種，含挖礦與ddos功能。
4. 根據業務已有對外網開放的服務及其餘方面確認，這次被黑是由於5月份出現的jenknis反序列化漏洞致使，因此在history文件也就沒有找到太多有價值的東西。

專向docker

既然系統自己沒有太多日誌，並且鑑於漏洞的利用方式，轉向排查docker jenknis容器的日誌或系統的syslog日誌(syslog日誌不排除被刪)。

docker logs

# 查看容器2eb09877d1b0的運行日誌，默認來自系統的/dev/stderr和/dev/stdout
docker logs 2eb09877d1b0

# 查看容器2eb09877d1b0 2017-06-17日開始的100條日誌
docker logs -f -t --since="2017-06-17" --tail 100  2eb09877d1b0 

# 上面語句可能存在一個問題，沒法導出含stderr的docker logs、沒法grep查看docker logs日誌
# grep查看含有特定字符的日誌行
docker logs 2>&1 | grep hello
docker logs 2>/dev/null | grep hello

# 導出docker logs，查找docker 容器日誌存放目錄
docker inspect --format='{{.LogPath}}' 2eb09877d1b0

調查結果

從docker容器日誌裏能夠詳細看到每一次jenknis報錯信息中含有的攻擊者執行的命令字符串，至此基本肯定了最先的攻擊時間和攻擊流程。

未完成的遺憾

一次完美的溯源應該是查清誰於什麼時間經過什麼方式黑進來，作了什麼事情。
而這次溯源中出現了一點不完美是由於docker logs沒有記錄源ip。

後來查詢官方文檔後，自定義了docker logs記錄的數據來源與日誌格式，詳細參考：
https://github.com/nginxinc/docker-nginx/blob/8921999083def7ba43a06fabd5f80e4406651353/mainline/jessie/Dockerfile#L21-L23
https://docs.docker.com/engine/admin/logging/view_container_logs/