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|Name=@%windir%\system32\inetsrv\iisres.dll,-30500|
Desc=@%windir%\system32\inetsrv\iisres.dll,-30510|EmbedCtxt=@%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)
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:
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:
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)