Citrix Systeme absichern bzw. härten

In zahlreichen Projekten hatten wir die Aufgabe, Mehrbenutzersysteme auf Windows-Basis wie Citrix oder VDI Systeme zu härten. In vielen Fällen wurde eine Windows-Applikation wie z.B. ein Anwendung für die Bauplanung oder eine Finanzkalkulation auf einem Terminal Server System bzw. Citrix System bereitgestellt, um mehreren Nutzern den Zugriff auf den gleichen Datenbestand zu gewähren.
Einige Windows-Applikationen bieten von ihrer Architektur her nicht die Möglichkeit, eine Client-Anwendung auf einer Arbeitsstation zu installieren, die dann mit einer Server-Anwendung und Datenbank kommuniziert (z.B. Microsoft ProjectWise, SAP GUI, Remedy).  Sie bieten auch kein Webfrontend an, wodurch man mittels des Browser zusammen an einem Datenbestand arbeiten könnte. Oftmals handelt es sich um hoch spezielle Anwendungen aus dem Baugewerbe und Finanzsektor, deren Portierung  zu einer Weblösung eine komplexe und kostenintensive Neuentwicklung bedeuten würde.
Neben der Projektsteuerung und der Konzeption einer hinreichend sicheren Architektur kommt uns in der Regel auch die Aufgabe zu, ein solches System umfassend zu bewerten und anschließend zu härten. In den letzten Jahren verwendeten wir zu diesem Zweck bereits häufig das Werkzeug “AppSense”, welches sich mittlerweile als wesentlicher Faktor im Sicherheitskonzept einer solchen Umgebung etabliert hat.
Wir nutzen es, um den Benutzer auf dem Windows System auf die für ihn vorgesehene Aufgabe einzuschränken und den Ausbruch aus der Umgebung zu verhindern.
Im Gegensatz zur vermeintlichen Härtung über die Windows Gruppenrichtlinien, welche für unsere Auditoren niemals eine ernst zu nehmende Hürde dargestellt hatten, werden durch AppSense mehrere Schichten der Sicherheit implementiert. Einige häufig genutzte Features sollen hier kurz beschrieben werden:

• Trusted Ownership Modell
  Dieses Modell erlaubt es nur den Administratoren des Systems, ausführbare Anwendungen auf das System zu bringen und dort auszuführen. Vor allem, wenn Benutzer lokale Laufwerke montieren können, um z.B. Baupläne auf das Citrix System zu laden, will man dennoch nicht zulassen, dass der Benutzer einen Portscanner oder einen Passwort-Dumper auf das System kopiert und dann dort startet.
• White- und Black-Lists
  Über Listen können Anwendungen als unerwünscht definiert werden. Das gilt auch für Anwendungen, die nach dem Trusted-Ownership-Modell von einem Administrator auf das System gebracht wurden, wie z.B. “cmd.exe”, “netstat.exe” oder “firefox.exe”. Bei einer Kontrolle über Gruppenrichtlinien konnte man in der Vergangenheit einfach die “cmd.exe” in “cmd2.exe” umbenennen und sie dann starten. Beim Kopieren, wird allerdings der Besitzer auf den kopierenden Benutzer gesetzt, sodass eine solche “cmd2.exe” unter AppSense nicht zur Ausführung gebracht werden könnte.
• Device-Rules
  Es kann unterschieden werden, ob sich ein Benutzer aus dem internen Netz von seinem Arbeitsplatz-PC anmeldet oder ob er aus dem Internet von einem unbekannten Gerät auf das System zugreift und dementsprechend ein unterschiedliches Set an Regeln angewandt werden.
• Network-Connection Filters
  Für Gruppen auf dem System können auch Filterungen des Netzwerkverkehrs definiert werden. So kann man beispielsweise von extern kommenden Benutzern verbieten, mit anderen Systemen im internen Netz zu kommunizieren. Oder man kann bestimmen Gruppen verbieten, die IP des firmeneigenen Proxies anzusprechen, damit sie sich von dem System aus nicht ins Internet verbinden können.
• uvm.

Im folgenden Screenshot sieht man den Inhalt der Gruppe “Evil Executables”.

Der Inhalt der Meldung bei einem Block kann personalisiert werden.

Man kann die Anzeige des Benachrichtigungsfensters für die einzelnen Fälle konfigurieren und auch definieren, dass sie je nach Grund des Blocks angezeigt werden oder nicht.

Vor allem die umfassenden Möglichkeiten der Protokollierung ermöglichen eine nahtlose Überwachung des Systems. Jede Aktion, jeder Block, jeder Autorisierung und damit jeder Ausbruchsversuch wird sichtbar gemacht.
AppSense kann in ein CSV oder XML File auf der Platte, in das lokale Windows Application Log oder ein eigenes Windows Log namens “AppSense” protokollieren. In unserem Fall ist vor allem die Protokollierung in das Application Log von Windows von Vorteil, da wir in vielen Projekten die lokalen Windows Eventlogs bereits per Syslog verschicken und zentral auswerten.

So kann jeder Ausbruchsversuch schnell erkannt und behandelt werden.
Im Folgenden ist eine Ansicht aus Splunk zu erkennen, in der ein Benutzer versuchte, drei für ihn nicht freigegebene Programme aufzurufen, darunter auch die Kommandozeile “cmd.exe” und den MS Terminal Server Client “mstsc.exe”.