Ansicht umschalten
Avatar von oneSTone o2o
  • oneSTone o2o

mehr als 1000 Beiträge seit 07.01.2000

Applocker - der Hebel mit dem man in einem AD gegen Locky ansetzen kann

Application-Locker (nicht Application-Blocker, obwohl es das auch ganz gut treffen würde, weil es geht ja letztlich darum, nicht erwünschte Programmdateien auszusperren.)

Wer über ein AD mit Group-Policies verfügt, ist eigentlich fein raus. Man muss es nur richtig machen. Eine automatisierte Softwareverteilung, damit man den ganzen Krempel nicht von Hand und in unterschiedlichen Versionen (aus verschiedenen Ordnern, Sammlungen, "gerade eben mal runtergeladen", ...) installiert, ist auch hilfreich.

Laut Golem.de *1 lädt das Office-Makro von Locky eine ladybi.exe herunter und startet diese. Darin steckt der eigentliche Schadcode. Das ist der Hebel, an dem man gegen Locky und andere ähnliche Programme ansetzen kann.

Folgendes:

Man lege eine neue Computer-Policy an, die auf alle Computer (PCs, Laptops, Terminalserver, virtuelle Desktops, eben alles wo User Unsinn bauen können *2) im AD oder in der gewünschten OU greift.

- Compute Configuration
-- Policies
--- Windows Settings
---- Security Settings
----- Application Control Policies
------ Applocker
------- Executeable Rules

Da drin kann man nun Regeln definieren, welche Applikationen vom Benutzer ausgeführt werden dürfen. Das können Allow und Deny Regeln sein, die nach folgenden Regeln entschieden werden:
- Publisher, das heißt, in der EXE-Datei muss ein Zertifikat des Softwareherstellers hinterlegt sein. Ok, kann man fälschen, ist aber schon schwierig.
- Path. Hier sollte man natürlich sinnvollerweise auf jeden Fall "c:\windows", "c:\programm files" und "c:\program files (x86)" als "allow" (für Everyone oder Domain Users) hinterlegen, sonst sägt man sich den Ast ab, auf dem man sitzt. Man muss außerdem dafür sorgen, dass diese Ordner vom Anwender nicht beschrieben werden können, aber das ist eigentlich Standard in einer normalen Windows-Installation. Niemand meldet sich mit Admin-Rechten zum normalen Arbeiten an, nichtmal Admins *4, sonst ist eh alles für die Katz.
- File hash, dazu muss man alle Exe-Dateien, die ausgeführt werden können sollen, mal "einsammeln" und (also "c:\oracle" nach "*.exe" durchsuchen und diese dann temporär in einen Ordner kopieren und von dort) von diesem Policy-Assistenten einen Hash errechnen lassen, der dann für jede dieser Exe-Dateien in der Policy hinterlegt wird. (die temporären Kopien kann man danach wieder löschen, es zählt dass der Dateiname mit seinem Hash in der Policy enthalten ist!) Dann können diese Programme von jedem Laufwerk gestartet werden. Man sollte halt nur nicht unbedingt ladybi.exe hashen...

Sobald man Regeln in dieser Policy eingestellt hat, ist diese aktiv und man kommt nicht mehr drumherum. Empfehlung: Unbedingt eine eigene Policy dafür, nicht eine andere Policy dafür mißbrauchen. Denn wenn es eine eigene Policy ist, kann man sie, fals man was falsch gemacht hat, jederzeit ohne weitere Folgen einfach deaktivieren. Anfangs ist es gut, einen PC (oder Server) zu haben, auf dem das Group-Policy-mmc läuft, der nicht in der OU ist, auf den die Applocker-Policy nicht wirkt, aber sobald man ein prinzipiell funktionierendes Regelwerk hat, ist dieser Notanker nicht mehr nötig.

Evtl. nimmt man per "Restricted Users" die Admins da raus, da ein Admin per Rechtsklick und "Run As Admin" ein Programm immer noch starten kann, oder der Admin kopiert das setup.exe nach "c:\program files\install" und startet es von dort.

So praktizieren wir das hier schon seit Jahren (seit Win 7 Einführung und nachdem diese Policy verstanden wurde! *3) in einer Umgebung mit etwa 1500 Plätzen. Locky ist hier kein Thema. Und ja, anfangs, wenn man einen neuen Kollegen dazu bekommt, der sich ein Admintool installieren will, der tut sich damit erstmal schwer, aber man gewöhnt sich dran.

*1 Siehe http://www.golem.de/news/krypto-trojaner-locky-mehr-als-5-000-infektionen-pro-stunde-in-deutschland-1602-119247.html
*2 Auf normale Server, wo User sich nicht aufschalten können, sondern nur Admins, sollte man diese Policy nicht wirken lassen, damit macht man sich nur das Leben schwer. Aber Paranoia ist in dem Fall auch nicht ganz falsch, kommt auf die Umgebung und den Anspruch an.
*3 Erstmal in einer eigenen OU mit ein paar PCs in dieser OU testen, damit man versteht, wie das funktioniert!
*4 Administrative Sachen startet der Admin selbstverständlich mit "run as" (shift rechte Maustaste auf das Program, und dann der separate Admin-Account, der dann die speziellen AD-Berechtigungen und im Dateisystem hat).

Wer es anders macht, dem ist leider nicht zu helfen.

Das Posting wurde vom Benutzer editiert (19.02.2016 18:43).

Bewerten
- +
Ansicht umschalten