Zertifikatsfehler bei „Umleitung“ in DNS RPZ von https/ssl

Question

Ich habe eine DNS-RPZ eingerichtet, bei der ich Benutzer mithilfe von DNS-RPZ-Einträgen zu einem Walled Garden „umleite“, wenn sie versuchen, auf eine Liste mit schädlichen Websites zuzugreifen.

Angenommen, ein Benutzer versucht, auf badsite.com zuzugreifen. Die Umleitung zu meinem Walled Garden für HTTP-Verbindungen funktioniert, aber bei HTTPS-Verbindungen verursacht sie Zertifikatsfehler, da die URL im Browser dieselbe bleibt (badsite.com), die aufgelöste IP jedoch eine Verbindung zu meinem Walled Garden herstellt (walledgarden.example.com).

Gibt es eine Möglichkeit, die Zertifikatsfehler bei der Verwendung von DNS RPZ zur Umleitung bei https-Verbindungen zu beheben?

Answer 1

Stellen Sie sich für einen Moment vor, Sie seien ein Malware-Autor, der die DNS-Server Ihres Unternehmens erfolgreich manipuliert hat. Sie versuchen, DNS zu verwenden, um falsche IP-Adressen bereitzustellen, wenn jemand versucht, eine Bank zu besuchen. Leider können Sie diese verwirrenden Browserwarnungen nicht ausblenden, wenn HTTPS aufgerufen wird.

Im Grunde bitten Sie uns um Hilfe. Ihre Absichten sind im Vergleich zu diesem angeblichen Malware-Autor harmlos, aber das ändert nichts an der Tatsache, dass die Technologie hier wie vorgesehen funktioniert.Sie können Sicherheit nicht anhand von Absichten konzipieren.

---

Da die Richtlinienaktion auf DNS-Ebene erfolgt, gibt es keine Möglichkeit zu wissen, ob der Benutzer zum Zeitpunkt des Sendens der Abfrage HTTP oder HTTPS verwendet. Das Einzige, was Sie steuern können, ist, ob Sie eine IP-Adresse zurückgeben und wie diese IP-Adresse lautet.

Wenn Sie an diesem Punkt angekommen sind, handelt es sich um ein grundlegendes HTTPS-Hijacking-Szenario. Es gelten dieselben Regeln. Wenn Sie in der Lage sind, die vertrauenswürdigen Zertifizierungsstellen zu manipulieren, können Sie auch die Browser manipulieren. Ansonsten ist alles erfolglos.

Sie haben hier vier Möglichkeiten:

1. Folgen Sie dem Vorschlag von sebix in den Kommentaren: Senden Sie ein CA-Zertifikat an jede Arbeitsstation, die diesem RPZ-Schutz unterliegt. Wenn es sich um ein Unternehmen handelt, ist dies durchaus machbar und im besten Fall existiert ein solches CA-Zertifikat möglicherweise bereits.
2. Behandeln Sie die Dinge so, wie sie jetzt sind. So können die Leute eine Beschreibung sehen, warum sie die betreffende Site nicht erreichen.
3. Ändern Sie Ihre Umschreibung, um zu verhindern, dass sie überhaupt eine Webseite erhalten. Anstatt sie an eine Webseite zu senden, „fressen“ Sie die Abfrage mit rpz-drop., CNAME .(NXDOMAIN) oder CNAME *.(NODATA).
4. Wählen Sie eine IP-Adresse, die die Verbindung über Port 443 immer ablehnt, und fügen Sie ihr einen AEintrag hinzu, der angibt, was auf Richtlinienebene vor sich geht. Lassen Sie Ihre Neufassung CNAMEauf diesen Eintrag verweisen. Dies gibt einem Techniker zumindest eine Art Orientierungshilfe, wenn er mit der Fehlerbehebung beginnt. Natürlich sind diese Techniker in der Minderheit, aber es ist besser als nichts.

Ein Beispiel für Nr. 4 wäre etwa das Folgende:

# 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