彻底根治DDoS?只有他们才能做到

安全 黑客攻防
解决DDoS问题,有人认为很容易,只需要让ISP(互联网服务商)重写互联网即可。重写互联网标准,尤其是处于路由系统核心位置的边界网关协议(BGP),应得到妥善修订。

解决DDoS问题,有人认为很容易,只需要让ISP(互联网服务商)重写互联网即可。重写互联网标准,尤其是处于路由系统核心位置的边界网关协议(BGP),应得到妥善修订。

[[180017]]

BGP真心是个非常糟糕的东西,欧洲网络与信息安全局(ENISA)将称之为“互联网的阿克流斯之踵”。理想世界里,这个东西必须被重写。但现实世界中,情况就复杂了。

除了要让政府监管机构帮助重写互联网路由层这种可怕的想法,这还像是试图完全重建一艘豪华游轮一样匪夷所思。仅仅是因为游轮服役已久,舱门有点关不严实了就要拆了重建是不合理的。这是艘大船,正航行在海洋上,人们都还生活在里面。

无论如何,ISP已经让各种标准帮助阻挡了至少一类DDoS,而且这玩意儿存在16年了。他们所要做的,就是实现和完善它。

反射问题

尽管有很多子类,DDoS攻击可被分为2大类。第一类是直接攻击,设备直接对目标发起流量洪水。

第二类是反射攻击。攻击者通过使用貌似目标的地址,向另一台设备发送数据包,来冒充目标。然后收到数据包的设备就会试图联系目标,实现DDoS攻击并将真正的目标踢掉线。

攻击者将IP包头的源地址字段替换成受害目标的地址,玩弄反射设备,让反射设备不知不觉就成了DDoS攻击的帮凶。这有点像是冒用别人的身份发送信件。其中关键在于放大:这取决于所发数据包的类型,发给目标的响应包可能大上一个数量级。

路由安全相互商定规范(MANRS)解释称:通过确认源地址和使用能阻止错误源IP地址数据包进出网络的反欺骗过滤,ISP可以有效防止第二类DDoS攻击。这是一部分网络运营者提出的宣言,他们希望通过向服务提供商提交最佳实践,来让路由层更加安全。

返回发送者

BCP 38,这个2000年就已出现的标准可以做到这一点。在网络边界设备上实现后,它可以检查入站数据包是否含有客户认可的源IP地址(比如,在恰当的IP段内)。如果不包含正确的源IP地址,数据包即被丢弃。很简单的标准,值得在自身环境中实现。如果所有运营者都实现了这一简单的最佳实践,反射和放大型DDoS攻击将得到大幅减少。

还有其他东西可供ISP阻住这些攻击,比如响应速率限制。权威DNS服务器常被用作反射式攻击中蠢笨且易上当帮凶,因为它们发给受害目标的流量比攻击者发送的还多。这些DNS的运营者,就可以用BIND软件默认自带的一项机制,来限制响应数量。这项机制可以通过检测入站流量的模式,来限制响应,避免对目标造成洪泛攻击。

ping联网(Internet of Ping)

ping包横行的问题亟待解决,因为此类风险正在上升。物联网的出现,让攻击者大把捞取网络摄像头和硬盘录像机(DVR)这种“哑设备”,并将它们指向中意的任何目标。这是一个“ping联网”的世界。

我们正处在用“愤怒的烤面包机军队”(指物联网设备)就能搞摊互联网的时代。鉴于物联网IP地址范围的广大,ISP想要检测和解决这一问题将更加困难。

10月的DNS提供商Dyn遭ping洪水攻击致主流网站掉线的事件,就是物联网ping洪水的真实例证。上千万IP地址发送ping包,而这还只是攻击者的预演热身,正戏会造成何种程度的网络灾难难以想象。

安全大师布鲁斯·施奈尔已经报告过有人正在试图撼动互联网的大门。“我们能对此做什么呢?什么都做不了,真的。”

好吧,还是能做点儿什么的。我们可以恳求ISP们联合起来,开始实现一些预防性技术。我们还可以鼓励物联网厂商们强化物联网设备的安全性。

“恰当的代码签名”什么的可以暂时放下,先从不使用默认登录凭证做起吧。看到Mirai这种没什么技术含量的恶意软件仅使用预置的用户名/口令列表,就拿下了半个Web,这其中必然有什么东西出了问题。

我们该怎样劝服物联网厂商做得更好呢?或许来点儿政府监管比较合适。实际上,有组织已经开始在这两方面做出努力了。

不幸的是,国家、行业政策的制订和实施会非常缓慢,而DDoS数据包则快如闪电。但是,难道不应该是号称“网络看门人”的互联网服务商自己站出来主动来解决这个问题吗?

责任编辑:未丽燕 来源: 安全牛
相关推荐

2009-11-26 09:37:04

2012-06-13 16:01:49

Passbook苹果

2018-01-05 10:47:59

前端JavascriptWeb

2015-12-11 10:27:50

易维帮助台/Helpd

2011-05-25 20:48:23

seo

2012-09-24 10:06:12

LinuxGoogle

2017-06-18 16:01:57

2017-02-27 18:20:30

Amazon持续交付

2012-07-24 09:06:07

Android诺基亚

2011-11-18 09:16:20

团队管理

2009-07-06 18:24:51

IT资产运维管理广通信达科技

2020-03-31 09:53:08

互联网数据技术

2022-04-21 14:43:59

AI数据隐私

2010-04-06 11:23:48

2019-01-24 10:36:48

2019-08-01 14:00:21

2022-05-30 08:00:00

元宇宙DevSecOps数字化

2010-10-29 18:04:14

虚拟化云计算
点赞
收藏

51CTO技术栈公众号