当前位置:  技术问答>linux和unix

受syn,close_wait的折磨已经有二个多月了，还在继续．．．．

    来源: 互联网  发布时间：2016-06-21

    本文导语:  由于受到syn,close_wait 的功能,我做了以下配置. sysctl -w net.ipv4.tcp_syncookies=1 sysctl -w net.ipv4.tcp_max_syn_backlog=3072 sysctl -w net.ipv4.tcp_synack_retries=1 sysctl -w net.ipv4.tcp_syn_retries=1 sysctl -w net.ipv4.conf.all.send_redirects=0  sysctl -w...

由于受到syn,close_wait 的功能,我做了以下配置.
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=3072
sysctl -w net.ipv4.tcp_synack_retries=1
sysctl -w net.ipv4.tcp_syn_retries=1
sysctl -w net.ipv4.conf.all.send_redirects=0 
sysctl -w net.ipv4.conf.all.accept_redirects=0 
sysctl -w net.ipv4.conf.all.forwarding=0 
sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1


sysctl -w net.ipv4.tcp_fin_timeout=30
sysctl -w net.ipv4.tcp_keepalive_time=30

sysctl -w net.ipv4.tcp_window_scaling=0
sysctl -w net.ipv4.tcp_sack=0
sysctl -w net.ipv4.tcp_timestamps=0
sysctl -w net.ipv4.tcp_keepalive_probes=2
sysctl -w net.ipv4.tcp_keepalive_intvl=2


iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
iptables -A INPUT -i eth0 -m limit --limit 1/sec --limit-burst 5 -j ACCEPT

iptables -N syn-flood
iptables -A INPUT -p tcp --syn -j syn-flood
iptables -A syn-flood -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A syn-flood -j REJECT

iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

==================
配置后,syn没有出现了,close_wait 还是会出现,netstat -nat 后如下

tcp      230      0 ::ffff:172.16.4.2:80        ::ffff:123.125.66.53:60692  CLOSE_WAIT  
tcp      296      0 ::ffff:172.16.4.2:80        ::ffff:124.115.1.66:53552   CLOSE_WAIT  
tcp      230      0 ::ffff:172.16.4.2:80        ::ffff:123.125.66.54:46341  CLOSE_WAIT  
tcp      308      0 ::ffff:172.16.4.2:80        ::ffff:203.208.60.130:39266 CLOSE_WAIT  
tcp      282      0 ::ffff:172.16.4.2:80        ::ffff:61.135.249.72:3131   CLOSE_WAIT  
tcp      397      0 ::ffff:172.16.4.2:80        ::ffff:72.30.65.40:40316    CLOSE_WAIT  
tcp      217      0 ::ffff:172.16.4.2:80        ::ffff:203.208.60.130:36967 ESTABLISHED 
tcp      248      0 ::ffff:172.16.4.2:80        ::ffff:124.115.0.169:60909  CLOSE_WAIT  
tcp        0      0 ::ffff:127.0.0.1:51571      ::ffff:127.0.0.1:3306       ESTABLISHED 
tcp      397      0 ::ffff:172.16.4.2:80        ::ffff:72.30.65.40:58964    CLOSE_WAIT  
tcp      397      0 ::ffff:172.16.4.2:80        ::ffff:72.30.65.40:39003    CLOSE_WAIT  
tcp      308      0 ::ffff:172.16.4.2:80        ::ffff:203.208.60.130:40261 CLOSE_WAIT  
tcp        0      0 ::ffff:127.0.0.1:54782      ::ffff:127.0.0.1:3306       ESTABLISHED 
tcp      538      0 ::ffff:172.16.4.2:80        ::ffff:220.189.33.48:1790   ESTABLISHED 
tcp        1      0 ::ffff:127.0.0.1:41291      ::ffff:127.0.0.1:3306       CLOSE_WAIT  
tcp      161      0 ::ffff:172.16.4.2:80        ::ffff:220.181.7.58:30159   CLOSE_WAIT  
tcp      416      0 ::ffff:172.16.4.2:80        ::ffff:125.115.147.17:25631 ESTABLISHED 
tcp        0      0 ::ffff:127.0.0.1:45221      ::ffff:127.0.0.1:3306       ESTABLISHED 
tcp        0      0 ::ffff:127.0.0.1:35540      ::ffff:127.0.0.1:3306       ESTABLISHED 
tcp      230      0 ::ffff:172.16.4.2:80        ::ffff:123.125.66.43:32872  CLOSE_WAIT  
tcp        0      0 ::ffff:127.0.0.1:34001      ::ffff:127.0.0.1:3306       ESTABLISHED 
tcp        0      0 ::ffff:127.0.0.1:34217      ::ffff:127.0.0.1:3306       ESTABLISHED 
tcp        1      0 ::ffff:127.0.0.1:39694      ::ffff:127.0.0.1:3306       CLOSE_WAIT  
tcp        0      0 ::ffff:127.0.0.1:37725      ::ffff:127.0.0.1:3306       ESTABLISHED 
tcp        0      0 ::ffff:127.0.0.1:37269      ::ffff:127.0.0.1:3306       ESTABLISHED 
tcp        0      0 ::ffff:127.0.0.1:38541      ::ffff:127.0.0.1:3306       ESTABLISHED 
tcp      249      0 ::ffff:172.16.4.2:80        ::ffff:124.115.0.169:58191  CLOSE_WAIT  
tcp      397      0 ::ffff:172.16.4.2:80        ::ffff:72.30.65.40:60389    CLOSE_WAIT  
tcp      163      0 ::ffff:172.16.4.2:80        ::ffff:220.181.7.73:56683   CLOSE_WAIT  
tcp      397      0 ::ffff:172.16.4.2:80        ::ffff:72.30.65.40:37613    CLOSE_WAIT  
tcp      397      0 ::ffff:172.16.4.2:80        ::ffff:72.30.65.40:57325    CLOSE_WAIT  
tcp      230      0 ::ffff:172.16.4.2:80        ::ffff:123.125.66.48:26260  CLOSE_WAIT  
tcp      296      0 ::ffff:172.16.4.2:80        ::ffff:124.115.1.66:50622   CLOSE_WAIT  
tcp      247      0 ::ffff:172.16.4.2:80        ::ffff:118.81.126.78:27859  CLOSE_WAIT  
tcp      151      0 ::ffff:172.16.4.2:80        ::ffff:220.181.7.97:47214   CLOSE_WAIT  
tcp      218      0 ::ffff:172.16.4.2:80        ::ffff:203.208.60.130:48074 CLOSE_WAIT  
tcp      247      0 ::ffff:172.16.4.2:80        ::ffff:118.81.126.78:27855  CLOSE_WAIT  
tcp        0   5232 ::ffff:172.16.4.2:22        ::ffff:220.189.33.48:1794   ESTABLISHED 
tcp      500      0 ::ffff:172.16.4.2:80        ::ffff:220.189.33.48:1793   CLOSE_WAIT  
tcp      328      0 ::ffff:172.16.4.2:80        ::ffff:125.115.147.17:25592 ESTABLISHED 
tcp        0      0 ::ffff:172.16.4.2:80        ::ffff:60.211.145.178:51759 ESTABLISHED 
tcp      397      0 ::ffff:172.16.4.2:80        ::ffff:72.30.65.40:53169    CLOSE_WAIT  
tcp        0      0 ::ffff:172.16.4.2:80        ::ffff:60.211.145.178:51760 ESTABLISHED 
tcp      397      0 ::ffff:172.16.4.2:80        ::ffff:72.30.65.40:41663    CLOSE_WAIT  
tcp      193      0 ::ffff:172.16.4.2:80        ::ffff:65.55.51.114:43455   ESTABLISHED 
tcp      156      0 ::ffff:172.16.4.2:80        ::ffff:123.125.64.38:46317  CLOSE_WAIT  
tcp      397      0 ::ffff:172.16.4.2:80        ::ffff:72.30.65.40:33408    CLOSE_WAIT 


