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

端系统对RST报文的过滤

作者:易隐者 发布于:2012-10-8 17:00 Monday 分类:网络分析

       前段时间在分析网上一个兄弟传给我的报文时,发现了几个有意思的现象,我觉得值得分析讨论,我们首先来看一个服务器与客户端交互的会话: 

点击查看原图

       在这个交互的过程中,我们可以看到一个比较奇怪的现象,那就是客户端10.16.137.56在收到来自服务器的FIN报文之后,紧接着向服务器端发送RST报文,但是服务器给其回应了一个ICMP主机管理性禁止差错报文,并且不断尝试向服务器发送FIN报文。
       我们来看一下服务器给客户端回应的ICMP主机管理性禁止差错报文的解码: 

点击查看原图

       Type 3,Code 10——主机管理性禁止差错,其封装的原始报文报头信息显示,该ICMP差错报文正是由客户端发往服务器端的RST报文引起的。下图为客户端发往服务器端的RST报文解码: 

点击查看原图

       另外,我们注意到,服务器发送给客户端的ICMP差错报文的TTL值为48,而服务器端发送给客户端的FIN报文报头中的TTL值也是48,如下图所示: 

点击查看原图

       这从侧面说明这个ICMP差错报文的确是服务器端系统发送的,而不是中间设备发出的。

       那么为什么服务器端系统会过滤掉客户端的RST报文呢?

       想想TCP会话劫持和TCP RST攻击,大家就能够体会,服务器管理员为什么这么做了。

       TCP会话劫持的实施者经常会扮演对端的身份分别向客户端或服务器端发送RST报文,以达到干扰客户端与服务器端正常交互的目的。有些服务器的管理员可能遇到过这种TCP会话劫持的攻击,因此在服务器端系统上利用相关工具设置了过滤RST报文的策略,当服务器收到RST报文时,直接忽略掉,因此服务器端系统的传输层并不会收到这个RST报文。

       其交互过程大致如下图所示:

点击查看原图

过滤RST报文可能带来的影响

       服务器传输层无法收到客户端的RST 报文,只能在多次尝试重传FIN报文直至超时,然后主动向客户端发送RST报文。如此带来的影响就是执行过滤策略的端系统无法正常处理来自于TCP连接对端的异常释放行为(RST),这将导致端系统的TCP连接释放需要更长的时间,在有大量对端通过RST报文异常释放TCP连接的场景下,可能会对性能产生一定的影响。

阅读全文>>

标签: TCP RST icmp差错 会话劫持 TTL FIN type 3 code 10 端系统

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

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

作者:易隐者 发布于: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) 浏览(17264)

ICMP通讯管理性过滤禁止差错报文(type 3,code 13)

作者:易隐者 发布于:2012-9-20 20:10 Thursday 分类:网络分析

ICMP通讯管理性禁止差错报文的产生

       ICMP通讯管理性禁止差错报文是由于中间设备或服务器对该报文的禁止访问策略而产生的,当一个报文经过某中间设备或达到服务器时,如果中间设备或服务器的管理策略禁止该报文的通过,那么,中间设备或服务器会生成一个目的地址为客户端的ICMP通讯管理性禁止报文,其产生过程如下图所示:

点击查看原图

ICMP通讯管理性禁止差错报文产生过程

ICMP通讯管理性禁止差错报文的封装

        ICMP通讯管理性禁止差错报文的封装格式如下图所示: 

点击查看原图


ICMP通讯管理性禁止差错报文的封装(wireshark)

ICMP通讯管理性禁止差错报文在实际网络分析中的作用

       由ICMP通讯管理性禁止差错报文产生的机制决定了其可以帮助我们快速地发现数据报文被丢弃的位置和原因,从而大大提高了我们定位、解决问题的效率。
       但是,ICMP通讯管理性禁止差错报文也是一把双刃剑,它也可以帮助黑客判断一些安全防护设备的策略和位置,正是基于这种考虑,有时一些设备不发送这种ICMP通讯管理性禁止差错报文。

阅读全文>>

标签: icmp差错 ICMP Type 3 Code 13 ICMP通讯管理性禁止差错

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

TCP MSS与PMTUD

作者:易隐者 发布于:2012-9-6 19:16 Thursday 分类:网络分析

 

       一旦DF位置一,将不允许中间设备对该报文进行分片,那么在遇到IP报文长度超过中间设备转发接口的MTU值时,该IP报文将会被中间设备丢弃。在丢弃之后,中间设备会向发送方发送ICMP差错报文。
为了简单直观的展示这个交互的过程,我做了下面这个图示: 

点击查看原图


       我找了一个实际环境下捕获的ICMP需要分片但DF位置一的差错报文,下图为其解码格式: 

点击查看原图


       我们可以看到其差错类型为3,代码为4,并且告知了下一跳的MTU值为1478。在ICMP差错报文里封装导致此差错的原始IP报文的报头(包含IP报头和四层报头)。

       一旦出现这种因DF位置一而引起丢包,如果客户端无法正常处理的话,将会导致业务应用出现异常,外在表现为页面无法打开、页面打开不全、某些大文件无法传输等等,这将严重影响业务的正常运行。
那么客户端如何处理这种状况呢?
TCP主要通过两种方式来应对:
1, 协商MSS,在交互之前避免分片的产生
2, 路径MTU发现(PMTUD)

TCP MSS

       TCP在三次握手建立连接过程中,会在SYN报文中使用MSS(Maximum Segment Size)选项功能,协商交互双方能够接收的最大段长MSS值。
       MSS是传输层TCP协议范畴内的概念,顾名思义,其标识TCP能够承载的最大的应用数据段长度,因此,MSS=MTU-20字节TCP报头-20字节IP报头,那么在以太网环境下,MSS值一般就是1500-20-20=1460字节。
客户端与服务器端分别根据自己发包接口的MTU值计算出相应MSS值,并通过SYN报文告知对方,我们还是通过一个实际环境中捕获的数据报文来看一下MSS协商的过程:

点击查看原图

       这是整个报文交互过程的截图,我们再来看一下客户端的报文详细解码: 

点击查看原图

       上图为客户端的SYN报文,在其TCP选项字段,我们可以看到其通告的MSS值为1460;我们在看看服务器端的SYN/ACK报文解码: 

点击查看原图


       上图为服务器端给客户端回应的SYN/ACK报文,查看其TCP选项字段,我们可以发现其通告的MSS值为1440。

       交互双方会以双方通告的MSS值中取最小值作为发送报文的最大段长。在此TCP连接后续的交互过程中,我们可以清楚的看到服务器端向客户端发送的报文中,TCP的最大段长度都是1440字节,如下图解码所示:

点击查看原图

       通过在TCP连接之初,协商MSS值巧妙的解决了避免端系统分片的问题,但是在复杂的实际网络环境下,影响到IP报文分片的并不仅仅是发送方和接收方,还有路由器、防火墙等中间系统,假设在下图的网络环境下: 

点击查看原图

       中间路径上的MTU问题,端系统并不知道,因此需要一个告知的机制,这个机制就是路径MTU发现(PMTUD: Path MTU Discovery )!

PMTUD

       说起PMTUD,我们必须在此回到上面讲到的ICMP需要分片但DF位置一差错报文,还记得那个ICMP差错报文中有一个字段是告知下一跳的MTU值的吗?PMTUD正是利用ICMP需要分片但DF位置一差错报文的这一特性来实现的。
       发送方在接收到该差错报文后,会根据该报文给出的下一跳的MTU值计算适合传输的最大段长度,从而在后续的发送报文过程中,避免在中间路径被分片的情况产生。
       这在端系统主要是通过在路由表里临时添加目的主机路由并将ICMP差错报文告知的下一跳MTU值跟该主机路由关联起来来实现。
       PMTUD的确是个非常不错的机制,但是在复杂的实际网络环境中,有时候会失效,因为为了安全起见,有些网络管理员会在路由器、防火墙等中间设备上设置过滤ICMP报文的安全策略,这将导致ICMP差错报文被这些中间设备丢弃,无法达到发送方,从而引起PMTUD的失效,网上有个宫一鸣前辈共享的案例——《错误的网络访问控制策略导致PMTUD 实现故障一例》,该案例正是说明这种情况绝好的例子,大家可以自行百度此文档学习参考。

       值得一提的是PMTUD仅TCP支持,UDP并不支持PMTUD。

       由于PMTUD可能存在ICMP差错报文被过滤的情况,很多中间设备的接口支持adjust tcp mss设置功能,思科路由器一般是在接口模式下使用命令“ip tcp adjust-mss 1400 ”来做设置,其他的品牌产品的相关设置大家可在实际工作环境下自查相关品牌和产品的使用手册。

        这个功能主要是通过由中间设备修改经过其转发的TCP SYN报文中的MSS值,让中间设备参与进TCP 三次握手时SYN报文的MSS协商来避免分片。

       需要注意的是,该功能不像MTU值,只针对出接口,此功能一旦开启,其将针对该接口的收发双向有效。
我做一个简化环境下的工作过程图示以便于大家理解其工作过程:

点击查看原图

阅读全文>>

标签: TCP icmp差错 分片 SYN TCP选项 UDP MTU ICMP PMTUD MSS

评论(4) 引用(0) 浏览(33912)

IP分片(IP Fragment)

作者:易隐者 发布于:2012-9-3 22:22 Monday 分类:网络分析

为什么要分片

       不同的链路类型能够支持的最大传输单元值(MTU: Maxitum Transmission Unit)主要是由相关RFC文档规定的,常见的以太网链路的MTU值为1500,如果需要转发的IP报文超出其转发接口的MTU值,则在转发该报文之前,需要将其分片,分为多个适合于该链路类型传输的报文,这些分片报文在到达接收方的时候,由接收方完成重组。

       各种常见链路类型的MTU值如下图所示: 

