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

某业务系统由于连接数限制导致间歇性访问慢故障分析案例

作者:易隐者 发布于:2012-9-26 18:05 Wednesday 分类:网络分析

【说在之前】:

1,该案例为端系统设置连接数限制导致的应用间歇性缓慢故障,在实际工作环境下,我们更容易遇到的是中间系统对连接数限制导致的一些范访问异常,令人头疼的是,并不是所有开启连接数限制功能的中间系统在丢包后都会向源主机发送ICMP差错报文,这会给大家分析定位带来难度,大家在实际工作中需要留意;

2,该案例涉及到的知识点主要为“ICMP主机管理性禁止差错报文”和“连接数限制”,关于ICMP主机管理性禁止差错报文,大家可参考本博客《ICMP通讯管理性过滤禁止差错报文(type 3,code 13)》一文,虽然“type 3,code 10”与“type3,code 13”有些差异,但是差别不大,可以借鉴;关于连接数相关知识点,大家可参考本博客《连接数相关知识》一文;

【我的案例】:

1 故障环境

网络拓扑:

点击查看原图


说明:
1,内部办公机器都是192.168.1.0/24段的,内部办公主机通过防火墙做NAT,转换为X.X.X.138访问互联网;
2,内部办公服务器的地址为192.168.1.191,其通过防火墙映射为公网地址X.X.X.139对外提供6888端口的web服务。
业务访问流程:
       内部办公机器都是通过NAT后的公网地址X.X.X.138访问办公服务器的公网地址X.X.X.139。其流程如下图所示: 

点击查看原图


2 故障现象

       故障现象主要表现为:
1,部分内网办公主机经常出现打开主页慢、登录慢或者某些页面不显示的情况,如下图所示: 

点击查看原图

打开主页时的长时间等待页面截图 

点击查看原图

登录时长时间等待页面截图

2,这些故障现象间歇性出现,有时多刷新几次页面后,打开的速度会恢复正常。
3,外网用户访问业务系统一直正常,该故障已经持续数月。

3 故障分析

       通过故障现象,我们可以看出,这是比较典型的部分系统出现问题的案例,由于其不具备全体的故障特征,又是间歇性的发生,因此,此类故障按照常规的分析方法很难找到真正的故障原因,我们还是先在客户端抓取一下故障时交互的数据包,站在数据包的角度来分析一下可能的原因。
1,找一台出现故障的主机192.168.1.167,捕获其打开主页面缓慢时的数据包。
2,查看缓慢时的数据交互情况,如下图所示: 

点击查看原图

       我们通过delta tima值可以看到,这个交互的过程存在较大的延时,并且我们发现,在交互的过程中存在数个“ICMP主机通讯管理性禁止”的差错报文,这些报文都是X.X.X.139发给故障主机192.168.1.167的。
3,我们双击其中一个ICMP主机通讯管理性禁止报文,查看其封装的被过滤的原报文相关信息,如下图所示:

点击查看原图

       我们发现,被X.X.X.139管理性过滤掉的报文是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文。
4,我们再结合上下数据包交互的情况,我们可以发现,这个ICMP主机通讯管理性禁止报文的前一个报文正是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文,如下图所示: 

点击查看原图

       这充分说明当故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求时,被服务器管理性过滤禁止了。
5,那么服务器为什么会管理性禁止故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求报文呢?难道服务器上设有针对源端口为4075的禁止访问策略吗?服务器显然没有做这种针对源端口过滤的必要,另外,我们还发现除了故障主机以源端口4075访问服务器的SYN报文被管理性禁止外,还有其他源端口的SYN请求报文被服务器管理性禁止,如下图所示: 

点击查看原图

       这里被服务器禁止的报文的源端口有4078、4083、4086等。
       另外,通过上图中的“delta time”值,我们也可以发现正是这些报文导致了故障主机在建立新的TCP连接之前花费了数秒的连接建立尝试时间(SYN重传时间,大家可参考本博客《TCP重传》一文),从而导致了页面打开缓慢的现象出现。
