Verhindern, dass die Websicherheits-Appliance ein offener Proxy ist

Einleitung

In diesem Dokument wird beschrieben, wie verhindert werden kann, dass die Web Security Appliance (WSA) ein offener Proxy ist.

Umwelt

Cisco WSA, alle Versionen von AsyncOS

Die WSA kann in zwei Bereichen als offener Proxy angesehen werden:

1. HTTP-Clients, die sich nicht in Ihrem Netzwerk befinden, können einen Proxy-Server verwenden.
2. Clients, die HTTP CONNECT-Anforderungen verwenden, um Nicht-HTTP-Datenverkehr durch Tunnel zu leiten.

Jedes dieser Szenarien hat völlig andere Auswirkungen und wird in den nächsten Abschnitten ausführlicher behandelt.

HTTP-Clients, die sich nicht in Ihrem Netzwerk befinden, können einen Proxy über

Die WSA fungiert standardmäßig als Proxy für alle an sie gesendeten HTTP-Anfragen. Dabei wird davon ausgegangen, dass sich die Anforderung auf dem von der WSA überwachten Port befindet (die Standardeinstellungen sind 80 und 3128). Dies kann ein Problem darstellen, da Sie möglicherweise nicht möchten, dass ein Client aus einem Netzwerk die WSA verwenden kann. Dies kann ein großes Problem darstellen, wenn die WSA eine öffentliche IP-Adresse verwendet und über das Internet auf diese zugegriffen werden kann.

Es gibt zwei Möglichkeiten, dies zu beheben:

1. Verwenden Sie eine Firewall, die der WSA vorgeschaltet ist, um nicht autorisierte Quellen vom HTTP-Zugriff fernzuhalten.
2. Erstellen Sie Richtliniengruppen, damit nur die Clients in den gewünschten Subnetzen zugelassen werden. Diese Richtlinie lässt sich einfach wie folgt demonstrieren:
   

   Politische Gruppe 1: Gilt für das Subnetz 10.0.0.0/8 (setzt voraus, dass es sich um Ihr Client-Netzwerk handelt). Fügen Sie die gewünschten Aktionen hinzu.
   Standard-Policy: Alle Protokolle blockieren - HTTP, HTTPS, FTP über HTTP

Detailliertere Richtlinien können oberhalb der Richtliniengruppe 1 erstellt werden. Solange andere Regeln nur für die entsprechenden Client-Subnetze gelten, wird der gesamte andere Datenverkehr die Regel "Alle verweigern" am unteren Rand abfangen.

Clients, die HTTP CONNECT-Anforderungen zum Tunneling von Nicht-HTTP-Datenverkehr verwenden,

HTTP CONNECT-Anfragen werden verwendet, um Nicht-HTTP-Daten über einen HTTP-Proxy zu tunneln. Die gängigste Verwendung einer HTTP CONNECT-Anforderung ist das Tunneln von HTTPS-Datenverkehr. Damit ein explizit konfigurierter Client auf eine HTTPS-Site zugreifen kann, MUSS er zunächst eine HTTP CONNECT-Anforderung an die WSA senden.

Ein Beispiel für eine CONNECT-Anforderung ist: VERBINDEN http://www.website.com:443/ HTTP/1.1

Dadurch wird die WSA informiert, dass der Client einen Tunnel durch die WSA zu http://www.website.com/ an Port 443 erstellen möchte.

HTTP CONNECT-Anforderungen können zum Tunneling beliebiger Ports verwendet werden. Aufgrund potenzieller Sicherheitsprobleme lässt die WSA standardmäßig nur CONNECT-Anfragen an diese Ports zu:

20, 21, 443, 563, 8443, 8080

Wenn aus Sicherheitsgründen weitere CONNECT-Tunnel-Ports hinzugefügt werden müssen, wird empfohlen, diese einer zusätzlichen Richtliniengruppe hinzuzufügen, die nur für die Client-IP-Subnetze gilt, die diesen zusätzlichen Zugriff benötigen. Die zulässigen CONNECT-Ports finden Sie in jeder Richtliniengruppe unter Anwendungen > Protokollsteuerung.

Ein Beispiel für eine SMTP-Anforderung, die über einen offenen Proxy gesendet wurde, finden Sie hier:

myhost$ telnet proxy.mydomain.com 80
Trying xxx.xxx.xxx.xxx...
Connected to proxy.mydomain.com.
Escape character is '^]'.
CONNECT smtp.foreigndomain.com:25 HTTP/1.1
Host: smtp.foreigndomain.com
HTTP/1.0 200 Connection established
220 smtp.foreigndomain.com ESMTP
HELO test
250 smtp.foreigndomain.com