脑洞大开-一种特殊的二层流控协议
作者:飞鸟 发布于: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。
该组播MAC为MAC control包。这个MAC control 协议是做什么的?大家可以先google下。
这种帧用来做流控的,当一接口流量过大时,可以通过发送这种帧来让相应的接口暂停一段时间发包来达到流控的目的。但是这里,我们发现流量也不大,不应该有设备发送这种流控的帧的。后来仔细想了一下,前期该用户被黑产控制过两台肉机对外网进行DDOS。黑产DDOS时最理想的情况就占据所有的带宽,但是这种情况只是理想情况,在实际情况下很难达到,因为其他机器也可以占用网络带宽。在这里,黑客比较脑洞大开的一面展现了,他们控制一台机器专门发送这种流控数据包,让收到、理解并响应的机器暂停一段时间再发包。这里,暂停发包的时间,在mac control帧的pause_time字段来控制。这样的话,如果其他机器理解并响应这种数据包的话,这台机器可以充分的占用带宽来进行DDOS。给黑产的这种思路点个赞。
4、问题
另外,上文还留一个问题:只要有数据包从该接口发出,交换机都会进行MAC地址学习吗?答案是不一定。为什么呢?大家可以先思考一下,或者做实验验证一下,下一期给出答案。
SYN flood+带宽消耗混合式DOS攻击一例
作者:易隐者 发布于:2014-4-11 21:02 Friday 分类:网络安全
一用户新系统上线前,发现流量存在异常,利用wireshark抓包后,查看summary视图,发现其每秒近4000个包,平均包长991字节,如下图所示:我们在通过coversations视图查看其连接情况,发现IP连接会话中,源主机向113.105.171.88、121.12.110.60、121.12.110.61等3个IP交互的报文数远远大于其他IP的,如下图所示:
我们再查看TCP会话,发现交互特征明显,都是发送一个长度为1024字节的报文,如下图所示:
我们回到数据包视图:
看上去基本上都是SYN报文,但是常规的SYN报文一般只有64字节,无应用层数据,而这里其显示存在970字节的应用层数据,这明显是不合常理。
我们查看这些数据包的具体解码,如下图所示:
发现其长度为970字节的应用层数据全部是“0”填充的。
综 合上述分析,基本可判断为黑客利用被拿下的机器,对固定主机发送包含以“0”填充的、长度为970字节的应用数据的SYN Flood攻击报文,在对服务器造成SYNflood攻击效果之外,还会给被攻击主机的互联网出口带宽资源带来较大的消耗,到达综合的拒绝服务攻击效果。
常规DOS攻击手段以前遇到和处理的蛮多,但这种较为聪明和更有效率的混合式DOS攻击方式在实际工作过程中较为少见,是以记之,供各位兄弟姐妹参考。标签: wireshark DOS DOS攻击 SYN flood 混合式DOS攻击 带宽消耗
利用UDP19端口实施DOS攻击的真实案例
作者:易隐者 发布于:2013-10-17 17:06 Thursday 分类:网络安全
昨天在一个用户现场发现了一个利用UDP19端口对互联网受害者主机进行DOS攻击的真实案例。这个情况是我第一次见到,个人认为对以后遇到此类情况的兄弟具有参考价值。有必要做一个简单的分析记录。
在此次的分析过程中,我主要通过wireshark来抓取相关数据报文的。
数据包分析
1,我们首先通过wireshark的“Summary”功能,查看网络流量统计情况,如下图所示:
我们发现服务器区域的流量较大,平均每秒10M左右的流量,这个流量相对于用户整个30M的互联网出口带宽而言,已经算相当大的流量了。
2,我们再通过wireshark的“Protocal Hierarchy”功能,查看这么大的流量在各个协议之间的分布情况,如下图:
我们看到UDP和IP分片的报文流量占据了总流量的92%以上,而业务应用所使用的TCP流量仅有7.24%!这意味着绝大部分的流量都是垃圾流量,那么这些垃圾流量到底是什么呢?
3,我们接下来分析这些占总流量92%以上的UDP报文和IP分片报文到底是用来干什么的。我们通过wireshark的数据包查看UDP报文都是UDP19端口交互的报文,如下图:
我们使用wireshark的“Follow UDP Stream”功能,将其中任意一个UDP19端口交互的报文进行重组还原,如下图所示:
我们可清晰看到这个UDP19端口交互的内容都是明显填充的内容。
4,UDP19端口是用来做什么的呢?我们百度一下,摘录了百度百科中对UDP19端口的相关描述如下:
“端口:19
服务:Character Generator
说明:这是一种仅仅发送字符的服务。UDP版本将会在收到UDP包后回应含有垃圾字符的包。TCP连接时会发送含有垃圾字符的数据流直到连接关闭。HACKER利用IP欺骗可以发动DoS攻击。伪造两个chargen服务器之间的UDP包。同样Fraggle DoS攻击向目标地址的这个端口广播一个带有伪造受害者IP的数据包,受害者为了回应这些数据而过载。”
(该段百度百科描述的原始链接为:
http://baike.baidu.com/link?url=PVKVjqJ4jUhiI6y9bPnrTiVZwSi8vu6mxIw9LxHVqRpmjKWpPJyboZIUddoLL6m3aYVo_LcwgDwSOnLJcElRU_)
5,我们了解了这个UDP19端口的上述信息,那么用户目前遇到的情况是否正是黑客利用其对外进行DOS攻击呢?我们来一起验证一下。
我们通过抓包发现,跟服务器192.168.1.8的UDP端口交互的主机主要有37.17.173.32、88.190.35.204、97.86.229.87、71.61.231.170、等,我们分别来看一下这些IP与192.168.1.8交互报文的解码:
明显发现,这些报文的TTL都是236,这基本可判定这些报文应该都来自于同一物理位置的机器,换句话说,这些报文都是一台机器伪造的IP报文!
6,至此,我们基本可以将此次异常的原因定位为黑客利用服务器开启的UDP19端口,伪造源IP为互联网某受害者服务器的IP地址向192.168.1.8服务器的UDP19端口发送报文,服务器在收到这个报文后会向互联网受害者服务器IP送填充任意字符的报文,导致受害者服务器带宽被占满,从而达到对受害者服务器DOS攻击的效果,其工作机制大致如下图所示:
更进一步的分析
我们分析清楚了异常的原因,但是UDP19端口并不是服务器的对外提供业务的端口,为什么服务器会开启UDP19端口呢?我们在服务器上通过“netstat –ano”命令,查看UDP19端口是由什么进程开启的,如下图所示:
由上图我们知道该端口由进程ID号为1432的进程开启,查看任务管理器,得知该进程为简单TCPIP服务,进程名为tcpsvcs.exe,该进程是微软Windows网络组件的一部分。这个系统进程用于计算机使用专用的TCP/IP网络服务,例如DHCP,简单TCP和打印服务。
通过百度搜索tcpsvcs.exe、UDP19端口等关键字,如下图所示:
我们发现曾有人遇到过这种问题,当事人反馈“win2003 sp2 近来发现tcpsvcs.exe上传速度太猛了,最高时有2m,都差不多占了全部带宽了…….总是国外IP连接19端口,IP禁了几十个,还是不断有新的” (原始链接为:http://bbs.csdn.net/topics/390496813),这说明我们的用户并不是唯一一个遇到这种情况的:黑客利用服务器对外开放的UDP19端口,伪造受害者IP向服务器发送报文,服务器在收到报文后,会向受害者IP发送填充的字符报文,这些报文大部分都是大报文,需要分为多个分片报文,这会产生较大的网络流量,消耗服务器和互联网受害者的网络带宽资源。
标签: wireshark 分片 TTL DOS UDP19端口 tcpsvcs进程 伪造源IP Character Generator tcpsvcs.exe
异常流量分析方法——发现-定位-管控
作者:易隐者 发布于:2012-11-8 21:50 Thursday 分类:网络分析
我们在实际工作环境中遇到各种影响网络系统和业务正常运行的异常流量的概率远远高于遇到疑难故障的概率,在我的博客里已经将疑难杂症的分析方法和思路做了非常深入的阐述(大家可参考《疑难故障分析常规流程和思路》、《疑难网络故障的分析方法和原理之关联分析法》、《疑难网络故障的分析方法和原理之对比分析法》等文),并且我为此撰写了大量的疑难故障的实际分析和解决的案例,我在《疑难故障分析常规流程和思路》一文中,仅仅简单的提到“全局捕包确认异常类型和源头”等寥寥数字,这并不是我疏忽,而是当这些异常流量足以对网络和业务应用产生较为严重影响的时候,其在流量的特性上往往具有较为明显的特征,因此站在网络分析技术的角度,我认为针对这些异常流量的分析是一件非常简单的事情,只要通过简单几个分析步骤和流程,即可快速的定位。但是这些看似简单的方法和流程,对于一些不了解网络分析技术或网络分析初学者来说,却是一件令人头疼的事情,我曾在工作中数次遇到朋友问我:为什么不把这些最常遇到的异常流量问题的分析方法和思路,简单明了的写出来,以助初学者快速入手呢?
我想的确有道理,把这些东西写出来,让更多的朋友能够利用我写的分析方法和思路解决实际工作过程中遇到的问题,岂不是一件快事?但是考虑到高彦刚老师在其《实用网络流量分析技术》一书中,已经对蠕虫、P2P、环路、ARP病毒等常见异常流量的分析案例做了专业的介绍,在此我将不再将高老师已经做过的、非常优秀的事情再做一遍,我主要将异常流量分析的方法和思路总结为一个简单易懂的、通用的分析流程。据此流程,你可以快速的分析定位大部分的异常流量。
该方法并不局限于任何一款具体的网络分析产品和工具,只要你熟练掌握某一种网络分析工具(wireshark、omnipeek、科来或其他),都可以按照这个分析方法,快速的分析定位大部分的异常流量。
什么是异常流量
严格的来讲,正常业务流量之外的流量,都应该归类为异常流量的范畴。但是,除了在工业控制系统等生产网络环境中,可以这样定义异常流量之外,其他的办公网络环境如此严格的定义异常流量都是不合适的。因为在普通的办公网环境下很难保证网内交互的都是业务流量。
在办公网络环境下,办公端系统的应用和管理是非常丰富和复杂的,我们难以做到让每个办公终端在固定的时间内只运行某些固定的业务系统,相反,这些办公终端会根据不同的使用者特性和个人偏好,在不同的时段运行的大量的应用进程,这些进程中可能包含正常的办公应用的进程,也可能包含大量依托于互联网的非业务应用进程,甚至可能包含使用者自己都不知道的第三方插件、木马、病毒等进程。因此,我们还需要定义一个应用更为广泛的狭义上的异常流量。
狭义范畴上的异常流量主要指:病毒、蠕虫、木马、垃圾应用(P2P下载/在线视频/在线游戏等)、攻击(各种DOS攻击流量)等影响网络和业务正常运行的流量。
如此一来,我们便明确了我们需要分析的对象了,如果你是一个初学者,这样是不是感觉更具体一点?是不是有种找到靶心的感觉,哈哈。话不多说,还是跟我一起来开启这趟分析之旅吧。
异常流量分析方法和思路
按照我个人的经验,我将异常流量的分析方法归纳为三大步骤和五个过程,分别为
发现-定位-管控三大步骤和Whether-Who-What -Where-How五个过程。如下图所示:
发现-定位-管控三大步骤
Whether-Who-What -Where-How五个过程
发现-定位-管控三大步骤:
定位(Location):通过分析定位出异常流量的根源、类型、运作模式以及具体的主机位置,为下一步的管控提供全面的信息。
管控(Control):利用现有资源,及时实现对异常流量的管理和控制,消除异常流量对网络和业务正常运转的影响。
Whether-Who-What -Where-How五个过程:
Whether:通过分析,大致判断网络内部是否存在异常流量?
Who:若存在异常流量,异常流量都与谁有关?
What:异常流量是什么类型的?异常流量的运作机制怎样?
Where:异常流量相关的主机都在什么位置?
How:如何实现对异常流量的及时管理和控制?
这三大步骤和五个具体分析过程是相互关联的。下面我们将这三大步骤和五个具体分析过程关联起来进行阐述。
标签: 交换机 TCP wireshark omnipeek 防火墙 IPS 科来 中间设备 UDP 抓包 DOS 攻击 行为特征 发包频率 异常流量 蠕虫 木马 P2P 扫描 TCP会话 UDP会话 平均包长 平均每秒包数 利用率
基于UDP 7000端口的DOS攻击案例
作者:易隐者 发布于:2012-9-24 11:12 Monday 分类:网络安全
在某某用户现场捕获到基于UDP 7000端口实施DOS攻击的报文。
我们简单的看一下大致的分析过程:
1,通过对报文的统计,我们可以看出流量较大,平均包长1266.6字节,大包居多:
2,我们查看数据包交互情况,发现基本上都是192.168.218.112的5444端口发往121.10.173.106的UDP 7000端口的报文,这些报文大小都是1070字节,IP标识逐步递增,在15秒的时间内发送了12192个UDP报文:
3,我们查看其UDP封装的应用字段,发现全部为“AAAAAAAAAAA”的无意义填充数据:
小结:
无论是基于什么端口的,大部分的基于UDP的攻击都是利用UDP无连接的特性,向被攻击者发送大流量的垃圾报文,导致被攻击者的网络带宽资源被占用,造成拒绝服务的攻击效果,这个案例当然也不例外。
标签: UDP 拒绝服务攻击 DOS DOS攻击 UDP 7000端口
日历
最新日志
链接
分类
最新碎语
- 如果一个人想要做一件真正忠于自己内心的事情,那么往往只能一个人独自去做"——理查德·耶茨
2019-06-25 21:34
- 日后我们知道,真正的人生道路是由内心决定的。不论我们的道路看上去如此曲折、如此荒谬地背离我们的愿望,它终归还是把我们引到我们看不见的目的地。(茨威格《昨日世界》)
2019-03-16 21:27
- 如果你渴望得到某样东西,你得让它自由,如果它回到你身边,它就是属于你的,如果它不会回来,你就从未拥有过它。——大仲马《基督山伯爵》
2018-10-09 22:07
- 人生有两大悲剧:一个是没有得到你心爱的东西;另一个是得到了你心爱的东西。人生有两大快乐:一个是没有得到你心爱的东西,于是可以寻求和创造;另一个是得到了你心爱的东西,于是可以去品味和体验。——弗洛伊德
2018-09-25 18:06
- 一个人越有思想,发现有个性的人就越多。普通人是看不出人与人之间的差别的——布莱兹·帕斯卡尔
2018-08-30 18:44
存档
- 2020年11月(2)
- 2018年1月(1)
- 2017年12月(1)
- 2017年11月(6)
- 2017年6月(1)
- 2017年5月(1)
- 2017年4月(1)
- 2017年3月(1)
- 2016年11月(1)
- 2016年4月(1)
- 2015年7月(2)
- 2015年6月(1)
- 2015年5月(5)
- 2014年12月(1)
- 2014年11月(1)
- 2014年10月(1)
- 2014年8月(1)
- 2014年7月(1)
- 2014年6月(1)
- 2014年5月(1)
- 2014年4月(3)
- 2014年2月(2)
- 2014年1月(2)
- 2013年12月(1)
- 2013年11月(1)
- 2013年10月(2)
- 2013年9月(1)
- 2013年8月(1)
- 2013年7月(3)
- 2013年6月(2)
- 2013年5月(1)
- 2013年4月(3)
- 2013年3月(1)
- 2013年2月(2)
- 2013年1月(2)
- 2012年12月(11)
- 2012年11月(12)
- 2012年10月(12)
- 2012年9月(26)
- 2012年8月(29)
- 2012年7月(18)
- 2012年6月(2)
- 2012年5月(25)
- 2012年4月(16)
- 2012年3月(13)
- 2012年2月(6)