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

网络分析能力修行模型

作者:易隐者 发布于:2012-11-14 20:53 Wednesday 分类:网络分析

概述
       数次应业内朋友之邀,为其团队培训网络分析技术,从第一次开始,我就着手架构这个能力修行模型的框架,但还不够完善和成熟。随着我对网络分析技术理解的深入和本身水平的提升以及培训次数的增加,我不断的将其完善,并最终形成现在的雏形。

       根据这个网络分析能力修行模型,初学者可以清晰了解如何入手学习网络分析技术,并按部就班、循序渐进的提升网络分析技术的能力水平。

       所谓“道可顿悟,术需渐修”,但愿此文能够成为诸位网络分析初学者“悟道”的法门。

络运行的本质

       网络运行的本质是什么?是数据报文与协议。 

点击查看原图

       数据报文是网络运行世界里,具有完整信息的、最小的组成单元,而协议则是数据报文在网络内交互必须遵循的规则。因此掌握了这两者,基本上就可以把握网络运行的本质。

       网络分析技术将数据报文和协议完美的结合起来,因此网络分析技术通常也被叫做协议分析、数据包分析或报文分析。那么网络分析到底是如何工作的呢? 

点击查看原图

       网络分析技术是通过捕获网络通讯过程中的数据包(数据包是网络通讯过程中有意义的、最小的组成单元),并通过对捕获到的数据包进行深入的统计和分析,从而洞穿网络各个层面(包括性能、安全、业务以及故障等)运行情况的一种技术。
       通过网络分析技术,我们可以轻松透视网络运行的本质,如果我们的网络分析技术能力非常强,我们的技术水平会远远超出那些只精通于具体设备的工程师们,成为名副其实的网络层面的专家,那么我们如何修行才能提升自己的网络分析技术呢?下面我将通过网络分析能力修行模型展开详细介绍。

网络分析能力修行模型

       我将自己的成长经验总结为下图所示的网络分析能力修行模型: 

点击查看原图

       在这个模型中,围绕网络分析能力的提升,主要包含以下四方面的内容:

 基础

       古语云“千里之行始于足下”、“万丈高楼平地起”。做任何事情都离不开基础,网络分析技术能力的提升同样需要牢固扎实的技术基础作为支撑。

 工具
       古语云“巧妇难为无米之炊”。工具可以帮助我们事半功倍,大大提高我们的工作效率,没有称手的工具,纵然你有一身本领,却难免陷入纷繁复杂的二进制世界难以自拔。

 方法
       古语云“砍柴不照纹,累死砍柴人”。有基础有工具却不得法,虽可解决一些常见问题,但往往是随性而起,难以为继。即使大部分情况下你能成功解决问题,也只能说明你的运气和感觉都还不错,但是你无法将你的运气和感觉传递给你的团队、学生及他人。简言之:无章法,不足道。

 案例
       古语云“纸上得来终觉浅,绝知此事要躬行”。基础牢靠、精通工具、掌握方法,这已经为我们践行网络分析技术做好充分的准备,我们需要在实际工作环境中,把握任何机会,践行自己的网络分析技能,在利用网络分析技术解决问题之后,不断总结,并形成文档;另外一条践行的捷径是讨论学习他人的案例,将他人的经历经验借鉴过来为己所用,在短时间内快速提升自己。总之,多践行,多总结,多学习。

       根据这个网络分析能力修行模型,我将网络分析技术的学习和提升分为四个阶段,如下图所示: 

点击查看原图

第一阶段:打好基础
       这个阶段较为漫长,并且会一直持续伴随整个学习成长的过程。一般而言,这个阶段主要是学习网络基础、各种网络和安全设备的工作原理和机制、不同系统或设备的报文处理流程、TCP/IP协议体系、各常见应用等。在这个阶段,大部分是通过自主学习来获得提升的。

第二阶段:熟悉工具
       在扎实的技术基础上,熟练掌握1-2种网络分析的工具,不会花费太多的时间,但是如想成为高手,必须充分理解各种常见工具的优势特点,学会在不同的情况下,选择性的综合利用这些工具的优势特性,提高我们解决问题的效率。

第三阶段:掌握方法
      掌握网络分析的常规思路,深入理解网络分析方法的原理和使用场景,能够在实际工作环境下,按照网络分析方法和思路展开网络分析工作。

