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

三实“捕影”2018招人计划

作者:飞鸟 发布于:2018-1-26 13:45 Friday 分类:其 他

0x01 小组介绍

“捕影”应急响应小组是安徽三实公司旗下专门负责网络疑难故障处置、安全事件应急响应、业务系统性能优化、日志分析的团队。


   0x02  小组荣誉

1.    公安部一所网防G01安徽技术支撑团队;

2.    安徽省公安厅网安总队技术支撑团队;

3.    安徽唯一一支专注于网络疑难杂症与黑客攻击入侵应急响应的团队;

4.    协助政企金融用户处理数百起网络疑难故障;

5.    协助多地网安与用户处理数百起黑客入侵事件;

6.    freebuf、团队博客蚂蚁网上发表了数百篇专业疑难故障与应急响应类文章;

7.    安徽省19大网络安全应急保障工作、组织几十家用户的应急演练;

8.    多次为安徽省公安厅、安徽省经信委、各地市公安/网信办提供技术培训和讲座;

9.    多位网络分析专家/应急服务专业级工程师/CISP/各种安全厂商认证工程师;

10.  团队博客www.vants.orgwww.freebuf.com/author/feiniao

    0x03 招人计划

 助理工程师

1.    熟悉常见网络结构

2.    了解基本的网络原理(交换机、路由器、防火墙等)

3.    掌握wireshark、科来等抓包软件的使用;能够在故障现场根据具体故障现象抓取相应的数据包

4.    了解常见的网络设备、服务器、登录配置操作

5.    了解常见安全设备、存储设备、虚拟化的工作机制和原理,能够完成常规的操作;

6.    能与用户沟通,完成日常工作,并撰写报告;

7.    常规问题的分析和解决

8.    协助团队负责人完成其他常规工作。

技术工程师

1.    具备一定的安全能力,熟悉网络安全与web安全的原理

2.    了解常见攻击方式,如xsssql注入、文件上传等原理

3.    熟悉主流安全设备的工作原理

4.    具有一定的分析和处理入侵事件的能力

5.    具备一定的日志分析能力,能够通过日志分析黑客攻击的痕迹

6.    熟悉TCP/IP协议,对数据包有一定的分析能力

7.    熟悉主流的网络设备,了解网络设备的工作原理

8.    能够独立处理日常的工作

9.    独立撰写用户服务过程文档。

(以上至少满足5)

 中高级安全工程师

1.    精通TCP/IP原理,具有独立解决用户网络疑难故障的能力

2.    深入理解应急响应的流程、具体步骤,可独立进行安全事件的应急处置

3.    了解IT项目管理知识体系,能够胜任公司大型安全服务项目经理

4.    撰写体系化的技术文档并进行团队分享。

  C开发工程师

1.  独立完成系统模块开发、维护,按计划完成各个模块日常开发工作;

2.  配合同事以及上级领导制定软件开发方案

3.  解决项目中因程序引起的故障问题;

4.  项目维护和新功能模块开发;

5.  良好的代码编写习惯、以及技术文档书写能力

6.  良好的沟通与表达能力、思路清晰,较强的动手能力与逻辑分析能力。

    0x04  联系方式

 地址

合肥市高新区长江西路1185F创业园A408。

联系方式

Tel:132 9551 2120

Mail:liuqy@ahsss.com.cn


阅读全文>>

标签: 疑难故障 TCP wireshark 招聘 三实 应急响应 捕影 日志分析 招人 捕影小组 应急处置 三实捕影

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

省局门户网站地市信息公开栏目访问异常应急处置

作者:竹林再遇北极熊 发布于:2017-12-2 11:40 Saturday 分类:网络分析

1 情况概述

1.1 拓扑结构

点击查看原图

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

1.2 情况简介

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

点击查看原图

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

点击查看原图

   大部分市局...

阅读全文>>

标签: 疑难故障 策略误报 报文分析 策略分析

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

省厅A登陆省厅B预算系统异常应急处置

作者:竹林再遇北极熊 发布于:2017-11-28 21:59 Tuesday 分类:网络分析

1 情况概述

1.1 拓扑结构

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

1.2 情况简介

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

阅读全文>>

标签: 疑难故障 应用故障 策略误报

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

IDS异常导致业务访问故障的案例

作者:易隐者 发布于:2013-3-29 16:46 Friday 分类:案例讨论

【说在之前】:

