DDoS与CC以及常见解决方式

发布于 2020-04-01  50 次阅读


简单说明

DDoS攻击

DDoS攻击(分布式拒绝服务攻击)一般来说是指攻击者利用“肉鸡”对目标网站在较短的时间内发起大量请求(发送大量无用数据),大规模消耗目标网站的主机资源,让它无法正常服务。在线游戏、互联网金融等领域是 DDoS 攻击的高发行业。
DDoS攻击是基于DoS攻击(拒绝服务攻击)基础上产生的一种新的攻击方式,主要特点是分布式,即很多机器同时攻击一台机器,从而产生更大的威力。

CC攻击

CC攻击是DDOS(分布式拒绝服务)的一种,相比其它的DDOS攻击CC似乎更有技术含量一些。这种攻击你见不到真实源IP(大部分基于HTTP-PROXY),见不到特别大的异常流量,但是破坏性非常大,直接导致系统服务挂了无法正常服务。
CC攻击主要是针对业务一些比较消耗资源的地方,比如搜索框,发起大量请求,导致目标机资源占满,无法处理正常请求。

被攻击现象

如何判断是否遭受DDoS攻击?

  1. 被攻击主机上有大量等待的连接
  2. 网络中充斥着大量无用数据包
  3. 源地址为假,制造高流量无用数据,造成网络拥塞,使受害主机无法正常和外界通讯
  4. 利用受害主机提供的传输协议上的缺陷,反复高速地发出特定的服务请求,使主机无法处理所有正常请求
  5. 严重时会造成系统死机。

利用原理

DDoS和CC都是利用了TCP/IP协议的缺陷

差异

  1. DDoS是基于IP的攻击,而CC是专门针对服务的攻击
  2. DDoS防护成本高,危害大,CC虽然不是毁灭性的,但是成本相对较低,也能达到不错的效果
  3. DDoS门槛高(那些傻瓜式页端除外),CC门槛低一些,利用脚本+代理池即可实现
  4. DDoS主要是流量攻击,需要流量更大,CC攻击一般不需要很大流量,因为都是模拟正常浏览请求

CC攻击防护难点

  1. CC 攻击的 ip 都是真实的,分散的
  2. CC 攻击的数据包都是正常的数据包
  3. CC 攻击的请求都是有效请求,且无法拒绝
  4. CC 攻击的大部分是网页,服务器可以连接,ping 也没问题,但是网页就是访问不了
  5. 如果服务一开,机器很快资源占满,服务器很快就死,且可能丢包。
  6. 常见防护方式容易对SEO和用户体验不友好,比如常见的验证码,5秒盾等,即使是js自动跳转的方式对SEO也是非常不友好。

DDoS攻击防护难点

  1. 危害大,一般稍大规模的没有硬件墙根本无法防护
  2. 防护成本高,一般高防服务器价格都很贵,且市面假防较多0

常见DDoS攻击

SYN攻击

介绍

SYN(synchronous)是TCP/IP建立连接时使用的握手信号。在客户机和服务器之间建立正常的TCP网络连接时,客户机首先发出一个SYN消息,服务器使用SYN+ACK应答表示接收到了这个消息,最后客户机再以ACK消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接,数据才可以在客户机和服务器之间传递。

SYN洪水攻击

正常TCP三次握手建立连接的过程首先是客户端发送一个SYN报文给服务端,然后这个服务端发送一个SYN-ACK包以回应客户端,接着,客户端就返回一个ACK包来实现一次完 整的TCP连接。在服务端返回一个确认的SYN-ACK包的时候有个潜在的弊端,他可能不会接到客户端回应的ACK包。这个也就是所谓的半开放连接,服务端需要耗费一定的数量的系统内存来等待这个未决的连接,虽然这个数量是受限的,但是恶意者可以通过创建很多的半开放式连接来发动SYN洪水攻击 。
通过ip欺骗可以很容易的实现半开放连接。攻击者发送SYN包给服务端系统,这个看起来是合法的,但事实上所谓的客户端根本不会回应这个 。SYN-ACK报文,这意味着服务端将永远不会接到ACK报文。 而此时,半开放连接将最终耗用受害者所有的系统资源,受害者将不能再接收任何其他的请求。通常等待ACK返回包有超时限制,所以半开放 。
连接将最终超时,而受害者系统也会自动修复。虽然这样,但是在受害者系统修复之前,攻击者可以很容易的一直发送虚假的SYN请求包来持续攻击。 在大多数情况下,受害者几乎不能接受任何其他的请求,但是这种攻击不会影响到已经存在的进站或者是出站连接。虽然这样,受害者系统 还是可能耗尽系统资源,以导致其他种种问题。
攻击系统的位置几乎是不可确认的,因为SYN包中的源地址多数都是虚假的。当SYN包到达受害者系统的时候,没有办法找到他的真实地址 ,因为在基于源地址的数据包传输中,源ip过滤是唯一可以验证数据包源的方法。

防护方式 之 SYN cookie

就和他的名字一样,SYN cookie就是用一个cookie来响应TCP SYN请求的TCP实现,根据上面的描述,在正常的TCP实现中,当服务端接收到一个SYN数据包,他返回 一个SYN-ACK包来应答,然后进入TCP-SYN-RECV(半开放连接)状态来等待最后返回的ACK包。服务端用一个数据空间来描述所有未决的连接, 然而这个数据空间的大小是有限的,所以攻击者将塞满这个空间。 在TCP SYN COOKIE的执行过程中,当服务端接收到一个SYN包的时候,他返回一个SYN-ACK包,这个数据包的ACK序列号是经过加密的,也就 是说,它由源地址,端口源次序,目标地址,目标端口和一个加密种子计算得出。然后服务端释放所有的状态。如果一个ACK包从客户端返回, 服务端将重新计算它来判断它是不是上个SYN-ACK的返回包。如果这样,服务端就可以直接进入TCP连接状态并打开连接。从而使服务端避免守侯半开放连接。

防护原理

1:一个SYN包从客户端发送到服务端。
2:防火墙在这里扮演了服务端的角色来回应一个带SYN cookie的SYN-ACK包给客户端。
3:客户端发送含有cookie的ACK包,接着防火墙和客户端的连接就建立了。
4:防火墙这个时候再扮演客户端的角色发送一个SYN给服务端。
5:服务端返回一个SYN给客户端 。
6:防火墙扮演客户端发送一个ACK确认包给服务端,这个时候防火墙和服务端的连接也就建立了 。
7:防火墙转发客户端和服务端之间的数据 。
如果系统遭受SYN Flood,那么第三步就不会有,而且无论在防火墙还是服务端都不会收到相应在第一步的SYN包,所以我们就击退了这次SYN洪水攻击。

这种属于加固协议栈实现的防护,资源消耗是在服务器上,防不了很大的攻击,必要时还是要借助硬件防火墙

防护原理之 减少SYN-ACK数据包的重发次数

当Linux检测到数据包无返回时会自动尝试重发,这无疑增大了资源消耗,减少这个数值可以实现一定防范

防护原理之 对SYN限速

既然是攻击,不能完全防住,能抑制住也是个很不错的方案,可以借助iptables等实现syn限速
!!!注意! 可能对正常业务造成影响!!!

防护原理之 增大backlog队列

backlog的值是网络连接过程中,某种状态的队列的长度;如果并发过高,那么会导致backlog的队列占满,服务器就会丢掉传进来的其他连接,然后就会出现客户端连接失败的情形
增大backlog队列,可以相对来说减少一些影响

检测方式

bash中输入netstat -n -p TCP,有好多SYN_RECV状态的连接

防护实现方式

Windows当我没说,一攻击就凉
Linux的实现:(参数根据实际情况设置)

方式1:减少SYN-ACK数据包的重发次数(默认是5次):
sysctl -w net.ipv4.tcp_synack_retries=3
sysctl -w net.ipv4.tcp_syn_retries=3
方式2:使用SYN Cookie技术:
sysctl -w net.ipv4.tcp_syncookies=1
方式3:增加backlog队列(默认是1024):
sysctl -w net.ipv4.tcp_max_syn_backlog=2048
方式4:限制SYN并发数:
iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT --limit 1/s

