矿业集团解决网络故障分析讨论

孤独的意尹者 · 发表于 2008-1-10 14:40:28

前两天在一个矿业集团解决网络故障时抓取的数据包，放上来，供各位兄弟分析讨论，以求共同进步，呵呵。
故障现象为：cisco 7609交换机延迟很大，互联网出口设备堵塞，互联网访问中断。
大家解压后直接使用科来打开就可以了。

[ 本帖最后由孤独的意尹者于 2008-1-10 18:10 编辑 ]

chinaheiyu · 发表于 2008-1-10 15:33:32

要是楼主能把整个网张拓朴结构阐述下就好了，，

孤独的意尹者 · 发表于 2008-1-10 15:39:23

原帖由 chinaheiyu 于 2008-1-10 15:33 发表
要是楼主能把整个网张拓朴结构阐述下就好了，，

由于该故障与拓扑无关，所以，我就没有上传拓扑了！呵呵。

孤独的意尹者 · 发表于 2008-1-10 15:40:35

由于我公司网络原因，发了两个一样的帖子，希望斑竹将另一帖的数据包并过来，同时将另一帖删除，谢谢！

已经处理，但是不能解压，请重新上传一下。谢谢！

chinaheiyu · 发表于 2008-1-10 16:59:23

原帖由 孤独的意尹者 于 2008-1-10 15:39 发表

由于该故障与拓扑无关，所以，我就没有上传拓扑了！呵呵。

就算没关系，大家看的时候也比较明了吧！兄弟们支持不？

还有，最好楼主自己先能阐述下你的思路，起个头！

[ 本帖最后由 chinaheiyu 于 2008-1-10 17:00 编辑 ]

ppyycc · 发表于 2008-1-10 17:07:23

这么短时间这么多伪造的syn包有什么好分析的……

chinaheiyu · 发表于 2008-1-10 17:14:23

原帖由 ppyycc 于 2008-1-10 17:07 发表
这么短时间这么多伪造的syn包有什么好分析的……

分析还没入门，请教下！我们看到初始化的TCP连接数较多，而成功建立的TCP连接数很少时，说明网络中的主机可能感染病毒，且此病毒正在试图连接其他主机的某些TCP端口以进行感染！至于是哪一台或者几台，还请望请教！

ppyycc · 发表于 2008-1-10 17:19:07

omg 看看ip.scr 和ip.dst不就行了

lbzxy · 发表于 2008-1-10 17:32:48

数据包好像不完整。
我认为应该是由于P2P下载及一些在线视频造成的。
请问楼主是这样的吗？

xwy3260 · 发表于 2008-1-10 17:51:41

看了一下，网络中存在大量的问题，比如：
1.BIT下载
2.在线观看视频或音频
3.网络攻击行为
......
大家继续找啊！

孤独的意尹者 · 发表于 2008-1-10 17:58:57

原帖由 ppyycc 于 2008-1-10 17:07 发表
这么短时间这么多伪造的syn包有什么好分析的……

需要说明的是:
1,这个不是什么怪异的故障，此帖目的在于：通过一般问题的探讨，让更多想学习网络分析的兄弟有个入门的思路，另一方面，可以让像你一样熟练甚至精通于网络分析的先闻道者帮助帮助后学者。
2，我们说探讨，那就不应该仅仅局限于发现问题，我们应该可以更进一步的分析问题的原因、定位故障的源头、提出解决的方法等等，你觉得如何？

孤独的意尹者 · 发表于 2008-1-10 18:13:46

原帖由 chinaheiyu 于 2008-1-10 16:59 发表

就算没关系，大家看的时候也比较明了吧！兄弟们支持不？
还有，最好楼主自己先能阐述下你的思路，起个头！

已经补上拓扑图（该拓扑图仅为主要结构的示意图）并重新上传编辑了4506的数据包。
我就先开个头吧，首先通过“矩阵图”我们可以发现有一个异常的IP存在太多的连接，我们可以将关注点聚焦到该IP上。。。。

[ 本帖最后由孤独的意尹者于 2008-1-10 18:22 编辑 ]

孤独的意尹者 · 发表于 2008-1-10 18:27:36

通过矩阵图，我们孩可以发现：
1，与异常IP4.79.142.202有连接的IP都是随机的公网地址（矿业集团内部使用137段的地址）。
2，带来的疑问有：
（1）异常IP4.79.142.202是什么机器？用来干什么的?
（2）那些很随机的公网地址是从哪里来的？
（3）这些连接都是什么数据包？

[ 本帖最后由孤独的意尹者于 2008-1-10 18:29 编辑 ]

孤独的意尹者 · 发表于 2008-1-10 18:42:04