1,这个是以前我在某个商业银行解决的疑难故障,其中IDS设备出现异常,将原先捕获到的原始数据包通过交换机的镜像口回放至交换机,而交换机的镜像端口并未关闭MAC地址学习功能,引起业务服务器交换机MAC表混乱,导致业务服务器的访问出现异常;

2,这是一个非常少见的疑难故障,因此值得大家学习参考;

3,这段时间由于我个人的规划,工作会作出一些变动,杂事较多,有段时间未在博客中更新新的文章,还望各位兄弟见谅,就将这篇老文作为我三月份博客的更新吧。

【案例全文】:

        前段时间晚上,接到某单位朋友电话,说是其一核心业务系统白天出现了故障,很长一段时间没有解决,现在很多厂家工程师都在,让我过去增援一下,明确定位一下故障的原因所在。于是赶紧打的到现场。下面我把故障的情况描述一下:

故障拓扑

        经过简化的网络拓扑如下: 

点击查看原图

 故障现象

       核心业务访问异常,业务出现中断现象,使用测试pc直接接入业务服务器交换机,设置为服务器同网段IP,在使用ping测试服务器,不通。

故障分析

       故障时,交换机MAC表出现异常,主要表现为交换机端口镜像的目的口上,出现了防火墙ETH2口的MAC地址和核心服务器的MAC地址,导致核心业务访问出现异常。

分析业务交换机MAC表异常的原因:

       交换机MAC表学习的过程为源地址学习,H3C交换机在做端口镜像时,镜像目的端口默认是可以参与网络数据转发的,那么在交换机端口镜像的目的口上出现了防火墙E2口的MAC和业务服务器的MAC,只能说明该端口上收到了源MAC为防火墙E2口和业务服务器的报文,但是作为与IDS监听口相连的端口镜像目的口,通常情况下是不可能收到任何报文的,因为IDS监听口只是被动监听发过来的报文,而不会主动向网络内发送任何的报文。

这里我们大胆猜想一下:

       IDS在极端情况下,工作机制出现异常,将以前捕获的报文,从监听口播放出去,导致交换机口学习到了业务服务器的MAC和防火墙E2口的MAC,这样交换机1根据源地址学习的工作机制,将防火墙E2口MAC和业务服务器MAC对应记录到端口镜像目的端口上。这样可以完美的解释整个故障的现象。如下图所示: 
点击查看原图

 故障解决的方式:

       关闭交换机端口镜像目的端口的MAC地址学习功能。这样即使该端口接收到大量的相关报文,其也不会影响交换机正常的MAC地址表项。

       到底是不是IDS将以前捕获的报文发送至镜像目的端口 ?我们可以通过TAP串接抓取IDS监听口的报文。如果是,那么IDS为什么会这么做?这个问题是个疑问,我想只有厂家可以解释了。技术的东西是可以较真的,没什么太多的变数。

阅读全文>>

标签: 端口镜像 疑难故障 MAC表 IDS

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

某公司业务系统经ISA防火墙访问正常而经硬件防火墙访问慢故障分析解决案例

作者:易隐者 发布于:2013-1-25 10:10 Friday 分类:案例讨论

1 故障环境

      这个故障产生的环境较为简单,我们在不影响故障分析的前提下,简化分析网络环境,其故障发生的拓扑结构大致如下所示:

1.1 网络拓扑

       故障发生的拓扑结构如下所示:
 点击查看原图

1,业务服务器的IP为16.66.252.249/24,网关为16.66.252.254;

2,测试客户端的IP为16.66.180.167/24,网关为16.66.180.1;

3,防火墙与服务器相连的接口地址为16.66.252.254,防火墙与测试客户端相连接口的地址为16.66.180.1;

4,防火墙工作在纯路由模式下;

1.2 业务访问流程

1,业务服务器的业务端口为TCP 211;

2,测试客户端将数据报文经过硬件防火墙转发至业务服务器端,业务系统根据测试客户端的相关请求,返回业务应用数据报文经硬件防火墙转发给测试客户端;

2 故障现象

       经过与用户的交流和现场的测试,确定故障现象主要表现为以下几点:

1,客户端经过ISA访问业务服务器,测试连接速度非常快;

2,将ISA换成天融信硬件防火墙,硬件防火墙工作在纯路由模式下,测试发现客户端连接业务服务器的大概需要消耗20秒左右的延时;

3,用户反馈,测试过使用cisco的ASA和H3C的硬件防火墙,均有不同程度的较大的连接延时;

3 故障分析

3.1 分析过程

