Windows Firewall Regeln

Wer komplexe Firewall-Regeln mit vielen IP Adressen oder ähnlichem erstellen muss, wird mit dem GUI schnell narrisch. Daher habe ich mich auf die Suche gemacht und festgestellt, dass die Firewall-Regeln in der Registry gespeichert werden und sich dort ausgezeichnet manipulieren lassen.

Die Regeln finden sich hier:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules

Die Regel für den Internet Information Server (IIS) auf Port 80 sieht z.B. so aus:

v2.22|Action=Allow|Active=TRUE|Dir=In|Protocol=6|LPort=80|App=System|[email protected]%windir%\system32\inetsrv\iisres.dll,-30500|
[email protected]%windir%\system32\inetsrv\iisres.dll,-30510|[email protected]%windir%\system32\inetsrv\iisres.dll,-30501|

Eine Regel zum Blocken bestimmter IP Adressen und ganzer Subnetze sieht z.B. so aus:

v2.20|Action=Block|Active=TRUE|Dir=In|RA4=192.168.125.0/255.255.255.0|RA4=192.168.124.34|RA4=192.168.126.223|Name=Block stupid people|

Es empfiehlt sich, die Regel via GUI anzulegen, und dann zusätzliche Adressen in der Registry hinzuzufügen.

(RaiZl)

CAPI2 Fehler während VSS Backup

Seit geraumer Zeit sichere ich unsere wichtigsten Daten - nebst doppelter Datenhaltung Vorort - mittels Livedrive  in die Cloud. Die zugehörige Software besteht aus einem Desktop-Programm und dem "Livedrive VSS Service". Seit einiger Zeit tauchten bei jedem Backup im Eventlog Einträge folgender Art auf:

20151128_capi2.jpg

 

Die darauf folgende Google-Recherche brachte folgendes als Ursache zum Vorschein:

During backup a VSS process running under NETWORK_SERVICE account calls cryptcatsvc!CSystemWriter::AddLegacyDriverFiles(), which enumerates all the drivers records in Service Control Manager database and tries opening each one of them. , The function fails on MSLLDP record with "Access Denied" error.

Turned out it fails because MSLLDP driver's security permissions do not allow NETWORK_SERVICE to access the driver record.

In meinem Fall ging es zwar nicht um den Account "NETWORK_SERVICE", aber das Problem war ansonsten identisch. Wer sich den Security Descriptor ansehen will, kann dies mit dem Sysinternals-Tool AccessChk bewerkstelligen und somit leicht feststellen, welcher Eintrag im Security Descriptor fehlt oder falsch ist (sprich der jeweilige Service Account unter dem das Service läuft).

accesschk.exe -c mslldp

Mittels System-Tool "sc" kann der Security Descriptor vom MSLLDP Treiber neu geschrieben werden (Achtung: der unten angegebene String muss nicht für jeden Fall ident sein, also vorsicht damit, eventuell den original Security Descriptor vorher sichern mittels "SC sdshow MSLLDP"):

sc sdset MSLLDP D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)(A;;CCLCSWLOCRRC;;;SU)

Schaut wild aus, ist es auch ;-).

Wenn es geklappt hat sollte "sc" wie im Screenshot ersichtlich mit "[SC] SetServiceObjectSecurity SUCCESS" reagieren:

20151128_mslldp-sc.jpg

AccessChk liefert nun folgendes:

C:\WINDOWS\system32>accesschk.exe -c mslldp

Accesschk v6.0 - Reports effective permissions for securable objects
Copyright (C) 2006-2015 Mark Russinovich
Sysinternals - www.sysinternals.com

mslldp
RW NT AUTHORITY\SYSTEM
RW BUILTIN\Administrators
RW S-1-5-32-549
R NT SERVICE\NlaSvc
R NT AUTHORITY\SERVICE

Inzwischen ist bereits ein weiteres Backup gelaufen und es wurde kein neues CAPI2 Event erzeugt.

(RaiZl)