weiter Windows Update Fehler 80072f8f trotz deaktivertem Proxy

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
Junioruser1976
Beiträge: 37
Registriert: Di 02.07.2019, 07:43

weiter Windows Update Fehler 80072f8f trotz deaktivertem Proxy

Beitrag von Junioruser1976 »

Hallo,

hier ist mal wieder der Securepointneuling mit seiner Übungsumgebung eines Rechners mit Proxy:-)

Proxy incl SSL interception + Webfilter funktionieren jetzt grundsätzlich- soweit so gut:  konnte mir über den Webfilter einzelne Sites schonmal sperren und https läuft jetzt auch durch und ist aufrufbar über Proxy...

Nun bin ich grad dabei, die Konfiguration für erfolgreiche Updates von Windows und Virenscanner zu integrieren und damit die ersten Erfahrungen zu sammeln praktisch in meiner Musterumgebung: 

Anscheinend war noch irgendein kleiner Fehler in der Konfi bei den Ausnahmen drin- denn Windows Update lief ab dann über diesen Rechner  dann leider nicht mehr- es kam die  Fehlermeldung 80072f8f.

Ich wollten dann erstmal den Rechner aktualisieren um danach weiter zu üben und in Ruhe den Fehler zu finden.

Ich hatte dafür den Client einfach in der Firewall wieder auf any gestellt im Portfilter , Proxy aus und meinte, damit den Proxy komplett umgehend umgehen zu können. Leider zeigte sich weiter der genannte Fehler. Synchronisierung mit time.windows.com ließ sich aufrufen, Zeiten waren auch korrekt auf allen Ebenen.

Ich habe dann auf der UTM eine alte Konfiguration, die zeitlich noch VOR Konfiguration von Zertifitkat und Proxy komplett lag.

Aber auch dann gab es zunächst diesen Fehler weiterhin. Auch an den lokalen Einstellungen am Client selbst schien es eher nicht zu liegen: hatte jedenfalls zum test einen weiteren Übungsclient ins gleiche Netz hinter die FW gepackt- und auch hier gleiche Fehlermeldung.

Ich habe daraufhin Neustart der Firewall mit dieser alten Konfiguration "ohne Proxy" noch zusätzlich gemacht- danach war der Fehler weg und Updates liefen wieder durch.

Hatte sich da nur die Verbindung zu einem Windows-Zeitdienst o.ä. aufgehängt unplanmäßig (u.a. auch , weil der betreffende Client wegen meines Urlaubs 2 Wochen komplett aus war)  oder kann ich allgemein daraus mir merken, dass der grundlegende Wechsel von "mit Proxy" zurück zu any oder gravierende Änderungen in der Proxykonfiguration o.ä. besser immer einen Neustart zwischendrin erfordern?

Oder anders gesprochen: reicht eigentlich -außer die FW hängt sich auf- immer Regeln aktualisieren und speichern- oder empfehlen Sie und wenn ja wann immer wieder mal zwischendrin einen Neustart?

Viele Grüße

friede
Beiträge: 13
Registriert: Do 25.07.2019, 12:23

Beitrag von friede »

Hi,

Wenn du über den Proxy gehst, ist es egal, ob du eine Any-Regel drin stehen hast. Entscheidend ist die Regel, die den Zugriff auf das interne Interface mit Proxy-Diensten erlaubt.
Mit Windows-Updates haben wir auch unsere leidlichen Erfahrungen gemacht. Ende vom Lied: Festen Proxy rein, nicht transparent. In der Firewall gibt es dann logischerweise keine http/https-Regel vom internen Netz nach internet.
Die SSL-Interception bleibt bei uns mittlerweile aus. Durch den festen Proxy werden auch zuverlässig Https-Anfragen durch den Webfilter geschickt.

Junioruser1976
Beiträge: 37
Registriert: Di 02.07.2019, 07:43

Beitrag von Junioruser1976 »

Hi,

vielen Dank. Das ist schonmal wieder ein wichtiger Praxis-Hinweis, dass es besser geht mit festen Proxy. Werde es so dann nochmal jetzt so probieren mal sehen, was dann passiert und ob es jetzt klappt mit den Updates.

Das mit "SSL Interception aus und trotzdem werden dann bei festem Proxy Https-Anfrage durch den Webfilter geschickt" , ist mir aber leider noch weiter nicht so klar -das hatte ich bislang genau anders verstanden, dass das grad nicht geht dann für https+ Proxy- und dass dann SSL interception in jedem Fall an sein muss, damit das auch für https funktioniert.

