網絡流量分析(二)
原著:
翻譯:土鱉(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.