![[ 永远的UNIX::UNIX技术资料的宝库 ]](/images/title.gif)
|
| 首页 > 网络管理 > 其它 > 正文 |
 |
| 网络流量分析 |
| 本文出自: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)
|
|
|
|
|
★ 樊强制作 欢迎分享 ★ |