Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Firewall-Regel Verbindung zum WAN sperren mit Ausnahme
Eine Regel erstellen welche Zugriff zu den entsprechenden Domains erlaubt und diese von der Reihenfolge vor der einschränkenden Regel platzieren.
Zugriff zu einem DNS-Server sollte natürlich auch möglich bleiben, wenn nicht die Sophos den Part übernimmt.
Was revx bereits sagte.
Neue Firewall-Regel anlegen, Position über der Verbots-Regel auswählen.
Dann als Source die alten Clients, als Service http (80) und https (443), und als Destination:
Habe die URL`s soweit eingetragen aber beim Suchen der Clients nach Windwos Update kommt der Fehler, dass nicht nach Updates gesucht werden konnte. Fehlen evtl. noch URL`s?
Prüfe wie bereits erwähnt ob die Clients überhaupt die Domains via DNS auflösen können. Wenn sie beispielsweise in den Einstellungen nun 8.8.8.8 als DNS eingetragen haben, versuchen sie bei google die Microsoft-Domains aufzulösen, das wird aber geblockt und das Update schlägt fehl. Nutzen die Clients die Sophos als DNS, sollte es hingegen klappen. Das musst du mal ausprobieren.
Meines Wissens nach werden firewall Regeln von nahezu allen Systemen so ausgelegt, dass ein Verbot eine Erlaubnis überschreibt. Merken, einmal verboten, immer verboten. Auch eine Ausnahme mit Erlaubnis geht nicht. Du kannst also nicht einfach alles verbieten und dann einzelnes wieder erlauben.
@owl2010 : Ok, das sieht so aus wie es aussehen soll. Die nslookups (direkte DNS-Queries) werden über google (8.8.8.8) blockiert und die anderen beiden funktionieren. Interessant ist hier jedoch, dass scheinbar die IP der Sophos nicht in den Netzwerkeinstellungen als DNS hinterlegt ist, zB via DHCP, da das erste nslookup ohne Angabe eines DNS die 192.168.80.2 nutzt, während der 3. nslookup mit der mutmaßlichen Sophos-IP 192.168.80.254 arbeitet. Da solltest du nochmal genau hinsehen ob da nicht evtl. eine Fehlkonfiguration vorliegt, wenn ggfs auch das Standardgateway auf die .2 zeigt und da evtl gar nichts geht.
Ein Blick in ipconfig /all ist also anzuraten.
Samurai76 schrieb:
Meines Wissens nach werden firewall Regeln von nahezu allen Systemen so ausgelegt, dass ein Verbot eine Erlaubnis überschreibt.
Nope. iptables arbeitet zB stur von oben nach unten ab. Der erste Exit, der zutrifft, wird genommen, egal ob es ein drop, deny oder allow ist. Deswegen muss man die Firewall-Regeln auch sehr genau designen und sortieren, weil man sich im worst case selbst aussperrt. Sowas wie "1: block all incoming und 2: allow ssh" sperrt dich schneller aus einer Firewall aus als du gucken kannst.
Ah ok, dann ist das geklärt. Die DNS-Auflösung funktioniert dann soweit korrekt und sollte nicht das Problem sein - schade
Ergänzung ()
Wobei, ich sehe erst jetzt den Ping am Ende. Der schlägt ja fehl. Das heißt, dass die Freigabe-Regel hier noch nicht greift. Wobei der Ping natürlich ICMP ist und oben eine Ausnahme-Regel für http/https vorgeschlagen wurde. Also ggfs die Freigabe-Regel mal port- und protokoll-neutral erstellen und prüfen ob der Ping dann geht.
Kannst du mal das Log mitlaufen lassen und schauen, was passiert, wenn du versuchst Windows Updates zu ziehen?
Gerne mit Filter auf die IP vom Client, der versucht die Updates zu ziehen.
Habe ich gemacht - er geht sofort nur auf die Regel #12, die ja WAN blockieren soll und diese Regel ist dann auch grün. Aber er zeigt gar nicht die Regel oberhalb an (Regel #26) welche ja die Updates freigeben soll:
Brauchts denn hier keine Webpolicy? Bzw. wird sowieso alles erlaubt wenn keine Webpolicy in der Firewall-Regel definiert wird? Was hast du im aktivieren Application Filter (APP grün) gesetzt?
Es ist natürlich möglich, dass der Wizard für die Firewall die Regeln im Hintergrund anders handhabt als es den Anschein hat. Wie bereits dargelegt wurde, werden Firewall-Regeln stets der Reihe nach bearbeitet und der erste Match wird genommen. Deswegen ist eine "Block all incoming" Regel an erster Stelle eben auch potentiell tödlich, da man sich damit selbst aussperrt und weder ssh noch webgui noch funktionieren.
Aber: Eine Firewall ist üblicherweise auch in mehrere Chains aufgeteilt. Man sieht das bei iptables beispielsweise daran, dass es grundsätzlich erstmal natürlich die INPUT / OUTPUT / FORWARD chains gibt, man aber innerhalb dieser Chains weitere anlegen kann, sozusaggen sub chains, um bestimmte Regeln zu gruppieren, beispielsweise Portweiterleitungen. In der FORWARD chain gibt es dann nur eine einzige Zeile, die alle Portweiterleitungen abfrühstückt, sinngemäß mit "jump-to-subchain-portforward" und erst da sind dann die 17 Portweiterleitungen als Ausnahmen per allow zugelassen. Einige Firewall-Frontends wie zB ufw bei Linux fügen locker ein Dutzend solcher sub chains ein und auch da gilt natürlich, dass alle Regeln der als erstes aufgerufenen sub chain vor allen Regeln der später geprüften sub chains Vorrang haben.
Nu kann es natürlich sein, dass Sophos bestimmte Regeln eben genau so gruppiert und damit hinter den Kulissen eine andere Reihenfolge abarbeitet als es in der GUI dargestellt wird. Ist aber reine Spekulation.
*edit
Und da widerlege ich mich gleich mal selbst:
On the Sophos XG Firewall all rules located in the Firewall section of the admin console are processed in a top to bottom order. Each rule is checked to see if it matches and then the next rule is evaluated in that order until the bottom rule is reached. Once a rule matches then the remaining rules are skipped and the traffic is allowed or denied based on the matching rule.
Ich vermute dann mal, dass irgendetwas mit dem Matching nicht hinhaut. Sophos scheint den Update-Traffic nicht mit dieser Regel in Verbindung zu bringen, weil irgendein Parameter nicht passt. Die Regel wird geskipped und dann kommt der Dampfhammer der alles blockiert.
*edit2
Problematisch kann natürlich sein, wenn man beim Erstellen der Regeln tatsächlich eine Domain angibt und keine IP. Üblicherweise ist es nämlich so, dass dann EINMALIG diese Domain aufgelöst wird und dann EXAKT DIESE IP-Adresse in die Regel eingefügt wird. Sollte die Domain dynamische IPs beinhalten oder zB per Round-Robin jedes Mal eine andere IP ausspucken - Stichwort: Load balancing - kann es sein, dass man sich selbst ins Knie geschossen hat. Dann muss man alle tatsächlich genutzten IP-Adressen herausfinden und in der Regel erfassen. Manchmal setzt man dafür auch Skripte ein, die im Hintergrund zyklisch die Domains prüfen und die Firewall-Regeln automatisch anpassen. Da muss man mal schauen ob es vielleicht gute Tutorials im Netz gibt, die umfassende Hilfestellung zum Thema "Windows Update erlauben" geben.
Um das mal zu belegen: In deinem Screenshot in #15 taucht die IP von windowsupdate.microsoft.com aus #7 zum Beispiel gar nicht auf, sofern der Screenshot denn vollständig ist. Da gibt es keine 52.137.90.34 und an meinem PC liefert ein "nslookup windowsupdate.microsoft.com" dazu beispielsweise 52.185.71.28
Ergänzung ()
Sorry, dass ich hier ständig auf mich selbst antworte, wobei ich bis eben nur editiert habe.
Wie auch immer, habe gerade recherchiert und die IP-Adressen der Update-Server sind weder fix noch werden sie veröffentlicht. Das heißt, dass man sie in dieser Form nicht blocken oder freigeben kann, da man dazu die IP-Adresse oder einen eindeutig identifizierbaren Port brauchen würde.
Von daher vermute ich mal, dass @Freestyler hier wohl auf dem richtigen Weg ist, die Firewall ist nicht der richtige Ort, sondern die Webfilter-Optionen. Gegebenenfalls muss man dann aber schauen ob Einstellungen im Webfilter, der dann ja tatsächlich Domains blocken kann, wenn ich das richtig gelesen habe, eine Block-Regel in der Firewall überschreiben oder andersherum. Tendenziell würde ich vermuten, dass die Firewall mit ihrem "Block all" dann stets Vorrang hat. Gegebenenfalls muss die Block-Regel daher umgebaut werden, um alles außer http/https zu blocken damit dies zwar generell erlaubt ist, aber dann vom Webfilter auf die Update-Domains von Microsoft beschränkt wird. Wie genau das bei Sophos geht, kann ich aber nicht sagen, ich hab von deren Produkten keine näheren Kenntnisse und kann nur neutral mit meinem Firewall-Wissen urteilen.
