schlangen, aber auch die Befehlshistorie
und die letzten Logins (»last«) stehen da
im Fokus. Autopsy aus dem Sleuth Kit
([13], Abbildung 6) hilft dem forensisch
tätigen Admin ebenfalls.
Wer besonders gut vorbereitet sein will,
setzt ein Baseline Image ein. Gerade in
Zeiten von Containern und Virtualisierung
helfen solche Vorlagen, die den letzten
„gesunden“ Konfigurationsstand definie-
ren, mit »diff« und »find« Unterschiede
der letzten Tage, Wochen oder gar Mo-
nate zu entdecken. So lassen sich dann
schnell etwaige Änderungen durch
Hacker aufspüren.
Nicht zu weit gehen
Weitere zentrale Fragen für die Analyse
lauten: „Wie weit soll der Admin gehen?
Wie viel Zeit hat er? Wo liegen seine Prio-
ritäten?“ Auch hier helfen klare Vorgaben
und Entscheidungen im Vorfeld – im Rah-
men eines Katastrophenplans. Der sollte
selbstverständlich auch Zeit für weitere
Maßnahmen einplanen wie:
n Alle Passworte ändern.
n Neue Backups anlegen (inklusive
Tests zur Wiederherstellung).
n Alle Third-Party-Produkte gegebenen-
falls entfernen und wieder einspielen.
n (Temporär) alle Komponenten entfer-
nen, die mit Geld, dem Zahlungspro-
zess und Abrechnungen zu tun haben
(Schadenvermeidung).
n Alle möglicherweise betroffenen Kun-
den, Anwender und Stakeholder in-
formieren.
n Intensives Rund-um-die-Uhr-Monito-
ring nach dem Neustart.
Gerade im amerikanischen Kulturkreis
finden sich auf zahllosen Webseiten
Tipps dazu, was Admins nach dem Hacktun sollten. Stellvertretend sei hier auf
Jonathan Hassels „11 Things to do when
you have been hacked“ verwiesen [14].Menschen machen Fehler
Aber wie machen das professionelle Er-
mittler? Ein Artikel aus der „Süddeut-
schen Zeitung“ beschreibt die Möglich-
keiten der Forensiker, um beispielsweise
APT28, die „am besten erforschte Ha-
ckergruppe“, zu enttarnen [15].Bevor Admins ihre Flotte an Arbeitsplatzrech-
nern nach einem Kompromittierungsversuch
wieder in Betrieb nehmen, müssen sie diese
mit einem vertrauenswürdigen Betriebssys-
tem bespielen. Hier ist deutlich im Vorteil, wer
auf Thin Clients setzt. Die meist lüfterlosen
Kästchen verwirklichen konsequent das Server-
Client-Prinzip: Daten und Anwendungen bleiben
auf dem Server, der Client hat sich allein um
die Ausgabe von Bild und Ton zu kümmern und
die Eingaben von Maus und Tastatur entgegen-
zunehmen.
Damit entspricht der schlanke Arbeitsplatz-
rechner mustergültig einer der Empfehlungen,
die die US-Behörde NIST (National Institute of
Standards and Technology) in ihrem Notfallplan-
Leitfaden 800-34 gibt [18]. Das NIST-Doku-
ment mit seinen konkreten Lösungsansätzen
findet sich auch im Literaturverzeichnis des
deutschen BSI-Standards 100-4 „Notfallma-
nagement“ [19].
Da sich auf dem lokalen Speicher der Geräte
keine interessanten Daten mit dem lokalen
Betriebssystem mischen, ist Letzteres leicht
auswechselbar und das Recovery einfach durch-zuführen. Manche Thin Clients verzichten dafür
sogar auf Massenspeicher und beziehen ihr
Bootsystem aus dem Netzwerk [20].
Systeme werden dicker
Heute erwarten Anwender von Thin Clients
allerdings zeitgemäße Features wie verschie-
dene Remote-Desktop-Protokolle, Hardware-
beschleunigte Videowiedergabe, IP-Telefonie
und die Unterstützung von Peripherie wie
Barcode-Scannern, Smartcard-Lesern oder
Diktiergeräten. Das realisieren Linux-basierte
Systeme in Betriebssystem-Images von etwas
weniger als 1 GByte – gespeichert auf einer
Thin-Client-lokalen SSD, die je nach Anbieter
und Modell 4 bis 16 GByte fasst.
Selbst diese Größe lässt sich bei Bedarf in ei-
nem modernen LAN transportieren. Per PXE-
Boot oder mit dem Update-Mechanismus der
passenden Managementsoftware (Abbildung 5)
sind selbst Tausende Geräte in vertretbarer Zeit
mit einem sauberen Image beschickt. Das geht
besonders schnell, wenn aktualisierte Geräte
ihrerseits ihre Nachbarn mit der neuesten Ver-
sion versorgen können (Buddy Update).Weiter vereinfachen lässt sich die Recovery-
Aufgabe, indem der Administrator die Arbeits-
plätze vereinheitlicht. Bei dieser Standardisie-
rung handelt es sich ebenfalls um eine Empfeh-
lung des NIST.
Tatsächlich müssen sich die Computer dabei
nicht aufs Haar gleichen. Thin-Client-Anbieter
bauen ihr Betriebssystem in der Regel so, dass
es auf allen hauseigenen Geräten sowie eini-
gen der Konkurrenz gleichermaßen lauffähig
ist. Ergänzend zu diesem Operating System
von der Stange rollt der Sysadmin dann die
maßgeschneiderten Konfigurationen per Ma-
nagementtool aus.
Datensparsamkeit und ein automatisierter Aus-
tausch des Betriebssystems machen den Thin
Client nach einem Sicherheitsvorfall schnell
wieder flott. Im Betrieb beschränkt er mit
Linux, zeitgerechten Security-Fixes und einem
Read-only-Dateisystem zugleich die Angriffs-
möglichkeiten für Cracker. (Mathias Huber)Mathias Huber ist Produktmanager beim Thin-
Client-Spezialisten IGEL.Schnelle Erholung dank Thin ClientsAbbildung 5: Ein Managementsystem wie IGELs Universal Management Suite und so genannte Buddy Updates
schaffen schnell ein frisches Linux auf Thin Clients.29http://www.linux-magazin.deTitelthemaMaßnahmen