Ack攻击

介绍

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不但可以危害路由器等网络设备,而且对服务器上的应用有不小的影响。抓包:

特点

相对来说这种攻击方式对服务器影响较小,因此大部分是夹杂着syn进行的

防护方式

常见防护原理
  1. 利用对称性判断来分析出是否有攻击存在。所谓对称型判断,就是收包异常大于发包,因为攻击者通常会采用大量ACK包,并且为了提高攻击速度,一般采用内容基本一致的小包发送。这可以作为判断是否发生ACK Flood的依据,但是目前已知情况来看,很少有单纯使用ACK Flood攻击,都会和其他攻击方法混合使用,因此,很容易产生误判。
  2. 建立一个hash表,用来存放TCP连接“状态”,相对于主机的TCP stack实现来说,状态检查的过程相对简化。例如,不作sequence number的检查,不作包乱序的处理,只是统计一定时间内是否有ACK包在该“连接”(即四元组)上通过,从而“大致”确定该“连接”是否是“活动的”

这种攻击一般依赖防火墙进行判断,防火墙大部分是使用的上面第二种方法对攻击进行拦截。

ICMP

ICMP之 ICMP泛洪攻击

ICMP泛洪(ICMP flood)是利用ICMP报文 进行攻击的一种方法。如果攻击者向目标主机发 送大量的ICMP ECHO报文,将产生ICMP泛洪, 目标主机会将大量的时间和资源用于处理ICMP ECHO报文,而无法处理正常的请求或响应,从而实现对目标主机的攻击。

ICMP之 Smurf攻击

Smurf IP利用广播地址发送ICMP包,一旦广播出去,就会被广播域内的所有主机回应,当然这些包都回应给了伪装的IP地址(指向被攻击主机),伪装IP地址可以是互联网上的任何地址,不一定在本地;假如骇客不停地发送此种类型的包,就会造成DoS攻击。

ICMP之 死亡Ping(Death of Ping)

在早期的阶段,路由器对包的最大尺寸都有限制,许多操作系统对TCP/IP栈的实现在ICMP包上都是规定64KB,并且在对包的标题头进行读取之后,要根据该标题头里包含的信息来为有效载荷生成缓冲区,当产生畸形的,声称自己的尺寸超过ICMP上限的包也就是加载的尺寸超过64K上限时,就会出现内存分配错误,导致TCP/IP堆栈崩溃,致使目标机器宕机

防护方式

直接丢弃所有icmp包即可
firewalld实现方式:

firewall-cmd --permanent --add-rich-rule='rule protocol value=icmp drop'

iptables实现方式:

iptables -A INPUT -p icmp --icmp-type 8 -s 0/0 -j DROP

内核实现方式:

net.ipv4.icmp_echo_ignore_all=0

当然除了死亡Ping之外,对ICMP限速也是可以的,不过没啥意义
实际如果你的网口被占满的话,还是借助硬件墙比较好

缺陷

对所有ICMP不回应,基于ICMP的ping全部为超时

TCP LAND攻击

介绍

Land 攻击是一种使用相同的源和目的主机和端口发送数据包到某台机器的攻击。当操作系统接收到这类数据包时,不知道该如何处理,或者循环发送和接收该数据包,这样会消耗大量的系统资源,从而有可能造成系统崩溃或死机。
在Land攻击中,一个特别打造的SYN包中的原地址和目标地址都被设置成某一个服务器地址,这时将导致接受服务器向它自己的地址发送SYN一ACK消息,结果这个地址又发回ACK消息并创建一个空连接,每一个这样的连接都将保留直到超时掉。对Land攻击反应不同,许多UNIX实现将崩溃,而 Windows NT 会变的极其缓慢(大约持续五分钟)。
换句话说: 我连我自己,但是就是连不上,不断死循环

特征

如简介所说,抓包很容易发现

防护方法

借助防火墙设置特定策略,丢弃该类数据包

Fraggle攻击

简介&实现原理

