主页 / server / 问题 / 1049513
Accepted
gooleem
Asked: 2021-01-13 02:25:15 +0800 CST

绑定：查询（缓存）'./ANY/IN' 被拒绝 - 是 DDos 攻击吗？

  • 772

我的系统日志中充斥着类似的消息

Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied

而且我不知道这是 DDoS 攻击还是只是奇怪的绑定行为。

所以我建立了一个简单的fail2ban监狱，它可以阻止在24小时内产生超过20个此类错误的IP。周末后，我检查并感到惊讶：超过 1000 个 IP 已被阻止。包括像1.1.1.1这样的著名的。所以这是不对的。

我的服务器是通过 Plesk Obsidian 管理的 Debian 9。我没有对 bind9/named 进行特殊配置（据我所知）。它是我所有域的主要 ns 服务器。

所以问题是：我能做些什么来保护我的服务器免受如此大量的 dns 查询的影响，或者我应该忽略它们。

domain-name-system bind named-conf

1 个回答

  1. Best Answer

    很难确切地说，但乍一看，这可能是一次尝试性的反射攻击（或测试在此类攻击中使用您的服务器的可行性）。

    这种攻击背后的想法是通过 UDP 向开放的解析器服务器发送带有欺骗源 IP 地址的查询，以生成到攻击目标（实际具有欺骗源 IP 的主机）的流量，使用已知的查询生成大响应以获得发送查询所需的攻击者带宽的高放大。

    假设是这种情况，其含义是：

    • 您不是真正的目标，而只是为了“借出”您的带宽。源地址是据称受到攻击的人（或正在检查您的服务器是否可用于此类目的的人）。
    • 它实际上没有用。当您拒绝这些请求时，响应并不像实际响应那样大. ANY。（大概是从一开始就不允许递归，这很好）。

    关于您认为它似乎是合法的，因为其中一个源 IP 地址是1.1.1.1，我想说我的本能反应是完全相反的。看到1.1.1.1这个查询的源地址立即表明发生了一些奇怪的事情：

    • 我们知道这1.1.1.1是任播，这使得从该地址发起查询是一个糟糕的主意。如果您从1.1.1.1您的响应中响应查询将被路由到最近的（在 BGP 意义上）1.1.1.1实例，而不是生成查询的实例。
    • 即使忽略源地址的选择，为什么 Cloudflare 公共解析器会向您的服务器发送查询. ANY？您不是授权者.，他们也没有理由将查询转发给您。

    也就是说，我认为您是正确的，这些查询可能“没有好处”。
    现在，阻止来自这些地址的流量是否是个好主意，我不太确定。这里的问题是它为简单的 DoS 攻击打开了大门。有人可以使用您的这种阻止行为使您的服务器停止响应来自任意地址的查询，这可能被滥用以拒绝合法流量。

    • 3

相关问题