Watch the Watchmen!

Ordnungsmerkmale

erschienen in: <kes> 2006^#2, Seite 11

Rubrik: Bedrohung

Schlagwort: Admin-Accounts

Zusammenfassung: Hochprivilegierte Accounts von Systemadministratoren sind im Missbrauchsfall – durch interne wie externe Täter – eine große Gefahr. Grund genug, sie genauer zu überwachen, empfehlen unsere Autoren.

Autor: Von Márton Illés und Robert Fekete, Budapest

Gegen externe Angriffe sind heutzutage üblicherweise etliche Sicherheitsmechanismen im Einsatz – weniger umfassend sieht es beim Schutz gegen Innentäter aus, wenngleich sich auch hier schon deutliche Verbesserungen abzeichnen. Eine besonders gefährliche Bedrohung aus dem Inneren wird jedoch häufig übersehen: (die Accounts von) Systemadministratoren. Solche hochprivilegierten Benutzerkonten sind gleichermaßen mächtig wie schwer zu kontrollieren und stellen somit eine der gefährlichsten Angriffsquellen überhaupt dar. Dabei muss nicht einmal der rechtmäßige Administrator selbst böswillig agieren: Denkt man an Remote-Administration in Außenstellen oder ein Outsourcing der Systembetreuung, so können durchaus auch andernorts eingedrungene Externe hier wie Innentäter auftreten.

Handelt es sich beim Angreifer tatsächlich um den Administrator selbst, so verschlimmert das die Lage weiter, da dieser neben umfassenden Privilegien bis hin zur "virtuellen Allmacht" auf den betreuten Systemen auch ein umfassendes Wissen über die IT-Umgebung, Sicherheitsmaßnahmen und Protokollierung mitbringt. Hierdurch dürfte es einem böswilligen Admin in vielen Umgebungen möglich sein, die Spuren unerlaubten Handelns erfolgreich zu verwischen.

Abgesehen vom hohen Risiko solcher Accounts, das trotz vergleichsweise geringer Wahrscheinlichkeit böswilligen Handelns eine besondere Überwachung rechtfertigen kann, gibt es weitere gute Gründe hier "genauer hinzusehen", die durchaus auch im beiderseitigen Interesse liegen:

Effizienz-Prüfung: Sowohl bei eigenen Mitarbeitern (Achtung: Mitbestimmungspflicht beachten), vor allem aber auch bei Outsourcing-Dienstleistern ist eine Kontrolle des Handelns wünschenswert, um Optimierungspotenzial zu erschließen oder sogar Mängel aufzudecken. Umgekehrt kann es auch für den internen wie externen Admin interessant sein, wenn Belege für seine korrekte Arbeit vorliegen (Stichwort: Haftung).
Detaillierte Protokollierung: Bei manchen Geschäftsprozessen ist es wünschenswert oder sogar durch Regularien (SOX, HIPAA, PCI, Datenschutzgesetze usw.) vorgeschrieben, bestimmte Ereignisse oder Modifikationen am System festzuhalten. Hier sind nicht zuletzt Eingriffe mit System-Privilegien zu berücksichtigen, die entweder unmittelbar bedeutend sind oder möglicherweise eine "normale" Protokollierung aushebeln könnten.

Generell sollten für Administrator-Accounts strengste Anforderungen an grundlegende Sicherheitsmechanismen gelten: Authentifizierung mit starken Verfahren (Krypto-Token, Smartcards, Biometrie usw.), minimale Rechtevergabe, Protokollierung von Zugriffen auf verwaltete Systeme und so weiter. Auch ein separates Netz für den administrativen Zugriff verbessert die Sicherheit und Überwachbarkeit erheblich. Wo das nicht physisch möglich ist, sollte zumindest eine logische Trennung durch Firewalls oder Virtual LANs (VLANs) erfolgen.

Man sollte auch nicht vergessen, dass eine reine Protokollierung unbefugte oder unerwünschte Aktionen nicht verhindern, sondern lediglich erfassen kann. Wünschenswert wäre hier eine weiter reichende Lösung, die administrative Zugriffsversuche möglichst umfassend, auch inhaltlich überwachen und gegebenenfalls spezifisch unterbinden kann, rechtmäßiges Arbeiten aber kaum oder gar nicht erschwert. Ein Ansatz auf dem Zielrechner erscheint aufgrund der dortigen Privilegien der Admins kaum als sinnvoll. "Davor" erweist sich jedoch als zusätzliche Schwierigkeit, dass Tools zur Fernwartung (sinnvollerweise!) verschlüsselt agieren und die Inhalte der Admin-Session damit einer näheren Betrachtung nicht ohne weiteres zur Verfügung stehen.

