DDoS防护之TCP防护
欢迎访问网易云社区，了解更多网易技术产品运营经验。
TCP协议，相信对于每一个开发工程师都不陌生。由于该协议是一个面向连接，可靠的特性，广泛应用于现在互联网的应用中。如常见的Web、SSH、FTP等都是基于TCP协议。目前TCP协议占全网的流量达到80%，因此这也成为黑客主要攻击的类别。
例如在2016年，造成美国大半个互联网下线的Dyn事件，10月21日，提供动态DNS服务的Dyn DNS遭到了大规模DDoS攻击，攻击主要影响其位于美国东区的服务。此次攻击导致许多使用DynDNS服务的网站遭遇访问问题，其中包括 GitHub、Twitter、Airbnb、Reddit、Freshbooks、Heroku、SoundCloud,、Spotify 和 Shopify。攻击导致这些网站一度瘫痪，Twitter甚至出现了近24小时0访问的局面。事后据Dyn产品部门执行副总裁的深入剖析本轮攻击就是利用TCP协议的数据包进行攻击。一开始就成功打破了Dyn的防护，并对其内部系统造成了严重破坏。该公司并未披露本次攻击的确切规模，外界估计它可能大大超过了针对OVH的那次DDoS攻击。（峰值达到了1.1Tbps，这也是迄今所知最大的一次DDoS攻击。）
那么这些针对TCP的攻击都是如何发起的呢？下面首先我们先回顾一下TCP报文的交互过程。
下面是本机浏览器访问http://www.163.com，使用wireshark抓包的结果：
这里我们忽略中间的数据传输过程，重点先关注一下头尾处的连接建立我断开连接的部分。
TCP连接的建立：主要的目的是为了互相通知对方自己的初始化的sequence Number,这个序号用于IP数据包在网络上乱序到达的时，便于TCP对IP数据包的重排序。
客户端的第一个报文如下图：
TCP中的syn标志位置为1，序号为 612417286（记为i）。
服务端接收到报文后，对该报文进行确认，并发送自己的sequence number给客户端，故为SYN_ACK包,如下图：
可以看到tcp中syn,ack标志位同时被置为1，服务端确认客户端的报文,Acknowledgement number（确认号）为612417287（i+1），并带上自己的sequence number 为 522111292（记为j）。
客户端收到后会对发送确认报文，对服务端报文进行确认。如图：
TCP的ack标志位被置为1，确认号为522111293（j+1）。
这样经过这3个报文，客户端和服务端都获取到了对方的初始sequence number，连接就建立了。
TCP连接断开: TCP是一个全双工的数量传输协议，所以TCP连接的断开实际上是2个方向上的传输关闭过程。接下来看看报文的交互过程，本例为服务端发起的关闭：
首先服务端发送一个FIN报文。通知客户端，服务端不在有数据发送给客户端。
这里我们可以忽略ack和Acknowledgement number，这个为对前一次客户端报文的确认。我们可以看到TCP中的FIN标志位置为1，sequence number 为522230043（记为k）。
客户端收到fin报文后，回复一个ack包确认。
这样从服务端到客户端这个方向上的数据传输通道就被关闭，即服务端应用不可以在通过这条连接发送数据给客户端。
接下来就是关闭客户端到服务端的传输通道，客户端首先发送fin包
服务端收到后发送确认报文给客户端。
这样一来从客户端到服务端的传输通道也关闭了，那么此时两个方向上的传输通道都关闭了，TCP的通信双方就都断开了连接。
简略的交互示意图如下：
从上述的连接建立和断开方式我们会发现TCP连接的建立和断开涉及多个报文，多个状态之间的转换。那么从攻击者角度看上述过程，我们该怎么利用交互过程进行DDOS攻击呢？
TCP攻击可以简单的分为以下三类：
1. FLOOD类攻击，例如发送海量的syn,syn_ack,ack,fin等报文，占用服务器资源，使之无法提供服务。
2. 连接耗尽类攻击，如与被攻击方，完成三次握手后不再发送报文一直维持连接，或者立刻发送FIN或RST报文，断开连接后再次快速发起新的连接等，消耗TCP连接资源。
还有一类则比较巧妙，是在我们上述没有做分析的数据传输过程中的利用TCP本身的流控，可靠性保证等机制来达到攻击的目的，即：
3. 利用协议特性攻击：例如攻击这建好连接之后，基于TCP的流控特性，立马就把TCP窗口值设为0，然后断开连接，则服务器就要等待Windows开放，造成资源不可用。或者发送异常报文，可能造成被攻击目标奔溃。
那么上述三种类型的攻击具体的实时和防御原理是怎样的呢？
FLOOD类攻击与防御
Flood类攻击中最常见，危害最大的是syn_flood攻击，也是历史最悠久的攻击之一。因此我们先来看看syn_flood攻击。
syn_flood攻击：SYN-Flood攻击是当前网络上最为常见的DDoS攻击，也是最为经典的拒绝服务攻击，它利用了TCP协议实现上的一个缺陷，通过向网络服务所在端口发送大量的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。这种攻击早在1996年就被发现，但至今仍然显示出强大的生命力。很多操作系统，甚至防火墙、路由器都无法有效地防御这种攻击，而且由于它可以方便地伪造源地址，追查起来非常困难。
从上文我们可以知道客户端发起连接的报文即为syn报文。当攻击者发送大量的伪造IP端口的syn报文时，服务端接收到syn报文后，新建一共表项插入到半连接队列，并发送syn_ack。但由于这些syn报文都是伪造的，发出去的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包，就足够撑爆半连接队列，从而使真正的连接无法建立，无法响应正常请求。
而一台普通的每秒就可以轻松伪造100w个syn包。因此即使把队列大小调大最大也无济于事。那么应该如何区防护呢？
Syn_flood防御：通常针对syn_flood 有2种比较通用的防护机制
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加入白名单。
通常在实际应用中还会结合首包丢弃的方式结合源认证一起使用，首包丢弃原理为：在DDOS防护设备收到syn报文后，记录5元组，然后丢弃。正常用户将重传syn报文，防护设备在收到报文命中5元组，并且在规定时间内，则转发。当重传syn报文到达一定阀值时，在启用上述的源认证。这样就能减少反射syn_ack报文的数量，缓解网络拥堵，同时对防护不产生影响。
以上是TCP的syn_flood的攻击和防御原理，后续将分析TCP其他类型的攻击和防护，敬请期待。
延伸阅读：
DDoS高防服务-DDOS攻击防御-DDos压力测试_网易云
相关文章：
【推荐】 快速登录机器&数据库
【推荐】 测试环境docker化（一）—基于ndp部署模式的docker基础镜像制作
