© Mathias The Dread, photocase.com

Secure-Shell-Verbindungen sind beim Administrieren und Fernsteuern von Servern und Routern unverzichtbar. Die Kollegen der Compliance-Fraktion haben allerdings das Nachsehen, denn der Inhalt der SSH-Datenröhren entzieht sich ihrer Kontrolle. Genau hier setzt die getestete Balabit SCB an.

Die Secure Shell schützt vor Manipulation und Abhören der übertragenen Kommandos und Programmausgaben. Doch nicht jedem ist der Schutz genehm: Angreifer stört er sowieso, es gibt aber auch legitime Gründe, wenigstens zu protokollieren, was Admins und Benutzer in ihren SSH-Sitzungen treiben. Sinnvoll ist das etwa zur Kontrolle von Outsourcing-Partnern, zur Dokumentation und zum Change Management sowie bei Audits und Zertifizierungen, etwa nach SOX, HIPAA oder ISO 9001.

Der US-amerikanische Sarbanes Oxley Act (SOX) aus dem Jahre 2002 soll die Vertrauenswürdigkeit der Finanzangaben börsennotierter Firmen verbessern. SOX fordert Kontrollen, die eine Manipulation der Ergebnisse erschweren, und erstreckt sich damit auch auf die IT. Der Health Insurance Portability and Accountability Act (HIPAA) ist ähnlich, gilt aber für den Medizinsektor. In Europa orientieren sich Unternehmen eher an den ISO-Normen 9001/14001 (Qualitätsmanagement) und ISO 17799 (IT Security Management), aus denen sich ähnliche Forderungen ableiten. Im Gegensatz zu SOX und HIPAA ist ihre Umsetzung aber nicht gesetzlich verankert.

Spitzel-Pflicht

Inwieweit SOX&Co. verlangen den SSH-Verkehr minutiös aufzuzeichnen, ist schwer zu beurteilen. Klar, dass Balabit mit diesem Thema wirbt. Es ist dennoch im Einzelfall abzuwägen, ob sich zum Beispiel die Bilanzen in SAP über eine SSH-Verbindung zum Serversystem schönen lassen und eine Kontrolle à la SCB erfordern oder ob andere Maßnahmen sinn- und wirkungsvoller sind.

Das Schwierige am Aufzeichnen des SSH-Inhalts ist, die legitimen Lauscher von dem gemeinen Man in the Middle zu unterscheiden und diesen weiterhin wirksam auszusperren. Beide klinken sich ja in den Datenstrom zwischen SSH-Client und -Server ein und versuchen etwas, das die SSH mit großem Aufwand verhindern möchte. Gegenüber dem Client treten sie als Server auf und dem Server gaukeln sie einen Client vor. Von einem Angreifer unterscheidet die SCB nur ihr Hostkey, dem die Clients vertrauen müssen. Wer SSH bereits nutzt, bevor er die SCB einführt, muss die neuen Hostkeys publizieren oder die vorhandenen privaten Keys in die SCB importieren.

Die SCB sieht den Klartext jeder Session und speichert ihn auf der eigenen Festplatte ab. Als Highlight ist es möglich, die ganze Session zu einem beliebigen späteren Zeitpunkt in einem (leider proprietären) Format zu exportieren und mit einem Player des Herstellers abzuspielen. Den Player gibt es für Linux und Windows. Er zeigt in Originalgeschwindigkeit, was genau der Benutzer getippt und welche Ausgaben er gesehen hat. Das Verfahren gleicht einem Screengrabber. Einzelne Filme (Sessions) lassen sich bei der Analyse auch nach benutzerdefinierten Strings durchsuchen, um schnell zu einer möglicherweise kritischen Stelle zu gelangen.

Bridge, Router oder Bastion