Fraggle类似于Smurf攻击,只是使用UDP应答消息而非ICMP。UDP端口7(ECHO)和端口19(Chargen字符生成服务)在收到UDP报文后,都会产生回应。在UDP的7号端口收到报文后,会回应收到的内容,而UDP的19号端口在收到报文后,会产生一串字符流,会产生大量无用的应答报文,占满网络带宽。攻击者可以向子网广播地址发送源地址为受害网络或受害主机的UDP包,端口号用7或19。
子网络启用了此功能的每个系统都会向受害者的主机作出响应,从而引发大量的应答包,导致受害网络的阻塞或受害主机的崩溃;子网上没有启动这些功能的系统将产生一个ICMP不可达消息,因而仍然消耗带宽。也可将源端口改为Chargen,目的端口为ECHO,这样会自动不停地产生回应报文,其危害性更大。

特征

抓包发现在UDP7或者19端口有非常多报文

防护方式

防火墙屏蔽UDP端口号为7或19的报文

iptables -A INPUT -p UDP --sport=7 -j DROP
iptables -A INPUT -p UDP --sport=19 -j DROP

teardown攻击

原理

对于一些大的IP数据包,往往需要对其进行拆分传送,这是为了迎合链路层的MTU(最大传输单元)的要求。比如,一个6 000字节的IP包,在MTU为2 000的链路上传输的时候,就需要分成3个IP 包。在IP报头中有一个偏移字段和一个拆分标志(MF)。如果MF标志设置为1,则表示这个IP包是一个大IP包的片段,其中偏移字段指出了这个片段在整个IP包中的位置。例如,对一个6 000字 节的IP包进行拆分(MTU为2 000),则3个片段中偏移字段的值依次为0,2000,4 000。这样接收端在全部接收完IP数据包后,就可以根据这些信息重新组装这几个分次接收的拆分IP包。在这 里就有一个安全漏洞可以利用了,就是如果黑客们在截取IP数据包后,把偏移字段设置成不正确的值,这样接收端在收到这些分拆的数据包后,就不能按数据包中的偏移字段值正确组合这些拆分的数据包,但接收端会不断尝试,这样就可能致使目标计算机操作系统因资源耗尽而崩溃。

防护方式

一般没人打这种包,有的话直接硬件墙走起

IP欺骗

原理

这种攻击利用TCP协议栈的RST位来实现,使用IP欺骗,迫使服务器把合法用户的连接复位,影响合法用户的连接。假设有一个合法用户(100.100.100.100)已经同服务器建了正常的连接,攻击者构造攻击的TCP数据,伪装自己的IP为100.100.100.100,并向服务器发送一个带有RST位的TCP数据段。服务器接收到这样的数据后,认为从100.100.100.100发送的连接有错误,就会清空缓冲区中已建立好的连接。这时,合法用户100.100.100.100再发送合法数据,服务器就已经没有这样的连接了,该用户就被拒绝服务而只能重新开始建立新的连接。

防护原理

基本没人打的,不用看了

UDP Flood

实现原理

UDP Flood是日渐猖厥的流量型DoS攻击,原理也很简单。常见的情况是利用大量UDP小包冲击DNS服务器或Radius认证服务器、流媒体视频服务器。

100k pps的UDP Flood经常将线路上的骨干设备例如防火墙打瘫,造成整个网段的瘫痪。由于UDP协议是一种无连接的服务,在UDP FLOOD攻击中,攻击者可发送大量伪造源IP地址的小UDP包。但是,由于UDP协议是无连接性的,所以只要开了一个UDP的端口提供相关服务的话,那么就可针对相关的服务进行攻击。

正常应用情况下,UDP包双向流量会基本相等,而且大小和内容都是随机的,变化很大。出现UDP Flood的情况下,针对同一目标IP的UDP包在一侧大量出现,并且内容和大小都比较固定。

防护方式

直接丢弃UDP即可,或者对UDP速率做限制
iptables -A INPUT -p udp -m limit --limit 1000/min -j ACCEPT
iptables -A INPUT -p udp -j DROP

当然更多情况还是用防火墙吧,毕竟服务器那小口子,一会就满了

DNS Query Flood

