<![CDATA[蚂蚁网-多维人生，三实而立！]]> http://www.vants.org/ zh-cn www.emlog.net SharkFest'20 Virtual Retrospective http://www.vants.org/?post=301 THURSDAY SESSIONS

FRIDAY SESSIONS

阅读全文>>]]> Thu, 05 Nov 2020 01:57:31 +0000 易隐者 http://www.vants.org/?post=301 SharkFest'19 Retrospective http://www.vants.org/?post=300 KEYNOTE PRESENTATIONS

Latest Wireshark Developments & Road Map
Gerald Combs

TUESDAY CLASSES

WEDNESDAY CLASSES

THURSDAY CLASSES

阅读全文>>]]> Thu, 05 Nov 2020 01:39:00 +0000 易隐者 http://www.vants.org/?post=300 省局门户网站地市信息公开栏目访问异常应急处置 http://www.vants.org/?post=291 1 情况概述

1.1 拓扑结构

点击查看原图

   服务器通过交换机、WAF、IPS，经防火墙映射对外提供服务，办公外网与互联网通过出口交换机访问服务器。

1.2 情况简介

   2017年11月17日有市局反应省局门户网站地市信息公开栏目访问异常。

点击查看原图

   点击信息公开栏目后如下图所示：

点击查看原图

   大部分市局...

阅读全文>>]]> Sat, 02 Dec 2017 03:40:06 +0000 竹林再遇北极熊 http://www.vants.org/?post=291 省厅A登陆省厅B预算系统异常应急处置 http://www.vants.org/?post=290 1 情况概述

1.1 拓扑结构

   如上拓扑所述，省厅A的客户端1和客户端2属于两个不同的安全域，通过防火墙代理，经过互联网，访问省厅B一台层层安全防护的预算系统服务器。

1.2 情况简介

   预算系统分别使用B/S、C/S架构对外提供服务，服务端域名是xxx.com，解析后的公网IP分别是X.X.X.155和X.X.X.22，浏览器访问比客户端访问多...

阅读全文>>]]> Tue, 28 Nov 2017 13:59:27 +0000 竹林再遇北极熊 http://www.vants.org/?post=290 某省厅门户网站A市局访问异常应急处置 http://www.vants.org/?post=289 1 情况概述

1.1  网络拓扑结构

    梳理省厅网络拓扑结构，了解WEB服务器通过接入交换机、WAF、抗D，经防火墙对外映射对外提供服务，其中交换机、抗D、WAF均为二层部署，如下图所示：


1.2 情况简介

    A市局近期有无法访问省厅门户网站的现象，换个IP即可正常访问，与省厅沟通后发现其他市局和互联网用户均能正常访问。

1.3 分析思...

阅读全文>>]]> Tue, 28 Nov 2017 13:47:08 +0000 竹林再遇北极熊 http://www.vants.org/?post=289 某业务系统访问慢分析 http://www.vants.org/?post=279 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报文不作为此次分析的重点，感兴趣的小伙伴可以私下讨论。

阅读全文>>]]> Fri, 21 Apr 2017 07:59:01 +0000 飞鸟 http://www.vants.org/?post=279