本文の内容は、2022年8月2日にBrett Wolmaransが投稿したブログ(https://sysdig.com/blog/dns-security-cloud-protection/)を元に日本語に翻訳・再構成した内容となっております。
クラウド上でDNSを使用する場合、セキュリティは見過ごせません。この記事は、DNSセキュリティの導入オプションと、クラウドでのDNSのセキュリティベストプラクティスについて詳しく知りたいクラウドアーキテクトとセキュリティ実務者向けのものです。
DNSセキュリティのためのDNSベストプラクティスを学び、DNSのためのクラウドアプローチの利点を理解することができます。DNSに求められる主な要件は次の3つです。
- 信頼性
- パフォーマンス
- セキュリティ
この記事では、DNSの基本から始まり、クラウドにおけるDNSのトピックに進みます。次に、DNSのセキュリティについて詳しく説明し、最後に、DNSのニーズに対して「Build vs Buy」のアプローチを決定するのに役立つ推奨事項を紹介します。
DNSの基本について見てみましょう。DNSに慣れていて、クラウドのDNSについて学びたい読者は、先に読み飛ばしてください。
DNSとは何か？
ご存知のように、DNSはDomain Name Systemの略称です。1987年にPaul Mockapetrisによって最初に定義され、その後、45以上（！）のRFCによって拡張されたDNSは、インターネットの電話帳です（電話帳を覚えている人向けです）。実際にウェブサイトに接続するときは、電話番号の代わりに、DNSクライアントを使用してDNSサーバーにそのウェブサイトのIPアドレスを問い合わせます。そして、連絡先の名前の代わりに、完全修飾ドメイン名（ホスト名とも呼ばれる）を調べます。たとえば、www.sysdig.com。DNSがうまく機能すれば、www.sysdig.com のIPアドレスを答えとして受け取り、接続できるようになります。
DNSクエリーはどのように動作するのでしょうか？
DNSは電話やPCだけのものではありません。冷蔵庫やコーヒーメーカーなど、インターネットに接続されたキッチン用品でも使われているのです。まずは、簡単なDNSルックアップの基本ステップを図でご紹介します。
簡単なDNSルックアップDNSは階層構造になっており、最上位にルートサーバー、その下にトップレベルドメイン（.com、.net、.org）、国別ドメインが配置されています。ルートサーバーは世界中に配置されており、堅牢で厳しい設計が必要です。
トランスポート・プロトコルに関しては、UDPポート53はあなたの友人ですが、最近はTCPポート853もあります。アプリやウェブブラウザからDNSルックアップを見ることはできないので、ここではDNSクライアントとしてdigを使い、コマンドラインから1つ紹介します。
注：nslookupを使用することも考えましたが、Sysdigではdigを使用します！
シンプルなDNS Dig
以前に、暗号化されていないDNSが知らないうちに収益化されることによるプライバシーの問題について触れました。幸いなことに、EDNS、クライアントサブネット表示、そしてもちろんDNS over HTTPS（DoH）とDNS over TLS（DoT）のような比較的エキサイティングな開発により、機能性とプライバシーを含めて状況は良くなってきています。
DNSは非常に大きな存在です。Verisign Domain Namesのレポートによると、2022年の第1四半期は、すべてのトップレベルドメイン（TLD）を通じて3億5,050万件のドメイン名登録で終了しました。そのうち、オリジナルの8つのTLDを含む約1262のTLDが存在します。
DNSの使用例とアーキテクチャー
DNSサーバーには、2つの主なユースケースと2つの主なデプロイメントアーキテクチャーがあります。- 内部DNSサーバーとして、組織内で解決する必要があるすべてのものに対応します。例えば、ファイルサーバー、メールサーバー、プリントサーバーなど、従来の組織ネットワークを構成する何千もの種類のデバイスが挙げられます（古風に聞こえるかもしれませんが）。
- インターネットからのクエリーに対応するインターネット向けDNSサーバーは、リモートワーク、ポストCovid SaaSの世界では、顧客だけでなく、従業員も扱うかもしれません。
もちろん、ほとんどの組織では、この両方のユースケースを持つことになります。同じサーバー上で組み合わせることもあれば、別々のサーバーを使用することもあります。DNSビューまたは「スプリットDNS」を使用することは、このためのDNSのベストプラクティスです。
主なデプロイメントアーキテクチャーは次の2つです。
- 独自のDNSインフラクチャーを構築する。このアプローチは、インターネットの最初の20年ほどの間、唯一の選択肢でしたが、さまざまな評価があります。DNSに対するDIYのアプローチは、一般的に言って、特に規模が大きくなると、うまくいくのが難しくなります。しかし、現在では選択肢があります。
- クラウドでDNSを利用する。サービスとしてのDNSを活用することは、少なくとも過去10年間は選択肢の1つでした。多くの理由から、これは現実的な最初の選択肢となっており、特にあらゆるものがクラウドに移行していることが挙げられます。
この記事では、クラウド上のDNSに焦点を当てます。
クラウド上のDNSのアーキテクチャー
ホストDNSプロバイダーの基本的なハイレベル・アーキテクチャーを見ると、共通のテーマが浮かび上がってきます。内部的には、これらのプロバイダーはそれぞれ独自のシークレットソースをいくつか持っていますが、それはこの記事の範囲外であり、ほとんどの場合、本当に公開されている情報ではありません。これらのプロバイダーがどのようにDNSサービスをビルドしてきたかについて公開されている情報を見ると、以下のような共通のエッジネットワーク、エニーキャストアーキテクチャーがあることがわかります。
エニーキャストでは、グローバルに分散したDNSサーバーは、BGPの魔法で伝搬する単一の同一IPアドレスを宣伝します。レイヤー3ルーティングにより、DNSクエリーは自然に最も近いサーバーに到着します。これにより、冗長性、パフォーマンス、信頼性、および最小のレイテンシーが実現されます。
エニーキャストBGPによるDNSのセキュリティこれに基づいて、クラウド上のDNSのハイレベルなアーキテクチャーを構築しました：DNS in the Cloud Architecture
クラウドDNSプロバイダーは、グローバルなエニーキャストエッジネットワーク上にDNSサーバー群を配置し、DNSをサービスとして顧客に提供します。顧客はAPIまたはWebインターフェイスを使用してゾーンを設定し、ドメインをクラウドDNSプロバイダーに委譲します。DNSプロバイダーは、サーバー群全体にお客様の設定を複製する役割を担います。
その後、以下のような流れになります。
- DNSクエリーは、エニーキャストの魔法に基づいて、最も近いDNSサーバーにルーティングされます。
- クラウドDNSサーバーは、クエリーの対象となるFQDN（Fully Qualified Domain Name：完全修飾ドメイン名）の顧客設定を参照します。
- クラウドDNSサーバーは、通常、アルゴリズムにヘルスチェックとジオロケーションを追加します。これにより、返される回答が「健全な」、つまり稼働して利用可能なリソースを指していることが確認されます。
- DNSアンサーは元のクエリーに対して、低レイテンシーで健全なリソースを指して返されます。
責任共有モデル
拡大すると、クラウド上のDNSの共有責任モデルが見えてきます。
クラウド上のDNSの責任共有モデル
- ホスティングされたDNSプロバイダーは、DNSサーバー自体のデプロイメント、維持、セキュリティ、デジタルセキュリティ、パフォーマンス、および信頼性に責任を負います。
- お客様は、特定の構成について責任を負います。
- ドメイン登録を含むドメイン。
- ゾーンとレコード、FQDN（完全修飾ドメイン名）をVMやホストされたゾーンなどのクラウドリソースにマッピングします。
- 管理者ユーザーアカウント
- リソースのヘルスチェック設定（頻度とタイムアウト間隔を含む）。
- リソースのジオロケーションレコード
DNS in the Cloudの機能
クラウド上のDNS（ホストDNS、DNS as a Serviceとも呼ばれる）は、DIYに代わるアプローチであり、重要な利点があります。DNS in the Cloud
注：DNS in the Cloudは、AWS EC2インスタンスでBINDを立ち上げるところではありません。DNS in the Cloudは、DNSハードウェア、ソフトウェア、そしてほとんどの場合、DNSセキュリティをアウトソースすることを意味します。BINDやその他のDNSソフトウェアをメンテナンスする必要はなく、OSやVMをメンテナンスする必要もない。DNSエンジンは抽象化されているので、共有責任モデルの自分の側だけを処理すればよいのです。
クラウド上のDNSは、多くの最適化の扉を開きます（先に述べたエニーキャストのような）。最近のウェブページでは、すべての画像、追加ボタン、ウィジェット、リンク、アイコン、およびその他の埋め込みコンテンツが固有のホスト名を持つ場合があり、トップレベルページ、たとえば www.cnn.com は、ページをロードするために100以上のDNSルックアップを必要とします!
そしてありがたいことに、DNS in the Cloudは実に高速です。これらのうち、どれだけが1桁ミリ秒の応答時間を実現しているか見てみましょうか？https://www.dnsperf.com/ で、いくつかの異なる地理的な場所から、ご自身で試してみてください。
DNSPerfローパフォーマンスチャート 出典: https://www.dnsperf.com/
DNS in the Cloudのメリット
DNS in the Cloudのメリットは、低レイテンシー、セキュリティ、信頼性だけではありません。ここでは、DNS in the Cloudの主な利点を紹介します。- セキュリティ：詳細は後述しますが、基本的にDNSサーバー自体をアウトソースするため、BINDやその他のDNSソフトウェアのパッチや最新のハッキングを防ぐためのセキュリティの維持、DDOS攻撃によるDNSサーバーのダウン、その他DNSサーバーに影響を与えるような脆弱性や攻撃の心配をする必要がありません。歴史上最も有名なDNSソフトウェアのバグは、もちろん故Dan Kaminsky氏がBlackHat 2008で初めて発表したKaminsky攻撃でしょう。
- パフォーマンス： クラウド上のDNSは、本当に、本当に速いです。何百ものDNSインスタンスとエニーキャストにより、インターネットに面したDNSサーバーを立ち上げるよりも高速になります。クラウドホスティングのDNSパフォーマンスを比較する興味深いテストが行われましたので、ご覧ください。
- トライバルナレッジ ：クラウド上のホストされたDNSがあなたのクラウドプロバイダー上にある場合、例えばAWSの場合、強力な統合機能があります。例えば、Route53はAWSのリソースについて知っているので、ロードバランサーに対するヘルスチェック、サービスに基づいたルーティングルールなど、AWS特有の特典を活用することができます。
- 価格： Route53のようなDNS as a Serviceは非常に安価でパフォーマンスが高いので、本当に安価で強力なデータベースサーバーとして使うなど、独創的なアイデアで利用されているそうです。
- 信頼性：エニーキャストだけでなく、フォールトトレランス、スケール、信頼性は、DNSの要件に関しては、パフォーマンスと同じように最高の栄誉を獲得しています。クラウド上のDNSは、大規模なウェブクラウドプロバイダーの予算がない限り、自分でビルドできるものよりも間違いなく信頼性が高くなります。ホスティングされたDNSの信頼性の一例として、AWS Route53は100%のアップタイムSLAを提供する唯一のAWSサービスです。もし障害が発生した場合、これは本当にAWSの請求書に返金クレジットとして現れるかもしれないので、本当の100%アップタイムに近づけるためにはバックアッププロバイダーが必要かもしれません。冗長性を高めるために複数のプロバイダを重ねることについては、後ほど詳しく説明します。
DNS-as-a-Serviceを利用するもう一つの利点は、DNSエンジンの実装の詳細から可能な限り離れることです。ここで思い浮かぶのは、もちろんBINDです。良いことに、主要なクラウドDNSプロバイダーのほとんどは、カスタマイズされたBINDを使用しているか、BINDをまったく使用していないため、非常に大きな変動要因を排除することができます。
統合されたクラウドDNS
私たちの多くは、パブリッククラウドにデプロイし、ビジネスアプリケーションのクラウドファースト戦略を持っています。では、アプリケーションやサービスがすでにクラウド上にある場合、クラウドサービスを認識し、それを活用できるDNSを持つことは意味があるのでしょうか？統合型クラウドDNSとは？
統合クラウドDNSとは、私が最近思いついた言葉です。クラウドプロバイダーが提供するホストDNSには、他のネイティブサービスへの特別なフックが含まれているので、それを表現する方法が必要だと考えたからです。このフックこそが、統合を実現するものです。一般的に、クラウドパターンは疎結合を強調し、密結合は推奨しませんが、もちろん一般的なルールと同様に例外はあります。
特に、DNSにマッピングするIPアドレスが同じクラウドプロバイダー内のサービスである場合、DNSとこれらのサービス間の「強固な」結合は、いくつかの実質的な利点をもたらします。もちろん、これはクラウドプロバイダー側の意図的なもので、自社のネイティブサービスに対する採用やロイヤリティを高めるのに役立つからです。
そして、統合DNSを利用するためのいくつかの強制的な機能ですが、時にはそれが必要ない場合でも、副次的な効果としてDNSを手に入れることができます。具体的な例としては、EC2インスタンスのようなリソースをスピンアップすると、そのリソースに対するDNSレコードが自動的に生成されます。そしておそらく、開発者はそのレコードを使い始めるでしょう。
この「強固な」結合は、次のような利点をもたらします：
- DNSサービスは、既存のIdentity and Access Management（IAM）ポリシーを利用できる。
- ヘルスチェックは、IPアドレスではなく、論理的なものに基づいて行われます。IPアドレスは時々変わりますが、AWS EC2のインスタンスIDやタグはIPアドレスよりもずっと長い間、耐久性があるため、非常に便利です。
- AWS Cloud Trailのような既存のクラウドログメカニズムでログを記録することができる。
- AWS Guard Dutyのような既存のクラウドセキュリティコントロールやポリシーとの統合。
しかし、私が言っていることを説明するために、具体的な例を見てみましょう。
Amazon Route 53は、Amazon IAM、Amazon API Gateway、Amazon ELB、Amazon VPC、AWS S3バケットなど、他のAWSサービスとの統合を特注で行っています。ここでは、視覚的に示すのが最も良い簡単な例です。
クラウド上のDNS
Amazon Route 53がKubernetesクラスターとどのように統合されるかを示すもう一つの例です。
クラウドのDNS
そして、セキュリティに関しては、DNSセキュリティのための精巧な統合があります。
統合型クラウドDNSの比較
統合型クラウドDNSの代表的なサービスとして、Google Cloud DNSとAWS Route 53があります。Google Cloud DNSには、密結合を可能にする多くの素晴らしい機能があります。AWS Route53も同様です。しかし、Route53は何年も前からAWSのロードバランサーと統合されていますが、Google Cloud DNSは独自のロードバランサーとの統合を始めたばかりなのです。
Google Cloud DNS のベストプラクティスは、やや一般的であまり具体的ではありませんが、以下のようなものがあります。
- 条件付き転送を使用する
- DNSピアリングの使用
- Google Cloud のファイアウォールを開き、DNS トラフィックを許可する。
AWS Route 53を掘り下げてみると、Google Cloud DNSと同様に、VPCに従来のDNSサーバーを立ち上げた場合では得られない多くの機能があることがわかります。
AWS Route 53を使用する場合、いくつかのDNSのベストプラクティスがあり、それは実質的により具体的であるように思われます。
- 迅速なフェイルオーバーメカニズムのために60秒または120秒のTTLを設定する。
- データプレーンのRoute 53ヘルスチェックを使用する
- CNAMEレコードの代わりにRoute 53のエイリアスレコードを活用する。
- ジオロケーションベースのルーティングを常にデフォルトにする
もちろん、AWS Route 53が持つAWS Load Balancingとの非常に素晴らしい統合を含める必要があります。
しかし、より興味深い例として、AWS Route 53はAWS EKS Elastic Kubernetes Service for ExternalDNSと緊密に連携しています。この機能は、Amazon EKSがAmazon Route 53にアクセスできるようにするAWS Identity and Access Management (IAM) 権限を必要とします。
これらの具体的なメリットはDNSのベストプラクティスであり、ロールユアオウンのアプローチで実現するのは非常に困難です。もちろん、特定のクラウドプロバイダーへの深いロックインなど、密結合の通常のトレードオフが適用されますが、密結合の利点の素晴らしい例です。
管理者用監査ログも忘れてはなりません。Google Cloud DNSと同様に、AWS Route 53のためにAWSアカウントで行われたすべての変更は追跡されます。AWSの場合、このトラッキングはCloudTrailでリアルタイムに近い形で行われます。あとは、どの変更が危険か、どの変更が追加のソリューションやツールを必要とするかを見極めるだけです。
AWSアカウントの誰かが、VPCをHosted Zoneに関連付けたり、リソースレコードセットを変更したり、ドメインを登録したり、Route 53の設定に関して他の危険な動作をしているかどうかを知りたくはありませんか？
Google Cloud DNS for GCPとAWS Route 53 DNSサービスに関して、それらがどのように積み重なるかを掘り下げてみましょう。
クラウドDNSの比較：Google Cloud DNSとAWS Route 53の比較
| Cloud DNS 機能 | 説明 |  Google Cloud DNS |
 AWS Route 53 |
| 信頼できるDNSルックアップ | www.google.com のようなドメイン名へのリクエストを74.125.29.101のようなIPアドレスに変換します。 |  |
|
| Cloud IAM | IAMとの統合により、DNSリソースの完全な制御と可視化により、安全なDNSドメイン管理を実現します。 | |
|
| クラウドログとDNS監視 | DNSは、ネットワーク内のVMやインバウンド転送フローから受信したすべてのDNSクエリーのレコードをログに記録します。Cloud LoggingでDNSログを表示し、Cloud Loggingのエクスポートがサポートする任意の宛先にログをエクスポートすることができます。DNS監視は、DNSクエリーと応答を記録し、DNSがアプリケーションチームによってどのように使用されているかを理解するために不可欠なパフォーマンス統計とメトリクスを提供します。 | |
|
| 豊富なルーティングポリシー | DNSのクエリーとレスポンスをルーティングする方法は1つだけではない場合があります。加重ラウンドロビン（WRR）ルーティングポリシー、フェイルオーバールーティングポリシー、ジオロケーションルーティングポリシー、ジオプロキシミティルーティングポリシー、レイテンシールーティングポリシーなど。 | |
|
| Global IP Anycast | 世界中に配置された複数の物理サーバーで、論理的なネームサーバーを使用可能 | |
|
| DNSをコードで管理 | DevOpsアプローチでDNSをデプロイし、ゾーンファイルやその他のDNS設定アーティファクトをGitHubやお好みのGitベースのリポジトリに保存し、他のコードと同じようにデプロイパイプラインで実行します。Akamai、GCP、AWSで機能するTerraformや、AWS Cloud Formation Templatesなどのクラウドプロバイダーのネイティブメソッドを使用しています。 | |
|
| プライベートエンドポイント | クラウドプロバイダーの仮想ネットワークとお客様のデータセンター間のトラフィックは、クラウドプロバイダーのバックボーンネットワークで移動します。これらのプライベートリンクは、プライベートエンドポイントで終端し、DNSが解決する必要があります。 | |
|
| 対応するレコードの種類 | DNSレコードには、1つのIPアドレスに解決するwww.sysdig.com のようなAレコードがよく知られていますが、多くの種類があります。 | A, AAAA, CNAME, MX, TXT, PTR, SRV, SPF, NS, SOA |
A, AAAA, CNAME, MX, TXT, PTR, SRV, SPF, NS, SOA, DNSKEY, DS, IPSECKEY, NAPTR, SSHFP, TLSA, CAA |
| ドメイン登録 | |
|
|
| ヘルスチェック | ヘルスチェックはDNSサービスから行われ、ロードバランサーのような他のサービスには依存しません。ヘルスチェックは、お客様のウェブサーバーやその他のクラウドリソースの健全性とパフォーマンスを監視します。 | |
 |
クラウドDNSのセキュリティ機能を比較：Google Cloud DNSとAWS Route 53の比較
| クラウドDNSのセキュリティ機能 | 説明 | Google Cloud DNS |
AWS Route 53 |
| レスポンス・ポリシー・ゾーン（RPZ） | RPZを使用することで、ネットワークやDNSの管理者は、セキュリティサービスプロバイダーからのレピュテーションフィードに基づいて、ほぼリアルタイムで独自の保護ポリシーを実行することができます。 | |
|
| Secure Transports: DNS over HTTPS (DoH) | DNS over HTTPS（DoH）は、DNSクライアントとサーバー間の通信を暗号化し、ISPやクラウドプロバイダーなどの中間プロバイダーによるDNSリクエストの追跡を防止します。 | |
|
| Secure Transports: DNS over TLS (DoT) | DNS over TLS（DoT）は、DoHと同様にDNSクライアントとサーバー間の通信を暗号化し、ISPやクラウドプロバイダーなどの中間プロバイダーによるDNSリクエストの追跡を防止します。 | |
(planned) |
| DNSSEC | ドメインネームシステムセキュリティ拡張（DNSSEC）によるDNS偽造による多くのDNS攻撃タイプの防御 | |
|
| 監査ログ、DNS監視 | DNSに加えられたすべての管理上の変更をリアルタイムでログに記録します。DNS監視は、サービスが低下した場合に警告を発します。 | |
|
| 信頼に基づくモデル | 信頼できるネームサーバーのリストに対してのみコンテンツを提供することで、IPアドレス偽装のDNS攻撃タイプを防御します。 | |
|
| DNS ファイアーウォール | DNSファイアウォールは、マルウェアの自動検出、ドメイン生成アルゴリズム、DNSデータ漏洩（DNSを悪用して攻撃者と被害者の間で非構造化データを交換する）、カスタムブロック/許可リストなど、DNS攻撃の種類から守るフル機能搭載のファイアウォールです。 | |
あり（サブセットのみ）：既知の悪意のあるドメインに対するDNSクエリーをブロック、アプリケーションがクエリーできるドメインの監視と制御 |
マルチクラウドDNSのスタック
この記事の前半で、DNSの当初の高度に分散した意図的なデプロイメントが、実際には統合されてきていることを説明し、これが悪いことである理由について、いくつかの学術的な研究論文を参照しました。この記事を読むと、多くの大規模なウェブプロパティが本当にバックアップのDNSプロバイダを持っていなかったので、有名なDynの攻撃が頭に浮かぶことでしょう。しかし、次のMirai攻撃の影響を受けないようにするのは、本当に簡単なことなのです。1つのカゴにすべての卵を入れないことです。すなわち、複数のクラウドDNSプロバイダーを利用します。
DNSは少なくとも2つの信頼できるネームサーバー（NS）を必要としていますが、これは新奇な数字であり、4、6、8、あるいはそれ以上にして、複数のクラウドDNSプロバイダーでバランスを取ることができます。もちろん、それらを同期させる必要があります。
この推奨を補強するために、北米にある3つの大きな金融機関のDNSサーバーを調べたスクリーンショットを以下に掲載します。
DNSクラウドプロバイダーのスタッキング
digコマンドに対する応答から、これらの組織のうち最初の組織はDIYアプローチを利用して独自のDNSをホストしているように見えますが、2番目と3番目は複数のDNS in the Cloud（別名DNS as a Service）プロバイダーを持つ「スタッキング」アプローチを使っており、他の方法では実現が非常に困難な冗長性を与えていることが分かります。そのうちの1社はUltradnsとAkamaiの両方を使用しており、もう1社はNS1とAkamaiを使用しています。
DNS攻撃の種類と危険性
DNSの危険性は、DDOSや卑劣なハッキングなど明白なものもありますが、DNSを無防備な状態にしたり、意図しない障害を引き起こす可能性のある設定ミスを除外することはできません。DNSの危険の主な種類は、次の3つに分類されます：
- ボリューム型DDOSに基づくサービス拒否
- ハッキングとエクスプロイト
- 不手際と自業自得
DDOS攻撃
DynとAWS Route53は過去に大規模なDDOS攻撃を受け、混乱を招きましたが、1.2テラビット/秒のDDOS攻撃がセルフホスティングのDNSインフラに何をもたらすか想像してみてください。Dyn Mirai攻撃は、Reddit、New York Times、Twitter、Netflix、GitHub、AirBnbなど、数百万人が利用するWebサイトのDNS解決を阻害しました。この攻撃では、Miraiを活用してIoTデバイスの軍勢を制御し、数千万ものソースIPからDynを攻撃しました。さらに最近の2022年6月には、セキュリティリサーチャーのBrian Krebsが、DNSベースのDDOS攻撃を仕掛けるツールを提供するビジネスを営む犯罪者の起訴の進捗状況について報告しています。
卵はたくさんあるが、かごは少ない
Dynの場合、なぜ1つのDNSプロバイダーが攻撃されただけで「インターネット」が停止したのでしょうか。理論的には、DNSは完全に分散化されているため、完全に冗長化されているはずですが、実際には疑似分散化されているに過ぎないことが判明しています。Moz.comによると、トップ500のウェブサイトのうち、181のウェブサイトが上記の5つのサービスのいずれかをDNSプロバイダとして使用しています。このトピックについては、ハーバード大学の研究者によるこの素晴らしい論文「Evidence of Decreasing Internet Entropy: The Lack of Redundancy in DNS Resolution by Major Websites and Services」で詳しく調べることができます。
DNSハック
DDOSがハンマーであるなら、他のDNS攻撃タイプは外科用器具のようなものです。これらのDNS攻撃の種類をすべて分類することは困難ですが、大まかに分類すると、2つのハッキングの種類に分けられます。- DNSトンネリングなど、内部からのDNSハック
- DNSスプーフィングやキャッシュポイズニングなどの外部からのDNSハック
サブドメインを見つけるためのシンプルなGoogle Dorks ( site:*.sysdig.com -www -store -jobs -uk ) からGithub上のあらゆる種類のクールなツールまで、DNSを悪用する多くの既製のオプションが存在します。
内部からのDNSハッキングは、多くのDNSトンネリングとexfiltration DNS攻撃タイプによって例証されています。一般的に、これらのタイプの攻撃では、ハッカーは、DNSパケットがファイアウォールによってほぼ常に一般的に任意のIPアドレスへの送信を許可されていることを悪用します。Infoblox社のライターは、DNS Smugglingについて、次のような見事な見解を示しています。「DNSデータ漏洩は、ガレージのドアを開けずに車を盗むようなものだ。車をドアや窓を通れる大きさに分解し、外で車を作り直さなければならない」という、非常に巧妙で面白い例えを挙げています。
DNS Smugglingの非常に単純な例を挙げます（他にもあります）：
攻撃者がすでにネットワーク内にいて、クレジットカードのデータベースにアクセスし、クレジットカード番号を検知されずに外部に送信したいと考えているとします。
攻撃者は、インターネット上にDNSサーバーを立ち上げ、「windows-server-update-microsoft.net」のような無害そうなドメイン名を登録します。このドメイン名は、このブログの投稿時にたまたま12ドル程度で入手できたものです。
注：このドメインを登録しようとは思わないでください。私は、このスロープがいかに滑りやすいかをお見せしたいだけなのです。マイクロソフトのソファーのクッションに小銭があれば、データサイエンティストたちが「update」と「windows」というキーワードを中心にドメイン生成アルゴリズムを実行し、これらのドメインを前もって簡単に登録できると思うかもしれませんが…これが現実なんです。
そのDNSサーバーで、攻撃者はクエリーログを有効にし、すべてのクエリーをログに残します。そして、ネットワーク内部からスクリプトを実行し、すべてのクレジットカード番号をループさせ、DNSドメインにこのように追加していくのです：
DNSの仕組みを知っていれば、このクエリーがwindows-server-update-microsoft.netサーバーに行くのではなく、設定されたローカルDNSリゾルバーに行き、そこから転送されることがわかるはずです。そして、攻撃者のDNSサーバーにクエリーが届くと、そのクエリーの内容が記録されます。
しかし、インサイドアウト型のDNS攻撃は、これだけではありません。ネットワーク内に侵入した悪意ある者は、他のサーバーと同じようにDNSサーバーをターゲットにして、その制御を試みることができます。しかし、DNSサーバーは、他のサーバーと異なり、標的が非常に豊富で、いったん制御されると、ハッカーは好きな場所にトラフィックを誘導することができるようになります。
一般的なドメイン名をリダイレクトしたり、コマンド＆コントロールサーバーに特別なDNS名を付けるなど、粗雑で容易に発見される手口を避けることで、ハッカーは発見されないようにすることができます。
外部からのDNSハッキングには、最新のサイドチャネル攻撃や、Sea TurtleのようなDNSハイジャックなどがありますが、もちろん、最もよく知られているのは、DNSキャッシュポイズニングです。
古典的なDNSキャッシュポイズニングとDNSスプーフィングによるハッキングは、何十年も前から存在しています。DNSSECのような緩和策は、実際に導入されると不便で問題があるため、広く採用されないことが分かっています。DNSSECの設定と維持は非常に困難であるため、DNSSECをすでに提供しているDNSクラウドサービスにアウトソーシングすることがより良い選択肢となる可能性があります。
プライバシーに関する大きな懸念は、ほとんどのDNSサーバーが暗号化をサポートしていないため、MiTMの懸念につながることです。現在ではデフォルトで Firefox ブラウザからの DNS クエリは DoH によって暗号化され、Cloudflare または NextDNS のいずれかに送信されます。そう、オペレーティングシステムが設定したものを上書きするのです!
Frefox DNS-over-HTTPS
有名な Kaminsky 攻撃は、BIND の応答に対する弱い検証によって、攻撃者が正しいトランザクション ID（当時は単なる 16 ビット数）をブルートフォースで取得する方法を示しました。
ドメイン名そのものに基づくハッキングもあります。ドメイン名の数が非常に多いため、ブランド偽装、TypoSquatting、CyberSquatting、Look-a-Like Webサイトなど、ドメイン名自体のテキストに基づく混乱攻撃の大きな表面領域が形成されています。
代替TLD、同形異番号ドメイン、ハイフネーションドメイン、ブランドと一緒に「login」「www2」「support」などのキーワードを含むドメインは、ドメイン乗っ取り、OWASP CSRF攻撃、フィッシングなどのあらゆる種類の攻撃を構築するための基盤となります。
DNS Razzleのような楽しいDNSツールについては、ブログ記事全体が書かれるかもしれません。面白半分に、私はdnstwistという名前のドメイン生成アルゴリズム（DGA）用の少しシンプルなツールを試してみました。ここでは、netflix.comというドメイン名に対してそれを実行し、すべての順列を確認しています。これはtyposquatting攻撃に使用される可能性があり、その数を見るのは恐ろしいことで、これらのIPアドレスのすべてがnetflixに属しているとは考えにくいのです！
DNSの設定ミス、失策、障害
DNSの誤設定や不手際は、単純な設定ミスからパッチ適用が遅れていることまで、多岐にわたります。DNSは、設定が非常に難しいことで有名です。Core BIND自体に非常に多くのバグがあり、それらは常に出現しています。そして、どんどん出てくるのです。DNSのベストプラクティスに従えば、こうした状況を避けることができますが、このように、DNSのミスや混乱に関する話はたくさんあります。
世界最大級の組織であっても、時折ミスを犯す可能性はゼロではありません。それでも、ほとんどの場合、DNSを巨大なDNS-as-a-Serviceプロバイダーにアウトソースする方がはるかに信頼性が高いと言えます。彼らはDNSの運用に常に専念するためだけに巨大なチームを抱えているからです。
カーネギーメロン大学のAqsa Kashaf氏、Vyas Sekar氏、Yuvraj Agarwal氏は、Analyzing Third Party Service Dependencies in Modern Web Servicesの中で次のように書いています。Mirai-Dyn事件から学んだこととは？複数のDNSプロバイダーを「積み重ねる」ことは、1つのプロバイダーがダウンした場合、全く別のインフラストラクチャーで構築されたバックアップDNSプロバイダーにロールオーバーするために理にかなっています。このバックアップは、他のクラウドDNSプロバイダーでもよいし、自分自身でもよいでしょう。例えば、Dynのインシデントの後、twitter.comはDynに加えてプライベートDNSをデプロイして冗長性を追加しました。
同様に、ホスティングされたDNSプロバイダーを簡単にスタックできる場合、例えばNS SOAレコードにAWS Route 53（Route53と短縮されることもあります）とGoogle DNSの両方を使用することができますし、私自身、金融業界の重要なドメインに最大8つのNSレコードを使用している実績があります。結局のところ、誰も銀行のウェブサイトでDNSが失敗することを望んでいないのです。
DNSセキュリティのベストプラクティス
DNSは、特に大規模なDDOS攻撃に弱く（ターゲットであると同時に手先でもある）、さまざまな方法でハッキングや悪用が可能です。また、設定ミス（パッチを適用していない場合を含む）により、サービス停止や最悪の事態を引き起こすという、ささいなミスとは言えない自業自得の側面も持っています。プライマリDNSサーバーをプロキシの後ろに隠すなど、低レベルで非常に具体的なDNSセキュリティのベストプラクティスがいくつか存在します。そして、それらを正しく理解する必要があります。
しかし、たとえ低レベルの設定の詳細がすべて正しくても、戦術的なレベルで高レベルのベストプラクティスに従わなければ、トラブルに巻き込まれる可能性があります。私たちは、入手可能な情報を調査し、以下のようなハイレベルなDNSセキュリティのベストプラクティスを導き出しました。
安全な設定とパッチの適用
DNSインフラストラクチャーを自分で構築している場合、DNSソフトウェアに対するCVEやその他のアップデートに遅れないようにする責任があります。DNSの重大なバグの歴史を考えると（BINDのことです）、DNSのパッチは、最も重要なサービスと同じように扱ってください。DDOS保護とDNSファイアウォールを導入してください。必要に応じてDNSSECを使用し、DoHのプライバシーへの影響を考慮してください。設定にアクセスする各アカウントで多要素認証（MFA）を使用し、管理インターフェイスと通信するためにTLS 1.2以上を使用しましょう。ドメイン名（および登録者）を把握する
本当に基本的なステップは、すべてのドメイン名と、それらがどのようにアプリケーションにマッピングされるかを知ることです。これが制御不能になった場合、何が起こるか想像してみてください。すべてのDNSサーバー、すべてのゾーン、およびDNSアーキテクチャーとトポロジーをカタログ化します。このブログポストで説明されているように、クラウドログを監視することによって、ドメイン名の作成をリアルタイムで把握することは、素晴らしい戦術です。DNS監視ソリューションの導入
DNSの障害は、どんなに大きな組織でも発生する可能性があります。このため、アプリケーションのアップタイムを監視するのと同様に、より詳細なDNS監視を行うことで、アプリケーションスタックのパフォーマンスやデータベースの停止などの他の問題と比較して、DNS自体が問題を引き起こしているかどうかを理解することができます。DNSモニタリングソリューションの一覧はこちらですが、他にも多くのソリューションがあります。DNSのセキュリティ機能を把握する
既存のDNSソリューションまたはサービスプロバイダーが提供するセキュリティ機能を把握しましょう。DNSベンダーから、セキュリティに関するロードマップを入手し、DNSセキュリティの開発に取り組んでいることを確認します。セキュリティ機能を提供するDNSソリューションまたはサービスプロバイダーを使用していない場合は、それらを破棄して、セキュリティ機能を提供するプロバイダーを探します。この記事で取り上げたDNSの機能についての機能一覧をご覧ください。豊富で効果的なログ
アプリケーションのあらゆる面でログに依存するのと同様に、DNSログも同じレベルの優先度で収集および分析する必要があります。DNSログは、脅威の早期発見の指標となり、セキュリティ情報およびイベント管理（SIEM）または同様のツールを使用して改善するために重要です。AWS CloudTrailでAPIとユーザーアクティビティーのログを設定しましょう。脅威防御の導入
脅威フィードを使用して、悪意のあるドメインへのリクエストをブロックします。キルチェーンの早い段階でDNS脅威フィルタリングを使用することで、WebサーバーへのTCP SYNを行う攻撃を防ぐことができます。DNSの脅威フィードは、DNSがメールサービスに影響を与える方法にも適用できます。必要に応じて、許可リストとブロックリストをデプロイし、DNSトラフィックに異常がないか監視する必要があります。逆の見方をすれば、https://www.dnsbl.info/ などのサービスを利用すれば、他の組織が誤って自社のドメインをブロックしていないかどうかを確認することができます。クラウドファーストのDNS戦略の採用
10年以上前から、組織がデジタル変革や近代化を進める上で、クラウドファーストが推奨されています。DNSも同じです。ホストDNSのケースを作るのは簡単です。クラウド上のDNSのシンプルさ、セキュリティ、堅牢性、パフォーマンス、有効性は、デフォルトのデプロイメント方法とすべきです。また、DNSプロバイダーを「スタッキング」して、別のMiraiが発生した場合に、バックアッププロバイダーがあるようにすることを検討するのも良いアイデアです。
クラウドプロバイダーは、多くの顧客が自前のDNSアーキテクチャを一夜にして切り替えることができないことを知っています。AWS Route 53には、AWS Route 53 Resolver for Hybrid Cloudsとして知られる、プライベートDNSをAWSと統合するための高度な機能も含まれています。
高いセキュリティ、ダークな環境など、いくつかのコーナーケースでは、100％クラウドDNSというのは適切ではありませんが、それでもデフォルトであるべきです。
まとめ
DNSがインターネットやイントラネット上のアプリケーションやビジネス戦略にとっていかに重要であるか、おわかりいただけたと思います。DNSが機能していないと、何も機能しません。インターネット上に展開するサービスやアプリケーションが、アプリケーションやマイクロサービスの観点からは無敵だとしても、DNSが機能していなければ、誰もあなたのサービスを利用することができず、物事は止まってしまうでしょう。
正しいデプロイメント戦略を選択することがなぜ重要なのか、お分かりいただけたと思います。
DNSの最も重要な要件は、次のとおりです：
- パフォーマンス
- 信頼性
- セキュリティ
アーキテクチャーのアプローチには、2つの基本的なものがあります。
- 古典的なDIYアプローチ。
- 独自のDNSをビルドすることは実際可能であり、レガシー環境では何年も存続するでしょう。
- 今後、新たな展開において、DIYのアプローチは、高度なセキュリティ環境などのコーナーケースに限定されるかもしれません。
- 拡張性、信頼性、効率性に優れたDNSインフラクチャーを構築するには、時間、コスト、専門知識が必要です。
- クラウドDNSの活用
- 業界のトレンドは、このアプローチです。
- ほとんどの組織やユースケースにおいて、これはDNSの要件を満たすための最適かつ最もコスト効率の高い方法です。
- クラウド上のDNSは機能と採用率が高まっています
また、両方が混在している場合もありますが、クラウドファーストの戦略が適用されます。
決断はお客様次第ですが、クラウド上のDNSには多くの利点があり、別の方向へ進むことは困難です。
どの方法を選択するにしても、この記事で紹介したDNSのベストプラクティスは、あなたを成功に導くのに役立つでしょう。