欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

【转】上网认证页面无法打开案例

作者:易隐者 发布于:2012-11-25 10:40 Sunday 分类:案例讨论

【说在之前】:

1,该案例的确属于疑难故障范畴,若不是通过抓包方式,站在数据包交互的角度进行分析是无法定位、解决该故障的,因此,该案例具有学习参考价值;

2,案例的分析用到了关联分析法和对比分析法,思路非常清晰,但整个文档在图文编辑和措词这块还可以做进一步的加强,考虑到原文的完整性,我不对该文档做任何修改;

3,难能可贵的是作者在找到故障原因并解决故障之后,没有像大部分人那样将这个故障束之高阁, 而是将自己的分析思路、过程整理成文档,分享给大家,另外,发现其中难以解释的、存在疑问的地方,供大家一起讨论,这正是我一直倡导的“自我总结、无私分享、共同探讨、共同进步”的学习方式;

4,针对该案例后面的疑问,我就我的理解作出相关解答,供大家参考。

     针对第一个疑问:AC在此处工作在透明模式下,正常情况下其对报文的干预和处理根本不需要经过路由,也就是说,AC在做HTTP重定向的时候,根本不需要根据路由表,将这个HTTP重定向报文转发给PIX防火墙,而应该直接构造相应HTTP重定向报文发往核心交换机,因此,此处出现这样的问题,我个人认为如果AC是按照路由方式处理的话,其应该有相应的转发表,转发表中会有下一跳、转发接口等相关信息,而出现此案例中的问题,说明AC的转发表出现了异常,可能是其上联口和下联口是属于同一网段,而AC转发表未对其进行区分导致的;

     针对第二个疑问:这里需要明确,AC的管理口和业务口是否是完全独立的,如果是,那么所谓的两条默认路由是完全分开的,没有任何问题,如果不是,那么根据不同的系统处理方式,负载均衡(根据报文或其他)或者选择其中一条都是有可能的,多年前我曾写过一篇《供电局调度所前置机故障解决说明》的文档,就是两条默认路由导致异常的案例,过段时间我把这个案例共享到我的博客供大家参考。

5,该案例作者肖鉴为我以前推出《合肥网络分析技术团队招募学徒》的第一个学员。他不远千里从福建专程请假几十天跟随我学习相关知识,当我第一眼看到他时,我就被他的这种对技术执着追求的行为所感动,他基础不错,学习踏实认真,我个人认为我真正给他的帮助不在于具体技术的成长和进步,而在于影响他对技术的自信、清晰的职业发展方向规划以及行事的风格,在他身上我能看到我以前的影子,他现在深信服的总代,刚获得深信服深信服华南区技术大比武冠军,看到他的成长,我的内心是无比的欣慰。

【原文全文】

1. 网络环境

        故障网络环境如下图所示: 

点击查看原图

说明:
1. 出口防火墙工作在路由模式做NAT代理内网上网,E1口IP地址192.168.247.1/24。
2. 上网行为管理工作的网桥模式下,为其网桥IP地址配置192.168.247.3/24、网关IP地址为192.168.247.1用于设备管理,下联三层交换机IP地址为192.168.247.2/24。由于,前置PIX防火墙为阻止192.168.247.0/24网段上网,所以为了上网行为管理能够更新内置规则库,上网行为管理口下联三层核心交换机为其配置IP地址192.168.20.250网关IP地址192.168.20.1。
3.上网行为管理对内网部分网段实行认证上网。

2. 故障现象

       内网无须进行认证PC机访问互联网正常,需进行认证网段PC机上网在正常情况必须得先进行认证输入用户名和密码后方可访问互联网,故障表现为认证网段PC机无法正常跳转至认证界面输入用户名和密码。如下图所示: 

点击查看原图

3. 故障分析

