近期遇到几例服务器被SYN***的问题，今天详细近期遇到几例服务器被SYN***的问题，今天详细分析一下SYN flood***的原理

简单回顾一下TCP/IP三次握手的过程

wKioL1NLbFXBgERzAAA61bupt_A780.jpg

1. Host A 发送一个TCP SYNchronize 包到 Host B
2. Host B 收到 Host A的SYN
3. Host B 发送一个 SYNchronize-ACKnowledgement
4. Host A 接收到Host B的 SYN-ACK
5. Host A 发送ACKnowledge
6. Host B 接收到ACK
7.TCP socket 连接建立ESTABLISHED.

SYN flood（SYN洪水***）
在三次握手过程中，Host B发送SYN-ACK之后，收到Host A的ACK之前的TCP连接称为半连接(half-open connect).此时Host B处于SYN_RECV状态.当收到ACK后，Host B转入ESTABLISHED状态.
SYN***就是***端Host A在短时间内伪造大量不存在的伪IP地址，向Host B不断地发送SYN包，Host B回复确认包，并等待Host A的确认，由于源地址是不存在的，Host B需要不断的重发包直 至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
SYN flood***是一种典型的DDos***。检测SYN***非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN***.
我们模拟一次***：

在Host A上执行***程序，伪装源IP成8.8.8.8（google DNS），目标地址192.168.39.131的80端口

wKiom1NLbYXBs-6yAACgibMotu0565.jpg

在Host B上netstat -an | grep  SYN_RECV可以看到产生大量SYN_RECV状态的连接

wKioL1NLbXfANlCVAAUqnUpuTQw450.jpg


此时Host B收到包后连接为SYN_RECV状态，根据TCP/IP协议应该发送SYN_ACK回复给Host A，在Host B上使用tcpdump -i eth0 'tcp [13] & 2 =2'抓取，发现存在大量SYN_ACK状态的连接，
可惜源ip为伪装的地址，所以会超时重传。此时如有正常请求Host B的80端口，它的SYN包就会被Host B丢弃，因为半连接队列已经满了（耗尽内存以及CPU资源），从而达到***目的。

wKiom1NLbcLhtS4PAAjHMd8Tnc0800.jpg

Linux kernel也提供了Syncookies 等机制来防止syn***，以下是具体修改的内核参数。

# default = 5

net.ipv4.tcp_syn_retries = 3
# default = 5
net.ipv4.tcp_synack_retries = 3
# default = 1024
net.ipv4.tcp_max_syn_backlog = 65536
# default = 124928
net.core.wmem_max = 8388608
# default = 131071
net.core.rmem_max = 8388608
# default = 128
net.core.somaxconn = 512
# default = 20480
net.core.optmem_max = 81920
# default = 1
net.ipv4.tcp_syncookies = 0

其中net.ipv4.tcp_synack_retries, net.ipv4.tcp_syncookies,