解决上述疑问：
1，使用小工具反向解析异常ip 4.79.142.202对应的域名为：www.grc.com，查看该域名，可以发现该域名为一美国的web站点，google一下关键词“grc"，竟然找到一篇关于DOS攻击的文章：”……D.R.D.O.S是Distributed Reflection Denial of Service Attack的缩写,直译为分布式（Distributed）反射（Reflection）拒绝服务（Denial of Service）攻击，2002年1月11日凌晨两点，grc.com遭到攻击，大量的ack应答淹没了可怜的grc.com……"，可见，该站点曾经被别人DOS攻击过，那么这次也是针对该站点的DOS攻击吗？有待后面的分析确认；
2，内网地址为137段的，那么异常IP或者那些与异常IP有连接的随机公网地址可能是被伪造出来的；
3，查看“数据包”可以发现：那些连接都是针对HTTP的syn请求包，而且目的地址为4.79.142.202，至此可确认与异常IP4.79.142.202有连接的随机公网地址的确是被伪造出来的，而且基本上可以断定这些异常的连接是针对4.79.142.202的DOS流量；

孤独的意尹者 · 发表于 2008-1-10 18:48:15

上面的分析基本上将故障原因找到了，下一步就是如何定位故障源、如何使网络恢复正常了，请各位兄弟积极探讨，发表各自的看法。

孤独的意尹者 · 发表于 2008-1-10 18:49:29

原帖由 ppyycc 于 2008-1-10 17:19 发表
omg 看看ip.scr 和ip.dst不就行了

ip.scr是伪造的，ip.dst是受害者，如何找到真正的故障源呢？

孤独的意尹者 · 发表于 2008-1-10 18:52:41

原帖由 lbzxy 于 2008-1-10 17:32 发表
数据包好像不完整。
我认为应该是由于P2P下载及一些在线视频造成的。
请问楼主是这样的吗？

P2P及一些在线视频在这个大网中肯定是有的，但是故障时，互联网已经中断了，这些数据流不是很多，这个可以通过“协议”视图看到。

孤独的意尹者 · 发表于 2008-1-10 18:54:10

原帖由 xwy3260 于 2008-1-10 17:51 发表
看了一下，网络中存在大量的问题，比如：
1.BIT下载
2.在线观看视频或音频
3.网络攻击行为
......
大家继续找啊！

的确是攻击行为，但最好能将您的分析过程描述一下，方便讨论，呵呵。

chinaheiyu · 发表于 2008-1-11 10:24:50

以下分析是刚刚看帮助文件学习的，现学现卖，不足之处或者有问题还问指明！
先来看下，这张图。。

发送数据包和字节都为0，但是接收数据包。这能说明一个什么问题呢？不急，我们再看。

数据包主要分布在两端，说明网络中可能存在非正常的网络通讯，如碎片或数据包溢出攻击。
初始化的TCP连接数较多，而成功建立的TCP连接数很少时，表示网络中的主机可能感染病毒，且此病毒正在试图连接其他主机的某些TCP端口以进行感染！202.237.154 这个网段是哪里的？
看到楼上说虚拟IP，是么样现实的？

xwy3260 · 发表于 2008-1-11 11:09:17

紧接楼上，这时应该根据会话视图来查看具体的通讯会话情况。

PS：楼主用的是sniffer还是ethereal?

[ 本帖最后由 xwy3260 于 2008-1-11 11:25 编辑 ]

flamen · 发表于 2008-1-11 21:07:04

抓包用的ethereal，分析的时候用的科来分析系统。

xwy3260 · 发表于 2008-1-11 23:22:20

原帖由 孤独的意尹者 于 2008-1-10 18:49 发表

ip.scr是伪造的，ip.dst是受害者，如何找到真正的故障源呢？

请楼主说下怎样查找真正的故障源？方便大家学习！

[ 本帖最后由 xwy3260 于 2008-1-12 12:31 编辑 ]

jxjxzxh2007 · 发表于 2008-1-15 07:00:59

故障原因找到了,故障时查看接入交换机上哪个端口上来的数据报文最多,show interface 可直接定位交换机端口,顺藤摸瓜,找出攻击源,

wingjing · 发表于 2008-1-15 10:31:28

通过数据包里的那些随机公网IP，能发现对应的MAC只有一个，而且是内网的某一台机器...
哈哈，直接操刀砍那台客户机去了。。。
PS:这个病毒编写者还有点良心，伪造的公网IP都是日本的。。

孤独的意尹者 · 发表于 2008-1-15 12:04:47

原帖由 jxjxzxh2007 于 2008-1-15 07:00 发表
故障原因找到了,故障时查看接入交换机上哪个端口上来的数据报文最多,show interface 可直接定位交换机端口,顺藤摸瓜,找出攻击源,

