DNSアンプ攻撃対策の基本。踏み台にされないために見直したいポイント

DNSアンプ攻撃対策は、DDoS対策の中でも基本として押さえておきたいテーマです。
この攻撃は、外部から再帰問い合わせを受け付けるオープンリゾルバーを悪用し、小さな問い合わせから大きな応答を引き出して、被害者へ大量の通信を送りつける手法として知られています。
Cloudflareは、DNS amplification DDoS attackを、反射型かつ増幅型のDDoS攻撃だと説明しています。
つまり、攻撃者自身が大きな帯域を持っていなくても、公開されたDNSリゾルバーを踏み台にすることで、被害を大きくしやすい攻撃です。

この攻撃が厄介なのは、自社が直接狙われる場合だけではなく、自社のDNSサーバーやネットワーク機器が第三者への攻撃に悪用される可能性もあることです。
DDoS対策では、被害を受ける側の備えだけでなく、自組織の機器が踏み台として悪用されないようにする視点も重要です。
そのため、DNSアンプ攻撃対策は、自社防衛と踏み台防止の両方から考える必要があります。

この記事では、DNSアンプ攻撃の仕組みから、なぜ成立するのか、優先して行いたい対策、運用時の注意点までを順に整理します。
DNS水責め攻撃のような別のDNS攻撃と混同しないように、増幅型攻撃としての特徴に絞ってまとめます。

DNSアンプ攻撃とは何か

オープンDNSリゾルバーの大きな応答を悪用して被害者へ通信を集中させる攻撃

DNSアンプ攻撃とは、オープンDNSリゾルバーに対して、送信元IPアドレスを被害者のものへ偽装した問い合わせを送り、その応答を被害者へ集中させるDDoS攻撃です。
Cloudflareは、この攻撃を、オープンDNSリゾルバーの機能を利用して、ターゲットのサーバーやネットワークを増幅されたトラフィックで圧倒する攻撃だと説明しています。
つまり、攻撃者はDNSの正規の応答機能そのものを悪用して、被害者へ大量のUDP通信を送りつけます。

この攻撃が成立しやすい背景には、DNSがUDPを使うことと、問い合わせ内容やレコード種別によって、応答が問い合わせより大きくなることがあることがあります。
小さな要求に対して大きな応答が返るほど、攻撃時の増幅効果が大きくなります。
そのため、外部から誰でも再帰問い合わせできるDNSリゾルバーが公開されたままだと、反射板として悪用されやすくなります。
DNSアンプ攻撃で本当に問題になるのは、DNSを使っていること自体ではなく、外部へ無制限に再帰応答する状態を残してしまうことです。

権威DNSと再帰DNSを分けて考える必要がある

DNSアンプ攻撃を理解するうえでは、権威DNSと再帰DNSの役割を分けて考えることが大切です。
JPNICは、オープンリゾルバーを、外部の不特定のIPアドレスからの再帰的な問い合わせを許可しているDNSサーバーと説明しています。
この説明からわかるのは、アンプ攻撃で主に悪用されるのは、公開が必要な権威DNSではなく、外部から自由に再帰問い合わせできるリゾルバーだという点です。

公開ドメインを管理する権威DNSは、通常、インターネット上から問い合わせを受ける必要があります。
一方で、再帰DNSは通常、内部利用や限定利用を前提にすべきものです。
この区別が曖昧だと、公開が必要なDNSまで止めてしまったり、逆に再帰機能を外部へ開いたままにしてしまったりしやすくなります。
DNSアンプ攻撃対策では、どのサーバーが権威用で、どのサーバーが再帰用なのかを明確にすることが出発点になります。

DNSアンプ攻撃対策で優先したい基本施策

オープンリゾルバーを残さない

DNSアンプ攻撃対策で最優先になるのが、オープンリゾルバーを残さないことです。
JPNICは、オープンリゾルバーとなっているサーバーやネットワーク機器は、DDoS攻撃の踏み台になってしまうおそれがあるため、対策が必要だと注意喚起しています。
Cloudflareも、DNS amplification DDoS attackは外部から再帰問い合わせを受け付けるオープンリゾルバーを悪用して成り立つと説明しています。
このことからも、再帰問い合わせを外部へ広く開いたままにしないことが基本だとわかります。

