tcpdump抓包分析详解

tcpdump抓包分析详解
[root@linux ~]# tcpdump [-nn] [-i 接口] [-w 储存档名] [-c 次数] [-Ae][-qX] [-r 档案] [所欲撷取的数据内容]
参数：
-nn：直接以IP 及port number 显示，而非主机名与服务名称
-i ：后面接要『监听』的网络接口，例如eth0, lo, ppp0 等等的界面；
-w ：如果你要将监听所得的封包数据储存下来，用这个参数就对了！后面接档名
-c ：监听的封包数，如果没有这个参数，tcpdump 会持续不断的监听，直到使用者输入[ctrl]-c 为止。

-A ：封包的内容以ASCII 显示，通常用来捉取WWW 的网页封包资料。

-e ：使用资料连接层(OSI 第二层) 的MAC 封包数据来显示；
-q ：仅列出较为简短的封包信息，每一行的内容比较精简
-X ：可以列出十六进制(hex) 以及ASCII 的封包内容，对于监听封包内容很有用
-r ：从后面接的档案将封包数据读出来。

那个『档案』是已经存在的档案，并且这个『档案』是由-w 所制作出来的。

所欲撷取的数据内容：我们可以专门针对某些通讯协议或者是IP 来源进行封包撷取，
那就可以简化输出的结果，并取得最有用的信息。

常见的表示方法有：
'host foo', 'host 127.0.0.1' ：针对单部主机来进行封包撷取
'net 192.168' ：针对某个网域来进行封包的撷取；
'src host 127.0.0.1' 'dst net 192.168'：同时加上来源(src)或目标(dst)限制
'tcp port 21'：还可以针对通讯协议侦测，如tcp, udp, arp, ether 等
还可以利用and 与or 来进行封包数据的整合显示呢！
范例一：以IP 与port number 捉下eth0 这个网络卡上的封包，持续 3 秒[root@linux ~]# tcpdump -i eth0 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
01:33:40.41 IP 192.168.1.100.22 > 192.168.1.11.1190: P 116:232(116) ack 1 win 9648
01:33:40.41 IP 192.168.1.100.22 > 192.168.1.11.1190: P 232:364(132) ack 1 win 9648
<==按下[ctrl]-c 之后结束
6680 packets captured <==捉下来的封包数量
14250 packets received by filter <==由过滤所得的总封包数量
7512 packets dropped by kernel <==被核心所丢弃的封包
如果你是第一次看tcpdump 的man page 时，肯定一个头两个大，因为tcpdump 几乎都是分析封包的表头数据，用户如果没有简易的网络封包基础，要看懂粉难吶！所以，至少您得要回到网络基础里面去将TCP 封包的表头数据理解理解才好啊！^_^！至于那个范例一所产生的输出范例中，我们可以约略区分为数个字段，我们以范例一当中那个特殊字体行来说明一下：
01:33:40.41：这个是此封包被撷取的时间，『时:分:秒』的单位；
IP：透过的通讯协议是IP ；
192.168.1.100.22 > ：传送端是192.168.1.100 这个IP，而传送的port number 为22，您必须要了解的是，那个大于(>) 的符号指的是封包的传输方向喔！192.168.1.11.1190：接收端的IP 是192.168.1.11，且该主机开启port 1190 来接收；
P 116:232(116)：这个封包带有PUSH 的数据传输标志，且传输的数据为整体数据的116~232 byte，所以这个封包带有116 bytes 的数据量；
ack 1 win 9648：ACK与Window size 的相关资料。

最简单的说法，就是该封包是由192.168.1.100 传到192.168.1.11，透过的port 是由22 到1190 ，且带有116 bytes 的数据量，使用的是PUSH 的旗标，而不是SYN 之类的主动联机标志。

呵呵！不容易看的懂吧！所以说，上头才讲请务必到TCP 表头数据的部分去瞧一瞧的啊！
再来，一个网络状态很忙的主机上面，你想要取得某部主机对你联机的封包数据而已时，使用tcpdump 配合管线命令与正规表示法也可以，不过，毕竟不好捉取！我们可以透过tcpdump 的表示法功能，就能够轻易的将所需要的数据独立的取出来。

