DDoS防护之TCP防护

桃扇骨 2022-04-15 01:58 301阅读 0赞

欢迎访问[网易云社区][Link 1]，了解更多网易技术产品运营经验。

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][http_www.163.com]，使用wireshark抓包的结果：

![201811201027122b90ccea-d8ad-4bbe-be6d-c217b5da98bb.jpg][]

![201811201027193d251332-c446-4b4e-8c77-bdc8d9b8bc30.jpg][]

这里我们忽略中间的数据传输过程，重点先关注一下头尾处的连接建立我断开连接的部分。

TCP连接的建立：主要的目的是为了互相通知对方自己的初始化的sequence Number,这个序号用于IP数据包在网络上乱序到达的时，便于TCP对IP数据包的重排序。

客户端的第一个报文如下图：

![201811201027327189470d-0d67-495d-aa9d-eeb5b9e90442.jpg][]

TCP中的syn标志位置为1，序号为 612417286（记为i）。

服务端接收到报文后，对该报文进行确认，并发送自己的sequence number给客户端，故为SYN\_ACK包,如下图：

![20181120102745cb77a998-4ffd-41f3-98c6-955bb384fb71.jpg][]

可以看到tcp中syn,ack标志位同时被置为1，服务端确认客户端的报文,Acknowledgement number（确认号）为612417287（i+1），并带上自己的sequence number 为 522111292（记为j）。

客户端收到后会对发送确认报文，对服务端报文进行确认。如图：

![2018112010275548317cdc-45f9-45bf-a652-a17e895b14f2.jpg][]

TCP的ack标志位被置为1，确认号为522111293（j+1）。

这样经过这3个报文，客户端和服务端都获取到了对方的初始sequence number，连接就建立了。

TCP连接断开: TCP是一个全双工的数量传输协议，所以TCP连接的断开实际上是2个方向上的传输关闭过程。接下来看看报文的交互过程，本例为服务端发起的关闭：

首先服务端发送一个FIN报文。通知客户端，服务端不在有数据发送给客户端。

![20181120102807418b342c-c3b7-46a7-8db7-95cf3414931f.jpg][]

这里我们可以忽略ack和Acknowledgement number，这个为对前一次客户端报文的确认。我们可以看到TCP中的FIN标志位置为1，sequence number 为522230043（记为k）。

客户端收到fin报文后，回复一个ack包确认。

![201811201028173c109628-bf9b-4ad4-9586-cec4937d40b3.jpg][]

这样从服务端到客户端这个方向上的数据传输通道就被关闭，即服务端应用不可以在通过这条连接发送数据给客户端。

接下来就是关闭客户端到服务端的传输通道，客户端首先发送fin包

![20181120102907c94548d2-b791-495b-905a-cf1ecd84d820.jpg][]

服务端收到后发送确认报文给客户端。

![201811201029243a595015-2f53-4b36-a051-8f905689f701.jpg][]

这样一来从客户端到服务端的传输通道也关闭了，那么此时两个方向上的传输通道都关闭了，TCP的通信双方就都断开了连接。

简略的交互示意图如下：

![20181120102935d756dd4c-24c4-4dd6-b9fc-2f80aa0ebba2.jpg][]

从上述的连接建立和断开方式我们会发现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报文就被拦截。下面为防护示意图：

![20181120103022d56cd919-eea2-4721-b699-c88d3ff3cfe5.jpg][]

2.reset认证：

Reset认证利用的是TCP协议的可靠性，也是首先由DDOS防护系统来响应syn。防护设备收到syn后响应syn\_ack,将Acknowledgement number (确认号)设为特定值（记为cookie）。当真实客户端收到这个报文时，发现确认号不正确，将发送reset报文，并且sequence number 为cookie + 1。

而伪造的源，将不会有任何回应。这样我们就可以将真实的客户端IP加入白名单。

![20181120103035d1cc35a1-db8e-4df8-bdac-9b36c9cc3f5e.jpg][]

