通过tcpdump分析TCP报文(1)

第一部分,先熟悉一下tcpdump的基本使用对一个普通的TCP数据报文进行分析


tcpdump的基本使用

常用参数:
参考:https://blog.51cto.com/nickfox/2089655
-i 指定监听的网络接口
-nn IP和端口均以数字形式显示
-c 在收到指定的数量的分组后,tcpdump停止,如果没有这个参数,tcpdump会持续不断的监听直到用户输入 [ctrl]-c 为止
-e 输出数据链路层的头部信息(显示MAC地址相关信息)。
-t 在输出的每一行不打印时间戳
-q 只输出较少的协议信息(仅输出协议名称,如TCP;而不输出封包标记信息,如F、P等标记)

-w FILE直接将分组写入文件中,而不是到stdout
-r FILE从后面接的文件将数据包数据读出来。那个「文件」是已经存在的文件,并且这个「文件」是由 -w 所制作出来的
-s 设置tcpdump的数据包抓取长度为len,如果不设置默认将会是65535字节。对于要抓取的数据包较大时,长度设置不够可能会产生包截断,若出现包截断,输出行中会出现"[|proto]“的标志(proto实际会显示为协议名)。但是抓取len越长,包的处理时间越长,并且会减少tcpdump可缓存的数据包的数量,从而会导致数据包的丢失,所以在能抓取我们想要的包的前提下,抓取长度越小越好(-s 0 使用默认长度65535)。
-D 列出可用于抓包的接口。将会列出接口的数值编号和接口名,它们都可以用于”-i"后
-L 列出网络接口的已知数据链路。
-F 从文件中读取抓包的过滤表达式。若使用该选项,则命令行中给定的其他表达式都将失效。

-A 数据包的内容以 ASCII 显示,通常用来捉取WWW的网页数据包资料
-X 数据包内容以十六进制 (hex)和ASCII显示,对于监听数据包内容很有用
-XX 比-X输出更详细


我这里使用的抓包设备是树莓派,先用上述的-D/-L参数,查看下当前环境的基本信息。

  1. sudo tcpdump -D:
    在这里插入图片描述
    我的设备当前使用的是wifi连接,所以第一个是wlan0,如果抓包的时候没有使用 -i 指定接口,默认抓第一个接口的包。
  2. sudo tcpdump -L:
    在这里插入图片描述
    链路类型,Ethernet,所以二层头是下面这样
    在这里插入图片描述

测试环境
再用我windows下写过的一个socket实例和树莓派建立一次tcp连接试一下抓包。
socket实例是这篇文章里写过的,可以直接拿来使用:https://blog.csdn.net/qq_25453065/article/details/79827715
linux 请求socket连接,可以通过操作文件描述符实现,它要指向linux的特殊文件:/dev/tcp/hostname/port。

下面操作一下:
windows 这一端
直接打开实例,随便输入一个1024以上的端口号,点击Listen按钮,下面状态信息编程侦听状态即可。这台设备局域网ip是192.168.2.101
在这里插入图片描述
树莓派这一端
创建文件描述符7,模式是输入和输出,所以是<>。因为windows的ip是192.168.2.101,同时侦听的是2345端口,所以命令写成下面这个样子:
exec 7<> /dev/tcp/192.168.2.101/2345
之后对这个连接的写入和读取操作,都可以通过描述符7来实现。
之后用 cat <&7 命令读取了信息,因为windows那一端,我写的是只要有客户端上线,就会自动由服务器向所有在线的客户端广播上线信息,所以会收到这条消息。
在这里插入图片描述
在这里插入图片描述
上线即广播消息的对应实现代码:
在这里插入图片描述


对一个普通的TCP数据报文进行分析