在上面的范例一当中，我们仅针对eth0 做监听，所以整个eth0 接口上面的数据都会被显示到屏幕上，不好分析啊！那么我们可以简化吗？例如只取出port 21 的联机封包，可以这样做：
[root@linux ~]# tcpdump -i eth0 -nn port 21
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
01:54:37.96 IP 192.168.1.11.1240 > 192.168.1.100.21: . ack 1 win 65535
01:54:37.96 IP 192.168.1.100.21 > 192.168.1.11.1240: P 1:21(20) ack 1 win 5840 01:54:38.12 IP 192.168.1.11.1240 > 192.168.1.100.21: . ack 21 win 65515
01:54:42.79 IP 192.168.1.11.1240 > 192.168.1.100.21: P 1:17(16) ack 21 win 65515 01:54:42.79 IP 192.168.1.100.21 > 192.168.1.11.1240: . ack 17 win 5840
01:54:42.79 IP 192.168.1.100.21 > 192.168.1.11.1240: P 21:55(34) ack 17 win 5840 这样就仅提出port 21 的信息而已，且仔细看的话，你会发现封包的传递都是双向的，client 端发出『要求』而server 端则予以『响应』，所以，当然是有去有回啊！而我们也就可以经过这个封包的流向来了解到封包运作的过程。

举例来说：
我们先在一个终端机窗口输入『tcpdump -i lo -nn 』的监听，
再另开一个终端机窗口来对本机(127.0.0.1) 登入『ssh localhost』
那么输出的结果会是如何？
[root@linux ~]# tcpdump -i lo -nn
1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
2 listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
3 11:02:54.253777 IP 127.0.0.1.32936 > 127.0.0.1.22: S 933696132:933696132(0)
win 32767 <mss 16396,sackOK,timestamp 236681316 0,nop,wscale 2>
4 11:02:54.253831 IP 127.0.0.1.22 > 127.0.0.1.32936: S 920046702:920046702(0)
ack 933696133 win 32767 <mss 16396,sackOK,timestamp 236681316 236681316,nop,
wscale 2>
5 11:02:54.253871 IP 127.0.0.1.3293
6 > 127.0.0.1.22: . ack 1 win 8192 <nop,
nop,timestamp 236681316 236681316>
6 11:02:54.272124 IP 127.0.0.1.22 > 127.0.0.1.32936: P 1:23(22) ack 1 win 8192
<nop,nop,timestamp 236681334 236681316>
7 11:02:54.272375 IP 127.0.0.1.32936 > 127.0.0.1.22: . ack 23 win 8192 <nop,
nop,timestamp 236681334 236681334>
上表显示的头两行是tcpdump 的基本说明，然后：
第3 行显示的是『来自client 端，带有SYN 主动联机的封包』，
第4 行显示的是『来自server 端，除了响应client 端之外(ACK)，还带有SYN 主动联机的标志；
第5 行则显示client 端响应server 确定联机建立(ACK)
第6 行以后则开始进入数据传输的步骤。

