由 doooom 在 05-18-2003 15:01 发表:

我也直播点东西，跟上形式----服务器抗并发XXX攻击之研究。

首先说说这个现在的无聊小黑客用的ddos软件。小黑客啥都不懂，不知到啥叫root也可以搞的你服务器瘫痪，就是用这样的xx软件。攻击的方式大概就是给你服务器无数的数据包，直到服务器噎死。但是小黑客们往往没有比服务器还宽的带宽(他们还不能去黑些肉鸡)，没等服务器噎死，自己先噎死了。这样他们就用另外一种方式，他们和服务器通信，然后喊你一声就不理你了，你就不断的试着喊他。这样和服务器建立无数的半链接，拖垮服务器。也就是syn攻击。

(这个是我so far的理解，可能还不对，将在今后的直播里面纠正。)

首先怎么对付这样的攻击，打开内核里面的syncookie就可以了具体方法是

当然你的内核要有这个支持，支持了还不行默认是关闭的。

echo "1" > /proc/sys/net/ipv4/tcp_syncookies

这样就打开了支持了，这个syncookie的主要功能就是对付这样的syn flood。

打开这个链接之后，当然还不止，一般的说服务器都跑apache，还要给它加一个抗ddos的补丁

在这里： http://www.networkdweebs.com/stuff/security.html

PS：刚刚开始琢磨这些东西，说的不对的大家不吝指出。

发行版再好，不如自己做的lfs好。

由 doooom 在 05-18-2003 15:08 发表:

这样设置狠解决问题，有了这个东西之后用攻击软件再攻击，服务器受的影响小很多。

当然还是要加防火墙，具体全部的就不写上了就把input的一部分写上。

#################################################3

echo " Set Policies"

$IPT -P INPUT DROP

$IPT -P OUTPUT DROP

$IPT -P FORWARD DROP

###############################################################

echo " User-Specified Chains"

$IPT -N bad_packets

$IPT -N bad_tcp_packets

$IPT -N tcp_inbound

$IPT -N tcp_outbound

##########################################

echo " bad_packets chain"

$IPT -A bad_packets -p ALL -m state --state INVALID -j LOG \

--log-prefix "Invalid packet:"

$IPT -A bad_packets -p ALL -m state --state INVALID -j DROP

$IPT -A bad_packets -p tcp -j bad_tcp_packets

$IPT -A bad_packets -p ALL -j RETURN

#####################################################

echo " bad tcp package"

$IPT -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \

--log-prefix "New not syn:"

这句很有意思

$IPT -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

$IPT -A bad_tcp_packets -p tcp -j RETURN

#########################################################33

echo " tcp_inbound chain"

HTTP

$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 80 -j ACCEPT

HTTPS (Secure Web Server)

$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 443 -j ACCEPT

Email Server (SMTP)

$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 25 \

-m limit --limit 1/second --limit-burst 2 -j ACCEPT

Email Server (POP3)

$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 110 \

-m limit --limit 1/second --limit-burst 2 -j ACCEPT

Email Server (IMAP4)

#$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 143 \

-m limit --limit 1/second --limit-burst 5 -j ACCEPT

sshd

$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 22 -j ACCEPT

Not matched, so return so it will be logged

$IPT -A tcp_inbound -p TCP -j RETURN

###############################################################################

INPUT Chain

$IPT -A INPUT -p ALL -i $LO_IFACE -j ACCEPT

$IPT -A INPUT -p ALL -i lo -s 127.0.0.1 -j ACCEPT

$IPT -A INPUT -p ALL -s 192.168.0.0/16 -j DROP

$IPT -A INPUT -p ALL -s 10.0.0.0/8 -j DROP

$IPT -A INPUT -p ALL -s 172.16.0.0/12 -j DROP

$IPT -A INPUT -p ALL -s 127.0.0.0/8 -j DROP

$IPT -A INPUT -p ALL -d 224.0.0.1 -j DROP

$IPT -A INPUT -p UDP -i $INET_IFACE -j DROP

$IPT -A INPUT -p ICMP -i $INET_IFACE -m limit --limit 3/minute \

--limit-burst 5 -j ACCEPT

$IPT -A INPUT -p ICMP -i $INET_IFACE -j DROP

$IPT -A INPUT -p ALL -j bad_packets

$IPT -A INPUT -p ALL -i $INET_IFACE -m state --state ESTABLISHED,RELATED \

-j ACCEPT

$IPT -A INPUT -p TCP -i $INET_IFACE -j tcp_inbound

$IPT -A INPUT -p ALL -d 255.255.255.255 -j DROP

$IPT -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \

--log-prefix "INPUT packet died:"

发行版再好，不如自己做的lfs好。

由 doooom 在 05-18-2003 15:18 发表:

但是问题又来了，这个syncookie有一些安全漏洞， 再开启syncookie的机器上面黑客可以猜测cookie并链接到一个开启没有保护的网路界面上面。( Systems that have syncookies enabled are vulnerable to this attack if an attacker guesses the cookie and can connect to an open, unprotected TCP socket. )

所以这个cookie是最好别用了。

防火墙的脚本看起来挺长但是对上面说到的攻击没有保护。如果一个攻击者开启了一个1000个并发的攻击软件，很快就可以建立无数的established和time_wait和syn链接，服务器很快就不响应了。

