免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
12
最近访问板块 发新帖
打印 上一主题 下一主题

应用层的FLOOD攻击,大家对于这样的攻击有什么办法? [复制链接]

论坛徽章:
0
11 [报告]
发表于 2005-07-10 12:58 |只看该作者

应用层的FLOOD攻击,大家对于这样的攻击有什么办法?

你只是缓解了单个IP发起多个连接并反复执行同一有弱点的脚本所造成的DoS问题,但是并没有解决这个脚本本身的问题。就好像给一个牙痛病人开了镇痛剂一样,这是缓解症状的作法,而不是解决问题的作法。假如对方改变作法,例如采用30台或更多机器同时刷登录页面,那不还是会死么……

我认为提高被攻击的那个页面的处理能力是关键。例如,尽量缩短页面持有数据库连接的时间,把一部分适合数据库来做的工作交给数据库而不是在程序中做,等等。如果发现即使这样做仍然无法解决问题,可以考虑用db做一个每IP每30秒只允许登录一次、全局范围只允许30个连接同时进入登录操作的限制。

论坛徽章:
0
12 [报告]
发表于 2005-07-10 13:13 |只看该作者

应用层的FLOOD攻击,大家对于这样的攻击有什么办法?

原帖由 "delphij" 发表:
你只是缓解了单个IP发起多个连接并反复执行同一有弱点的脚本所造成的DoS问题,但是并没有解决这个脚本本身的问题。就好像给一个牙痛病人开了镇痛剂一样,这是缓解症状的作法,而不是解决问题的作法。假如对方改变作法,例如采用30台或更多机器同时刷登录页面,那不还是会死么……

30个同时DOS的话,一样的不会有问题,因为是属于应用层攻击,也就是说30个IP绝对是真实的,而且建立了非常多的并发连接,如果是DOS肯定会比一般的浏览要多,比如50个甚至100个,那么这个时候脚本会整理出超过这些数量的IP出来自动加到防火墙规则里。当然也有缺点,就是假如很多人用同一个IP的时候,会被“误杀”,但是也是没有办法的。毕竟是计算机,对于这样的现象人工都不一定能判断出来又何况一个自动程序呢?

原帖由 "delphij" 发表:

我认为提高被攻击的那个页面的处理能力是关键。例如,尽量缩短页面持有数据库连接的时间,把一部分适合数据库来做的工作交给数据库而不是在程序中做,等等。如果发现即使这样做仍然无法解决问题,可以考虑用db做一个每IP每30秒只允许登录一次、全局范围只允许30个连接同时进入登录操作的限制。

和程序有一点点关系,的确是不错,但最关键的是DOS是广义的概念,并不是只是在某一方面,由于对方IP采用的是使用login方式来攻击,所以造成了MYSQL的负荷增加,假如他用别的方式呢?比如不停的访问一个页面,虽然并不操作数据库,但如果每个数量足够多一样形成DOS。那么这个时候我们又开始修改http服务?HTTP服务修改完了无法再提高了,就提高磁盘IO?程序的优化毕竟都有个限度,要完全杜绝DOS只怕最重要的还是人心。而人心我们无法在这里改造,所以我们只能选择最捷径的方法。

论坛徽章:
0
13 [报告]
发表于 2005-07-10 16:32 |只看该作者

应用层的FLOOD攻击,大家对于这样的攻击有什么办法?

我认为你的系统被DoS的最根本的原因是MySQL连不上了(通常DoS攻击都通过耗尽某种容易耗竭的资源来达到目的),那么,我们是否可以认为,通过增加这类资源的数量,或者减少某一特定用户耗尽这一资源的可能性来达到阻止攻击的目的呢?

我觉得基于2-4层的防御手段通常只适合于本身就是2-4层的攻击,或者非常严重的DDoS。比如你说的访问同一个页面,要达到目的攻击的发起者同样需要很高的代价(带宽),一般做DoS的人是不会这样做的(他们要达到的是“四两拨千斤”或者说“非对称”攻击)。那你说,DoS有没有办法杜绝?多数还是有办法的,类似网易、新浪这样的公司会采用包括负载均衡设备、增加服务器带宽等等各种各样的技术来提高DoS的“门槛”,想要DoS他们,你需要进入机房(或者跟机房有非常好的连接),然后用专用的网络测试设备直接去攻击服务器,通常还得一下子攻击所有的机房才能做到。



说到这里我想起了某个我维护的网站在某天早上由于某人以测试目的将某省所有DNS解析不到的地址全都转到这个网站上,并导致MySQL连接数过高且服务器过载的情况。这种攻击属于显然的DDoS,按说是没办法挡住的,但仔细分析访问发现多数“攻击”是针对这个网站的首页进行的,而且有一些特征,于是解决方案就出来了——在首页针对这种特征作短路操作,其效果是那台服务器的load迅速从70+下降到了1以下。