3.1 常规分析

       在PC上访问网络时无法跳出登陆界页时,我们手动输入http://192.168.247.3认证登陆页面是正常,如下图所示,并且,输入完认证用户名和密码后可以正常访问互联网。说明网络中并不存在路由问题。那么是否可能是设备本身处理机制出现问题呢?还是,PC机与上网行为管理设备通信出现了其它的异常导致PC机无法正常弹出认证页面?。 

点击查看原图

阅读全文>>

标签: 交换机 团队 疑难故障 TCP 网络分析 负载均衡 抓包 深信服 上网行为管理 HTTP重定向 AC 路由表 转发表

评论(0) 引用(0) 浏览(13205)

【转】中科院《个人隐私泄露风险的技术研究报告V1.0》的部分内容

作者:易隐者 发布于:2012-11-23 9:43 Friday 分类:案例讨论

【说在之前】:

1,早上看到新浪新闻《中科院报告:360产品存在三大隐私安全问题 》,其中引用了中科院保密技术攻防重点实验室研究撰写的《个人隐私泄露风险的技术研究报告》的部分内容,通过分析可见任何应用产品,若非自行开发,均可能在后台执行各种非法的或非授权的操作,而这种隐形的操作行为很可能会给最终用户带来各种威胁;

2,这些后台的隐形行为不易为用户所察觉,但是利用网分析技术可以对这些隐形行为进行数据包级别的深入分析;

3,该报告分析的主要方式是通过网络分析的技术手段实现对360浏览器网络行为的分析,使用的工具看截图应该是wireshark,此报告作为利用网络分析技术对应用进行分析评估的一个案例,值得大家参考学习。

【原文链接】:http://tech.sina.com.cn/i/2012-11-23/08517825584.shtml

【原文】:

  前言

  随着国内外个人隐私泄露事件的频繁发生和对个人隐私保护的重视,人们越来越关注日常工作生活中计算机软件、移动终端以及高技术带来的个人隐私问题。中国科学院信息工程研究所保密技术攻防重点实验室对当前常用软件和终端产品的用户隐私保护情况进行了初步调查,通过实验研究发现了一些有关隐私保护存在的风险。本文主要从常用软件、网络服务、移动终端以及声光电磁等四个方面介绍了实验室的研究结果和发现。文中内容注重实例研究和数据再现,希望引起有关部门对个人隐私相关问题的关注。

  本文得到了北京大学互联网安全技术北京市重点实验室的帮助。

  1 终端常用软件与用户隐私保护

  1.1网络浏览器

  许多网络浏览器为了增强用户体验、提供个性化服务、发展定向广告业务等目的,通常会在后台收集用户的网页浏览记录等个人信息上传到服务器。然而许多收集用户个人信息的行为是在用户不知情的情况下进行的,或者所收集的信息超出了软件《安装许可协议》中进行了明确规定的范围。

  实验室以360安全浏览器当前最新版本5.0为例,对浏览器的用户隐私泄露问题进行了分析和研究,网络浏览器中的隐私泄露威胁存在于以下几个方面:

  1)预留后门,植入代码:一些浏览器在使用过程中会在用户不知情的情况下在后台执行《安装许可协议》规定内容之外的功能,360安全浏览器在运行过程中约每5分钟与服务端进行一次通信,并下载一个文件,如下图所示,下载的文件为se.360.cn/cloud/cset18.ini,但是从数据流可以看出该文件实际上是一个PE文件,文件头中标识的产品名称为DataDll。

图1-1 
图1-1

  将该文件从数据流中提取出来得到一个dll文件,查看该文件的属性,得到其文件说明为“360安全浏览器 安全网银”。

图1-2 
图1-2

  从该文件中提取到一段Base64编码的文本信息:

W3N0XQ0KY291bnQ9Mg0KW3N0MV0NCmlkPTENCnVybD1odHRwOi8vd3d3LmJhaWR1LmNvbS9zZWFyY2gvc

mVzc2FmZS5odG1sKg0KW3N0Ml0NCmlkPTINCnVybD1odHRwOi8vdmVyaWZ5LmJhaWR1LmNvbS92Y29kZT8q

