欢迎关注: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) 浏览(18938)

使用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) 浏览(14188)

常见网络分析工具特色功能简介及其在实际工作中的应用之Omnipeek

作者:易隐者 发布于:2012-7-20 21:46 Friday 分类:网络分析

1 Omnipeek简介

       Omnipeek为WildPackets公司开发出品的专业网络分析产品,在国内经过天旦网络分析专家论坛的大力技术推广和宣传,凭借产品本身不错的易用性和特色功能,加之网上随意下载的各个破解版本,使其成为一个广为人知的网络分析工具。

2 Omnipeek相关资源

        Omnipeek厂商主页:
        http://www.wildpackets.com/
        网络分析专家论坛上的Omnipeek专题:
        http://www.netexpert.cn/forum.php?mod=forumdisplay&fid=28
        Omnipeek demo版本下载链接:
        http://www.wildpackets.com/mypeek_registration/demo-ope

阅读全文>>

标签: 过滤器 omnipeek Adpex 插件 plug-in

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

[转]F5负载均衡环境下某应用故障分析案例

作者:易隐者 发布于:2012-7-18 13:45 Wednesday 分类:案例讨论

       本文来自互联网,非我原创,原文章名为《高级TCP/IP网络排错》,该案例出自其第三节:用OmniPeek解决网络中的难题。

       如该案例作者看到我的转载请跟我联系,可以做个朋友,切磋一下技术问题,如果哪位网友知道该案例的原作者,也烦请留言告知。

【我的点评】:

1,充分运用了中间设备自带的抓包功能(对中间设备自带抓包功能感兴趣的兄弟,请参阅我的文章《常见系统和网关设备自带抓包功能介绍及操作指南》),提高了分析效率;

2,整个过程使用对比分析法(参见我的文章《疑难网络故障的分析方法和原理之对比分析法》),发现进出F5报文的差异,快速界定异常问题产生的原因是F5、客户端还是服务器;

3,在做数据包分析之前,确定了业务报文交互路径,明确可能的故障点,为下一步的排查提供了基础,但是从作者给的拓扑结构上看,出来F5之外,这个数据路径应该还会经过那台旁接的防火墙;

4,“F5日志中报端口无法到达”,此问题不太像是指物理端口不可达,个人感觉是指UDP端口不可达的可能性更大一些;

阅读全文>>

标签: 负载均衡 F5 omnipeek RST 应用故障 端口不可达

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

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