实现原理

UDP DNS Query Flood攻击实质上是UDP Flood的一种,但是由于DNS服务器的不可替代的关键作用,一旦服务器瘫痪,影响一般都很大。

UDP DNS Query Flood攻击采用的方法是向被攻击的服务器发送大量的域名解析请求,通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名,被攻击的DNS 服务器在接收到域名解析请求的时候首先会在服务器上查找是否有对应的缓存,如果查找不到并且该域名无法直接由服务器解析的时候,DNS 服务器会向其上层DNS服务器递归查询域名信息。域名解析的过程给服务器带来了很大的负载,每秒钟域名解析请求超过一定的数量就会造成DNS服务器解析域名超时。

DNS Query Flood就是攻击者操纵大量傀儡机器,对目标发起海量的域名查询请求。为了防止基于ACL的过滤,必须提高数据包的随机性。常用的做法是UDP层随机伪造源IP地址、随机伪造源端口等参数。在DNS协议层,随机伪造查询ID以及待解析域名。随机伪造待解析域名除了防止过滤外,还可以降低命中DNS缓存的可能性,尽可能多地消耗DNS服务器的CPU资源。

根据微软的统计数据,一台DNS服务器所能承受的动态域名查询的上限是每秒钟9000个请求。而我们知道,在一台P3的PC机上可以轻易地构造出每秒钟几万个域名解析请求,足以使一台硬件配置极高的DNS服务器瘫痪,由此可见DNS 服务器的脆弱性。同时需要注意的是,蠕虫扩散也会带来大量的域名解析请求。

防护原理

  1. 在UDP Flood的基础上对 UDP DNS Query Flood 攻击进行防护
  2. 根据域名 IP 自学习结果主动回应,减轻服务器负载(使用 DNS Cache)
  3. 对突然发起大量频度较低的域名解析请求的源 IP 地址进行带宽限制
  4. 在攻击发生时降低很少发起域名解析请求的源 IP 地址的优先级
  5. 限制每个源 IP 地址每秒的域名解析请求次数

winnuke攻击

攻击原理

winnuke是利用NetBIOS协议中一个OOB(OutofBand)的漏洞,也就是所谓的带外数据漏洞而进行的,它的原理是通过TCP/IP协议传递一个Urgent紧急数据包到计算机的137、138或139端口,当win95/NT收到这个数据包之后就会瞬间死机或蓝屏,不重新启动计算机就无法继续使用TCP/IP协议来访问网络。

带外数据OOB是指TCP连接中发送的一种特殊数据,它的优先级高于一般的数据,带外数据在报头中设置了URG标志,可以不按照通常的次序进入TCP缓冲区,而是进入另外一个缓冲区,立即可以被进程读取或根据进程设置使用SIGURG信号通知进程有带外数据到来。

后来的Winnuke系列工具已经从最初对单个IP的攻击发展到可以攻击一个IP区间范围的计算机,可以检测和选择端口,并且可以进行连续攻击,还能验证攻击的效果,所以使用它可以造成某个IP地址区间的计算机全部蓝屏死机。

解决方案

此类攻击是由于利用软件开发过程中对某种特定类型的报文或请求没有处理,导致软件遇到这类型报文时运行出现异常,软件崩溃甚至系统崩溃。防范此类攻击的方法就是升级系统或给系统打补丁,也可以删除NetBIOS协议或关闭137、138、139端口。

碎片攻击

简介

链路层具有最大传输单元MTU这个特性,它限制了数据帧的最大长度,不同的网络类型都有一个上限值。以太网的MTU是1500,你可以用 netstat -i 命令查看这个值。如果IP层有数据包要传,而且数据包的长度超过了MTU,那么IP层就要对数据包进行分片(fragmentation)操作,使每一片的长度都小于或等于MTU。我们假设要传输一个UDP数据包,以太网的MTU为1500字节,一般IP首部为20字节,UDP首部为8字节,数据的净荷(payload)部分预留是1500-20-8=1472字节。如果数据部分大于1472字节,就会出现分片现象。
IP首部有两个字节表示整个IP数据包的长度,所以IP数据包最长只能为0xFFFF,就是65535字节。如果有意发送总长度超过65535的IP碎片,一些老的系统内核在处理的时候就会出现问题,导致崩溃或者拒绝服务。另外,如果分片之间偏移量经过精心构造,一些系统就无法处理,导致死机。所以说,漏洞的起因是出在重组算法上。

