Ein- u. Ausgehende Windows Firewallregel für RDP

[ineedhelp 12]

@Community

 

Ich habe einen Server auf dem nur von einem bestimmten IP-Adressbereich per RDP zu gegriffen werden darf. Dieser Server darf aber nur auf bestimmte IP-Adressen per RDP zugreifen. Wie müssen die Windows Firewallregeln aussehen? Ich habe schon so viele Möglichkeiten und sperre mich leider immer wieder per RDP aus. Zum Glück kann ich mich lokal an den Server anmelden. 

 

Danke im Voraus und wünsche ein sonniges Wochenende.

[cj_berlin 1.171]

Moin,

 

wenn die Default-Regel in beiden Fällen auf "verweigern" steht, dann musst Du für den Zugriff auf den Server die zulässigen Quell-IPs angeben und für den Zugriff von diesem Server aus die zulässigen Ziel-IPs. Ports sind in beiden Fällen 3389 TCP + UDP.

 

Wenn die Default-Regel auf "zulassen" steht, gehört das ganze Konzept auf den Prüfstand und nicht nur RDP, Aber für RDP müsstest Du dann zwei Regeln haben: eine wie oben und eine, die RDP zumacht, aber tiefer in der Reihenfolge steht.

[daabm 1.212]

Kennt die Windows-FW eine "Reihenfolge"? Wenn ich das richtig verstehe, ist die Regel-Rangfolge nicht ganz so einfach: https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/rules (die Formulierung "more specific rules take precedence" finde ich herzerfrischend. Wie ist das, wenn bei einer ein Set von IP-Ranges steht und bei der anderen ein Set von Ports?)

Eine explizite Block-Regel gewinnt wohl immer, daher müsste man grundsätzlich für Inbound _und_ Outbound "Block" als Standard einstellen und dann per Allow gezielt wieder öffnen.

[cj_berlin 1.171]

Stimmt, da war was. Dann muss man, wenn es aus irgendeinem Grund nicht möglich ist, das Default-Verhalten auf Block zu setzen, alle unerwünschten Ranges explizit blockieren. Viel Spaß damit - aber mit viel Aufwand ist auch das machbar. Ob's sinnvoll ist, ist eine andere Frage.

 

Je nachdem, wie das Netz segmentiert ist, würde ich als Konzept-Vorschlag noch den RD Gateway einwerfen, aber das hat wieder Abhängigkeiten, die man bedenken muss.

[testperson 1.554]

Hi,

 

evtl. wäre serverseitig eine Isolierung per Verbindungssicherheitsregel "Authentifizierung für ein- / ausgehend anfordern" noch ein Ansatz. Grob:

• Implemeting IPSec in Windows Domain – part 1 | Michael Firsov (wordpress.com)
• Implemeting IPSec in Windows Domain – part 2 | Michael Firsov (wordpress.com)

Gruß

Jan

[MurdocX 913]

Da haut @testperson aber einen raus

 

Ich sehe hier diese Wege:

• (siehe oben von Kollegen) Default Block auf den ausgehenden Verkehr -> "Allow" RDP-Regel erstellen und IPs dort freigeben
• -> Eine Block-Regel lässt sich leider nicht aufgrund von Remoteadressen beschränken, eine Allow-Regel schon.
• Alle anderen möglichen Inbound-RDP Verbindungsmöglichkeiten der Servernachbarn kontrollieren
• Netzübergreifend die Verbindungsmöglichkeiten an der Firewall steuern

bearbeitet Dienstag um 16:56 von MurdocX

[Weingeist 157]

Am 5.5.2024 um 22:20 schrieb MurdocX:

-> Eine Block-Regel lässt sich leider nicht aufgrund von Remoteadressen beschränken, eine Allow-Regel schon.

Wieso genau sollte das nicht funktionierten? Ein Block funktioniert natürlich genauso selektiv wie eine Allow-Regel. Das Problem ist nur, dass man es nicht auf DNS-Namen machen kann.

 

