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

Question

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

基本的に、あなたが私たちに助けを求めているのは、これです。あなたの意図は、このマルウェア作成者とされる人物に比べれば無害ですが、それでも、ここでテクノロジーが意図したとおりに機能しているという事実は変わりません。意図に基づいてセキュリティを設計することはできません。

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

ここまで来ると、これは基本的な HTTPS ハイジャックのシナリオです。すべて同じルールが適用されます。信頼された CA を操作できる立場にある場合は、ブラウザを操作できます。それ以外は、何の役にも立ちません。

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

コメントにある sebix の提案に従ってください。この RPZ 保護の対象となるすべてのワークステーションに CA 証明書をプッシュします。これが企業の場合、これは完全に実行可能であり、最良のシナリオでは、そのような CA 証明書がすでに存在している可能性があります。
現状のまま対処することで、人々が問題のサイトにアクセスできない理由を説明できるようになります。
書き換えを変更して、Web ページがまったく取得されないようにします。Web ページに送信する代わりに、、rpz-drop.( CNAME .NXDOMAIN)、またはCNAME *.(NODATA) を使用してクエリを「受け入れ」ます。
ポート 443 の接続を常に拒否する IP アドレスを選択し、Aポリシーレベルで何が起こっているかを示すレコードをその IP アドレスに与えます。書き換え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

Answer 1