"Ich habe gemeint, das sei so sicher"
Marc Ruef | 22.08.2005

Security Consultant, wie ich meinen Job verstehe, mutet schon fast ein bisschen erhaben an. Wenigstens im IT-Umfeld. Als Consultant ist man weniger Exekutive, sondern man lässt für sich arbeiten, gibt Ratschläge und Anweisungen. Finden wir eine Schwachstelle in einem System, ist der Systemverantwortliche angewiesen, sich dieser Sache anzunehmen. Dass wir etwas selber an den Konfigurationen eines Rechners anpassen, ist aus vielen Gründen ungeschickt.

Einer davon liegt in einer schwindenden Wirtschaftlichkeit bei Problemen. Wenn eine kleine Security-Firma plötzlich Support machen muss, sind die Mitarbeiter unweigerlich in Feldern absorbiert, in denen sie mit ihrem spezialisierten Fachwissen nur wenig Nutzen bringen. Nach einem Hardening an einer Firewall ist es nämlich nicht selten, dass es plötzlich heisst: "Unser Mailserver läuft nicht mehr, das hat sicher mit der Anpassung durch Sie zu tun!" Da rennt man dann schnell Problemen nach, die man gar nicht verursacht hat - Dies frühzeitig zu beweisen ist in solchen Fällen oftmals zeitintensiver, weder sich halt mal eben "kurz" um das eigentliche Problem zu kümmern. Wichtiger Tipp an alle Consultants: Ja nichts anfassen!

Es gibt aber dennoch Situationen, in denen ich mich als Sicherheitsberater gezwungen sehe, an einem Host unverzüglich Hand anzulegen. Und zwar dann, wenn dringende Sofortmassnahmen gefragt sind und niemand gegenwärtig ist, der diese Umsetzen kann. Dieser unliebsame Fall tritt normalerweise nur in zeitkritischen Projekten ein. Zum Beispiel dann, wenn wir als forensische Analysten eines elektronischen Einbruchs hinzugezogen werden. Oftmals will der Kunde den Betrieb schnellstmöglich wieder herstellen, ohne sich dabei erneut zu exponieren. Innert Stunden (am liebsten Minuten!) soll sodann ein neues System auf die Beine gestellt werden, das den alten Dienst wieder reibungslos und sicherer verrichten kann. Hardening, Patching und weitere Sicherheitsmassnahmen müssen innert kürzester Zeit - oftmals ohne Konzeptgrundlagen - umgesetzt werden.

In einer der letzten Woche sah ich schon eine solche Situation auf mich zukommen. Kurzfristig sollte ich eine forensische Analyse, der Einbruch betraf einen Online-Shop, leiten. Der Kunde war wirtschaftlich von dieser Distributions-Quelle abhängig und entsprechend nicht erfreut als ich ihm sagte, dass ich das System zwecks Analyse mehrere Tage vom Netz nehmen müsse. Sofort wurden Pläne geschmiedet, wie ein Ersatzsystem den Dienst verrichten kann, während im Hintergrund meine Analyse des Original-Servers läuft.

Als man sich geeinigt hatte, dass das neue Ersatzsystem zusätzlich abgesichert und als equivalenter Ersatz betrieben werden sollte, machten sich die Administratoren an die Arbeit. Sie führten abschliessend einige Hardening-Eingriffe durch, die das System sicherer machen sollten. Meine Aufgabe bestand zudem in einer weiteren Phase im Aufdecken der letzten Schwachstellen des Systems, um dieses so dicht wie möglich zu machen. (Ich "liebe" Tage, an denen ich sowohl eine forensische Analyse als auch ein Vulnerability Assessment zeitgleich umsetzen muss - Ich arbeite nämlich ausschliesslich single-tasking!)

Die ersten Test-Resultate fielen zu meinem Erstaunen nicht wirklich gut aus. Eine Vielzahl an Schwachstellen wurde nicht wie abgemacht durch die Administratoren vorgängig aus dem Weg geräumt. Und viele Schutzmassnahmen entpuppten sich trotz exakter Anweisungen als fehlerhaft umgesetzt oder gar nicht in Betracht gezogen. Wieso bloss?

Die Administratoren setzten eine Reihe von Schutzmassnahmen um, die sie zum Grossteil nicht verstanden. Dieses mangelnde Grundverständnis führte dazu, dass sie falsch umgesetzt wurden und ihre Richtigkeit noch nicht einmal selbst überprüft werden konnte. Die zuständigen Personen waren aus ihrer Sicht absolut der Meinung, dass sie ein sicheres System errichtet hätten. Eine trügerische Selbstzufriedenheit.

Dabei wäre das Überprüfen der getätigten Arbeiten, wenigstens in einer rudimentären Form, sehr einfach gewesen. Durch die öffentlich zugänglichen Vulnerability Scanner, bestes Beispiel die populäre open-source Lösung Nessus (http://www.nessus.org), hätten die bekanntesten Fehlkonfigurationen und Softwarefehler entdeckt werden können. Falsch eingestellte Parameter oder eben halt doch vergessene Patches wären in einer schönen Liste dargestellt gewesen und hätten nur nocheinmal durchlaufen werden müssen. Die fehlende Sensibilisierung der Administratoren hat sie primär daran gehindert, saubere Arbeit zu leisten. Gar niemand wäre auf die Idee gekommen, dass man seine Arbeit so auf einfache Weise hätte überprüfen können.

Hardening besteht nicht nur in der Erstellung eines Konzepts und dem Adaptieren dieses. Viel mehr muss es auch überprüfbar sein. Im Nachhinein kann jeder behaupten, er hätte die Guidelines durchlaufen und sich an die Richtlinien gehalten. Hat dies niemand überprüft und offiziell abgenommen, ist dies lediglich eine nicht nachvollziehbare Aussage. Und im Fall eines Zwischenfalles ist nichts wertloser, weder eben eine solche.

Dies soll zeitgleich eine subtile Kritik all jener sein, die "Angriffs-Tools" (http://www.computec.ch/download.php?list.19) - wie Nessus nunmal auch eingesetzt werden kann - verbieten wollen. Ungeschulte Administratoren hätten in diesem Fall grad gar keine Chance mehr, innert kurzer Zeit die existente Sicherheit einer Installation zu determinieren. Computersicherheit würde in diesen und manch anderen Fällen noch viel unwirtschaftlicher zum umsetzen werden. Und die Angreifer würden ja trotzdem eigene Tools unter der Hand weitergeben, mit denen sich Angriffe automatisieren lassen. Der Verbot von Werkzeugen - und Software ist lediglich eine elektronische Form eines solchen - birgt längerfristig nur Nachteile in sich. Gleiches gilt für das Verbot von Informationen ansich, die ebenso als (intellektuelles) Werkzeug betrachtet werden können und müssen.