全球主机交流论坛

标题: 再发防CC技术帖--攻击行为分析 [打印本页]
作者: renguoshi    时间: 2012-2-15 11:09
标题: 再发防CC技术帖--攻击行为分析
本帖最后由 renguoshi 于 2012-2-15 11:27 编辑

昨天下午上线,到今早一看,anti-cc.com 安然无恙. 大家加大点力度

结合 3.tagcgi.com/view.html 显示的CC监控记录,跟大家分享一下昨天发生的几种攻击行为,以启发所应对的对策.
(, 下载次数: 0)

这种攻击是来自自动程序, 大家可以看到,记录了95次攻击.然后就渺无音信了. 为什么会这样呢?  我来解释一下.

在这种自动攻击被记录为CC前,会有一系列验证行为发生,而且根据攻击行为的变化,其后续验证是可以不同的. 对于这种自动攻击,假人检测最晚会在其访问 anti-cc.com的动态程序之前发生. 也就是说, 在开启假人检测的前提下,没有经过验证的自动访问,是不会"接触"到网站的动态内容的. 甚至这种自动攻击对静态文件的存取,也是受限的. 因为anti-cc.com的tagcgi服务器,对这种行为会进行"掺沙子"的行为. 如果其自动攻击不能符合web服务器掺沙子的路径规则.静态文件访问也会引起成功的CC防护.
  当然,最关键的还是其具有独特算法的假人验证.这种验证的独特之处,在于它是算法无关的,它不像有些防CC防火墙那样,别人知道了算法,就可以用工具去伪造攻击包了. 它的算法无关的特性,决定了对方就算知道算法,也是无法展开CC攻击的.不管是智能程序,还是劫持浏览器. 这据说是人家tagcgi的专利. 这些都是跟并发次数无关的.

  有同学要问了,居然记录到95次攻击,为什么不第一次就把这IP禁掉?  这是因为在检测到第一次攻击时,如果你配置了"实时IPTABLES阻断的话", tagcgi服务器为启动IPTABLES规则. 但因为攻击是来自自动程序,而自动程序往往运行在服务期上. 就像这个服务器,就是buyvm家的.其攻击速度很快.在IPTABLES规则应用成功之前,已经进来了95次连接! 不过,就算连接能进来,那也是很难有攻击行为的,因为这种访问,连静态文件都不会让它存取. 会被直接关掉. 然后CC次数增一而已.
(, 下载次数: 0)

再看这种攻击,这就是一直按住F5的结果,其实这种行为是可以放行的,但我为了验证tagcgi的防CC能力,故意把它配置出来. 呵呵,这种访问一般都会通过假人验证,因为是用的浏览器,而且频率不会太快(没法跟自动程序相比). 但是我有意设置了一个门槛,这个就是每秒请求次数, 但每秒请求次数再大,tagcgi也不会认为他是CC攻击的. 但在每秒请求次数超过设定的门槛时,tagcgi可以根据配置的规则,选择是否启动图像验证.如果超过图像验证次数,这个IP也会被封掉了

这种访问由于是人工刷新,而且一般不会在距离近的服务器上,所以被记录为CC的次数只有1. 也就是说,在IPTABLES启用规则的短时间间隔内,只能形成1次CC.

当然,对于这两种情况. 只要被认为是CC,其对动态程序,静态程序的访问都会被拒绝.

另外,对于手机浏览器,如果启动防CC功能. 由于手机浏览器喜欢重复发包,这就需要对图像验证开启的门坎提高些,这也是为什么用手机浏览器容易出验证码的原因.

有同学提醒大量IPTABLES的规则设置,可以用IPSET. 这个据说正再做,但据说要重新编译内核.
有同学需要防CC帮助的.站内消息我,可以义务帮忙.

作者: zyzit    时间: 2012-2-15 11:10
支持此类文章 哦耶
作者: 用户名    时间: 2012-2-15 11:13
路过
作者: renguoshi    时间: 2012-2-15 11:17
攻击可以,但不要把我的流量耗尽啊
作者: renguoshi    时间: 2012-2-15 11:42
这个防cc web服务器是免费的.大家试一下.如果扛得住,反正可以免费用
作者: geyunbing    时间: 2012-2-15 11:43
提示: 作者被禁止或删除 内容自动屏蔽
作者: Kokgog    时间: 2012-2-15 11:45
ipset不用重新编译内核,只需要编译进内核
作者: sowahkhoo    时间: 2012-2-15 11:47
提示: 作者被禁止或删除 内容自动屏蔽
作者: renguoshi    时间: 2012-2-15 11:50
Kokgog 发表于 2012-2-15 11:45
ipset不用重新编译内核,只需要编译进内核

恩,估计加上这个就更强悍了.  
作者: sunsea    时间: 2012-2-15 12:11
mark
作者: 我是人    时间: 2012-2-15 12:18
本帖最后由 我是人 于 2012-2-15 12:19 编辑

有个问题。。。那个图片验证，是真的还是假的？
作者: 有个就好    时间: 2012-2-15 12:24
额，CC
作者: renguoshi    时间: 2012-2-15 12:26
本帖最后由 renguoshi 于 2012-2-15 12:27 编辑
我是人 发表于 2012-2-15 12:18
有个问题。。。那个图片验证，是真的还是假的？