第四阶段:践行案例
       综合利用已学知识和掌握的方法,不断通过实际案例践行网络分析技术,以及对他人案例的学习,让自己的网络分析技术得以快速提升和升华。

       这四个阶段在大的学习和提升方向上是线序的,但这并不是绝对的,比如我们既可以借助他人的案例加固基础知识,又可以在实际案例中提升工具使用的熟练度,也可以利用网络分析工具学习协议体系……

网络分析能力修行模型不同阶段的学习资料

       在我的个人博客蚂蚁网——www.vants.org中,基本涵盖了网络分析能力修行模型中各个阶段学习的内容,下面我将各个阶段的资料做一个统一整理,方便初学者学习参考。

网络分析基础

防火墙的状态检测 http://www.vants.org/?post=24
应用层检测/深度包检测(DPI)http://www.vants.org/?post=23
TCP异常终止(reset报文)http://www.vants.org/?post=22
TCP重传 http://www.vants.org/?post=36
ICMP重组超时 http://www.vants.org/?post=35
TCP SACK选项 http://www.vants.org/?post=74
传输层的响应时间(系统层响应时间/服务器响应时间)http://www.vants.org/?post=115
关于防火墙的arp代理功能对不同格式的arp报文的处理情况的实验 http://www.vants.org/?post=121
ARP代理(Proxy ARP)http://www.vants.org/?post=119
免费ARP(gratuitousARP)http://www.vants.org/?post=118
ARP表的更新和老化http://www.vants.org/?post=120
第三方延时http://www.vants.org/?post=117
应用响应时间(ART)http://www.vants.org/?post=116
ICMP通讯管理性过滤禁止差错报文(type 3,code 13)http://www.vants.org/?post=127
连接数相关知识http://www.vants.org/?post=126
TCP/IP 应用程序的通信连接模式http://www.vants.org/?post=182
TCP保活(TCP keepalive)http://www.vants.org/?post=162
多次RST以及不同场景下的RST报文的差异http://www.vants.org/?post=141
端系统对RST报文的过滤http://www.vants.org/?post=140
经受时延的确认(Delay ACK)http://www.vants.org/?post=114
TCP MSS与PMTUD http://www.vants.org/?post=109
IP分片(IP Fragment) http://www.vants.org/?post=106
TCP 的PUSH标志位http://www.vants.org/?post=102
TCP交互式应用http://www.vants.org/?post=101
基于UDP的应用如何保证应用数据的可靠性http://www.vants.org/?post=99
关于“client push”应用响应时间测量方法的讨论http://www.vants.org/?post=30
iPhone与Multicast DNS        http://www.vants.org/?post=130
非标准TCP三次握手建立连接过程一例http://www.vants.org/?post=91
ACK flood攻击的影响http://www.vants.org/?post=136
基于UDP组播实施分片攻击的可能性http://www.vants.org/?post=98
关于防火墙访问控制的疑问http://www.vants.org/?post=26
TCP/IP 数据包处理路径 http://www.vants.org/?post=188

网络分析工具

常见网络分析工具特色功能简介及其在实际工作中的应用之缘起 http://www.vants.org/?post=43
常见网络分析工具特色功能简介及其在实际工作中的应用之Network Monitor http://www.vants.org/?post=41
常见网络分析工具特色功能简介及其在实际工作中的应用之Omnipeek  http://www.vants.org/?post=66
Wireshark对ping报文的解码显示(BE与LE)http://www.vants.org/?post=133
利用科来与IDS Informer构建网络攻击学习平台http://www.vants.org/?post=31

网络分析方法

疑难故障分析常规流程和思路http://www.vants.org/?post=27
疑难网络故障的分析方法和原理之对比分析法http://www.vants.org/?post=49
疑难网络故障的分析方法和原理之关联分析法http://www.vants.org/?post=51
如何跟踪分析数据经过中间设备后的变化以及这些变化给客户端与服务器带来的影响http://www.vants.org/?post=93
一切皆有可能http://www.vants.org/?post=122
异常流量分析方法——发现-定位-管控http://www.vants.org/?post=185
如何保证中间设备两端捕获的数据包的时间同步性?http://www.vants.org/?post=50

网络分析案例

