DNSリバインディング攻撃: 悪意のあるWebサイトがプライベートネットワークを悪用する方法

This post is also available in: English (英語)

概要

Webベースのコンソールが管理用のソフトウェアやスマートデバイスに広く使われるようになったおかげで、データをインタラクティブに可視化したり、設定をユーザーフレンドリーに行えるようになりました。こうした流れは企業コンピュータシステムの複雑化や家庭用最新IoTデバイス（Internet of Things モノのインターネット）の利用数増加につれて勢いを増しています。こうしたWebアプリケーションはふつう、ファイアウォールで保護された環境の内側やプライベートネットワーク内に設置されていますから、その利用者に対しては高い信頼度が設定される傾向があります。また、それらの製品は利用者がすべて認証済みであることを前提としているので、機微な情報の開示や管理者権限の付与にさいしても、アプリケーションレベルでは強力な保護を提供していないケースが多々あります。

「プライベートネットワーク内のWebサービスはインターネットから隔離されているから同一オリジンポリシーにより任意のWebサイトが内部のサーバーとやりとりすることはない」とされてはいますが、「DNSリバインディング」と呼ばれるテクニックでドメインネームシステム（DNS）を悪用すれば、Webベースのコンソールを使って内部ネットワークをエクスプロイトすることは可能です。このテクニックを使うと、被害者のブラウザで内部Webアプリケーションが起動されれば、悪意のあるWebサイトに対し、それらアプリケーションが持つ攻撃対象領域を露出させることができます。

本稿では、DNSリバインディング攻撃のメカニズムとその深刻さを、侵入事例を交えてご紹介します。その後、この攻撃に対する主な緩和策とその限界について解説します。

パロアルトネットワークスでは、弊社のDNSセキュリティとパッシブDNSのデータから、こうしたDNSリバインディング攻撃を検出する検出器をローンチしました。本システムはさまざまなDNSリバインディングペイロードに対してスケーラブルな検知機能を提供し、従来のIPフィルタリングソリューションとの比較で誤検知率を85.09%低減しています。本システムはDNSデータをリアルタイムに取り込むことで侵入行為をいち早く特定しています。

パロアルトネットワークスの次世代ファイアウォールのお客様で、DNS セキュリティ、URL フィルタリング、脅威防御のセキュリティサブスクリプションをお持ちの方は、DNSリバインディング攻撃から保護されています。

DNSリバインディングの仕組み

任意のクロスオリジンリクエストの許可が非常に危険なことはわかっているので、最新ブラウザのほとんどはこうしたリクエストをブロックします。ですがDNSリバインディングによりこの制限を回避することが可能です。ここでは、同一オリジンポリシーの重要性と、DNSリバインディングテクニックの仕組みをご紹介します。

同一オリジンポリシー

通常、WebアプリケーションがWebページをレンダリングするには、JavaScriptや画像、CSSなどのさまざまなリソースを必要とします。あるWebページは、これらのリソースを自身と同一のサーバーから取得することもできますし、異なるオリジンからも取得できます。クロスオリジンでリソースを要求できれば、アプリケーションはサードパーティのスクリプトライブラリなどの共有リソースからの恩恵を受けることができます。ところが、あるWebサイトから任意のオリジンのリソースにアクセスできるようにしてしまうと、深刻な事態を招きます。アクセス制御を行わなければ、悪意のあるWebページが正当なユーザーに与えられた信頼を悪用し、その人になりかわって重要なWebアプリケーションに不正なリクエストを送信できてしまいます。この悪用は「クロスサイトリクエストフォージェリ（CSRF）」という名前で知られています。

最近のブラウザであれば、このCSRFからの脅威を緩和するために「同一オリジンポリシー」をとっています。このポリシーはスクリプトに「オリジンの異なるWebリソースへのアクセスをを禁止」するもので、WebページはHTMLタグ内にクロスオリジンのリソースを読み込むことはできますが（たとえばサードパーティの広告を表示するiframeを埋め込むことができる）悪意のあるWebサイトがスクリプトによるクロスオリジンリクエストのレスポンスの内容を読み取ることはできなくなります。

DNSリバインディング

