スプリットホライズンDNSはどのくらい重要ですか？
スプリットDNS は、ソースIPに応じて異なる結果を返します。
これは一般的に、列挙と発見を制限するために、内部リソースの重要なセキュリティ対策として宣伝されています。
これまで、分割DNSには、TTLを適切に考慮しないプログラムで多くの問題がありました。彼らは長い間解決をキャッシュし、DNSは一貫性がない（つまり、私のソースIPに依存している）ため、壊れます。たとえば、WindowsとChromeにはそれぞれ問題があります。
スプリットDNSのセキュリティ値について疑問に思っています。 DNSはテキスト名をIPアドレスにマッピングするだけです。攻撃者はIPよりもホスト名を列挙する方が簡単ですか？インターネットアドレスは秘密にする必要がありますか？ソースIPでブロックするファイアウォールがあっても、スプリットDNSはまだ価値がありますか？
スプリットDNSは実際のセキュリティをどの程度提供しますか？
標的型攻撃の最初の部分（つまり、ネットワークに侵入すること）は、標的について可能な限り調べることです。企業が内部ネットワークで公開ドメインと同じドメイン名を使用することは非常に一般的です。ホストの名前がその目的を説明することも非常に一般的です。
スプリットDNSを使用しない場合は、ドメイン内のすべてのホストに関する情報を1か所の公共の利用可能な場所で公開することになります。これらの公開された情報は、ホストの名前と内部で使用されているIPアドレスを明らかにし、企業のインフラストラクチャについて攻撃者に多くの情報を提供する可能性があります。
DNSはテキスト名をIPアドレスにマッピングするだけです。
内部ホストのこれらのマッピングを知っている場合に攻撃者が実行できる1つの例：
- 公開されているDNS情報にアクセスし、IPアドレス10.1.2.3のwiki.example.comという名前のホストがあることを確認します。ホストの名前を考えると、これはおそらく会社に関する興味深い情報を提供する内部wikiである可能性があります。そこで公開されている企業インターンの情報を引き出してみましょう。
- これを行うために、攻撃者は独自のウェブサイトexample.attackerをセットアップします。このサーバーは、最初に攻撃者が制御する外部IPアドレスに解決します。このドメインのDNSサーバーも攻撃者によって制御されています。このサーバーへのリンクには、興味深いフィッシングメールなどが含まれ、社内の誰かがサイトにアクセスできるようになります。
- サイトがアクセスされ、いくつかのスクリプトがダウンロードされると、攻撃者はこのサイトのIPアドレスを会社から見えるように攻撃したいサイトのIPアドレスに変更します。つまり、example.attackerは同じIPアドレス10.1に解決されます。 .2.3 wiki.example.comとして。このトリックは DNS Rebinding と呼ばれます。
- 攻撃者のサイトから既にダウンロードされたスクリプトは、example.attackerへのアクセスを試みます。このサイトは10.1.2.3に解決されるので、このリクエストは内部サーバーwiki.example.comにアクセスしますが、名前はexample.attackerです。単一のドメインでのみ使用されるサーバーは、リクエストのHostヘッダーを無視することがよくあります。そのため、両方の名前が同じIPアドレスに解決される限り、wiki.example.comだけでなくexample.attackerを使用してもサイトのコンテンツにアクセスできます。
- 同一生成元ポリシーは、IPアドレスではなくDNS名でのみアクセスを制限するため、元のexample.attackerホストから既にロードされているスクリプトは、新しいexample.attackerホストサイト（wiki.example.com）とやり取りして取得できます。このサイトからの情報とこれらの情報を攻撃者に転送します。
要約すると、ターゲットについての知識が多ければ多いほど、妥協できるようになります。スプリットDNSは、すべてのデータ漏洩から保護するための究極のソリューションではありませんが、データの少なくとも一部を保護するのに役立ちます。したがって、それは徹底的な防御の一部です。
これまで、分割DNSには多くの問題がありましたが、プログラムはttlを適切に尊重していませんでした。彼らは長い間解決をキャッシュし、DNSは一貫性がない（つまり、私のソースIPに依存している）ため、壊れます。
保護された企業ネットワークと保護されていないインターネットの両方で同じシステム（ノートブックまたはモバイル？）を使用しているようです。これは、マルウェアが企業ネットワークに移動するための簡単な方法を提供するため、非常に悪い考えです。安全な方法は、代わりに会社のノートブックを直接インターネットに接続せずに、DNSルックアップを含め、会社のネットワークを介してすべてをトンネリングする外部のときにのみVPNを使用することです。また、プライベートハードウェアは保護された企業ネットワークに接続してはならず、企業内で使用する場合は別のネットワーク内に含める必要があります。この方法で使用した場合、同じシステムで外部DNS設定と内部DNS設定を切り替えることはないため、スプリットDNSの問題も発生しません。
スプリットホライズンDNSは悪い考えです。それは基本的にDNSSECを確実に実装することを不可能にします（回避策はありますが、すべて不十分です）。
スプリットホライズンDNSの主な利点は、内部ネットワークを非表示にできることですが、サブドメインを作成し、そのSOAサーバーにパブリックネットワークからアクセスできないようにすることで、同じことが実現できます。 。
したがって、スプリットホライズンDNSではpayroll.bigcorp.comを使用し、安全なサブドメインではpayroll.i.bigcorp.comを使用します。しかし、サブドメインがあれば、実際にDNSSECを有意義に使用できます。
議論されていないスプリットDNSのもう1つの利点は、再帰です。内部DNSサーバーが再帰的な検索を実行できないようにすることをお勧めします。彼らは脆弱性を悪用する応答を受け取り、侵害されたままになる可能性があります。したがって、このタスクをオフロードして、別のDNSサーバーまたは公開されているDNSサーバーを分離します。これは、多層防御を適用し、インフラストラクチャの回復力を高めるための優れた方法です。