hping3进行SYN Flood攻击，flood攻击原理及防御_hping3攻击

SYN Flood原理：
客户端向服务端发送大量SYN请求，服务端响应SYN+ACK然后进入SYN-RCVD状态等待客户端进行三次握手最后一步。发送大量SYN请求就会导致服务器产生大量SYN-RCVD队列，直至将服务器的队列资源耗尽达到DOS攻击的目的。

hping3是一个命令行下使用的TCP/IP数据包组装/分析工具，通常web服务会用来做压力测试使用，也可以进行DOS攻击的实验。同样Hping只能每次扫描一个目标。

使用HPING进行压力测试

我们先测试网站正常访问
kali安装httpd服务进行测试。

[root@kali]# yum install -y httpd

[root@kali]# systemctl start httpd
1
2
3

浏览器访问 http://192.168.1.63/
对 http://192.168.1.63/ 进行压力测试

hping3 -c 1000 -d 120 -S -w 64 -p 80 --flood --rand-source 192.168.1.63
1

-c 1000 = 发送的数据包的数量。

-d 120 = 发送到目标机器的每个数据包的大小。单位是字节
-d --data data size (default is 0) 发送数据包大小，缺省是0。

-S = 只发送SYN数据包。

-w 64 = TCP窗口大小。

-p 80 = 目的地端口(80是WEB端口)。你在这里可以使用任何端口。

–flood = 尽可能快地发送数据包，不需要考虑显示入站回复。洪水攻击模式。

–rand-source = 使用随机性的源头IP地址。这里的伪造的IP地址，只是在局域网中伪造。通过路由器后，还会还原成真实的IP地址。

我们再次刷新网页发现加载速度已经变慢。
Ctrl+c停止后即可访问速度正常。

hping3参数

root@kali:~# hping3 -h
usage: hping3 host [options]
  -h  --help      show this help
  -v  --version   show version
  -c  --count     packet count
  -i  --interval  wait (uX for X microseconds, for example -i u1000)
      --fast      alias for -i u10000 (10 packets for second)
      --faster    alias for -i u1000 (100 packets for second)
      --flood      sent packets as fast as possible. Don't show replies.
  -n  --numeric   numeric output
  -q  --quiet     quiet
  -I  --interface interface name (otherwise default routing interface)
  -V  --verbose   verbose mode
  -D  --debug     debugging info
  -z  --bind      bind ctrl+z to ttl           (default to dst port)
  -Z  --unbind    unbind ctrl+z
      --beep      beep for every matching packet received
Mode
  default mode     TCP
  -0  --rawip      RAW IP mode
  -1  --icmp       ICMP mode
  -2  --udp        UDP mode
  -8  --scan       SCAN mode.
                   Example: hping --scan 1-30,70-90 -S www.target.host
  -9  --listen     listen mode
IP
  -a  --spoof      spoof source address
  --rand-dest      random destionation address mode. see the man.
  --rand-source    random source address mode. see the man.
  -t  --ttl        ttl (default 64)
  -N  --id         id (default random)
  -W  --winid      use win* id byte ordering
  -r  --rel        relativize id field          (to estimate host traffic)
  -f  --frag       split packets in more frag.  (may pass weak acl)
  -x  --morefrag   set more fragments flag
  -y  --dontfrag   set don't fragment flag
  -g  --fragoff    set the fragment offset
  -m  --mtu        set virtual mtu, implies --frag if packet size > mtu
  -o  --tos        type of service (default 0x00), try --tos help
  -G  --rroute     includes RECORD_ROUTE option and display the route buffer
  --lsrr           loose source routing and record route
  --ssrr           strict source routing and record route
  -H  --ipproto    set the IP protocol field, only in RAW IP mode
ICMP
  -C  --icmptype   icmp type (default echo request)
  -K  --icmpcode   icmp code (default 0)
      --force-icmp send all icmp types (default send only supported types)
      --icmp-gw    set gateway address for ICMP redirect (default 0.0.0.0)
      --icmp-ts    Alias for --icmp --icmptype 13 (ICMP timestamp)
      --icmp-addr  Alias for --icmp --icmptype 17 (ICMP address subnet mask)
      --icmp-help  display help for others icmp options