Bei der Infrastruktur hat Balabit ganze Arbeit geleistet: Für jedes Umfeld gibt es eine passende Technik, um die SCB-Appliance mit möglichst geringem Aufwand in die bestehende IT-Infrastruktur zu integrieren. Die Shell Control Box kann sich als Bridge, Router (Abbildung 1a), oder als Bastion Host (Abbildung 1b) ins Unternehmensnetzwerk einfügen. Zusätzlich gibt es im Konfigurationsmenü »Connections« noch die Option, virtuelle IP-Adressen einzusetzen (zusammen mit NAT, Network Address Translation). In jedem Fall terminiert die SCB die SSH-Verbindung und öffnet eine zweite zum Server, um an den Klartext zu kommen.

Abbildung 1a: Im Router-Modus terminiert die SCB eine über sie verlaufende SSH-Verbindung und startet eine zweite Verbindung zum realen Server. Die Daten protokolliert sie und leitet sie weiter. Da die SCB dem Client vorgaukelt, selbst der Server zu sein, muss sie dessen Key kennen, um nicht wie ein Angreifer zu wirken.

Abbildung 1b: Im Bastion Mode verbindet sich der SSH-Client explizit mit der SCB. Diese authentifiziert sich in eigenem Namen und entscheidet je nach gewählter Portnummer, zu welchem SSH-Server der Client tatsächlich will.

Die vier Bausteine erweisen sich in der Praxis als deutlich flexibler, als es das Manual vermuten lässt. Alle Topologien, die sich die Tester überlegten, waren damit umsetzbar. Besonders elegant ist die Kombination von Router-Modus und NAT (Abbildung 1c), vorausgesetzt alle SSH-Server stehen in einem gemeinsamen Netzwerk. Als Abbild davon legt der Admin in der SCB ein virtuelles Netzwerk an. Eine Firewall vor den realen SSH-Servern leitet den Secure-Shell-Verkehr per Destination-NAT an dieses virtuelle Netz. Die Firewall modifiziert hierfür nur den Netzwerkteil der Ziel-IP und lässt den Host-Teil unverändert.

Abbildung 1c: Die Kombination aus Routing und NAT ist besonders praktisch: Die Firewall erkennt SSH-Verkehr und leitet ihn per Destination-NAT an die SCB, die sich ihrerseits an den realen Server wendet.

Damit greift die SCB alle Verbindungen auf und setzt als Ziel-IP wieder die ursprüngliche Netzwerkadresse ein. In dieser Konstellation darf die SCB an beliebiger Stelle im Netz stehen und ihr Admin muss nur noch eine Connection Policy einrichten, statt jeden Server einzeln einzutragen.

Wie ein Proxy

Im Bastion Mode (Abbildung 1b) arbeitet die SCB wie ein Proxy. Die Clients verbinden sich per SSH explizit zu ihr. Welchen Server der Client will, erfährt die SCB entweder anhand des TCP-Ports, den der Client angesprochen hat, oder anhand der virtuellen IP-Adresse des SCB-Interface.

Per Source-NAT ist es zudem in jedem Modus möglich, als Quelle die IP-Adresse des echten Clients einzutragen, sodass in den Logfiles der Zielserver die tatsächlichen Clientadressen landen.

Die SCB muss sich in jedem Fall gegenüber dem Client authentifizieren, egal wie sie in das Netz eingebunden ist. Im Unterschied zu einem Angreifer kennt ihr Administrator die neuen Hostkeys der realen Server und kann diese auf die SCB kopieren. Ohne Originalschlüssel würde der Client den Angriff bemerken. Welcher Schlüssel der richtige ist, hängt aber sehr wohl von der Integrationsvariante ab. Es gilt: Die SCB muss den Key verwenden, der zu der IP-Adresse passt, mit der sich der Client verbindet. Bei Bridge und Router ist das der Key des Zielservers.

Im Bastion-Modus verbindet sich der Client hingegen wissentlich mit der SCB. Diese braucht folglich eigene Schlüssel, denen der Client auch vertrauen muss. Für jeden TCP-Port, der stellvertretend für einen Server steht, erzeugt die SCB einen SSH-Schlüssel. Ein Client, der sich mit »ssh -p 1072 fritsch@10.10.10.100« verbinden will, erfährt einen anderen Hostschlüssel als »ssh -p 1158 fritsch@10.10.10.100«. Das ist auch sinnvoll, schließlich führen beide Kommandos zu verschiedenen realen Server.