3.1.1 确认是否是硬件防火墙产生的延时

       经过ISA防火墙,业务系统连接测试一切正常,速度很快,但是经过硬件防火墙(TOPSEC/CISCO/H3C)之后,就产生了较大的延时,那么看起来似乎是硬件防火墙产生的延时,我们先从这个角度入手,在测试客户端与业务服务器端同时抓包做对比分析,用于确认是否是硬件防火墙产生的转发延时。

1,我们分别在服务器、客户端上安装科来网络分析系统,并开启捕获界面;
2,在测试客户端上做应用连接测试,当测试客户端弹出连接成功窗口后,分别停止客户端与服务器端的捕包界面;
3,我们通过科来网络分析系统的“TCP会话”视图分析客户端上的测试连接建立的TCP会话过程,如下图所示:
点击查看原图 
       客户端的这个数据交互过程充分说明了,在测试连接的过程中,产生了17秒左右的延时。
4,通过科来网络分析系统的“TCP会话”视图分析服务器端的应用连接建立的TCP会话交互情况,如下图所示:
 点击查看原图
       上图清晰的反应了服务器端的应用层响应是在延迟了16.34秒后才发出了;
5,对比分析客户端与服务器端的数据交互过程,我们可以得出以下两点结论:
经过硬件防火墙,应用连接的建立花费了17秒左右的时间;

这个延时不是硬件防火墙产生的,而是业务系统应用产生的。

3.1.2 分析经过ISA防火墙时的业务交互情况

       既然这个延时是业务应用本身产生的,跟硬件防火墙完全无关,那么为什么经过ISA访问的时候,连接测试一切正常呢?

       我们还是在业务服务器上捕获客户端与服务器测试应用连接建立交互的数据报文,分析一下经过ISA访问业务系统时的数据交互情况,如下图所示:
 点击查看原图
其连接正常响应时的数据交互情况大致如下所述:
1,客户端与服务器通过TCP三次握手建立连接;
2,连接建立成功后,客户端立即向服务器端发送了应用层连接请求报文,该报文长度为150字节;
3,服务器在收到这个应用请求之后,在0.006645秒内,响应了客户端的应用层连接请求,这个报文长度为74字节,应用层字段长度为16字节;
4,客户端响应了服务器端的应用层响应报文,向服务器端发送应用层字段长度为16字节的报文确认;

5,应用测试连接成功,客户端主动通过TCP四次握手过程,正常释放TCP连接;

       上述过程清晰的展示了客户端在经过ISA访问服务器时,应用连接建立的时间是非常短的,速度非常快。

3.1.3 分析经过硬件防火墙时的业务交互情况

       在确认了经过ISA防火墙的业务系统网络交互行为之后,我们再来分析一下经过硬件防火墙时,业务系统的网络交互行为是怎么样的。
1,我们首先在服务器端开启科来网络分析系统捕获服务器交互的所有数据报文;
2,在测试客户端上做业务应用连接测试,当测试客户端弹出连接成功窗口后,停止服务器端的捕包界面;
3,我们通过科来网络分析系统的“数据包”视图,查看这个过程中业务服务器的数据交互情况,具体如下图所示:
 点击查看原图
  点击查看原图
       交互过程说明:
服务器端在接收到客户端的应用层请求报文后,没有立即向客户端发送带有应用层数据的连接响应报文,而是先向DNS反向解析客户端地址对应的域名;
由于防火墙无法访问互联网,因此,硬件防火墙返回ICMP目的网络不可达差错报文;
服务器端在尝试4次DNS反向解析失败后,发送NBNS名字解析报文;

NBNS解析成功后,服务器端才向客户端发送应用层连接请求响应数据报文;

 4,通过上图的数据交互情况分析,我们可以得出以下两点结论:

服务器端在收到客户端的应用连接建立请求报文后,没有立即发送应用响应报文,而是首先做反向名字解析,解析不成功,再做NBNS解析;

17秒的延时,就是服务器4次DNS反向解析失败产生的。

3.2 分析结论

       通过上面一系列的分析,我们可以确定,导致该故障产生的核心原因是业务系统程序的处理机制异常导致的。

4 故障解决

       我们知道了经过硬件防火墙访问业务系统变慢的原因是因为业务服务器在接收到客户端的应用请求时,需要针对客户端的IP地址做一个反向名字解析,那么我们可以通过在业务服务器的hosts列表中添加客户端的IP对应的主机名,以此来避开服务器的反向DNS名字解析过程,从而解决了业务系统慢的问题。此方法已经现场测试验证有效。

阅读全文>>

标签: 疑难故障 防火墙 DNS ISA

评论(7) 引用(0) 浏览(11587)

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