「同一オリジンポリシー」で異なるオリジンを識別するには、URIスキーム、ホスト名、ポートの組み合わせを利用します。ブラウザはこれらのコンポーネントのなかからホスト名を使ってインターネット上の異なるサーバーを識別しています。ただ、このホスト名はネットワーク機器に直接バインドされているわけではなくDNSによってIPアドレスに解決されているものですし、IPアドレスも静的ないし動的にこれらの機器にバインドされています。またドメイン所有者であればDNSレコードを自分の好きなように設定できますから、ホスト名を任意のIPアドレスに解決することも可能です。「DNSリバインディング」はこうした特権を悪用する攻撃で、被害者のブラウザが攻撃者のサーバーから攻撃用ペイロードを読み込んだら、ホスト名を標的のサーバーを指す内部IPアドレスにバインドしなおし（=リバインディング）ます。これにより、攻撃者のスクリプトは同一オリジンポリシーに違反することなく、悪意のあるホスト名を使ってプライベートリソースにアクセスできるようになります。

図1は、DNSリバインディング攻撃の仕組みを仮想的な例で示したものです。この例では、被害者のAlexが内部ネットワークにIPアドレス192[.]0.0.1でプライベートWebサービスを立てています。このサーバーには機密データが入っていて、Alexのコンピュータからしかアクセスできないことになっています。攻撃側のBobはDNSリゾルバ（1[.]2.3.4）と悪意のあるWebサイトをホストするWebサーバー（5[.]6.7.8）という2つのサーバーをコントロールしています。さらにBobはattack[.]comというドメインを登録し、ネームサーバー（NS）のそのレコードを1[.]2.3.4に向けています。

Alexがブラウザでattack[.]comを開くと、BobのリゾルバにDNSリクエストが送信され、悪意のあるサーバーのアドレスである5[.]6.7.8が取得されてきます。そうしてAlexのブラウザに読み込まれると、BobのWebサイトの悪意のあるスクリプトが自身のドメインに対して再度DNS名前解決を行おうとします。ただし今回リゾルバは192[.]0.0.1を返してきます。つまり、attack[.]comは標的のサーバーのIPアドレスに「リバインド」されています。その後、悪意のあるスクリプトがattack[.]comにリクエストを送り続け、最終的にプライベートサーバーに到達します。Alexのブラウザはこれらのリクエストをクロスオリジンとは認識しないので、悪意のあるWebサイトが被害者のブラウザ上で開かれている間は、返された秘密を読み取り、窃取したデータを流出させることができます。

実世界の攻撃におけるDNSリバインディング

DNSのリバインディングを利用することで、攻撃者は被害者のブラウザをプロキシとして悪用し、攻撃対象をプライベートネットワークへと拡大することができます。このテクニックを使うことで、企業や家庭のネットワーク上で立ち上げられているWebアプリケーションが増えるにつれ、攻撃者にさらされる潜在的脆弱性も著しく増加します。くわえて、社内サービスではデフォルトの信頼が高く設定されることが多いので、さまざまな侵入テクニックと脆弱性エクスプロイトを組み合わせた実世界の攻撃で、DNSリバインディングは非常に重要な役割を果たしうるのです。以下のセクションでは、オープンソースDNSリバインディングプラットフォームのSingularityを使って、実際の侵入においてこのテクニックがどのように利用されているのかを示していきます。

DNSリバインディングによるプライベートネットワークへの侵入

DNSリバインディング攻撃の最初のステップは他のWebベースの攻撃と同じで、フィッシングメールの送信やサイバースクワッティングなど、さまざまなソーシャルエンジニアリングの手法で被害者を騙し、悪意のあるWebサイトを開かせることです。

攻撃者は、被害者のブラウザで悪意のあるWebサイトを開いたら、まずは脆弱なサービスをホストしているプライベートIPアドレスとポートを特定し、その後でDNSリバインディング攻撃を実行する必要があります。攻撃側のWebサイトは、WebRTCテクニックを使ってローカルネットワーク上でオープンになっているWebサービスをスキャンできます。Singularityでは、クロスオリジンのリクエストを直接送信し、エラーメッセージを受信するまでの時間を計測するという、よりわかりやすい戦略を採用しています。要求されたサーバーが存在する場合、例外発生までの時間は短くなります。図2は、私たちの検証環境をスキャンしたときのSingularityのパフォーマンスを示しています。Singularityは10[.]0.0.6:80と10[.]0.0.6:8080にホストされている内部サービスをものの数秒で洗い出しています。このステップはDNSリバインディングに使えるターゲットを露出させるものです。攻撃者は開いているポートからこれらのIPアドレスの背後にどのようなWebアプリケーションがあり、そのアプリケーションが脆弱であるかどうかを推測することもできます。

攻撃者のWebサイトは、対象となるサービスを探し出した後、そのiframe内でDNSリバインディング攻撃を行うことができます。最初のリクエストは、悪意のあるホスト名からリバインディングのペイロードを取得します。この攻撃スクリプトは、ターゲットのIPアドレスにリバインドするまで、ホスト名の解決を繰り返し実行します。そうすることで被害者に気づかれずにiframeは内部サービスと通信を続けられます。

実際の攻撃では、DNSリバインディングの潜在的ターゲットの1つとして、HTTPベースのコンソールを持つネットワークインフラ機器が挙げられます。たとえば、個人向けルーターが攻撃に対して脆弱である可能性があります。こうしたルーターの多くはデフォルトのパスワードや弱いパスワードが設定されています。つまり、侵入者がIPアドレスを推測するのは容易で、そうして推測したIPに悪意のあるホストネームをリバインドすることができます。攻撃者は、ネットワークの設定パネルに侵入後、被害者のネットワーク内のネットワークパッケージをスニッフィングしたり、DOS（サービス拒否）攻撃を行ったり、トラフィックをハイジャックしたりすることができます。

また最近では家庭やオフィスに普及しているスマートデバイスからの脅威もあります。Webベースのコンソール以外にも、DNSリバインディングでは、最新のIoTデバイスが内部ネットワークに露出させている他のRESTful APIやユニバーサルプラグアンドプレイプロトコル（UPnP）サーバーも対象にすることができます。これらのAPIは、機能の実装やメンテナンスのために予約されていますが、なかにはDNSリバインディングに対する保護が十分でないものもあります。攻撃者が被害者のブラウザを侵害し、ホスト名をターゲットのIPアドレスにリバインドすると、これらのサービスは、侵害されたブラウザに対して、ネットワークスキャンやセンサーデータの流出、認証不要のリモートコントロールなど、一定の権限を与えてしまいます。DNSリバインディング脆弱性は、Google Home、Sono WiFi Speaker、Rokuなど、知名度の高い企業の複数のスマートデバイスでも見つかっています。図3に示すように、2015年以降、DNSリバインディングに関連するCVEレコードは毎年少なくとも1件は発生しています。関連CVE数は2018年から大幅に増加しています。

企業にとって社内管理用のWebアプリケーションは重要です。そうしたアプリケーションには機密情報がホストされており、そこで管理者がシステムを管理できるようにしています。そのため、企業ネットワークのマシン上でDNSリバインディングが行われたWebサイトが実行されているのは非常に危険です。

ここでそのリスクを説明するため、弊社検証環境でDNSリバインディング攻撃を行ってみます。対象となる社内Webアプリケーションは、Hadoopの社内Webインターフェイスです。図4aに示すように、被害者はURL10[.]0.0.6:8088/clusterでこのUIにアクセスすれば、外部からは利用できないクラスタの状態を確認することができます。図4bは、攻撃者のWebサイトが被害者のブラウザでトリガーしたリバインディング要求を示しています。この検証では、悪意のあるホスト名をs-54.183.63.248-10.0.0.6-1609933722-fs-e.dynamic.dns-rebinding-attack[.]comとしています。ホスト名に対するHTTPリクエストは、実際に10[.]0.0.6に送信され、successfulステータスコードを受信しました。この後は、被害者のブラウザをトンネルとして利用し、攻撃者はターゲットのサービスと直接やりとりすることができます。図4cに示すように、攻撃者は、被害者がHadoopクラスタからアクセスできるのと同じ情報を、悪意のあるドメインを通じて取得することができます。攻撃者は、情報を窃取するだけでなく、管理ページで実行中のジョブを終了させる権限も持ちます。今回のHadoopの例で見たように、広く利用されている開発・管理プラットフォームの多くは、きちんと保護されていなければ、DNSリバインディングによって攻撃者に露出させられてしまう可能性があります。

CSRF保護をバイパスする

悪意のあるWebサイトは、攻撃者に向けて単にトラフィックをトンネリングするだけでなく、DNSリバインディングテクニックを利用してトークンベースのCSRF保護を回避することができます。DNSリバインディングがクロスオリジンのトラフィックを隠蔽するのに対し、CSRFはクロスオリジンのリクエストを直接送信することでターゲットサーバーの被害者に対する信頼を悪用します。CSRFはよく知られた脅威であり、多くのWebアプリケーションがこの脅威に対する防御策を実装しています。主流となっている保護戦略の1つは最初の応答ページに固有のトークンを埋め込むものです。その後に続くすべてのリクエストがこのトークンを使用して送信されていなければサーバーに受け入れられません。この戦略は、悪意のあるWebサイトがクロスオリジンリクエストのレスポンスコンテンツを読み取ることを防止する同一オリジンの制限に基づいて行われているものです。つまり、攻撃者はレスポンスからトークンを取得できないので、有効なクロスサイトリクエストを送信するチャンスがないのです。

ところがDNSリバインディング攻撃の場合、ブラウザはクロスオリジンのリクエストに気づけません。このため、悪意のあるスクリプトで最初のレスポンスからCSRFトークンを取得して、そのトークンでその後のリクエストを偽造できてしまいます。

私たちは、この脅威を実証するために、Singularityのリモートコマンド実行（RCE）ペイロードを検証環境で起動させました。この攻撃は、Rubyで書かれたWeb開発フレームワークであるRailsをターゲットにしています。Railsで予約されているPUT APIの1つを使うことで、要求者はサーバー上で任意のシステムコマンドを実行できます。CSRFトークンと同様に、このAPIでは、訪問者が動的なセッションID（図5の赤でマークされた文字列）を含むリクエストURLを生成する必要があり、このIDがメインページに埋め込まれます。Webアプリケーションは、その場で新しいトークンを生成し、各セッションにトークンをマッピングします。サーバーからのレスポンスを読まずに、有効なAPIエンドポイントを予測することは不可能です。ところが、SingularityのRCEペイロードはDNSリバインディングを実行すればindexページからトークンを取得できてしまいます。このデモでは、悪意のあるサイトでブラウザのコンソールに窃取されたセッションIDを表示させています。この後は、目的のURLをうまく組み立てて、脆弱なAPIを利用して、サーバー側で任意のコマンドを実行し、サーバーのターミナルに「Hello from rebinding test（リバインドテストからこんにちは）」というメッセージを表示しています。Singularityチームによる同エクスプロイトの公開後、Raislはすべての受信リクエストについてホストフィールドを検証するサーバーサイドの緩和策を実施しています。

DNSリバインディングからの保護

DNSリバインディング攻撃を緩和するために、関連するネットワークコンポーネントごとにさまざまな戦略が試みられています。このセクションでは、さまざまな防御メカニズムとその限界についてご紹介します。その後、私たちのDNSリバインディング検出器の基本的な考え方とその利点について解説します。

ブラウザベースの緩和策

ChromeやFirefoxなど最新のブラウザはDNSリバインディング攻撃を防ぐためにDNSのPinning（ピン留め）テクニックを実装しています。このテクニックでは、DNSレコードのTTL（time-to-live）値に関係なく一定期間、DNSの名前解決の結果をブラウザにキャッシュさせます。この結果、この期間内に悪意のあるWebサイトがDNSリクエストを繰り返してホスト名をリバインドさせることはできなくなります。この保護はブラウザに実装することができ、他のネットワークインフラを変更する必要がないので便利である反面、実質的にブロックが可能なのは、DNSリバインディング攻撃の従来からある実装、時間変動型攻撃のみです。時間変動型攻撃の実装では、攻撃者は悪意のあるホスト名のDNSレコードに極めて低いTTLを割り当てておきます。被害者のブラウザに読み込まれたリバインド用スクリプトは、このDNSレコードの有効期限が切れるのを待ち、そのホスト名に対するリクエストを送信し、ブラウザが再度名前解決をしてターゲットのIPアドレスが戻ってくることを期待します。このシナリオでDNSピン留めテクニックは低いTTLを無視し、2回目のリクエストにも1回目と同じ結果を使います。

ただしDNSピン留めの保護を回避する方法は複数あります。簡単な回避方法の1つは、ブラウザのキャッシュが切れるまで繰り返しリクエストを送信するよう悪意のあるスクリプトを設計することです。そうすれば悪意のあるホスト名がターゲットのIPアドレスにリバインドされ、攻撃者のWebサイトは対象サービスから期待したレスポンスを受け取ることができます。

