Windows Firewall mit Erweiterter Sicherheit debuggen von DROP Paketen


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/

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s


%d Bloggern gefällt das: