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) 浏览(7185)

某业务系统访问慢分析

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

1.    问题描述

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

2.    故障现象

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

Ø  登录

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

Ø  办理业务

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

3.    网络拓扑

说明：

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

2.   防火墙不仅做网络层的访问控制，同时启用WAF、IPS功能

3.   抓包设备对7609和6509上对相应流量做镜像

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

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

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

4.    故障分析

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

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

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

1.   10.40.44.199和10.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,源IP为10.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) 浏览(5273)

又遇TCP协议栈异常问题

作者：易隐者 发布于：2013-10-29 16:47 Tuesday 分类：案例讨论

       大家还记得我以前写的《TCP确认机制异常案例》(链接为：http://www.vants.org/?post=200)吗？今天在一个用户那边再次遇到了一个TCP协议栈异常的问题。

       用户反馈的问题现象是业务交互出现异常，难以定位异常出现的原因，我在用户现场分析了异常出现时的报文交互情况，如下图所示：

       由F5设备主动向服务器发送SYN连接请求报文，服务器响应SYN/ACK报文，F5发送ACK报文确认后，向服务器连续发送3个大小分别为1514、1514、350大小的应用请求报文，但是1.199秒之后，F5重传了应用请求的第一个报文（该报文序列号为No7，该数据报其实是序号为No4的报文的重传），紧接着，2秒后，看到服务器的SYN/ACK的重传报文（该报文序列号为No8，该报文为No2报文的重传报文），后面数十秒的交互，基本是都是F5对应用请求报文的重传和服务器SYN/ACK报文的重传，在40秒之后，由F5主动发送RST报文释放该TCP连接。

       由整个交互的过程，我们可以清晰的看到，服务器不断重传SYN/ACK报文，说明服务器没有正常处理F5的ACK报文（序列号为No3的报文），站在F5的角度，TCP连接已经建立成功，但是站在服务器的角度，却认为TCP连接未建立完成，因此服务器不断重传SYN/ACK报文，为什么服务器在明确收到了F5的三次握手的ACK报文，却没有正确处理呢？而且后续F5重传的应用请求报文（No7、No10、No11、No14、No17）都可以说是对服务器SYN/ACK报文的确认，但是服务器全部忽略了，因此，这基本上可以判断为服务器端系统的TCP协议栈出现异常，导致了应用出现了异常。

阅读全文>>

标签: TCP F5 应用故障 SYN 重传 TCP协议栈 应用异常

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

别具匠心的HTTP应用层行为设计

作者：易隐者 发布于：2012-12-26 16:09 Wednesday 分类：网络分析

       今年的年初，有位兄弟在QQ跟我讨论一个较为少见的报文交互情况，我当时在看了具体的报文交互之后，对他说是某种HTTP探测机制，他则对我说有人认为是某种SACK的重传机制，记得我曾说过我会找时间好好研究一下这个交互的行为，后来的确也写了一些分析、画了一些图示，但是在未完成的情况下被耽搁了，直至最近才把这个翻出来，闲话少说，我们还是直奔主题，一起来看一下这个有意思的应用交互行为吧。

       这个报文交互过程如下：

       其交互的数据流图如下： 

       我们再来看一下其中几个重要报文的详细解码，首先看服务器的HTTP 200 OK响应报文的解码，如下图所示： 

服务器响应报文解码（No128报文解码）

       这个服务器的响应报文，其应用字段长度为585字节，序列号为101871，最后两字节应用字段为Hex 0d0a，我们再来看一下客户端对这个服务器响应报文的确认报文的解码，如下图所示： 

       从上图解码来看，这是一个最为常见的确认报文，确认号为102456（101871+585）。我们再看看服务器的重传报文解码，如下： 

服务器后续重传报文解码（No132报文解码）

       我们能够清楚的看到，这个来自服务器的重传报文其应用字段为1字节，序列号为102454，应用字段为Hex 0d，通过序列号我们可以看出这个重传报文并不是No130应用响应报文的重传，而仅仅是重传了No130报文中倒数第二个字节的应用字段！我们再看看客户端对服务器这个重传报文（No132报文）进行确认的报文解码： 

客户端对服务器这个重传报文（No132报文）进行确认的报文解码

       客户端确认号为102456，但是其SACK却显示为102454-102455！确认号大于块左边界、块右边界值，这是不符合SACK的相关规范的！

       我把这个交互过程制作一个更为清晰明了的图示如下： 

       现在大家应该清楚这个交互的具体情况了，那么疑问来了：

1， 服务器端为何重传倒数第二个字节的应用字段？
2， 客户端在确认服务器的重传报文时，为何使用不规范的SACK？

       带着这两个疑问，我用自己的机器访问163网站，重现了这个交互过程如下： 

       这个过程跟上面的交互过程几乎是一致的，我们就不再做详细的分析了，但是我们来仔细的查看一下客户端对服务器一字节应用字段重传的确认报文的解码： 

客户端对服务器重传报文进行确认的报文解码

       在这个解码中，我们看到，我的机器在对服务器的一字节重传报文进行确认时，并未使用SACK，而是正常的重传了对服务器应用响应报文的确认，这是一般情况下的正常处理。这也说明了服务器的这个“重传一字节应用字段”的行为并不会导致客户端的确认出现异常。只有系统处理差异才能够解释这种情况的发生：我使用的客户端是XP操作系统，而那位与我讨论的兄弟使用的是其他操作系统。不同的操作系统在遇到这种重传部分应用字段的报文时处理机制不一样导致了疑问2的出现，这种不合SACK规范的确认报文虽然不会对服务器造成交互的影响，但足以让我们产生困惑，因此，严格来说，那位与我讨论的兄弟所使用的端系统如此处理是异常的。

       如此我们解决了第二个疑问。

       而针对第一个疑问，问遍了google和baidu无果后，让我们一起来分析一下这种行为可能带来的好处和坏处。

       服务器在作出应用响应之后，在200ms左右未收到来自客户端的确认报文，则将倒数第二个字节的应用字段封装重传给客户端。

这样做的好处是在如下几种情况下会提高服务器与客户端的交互效率：

1， 服务器发往客户端的应用响应报文在网络传输过程中被丢弃
       服务器的响应报文被丢弃，未到达客户端，在这种情况下，服务器的这个“200ms内未收到客户端ACK报文则重传一字节应用字段”的行为，避免了服务器端被动等待客户端确认报文到达直至重传定时器清零，服务器才可以重传报文，服务器通过这种行为主动探测客户端对服务器报文接收的情况，提高了交互的效率。 

服务器应用响应报文被丢弃时的交互过程图示

2，客户端对服务器应用响应报文的确认在网络传输过程中被丢弃
       如果客户端对服务器应用响应报文的确认报文在到达服务器之前被丢弃了，那么，会出现服务器端等待客户端确认报文到达的情况，这是一个超时重传的等待时间，一般至少在数秒之间，而服务器的这个“200ms内未收到客户端ACK报文则重传一字节应用字段”的行为，可以在200ms左右主动发送“封装最后倒数第二个字节应用字段的重传报文”，这个报文到达客户端之后，客户端将重新发送确认报文，这减少了超时重传的等待时间，从而提高了交互的效率；

客户端对服务器响应报文的确认被丢弃时交互过程的图示

坏处就是：与一般正常交互过程相比，可能会给网络多带来两个64字节的小包。

       如果客户端正常收到了服务器的应用响应报文，只是客户端的ACK报文较慢（网络传输延时或者客户端的delay ack机制等）到达服务器，则服务器会发送这种带有一个应用字段的重传报文，而客户端在收到这个报文后，会对这个报文进行确认。

       而这个坏处相对于其带来的好处而言，实在不值一提，因此不得不说，这个HTTP应用行为的设计是别具匠心的！

       那么为什么是倒数第二个字节而不是倒数第一个字节、倒数第三个字节或者其他字节？理论上来说重传任何一个字节达到的效果都是一样的，只重传部分应用字段（一个字节）是为了节约网络带宽资源，或许程序设计者如此设计有一些特别的用处，但是这只能去问程序设计者本人了。

      另：我已将相关报文文件作为附件上传至此，有兴趣的兄弟姐妹可下载学习探讨，下载后解压即可使用wireshark直接打开查看。

阅读全文>>

附件下载：
别具匠心的HTTP应用行为设计-兄弟提供的原报文.zip 203.32KB
别具匠心的HTTP应用行为设计-我重现的报文1.zip 2.1KB
别具匠心的HTTP应用行为设计-我重现的报文2.zip 4.21KB

标签: sack 解码 重传 get delay ack HTTP 应用行为

评论(1) 引用(0) 浏览(80768)

网页打开慢但HTTP下载快故障分析案例

作者：易隐者 发布于：2012-10-10 16:06 Wednesday 分类：网络分析

【说在之前】：

1，用到了疑难杂症网络分析过程中最基本、最核心的两个分析方法：对比分析法和关联分析法；

2，该案例涉及到的知识点主要有SYN重传、连接数限制等，大家可参考本博客中相关知识点的文章。

【我的案例】：

故障环境

       某单位大体的网络结构如下图所示： 

内部办公人员通过交换机到流控设备，再通过防火墙做NAT访问互联网。

故障现象

1，在地矿局进行互联网时，打开网页的速度非常的慢，有的网页要刷新几次才可以正常显示；
2，但是使用下载工具或是基于HTTP的下载速度却很快。

故障分析

1 确认故障原因

        我们找一台主机，访问互联网的某网站，发现的确比较慢，我们抓取故障时的交互数据包，如下图所示： 

       通过上图，我们可以发现，客户端在与服务器建立TCP连接时，其SYN请求报文被客户端重传了一次，这个重传导致了2.88秒的延时。TCP重传一般是中间设备丢包导致的，那么到底是在什么地方丢包的呢？我们首先需要界定一下可能丢包的故障关键点。

2 选择故障关键点

       该故障环境相对简单，在办公用户访问互联网时，数据包只通过了交换机、流控设备和防火墙，而交换机主要负责转发数据，不会对数据包进行深度的检测和过滤等操作，所以在该环境下主要的关键故障点是流控设备和防火墙，如下图所示：

 

3分析流控设备是否丢包

       关键故障点确定之后，我们首先在流控设备的前后同时抓包做对比分析，以确定是否是流控设备丢包，如下图所示： 

       通过我们还原故障现象时，在流控设备前后抓取数据包的对比分析，结论显示，流控设备前后数据包交互的过程是一样的（这个对比分析通过五元组关联同一会话之后，对比查看数据交互过程的差异即可，由于流控设备前后的数据交互过程完全一样，在此不做具体详细的分析说明），这说明，在打开页面较慢时，流控设备并未丢弃任何交互的数据报文。

4 分析防火墙是否丢包

       同样，我们再在防火墙的进出口同时抓包，通过比较防火墙前后数据包的交互情况来确定造成故障的原因，部署图如下所示： 

1， 在访问某网站出现缓慢现象时，在防火墙前后同时抓取数据包，并保存，为下面的对比分析提供原始的数据报文。
2，我们先分析防火墙内网口抓取的数据，在科来网络分析系统的“TCP会话”视图，我们发现了一个web连接持续的时间为6秒，并且其在三次握手过程中，存在重传现象，如下图所示： 

这个TCP会话的源端口是1124，目的地址为58.30.236.11，目的端口是80
3，我们通过关联分析法，在进行网页访问时，我们在防火墙前后同时进行抓包，下图就是在防火墙出口处抓取到的数据包： 

       我们知道防火墙在网络运行中起到防护作用，会将未经授权的报文过滤，但是防火墙一般不会阻止正常的数据包，我们在比较上面两张图发现，在防火墙后捕获到的数据包第一次发送同步请求没有成功，然后又重传了一次同步数据包，才成功建立了连接；而在防火墙前面抓取到的数据包却没有看到重传的数据包（黑框标记的部分），这很清晰的说明，第一个SYN报文被防火墙丢弃了。

4 分析结论

       通过上面的分析，我们可以得出如下结论：

       由于防火墙在转发数据包时，随机丢弃了客户端发送的SYN报文而造成的。可能是防火墙配置不当（连接数限制）或防火墙BUG（在处理TCP新建连接时不稳定）导致的。

总结

       经过分析知道是由于防火墙不规律丢弃SYN报文导致的网页打开慢现象，但是为什么HTTP下载的速度却很快？这是因为防火墙仅随机丢弃SYN报文，而HTTP下载在刚开始建立TCP连接时，防火墙有可能会丢弃其SYN报文，但是下载行为决定其会不断发起SYN报文进行连接建立的尝试，而一旦连接建立成功，则防火墙不会丢包，给用户的感觉就是速度也非常快。

阅读全文>>

标签: TCP 对比分析法 关联分析法 丢包 SYN 防火墙 重传 BUG NAT 连接数限制 SYN报文

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