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

异常流量分析方法——发现-定位-管控

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

       我们在实际工作环境中遇到各种影响网络系统和业务正常运行的异常流量的概率远远高于遇到疑难故障的概率,在我的博客里已经将疑难杂症的分析方法和思路做了非常深入的阐述(大家可参考《疑难故障分析常规流程和思路》、《疑难网络故障的分析方法和原理之关联分析法》、《疑难网络故障的分析方法和原理之对比分析法》等文),并且我为此撰写了大量的疑难故障的实际分析和解决的案例,我在《疑难故障分析常规流程和思路》一文中,仅仅简单的提到“全局捕包确认异常类型和源头”等寥寥数字,这并不是我疏忽,而是当这些异常流量足以对网络和业务应用产生较为严重影响的时候,其在流量的特性上往往具有较为明显的特征,因此站在网络分析技术的角度,我认为针对这些异常流量的分析是一件非常简单的事情,只要通过简单几个分析步骤和流程,即可快速的定位。
       但是这些看似简单的方法和流程,对于一些不了解网络分析技术或网络分析初学者来说,却是一件令人头疼的事情,我曾在工作中数次遇到朋友问我:为什么不把这些最常遇到的异常流量问题的分析方法和思路,简单明了的写出来,以助初学者快速入手呢?
       我想的确有道理,把这些东西写出来,让更多的朋友能够利用我写的分析方法和思路解决实际工作过程中遇到的问题,岂不是一件快事?但是考虑到高彦刚老师在其《实用网络流量分析技术》一书中,已经对蠕虫、P2P、环路、ARP病毒等常见异常流量的分析案例做了专业的介绍,在此我将不再将高老师已经做过的、非常优秀的事情再做一遍,我主要将异常流量分析的方法和思路总结为一个简单易懂的、通用的分析流程。据此流程,你可以快速的分析定位大部分的异常流量。
       该方法并不局限于任何一款具体的网络分析产品和工具,只要你熟练掌握某一种网络分析工具(wireshark、omnipeek、科来或其他),都可以按照这个分析方法,快速的分析定位大部分的异常流量。

什么是异常流量

       严格的来讲,正常业务流量之外的流量,都应该归类为异常流量的范畴。但是,除了在工业控制系统等生产网络环境中,可以这样定义异常流量之外,其他的办公网络环境如此严格的定义异常流量都是不合适的。因为在普通的办公网环境下很难保证网内交互的都是业务流量。
       在办公网络环境下,办公端系统的应用和管理是非常丰富和复杂的,我们难以做到让每个办公终端在固定的时间内只运行某些固定的业务系统,相反,这些办公终端会根据不同的使用者特性和个人偏好,在不同的时段运行的大量的应用进程,这些进程中可能包含正常的办公应用的进程,也可能包含大量依托于互联网的非业务应用进程,甚至可能包含使用者自己都不知道的第三方插件、木马、病毒等进程。因此,我们还需要定义一个应用更为广泛的狭义上的异常流量。

       狭义范畴上的异常流量主要指:病毒、蠕虫、木马、垃圾应用(P2P下载/在线视频/在线游戏等)、攻击(各种DOS攻击流量)等影响网络和业务正常运行的流量。
       如此一来,我们便明确了我们需要分析的对象了,如果你是一个初学者,这样是不是感觉更具体一点?是不是有种找到靶心的感觉,哈哈。话不多说,还是跟我一起来开启这趟分析之旅吧。

异常流量分析方法和思路

       按照我个人的经验,我将异常流量的分析方法归纳为三大步骤和五个过程,分别为
发现-定位-管控三大步骤和Whether-Who-What -Where-How五个过程。如下图所示: 

点击查看原图

发现-定位-管控三大步骤

点击查看原图

Whether-Who-What -Where-How五个过程

发现-定位-管控三大步骤:
发现(Discovery):及时发现当前网络环境中是否存在异常流量。
定位(Location):通过分析定位出异常流量的根源、类型、运作模式以及具体的主机位置,为下一步的管控提供全面的信息。
管控(Control):利用现有资源,及时实现对异常流量的管理和控制,消除异常流量对网络和业务正常运转的影响。

Whether-Who-What -Where-How五个过程:
Whether:通过分析,大致判断网络内部是否存在异常流量?
Who:若存在异常流量,异常流量都与谁有关?
What:异常流量是什么类型的?异常流量的运作机制怎样?
Where:异常流量相关的主机都在什么位置?
How:如何实现对异常流量的及时管理和控制?
       这三大步骤和五个具体分析过程是相互关联的。下面我们将这三大步骤和五个具体分析过程关联起来进行阐述。

阅读全文>>

标签: 交换机 TCP wireshark omnipeek 防火墙 IPS 科来 中间设备 UDP 抓包 DOS 攻击 行为特征 发包频率 异常流量 蠕虫 木马 P2P 扫描 TCP会话 UDP会话 平均包长 平均每秒包数 利用率

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

使用Omnipeek分析SSH端口攻击案例

作者:易隐者 发布于:2012-10-7 19:47 Sunday 分类:网络安全

       在某用户网络环境下发现攻击的实例,为了让大家对omnipeek有个初步直观的了解,此次我使用omnipeek作为分析的工具。

1,我们使用omnipeek打开数据包文件,通过omnipeek的“统计”功能,我们发现,在1分47秒的时间内,共产生了近119万个数据包,如下图所示:

点击查看原图

 并且绝大部分都是小于127字节的小包,这是基本上可以判断网内存在明显的异常发包行为。

2,我们再看omnipeek的“IP Analysis”的统计情况,如下图: 