DQpbdHJheW1zZ10NCnN0YXRpY3NpZD0zMQ0KY291bnQgPSAxDQp1cmwxPWh0dHA6Ly93d3cuYmFpZHUuY2

9tL3NlYXJjaC9yZXNzYWZlLmh0bWwqDQpbbWFpbl0NCmhrcmVzMj0xDQpjYmM9MQ0KW2NiY10NCnVybGNvdW

50PTENCnVybDE9aHR0cDovL3d3dy5iYWlkdS5jb20vc2VhcmNoL3Jlc3NhZmUuaHRtbCoNCmNiY2NvdW50PTINC

mMxPUJBSURVSUQNCmMyPUJEVVNT

  经过解码后的内容为:

  [st]

  count=2

  [st1]

  id=1

  url=http://www.baidu.com/search/ressafe.html*

  [st2]

  id=2

  url=http://verify.baidu.com/vcode?*

  [traymsg]

  staticsid=31

  count = 1

  url1=http://www.baidu.com/search/ressafe.html*

  [main]

  hkres2=1

  cbc=1

  [cbc]

  urlcount=1

  url1=http://www.baidu.com/search/ressafe.html*

  cbccount=2

  c1=BAIDUID

  c2=BDUSS

  由此可推测该DLL文件的功能与网银无任何关系,而是跟搜索引擎百度相关可能是为了躲避Referer字段的检查。这种行为虽然不涉及用户隐私,但是具有欺骗性。

  此外,360安全浏览器还会在用户不知情的情况下定期从服务端下载和执行一个名为“ExtSmartWiz.dll”的动态链接库。如果该动态链接库被植入恶意功能或者不法分子利用域名劫持等方法对浏览器下载的“ExtSmartWiz.dll”文件进行恶意篡改,将会给用户安全带来严重危害。

  2)收集用户浏览记录:很多浏览器会将用户所打开的页面地址上传到服务器,以分析用户的个人爱好或者统计网站的受欢迎度,从而在浏览器首页更好地为用户推荐个性化内容。这种行为也侵犯了用户的隐私数据。下图为当用户使用360安全浏览器5.0访问网页的时候,每打开一个网页之后都会向360的特定服务器发送一个POST请求,内容包含加密过的url信息。

图1-3
 图1-3

  3)收集浏览器地址栏输入信息:当用户在浏览器地址栏中输入网址的时候,很多浏览器为了帮助用户自动补全网址,会把用户所输入的内容上传到服务器来。下图为当用户在360安全浏览器5.0的地址栏中输入“10.105.240.57”时,浏览器会将该地址发送到sug.so.360.cn,并且发送时附带的Cookie中会带有具有用户唯一性标志的guid值,这可能会导致特定用户的地址栏输入以及浏览记录被跟踪和泄漏。

图1-4 
图1-4

  下图所示为当用户在360安全浏览器5.0的地址栏中输入“weibo.com”的过程中,每输入一个字符,浏览器就会向sug.so.360.cn发送当前浏览器地址栏中的内容(即“w”、“we”、“wei”、“weib”、“weibo”、“weibo。”、“weibo.c”、“weibo.co”、“weibo.com”)。

中科院报告:360产品存在三大隐私安全问题

图1-5

阅读全文>>

标签: wireshark 网络分析 解码 安全 业务 网络行为 应用分析 应用评估

评论(0) 引用(0) 浏览(5428)

多层架构业务应用场景下的网络分析

作者:易隐者 发布于:2012-11-22 13:06 Thursday 分类:网络分析

       我们在日常工作中,最为常见的网络分析场景为针对简单的C/S或B/S架构的应用的分析,在简单环境中,C/S或B/S架构的应用主要是一层架构的,如下图所示: 

点击查看原图

       在这个架构的应用中,业务的交互仅仅涉及到客户端与服务器,这样的业务交互过程和报文交互路径都非常简单清晰,分析这种架构业务应用的性能问题、故障问题并不存在很大的难度,因为不会涉及过多的中间环节,但是在规模较大、应用较为重要和复杂的环境中,最为常见的是多层架构的业务应用系统。

