本文主要介绍了SYNPROXY的相关原理、DDoS简述、LVS相关应用等内容。
上篇文章回顾： 容器进程Core Dump处理
SYNPROXY简述
SYNPROXY是防御DDoS攻击的有力手段。
SYNPROXY是一个TCP握手代理，原生支持是从Linux内核3.13开始的。当一个TCP请求从客户端发出时，首先与该握手代理进行三次握手，其采用SYNCookie技术，只有该请求通过cookie合法性校验，代理服务器才会与服务器进行真正的TCP三次握手，此时客户端和服务端之间的连接才真正建立，进入数据传输阶段。
DDoS简述
DDoS（Distributed Denial of Service，分布式拒绝服务）攻击源于DoS（Denial of Service，拒绝服务）攻击。DoS攻击又称洪水攻击，其攻击目的主要是使计算机的网络或系统资源耗尽，无法为正常请求建立连接，导致客户端无法正常访问。而当攻击者为两个及两个以上的被攻陷的计算机组成的“僵尸团”时，则为DDoS攻击，相比于DoS的“单挑”，显然“群殴”来得杀伤力和破坏力更大。
DDoS的攻击形式多样，按照攻击形式分为带宽消耗型攻击和资源消耗型攻击，按照攻击层级分为网络层DDoS攻击和应用层DDoS攻击。网络层DDoS攻击最为常见和杀伤力较大的攻击为SYNFlood攻击。
SYNFlood攻击利用TCP协议缺陷，发送大量伪造的TCP连接请求（SYN报文），使被攻击方的内存资源不足或者CPU超负载。即，建立TCP连接需要三次握手，被攻击方在收到攻击方SYN报文回复SYN-ACK报文，但是伪造的SYN报文一般源IP地址不存在或不可达，导致被攻击方为维护数以万计的SYN_RCVD状态（半开放状态）连接而消耗巨大的资源，产生频繁的超时重传动作，使得正常的连接请求无法建立，甚至于被攻击方的CPU资源被耗尽，服务器处于瘫痪状态。
DDoS让人头疼的地方在于，它就像普通感冒一样，只能防御，难以根治，并且攻击手段在不断进化。而SYNPROXY作为最为经济实惠的防御手段，成为众多防御手段中较为常用的一种。
SYNPROXY原理
前文说过，SYNPROXY基于SYNCookie技术实现防御DDoS功能，而SYNCookie技术又是基于TCP三次握手做的修改，所以我们需要回顾下TCP三次握手，进而学习SYNCookie技术和SYNPROXY原理。
1、TCP三次握手
我们知道，TCP是一种可靠的、面向连接的、基于字节流的四层传输层协议，连接建立需要TCP三次握手。
第一次握手：客户端say hello，发送SYN报文，进入SYN_SEND状态，服务端收到客户 端的“问候”（SYN报文）后回以SYN-ACK报文表示友好，进入SYN_RCVD状态；
第二次握手：客户端收到服务端的SYN-ACK报文后，发送ACK报文，进入ESTABLISED状态；
第三次握手：服务端在收到客户端的ACK报文后，进入ESTABLISED状态，两方正式“建交”。
SYNCookie技术
SYNCookie由Daniel J. Bernstein发明，主要用于防御SYNFlood攻击。它的原理是，在服务器接收到SYN报文并返回SYN-ACK报文时，不分配一个专门的数据区，而是根据这个SYN报文计算出一个cookie值。这个cookie值作为将要返回的SYN ACK报文的初始序列号。当客户端返回一个ACK报文时，服务器根据报文头信息计算cookie，与客户端返回的确认序列号(初始序列号 + 1)进行对比，如果相同，则是一个正常连接，然后，分配资源，建立连接。实现的关键在于cookie的计算，cookie的计算应该包含本次连接的状态信息，使攻击者不能伪造。关于cookie如何计算和校验参见SYN cookies。
SYNPROXY原理
工作流程（图中红色部分就是由握手代理模拟发出的，对于客户端而言是透明的），简要分为以下三个阶段：
-
第一阶段：客户端与握手代理进行三次握手，第二步握手代理回复客户端的ACK-ACK报文携带的初始序列号（ISN1）由SYNCookie算法生成，与SYNCookie工作流程相似；
-
第二阶段：当cookie验证通过后，握手代理充当客户端和服务端进行三次握手，并负责校正初始序列号（ISN2）和窗口大小；
-
第三阶段：在连接建立之后握手代理负责调整客户端和服务端之间数据传输过程中的序列号和确认号。
那么问题来了，为什么第二步握手代理回复给客户端的SYN-ACK报文的接收窗口大小为0，又何时何法将服务端真正的窗口大小透传给客户端？握手代理又如何协调客户端和服务端之间的初始序列号（ISN）以保证真正的连接建立？
关于窗口的问题
-
为什么第二步握手代理回复的SYN-ACK报文的接收窗口大小为0？在客户端和服务器端真正建立连接前，首先，握手代理和客户端要进行三次握手，其次才是握手代理和服务端的三次握手，若是在此时，客户端发送数据过来，无疑不会被服务端正确接收。为了避免这种情况的发生，握手代理回复给客户端一个大小为0的窗口，告诉客户端“我还没有准备好接收数据”，因为此时仅仅是握手代理和客户端之间的三次握手，真正的连接尚未建立，无法传输数据。
-
那么，何时何法将服务端真正的窗口大小透传给客户端？当握手代理和服务器完成了三次握手，握手代理再将服务端回复的SYN-ACK报文中真正的窗口大小（图中第五步）透传给客户端，告诉客户端“我准备好了，可以开始传输数据了”。
关于序列号的问题
-
第二步握手代理回复的SYN-ACK报文中所携带的初始序列号是如何产生的？这个序列号是握手代理采用SYNCookie技术计算得出的cookie值，这个cookie值根据客户端的SYN报文中的源地址、目的地址、源端口、目的端口等信息计算出来的，准确性很高，使得客户端第三次握手发来的ACK报文几乎无法被伪造。
-
第五步服务端回复的SYN-ACK报文中所携带的初始序列号，握手代理又如何透传给客户端？可以看出，两个ISN（ISN1、ISN2）是独立生成的，由于客户端并不知道握手代理的存在，会将握手代理发送的SYN-ACK记录在TCP连接中，在握手代理透传服务端的ACK-SYN时，携带的是服务端生成的ISN2，与之前的ISN1不一样，因此这个透传的SYN-ACK应当是不会被客户端正确接收的。那么，SYNPROXY是如何解决这个问题呢
1.握手代理将服务端的SYN-ACK报文去掉SYN标记，仅保留ACK标记，作为一个窗口更新动作发送给客户端；
2.对于从服务端收到的任何数据报文，在发往客户端前，调整其序列号使得与客户端握手时的ISN相适应；
3.对于从客户端收到的任何数据报文，在发往服务端前，调整其ACK使得与服务端握手时的ISN相适应。
如此，所有问题都解决了，SYNPQOXY就像一个智能传话筒，全程参与着客户端和服务端的数据传输过程。
结论
需要说明，由于SYNPROXY自身导致的性能缺陷，再加上DDoS攻击的无法完全防御性，依靠SYNPROXY完全抵御DDoS攻击几乎不可能。只要攻击者发起规模足够大的攻击，SYNPROXY便有可能抵挡不住攻势。实践证明，SYNPROXY对SYNFlood攻击具有有效且有限的防御作用。
LVS应用
LVS为什么要使用SYNPROXY
Linux内核原生的ip_vs模块主要实现负载均衡功能，对DDoS攻击几乎没有防护作用，后端真实服务器一般也不具备这种攻击防御，或者防御作用不高，一旦这种攻击包被转发到后端真实服务器上，会造成后端真实服务器崩溃，LVS机器也会因此产生资源消耗，影响LVS转发性能。
LVS支持SYNPROXY
"A distribution of Linux Virtual Server with some advanced features. It introduces a new packet forwarding method - FULLNAT other than NAT/Tunneling/DirectRouting, and defense mechanism against synflooding attack - SYNPROXY."
"This FullNAT and SYNPROXY code for IPVS in Linux kernel 2.6.32 was written by Jiaming Wu,Jiajun Chen,Ziang Chen,Shunmin Zhu at taobao.com, Jian Chen at 360.cn, with some advising from Wensong Zhang at taobao.com. The code was affected by ideas of the source NAT and SYNPROXY version that was hard coded to IPVS in Linux kernel 2.6.9 by Wen Li, Yan Tian, Jian Chen, Yang Yi, Yaoguang Sun, Fang Han, Ying liu and Jiaming Wu at baidu.com in 2009.
The FullNAT and SYNPROXY support were added to keepalived/ipvsadm by Jiajun Chen and Ziang Chen at taobao.com."
淘宝开发的LVS支持SYNPROXY功能，基于TCP的SYNCookie技术，适用于LVS/FULLNAT模式。源码请移步官方地址alibaba-LVS/FULLNAT。
小结
本文浅谈DDoS攻击、SYNCookie技术和SYNPROXY原理，更多关于SYNPROXY和SYNCookie的具体实现以及LVS/FULLNAT模式是如何实现SYNPROXY，需要深入研究源码，希望此文对大家有所帮助。
参考资料
- http://www.doc88.com/p-695303225593.html
- https://blog.csdn.net/dog250/article/details/77920696
- https://zh.wikipedia.org/wiki/%E9%98%BB%E6%96%B7%E6%9C%8D%E5%8B%99%E6%94%BB%E6%93%8A
- https://zh.wikipedia.org/wiki/%E4%BC%A0%E8%BE%93%E6%8E%A7%E5%88%B6%E5%8D%8F%E8%AE%AE
文章首发于公众号“小米运维”，点击查看原文。