SYN Flood攻击在现实实体机环境中的测试_synflood防御需要开吗

Warning！本文仅为实验记录以及安全测试，请勿用于非法攻击！

SYN Flood原理

TCP协议是面向连接，可靠的，基于字节流的传输层通信协议，通过三次握手来建立客户端与服务端的连接。

TCP三次握手过程如下

客户端A向服务端B发送SYN包请求建立连接，服务端B收到SYN包后会向客户端A发送SYN+ACK包进行连接确认，客户端A回复ACK包后才真正建立TCP连接。

但问题就是，要是A没有回复ACK包，B会一直等待直到超时。B超时后会认为可能是A没有收到，进而重发SYN+ACK包（TCP超时重传 默认重发5次）

当A大量发送SYN包却不进行第三次握手时，B会积累大量处于半连接状态的Socket，使得CPU资源用于处理庞大的半连接队列导致无法处理正常用户的正常网络请求，进入拒绝服务状态。

测试环境

一台win10电脑A的虚拟机kali 一台电脑B的windows10 wireshark

准备工作

开手机热点 kali用桥接模式 建立A、kali、B的连接

A作为客户端来模拟正常访问行为顺带进行虚拟机kali的流量检测工作 IP为192.168.43.86

kali作为攻击机来对B进行FYN Flood攻击 IP为192.168.43.128

B作为服务端 IP为192.168.43.252

在B中开启各种网络服务器 搭建服务器作为靶机

随便搞了个joomla作为网站架构 之前没截图 这是后来重新安装补的截图 所以域名不一样

贴一个大佬的joomla地址Release Joomla! 3.4.5 · joomla/joomla-cms · GitHub

测试客户端A的正常访问 是可以正常访问得到的

客户端A打开wireshark监听Wlan 准备抓包

kali用管理员权限执行命令

hping3 -q -n -a 1.1.1.1 -S -s 53 --keep -p 100 --flood 192.168.43.252

-q安静模式 -n数字化输出主机地址 -a伪造IP -S设置SYN=1 -S设置源端口 -k保持源端口 -p设置目标端口 --flood洪水发包无回显

效果展示

发起攻击后客户端A已经无法连接到192.168.43.252:100网页了

客户端A抓包如下

 用于远程操作的todesk也炸了

 之前顺手在服务端B上也准备了抓包 这是我第一次遇见WLAN黑了的情况

服务端B的网卡炸了 重启了才好...

记得上篇文章说到虚拟机情况下防火墙的开关对SYN Flood的防御效果不一样 于是我又关闭了防火墙进行重复实验，但还是仍然无法访问网页。

防御措施

1.黑名单制度

    若固定来源的IP发起巨量SYN包，直接将此IP拉入黑名单。

2.无效连接监视释放

    通过不停扫描半开放连接队列和不活动连接，达到一定数量时断开这些连接，释放系统资源。

3.SYN Cache技术

    SYN Cache技术是在收到SYN数据报文时不急于去分配TCB，而是先回应一个SYN ACK报文，并在一个专用HASH表（Cache）中保存这种半开连接信息，直到收到正确的回应ACK报文再分配TCB。

4.SYN Cookie技术

    SYN Cookie技术使用一种特殊的算法生成seq，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方的ACK报文后，重新用哈希计算验证，看其是否与对方回应报文中的（seq-1）相同，从而决定是否分配TCB资源。