![[ 永遠的UNIX::UNIX技術資料的寶庫 ]](/images/title.gif) GB | BIG5
|
| 首頁 > 網絡管理 > 其它 > 正文 |
 |
| 網絡流量分析 |
| 本文出自:www.securityfocus.net 作者: (2001-09-11 12:00:01) |
網絡流量分析(一)
原: Karen Frederick
翻譯:土鱉(ISHTAR ISHTARIII@263.NET)
以往關入侵分析的文章都把注意力集中在可疑的數據包(TCP包或者保留的IP地址)上.但是弄清楚什是正常的網絡數
據流也是非常重要的.知道什是正常數據流最好的辦法就是先產生一些正常的數據流,然攔截數據包進行分析.在本文
中,本人介紹一些截獲數據包的工具並對截獲數據進行一些分析,順帶說一下非正常的數據流.學習本文的前提在你已經
有TCP/IP的基礎.
現在已經有了 很多截獲數據包的工具,最有名的是UNIX下的TCPDUMP和WINDOWS下面的WINDUMP.我在自己家98的機器上用
過WINDUMP2.1,用CABLE MODEM上網攔截數據包,不過需要指出的是:未經授權而攔截數據包時你可千萬要小心啊.
WINDUMP基礎
WINDUMP使用起來很簡單,在它的站點上你可以找到使用文件.我經常用的命令是
WINDUMP N S,或者WINDUMP n S v 或者WINDUMP n-S-vv.-N是不顯示計算機名而直接顯示IP地址;-S是顯示
TCP/IP的實際進程數,如果不選擇這個選項,可能出現的就是近似值,比如:如果現在的進程數是87334271,下一秒變成了多
了一個,就會顯示出來是87334272.-V和-VV是讓機器顯示更加全面的信息,顯示諸如存活時間/IP的ID等信息.
在開始剖析例子之前,我們先看一下WINDUMP記錄的不同種類的數據包,這裡有一個TCP的例子,
13:45:19.184932 sshserver.xx.yy.zz.22 > mypc.xx.yy.zz.3164: P 4138420250:4138420282(32) ack
87334272 win 32120 (DF)
13:45:19.184932 [timestamp] sshserver.xx.yy.zz.22 [source address and port] >
mypc.xx.yy.zz.3164: [destination address and port] P [TCP flags] 4138420250:4138420282
[sequence numbers] (32) [bytes of data] ack 87334272 [acknowledgment flag and number] win
32120 [window size] (DF) [don't fragment flag is set]
and then gives the number of data bytes in the packet:
下一個是UDP的例子,裡面也是該有的全有了:時戳/數據源地址和端口/目的地地址和端口,最還招供了使用的協議(UDP)和
數據包裡面的數據數
15:19:14.490029 208.148.96.68.23079 > mypc.xx.yy.zz.6976: udp 401
ICMP包格式也是類似的,只是注意一下最,出現了存活時間和IP的ID,當然,你要使用-V選項
18:33:45.649204 mypc.xx.yy.zz > 64.208.34.100: icmp: echo request (ttl 4, id 56693)
最,WINDUMP也抓獲ARP請求和回復.我們來看看:第一行是ARP請求;在這個例子裡,MYPC把MAC地址為24.167.235.1的機器信
息發送MYPC.XX.YY.ZZ(MYPC的IP地址),第二行則顯示了ARP回復,包含著24.167.235.1這個MAC地址.
13:45:13.836036 arp who-has 24.167.235.1 tell mypc.xx.yy.zz
13:45:13.841823 arp reply 24.167.235.1 is-at 0:xx:xx:xx:xx:xx
UDP和ICMP例子
上面我們已經看過了WINDUMP的記錄格式,接下來我們看看數據包:MYPC使用DHCP來獲得IP地址,而DHCP租用是定時更新的,這
個過程是從MYPC的68端口到DHCP機器的67端口,然由DHCP服務器回送到MYPC
18:47:02.667860 mypc.xx.yy.zz.68 > dnsserver.xx.yy.zz.67: xid:0x8d716e0f C:mypc.xx.yy.zz [|bootp]
18:47:03.509471 dnsserver.xx.yy.zz.67 > mypc.xx.yy.zz.68: xid:0x8d716e0f C:mypc.xx.yy.zz
Y:mypc.xx.yy.zz [|bootp]
WINDUMP的一個好處就在它可以自動識別協議和記錄的其他信息,在這個例子裡,他就識別出這是一個BOOTP,所以它不僅記
錄了標準的UDP記錄,而且記錄了BOOTP的特定信息:XID,C,Y.
現在我們來看看一些ICMP數據:一個例子就是你在98機器上使用TRACERT命令時出現的數據流,WINDOWS使用ICMP來識別系統之
間的跳(UNIX則使用UDP).
WINDOWS在執行路由追蹤時先向目的主機發送3個ICMP包,將存活時間設為1,這意味著當數據包到達第一跳時,數值會降為0.此
時.第一跳的機器會將ICMP超時錯的信息回送到主機,主機就再發出3個ICMP包,將跳數設為2,所以這會就可以在時延結束前到
達第二跳的機器,第二跳的機器就又將時延錯回送到主機,主機重新再發ICMP包,如此這般,直到找到目標機或者中間有一關將
數據流截斷為止.
which is one of the intermediate network devices between mypc and 64.208.34.100.
這裡就有一個路由追蹤的例子,ICMP的時延值已經被設為1,2,3而且都已經過期,由尚未到達最終目的機,WINDOWS開始發送
時延設為4的ICMP包,這裡是第一個數據包和回復 ,請注意雖然第一個數據包的目的地址是64.208.34.100,回復卻來自
24.95.80.133,這是MYPC和64.208.34.100之間的一個網絡設施的地址.
18:33:45.649204 mypc.xx.yy.zz > 64.208.34.100: icmp: echo request (ttl 4, id 56693)
18:33:45.668638 24.95.80.133 > mypc.xx.yy.zz: icmp: time exceeded in-transit (ttl 252, id 0)
在收到時延錯誤信息的千分之一秒內,MYPC發出續的ICMP包,在收到數據包的錯誤信息時,機器立即發送出第三個ICMP包:
18:33:45.669968 mypc.xx.yy.zz > 64.208.34.100: icmp: echo request (ttl 4, id 56949)
18:33:45.690719 24.95.80.133 > mypc.xx.yy.zz: icmp: time exceeded in-transit (ttl 252, id 0)
18:33:45.691863 mypc.xx.yy.zz > 64.208.34.100: icmp: echo request (ttl 4, id 57205)
18:33:45.710787 24.95.80.133 > mypc.xx.yy.zz: icmp: time exceeded in-transit (ttl 252, id 0)
請注意這些數據相當近似,只是每一個ICMP回應請求中IP的ID號不同,這點很重要,我們應該對IP的ID號雷同的現象引起高度
的重視.
檢測SSH進程
SSH是一個更加典型的數據流.我在工作站上裝了個SSH的客戶並連接到一個開了俺帳戶的機器上.
我有用連接到SSH服務器上的SSH的客戶端軟件.我的機器並不直到SSH服務器的IP地址,所以他需要DNS的服務,不幸的是,我
的機器上又使不了DNS,所以沒辦法的辦法之一就是先使ARP取得默認網關的MAC地址.
13:45:13.836036 arp who-has gateway.xx.yy.zz tell mypc.xx.yy.zz
13:45:13.841823 arp reply gateway.xx.yy.zz is-at 0:xx:xx:xx:xx:xx
would expect with a DNS query:
現在可以連接到網關上了,MYPC可以發出如下所示的DNS請求,請注意MYPC使用了大1023的端口,要求建立到DNS的53端口的
連接,這種請求使用的是UDP協議
13:45:13.841920 mypc.xx.yy.zz.3163 > dnsserver.xx.yy.zz.53: 1+ A? sshserver. (32)
DNS請求的結果是”1+A SSHSERVER”,我們可以認為這是一個IP地址的進程,因為A和+証明我們要求的是一個循環進程,1是
DNS請求數,用匹配DNS的請求和回復,SSHSERVER則是我們要解析的名字
以下是DNS服務器的回應:
13:45:13.947208 dnsserver.xx.yy.zz.53 > mypc.xx.yy.zz.3163: 1 q: sshserver. 3/4/6 sshserver. CNAME
ssh2server., ssh2server. CNAME ssh3server., ssh3server. A sshserver.xx.yy.zz (283)
回復情況由"1 q: sshserver. 3/4/6"體現,1是DNS的進程序號, "q: sshserver."是顯示我們的請求,3/4/6是顯示有3個回
復,4個標準記錄和6個額外記錄,和SSHSERVER連接的IP地址方在A面
現在我們知道了SSH服務器的IP地址,就可以連上去了,MYPC開始三次握手:
13:45:13.956853 mypc.xx.yy.zz.3164 > sshserver.xx.yy.zz.22: S 87334271:87334271(0) win 65535 (DF)
13:45:14.059243 sshserver.xx.yy.zz.22 > mypc.xx.yy.zz.3164: S 4138420249:4138420249(0) ack 87334272
win 32120 (DF)
13:45:14.059475 mypc.xx.yy.zz.3164 > sshserver.xx.yy.zz.22: . 87334272:87334272(0) ack 4138420250
win 65535 (DF)
三次握手完成,記住:即使2台機器在SSH端口建立了連接,我也沒有登錄到SSH服務器上去,在3次握手完成前機器間並沒有數
據交流.SSH客戶和服務器是建立了SSH進程,通過下面的數據包進行交流:
13:45:19.184932 sshserver.xx.yy.zz.22 > mypc.xx.yy.zz.3164: P 4138420250:4138420282(32) ack
87334272 win 32120 (DF)
13:45:19.201814 mypc.xx.yy.zz.3164 > sshserver.xx.yy.zz.22: P 87334272:87334314(42) ack 4138420282
win 65503 (DF)
13:45:19.300401 sshserver.xx.yy.zz.22 > mypc.xx.yy.zz.3164: . 4138420282:4138420282(0) ack 87334314
win 32120 (DF)
13:45:19.300616 mypc.xx.yy.zz.3164 > sshserver.xx.yy.zz.22: P 87334314:87334690(376) ack 4138420282
win 65503 (DF)
13:45:19.303977 sshserver.xx.yy.zz.22 > mypc.xx.yy.zz.3164: P 4138420282:4138421210(928) ack
87334314 win 32120 (DF)
13:45:19.422141 sshserver.xx.yy.zz.22 > mypc.xx.yy.zz.3164: . 4138421210:4138421210(0) ack 87334690
win 32120 (DF)
13:45:19.488282 mypc.xx.yy.zz.3164 > sshserver.xx.yy.zz.22: . 87334690:87334690(0) ack 4138421210
win 64575 (DF)
sshserver's port 22.
我敲了密碼,正式作為用戶登錄了進去,所有我使用SSH服務器所產生的數據流都很類似,在MYPC的3136端口和SERVER的22端
口之間,有PSH/ACK和ACK包.
我從SSHSERVER注銷的時候,服務器和客戶機之間也有數據流產生,客戶機收到來自服務器的最數據:
13:45:33.791528 mypc.xx.yy.zz.3164 > sshserver.xx.yy.zz.22: P 87335442:87335474(32) ack 4138426586
win 64359 (DF)
13:45:33.902690 sshserver.xx.yy.zz.22 > mypc.xx.yy.zz.3164: . 4138426586:4138426586(0) ack 87335474
win 32120 (DF)
一旦收到這個數據,客戶機就自動斷開連接,服務器確認斷開:
13:45:33.902909 mypc.xx.yy.zz.3164 > sshserver.xx.yy.zz.22: F 87335474:87335474(0) ack 4138426586
win 64359 (DF)
13:45:34.002179 sshserver.xx.yy.zz.22 > mypc.xx.yy.zz.3164: . 4138426586:4138426586(0) ack 87335475
win 32120 (DF)
13:45:34.003336 sshserver.xx.yy.zz.22 > mypc.xx.yy.zz.3164: F 4138426586:4138426586(0) ack 87335475
win 32120 (DF)
13:45:34.003492 mypc.xx.yy.zz.3164 > sshserver.xx.yy.zz.22: . 87335475:87335475(0) ack 4138426587
win 64359 (DF)
所以,我們可以歸納出SSH連接的5個步驟:
(1)使用ARP確認MYPC的默認網關的MAC地址
(2)發出DNS請求確認SSH服務器的IP地址
(3)MYPC的高端口和SSHSERVER低端口間的三次TCP握手
(4)MYPC和SSHSERVER之間的數據交流,包括建立SSH連接,用戶認証和數據傳輸.
(5)MYPC和服務器間的TCP連接斷開
在這個例子裡,SSH客戶機使用的是高端口(高1023).在一般連接裡,客戶機使用的高端口而服務器使用的是低端口,但是
需要引起注意的是很多SSH的客戶機也使用低端口,所以千萬別讓一個和本文例子不同的情況把你給弄糊塗了
在和SSH類似的連接裡,有更多的如TELNET等協議
結論
對例行的網絡流量進行分析是好好了解TCP/IP和我們環境的好辦法,每次我攔截數據包時,我總能學到點新東西,如果你對
本文有了興趣, 我強烈建議你生產/攔截並分析你自己的數據包, 我只是稍微進行 了一些介紹,面將繼續介紹更多的數
據流分析,尤其是FTP和HTTP.
以下為作者簡介:
Karen Frederick is a senior security engineer for NFR Security. Karen has a B.S. in Computer Science and
is completing her Master's thesis in intrusion detection through the University of Idaho's Engineering
Outreach program. She holds several certifications, including Microsoft Certified Systems Engineer + Internet,
Check Point Certified Security Administrator, and SANS GIAC Certified Intrusion Analyst. Karen is one of
the authors and editors of "Intrusion Signatures and Analysis", a new book on intrusion detection that was
published in January 2001.
--------------------------------------------------------------------------------
網絡流量分析(二)
原:
翻譯:土鱉(ISHTAR ISHTARIII@263.NET)
--------------------------------------------------------------------------------
(譯者注: 作者在這裡又把前面一篇文章開頭的話說了半天,俺就全給他省了)在以前的文章裡已經探討了TCP/UDP/SSH的情況,
下面我們來看FTP,你應該有TC排隊基礎,熟知WINDUMP和TCPDUMP的報告格式,這些我們在前文裡面已經介紹過了
標準的FTP進程
FTP建立進程的方式非常有趣.在檢測FTP流量前,我從MYPC.XX.YY.ZZ到遠程的FTP服務器建立一個連接,假設這個服務器是
FTP.microsoft.com(207.46.133.140)
FTP進程和我們上文見到的SSH進程的建立方式有些類似,首先取得默認網關的MAC地址,只是這裡這個過程在MYPC的ARP CACHE
裡完成,不必勞煩動用ARP請求,這個結果會在DNS裡面見到,請求獲得目的FTP服務器的IP地址,又取得一個DNS回復,注意這
些UDP包,客戶機使用高端口而服務器使用低端口53用DNS解析.
13:50:46.490130 mypc.xx.yy.zz.3170 > dnsserver.xx.yy.zz.53: 1+ A? ftp.microsoft.com. (35)
13:50:46.500269 dnsserver.xx.yy.zz.53 > mypc.xx.yy.zz.3170: 1 q: ftp.microsoft.com. 1/4/4
ftp.microsoft.com. A 207.46.133.140 (215)
現在MYPC有了服務器的IP地址: 207.46.133.140,立即服務器的21端口建立TCP的三次握手
13:50:46.564494 mypc.xx.yy.zz.3171 > 207.46.133.140.21: S 87666930:87666930(0)
win 65535 (DF)
13:50:46.671920 207.46.133.140.21 > mypc.xx.yy.zz.3171: S 3058770520:3058770520(0)
ack 87666931 win 17520 (DF)
13:50:46.672155 mypc.xx.yy.zz.3171 > 207.46.133.140.21: . 87666931:87666931(0)
ack 3058770521 win 65535 (DF)
握手完成,客戶機開始和FTP服務器交換信息,服務器要求用戶提供用戶名,我敲了anonymous而且輸入EMAIL作為密碼,
這一系列交流是通過PUSH/ACK和ACK包完成的.下面就是一個例子,在例子裡面,MYPC使用的是3171端口,服務器是21端口
13:50:46.779273 207.46.133.140.21 > mypc.xx.yy.zz.3171: P 3058770521:3058770576(55)
ack 87666931 win 17520 (DF)
13:50:46.896881 mypc.xx.yy.zz.3171 > 207.46.133.140.21: . 87666931:87666931(0)
ack 3058770576 win 65480 (DF)
13:50:48.282313 mypc.xx.yy.zz.3171 > 207.46.133.140.21: P 87666931:87666947(16)
ack 3058770576 win 65480 (DF)
13:50:48.388962 207.46.133.140.21 > mypc.xx.yy.zz.3171: P 3058770576:3058770648(72)
ack 87666947 win 17504 (DF)
13:50:48.495939 mypc.xx.yy.zz.3171 > 207.46.133.140.21: . 87666947:87666947(0)
ack 3058770648 win 65408 (DF)
和SSH相比,FTP有些差別:它在整個連接過程中採用進程控制.用戶向服務器的請求和服務器對客戶的回應都通過這個控制
通道進行.類似目錄列表/上傳和下載這樣的數據傳輸則不通過這個通道進行,在這個例子裡,客戶機的3171端口個服務器的
21端口就是控制通道,當用戶下載文件或者要求列出目錄列表時,相應的數據傳輸實際上是通過另外一個連接進行的.
當用戶使用LS命令來要求列出目錄時,相應的步驟開始了.服務器為了初始化一個到客戶機的連接,它就必須知道和客戶機的
哪個端口建立連接.在這個記錄文件裡,在第一行裡: 客戶機告訴服務器用連接的IP地址和端口號;第二行則是服務器的回
復,告訴客戶機IP地址和端口號被接受;第三行是客戶機要求列出目錄列表,第四行則是服務器告知客戶機自己正在初始化連接
13:50:53.501031 mypc.xx.yy.zz.3171 > 207.46.133.140.21: P 87666966:87666994(28)
ack 3058770765 win 65291 (DF)
13:50:53.607175 207.46.133.140.21 > mypc.xx.yy.zz.3171: P 3058770765:3058770795(30)
ack 87666994 win 17457 (DF)
13:50:53.632708 mypc.xx.yy.zz.3171 > 207.46.133.140.21: P 87666994:87667000(6)
ack 3058770795 win 65261 (DF)
13:50:53.737852 207.46.133.140.21 > mypc.xx.yy.zz.3171: P 3058770795:3058770850(55)
ack 87667000 win 17451 (DF)
為了傳輸數據(,在這裡是客戶機從服務器取得的目錄列表,),服務器初始化了一個從自己的20端口到客戶機指定端口(這裡
是3172)的連接,我們看到三次握手建立,服務器開始向客戶機發送PUSH/ACK數據包,這裡面就有文件列表,因為他正好小到
可以放進一個包裡.
13:50:53.738024 207.46.133.140.20 > mypc.xx.yy.zz.3172: S 3061133541:3061133541(0)
win 16384 (DF)
13:50:53.738200 mypc.xx.yy.zz.3172 > 207.46.133.140.20: S 87674104:87674104(0)
ack 3061133542 win 65535 (DF)
13:50:53.844704 207.46.133.140.20 > mypc.xx.yy.zz.3172: . 3061133542:3061133542(0)
ack 87674105 win 17520 (DF)
13:50:53.850833 207.46.133.140.20 > mypc.xx.yy.zz.3172: P 3061133542:3061133706(164)
ack 87674105 win 17520 (DF)
這時,出現了2個獨立的連接:
一個是客戶機的3171和服務器的21端口的連接
一個是客戶機的3172和服務器的20端口的連接
服務器一旦完成目錄列表的傳輸,就採用發送FIN/ACK包數據的方式準備結束連接.需要注意的是服務器僅僅在自己的20端
口上結束了連接而不是21端口上的控制通道.當數據傳輸連接截斷,控制通道內仍然有數據傳輸.下面記錄的第五行就顯
示了控制通道內一個24字節的傳輸,從客戶機的角度看來,是一個”226 TRANSFER COMPLETE”的顯示,表示傳輸成功.
13:50:53.850981 207.46.133.140.20 > mypc.xx.yy.zz.3172: F 3061133706:3061133706(0)
ack 87674105 win 17520 (DF)
13:50:53.851068 mypc.xx.yy.zz.3172 > 207.46.133.140.20: . 87674105:87674105(0)
ack 3061133707 win 65371 (DF)
13:50:53.895937 mypc.xx.yy.zz.3171 > 207.46.133.140.21: . 87667000:87667000(0)
ack 3058770850 win 65206 (DF)
13:50:53.903415 mypc.xx.yy.zz.3172 > 207.46.133.140.20: F 87674105:87674105(0)
ack 3061133707 win 65371(DF)
13:50:54.002060 207.46.133.140.21 > mypc.xx.yy.zz.3171: P 3058770850:3058770874(24)
ack 87667000 win 17451 (DF)
13:50:54.009333 207.46.133.140.20 > mypc.xx.yy.zz.3172: . 3061133707:3061133707(0)
ack 87674106 win 17520 (DF)
13:50:54.196818 mypc.xx.yy.zz.3171 > 207.46.133.140.21: . 87667000:87667000(0)
ack 3058770874 win 65182 (DF)
如果我從服務器下載數據,我們會看見相同的數據進程,服務器會從自己的20端口到客戶機的新的高端口建立一個連接,
進行三次握手,數據是通過這個連接進行傳輸,傳輸一旦完成,連接即告斷開.
在FTP進程裡,在同一時間內可能存在多個數據連接,每建立一個連接,一個新的客戶機的端口就被打開使用,僅僅看到進程
的一部分的話,可能會被認為是一個端口掃描,尤其是當客戶機端口有保護時.所以遇見這種情況時,你就應該仔細看看數
據傳輸的情況以判斷到底是端口掃描還是僅僅只是FTP連接.
被動的FTP進程
FTP的另一特殊之處在服務器要初始化和客戶機的連接,而不是由客戶機初始化所有與服務器的連接,由他的這種特性,
可能會導致一些防火牆和包過濾器的過激反應.為了解決這個問題,用戶可以採用被動FTP來取代標準FTP.
被動FTP在開始時個一般的FTP一樣:客戶機先初始化一個從服務器21端口到自己高端口的連接,當需要開放一個數據傳輸
通道是,服務器向客戶機發送一個可供選擇的高端口號,客戶機則初始化從自己的高端口和服務器的高端口的連接.所以在
使用被動FTP時,20端口從不被使用,所有數據傳輸均通過高端口進行.
這裡有一個被動FTP工作的例子,信息源是一台OPENBSD2.8,截獲手段是TCPDUMP,OPENBSD的客戶端的默認設置是使用被動FTP
首先,被動的FTP和普通的FTP一樣,客戶機初始化一個從自己的高端口到服務器21端口的TCP連接(請注意我這裡用的是OPENBSD
下的TCPDUMP而不是WINDOWS下面的WINDUMP,所以記錄看來有很大的差別)
15:57:28.005993 bsdpc.xx.yy.zz.28348 > 207.46.133.140.21: S 157025335:157025335(0)
win 16384
15:57:28.099136 207.46.133.140.21 > bsdpc.xx.yy.zz.28348: S 1286994806:1286994806(0)
ack 157025336 win 17520 (DF)
15:57:28.099193 bsdpc.xx.yy.zz.28348 > 207.46.133.140.21: .
ack 1286994807 win 17376
15:57:28.193361 207.46.133.140.21 > bsdpc.xx.yy.zz.28348: P 1286994807:1286994862(55)
ack 157025336 win 17520 (DF)
15:57:28.193413 bsdpc.xx.yy.zz.28348 > 207.46.133.140.21: . ack 1286994862 win 17376
(N.B.: Several additional PUSH/ACK and ACK packets have been omitted.)
(作者原注:這裡省略了好多PUSH/ACK和ACK數據包)
the client simply acknowledges that it has received the packet with the port information.
接下來,我鍵入LS以取得文件列表,在第一個數據包裡,我的FTP客戶機告訴服務器要使用被動FTP,第二個包則是服務器的
回應,包括了分配以用連接的服務器IP地址和端口號,在第三個包裡,客戶機確認已經收到了包含端口信息的數據包.
15:57:36.243722 bsdpc.xx.yy.zz.28348 > 207.46.133.140.21: P 157025383:157025389(6)
ack 1286995115 win 17376
15:57:36.342188 207.46.133.140.21 > bsdpc.xx.yy.zz.28348: P 1286995115:1286995166(51)
ack 157025389 win 17467 (DF)
15:57:36.342213 bsdpc.xx.yy.zz.28348 > 207.46.133.140.21: .
ack 1286995166 win 17325
現在客戶機知道使用服務器的哪一個端口,從另一高端口建立了一個倒服務器的連接,在這裡是端口24626,服務器使用端口
3668,三次握手建立,我們就看見服務器21端口和客戶機28348端口間的控制通道裡開始有數據傳輸
15:57:36.342370 bsdpc.xx.yy.zz.24626 > 207.46.133.140.3668: S 157871686:157871686(0)
win 16384
15:57:36.440039 207.46.133.140.3668 > bsdpc.xx.yy.zz.24626: S 1292391804:1292391804(0)
ack 157871687 win 17520 (DF)
15:57:36.440076 bsdpc.xx.yy.zz.24626 > 207.46.133.140.3668: .
ack 1292391805 win 17376
15:57:36.440167 bsdpc.xx.yy.zz.28348 > 207.46.133.140.21: P 157025389:157025395(6)
ack 1286995166 win 17376
15:57:36.542608 207.46.133.140.21 > bsdpc.xx.yy.zz.28348: P 1286995166:1286995220(54)
ack 157025395 win 17461 (DF)
15:57:36.542638 bsdpc.xx.yy.zz.28348 > 207.46.133.140.21: . ack 1286995220 win 17322
數據傳輸連接已經建立,文件列表得以傳輸,如果你現在看看依照時戳的記錄,似乎是在數據傳輸結束前(第三行)服務器就
終止了連接(第一行),如果你再看下去,你就會發現收到的數據包是雜亂無章的,0字節的數據包1167字節的數據包發出,
但是卻先被收到,當你分析記錄時按時戳順序是很有用的,但是你最好注意序列號.
15:57:36.547340 207.46.133.140.3668 > bsdpc.xx.yy.zz.24626: F 1292392972:1292392972(0)
ack 157871687 win 17520 (DF)
15:57:36.547367 bsdpc.xx.yy.zz.24626 > 207.46.133.140.3668: .
ack 1292391805 win 17376
15:57:36.549363 207.46.133.140.3668 > bsdpc.xx.yy.zz.24626: P 1292391805:1292392972(1167)
ack 157871687 win 17520 (DF)
15:57:36.549396 bsdpc.xx.yy.zz.24626 > 207.46.133.140.3668: .
ack 1292392973 win 16209
15:57:36.551374 bsdpc.xx.yy.zz.24626 > 207.46.133.140.3668: F 157871687:157871687(0)
ack 1292392973 win 17376
15:57:36.635184 207.46.133.140.21 > bsdpc.xx.yy.zz.28348: P 1286995220:1286995244(24)
ack 157025395 win 17461 (DF)
15:57:36.635211 bsdpc.xx.yy.zz.28348 > 207.46.133.140.21: .
ack 1286995244 win 17376
15:57:36.647798 207.46.133.140.3668 > bsdpc.xx.yy.zz.24626: .
ack 157871688 win 17520 (DF)
小結
我們已經深入分析了FTP,FTP用2種方式連接:數據控制:控制通道用發送客戶機到服務器的命令請求和服務器的回應.FTP
客戶機初始化一個到服務器的控制連接.在標準FTP裡,服務器初始化所有的到客戶機的連接,在被動FTP裡,客戶機初始化所
有的到服務器的數據傳輸.
我建議大伙做點自己的FTP測試(千萬注意合法性!!!)下一篇文章將重點介紹一些普通數據流的額外特性.
Karen Frederick is a senior security engineer for NFR Security. Karen has a B.S. in Computer Science and
is completing her Master's thesis in intrusion detection through the University of Idaho's Engineering
Outreach program. She holds several certifications, including Microsoft Certified Systems Engineer + Internet,
Check Point Certified Security Administrator, and SANS GIAC Certified Intrusion Analyst. Karen is one of the
authors and editors of "Intrusion Signatures and Analysis", a book on intrusion detection that was published
in January 2001.
(http://www.fanqiang.com)
進入【UNIX論壇】
|
|
| 相關文章 |
網絡流量分析 (2001-09-11 12:00:01)
CERNET收費政策中定義的國內流量IP分配地址列表 (2001-08-21 12:00:01)
在LINUX中實現流量控制器 (2001-08-11 07:05:00)
MRTG Router 流量分析架設法 (2001-05-02 03:55:00)
|
|
|
|
|
★ 樊強制作 歡迎分享 ★ |