确认连接没有问题,用tcpdump抓一个简单的报文来分析一下。
由于我这里树莓派是在windows上用VNC连接的,所以两台设备之间的报文往来会很多,所以,我们不能基于hostname抓包,直接基于port抓包比较好。所以第一步是查出来建立连接所使用的端口,这个是随机分的,不能预先知道。
第一步,查端口的方法,也比较简单,因为建立tcp连接的会先进行三次握手,这里进行握手的时候,报文携带的SYN标记就是一个很好的过滤条件,最后查出树莓派这端用来发起连接请求的端口号是56412。
在这里插入图片描述
第二步,基于端口号56412抓包。使用了-e和-XX两个参数,为了尽可能详细的分析报文,还使用了-S,是为了ack显示实际值,而不是相对值。敲完命令,在windows端发送一个消息,Server:hello!。此时就可以在树莓派上抓到两个包,一个是来自server的消息,一个是从本端发出的应答消息。
在这里插入图片描述
在这里插入图片描述
我们先分析第一个报文,也就是来自server的消息报文。


1.先看二层头部:
二层头,由这三部分组成,与帧格式对应。
在这里插入图片描述
也就是说目的mac是b8-27-eb-e6-1c-6b,源mac是a0-c5-89-55-f0-14,Type是0800。
目的mac对应的是树莓派的网卡地址,源mac是电脑的网卡地址。type根据不同的值,代表之后紧接着的头部是不同的协议,0800代表的是后面是IPV4报文

在这里插入图片描述
Type对应的含义:
在这里插入图片描述
对于遵守TCP/IP协议的设备来说,收到这样一个报文,先解析目的mac是不是自己的,如果不是,则直接丢弃,如果是,则剥掉二层头,暴露出三层头,然后上送对应的三层协议栈处理。


2.再看三层头部:
三层头,这里一共是20字节。
在这里插入图片描述
对应IP头格式来看,
Version:0x4,IHL:0x5,
所以这是一个IPV4报文,同时IP头长度是5个UINT32,也就是20字节。

Total Length:0x37 = 55(DEC)
55字节是从IP头开始之后的报文总长度,IP头占了20,也就是说后面的TCP头+data一共35字节。

Identification + Flags + Fragment Offset:0x728c4000
这一行是分片时才会起作用的字段,这里报文长度太短,达不到MTU,暂不分析。

Time to Live: 0x80,Protocol:0x06,Header CheckSum:0x0262
TTL是0x80,也就是256,这个值只有在经过一个路由器时,才减一。我的两个设备在同一个局域网下,相当于二层互通,所以根本用不上路由器转发,这个值就是初始值,没有减一过。
Protocol是6代表下一层协议是TCP。
校验和,为了检验纠错使用,暂不分析。

Source Address:0xc0a80265,Destination Address:0xc0a8021d
源IP和目的IP,转为点分十进制表示:即为192.168.2.101 和 192.168.2.29
在这里插入图片描述
protocl字段对应的含义:
在这里插入图片描述


3.再来是四层头
这里的tcp头部也是20字节,没有扩展字段
在这里插入图片描述
Source Port:0x0929,Destination Port:0xdc5c
源端口号0x929 = 2345(DEC),目的端口号0xdc5c = 56412(DEC),对应我们建立TCP连接所使用的端口号。

Sequence Number:0xbf05ba26,Acknowledgment Number:0xda14ece3
seqNumber是报文的发送方发送的报文序列号,每发送一个就加一。
AckNumber是报文的发送方请求应答方发送的报文序列号。

Dataoffset:0x5,Reserved(6 Bits): 000000,Flag(6Bits):0x18 = 011000,Window:0x0100
dataoffset表示tcp头部长度是5个UINT32,也就是20字节,跟IP头部的IHL类似。
Reserved必须填0,保留字段,暂时没用,可能后续会有扩展的用途吧
Flag有6个bit,下一篇文章再详述。
Window相当于就是接收方的当前缓冲区大小,指明了能够一次接收多少字节的报文。

Checksum:0x4fde,Urgent Pointer:0x0000
checksum是与ip头中的header checksum功能类似,校验用
Urgent Pointer配合URG标记置一才会有用处。
在这里插入图片描述


4.最后是data
在这里插入图片描述
直接用utf-8编码方式来解析对应data
0x5365727665723a2068656c6c6f210a
在这里插入图片描述
可以直接解析出具体的内容。所以说在网络中明文传输,很危险的。。


这篇总结借助tcpdump比较详细的分析了一个普通的数据报文他的组成以及各个字段的含义。下一篇用tcpdump抓一下tcp的握手和挥手报文,总结分析其中的过程。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章