三层/多层架构应用

       那么什么是多层架构的应用呢?我从网上找了一段文字,应该能够将其说明清楚:“所谓三层架构,是在客户/服务之间加入了一个"中间层",也叫组件层。它与客户层、服务器层共同构成了三层体系。这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才有三层体系结构,三层是指逻辑上的三层。通过引入中间层,将复杂的商业逻辑从传统的双层结构(Client-Server)应用模型中分离出来,并提供了可伸缩、易于访问、易于管理的方法,可以将多种应用服务分别封装部署于应用服务器,同时增强了应用程序可用性、安全性、封装复用性、可扩展性和可移置性,使用户在管理上所花费的时间最小化,从而实现了便捷、高效、安全、稳定的企业级系统应用。”

       三层架构主要分为表示层、业务逻辑层、数据访问层三层,每层主要负责的工作如下:

表示层:主要负责从用户收集信息,将用户信息发送到业务服务层做处理,从业务服务层接收处理结果,将结果显示给用户等;
业务逻辑层:主要负责从表示层接收输入,与数据层交互执行已设计的业务,操作(业务逻辑,系统服务等),将处理结果发送到表示层等;
数据访问层:主要负责数据存储,数据获取,数据维护,数据完整性等;

       下图为一个经典三层架构的应用示意图: 

点击查看原图

       在实际工作环境中,最为简单和常见的三层架构的应用为下图所示:

点击查看原图

       在这个架构中,其实是将表示层和业务逻辑层整合在一起,通过应用服务器统一对外提供业务访问界面和业务逻辑处理。
       我们遇到的大型、复杂的应用基本上都是基于多层架构开发的,针对多层架构应用的分析将是以后网络分析工作中无法回避的问题。

分析多层架构应用的难处

       针对多层架构应用的分析,可不像我们平时分析简单一层架构的B/S、C/S应用那样简单,分析多层架构的业务应用主要具有以下几点难度:

1, 业务数据交互路径更为复杂
       一个客户端访问多层架构的业务应用时,其业务数据交互路径一般如下图所示: 

点击查看原图

1, 客户端向Web服务器发送相关业务应用的操作
2, Web服务器将客户端的相关业务操作请求交由应用服务器处理
3, 应用服务器将业务操作涉及到的相关数据请求发往数据库服务器
4, 数据库服务器将相关数据操作结果反馈给应用服务器
5, 应用服务器根据数据库服务器反馈的数据结合业务逻辑,得出相关信息发往Web服务器
6, Web服务器将客户端相关业务操作的反馈数据显示给客户端

       纵观整个交互的过程,我们可以知道同样一个业务操作的交互,多层架构的应用跟简单的一层架构的应用相比,多出了数个中间环节,这导致业务交互路径变得复杂,我们需要在不同的环节分别抓包做关联分析。这些都会增加网络分析的工作量和难度。

2,数据加密问题:数据库加密
       基于数据安全的角度,现在很多涉及到数据库的交互,其在应用层将数据库应用字段加密,如下图所示: 

点击查看原图

       在这种情况下,我们站在网络交互的角度捕获的报文只能够提供三层和四层的相关信息,数据库应用数据信息均无法正常查看,因此我们无法分析到底哪一个报文是某个客户端的业务操作引发的应用服务器对数据库服务器的访问行为,这给我们的分析工作带来了巨大的不便。
       如果真的遇到加密的情况,那么站在网络层面对其报文进行分析已经无能为力了,建议在数据库服务器上站在业务应用的角度,调用其数据库日志进行辅助分析。

3,存在连接复用问题:连接复用
       一般情况下,如果客户端与服务器建立业务交互连接,那么可能涉及到的web服务器、应用服务器、数据库服务器之间都分别新建连接用于相关数据的交互,如下图所示: 