( 如果观察链接情况可以用 netstat -n， 不要在开了X的时候看，不然。。。。反正服务器是不用X的。)

所以比较彻底的解决办法就是限制每个IP的链接数量。如果我限制在5个链接，在攻击者不改变IP的情况下就可以有一定效果的遏制攻击了。

( 其实如果它改变IP，实在想不出什么好办法对付so far。)

发行版再好，不如自己做的lfs好。

由 doooom 在 05-18-2003 15:33 发表:

如果想要限制每个IP的并发链接数量，呵呵这个iptables居然不支持。。。。ft。

当然要自己打补丁了，也难乖gentoo上面一个说这个补丁的文章提到：THE #￥@！# LINUX KERNEL IS MISSING。

到iptables的老家netfilter去下载一个叫做patch-o-matric的TARBALL，这个是一套针对内核的netfilter补丁( iptables当然要内核的支持了哦)，解开之后执行

XXX# KERNEL_DIR=xxx ./runme pending

这个是增加一套即将增加到内核上面的补丁，可以说是最置顶信赖的。

比如多端口match ( --mport 23：25，54)

然后把 pending 换成 base再打一些补丁，这里的补丁就不都是很知道信赖了。。。。有些还处于开发阶段。但是里面有我们需要的iplimit补丁

其他的都不选就选一个iplimit。这个补丁还是working for the author的呵呵。

暂且相信它了。有了这个补丁之后配和最新的iptables (这个要注意阿，老的不work。)就可以使用 iplimit match了。

比如：

iptables -p tcp --syn --dport 23 -m iplimit --iplimit-above 2 -j DROP

就是限制一个ip只有俩telnet链接。

呵呵有了这个东西之后就好很多了。我给它设置成一个ip连一个，其他都drop。。。

发行版再好，不如自己做的lfs好。

由 doooom 在 05-18-2003 15:45 发表:

但是，我太喜欢但是了，我们的服务器上面很多都是跑http服务阿。

如果我打开了一个网页，再打开一个，两个同时下载，如果我限制一个ip连一个可就。。。。

还有很多人有恶习就是一下子打开无数的文章，然后一个一个看。对这样的人谴责一下。但是即使是在同一个窗口里面浏览也会出现链接两个链接的情况，具体是这样的。

如果我链接一个网页，当然首先是和服务器建立一个链接了然后开始传输，这个时候在服务器上面NETSTAT -N 看到的就是ESTABLISHED的一个链接。

传输完了之后服务器开始断开链接状态变为FIN_WAIT_2，这个时候服务器发给你一个syn包，然后等待回应，如果回应了就断开，但是很多的时候不是这样，而是没有，服务器上面的这个链接变为TIME_WAIT，早期的网路协议里面好象是180秒，那个时候网路比较慢了，多等一回，现在是60秒。

也就是你这个链接在你通信结束之后还要在服务器上面保留60秒至少。这样如果你在这个期间又浏览了网页，服务器上面链接就变成两个了，一个是新的established，一个是老链接的尸体time_wait。

这样限制一个ip链接数量比较小就可能不大方便了，但是如果把链接数开大，又和没有限制一样了。这个时候需要作的就是减小time_wait的时间。

发行版再好，不如自己做的lfs好。

由 doooom 在 05-18-2003 15:58 发表:

要改这个wait的时间可不容易，本来想在/proc目录里面调整一些参数就好了吧，但是没有的调。。。。。看来还要打补丁。

这个时候找到了一个叫ipvs的东西，从gentoo来的，有了这个就可以在/proc/SYS/NET/IPV4/里面多一个VS目录，里面有设置timeout时间的文件。这个东西据说是work，however(我不“但是”了)，我试了一下不行，这个说是virtual server用的，也就是cluster里面的东西。我们运气不好里面的timeout_TIMEWAT不是我们要的timeout设置(可能，并不确定是什么)。

这下没有补丁好下载了，看来只好自己作补丁了。卡卡。

仔细研究一下这个google里面的各种文章，最后找到了在内核的 tcp.h 定义了这个timeout值。

用vi打开 linux-2.4.20/include/net/tcp.h

找到 TCP_TIMEWAIT_LEN 这个值，将里面的60改到你想要的东西就好了，我改成了15.。。。哈哈，恐怕太小了，不复合国际标准了。

这个是我改完的代码，出了那个值还改了几个reties的值，这些也可以减小服务器被攻击时候的负担。

> > 源码: >
> * * * >
>
> > > #define TCP_RETR1 3 /*
> > > * This is how many retries it does before it
> > > * tries to figure out if the gateway is
> > > * down. Minimal RFC value is 3; it corresponds
> > > * to ~3sec-8min depending on RTO.
> > > /
> > >
> > > #define TCP_RETR2 10 /
> > > * This should take at least
> > > * 90 minutes to time out.
> > > * RFC1122 says that the limit is 100 sec.
> > > * 15 is ~13-30min depending on RTO.
> > > /
> > >
> > > #define TCP_SYN_RETRIES 3 / number of times to retry active opening a
> > > * connection: ~180sec is RFC minumum /
> > >
> > > #define TCP_SYNACK_RETRIES 5 / number of times to retry passive opening a
> > > * connection: ~180sec is RF