linux出现syn是什么进程

Linux syn攻击是一种黑客攻击，如何处理和减少这种攻击是系统管理员比较重要的工作，怎么才能出色的完成这项工作，希望通过本文能给你一启发，让你在以后工作中能轻松完成抵御Linux syn攻击的任务。

虚拟主机服务商在运营过程中可能会受到黑客攻击，常见的攻击方式有SYN，DDOS等。通过更换IP，查找被攻击的站点可能避开攻击，但是中断服务的时间比较长。比较彻底的解决方法是添置硬件防火墙。不过，硬件防火墙价格比较昂贵。可以考虑利用Linux 系统本身提供的防火墙功能来防御。

抵御SYN SYN攻击是利用TCP/IP协议3次握手的原理，发送大量的建立连接的网络包，但不实际建立连接，最终导致被攻击服务器的网络队列被占满，无法被正常用户访问。

Linux内核提供了若干SYN相关的配置，用命令： sysctl -a | grep syn 看到：

net.ipv4.tcp_max_syn_backlog = 1024 net.ipv4.tcp_syncookies = 0

net.ipv4.tcp_synack_retries = 5 net.ipv4.tcp_syn_retries = 5

tcp_max_syn_backlog是SYN队列的长度，tcp_syncookies是一个开关，是否打开SYN Cookie 功能，该功能可以防止部分SYN攻击。tcp_synack_retries和tcp_syn_retries定义SYN 的重试次数。加大SYN队列长度可以容纳更多等待连接的网络连接数，打开SYN Cookie功能可以阻止部分 SYN攻击，降低重试次数也有一定效果。

调整上述设置的方法是：

增加SYN队列长度到2048：

sysctl -w net.ipv4.tcp_max_syn_backlog=2048

打开SYN COOKIE功能：

sysctl -w net.ipv4.tcp_syncookies=1

降低重试次数：

sysctl -w net.ipv4.tcp_synack_retries=3 sysctl -w net.ipv4.tcp_syn_retries=3

为了系统重启动时保持上述配置，可将上述命令加入到/etc/rc.d/rc.local文件中。

防止同步包洪水（Sync Flood）

# iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT

也有人写作

#iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT

--limit 1/s 限制syn并发数每秒1次，可以根据自己的需要修改

防止各种端口扫描

# iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

Ping洪水攻击（Ping of Death）

# iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

到这里Linux syn攻击问题的处理就可以解决了。

SYN_RECV状态，顾名思义，是收到SYN包后应该置的状态。关于SYN_RECV状态,受某些教科书的误导,我以前一直理解为服务器收到SYN包后应该置此状态。也没细想到底是置那个socket的状态，最近在看三次握手协议在linux内核中的实现时,才仔细思考这个问题应该是置连接套接字的状态而非监听套接字的状态。

通常,SYN包只用于TCP三次握手协议中。常见的tcp三次握手协议过程(当然还有同时连接、

半连接等其它一些情况)如下：

1、client SYN包--->server

2、client <---SYN包/ACK包 server

3、client ACK包--->server

根据tcp状态图,对应下述4个状态的变化

a、client发送完毕，状态变成SYN_SEND

b、server收到SYN报并发送ack确认包和SYN包，状态变为SYN_RECV

c、client发送ack包完毕，状态变成ESTABLISHED

d、server发送ack包完毕，状态变成ESTABLISHED

在linux内核中,上述几个状态对应为TCP_SYN_SEND、TCP_SYN_RECV、TCP_ESTABLISHED.

RFC793中关于SYN_RECV状态的描述如下：

SYN-RECEIVED - represents waiting for a confirming connection

request acknowledgment after having both received and sent a

connection request.

从上面可以看出,这个状态是在本端接收到对端连接请求,并发送连接对端请求后,等待对端应答时所置的状态。所以,本质上连接的过程是双方请求应答的来回,应该称四次握手,只是常见的应用以c/s模式为主,而linux、包括绝大部分 *** 作系统都把服务器端的应答和请求封装在一个包里面。

但在linux内核中,却是在监听套接字收到了客户端的ACK包后,才创建连接套接字并初始化为TCP_SYN_RECV状态,如下函数调用关系：

tcp_v4_rcv-->tcp_v4_do_rcv-->tcp_v4_hnd_req-->tcp_check_req-->

tcp_v4_syn_recv_sock-->tcp_create_openreq_child...

---