UDP/TCP
  -s  --baseport   base source port             (default random)
  -p  --destport   [+][+]<port> destination port(default 0) ctrl+z inc/dec
  -k  --keep       keep still source port
  -w  --win        winsize (default 64)
  -O  --tcpoff     set fake tcp data offset     (instead of tcphdrlen / 4)
  -Q  --seqnum     shows only tcp sequence number
  -b  --badcksum   (try to) send packets with a bad IP checksum
                   many systems will fix the IP checksum sending the packet
                   so you'll get bad UDP/TCP checksum instead.
  -M  --setseq     set TCP sequence number
  -L  --setack     set TCP ack
  -F  --fin        set FIN flag
  -S  --syn        set SYN flag
  -R  --rst        set RST flag
  -P  --push       set PUSH flag
  -A  --ack        set ACK flag
  -U  --urg        set URG flag
  -X  --xmas       set X unused flag (0x40)
  -Y  --ymas       set Y unused flag (0x80)
  --tcpexitcode    use last tcp->th_flags as exit code
  --tcp-mss        enable the TCP MSS option with the given value
  --tcp-timestamp  enable the TCP timestamp option to guess the HZ/uptime
Common
  -d  --data       data size                    (default is 0)
  -E  --file       data from file
  -e  --sign       add 'signature'
  -j  --dump       dump packets in hex
  -J  --print      dump printable characters
  -B  --safe       enable 'safe' protocol
  -u  --end        tell you when --file reached EOF and prevent rewind
  -T  --traceroute traceroute mode              (implies --bind and --ttl 1)
  --tr-stop        Exit when receive the first not ICMP in traceroute mode
  --tr-keep-ttl    Keep the source TTL fixed, useful to monitor just one hop
  --tr-no-rtt       Don't calculate/show RTT information in traceroute mode
ARS packet description (new, unstable)
  --apd-send       Send the packet described with APD (see docs/APD.txt)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

hping3 host [options]

  -h  --help        	显示帮助
  -v  --version     	显示版本
  -c  --count       	发送数据包的数目
  -i  --interval    	发送数据包间隔的时间 (uX即X微秒, 例如： -i u1000)
      --fast        	等同 -i u10000 (每秒10个包)
      --faster      	等同 -i u1000 (每秒100个包)
      --flood       	尽最快发送数据包，不显示回复
  -n  --numeric     	数字化输出，象征性输出主机地址
  -q  --quiet       	安静模式
  -I  --interface   	网卡接口 (默认路由接口)
  -V  --verbose     	详细模式
  -D  --debug       	调试信息
  -z  --bind        	绑定 ctrl+z 到 ttl (默认为目的端口)
  -Z  --unbind      	取消绑定 ctrl+z 键
      --beep        	对于接收到的每个匹配数据包蜂鸣声提示
  
模式选择  
  default mode      	默认模式是TCP
  -0  --rawip       	RAW IP模式，原始IP模式。在此模式下Hping3会发送带数据的IP头。即裸IP方式。使用RAWSOCKET方式
  -1  --icmp        	ICMP模式，此模式下Hping3会发送IGMP应答报，你可以用 --icmptype,--icmpcode 选项发送其他类型/模式的ICMP报文
  -2  --udp         	UDP模式，默认Hping3会发送UDP报文到主机的0端口，你可以用 --baseport,--destport,--keep 选项指定端口
  -8  --scan        	扫描模式，扫描指定的端口
                    	Example: hping3 --scan 1-30,70-90 -S www.target.host
  -9  --listen      	监听模式
    
