|
|
本帖最后由 renguoshi 于 2012-2-15 11:27 编辑
昨天下午上线,到今早一看,anti-cc.com 安然无恙. 大家加大点力度
结合 3.tagcgi.com/view.html 显示的CC监控记录,跟大家分享一下昨天发生的几种攻击行为,以启发所应对的对策.
cc1.jpg
(22.19 KB, 下载次数: 0)
这种攻击是来自自动程序, 大家可以看到,记录了95次攻击.然后就渺无音信了. 为什么会这样呢? 我来解释一下.
在这种自动攻击被记录为CC前,会有一系列验证行为发生,而且根据攻击行为的变化,其后续验证是可以不同的. 对于这种自动攻击,假人检测最晚会在其访问 anti-cc.com的动态程序之前发生. 也就是说, 在开启假人检测的前提下,没有经过验证的自动访问,是不会"接触"到网站的动态内容的. 甚至这种自动攻击对静态文件的存取,也是受限的. 因为anti-cc.com的tagcgi服务器,对这种行为会进行"掺沙子"的行为. 如果其自动攻击不能符合web服务器掺沙子的路径规则.静态文件访问也会引起成功的CC防护.
当然,最关键的还是其具有独特算法的假人验证.这种验证的独特之处,在于它是算法无关的,它不像有些防CC防火墙那样,别人知道了算法,就可以用工具去伪造攻击包了. 它的算法无关的特性,决定了对方就算知道算法,也是无法展开CC攻击的.不管是智能程序,还是劫持浏览器. 这据说是人家tagcgi的专利. 这些都是跟并发次数无关的.
有同学要问了,居然记录到95次攻击,为什么不第一次就把这IP禁掉? 这是因为在检测到第一次攻击时,如果你配置了"实时IPTABLES阻断的话", tagcgi服务器为启动IPTABLES规则. 但因为攻击是来自自动程序,而自动程序往往运行在服务期上. 就像这个服务器,就是buyvm家的.其攻击速度很快.在IPTABLES规则应用成功之前,已经进来了95次连接! 不过,就算连接能进来,那也是很难有攻击行为的,因为这种访问,连静态文件都不会让它存取. 会被直接关掉. 然后CC次数增一而已.
cc2.jpg
(30.75 KB, 下载次数: 0)
再看这种攻击,这就是一直按住F5的结果 ,其实这种行为是可以放行的,但我为了验证tagcgi的防CC能力,故意把它配置出来. 呵呵,这种访问一般都会通过假人验证,因为是用的浏览器,而且频率不会太快(没法跟自动程序相比). 但是我有意设置了一个门槛,这个就是每秒请求次数, 但每秒请求次数再大,tagcgi也不会认为他是CC攻击的. 但在每秒请求次数超过设定的门槛时,tagcgi可以根据配置的规则,选择是否启动图像验证.如果超过图像验证次数,这个IP也会被封掉了
这种访问由于是人工刷新,而且一般不会在距离近的服务器上,所以被记录为CC的次数只有1. 也就是说,在IPTABLES启用规则的短时间间隔内,只能形成1次CC.
当然,对于这两种情况. 只要被认为是CC,其对动态程序,静态程序的访问都会被拒绝.
另外,对于手机浏览器,如果启动防CC功能. 由于手机浏览器喜欢重复发包,这就需要对图像验证开启的门坎提高些,这也是为什么用手机浏览器容易出验证码的原因.
有同学提醒大量IPTABLES的规则设置,可以用IPSET. 这个据说正再做,但据说要重新编译内核.
有同学需要防CC帮助的.站内消息我,可以义务帮忙.
|
评分
-
查看全部评分
|