Portverwirrung

Dummerweise unterscheiden ältere SSH-Clients bei ihren Known-Hosts-Tabellen nicht nach TCP-Portnummern. Das Resultat ist eine deutliche Warnung, sobald sich der Benutzer vom gleichen Client aus auf verschiedene Ports verbindet. Beim ersten Port ist noch alles okay; beim zweiten merkt der Client nicht, dass der Benutzer einen anderen Dienst meint, er merkt aber sehr wohl, dass sich der Hostkey geändert hat.

Abhilfe schaffen ein Client-Update oder ein Workaround: In »~/.ssh/known_hosts« dürfen IP-Adressen mehrfach auftauchen. Der Client untersucht alle Einträge und ist zufrieden, wenn einer davon zum Server passt. Die zusätzlichen Keys muss der User manuell eintragen. Es ist auch möglich, auf der SCB-Appliance für alle Verbindungen denselben Hostkey zu konfigurieren. Der Hersteller verspricht sogar, diesen Trick als eigene Option ins GUI aufzunehmen.

Die Implementierung als Bridge führt ohne Not einen Single Point of Failure ins Netzwerk ein, da die verbauten Ethernet-Karten kein Fail-open kennen. Im Fehlerfall (zum Beispiel wenn die Stromversorgung ausfällt) trennt die Appliance die Verbindung (Fail-close). Je nach Umgebung kann es aber wichtig sein, die Connectivity zu erhalten und auf das Protokoll zu verzichten. Balabit will für Release 2 der SCB daher Fail-open-Karten einsetzen.

Installation

Die Balabit-SCB-Appliance basiert auf einer Sun-Plattform (siehe Kasten “Sun Fire”) mit vier Netzwerkkarten: externes und internes Interface, Out-of-Band-Management und High Availability. Letzteres ist aber nur in der höheren Ausbaustufe (Modell N2500) verfügbar, bei der getesteten N1025 liegt das vierte Interface brach.

Sun Fire

Die getestete Balabit-Appliance SCB N1025 basiert mit wenigen Modifikationen auf der Sun Fire X2100 M2 x64 (siehe Abbildung 2). Die Dualcore-CPU stammt von AMD (Opteron 1214 mit 2,2 GHz und 64 Bit). Die 2 GByte Speicher (DIMMs) lassen sich auf maximal 8 GByte erweitern. Zudem sind vier Ethernet-Karten on Board verbaut (Gigabit-fähig) und zwei 32-Bit-PCI-Express-Slots verfügbar. Am On-Board-Raidcontroller hängen zwei 80-GByte-SATA-Festplatten (7200 U/Minute). Abbildung 2: Die Hardware der Balabit SCB stammt von Sun. Verbaut sind gewöhnliche PC-Komponenten: CPU 1, RAM 2, NICs 3, PCI-E-Slots 4, Raid-Anschluss 5 und zwei Disks 6 eines Entrylevel-Servers. Laut Preisliste verwendet Balabit inzwischen 250-GByte-Festplatten. Leider verfügt die Plattform nur über eine einzige Stromversorgung. Ein zweites Power Supply lässt sich nicht nachrüsten. Der Blick in die Appliance beeindruckte die Tester leider nicht. Es handelt sich um einen Einsteiger-Server (Entrylevel), bestehend aus handelsüblichen PC-Bauteile in einem 19-Zoll-Rackgehäuse. Immerhin hat Sun daran gedacht, ein DVD-ROM-Laufwerk einzubauen und die Wartungsanleitung auf den Deckel der Appliance zu kleben. Diese vermeintlich simplen Dinge vergessen andere Hersteller oft. (Norbert Landowski)

Die externe Netzwerkkarte ist so vorkonfiguriert, dass der Admin-Webserver via HTTPS auf die IP-Adresse 192.168.1.1 reagiert. Wer Sun kennt, schätzt vielleicht deren Lights-out-Management: Per serieller Schnittstelle erhält der Admin Zugriff auf ein laufendes Solaris-Betriebssystem. Bei der SCB ist das leider nicht möglich, weil laut Hersteller eine passende Linux-Schnittstelle fehlt.

