HTTP-Prox – Windows-Update schlägt fehl

[isential gmbh]

Hallo!

Ich nutze die Firmware "UTM v11.7 - 11.7.1 (Final)" und habe Probleme mit dem HTTP-Proxy. Ob die Probleme mit der Firmwareversion zusammenhängen, kann ich nicht sagen, denn ich habe dummerweise beim Konfigurieren zunächst ein Update auf die neueste Version durchgeführt.

Gefordert ist, dass sowohl http als auch https ausschließlich über den Proxy gehen. Zusätzlich soll die Nutzung des Proxy (bis auf gewollte bzw. notwendige Ausnahmen) immer mit Authentifizierung erfolgen. Dazu habe ich folgende Schritte durchgeführt:

• Windows-Domäne eingebunden (keine lokalen Benutzer).
• Transparenter Modus abgeschaltet.
• SSL-Interception abgeschaltet (funktioniert eh nicht wirklich rund).
• Eine Benutzergruppe erstellt, der die Domänen-Benutzer angehören. Als einzige Berechtigung "HTTP-Proxy" angegeben.
• HTTP-Proxy auf 8080 und Authentifizierungsmethode auf NTLM gesetzt. 
• Unterschiedliche Authentifizierungsausnahmen eingegeben.Unter anderem:
  

  Code: Alles auswählen

  ^[^:]*://(|.*\.)microsoft\.(com|de)([:/\&#].*|)
  ^[^:]*://(|.*\.)windowsupdate\.com([:/\&#].*|)

• Darüber hinaus habe ich die Seiten in der Whitelist des Virenscanners aufgenommen, aus denen man Updates und Virendefinitionen holt. U. a. auch Windows-Update:
  

  Code: Alles auswählen

  ^[^:]*://(|.*\.)windowsupdate\.com([:/\&#].*|)

• Um das Anforderungsprofil zu erfüllen, http und https ausschließlich über den Proxy zu leiten, habe ich folgende Regeln eingerichtet und ganz nach vorne gesetzt:
  

  Code: Alles auswählen

  internal network => internal interface => proxy
  internal interface => internet => any => hn => accept
  internal network => internet => http => drop
  internal network => internet => https => drop
  internal network => internet => any => hn => accept

Damit erreiche ich ohne Änderungen im Netzwerk bzw.. an den Clients und ohne GPO-Gefrickel, genau das, was ich wollte: Beide Protokolle werden ausschließlich über den Proxy geleitet.
Ich hoffe, es ist bis hierher alles klar. Nun zu einem meiner Probleme:

Windows Update schlägt ständig fehl. Ich kann das Problem nachstellen, indem ich http://windowsupdate.com (ohne "s")in die Adresszeile des Browsers eingebe. ICh bekomme vo der Firewall folgende Fehlermeldung zurück:

Zugriff gesperrt
Der Zugriff zu dieser Webseite ist nicht möglich.
Der Securepoint Content Filter hat die von Ihnen aufgerufene Webseite gesperrt, da Filtereinstellungen den Zugriff verbieten.

Sollte der Zugang irrtümlich blockiert sein, wenden Sie sich bitte an den Administrator ihrer Securepoint UTM.

OK, ich deaktiviere den Content-Filter und versuche es erneut. Dann werde ich mit folgender Fehlermeldung beglückt:

ERROR
The requested URL could not be retrieved
The following error was encountered while trying to retrieve the URL: http://windowsupdate.com/

Unable to determine IP address from host name windowsupdate.com

The DNS server returned:

No DNS records

This means that the cache was not able to resolve the hostname presented in the URL. Check if the address is correct.
Your cache administrator is webmaster.

Wenn ich auf "webmaster" klicke, will mein Mail-Client folgende E-Mail senden:

CacheHost: firewall.isential.local
ErrPage: ERR_DNS_FAIL
Err: [none]
DNS ErrMsg: No DNS records
TimeStamp: Tue, 16 May 2017 20:06:01 GMT
ClientIP: 192.168.70.8
HTTP Request:
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Host: windowsupdate.com

Wenn ich stattdessen https://windowsupdate.com (mit "s") eingebe, geht es weiter und ich lande auf einer Microsoft-Seite. Dasselbe passiert auch mit anderen Seiten, die von http auf https redircten: Gebe ich die Adresse mit nur http ein (ohne "s"), kommt die Fehlermeldung, wird dies von der Firewall verhindert (wie oben beschrieben).

Da Windows-Update über http (ohne "s") durchgeführt wird, vermute ich, dass es gerade deswegen fehlschlägt. Aber warum? Die Ausnahmen sind syntaktisch richtig, so dass sie greifen sollten.

Nun hat sich die Firewall halb aufgehängt und da ich sie gerade über eine VPN-Verbindung fernwarte, kann ich Sie nicht kaltstarten. Ein Neustart über die Web-Oberfläche reagiert nicht – es kommt immer wieder die beschriebene Fehlermeldung des Proxy. Auch die Anwendunge werden nicht mehr im Fenster "Anwendungsstatus" angezeigt, womit ich den Proxy manuell nicht sneu starten kann. Also Feierabend...

Morgen mache ich weitere Tests und berichte ich dann weiter. Bis dahin kann mir vielleicht einer der Experten weiterhelfen.

Schönen Dank und bis dahin!

René

[isential gmbh]

Ach tja, noch eine Beobachtung:

Eine Seite in der Form https://vserver4711.provider.tld:8443 (Plesk) wird ebenfalls von der Firewall abgewiesen. Lasse ich den Port weg, so funktioniert die Adresse, erreiche aber den sich hinter dem Port lauschenden Dienst nicht. Ich glaube, Ich mach' Urlaub!

[isential gmbh]

Nun verwirrt mich die Firewall. Ich bin in die Firma gekommen und habe die Firewall nach dem gestrigen Hänger neu gestartet. Jetzt funktionieren die Windows-Updates wieder. Nun weiß ich nicht, ob die Firewall die gesamte Zeit gesponnen hat oder ob der Dienst Windows-Updates gestern Abend ein Problem hatte.

Ich habe den Eindruck, dass der Proxy nicht immer neue Einträge bzw. Konfigurationsänderungen sofort zuverlässig übernimmt. Kann das jemand bestätigen?

Es wäre toll, wenn jemand ein bisschen Licht ins Dunkel bringen könnte.

Auch über User-Erfahrungen mit dem Proxy würde ich mich freuen.

Vielen Dank!

René

[isential gmbh]

Wahrscheinlich zu früh gefreut. Das Update vom "Windows Defender" war erfolgreich und ließ mich jubeln, die Ernüchterung kam dann mit dem Abruf der Windows Updates. Einige gehen, dann melden andere Fehler. Jetzt hat das Windows-Update zwei Updates herunterladen können, verharrte aber mehrere Minuten bei 100%, um dann folgende Fehlermeldung zu bringen:

Fehler Windows-Update

Die Firewall meldet folgendes (nach "update" abgegrenzt):

Firewall-Meldungen

Nun, wo liegt der Haken?
Schönen Dank im Voraus!
René

[kennethj]

Hallo,

haben Sie einen festen Proxy mit Authentifizierung auf der UTM eingeirchtet? (407 -> Proxy Authentification Required.)
Wenn ja finden Sie hier die Lösung. (Szenario 2)

Gruß

[isential gmbh]

Ja, das habe ich. Ich habe auch die Authentifizierungsausnahmen auch gemacht (ein bisschen anders):

Code: Alles auswählen

^[^:]*://(|.*\.)microsoft\.(com|de)([:/\&#].*|)
^[^:]*://(|.*\.)windowsupdate\.com([:/\&#].*|)

Damit erfasse ich als Authentifizierungsausnahme die Domänen microsoft.com, microsoft.de und windowsupdate.com (auf die will ich immer drauf kommen, mit oder ohne Authentifizierung). Für die Whitelist des Virenscanners nehme ich dann andere, die nur die Updateserver erfassen.

Allerdings erfassen meine Ausnahmen folgenden Link nicht: www.msftncsi.com

Aber auch ohne diesen Link hat es heute, wenn auch holprig, funktioniert. Das verwirrt mich. Nichtsdestotrotz trage ich diese Ausnahme ein:

Code: Alles auswählen

^[^:]*://(|.*\.)msftncsi\.com([:/\&#].*|)

Für die fehlende Ausnahme nehme ich gleich die gesamte Domäne.

Nun beobachte ich, wie sich das schlägt, bin jedoch sehr zuversichtlich.

Vielen Dank!

René

[isential gmbh]

Nachdem alles so geschmeidig lief, tauche aus heiterem Himmel der Fehler mit Windows-Update auf. Das verstehe ich aber jetzt gar nicht mehr, denn den Einstellungen nach, müsste es funktionieren.

Ich habe in den Protokollen gesehen, das eine URL geblockt wurde, welche einen Download imitieren sollte. Folgende Meldung gibt die Firewall im Browser aus, wenn ich diese URL eingebe:

Zugriff gesperrt
Der Zugriff zu dieser Webseite ist nicht möglich.
Der Securepoint Content Filter hat die von Ihnen aufgerufene Webseite gesperrt, da Filtereinstellungen den Zugriff verbieten.

Sollte der Zugang irrtümlich blockiert sein, wenden Sie sich bitte an den Administrator ihrer Securepoint UTM.

Hier die URL:

Code: Alles auswählen

http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/pinrulesstl.cab?7020497bb5764ed7

Unter anderem habe ich folgenden regulären Ausdruck als a) Authentifizierungsausnahme, b) Webseiten-Whitelist im Virenscanner und c) im Webfilter als Regel für "internal-networks":

Code: Alles auswählen

^[^:]*://(|.*\.)windowsupdate\.com([:/\&#].*|)

Dieser reguläre Ausdruck trifft auf die URL auf jeden Fall zu und dennoch meldet die Firewall in ihrem Log folgendes:

Code: Alles auswählen

17.05.2017 19:26:22    spfilter    BLOCKED ip="192.168.70.8", host="192.168.70.8", usr="-", grp="3", cat="", cat_all="", act="URLLIST", srv="213.128.147.51", url="http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/pinrulesstl.cab?7020497bb5764ed7"

17.05.2017 19:26:22    HTTP-Proxy (squid)    1495041982.325 8 192.168.70.8 TCP_MISS/403 3013 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/pinrulesstl.cab? - HIER_DIRECT/192.168.70.254 text/html

Ich verstehe es nicht. Es sieht so aus, als ob der Webfilter gar nicht matchen würde. Oder wie verstehe ich die Zeile mit "BLOCKED"?

Wie es aussieht, brauche ich doch noch Hilfe.

Im Voraus vielen Dank!

René

[kennethj]

Hallo,

korrekt der Webfilter greift nicht - liegt daran dass dieser im Webinterface keine Regulären Ausdrücke kann.(Sondern nur mit Whitecards *)

Gruß

[isential gmbh]

Ach du meine Güte! Der Sinn erschließt sich mir nicht. Ich möchte erst gar nicht wissen, wie viele User auf die Falle getappt sind. Nun werde ich versuchen, das mit Wildcards zu lösen – das kann aber schon gefährlich werden, denn man kann damit nicht so fein eingrenzen und wenn man nicht aufpasst, rutscht das eine oder andere durch.

Ist das by Design so oder kommt irgendwann auch eine Unterstützung von regulären Ausdrücken?

Schönen Dank für die schnelle und präzise Hilfe!

René

[David]

Hoi Rene,
das ist aktuell nicht geplant.