点击查看原图

       但是在这个情况下,一旦客户端的访问的数量非常巨大或者访问峰值时的连接非常巨大,将导致应用服务器与数据库服务器之间的连接数非常大,严重影响数据库服务器的性能,为了解决这种问题,应用服务器在与数据库服务器之间交互时,采用连接复用的方式以节省服务器的资源,提高交互的性能和效率,如下图所示: 

点击查看原图

       在这种方式下,应用服务器与数据库服务器之间只需要建立很少的连接,并将这些连接长期保持(长连接),后续的所有应用服务器与数据库服务器之间的增、删、改、查询等操作均通过已有的数条连接进行应用交互。如此大大降低了应用服务器与数据库服务器之间的连接数。

       连接复用给网络分析带来的问题是,我们不得不在数条连接中查找某个客户端具体操作对应的数据库报文,而每个数据库的连接均包含大量的数据库语句,有些是相近甚至是相同的数据库语句,这些无疑会给网络分析工作带来巨大的工作量和难度,如果同时间访问的客户端数量很多的话,这样的分析工作无异于大海捞针,基本上变得不可行了。

       上述三大难点,给我们分析多层架构的应用带来了非常大的难度,虽然如此,但是好在并不是所有的多层架构应用都是连接复用的,也不是所有的数据库交互都是加密的,如果实际工作中真的遇到了多层架构的应用需要我们进行分析,我们往往没有什么太多的选择余地,我们能做的就是尽己所能、尽力而为了。

多层架构应用的分析

       针对多层架构的业务应用的分析,我们一般按照如下的思路开展网络分析工作:

1, 关键路径多点同时捕包
       要针对多层架构的业务应用进行分析,必须在业务数据交互路径中的每个关键点进行捕包,以便后续的关联分析和对比分析。这个在我的文章《疑难网络故障的分析方法和原理之对比分析法》中介绍得非常清楚,大家可以访问http://www.vants.org/?post=49参考。
       在多层架构的应用中,我们主要需要在客户端与Web服务器之间、Web服务器与应用服务器之间、应用服务器与数据库服务器之间同时进行业务交互报文的猜忌和捕获,如下图所示: 

点击查看原图

2, 捕包机器时间同步
       一般而言,我们可以通过NTP服务器将多台捕包机器的时间同步,但如果在条件不允许的情况下,大家可参考我的文章《如何保证中间设备两端捕获的数据包的时间同步性?》中提供的简单有效的方法来实现不同关键点捕包时间的同步,如下图所示: 

点击查看原图

       在各个关键路径上的捕包机器时间都同步了,那么在大部分的情况下,我们就可以根据连接或报文发生的时间段在海量业务交互报文中提取跟业务操作相关的报文进行关联分析,从而提高关联的分析的效率。

3, 关联分析
       一旦全部准备就绪,那么剩下的工作就是根据不同位置捕获到的业务交互报文,利用应用层字段,如cookie值、sessionID、用户名、帐号、Userid、业务号、单号、ProcessID等关键字实现客户端<->Web服务器、Web服务器<->应用服务器、应用服务器<->数据库服务器之间的关联。下面我选取了部分在实际工作中遇到的多层架构应用中可关联的关键字截图以供参考: 

点击查看原图

点击查看原图

点击查看原图

参考资料:
1,海万学——《多层结构应用性能分析与故障诊断》
       海万学是国内为数不多的网络分析方面的专家,其个人博客为:www.packetstory.com,就是更新有点慢,大家可关注。
2,gqming——《多层结构应用各层之间数据传递的问题》链接为http://bbs.csdn.net/topics/190123492

阅读全文>>

标签: 同步 日志 网络分析 对比分析法 应用字段 关联分析 C/S 多层架构 连接复用 cookie 时间同步 B/S 三层架构

评论(0) 引用(0) 浏览(12600)

网络分析能力修行模型

作者:易隐者 发布于:2012-11-14 20:53 Wednesday 分类:网络分析

