对FTP登入产生的帧的分析

对FTP登入产生的帧的分析 
       一次成功的FTP登陆是从命令行ftp 192.168.30.7开始的，结束于提示User Logged in出现ftp>提示符。通过使用Iris v4.0对本机（IP:192.168.30.40）和FTP服务器（IP:192.168.30.7）之间传输的数据进行捕捉，一共获得了11个帧，并将其保存为一个Cap文件进行分析，其中FTP Data不为0bytes的帧有第4、6、7、9、10帧，下面结合实际情况对帧的结构进行说明。

MAC Header Ipv4 Header TCP Header FTP Data
14         20          20         可变

表1 帧结构

        TCP/IP模型为4层结构，分为应用层，运输层，网络层以及数据链路层。由表1可以清楚的看出这四层结构。首先是属于应用层的FTP数据，由于它是最原始的数据，所以被放置在一个帧的最里面，由于应用程序的分层设计，所以在有的帧中FTP Data为0字节，因为这些帧没有涉及到应用层程序的操作，然后把这个只有FTP Data的帧传送给运输层。在这一层在FTP数据的前面加上了一个TCP Header，长度为20个字节，然后把此帧传送给网络层，由网络层在帧的前面加上IP Header，最后传给数据链路层，在帧的前面加上MAC Header。这样就完成了一个帧的组合，下面分别对一个帧的四个组成部分进行详细的说明。

MAC Header

       MAC Header是在数据链路层加上的，他的长度为14个字节，结构如下：

Destination Address Source Address Type
6                   6              2

表2 MAC Header结构

       我们知道，网络中的每台计算机都有自己的IP地址，每个应用程序都有自己的Port，这样保证了数据能够传送给指定IP上的指定的应用程序。链路层不关心这些帧送到目的地以后是如何被按层拆解的，以及这个帧中的信息是送给那个应用程序的，他只负责把一个帧送到指定地址的计算机或者其他设备上，这样就足够了，所以，在MAC Header中没有多余的信息，只包含了和IP地址相对应的物理地址MAC地址，以及Type。

由于是把这个帧发送出去，因此把接受方的MAC地址放在了最前面，同时也把发送方的MAC地址告诉了接受方，这样才可以让接受方知道响应的时候把帧送到哪里去，这两个MAC地址的长度都是6字节，其中前三位[前三个字节中的第1，2位并不是厂商地址，而是具有特殊意义的。] 是硬件设备的厂商被分配的地址，后面的三位是这个厂商的自己的流水号。在一般情况下，MAC地址是不能像IP地址那样通过软件来随意更改的，这样保证了网络上不会出现同样的MAC地址，保证了数据传输。当我们知道目的节点的IP地址，但是不知道它的物理地址时，就要使用ARP协议，发送一个广播帧给网络中的所有节点，在这个广播帧中MAC的目的地址是FF:FF:FF:FF:FF:FF，在这个帧中记录了目的节点的IP，和发送方的IP以及MAC地址，这样当目的节点受到这个帧以后就可以把自己的MAC地址返回给发送节点了。

Type字段的意义标示出了该帧链路层的上层协议是什么，以便把后面的数据报进行分用,传送给正确的上层协议处理，比如此例中该字段内容是0800，表示IP，另外0806表示ARP，8035表示RARP。

Ipv4 Header

       Ipv4 Header是在网络层加上的，没有选项和填充的情况下，他的长度是固定的20个字节长度。因为它不直接和应用层打交道，所以它没有记载能唯一区分应用程序的Port，只是记载了IP地址。下面分别对每个字节进行说明。

Version 长度4位

       在本例中，这里的记录信息为4，表示IP协议的版本号是4，所以也记作Ipv4，在这个版本中IP地址的长度为32位，由于早期IP 地址分配出现很多浪费，所以造成未来可用IP数目的紧缺，因此开发出Ipv6，在新的版本中IP地址的长度变为128位。通过读取这4位的信息，可以知道这个帧所记载的IP长度，以及其他信息所遵循的IP协议的版本。这样才能保证发送节点，目的节点，路由器和网关用一样的格式传输和转发本数据报。

Header Length 长度4位

       在本例中，这里的记录信息为5，表示Header的长度为5*32位=20个字节。本字段的4位，和Version中的4位一起组成一个字节45。由于本字段是一个4位的字段，所以它能表示的最大数目是15，那么最大Header长度就是15*32位=60个字节。一般情况下，不包含任何选项和填充字节的IP包，Header长度字段都是5。选项字段是一个长度可以变化的字段，主要记录了诸如安全性，路径选择等信息，我们注意到，由于它的长度不是固定的，所以不能保证[由于IP Header中只设计了一个4位字段保存Header长度，用这个字段*32位计算出Header长度，所以必须保证Header本身的长度是32位的倍数。] Ip Header的长度是32位的倍数，此时就需要通过增加填充字节来保证IP Header的长度是32位的倍数。

