tcpdump抓包分析案例

 找了很久抓包分析的一些例子，可以就是那么几个在不停的重复。抓包分析起来才觉得基本功太不够了，涉及到的东西太多，要了解的东西也太多。发这个贴的目的是有  希望我们有幸一起分享您的劳动汗水和结晶   

建议大家多举些例子，谢谢大家。

tcpdump抓包分析详解 http://blog.csdn.net/yeqihong/archive/2007/01/08/1477050.aspx

用tcpdump分析traceroute的工作原理［原创］

http://www.0ginr.com/bbs/viewthread.php?tid=184&extra=page%3D1

例1：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看看

hme0 A-SERVER 255.255.255.255 SP 00:03:ba:08:b2:83

我们看到本机已经有了PS标志，此时再测试系统的网络连接恢复正常，问题解决！

例2：netflow软件问题

故障现象：在新装的网管工作站上安装cisco netflow软件对路由设备流量等进行分析，路由器按照要求配置完毕，本地工作上软件安装

正常，无报错信息，但是启动netflow collector却收不到任何路由器上发出的流量信息，导致该软件失效。 排查：反复检查路由和软

件，配置无误。采用逐步分析的方法，首先先要定位出有问题的设备，是路由器根本没有发送流量信息还是本地系统接收出现了问题？

突然想到在路由器上我们定义了接收的client端由udp端口9998接收数据，可以通过监视这个端口来看路由器是否确实发送了udp数据，

如果系统能够接收到来自路由的数据包，那么路由方面的问题可能行不大，反之亦然。

在网管工作站上使用tcpdump来看看：

nms#tcpdump port 9995

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

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(10 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数据，问题解决！

总结：上面我们通过实际的例子演示了包分析软件在故障解决中起到的作用，通过这些例子，我们不难发现，用好包分析软件，对系统

管理员快速准确定位网络故障，分析网络问题有不可替代的作用

转自  http://chinabeta.cn/wgjs/pmsj/200704/15695.html

使用Ethereal的过滤器处理某学校网络问题中的大致过程

http://bbs.chinaunix.net/viewthread.php?tid=874452&highlight=使用Ethereal的过滤器处理某学校网络问题中的大致过程

一个学校发现其中有ARP欺骗,冲击波病毒,蠕虫王病毒,需要处理.

处理过程:

在核心交换机上配置端口镜像分别抓各个网段的数据包,(分别抓各个网段的数据包的目的是减小核心交换机压力,也方便缩小分析量)

1.ARP欺骗

使用下列过滤法则:

arp.opcode==1 or arp.opcode==2

发现ARP欺骗包后,以其MAC为过滤条件即:

eth.scr ==.....

分析其相关IP信息,找到具体用户.如果用户修改了IP和MAC地址就只有一根一根去拔线了!

2.冲击波病毒

分析数据包,使用下列过滤法则:

tcp.port == 135

tcp.port == 139

分析过滤后的数据包,察看发现全是TCP三次握手中的第一个syn包,检查其占总体数据的比率远高于正常水平.

通过IP查找源头!

3.蠕虫王病毒

tcp.port == 1433

4.使用下列过滤法则:

!(tcp.port ==5900 or tcp.port ==135 or tcp.port==139)

先保存过滤后的数据包,再分析.

发现:

tcp.port == 5900占用的数据比率也比较高

VNC TCP port: 5900) 5900/tcp open vnc VNC (protocol 3.

追踪相关IP!