IP 模式  
  -a  --spoof       	源地址欺骗。伪造自身IP，对目的进行攻击，防火墙就不会记录你的真实IP了，当然回应的包你也接收不到了
  	  --rand-dest   	随机目的地址模式，详细使用 man 命令
      --rand-source 	随机源地址模式，详细使用 man 命令
  -t  --ttl         	指定 ttl 值 (默认 64)
  -N  --id          	hping3 中的 ID 值，缺省为随机值
  -W  --winid       	使用 win* id 字节顺序，针对不同的操作系统。UNIX,WINDIWS的id回应不同，这选项可以让你的ID回应和WINDOWS一样
  -r  --rel         	相对id字段(用于评估主机流量)  //更改ID的，可以让ID曾递减输出，详见HPING-HOWTO
  -f  --frag        	将数据包拆分成更多的frag，可能通过弱访问控制列表（acl）	//分段，可以测试对方或者交换机碎片处理能力，缺省16字节
  -x  --morefrag    	设置更多的分段标志    //大量碎片，泪滴攻击
  -y  --dontfrag    	设置不分段标志    //发送不可恢复的IP碎片，这可以让你了解更多的MTU PATH DISCOVERY
  -g  --fragoff     	set the fragment offset    //设置断偏移
  -m  --mtu         	设置虚拟最大传输单元，当大于MTU时分段；如果数据包大于MTU，等同于使用 --frag 选项
  -o  --tos         	tos字段，服务类型，缺省值为0x00，通过 hping3 --tos help 命令查看详细
  -G  --rroute     		记录IP路由，并显示路由缓冲
      --lsrr        	松散源路由并记录路由 (loose source routing and record route)
      --ssrr        	严格源路由并记录路由 (strict source routing and record route)
  -H  --ipproto     	设置IP协议字段，仅在RAW IP模式下使用
  
ICMP 模式
  -C  --icmptype    	icmp类型，默认回显(echo)请求
  -K  --icmpcode    	icmp代号，默认0
      --force-icmp  	发送所有icmp类型(默认仅发送支持的类型)
      --icmp-gw     	设置ICMP重定向网关地址(默认0.0.0.0)
      --icmp-ts     	等同 --icmp --icmptype 13 (ICMP 时间戳)
      --icmp-addr   	等同 --icmp --icmptype 17 (ICMP 地址子网掩码)
      --icmp-help   	显示其他icmp选项帮助
  
UDP/TCP 模式
  -s  --baseport    	设置源端口，默认为随机源端口
  -p  --destport    	设置目的端口，默认端口为0
  -k  --keep        	保持源端口不变
  -w  --win         	win的滑动窗口。windows发送字节(默认64)
  -O  --tcpoff      	set fake tcp data offset(instead of tcphdrlen / 4)    //设置伪造tcp数据偏移量(取代tcp地址长度/4)
  -Q  --seqnum      	仅显示tcp序列号
  -b  --badcksum    	(尝试)发送具有错误IP校验和的数据包，所以你会得到错误UDP/TCP校验和。但是许多系统会修复发送数据包的IP校验和
  -M  --setseq      	设置TCP序列号
  -L  --setack      	set TCP ack，不是 TCP 的 ACK 标志位
  -F  --fin         	set FIN flag  
  -S  --syn         	set SYN flag  
  -R  --rst         	set RST flag  
  -P  --push        	set PUSH flag  
  -A  --ack         	set ACK flag，设置 TCP 的 ACK 标志位
  -U  --urg         	set URG flag      //一大堆IP报头的设置
  -X  --xmas        	set X unused flag (0x40)
  -Y  --ymas        	set Y unused flag (0x80)
      --tcpexitcode     使用last tcp->th_flags 作为退出码
      --tcp-mss         使用给定的值启用TCP MSS选项
      --tcp-timestamp   启用TCP时间戳选项来猜测HZ/uptime
  
通用设置  
  -d  --data        	发送数据包的大小，默认为0
  -E  --file        	发送指定文件内的数据
  -e  --sign        	添加“签名”
  -j  --dump        	转储为十六进制数据包
  -J  --print       	转储为可打印字符
  -B  --safe        	启用“安全”协议
  -u  --end         	告诉你什么时候--file达到EOF并防止倒回
  -T  --traceroute  	traceroute模式(等同使用 --bind 且 --ttl 1)
      --tr-stop     	在traceroute模式下，收到第一个非ICMP报文时退出
      --tr-keep-ttl 	保持源TTL固定，仅用于监视一跳
      --tr-no-rtt   	不要在traceroute模式下计算或显示RTT信息

ARS packet description (new, unstable)
      --apd-send    	发送用APD描述的数据包(参见docs/APD.txt)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93

Syn_Flood概述