其实这就是安全的另一方面——安全是有代价的,你需要的是“成本上可行”的方法来获得“相对的”安全,或者说,攻击者攻击你所带来的收益要低于甚至远远低于他要付出的成本,而且你为了这种安全所付出的代价也不太大——而不是做到“绝对的”安全,因为后者根本不可能做到,或者做到的成本远远高于通过避免某种攻击所能带来的收益。

论坛徽章:
0
14 [报告]
发表于 2005-07-10 16:58 |只看该作者

应用层的FLOOD攻击,大家对于这样的攻击有什么办法?

原帖由 "platinum" 发表:

能否解释一下?能承受多少量的攻击?

阁下的签名图选的那个网站太垃圾了吧
WINDOWS都能拼错掉的
我昏

论坛徽章:
0
15 [报告]
发表于 2005-07-10 17:17 |只看该作者

应用层的FLOOD攻击,大家对于这样的攻击有什么办法?

原帖由 "delphij" 发表:

我认为你的系统被DoS的最根本的原因是MySQL连不上了(通常DoS攻击都通过耗尽某种容易耗竭的资源来达到目的),那么,我们是否可以认为,通过增加这类资源的数量,或者减少某一特定用户耗尽这一资源的可能性来达到阻止攻击的目的呢?

我觉得基于2-4层的防御手段通常只适合于本身就是2-4层的攻击,或者非常严重的DDoS。比如你说的访问同一个页面,要达到目的攻击的发起者同样需要很高的代价(带宽),一般做DoS的人是不会这样做的(他们要达到的是“四两拨千斤”或者说“非对称”攻击)。那你说,DoS有没有办法杜绝?多数还是有办法的,类似网易、新浪这样的公司会采用包括负载均衡设备、增加服务器带宽等等各种各样的技术来提高DoS的“门槛”,想要DoS他们,你需要进入机房(或者跟机房有非常好的连接),然后用专用的网络测试设备直接去攻击服务器,通常还得一下子攻击所有的机房才能做到。

说到这里我想起了某个我维护的网站在某天早上由于某人以测试目的将某省所有DNS解析不到的地址全都转到这个网站上,并导致MySQL连接数过高且服务器过载的情况。这种攻击属于显然的DDoS,按说是没办法挡住的,但仔细分析访问发现多数“攻击”是针对这个网站的首页进行的,而且有一些特征,于是解决方案就出来了——在首页针对这种特征作短路操作,其效果是那台服务器的load迅速从70+下降到了1以下。

其实这就是安全的另一方面——安全是有代价的,你需要的是“成本上可行”的方法来获得“相对的”安全,或者说,攻击者攻击你所带来的收益要低于甚至远远低于他要付出的成本,而且你为了这种安全所付出的代价也不太大——而不是做到“绝对的”安全,因为后者根本不可能做到,或者做到的成本远远高于通过避免某种攻击所能带来的收益。


不错,这的确是解决问题的方法之一,但是毕竟受到硬件设备的影响,让我不能随便开启那么高的资源。的确防止DoS这样的攻击是需要一定成本才行的。在现有基础上,也并不是所有人都有足够的条件来防止各种攻击,其实我也趋向于使用你说的这些方法。但在目前的情况看,我还是只能先用这个临时方法来解决。

论坛徽章:
0
16 [报告]
发表于 2005-07-10 17:45 |只看该作者

应用层的FLOOD攻击,大家对于这样的攻击有什么办法?

改一下login程序应该不用那么高成本吧……

论坛徽章:
2
丑牛
日期:2013-09-29 09:47:222015七夕节徽章
日期:2015-08-21 11:06:17
17 [报告]
发表于 2005-07-10 17:59 |只看该作者

应用层的FLOOD攻击,大家对于这样的攻击有什么办法?

[quote]原帖由 "delphij"]其实这就是安全的另一方面——安全是有代价的,你需要的是“成本上可行”的方法来获得“相对的”安全,或者说,攻击者攻击你所带来的收益要低于甚至远远低于他要付出的成本,而且你为了这种安全所付出的代价也不太大——而不是做到“绝对的”安全,因为后者根本不可能做到,或者做到的成本远远高于通过避免某种攻击所能带来的收益。.[/quote 发表:

强烈支持!

论坛徽章:
0
18 [报告]
发表于 2005-07-10 18:47 |只看该作者

应用层的FLOOD攻击,大家对于这样的攻击有什么办法?

[quote]原帖由 "delphij"]改一下login程序应该不用那么高成本吧……[/quote 发表:

login改不改效果一样,呵呵~何况login要用的某些东西真的不能少也不能随便修改。
最重要的是login只是其中一种方式而已,日志里还有其他很多方式,比如某个页面的浏览等等。以及并发浏览N个页面等等。改了login也一点用都没有。

论坛徽章:
0
19 [报告]
发表于 2005-07-10 23:17 |只看该作者

应用层的FLOOD攻击,大家对于这样的攻击有什么办法?

login,加上一个验证码,这个不是动作最小,效果友好?


这个解决办法 最好 为什么不用呢?(验证码 没有被破解以前)

只要验证码错误 就不进行数据库操作了
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP