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

MOTS攻击之UDP攻击

作者:飞鸟 发布于:2017-11-15 21:26 Wednesday 分类:网络安全

1.  废话

前段时间写了篇文章介绍MOTS攻击的原理及相关的攻击方式,当时只是了解其原理,没有通过程序具体实现。这段时间找时间学习了Python,抽了几天晚上时间用Python实现了UDP的攻击程序。对于TCP这块的攻击找时间再完善一下相关程序。

对于MOTS攻击方式不了解的同学们可以翻翻我上篇文章,MOTS攻击技术分析》。底层原理是关键,程序实现只是侧面佐证。

废话不多说,直接...

阅读全文>>

标签: TCP reset 丢包 重传 DDOS MOTS 劫持 MOTS-UDP UDP欺骗

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

某业务系统访问慢分析

作者:飞鸟 发布于:2017-4-21 15:59 Friday 分类:网络分析

1.    问题描述

一用户内网系统对内提供业务办理业务,其省局和地市都需要访问改业务系统。最近一段时间,经常有地市反映登录较卡及办理业务时也很卡。经过对设备、链路、策略等方面的常规检查,并没有发现问题。近期,由于地市反映卡的现象较严重,用户体验较差,在这种情况下,“捕影”应急响应小组接手处置该问题。

2.    故障现象

经了解与测试,发现在两个方面用户体验较差。

Ø  登录

登录时一直在等待,等一段时间后就提示“连接被重置”

点击查看原图

点击查看原图

Ø  办理业务

根据用户反馈,在填写完相应的表单后,单击“保存”后,需要十多秒才可以保存成功。

3.    网络拓扑

点击查看原图

说明:

1.   负载均衡和防火墙物理上旁路部署,逻辑上串联。

2.   防火墙不仅做网络层的访问控制,同时启用WAFIPS功能

3.   抓包设备对76096509上对相应流量做镜像

4.   Web服务器做负载均衡,用户访问负载均衡虚地址,通过负载均衡后转换为访问实地址,真实服务器有两台10.0.102.1010.0.102.11

5.   客户端访问web服务时,首先经过76096509,然后到防火墙,由防火墙转发到负载均衡,负载均衡再转发到防火墙,然后防火墙转发到真实服务器

客户端到服务器的流量流逻辑相对较复杂,其数据流逻辑如下,其数据包返回时按原路返回:

点击查看原图

4.    故障分析

    由于此故障是应用层面的故障,因此我们怀疑的重点在会对应用层数据包做处理的设备上。防火墙启用了WAFIPS功能,其会对应用层数据包进行过滤,因此其作为怀疑的重点。同时,负载均衡作为代理设备,其负载算法可能会对正常连接造成影响。

    既然怀疑的重点在于防火墙和负载均衡上面,并且用户现场部署有相应的流量镜像设备。因此我们只需要将故障出现时的数据包下载下来分析即可。和用户沟通,其出现故障时间为850左右,客户端IP10.40.44.199,根据用户描述,其在那段时间操作很卡,做个操作需要十多秒的时间。

    过滤相应时间与相应IP的数据包,找到相应的交互数据流。我们来分析交到的数据流。

1.   10.40.44.19910.0.1.10建立完三次握手后(因为抓包设备的原因导致数据包先看到SYN+ACK,序号为163084的包其实为ACK)

2.   10.40.44.199进行一个POST的保存操作,相应POST操作的URL/TopIcis/EntLiaisonsRecordSave.do

点击查看原图

3.   10.0.1.10进行相应的ACK确认,然后10.0.1.10发送了一个Reset报文将连接释放了。

      是不是这个数据包的应用层数据触发了相应的安全策略,才会被reset异常释放掉?我们对其应用层内容进行分析,发现并没有攻击语句,基本上不会触发防火墙的WAF策略。

点击查看原图

既然没有触发相应的安全策略,为什么正常的请求还是被异常释放?肯定是某些机制在起作用或者说某些机制异常导致的。那么我们需要定位到是防火墙、服务器还是负载均衡设备发出的reset包。

由于抓包设备是对相关vlan的流量做镜像的,也就是说服务器、防火墙及负载均衡的数据包都被抓取到。

直接分析数据包,可以看到其TTL=64,IP10.0.1.10,直接分析是负载均衡发送的reset数据包,但是负载均衡作为代理设备,服务器或防火墙发送的reset数据包转发到负载均衡时,其数据包层面的表象就是上面所看到的

点击查看原图

     因为我们需要分析这个数据是不是服务器或者防火墙发出的?防火墙工作为路由模式,如果是防火墙或服务器发出的reset数据包,那么我们直接通过下面过滤表达式即可过滤出来:

(ip.src == 10.0.102.10 or ip.src == 10.0.102.11) and tcp.flags.reset == 1

    直接过滤,果然发现10.0.102.11发送了一个reset包,难道是防火墙或者服务器发起的?仔细分析了一下时间,上个报文的时间为08:51:02秒,而这个报文的时间为08:50:53秒,reset包作为传输层的一个标识数据包,中间设备转发时肯定不会产生这么大的延迟,因此,个人推断这个数据包肯定不是这个会话的。因此发送这个reset包的正是负载均衡设备本身。

点击查看原图

    分析至此,已定位到是负载均衡发起的reset报文将该连接释放导致的。但是,这个结论与用户描述的现象并不吻合:进行保存操作时比较卡,需要十多秒才可以保存成功。上面我们分析的是负载均衡把连接释放了。如果这样的话,用户的现象应该是连接中断才对。

    如果是这样的话,客户端肯定会存在重传的数据包,我们直接对应用层的数据进行过滤,果然发起客户端在11秒后进行了重传操作。

点击查看原图

    重传相应的保存操作报文后,服务器正常响应。

点击查看原图

    至此,对这次性能慢的分析已形成闭环。用户保存卡的原因为:客户端在向服务器进行保存操作时,被负载均衡异常释放掉;然后客户端在11秒后再次请求,服务器正常响应,负载均衡正常转发。

    关于负载均衡为什么将上一个post报文丢弃并发送reset报文不作为此次分析的重点,感兴趣的小伙伴可以私下讨论。

阅读全文>>

标签: 疑难杂症 负载均衡 reset 丢包 重传 访问慢 故障分析

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

【转】VPN Tunnel 口MTU问题解决

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

【说在之前】:

1,这个帖子是我在锐捷的论坛里看到的,现象很特别,值得研究讨论一番;

2,原帖中仅对故障做了描述,并未给出导致故障产生的根本原因,大家可以自行先考虑考虑,并尝试分析推测一下可能的原因,可在此贴下留言以供探讨;

3,此案例的正确答案应该已由回复中的liuquyong兄弟给出,主要原因在于加解密次数的减少导致了ERP交互性能的提升。关键就在于下面这张来自于思科的加解密流程图:

点击查看原图

【原文连接】:

  http://support.ruijie.com.cn/showtopic-22758.aspx

【原文全文】:

Gre隧道,Tunnel接口的MTU值设置为大于1500的值,有效吗?带着这个问题我讲讲今天遇到的问题:
NPE20(总部,版本RGNOS 9.12)与NBR300(分部,版本RGNOS 9.12)建立Tunnel 0接口的GRE隧道。
2010年初的时候刚开始用Tunnel功能,当时show interface tunnel 0  显示的 Tunnel 的 MTU值 1464,此时分部访问总部的ERP(用友U890,C/S架构,通过Tunnel隧道来访问的)很慢,卡!只要一遇到分部客户端与服务器之间有数据交互的时候,就异常的卡,有时软件直接无响应。
命令行将此Tunnel的MTU值设置为65535,此时访问速度“嗖”的立刻上去,只能用两个字形容:流畅!
前天,我将NPE20和NBR300都升级到最新的9.17 2P1 B4版本,9.17的Web控制界面操控性以及网速都有一定的提升,但这时出现问题,Tunnel的MTU值设置为65535之后,会自动变回1464,企业内的应用再度变卡,就和上述曾经遇到的卡的情况一样。并且无论如何都不像9.12版本那样保持65535。
此问题一直延续到今天。于是迫于无奈,在咨询了锐捷400电话客服之后,由3034号客服帮我将NPE20、NBR300都刷回9.12版本。刷回9.12版本之后的tunnel 0 先是保持1464默认值,这时还是卡,没有任何起色。手动将MTU值设置为65535,分部访问总部的ERP访问速度和响应速度一下子就上去了,非常流畅!
在咨询3034客服之前,我也咨询过几个客服关于MTU值的问题,得到的答案基本上都是类似于“公网传输数据包的MTU 最大只能1500" 、  “你设置为65535实际上没有效果”之类的话。并且让我两端互ping来测试是否丢包,互ping的时候的确是不丢包的,就算互ping的时候的指定ping包的大小也基本不丢包。
但是我想说,这只是理论,而我所遇到的问题是事实,事实胜于雄辩,Tunnel 0 的MTU为1464时与65535时相比,企业分部与总部之间的内部应用访问速度效果提升是:绝对异常明显的!!
所以,在这里我第一想说感谢3034客服帮我恢复到9.12,这个可以保存手动设置的65535MTU值的版本。第二我想恳请锐捷能够在下一个RGNOS版本中将GRE隧道的Tunnel 接口的这个MTU值改为可以保存用户手动配置的值,比如手动设置为65535,而别再自动恢复理论默认的1464之类的值。
因为今天我遇到的问题的确是:相对与MTU1464的默认值,MTU 65535时的隧道内访问速度是:提升绝对异常明显的!所有的事实,3034号客服可以证明!问题虽解决了,但是他也比较纳闷比较难解释。
我其实很纠结,我想用9.17 2P1 B4的新特性,包括上外网的网速也有一定的提升,但是无奈只能用9.12这个老版本。

阅读全文>>

标签: 丢包 故障 交互 MTU ping tunnel接口 GRE 锐捷

评论(19) 引用(0) 浏览(38724)

更换设备后业务访问故障案例

作者:易隐者 发布于:2012-12-5 19:18 Wednesday 分类:网络分析

故障环境

网络拓扑

       故障环境下的拓扑结构如下图所示: 

点击查看原图

1,分公司与中转区域通过互联网建立VPN隧道;
2,中转区域通过专线与总部业务服务器区域互联;

业务访问流程

       中转区域机器通过专线直接访问总部业务服务区域的服务器,而分公司则先通过互联网与中转区域建立VPN隧道,经中转区域CISCO VPN设备后,再访问总部业务服务区域的服务器。

故障现象

       此次故障现象主要表现为:
1,分公司只有极少数机器可以正常访问总部的业务服务器,绝大部分机器都不能访问总部的服务器;
2,中转区域全部无法正常访问总部业务服务器;
3,出现上述故障现象时,使用ping命令做连通性测试,都是正常的,无较大延时也无丢包现象;
4,上述现象发生在中转区域更换新的CISCO VPN设备之后,使用以前老的CISCO VPN设备未出现任何问题;
5,新的CISCO VPN设备的配置是从老设备上的配置导入的,因此可以肯定配置完全一致。

故障分析

1 分析过程

       根据故障现象以及前期的测试情况来看,该故障属于业务应用故障,我们认为站在数据报文交互的角度进行分析比单纯猜测和毫无根据的做各种测试更有效率。

 故障重现
       我们首先选择一台IP地址为10.18.3.22的机器作为测试机,并在测试机器上使用IE浏览器访问10.3.3.21服务器,以便在故障现象出现时,我们捕获测试机与服务器业务交互的报文。

近故障点抓包,分析交互过程
       考虑到服务器端在总部,在服务器近端抓包难度很大,我们决定先在客户端近端抓包。
在测试机访问服务器故障重现时,我们在测试机近端捕获了测试机与服务器间的业务交互报文,如下图所示:  

点击查看原图

测试机与服务器的交互报文
点击查看原图 
对应的TCP数据流图


       通过对这个报文交互过程的分析,我们发现,测试机与服务器的TCP三次握手建立连接正常,客户端向服务器发送“GET”请求也正常,问题出现在服务器给测试机的响应报文,我们在测试机近端抓包,只看到了服务器向客户端发送的28字节的报文,而我们通过该TCP报文的Seq=1433可以计算出,在这个报文之前,还有一个载荷长度为Len=1433-28-1=1404字节的TCP报文未正常到达测试机。测试机在等待45秒后,由于一直未收到该报文,其主动向服务器发送FIN报文,正常释放了这个TCP连接。
       纵观整个过程,我们可以自然的得出结论:服务器端的报文在网络中被中间设备丢弃,导致了故障的产生。
