建站一个月。。。几乎每天都在被攻击。。。而且道高一丈魔高一丈的。。。攻击方法不断升级。。。
我的架构是nginx php mysql,今天搭上了SSDB,依旧未管用
主要攻击是在搜索页,一开始是单一ip单一词汇刷而已
封了ip以后变成n个ip不停刷
于是我就把搜索使用的词封掉,于是变成n个8-10个词的组合不停的刷,就这也算有规律可循
但是到了今天变成了拿字典来刷,完全无规律组合词多ip不停搜索
一上来我就挂,即使我把搜过的纪录全放到了SSDB,但是还是一刷就挂,一堆新组合词语,mysql瞬间200%,nginx 503。
最后只能放上了验证码,机制是搜索10次填写一次验证码。。。至于这个办法是否管用现在还不知道。。。
有人建议用sphinx,我还没用,貌似文档不太友好,对我这个非技术人员比较头疼。。。
求专业技术大拿提供解决问题思路。。。
1
raly 2014-12-23 21:47:45 +08:00 via iPhone
什么站这么招人嫉妒?
|
2
ryd994 2014-12-23 21:49:01 +08:00 via Android
Nginx limit_req limit_conn
|
3
yunshansimon 2014-12-23 21:49:20 +08:00 via iPad
登录以后用自己的搜索,登录之前,所有搜索转百度。注册用邮箱或手机认证。
|
4
zhs227 2014-12-23 21:49:33 +08:00
这个事情描述的很劲爆,就像楼主的头像一样, 火!
为什么不弄注册用户才能搜索呢,每小时每用户只能搜3个关键词,再加个注册验证码或手机号注册验证(参考115),妥妥的就解决了啊?楼主没写清楚网站,难道是你之前说的那个字幕站? |
5
kingda 2014-12-23 21:50:14 +08:00
huo360.com ?@raly @Jack
|
6
LINAICAI 2014-12-23 21:50:15 +08:00
开玩笑吧。。。我垃圾站放一年没人来看
|
7
Jack OP @yunshansimon 这倒是个办法。。。以前没有想到。。。不过似乎和让填验证码也没啥本质区别
|
8
ryd994 2014-12-23 21:51:38 +08:00 via Android
还有限制搜索搜索频率,这个让PHP做,频率过高的直接503让他以为成功
|
9
nocturnal 2014-12-23 21:52:15 +08:00 via Android
封ip?
|
11
Cu635 2014-12-23 21:55:02 +08:00
限制搜索频率,六维就是这么干的。
加上搜索多少次之后要验证码,google对可疑ip就是这么干的。 |
15
iyaozhen 2014-12-23 22:03:25 +08:00
加上验证码基本上可以了,良好的验证码还是比较难破解的,或者说是破解成本升高。
|
16
20150517 2014-12-23 22:05:20 +08:00 via Android
搜索一般是直接post,这种post完全没有cookie没有session,知道这点后,没session上手就post的,返回一个cached的页面,
1. 不要去封什么ip,没意思的,外面ip买买几分钱一个代理,你手动封肯定不是办法 2. 要返回正常页面,使他不能判断是不是你服务器到极限了 几次下来,他就无趣了,ip毕竟要花钱 ,他也是有点成本的 |
17
ljcarsenal 2014-12-23 22:05:28 +08:00
攻击图什么呢 要保护费么
|
18
20150517 2014-12-23 22:06:34 +08:00 via Android
如果他升级了,有session了,你要封ip要自动化,参考谷歌,你搜多了他就不让你搜了
|
19
ElmerZhang 2014-12-23 22:07:00 +08:00
搜索达到一定频率搜索功能直接启用验证码,不按IP什么的做限制,直接按功能做限制
|
20
Jack OP @ljcarsenal 我也想知道,只能理解为竞争对手,我的网站上不去就去他的网站了
|
22
yunshansimon 2014-12-23 22:12:18 +08:00 via iPad
@Jack 换IP这种攻击,如果你还要运行什么行为分析代码,服务器早over了,只能堵他是机器人的漏洞。他的客户端就干一个事,换不同ip(断网拨号,或者在VPN里面切换),post查询。你可以这样试一下,在查询页面里加一个隐藏随机码,这个随机码同时放到session里面,获得post后,检查随机码是否等于session里保存的随机码,不等于就404。这用来防止无脑post型,就算他写代码,也必须先get你的网页,解析加入查询内容,然后才能提交,他也需要很多内存。
|
23
Jack OP @yunshansimon 我也发现了。。。记录ip分析啥的完全无用。。。上来直接就挂。。。
|
24
zhs227 2014-12-23 22:16:43 +08:00
20150517 提到的这个是好办法
我又想到,如果IP确实太多封不完的话,最关键保护方法有两点: 1. 不要让搜索结果页面异常(比如ban IP 或404),或者至少让攻击者很难分辩结果页面是否专门针对攻击设计 2. 即使攻击者发现了结果不对(比如是缓存结果),也不能让他找到为什么结果不对(隐藏识别算法)。就像 @20150517 说的一样,在页面请求的时候js初始化一个cookie(比如md5(ip)之类的),然后判断没有cookie的请求一律返回cache页面。 |
25
salemilk 2014-12-23 22:17:01 +08:00 via iPhone
神马网站这么火啊?
|
26
nilai 2014-12-23 22:19:08 +08:00
小型CC。 改程序就应该能搞定。
|
27
moname 2014-12-23 22:24:16 +08:00
访问此页面: http://huo360.com/v 出现一些错误
A PHP Error was encountered Severity: Warning Message: array_multisort(): Array sizes are inconsistent Filename: v/main.php Line Number: 74 |
28
oott123 2014-12-23 22:28:08 +08:00
|
30
pubby 2014-12-23 22:41:33 +08:00
shpinx中文不行啊,得用coreseek 不过这货几年没更新了
用coreseek在索引不大的情况下大概是 30ms 每查询 如果你都是简单查询视频名称的话,可以考虑自己先弄一份分词好的映射表,直接丢内存查找 不过话说回来,人家铁了心要搞你,到时候还是会有新花样出来的。 |
31
Jack OP 刚才瞬间被爆了,验证码也没啥用了,就是海量请求。。。秒挂,然后又秒好,只能听天由命了么。。
|
33
dbas 2014-12-23 23:07:05 +08:00
同你程序无关,小小的cc攻击,只有自动封ip最合理
我都是这样处理的 |
34
jyoe 2014-12-23 23:09:49 +08:00 via Android
流量攻击无非是求财,逼你做广告啥的。
|
35
cevincheung 2014-12-23 23:13:44 +08:00
@Jack 每秒几百次还是妥妥的。sphinx给出数据在mysql中的ID,然后根据ID去MySQL中检索数据。
ID关联的MySQL结果可以缓存到Redis。Hash还是很有效的。 Ps。不要说你的db、web、proxy都在一台服务器上…… - -# |
37
nilai 2014-12-23 23:18:14 +08:00 via iPad
Ci写的。好多地方有漏洞哦
|
38
Jack OP @cevincheung 小弟不是做技术的- -,再说网站流量还不大,我还没觉得有必要去弄这些。。。
|
39
lsylsy2 2014-12-23 23:19:13 +08:00
上CDN试试?
国内安全宝 360,国外CloudFlare |
40
yangxin0 2014-12-23 23:23:26 +08:00
把nginx的请求数量限制。 设置一个mysql不会挂的数值。内核的syn_cookie打开.
|
41
yangxin0 2014-12-23 23:25:28 +08:00
写一个脚本分析nginx日志, 在crontab上定期运行, 5min or 其他, 发现请求书高的IP用iptables给封掉。基本连续跑一天, 攻击中手上的肉鸡都会被封杀完。 我想你这个小站也不会让攻击中动用几十万肉鸡吧, 如果是这样, 把服务器停了吧。
|
42
yangxin0 2014-12-23 23:26:25 +08:00
IP阈值你这个要好好思考, 或者可以先上线在动态调整。
|
43
zhs227 2014-12-23 23:29:16 +08:00
还有一招,把搜索引擎的页面地址改为随机生成,不停的改。一分钟几十万次,带宽也会被塞满吧,只有静态页面加CDN才扛得住,还要流量足。
|
44
cevincheung 2014-12-23 23:29:45 +08:00 1
|
45
cevincheung 2014-12-23 23:31:40 +08:00
@Jack
那就给服务器上点配置,redis+sphinx一上,立刻妥妥的。 |
46
yangxin0 2014-12-23 23:33:09 +08:00
@cevincheung 人家就一个单机小站, 你这是要搞集群么。
|
48
billwang 2014-12-23 23:39:10 +08:00
这种攻击,就是你把搜索搞定了他还会从其他层面攻击,建议从根本考虑解决。比如放到大一些的云服务商上去,或者找专业服务商解决,不是不知道到哪里交保护费吗?这些渠道可以试试看。
|
49
Jack OP @cevincheung 好吧。。。明天先搞定sphinx试试。。。
|
51
leofml 2014-12-23 23:44:26 +08:00
试试安全狗吧, 基于session的302跳.
|
52
izoabr 2014-12-23 23:45:13 +08:00
如果内容开放就第三方搜索,如果不开放就注册用户权限控制。
完了加上CDN吧 |
53
danliuwo 2014-12-23 23:55:45 +08:00
直接索引数据库肯定受不了,推荐 xunsearch/coreseek
|
55
shiny 2014-12-24 00:03:51 +08:00 1
简单粗暴——改用百度/google 的站内搜索
|
56
Slienc7 2014-12-24 00:08:35 +08:00 via Android
都已经趴了 为何还不换谷歌?
|
57
lecher 2014-12-24 00:09:04 +08:00
先关掉站内搜索功能,切换成用百度站内搜索,普通用户可以勉强用,反正开了也会被刷挂掉。
全站用nginx对首页、目录页做一下静态化。 |
60
Slienc7 2014-12-24 00:12:08 +08:00 via Android
第三方图形/动画验证码
|
61
lecher 2014-12-24 00:17:56 +08:00
只是为了先分流攻击,保证网站不挂。
至于请求有没有效无所谓了。这么大流量的百度站内搜索,还可以帮你刷刷域名的热度呢。 建站一个月就被攻击那么凶残,多大仇才能花那么大的成本打你的网站。 |
62
wdhwg001 2014-12-24 00:29:39 +08:00 via iPhone
…搜索结果页面静态,用一个js生成ip分段cookie去ajax获取结果,然后根据C段设置每255个ip在5秒内只能搜索一次,如果撞了的话所有的255个ip都要输入5次第三方验证码(这个页面是静态的)…
说白了有点像一个信任机制,比如一开始是2,撞cd会掉成负的,负的需要验证码,输入成功一次+1,再撞又会扣,下限为-10… 另外请确保乃的ip识别是只识别真实ip,不处理任何forward… |
63
shiny 2014-12-24 00:35:43 +08:00
既然只上线一个月,肯定没多少真实用户访问;
换我就直接把搜索功能去掉,然后其他页面做 cache; 粗暴直接有效。 |
64
wdhwg001 2014-12-24 00:41:05 +08:00 via iPhone 1
ajax无cookie→显示“无搜索结果”(静态,直接一行代码踢走)
ajax中的cookie和ip不符→显示“无搜索结果”(静态,同样踢走) 信任为0以下→显示第三方验证码页面(静态,因为查了session所以这时候其实是跑了一点代码的) 正确输入了验证码→信任+1并像正常一样处理搜索 信任大于0→几率扣除信任并正常显示结果 |
65
lhbc 2014-12-24 00:55:28 +08:00
|
66
lxyu 2014-12-24 01:40:50 +08:00
这个是典型的打你的搜索链接。查下 cc 攻击防御吧。
|
67
msg7086 2014-12-24 01:52:48 +08:00
limit_req+fail2ban,很难么?
动态请求次数超过每秒1次直接自动封ip1小时。 你最起码得有几万个ip才能一波带走服务器。 |
68
typcn 2014-12-24 04:00:26 +08:00 9
你可以看看我博客右边的搜索
http://blog.eqoe.cn/ 提交 Get 请求,如果关键词没有被缓存,服务器返回 error=1 表示需要 Hash 验证 然后,获得一个 TOKEN,然后客户端在此 TOKEN 后增加[数字],直到这个字符串 SHA1 值的前4位为0 提交 POST 请求,将 TOKEN 与 计算出的[数字]一同提交到服务器,服务器验证正确之后返回搜索内容,并将内容缓存到内存中,下次搜索直接返回。 一个IP地址只能拥有一个 TOKEN ,如果重复获取之前的 TOKEN 将失效。 他一提交搜索请求 CPU 满一个核心,3秒之后计算完成,才进行了一次搜索,他那些代理IP毫无用处,除非他有成千上万台电脑。 然而对用户来说,等待3秒比输入验证码好得多。 详情可以参考这篇文章 http://blog.eqoe.cn/posts/add-search-and-hashcash.html 你可以测试对我的博客进行批量搜索,我的博客是单核运行的,只有 100MB 可用内存,测试一下需要多大压力才能打挂。 |
69
tumutanzi 2014-12-24 06:14:16 +08:00
为什么攻击你?
|
70
clino 2014-12-24 07:35:18 +08:00 via Android
我觉得iptable封ip的时候封整个网段会不会更快
|
71
twinsant 2014-12-24 08:59:49 +08:00
@Jack 如何防御DDoS攻击:流量攻击防御生存手册 http://twinsant.com/tech/battle-of-ddos
|
72
tabris17 2014-12-24 09:09:56 +08:00
从一开始的CC攻击变成DDoS了咯,那就要改别的措施了
|
73
huigeer 2014-12-24 09:21:17 +08:00
跟你什么仇什么怨,,
|
74
139885087 2014-12-24 09:25:00 +08:00
跟你什么仇什么怨
|
76
rhwood 2014-12-24 09:30:50 +08:00
封ip+花钱硬抗,攻击你也是有成本的。
|
78
iiusky 2014-12-24 09:47:12 +08:00
弄个用户注册机制,然后做任务换取积分,搜索一次扣1分,然后一分钟内这个用户这个 ip只能搜索2次
|
80
hslx111 2014-12-24 10:02:57 +08:00
我在想楼主到底惹到什么人了。。。
|
81
clino 2014-12-24 10:04:08 +08:00
我觉得还是写个脚本把所有有异常行为的ip所在的255网段用iptable的方式封掉这样比较快
攻击者的代理服务器也不会无穷无尽的吧 |
82
mjever 2014-12-24 10:06:59 +08:00
这得多大仇?
|
84
geew 2014-12-24 10:09:50 +08:00
搜索不是post请求么 限制每分钟每个ip的请求数量 超过的打入黑名单 参考v2ex
|
85
wy315700 2014-12-24 10:15:41 +08:00
想办法找到攻击者,
|
87
tabris17 2014-12-24 10:20:06 +08:00
首先攻击者也是有成本的,一是IP地址;二是CPU资源。抵御攻击无非就是用最少的成本尽可能地耗费攻击者的这两种资源。
方法楼上都写了,也就这么些 |
89
chenshaoju 2014-12-24 10:42:18 +08:00
|
90
Jack OP @chenshaoju 有没有国外的类似服务呢。。。未备案网站。。。国内这种服务一概无法使用
|
91
aa45942 2014-12-24 10:58:26 +08:00
|
92
wikimo 2014-12-24 11:08:17 +08:00
什么站这么牛逼,天天攻击,sphinx 替代品可以尝试xunsearch,文档啥的,你应该能懂,操作也简单,搜索速度也还可以。你放个静态页面在那里会不会挂掉,不会的话,可以考虑通过memcached, redis之类的工具,将频频攻击的ip加入到一个黑名单中去,直接不参与搜索,或者结合iptables和脚本去尝试解决,实在不行就先关站吧,流量攻击都不太好解决。个人意见。
|
93
clino 2014-12-24 11:08:32 +08:00
@chenshaoju 如果攻击者有成千上万个代理ip,那是可以做到1分钟内用不重复的ip来刷的
我有个新想法,给每个ip在后段生成一个token,搜索的提交用前端javascript来调用api来获取结果,调用api的时候必须使用这个和ip配合的token才能获取到结果,token是一次性的,用完马上就生成新的,前端javascript里的token是动态生成的嵌在html里的 当然攻击者也可以分析html里的javascript来获取到token,那么可以吧javascript里的token的生成千变万化,比如用不同的变量名,token可以用生成函数来获取,这样可以变化多端,用较少的改变就能增加很多攻击者的成本 |
94
frankzeng 2014-12-24 11:15:24 +08:00
你把攻击过的ip提出来,全部封掉,过段时间应该就清静了
|
95
aust1n 2014-12-24 11:23:37 +08:00
丢一个验证码 www.geetest.com
有用记得金币 |
96
wizardforcel 2014-12-24 11:37:53 +08:00
交保护费没门。趁不能访问去加速乐备个案,然后直接用它的cdn。
|
97
oott123 2014-12-24 11:39:09 +08:00 via Android
|
98
lolicon 2014-12-24 11:40:54 +08:00
@Jack www.cloudflare.com 当年香港xx,马来西亚xx的时候,都是这一家抗的
|
100
ksky 2014-12-24 11:45:23 +08:00
可以先把搜索交给Google。
|