Syn-Flood攻击是当前网络上最为常见的DDoS攻击，也是最为经典的拒绝服务攻击，它利用了TCP协议实现上的一个缺陷，通过向网络服务所在端口发送大量的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。

这种攻击早在1996年就被发现，但至今仍然显示出强大的生命力。很多操作系统，甚至防火墙、路由器都无法有效地防御这种攻击，而且由于它可以方便地伪造源地址，追查起来非常困难。它的数据包特征通常是，源发送了大量的SYN包，并且缺少三次握手的最后一步握手ACK回复。

Syn-Flood攻击属于TCP攻击中的一种，Flood类攻击中最常见，危害最大的是Syn-Flood攻击，也是历史最悠久的攻击之一，在了解Syn-Flood攻击之前，可以先看看TCP攻击详解。

Syn_Flood攻击原理

攻击者首先伪造地址对服务器发起SYN请求（我可以建立连接吗？），服务器就会回应一个ACK+SYN（可以+请确认）。而真实的IP会认为，我没有发送请求，不作回应。服务器没有收到回应，会重试3-5次并且等待一个SYN Time（一般30秒-2分钟）后，丢弃这个连接。

如果攻击者大量发送这种伪造源地址的SYN请求，服务器端将会消耗非常多的资源来处理这种半连接，保存遍历会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。TCP是可靠协议，这时就会重传报文，默认重试次数为5次，重试的间隔时间从1s开始每次都番倍，分别为1s + 2s + 4s + 8s +16s = 31s,第5次发出后还要等32s才知道第5次也超时了，所以一共是31 + 32 = 63s。

也就是说一共假的syn报文，会占用TCP准备队列63s之久，而半连接队列默认为1024，系统默认不同，可 cat /proc/sys/net/ipv4/tcp_max_syn_backlog c查看。也就是说在没有任何防护的情况下，每秒发送200个伪造syn包，就足够撑爆半连接队列，从而使真正的连接无法建立，无法响应正常请求。 最后的结果是服务器无暇理睬正常的连接请求—拒绝服务。

攻击细节：

为了提高发送效率在服务端产生更多的SYN等待队列，攻击程序在填充包头时，IP首部和TCP首部都不填充可选的字段，因此IP首部长度恰好是20字节，TCP首部也是20字节，共40字节。

对于以太网来说，最小的包长度数据段必须达到46字节，而攻击报文只有40字节，因此，网卡在发送时，会做一些处理，在TCP首部的末尾，填充6个0来满足最小包的长度要求。这个时候，整个数据包的长度为14字节的以太网头，20字节的IP头，20字节的TCP头，再加上因为最小包长度要求而填充的6个字节的0，一共是60字节。

但这还没有结束。以太网在传输数据时，还有CRC检验的要求。网卡会在发送数据之前对数据包进行CRC检验，将4字节的CRC值附加到包头的最后面。这个时候，数据包长度已不再是40字节，而是变成64字节了，这就是常说的SYN小包攻击，数据包结构如下：

|14字节以太网头部|20字节IP头部|20字节TCP|6字节填充|4字节检验|
 
|目的MAC|源MAC|协议类型| IP头 |TCP头|以太网填充 | CRC检验 |
1
2
3

到64字节时，SYN数据包已经填充完成，准备开始传输了。攻击数据包很小，远远不够最大传输单元(MTU)的1500字节，因此不会被分片。那么这些数据包就像生产流水线上的罐头一样，一个包连着一个包紧密地挤在一起传输吗?事实上不是这样的。

以太网在传输时，还有前导码(preamble)和帧间距(inter-frame gap)。其中前导码占8字节(byte)，即64比特位。前导码前面的7字节都是10101010，1和0间隔而成。但第八个字节就变成了10101011，当主机监测到连续的两个1时，就知道后面开始是数据了。在网络传输时，数据的结构如下：

|8字节前导码|6字节目的MAC地址|6字节源MAC地址|2字节上层协议类型|20字节IP头|20字节TCP头|6字节以太网填充|4字节CRC检验|12字节帧间距|
1

也就是说，一个本来只有40字节的SYN包，在网络上传输时占的带宽，其实是84字节。