Auch der direkte Zugriff per SSH auf die Kommandozeile der SCB ist per Default nicht möglich. Über eine versteckte Option (hinter der URL der Management-Oberfläche ein paar Parameter eintippen) ist dieser Zugang aber aktivierbar. Im Test hat das bestens funktioniert.

Nach der Basisinstallation muss der SCB-Admin Folgendes konfigurieren:

• SSH-Verbindungseinstellungen, etwa Quell- und Ziel-IP-Adressen
  und, je nach Modus, TCP-Portnummern.
• Verbindungs-Policies definieren exakt, was zu welchem Zeitpunkt
  wem von wo aus gestattet ist (Abbildung 3).
• Die Authentication Policy legt fest, welche Authentifizierung
  die SCB für eine Verbindung von den Clients akzeptiert
  (Abbildung 4).
• Einstellungen für das Archivieren des Audit Trails der
  Verbindung. Diese Audit-Datei kann die SCB verschlüsselt
  ablegen.

Abbildung 3: Die Connection Policy gibt für jede einzelne SSH-Verbindung vor, von welcher Quelle zu welchem Ziel sie läuft, ob sich die SCB via SNAT vor dem Zielhost verbergen soll, welche Keys sie verwendet und welche Authentication Policy (Abbildung 4) gilt.

Abbildung 4: In einer Authentication Policy bestimmt der Admin, welche Authentifizierungsmechanismen die SCB dem SSH-Client anbietet: None, Password, Keyboard-Interactive oder Public Key.

Im Admin-GUI der SCB haben Public und Private Key nichts miteinander zu tun. Um stimmige Bezeichnungen hat sich in der SCB-Version 1 aber niemand gekümmert, die Verwirrung ist groß. Mit Public Key meint die SCB den öffentlichen Benutzerschlüssel, den sie – analog zur »authorized_keys«-Datei normaler SSH-Server – für die User-Authentifizierung heranzieht. Er sollte besser Client Side Verification Key heißen.

Den Private Key benutzt die SCB, um sich gegenüber dem realen Server zu authentifizieren. Er könnte daher Server Side Authentication Key heißen. Die SCB-Appliance kann einen eigenen Private Key generieren, dessen öffentlichen Part der Admin anschließend auf den realen Server laden muss, oder er importiert einen bereits vorhandenen Key.

Als weiteren Schlüssel verwaltet die SCB die Hostkeys der realen Server (Abbildung 5). Im Bastion-Modus genügt der öffentliche Key, den privaten muss die Appliance nicht kennen. Der Admin wählt in der Connections Policy (Abbildung 3), ob die SCB den Hostkey bei der ersten Verbindung zum Server akzeptiert und speichert oder ob der Admin jeden Hostkey selbst lädt.

Abbildung 5: Die Hostkeys der realen Server speichert die SCB ganz so, wie es ein gewöhnlicher SSH-Client macht. Der Admin kann die Public Keys explizit importieren oder hier wenigstens die Fingerprints prüfen.

Channel Policy

Die Channel Policy gibt vor, was Client und Server über ihre SSH-Verbindung transportieren dürfen. Der Admin darf bestimmen, ob ein Anwender lediglich Shellzugriff erhält, ob er X11-Forwarding verwenden oder ob er auch SCP- und SFTP-Sessions starten darf.

In der Channel Policy verbirgt sich als Schmankerl auch die Vier-Augen-Autorisierung. Nur wenn sich zwei Admins gleichzeitig auf einem Rechner einloggen, lässt die SCB sie gewähren. Einer allein erhält keinen Zutritt. Nach dem Login sorgt die SCB aber für keine weitere gegenseitige Prüfung mehr. Weder sehen die Benutzer gegenseitig ihre Ein- und Ausgaben, noch müssen sie gegenseitig ihre Kommandos absegnen.

Die Firma Balabit legt die SCB darauf aus, Audit Trails zu erhalten und die Compliance zu SOX&Co. zu erreichen. Das Produkt könnte aber viel mehr leisten: Statt nur die Ein- und Ausgaben aufzuzeichnen und später abzuspielen, wäre es denkbar, den SSH-Traffic weiter zu analysieren und beispielsweise einen Virenscanner in SCP- und SFTP-Transfers einzuklinken.

