eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« "中国软件技术大会"和朋友们在一起 | Blog首页 | 也谈关于 Blog 的版权 »

落后的技术就是灾难

这几天我的网站连续遭遇了几次搜索攻击,导致服务器失去相应,这非常类似以前海量的蜘蛛来爬的情况。

这次的情况是这样的,当我发现服务器的http请求失去响应时登陆服务器,发现大量的Tag搜索请求:

[gqgai@eygle logs]$ top

top - 17:13:49 up 120 days, 1:43, 1 user, load average: 87.96, 175.87, 123.25
Tasks: 229 total, 55 running, 173 sleeping, 0 stopped, 1 zombie
Cpu(s): 84.4% us, 15.6% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 2074980k total, 1837916k used, 237064k free, 840k buffers
Swap: 4192956k total, 154724k used, 4038232k free, 21004k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
46 root 16 0 0 0 0 D 7.9 0.0 42:56.37 kswapd0
20279 nobody 25 0 54536 38m 3552 R 6.6 1.9 0:04.00 mt-search.cgi
20289 nobody 24 0 50976 34m 3508 R 6.6 1.7 0:03.41 mt-search.cgi
20288 nobody 25 0 49768 34m 3620 R 5.9 1.7 0:03.52 mt-search.cgi
20242 nobody 25 0 40148 33m 3544 R 4.9 1.7 0:03.29 mt-search.cgi
20253 nobody 25 0 52776 37m 3520 R 4.9 1.8 0:03.58 mt-search.cgi
20275 nobody 25 0 52552 36m 3540 R 4.6 1.8 0:03.59 mt-search.cgi
20236 nobody 25 0 51804 34m 3540 R 3.6 1.7 0:04.00 mt-search.cgi
20277 nobody 24 0 52960 36m 3620 R 3.6 1.8 0:03.83 mt-search.cgi
20223 nobody 25 0 51800 37m 3644 R 3.3 1.8 0:03.89 mt-search.cgi
20225 nobody 25 0 48364 30m 3532 R 3.3 1.5 0:03.44 mt-search.cgi
20228 nobody 20 0 45948 31m 3528 R 3.3 1.5 0:03.31 mt-search.cgi

CPU load已经达到150左右。

检查日志,发现这些请求都是来自一个ip: 60.28.235.177
经过查询,这个ip地址来自天津一个叫做Tengxun的公司:

inetnum: 60.28.235.0 - 60.28.235.255
netname: TengXun-LTD-TJ
country: CN
descr: TengXun Technology Ltd Company
admin-c: HZ19-AP
tech-c: HZ19-AP
status: ASSIGNED NON-PORTABLE
changed: ipaddr@ywb.online.tj.cn 20051229
mnt-by: MAINT-CNCGROUP-TJ
source: APNIC

route: 60.28.0.0/15
descr: CNC Group CHINA169 Tianjin Province Network
country: CN
origin: AS4837
mnt-by: MAINT-CNCGROUP-RR
changed: abuse@cnc-noc.net 20060118
source: APNIC

开始我一直怀疑TengXun是不是就是QQ的"腾迅",经过继续查询,发现同一网段的另外一个ip地址:60.28.235.173 来自腾迅的Soso,访问该地址的80端口得到如下错误:

Forbidden
You don't have permission to access / on this server.
-------------------------------------------------------
Apache/1.3.33 Server at pic2.soso.com Port 80

看来这个地址和腾迅的SOSO有关,应该就是SoSO放出来的一只蜘蛛。

目前不清楚Soso为什么会以如此高的并发狂拖网页,而其他搜索引擎就不会如此,没有办法,只好暂时封掉SoSo的IP。

由于iptables封锁的规则存在顺序问题,所以使用iptables增加规则应该使用如下命令:
iptables -I INPUT 1 -s 60.28.235.177 -j REJECT

这样封锁的结果是:

[root@eygle ]# iptables --list -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
REJECT all -- 60.28.235.177 0.0.0.0/0 reject-with icmp-port-unreachable
RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0

该网址被成功封锁,感谢网友 huc 的帮忙 :)。

-The End-


历史上的今天...
    >> 2016-12-02文章:
    >> 2011-12-02文章:
    >> 2007-12-02文章:
    >> 2005-12-02文章:
           Today is the Birthday Of AnAn

无觅

By eygle on 2006-12-02 21:05 | Comments (16) | Web | 990 |

16 Comments

没用我的tag cache技术?

有,但是没用的。

越烂的搜索引擎越给人制造麻烦,从没见谁说被google的蜘蛛爬死了。

iptables的封锁还有点问题,头痛...