？
为什么是假的？ 刷新下看看。 但在手机上可能会不正常。
作者: 我是人    时间: 2012-2-15 12:30
renguoshi 发表于 2012-2-15 12:26
？
为什么是假的？ 刷新下看看。 但在手机上可能会不正常。

因为。。。在Opera上看不到图片，但是不填任何东西点Verify都验证成功。
作者: 我是人    时间: 2012-2-15 12:32
还有个问题。。。3.tagcgi.com防CC吗？
作者: renguoshi    时间: 2012-2-15 12:33
我是人 发表于 2012-2-15 12:30
因为。。。在Opera上看不到图片，但是不填任何东西点Verify都验证成功。

嗯，如果开启防cc功能，手机上有点乱。 你试试能访问么
作者: 我是人    时间: 2012-2-15 12:33
本帖最后由 我是人 于 2012-2-15 12:37 编辑
renguoshi 发表于 2012-2-15 12:33
嗯，如果开启防cc功能，手机上有点乱。 你试试能访问么


不是手机。。。

可以访问，就是如果出现图片验证时，图片出不来，而且可以不填任何东西直接验证成功。
作者: renguoshi    时间: 2012-2-15 12:34
本帖最后由 renguoshi 于 2012-2-15 12:35 编辑
我是人 发表于 2012-2-15 12:32
还有个问题。。。3.tagcgi.com防CC吗？


这个好像不防，没开启防cc。应该只是个临时服务器。上面有些示例源码而已
作者: renguoshi    时间: 2012-2-15 12:36
本帖最后由 renguoshi 于 2012-2-15 12:41 编辑
我是人 发表于 2012-2-15 12:33
不是手机。。。


据说测过ie，chrome，firefox。 opera好像没测过。但我手机用opera访问未开启cc的tagcgi是可以的。但开了cc，访问的话，出验证码的机滤比较高的。 你安住F5,看会把你封掉么
作者: www4074    时间: 2012-2-15 12:36

支持此类文章 哦耶
作者: 我是人    时间: 2012-2-15 12:43
renguoshi 发表于 2012-2-15 12:36
据说测过ie，chrome，firefox。 opera好像没测过。你安住F5,看会把你封掉么
...

刚刚试了一下，没封。

ISP有proxy，每个连接使用不同IP。
作者: renguoshi    时间: 2012-2-15 12:46
本帖最后由 renguoshi 于 2012-2-15 12:47 编辑
我是人 发表于 2012-2-15 12:43
刚刚试了一下，没封。

ISP有proxy，每个连接使用不同IP。


  没用过opera，估计发包频率没过门槛。等回头我也装个试试。

刚封了3个按F5的
Ip is:220.255.2.71  
Record Time at: 2012-02-15 07:45:03 CC count:1
Show the IP's CC history

Ip is:114.240.36.252  
Record Time at: 2012-02-15 07:34:22 CC count:1
Show the IP's CC history

Ip is:106.9.2.1  
Record Time at: 2012-02-15 07:30:24 CC count:1
Show the IP's CC history
作者: 我是人    时间: 2012-2-15 12:48
renguoshi 发表于 2012-2-15 12:46
没用过opera，估计发包频率没过门槛。等回头我也装个试试。

刚封了3个

220.255.2.71是ISP的proxy。。。问题是，他们有一大堆IP。
作者: renguoshi    时间: 2012-2-15 12:51
我是人 发表于 2012-2-15 12:48
220.255.2.71是ISP的proxy。。。问题是，他们有一大堆IP。

嗯，再多的IP，只要不到流量攻击的份上，那也是没用的。
proxy连带无辜的问题，之后可以靠规则解决，需要把规则配成，当CC停止时，立即放开被禁的IP就可以。一样也可以防CC,但又尽量不累及无辜。
作者: renguoshi    时间: 2012-2-15 13:36
本帖最后由 renguoshi 于 2012-2-15 13:45 编辑

第一阶段测试通过，现在启用自动CC开启。在不检测到CC行为时，不会开启防CC.  这种模式，其实对服务端来讲，性能差别不大。但客户端如果不做攻击的话，就会少了验证过程。能够加快访问速度。
作者: domin    时间: 2012-2-15 13:37
不懂求带
作者: renguoshi    时间: 2012-2-15 13:45
domin 发表于 2012-2-15 13:37
不懂求带

一起学习
作者: 银网小吴    时间: 2012-2-15 13:51
支持LZ
作者: renguoshi    时间: 2012-2-15 14:16
大家用服务器CC吧，别老用F5了

转个CC测试工具：


wget http://www.abiao.org/soft/linux/webbench-1.5.tar.gz
tar zxvf webbench-1.5.tar.gz
cd webbench-1.5
make && make install
webbench -c 500 -t 300 http://anti-cc.com/index.html

然后去看看自己服务器被禁了没
作者: 杯具    时间: 2012-2-15 14:16
弄得好复杂，其实只要限制同一个ip，同时访问服务器的线程数就可以了。
作者: renguoshi    时间: 2012-2-15 14:19
杯具 发表于 2012-2-15 14:16
弄得好复杂，其实只要限制同一个ip，同时访问服务器的线程数就可以了。

这样不行，具体看资料。因为没法防多肉鸡同时低频率CC
作者: meta168    时间: 2012-2-15 14:33
技术贴,看不懂
作者: x10    时间: 2012-2-15 15:53
支持技术文章



欢迎光临 全球主机交流论坛 (https://hostloc.onozo.cc/) Powered by Discuz! X3.4