Type Of Service 长度8位

       在本例中，这里的记录信息为00，表示一般服务，此字段头部包含一个3位的优先级设置字段，但是Iris软件并没有对这3个字段进行标示。接下来的第4,5,6,7位每一位都是一种标示，按照顺序依次是最小延迟、最大吞吐量、最大可靠性、最小开销，这四位默认都是0，表示Normal，如本例所示就是Normal。字段的第8位为0，作为一个补充位保证了一个字节的完整性。在一些情况下，本字段的4,5,6,7标志位会被设置为1，例如[具体协议的应用可以参考《TCP/IP祥解》一书的图3-2] ：对于语音传输来说就要尽量的避免延迟现象的产生，所以第4位要设置为1，我们使用的Ip电话就是这个道理，它并不需要很大的吞吐量，也不需要每个bit都要保证可靠的传输，所以使用Ip电话有时候会信号不好。另外当我们要传送很大的文件的时候就要把最大吞吐量位置1，当进行商业活动时，比如我们在招商银行网站登陆自己的账户，必须保证信息传输的可靠性，所以就把第6位最大可靠性置1。值得注意的是，这四位中只能同时有1位被置于1。

Total Length 长度16位

       这个字段记录了一个IP数据报的总的长度，单位是字节，在没有填充的情况下，他的长度就是一个帧的长度减去MAC Header的长度得到的结果。这个字段长度2个字节，也就是说理论上一个Ip数据报的长度可以达到65535字节。因为各种网络对帧的数据部分的最小长度有一个规格，比如以太网是46字节，所以当帧的数据部分长度不够的时候就需要通过填充字节来补充，所以必须知道IP数据报的长度，这样才能区分出来那些是后来补充的，那些是数据报本身的数据。

Identification 长度16位

       标示字段，一般每个数据报都会有一个唯一的数字标示，并且每发送一个数据报就会加一。当要把一个数据报分片发送的时候，会把这个字段的内容，复制到每个片中，表示这些被分割的片属于同一个数据报。

Flags 长度3位

       第一位是保留位，暂时没有用到。第二位表示是否是分段，第三位表示是否是分段的最后一片。

Fragment offset长度13位

       分段的时候，用来表明每一段和原有数据报开始位置的偏移量。这样才能按照正确的顺序把每个分段组合成一个完成的数据报。

Time to live 长度8位

       为了避免一个数据报无限制的在网络中传输下去，造成网络拥塞，每个数据报都有自己的生存时间，由于此字段为8位，所以最大生存时间是255，这样，当一个数据报经过一个网关、路由器或者是一个主机的时候，生存时间都会被减去1，当生存时间被减到0以后，这个数据报就要被抛弃了。tracert的设计原理就是这样的，他首先发送一个生存时间1的数据包，当这个包被抛弃的时候，就会知道遇到了第一个路由器，然后再发送生存时间为2的数据包，。。。。。。直到到达目的节点，这样就可以按照顺序找出经过的路由器。

Protocol 长度8位

       这个字段记录了接受数据的上层协议的标示，在本例中为6，表示上层协议应该是TCP，另外17标示UDP。当一个数据帧被目的节点接收到以后，就从底层网上走，因此就要知道从底层交给上一层的那个协议处理呢？所以要在这里纪录。

Checksum 长度16位

       报头检验和字段，用来检验IP Header的完整性，不检验后面的数据，如果检验失败就把错误的数据报丢掉，然后让上层负责重传。

Source Ip address 长度32位      

       发送数据报的节点的IP地址。

Destination Ip address 长度32位

       接受数据报的节点的IP地址。

Ip Options

       记录是否有可选项。本例中没有。这个字段的长度是可变的，需要通过填充字节来保持完整性。


TCP Header

       在传输层加上的报头。长度也是固定的20个字节。这里包含了接受和发送数据报的应用程序的Port，这样，通过IP和端口就能唯一确认一条TCP/IP连接。下面详细说明：

Source Port 长度8位

       发送数据报的节点的端口号，8位长度最大的Port是65535，当节点发送数据报的时候会随机产生一个Port号用来与ftp服务器连接，在windows中，这个随机产生的号码在1024和4000之间，大于4000可以说明不是windows系统生成的，1024以下的Port是常用Port不能随便占用。