外部公開の再帰問い合わせを許可したままにしている。
ブロードバンドルーターなどのネットワーク機器に組み込まれたリゾルバーが、意図せず外部から利用可能になっている。
こうした状態では、管理者が意識していないサーバーやルーターが反射板になることがあります。
そのため、再帰問い合わせを許可する対象を内部利用に限定し、外部からの不特定アクセスを閉じることが基本です。

送信元IPアドレス偽装を通しにくいネットワーク運用を行う

DNSアンプ攻撃は、送信元IPアドレスを被害者のものに偽装した問い合わせを、オープンリゾルバーへ送ることで成立します。
Cloudflareは、攻撃者がオープンDNSリゾルバーへ、被害者のIPアドレスに偽装したリクエストを送り、被害者が応答を受け取る仕組みを説明しています。
APNICのSAVE factsheetも、DNS reflection and amplification attacksは偽装IPアドレスを使うことで成り立つとして、BCP 38による送信元アドレス検証を対策として挙げています。

言い換えると、オープンリゾルバー対策に加えて、送信元IPアドレス偽装を通しにくくする対策も重要です。
自組織のネットワークから偽装パケットを外へ出さないことも重要です。
IIJの資料でも、アドレス詐称パケットの流出防止が有効だと示されています。
DNSアンプ攻撃対策では、DNSサーバー設定とネットワーク出口対策を切り離さずに考える必要があります。

DNSサーバーだけでなくルーターや組み込み機器も確認する

DNSアンプ攻撃対策では、専用のDNSサーバーだけを確認して終わらせないことも重要です。
JPCERT/CCは、オープンリゾルバーはDNSサーバーの設定不備によるものだけでなく、ブロードバンドルーターなどのネットワーク機器に組み込まれているリゾルバーが、意図せずインターネットからアクセス可能になっているケースもあると案内しています。
JPNICも、本来はDNSサーバーを意図したものではないにもかかわらず、デフォルト設定のままなどの理由で応答機能が有効になっている場合があると説明しています。

そのため、LinuxやWindowsのDNSサーバーだけを見れば十分とは言えません。
ルーター。
ファイアウォール。
小型のネットワーク機器。
組み込み型のDNS機能を持つ装置。
こうした周辺機器まで含めて、外部から再帰問い合わせできる状態になっていないかを確認する必要があります。
踏み台は、目立つサーバーより、見落とされやすい機器に残ることがあります。

被害を受ける側としてのDDoS耐性も整える

DNSアンプ攻撃対策は、自社が踏み台にならないことだけでは終わりません。
自社が攻撃対象になった場合に備える視点も必要です。
IPAの情報セキュリティ白書では、DDoS対策は被害者側の備えだけでなく、加害側に加担しないための対応も重要だと整理されています。
Cloudflareも、増幅攻撃は被害者側へ大量の応答が集中することで、サーバーや周辺機器が過負荷状態になると説明しています。

そのため、公開サービスの前段でDDoS保護を受けられる構成にする。
回線や機器の負荷状況を監視する。
権威DNSや公開サービスを単一構成にしない。
こうした耐性強化も検討する必要があります。
DNSアンプ攻撃対策で重要なのは、自組織が踏み台にならないことと同時に、攻撃を受けたときに止まりにくい構成を整えることです。

DNSアンプ攻撃対策を進めるときの注意点

DNSを使っていること自体を問題にしない

DNSアンプ攻撃対策というと、DNSサービスそのものを危険視してしまうことがあります。
ただ、見直すべきなのはDNSの存在そのものではありません。
Cloudflareは、この攻撃が外部から再帰問い合わせを受け付けるオープンリゾルバーを悪用して成立すると説明しています。
JPNICも、外部の不特定IPアドレスから再帰問い合わせを許可しているDNSサーバーが、踏み台として悪用されるおそれがあると案内しています。

社内向けの名前解決は多くの環境で必要です。
そのため、DNSを止める発想ではなく、誰に対して再帰問い合わせを許可するのかを明確にし、不要な外部公開をなくす考え方が現実的です。
必要な機能と、外へ開いてはいけない機能を分けて考えることが重要です。

権威DNSと再帰DNSを混同しない