Wenn ich SSL dann rausnehme, schreiben Sie ja, geht es trotzdem zumindest jedenfalls noch durch den Webfilter- gilt das dann auch für den Virenscanner- oder anders gefragt: was genau prüft dann die Firewall bei https mit der SSL Interception noch darüber hinaus- also worauf verzichte ich, wenn ich das dauerhaft deaktiviere?

Viele Grüße

friede
Beiträge: 13
Registriert: Do 25.07.2019, 12:23

Beitrag von friede »

Hi,

wenn man den gesamten Traffic über den eingetragenen Proxy leitet, arbeitet der Webfilter auch auf HTTPS-Seiten, dazu muss die SSL-Interception nicht eingeschalten sein. Die Block-Seite kann lediglich anders aussehen.
Der Virenscanner etc. funktioniert dann leider nicht, lediglich der Webfilter.

Egal wie du dich entscheidest, wenn du deine Clients im Netzwerk administrieren kannst, würde ich immer einen fest eingetragenen Proxy bevorzugen, egal ob mit oder ohne SSL-Interception. Beim transparenten Proxy fängt man dann schnell mit zig Ausnahmen an. Wenn du nur im festen Modus arbeitest, funktioniert dein Programm oder es funktioniert nicht, Wenn es nicht funktioniert muss man prüfen, ob der Zielserver und -dienst fest sind, dann kann man im Webfilter die entsprechende Ausnahme setzen un diesen Traffic direkt rausschicken. Die Erfahrung hat aber gezeigt, dass die meisten Programme mittlerweile eigene Proxy-Einstellungen haben oder den Systemproxy verwenden (unter Windows unter "Internetoptionen").

Junioruser1976
Beiträge: 37
Registriert: Di 02.07.2019, 07:43

Beitrag von Junioruser1976 »

Hi,

vielen Dank für die ergänzende Erklärung- hab jetzt mal mit festem Proxy  eine Konfiguration auf meinem Musterrechner aufgesetzt und nur noch die Windows und Trend-Microausnahmen im Webfilter rein- mal sehen, ob es jetzt mit den Updates klappt.
Und die Erfahrung, dass ggf. "Webfilter verhindert zugriff" verschieden anzeigt, hab ich auch ausprobiert: im Firefox sieht es anders auch als z.B bei IE oder Chrome.

Grüße und ein schönes Wochenende

Bjoern
Securepoint
Beiträge: 685
Registriert: Mi 03.07.2013, 10:06

Beitrag von Bjoern »

Hallo,

mit der Version 11.8.x kann man den Webfilter auch für https im transparenten Modus laufen lassen. Dazu muss aber die SSL-Interception wieder aktiviert werden mit dem Zusatz "Webfilter basiert:". Ab der Version 11.8 bricht die Firewall nicht gleich die https Pakte auf sondern liest den SNI Wert aus. Anhand des Wertes wird dann mit dem Webfilter verglichen ob die Seite geblockt werden soll oder nicht. Es wird nur interceptet wenn die Webseite geblockt werden soll.

Sollte jedoch gewünscht werden das auch HTTPS Seiten auf Viren gescannt werden sollen bleibt nur die reine SSL-Interception über. Dieses würde ich nie im transparenten Modus machen nur mit festem Proxy da man hier per Regex die Webseiten davon ausnehmen kann.

Gruß Björn

Junioruser1976
Beiträge: 37
Registriert: Di 02.07.2019, 07:43

Beitrag von Junioruser1976 »

Hallo,

sorry, hat etwas gedauert- aber kann jetzt weitere Erfahrungen berichten, aus denen sich aber auch noch wieder ein paar neue Fragen noch ergeben haben:

Habe jetzt in den letzten 2 Monaten mit verschiedenen Testkonfigurationen gearbeitet:

Testkonfi 1:
Fester Proxy und ohne SSL:
läuft, aber Windows hat immer noch trotz aller ordnungsgemäß eingepflegten Windowsausnahmen die Serviceregistration tagesaktuell verloren, die dann immer mit https://aka.ms/diag_wu wiederhergestellt werden musste- Updates an sich liefen aber wieder durch