Destination port 长度8位

       接受数据报的节点的端口号，ftp会开放Port 21用来和接受控制命令，当传送数据的时候，FTP Server会自动打开Port 20通过该端口传送，当然，客户端也会被动打开一个端口用来接受数据。如果在某些条件下，把ftp控制端口定为X，那么要注意数据端口默认就是X-1，因此在设定的时候不要冲突。

Sequence Number 长度32位

       第一次传送的时候会随机生成一个序号，随后用这个序号表示字节位置。

Ack Number长度32位

       响应序号，用来纪录希望下次得到的数据的字节开始位置，这个位置的计算是通过得到的Seq number加上报文的长度，就可以知道期望下次传送的报文的起始位置了，第一次传送的时候由于没有收到过任何报文，所以不能知道期望下次收到什么，所以ack numbe为0。

Header length 长度4位

       本例中记录5，表示20个字节。计算方法和作用同IP报头。

Reserved 长度6位

       保留字段。

Flags 长度6位

       依次是URG、ACK、PSH、RST、SYN、FIN位。

       URG紧急指针有效，如果该位为1，那么后面的Urgent Pointer有效。

       ACK如果该位为1，表示该响应信息包里面有响应确认的信息，即ack number不为0。

PSH 推进标志位，要求发送方的TCP协议立即将所有数据发给底层协议，或者要求接受方将其所有数据立即交给上层协议。

RST 将传输层连接复位到它的初始状态，用于将错误回复到正确状态。

SYN 用来表明此信息包的序号为ISN，而不是一般的序号。ISN是在连接开始的时候随即选取的一个初始序号。连接开始建立的时候，双方的第一个IP数据报中都会把此位置1。

FIN 传输完毕的标志位。由于本例只是记录了登陆成功的帧，没有记录断开连接的帧，所以没有这个位置为1的帧。

Window Size 长度16位

       由于数据报的传送是双向的，所以这个字段记录了发送方可用来接受数据的字节数目，是用来完成流量的控制的。

Checksum 长度16位

       报头检验，同IP报头的检验。

Urgent pointer 长度16位

       如果URG被标示为1，说明包含紧急信息，那么这个字段就纪录一个偏移量，这个偏移量加上这个TCP Header中的Seq Number就可以得到紧急信息数据的最后一个字节。

TCP Options 长度可变

       TCP选项，长度不固定。填充原理和IP Header填充一样。


       通过比较多组登陆ftp操作获得的Cap文件（每组都使用相同的物理设备和相同的用户登陆，产生11个帧）发现每组中对应帧[所谓对应帧指的是第一组中的第一帧和第n组中的第一帧比较] 的MAC Header都是不变的，这是因为物理设备保持不变，同时都是IP数据报。IP Header中除Identification、Check Sum、本机端口外所有数据一样。TCP Header中除Seq Number、Ack Number、Check Sum外所有数据都一样，从上面的分析可以知道，这些不同数据的产生是必然的，并且不会对分析产生影响。


       在帧4、6、7、9、10中，Ftp Data包含内容。所有信息都是没有加密过的明文。

       服务器在第4帧做出的Response code为220表示Service ready for new user，显示IIS FTP的欢迎语句。

       第六帧用户发出访问控制命令USER，并且提供了用户名ftp。

       第七帧服务器做出的Response code为331 User name okay, need password.，提示用户名正确等待密码，并且显示Anonymous access allowed, send identity (e-mail name) as password。

       第九帧用户发出访问控制命令PASS，并且提供了密码“”。

       第十帧服务器做出的Response code为230 User logged in, proceed.，并且显示Anonymous user logged in，到此完成一次登陆。

FTP DATA不为空的都是用0D 0A结尾表示回车。


环境变化：

本机IP：192.168.30.40->192.168.30.41

FTP IP： 192.168.30.7->192.168.30.8

FTP MAC：00 0A EB 09 BC BB->00 60 B0 6C 03 FE

结果变化：

相同字节数目：706->728 增长22个。

相同字节增长的原因：本次试验一共采集了8个Cap包，每个包中有11个帧，本次帧和第一次试验得到的帧比较发现，对应位置的IP和MAC地址产生了变化，本机随机生成的Port也发生了变化，但是这些变化并没有影响相同字节的数量。影响相同字节数量的变化是由于IP Header中的Identification和checksum变化引起的，同过比较得知，这次试验中每个包中对应的帧的IP Header部分的Identification的高8位是相同的，同时checksum的高8位也是相同的。但是第一次试验中这两个字段是不同的，所以本次试验和上次试验比较每个帧的相同字节增加16位，也就是2个字节。由于一个包中有11个字节，所以本次试验比上次试验增加了2*11=22个相同字节。