大家都知道一个TCP连接的启动需要经历三次握手的过程。正常情况下客户端首先向服务端发送SYN报文,随后服务端回以SYN+ACK报文到达客户端,最后客户端向服务端发送ACK报文完成三次握手,后续就是上层业务数据交互,直到某一方断开连接。
那么假如在这“握手”的过程中,客户端程序因为莫名崩溃等原因,收到SYN+ACK报文后不再回以ACK,即丢失第三次握手,这时服务端可能会以为会发送的包丢失了,于是重新发送一遍SYN+ACK,再收不到来自客户端的ACK响应的话,就把这次连接丢弃掉。这个过程大约会持续分钟级,这个持续时间被称作SYN timeout时间。如果只有个别这样的异常情况,目标服务端处理起来自是毫不费力;可如果大量这样的情况出现,对服务端来说就不堪重负了。这是为什么呢?
如果大量的握手请求涌向TCP服务端,而它们只发出SYN报文而不以ACK响应结束握手,服务端就要为这每一个请求都维持约一分多钟的连接去等待ACK,也就形成所谓的“半连接”。维护这些半连接是需要消耗很多服务器的网络连接资源的。如果短时间内这些资源几乎都被半连接占满,那么正常的业务请求在这期间就得不到服务,处于等待状态。
SYN泛洪攻击示意图
更进一步的,如果这些半连接的握手请求是恶意程序发出,并且持续不断,那么就会导致服务端较长时间内丧失服务功能——这就形成了DoS(Denial of Service拒绝服务)攻击。这种攻击方式就称为SYN泛洪(SYN flood)攻击。
由于正常的TCP三次握手中发出去多少SYN报文,就会收到多少SYN+ACK报文。攻击方需要将这些消息丢弃,同时为了隐藏自己,于是需要大量伪造泛洪攻击的源地址,随机改成其它地址。为达到SYN泛洪攻击的效果,这些伪造的源地址最好无法响应SYN+ACK,如这些源地址的主机根本不存在,或者被防火墙等网络设施拦截,等等