Linux läuft theoretisch seit 1999 auf IBMs Großrechnern – und wie sieht die Praxis aus? Unser Beispiel zeigt, was alles schief gehen kann und wie dabei eine Firewall auf den Dino kam.

Für IBM ist Linux auf dem oft als Dinosaurier verspotteten Mainframe zum unerwarteten Erfolg geworden und trägt derzeit, zusammen mit dem Trend zur Konsolidierung, zur Renaissance der S/390 bei, die jetzt im neuen Gewand als zSeries auftritt. Mainframes sind unter anderem im Finanzsektor stark verbreitet. Dort steht Sicherheit an erster Stellen, deshalb hier ein Erfahrungsbericht über eine Firewall-Portierung.

Nach den ersten erfolgreichen Gehversuchen im Jahr 1999 steht für Linux auf Großrechnern seit 2000 eine installierbare Distribution zur Verfügung. Inzwischen sind die schlimmsten Kinderkrankheiten überstanden – ein guter Zeitpunkt, um alle möglichen Anwendungen zu portieren.

Eine dieser Anwendungen ist eine Personal Firewall. Niemand wird auf die Idee kommen, den kompletten Mainframe als eine einzige Firewall zu verwenden, aber innerhalb des Großrechners erweisen sich Filter zum jeweiligen Netz als sehr nützlich. Ein Mainframe ist heute schließlich kein allein stehender Computer mehr, sondern die Basis für viele virtuelle Maschinen, die gleichzeitig laufen und einen ganzen Park an Servern ersetzen. In der Server-Farm sind Firewalls Stand der Technik, warum also nicht auch im Großrechner?

Die Welt der Mainframes dreht sich nicht nur um besondere Architekturen, sie hat auch ihre eigenen Begriffe und Abkürzungen. Der Kasten “S/390 und zSeries” erklärt einige davon, während der Kasten “Virtuelle Maschinen” näher auf das Konzept einer VM eingeht.

Konfiguration

Wie sieht die Konfiguration eines VM-Users als Linux-System konkret aus? Die Firewall-Portierungs-Maschine der Autoren dieses Artikels dient hier als Beispiel. Im CMS (Conversational Monitor System) gibt es eine Minidisk mit einem CMS-Dateisystem, auf der sich eine Skriptdatei befindet, die beim CMS-Start automatisch ausgeführt wird. Dort können beispielsweise über CP-Befehle virtuelle Netzwerkverbindungen definiert und aktiviert und auch das IPL (Initial Program Load) eines anderen Betriebssystem angestoßen werden.

Die Geräte einer VM werden über einen Device Identifier (0000 bis FFFF) angesprochen. Für einen VM-User spielt die Zuordnung der physischen Anschlüsse zu den Geräten keine Rolle, man hat also freie Hand bei der Auswahl. Es haben sich aber bestimmte Adressen eingebürgert. So hat die erste Minidisk für das CM-System in der Regel die Adresse 191 (Listing 1, Markierung 11); die Adressen für virtuelle Konsole (5), virtuellen Lochkartenleser (6) und -stanzer (7) und einen virtuellen Drucker (8) entsprechen in Listing 1 dem Standard.

Als Erstes sind der Username, das Passwort, eine initiale und eine maximale Hauptspeichergröße und die Sicherheitsklasse hinter dem »USER«-Statement definiert (1). Die zweite Zeile bewirkt, dass das System bei einem Neustart des VM mit hochgefahren wird (2). Als Nächstes wird der Prozessoranteil zugeordnet (3): Unser System erhält so viel CPU-Leistung wie möglich, jedoch mindestens drei Prozent der Gesamtleistung.

Die nächste Zeile bewirkt den Autostart des CM-Betriebssystems (4). Die vier »Link«-Statements (9) erlauben den Read-only-Zugriff (RR) auf benötigte Systembereiche von VM und VM-TCP/IP. So befindet sich auf der Minidisk 592 des Users »TCPMAINT« beispielsweise der FTP-Client des VM – ohne diese Zeile wäre unser User vom Rest der Welt abgeschnitten.

Die nächsten beiden Einträge (10) reichen zwei reale Adressen (1012 und 1013) der VM-LPAR direkt an unsere virtuelle Maschine weiter, jedoch unter den neuen virtuellen Adressen 112 und 113. Dahinter verbergen sich zwei Verbindungen zu dem OSA-Adapter, die eine virtuelle Netzwerkkarte ermöglichen (Read- und Write-Kanal).

Die »MDISK«-Statements (11) definieren jeweils Minidisks mit den virtuellen Adressen gemäß der zweiten Spalte. In der dritten Spalte steht der Gerätetyp, danach der Startzylinder, die Zylinderanzahl und der Name des zugrunde liegenden DASD-Device. Die weiteren Parameter betreffen Zugriffsrechte anderer VM-Guests sowie Zugriffspasswörter.