SMB auf Windows Clients

[Moped 11]

Hallo Zusammen,

 

ich wollte mal nachfragen, wie ihr das mit SMB auf Windows 10/11 Clients handhabt, bezogen auf die Sicherheit

Wir sollen, wie es so schön heißt, "die SMB Kommunikation auf den Clients sperren"

Ist dann noch ein gescheites Arbeiten Möglich?

Blockt ihr z.B. in der Windows Firewall den Port 445? Wobei in der MS Beschreibung steht "Die Windows Firewall hat standardmäßig alle eingehenden SMB-Kommunikationen blockiert, seit Windows XP SP2 und Windows Server 2003 SP1."

 

 

Suche nach einer praktikablen Lösung, deshalb mal die Frag in die Runde wie ihr es handhabt

 

[chrismue 96]

Mahlzeit,

 

du bist sicher, dass du ALLE SMB KOMMUNIKATION sperren sollst?

Oder geht es hie um SMB1?

 

Gruß

chrismue

[MurdocX 949]

Hallo,

 

kurze Gegenfrage: Welcher Port muss denn überhaupt auf einem Client offen sein?

 

Clients haben ausschließlich ausgehende Kommunikation. Ausnahmen bestätigen die Regel. Mach die Clients dicht. Für ggf. administrative Tätigkeiten erlaube ein geschlossenes Admin-Netz.

[Moped 11]

vor 38 Minuten schrieb chrismue:

Mahlzeit,

 

du bist sicher, dass du ALLE SMB KOMMUNIKATION sperren sollst?

Oder geht es hie um SMB1?

 

Gruß

chrismue

 

Die Aussage bezog sich jetzt nicht auf eine bestimmte Version,  wobei ich SMB1 schon per GPO deaktiviert habe und die bei W11 nicht mehr dabei ist

vor 35 Minuten schrieb MurdocX:

Hallo,

 

kurze Gegenfrage: Welcher Port muss denn überhaupt auf einem Client offen sein?

 

Clients haben ausschließlich ausgehende Kommunikation. Ausnahmen bestätigen die Regel. Mach die Clients dicht. Für ggf. administrative Tätigkeiten erlaube ein geschlossenes Admin-Netz.

 

Das ist eine gute Frage, sinnvoll wäre es ja die Clients dicht zu machen, klar.
Aber das muss man dann mal separat testen und anpassen

Die Windows Firewall steht bei uns auf Blockieren (Standart), damit sollte ja eigentlich alles zu sein (bis auf die Windows eigenen Ports glaube ich. 
Weil wenn ich sage "Alle Blockieren" funktioniert erst mal fast nichts mehr 

[cj_berlin 1.312]

vor 8 Minuten schrieb Moped:

Weil wenn ich sage "Alle Blockieren" funktioniert erst mal fast nichts mehr 

Das musst Du aber nur Inboud setzen, nicht Outbound  

[NorbertFe 2.032]

So würd ich das auch interpretieren. ;) Keine Datei- und Druckerfreigabe auf Clients. Braucht kein Mensch. 

[Moped 11]

Habe das gerade nochmal getestet, dabei u.a. festgestellt, dass wir von unserem Softwareverteilprogramm in einer $ Freigabe die Logfiles liegen haben 
Die kann ich, nachdem ich "Alles Blockieren" eingestellt habe, natürlich auch nicht mehr erreichen.

Damit fällt das dann wohl flach  

[testperson 1.675]

Du kannst doch eine Ausnahme für das Softwareverteilprogramm erstellen. Siehe die Antwort oben von @MurdocX:

vor 1 Stunde schrieb MurdocX:

Clients haben ausschließlich ausgehende Kommunikation. Ausnahmen bestätigen die Regel. Mach die Clients dicht. Für ggf. administrative Tätigkeiten erlaube ein geschlossenes Admin-Netz.

 

[Moped 11]

vor 20 Stunden schrieb testperson:

Du kannst doch eine Ausnahme für das Softwareverteilprogramm erstellen. Siehe die Antwort oben von @MurdocX:

 

 

werde mir das mal anschauen, danke euch 

[Weingeist 159]

Alles was Outbound erlaubt ist, ist bei der Windows-Firewall auch automatisch Inbound erlaubt. Sprich wenn die Port/Protokoll/Local/Remote-Paarung etc. identisch ist bewirkt eine Outbound-Regel, dass der Inbound-Part ebenfalls erlaubt ist. Deshalb muss man auch sehr selten Inbound-Regeln definieren. Umgekehrt gilt das nicht.

 

