ホストヘッダーを使用してサービスの存在を隠すことはできますか？

Question

93.184.216.34で実行されているWebサーバーを想像してください。通常、パブリックDNSエントリexample.comを介して到達可能です。通常、Webサーバーでは、HTTPリクエストで受信したHostヘッダーに基づいて、複数の「仮想」サーバーを区別できます。

同じWebサーバーがcx6wdffpuik997eljf6d878i6f3np4207ne30vyjsvhpra69を介して要求されたときに、パブリックDNSエントリではなく、ローカルDNSサーバーまたは変更されたホストファイルを介して行われる別のサービスを提供するとします。

これは隠されたサービスの存在を効果的に隠しますか？これは実際に行われていますか？

注：これを単独で使用してサービスを保護することはできません。さらに、クライアント証明書による認証も行われます。

Esa Jokinen · Accepted Answer

同じIPアドレスで他の名前ベースの仮想ホストを決定する唯一の方法は、すべてのドメインに対して前方参照を実行し、同じIPアドレスを持つAレコードを確認することです。その後のみ、サーバーがHostヘッダーを介してこれらすべてのホスト名に応答しているかどうかを確認でき、すべてのホスト名に対して応答が同じであるか、異なるサービスがあるかどうかを確認できます。

これを知っていると、このようなサービスを非表示にすることは確かに可能ですが、それでもobcursityによるセキュリティです。誰かがこれを使用しているかもしれませんが、いくつかの欠点があります：

秘密のホスト名が誤って漏洩する可能性があり、「Host:ヘッダー」はパスワードとしては不適切な場所になります。これは次の原因で発生する可能性があります：
- サードパーティのDNSサービスを介したリクエスト。 DNSが通常は暗号化されておらず、複数の再帰サーバーにキャッシュされる可能性があることは、これをそれほど悪くはしません。
- ホスト名が信頼できるパブリックDNSサーバー上にある場合、不十分な ゾーン転送 制限またはDNSSEC ゾーンウォーキング （古いNSECレコードで可能、NSEC3、 RFC 5155 ＆で修正済み） RFC 6781、5 ）。
- Server Name Indication（SNI、 RFC 6066、3 ）は、1.3より前のすべてのTLSバージョンで暗号化されていないClientHelloの一部であるため、ホスト名を明らかにします（暗号化されたSNIの仕組み）。
ホスト名がどのように漏洩したかに応じて、どのIPアドレスに接続するかを知る必要があるかもしれませんが、それは単に速度低下です。
- Aレコードがプライベートネットワーク上のDNSサーバーでのみ利用可能である場合、IPアドレスは非表示になりますが、その場合、ネットワークの外部でサービスを使用することが難しくなります。その場合は、プライベートネットワーク上のサービスも。
- IPアドレスがローカルのhostsファイルにある場合は、IPパケットヘッダーでネットワークレイヤー（L3）のトラフィックを見ることができるすべてのユーザーが引き続き使用できます。これには、DNS要求またはSNIを監視してホスト名をすでに取得している人も含まれます。
TLS実装の難しさ。
- 任意の偽のアドレスの証明書は取得できません。
- 実際のドメインのサブドメインだった場合...
  - サブドメインに対して発行された証明書は、 Certificate Transparency を介してホスト名を明らかにします（例： https://crt.sh/?q=example.com ）
  - 例えばLet's Encryptでは、ACMEチャレンジで公開する必要があります。
- これを回避する適切な方法は、です。
  - 独自の内部認証局
  - 「シークレット」サブドメインをカバーするワイルドカード証明書*.example.com.

それが解決するよりも多くの問題を作成するので、私はそれをお勧めしません。多要素認証によるパスワード保護と可能なクライアント証明書はより良いオプションであり、サービスの場所によって、セキュリティが大幅に向上するわけではありません。

James_pic · Answer

これは、まさにあなたが説明した状況ではありませんが、ドメインフロインティングは、ホストヘッダーを悪用して通信の本来の性質を隠す例です。通常、ファイアウォールを回避するためです。

ドメインフロンティングの基本的なセットアップは次のとおりです。

Innocuous.example.comに対してDNSリクエストを行います
返されたIPアドレスへのSSL接続を開き、innocuous.example.comをSNIのアドレスとして指定します。
暗号化された接続を介して、ホストsuspicious.example.comに対してHTTPリクエストを行います

ファイアウォールが認識している限り、これは許可されているinnocuous.example.comへの接続です。ただし、サーバーがsuspicious.example.comとinnocuous.example.comのトラフィックを処理するように構成されている場合（たとえば、両方が同じCDNによって処理されている場合など）、応答を処理します。 suspicious.example.comの場合。

ほとんどの実際の使用例では、suspicious.example.comの存在が秘密である可能性は低いことに注意してください。ドメインフロンティングは通常、正当であるがファイアウォールによってブロックされているサイトにアクセスするために使用されます。

疑わしいWebサイトを目に見えないように隠すシステムを設計している場合は、 https://innocuous.example.com/cx6wdffpuik997eljf6d878i6f3np4207ne30vyjsvhpra69 でホストする方がはるかに簡単です。 DNSまたはSNIリークを心配します。

ThoriumBR · Answer

それは働くことができます-しばらくの間...

直接解決できないドメインのHostヘッダーがあると、正しいヘッダーとIPを知らない人がサービスを開くことができなくなります。これは、シークレットドメインとIPの両方がリークするまで機能します。これには時間がかかる場合があります。

Esa Jokinen がすでに指摘している外部DNSおよび証明書の透過性の他に、Refererヘッダーがあります。

非表示のサイト（画像、JavaScript）にany外部リンクまたはリソースがある場合、クライアントブラウザはRefererを隠しドメインなので、リンクしたサイトはその存在を知っています。

しかし、それは問題の一部にすぎません。ドメインを知っていても、サーバーのIPアドレスがわからない場合は何も意味がなく、誤って漏洩することはさらに困難です。

クライアント側のリークはシークレットドメインをリークしますが、サーバーのIPアドレスはサーバー側から（またはどこかでIPとシークレットドメインの両方を公開している誰かによって）リークされる必要があります。そして、これを明らかにする方法は、引き出すのがより困難です。

Torシークレットサービスの場合、攻撃するためにサーバーのIPを知る必要はありません。TorはIPを必要とせずにサーバーに接続します。しかし、非表示のサービスでは、後で何らかの方法でサーバーを攻撃してIPを取得できるようにするには、まずサーバーに接続する必要があります。ただし、IPなしでは接続できず、IPを取得するにはIPが必要です。

サーバーを見つける方法は？ Bruteforce ...生きているすべてのパブリックIPに接続し、シークレットドメインを含むHostヘッダーを送信して、何が返されるかを確認します。しばらくかかることがありますが、見つかります。

セキュリティはあいまいなため、これだけに頼るわけではありませんが、この場合は非常にあいまいです。