Sophos Client Firewall: Blocks all on Windows 7 - suddenly

Hello Stefan Fröchtenicht,

if I see the configuration correctly it permits for the Primary location trusted connections to selected segments on 10.x.x.x as well as outgoing TCP and UDP, and for the Secondary only access to a /23 segment.

i can't find any logs
the local log on the endpoints (accessible from the GUI) should be there, the System log should tell the detected location. Sounds like it's using Secondary -  the location detection method is DNS using a TLD-name and if this isn't returning the configured IP address the endpoints will use the Secondary which will block almost all communication.

Christian   

Hi Christian,

thats right. the 10.x.x.x are our internal networks. Thats the primary location.

On the secondary, there is no thrusty network. So it will be all blocked.

is that wrong?!

maybe windows 7 can't resolv the dns search for the location?!

but thats interessting... i will test it out.

EDIT/UPDATE:

I've deactivated the secondary location function and it doesnt work... Same problem.

Here are the logs from the client:

firewall_logs_client.zip

i can't find anything. there is something with "hidden process" but this function is deactivated.

@ QC ich sehe du sprichst deutsch. Wir können auch gern auf Deutsch weiter sprechen. :)

Hallo Stefan Fröchtenicht,

auf Deutsch
wenn's einfacher ist [:)]. 

Im Systemprotokoll ist eine Menge Firewall wurde konfiguriert (primärer Standort), das ist wahrscheinlich von den Policy Tests.
Am 27.1. gab es um 12:50:03 eine Konfiguration (ob lokal oder über SEC kann ich nicht sagen), danach um 13:10:44 wurde winvnc.exe wegen ungültiger Prüfsumme geblockt, kurz darauf der Computer (oder zumindest SCF) gestoppt. Nach dem Start heute gibt es wegen Ungültige Prüfsumme und Versteckter Prozess geblockte Verbindungsversuche - so als wären in der Konfiguration die entsprechenden Einstellungen vorgenommen worden. Ganz klar ist mir das Protokoll nicht, für die Prüfsumme gilt jedenfalls: Ist ein Prozess wegen der Prüfsumme (oder einem anderen Kriterium) "auffällig" geworden, erlaubt ihm eine Konfigurationsänderung (d.i. keine Prüfsummen heranziehen) erst dann einen Netzzugang, wenn er auch neu gestartet wurde. 

We haven't  made any changes
berühmte erste Worte [;)]. Ich lehne mich da aus dem Fenster: Aus welchem Grund auch immer war am 27. eine geänderte Konfiguration aktiv, die es auch beim heutigen Start war. Ich kann mir das nur schwer (eigentlich gar nicht) vorstellen, was da genau passiert sein könnte. Mit der "richtigen" Konfiguration sollte es jedoch nach einem Neustart funktionieren.

Christian 

Danke, Deutsch ist dann etwas einfacher :-)

Hoch interessant.

Ja, dass "Wir haben nichts geändert" stimmt natürlich nicht ganz. Natürlich habe ich etwas geändert, aber nicht was dieses Problem betreffen dürfte... Ich will mich aber auch nicht rausreden ;-) Ich kann es so erklären:

Interessant ist es, dass in meiner lokal installieren SEC (nur die Konsole) folgendes angezeigt wird:

Auf der Konsole auf dem Server so:

Dadurch kann ich meinen Konfigurationsfehler erklären.

ALSO verstehe ich richtig:

Wenn ich an der Firewall Richtlinie etwas anpasse, dann muss der Client danach neugestartet werden.

Was wäre dann die richtige Konfiguration?

So wie ich sie im ersten Post hochgeladen habe?

Die Richtlinie muss auf die Clients, wenn diese drauf ist, dann neustarten, dann sollte es wieder gehen?

Vielleicht wäre es auch toll, wenn du meine Richtlinie von oben nimmst, die entsprechend anpasst und wieder hochlädst (Ex-/Import über die SEC), dann kann ich sie mir genauer anschauen und es ist etwas verständlicher.

Auch interessant ist, dass es nur auf Win7 Clients ist...

Hallo Stefan,

spannend. in meiner lokal installieren SEC sieht es aus wie das GUI von SCF 3.x (das hab ich zwar noch nicht gesehen, aber gemäß Best Practice: SCF müsste es so aussehen. Ist mir noch nicht untergekommen, dass das UI unterschiedlich ist - vielleicht kann der Support dazu etwas sagen. Oder war das gar nicht die Konsole? Das würde jedenfalls einiges erklären: Für nicht existierende Einstellungen wird der Standardwert angenommen - und der ist z.B. Prüfsummen verwenden.

Wenn ich an der Firewall Richtlinie etwas anpasse
grundsätzlich muss eine geblockte Anwendung neu gestartet werden damit sie wieder Netzwerkzugang bekommt. Bei Systemanwendungen ist üblicherweise ein kompletter Neustart wenn nicht notwendig dann zumindest sinnvoll.

Die hochgeladene Richtlinie sieht ok aus, sollte machen, was erwartet wird.

nur auf Win7 Clients
klar, da diese Einstellungen nur SCF 2.9 und nicht SCF 3.x betreffen.

Christian

Hey,

WOW! Das ist mal interessant! Das heißt, dass die angesprochenen Funktionen (Versteckte Prozesse, Prüsummen, etc.) nicht mehr unter SCF 3.x existieren!

Zur Console: Ich werde sie mir mal komplett neu installieren. Schon komisch.

Da ja alles geblockt wurde (IE, VNC, etc.) macht ein neustart schon Sinn. Das heißt, dass meine Kollegen da durch müssen... Ich verteile die Richtlinie, dann geht erstmal wohl nichts mehr, dann muss der Client neugestartet werden und dann müsste es gehen.

Danke für die Hilfe. Ich werde es testen und Bericht erstatten!

Moin, Moin,

vielen, vielen Dank! Es läuft nun wieder alles ohne Probleme! Danke!

Zur Console: Bei mir und meinen Kollegen (alle Windows 10) werden die Funktionen der Firewall NICHT angezeigt. Schon interessant.

Der Support weiß bescheid und wird sich hoffe ich diesen Thread ansehen.

Schöne Woche noch!

Hallo Stefan,

in der Console auf Windows 10 werden die Funktionen der Firewall NICHT angezeigt
dachte ich mir, scheint mir aber irgendwie nicht sinnvoll. Welches Betriebssystem hat der SEC Server?

Christian

P.S.: Wenn das Problem gelöst ist, bitte die Antwort markieren

Moin Christian,

Der Server hat Windows Server 2012 R2 Datacenter.

Antwort ist markiert ;)

Moin Christian,

Der Server hat Windows Server 2012 R2 Datacenter.

Antwort ist markiert ;)