DNSアンプ攻撃対策を進めるときは、権威DNSと再帰DNSの役割を混同しないことも大切です。
DNSアンプ攻撃で主に悪用されるのは、外部から再帰問い合わせできるオープンリゾルバーです。
そのため、権威DNSの公開と、再帰DNSの公開は同じ意味ではありません。
役割が曖昧なままだと、公開が必要なDNSまで止めてしまったり、逆に再帰機能を残したままにしたりしやすくなります。

DNSアンプ攻撃対策では、どのサーバーが権威用で、どのサーバーが再帰用なのかを明確にしてから見直す必要があります。
設定の意味を整理せずに操作すると、対策したつもりで別の穴を残すこともあります。

一度対策して終わりにしない

DNSアンプ攻撃対策は、一回設定を閉じたら終わりというものではありません。
機器の入れ替え、ファームウェア更新、DNS設定変更、拠点追加などがあるたびに、意図せず公開状態が変わることがあります。
JPNICは、オープンリゾルバーとなっているサーバーやネットワーク機器は対策が必要だと継続的に注意喚起しています。
IIJの資料でも、アドレス詐称パケットの流出防止や設定確認の重要性が示されています。

新しい機器を導入したときに再帰機能が有効のままになっている。
保守作業で設定が戻る。
公開範囲の変更で外部から名前解決できる状態になる。
こうしたことは現実に起こり得ます。
DNSアンプ攻撃対策で大切なのは、一度閉じた設定を安心材料にすることではなく、構成の変化に合わせて継続的に確認することです。

まとめ

DNSアンプ攻撃対策はオープンリゾルバーを残さないことが基本

DNSアンプ攻撃は、オープンDNSリゾルバーに対して、送信元IPアドレスを被害者のものへ偽装した問い合わせを送り、その応答を被害者へ集中させるDDoS攻撃です。
Cloudflareは、この攻撃を反射型かつ増幅型のDDoS攻撃だと説明しています。
JPNICも、外部の不特定IPアドレスからの再帰問い合わせを許可しているオープンリゾルバーは、DDoS攻撃の踏み台になり得ると案内しています。
つまり、この攻撃の本質は、DNSを使っていることではなく、外部へ無制限に再帰応答する状態を残してしまうことにあります。

対策として最優先したいのは、オープンリゾルバーを残さないことです。
再帰問い合わせを許可する対象を内部利用に限定し、外部からの不特定アクセスを閉じる必要があります。
あわせて、送信元IPアドレス偽装を通しにくいネットワーク運用も重要です。
APNICは、DNS reflection and amplification attacksへの対策として、BCP 38による送信元アドレス検証を挙げています。
そのため、DNSサーバー設定だけでなく、ネットワーク出口対策まで含めて見直す必要があります。

また、確認対象は専用のDNSサーバーだけではありません。
JPCERT/CCは、ブロードバンドルーターなどのネットワーク機器に組み込まれたリゾルバーが、意図せずインターネットからアクセス可能になっているケースがあると案内しています。
JPNICも、本来はDNSサーバー用途を想定していない機器でも、デフォルト設定などの理由で応答機能が有効になっている場合があると説明しています。
このことからも、DNSアンプ攻撃対策では、サーバー、ルーター、ファイアウォール、小型機器まで含めて、外部から再帰問い合わせできる状態になっていないかを確認することが大切です。

さらに、DNSアンプ攻撃対策は、自組織が踏み台にならないことだけでは終わりません。
DDoS対策では、被害を受ける側の備えだけでなく、自組織のサーバーやネットワーク機器が攻撃の踏み台にならないようにする視点も重要です。
そのため、公開サービスの前段でDDoS保護を受けられる構成にすることや、公開サービスを単一構成にしないことも有効です。
自社防衛と踏み台防止の両方から考えることが重要です。

DNSアンプ攻撃対策で本当に重要なのは、DNSを危険なものとして止めることではありません。
オープンリゾルバーを残さないことです。
送信元IPアドレス偽装を通しにくくすることです。
サーバーだけでなく周辺機器まで確認することです。
そして、一度対策して終わりにせず、構成の変化に合わせて継続的に見直すことです。
そうした積み重ねが、現実的で効果のあるDNSアンプ攻撃対策につながります。