Derzeit landet der Inhalt von SCP- und SFTP-Transfers auf Wunsch immerhin auf der SCB-Festplatte (»Audit«-Einstellung der Channel Policy) und lässt sich mit dem Zorp Audit Dumper (ZAD) auch wieder rekonstruieren. Der gehört aber nicht zum Standard-Lieferumfang der Appliance. Balabit will mit einer offiziellen Release des ZAD warten und plant nach eigenen Angaben, diese Funktion in den Audit-Player zu integrieren.

Auch beim Schlüsselmanagement verschenkt Balabit Punkte. Wer nur wenige User hat und wenige Server betreibt, wird sich mit der manuellen Konfiguration abfinden. Für größere Umgebungen wäre eine PKI-Anbindung aber sehr wünschenswert. Mit X.509-Zertifikaten, Smartcards und CRLs (Certificate Revocation Lists) könnte die SCB zum Beispiel mit SSH Tectia [2] mithalten. Balabit plant Zertifikat-basierte Authentifizierung jedoch erst für Anfang 2008. Schade, eigentlich ist Identity Management schon lange eine bekannte und wichtige Aufgabe.

Bei manchen Sicherheitsverstößen ist sogar das OpenSSH-Kommandozeilen-Interface benutzerfreundlicher. Wenn sich zum Beispiel der Schlüssel eines Servers geändert hat, bemerkt der Client nur, dass sich die Verbindung nicht mehr aufbaut. Die SCB gibt keinerlei Information an den Client – ob der Server komplett hängt oder ob ein Sicherheitsproblem vorliegt, ist nicht zu unterscheiden. Nur das Logfile der SCB weist auf die Ursache hin. Viel besser wäre es, die SCB würde den Client direkt informieren.

Fehlende Funktionen

Schade ist auch, dass sich das selbst generierte Zertifikat des Admin-Webservers nicht ändern lässt. Das Zertifikat einer hauseigenen oder externen PKI würde vielen Admins helfen den Zugang zur SCB sicher zu halten. Auch störte im Test, dass es immer mit großen Hürden verbunden war, die Systemzeit manuell oder per NTP zu korrigieren. Bei NTP stießen die Tester sogar auf einen Bug, den Balabit aber recht schnell behob. Gerade bei einer Appliance, die mit SOX und HIPAA wirbt, ist die korrekte Uhrzeit aber entscheidend. Schließlich muss man im Ernstfall wissen, wann genau eine Manipulation stattfand.

Sehr positiv ist dagegen der Audit-Player zu bewerten (Abbildung 6). Wie in einem Flashfilm sieht der Admin, was der Benutzer durch die SSH-Verbindung geschickt und empfangen hat. Auf dem Schirm erscheint genau die Ausgabe, die der User auch gesehen hat.

Abbildung 6: Der Audit-Player spielt die aufgezeichneten Audit Trails wie einen Film ab und rekonstruiert den Bildschirminhalt des Clients. Die Geschwindigkeit ist frei wählbar, die Schriftgröße eigenartigerweise nicht.

Neuland

Das junge Produkt SCB wagt sich in Neuland vor und gibt Admins die Möglichkeit, hervorragende Audit Trails von SSH-Verbindungen anzufertigen. Trotz der berechneten Enterprise-Preise sind aus Enterprise-Blickwinkel noch einige Schwächen erkennbar, die der Hersteller mit Updates aber korrigieren kann. Wer mit SSH-Schlüsseln arbeitet und keine automatische Kontrolle des Inhalts von SCP, SFTP und Portforwarding braucht, ist mit der SCB sehr gut gerüstet. Im Testlabor stellte sich heraus, dass die SCB zudem das Change Management sehr erleichtert. Die Audit Trails zeigen detailliert, wer wann was wie geändert hat. Das ist nicht nur für die von Balabit beworbenen Sicherheitsaufgaben und Zertifizierungen hilfreich. (fjl)