点击查看原图


报文的分片和重组

       我们先来看一下分片的过程,为了简单起见,我就用《TCPIP详解卷一》第11章《UDP:用户数据报协议》中关于IP分片的案例,应用进程将1473字节应用字段交给UDP处理,UDP加上8字节的UDP报头之后,交给IP层处理,IP层在转发之前,发现该报文长度超出转发接口的MTU,因此需要分片,分为两个IP分组,如下图所示: 

点击查看原图


       从上图可以看出原始的IP报文经过分片后,只有第一个分片报文是带有四层信息的,后续报文均不带四层信息,为做直观展示,我找了一个实际环境下抓取的分片报文,如下图所示: 

点击查看原图

       这是分片的第一个报文,我们可以看到该报文IP层封装的上层协议为ICMP协议,这是一个ping报文(上层协议信息),我们再来看一下后续分片报文的解码:

点击查看原图

       这是分片后续报文,我们能看到封装的是ICMP协议,但是封装的上层协议的具体信息就无法看到了。

       IP数据报被分片之后,所有分片报文的IP报头中的源IP、目的IP、IP标识、上层协议等信息都是一样的(TTL不一定是一样的,因为不同的分片报文可能会经过不同的路由路径达到目的端),不同的地方在于分片标志位和分片偏移量,而接收方正是根据接收到的分片报文的源IP、目的IP、 IP标识、分片标志位、分片偏移量来对接收到的分片报文进行重组

       接收方根据报文的源IP、目的IP、IP标识将接收到的分片报文归为不同原始IP数据报的分片分组;分片标志中的MF位(More Fragment)标识了是否是最后一个分片报文,如果是最后一个分片报文,则根据分片偏移量计算出各个分片报文在原始IP数据报中的位置,重组为分片前的原始IP报文。如果不是最后一个分片报文,则等待最后一个分片报文达到后完成重组。

分片带来的问题

1, 分片带来的性能消耗

       分片和重组会消耗发送方、接收方一定的CPU等资源,如果存在大量的分片报文的话,可能会造成较为严重的资源消耗;
       分片对接收方内存资源的消耗较多,因为接收方要为接收到的每个分片报文分配内存空间,以便于最后一个分片报文到达后完成重组。

2,分片丢包导致的重传问题

       如果某个分片报文在网络传输过程中丢失,那么接收方将无法完成重组,如果应用进程要求重传的话,发送方必须重传所有分片报文而不是仅重传被丢弃的那个分片报文,这种效率低下的重传行为会给端系统和网络资源带来额外的消耗。

3, 分片攻击

       黑客构造的分片报文,但是不向接收方发送最后一个分片报文,导致接收方要为所有的分片报文分配内存空间,可由于最后一个分片报文永远不会达到,接收方的内存得不到及时的释放(接收方会启动一个分片重组的定时器,在一定时间内如果无法完成重组,将向发送方发送ICMP重组超时差错报文,请大家参考本博客《ICMP重组超时》一文),只要这种攻击的分片报文发送的足够多、足够快,很容易占满接收方内存,让接收方无内存资源处理正常的业务,从而达到DOS的攻击效果。

4, 安全隐患

       由于分片只有第一个分片报文具有四层信息而其他分片没有,这给路由器、防火墙等中间设备在做访问控制策略匹配的时候带来了麻烦。
       如果路由器、防火墙等中间设备不对分片报文进行安全策略的匹配检测而直接放行IP分片报文,则有可能给接收方带来安全隐患和威胁,因为黑客可以利用这个特性,绕过路由器、防火墙的安全策略检查对接收方实施攻击;
       如果路由器、防火墙等中间设备对这些分片报文进行重组后在匹配其安全策略,那么又会对这些中间设备的资源带来极大的消耗,特别是在遇到分片攻击的时候,这些中间设备会在第一时间内消耗完其所有内存资源,从而导致全网中断的严重后果。

       基于以上原因,很多应用程序都尽量避免分片的产生,其通过将IP报文的分片标志中的DF位(Don’t Fragment)置一来实现,而这可能给应用带来一些难以预料的麻烦。下一篇我将介绍端系统如何处理这种状况,请大家关注。

分片补充

1,分片既有可能发生在端系统(发送主机)上,也可能发生在转发报文的路由器、防火墙等中间系统上
2,分片只发生在转发出接口上

跟分片有关的案例

        后续我会在本博客里添加一些跟分片有关的案例,有兴趣的同学可关注。

阅读全文>>

标签: ip分片 重组超时 IP标识 icmp差错 分片 ip fragment IPID UDP 分片攻击 分片偏移量 DF位 MF位 MTU 重组 fragment ICMP

评论(6) 引用(0) 浏览(94415)

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