一般而言,偶尔丢包是正常的,TCP会通过重传机制,保证应用正常交互,但是在这个故障交互的报文中,我们仅看到有报文被丢弃,并且这个报文在45秒的时间内,一直未到达测试机,这不符合TCP重传的工作机制,只有一种情况可以解释这种现象,那就是这个一直未到达测试机的报文,其原始报文和重传报文都被中间设备丢弃了。
       结合故障现象是在更换为新的CISCO VPN设备后出现的,我们很自然的想到,应该是新更换的CISCO VPN设备丢弃这个报文。那么CISCO VPN设备并未做特殊的设置,一般不会丢弃特定报文,联想到这个被丢弃的报文应用字段长度为1404字节,加上20字节的TCP报头和20字节的IP报头,其IP报文长度应该有1444字节,是否有可能是其超出了CISCO VPN设备的某些接口的MTU呢?
       对CISCO VPN设备的特性并不了解,那么我们还是做一个简单的测试,验证我们的分析和推论是否正确。

验证
       将测试机网卡的MTU值修改为1400之后,再次尝试通过IE访问总部的服务器,访问完全正常,下面为修改MTU值之后的测试机与总部服务器之间正常交互的报文: 

点击查看原图

       上述正常交互的报文,充分验证了我们前面的推论。

2 分析结论

       老CISCO VPN设备的tunnel接口MTU等属性并没有保存在配置文件里,因此虽然将老设备的配置直接导入到新设备中,但是新更换的CISCO VPN设备VPN tunnel接口MTU较小,导致服务器发给客户端的TCP大包报文被丢弃,引发业务访问故障的产生。
       而分公司极少数机器在更好新设备后仍然能够正常访问服务器,是因为这些机器本身网卡的MTU值较小,因此虽然新的设备上线,但并不影响这些机器对服务器的正常访问。

故障解决

      调整CISCO VPN设备相关tunnel口MTU值,此故障解决。

阅读全文>>

标签: 疑难故障 丢包 MTU VPN

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

Netscout 的KFP分析方法论

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

        Netscout有一个非常知名的应用性能管理的分析理论—— KFP分析方法论

        所谓“KFP”就是“KPI-Flow-Packets”,我在网上搜集诸多关于Netscout的KFP分析方法的资料,下面是我摘录的一些描述KFP的图表: 

点击查看原图

点击查看原图

点击查看原图

点击查看原图

        这些图表将KFP的工作方式做了直观的展示。再加上一段netscout针对KFP的描述:

"The KPI-to-Flow-to-Packet Approach
NetScout’s products leverage deep packet inspection technology to deliver complete visibility into real-time operational intelligence spanning high-level KPIs (Key Performance Indicators) and early warning all the way down to actual packets, enabling IT organizations to reduce MTTR. The nGenius Solution provides  an from key performance indicators (such as response time or errors) to application flow data (such as utilization, conversations or top talkers) and then to packet-level details – if necessary. This “KPI-to-Flow-to-Packet” approach allows you to delve as only deeply as required to effectively manage and troubleshoot your network and application performance. "

        综合这些相关资料的描述,KFP方法论主要利用Netscout系列产品进行核心业务应用性能分析管理的方法:

K:KPI

       其主要确定各种核心业务应用的关键性能指标(根据不同应用的特点,其KPI的选择有所差异),如HTTP应用的KPI主要有:响应时间、响应成功率;VOIP应用的KPI主要有:丢包率、语音质量等。
Netscout产品统计计算出各个应用在交互过程中的KPI值,并且根据这些KPI值制定相应的告警条件,提前预警业务应用的性能问题,反应业务应用的性能情况。

F:Flow

       在Netscout发出告警之后,用户接下来可以利用Flow进行进一步的分析,包括利用率、会话、最差性能等,发现跟告警相关的具体会话、应用、服务等。

P:Packet

        最终站在数据包交互的角度,分析具体数据报文的细节,定位问题根源。

       KFP方法论的思路固然可以通用,但是具体到实现的效果,估计只有Netscout的产品能够完美的体现出来,毕竟这个是Netscout提出来的。

阅读全文>>

标签: Netscout 丢包 响应时间 预警 交互 应用性能 packet KPI Flow KFP VOIP MTTR

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

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