☰

バインド: クエリ (キャッシュ) './ANY/IN' が拒否されました - これは DDos 攻撃ですか?

tag-icon • tag-icon domain-name-system bind named-conf
バインド: クエリ (キャッシュ) './ANY/IN' が拒否されました - これは DDos 攻撃ですか?

私のsyslogには次のようなメッセージが流れています

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 攻撃なのか、単に bind の奇妙な動作なのかはわかりません。

そこで、24 時間以内に 20 件を超えるエラーを生成する IP をブロックする単純な fail2ban jail を設定しました。週末が終わって確認してみると、1000 件を超える IP がブロックされていたことに驚きました。1.1.1.1 などの有名な IP も含まれています。これは正しくありません。

私のサーバーは、Plesk Obsidian で管理されている Debian 9 です。bind9/named に特別な構成は行っていません (私の知る限り)。これは、すべてのドメインのプライマリ ns サーバーです。

そこで質問です。このような大量の DNS クエリからサーバーを保護するにはどうすればいいのでしょうか。それとも、単に無視するべきでしょうか。

答え1

断言するのは難しいですが、一見すると、リフレクション攻撃の試み（または、そのような攻撃にサーバーを使用することの実現可能性のテスト）であるように見えます。

このような攻撃の背後にある考え方は、偽装された送信元 IP アドレスを使用して UDP 経由でオープン リゾルバ サーバーにクエリを送信し、攻撃対象 (実際に偽装された送信元 IP を持つホスト) へのトラフィックを生成することです。このとき、大きな応答を生成することが知られているクエリを使用して、クエリの送信に必要な攻撃者の帯域幅を大幅に増幅します。

それが事実であると仮定すると、次のようになります。

  • あなたは実際のターゲットではなく、単にあなたの帯域幅を「貸し出す」ことを意図しています。送信元アドレスは、攻撃を受けていると思われる人 (または、あなたのサーバーがそのような目的に使用できるかどうかを調べている人) です。
  • 実際には機能しませんでした。これらのリクエストを拒否しているため、応答は実際の応答ほど大きくありません. ANY。(おそらく、そもそも再帰を許可していないため、これは良いことです)。

ソース IP アドレスの 1 つが であるため、正当なものであると思われるというあなたの感覚については1.1.1.1、私の本能的な反応は正反対であると言えます。1.1.1.1このクエリのソース アドレスが であることから、何か奇妙なことが起こっていることがすぐにわかります。

  • これはエニーキャストであることはわかっています1.1.1.1。そのため、このアドレスからクエリを開始するのはお勧めできません。このアドレスからのクエリに応答すると、その応答はクエリを生成したインスタンスではなく、1.1.1.1最も近い (BGP の意味で) インスタンスにルーティングされます。1.1.1.1
  • 送信元アドレスの選択を無視したとしても、なぜ Cloudflare パブリック リゾルバが のクエリをお客様のサーバーに送信するのでしょうか. ANY? お客様は の権限を持っておらず.、Cloudflare パブリック リゾルバもお客様にクエリを転送する理由がありません。

つまり、これらのクエリはおそらく「悪意がある」というあなたの意見は正しいと思います。
さて、これらのアドレスからのトラフィックをブロックすることが良い考えであるかどうかは、私にはよくわかりません。ここでの問題は、それが簡単に DoS 攻撃を受けてしまうことです。誰かがあなたのこのブロック動作を利用して、任意のアドレスからのクエリに対するサーバの応答を停止させ、正当なトラフィックを拒否するために悪用される可能性があります。

関連情報