Mit Windows 7 und Windows Server 2008 R2 wurde ein Sicherheitsfeature von Microsoft eingeführt, welches bis dato ein bisschen ein Schattendasein fristet. In den Vorgängerversionen von Windows gab es Software Restriction Policies unter den Group Policy Einstellungen. Diese wurden eingesetzt, wenn auch nur spärlich, um Benutzer an der Ausführung gewisser Programme zu hindern (Blacklisting). Da dieses Ziel aber auch über die NTFS Berechtigungen erreicht werden kann, wurde die Software Restriction selten bis gar nie eingesetzt. Microsoft hat nun mit dem AppLocker den Ansatz umgedreht und ist zu einem Whitelisting-Verfahren übergegangen. Dies bedeutet, dass alles verboten ist was nicht explizit erlaubt wurde. Also der gleiche Ansatz wie bei Firewall-Regelwerken.

Einsatzgebiet

Auch wenn natürlich der Einsatz auf den Endgeräten wünschenswert wäre, so sehe ich das grösste Potenzial dieses Feature im Bereich des Microsoft Terminal Server und Citrix XenApp. Die Herausforderung in diesen Umgebungen ist ja dem Benutzer alle Möglichkeiten zu lassen, um effizient zu arbeiten, aber das System so zu sichern (Hardening), dass kein Ausbrechen aus der vorgegebenen Umgebung möglich ist.

Terminal Server und Citrix XenApp Administratoren, die sich mit Sicherheit befassen, kommen früher oder später in Kontakt mit dem Whitelisting Ansatz. In diesem Bereich haben sich Firmen wie AppSense und triCerat mit ihren Lösungen einen Namen gemacht. Ich wollte mal schauen, was ich mit dem AppLocker schon alles abdecken kann, was die gestandenen Lösungen bieten.

Das Ziel

Zuerst brauche ich ein Ziel, das ich mit der Lösung erreichen will. Das Ziel ist rasch definiert: Ein Benutzer soll nur die ihm zugewiesenen Applikationen starten können. Wie Marc Ruef in seinem Artikel Citrix under Attack beschreibt, besteht ein grosses Risiko, dass man aus der vorgesehenen Umgebung ausbrechen kann.

Erste Schritte

Hier wird eigentlich schon klar warum diese Feature ein Schattendasein fristet. Man findet es nicht prominent als Programmpunkt irgendwo aufgelistet, sondern als Unterpunkt in der lokalen oder globalen Computer Policy. Da ich ein Fan von zentral gemanagten Systemen bin, entscheide ich mich für den GPO (Group Policy Object) Ansatz. Dies erlaubt mir die Policy gleichzeitig auf all meinen Terminal Server einzusetzen.

Nach dem Erstellen des GPO finde ich die AppLocker Einstellungen unter dem Menupunkt Computer Configuration/Policies/Windows Settings/Security Settings/Application Control Policies/AppLocker. Nun sehe ich, welche Einstellungsmöglichkeiten ich habe. Insgesamt kann ich aus fünf verschiedenen Regelgruppen auswählen. In der nachfolgenden Tabelle sind die Gruppen und deren betroffenen Dateien ersichtlich. Die Gruppe DLL Rules ist als erstes nicht ersichtlich und muss über die Einstellungen von AppLocker zuerst aktiviert werden. Ich lasse sie für die Terminal Server Umgebung aber deaktiviert, da jeder DLL Aufruf gegen das Regelwerk geprüft werden müsste und die Performance enorm darunter leiden würde. Auch würde sich der Konfigurationsaufwand und die Fehleranfälligkeit unnötig erhöhen.

Als erstes erstelle ich für die vier verbleibenden Regelgruppen die Standardregeln. Dies geschieht einfach mittels rechter Maustaste und Create Default Rules. Dies dient mir als Basis für mein Regelwerk. Vor allem wird jeweils eine Regel für die Administratoren erstellt, damit die nicht aus Versehen aus dem System ausgesperrt werden. Nun bin ich bereit das Regelwerk zu definieren.

Das Regelwerks erstellen

Zuerst erstelle ich eine Standard Regel. Die soll mir aufzeigen, auf was für Dateien ein Benutzer in einer Remote Desktop Session Zugriff braucht. Dafür wähle ich Notepad als meine Testapplikation aus. Ich weiss, dass Notepad keine weiteren Programme braucht, um starten zu können.

Ich wähle bewusst die Regel für Dateipfade aus. Mit den NTFS Rechten kann ich die Executables sehr gut vor Änderungen schützen. Generell Publishern vertrauen kommt für mich nicht in Frage. Microsoft liefert mit Windows genügend Programme, um aus dem Kontext auszubrechen. Diese wären alle erlaubt, wenn ich Microsoft vertrauen würde. Und der Filehash ist eine sehr gute Möglichkeit um sich zu schützen, man muss aber die Regeln anpassen sobald kleinste Änderungen an der Software erfolgen (z.B. Patches). Nun gebe ich den Pfad von notepad.exe (%SYSTEM32%\notepad.exe) in der Regel an und erlaube die Ausführung für alle Domain Users. Ist die Regel erstellt, folgt schon der nächste Schritt.

Das Regelwerk testen und aktivieren

Als nächstes aktiviere ich die Regel im Audit only Modus. Damit überwache und teste ich die Regel.

Das heisst die Anwendungen werden geprüft und alle Aktivitäten werden aufgezeichnet. Im Event Viewer und dem Punkt Applications and Services Logs/Microsoft/AppLocker findet man alle Logs betreffend Applocker. Nun finde ich Warnungen über Applikationen, die nicht gestartet hätten werden können.

Warnung: Damit die Regel auch greift, muss der Service Application Identity gestartet sein. Auch sollte das Startverhalten von Manual auf Automatic eingestellt werden. Ansonsten greifen die Regeln nicht.

Nun habe ich genügend Informationen, um für die alle Applikationen, die für die Remote Desktop Verbindung gebraucht werden, eine Regel zu erstellen. Nach der Anpassung der Regel und einem weiteren Test kann ich nun alle Regeln aktivieren.

Wenn ich nun versuche auf Applikationen und Scripts zuzugreifen, kriege ich eine Fehlermeldung, die mich darauf hinweist, dass ich keine Berechtigung zur Ausführung habe.

Dies geschieht bei allem, was ich versuche auszuführen – bis auf diejenigen Sachen, die ich explizit erlaubt habe. Das Regelwerk kann nun nach Belieben erweitert werden, um die Umgebung genau nach den vorgegebenen Sicherheitsrichtlinien zu gestalten.

Fazit

Microsofts AppLocker ist eine einfache Whitelisting Lösung, die man vor allem im Bereich Terminal Server einsetzen kann. AppLocker hat nicht den Umfang von den bekannten Lösungen – wie von AppSense oder triCerat -, bietet aber genügend Funktionalität, um ein Whitelisting-Konzept umzusetzen. Auch darf man AppLocker nicht als eigenständige Lösung betrachten, sondern immer als einen Teil des ganzen Hardening-Konzepts. Weitere Anregungen betreffend Windows Hardening hat Andrea Covello in seiner dreiteiligen Hardening-Serie veröffentlicht

Über den Autor

Links

• https://www.computec.ch/download.php?view.747