サブドメイン列挙の目的は何ですか？
特定のドメインのサブドメインを列挙する多くのセキュリティツールがあります。私は疑問に思う：
- セキュリティ/ハッキングに関して、その目的は何ですか？
- 最も一般的なサブドメイン名の辞書を使用してブルートフォース以外の方法でそれを行う方法はありますか？
- ドメインをサブドメインの列挙から保護するにはどうすればよいですか？
セキュリティ/ハッキングに関して、その目的は何ですか？
リソースのホスト名は、利用可能なマシンとリソースに関する情報を提供することにより、攻撃者のタスクの範囲を狭めるための貴重な情報を提供できます。ネットワーク（IP）アドレスの基盤となるスペースはまばらに配置されており（_IP:port_の組み合わせはさらに多い）、組織がマシンをホストしているアドレスを絞り込むと、マシンの検索、トポロジーのマッピングに必要な準備作業が大幅に削減されます。攻撃を開始します。
たとえば、DNSに_ssh.company.com_という名前が存在すると、SSHデーモンをホストしている可能性のあるマシンのヒントが得られます。最初の例では、デーモンがデフォルトのポートで実行され、攻撃のオーバーヘッドが大幅に削減され、脆弱性の調査段階に進むと想定するのが妥当です。対照的に、組織の広いIP範囲（既知の場合アプリオリの場合）のスキャンは遅く、時間がかかり、ファイアウォールとポートのIDSデバイスで早期アラートをトリガーする可能性が高くなりますスキャン試行。
最も人気のあるサブドメイン名の辞書を使ってブルートフォース以外の方法でそれを行う方法はありますか？
はい、関連するインフラストラクチャの（誤った）構成の程度に応じて使用できる代替方法があります。一般的な方法のリストは次のとおりです。
辞書攻撃は、一般的なホスト名に対する標準のDNSクエリを送信することによって受動的に動作します。定義により、ゾーンの完全な列挙を提供することは保証できませんが、常に共通のホスト名を持つリソースを見つけます。この攻撃ベクトルは、DNSの適切な機能を妨げることなく軽減することができません。
brute-force攻撃も受動的に動作しますが、ホスト名の可能なすべての組み合わせを生成します。 RFC 1035 がDNSラベルの最大許容長とFQDNの全長（§2.3.4）を制限するため、このような攻撃は徹底的なものになる可能性があります。ただし、これは非常に時間がかかります。特に、DNS名前空間の人口が少ない場合はそうです。
zone transfer attackは、指定された権限のあるDNSネームサーバーに zone transfer を要求しようとしますドメイン。ゾーン転送は、ゾーンの内容全体のダンプを表します。これは通常、スレーブサーバーがローカルにキャッシュされたゾーンのコピーを更新するために使用されます。ゾーン転送が成功すると、ゾーン全体が列挙されます。
ほとんどのシステム管理者は、ゾーン転送要求を送信する可能性のあるソースIPアドレスを制限することにより、あいまいなセキュリティを提供しています。したがって、この攻撃が成功するのは、サーバーにオープンゾーン転送ポリシーがある場合（だれでもゾーン転送を送信できる）、攻撃側が進行中のゾーン転送を監視できるか、攻撃側が次のいずれかからパケットを発行できる場合です。おそらくネットワーク内のトラフィック傍受による、信頼できるIPアドレス。
NSECウォーキング攻撃は [〜＃〜] dnssec [〜＃〜] /を列挙できます -signedゾーン。 DNSSECは、攻撃者がサービス拒否の試みでNXDOMAIN応答を偽装することを防ぐために、ゾーンにレコードの非存在を表明する必要があります。存在拒否の証拠の提供は、通常、ゾーンレコードを並べ替え、それらをNSECレコードのチェーン（それぞれに署名済み）でリンクすることによって実現されます。したがって、各NSECレコードの間にある名前空間には、有効なリソースレコードが含まれていません。ただし、この手法では、必然的に
NSECスペースを トリビアルウォーク にしてDNSゾーンを列挙できます。このリスクを最小限に抑えるためのさまざまな代替メカニズムが提案されています。
オンライン署名。この場合、
NXDOMAIN応答はアドホックで生成され、名前空間のより小さなサブセットを繰り返し制限します（たとえば、_a.domain.com_を制限します）。次に_aa.domain.com_、次に_aaa.domain.com_）。ただし、このアプローチでは、署名キーをスレーブサーバーに配布する必要があります。_
NSEC3_レコードは、存在拒否の証明にハッシュを導入します。ハッシュは静的に署名されるため、署名鍵のコピーをスレーブサーバーに提供する必要がなくなります。ホスト名がハッシュ化されると、_NSEC3_レコードのチェーンをたどるのは簡単ではなくなり、オーバーヘッドが大幅に増加しますが、 一部のクレームが存在します これでもまだ不十分です。
ウィキペディアには、問題全体に関する good view があります。
ドメインを保護するには？
上記の攻撃からの保護は、適切に構成されたネームサーバーを使用し、DNSSECの展開を慎重に検討することにより、防御の最前線になるはずです。ただし、適切なDNS機能を損なうことなく、辞書または総当たり攻撃の脅威を完全に排除することはできません。
DNSが公開情報であることを常に認識しておく必要があります。ゾーンファイルを要求した人に譲らない方がいい習慣かもしれませんが、これは単にセキュリティごとのセキュリティです。多層防御セキュリティテクニックは、ネットワークトポロジでの適切なセキュリティ対策、システムユーザーの社会的攻撃に対するトレーニング、ユーザーが操作する可能性のある公開デーモンの適切な引き締め、およびその他の書面によるセキュリティポリシーで定められていることを通じて、引き続き採用する必要があります。
ゾーン転送テスト
お好みの* nix環境でDig(1)ユーティリティを使用してDNSゾーン転送をテスト（または実験）するのは簡単です。転送できるゾーンを見つけることは別の問題ですが、 digi.ninjaはこの目的で_zonetransfer.me_ example を提供します。次のコマンドは、_zonetransfer.me_ゾーンに対する正常なゾーン転送を示しています。これにより、このデモゾーンの完全な列挙が提供されます。
_Dig @nsztm1.digi.ninja zonetransfer.me AXFR
_コマンドの関連フィールドを置き換えることにより、独自のゾーンをテストできます。失敗した試みは応答を引き出すはずです
_; Transfer failed
_サブドメイン列挙手法は、ペンテスト割り当ての攻撃前段階または情報収集段階で使用される受動的な方法です。
サブドメインを列挙することは、Webアプリケーションの異なる部分をポイントしたり、別のIPアドレスを持つ別のサーバーでホストされている別のWebサイトにつながる可能性があるため、重要です。これにより、ターゲット組織の正確なパブリックネットワークプロファイルを作成できます。このプロセスは、スキャンを開始する直前に、周辺テストの前兆として機能する可能性があります。参照 サイトのサブドメインを見つけるにはどうすればよいですか？
サブドメインの列挙に使用されるツールは、ワードリストを使用したブルートフォースアプローチに依存しています。別の可能な方法は、DNSゾーン転送を試みることです。この場合、攻撃者はスレーブDNSサーバーになりすまして、マスターDNSにレコードのコピーを要求します。ただし、これは安全に構成されていないDNSサーバーでのみ機能します。私の意見では、ブルートフォースは列挙に利用できる最も信頼できる手法です。参照 DNSゾーン転送攻撃
前述のように、これは列挙の「パッシブな方法」であり、したがって、AFAIKはこれを防ぐ方法はありません。ドメインがパブリックインターネット経由でアクセス可能である限り、ブルートフォースメソッドを使用してドメインを見つけることができます。