如果我们使用tcpdump 在router 上监听『明码』的传输数据，例如FTP 传输协议，我们先在主机端下达『tcpdump -i lo port 21 -nn -X 』然后再以ftp 登入本机，并输入账号与密码，结果你就可以发现如下的状况：
[root@linux ~]# tcpdump -i lo -nn -X 'port 21'
0x0030: 0e2e 0b61 3232 3020 2876 7346 5450 6420 ...a220.(vsFTPd.
0x0030: 0e2e 0b67 5553 4552 2064 6d74 7361 690d ...gUSER.dmtsai.
0x0030: 0e2e 1b38 5041 5353 206d 7970 6173 7377 ...8PASS.mypassw
上面的输出结果FTP 软件使用的是vsftpd ，并且使用者输入dmtsai 这个账号名称，且密码是mypasswordisyou
为了让网络接口可以让tcpdump 监听，所以执行tcpdump 时网络接口会启动在『错乱模式(promiscuous)』，所以你会在/var/log/messages 里面看到很多的警告讯息，通知你说你的网络卡被设定成为错乱模式！别担心，那是正常的。

至于更多的应用，请参考man tcpdump
例题：如何使用tcpdump 监听(1)来自eth0 适配卡且(2)通讯协议为port 22 ，(3)目标来源为192.168.1.100 的封包资料？
答：tcpdump -i eth0 -nn 'port 22 and src host 192.168.1.100'
arp故障
故障现象：局域网中的一台采用solaris操作系统的服务器A-SERVER网络连接不正常，从任意主机上都无法ping通该服务器。

排查：首先检查系统，系统本身工作正常，无特殊进程运行，cpu，内存利用率正常，无挂接任何形式的防火墙，网线正常。

此时我们借助tcpdump来进行故障定位，首先我们将从B-CLIENT主机上执行ping命令，发送icmp数据包给A-SERVER，如下：
[root@redhat log]# ping A-SERVER
PING A-SERVER from B-CLIENT : 56(84) bytes of data.
此时在A-SERVER启动tcpdump，对来自主机B-CLIENT的数据包进行捕获。

A-SERVER# tcpdump host B-CLIENT
tcpdump: listening on hme0
16:32:32.611251 arp who-has A-SERVER tell B-CLIENT
16:32:33.611425 arp who-has A-SERVER tell B-CLIENT
16:32:34.611623 arp who-has A-SERVER tell B-CLIENT
我们看到，没有收到预料中的ICMP报文，反而捕获到了B-CLIENT发送的arp 广播包，由于主机B-CLIENT无法利用arp得到服务器A-SERVER的地址，因
此反复询问A-SERVER的MAC地址，由此看来，高层的出问题的可能性不大，很可能在链路层有些问题，先来查查主机A-SERVER的arp表：
A-SERVER# arp -a
Net to Media Table
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 netgate 255.255.255.255 00:90:6d:f2:24:00
hme0 A-SERVER 255.255.255.255 S 00:03:ba:08:b2:83
hme0 240.0.0.0 SM 01:00:5e:00:00:00
请注意A-SERVER的Flags位置，我们看到了只有S标志。

我们知道，solaris在arp实现中，arp的flags需要设置P标志，才能响应ARP requests。

手工增加p位
A-SERVER# arp -s A-SERVER 00:03:ba:08:b2:83 pub
此时再调用arp -a看看
A-SERVER# arp -a
Net to Media Table
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 netgate 255.255.255.255 00:90:6d:f2:24:00
hme0 A-SERVER 255.255.255.255 SP 00:03:ba:08:b2:83
hme0 240.0.0.0 SM 01:00:5e:00:00:00
我们看到本机已经有了PS标志，此时再测试系统的网络连接恢复正常，问题解决！
例2：netflow软件问题
故障现象：在新装的网管工作站上安装cisco netflow软件对路由设备流量等进行分析，路由器按照要求配置完毕，本地工作上软件安装正常，无报错信息，但是启动netflow collector却收不到任何路由器上发出的流量信息，导致该软件失效。

排查：反复检查路由和软件，配置无误。

采用逐步分析的方法，首先先要定位出有问题的设备，是路由器根本没有发送流量信息还是本地系统接收出现了问题？突然想到在路由器上我们定义了接收的client端由udp端口9998接收数据，可以通过监视这个端口来看路由器是否确实发送了udp数据，如果系统能够接收到来自路由的数据包，那么路由方面的问题可能行不大，反之亦然。

在网管工作站上使用tcpdump来看看：
nms#tcpdump port 9995
tcpdump: listening on hme0
18:15:34.373435 routea > nms.9995: udp 1464
18:15:34.373829 routea.50111 > nms.9995: udp 1464
18:15:34.374100 routea.50111 > nms.9995: udp 1464
马上我们就看到数据包确实从路由器上发过来了，问题出在路由器的可能性基本排除，重新核查系统，果然，网管工作站上安装了防火墙，udp端口9998是被屏蔽的，调整工作站上的防火墙配置，netflow工作恢复正常，故障排除！
例3：邮件服务器排障
故障现象：局域网新安装了后台为qmail的邮件服务器server，邮件服务器收发邮件等基本功能正常，但在使用中发现一个普遍的怪现象：pc机器上发邮件时连接邮件服务器后要等待很久的时间才能开始实际的发送工作。

排查：网络连接没有问题，邮件服务器server和下面的pc性能都没有问题，问题可能出在哪里呢？为了进行准确的定位，我们在pc机client上发送邮件，同时在邮件服务器server上使用tcpdump对这个client的数据包进行捕获分析，如下：
server#tcpdump host client
tcpdump: listening on hme0
19:04:30.040578 client.1065 > server.smtp: S 1087965815:1087965815(0) win 64240 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF)
19:04:30.040613 server.smtp > client.1065: S 99285900:99285900(0) ack 1087965816 win 10136 <nop,nop,timestamp 20468779 0,nop,[|tcp]> (DF)
19:04:30.040960 client.1065 > server.smtp: . ack 1 win 64240 (DF)
顺利的完成三次握手，目前为止正常，往下看
19:04:30.048862 server.33152 > client.113: S 99370916:99370916(0) win 8760 <mss 1460> (DF)
19:04:33.411006 server.33152 > client.113: S 99370916:99370916(0) win 8760 <mss 1460> (DF)
19:04:40.161052 server.33152 > client.113: S 99370916:99370916(0) win 8760 <mss 1460> (DF)
19:04:56.061130 server.33152 > client.113: R 99370917:99370917(0) win 8760 (DF) 19:04:56.070108 server.smtp > client.1065: P 1:109(108) ack 1 win 10136 <nop,nop,timestamp 20471382 167656> (DF)
这里有问题了，我们看到server端试图连接client的113 identd端口，要求认证，然而没有收到client端的回应，server端重复尝试了3次，费时26秒后，才放弃认证请求，主动发送了reset标志的数据包，开始push后面的数据，而正是在这个过程中所花费的26秒时间，造成了发送邮件时漫长的等待情况。

