linux – Amplified反映了对DNS服务器的攻击

前端之家收集整理的这篇文章主要介绍了linux – Amplified反映了对DNS服务器的攻击前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
Amplified反射攻击这个词对我来说是新的,我有几个问题.

我听说它主要发生在DNS服务器上 – 这是真的吗?
你如何防范它?
你怎么知道你的服务器是否可以用于这种攻击 – 这是一个配置问题吗?

解决方法

首先,这种攻击并非(主要)针对DNS本身,如标题所示.它当然会在DNS服务器上创建一些额外的负载,但主要目的是为其他人提供DDoS.糟糕的服务器配置可能会使情况变得更糟,但最终这个问题在DNS和UDP的设计中是固有的,事实上,任何无状态通信协议都是如此.

它基本上是这样的:攻击者将普通(DNS)查询发送到(DNS)服务器.这些查询被伪造成看起来好像它们来自目标系统. DNS服务器现在回答查询,将答案发送回其所谓的来源 – 受害者.这就是为什么它被称为反射攻击.

这是可能的,因为您可以验证无状态通信的来源(如UDP上的DNS),因为您可以信任明信片上的发件人地址.服务器无法确定查询是合法的还是此类攻击的一部分. DNS只是这里最流行的协议,因为它周围有很多很多服务器,你不需要太多的技术见解或特殊设备来(错误地)使用它.

为了使事情变得更糟(并且在所有攻击效率方面),请查看放大部分.如果攻击者的流量与结果流量相等,那将不会造成太大伤害.攻击者的唯一好处是他的地址隐藏在DNS服务器后面.他可以直接伪造发件人地址,完全没有必要通过DNS重新路由.但DNS回答,这也是DNS在这里如此受欢迎的另一个问题,可能比问题大得多.您可以根据所使用的确切查询找到不同的数字,但如果服务器足够友好以便为您执行递归查询,则可以达到1:60.因此,攻击者不需要在他控制下的许多机器来产生大量恶意流量.

由于您可以在公共互联网上轻松找到成百上千的“开放式”DNS服务器,因此您可以快速计算出,如果他知道的每个开放DNS服务器将他的查询扩展到目标的六十倍,攻击者必须做多少工作.正如我在开始时所说的那样,没有很好的方法来对付这个问题.当然,由于配置错误,许多DNS服务器对所有人开放,而不应该是这样.但是有许多开放服务器必须是开放的,因为这正是他们的目的.

虽然您无法判断请求是否是攻击的一部分,但您唯一的选择是不再运行服务器.你可以摆弄速率限制和其他玩具,但你不能完全摆脱这个.如果您提供DNS以获得乐趣,则可以将请求的源IP列入黑名单.但如果你的规模较大,这将会对受害者造成更大的伤害.请记住,您在DNS服务器上看到的只是受害者的地址.想象一下,您的公司正在通过您的提供商的DNS受到攻击,您的提供商决定为您的公司削减DNS服务.攻击者可以将此作为关于拒绝服务的巨额奖励积分.

无论如何,这些攻击都是白天和黑夜发生的,它们被认为是互联网的“背景噪音”.如果您设置公共(递归)DNS服务器,则在您参与随机攻击之前不会花很长时间.当然,当大型基础设施(甚至是dns根服务器)被滥用而放大时,有时事情变得非常糟糕,但在这些情况下,人员会采取主动对策,直到攻击降至“正常”水平.

到目前为止在教学上.最后回答你的问题:

您知道如果服务器无限制地回答查询,那么您的服期.如果您正在提供递归查询,则您的服务器可以为攻击者生成提到的1:60比率.如果它只提供非递归服务,它不会那么糟糕,但仍然……

所以…

>确保您确实需要运行公共DNS服务器
>如果必须,请查看BIND的allow-recursion和allow-query指令
>如果您的DNS服务器对您自己的区域具有权威性,则根本不需要递归,将allow-recursion设置为“none;”
>如果要为其他域运行解析程序,请限制允许的用户进行查询和递归查询.您可以在上述指令中定义IP地址,网络或访问列表
>考虑不仅在BIND中而且在系统级别上限制DNS流量的速率.作为一个非常简单的示例,这些iptables规则不允许每个IP地址每分钟超过10个查询

.

iptables -A INPUT -p udp --dport 53 --set --name dnslimit
iptables -A INPUT -p udp --dport 53 -m recent --update --seconds 60 --hitcount 11 --name dnslimit -j DROP

现在,考虑到这些要点,你应该好好去.您的服务器现在可能仍然存在恶意流量,但数量不足以让您睡个好觉.

猜你在找的Linux相关文章