複数Aレコード攻撃と呼ばれるより洗練された実装では、DNSのピン留めによる保護があっても、より安定的かつ効率的にDNSリバインディングを実現できます。図6は、その攻撃手順を示したものです。このケースではDNSの動作が従来型攻撃とは異なり、被害者のブラウザは悪意のあるホスト名を一度しか解決しません。ただし、攻撃者のIPアドレスとターゲットのIPアドレスの両方が返されてきます。悪意のあるスクリプトが2つ目のリクエストを送信すると、ブラウザはまずパブリックIPアドレスを試しますが、攻撃者のWebサーバーは被害者のIPアドレスを記憶していて、ファイアウォールで受信トラフィックをブロックします。このリクエスト失敗により被害者のブラウザはプライベートIPアドレスに対して通信を行なわざるを得なくなり、これによってDNSリバインディングのプロセスが完了します。

DNSベースの緩和策

もう一つのタイプの緩和策は、DNSの解決段階に焦点を当てたものです。セキュアなDNSサービスであるOpenDNSは、RFC1918（プライベート網のアドレス割当）やループバックIPアドレスに向けられたDNSレスポンスをドロップします。DnsmasqやUnboundなどのDNSキャッシングソフトウェアも、プライベートIPアドレスに対して同様のフィルタリングポリシーを実装しています。

この戦略は、一元管理型の保護ソリューションでもありますが、これにも限界があります。まず、セキュリティで保護されたDNSサービスがすべて、プライベートサービスに向けられたIPアドレスの完全リストをブロックしてきたわけではありません。たとえば、ルーティング不能なIPアドレス0[.]0.0.0は、ローカルマシンのIPアドレスを表すことができ、DNSリバインディング攻撃の対象となり得ますが、フィルタリングポリシーのなかにはこれを見落としているものがありました。プライベートIPアドレスの他にも、攻撃者はCNAMEレコードを使って内部のホストネームにリバインドすることができます。攻撃者からすれば、被害者の内部リゾルバやそのマシンにプライベートIPアドレスへの解決を任せられるということになります。そうしてたとえば悪意のあるホスト名をlocalhostにリバインドさせることができます。これにより後に続くすべてのトラフィックがローカルサービスに到達します。要するにIPベースのフィルタリングでは保護しきれないDNSリバインディング攻撃が存在するということです。

さらに、すべてのプライベートIPアドレスをフィルタリングしてしまうと、多くの場合、ブロックの誤検知を引き起こしかねません。私たちは正当なサービスのなかにもDNSリバインディングに似た振る舞いのDNS名前解決を行うものがあることを確認しています。たとえばIoTサービスのなかにはプライベートネットワーク内でトラフィックの向かう先を判別する用途でホスト名を使うものがあります。この場合、そうしたホスト名は内部のIPアドレスにのみ解決されることになるため、IPベースの保護ソリューションでは誤ってブロックされてしまいかねません。また正当なホスト名のなかにもパブリックとプライベートの両方のIPアドレスに解決するものがあって、それらはこの保護ポリシーに違反することになります。たとえば、公共サービスでは、継続的な開発やトラフィックの最適化のために、保守管理者のネットワークにミラーサーバーを設置することがありますが、これらのホスト名には、パブリックIPアドレスとプライベートIPアドレスに向けられたパブリックAレコードを持っています。この場合、保守管理者は内部サーバーとやりとりをしてパブリックサーバーでその他のトラフィックを処理しています。

私たちは、パッシブDNSデータ内で内部IPアドレスに解決されたホスト名を測定することで、誤検知によるブロックの影響を定量化しています。2021年6月には、アクティブなホストネーム全体の8.99%がプライベートIPアドレスに向けられていました。DNSベースの緩和策は、これらのトラフィックをすべてブロックしてしまいます。ただしこれらのホスト名の99.84%はパブリックIPをまったく指しておらず、完全にDNSリバインディングのものである振る舞いを示していないことから、ブロックされるべきではありません。この緩和策によるDNSトラフィックの誤検出率は85.09%でした。

サーバーベースの緩和策