Wenn Du Outbound auf Standard Offen lässt, kann jede Software  problemlos überall hin und her kommunzieren. Der komplette Inbound-Traffic ist erlaubt, solange der Verbindungsaufbau durch den Client stattfindet. Wodurch der auch immer ausgelöst wird (Service, Mausklick, Task, installiertes Programm etc.).

 

Dann gibt es noch diverse vordefinierte Regeln die für Basis-kommunikation grundsätzlich zwingend notwendig ist oder der Sicherheit dienen (Block). Die bekommst Du in der GUI und selbst command line nie zu Gesicht (Registry, Static Rules). Ein kleiner Teil der System-Rules sind Configurable, die sieht man zwar nicht in der GUI, dafür aber in der cmd. Dann gibts eine stark wachsende Anzahl von App-Rules. Die siehst (fast) nur in der Registry und sind auch nur da manipulierbar (die neuesten Updates bringen hier angeblich etwas Funktion in die GUI oder Cmd-Line, noch nicht getestet)

 

Zu SMB: Du kannst nicht einfach SMB auf den Clients abdrehen. Da geht dann wirklich einiges nicht mehr.

LanmanServer kann man theoretisch abdrehen. Irgendwo habe ich mal aufgeschrieben was nicht mehr geht (mir wars dann aufgrund einer Situation zu doof, weiss aber nicht mehr warum, müsste ich suchen). Findest aber sicher per google raus.

LanManWorkstation kannst nicht wirklich abschalten, sonst geht nicht mehr viel weil z.B. Netlogon oder die Ausführung von GPO's etc. davon abhängig sind. Auch DFS oder Zugriff auf Fileshares geht nicht mehr. Was geht ist die Beschränkung des Traffics auf bestimmte Endgeräte oder sogar Benutzer/Gruppen.

 

 

Was so wohin geht/herkommt kann man sehr schön erkennen wenn man das Firewall-Journaling aktiviert.

 

Englisches OS: auditpol.exe /set /category:"Object Access" /subcategory:"Filtering Platform packet drop" /success:enable /failure:enable
Deutsches OS: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable
Sprachübergreifend: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

 

Die Einträge landen im Security Log. Musst die Grösse auf 256MB oder mehr hochstellen, sonst ist das rasch voll. Du wirst erstaunt sein, wieviel Kommunikation so ins weite Netz geht.

 

Mühsam ist die Unterscheidung von Traffic der via der svchost.exe läuft. Da erkennt man zwar die Prozess-Nummer (wiederum mit tasklist.exe aufrufbar), aber die ist nicht zwingend aktuell, weil der Prozess schon wieder beendet sein kann. Da muss man sich dann damit behlefen den Services eigene Hardlinks zur svchost.exe zu spendieren. Dann werden die Verursacher sichtbar (z.B. svchost_servicename.exe) und man kann entsprechende Regeln aufsetzen. (Wobei es unzuverlässig ist auf Services Regeln zu erstellen weil manche von Windows aus Sicherheitsgründen maskiert werden, leider erkennt sie dann auch die Windows-Firewall nicht mehr *hmpf*)

Da musst Du entweder tatsächlich mit den Hardlinks arbeiten oder tiefer rein und auf BFE-Ebene filtern via den zugehörigen Service-Protokollen (RPC).

 

 

 

[MurdocX 949]

vor 3 Stunden schrieb Weingeist:

Alles was Outbound erlaubt ist, ist bei der Windows-Firewall auch automatisch Inbound erlaubt. Sprich wenn die Port/Protokoll/Local/Remote-Paarung etc. identisch ist bewirkt eine Outbound-Regel, dass der Inbound-Part ebenfalls erlaubt ist. Deshalb muss man auch sehr selten Inbound-Regeln definieren. Umgekehrt gilt das nicht.

 

Interessante Auslegung. Das kann ich so nicht bestätigen und gehe auch weit zu sagen, dass es falsch ist. Out- und Inbound Traffik geht immer vom Initiator aus. Wenn ich also initial eine Outbound-Connection habe, dann darf natürlich die Gegenüberstelle antworten. Was aber nicht heißt, dass deshalb auch der initiale Inbound-Connection damit freigeschaltet wäre. 

 

vor 3 Stunden schrieb Weingeist:

Zu SMB: Du kannst nicht einfach SMB auf den Clients abdrehen. Da geht dann wirklich einiges nicht mehr.

