主题:【求助】关于网站大量 Error 001 应对 -- 铁手
先祝大家新年快乐,在新的一年,即将到来的龙年龙腾虎跃。
关于网站近期大量出现 Error 001,经过一段时间的分析调查,并做了一些必要的调整,基本恢复稳定。这里做个简单说明,并请熟悉linux服务器管理的河友帮忙参考一下。必要时,请短信给我。
Error 001 是我自己定义的错误代码。和网络链接是否通畅有关。在系统信息提示中有:ip_conntrack: table full, dropping packet.
以下命令给出以下结果:
wc -l /proc/net/ip_conntrack
96187 /proc/net/ip_conntrack
在网站大量出现 Error 001 时,这个值超过了系统预设上限。在系统资源允许的情况下大幅提高上限,基本上缓解了问题之后,这个数值眼下还在不断的上升。
我的基本判断是:
有人有意无意、恶意非恶意的造成对西西河网站的大量链接,导致系统网络相关资源耗尽。我倾向于是一种恶意行为。因为这种行为已经持续了相当一段时间,并有愈演愈烈的趋势,而以前的系统配置在相当长一段时间内一点问题都没有。
为了有效阻止这种行为对网站造成进一步的影响,请熟悉 linux 服务器管理的河友帮忙。虽然我已经尽自己最大能力分析问题所在,并做了必要的系统调整,但还是请各位在给参考意见的时候,尽可能把我当做什么都不懂,这样我们可以从尽可能多角度,尽可能大的覆盖面去分析症结所在,并作出尽可能优化的配置。
比如,
可以帮我想一下查看什么参数,系统统计,怎么分析和判断问题出在哪里,是表面现象还是问题的根子。
也可以帮我想一下,做什么样的系统配置去最大限度的避免问题出现。
总之,思路越宽越好。
多谢各位。
我对Linux 也不熟, 这两天放了下狗,下边的文章有用么?
http://adrianotto.com/2009/07/ip_conntrack-table-full-dropping-packet/
最先ccthere家园博客那一栏消失了,最近cchere家园博客那一栏也消失了,为什么呢?这很不方便,并不仅仅是error001这一个问题。
请考虑是私人为了下载帖子编写的爬虫的情况,这样的话,是否可以通过对请求头部进行分析判断是否是常用浏览器,如ie,ff,opera,safari,chrom等,如不是这几个,可以拒绝链接。这是我之前在编写爬虫的时候所了解到的一些信息。
1.外链出处
要点:
局域网中当有人使用p2p类的软件就很容易使ip_conntrack达到最大值
ip_conntrack: table full, dropping packet. 的错误提示..网关丢弃数据包..网络中断..
具体解决办法如下二种:
1.加大ip_conntrack_max设定值
#modprobe ip_conntrack 需提前加载ip_conntrack模块
#echo "986400" > /proc/sys/net/ipv4/ip_conntrack_max 数值具体多大应计算得出
开机使用新数值..有三种办法:
除vi /etc/rc.local外亦有:
#vi /etc/sysctl.conf 加入: net.ipv4.ip_conntrack_max = 986400
#sysctl -w net.ipv4.ip_conntrack_max=986400
2.减小ip_conntrack timeout 的时限 默认5天即432000s
ip_conntrack_tcp_timeout_established 值默认432000s 即5天
#echo "3600" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
开机使用同于上例
#vi /etc/sysctl.conf 加入: net.ipv4.ip_tcp_timeout_established = 3600
#sysctl -w net.ipv4.ip_tcp_timeout_established=3600
另:通过ip_conntrack buffer 使用状况查出局域网中进行p2p下载的主机
查看目前 ip_conntrack buffer 使用状况
#grep conn /proc/slabinfo
结果实例: ip_conntrack 5918 8140 384 10 1:tunables 54 27 0:slabdata 814 814 0 (各值说明如下)
ip_conntrack the cache name
5918 the number of currently active objects
8140 the total number of available objects
384 the size of each object in bytes
814 the number of pages with at least one active object
814 the total number of allocated pages
1 the number of pages per slab are given
man slabinfo 可查询详细说明.
查出目前 ip_conntrack 记录最多的前五名 IP
#cat /proc/net/ip_conntrack | cut -d ' ' -f 10 | cut -d '=' -f 2 | sort | uniq -c |
sort -nr | head -n 5
结果实例:
2987 192.168.1.30
334 192.168.1.52
166 192.168.1.56
99 192.168.1.43
84 192.168.1.46
由此可知, 192.168.1.30占用了绝大多数的ip_connect buffer,推断这个IP的User可能使用了P2P软件
推荐一个清除某IP链接的方法:通过过滤ip_conntrack表得到ESTABLISHED状态过多的ip,用hping工具将这些ip从表中清理掉...
下载: http://www.hping.org/download.html
安装: ./configure;make;make install
hping清理IP链接脚本:(此脚本修改链接状态为closed)
#!/bin/sh
if [ -z $1 ] ; then
echo "NO INPUT IP"
exit
fi
grep -E "^tcp .{10,25}ESTABLISHED src=$1 " /proc/net/ip_conntrack | while read line; do
S_IP=`echo $line | awk '{print substr($5,5)}'`
S_SOCK=`echo $line | awk '{print substr($7,7)}'`
D_IP=`echo $line | awk '{print substr($6,5)}'`
D_SOCK=`echo $line | awk '{print substr($8,7)}'`
echo "$S_IP:$S_SOCK $D_IP:$D_SOCK"
hping2 $D_IP -R -s $S_SOCK -p $D_SOCK -a $S_IP -k -c 1 > /home/huaying/1.log 2>&1 &
done
对于具体p2p下载产生链接数及ip_connect_max具体设置数值大小推荐以下范文,感兴趣的朋友可以看看...http://www.chinaunix.net/jh/36/596067.html
附:linux NAT 性能优化常用设置...
#echo "1024 65000" > /proc/sys/net/ipv4/ip_local_port_range
#echo "100 1200 128 512 15 5000 500 1884 2">/proc/sys/vm/bdflush
#echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
#echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
#echo "1048576" > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
#echo "1" > /proc/sys/net/ipv4/ip_forward
#echo "268435456" >/proc/sys/kernel/shmall
#echo "536870912" >/proc/sys/kernel/shmmax
#echo "600" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
#echo "1024" > /proc/sys/net/ipv4/neigh/default/gc_thresh1
#echo "2048" > /proc/sys/net/ipv4/neigh/default/gc_thresh2
#echo "4096" > /proc/sys/net/ipv4/neigh/default/gc_thresh3
#echo "52428800" > /proc/sys/net/ipv4/route/max_size
#echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
#echo "1" > /proc/sys/net/ipv4/tcp_window_scaling
2. 外链出处
要点:提供了一个对付DDOS的思路
一个perl脚本来清空ip_conntrack.但是我发觉更简单办法是移除ip_conntrack模块.移除时提示有依赖,还是直接service iptables stop来得快 .但是要记得,ip_forward也被设为0了,所以该设的全重设
http://linux.bdcf.net/index.php?option=content&task=view&id=87&Itemid=2
一个perl脚本来清空ip_conntrack.但是我发觉更简单办法是移除ip_conntrack模块.移除时提示有依赖,还是直接service iptables stop来得快.但是要记得,ip_forward也被设为0了,所以该设的全重设
如何清除/proc/net/ip_conntrack的内容?
作者 woflyin
2004-12-09
对于做处于网关地位的机器,其开启了nat功能,那么/proc/net/ip_conntrack是保存的是内网地址和外部地址连接的情况,记录每个连接的周详情况,其内容一般会保持5天,期间重新启动网络并不会有效减少其内容,唯一的办法就是重新启动和增大内存的数量,给监控带来不便,内容很容易满,核心便会报警:
ip_conntrack: table full, dropping packet
解决办法:
1.增加内存:修改/etc/sysctl.conf的配置容量 net.ipv4.ip_conntrack_max=大的数值!
2.隔一段时间重新启动系统,清空ip_conntrack
3.对ip_conntrack编程,读取其内容,匹配指定的ip地址,然后调用发包程式发送RST报文,人为的完成tcp连接。用perl实现,调用了一个外部程式hping2,能够从其主页找到,这个程式就是个构包器
用法:cl.pl ipaddress
#!/usr/bin/perl
$ip = $ARGV[0];
#print $ARGS,$ip;
exit if(!$ip);
open(FH,"ip_conntrack");
while()
{
if (/^tcp .*ESTABLISHED src=$ip/)
{
#print $_;
@line = split(/=/,$_);
$sip = $line[1];
$sip =~s/ .*//g;
$dip = $line[2];
$dip =~s/ .*//g;
$sport = $line[3];
$sport =~s/ .*//g;
$dport = $line[4];
$dport =~s/ .*//g;
print "$sip:$sport $dip:$dportn";
`/usr/bin/hping2 $dip -R -s $sport -p $dport -a $sip -k -c 1 >/dev/null 2>/dev/null &`;
}
}
4。问题:通过这个思路,是否能够对消除ddos攻击有一定帮助呢?查询ip_conntrack表,判断syn_SENT标志是否过多,过多就能够采取这样的做法消除他们呢?希望大家讨论,一起进步!
3. 这个似乎有用。
要点:用iptables的raw表解决ip_conntrack: table full, dropping packet的问题
内容不引用了,老铁自己看吧。
前一段Error001特别多,这几天不大看到。我对Linux、网站维护和防止恶意攻击一点不懂,相信老铁会找到办法的。祝老铁新年快乐!
老铁有没有统计过每链接pv数,就是pv/链接数,用现在的和以前没出问题时候的值比较一下。如果差别不大,那么恭喜老铁,你该加服务器了,的确流量上去了。
首先请老铁提供一下其他信息,例如是不是真的有长链接的应用例如聊天室出现链接泄露了,这些链接是不是都在80端口。
其次得判断是不是收到ddos攻击了,分ip统计链接数。
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的链接数并排序。
如果发现有的ip和服务器的链接数异常高,这些ip数量不多,但是链接数比平均每个ip的链接数多很多,并且累加起来链接数很高,那最简单,是最简单的攻击手段。攻击方用不多的服务器攻击你,这种情况处理起来最简单。不管的是apache还是nginx,加一个ip过滤模块就行了,限制单个ip的链接数就行了。
如果没出现这种情况,那么需要分析一下apache/nginx的日志,看看是不是有的链接持续时间比较长,但是一直没什么数据。这个分析和日志格式有关,我就没法贴脚本了。
如果出现大量没数据的链接,说明被攻击了,呵呵。另外就算不出现这种情况也有可能是受攻击了,攻击方控制了一大批肉鸡,一起访问西西河。这种访问和正常的访问区别不大,相当于压力测试的压力过大,要解决起来有个绝招,一般人我不告诉他。
先买个关子,如果确认是受到了ddos攻击,我再提供解决方案。
很可能是顶栏太长出现了滚动条,把第二行内容隐藏起来了。解决方法很简单,拖一下滚动条,家园博客什么的就出来了。
罪魁祸首是这几个字:
一般就增加资源。
你这个错误代码实在是太影响用户体验了。
即便是被人滥用,增加资源也能改善的。
,但是ccthere这种情况已经有两三周了吧,cchere是就这几天,可以用这个解释。现在恢复了,就好。呵呵。