Wie detailliert konfiguriert ihr die Windows-Firewall?

[basstscho 10]

Hallo zusammen,

 

ich hatte vor einen Austausch mit einem befreundeten Kollegen, der die Windows-Firewall deutlich intensiver konfiguriert als ich. Gerne würde ich wissen wie ihr es bei euch im Unternehmen handhabt.

 

Bei mir (über GPO, lokale Regeln nicht zusammenführen):

- Allen ausgehenden Verkehr zulassen (und auch keine Regeln definiert)

- Bei den eingehenden Regeln ist:

• innerhalb der Domäne der ping erlaubt
• auf Clients dann i.d.R. auch nicht mehr
• auf Server natürlich die entsprechenden Dienste

 

Der Bekannte blockiert auch den ausgehenden Traffic und definiert dann die benötigten Ports/Anwendungen. Das ist aus meiner Sicht ein sehr aufwändig.

 

Hintergrund zu unserem System: Internetzugang geht bei uns im Netzwerk nur über einen gefilterten Proxy raus und auf allen Clients ist Applocker (whitelist) konfiguriert.

Mach ich es mir zu einfach? Konfiguriert ihr ebenfalls Ausgangsseitig die komplette Kommunikation?

 

Danke und Grüße,

Johannes

[MurdocX 1.002]

vor 18 Stunden schrieb basstscho:

Konfiguriert ihr ebenfalls Ausgangsseitig die komplette Kommunikation?

Nein, zumindest nicht auf der Windows Firewall.

 

Was man dort konfigurieren würde, wären ausgehende Denys von OS seitigen LOLBINs. Dort wären dann genau die Tools drin, die durch den AppLocker normalerweise nicht blockiert werden, weil sie sich im Systemverzeichnis befinden und dem OS angehören. 

[daabm 1.428]

Wir blocken outbound im public profile. War etwas Herzrasen beim Rollout (6-stellige Anzahl Clients - wehe die finden keine Domäne mehr...), funktioniert aber einwandfrei. Und braucht auch keine große Pflege. Im domain profile ist outbound offen - das würden wir nicht verwaltet kriegen, zu viele Sonderlocken...

Nachtrag: "Bei uns im Netzwerk" ist etwas kurz gegriffen - was ist mit Laptops unterwegs oder zuhause?

[basstscho 10]

Vielen Dank für eure erste Einschätzung!

 

vor 2 Stunden schrieb MurdocX:

Was man dort konfigurieren würde, wären ausgehende Denys von OS seitigen LOLBINs. Dort wären dann genau die Tools drin, die durch den AppLocker normalerweise nicht blockiert werden, weil sie sich im Systemverzeichnis befinden und dem OS angehören. 

Hast du mir ein paar Beispiele? Würde ich gerne ergänzen!

 

vor einer Stunde schrieb daabm:

Nachtrag: "Bei uns im Netzwerk" ist etwas kurz gegriffen - was ist mit Laptops unterwegs oder zuhause?

Ja, das stimmt natürlich! Da könnte man sicher noch nachschärfen. Habt ihr das dann auf Port-Basis gemacht - also z.B. 80 & 443 offen oder die einzelnen Anwendungen freigeschaltet?

[MurdocX 1.002]

vor 3 Stunden schrieb basstscho:

Hast du mir ein paar Beispiele? Würde ich gerne ergänzen!

Ich denke das würde Dir nichts bringen. In das Thema muss man sich einlesen, um es zu verstehen und anzugehen. Google einfach mal "lolbins". 

[testperson 1.857]

vor 14 Stunden schrieb basstscho:

Hast du mir ein paar Beispiele? Würde ich gerne ergänzen!

 

Hier ist ein ganz gutes Projekt bzw. eine Übersicht dazu: LOLBAS

Ein Ansatz für die Firewall: GitHub - eneerge/Powershell-Firewall-Block-LOLbins (Das solltest du dir aber recht genau ansehen, überarbeiten und testen. Das Profil "Any" würde ich spontan für too much halten in Domänen Umgebungen.)

 

[cj_berlin 1.508]

