常规洪水攻击的原理
- 在TCP第二次握手建立半连接时,此时就可以发动洪水攻击
- 就是大量的请求发起TCP连接,当第二次握手时,服务器会把这些请求放到半连接队列中,由于这些恶意攻击的客户端不会再确认第三次握手,就导致这些半连接无法被释放,服务器会一直等直到超时,此时半连接队列会被塞满,正常请求连接就无法被应答,这就是洪水攻击的方式
常规如何解决洪水攻击
- 开启syncookies方式,第一次握手时,服务器会根据(源地址,源端口,目的地址,目的端口等) 和一个随机数,计算出来一个哈希值(SHA1), 然后第二次握手会把这个生成的syncookies一并返回给客户端,客户端确认第三次握手时,会把这个syncookies再发送给服务端,服务端会校验该syncookie是否和之前的匹配, 如果匹配则建立TCP连接。
- 这种做法好处:当服务端没有收到 或 收到的syncookies不匹配时是不会建立TCP连接的。并且使用syncookies时,服务端不会去维护半连接队列,也就是不存在半连接状态,因为使用syncookies对比就无需半连接了,所以就避免了半连接队列被打满导致无法接收新的连接。
syncookies无法解决的场景
- 当发动大量DDOS攻击时,syncookies这种方式也会瘫痪,瘫痪原因是因为CPU要计算大量的syncookies,导致CPU被打死了。因为在计算syncookies时也是消耗CPU性能的,面临巨量的DDOS,CPU是扛不住的,此时只能增大带宽,用配置硬顶。
其他解决方案
- 增大半连接队列和全连接队列(海量攻击该方法基本无效)
- 减少SYN+ACK的重传次数(TCP是靠重传维持稳定连接的),即收到大量syn请求的洪水攻击时,服务端接收不到回应会不断重试,直到最大次数,降低这个最大次数就能缓解一下
如何查询判断是否被洪水攻击了
1. 先进行流量查看:
sar -n DEV 1 -h
然后只看eth0即可-->用rxkb/s 和 rxpck/s 这两列相除-->如果得出的包就50-60几字节,
那就说明是小包搞鬼,有可能遭受洪水攻击了,一般来说最大MTU = 1460
2. 如果发现是小包搞鬼,那就再进行网络抓包, 输入如下命令
tcpdump -i eth0 -n tcp port 80
3. 看有多少个[S], 这个表示发起TCP请求阶段,如果[S]过多,那就说明是洪水攻击,这是洪水攻击的特征
4. 进一步确认是洪水攻击,查询半连接的池子大小,以及当前半连接数量
半连接总大小: cat /proc/sys/net/ipv4/tcp_max_syn_backlog
当前半连接数: ss -s 或 netstat -n -p | grep SYN_RECV | wc -1
[S]: SYN,开始连接
[P]: PSH, 推送数据
[F]: FIN, 结束连接
[R]: RST, 重置连接
[.]: 没有Flag,可能是ACK 也可能是URG