【网络安全】拒绝服务之SYN Flood同步包风暴详解，理论结合实战演练！（避免拒绝授权访问或拒绝服务攻击的网络安全服务是）

【网络安全】拒绝服务之SYN Flood同步包风暴详解，理论结合实战演练！（避免拒绝授权访问或拒绝服务攻击的网络安全服务是）

网络安全问题在当今时代越来越突出，引用大大说过的话：“没有网络安全就没有国家安全”。曾听闻：不学习信息安全的运维工程师不是一个优秀的运维工程师,在这里说这么多只是想提醒学习运维的同学网络安全对于运维的工作是至关重要的。之前做过很多项目都或多或少遇到过不少安全问题，所以对于安全问题真是深有感触。自从做了运维工作以来对于工作中遇到的安全问题更是层出不穷。今天和大家分享之前项目中遇到过的安全问题：同步包风暴SYN Flood !

一、相关安全知识介绍

网络安全涉及到的attack常见的四个类型：

1、信息泄露-破坏信息的机密性

2、完整性破坏-破坏信息的完整性

3、拒绝服务-破坏系统可用性

4、非法使用-破坏信息合法性

在IT项目中一般遇到的最常见的威胁类型就是拒绝服务,相信做运维的同学都应该遇到过不少。

拒绝服务的类型大致有以下八种：

1、同步包风暴SYS Flood

2、UDP洪水

3、Smurf

4、垃圾邮件

5、消耗cpu和内存资源的拒绝服务

6、死亡之ping

7、泪滴（Teardrop Attack）

8、分布式拒绝服务

其中项目中遇到最多的就是消耗cpu和内存资源的拒绝服务和同步包风暴SYS Flood，在两者中，前者较为简单粗暴，但同时容易被安全防御工具所识别；而后者则更为隐蔽。

二、同步包风暴SYS Flood原理详解

来一段官方介绍：假造源ip和MAC发送多个同步包（syn packet）跟服务器（server），服务器无法收到确认数据包（ACK packet）使tcp/ip协议的三次握手无法顺利完成，因而无法建立连接。其原理是发送大量半连接状态的服务请求，使服务器主机无法处理正常的连接请求，因而影响应用正常运作。

1、tcp协议介绍

需要了解的信息：ACK ： TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1SYN(SYNchronization) ： 在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。对方若同意建立连接，则应在响应报文中使SYN=1和ACK=1. 因此,  SYN置1就表示这是一个连接请求或连接接受报文。synchronization  [ˌsɪŋkrənaɪ'zeɪʃn]  同步FIN （finis）即完，终结的意思， 用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。finis   ['faɪnɪs]  终结

建立tcp连接时的tcp三次握手和断开tcp连接时的4次挥手整体过程

tcp三次握手过程：

3、最后Client 再进行一次确认，设置  ack=y+1.

seq 序列号范围：2^32 -1   到最大值，再从0开始

seq 序列号作用：依据这个序列号来组数据

三、实战演练

上面说了这么多理论知识做铺垫，下面终于开始我们的实战演练。理论知识不牢固的同学一定要认真阅读理解理论知识部分，理论是实战的基石。

实战1：使用tcpdump抓包查看tcp三次握手过程

实验环境：

客户端(kali)：           lwj          192.168.0.109

服务端(centos7.4)： ora11g   192.168.0.106

注：在做实验之前，先检查两台设备的网络连通性。

1、在server端监控22端口数据包

2、打开kali客户端，进行ssh连接

3、返回服务器查看抓包信息：

04:44:55.518460 IP 192.168.0.109.56798 > 192.168.0.106.ssh: Flags [S], seq 2549122601, win 64240, options [mss 1460,sackOK,TS val 686508812 ecr 0,nop,wscale 7], length 0 04:44:55.518525 IP 192.168.0.106.ssh > 192.168.0.109.56798: Flags [S.], seq 2481019190, ack 2549122602, win 28960, options [mss 1460,sackOK,TS val 2146663 ecr 686508812,nop,wscale 7], length 0 04:44:55.518732 IP 192.168.0.109.56798 > 192.168.0.106.ssh: Flags [.], ack 2481019191, win 502, options [nop,nop,TS val 686508812 ecr 2146663], length 0