是个定位的方法，但是工作量似乎比较大，呵呵

孤独的意尹者 · 发表于 2008-1-15 12:06:19

原帖由 chinaheiyu 于 2008-1-11 10:24 发表
以下分析是刚刚看帮助文件学习的，现学现卖，不足之处或者有问题还问指明！
先来看下，这张图。。
6526
发送数据包和字节都为0，但是接收数据包。这能说明一个什么问题呢？不急，我们再看。
6527
数据包主要分布 ...

不是虚拟的IP，是伪造的虚假IP，这些IP是由木马病毒随机生成的

孤独的意尹者 · 发表于 2008-1-15 12:19:50

我接着上面得分析继续抛砖引玉：
＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋
我们在7609上抓取得数据包，已经可以定位出故障原因了，但是如何定位故障源呢？我们先分析一下：
1，我们通过7609上的数据包知道源IP是伪造的，那么什么是不可伪造的呢？对，就是源MAC地址，我们可以通过查找源MAC地址来定位故障源；
2，由于整个矿业集团城域网是由好几台7609等高端设备组成得OSPF环网，在7609上抓取的数据包都是经过一个或者多个路由设备过来的，那么在7609上抓取的数据包的MAC都是路由的MAC地址，无法定位真正的源MAC；
3，我们要找真正故障主机的MAC，就必须在故障主机最近的交换机上抓取数据包，那么我们就可以在各矿属单位的核心交换机4509或6509上抓取数据包；
4，通过分析4506上抓取的数据包，我们可以发现所有伪造IP均来自以下四个MAC：00:E0:4C:80:16

9、00:E0:4C:30:1A:A4、00:11:5B:ED:5F:7B、00:19:E0:27:3D:5C；
5，通过查看4506的ARP表定位出故障主机IP地址；
至此，将故障源定位出来了，接下来，就是如何解决故障了

[ 本帖最后由孤独的意尹者于 2008-1-15 12:43 编辑 ]

孤独的意尹者 · 发表于 2008-1-16 12:22:30

没人说说怎么解决吗？

KIMICN · 发表于 2008-1-16 17:14:00

解决好办啊顺着MAC地址找到相对应的接入层交换机端口 shutdown等人打电话过来吧，先警告一下。有条件可以在端口上配置 storm-control对单播广播进行限制，矿业集团一定有钱可以建议他们买上网安全控制设备随时监控异常行为~~
其实解决这类病毒或者蠕虫引起的原因还是要部署企业级的杀毒软件定期补丁最主要的是规章制度（老生常谈了。。）

孤独的意尹者 · 发表于 2008-1-17 11:19:47

原帖由 KIMICN 于 2008-1-16 17:14 发表
解决好办啊顺着MAC地址找到相对应的接入层交换机端口 shutdown等人打电话过来吧，先警告一下。有条件可以在端口上配置 storm-control对单播广播进行限制，矿业集团一定有钱可以建议他们买上网安全控制设备随时监控 ...

KIMICN兄：
矿里有一个瓦斯监控系统，终端时间超过10分钟的话，就算一次安全事故，后果很严重的（一大堆的报告要写、N多人的奖金会泡汤。。。。）所以，不能将接入层交换机端口 shutdown的，呵呵。
当然最终的解决方案肯定是部署企业级的杀毒软件定期补丁、规章制度等等了～～～
现场即时处理的方法为交换机上做针对受害IP的ACL（实际是这样做的，网络恢复正常了）
当时有想到LINUX系统路由处理中有个路由黑洞的机制，只是不怎么清楚，所以底气不足，没提，呵呵～～～
后来，到互联网上google了一下关键词：路由黑洞，发现通过路由黑洞完全可以在保证对交换机性能影响最小的情况下实现这种垃圾DOS包的过滤：

”黑洞路由，便是将所有无关路由吸入其中，使它们有来无回的路由，一般是admin主动建立的路由条目。

提到黑洞路由就要提一下null0接口。
null0口是个永不down的口，一般用于管理，详见我建立的null0的词条（如果通过审核的话）
admin建立一个路由条目，将接到的某个源地址转向null0接口，这样对系统负载影响非常小。
如果同样的功能用ACL（地址访问控制列表）实现，则流量增大时CPU利用率会明显增加。
所以，设置黑洞路由一直是解决固定DOS攻击的最好办法。
相当于洪水来临时，在洪水途经的路上附近挖一个不见底的巨大深坑，然后将洪水引入其中。 “

矿业集团解决网络故障分析讨论

本帖子中包含更多资源

评分

评分

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源

To xwy3260

故障时查看接入交换机上哪个端口上来的数据报文最多,show int