当前位置:网站首页>全网最全tcpdump和Wireshark抓包实践
全网最全tcpdump和Wireshark抓包实践
2022-07-06 09:34:00 【唐僧骑白马】
tcpdump和Wireshark抓包实践
1、wireshark基本使用
1.1、如何捕获报文
- 点击捕获——>选项,打开捕获窗口
- 网卡设备/流量/捕获过滤器,点击“开始”按钮开始抓包
- 输出(指定缓存文件)/选项(显示、名称解析、自动停止抓包条件) 面板
- 点击捕获——>停止,停止抓包
1.2、Wireshark 面板
1.3、快捷方式工具栏
##1.4、数据包的颜色(视图->着色规则)
1.5、设定时间显示格式
1.6、数据包列表面板的标记符号
1.7、文件操作
- 标记报文 Ctrl+M
- 导出标记报文(文件->导出特定分组),亦可按过滤器导出报文
- 合并读入多个报文(文件->合并)
##1.8、如何快速抓取移动设备的报文?
- 在操作系统上打开 wifi 热点
- 手机连接 wifi 热点
- 用 Wireshark 打开捕获——>选项面板,选择 wifi 热点对应的接口设备抓包
1.9、抓包文件常见几种类型
- pcap
这个是 libpcap 的格式,也是 tcpdump 和 Wireshark 等工具默认支持的文件格式。pcap 格式的文件中除了报文数据以外,也包含了抓包文件的元信息,比如版本号、抓包时间、每个报文被抓取的最大长度,等等。
- capcap
文件可能含有一些 libpcap 标准之外的数据格式,它是由一些 tcpdump 以外的抓包程序生成的。比如 Citrix 公司的 netscaler 负载均衡器,它的 nstrace 命令生成的抓包文件,就是以.cap 为扩展名的。这种文件除了包含 pcap 标准定义的信息以外,还包含了 LB 的前端连接和后端连接之间的 mapping 信息。Wireshark 是可以读取这些.cap 文件的,只要在正确的版本上。
- pcapng
pcap 格式虽然满足了大部分需求,但是它也有一些不足。比如,现在多网口的情况已经越来越常见了,我们也经常需要从多个网络接口去抓取报文,那么在抓包文件里,如果不把这些报文跟所属的网口信息展示清楚,那我们的分析,岂不是要张冠李戴了吗?
为了弥补 pcap 格式的不足,人们需要有一种新的文件格式,pcapng 就出现了。有了它,单个抓包文件就可以包含多个网络接口上,抓取到的报文了。
1.10、解析https报文,TSL报文
在用户环境变量新建一个SSLKEYLOGFILE变量,然后填写一个日志文件
重启浏览器,打开wireshark,编辑——>首选项——>Protocols——>TLS,填写环境变量里面编写的文件路径,然后重新打开wireshark即可生成环境变量里的文件(不需要新建这个文件,打开wireshark会自动生成)
自动生成的文件
1.11、wireshark Expert Information信息详解
- Warning 条目的底色是黄色,意味着可能有问题,应重点关注。
- Note 条目的底色是浅蓝色,是在允许范围内的小问题,也要关注。什么叫“允许范围内的小问题”呢?举个例子,TCP 本身就是容许一定程度的重传的,那么这些重传报文,就属于“允许范围内”。
- Chat 条目的底色是正常蓝色,属于 TCP/UDP 的正常行为,可以作为参考。比如你可以了解到,这次通信里 TCP 握手和挥手分别有多少次,等等。
上图展示的就是客户端抓包文件的情况,我们逐个来解读这三种不同级别的 Severity(严重级别)。 - Warning:有 7 个乱序(Out-of-Order)的 TCP 报文,6 个未抓到的报文(如果是在抓包开始阶段,这种未抓到报文的情况也属正常)。
- Note:有 1 个怀疑是快速重传,5 个是重传(一般是超时重传),6 个重复确认。
- Chat:有 TCP 挥手阶段的 20 个 FIN 包,握手阶段的 10 个 SYN 包和 10 个 SYN+ACK 包。
1.12、wireshark常用过滤器
ip.addr eq my_ip:过滤出源IP或者目的IP为my_ip的报文
ip.src eq my_ip:过滤出源IP为my_ip的报文
ip.dst eq my_ip:过滤出目的IP为my_ip的报文
tcp.seq eq 1 and tcp.ack eq 1 RST 的序列号是 1,确认号也是 1
frame.time >="dec 01, 2015 15:49:48" and frame.time <="dec 01, 2015 15:49:49" #frame.time 过滤器
frame.time >="dec 01, 2015 15:49:48" and frame.time <="dec 01, 2015 15:49:49" and ip.addr eq 10.255.252.31 and tcp.flags.reset eq 1 and !(tcp.seq eq 1 or tcp.ack eq 1)
# 对于 RST 报文,过滤条件就是
tcp.flags.reset eq 1
ip.addr eq 10.255.252.31 and tcp.flags.reset eq 1
下面这个过滤器,就可以找到含有这个字符串的报文:
tcp contains "id=abcdafeafeagfeagfaraera1242dfea"
frame contains "id=abcdafeafeagfeagfaraera1242dfea"
ip contains "id=abcdafeafeagfeagfaraera1242dfea"
http contains "id=abcdafeafeagfeagfaraera1242dfea"
tcp.len eq 长度
tcp.flags.fin eq 1
tcp.flags.reset eq 1
tcp.payload eq 数据
利用各层的 contains 动词来写过滤器。比如:
# 应用层可以是 http contains "abc"
# 传输层可以是 tcp contains "abc"
# 网络层可以是 ip contains "abc"
# 数据链路层可以是 frame contains "abc"
1.13、设置裸序列号
打开wireshark,编辑——>首选项——>Protocols——>tcp,把“Relative sequence numbers”前面的勾去掉,就可以显示裸序列号了:
用 TCP 确认号,比如下面这个过滤器:
tcp.ack_raw == 754313633
1.14、TTL 详解
TTL 是 IP 包(网络层)的一个属性,字面上就差不多是生命长度的意思,每一个三层设备都会把路过的 IP 包的 TTL 值减去 1。而 IP 包的归宿,无非以下几种:
- 网络包最终达到目的地;
- 进入路由黑洞并被丢弃;
- 因为网络设备问题被中途丢弃;
- 持续被路由转发并 TTL 减 1,直到 TTL 为 0 而被丢弃。
不同的操作系统其初始 TTL 值不同,一般来说 Windows 是 128,Linux 是 64。由此,我们就可以做一些快速的判断了。
假如百度服务端是 Windows,那么 Windows 类系统一般 TTL 为 128,减去 52,得到 76。那就意味着这个回包居然要途经 76 个三层设备,这显然就违背常识了,所以反证这个百度服务端不会是 Windows。这就是我想说的第一点:TTL 的值是反映了网络路径跳数的,也可以通过它间接推导出对端的 OS 类型。
第二点:内网同一个连接中的报文,其 TTL 值一般不会变化。
你也能很清楚地看到,同样的服务端,在三次握手中(SYN+ACK 报文)的 TTL 是 59,在导致连接中断的 RST 包里却变成了 64!显然,这个 RST 包并不是跟我们握手的那个服务端发出的,否则 TTL 值就不会变化。发出这个包的会是谁呢?
其实,一般就是防火墙设备。由于防火墙也遵循 IP 协议,而这里的 TTL 值是 64,这就说明这个防火墙跟客户端之间没有别的三层环节,或者说是三层直连的。
1.15、重复确认(DupAck)
重复确认在 TCP 里面有很重要的价值,它的出现,一般意味着传输中出现了丢包、乱序等情况。我们来看看这两个重复确认报文的细节。
1.16、Flow Graph
你可以这样找到它:点开 Statistics 菜单,在下拉菜单中找到 Flow Graph,点击它,就可以看到这个抓包文件的“二维图”了。不过,因为我们要查看的是过滤出来的 TCP 流,而 Flow Graph 只会展示抓包文件里所有的报文,所以,我们需要这么做:先把过滤出来的报文,保存为一个新的抓包文件;然后打开那个新文件,再查看 Flow Graph。
上图读起来,是不是感觉信息量要比主界面要多一些?特别是有了左右方向箭头,给我们大脑形成了“第二个维度”,报文的流向可以直接看出来,而不再去看端口或者 IP 去推导出流向了。
1.17、I/O Graph
这个工具在 Statistics 下拉菜单中,I/O Graph
点击 I/O Graph 后,Wireshark 会弹出一个趋势图,其 X 轴是时间,Y 轴是性能指标:
注意,这时的图是不准确的,所以我们需要做一些调整。既然我们关注传输速度,所以就选择 All Bytes 这个指标项(也是默认选中的那项)作为 Y 轴,然后修改它的计量单位。很可能你的 Wireshark 默认选中的是 AVG(Y Field),而这并不是我们要关注的字节数。我们可以双击 AVG(Y Field) 进入编辑模式,把它改为 Bytes:
你可能也注意到了,在 X 时间轴上看,一开始几秒速度比较低,第 7 秒才达到 400KB/s 以上。为什么一开始速度这么低呢?其实,这正是 TCP 慢启动的一个缩影:初始阶段,速度是特别低的,但是会很快爬高。
1.18、TCP Stream Graphs
还是到 Statics 下拉菜单,选择 TCP Stream Graphs,在子菜单中选择 Time sequence (Stevens)。
然后就能看到时间为 X 轴、TCP 序列号为 Y 轴的图了。你应该知道,序列号其实就等于字节数,那么显然,这里这条线的斜率也就是传输速率了。
我们可以自己计算这个斜率(速率) 是多少。比如可以计算 10 秒和 40 秒两处的序列号的差距,再除以 (40-10) 秒,就是速率了。10 秒处的序列号是 2800092,40 秒处是 16480292,那么速率就是 (16480292-2800092)/(40-10)=456KB/s。
你可能发现了,两个 Graph 算出来的速度怎么有点差异?一个是 480KB/s 左右,一个是 456KB/s,相差有 5% 左右。
其实,这是正常的。因为 I/O Graph 统计的 Bytes 是二层帧的大小,而 TCP Stream Graphs 关注的是四层 TCP 段的大小。后者比前者少了二层到四层的头部。严格来说,TCP Stream Graphs 的斜率,只是 TCP payload 的速率;而 I/O Graph 展示的,才是我们一般谈论的传输速度。当然,在定性的讨论中,这点差异是可以忽略的
2、如何抓取报文?
用 tcpdump 抓取报文,最常见的场景是要抓取去往某个 ip,或者从某个 ip 过来的流量。我们可以用 host {对端 IP} 作为抓包过滤条件,比如:
tcpdump host 10.10.10.10
另一个常见的场景是抓取某个端口的流量,比如,我们想抓取 SSH 的流量,那么可以这样:
tcpdump port 22
还有不少参数我们也经常用到,比如:
-w 文件名,可以把报文保存到文件;
-i,指定抓包网卡
-r,读取抓包文件
c 数量,可以抓取固定数量的报文,这在流量较高时,可以避免一不小心抓取过多报文;
-s 长度,可以只抓取每个报文的一定长度,后面我会介绍相关的使用场景;
-n,不做地址转换(比如 IP 地址转换为主机名,port 80 转换为 http);
-v/-vv/-vvv,可以打印更加详细的报文信息;
-e,可以打印二层信息,特别是 MAC 地址;
-p,关闭混杂模式。所谓混杂模式,也就是嗅探(Sniffering),就是把目的地址不是本机地址的网络报文也抓取下来。
-X, 有时候你想看 TCP 报文里面的具体内容,比如应用层的数据,那么你可以用 -X 这个参数,以 ASCII 码来展示 TCP 里面的数据
$ sudo tcpdump port 80 -X
......
05:06:57.394573 IP _gateway.52317 > victorebpf.http: Flags [P.], seq 1:17, ack 1, win 65535, length 16: HTTP: GET / HTTP/1.1
0x0000: 4500 0038 282d 0000 4006 3a83 0a00 0202 E..8(-..@.:.....
0x0010: 0a00 020f cc5d 0050 0502 3a02 3ed1 3771 .....].P..:.>.7q
0x0020: 5018 ffff 4421 0000 4745 5420 2f20 4854 P...D!..GET./.HT
0x0030: 5450 2f31 2e31 0d0a TP/1.1..
读取抓包文件也可以使用-X参数
[[email protected] ~]# tcpdump -r 1201.pcap -X
reading from file 1201.pcap, link-type EN10MB (Ethernet)
03:19:38.035436 IP localhost.localdomain.http > 192.168.192.120.47958: Flags [R.], seq 0, ack 3193167715, win 0, length 0
0x0000: 4510 0028 0000 4000 4006 3888 c0a8 c06e E..(..@[email protected]....n
0x0010: c0a8 c078 0050 bb56 0000 0000 be53 df63 ...x.P.V.....S.c
0x0020: 5014 0000 543a 0000 P...T:..
03:19:38.998385 IP localhost.localdomain.http > 192.168.192.120.47962: Flags [R.], seq 0, ack 4061809141, win 0, length 0
0x0000: 4510 0028 0000 4000 4006 3888 c0a8 c06e E..(..@[email protected]....n
0x0010: c0a8 c078 0050 bb5a 0000 0000 f21a 49f5 ...x.P.Z......I.
0x0020: 5014 0000 b5dd 0000 P.......
3、如何读取抓包文件?
tcpdump 加上 -r 参数和文件名称,就可以读取这个文件了,而且也可以加上过滤条件。比如:
tcpdump -r file.pcap 'tcp[tcpflags] & (tcp-rst) != 0'
4、如何过滤报文?
tcp 标记值有 tcp-fin, tcp-syn, tcp-rst, tcp-push, tcp-push, tcp-ack, tcp-urg
# 过滤出 TCP RST 报文
tcpdump -w file.pcap 'tcp[tcpflags]&(tcp-rst) != 0'
# 用偏移量的写
tcpdump -w file.pcap 'tcp[13]&4 != 0'
5、如何过滤后转存?
有时候,我们想从抓包文件中过滤出想要的报文,并转存到另一个文件中。比如想从一个抓包文件中找到 TCP RST 报文,并把这些 RST 报文保存到新文件。那么就可以这么做:
tcpdump -r file.pcap 'tcp[tcpflags] & (tcp-rst) != 0' -w rst.pcap
6、如何让抓包时间尽量长一点?
前面我提到过 -s 这个长度参数,它的使用场景其实就包括了延长抓包时间。我们给 tcpdump 加上 -s 参数,指定抓取的每个报文的最大长度,就节省抓包文件的大小,也就延长了抓包时间。
一般来说,帧头是 14 字节,IP 头是 20 字节,TCP 头是 20~40 字节。如果你明确地知道这次抓包的重点是传输层,那么理论上,对于每一个报文,你只要抓取到传输层头部即可,也就是前 14+20+40 字节(即前 74 字节):
tcpdump -s 74 -w file.pcap
而如果是默认抓取 1500 字节,那么生成的抓包文件将是上面这个抓包文件的 20 倍。反过来说,使用同样的磁盘空间,上面这种方式,其抓包时间可以长达默认的 20 倍!
7、怎么知道抓包文件是在哪一端抓取的?
这是一个有趣的问题。尽管我们做抓包的时候很清楚是在哪端做了抓包,但是把文件传给别人后,对方就未必知道这一点,甚至我们自己过段时间也迷糊了:我上次这个抓包文件到底是在客户端上,还是服务端上抓取的?
要搞清楚这一点也很简单,我们可以利用 IP 的 TTL 属性。显然,无论是哪一端,它的报文在发出时,其 TTL 就是原始值,也就是 64、128、255 中的某一个。而对端报文的 TTL,因为会经过若干个网络跳数,所以一般都会比 64、128、255 这几个数值要小一些。
所以,我们只要看一下抓包文件中任何一个客户端报文(也就是源端口为高端口)的 TTL,如果它是 64、128 或 255,那说明这个抓包文件就是在客户端做的。反之,就是在服务端做的。
8、如何定位到应用层的请求和返回的报文?
在众多报文中找到应用层请求和对应的响应报文,这个任务用人工去做的话是很繁琐的。还好,用 Wireshark 就很方便。在 Wireshark 界面中,我们很容易找到请求和返回的报文。比如这样:
我们只要选中请求报文,Wireshark 就会自动帮我们匹配到对应的响应报文,反过来也一样。从图上看,应用层请求(这里是 HTTP 请求)是一个向右的箭头,表示数据是进来的方向;应用层响应是一个向左的箭头,表示数据是出去的方向。
9、数据包乱序一定会引起问题吗?
乱序(Out-of-Order),也是我们时常能在 Wireshark 里看到的一类现象。那么,乱序一定会引起问题吗?有一句话叫“脱离了剂量谈毒性就是耍流氓”。其实,乱序是否是问题,也取决于乱序的严重程度。
那第二个问题随之就来了:乱序包达到什么程度,就会真的引起问题?
这个问题,跟实际场景的具体情况也有很大的关系,不同的操作系统以及 TCP 实现细节,都可能有挺大的差异。不过,我还是想正面回答一下这个问题。我的经验是,如果乱序报文达到 10% 以上,就是严重的传输质量问题了,甚至可能导致传输失败,或者应用层的各种卡顿、报错等症状。所以,你可以统计一下乱序包的占比,如果它超过了 10%,就要重视了。
边栏推荐
猜你喜欢
03 products and promotion developed by individuals - plan service configurator v3.0
06个人研发的产品及推广-代码统计工具
Wu Jun's trilogy insight (V) refusing fake workers
03个人研发的产品及推广-计划服务配置器V3.0
集成开发管理平台
07 personal R & D products and promotion - human resources information management system
Connect to LAN MySQL
1. Introduction to JVM
Coursera cannot play video
信息与网络安全期末复习(完整版)
随机推荐
【逆向】脱壳后修复IAT并关闭ASLR
Set up the flutter environment pit collection
JUnit unit test
Akamai talking about risk control principles and Solutions
MySQL date function
Koa Middleware
MySQL报错解决
Introduction to spring trick of ByteDance: senior students, senior students, senior students, and the author "brocade bag"
Total / statistics function of MySQL
轻量级计划服务工具研发与实践
Flink 解析(三):内存管理
MySQL digital function
Flink 解析(一):基础概念解析
Activiti directory (V) reject, restart and cancel process
TCP's three handshakes and four waves
MySQL advanced (index, view, stored procedure, function, password modification)
唯有學C不負眾望 TOP5 S1E8|S1E9:字符和字符串&&算術運算符
JVM garbage collection overview
Flink 解析(六):Savepoints
Activiti directory (IV) inquiry agency / done, approved