概述
       数次应业内朋友之邀,为其团队培训网络分析技术,从第一次开始,我就着手架构这个能力修行模型的框架,但还不够完善和成熟。随着我对网络分析技术理解的深入和本身水平的提升以及培训次数的增加,我不断的将其完善,并最终形成现在的雏形。

       根据这个网络分析能力修行模型,初学者可以清晰了解如何入手学习网络分析技术,并按部就班、循序渐进的提升网络分析技术的能力水平。

       所谓“道可顿悟,术需渐修”,但愿此文能够成为诸位网络分析初学者“悟道”的法门。

络运行的本质

       网络运行的本质是什么?是数据报文与协议。 

点击查看原图

       数据报文是网络运行世界里,具有完整信息的、最小的组成单元,而协议则是数据报文在网络内交互必须遵循的规则。因此掌握了这两者,基本上就可以把握网络运行的本质。

       网络分析技术将数据报文和协议完美的结合起来,因此网络分析技术通常也被叫做协议分析、数据包分析或报文分析。那么网络分析到底是如何工作的呢? 

点击查看原图

       网络分析技术是通过捕获网络通讯过程中的数据包(数据包是网络通讯过程中有意义的、最小的组成单元),并通过对捕获到的数据包进行深入的统计和分析,从而洞穿网络各个层面(包括性能、安全、业务以及故障等)运行情况的一种技术。
       通过网络分析技术,我们可以轻松透视网络运行的本质,如果我们的网络分析技术能力非常强,我们的技术水平会远远超出那些只精通于具体设备的工程师们,成为名副其实的网络层面的专家,那么我们如何修行才能提升自己的网络分析技术呢?下面我将通过网络分析能力修行模型展开详细介绍。

网络分析能力修行模型

       我将自己的成长经验总结为下图所示的网络分析能力修行模型: 

点击查看原图

       在这个模型中,围绕网络分析能力的提升,主要包含以下四方面的内容:

 基础

       古语云“千里之行始于足下”、“万丈高楼平地起”。做任何事情都离不开基础,网络分析技术能力的提升同样需要牢固扎实的技术基础作为支撑。

 工具
       古语云“巧妇难为无米之炊”。工具可以帮助我们事半功倍,大大提高我们的工作效率,没有称手的工具,纵然你有一身本领,却难免陷入纷繁复杂的二进制世界难以自拔。

 方法
       古语云“砍柴不照纹,累死砍柴人”。有基础有工具却不得法,虽可解决一些常见问题,但往往是随性而起,难以为继。即使大部分情况下你能成功解决问题,也只能说明你的运气和感觉都还不错,但是你无法将你的运气和感觉传递给你的团队、学生及他人。简言之:无章法,不足道。

 案例
       古语云“纸上得来终觉浅,绝知此事要躬行”。基础牢靠、精通工具、掌握方法,这已经为我们践行网络分析技术做好充分的准备,我们需要在实际工作环境中,把握任何机会,践行自己的网络分析技能,在利用网络分析技术解决问题之后,不断总结,并形成文档;另外一条践行的捷径是讨论学习他人的案例,将他人的经历经验借鉴过来为己所用,在短时间内快速提升自己。总之,多践行,多总结,多学习。

       根据这个网络分析能力修行模型,我将网络分析技术的学习和提升分为四个阶段,如下图所示: 

点击查看原图

第一阶段:打好基础
       这个阶段较为漫长,并且会一直持续伴随整个学习成长的过程。一般而言,这个阶段主要是学习网络基础、各种网络和安全设备的工作原理和机制、不同系统或设备的报文处理流程、TCP/IP协议体系、各常见应用等。在这个阶段,大部分是通过自主学习来获得提升的。

第二阶段:熟悉工具
       在扎实的技术基础上,熟练掌握1-2种网络分析的工具,不会花费太多的时间,但是如想成为高手,必须充分理解各种常见工具的优势特点,学会在不同的情况下,选择性的综合利用这些工具的优势特性,提高我们解决问题的效率。