LanmanServer kann man theoretisch abdrehen. Irgendwo habe ich mal aufgeschrieben was nicht mehr geht (mir wars dann aufgrund einer Situation zu doof, weiss aber nicht mehr warum, müsste ich suchen). Findest aber sicher per google raus.

LanManWorkstation kannst nicht wirklich abschalten, sonst geht nicht mehr viel weil z.B. Netlogon oder die Ausführung von GPO's etc. davon abhängig sind. Auch DFS oder Zugriff auf Fileshares geht nicht mehr. Was geht ist die Beschränkung des Traffics auf bestimmte Endgeräte oder sogar Benutzer/Gruppen.

Natürlich kann ich es abdrehen, indem ich die FW inbound schließe. Am Client würde ich keine Dienste verändern. Die Kommunikation zur Domäne ist inital vom Client, also Outbound.

[Moped 11]

Hallo Zusammen,

danke für die Ausführungen, mega interessant.
 

Was genau ist denn der Unterschied wenn ich in der Firewall "Blockieren (Standard)" setze oder "Alle Blockieren"?

Bei Standard klappt ja noch sowas wie z.B. die SMB Verbindung.
 

Würde bedeuten, so wie @MurdocX schreibt, man stellt "Alle Blockieren" ein und gibt dann die entsprechenden eingehenden Verbindungen, wie man sie braucht frei.

 

Handhabt ihr das auch so?

 

Nachtrag: Wir haben das schon mal gehabt, dass z.B. wenn ich Teams starte, eine Meldung kam dass die Einträge in der Firewall angepasst werden sollen.

Das würde ja dagegen sprechen, dass Outbound Kommunikation auch automatisch Inbound geht, sonst würde das lokale Teams ja nicht die Firewall regeln anpassen wollen, oder habe ich da einen Denkfehler?
 

bearbeitet 26. Mai 2023 von Moped

[Weingeist 159]

vor 19 Stunden schrieb MurdocX:

es was Outbound erlaubt ist, ist bei der Windows-Firewall auch automatisch Inbound erlaubt. Sprich wenn die Port/Protokoll/Local/Remote-Paarung etc. identisch ist bewirkt eine Outbound-Regel, dass der Inbound-Part ebenfalls erlaubt ist. Deshalb muss man auch sehr selten Inbound-Regeln definieren. Umgekehrt gilt das nicht.

 

vor 19 Stunden schrieb MurdocX:

Interessante Auslegung. Das kann ich so nicht bestätigen und gehe auch weit zu sagen, dass es falsch ist. Out- und Inbound Traffik geht immer vom Initiator aus. Wenn ich also initial eine Outbound-Connection habe, dann darf natürlich die Gegenüberstelle antworten. Was aber nicht heißt, dass deshalb auch der initiale Inbound-Connection damit freigeschaltet wäre. 

 

Vielleicht habe ich das etwas missverständlich ausgedrückt. Ich versuche es mal anders.

 

Wenn man eine Inbound-Regel erstellt, heisst das nicht, dass die Antwort auch tatsächlich zurück gehen kann. Dafür braucht es oft eine zusätzliche Outbound-Regel.

Bei der Outbound-Regel muss aber so gut wie nie eine entsprechende Inbound-Regel erstellt werden um die Kommunikation zu ermöglichen. Die Rückantwort geht auch so durch die Firewall. Ausnahme ist z.B. SMB.
 

 

vor 19 Stunden schrieb MurdocX:

Natürlich kann ich es abdrehen, indem ich die FW inbound schließe. Am Client würde ich keine Dienste verändern. Die Kommunikation zur Domäne ist inital vom Client, also Outbound.

Du kannst SMB für inbound nicht in der FW abdrehen ohne bescheidene Side-Effects. Die Kommunikation mit DC, CA, WSUS, Filer, Printer brauchen die Inbound-Regeln von SMB. Teilweise sogar zwei Rules (Local/Remote).

 

Das einzige was ich nicht sicher bin, ob sie sie nur brauchen wenn die Verbindung gesichert/signed etc. ist, oder obe es auch für eine ungesicherte Verbindung ebenfalls notwendig ist.

 

