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 与 portnumber 捉下 eth0 这个网络卡上的封包，持续3 秒

[root@linux ~]#tcpdump -i eth0 -nn

tcpdump: verboseoutput suppressed, use -v or -vv for full protocol decode

listening on eth0,link-type EN10MB (Ethernet), capture size 96 bytes

01:33:40.41 IP192.168.1.100.22 > 192.168.1.11.1190: P 116:232(116) ack 1 win 9648

01:33:40.41 IP192.168.1.100.22 > 192.168.1.11.1190: P 232:364(132) ack 1 win 9648

<==按下 [ctrl]-c 之后结束

6680 packetscaptured              <==捉下来的封包数量

14250 packetsreceived by filter   <==由过滤所得的总封包数量

7512 packetsdropped 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: verboseoutput suppressed, use -v or -vv for full protocol decode

listening on eth0,link-type EN10MB (Ethernet), capture size 96 bytes

01:54:37.96 IP192.168.1.11.1240 > 192.168.1.100.21: . ack 1 win 65535

01:54:37.96 IP192.168.1.100.21 > 192.168.1.11.1240: P 1:21(20) ack 1 win 5840

01:54:38.12 IP192.168.1.11.1240 > 192.168.1.100.21: . ack 21 win 65515

01:54:42.79 IP192.168.1.11.1240 > 192.168.1.100.21: P 1:17(16) ack 21 win 65515

01:54:42.79 IP192.168.1.100.21 > 192.168.1.11.1240: . ack 17 win 5840

01:54:42.79 IP192.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) 登入『sshlocalhost』

那么输出的结果会是如何？

[root@linux ~]#tcpdump -i lo -nn

 1 tcpdump: verbose output suppressed, use -vor -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,timestamp236681316 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 <mss16396,sackOK,timestamp 236681316 236681316,nop,

   wscale 2>

 5 11:02:54.253871 IP 127.0.0.1.32936 >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 236681334236681316>

 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)通讯协议为 port22 ，(3)目标来源为192.168.1.100 的封包资料？

答： tcpdump -i eth0 -nn 'port 22 and srchost 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 BASE-ADDRESS.MCAST.NET 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 BASE-ADDRESS.MCAST.NET 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) win64240 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF)
19:04:30.040613 server.smtp > client.1065: S 99285900:99285900(0) ack1087965816 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=168Ack=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=168Ack=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=224Ack=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=224Ack=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 urgentoptions
src ＞ dst:表明从源地址到目的地址,flags是TCP包中的标志信息,S 是SYN标志, F (FIN), P (PUSH) , R (RST) "."(没有标记); data-seqno是数据包中的数据的顺序号,ack是下次期望的顺序号, window是接收缓存的窗口大小,urgent表明数据包中是否有紧急指针. Options是选项.

我认为是我的电脑里面有病毒，如果宽带路由有病毒的话，我的qq就不会是一直能上的了。