Web アプリケーション側の防御であれば、DNSリバインディングを効果的にブロックすることができます。その解決策のひとつとして、すべてのプライベートサービスにHTTPS通信を導入することが挙げられます。HTTPSハンドシェイクの段階では、SSL証明書を検証するために正しいドメインが必要となります。DNSリバインディング攻撃では、内部サーバーのSSL証明書が別のドメインのものであるにもかかわらず、ブラウザは悪意のあるドメインに通信していると思い込んでしまいます。そのため、攻撃スクリプトは対象サービスへのSSL接続を確立できません。また、すべてのプライベートサービスに強力な認証情報を導入することも効果的です。このアプリケーションレベルの保護により、攻撃者がDNSリバインディングを成功させたとしても、機密情報にアクセスすることはできなくなります。

ただしそうした緩和策は内部サービスの開発者に依存していますからスケーラブルではありません。サードパーティのWebアプリケーションが家庭や企業の環境に普及するにつれ、ネットワークの所有者が潜在的な脆弱性を持つすべてのサーバーに保護を施すことは難しくなっています。一方で脅威ハンターは前セクションで述べたRailsコンソールRCEの悪用のように、サードパーティWebアプリケーションにおけるDNSリバインディング脆弱性を探し続けています。

リアルタイムのDNSリバインディング検出

弊社のDNSセキュリティサービスは、お客様のDNSトラフィックを監視し、リアルタイム保護を提供しています。つまり私たちには、DNSリバインディング攻撃の異常なDNSクエリのパターンを認識する高度なシグネチャをエンフォースできるチャンスがあるということです。私たちは、DNSセキュリティとパッシブDNSデータを読み込む検知システムを立ち上げ、それによって現在進行中のリバインディング攻撃のIoC（Indicator of compromise 侵害の痕跡）を捕捉しました。DNSセキュリティのトラフィックを追跡するこの検出器は、悪意のあるホスト名をリアルタイムに特定・配信することが可能です。

私たちのシステムは、個々のDNSレスポンスに頼るのではなく、連続したDNSの名前解決パターンを捕捉することをめざしています。その検出ロジックは、高い信頼性でDNSのリバインディングを識別することができ、正当な用途に対してのみ、内部IPアドレスに解決するホスト名を許可します。高い検出精度にくわえ、このシステムは、時間変動型攻撃、複数Aレコード攻撃、CNAMEベース攻撃など、前述した全ての種類のDNSリバインディング攻撃を網羅しています。内部IPアドレスやlocalhostを狙った攻撃以外に、お客様の内部ホスト名への悪意あるホスト名のリバインディングも特定します。

誤検知を防ぐため、検知モジュールの背後には、正当な使用のためのフィルタを多層にわたって集積しています。これは前述したとおり、正当なサービスのなかにも、DNSリバインディングに似た振る舞いのDNS名前解決を行うものがあるからです。追加の情報がなければ、これらを悪意のあるホストネームと区別するのは困難です。弊社のフィルタは、パッシブDNSトラフィック、WHOISレコード、お客様からのフィードバックなど、外部にある知識を組み合わせてお客様の内部ホスト名やその他の問題のないサービスを除外しています。

結論

DNSリバインディング攻撃は、被害者のブラウザを侵害してこれをトラフィックトンネルとして使い、プライベートサービスを悪用するものです。このテクニックにより、攻撃者は機密情報を窃取し、被害者のサーバーに偽造したリクエストを送ることができます。ブラウザやリゾルバ、Webアプリケーションは、これを防御するためにさまざまな保護戦略を採用しています。しかしながら従来型の防御策を回避できる高度なエクスプロイトは存在します。また、内部のネットワーク環境が複雑になるにつれ、完全な保護を実施することは難しくなります。

パロアルトネットワークスは、お客様を保護するためにDNSリバインディングの検知システムをローンチしました。これにより、複数種類のDNSレコードを活用し、さまざまな名前解決上の振る舞いを見せるDNSリバインディングの多くの実装を効果的に識別することができます。このシステムのフィルタリングモジュールが内部IPの名前解決が正当利用であるかを識別し、誤検出によるブロックを防ぎます。侵入の可能性のある活動を捕捉した後、本システムは、パロアルトネットワークスの次世代ファイアウォールのセキュリティサブスクリプションに対し、コマンド＆コントロールカテゴリを持つ攻撃ホスト名をリアルタイムに提供します。

謝辞

本稿の改善にご協力いただきましたLaura Novak氏、Daiping Liu氏にこの場を借りてお礼申し上げます。