免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
12下一页
最近访问板块 发新帖
查看: 52226 | 回复: 11
打印 上一主题 下一主题

一起共享tcpdump抓包分析的范例 [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2007-07-27 17:24 |只看该作者 |倒序浏览
找了很久抓包分析的一些例子,可以就是那么几个在不停的重复。抓包分析起来才觉得基本功太不够了,涉及到的东西太多,要了解的东西也太多。发这个贴的目的是有  希望我们有幸一起分享您的劳动汗水和结晶   
建议大家多举些例子,谢谢大家

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

用tcpdump分析traceroute的工作原理[原创] http://www.0ginr.com/bbs/viewthr ... &extra=page%3D1

论坛徽章:
0
2 [报告]
发表于 2007-07-27 17:27 |只看该作者
例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看看
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) 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

论坛徽章:
0
3 [报告]
发表于 2007-07-27 17:45 |只看该作者
使用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
分析过滤后的数据包,察看发现全是TCP三次握手中的第一个syn包,检查其占总体数据的比率远高于正常水平.
通过IP查找源头!

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!


由于其教室中的PC都是有硬件还原卡的,而它PC也是管理较为混乱.于是决定决定在核心交换机上添加访问列表.

具体访问列表的方案参考:
网络设备配置中经常使用的访问列表或rule(华为设备中使用)
http://bbs.chinaunix.net/viewthr ... &extra=page%3D1

论坛徽章:
0
4 [报告]
发表于 2007-07-27 17:49 |只看该作者
freebsd用tcpdump的参数顺序有严格限制
如: #tcpdump -i eth1 -w c.cap -s 0  host 192.168.2.1 and host 23.33.22.56
能在freebsd下执行,如果把-w c.cap放到末尾就会出错,可是在linux还是能执行的。

请不要灌水,欢迎多举示例:wink:

论坛徽章:
54
2017金鸡报晓
日期:2017-02-08 10:39:42操作系统版块每日发帖之星
日期:2016-03-08 06:20:00操作系统版块每日发帖之星
日期:2016-03-07 06:20:00操作系统版块每日发帖之星
日期:2016-02-22 06:20:00操作系统版块每日发帖之星
日期:2016-01-29 06:20:00操作系统版块每日发帖之星
日期:2016-01-27 06:20:00操作系统版块每日发帖之星
日期:2016-01-20 06:20:00操作系统版块每日发帖之星
日期:2016-01-06 06:20:0015-16赛季CBA联赛之江苏
日期:2015-12-21 20:00:24操作系统版块每日发帖之星
日期:2015-12-21 06:20:00IT运维版块每日发帖之星
日期:2015-11-17 06:20:002015亚冠之广州恒大
日期:2015-11-12 10:58:02
5 [报告]
发表于 2007-07-27 22:32 |只看该作者
发现少了nmap。这个也挺好用。

论坛徽章:
0
6 [报告]
发表于 2007-07-27 23:15 |只看该作者
以前管局域网时查问题时常用!特别是arp欺骗~!

论坛徽章:
0
7 [报告]
发表于 2007-07-28 13:31 |只看该作者
学习ing!

论坛徽章:
0
8 [报告]
发表于 2007-07-29 04:33 |只看该作者
我是北京铁通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是选项.


我认为是我的电脑里面有病毒,如果宽带路由有病毒的话,我的qq就不会是一直能上的了。
未知病毒来势汹汹,专杀宽带路由http://publish.it168.com/2005/0518/20050518011001.shtml

论坛徽章:
0
9 [报告]
发表于 2009-04-28 13:10 |只看该作者
mark 一下。。。:wink:

论坛徽章:
0
10 [报告]
发表于 2009-04-28 19:04 |只看该作者
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP