Unterschiedliche Firewallregeln für LAN-/WAN-Interface

[teehuje 0]

Hallo miteinander,

 

folgendes Problem:

Ein Windows Server 2016 steht mit einer öffentlichen IP-Adresse beim Provider, diese Schnittstelle lässt sich nicht abschalten (es sei denn man deaktiviert das Interface auf dem Server selbst).

Ich brauche diese auch für den Zugriff auf das Internet. Ein separates Interface geht in ein privates Servernetzwerk (virtuelle Maschinen), worüber ich gerne per RDP auf den Server zugreifen würde. Außerdem würde ich gerne im privaten Netzwerk weitere Dienste für die anderen VMs bereitstellen. Mein Ansatz war es zunächst den Interfaces unterschiedliche Netzwerkprofile zuzuweisen.

Wenn ich aber über den InterfaceIndex-Parameter explizit nur ein Interface angebe, übernimmt er mir das Profil aber für beide Interfaces:

PS C:\> Get-NetConnectionProfile 
Name : Netzwerk
InterfaceAlias : Ethernet 2
Index : 15
NetworkCategory : Private
IPv4Connectivity : Internet
IPv6Connectivity : NoTraffic

Name : Netzwerk
InterfaceAlias : Ethernet
Index : 10
NetworkCategory : Private
IPv4Connectivity : Internet
IPv6Connectivity : NoTraffic

PS C:\> Set-NetConnectionProfile -InterfaceIndex 10 -NetworkCategory Public
PS C:\> Get-NetConnectionProfile 
Name : Netzwerk
InterfaceAlias : Ethernet 2
Index : 15
NetworkCategory : Public
IPv4Connectivity : Internet
IPv6Connectivity : NoTraffic

Name : Netzwerk
InterfaceAlias : Ethernet
Index : 10
NetworkCategory : Public
IPv4Connectivity : Internet
IPv6Connectivity : NoTraffic

Warum ist das so? Wie kann ich das Problem umgehen? Oder weiß jemand eine andere Lösung?

Danke im Voraus :)

[daabm 1.366]

Wenn Du in verschiedenen Netzen steckst, dann hast Du auch verschiedene IPs (lokal und remote). Über die kannst Du die FW-Regeln wunderbar filtern (Registerkarte "Bereich"), funktioniert deutlich zuverlässiger als diese albernen Profile.

[Weingeist 159]

Das Profilorientierte Design ist von der Idee her nicht verkehrt, zumindest für mobile Computer.  Aber eben nur in der Theorie. In der Praxis ist eine saubere Konfig die jeweils nur mit den richtigen Profilen arbeitet nicht trivial umzusetzen und daher eher wenig zielführend. Für Server und stationäre PC's ist es eher hinderlich als brauchbar.

 

Für stationäre Computer/Server wäre eine Adapterbasierende Filterung zielführend. Leider bietet die Firewall selbst von Haus auf keine Adapter-Basierende Filterung. Die FilterEngine würde wohl irgendetwas in diese Richtung zulassen da TMG/ISA die FilterEngine um diese Funktion erweitert bzw. die FilterEngine entsprechend konfiguriert. Allerdings ist es mir nicht gelungen die Art und Weise herauszufinden wie das der ISA/TMG genau macht und die Funktionalität wurde leider nicht in die Windows-Firewall übernommen.

 

Am Ende bleibt daher eigentlich nur der Weg über die bereits genannte IP-Filterung. Ist halt extrem mühsam wenn mit IPv4 und IPv6 und möglicherweise DHCP gearbeitet wird. Insbesondere bei DHCP gibt das doch einiges an Scripting-Aufwand wenn man das automatisieren und konfigurieren möchte. Der Wildwuchs an unsichtbaren Adaptern und mehrere IPv6 Adressen pro Adapter macht es auch nicht unbedingt einfacher.

 

 

Den ausgehenden Verkehr würde ich in allen Profilen blockieren und dann die notwendigen Regeln erstellen. Leider macht MS das Regelwerk nur für den IN-Verkehr selber zuverlässig OUT ist fast nur für die Telemetrie mit Standard-Regeln sauber erstellt, den Rest darf man händisch selber herausfinden ;)

 

Was blockiert wird und durchgeht kanns übrigens mit der Protokollierung herausfinden. Etwas umfangreicher als die vom Firewall-Dienst ist jene der FilterEngine selbst.

 

Aktivieren in CMD:

auditpol.exe /set /Category:"Objektzugriff /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable

oder international: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

--> Schreibt dann Protokoll, ProzessID, Port beteiligte IP's ins Sicherheitsprotokoll der Ereignisazeige. Auf dieser Basis kannst dann FW-Regeln erstellen.

[Dukel 455]

Die Frage ist ob man das mit Windows machen würde. Das klingt eher nach einer Aufgabe für einen Router/Firewall.

 

[Weingeist 159]

Darüber lässt sich bei allem im Security-Bereich streiten. Auf alle Fälle sind es ein paar deutliche Steine mehr im Weg wenn ein Client infiziert wird oder ausser Haus geht für den Rest der Infrastruktur. Die Filter-Engine von MS ist ziemlich robust und bietet selber wohl nicht viel Angriffsfläche. Wenn MS die Firewall nicht permanent mit nicht offensichtlich konfigurierbaren Regeln automatisch für fragwürdige Apps löchern und missbrauchen würde, wäre sie vermutlich durchaus als sicher zu bezeichnen.