===============
另外说明一个问题,我的内网IP都是以192.168.1.*的,但每次服务器启动后,就会有一个IP存在,
IP是：192.168.122.1：53　　，很奇怪，重启后每次都有．删除了这条，tomcat还是会当掉．
请帮我看看，万分感谢，折磨了２个多月了

|


 帮 你 顶一下  同样 期待 解决

|
1.防火墙暂时停下试试？
2.开机自动绑定一个ip，看看是否dhcp启动，再看看rc*.d里边是否有开机自动绑ip的程序

|
1。每天定时宕机，会不会与业务相关？？是否这时处于业务高峰期，性能到极限了，引发产品缺陷（例如内存泄露之类，当然我只是猜测）？？
   或者与之强相关的服务器每天定时做什么操作了，导致这台机器出问题？？
2。存在一些半开半闭的连接应该还算正常吧，当然如果数量巨大，就不正常了
3。楼主什么系统？？solaris的话可以在/etc/rc3.d和/etc/rc2.d目录下看看，以S打头的文件都是开机要启动的，看看里边有没有什么不应该的项 aix在/etc/rc.d/rc2.d下
4。看看以前防火墙的日志，有没有什么特殊的？
5。用ifconfig -a看看有没有启动dhcp，如果用固定ip，应该不启动的

|
1。每天定时宕机，会不会与业务相关？？是否这时处于业务高峰期，性能到极限了，引发产品缺陷（例如内存泄露之类，当然我只是猜测）？？
   或者与之强相关的服务器每天定时做什么操作了，导致这台机器出问题？？
2。存在一些半开半闭的连接应该还算正常吧，当然如果数量巨大，就不正常了
3。楼主什么系统？？solaris的话可以在/etc/rc3.d和/etc/rc2.d目录下看看，以S打头的文件都是开机要启动的，看看里边有没有什么不应该的项 aix在/etc/rc.d/rc2.d下
4。看看以前防火墙的日志，有没有什么特殊的？
5。用ifconfig -a看看有没有启动dhcp，如果用固定ip，应该不启动的

|
晕，烂网络，让我发两遍

    
 
 

您可能感兴趣的文章:

 
本站(WWW.)旨在分享和传播互联网科技相关的资讯和技术，将尽最大努力为读者提供更好的信息聚合和浏览方式。
本站(WWW.)站内文章除注明原创外，均为转载、整理或搜集自网络。欢迎任何形式的转载，转载请注明出处。












  • 相关文章推荐
  • 一种拒绝服务(Dos)攻击:SYN Flood介绍
  • 端口出现SYN_SEND状态是什么原因？
  • 如何批量关闭 syn_rec 的连接 （被DDos了）？
  • linux 系统受 syn flood 攻击，大家有什么好办法？（急）
  • 服务器上出现1024个 SYN-RECV 连接，请问是怎么回事啊？
  • 我用libnet发tcp syn包给自己, 但没有响应包, why?
  • 紧急求助：遭遇syn攻击
  • echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog 设置后值还是1？
  • SYN-FLOOD攻击！
  • 急求减少linux SYN半连接数以便在一定程度上防止DOS攻击的方法！
  • linux SYN洪水源码问题
  • CSS属性参考手册 iis7站长之家


    • 站内导航:


    特别声明:169IT网站部分信息来自互联网,如果侵犯您的权利,请及时告知,本站将立即删除！

    ©2012-2021,,E-mail:www_#163.com(请将#改为@)

    浙ICP备11055608号-3