0
Auf geblockte eingehende oder ausgehende Verbindungen der Windows Firewall mit der Aufgabenplanung reagieren
Manchmal muss man auf bestimmte Firewall-Ereignisse mit einer Aktion reagieren. Dies lässt sich mit entsprechendem Logging der Firewall-Events in das Event-Log und einem Event-Trigger lösen. Dieser Tipp beschreibt die nötigen Schritte um auf geblockte eingehende oder ausgehende Verbindungen reagieren zu können, und diese weiter zu filtern.
Zuerst müssen wir dazu das Logging der fehlgeschlagenen Verbindungen in das Security-EventLog aktivieren (in einer administrativen Konsole ausführen):
Wenn man hier zusätzlich erfolgreiche Verbindungen loggen wollte , müsste hier noch ein 
).
Diese Einstellung lässt sich auch in der lokalen Security-Policy (secpol.msc) konfigurieren:
Ab jetzt erscheinen die Ereignisse der "Windows-Filterplattform" im Security-Eventlog.
Für den Anfang habe ich euch dafür mal zwei Tasks als XML erstellt die euch als Basis dienen (jeweils für eingehende und ausgehende Verbindungen). Diese Tasks lassen sich in der Aufgabenplanung einfach mit Rechtsklick > Aufgabe importieren einbinden:
Das "besondere" an den obigen Tasks sind die zusätzlichen Eigenschaften auf die man in der Aufgabe mit Variablen zugreifen kann. So kann man z.B. Eigenschaften des Events einem Script als Argument mit auf den Weg geben. Die Definition der Variablen findet im Abschnitt
Auf diese Variablen kann man nun folgendermaßen in den Aktionen der Aufgabe zugreifen:
In den Aufgaben ist als Beispiel eine Meldung anzeigen-Aktion hinterlegt, die die Verwendung der Variablen demonstriert.
Im jetzigen Zustand wird bei allen fehlgeschlagenen Verbindungen die Aktion getriggert. Die lässt sich auf zwei Arten einschränken: Zum einen lässt sich mit den an ein Script übergebenen Variablen entscheiden, ob eine bestimmte Aktion ausgeführt werden soll (also im Script selber), oder man bearbeitet den benutzerdefinierten Trigger der Aufgabe. Da dieser Trigger als XML-Query hinterlegt ist, muss man sich etwas mit XPath-Abfragen beschäftigen. So weit möchte ich jetzt aber nicht ausholen sondern es nur anhand eines Beispiels demonstrieren.
Weitere Informationen wie die XPath-Filter funktionieren könnt Ihr hier nachlesen:
http://blogs.technet.com/b/askds/archive/2011/09/26/advanced-xml-filter ...
Dies ist z.B. der Trigger für geblockte eingehende Verbindungen:
um jetzt z.B. nur auf geblockte Verbindungen von einer bestimmten Remote IP-Adresse zu reagieren würde der Trigger so aussehen:
Ja ich weiß das DestAddress ist etwas eigenwillig zu verstehen, aber es ist damit der Remote-Endpunkt bei eingehenden Verbindungen gemeint.
An die Detail-Informationen eines Events kommt man wenn man auf den Tab Details eines geöffneten Events klickt.
Viel Erfolg
Grüße @colinardo
Zuerst müssen wir dazu das Logging der fehlgeschlagenen Verbindungen in das Security-EventLog aktivieren (in einer administrativen Konsole ausführen):
auditpol.exe /set /subcategory:{0CCE9226-69AE-11D9-BED3-505054503030} /failure:enable
/success:enable angehängt werden (aber Vorsicht, mit der Einstellung füllt sich das Eventlog ziemlich schnell ).Diese Einstellung lässt sich auch in der lokalen Security-Policy (secpol.msc) konfigurieren:
Ab jetzt erscheinen die Ereignisse der "Windows-Filterplattform" im Security-Eventlog.
Für den Anfang habe ich euch dafür mal zwei Tasks als XML erstellt die euch als Basis dienen (jeweils für eingehende und ausgehende Verbindungen). Diese Tasks lassen sich in der Aufgabenplanung einfach mit Rechtsklick > Aufgabe importieren einbinden:
XML-Task: Auf geblockte eingehende Verbindungen reagieren
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<Triggers>
<EventTrigger>
<Enabled>true</Enabled>
<Subscription><QueryList><Query Id="0" Path="Security"><Select Path="Security">*[System[(Level=4 or Level=0) and (EventID=5157)]] and *[EventData[Data[@Name='LayerRTID']='44']]</Select></Query></QueryList></Subscription>
<ValueQueries>
<Value name="Application">Event/EventData/Data[@Name='Application']</Value>
<Value name="DestAddress">Event/EventData/Data[@Name='DestAddress']</Value>
<Value name="DestPort">Event/EventData/Data[@Name='DestPort']</Value>
<Value name="ProcessID">Event/EventData/Data[@Name='ProcessID']</Value>
<Value name="Protocol">Event/EventData/Data[@Name='Protocol']</Value>
<Value name="SourceAddress">Event/EventData/Data[@Name='SourceAddress']</Value>
<Value name="SourcePort">Event/EventData/Data[@Name='SourcePort']</Value>
</ValueQueries>
</EventTrigger>
</Triggers>
<Principals>
<Principal id="Author">
<LogonType>InteractiveToken</LogonType>
<RunLevel>HighestAvailable</RunLevel>
</Principal>
</Principals>
<Settings>
<MultipleInstancesPolicy>Parallel</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>true</RunOnlyIfNetworkAvailable>
<IdleSettings>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>P3D</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>msg.exe</Command>
<Arguments>* "Dropped incoming connection coming from $(SourceAddress) to local port $(DestPort)"</Arguments>
</Exec>
</Actions>
</Task>XML-Task: Auf geblockte ausgehende Verbindungen reagieren
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<Triggers>
<EventTrigger>
<Enabled>true</Enabled>
<Subscription><QueryList><Query><Select Path='Security'>*[System[(Level=4 or Level=0) and (EventID=5157)]] and *[EventData[Data[@Name='LayerRTID']='48']]</Select></Query></QueryList></Subscription>
<ValueQueries>
<Value name="Application">Event/EventData/Data[@Name='Application']</Value>
<Value name="DestAddress">Event/EventData/Data[@Name='DestAddress']</Value>
<Value name="DestPort">Event/EventData/Data[@Name='DestPort']</Value>
<Value name="ProcessID">Event/EventData/Data[@Name='ProcessID']</Value>
<Value name="Protocol">Event/EventData/Data[@Name='Protocol']</Value>
<Value name="SourcePort">Event/EventData/Data[@Name='SourcePort']</Value>
</ValueQueries>
</EventTrigger>
</Triggers>
<Principals>
<Principal id="Author">
<LogonType>InteractiveToken</LogonType>
<RunLevel>HighestAvailable</RunLevel>
</Principal>
</Principals>
<Settings>
<MultipleInstancesPolicy>Parallel</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>true</RunOnlyIfNetworkAvailable>
<IdleSettings>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<AllowStartOnDemand>false</AllowStartOnDemand>
<Enabled>false</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>P3D</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>msg.exe</Command>
<Arguments>* "Dropped outgoing connection to $(DestAddress) port $(DestPort)"</Arguments>
</Exec>
</Actions>
</Task>Das "besondere" an den obigen Tasks sind die zusätzlichen Eigenschaften auf die man in der Aufgabe mit Variablen zugreifen kann. So kann man z.B. Eigenschaften des Events einem Script als Argument mit auf den Weg geben. Die Definition der Variablen findet im Abschnitt
<ValueQueries></ValueQueries> des XML-Files statt.Auf diese Variablen kann man nun folgendermaßen in den Aktionen der Aufgabe zugreifen:
$(VariablenName)
Im jetzigen Zustand wird bei allen fehlgeschlagenen Verbindungen die Aktion getriggert. Die lässt sich auf zwei Arten einschränken: Zum einen lässt sich mit den an ein Script übergebenen Variablen entscheiden, ob eine bestimmte Aktion ausgeführt werden soll (also im Script selber), oder man bearbeitet den benutzerdefinierten Trigger der Aufgabe. Da dieser Trigger als XML-Query hinterlegt ist, muss man sich etwas mit XPath-Abfragen beschäftigen. So weit möchte ich jetzt aber nicht ausholen sondern es nur anhand eines Beispiels demonstrieren.
Weitere Informationen wie die XPath-Filter funktionieren könnt Ihr hier nachlesen:
http://blogs.technet.com/b/askds/archive/2011/09/26/advanced-xml-filter ...
Dies ist z.B. der Trigger für geblockte eingehende Verbindungen:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(Level=4 or Level=0) and (EventID=5157)]] and *[EventData[Data[@Name='LayerRTID']='44']]</Select>
</Query>
</QueryList>
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(Level=4 or Level=0) and (EventID=5157)] and EventData[Data[@Name='LayerRTID']="44" and Data[@Name="DestAddress"]="192.168.5.99"]]</Select>
</Query>
</QueryList>
An die Detail-Informationen eines Events kommt man wenn man auf den Tab Details eines geöffneten Events klickt.
Viel Erfolg
Grüße @colinardo
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 239022
Url: https://administrator.de/tutorial/auf-geblockte-eingehende-oder-ausgehende-verbindungen-der-windows-firewall-mit-der-aufgabenplanung-reagieren-239022.html
Ausgedruckt am: 24.12.2024 um 14:12 Uhr