Syn_Flood防御

1、cookie源认证：

原理是syn报文首先由DDOS防护系统来响应syn_ack。带上特定的sequence number （记为cookie）。真实的客户端会返回一个ack 并且Acknowledgment number 为cookie+1。 而伪造的客户端，将不会作出响应。这样我们就可以知道那些IP对应的客户端是真实的，将真实客户端IP加入白名单。下次访问直接通过，而其他伪造的syn报文就被拦截。下面为防护示意图：

2、reset认证：

Reset认证利用的是TCP协议的可靠性，也是首先由DDOS防护系统来响应syn。防护设备收到syn后响应syn_ack,将Acknowledgement number (确认号)设为特定值（记为cookie）。当真实客户端收到这个报文时，发现确认号不正确，将发送reset报文，并且sequence number 为cookie + 1。 而伪造的源，将不会有任何回应。这样我们就可以将真实的客户端IP加入白名单。

3、TCP首包丢弃:

该算法利用了TCP/IP协议的重传特性，来自某个源IP的第一个syn包到达时被直接丢弃并记录状态(五元组)，在该源IP的第2个syn包到达时进行验证，然后放行。

当防御设备接到一个IP地址的SYN报文后:

接受到syn报文      -> 简单比对该IP是否存在于白名单中:   存在则转发到后端，否则进行第2步
不存在于白名单中 -> 检查是否是该IP在一定时间段内的首次SYN报文： 不是则进行第3步，是则进行第5步
不是首次SYN报文 -> 检查是否重传报文： 是重传则转发并加入白名单，不是则丢弃并加入黑名单
是首次SYN报文    ->  丢弃并等待一段时间以试图接受该IP的SYN重传报文，等待超时则判定为攻击报文加入黑名单。
1
2
3
4

首包丢弃方案对用户体验会略有影响，因为丢弃首包重传会增大业务的响应时间，有鉴于此发展出了一种更优的TCP Proxy方案。所有的SYN数据报文由清洗设备接受，按照SYN Cookie方案处理。和设备成功建立了TCP三次握手的IP地址被判定为合法用户加入白名单，由设备伪装真实客户端IP地址再与真实服务器完成三次握手，随后转发数据。而指定时间内没有和设备完成三次握手的IP地址，被判定为恶意IP地址屏蔽一定时间。除了SYN Cookie结合TCP Proxy外，清洗设备还具备多种畸形TCP标志位数据包探测的能力，通过对SYN报文返回非预期应答测试客户端反应的方式来鉴别正常访问和恶意行为。

清洗设备的硬件具有特殊的网络处理器芯片和特别优化的操作系统、TCP/IP协议栈，可以处理非常巨大的流量和SYN队列。

Syn Ack Flood 防御:

如果服务器没有主动发起连接的需求，直接将所以syn_ack包丢弃即可。
如果有对外连接的需求，则可利用源认证的方式防御，具体防护原理为： 向syn_ack的源IP，端口发送syn报文，能在固定时间内返回，并且序列号匹配则说明该IP，端口确实提高了服务，加入白名单。多次未防护的加入黑名单。

Ack Flood 攻击:

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

这里，服务器要做两个动作：查表、回应ACK/RST。这种攻击方式显然没有SYN Flood给服务器带来的冲击大，因此攻击者一定要用大流量ACK小包冲击才会对服务器造成影响。按照我们对TCP协议的理解，随机源IP的ACK小包应该会被Server很快丢弃，因为在服务器的TCP堆栈中没有这些ACK包的状态信息。

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

可以肯定的是，ACK Flood不但可以危害路由器等网络设备，而且对服务器上的应用有不小的影响。

Ack Flood 防御:

利用对称性判断来分析出是否有攻击存在。所谓对称型判断，就是收包异常大于发包，因为攻击者通常会采用大量ACK包，并且为了提高攻击速度，一般采用内容基本一致的小包发送，这可以作为判断是否发生ACK Flood的依据。

但是目前已知情况来看，很少有单纯使用ACK Flood攻击，都会和其他攻击方法混合使用，因此，很容易产生误判。

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

其他 Flood 攻击与防御