Es gibt viele gute Ansätze hier, beim Threat Modelling für die Windows Firewall sollte eins jedoch nicht außer Acht gelassen werden: Die Konfiguration, ob sie lokal vorgenommen wurde oder aus GPOs kommt, steht im Klartext in der Registry. Somit kann die Angreiferin, wenn sie dort Lesezugriff hat, bereits genau wissen, was konfiguriert wurde. Das verrät ihr unter Umständen Dinge, die sie sonst nur mit Mühe und viel Noise herausgefunden hätte, wenn überhaupt.

Will damit sagen: weniger kann manchmal mehr sein.

[basstscho 10]

vor 8 Stunden schrieb testperson:

 

Hier ist ein ganz gutes Projekt bzw. eine Übersicht dazu: LOLBAS

Ein Ansatz für die Firewall: GitHub - eneerge/Powershell-Firewall-Block-LOLbins (Das solltest du dir aber recht genau ansehen, überarbeiten und testen. Das Profil "Any" würde ich spontan für too much halten in Domänen Umgebungen.)

 

Danke für den Hinweis. Ich hab das mal auf meine Testgruppe losgelassen. Ungünstig ist dabei natürlich, dass das quasi je nach System unterschiedliche Regeln gibt. Die "Klassiker" direkt aus dem Systemverzeichnis sind aber auf jeden Fall mal mit dabei. 

 

vor 8 Stunden schrieb cj_berlin:

Es gibt viele gute Ansätze hier, beim Threat Modelling für die Windows Firewall sollte eins jedoch nicht außer Acht gelassen werden: Die Konfiguration, ob sie lokal vorgenommen wurde oder aus GPOs kommt, steht im Klartext in der Registry. Somit kann die Angreiferin, wenn sie dort Lesezugriff hat, bereits genau wissen, was konfiguriert wurde. Das verrät ihr unter Umständen Dinge, die sie sonst nur mit Mühe und viel Noise herausgefunden hätte, wenn überhaupt.

Will damit sagen: weniger kann manchmal mehr sein.

Das ist richtig. Ich war auch schon kurz davor ein paar Admin-IPs mehr Zugriff zu geben. Ist aber sowohl sicherheitstechnisch, als auch zwecks "Einsicht" nicht ideal.

[Weingeist 176]

Hie ein Plus für detailliert. Auf die granulare Freigabe auf einzelne IP's/DNS-Namen kam ich aber aus den Gründen die Evgenij bereits gennant hat auch wieder weg. Hat er schon öfter darauf hingewiesen und fand ich schlüssig. Ist auch viel zu pflegebedürftig. Weniger im Betrieb selbst - da ändert sich nicht so viel - aber wenn man z.B. Migrationen fährt. Da drehst ab. Was ich beibehalten habe ist die granulare Freigabe was überhaupt raus darf. Das gilt für MS als auch fremde Dienste. 

 

Ein paar Gründe für Detailierung

• man sieht im Security-Log was überhaupt alles raus kommunizieren will. Das ist bereits für Windows recht interessant (sofern man es aktiviert) aber auch jede unscheinbare Software.
• Die In-Logs sind relativ überschaubar und können recht easy ausgewertet werden, weil die ganzen Kontaktaufnahmen anderer Clients wegfallen, weil sie gar nicht erst raus gehen. Gerade für die Fehlersuche ist das extrem angenehm wenn das ganze Grundrauschen weg ist.
• Windows Updates auf Produktionsmaschinen können sehr effektiv verhindert bzw. geplant werden ohne die Updatedienste zu deaktivieren. Die werden von Windows sowieso gerne wieder aktiviert. So kann man Updates zwar intern freigeben, aber damit sie die Clients bekommen, muss mit einem einfach Script die Firewall-Regel aktiviert werden (das Gegenscript wird automatisch alle paar Stunden ausgeführt wenn man es mal vergisst). Dafür braucht es noch etwas mehr, da der Dienst maskiert ist.
• IPv6 wird in letzter Konsequenz blockiert (wenn sich ein Dienst nicht an die IPv4 Order hält, entdecken von Kofigurationsfehler oder irgend eine Management-Karte sich verselbstständigt). Ich mag keine zwei Dinge zu pflegen, keine Zeit.