☰

https/ssl 的 DNS RPZ 中的「重定向」憑證錯誤

tag-icon • tag-icon domain-name-system https redirection rpz dns-firewall
https/ssl 的 DNS RPZ 中的「重定向」憑證錯誤

我設定了一個 DNS RPZ，當使用者嘗試存取不良網站清單時，我會使用 DNS RPZ 記錄將使用者「重定向」到圍牆花園。

假設用戶嘗試造訪 badsite.com。對於http 連接，重定向到我的圍牆花園有效，但對於https 連接，它會導致憑證錯誤，因為瀏覽器中的URL 保持不變(badsite.com)，但解析的IP 正在連接到我的圍牆花園(walledgarden.example.com)。

使用 DNS RPZ 在 https 連線上進行重定向時，有什麼方法可以解決憑證錯誤嗎？

答案1

暫時，我希望您假裝您是惡意軟體作者，已成功破壞了您公司的 DNS 伺服器。每當有人嘗試造訪銀行時，您都會嘗試使用 DNS 來提供虛假 IP 位址。不幸的是，當呼叫 HTTPS 時，您無法讓那些令人困惑的瀏覽器警告消失。

這基本上就是您要求我們幫助您的事情。與這個所謂的惡意軟體作者相比，您的意圖是良性的，但這並沒有改變該技術在這裡按預期工作的事實。您無法圍繞意圖設計安全性。

由於政策操作發生在 DNS 級別，因此無法知道發送查詢時使用者使用的是 HTTP 還是 HTTPS。您唯一可以控制的是是否要傳回 IP 位址以及該 IP 位址是什麼。

一旦您到達了這一點，這就是一個基本的 HTTPS 劫持場景。所有相同的規則均適用。如果您能夠操縱受信任的 CA，那麼您就可以操縱瀏覽器。除此之外，沒有骰子。

您在這裡有四個選擇：

  1. 請按照評論中 sebix 的建議：將 CA 憑證推送到將受到此 RPZ 保護的每個工作站。如果這是一家企業，那麼這是完全可行的，而且在最好的情況下，這樣的 CA 憑證可能已經存在。
  2. 按目前的情況處理事情，這為人們提供了一種方式來查看他們無法訪問相關網站的原因的描述。
  3. 更改您的重寫以阻止他們獲取網頁。不要將它們傳送到網頁，而是使用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

相關內容