Eine Möglichkeit unerlaubte Kommunikation zu blocken ist es, die entsprechenden Programme erst überhaupt nicht zu installieren. Dazu bieten sich die Gruppenrichtlinien des Windows Server 2003 an, welche zentrale eine Konfiguration für angemeldete Benutzer und Systeme bereit stellen.
Über die optional zu installierende Gruppenrichtlinien-Verwaltungskonsole kann man komfortabel die Richtlinien auf Organisationseinheiten (OU) oder Standorte verteilen. Man kann sie über die Sicherheitsfilterung bestimmten Anwendern oder Systemen zuweisen und über die WMI-Filterung an weitere Bedingungen knüpfen.
Hilfreiche Tricks und Tutorials über das Thema Gruppenrichtlinien findet man auf der Seite von Mark Heitbrink.
Mittels der SRP – der Software Restriction Policies – oder auch der “Richtlinien für Softwareeinschränkung” im GPO Bereich
Computerkonfiguration > Windows-Einstellungen > Richtlinien für Softwareeinschränkungen
legt man zunächst die neuen noch leeren Richtlinien an.
Grundsätzlich gibt es vier verschiedene Möglichkeiten, Softwareeinschränkungen zu definieren:
- als Hash,
- mit einem Zertifikat,
- als Pfad
- in Zonen (Internetzonen).
Die genaue Beschreibung findet man auf dieser Technet-Seite von Microsoft.
Hash-basierte Regeln nimmt man z.B. wenn man bestimmte Programmversionen “treffen” will. Der Vorteil von Hash-basierten Regeln ist der das die Datei auch umbenannt oder verschoben werden kann, und trotzdem immer wieder identifiziert wird.
Eine Hashregel hat die Form
<md5-oder-sha1 Hash>:<Dateilänge in Bytes>:<Hash Algorithmus ID>
Ein Beispiel der Datei Skype.exe (siehe unten) lautet
117268c20028d5ee9359da6e8d74df07:21760296:32771
Wobei 117268c20028d5ee9359da6e8d74df07 der Hash der betreffenden Datei, 21760296 die Dateigröße in Bytes und 32771 die Hash-ID von MD5 ist (SHA1 hätte die ID 32772). Die Dateigröße bezieht sich auf die eigentliche Dateigröße und nicht auf die Größe auf dem Datenträger.
Das klingt auf den ersten Blick alles sehr kompliziert – Windows automatisiert hier aber sehr viel so dass man sich z.B. um die Berechnung und die ID nicht kümmern muss (siehe unten).
No Comments on "Blocking evil comminication (Teil II)"