Der Ansatz der Windows-Firewall ist im Grunde so einfach wie effizient. Block gewinnt immer, insbesondere auch wenn sich Bereiche mit Allow-Regeln Überschneiden. Es gibt keine Reihefolge, es werden immer alle Regeln ausgewertet. Die einzige Ausnahme ist die generelle Standard-Block Regel. Die blockiert nur, wenn es vorgängig keine erlauben Regeln gab.

Im Grunde gibt es mit diesem Ansatz nur einen echten Nachteil, es wird etwas mehr Rechenleistung verbraten als theoretisch nötig wäre.

 

Dazu sei noch erwähnt: Die Filterung auf einzelne Windows-Dienste - insbesondere wenn sie über die svchost.exe laufen - werden immer öfter maskiert. Das heisst, die BFE erkennt auch nicht mehr, welcher Dienst nun für die Kommunikation zuständig ist.  Dafür gibt es nur einen mir bekannten, hässlichen Workaround, der Dienst braucht seine eigene svchost.exe (Am besten als Hardlink, damit es Updatefest ist und nicht veraltete svchost.exe existieren können). Dabei ist wichtig, dass gruppierte Dienste auf die gleiche svchost.exe bzw. Hardlink verweisen sonst können sie nicht mehr miteinander kommunzieren. (Das gilt nur für die Dienste, die auch dann einen gemeinsamen Prozess haben, wenn das OS bei der Installation mind. 4GB RAM hatte).

So kann man ihn dennoch selektiv freigeben. Nur ist das nicht Update-fest im Sinne von neuen Windows-Versionen/Reparaturen. Manche Wartungsdienste setzen zudem manuelle Änderungen an Pfad der svchost.exe zurück (z.B. Update Health Service).

 

 

In Deinem Fall musst Du also die Standard-Regel block aktivieren und anschliessend

- Für Zugriffe welche von z.B. Client auf diesen Server erfolgt: Eine In-Regel erstellen

- Für Zugriffe welche von diesem Server auf andere Server erfolgt: Eine Out-Regel erstellen

 

Der verlinkte Artikel von testperson trifft den Nagel auf den Kopf um eben wirklich selektiv Geräte und Benutzer zu definieren welche überhaupt erst eine Verbindung aufbauen dürfen. Was genau sie dann kommunzieren dürfen, geschieht über die Rules. Geht natürlich nur, solange eben Kerberos durchgängig verfügbar ist wo entsprechende Zugriffe erforderlich sind.

 

Zusätzlich kann man noch RPC-Protokolle für beliebte Einfallstore sperren. Wie z.B. EFS, Druckerwarteschlange auf normalen Servern und Clients. Die Druckerwarteschlange braucht nur in der Funktion als Printserver Remote-Zugriff. Hier wird auch ein Vorteil sichtbar, wenn Drucker lokal installiert werden, man kann die externe Kommunikation bereits vollständig auf Protokollebene rausfiltern (auch wenn das oft lästig in der Pflege ist). Das verschafft unter Umständen Vorteile bezüglich der Verbreitung von Malware im Netzwerk und hilft möglicherweise, dass ein Problem möglichst auf einer Maschine bleibt.

bearbeitet Montag um 12:08 von Weingeist

[MurdocX 913]

Am 27.5.2024 um 14:08 schrieb Weingeist:

Wieso genau sollte das nicht funktionierten? Ein Block funktioniert natürlich genauso selektiv wie eine Allow-Regel.

Ist richtig. War wohl ein zeitlich streng begrenzter Rahmen eines technischen Schwächeanfalls aufgrund von Unterkoffeinierung. 

 

 

[Nobbyaushb 1.381]

vor 29 Minuten schrieb MurdocX:

Ist richtig. War wohl ein zeitlich streng begrenzter Rahmen eines technischen Schwächeanfalls aufgrund von Unterkoffeinierung. 

Ich leide ständig an Unterhopfung - kann man behandeln sagt mein Wirt