Archive for the ‘Firewall’ Category

Vorsicht mit Get-NetFirewallRule bzw. WMI MSFT_NetFirewallRule-Klasse bei Abfrage der Enabled-Eigenschaft – gilt allgemein bei $True und $False in Powershell

10 Juli 2016

Ein Script welches Windows Firewall Regel-Eigenschaften abfragte funktionierte nicht wie erwartet. Es wurde immer die Enabled Eigenschaft abgefragt aber es kam nicht das erwartete Ergebnis, wurde die Abfrage aber negiert, kam das erwartete Ergebnis heraus! Am Ende stellte es sich heraus, dass die Enabled-Eigenschaften kein klassisches Bool sondern einen String zurückgibt, hier die Story:

Fragen wir zunächst die aktuelle Anzahl von Regeln ab, hier bei einem aktuellen Windows 10:

$r=Get-NetFirewallRule
$r.length
413

Es gibt also 413 Regeln. Nun sollen alle Regeln ermitteln werden, die aktiviert sind:

($r | where enabled -eq $true).length
184

Jetzt sollen alle Regeln ermittelt werden, die nicht aktiviert sind:

($r | where enabled -eq $false).length
0

Die 0 ist jetzt nicht das erwartete Ergebnis, wenn man davon ausgeht, dass es 413 Regeln gibt, davon sind 184 aktiv, dann sollten mehr als 0 inaktiv sein.

Wo liegt das Problem? Das Problem ist, dass bei $True oder $False in Powershell immer True oder False am Bildschirm ausgegeben wird. Man interpretiert einen solchen Wert schnell als Boolean. Aber in diesem Fall hat man es nicht mit einem Boolean zu tun:

$r[0].enabled.pstypenames
Microsoft.PowerShell.Cmdletization.GeneratedTypes.NetSecurity.Enabled
System.Enum
System.ValueType
System.Object

Es ist also ein Aufzählungstyp!

($r | where enabled -eq "True").length
184
($r | where enabled -eq "False").length
229

So macht die Sache mehr Sinn!

Oder man macht die Abfrage über den passenden Typ:

($r| where enabled -eq ([Microsoft.PowerShell.Cmdletization.GeneratedTypes.NetSecurity.Enabled]:
:True)).length
184
($r| where enabled -eq ([Microsoft.PowerShell.Cmdletization.GeneratedTypes.NetSecurity.Enabled]:
:False)).length
229

Übrigens: $true –eq "True" ergibt immer True, auch wenn man $true –eq "irgendwas" setzt! Und $False –eq "False" ergibt immer False, egal mit was verglichen wird, außer $false!

Änderungen an Windows Firewall protokollieren mit Vergleich vorher/nachher

18 Juli 2015

Wenn man manchmal Programme installiert, dann ändern diese Einstellungen an der Firewall. Wenn man nun protokollieren möchte, was geändert wurde, so kann man sich – wie immer – Powershell bedienen.

Seit Windows 8 gibt es die Network Security Cmdlets, dort findet sich Get-NetFirewallRule. Hiermit kann man folgendes machen:

$fwVorher = Get-NetFirewallRule

Damit erzeugt man quasi einen Snapshot $fwVorher mit den alten Einstellungen der Firewall. Hier ein paar kurze Infos zum Status:

PS C:\Windows\system32> $fwVorher.Count
384
PS C:\Windows\system32> ($fwVorher|where enabled -eq True).Count
138

Es gibt also insgesamt 384 Firewallregeln, davon sind schon 138 aktiviert.

Jetzt geht man her und nimmt Änderungen am System vor. Hier aktiviere ich in einem neu eingerichteten Windows 8.1 Pro den RemoteDesktop und frage danach nochmal obige Informationen ab. Ich speichere es aber wieder in einer Variablen.

PS C:\Windows\system32> $fwNachher=Get-NetFirewallRule
PS C:\Windows\system32> ($fwNachher|where enabled -eq True).Count
141

Es sind also drei Regeln aktiviert worden. Stellt sich die Frage, welche das waren? Hier kommt nun wieder die Mächtigkeit von Powershell zum Tragen, denn wir kennen den Zustand davor und danach, somit können wir Powershell beauftragen die Unterschiede zu finden:

PS C:\Windows\system32> diff $fwVorher $fwNachher

