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攻击 带宽消耗
ACK flood攻击的影响
作者:易隐者 发布于:2012-10-8 10:14 Monday 分类:网络安全
我们在分析ACK flood攻击对端系统和中间系统的影响之前,首先需要了解端系统和中间系统一般情况下是如何处理其收到的ACK报文。
端系统对ACK flood报文的处理
端系统在收到一个ACK报文时,如果目的端口未开放,那么端系统会直接向源IP发送RST报文,其交互过程大致如下图所示:
如果端系统的相关端口是对外开放的,那么其在收到ACK报文时,首先会检查这个ACK报文是否属于TCP连接表中的一个已有连接(这个过程会对端系统主机CPU资源造成一定的消耗),如果是的话,则正常处理,如果不属于任何一个已有连接,那么端系统会向源IP发送RST报文,交互过程如下图所示:
根据上面两个过程的分析,我们可推论ACK flood攻击对端系统性能的影响并不会非常大,至少跟SYN flood(端系统需要给每个SYN报文分配相应连接表空间,会消耗端系统内存资源)攻击相比,其攻击效果似乎难上台面。
中间系统对ACK flood报文的处理
路由器和防火墙的工作机制决定了路由器和防火墙在处理ACK报文的时候是完全不同的,我们分别将路由器与防火墙对ACK flood攻击的处理过程做简单描述。
路由器是网络层的设备,其主要功能是选路和转发,其选路的依据大部分都是基于网络层信息(目的IP、源IP等),因此路由器在处理ACK报文的时候,其并不关心它是不是ACK报文,它主要关心其目的地址,需要根据其目的地址来进行选路,如果ACK flood攻击的目的主机都是固定的,那么路由器其实只需要在收到第一个ACK flood攻击报文时,调用CPU资源实现选路和转发,后续的ACK flood攻击报文由于目的主机是固定的,其甚至不需要调用CPU资源,直接使用快速转发表即可实现对ACK flood报文的转发,路由器对ACK报文的处理过程大致如下:
防火墙对ACK报文的处理主要跟连接状态表有关,防火墙在收到ACK报文时,首先检查该ACK报文是否属于连接状态表中的已有连接,如果是,防火墙转发该ACK报文,如果未命中任何一个已有连接,防火墙会将该ACK报文丢弃,如下图所示:
ACK Flood攻击对系统的影响
由此来看,ACK flood攻击对端系统与中间系统的影响相对于其他攻击来说都不是非常明显,至于网上有相关资料讲其需要配合SYN flood攻击产生较好的攻击效果,原因为针对防护SYN flood攻击的一种技术 ——SYN cookie技术。
当某些启用SYN cookie技术进行SYN flood攻击防护的中间设备(专业抗DOS设备、防火墙、IPS、负载均衡、路由器等),在收到ACK报文时,需要计算cookie值,这个过程会消耗一部分中间设备的CPU资源,如果大量的ACK报文过来的话,很可能很快就会导致设备资源耗尽,达到拒绝服务的效果。
关于SYN cookie的工作机制,我在互联网上找到一篇文章,文章链接为:
http://blog.csdn.net/force_eagle/article/details/5348946,作者:droplet,现全文引用至此:
“
Cookie如何计算?
cookie = MD5(srcip,dstip,sport,dport)
端口是否需要考虑哪?没有端口的话,可以少一点计算。
Syn-cookie是无状态的,在Gateway上,不会保存任何与connection相关的东西,所以不会占用gateway的资源,缺点就是需要计算cookie,CPU占用会高一点。
如果不考虑端口的话,cookie是不是可以cache哪,如果cache了,就有查找的开销,并不一定比MD5的hash快多少。
在Syn-cookie之前,先要检查一下srcip是不是spoofing的,这里需要做一个反向的路由查找,看看是不是从错误的接口进来的,也可以确认一下源地址是否可达。
是不是也应该做一个源端口的检查哪?如果是0~1024的端口,就默认是非法的,因为这些端口在操作系统里面,一般是保留的,不会分配给应用程序。
Syn attack是否有signatue? 不同的syn flood工具,生成的工具包,应该有一定的模式,如果能够找到这个signature,就可以通过signature来直接drop这个syn,不用再做syn-cookie的检查了。
Syn-cookie会strip掉client和server的tcp option,对client,可疑在cookie里面带上tcp option,但是对server来说,就比较难办一点。strip掉tcp option,对connection的性能有影响。
对syn-flood的防范,目前还是threshold based,因为不能区分正常包和攻击包,但是如果能够定义攻击的signature,就可以做signature based的防范,这样可以更有效一点。”
在这里有个疑问,启用SYN cookie技术的中间设备在收到SYN报文的时候会建立cookie序列,在收到ACK报文的时候会计算cookie是否合法,那么是不是任何一个ACK报文都计算cookie值呢?从全文的描述来看,应该是在收到三次握手的最后一个ACK报文时才进行计算。
如果是对所有ACK报文都进行cookie值计算,这个中间设备对SYN cookie技术的实现是不是非常不科学呢?如果仅针对三次握手时的第三个ACK报文进行cookie值计算,那么中间设备应该直接丢弃随机伪造的ACK flood攻击报文。如果是丢弃随机伪造的ACK flood报文,那么对中间设备资源的消耗也是有限的。
需要申明的是,以上仅为我个人站在技术原理的角度作出的推论,实际环境下没有亲见ACK flood攻击带来的影响。欢迎各位兄弟姐妹一起做进一步的探讨。
标签: TCP RST 防火墙 ACK flood SYN flood 连接表 SYN cookie ACK报文 连接状态表
使用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攻击?这是为什么呢?难道是源主机扫描攻击别人,被别人发现,别人就来个复仇计划,用两台高性能服务器对其发其反击?
真实用户网络环境的各种凌乱,若非亲见,又怎会相信。
日历
最新日志
链接
分类
最新碎语
- 如果一个人想要做一件真正忠于自己内心的事情,那么往往只能一个人独自去做"——理查德·耶茨
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)