落后的蜘蛛就是DOS攻击……

现在遇到的另外一个问题是iptables会将封锁的ip解析为一个错误的域名。
而下次ip访问又无法封锁掉...

可以直接用iptables -I INPUT -s 60.28.235.177 -j REJECT将该IP永久封闭,然后用service iptables save 保存设置,这样可以达到下次重新启动机器还能够封闭该IP的目的。

thanks huc;

我是这样做的,不过问题是iptables会将封锁的ip解析为一个错误的域名。

请看:
[root@eygle logs]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
REJECT all -- www177.asd.tj.cn anywhere reject-with icmp-port-unreachable

因为我的服务器有向外的DNS查询,解析为一个错误的域名了.

这是因为你看到的是一个错误的域名,但实际上iptables已经忠实地按照你的要求进行了ip屏蔽。这一点可以通过iptables --list -n来看到,如果你需要看到每条规则的序号(也可以叫做行号),可以再加上一个--line的选项。前面一条命令中的-n参数是以数字名称显示已有的列表。你可以比较一下两条命令的执行时间,带有-n参数的会非常迅速,但是不带这个参数的就比较慢,因为它要进行DNS解析,这是需要时间的。
当然iptables还可以直接封闭某个网段,例如iptables -I INPUT -s 66.66.0.0/16 -j REJECT。这样可以直接封闭某个网段。

iptables --list -n 是可以看到未解析的ip地址,是正确的。
[root@eygle logs]# iptables --list -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
REJECT all -- 60.28.235.177 0.0.0.0/0 reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

但是问题是我这条规则肯定没生效,每天都还有一个时段被60.28.235.177这个地址拖死,不知道怎么回事.

今天早上又是如此,还可能是什么问题呢?

日志类似如下显示:
60.28.235.177 - - [06/Dec/2006:09:00:02 +0800] "HEAD /cgi-bin/mt/mt-search.cgi?tag=beijing&blog_id=1 HTTP/1.1" 500 - "http://www.eygle.com/cgi-bin/mt/mt-search.cgi?tag=beijing&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0)"
60.28.235.177 - - [06/Dec/2006:09:01:55 +0800] "HEAD /cgi-bin/mt/mt-search.cgi?tag=replay&blog_id=1 HTTP/1.1" 500 - "http://www.eygle.com/cgi-bin/mt/mt-search.cgi?tag=replay&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0)"

如果加上--line的参数你就可以看到你现在的INPUT链中首先的第一条就是跳到RH-Firewall-1-INPUT 链中(注意这条处理链是在那个被屏蔽的IP的处理规则前面的!),但是你的RH-Firewall-1-INPUT 链的内容没有列出来,所以我猜测是因为前面的这条规则已经允许了这个IP地址访问你的网站。这样以后所有的这个IP的请求都可以被允许通过。
假设你用--line参数看到的那条规则的序号是小于前面那个RH-Firewall-1-INPUT 规则的序号,就基本可以肯定我的猜测了。
如果你要删除某条规则,最简单的办法就是用iptables -D number的命令。
如果有这种情况,可以先使用-I INPUT(注意是大写的I)参数将这条规则加入到INPUT链的最前面一个。这样的话就会生效了。
其实网上有一篇相关的指南“iptables指南 1.1.19”,作者是“中国linux公社”的“Linux新鲜社员”。是中文版本的,可以看看,估计会有帮助。

非常感谢,我已经修改为:

[root@eygle ~]# iptables --list --line -n
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 REJECT all -- 60.28.235.177 0.0.0.0/0 reject-with icmp-port-unreachable
2 RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0

这次应该生效了吧,今天再看看!

不用客气。其实在网上也看到有分成不同协议(例如分成TCP,UDP,ICMP。也有按照服务来区分,例如:mail,http,ftp等。)来减少内核的处理量的脚本。大家多沟通吧。

谢谢,观察了一下,那个网址被成功封锁了:)

LZ啊 你是不是用没有更新的IP数据库查询的啊,这个IP分明是天津网通的IP嘛 ,我核实了google跟baidu上各大出名的IP数据库,均显示该IP为天津网通,而腾讯SOSO域名使用的的是电信的服务器,且服务器在广州,(偶之前在tencent干了一年)你是不是误封sosoIP哦!tencent的技术不会那么菜。

这个ip信息是从APNIC上查出来的,不会有问题的。
没说不是天津的ip阿,上面的信息就是:
descr: CNC Group CHINA169 Tianjin Province Network

另外一个搜索引擎有分布式前端并不意外,你看Google不还在中国有机器?


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com