关于《DDoS攻击原理及防护方法论》一文的疑问
作者:易隐者 发布于:2012-10-7 20:12 Sunday 分类:网络安全
在网上查找ACK flood攻击相关资料时,发现了51CTO中的一篇名为《DDoS攻击原理及防护方法论》的文章,其链接为:http://netsecurity.51cto.com/art/200903/114969_3.htm,原文大家直接点击链接查看,在此不做引用。
在这篇文章中对ACK flood攻击做了相关的描述,但是我个人对这篇文章有一些疑问,特将其罗列如下,供各位感兴趣的兄弟一起讨论:
1,“如果存在则检查该数据包所表示的状态是否合法,然后再向应用层传递该数据包”
数据包本身并无状态可言,所谓状态是端系统或中间系统根据数据包的交互情况,自行判断的,因此,这里所指的“检查该数据包所表示的状态是否合法”不知到底是什么意思。
2,“例如该数据包所指向的目的端口在本机并未开放,则主机操作系统协议栈会回应RST包告诉对方此端口不存在”
所列举的例子不适用于前文描述的场景,前文描述为“主机在接收到一个带有ACK标志位的数据包的时候,需要检查该数据包所表示的连接四元组是否存在,如果存在则检查该数据包所表示的状态是否合法,然后再向应用层传递该数据包”,而此处列举的例子为端口未开放的场景,既然端口未开放,又何来连接四元组信息?既然无四元组信息,则“检查该数据包所表示的连接四元组是否存在”有从何而来?
3,“可以肯定的是,ACK Flood不但可以危害路由器等网络设备,而且对服务器上的应用有不小的影响”
ACK flood真的可以给路由器带来很大影响吗?首先我们需要明确概念:ACK为传输层的概念,路由为网络层设备,主要负责选路和转发(这个过程会消耗路由的CPU资源),路由器是不会管你是不是ACK报文,其工作的机制过程都是一样的,如果ACK flood攻击的目的主机都是固定的,那么路由器其实只需要在收到第一个ACK flood攻击报文时,调用CPU资源实现选路和转发,后续的ACK flood攻击报文由于目的主机是固定的,其甚至不需要调用CPU资源,直接使用快速转发表即可实现对ACK flood报文的转发,因此,这个说法不科学。值得进一步讨论和推敲。
4,“如果没有开放端口,服务器将直接丢弃,这将会耗费服务器的CPU资源。如果端口开放,服务器回应RST。
”
未开放端口是直接发送RST报文,而不是直接丢弃报文,并且直接RST对CPU资源的消耗并不大;如果端口开放,则检查TCP连接表,有相关信息则做相应的处理,无则发送RST报文。作者后面的这段表述与前面“例如该数据包所指向的目的端口在本机并未开放,则主机操作系统协议栈会回应RST包告诉对方此端口不存在”的表述出现差异,似乎从侧面反应写这篇文章的作者并未深入了解相关工作原理和机制,全文中出现前后矛盾的地方也说明作者很可能从其他地方照搬了很多作者本人未深入理解的内容。
5,“ACK Flood防护
利用对称性判断来分析出是否有攻击存在。所谓对称型判断,就是收包异常大于发包,因为攻击者通常会采用大量ACK包,并且为了提高攻击速度,一般采用内容基本一致的小包发送。这可以作为判断是否发生ACK Flood的依据,但是目前已知情况来看,很少有单纯使用ACK Flood攻击,都会和其他攻击方法混合使用,因此,很容易产生误判。
一些防火墙应对的方法是:建立一个hash表,用来存放TCP连接“状态”,相对于主机的TCP stack实现来说,状态检查的过程相对简化。例如,不作sequence number的检查,不作包乱序的处理,只是统计一定时间内是否有ACK包在该“连接”(即四元组)上通过,从而“大致”确定该“连接”是否是“活动的”。 ”
到底如何防护的?作者在此并未提供什么有价值的信息,仅仅简单的说了一下ACK flood的分析判断。站在网络分析的角度,ACK flood攻击的分析判断跟SYN flood攻击的分析过程大致相同,不同的在于分析其报文的解码,看其TCP标志位。
标签: RST ACK flood 路由器 连接表 DDOS
使用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)