回答:
まず、この種の攻撃は、タイトルが示すように(主に)DNS自体を標的とするものではありません。もちろん、DNSサーバーに追加の負荷がかかりますが、主な目的は他の誰かにDDoSをかけることです。サーバーの構成が悪いと悪化する可能性がありますが、最終的にこの問題はDNSおよびUDPの設計に固有のものであり、実際にはステートレス通信プロトコルに固有のものです。
基本的には次のように機能します。攻撃者は通常の(DNS)クエリを(DNS)サーバーに送信します。これらのクエリは、ターゲットシステムから発信されているかのように偽造されます。これで、DNSサーバーはクエリに応答し、その発信元と呼ばれる被害者に応答を送り返します。これがリフレクション攻撃と呼ばれる理由です。
これが可能なのは、ハガキの送信者アドレスを信頼できる限り、ステートレス通信のソースを(UDP上のDNSとして)検証できるためです。サーバーには、クエリが正当な攻撃なのか、そのような攻撃の一部なのかを判断する方法がありません。DNSはここで最もポピュラーなプロトコルです。なぜなら、DNSにはたくさんのサーバーがあり、それを(誤)使用するために多くの技術的な洞察や特別な機器を必要としないからです。
事態を悪化させる(そして攻撃効率を高める)には、増幅部分を見てください。攻撃者のトラフィックのサイズが結果のトラフィックと同じであれば、それほど害はありません。攻撃者にとっての唯一の利点は、DNSサーバーの背後にアドレスが隠されることです。彼は直接送信者アドレスを偽造することができ、DNSを介して再ルーティングする必要はまったくありません。しかし、DNSの答えは、それがDNSがここで非常に人気がある理由の1つであり、質問よりもはるかに大きくなる可能性があります。使用されている正確なクエリに応じてさまざまな数値を見つけることができますが、サーバーが再帰クエリを実行するのに十分なほど友好的であれば、最大で1:60になりますあなたのために。そのため、攻撃者は多くの悪意のあるトラフィックを生成するために自分の制御下にある多くのマシンを必要としません。
パブリックインターネット上で何百、何千もの「オープン」DNSサーバーを簡単に見つけることができるため、攻撃者が知っている各オープンDNSサーバーが60倍に増幅されたクエリをターゲットに反映する場合、攻撃者はほとんど作業をしなくても簡単に計算できます。最初に言ったように、これに対抗する本当に良い方法はありません。当然のことながら、多くのDNSサーバーは、設定ミスのために、すべてのユーザーに公開されているべきではありません。しかし、オープンである必要があるのと同じくらい多くのオープンサーバーがあります。まさにそれが彼らの目的だからです。
要求が攻撃の一部であるかどうかを判断することはできませんが、唯一の選択肢はサーバーを実行しないことです。レート制限やその他のおもちゃをいじることはできますが、これを完全になくすことはできません。楽しみのためにDNSを提供している場合、リクエストのソースIPをブラックリストに登録できます。しかし、大規模な場合、これは被害者にさらに損害を与えます。DNSサーバーで確認できるのは、被害者のアドレスだけです。会社がプロバイダーのDNSを介して攻撃を受けており、プロバイダーが会社のDNSサービスを切断することを決定したとします。攻撃者は、これをサービス拒否に関する膨大なボーナスポイントとして記録することができます。
とにかく、これらの攻撃は昼夜を問わず発生し、インターネットの「バックグラウンドノイズ」と見なされます。パブリック(再帰的)DNSサーバーをセットアップすると、ランダム攻撃に参加するまでに時間がかかりません。もちろん、大規模なインフラストラクチャ(DNSルートサーバーなど)が悪用されて悪用されると事態が悪化することもありますが、その場合、攻撃が「通常」レベルに下がるまで担当者が事前対策を講じます。
これまでの教育について。質問に答えるために、ついに:
サーバーが制限なくクエリに応答する場合、サーバーは脆弱であることがわかります。限目。再帰クエリを処理している場合、サーバーは攻撃者に対して前述の1:60の比率を生成できます。それが非再帰的にのみ提供されている場合、それほど悪くはありませんが、それでも...
そう...
allow-recursion
とallow-query
ディレクティブを見てくださいallow-recursion
「none」に設定された再帰の必要はまったくありません。。
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
さて、これらの点を念頭に置いて、あなたは行くのが良いはずです。サーバーに悪意のあるトラフィックがまだ残っている場合がありますが、十分な睡眠をとる量ではありません。