6,这个现象具有明显的针对TCP的随机性的过滤特性,因此,我们很容易就可以联想到是否是服务器在TCP传输层存在某些检测过滤机制?而在传输层最为常见的就是TCP连接数限制了。
       一般而言,在服务器上实现针对单IP访问服务器的TCP连接数进行限制是一件简单的事情,一个独立的IP只允许与服务器建立少量的TCP连接,这对于那些对外提供服务的服务器来说是一种较为常见的防护措施,在正常情况下,单个客户端与服务器的正常交互所需要的TCP连接数并不是很多,而限制的数值一般都会高于正常的需求,但是在有些情况(如经过NAT或代理后对业务的访问)下,这将导致问题的产生。
7, 上述推理非常合理,我们通过检查服务器的相关设置,验证了我们的分析和推论结果。
8, 分析结论:
       这个故障是由于业务服务器端设置了针对单IP访问连接数限制功能,而内部办公网主机都是通过防火墙NAT地址转换后对业务服务器进行访问,这直接导致在业务访问高峰时,出口NAT IP地址访问业务服务器的连接数超出限制,业务服务器对后续的TCP连接建立请求发出ICMP差错报文,等一些TCP连接释放后,才允许新建TCP连接,这导致访问业务系统非常缓慢。并且这种特性决定了故障现象表现为间歇性发生。

4 故障解决

       通过修改服务器Apach对单一IP地址的连接数的限制后,故障得到解决。

阅读全文>>

标签: 疑难故障 TCP icmp差错 SYN 连接数 NAT 地址转换 业务慢 连接数限制 ICMP主机管理性禁止差错报文 Type 3 Code 13 type 3 code 10

评论(2) 引用(0) 浏览(11298)

Wireshark对ping报文的解码显示(BE与LE)

作者:易隐者 发布于:2012-9-25 17:34 Tuesday 分类:网络分析

        我们非常熟悉ping报文的封装结构,但是,在这个报文解码里,我们发现wireshark的解码多了几个参数:Identifier(BE)、Identifier(LE)、Sequence number(BE)、Sequence number(LE),如下图所示: 

点击查看原图

       以前一直未注意wireshark是这样解码ping报文的,感觉非常奇怪,我们先来仔细的看一下wireshark对ping报文中这几个参数的解码情况:

点击查看原图

点击查看原图

点击查看原图

点击查看原图

         Wireshark解码显示,Identifier(BE)与Identifier(LE)都对应“hex 0200”,Sequence number(BE)与Sequence number(LE)都对应“hex 027b”,仔细看的话,我们能够发现BE值(0x0200)与LE值(0x0002)之间的差别就是顺序不一样。那到底BE、LE是指什么呢?搜遍百度无果,决定还是去wireshark官网看看,结果发现下面链接的内容:http://www.wireshark.org/lists/wireshark-bugs/200909/msg00439.html,其中有一段是这样描述的:

“After I discovered that the Windows ping sends ICMP echo request packets with the sequence number in little-endian byte order, but the Linux ping sends it in proper big-endian format, a discussion about it took place on the mailing list as to how to handle it (refer to  http://www.wireshark.org/lists/wireshark-dev/200909/msg00216.html).  However,to keep things simple and avoid adding any new ICMP preferences and/or trying to guess at the byte order, I thought why not just display the sequence number in both formats, so that's what this patch does.”

       我来做个总结:wireshark考虑到window系统与Linux系统发出的ping报文(主要指ping应用字段而非包含IP头的ping包)的字节顺序不一样(windowsLElittle-endian byte orderLinuxBEbig-endian),为了体现wireshark的易用性,开发者将其分别显示出来。

       Wireshark的牛B之处,由此细节可见一斑!

阅读全文>>

标签: wireshark 解码 ping BE LE little-endian big-endian

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

针对随机组播地址的ping攻击案例

作者:易隐者 发布于:2012-9-25 11:22 Tuesday 分类:网络安全

       前段时间,某兄弟在用户处遇到一个问题,说是在无线环境下,生产系统中的条码系统经常卡机,迟迟难以定位,网上找到我,并将报文发给我,让我帮忙看看。
       根据他的描述,一开始我以为是个应用系统故障,准备建议其在生产客户端与服务器端同时抓包做对比分析,后来仔细看起报文时,发现了一个主机针对随机的组播IP地址发送ping请求报文,如下图所示: 

点击查看原图

我们查看其中某个报文的解码: 

点击查看原图

       这个主机的网络交互行为特征大致有以下几点:

1,该主机发送了大量的ping报文,但是正常情况下,生产主机不会发送跟生产业务无关的报文,包括ping报文;
2,ping报文的目的地址都是随机的组播地址;
3,ping组播地址的发包频率虽有变化,但是其发包高峰时可以达到毫秒以内的时间间隔

       结合上述三点,我们可以确定为该主机异常行为。

       主机对多播报文的处理流程决定了网内过多的多播报文会对主机和网络性能带来严重的影响。而目前这个很可能只是大规模爆发之前的预演,发包时间间隔较为随机,有些是几毫秒,有些几十秒,真正爆发时,以该数据包文件来看,这台主机可以做到每秒数万的报文,到时候,估计将会出现全网瘫痪的现象。

       一台机器足以单挑一个的网络了! 

阅读全文>>

标签: 组播 多播 ping 攻击 行为特征 发包频率 随机组播地址

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

【转】某加密机经天融信防火墙后应用异常故障案例

作者:易隐者 发布于:2012-9-24 14:10 Monday 分类:案例讨论

【写在前面】:

1,该案例是一个特殊应用、特殊环境下的疑难故障案例,给我们的启示是在故障现场,我们需要充分了解清楚跟故障有关的应用特性,比如此案例中的加密机的工作机制;

2,该案例涉及到以下知识点:IP报头校验和、IP分片(请参考本博《IP分片》一文)、防火墙对分片报文的处理等;

3,此案例在整理文档时,应该简化了很多的分析测试过程,我按照我的理解做一些梳理:

(1),IP报头校验和只跟IP报头有关,跟IP封装的数据无关,因此,如果原文中的描述的“收到报文是否进行校验和检查”是指IP报头检验和的话,那么应该不会存在校验和错误而被防火墙丢弃的问题,如果是指TCP校验和或UDP检验和的话,那么,每个来自于加密机的报文其TCP或UDP校验和都是错误的(因为多了33字节),因此防火墙肯定会直接丢弃这个报文,根本不存在文档中描述的在防火墙转发接口抓到1460字节数据包的情况;

(2),防火墙不对收到的报文进行校验和计算,那么这个报文才会进入防火墙的内核处理流程,因为来自于加密机的报文是IP分片报文,因此防火墙会对此分片报文进行处理(选择直接转发分片报文还是重组后匹配策略再转发),如果防火墙直接转发,则没什么问题,如果是重组转发,这里就存在一个问题:防火墙能否完成这个报文的重组?因为IP分片的重组是根据IP报头中的相关信息来完成的,其中非常重要的一个参数就是分片偏离量,这个值决定了分片报文在原始报文中的位置,而在这个故障环境下,每个报文都被加密机在尾部添加了只有加密机能够识别的特征码,防火墙并不能识别,那么防火墙在重组这些报文的时候,如何处理正常分片报文跟前一分片报文尾部添加的33字节部分的重叠呢?这是值得思考的。如是覆盖33字节的尾部识别码,则到达对端加密机后,加密机会丢弃这个报文,并不是因为文中所说的“认为加密数据被篡改”,而是由于被覆盖了数个识别码导致接收端加密机无法正常识别加密报文(篡改的识别是通过校验和得到的,接收方根据报头信息可以计算出校验和,也就是说只要报头信息没错,校验和就不会错,而防火墙在重组完毕后转发前肯定会重新计算转发报文的报头校验和)。

4,各位读者兄弟根据自己的理解,自由参考我上面的分析和下面的案例原文,欢迎探讨和交流。

【原文全文】:

一、拓扑 

点击查看原图


二、环境描述

       该拓扑使用的VPN链路是某公司的产品,该VPN在做加密处理时,TCP头和IP头都不做加密,只对数据区做加密,通过在加密机的抓包,发现加密机把所有MTU大于1300的数据包做了分片处理,并且在所有包的末尾加入自己的N字节加密识别码,这样从加密机发出的数据包MTU值最大1333,对于大于1333的报文(如1460)的数据包加密机都是分2个包进行传送,在没接防火墙时一切正常,接入防火墙后导致访问不正常;
       拓扑中客户端172.16.1.22在访问服务器172.16.1.33时,服务器回应的MTU值1460数据包被服务器端加密机拆成2个包(第一个包1300),并在每个包的末尾加入33位,而防火墙在接收时将两个包合并转发,具体表现为防火墙接收口(接服务器端加密机)收到的报文数据长度是1333,而转发口(接客户端加密机)转发的报文数据长度是1460,这样客户端加密机就认为加密数据被篡改,导致VPN加密通讯错误;

三、分析过程与解决方式

1、 由于加密机的特殊性,所以加密封包后的数据在通过防火墙时,会被认为是错误报文,
解决方法:将防火墙“选项设置”---“安全设备系统参数”---“系统参数开关”下的“收到报文进行是否效验和检查”选项取消,如下图所示 

点击查看原图


2、 加密机对大于1300的数据包做分片处理,到防火墙时,发现数据是分片包,防火墙又给重组后转发,导致对端加密机认为数据被篡改,不再对该数据包做解密处理;
解决方法:启用防火墙中的分片处理,将经过防火墙的数据都不做分片重组处理;
3、 以上两点设置好后,TCP报文可以正常通讯,但UDP报文(如视频报文)由于数据量大的缘故在通过防火墙时,经常丢包;
解决方法:研发根据该问题给了一个特殊的补丁,专门解决UDP报文处理的,只要打上该补丁即可;

四、总结

1、 将防火墙“选项设置”---“安全设备系统参数”---“系统参数开关”下的“收到报文进行是否效验和检查”选项取消;
2、 启用防火墙中的分片功能,将经过防火墙的数据都不做分片重组处理;
3、 打上专用的补丁;

阅读全文>>

标签: ip分片 天融信 分片 防火墙 重组 校验和 IP报头检验和

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

基于UDP 7000端口的DOS攻击案例

作者:易隐者 发布于:2012-9-24 11:12 Monday 分类:网络安全

       在某某用户现场捕获到基于UDP 7000端口实施DOS攻击的报文。

我们简单的看一下大致的分析过程:

1,通过对报文的统计,我们可以看出流量较大,平均包长1266.6字节,大包居多: 

点击查看原图

2,我们查看数据包交互情况,发现基本上都是192.168.218.112的5444端口发往121.10.173.106的UDP 7000端口的报文,这些报文大小都是1070字节,IP标识逐步递增,在15秒的时间内发送了12192个UDP报文: 

点击查看原图

3,我们查看其UDP封装的应用字段,发现全部为“AAAAAAAAAAA”的无意义填充数据: 

点击查看原图

小结:
       无论是基于什么端口的,大部分的基于UDP的攻击都是利用UDP无连接的特性,向被攻击者发送大流量的垃圾报文,导致被攻击者的网络带宽资源被占用,造成拒绝服务的攻击效果,这个案例当然也不例外。 

阅读全文>>

标签: UDP 拒绝服务攻击 DOS DOS攻击 UDP 7000端口

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

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