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

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报文 连接状态表

评论(1) 引用(0) 浏览(20539)

关于《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

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

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

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