第三阶段:掌握方法
      掌握网络分析的常规思路,深入理解网络分析方法的原理和使用场景,能够在实际工作环境下,按照网络分析方法和思路展开网络分析工作。

第四阶段:践行案例
       综合利用已学知识和掌握的方法,不断通过实际案例践行网络分析技术,以及对他人案例的学习,让自己的网络分析技术得以快速提升和升华。

       这四个阶段在大的学习和提升方向上是线序的,但这并不是绝对的,比如我们既可以借助他人的案例加固基础知识,又可以在实际案例中提升工具使用的熟练度,也可以利用网络分析工具学习协议体系……

网络分析能力修行模型不同阶段的学习资料

       在我的个人博客蚂蚁网——www.vants.org中,基本涵盖了网络分析能力修行模型中各个阶段学习的内容,下面我将各个阶段的资料做一个统一整理,方便初学者学习参考。

网络分析基础

防火墙的状态检测 http://www.vants.org/?post=24
应用层检测/深度包检测(DPI)http://www.vants.org/?post=23
TCP异常终止(reset报文)http://www.vants.org/?post=22
TCP重传 http://www.vants.org/?post=36
ICMP重组超时 http://www.vants.org/?post=35
TCP SACK选项 http://www.vants.org/?post=74
传输层的响应时间(系统层响应时间/服务器响应时间)http://www.vants.org/?post=115
关于防火墙的arp代理功能对不同格式的arp报文的处理情况的实验 http://www.vants.org/?post=121
ARP代理(Proxy ARP)http://www.vants.org/?post=119
免费ARP(gratuitousARP)http://www.vants.org/?post=118
ARP表的更新和老化http://www.vants.org/?post=120
第三方延时http://www.vants.org/?post=117
应用响应时间(ART)http://www.vants.org/?post=116
ICMP通讯管理性过滤禁止差错报文(type 3,code 13)http://www.vants.org/?post=127
连接数相关知识http://www.vants.org/?post=126
TCP/IP 应用程序的通信连接模式http://www.vants.org/?post=182
TCP保活(TCP keepalive)http://www.vants.org/?post=162
多次RST以及不同场景下的RST报文的差异http://www.vants.org/?post=141
端系统对RST报文的过滤http://www.vants.org/?post=140
经受时延的确认(Delay ACK)http://www.vants.org/?post=114
TCP MSS与PMTUD http://www.vants.org/?post=109
IP分片(IP Fragment) http://www.vants.org/?post=106
TCP 的PUSH标志位http://www.vants.org/?post=102
TCP交互式应用http://www.vants.org/?post=101
基于UDP的应用如何保证应用数据的可靠性http://www.vants.org/?post=99
关于“client push”应用响应时间测量方法的讨论http://www.vants.org/?post=30
iPhone与Multicast DNS        http://www.vants.org/?post=130
非标准TCP三次握手建立连接过程一例http://www.vants.org/?post=91
ACK flood攻击的影响http://www.vants.org/?post=136
基于UDP组播实施分片攻击的可能性http://www.vants.org/?post=98
关于防火墙访问控制的疑问http://www.vants.org/?post=26
TCP/IP 数据包处理路径 http://www.vants.org/?post=188

网络分析工具

常见网络分析工具特色功能简介及其在实际工作中的应用之缘起 http://www.vants.org/?post=43
常见网络分析工具特色功能简介及其在实际工作中的应用之Network Monitor http://www.vants.org/?post=41
常见网络分析工具特色功能简介及其在实际工作中的应用之Omnipeek  http://www.vants.org/?post=66
Wireshark对ping报文的解码显示(BE与LE)http://www.vants.org/?post=133
利用科来与IDS Informer构建网络攻击学习平台http://www.vants.org/?post=31

网络分析方法