视频点播服务间歇性中断故障分析案例http://www.vants.org/?post=73
访问搜狐163时主页变为2008年某日主页面故障分析案例http://www.vants.org/?post=89
某学院专网网站打开慢故障分析案例http://www.vants.org/?post=92
FTP登陆故障分析http://www.vants.org/?post=103
某单位经过CA认证的业务应用访问缓慢故障分析案例http://www.vants.org/?post=104
网页打开慢但HTTP下载快故障分析案例http://www.vants.org/?post=128
某业务系统由于连接数限制导致间歇性访问慢故障分析案例http://www.vants.org/?post=125
数据包中出现超长帧的分析http://www.vants.org/?post=184
关于vista系统机器无法通过防火墙上网的故障分析解决案例http://www.vants.org/?post=124
关于服务器端发送FIN报文之前的数秒等待时间行为的分析http://www.vants.org/?post=95
大包传输丢包故障http://www.vants.org/?post=34
两台soho级小路由之间的“正义”之战http://www.vants.org/?post=163
某加密机经天融信防火墙后应用异常故障案例http://www.vants.org/?post=107
负载均衡故障诊断:一个MSS值引发的疑案http://www.vants.org/?post=110
关于网内抓包出现0.33.216.220IP地址问题的分析http://www.vants.org/?post=88
F5负载均衡环境下某应用故障分析案例http://www.vants.org/?post=65
某地税网上申报业务系统故障分析报告http://www.vants.org/?post=58
高新区房产局房产管理业务故障分析解决报告http://www.vants.org/?post=32
某部队部分网段访问总部网站故障分析案例http://www.vants.org/?post=25
IPS在线升级故障分析案例http://www.vants.org/?post=16
使用Omnipeek分析SSH端口攻击案例http://www.vants.org/?post=134
针对随机组播地址的ping攻击案例http://www.vants.org/?post=132
基于UDP 7000端口的DOS攻击案例http://www.vants.org/?post=131
基于UDP 80端口的DOS攻击案例http://www.vants.org/?post=113
可能的数据库密码猜解行为http://www.vants.org/?post=84
PHP漏洞扫描—morfeus fucking scanner  http://www.vants.org/?post=67
web站点cookie安全问题一例http://www.vants.org/?post=64

阅读全文>>

标签: 同步 状态检测 TCP异常终止 团队 IDS Informer 网络分析 数据包分析 协议分析 网络分析能力修行模型

评论(16) 引用(0) 浏览(19415)

MOTS攻击技术分析

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

1.   背景

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

阅读全文>>

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

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

见缝插针-DNS泛解析是怎么被黑客玩坏的

作者:飞鸟 发布于:2017-5-5 12:10 Friday 分类:网络安全

  网络创立之初,所有的访问都是通过IP地址来实现的,因web等协议与应用的兴起,有了域名,再通过IP去访问一方面不太容易记,另一方面因负载、CDN等方面的原因,单纯使用IP地址访问会带来一些问题。因此域名产生了,通过域名访问,中间设备只认识IP,因此最终还是解析到相应的IP地址去访问。这个用来解析的协议称作DNS,主要功能为将域名解析到相应的IP地址。

   ...

阅读全文>>

标签: wireshark DNS 安全分析 泛解析 域名泛解析 DNS泛解析 黑产

评论(2) 引用(0) 浏览(388)

某业务系统访问慢分析

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

脑洞大开-一种特殊的二层流控协议

作者:飞鸟 发布于:2017-3-16 15:18 Thursday 分类:网络分析

脑洞大开-一种特殊的二层流控协议

1、前因

一用户网络出现访问公网时断时续的现象,基本上每隔半小时网络都会断了,然后过一段时间自动好了,然后过半小时左右又断了,然后又自动好了。一整天都在这样的循环,用户经过常规的设备、链路排查,并没有发现奇常。在这种情况下,“捕影”应急响应小组接手处置。

2、应急处置

针对这种这种全局的故障,相对还是比较容易处置的。在交换机上抓包,在故障出现时,选择故障时间点的数据包。发现其平均流量为82.433MBps,平均每秒发包数为171385个。

点击查看原图

 

流量明显不正常。对这些数据包进行深入分析。发现其流量都为二层的流量。

点击查看原图

对二层的流量进行分析,发现一些很有意思的事情。

(1).MAC都为随机伪造的。