问题找到了，就可以对症下药了，通过修改服务器端的qmail配置，使它不再进行113端口的认证，再次抓包，看到邮件server不再进行113端口的认证尝试，而是在三次握手后直接push数据，问题解决！
我是北京铁通ADSL上网，通过一个四口的路由分给几个人用。

我的IP是192.168.2.4。

网关是192.168.2.11。

以前有一段时间没改网关IP的时候路由里保存的ADSL账号经常消失、我设置的路由密码也改回了出厂设置，那时候是确定LAN里面有病毒。

后来改成了现在的IP。

该路由IP后能上qq，开网页有时候速度其慢无比。

在凌晨时候就我一个人上网，开网页也是非常慢。

抓包
44 6.280504 222.133.100.166 192.168.2.4 HTTP Continuation or non-HTTP traffic
45 6.280757 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
46 6.403861 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
47 6.403903 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
48 6.579872 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
49 6.579911 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
50 6.755121 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
51 6.755165 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
52 7.543836 222.133.100.166 192.168.2.4 TCP http > 2974 [ACK] Seq=168 Ack=23283 Win=65535 Len=0
53 7.543949 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
54 7.543958 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
55 7.677383 222.133.100.166 192.168.2.4 TCP http > 2974 [ACK] Seq=168 Ack=24880 Win=65535 Len=0
56 7.677488 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
57 7.677497 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
58 7.678653 222.133.100.166 192.168.2.4 HTTP Continuation or non-HTTP traffic
59 7.788499 222.133.100.166 192.168.2.4 TCP http > 2974 [ACK] Seq=224 Ack=26960 Win=65535 Len=0
60 7.788609 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
61 7.788615 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
62 8.625733 222.133.100.166 192.168.2.4 TCP http > 2974 [ACK] Seq=224 Ack=29840 Win=65535 Len=0
63 8.625848 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic
64 8.625856 192.168.2.4 222.133.100.166 HTTP Continuation or non-HTTP traffic IP查询结果222.133.100.166 中国山东省菏泽市
ping 超时
nslookup can't find
TCP包的输出信息
src ＞dst: flags data-seqno ack window urgent options
src ＞dst:表明从源地址到目的地址, flags是TCP包中的标志信息,S 是SYN标志, F (FIN), P (PUSH) , R (RST) "." (没有标记); data-seqno是数据包中的数据的顺序号, ack是下次期望的顺序号, window是接收缓存的窗口大小, urgent表明数据包中是否有紧急指针. Options是选项.。