疑难故障分析常规流程和思路http://www.vants.org/?post=27
疑难网络故障的分析方法和原理之对比分析法http://www.vants.org/?post=49
疑难网络故障的分析方法和原理之关联分析法http://www.vants.org/?post=51
如何跟踪分析数据经过中间设备后的变化以及这些变化给客户端与服务器带来的影响http://www.vants.org/?post=93
一切皆有可能http://www.vants.org/?post=122
异常流量分析方法——发现-定位-管控http://www.vants.org/?post=185
如何保证中间设备两端捕获的数据包的时间同步性?http://www.vants.org/?post=50

网络分析案例

视频点播服务间歇性中断故障分析案例http://www.vants.org/?post=73
访问搜狐163时主页变为2008年某日主页面故障分析案例http://www.vants.org/?post=89
某学院专网网站打开慢故障分析案例http://www.vants.org/?post=92
FTP登陆故障分析http://www.vants.org/?post=103
某单位经过CA认证的业务应用访问缓慢故障分析案例http://www.vants.org/?post=104
网页打开慢但HTTP下载快故障分析案例http://www.vants.org/?post=128
某业务系统由于连接数限制导致间歇性访问慢故障分析案例http://www.vants.org/?post=125
数据包中出现超长帧的分析http://www.vants.org/?post=184
关于vista系统机器无法通过防火墙上网的故障分析解决案例http://www.vants.org/?post=124
关于服务器端发送FIN报文之前的数秒等待时间行为的分析http://www.vants.org/?post=95
大包传输丢包故障http://www.vants.org/?post=34
两台soho级小路由之间的“正义”之战http://www.vants.org/?post=163
某加密机经天融信防火墙后应用异常故障案例http://www.vants.org/?post=107
负载均衡故障诊断:一个MSS值引发的疑案http://www.vants.org/?post=110
关于网内抓包出现0.33.216.220IP地址问题的分析http://www.vants.org/?post=88
F5负载均衡环境下某应用故障分析案例http://www.vants.org/?post=65
某地税网上申报业务系统故障分析报告http://www.vants.org/?post=58
高新区房产局房产管理业务故障分析解决报告http://www.vants.org/?post=32
某部队部分网段访问总部网站故障分析案例http://www.vants.org/?post=25
IPS在线升级故障分析案例http://www.vants.org/?post=16
使用Omnipeek分析SSH端口攻击案例http://www.vants.org/?post=134
针对随机组播地址的ping攻击案例http://www.vants.org/?post=132
基于UDP 7000端口的DOS攻击案例http://www.vants.org/?post=131
基于UDP 80端口的DOS攻击案例http://www.vants.org/?post=113
可能的数据库密码猜解行为http://www.vants.org/?post=84
PHP漏洞扫描—morfeus fucking scanner  http://www.vants.org/?post=67
web站点cookie安全问题一例http://www.vants.org/?post=64

阅读全文>>

标签: 同步 状态检测 TCP异常终止 团队 IDS Informer 网络分析 数据包分析 协议分析 网络分析能力修行模型

评论(21) 引用(0) 浏览(27659)

某学院专网网站打开慢故障分析案例

作者:易隐者 发布于:2012-8-19 16:58 Sunday 分类:网络分析

故障环境

       某学院的网络拓扑示意图如下所示:

点击查看原图


         说明:
         核心交换机上划分了多个VLAN,防毒墙、防火墙均工作在透明模式下,路由器工作在纯路由模式下。

故障现象
        用户在内网打开专网的网页速度很慢,经常需要5-20秒左右才可以完全打开,有时直接就打不开。

故障分析

1 故障分析说明

       首先通过故障现象,我们可以确认该故障应该属于一个较为高级的故障,这种故障一般都与网络中的延时或者丢包有关,难以通过一些基本的测试或策略的检查来定位故障,我们需要进行一些深度的分析。针对此类延时或丢包故障,我们需要做的就是定位出产生延时或丢包的位置。

点击查看原图

阅读全文>>

标签: 交换机 TCP 网络分析工具 网络分析 数据包分析 对比分析 get 网络慢

评论(5) 引用(0) 浏览(10264)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1