点击查看原图

TCP SYN报文 25631个,TCP RST报文19247个,这说明基本上绝大部分的SYN连接都被RST了,网内可能存在基于TCP的大规模的扫描行为;

3,我们在查看omnipeek的“节点”统计功能,通过“总字节”参数排序,如下图所示: 

点击查看原图

我们可以清楚的看到绝大部分的流量和数据包都来自于排名前三的IP地址。并且这三个IP地址的发送数据包个数和接收数据包个数都非常巨大。

4,我们可以通告“过滤器”功能来看一下排名第一的IP交互的具体情况,
我们在omnipeek的“专家-层次”功能界面,使用排序功能,针对服务器地址进行排序,如下图所示: 

点击查看原图

点击查看原图

点击查看原图

我们可以明显的看到IP地址为X.X.28.134的主机与68.120.23.0-68.120.236.0网段的大量主机进行了交互,我们查看其交互的报文,如下图所示: 

点击查看原图


发现其都是向68.120.23.0-68.120.236.0网段主机的SSH 应用TCP 22端口发送SYN报文。

由此可得出结论:
       主机X.X.28.134在针对68.120.23.0-68.120.236.0网段进行大规模的SSH端口扫描行为(实际的扫描网段范围很可能更大,因为我们抓包的时间有限,只有1分47秒)。


此同时的ACK flood攻击

       我们在分析的过程中还发现,与X.X.28.134与 68.71.59.244与68.71.59.247两个IP之间存在巨大的交互报文,如下图所示: 

点击查看原图

为什么这两个IP与扫描主机交互的报文如此巨大?我们来具体的看一下这两个IP与扫描主机之间交互的报文:

点击查看原图

这两个IP向扫描主机发送数量巨大的ACK报文(无应用数据,SYN/FIN标志位未置一的报文)。
扫描主机在收到这些ACK报文后的处理方式如下图所示: 

点击查看原图

扫描主机向68.71.59.244的SSH端口发送RST报文。

我们来看一下具体 的ACK报文解码和RST报文解码,先看ACK报文的,如下图所示:

点击查看原图

 仅ACK标志位置一,源主机IP为68.71.59.247,端口为SSH的22端口,针对X.X.28.134主机的60502端口。

我们再看看“数据包”视图:

点击查看原图

       在极短的时间间隔内,同一个TCP会话中,68.71.59.247向X.X.28.134发送大量的ACK报文,这些ACK报文的序列号、确认号等信息完全一致,IP标识逐步递增,这些足以说明这些ACK报文不是简单的快速重传报文,也不是在网内被不断重复捕获的同一数据报文。
我们再看一下X.X.28.134对这些ACK报文回应的RST报文的解码,如下图所示: 

点击查看原图

RST标志位置一,ACK Number为0,说明该连接并不在X.X.28.134的连接表中,或者X.X.28.134并未开放60502端口。

       难道这就是传说的“ACK flood”攻击吗 ?

       忽然想起数年前,我在组织内部培训时,小鲍似乎在准备某个攻击话题时,提到ACK Flood攻击,记得当时我反问小鲍,实施这种攻击的意义何在?它不会像SYN flood攻击那样对防火墙、目的主机造成非常明显的资源消耗的影响,如果有人使用ACK Flood攻击目标主机并不会获得良好的拒绝服务效果,并且固执的认为这种攻击应该不会有人会用的。但是看到这个报文并分析至此,我不得不收回我以前的话,并承认我们遇到的的确就是一个ACK Flood攻击!

        源主机在针对大网段扫描SSH端口,同时被来自互联网的其他两个IP针对其执行扫描的源端口发送大量的ACK报文,实施ACK flood攻击?这是为什么呢?难道是源主机扫描攻击别人,被别人发现,别人就来个复仇计划,用两台高性能服务器对其发其反击?

       真实用户网络环境的各种凌乱,若非亲见,又怎会相信。

阅读全文>>

标签: omnipeek RST SSH ACK flood 攻击 SYN flood 端口扫描

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

针对随机组播地址的ping攻击案例

作者:易隐者 发布于:2012-9-25 11:22 Tuesday 分类:网络安全

       前段时间,某兄弟在用户处遇到一个问题,说是在无线环境下,生产系统中的条码系统经常卡机,迟迟难以定位,网上找到我,并将报文发给我,让我帮忙看看。
       根据他的描述,一开始我以为是个应用系统故障,准备建议其在生产客户端与服务器端同时抓包做对比分析,后来仔细看起报文时,发现了一个主机针对随机的组播IP地址发送ping请求报文,如下图所示: 

点击查看原图

我们查看其中某个报文的解码: 

点击查看原图

       这个主机的网络交互行为特征大致有以下几点:

1,该主机发送了大量的ping报文,但是正常情况下,生产主机不会发送跟生产业务无关的报文,包括ping报文;
2,ping报文的目的地址都是随机的组播地址;
3,ping组播地址的发包频率虽有变化,但是其发包高峰时可以达到毫秒以内的时间间隔

       结合上述三点,我们可以确定为该主机异常行为。

       主机对多播报文的处理流程决定了网内过多的多播报文会对主机和网络性能带来严重的影响。而目前这个很可能只是大规模爆发之前的预演,发包时间间隔较为随机,有些是几毫秒,有些几十秒,真正爆发时,以该数据包文件来看,这台主机可以做到每秒数万的报文,到时候,估计将会出现全网瘫痪的现象。

       一台机器足以单挑一个的网络了! 

阅读全文>>

标签: 组播 多播 ping 攻击 行为特征 发包频率 随机组播地址

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

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