网络协议学习笔记二
作者：冷家锋，刘婷婷
时间：2008-4-3
说明：欢迎转载，无须注明出处。水平有限，译者不保证译文的正确和准确，如因看了本译文而对看官的学习有误导，与译者无关。
学习网络和操作系统也有段时间了，总感觉无所进步，打算认真从tcpdump学起，来到www.winpcap.org网站，看到几篇文章，看了下，感觉自己的英文还对付，遂起翻译之意，也算是对自己一个交代;-)。网上搜了一下，似乎没有中文译文，可能是译者孤陋寡闻。
浏览了winpcap网站，感觉自己以前所学真是沧海一粟，太过浅薄，翻译几篇以作为开始。希望自己能坚持！！！
文章标题：Studying Normal Network Traffic, Part One
2001-01-29
原文链接：http://www.securityfocus.com/infocus/1222
本文是常规网络会话研究的第2篇。正如作者在第一篇的谈到的：很多网络入侵检测人员将注意力集中于可疑封包的特征，比如非法TCP标记（flag，网上搜了下，翻译为标记的较多，译者不知如何译更准确）组合或者保留（reserved）IP地址。其实，熟悉常规的网络会话是什么样的同样重要。研究网络会话例程是学习TCP/IP和您自己的系统环境的重要方法。本系列的第一篇介绍了如何用WinDump捕获封包并对封包进行检测，然后带着读者看了一些简单的TCP/IP会话的例子。本文将介绍FTP会话。从标准的会话流的角度看，FTP会话与大多数协议相比更为复杂。请读者注意，要理解本文的内容，您应该具备TCP/IP基础，并且熟悉WinDump或tcpdump日志格式，这一点本系列的第一篇进行了介绍。
<标准FTP会话>
FTP因其建立连接的方式而显得非常有趣。为了检测常规FTP会话，我们将在mypc.xx.yy.zz和一台远程FTP服务器（本例中是ftp.microsoft.com--IP:207.46.133.140）进行FTP会话。
会话开始，FTP会话与第一篇中分析的SSH会话很相似。常规地，FTP会话的第一步是发送一个获取默认网关的MAC地址的ARP请求。但是，本例中，该MAC地址存在与mypc的ARP缓存中，因此，不需要发送ARP请求。结果，我们在日志中首先看到的信息是DNS查询，该查询请求获得ftp.microsoft.com的IP地址，紧接着是DNS应答。注意：和我们预期的一样，这些UDP封包中，客户端使用高端口，服务器使用53端口。
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，接下来就是从一个高端口发起到ftp.microsoft.com的FTP端口21的TCP3步握手。
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)
3步握手过后，FTP客户端和服务器开始交换信息。然后笔者收到一条消息：笔者已经连接到ftp.microsoft.com，并要求笔者提供用户名。笔者敲入anonymous，然后笔者被要求输入一个email地址作为密码。笔者敲入email地址之后，获得了FTP提示符。该信息交换其实是客户端和服务器之间的一系列PUSH/ACK和ACK封包。下面是这些交换封包的一个例子。注意：这些封包使用mypc的3171端口和ftp.microsoft.com的 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)
到目前为止，FTP会话模式与SSH会话非常相似。然而FTP会话有一个明显的不同之处。FTP会话使用初始连接作为FTP会话的控制链路。该控制链路把客户端的命令发送到服务器并把服务器的应答传回到客户端。实际数据，比如目录列表，文件上传，下载不是通过该连接传送的。本例中，该控制链路是客户端的3171端口和FTP服务器的21端口。当用户下载文件或者请求目录列表时，数据通过一个单独的TCP连接进行发送，该连接专门为下载或目录列表请求创建，并且，一旦该请求结束，这个连接立即拆除。
当用户敲入”ls”命令以获取目录列表时，有几个步骤发生。服务器为了生成一个到客户端的数据连接，需要知道与客户端的哪一个端口通讯。第2行显示了服务器的应答，告诉客户端IP地址和端口号是可接受的。第3行是FTP客户端软件发送到服务器的命令，请求文件列表。最后，第4行，服务器通知客户端它正在产生数据连接。
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）的数据连接。此时3步握手产生，然后服务器发送一个PUSH/ACK封包到客户端。该封包包含文件列表，因为该封包非常小，因此可以包含在一个封包内。该封包的日志记录显示有164，表明在该封包中传输了164字节的数据。
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)
此时，有两个独立的连接：
。客户端3171端口和服务器的21端口之间的控制连接，
。客户端3172端口和服务器的20端口之间的数据连接。
一旦服务器完成了目录列表的传送，它就非常幽雅的执行该连接的拆除操作，该操作通过发送一个FIN/ACK封包来完成。要注意的是，服务器仅关闭其20端口的数据连接，而不是其21端口的控制连接。当数据连接正在拆除时，我们可以看到FTP会话仍然存在与控制连接。下面的第5个记录，显示了通过控制连接传输了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向客户端的一个不同于3172的高端口发起一个新的数据连接，然后是3步握手过程。数据将通过该连接传输，一旦传输结束，该连接即被拆除。
在一个FTP会话期间，数秒内可能会建立好几个连接。每次建立一个数据连接，客户端都会使用一个不同的端口。如果您只看会话的一部分，似乎这是一次端口扫描，尤其是当客户端分配连续的端口号时。您应该对会话进行更多的观察，以判定这是一次端口扫描还是仅仅是更多的FTP数据连接。
<Passive FTP会话>
FTP协议与其他协议的不同之处在于，由服务器发起到客户端的数据连接，而不是由客户端发起所有连接。由于防火墙和封包过滤程序的存在，FTP会话可能会遇到问题，因为FTP的数据连接是由服务器发起的。为了避免上述问题，用户可以利用passive FTP，而不是标准FTP。
Passive FTP和标准FTP采用系统的步骤：客户端在自己的高端口和服务器的21端口之间建立一个控制连接。然后，当需要打开一个数据连接说，服务器向客户端发送一个可用的高端口号。然后，客户端在其高端口中选择一个与服务器发送过来的高端口形成连接。因此，如果您使用passive FTP，端口20是不会用到的。此时，所有的数据是在两个高端口间传送的。
下面的例子是关于passive FTP的工作原理的。该会话由一台OpenBSD 2.8发起，用tcpdump捕获。OpenBSD的客户软件默认采用passive FTP。
首先，passive FTP与常规FTP类似，由客户端从其高端口向FTP服务器的21端口发起一个TCP连接。请注意：因为我们使用OpenBSD代替了Windows 98，用tcpdump代替了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.)
然后，与标准FTP会话过程类似，笔者在FTP客户端敲入ls以获得文件列表。在下面显示的第一个封包中，笔者的FTP客户端通知服务器使用passive 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
请注意：客户端知道服务器使用了哪个端口，客户端从另一个高端口向服务器发起了一个TCP连接。本例中，客户端使用端口24626，服务器使用端口3668。3步握手完成后我们可以看到在由服务器的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字节的数据之后发送的，但是0字节的数据最先收到。如果您需要分析类似的日志记录，将这些封包按时间戳排序是有效的，但是您应该注意其顺序号。
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使用两种不同的连接类型：控制连接和数据连接。控制连接用于从客户端向服务器发送命令，并从服务端接收命令的应答。控制连接由客户端发起。在标准FTP中，所有的数据连接由服务端发起。而在passive FTP中，所有的数据连接由客户端发起。
笔者怂恿您亲自进行FTP会话的封包捕获（当然，您需要有正确的授权）。本系列的下一篇文章将讨论一些正常封包的附加特征，比如TCP选项。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