主要的攻击原理都为利用大量的无效数据包，消耗服务器资源。由于攻击报文命中五元组和序列号的概率极低，所以对正常连接破坏有限（服务器资源充足的情况下）。

针对这些类型的攻击的处理方式也正是利用上面的特点。在连接建立的时候，利用syn_reset ，syn_cookie认证，认证通过之后，为每个tcp连接建立一个会话，保存五元组和序列号信息，只有匹配的包才转发到服务器，不匹配的丢弃。 关于上述认证的详解。

史上最大型DDoS攻击：每秒5亿个数据包（Imperva）

今年初，Imperva应客户要求缓解了一起每秒数据包数量超5亿个的DDoS攻击，可能是按数据包规模计的史上最大型DDoS攻击。

1月10号的攻击是所谓的SYN洪水攻击——攻击者通过发送超出目标计算机处理能力的TCP连接请求令该主机掉线。Imperva称，本次攻击中所用洪水数据包既有正常SYN包，也有大小在800-900字节之间的超大SYN包，源IP地址和端口也是高度随机的。

攻击者往往综合采用正常包和超大包攻击，正常SYN包耗尽CPU等服务器资源，而超大SYN包用于阻塞网络。

Imperva的调查发现，1月初的攻击采用了两个已知工具，一个用于发起正常SYN流量洪水，另一个制造超大SYN包攻击。这两个工具似乎是不同作者编写，然后被人组合使用在了互联网历史上最密集的网络基础设施DDoS攻击上。

公司企业和媒体往往倾向于关注DDoS攻击的规模。但实际上，规模并不是攻击缓解难度或破坏程度的最佳反映。每秒包数量(PPS)是个更好的指标。

去年GitHub遭受的攻击，其峰值流量达到1.35TB每秒，堪称史上最大带宽密集型DDoS攻击。该攻击吸引了大量关注，常被当作大型DDoS攻击可致巨大挑战的典型例子。

缓解难点

从缓解的立场看，提供足够的网络带宽可以减弱这种攻击。当下的DDoS攻击缓解及防护服务倾向于提供远超目前最大型DDoS攻击规模的带宽。这使得攻击规模不再成为令公司企业头痛的问题。

但处理涉超高PPS的攻击就是另一码事了，因为评估每个包所需的计算处理能力才是个中关键。限制网络路由器、交换机和服务提供商用以缓解DDoS攻击的设备的，不是数据包的大小，而是其产生速度。缓解高PPS攻击需要的处理能力，远远超出了当前绝大多数网络设备路由或交换数据包的能力。

公司企业提供带宽容量，所以大小往往成为衡量DDoS攻击的标准度量。但高PPS攻击才是公司企业更应该关注的方向。

比如说，GitHub攻击案例中，DDoS流量主要由不同服务器的相同端口发出的大数据包组成，PPS速率相对较低，为1.296亿。而本月初Imperva缓解的这起攻击，从随机源地址发出的包数量几乎是GitHub攻击的4倍。

高PPS攻击更难以产生，因为需要更多的计算资源；同理，其缓解也需要更多计算资源。公司企业应更为关注高PPS攻击。

DDoS攻击的影响最终取决于攻击方式和目标企业的脆弱性。运用得当的话，无论是高带宽的攻击还是高PPS的攻击，都能造成灾难性后果。提前预测多方式DDoS攻击的发展是不可能的。不同方式带来不同的缓解挑战。

比如说，高PPS攻击不会像高带宽攻击那样频繁地阻塞链路。高带宽攻击往往对无辜路人造成连带伤害，用网络拥塞将他们一起挤掉线。

Imperva十大DDoS攻击趋势：

https://www.imperva.com/docs/DS_Incapsula_The_Top_10_DDoS_Attack_Trends_ebook.pdf

Imperva报告：

https://www.imperva.com/blog/this-ddos-attack-unleashed-the-most-packets-per-second-ever-heres-why-thats-important/

参考来源

DDoS攻击–Syn_Flood攻击防护详解(TCP)

DDoS攻击–TCP攻击概述

DDOS攻击如何防御

Linux网络命令之Hping3

ICMP攻击实战及其简略防御方法

模拟SYN洪流攻击实验