InputObject                                                 SideIndicator
———–                                                 ————-
MSFT_NetFirewallRule (CreationClassName = "MSFT?FW?Firew… =>
MSFT_NetFirewallRule (CreationClassName = "MSFT?FW?Firew… =>
MSFT_NetFirewallRule (CreationClassName = "MSFT?FW?Firew… =>

Ja toll, super das wussten wir davor schon, dass es drei Regeln sind. Die Informationsaussage ist gleich 0. Nächster Versuch, das Compare-Object Cmdlet welches dem diff-Alias zugrunde liegt kennt einen Parameter Property mit dem kann man die Eigenschaft bestimmen, welche verglichen werden soll. Vielleicht klappt es ja damit:

PS C:\Windows\system32> diff $fwVorher $fwNachher -Property Enabled

                                                    Enabled SideIndicator
                                                    ——- ————-
                                                       True =>
                                                       True =>
                                                       True =>

Nicht viel besser wie die erste Variante.

OK, die Lösung des Problems ist ein weiterer Paramater: Passthru

Hier die Variante, wo alles schön ausführlich ausgibt:

diff $fwVorher $fwNachher -Property Enabled -PassThru

Eine etwas besser lesbare Variante wäre die hier:

PS C:\Windows\system32> (diff $fwVorher $fwNachher -Property Enabled -PassThru)| select dis*, des*, ena* | Fl *

DisplayName  : Remotedesktop – Schatten (TCP eingehend)
DisplayGroup : Remotedesktop
Description  : Eingehende Regel für den Remotedesktopdienst, um das Spiegeln einer vorhandenen Remotedesktopsitzung
               zuzulassen. (TCP eingehend)
Enabled      : True

DisplayName  : Remotedesktop – Benutzermodus (UDP eingehend)
DisplayGroup : Remotedesktop
Description  : Eingehende Regel für den Remotedesktopdienst, die RDP-Datenverkehr zulässt [UDP 3389]
Enabled      : True

DisplayName  : Remotedesktop – Benutzermodus (TCP eingehend)
DisplayGroup : Remotedesktop
Description  : Eingehende Regel für den Remotedesktopdienst, die RDP-Datenverkehr zulässt. [TCP 3389]
Enabled      : True

Damit hat man nun ein schönes Protokoll, welche Firewallregel aktiviert bzw. deaktiviert wurde.

Übrigens Windows 10 Build 10158 bringt in der Pro Fassung 626 Firewallregeln mit! Da geht was…

Windows 8.1 Netzwerkprofil ändern von Öffentlich oder Unbekannt auf Privat, anders formuliert: Warum sehe ich meinen Drucker oder Scanner nicht?

30 Oktober 2013

Wieder mal ein tolles Thema. Ich bin entweder zu blöd oder zu alt um bei einem Windows 8.1 Gerät die Netzwerkprofilzuordnung zu ändern. Aber wahrscheinlich ist – wie immer – eher Microsoft schuld, denn seit die auf User Experience machen, wird immer alles komplizierter.

Konkret ging es darum, einen Wifi-Direct Drucker unter Windows 8.1 anzubinden. Wenn aber der Drucker nicht auftaucht, was macht man dann? Zunächst muss ich sagen, dass ich nicht wissentlich gefragt wurde, ob ich den Drucker dem öffentlichen oder privaten Netzwerkprofil zuordnen möchte. Diese Einstellung aber im Nachhinein zu ändern, ist fast unmöglich, zumindest für mich. Vielleicht hat mir mal jemand eine GUI-Anleitung.

Sei es drum, da die GUI der Mode unterliegt und dies sicher die nächsten Jahre noch mehr zunehmen wird, gilt es, das Schweizer Taschenmesser, mit Namen Powershell auszupacken.

Also zunächst die Verbindung mit dem Drucker per Wifi-Direct hergestellt. Dann als Admin eine Powershell-Eingabeaufforderung geöffnet und dann

Get-NetConnectionProfile

ausgeführt. Mit dem Ergebnis:

Name             : Netzwerk
InterfaceAlias   : Ethernet 4
InterfaceIndex   : 5
NetworkCategory  : Public
IPv4Connectivity : Internet
IPv6Connectivity : LocalNetwork

Hier kann man erkennen, dass in diesem Fall das Profil auf Public gesetzt ist. Als Admin kann man es aber ganz einfach ändern, man muss nur den Index und die gewünschte Kategorie angeben:

Set-NetConnectionProfile –InterfaceIndex 5 –NetworkCategory Private

Das wars. Nun wird der Drucker, Scanner oder was auch immer sofort erkannt und kann bei den Geräten in den Windows-Einstellungen hinzugefügt werden.

Diese Methode hat den Vorteil, sie funktioniert die nächsten 30 Jahre! Wetten?

Windows Firewall mittels netsh konfigurieren

10 Juli 2012

Hier ein schöner Knowledge Base Artikel der verschiedene Konfigurationsbeispiele der erweiterten Windows Firewall mittels netsh darstellt. Vor allem werden die einfachen firewall den erweiterten firewall Befehlen gegenübergestellt.

http://support.microsoft.com/kb/947709

Was man damit anstellen kann?

Man könnte z. B. den Messenger dazu bringen sich nicht mehr automatisch bei MS anzumelden:

http://messengergeek.wordpress.com/2012/02/29/how-to-stop-the-built-in-messenger-from-signing-in-on-windows-8-consumer-preview/

Windows Firewall LOG-Datei PFirewall.LOG per Powershell analysieren

21 November 2010

Aufgrund des genialen Formats der pfirewall.log-Datei hier ein Einzeiler für Powershell, damit man die entscheidenden DROPs nicht verpasst:

$sr = New-Object System.IO.StreamReader ("pfirewall.log"); while (($line = $sr.ReadLine()) -ne $null) {if ($line -match "DROP") {Write-Host -fore Red $line} else {Write-Host $line}}; $sr.Dispose()

Drops werden nun immer in roter Farbe dargestellt.

Da die Methode die Logdatei Zeilenweise ausließt geht alles ganz flott und funktioniert auch mit riesengroßen Dateien.

Hier eine Variante vom Scripting Guy der mehr auf Details in der Log eingeht: http://blogs.technet.com/b/heyscriptingguy/archive/2009/04/16/how-can-i-parse-my-firewall-log-file-to-see-what-kind-of-packets-are-being-sent.aspx

Windows Firewall mit Erweiterter Sicherheit debuggen von DROP Paketen

12 November 2010

Wenn es mal wieder nicht klappt mit dem Zugriff von einem entfernten Rechner auf Netzwerkressourcen könnte es an der Windows Firewall liegen. Vorhanden ab Windows Vista.

Zuerst muss man mal rausfinden ob dem so ist.

Man startet also die Windows Firewall mit erweiterter Sicherheit (WF.MSC).

Dort schaut man dann zuerst welches Profil aktuell aktiv ist und klickt dann auf “Windows-Firewalleigenschaften” oder man klickt links im Baum auf den obersten Eintrag mit der rechten Maustaste und geht auf Eigenschaften.

Es öffnet sich ein Dialog mit Registern für jedes Profil. Hier klickt man nun auf das aktuell aktive Profil. Nun kann man bei Protokollierung durch klick auf Anpassen den Pfad sowie die Einstellungen dafür verändern.

Hier sollte man sich nun mindestens den Pfad für die Logdatei merken und die Protokollierung von verworfenen Paketen aktivieren. Der vorgebene Pfad lautet:

C:\Windows\system32\LogFiles\Firewall\pfirewall.log

Nun werden die verworfenen Pakete in der LOG-Datei gespeichert, allerdings muss man teilweise ein paar Sekunden warten bis die Daten in der LOG-Datei auftauchen.

Verworfene Pakete sehen dann so aus:

2010-11-12 18:44:51 DROP TCP 192.168.10.22 192.168.10.20 54745 8624 48 S 1684385589 0 65535 – – – RECEIVE
2010-11-12 18:45:07 DROP TCP 192.168.10.22 192.168.10.20 54745 8624 48 S 1684385589 0 65535 – – – RECEIVE
2010-11-12 18:47:47 DROP TCP 192.168.10.22 192.168.10.20 54747 8624 64 S 1346924637 0 65535 – – – RECEIVE

Tolle Sache. Hier die Beschreibung des Formats: http://technet.microsoft.com/en-us/library/cc753781(v=WS.10).aspx. Aber den Grund warum die Pakete verworfen wurden, der wird einem nicht mitgeteilt.

OK, als erstes sollte man auf dem betreffenden Server Rechner erst prüfen ob die betreffende Serveranwendung überhaupt läuft:

netstat –an

hilft. Dort sollte bei der lokalen Adresse 0.0.0.0 mit dem passenden Port stehen und der Status sollte ABHÖREN lauten.

Tiefergehende Infos bekommst man als Admin mittels

netstat –p TCP –abn

Dann werden die Prozesse angezeigt ebenso findet eine Einschränkung des Protokolls auf TCPv4 statt.

Mittels Event Tracing kann man das Spiel nun weiter treiben und noch tiefer schauen. Das Event Tracing ist eine ziemlich mächtige Sache. Hier bin ich schon mal darauf eingegangen in Verbindung mit USB: https://newyear2006.wordpress.com/2009/12/27/usb-probleme-in-windows-7-analysieren-und-verstehen/

Man kann sich tiefergehende Infos mittels netsh mitschneiden. Dazu startet man

netsh wfp

Dieser Befehl startet die Netzwerkshell und wechselt zum WFP Kontext welcher für Windows-Filter-Platform steht, welche für das inspizieren der Pakete zuständig ist.

Hier kann man nun das Aufzeichnen von Paketen mittels

capture start

aktivieren. Alle Pakete die nun empfangen werden, werden nun gespeichert und in die Datei WFPDiag.CAB im aktuellen Verzeichnis abgelegt wenn man den Befehl

capture stop

eingibt.

Die Datei WFPDiag.CAB enthält dann zwei Dateien die WFPDiag.ETL und WFPDiag.XML. Die XML-Datei kann man sich dann direkt anschauen und findet so interessante Einträge wie:

<netEvent>
<header>
  <timeStamp>2010-11-12T16:03:08.836Z</timeStamp>

<flags numItems="8">
  <item>FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET</item>

  <item>FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET</item>

  <item>FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET</item>

  <item>FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET</item>

  <item>FWPM_NET_EVENT_FLAG_REMOTE_PORT_SET</item>

  <item>FWPM_NET_EVENT_FLAG_APP_ID_SET</item>

  <item>FWPM_NET_EVENT_FLAG_USER_ID_SET</item>

  <item>FWPM_NET_EVENT_FLAG_IP_VERSION_SET</item>

  </flags>

  <ipVersion>FWP_IP_VERSION_V4</ipVersion>

  <ipProtocol>6</ipProtocol>

  <localAddrV4>192.168.10.20</localAddrV4>

  <remoteAddrV4>192.168.10.22</remoteAddrV4>

  <localPort>8624</localPort>

  <remotePort>54619</remotePort>

  <scopeId>0</scopeId>

<appId>
  <data>530079007300740065006d000000</data>

  <asString>S.y.s.t.e.m…</asString>

  </appId>

  <userId>S-1-5-18</userId>

  </header>

  <type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>

<classifyDrop>
  <filterId>74004</filterId>

  <layerId>44</layerId>

  <reauthReason>0</reauthReason>

  <originalProfile>2</originalProfile>

  <currentProfile>2</currentProfile>

  </classifyDrop>

  </netEvent>

Ist leider etwas unformatiert. Aber hier finden sich die gesuchten Informationen wieder: Die IP-Adresse des anfragenden Computers 192.168.10.22 und die des lokalen Computers mit 192.168.10.20 wo Port 8624 angesprochen werden soll.

Der Zweig mit ClassifyDrop enthält noch weitere Hinweise:

<classifyDrop>
  <filterId>74004</filterId>

  <layerId>44</layerId>

  <reauthReason>0</reauthReason>

  <originalProfile>2</originalProfile>

  <currentProfile>2</currentProfile>

  </classifyDrop>

Die Struktur wird in http://msdn.microsoft.com/en-us/library/ee707311(v=VS.85).aspx näher erläutert.

Entscheidend ist die LayerID 44  welche auf FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4 weiter oben in der XML-Datei zeigt. Übersicht der Filter: http://msdn.microsoft.com/en-us/library/aa366492(v=VS.85).aspx

Manchmal kann es helfen so tief ins System Einblick zu bekommen. Im konkreten Fall brachte es aber nichts. Erst als anstatt IIEXPRESS.EXE explizit der zugehörige Port 8624 per neuer Firewallregel geöffnet wurde, hat es funktioniert.

Den einen oder anderen Hinweis für die Innereien der Filterplattform findet man auch im Entwicklerforum: http://social.msdn.microsoft.com/forums/en-US/wfp/threads/