Die Shell Control Box schaltet sich in SSH-Verbindungen ein und zeichnet den Datenstrom auf

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.