ACK Flood攻击

1 原理

ACK Flood攻击是在TCP连接建立之后,所有的数据传输TCP报文都是带有ACK标志位的,主机在接收到一个带有ACK标志位的数据包的时候,需要检查该数据包所表示的连接四元组是否存在,如果存在则检查该数据包所表示的状态是否合法,然后再向应用层传递该数据包。如果在检查中发现该数据包不合法,例如该数据包所指向的目的端口在本机并未开放,则主机操作系统协议栈会回应RST包告诉对方此端口不存在。

这里,服务器要做两个动作:查表、回应ACK/RST。这种攻击方式显然没有SYN Flood给服务器带来的冲击大,因此攻击者一定要用大流量ACK小包冲击才会对服务器造成影响。按照我们对TCP协议的理解,随机源IP的ACK小包应该会被Server很快丢弃,因为在服务器的TCP堆栈中没有这些ACK包的状态信息。但是实际上通过测试,发现有一些TCP服务会对ACK Flood比较敏感,比如说JSP Server,在数量并不多的ACK小包的打击下,JSP Server就很难处理正常的连接请求。对于Apache或者IIS来说,10kpps的ACK Flood不构成危胁,但是更高数量的ACK Flood会造成服务器网卡中断频率过高,负载过重而停止响应。可以肯定的是,ACK Flood不但可以危害路由器等网络设备,而且对服务器上的应用有不小的影响。抓包:

如果没有开放端口,服务器将直接丢弃,这将会耗费服务器的CPU资源。如果端口开放,服务器回应RST。

2 ACK Flood防护

利用对称性判断来分析出是否有攻击存在。所谓对称型判断,就是收包异常大于发包,因为攻击者通常会采用大量ACK包,并且为了提高攻击速度,一般采用内容基本一致的小包发送。这可以作为判断是否发生ACK Flood的依据,但是目前已知情况来看,很少有单纯使用ACK Flood攻击,都会和其他攻击方法混合使用,因此,很容易产生误判。

一些防火墙应对的方法是:建立一个hash表,用来存放TCP连接“状态”,相对于主机的TCP stack实现来说,状态检查的过程相对简化。例如,不作sequence number的检查,不作包乱序的处理,只是统计一定时间内是否有ACK包在该“连接”(即四元组)上通过,从而“大致”确定该“连接”是否是“活动的”。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
SYN Flood 攻击利用 TCP 协议的三次握手过程中的漏洞来实现攻击。TCP 协议在建立连接时,需要进行三次握手,即: 1. 客户端向服务器发送 SYN 报文。 2. 服务器收到 SYN 报文后,回复 SYN+ACK 报文。 3. 客户端收到 SYN+ACK 报文后,回复 ACK 报文。 在正常情况下,服务器收到客户端的 SYN 报文后,会为该报文分配一个 TCP 连接队列,等待客户端发送 ACK 报文,完成三次握手后建立连接。而 SYN Flood 攻击利用了这个过程中的漏洞,攻击者发送大量的伪造的 SYN 报文,占用了服务器的 TCP 连接队列,导致正常的连接请求无法被处理,从而达到拒绝服务的目的。 具体来说,SYN Flood 攻击的过程如下: 1. 攻击者向目标服务器发送大量的伪造的 SYN 报文,这些报文中随机伪造了源 IP 地址和源端口号,但目标 IP 地址和目标端口号都是相同的。 2. 服务器收到 SYN 报文后,会为该报文分配一个 TCP 连接队列,并等待客户端发送 ACK 报文,完成三次握手后建立连接。 3. 由于攻击者发送的 SYN 报文都是伪造的,因此服务器无法收到客户端的 ACK 报文,TCP 连接队列中的连接一直处于未完成状态,占用了服务器的资源。 4. 当 TCP 连接队列满了后,服务器就无法再为正常的连接请求分配 TCP 连接队列,导致正常的连接请求无法被处理,从而达到拒绝服务的目的。 综上所述,SYN Flood 攻击利用了 TCP 协议的三次握手过程中的漏洞,通过发送大量伪造的 SYN 报文占用服务器的 TCP 连接队列,导致正常的连接请求无法被处理,从而达到拒绝服务的目的。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值