防护

打补丁吧,一些硬件墙也有防护这种攻击的能力,具体原理不详

常见CC攻击方式

  1. 直接攻击:主要针对有重要缺陷的 WEB 应用程序,一般说来是程序写的有问题的时候才会出现这种情况,比较少见。
  2. 僵尸网络攻击:有点类似于 DDOS 攻击了,从 WEB 应用程序层面上已经无法防御。
  3. 代理攻击:黑客借助代理服务器生成指向受害主机的合法网页请求,实现DOS和伪装。
  4. 肉鸡攻击:一般指黑客使用CC攻击软件,控制大量肉鸡发动攻击,相比代理攻击更难防御,因为肉鸡可以模拟正常用户访问网站的请求,伪造成合法数据包。

防护方式

  1. 如果服务端用的是nginx这种具有限速模块的http服务器,可以对每个链接请求频率进行限制(针对比较小的cc),参考链接: https://zhuanlan.zhihu.com/p/50355478
  2. 优化代码,尽可能减少服务器资源消耗
  3. 启用缓存机制,尽可能提高性能
  4. 使用防火墙的web防护模块,比如5秒盾,或验证码等
  5. 借助WAF模块对攻击IP进行封禁
  6. 借助iptables等对端口的请求限速
iptables -A INPUT -p tcp --sport 80 -m limit --limit 60/s -j ACCEPT
iptables -A INPUT -p tcp --sport 80 -j DROP

CC的一个变种 慢速攻击

简介

http慢速攻击是利用http合法机制,在建立连接后,尽量长时间保持连接,不释放,达到对HTTP服务攻击,攻击者发送POST请求,自行构造报文向服务器提交数据,将报文长度设置一个很大的值,且在随后每次发送中,每次只发送一个很小的报文,这样导致服务器一直等待数据,连接始终一直被占用。
如果攻击者使用多线程或傀儡机子去做同样操作,服务器WEB容器很快就被占满TCP连接而不再接受新请求

慢速攻击之Slowloris(slow headers)

攻击原理

HTTP协议规定,HTTP Request以\r\n\r\n(0d0a0d0a)结尾表示客户端发送结束,服务端开始处理。那么,如果永远不发送\r\n\r\n会如何?Slowloris就是利用这一点来做DDoS攻击的。攻击者在HTTP请求头中将Connection设置为Keep-Alive,要求Web Server保持TCP连接不要断开,随后缓慢地每隔几分钟发送一个key-value格式的数据到服务端,如a:b\r\n,导致服务端认为HTTP头部没有接收完成而一直等待。如果攻击者使用多线程或者傀儡机来做同样的操作,服务器的Web容器很快就被攻击者占满了TCP连接而不再接受新的请求。

慢速攻击之Slow HTTP POST(Slow body)

攻击原理

在POST提交方式中,允许在HTTP的头中声明content-length,也就是POST内容的长度。

在提交了头以后,将后面的body部分卡住不发送,这时服务器在接受了POST长度以后,就会等待客户端发送POST的内容,攻击者保持连接并且以10S-100S一个字节的速度去发送,就达到了消耗资源的效果,因此不断地增加这样的链接,就会使得服务器的资源被消耗,最后可能宕机。

慢速攻击之 Slow Read attack

攻击原理

采用调整TCP协议中的滑动窗口大小,来对服务器单次发送的数据大小进行控制,使得服务器需要对一个回应分成很多个包来发送。要使这种攻击效果更加明显,请求的资源要尽量大。

防护方式

  1. 使用nginx,nginx本身就对慢攻击有很好的防护作用
  2. tomcat可通过运行模式NIO和connectionTimeout值进行缓解
  3. 使用验证码,js跳转等对攻击进行防护

华风夏韵,洛水天依。