主题：【求助】关于网站大量 Error 001 应对 -- 铁手
家园 这招靠谱
家园 可能不是攻击 我观察了一下自己的浏览器，有可能是因为网络传输速度慢导致的问题。在打开网站的时候如果我当时正在下BT，有可能就会有一两个连接始终没完成。浏览器的表现就是基本页面出来了，但是不断转圈。或者内容全部出来了，但是浏览器始终处于下载页面状态。这时我估计你那边就有一个长时间的连接(Established状态）。用户多了这种连接就可以挤爆你的连接数量。
我建议你查看一下这种空连接的数量占的百分比，并看看和PV、在线用户数量等关系，如果是正相关，那可能就是我说的情况。那看看有没有缩短空闲连接的方法（Linux我也不熟悉）
吐嘈一下家用的NAT路由器，由于这些小路由器通常有连接限制。开BT的时候经常就莫名其妙地随机地断开一些TCP连接，粗暴断开，连个RST都不发。我就吃过这些东西的亏。
- 复 可能不是攻击
家园 老哥您就知足吧 NAT那可是大杀器，一般差点的局域网网关服务器都得仔细着点开NAT，工作原理决定了，这东西得解包、构包，同时还得把解包构包的过程记录下来，等返回的时候再反着来一次，绝对是和CPU八字犯冲型的，您看看您开BT的时候有同时发起了多少链接，小破路由器哪能撑得住这样玩儿法，肯定得自我保护DROP了，至于RST，那也得走NAT，一样被DROP了
- 复 可能不是攻击
家园 奇怪的是，netstat里面的 Established状态 的不多。主要是 ip_conntrack 里面的记录数量在不断增加，而且大部分是“Established”，而这些“Established” time out 的时间又是比较长的。
家园 我的猜测 手头没有iptables的详细资料。我的猜测是iptables里的established和Tcp的established概念不同。
iptables作为一个防火墙可能带有一个连接代理的功能。当连接进来时先代理连接（或者建立连接管理数据表项），之后再转发到TCP/IP的协议栈。这样从Iptable的established指的是防火墙处理的连接。而netstate看到的就是已经过滤的本机的TCP连接。具体的要看iptables的详细说明。如果我猜测正确的话，那些timeout值都是为了遵循TCP协议规定的默认值。可以很放心地根据实际情况缩短。
另外，看看规则上能不能过滤掉这些多余的established连接。
我是最近才正式开始在linux上干活，以上都是猜测，仅做参考。
家园 脚本是对的，可能发帖时候多了换行，拷贝后无法执行。 分析ipcontrack的脚本如下：
cat ipcontrack | awk '{print substr($5, index($5,"=")+1) }' | awk '{a[$1]+=1};END {for( i in a){print i,a[ i ] }}' | sort -n -k 2下面是我测试结果。
[root@ud60216 ~]# head ipcontracktcp 6 115 TIME_WAIT src=10.242.230.109 dst=10.242.148.102 sport=59592 dport=10080 packets=17 bytes=1324 src=10.242.148.102 dst=10.242.230.109 sport=10080 dport=59592 packets=11 bytes=18112 [ASSURED] mark=0 secmark=0 use=1
tcp 6 83 TIME_WAIT src=10.242.230.109 dst=10.242.148.102 sport=49749 dport=10080 packets=6 bytes=775 src=10.242.148.102 dst=10.242.230.109 sport=10080 dport=49749 packets=5 bytes=512 [ASSURED] mark=0 secmark=0 use=1
tcp 6 105 TIME_WAIT src=10.242.230.111 dst=10.242.148.102 sport=48174 dport=10080 packets=5 bytes=762 src=10.242.148.102 dst=10.242.230.111 sport=10080 dport=48174 packets=4 bytes=1657 [ASSURED] mark=0 secmark=0 use=1
tcp 6 27 TIME_WAIT src=10.242.148.102 dst=10.242.148.140 sport=42357 dport=64148 packets=7 bytes=1156 src=10.242.148.140 dst=10.242.148.102 sport=64148 dport=42357 packets=7 bytes=5180 [ASSURED] mark=0 secmark=0 use=1
tcp 6 90 TIME_WAIT src=10.242.230.109 dst=10.242.148.102 sport=52014 dport=10080 packets=6 bytes=820 src=10.242.148.102 dst=10.242.230.109 sport=10080 dport=52014 packets=5 bytes=512 [ASSURED] mark=0 secmark=0 use=1
tcp 6 77 TIME_WAIT src=10.242.230.112 dst=10.242.148.102 sport=53700 dport=10080 packets=18 bytes=1407 src=10.242.148.102 dst=10.242.230.112 sport=10080 dport=53700 packets=11 bytes=19839 [ASSURED] mark=0 secmark=0 use=1
tcp 6 25 TIME_WAIT src=10.242.230.107 dst=10.242.148.102 sport=47959 dport=10080 packets=10 bytes=960 src=10.242.148.102 dst=10.242.230.107 sport=10080 dport=47959 packets=7 bytes=8566 [ASSURED] mark=0 secmark=0 use=1
tcp 6 20 TIME_WAIT src=10.242.230.112 dst=10.242.148.102 sport=36645 dport=10080 packets=18 bytes=1311 src=10.242.148.102 dst=10.242.230.112 sport=10080 dport=36645 packets=11 bytes=19508 [ASSURED] mark=0 secmark=0 use=1
tcp 6 113 TIME_WAIT src=10.242.230.108 dst=10.242.148.102 sport=60306 dport=10080 packets=12 bytes=1241 src=10.242.148.102 dst=10.242.230.108 sport=10080 dport=60306 packets=8 bytes=11344 [ASSURED] mark=0 secmark=0 use=1
tcp 6 96 TIME_WAIT src=10.242.148.102 dst=10.242.148.140 sport=42710 dport=64148 packets=7 bytes=1108 src=10.242.148.140 dst=10.242.148.102 sport=64148 dport=42710 packets=7 bytes=4676 [ASSURED] mark=0 secmark=0 use=1
[root@ud60216 ~]# head ipcontrack | awk '{print substr($5, index($5,"=")+1) }' | awk '{a[$1]+=1};END {for( i in a){print i,a[ i ] }}' | sort -n -k 2
10.242.230.107 1
10.242.230.108 1
10.242.230.111 1
10.242.148.102 2
10.242.230.112 2
10.242.230.109 3
另外，目前我们生产环境中net.ipv4.netfilter.ip_conntrack_tcp_timeout_established设置为43200.不过我们前端有防dds攻击的策略。
另外加一个链接状况分类统计的脚本。
netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}'
家园 这个脚本执行了老半天才出结果 cat /proc/net/ip_conntrack | awk '{print substr($5, index($5,"=")+1) }' | awk '{a[$1]+=1};END {for( i in a){print i,a[ i ] }}' | sort -n -k 2
结果里面，在某些 ip 后面，有几千的值。至少有500个IP，后面的数值在几十到几百之间。
家园 这个数据应该算正常的 因为ip_contrack中保存的是一段时间类的链接情况，是累计值。
再执行一下
netstat -an | grep ESTABLISHED | awk '{print substr($5, 1 , index($5,":")-1) }'| awk '{a[$1]+=1};END {for( i in a){print i,a[ i ] }}' | sort -n -k 2
看一下当前链接状态ip统计。
ipconntrack的另外一些参数也看一下，
sysctl -a | grep conntrack
注意ip_conntrack_tcp_timeout_established和ip_conntrack_max。
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter.ip_conntrack_max = 1048576
建议和我设成一样，缩小timeout，增加max。
另外有个大杀器，既然是table full，那么可以在crontab中加一个任务，定时清理ip_conntrack，呵呵。
当然这样做比较暴力，一般合理调整上面两个值就够了。
家园 max值我已经增加过好几次，但是记录数不断增加 我注意了一下，在里面的ip 地址里，有不少是只有最后一个值不同，前三位都一样，这个看起来比较邪门。
.ip_conntrack_tcp_timeout_established = 432000 为什么还保留在5天？按我的理解，如果是 web 服务，5分钟应该到头了吧。保留时间长，是不是为了防火墙能够在一段时间内，比如5天内的链接情况来进行判断？
家园 不好意思，多打个了0 上次就说了是43200.
另外，目前我们生产环境中net.ipv4.netfilter.ip_conntrack_tcp_timeout_established设置为43200.不过我们前端有防dds攻击的策略。
设为5分钟对web服务器来说是可以的，但是不利于保留历史记录进行分析，当然了，如果不需要分析，那就设小一点。
另外netstat分析当前连接数情况如何，如果怀疑那批类似的ip是攻击方，可以在iptable中过滤，但是我觉得可能性不多。真正的ddos攻击不会这么麻烦。
现在看来ddos的攻击可能性不大，因为并发量还真不算大，要真是ddos攻击应该就打死了；而且ddos攻击讲究瞬间上很大的量，一般要打死位置，不会象现在这样还能用，而且一般也就持续几天几周。
06年我有个朋友自己做了婴童产品的网站，做的不错，国内做到前几名，结果被竞争对手请黑客进行ddos攻击。攻击持续一周，流量一直很大，导致这一周网站都打不开。等一周以后，ddos攻击没了，客户也流失的差不多了，就倒闭了。
09年时候他又做了个电子产品的b2c网站，也受到了ddos攻击，这次他就扛住了:-)
家园 这个timeout_established是默认标准 默认TCP空连接是4天到期，这个数值可以缩短。Web服务器的话5分钟是没有问题的。
家园 试试限制单个IP最大并发连接和单位时间内最大允许新连接数 一般用户不应该有几千个连接的。
看看下面的网页，希望有帮助
http://www.heartdemon.com/post/154.html
家园 ip_contrack中是历史记录，所以几天内累计出现 几千个链接是可能的。
所以关键还是要用netstat看看当前ESTABLISHED链接的分ip统计情况。
家园 另外建议分类统计一下ipcontrack中链接状态 稍微改一下脚本就可以了。
家园 5 天太大了。先试试4个小时，然后逐渐调整。 要找一个平衡点。
我的理解，ip_conntrack_tcp_timeout_established 值太大的话，会造成很多的TIME_WAIT而占用资源,即会话已结束但TCP连接还没有释放（因为还没有time out)。
用netstat -an |grep ESTABLISHED |wc -l 和netstat -an |grep WAIT |wc -l 以及其他状态SYN_SENT等比一下结果，看看到底是哪一种状态居多，如果主要是FIN_WAIT1或2和TIME_WAIT，那么看起来像是连接没有及时释放的问题。
另外，你有没有过去的网管数据? 看看是否是连接数突然增大的，如果是突然增大的那就很可能是被攻击了。
抱歉，手头没有机器，不然可以帮你写几个awk来分析netstat和/proc/net/ip_conntrack的内容。