注：Flags [S]  中的 S 表示为SYN包为1

实战2：tcp断开连接时的 4次挥手过程

客户端kali通过ssh登录server服务器后，抓取ssh远程连接断开后产生的4次挥手包（操作方式大体同实战1，这里就省略。。。。一万字）

60 04:53:33.919665 IP 192.168.0.109.56800 > 192.168.0.106.ssh: Flags [F.], seq 3108747074, ack 3078282445, win 501, options [nop, nop,TS val 687027209 ecr 2665063], length 0 61 04:53:33.919707 IP 192.168.0.106.ssh > 192.168.0.109.56800: Flags [.], ack 3108747075, win 273, options [nop,nop,TS val 266506 4 ecr 687027209], length 0 62 04:53:33.925599 IP 192.168.0.106.ssh > 192.168.0.109.56800: Flags [F.], seq 3078282445, ack 3108747075, win 273, options [nop, nop,TS val 2665069 ecr 687027209], length 0 63 04:53:33.926067 IP 192.168.0.109.56800 > 192.168.0.106.ssh: Flags [.], ack 3078282446, win 501, options [nop,nop,TS val 687027 215 ecr 2665069], length 0

这里只需要看最后4个包就行了。

为什么第二次和第四次没有seq序列号？

因为已经要断开了，没有必要产生新的序列号。

总结：4次挥手

a 我没有数据要传输了，我要断了  -》  b 好   ； b 数据传输完，我也要断了 -》  a 好

*这里抓包完毕后，加入TCP连接状态详解，能加深同学们对tcp协议的印象！

TCP连接状态详解：

服务器端：LISTEN：侦听来自远方的TCP端口的连接请求客户端：SYN-SENT：在发送请求连接后等待匹配的连接请求服务器端：SYN-RECEIVED：再收到和发送一个连接请求后等待对方对连接请求的确认客户端/服务器端：ESTABLISHED：代表一个打开的连接客户端：FIN-WAIT-1：等待远程TCP连接中断请求，或先前的连接中断请求的确认服务器端：CLOSE-WAIT：等待从本地用户发来的连接中断请求客户端：FIN-WAIT-2：从远程TCP等待连接中断请求服务器端：LAST-ACK：等待原来的发向远程TCP的连接中断请求的确认客户端：TIME-WAIT：等待足够的时间以确保远程TCP接收到连接中断请求的确认服务器端：CLOSED：没有任何连接状态

实战3：在局域网中使用 awl伪装ip地址进行多线程

在服务端返回一个确认的SYN-ACK包的时候有个潜在的弊端，如果发起的客户是一个不存在的客户端，那么服务端就不会接到客户端回应的ACK包。这时服务端需要耗费一定的数量的系统内存来等待这个未决的连接，直到等待超关闭，才能释放内存。如果恶意者通过ip欺骗，发送大量SYN包给受害者系统，导致服务端存在大量未解决连接并占用大量内存和tcp连接，从而导致正常客户端无法访问服务端，这就是SYN Flood同步包风暴的过程。

1、在客户端上安编译安装awl

2、在服务器端上安装web环境

3、在客户端上执行相关命令

（1）、arp -n 获取服务端ip对应的MAC

（2）、awl -i ens33 -m 00:0c:29:48:80:95 -d 192.168.0.106 -p 8

4、在web服务端查看，就能发现很多伪装成公网的ip在进行连接80端口并且连接状态为 SYN-RECV-

四、总结和扩展

以上就是拒绝服务之SYN Flood同步包风暴的原理和实战过程。要学会防御SYN Flood同步包风暴，首先要理解他的原理，才能有效的进行针对SYN Flood同步包风暴防御。

SYN Flood同步包风暴其实是属于半连接的一种，关于半连接的方式还可以应用于端口扫描。全连接的扫描，会在被扫描端留下痕迹；而半连接没有完成tcp三次握手，所以我们可以省略第三次握手，同样可以达到扫描对方的目的，但是不会在被扫描端服务器留下记录。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。