web-dev-qa-db-ja.com

https / sslのDNSRPZでの「リダイレクト」に関する証明書エラー

ユーザーが不良サイトのリストにアクセスしようとしたときに、DNS RPZレコードを使用して、ユーザーを壁に囲まれた庭に「リダイレクト」するDNSRPZを設定しました。

ユーザーがbadsite.comにアクセスしようとしたとします。 http接続のウォールドガーデンへのリダイレクトは機能しますが、https接続の場合、ブラウザーのURLは同じままであるため（badsite.com）、解決されたIPはウォールドガーデンに接続しているため（walledgarden.example.com）、証明書エラーが発生します。

Https接続でリダイレクトにDNSRPZを使用するときに証明書エラーを解決する方法はありますか？

domain-name-systemhttpsredirectionrpzdns-firewall
1
thelok

しばらくの間、あなたがあなたの会社のDNSサーバーを侵害することに成功したマルウェアの作者であるふりをしてほしい。誰かが銀行に行こうとするたびに、DNSを使用して偽のIPアドレスを提供しようとしています。残念ながら、HTTPSが呼び出されたときに、これらの混乱したブラウザの警告を消すことはできません。

それは基本的にあなたが私たちにあなたを助けるように頼んでいるものです。この想定されるマルウェア作成者と比較して、あなたの意図は良性ですが、テクノロジーがここで意図したとおりに機能しているという事実は変わりません。 インテント周辺のセキュリティを設計することはできません。

ポリシーアクションはDNSレベルで発生するため、クエリの送信時にユーザーがHTTPとHTTPSのどちらを使用しているかを知る方法はありません。制御できるのは、IPアドレスを返すかどうか、およびそのIPアドレスが何であるかだけです。

この時点に到達したら、これは基本的なHTTPSハイジャックシナリオです。すべて同じルールが適用されます。信頼できるCAを操作する立場にある場合は、ブラウザーを操作できます。それ以外は、サイコロはありません。

ここには4つのオプションがあります。

  1. コメントのsebixの提案に従ってください。このRPZ保護の対象となるすべてのワークステーションにCA証明書をプッシュします。これが企業の場合、それは完全に実行可能であり、最良のシナリオでは、そのようなCA証明書がすでに存在している可能性があります。
  2. 現状のままで対処することで、問題のサイトにアクセスできない理由の説明を人々が確認できるようになります。
  3. 彼らがウェブページをまったく取得しないようにあなたの書き直しを変更してください。それらをWebページに送信する代わりに、rpz-drop.、CNAME .（NXDOMAIN）、またはCNAME *.（NODATA）を使用してクエリを「食べる」。
  4. ポート443接続を常に拒否するIPアドレスを選択し、ポリシーレベルで何が起こっているかを示唆するAレコードを与えます。リライトCNAMEにこのレコードをポイントさせます。これにより、少なくとも技術者はトラブルシューティングを開始するときに、ある種のパンくずリストを見つけることができます。明らかに、これらの技術者は少数派になりますが、何もないよりはましです。

＃4の例は次のようになります。

# RPZ zone file
$Origin example.rpz.
badsite IN CNAME filtered-malware-site.example.com.

# normal zone file
$Origin example.com.
filtered-malware-site IN A 203.0.113.1
1
Andrew B