Testkonfi 2:
Nochmal 2. Neuer Versuch: alleiniger Transparenter Proxy + SSL Interception+ Zertifikate:
in dieser Kombination ging wie schon im Juli im ersten Versuch auch (also lag es wohl eher nicht an einem Schreibfehler bei den Regex/URLAusnahmen)- es kam wieder Fehlermeldung 80072F8F bzw. 80070057. Die ließ sich aber nicht mit Reparaturtools beheben. Bzw. Meldung „Zur Zeit keine Updates möglich“.

Testkonfi 3:
Konfiguration von Test 2  und ZUSÄTZLICH Systemproxy im Internetexplorer/Etch eingerichtet, weil ich in einem früheren Beitrag  im Forum (https://support.securepoint.de/viewtopic.php?f=27&t=6263&p=15387&hilit=Windows+update#p15387) gelesen hatte, dass, warum auch immer „die Ausnahmen von SSL für Windows nur bei festem Proxy funktionieren“. Es hat dann eine Weile noch nach Speicherung dieser ergänzenden Änderung gedauert- aber dann liefen die Updates problemlos durch, keine Fehlermeldungen mehr.
Hab das ganze in den Logfiles parallel beobachtet: interessant ist, dass der spfilter  „exit“ und dann Contentfilter starting meldete und direkt danach dann Windows Gesamt durchlief regulär. Seither bislang  stabil und funktioniert.

Frage 1:
warum hat sich der Webfilter 1x aufgehängt und neu gestartet? Oder ist das normales Prozedere bei Änderungen wie dieser hier?
Frage 2:
Kann es sein, dass die Firewall für Änderungen im Bereich Proxy fest/transparent bzw. Webfilterkonfigurationsänderungen immer etwas ich  nenn das mal "Zeit zum Verdauen“ braucht, bevor die Änderung nach Speicherung wirklich effektiv greift?
Frage 3:
Gibt es eine allgemeine Empfehlung, die Firewall nach Änderungen regelmäßig neu zu starten oder zumindest einzelnen Dienste geplant neu zu starten nach bestimmten Änderungen vorsorglich, oder sollte das eigentlich nicht nötig sein?
Frage 4:
Kann ich aus den Erfahrungen jetzt mitnehmen, dass für das ordnungsgemäße Funktionieren von Windows Updates IMMER ein fester Systemproxy erforderlich ist und dass man sonst nur noch die Möglichkeit hätte, die Windowsserver alle als Netzwerkobjekte anzulegen und sie dann vom transparenten Modus als Regel zu exkluden?

Viele Grüße
 

Bjoern
Securepoint
Beiträge: 685
Registriert: Mi 03.07.2013, 10:06

Beitrag von Bjoern »

Hallo,

zu den 4 Fragen.
1. Müsste man sich näher ansehen.
2. Änderungen am HTTP Proxy haben im Anschluss immer ein Dienst neustart. Dadurch kommt es vor als würde es etwas brauchen. Änderungen am Webfilter sind auch immer gleich da. Hier kommt es nur vor das die Browser sich sehr viel aus dem Cache ziehen und keine neue Anfrage schicken.
3. Nein es muss nichts manuell neu gestartet werden
4. Kommt darauf an was Sie erreichen wollen. Geht es ihnen nur darum Webseiten zu blocken oder auch auf Viren zu scannen?
    -> Wenn es ums reine blocken geht würde ich eher die Firewall auf die aktuelle Version updaten und dann den transparenten Modus einrichten. Die SSL-Interception muss dann auf Webfilterbasis aktiviert werden.
    -> Geht es jedoch um die Sicherheit und dem Scannen immer die Firewall fest als Proxy verwenden. Kein HTTP und HTTPS direkt raus lassen. Wichtig ist halt auch das Windows dann auch immer den Proxy nimmt. Es passiert leider immer wieder das auch Windows die Internetoptionen ignoriert und es direkt versucht. Hier können Sie dies jedoch über netsh winhttp korrigieren. Dadurch sollte auch dann alles über den Proxy geschickt werden.


Gruß Björn

Junioruser1976
Beiträge: 37
Registriert: Di 02.07.2019, 07:43

Beitrag von Junioruser1976 »

Hallo Bjoern,

vielen Dank Ihnen schonmal  für die Antworten, die mir an einigen Stellen wieder einiges weitergeholfen haben.

Ich möchte aber aus aktuellem Anlass nochmal auf das Problem heute erneut zurückkommen, weil ich das hier heute wieder akut hatte, kann aber jetzt, nachdem ich -zumindest ein bißchen- ;-) Logs lesen gelernt habe, was Neues auch an Infos noch besser beisteuern:

nochmal kurz zur Erinnerung: Situation ist so: im Portfilter: Proxy DMZ deaktiviert, Anyregel /HN für Internet bei DMZ freigeschaltet,  Systemproxy beim Client, der in der DMZ ist, ist rausgenommen: =) Internet funktioniert, also Websites lassen sich normal laden- aber Windows Update Dienst konstant Fehler 80072f8f wieder. FW und Client neu gestartet =) keine Änderung, aka.ms/diagn/wu meldet Service regisration corrupt, behebt das jeweils und danach wieder gleicher fehler

Hab mir jetzt mal die Logs dazu mal angeschaut  mit folgenden interessanten Beobachtungen:
1. der Client aus der DMZ läuft, obwohl (!) im Portfilter auf "Proxy aus" steht, weiter volles Rohr über den httpProxy incl. Webfilter
2. es geht immer ziemlich weit durch- man sieht sogar noch,dass der Webfilter Kontakt mit Window Update Server zulässt- und dann steigt die Kiste beim ht tp-Proxy mit folgender Fehlermeldung aus:

Error negotiating SSL connection on FD 12: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca (1/0)
 
Error negotiating SSL connection on FD 18: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca (1/0)

Ich hab dann schlau gedacht: deaktivier mal bei "Anwendungen" den http-Proxy- aber dann komm ich - obwohl ich im Portfilter das auf any stehen habe!!- noch nicht mal mehr ins Internet- umgekehrt ist das wiederum auch logisch, dass es so ist, weil ja der Client anscheinend trotz "Proxy aus" im Portfilter immer noch irgendwo intern auf der FW auf "Proxy ein" steht, warum auch immer.

3. da der Fehler was mit SSL zu tun hatte, hab ich dann mal als nächstes SSL Interception UND transparente Regeln deaktiviert -und siehe da: danach  war der Proxy dann endlich -ich nenn das mal- "richtig" aus- und dann hab ich auch endlich die verhaßte Fehlermeldung 80072f8f nicht mehr gehabt

Fragen:
zu 1. und 3.:

a)Warum kann ich mit "Proxy aus" im Portfilter nicht den gesamten Proxy deaktivieren?

b)Ist das ggf. Problem speziell bei meinen Übungen mit der DMZ als Testzone oder erwartet mich das gleiche Problem auch für das Internal Network ? (habe bislang noch nicht Proxy gewagt im Internal network, was hier 100% sicher laufen muss jeden Tag zu aktivieren, daher frage ich lieber mal vorher, ob mich das dann da auch erwartet)...

c)Kann ich es mir ggf. so vorstellen, dass SSL Interception/Transparenter Modus noch vorgeschaltet Richtung Proxy dann doch routen und daher trotz Regel Proxy aus am Portfilter das dann da noch hinläuft? (toll wäre, wenn Sie mal auf Ihrer Muster FW das so eingeben für die DMZ und schauen, ob es bei Ihnen auch über den Proxy geht wie beschrieben oder ob das nur ein Phänomen meiner Anlage hier ist)

d)lässt sich das, weil es eben ist wie es ist, nur durch Deaktivierung SSL/Transparenter Modus umgehen? bzw. Gibt es ggf eine Reihenfolge, wann man best practice in Bezug zum Portfilter SSL und Transparenter Modus aktiviert bzw. deaktiviert?

zu 2.
Wie kommt der Fehler zustande? Wie kann man ihn beheben bzw. vermeiden für die Zukunft ? (ich hatte hier vorher jetzt bevor ich mal wieder an den Portfilterregeln mit an und aus "geübt" hatte ein bißchen;-) heute, den Client mehrere Wochen problemlos laufen gehabt incl. Windows Updates über den Proxy- da war SSL Interception Transparent Proxy in gleicher Konfiguration hinsichtlich Windows Ausnahmen aktiv- und es lief alles- daran hatte ich nix geändert- also kann doch da eigentlich nicht das Problem liegen - wo liegt es aber dann?

Bin gespannt auf die Antworten

Viele Grüße und ein schönes Wochenende

Antworten