Um die Aktionen von Administrator-Accounts revisionssicher zu prüfen ist für Fernwartungs-Protokolle ein spezielles Proxy oder ein Bastion-Host erforderlich.

Hier wird also ein Proxy-System auf dem Weg zum fernadministrierten Server notwendig, das zum Audit und idealerweise auch zur zusätzlichen Autorisierung den Admin-Datenstrom entschlüsselt, analysiert, eventuell filtert und dann die Verbindung zum Zielsystem erneut chiffriert. Dies gilt im Besonderen für SSH, das bevorzugte Admin-Tool zum administrativen Remote-Access, zumindest für Unix-/Linux-Systeme, das hier im Folgenden stellvertretend betrachtet werden soll. Prinzipiell wären alle Gedanken auch auf andere Protokolle für Admin-Sessions anwendbar – allem voran für SSL-geschützte Verbindungen. Während SSL-Proxies für Sicherheitssysteme in den letzten Jahren eine zunehmende Verbreitung gefunden haben, sind "Fertiglösungen" für SSH jedoch noch äußerst rar.

Proxy oder Bastion für SSH

Sofern kein nutzbares SSH-Proxy – beispielsweise in einer Firewall – vorliegt, kann man einen dedizierten Host als "SSH-Bastion" einrichten, der dann als einzige zulässige SSH-Quelle für die nachgeschalteten Server freizugeben ist. Server-Admins müssen sich dann zunächst auf diesem speziellen System anmelden, das die Audit- und Autorisierungsfunktionen übernimmt, bevor sie von dort aus SSH-Verbindungen zu den Zielsystemen öffnen können. Es wäre auch denkbar, automatisch SSH-Tunnel vom Zielsystem zum Bastions-Host aufzubauen und dort die Verbindung über Forwarding-Einträge vom Eingangs-Tunnel durch die Filter-/Analyse-/Audit-Komponente zum abgehenden Tunnel durchzuleiten (vgl. <kes> 2005^#4, S. 42, wo eine solche Methode zur Trennung von Fernwartungsverbindungen in der DMZ beschrieben wurde).

Wesentlich ist – wie bei allen Bastionen – eine strenge Beschränkung auf das absolut Notwendige, um ein Minimum an Angriffsfläche zu bieten. Besonderes Augenmerk ist zudem auf eine strukturierte und selektive Protokollierung zu richten, vor allem wenn eine größere Zahl von Zielsystemen betreut wird. Die entstehenden Audit-Daten sollten leicht benutzbar sein, weswegen sich eine gesonderte Aufbereitung statt der simplen Ablage eines Session-Mitschnitts empfiehlt, in der man wichtige Modifikationen erst aus einer Vielzahl von Standardaktionen heraussuchen müsste. Auch eine Überwachung in Echtzeit sollte möglich sein, um laufende Prozesse zu begutachten.

Eine (automatisierte) digitale Signatur zur Integritätssicherung der protokollierten Daten ist unbedingt anzuraten. Darüber hinaus empfiehlt sich aber auch eine verschlüsselte Speicherung, da – je nach Aufgabe der Zielsysteme und Umfang der Protokollierung – auch die aufgezeichneten Informationen sicherheitsrelevant oder schutzbedürftig sein können: Denkbar sind hier sowohl Passwörter als auch personenbezogene Daten oder interne Informationen über Netzwerkstrukturen oder Sicherheitssysteme.

Als heikel erscheint die Frage, wer einen Bastion-Host administriert, sofern damit nicht nur externe Admins überwacht werden: Die Überwachten selbst scheiden naturgemäß für eine Rolle aus, die administrative Rechte auf der SSH-Bastion erfordert.

Vier-Augen-Prinzip

Die Einrichtung eines SSH-Proxies liefert über die genannten Audit-Funktionen hinaus auch die Perspektive zusätzlicher Autorisierungsmechanismen ohne Modifikation im Zielsystem: Damit ist etwa die Umsetzung eines Vier-Augen-Prinzips zur Server-Administration vorstellbar (und bspw. im SSH-Proxy der Zorp-Firewall von BalaBit auch implementiert). Im einfachsten Fall könnte ein Proxy oder Bastion-Host die Verbindung zum Zielsystem nur erlauben, sofern zeitgleich zwei Administratoren arbeiten. Alternativ könnte man fordern, dass ein zweiter Admin beziehungsweise Auditor zur Echtzeit-Überwachung der Logfiles angemeldet ist.

Über welche Verfahren und mit welchen Zusatznutzen auch immer: Der Protokollierung und Prüfung des Handelns privilegierter Accounts sollte man im Rahmen einer vielschichtigen Verteidigungsstrategie besondere Aufmerksamkeit widmen.

Márton Illés und Robert Fekete sind Security Consultants bei BalaBit IT Security Ltd. ( [externer Link] www.balabit.com).