我们知道MAC地址一共48位,前24位表示OUI,即厂商信息,后24位表示其MAC地址。这里面我们发现前24位是随机变换的,后24位是相同的。

(2).目的MAC为非设备MAC,其后24位为全0

点击查看原图

3、分析与处置

    故意伪造数据包向一个不存在的MAC发包有意义吗?对网络有影响吗?

答案肯定是有的?对交换机的性能有影响。我们知道交换机是根据MAC和接口的对应关系进行数据包转发,如果交换机收到一个数据包,会调用CPU查找该MAC所对应的接口。使用CPU处理的地方一般情况下都存在被攻击性能的可能。这里面我们看到平均每秒171385个数据包,交换机收到这些数据包以后会利用CPU进行查找MAC所对应的接口,这样的话对交换机的CPU存在性能方面的消耗。

    找到相应的原因以后,处理起来就非常容易了。虽然源MAC是伪造的,但是其肯定是通过交换机的物理端口转发过来的。一般情况下查找MAC表即可查找到相应的接口。注意这里面说的是一般情况下,并不是一定可以找到。难道有MAC过来交换机不会学习MAC与接口的对应关系?在这里,大家可以先思考一下,什么情况下存在这种可能。

    找到接口以后,处置就比较简单了,通过接口找到对应的机器,然后再对该机器进行分析,查找相应的进程即可。

    将该机器物理线拔掉以后,网络正常,再也没有出现过中断的情况。至此该故障已经解决。

    但是我们在他们内网另外一台交换机抓包的时候发现另外一个MAC存在可疑。其发包频率与流量都很大,但是其网络却很正常,和前面所说貌似矛盾,但是仔细想了一下,和交换机有关系,前面抓包在出口处的一台低端交换机上抓到的,这里面是在一台高端交换机上抓取到的,两个不同档次的交换机的性能肯定不一样。所以导致在这里虽然抓取到相应的数据包,但是没有出现网络中断的情况。

点击查看原图

点击查看原图

虽然网络正常,但是这种二层大流量高频率肯定不正常。这台机器肯定存在异常。

点击查看原图

根据上面的思路找到MAC所对应的接口,即可找到相应的机器。但是当我们在交换机上敲上dis mac-addree e411-5be9-9600时却发现找不到相应的接口,多次反复测试均找不到相应的接口。按照交换机源地址学习的工作机制,只要这个MAC从相应的接口发包,交换机就会学习将相应的MAC与接口的对应关系加入到MAC表中。但是这里面却找不到相应的接口,这令我百思不得其解。完全不符合交换机的源地址学习的工作机制。

由于在用户现场,先管不得这么多了,先把问题解决再考虑这个问题,直接通过交换机找到流量最大的接口,直接拔线,简单粗暴酸辣爽。拔完线以后,流量立马下来。问题肯定出现那台机器上了,直接反馈用户,由于是托管在用户方的机器,所以需要沟通再做一步处理。

回过头来,再看看这些包有什么特别之处。发现其目的MAC为组播MAC

点击查看原图

点击查看原图

该组播MACMAC control包。这个MAC control 协议是做什么的?大家可以先google下。

这种帧用来做流控的,当一接口流量过大时,可以通过发送这种帧来让相应的接口暂停一段时间发包来达到流控的目的。但是这里,我们发现流量也不大,不应该有设备发送这种流控的帧的。后来仔细想了一下,前期该用户被黑产控制过两台肉机对外网进行DDOS。黑产DDOS时最理想的情况就占据所有的带宽,但是这种情况只是理想情况,在实际情况下很难达到,因为其他机器也可以占用网络带宽。在这里,黑客比较脑洞大开的一面展现了,他们控制一台机器专门发送这种流控数据包,让收到、理解并响应的机器暂停一段时间再发包。这里,暂停发包的时间,在mac control帧的pause_time字段来控制。这样的话,如果其他机器理解并响应这种数据包的话,这台机器可以充分的占用带宽来进行DDOS。给黑产的这种思路点个赞。

4、问题

另外,上文还留一个问题:只要有数据包从该接口发出,交换机都会进行MAC地址学习吗?答案是不一定。为什么呢?大家可以先思考一下,或者做实验验证一下,下一期给出答案。

阅读全文>>

标签: DOS 二层流控 MAC地址学习 流控

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

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