通常在实际应用中还会结合首包丢弃的方式结合源认证一起使用，首包丢弃原理为：在DDOS防护设备收到syn报文后，记录5元组，然后丢弃。正常用户将重传syn报文，防护设备在收到报文命中5元组，并且在规定时间内，则转发。当重传syn报文到达一定阀值时，在启用上述的源认证。这样就能减少反射syn\_ack报文的数量，缓解网络拥堵，同时对防护不产生影响。

以上是TCP的syn\_flood的攻击和防御原理，后续将分析TCP其他类型的攻击和防护，敬请期待。

**延伸阅读：**

[理解DDoS防护本质：基于资源较量和规则过滤的智能化系统][DDoS]

[DDoS高防服务-DDOS攻击防御-DDos压力测试\_网易云][DDoS_-DDOS_-DDos]

[DDoS高防\_DDoS攻击防御\_DDoS压力测试\_网易云][DDoS_-DDOS_-DDos]

相关文章：  
【推荐】 [流式断言器AssertJ介绍][AssertJ]  
【推荐】 [Flask写web时cookie的处理][Flask_web_cookie]  
【推荐】 [浅谈容器监控和网易云计算基础服务实践][Link 2]

[Link 1]: https://sq.163yun.com/blog?tag=M_tg_767_72
[http_www.163.com]: http://link.zhihu.com/?target=http%3A//www.163.com
[201811201027122b90ccea-d8ad-4bbe-be6d-c217b5da98bb.jpg]: /images/20220415/aaaaac84334248828a4c667534976d81.png
[201811201027193d251332-c446-4b4e-8c77-bdc8d9b8bc30.jpg]: /images/20220415/154b93f395e84793b829e1180678f2b1.png
[201811201027327189470d-0d67-495d-aa9d-eeb5b9e90442.jpg]: /images/20220415/9d01ab075f224e7995c2568f7f599782.png
[20181120102745cb77a998-4ffd-41f3-98c6-955bb384fb71.jpg]: /images/20220415/adf5a4418ed14de8a9727d701f6fbf78.png
[2018112010275548317cdc-45f9-45bf-a652-a17e895b14f2.jpg]: /images/20220415/da1e0ab929a640c48abe50fb2e302b4b.png
[20181120102807418b342c-c3b7-46a7-8db7-95cf3414931f.jpg]: /images/20220415/07f2c97875494f648c2420ff7e4b9936.png
[201811201028173c109628-bf9b-4ad4-9586-cec4937d40b3.jpg]: /images/20220415/bfe8923876174e39a3f300e336b49d64.png
[20181120102907c94548d2-b791-495b-905a-cf1ecd84d820.jpg]: /images/20220415/5d68c7d67cf24259b123ca25a90013aa.png
[201811201029243a595015-2f53-4b36-a051-8f905689f701.jpg]: /images/20220415/7721d539a88f467c9ee72e91e11c3d9e.png
[20181120102935d756dd4c-24c4-4dd6-b9fc-2f80aa0ebba2.jpg]: /images/20220415/ba6ccabe81d34bf393591678edf91946.png
[20181120103022d56cd919-eea2-4721-b699-c88d3ff3cfe5.jpg]: /images/20220415/5a98791b54cc44958aaefa4cb8652c51.png
[20181120103035d1cc35a1-db8e-4df8-bdac-9b36c9cc3f5e.jpg]: /images/20220415/e444095fb53b430ca64cc4a8985381de.png
[DDoS]: https://zhuanlan.zhihu.com/p/31255061
[DDoS_-DDOS_-DDos]: http://link.zhihu.com/?tag=M_tg_767_72
[AssertJ]: https://www.cnblogs.com/163yun/p/9567379.html
[Flask_web_cookie]: https://www.jianshu.com/p/3167b7aa7983
[Link 2]: https://www.jianshu.com/p/06318dc8b8a9