欢迎关注: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)

MOTS攻击之TCP攻击

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

1.  概述

继续进行MOTS类型攻击方式的进展。这里再次强调一下,MOTS是指Man-On-The-Side,是一种在旁路监听模式下的攻击方式;MITM不同,MITM是指Man-In-The-Middle,是中间人攻击。MOTS其原理是监听与构造响应数据包,并在正常数据包返回之前插入伪造的数据包。其实现的核心条件是TCP/IP协议本身实现时并没有考虑这方面的安全问题。MOTS...

阅读全文>>

标签: TCP RST reset MOTS 旁路中间人攻击 TCP劫持 中间人

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

MOTS攻击技术分析

作者:飞鸟 发布于:2017-6-8 17:28 Thursday 分类:网络安全

1.   背景

我们经常遇到这样一个场景:在用户现场通过端口镜像对流量做镜像,用来分析数据包或者审计的时候,疑心较大的用户总是怀疑其数据会被篡改或客户端信任的结果并非真实服务器返回的值。我想大多数的技术兄弟可能都会和我一样回复用户:这是一台审计设备,是旁路部署,只能审计,不是串在里面的,不可能对数据进行篡改;也不可能影响客户端的最终请求响应的结果。这个理论我一直深信不疑...

阅读全文>>

标签: 端口镜像 TCP 明文 reset 分片 MOTS 链路劫持 劫持 HTTP劫持

评论(3) 引用(0) 浏览(4976)

某业务系统访问慢分析

作者:飞鸟 发布于: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)

带有应用层字段的TCP RST报文

作者:易隐者 发布于:2012-8-21 11:09 Tuesday 分类:网络分析

       今天在为一个朋友准备培训材料的时候,某个客户那边捕获的数据包文件中,无意中发现RST报文中竟然带有应用层字段,如下图所示:

点击查看原图

       这是一个SSH的TCP连接,一般而言,对端在收到TCP RST报文后,便会立即释放该TCP连接,这个是传输层控制的,即使RST报文中带有应用层字段,传输层也不会将这个应用层字段提交给应用进程。

       如此来看,这个TCP RST报文带有应用层字段“ Reset cause: Go away, we're not home ”,似乎也没什么意义。

      

阅读全文>>

标签: TCP RST reset 应用字段 培训 SSH

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

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