0
点赞
收藏
分享

微信扫一扫

蓝桥杯-队列

Yaphets_巍 03-12 17:30 阅读 2

SYN洪泛攻击属于 DOS 攻击的一种,它利用 TCP 协议缺陷,通过发送大量的半连接请求,耗费 CPU 和内存资源。

原理:

  • 在三次握手过程中,服务器发送 [SYN/ACK] 包(第二个包)之后、收到客户端的 [ACK] 包(第三个包)之前的 TCP 连接称为半连接(half-open connect),此时服务器处于 SYN_RECV(等待客户端响应)状态。如果接收到客户端的 [ACK],则 TCP 连接成功,如果未接受到,则会不断重发请求直至成功。
  • SYN 攻击的攻击者在短时间内伪造大量不存在的 IP 地址,向服务器不断地发送 [SYN] 包,服务器回复 [SYN/ACK] 包,并等待客户的确认。由于源地址是不存在的,服务器需要不断的重发直至超时。
  • 这些伪造的 [SYN] 包将长时间占用未连接队列,影响了正常的 SYN,导致目标系统运行缓慢、网络堵塞甚至系统瘫痪。

检测:当在服务器上看到大量的半连接状态时,特别是源 IP 地址是随机的,基本上可以断定这是一次 SYN 攻击。

防范:

  • 通过防火墙、路由器等过滤网关防护。
  • 通过加固 TCP/IP 协议栈防范,如增加最大半连接数,缩短超时时间。
  • SYN cookies技术。SYN Cookies 是对 TCP 服务器端的三次握手做一些修改,专门用来防范 SYN 洪泛攻击的一种手段。

SYN攻击利用的是TCP的三次握手机制,攻击端利用伪造的IP地址向被攻击端发出请求,而被攻击端发出的响应 报文将永远发送不到目的地,那么被攻击端在等待关闭这个连接的过程中消耗了资源,如果有成千上万的这种连接,主机资源将被耗尽,从而达到攻击的目的。

1、什么是SYN泛洪攻击

 TCP SYN泛洪发生在OSI第四层,这种方式利用TCP协议的特性,就是三次握手。攻击者发送TCP SYN,SYN是TCP三次握手中的第一个数据包,而当服务器返回ACK后,该攻击者就不对其进行再确认,那这个TCP连接就处于挂起状态,也就是所谓的半连接状态,服务器收不到再确认的话,还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接,由于每一个都没法完成三次握手,所以在服务器上,这些TCP连接会因为挂起状态而消耗CPU和内存,最后服务器可能死机,就无法为正常用户提供服务了。

2、SYN泛洪攻击原理

大家都知道一个TCP连接的启动需要经历三次握手的过程。正常情况下客户端首先向服务端发送SYN报文,随后服务端回以SYN+ACK报文到达客户端,最后客户端向服务端发送ACK报文完成三次握手,后续就是上层业务数据交互,直到某一方断开连接。

那么假如在这“握手”的过程中,客户端程序因为莫名崩溃等原因,收到SYN+ACK报文后不再回以ACK,服务端将如何处置呢?这时服务端会“优雅地”再等等,会不会是发送的包丢失了呢?于是重新发送一遍SYN+ACK,再收不到来自客户端的ACK响应的话,就把这次连接丢弃掉。这个过程大约会“优雅地”持续分钟级,这个持续时间被称作SYN timeout时间。如果只有个别这样的异常情况,目标服务端处理起来自是毫不费力;可如果大量这样的情况出现,对服务端来说就不堪重负了。这是为什么呢? 如果大量的握手请求涌向TCP服务端,而它们只发出SYN报文而不以ACK响应结束握手,服务端就要为这每一个请求都维持约一分多钟的连接去等待ACK,也就形成所谓的“半连接”。维护这些半连接是需要消耗很多服务器的网络连接资源的。如果短时间内这些资源几乎都被半连接占满,那么正常的业务请求在这期间就得不到服务,处于等待状态。

更进一步的,如果这些半连接的握手请求是恶意程序发出,并且持续不断,那么就会导致服务端较长时间内丧失服务功能——这就形成了DoS(Denial of Service拒绝服务)攻击。这种攻击方式就称为SYN泛洪(SYN flood)攻击。 由于正常的TCP三次握手中发出去多少SYN报文,就会收到多少SYN+ACK报文。攻击方需要将这些消息丢弃,同时为了隐藏自己,于是需要大量伪造泛洪攻击的源地址,随机改成其它地址。为达到SYN泛洪攻击的效果,这些伪造的源地址最好无法响应SYN+ACK,如这些源地址的主机根本不存在,或者被防火墙等网络设施拦截,等等。

3、防范措施

对于SYN泛洪攻击的防范,优化主机系统设置是常用的手段。如降低SYN timeout时间,使得主机尽快释放半连接的占用;又比如采用SYN cookie设置,如果短时间内连续收到某个IP的重复SYN请求,则认为受到了该IP的攻击,丢弃来自该IP的后续请求报文。此外合理地采用防火墙等外部网络安全设施也可缓解SYN泛洪攻击。

举报

相关推荐

0 条评论