Das kann man feststellen, wenn man sämtliche Standardregeln deaktiviert und alle selber nachbaut aufgrund der fehlgeschlagener Kommunikation. Edit: Ja ich habe mir das mal angetan obwohl das kein Mensch macht. Sprich geschaut was alles an minimaler Kommunikation notwendig ist, damit das anmelden an eine Domäne, austausch von Zertifikation, File-Services, Printservices etc. schmerzfrei funktioniert. Macht kein Mensch, ich habs trotzdem mal gemacht. ;)

 

 

Meine Vermutung geht dahin, dass das unterschiedliche Verhalten etwas mit der Sicherung der Kommunikation zu tun hat. Also das es nicht eine "richtige" Antwort ist, sondern teilweise ein Neuaufbau einer Verbindung für die Rücksendung ist bei SMB. Wenn Windows selber der Initiator ist, bleibt es wohl wie es ist. Ist aber reine Mutmassung. Dafür habe ich die Pakete an sich zu wenig analysiert sondern nur die geblockten Pakete auf den entsprechenden Ports/Protokoll/Dienst festgestellt.

 

vor 4 Stunden schrieb Moped:

schreibt, man stellt "Alle Blockieren" ein und gibt dann die entsprechenden eingehenden Verbindungen, wie man sie braucht frei.

Block all heisst: eine Blockieregel gewinnt über eine Erlauben-Regel. Egal welche.

Block standard heisst: eine Erlauben-Regel gewinnt über eine Blockier-Regel.

 

Das ist eine "Krücke" der Windows Firewall. Vermutlich ist das dem Umstand geschuldet, dass die Windows-Firewall nicht wie eine "normale" Firewall Regeln der Reihe nach abarbeitet sondern eben alle zusammen. So kann man immerhin sagen, welche gewinnen soll. Je nach dem echt zum "werfen".

bearbeitet 26. Mai 2023 von Weingeist

[MurdocX 949]

Am 26.5.2023 um 13:47 schrieb Weingeist:

Vielleicht habe ich das etwas missverständlich ausgedrückt. Ich versuche es mal anders.

Es ist ja nichts persönliches  

 

Am 26.5.2023 um 13:47 schrieb Weingeist:

Wenn man eine Inbound-Regel erstellt, heisst das nicht, dass die Antwort auch tatsächlich zurück gehen kann. Dafür braucht es oft eine zusätzliche Outbound-Regel.

Bei der Outbound-Regel muss aber so gut wie nie eine entsprechende Inbound-Regel erstellt werden um die Kommunikation zu ermöglichen. Die Rückantwort geht auch so durch die Firewall. Ausnahme ist z.B. SMB.

 

In meiner Teststellung klappt das wunderbar mit nur einer Inbound-Regel:

 

In- u. Outbound -> Block

 

 

 

Am 26.5.2023 um 13:47 schrieb Weingeist:

Du kannst SMB für inbound nicht in der FW abdrehen ohne bescheidene Side-Effects. Die Kommunikation mit DC, CA, WSUS, Filer, Printer brauchen die Inbound-Regeln von SMB. Teilweise sogar zwei Rules (Local/Remote).

Das einzige was ich nicht sicher bin, ob sie sie nur brauchen wenn die Verbindung gesichert/signed etc. ist, oder obe es auch für eine ungesicherte Verbindung ebenfalls notwendig ist.

Weder noch. Eine Inbound SMB wird ohne lokale Freigabe (Drucker oder Share) NIE benötigt. Unabhängig ob der SMB-Verkehr signed oder unsigned stattfindet. Es findet keine initiale Inbound-SMB bei einem ausgehenden Verkehr (Fileserver Zugriff bspw.) statt.  

 

Am 26.5.2023 um 13:47 schrieb Weingeist:

Block all heisst: eine Blockieregel gewinnt über eine Erlauben-Regel. Egal welche.

Block standard heisst: eine Erlauben-Regel gewinnt über eine Blockier-Regel.

Technisch hast du eine DROP-ALL Regel die entweder am Ende einer Firewall-Regel-Liste steht, oder am Anfang.

 

Die Windows-Firewall arbeitet hier korrekt, wie sie soll.

 

[daabm 1.354]

Ich ergänze mal: "Inbound" und "Outbound" bezieht sich ausschließlich auf den Initiator des IP- und TCP/UDP-Handshake beim Session-Aufbau. Ein Outbound-Allow erlaubt dem lokalen System, zum definierten Ziel eine Session aufzubauen. Ein Inbound-Allow erlaubt das einem Remote-System.

 

Danach haben wir eine offene Verbindung, über die selbstverständlich Daten in beide Richtungen fließen können.

 

Siehe netstat - "established".