vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisnächstes Kapitel


20

VAX/VMS

In diesem Kapitel wollen wir ein wenig in Erinnerungen schwelgen. Auch für die Jüngeren unter Ihnen ist ein kleiner Ausflug in die Geschichte sicher interessant. Ich beginne mit dem Aufstieg der Digital Equipment Corporation (DEC), des Unternehmens, das die einst so populären VAX (Virtual Address Extension) hergestellt hat.

Auf die eine oder andere Weise war DEC immer an kritischen Momenten der Computergeschichte beteiligt. (Vielleicht erinnern Sie sich daran, daß Ken Thompson Unix zuerst auf einer DEC PDP-10 gehackt hat.)

Wegweiser:

Um eine Vorstellung davon zu bekommen, wie lange DEC bereits Computerprodukte für die Industrie liefert, sollten Sie sich etwas Zeit nehmen und folgende Webseite besuchen: http://www.cs.orst.edu/~crowl/history/.

Der obige Link führt Sie zu Lawrence Cowls wunderbarer Site über die Geschichte des Computers. Dort sind die Meilensteine unserer Computerkultur dargestellt (beginnend mit dem allerersten Computer von Charles Babbage, ca. 1823). Auch die erste DEC PDP-1 ist auf dieser Site zu finden. Kurze Zeit darauf produzierte DEC bereits eine breite Palette von Produkten, z.B. den ersten Minicomputer - die DEC PDP-8.

1978 produzierte DEC die erste VAX, die Digital VAX 11/780. Diese Maschine bot eine 32- Bit-Architektur und 1 MIPS Leistung. Gemessen an dem damaligen Standard war die 11/ 780 leistungsfähig und schnell. (Und abwärtskompatibel zu der PDP-Reihe, die ihr vorausging.) Der Preis? Läppische 200.000 Dollar.

Hinweis:

MIPS steht für million instructions per second (Millionen Anweisungen pro Sekunde).

Seltsamerweise wurde die 11/780 so populär, daß sie sich als Benchmark-Maschine für den MIPS-Index etablierte. Sie wurde somit zum Maßstab für die Messung aller späteren Workstations. (Und das, obwohl die IBM 370/158 in Sachen Geschwindigkeit und Rechenleistung durchaus vergleichbare Werte erzielte. Dennoch erreichte die IBM 370/158 nie die Beliebtheit der 11/780.)

Noch einmal: Die 11/780 war eine Maschine für 200.000 Dollar, die annähernd 1 Million Anweisungen pro Sekunde bearbeiten konnte. Fantastisch. Wenn Sie diese Maschine heute im Internet zum Verkauf anbieten würden, müßten Sie dem Käufer noch etwas dazugeben, damit er sie abtransportiert. Nach heutigen Standards ist sie entweder Schrott oder, etwas milder ausgedrückt, ein Sammlerstück. Eine Sache machte die 11/780 jedoch zu einer ganz besonderen Innovation und unterscheidet sie noch immer von den anderen Rechnern in der Geschichte des Computers: Die 11/780 konnte zwei Betriebssysteme unterstützen. Das eine war das damals schon recht bekannte Unix, und das andere war VMS. Wir werden uns VMS gleich zuwenden, zuvor möchte ich Ihnen aber noch eine Vorstellung davon vermitteln, worum es bei der VAX ging.

VAX war ein Mehrbenutzersystem. Viele Leser sind vielleicht zu jung, um sich an die VAX- Stationen erinnern zu können. Die MicroVAX ist ca. 90 cm hoch, und ihre Karten sind größer als die meisten modernen Motherboards von PCs.

Als Terminal wurde ein VT220 verwendet, mit einem sichtbaren Bereich von ca. 8 1/2 Zoll. Auf der Rückseite des Terminals befinden sich verschiedene Anschlüsse. Darunter sind ein Datenleitungsanschluß, ein Druckeranschluß und ein serieller Port. Der serielle Port kann auf erstaunliche 19.200 Baud eingestellt werden, und die verfügbaren Terminal-Emulationen beinhalteten VT220 und VT100. Wenn Sie ein Modem an das Terminal anschließen, müssen Sie die Modembefehle auf einem leeren Bildschirm mit einem blinkenden Cursor eingeben. (Ein Wählvorgang würde z.B. durch Eingabe von ATDT5551212 eingeleitet.)

In dem Terminal befindet sich eine Firmware. Das ist Software, die auf der Platine hartcodiert ist. (PC-Benutzer können sich das wie ihr CMOS vorstellen. Es ist ein kleines Software-Modul, das eine begrenzte Anzahl von Aufgaben durchführen kann.) Leider hatte ich keine Möglichkeit, an eine Abbildung des Bildschirms zu kommen, so daß ich ihn beschreiben muß. Wenn das Terminal bootet, sehen Sie zuerst eine Copyright-Meldung und dann einen leeren Bildschirm mit einem blinkenden Cursor. Das Terminal ist nun bereit, Befehle entgegenzunehmen. Um die Einstellungen der Firmware zu ändern, betätigen Sie die [F3]- Taste Dadurch erhalten Sie am unteren Bildschirmrand ein Menü, in dem Sie unterschiedliche Einstellungen ansehen und ändern können. Diese betreffen nicht nur die Art, in der die Kommunikation durchgeführt wird, sondern auch das Layout und das Verhalten des Bildschirms. Sie können z.B. zwischen schwarzer Schrift auf bernsteinfarbenem Hintergrund oder umgekehrt wählen. Sie können eine Schreibmaschinentastatur oder einen Datenmodus festlegen und die Anzahl von Zeichen pro Zeile und Zeilen je Bildschirm verändern. Außerdem enthält die Firmware noch kurze Hilfe-Meldungen, die in der Statuszeile unten am Bildschirm zu sehen sind und z.B. anzeigen, welchen Drucker Sie benutzen. Maus, Festplatte, Diskettenlaufwerk oder andere Komponenten sind weder vorhanden noch erforderlich.

Hinsichtlich der Einstellungen für die Datenübertragung haben Sie eine große Auswahl. Sie können z.B. die Bitzahl verändern (normalerweise 7 oder 8) und auch die Parität (keine, ungerade, gerade). Dadurch kann das VT220 nicht nur mit VAX-Maschinen kommunizieren, sondern auch mit einer Vielzahl von Unix-Maschinen. Sie können ein VT220-Terminal z.B. als »Kopf« einer Workstation verwenden, die sonst keinen Monitor hat. Dazu schließt man das Terminal an den ersten seriellen Port der Workstation an. (Für die meisten Unix- Versionen muß man das achte Bit weglassen.)

Tip:

Für Linux-Hacker: Sie können Ihrem Rechner auch einen Internet-Knoten »hinzufügen«, indem sie ein solches Terminal benutzen. Dazu schließen Sie das Terminal entweder an COM1 oder COM2 an. Dann editieren Sie inittab , um eine weitere Instanz von getty an diesem Port zu erzeugen. Damit dies funktioniert, müssen Sie ein Nullmodem-Kabel verwenden. Außerdem müssen Sie als Emulation VT100 einstellen. Nach dem Reboot des Linux- Rechners wird ein Login-Prompt auf dem VT220 zu sehen sein. Dort melden Sie sich als irgendein gültiger Benutzer an, und Sie sind fertig. Dies ist sehr wertvoll, besonders, wenn Sie jemandem die Programmierung oder Navigation des Internet über eine Befehlszeilen-Schnittstelle (CLI - command line interface) beibringen wollen. Eines ist noch wichtig: Wenn Sie denselben COM-Port verwenden, an dem normalerweise Ihre Maus angeschlossen ist, müssen Sie gpm (general purpose mouse support) deaktivieren. Dasselbe gilt für die Konfiguration Ihres X-Servers.

Diese Terminals waren zwar für die Verwendung mit der VAX vorgesehen, können aber auch als die preiswerteste Methode für einen Zugang zum Internet verwendet werden. Natürlich benötigen Sie dafür eine altmodische Wählverbindung (vielleicht in Delphi), aber der Preis ist unschlagbar. Sie können ein solches Terminal heute für 20 Dollar kaufen. Dazu brauchen Sie noch ein 19.200-Baud-Modem, und das war's. Auch für den Zugang zu lokalen Mailboxen sind diese Geräte großartig.

Tip:

Interessant ist hierbei, daß ein solches Terminal von sich aus keine Umgebungsvariablen hat. Alle Umgebungsvariablen werden von der Shell übernommen, die Sie auf dem entfernten Rechner bekommen.

Mit einem solchen Terminal können Sie sich mit der VAX verbinden. (Beachten Sie bitte, daß ich nur sehr frühe Ausführungen von VT-Terminals beschrieben habe. Viele spätere Modelle unterstützten unterschiedliche Farben und Grafik-Modi, die bei den älteren VT100- und VT220-Terminals noch nicht verfügbar waren. Diese neueren Modelle sind sehr funktionstüchtig, aber sie können bis zu mehrere hundert Dollar kosten. Gute Beispiele hierfür sind VT330 und VT340.)

Sie können sich aber auch ohne ein solches Terminal mit einer VAX verbinden. Dies geschieht normalerweise mit Hilfe einer PC-Software, die eine VT100-Terminal-Emulation unterstützt. (Eine weitere beliebte und kompatible Emulation ist Kermit.)

20.1 VMS

Das VMS-Betriebssystem (Virtual Memory System) ist einzigartig, weist aber dennoch Ähnlichkeiten mit einigen anderen auf. Das Einloggen funktioniert ähnlich wie bei einem Unix-System. Sie erhalten einen Login-Prompt (Username:) und einen Paßwort-Prompt. Wenn Sie die korrekten Informationen eingegeben haben, sehen Sie einen Prompt in Form eines Dollar-Zeichens ($). Außerdem erhalten Sie eine Reihe von Werten, wenn Sie sich anmelden, darunter Ihren Benutzernamen, Ihre Prozeß-ID und so weiter.

Einige übliche VMS-Befehle sind in Tabelle 20.1 aufgeführt.

Tabelle 20.1: Übliche VMS-Befehle

Befehl

Zweck

HELP [args]

Ohne Argumente führt dieser Befehl zu dem Prompt Topic?. Dem HELP-Befehl wird normalerweise der Befehl angefügt, über den Sie etwas erfahren möchten.

COPY [arg1 arg2]

Kopiert ein oder mehrere Dateien in eine andere Datei oder ein Verzeichnis.

DIRECTORY

Ähnlich dem DOS-Befehl dir führt dieser Befehl zur Ausgabe des Inhalts eines Verzeichnisses und der mit den Dateien verbundenen Attribute.

MAIL

Ruft die Mail-Schnittstelle für VAX auf. Diese funktioniert ähnlich wie Mail bei Unix. Wenn Sie eine Nachricht verfassen wollen, werden Sie aufgefordert, einen Empfänger und einen Betreff einzugeben.

LOOK

Das VAX-Äquivalent zum Unix-Befehl ps. LOOK zeigt Ihnen Ihre laufenden Prozesse.

Tip:

Es gibt eine nützliche Tabelle mit einer Gegenüberstellung von VAX- und Unix-Befehlen, die sich gut als Kurzreferenz für Unix-Anwender eignet. Sie finden sie unter http://egret.ma.iup.edu/~whmf/vms_to_unix.html. Es wäre gut, wenn Sie gleich einen Blick darauf werfen würden, da ich mich in diesem Kapitel noch auf einige dieser Befehle beziehen werde.

VMS hat viele Annehmlichkeiten, die Sie von anderen Betriebssystemen her kennen. Die Befehle sind nur etwas anders. Die C-Shell bei Unix hat z.B. eine Einrichtung, die zuvor am Prompt eingegebene Befehle erneut aufruft. Dieser Befehlspuffer wird history genannt. (DOS hat ein ähnliches Modul, das normalerweise beim Booten geladen wird und DOSkey heißt.) Bei VMS können Sie zuvor eingetippte Befehle durch (Strg)+(B) zurückrufen.

Weiterhin gibt es Tastenkombinationen zum Stoppen eines Prozesses, Auflisten aller Prozesse, Wiederaufnahme eines Prozesses, Aufrufen aktueller Benutzerstatistiken und Editieren der aktuellen Befehlszeile.

Es sind immer noch viele VAX-Server im Internet, und VMS ist noch lange nicht tot. Die neueste Version heißt OpenVMS. OpenVMS ist für VAX und Alpha-Rechner verfügbar. Alphas sind extrem schnelle Workstations (derzeit mit Geschwindigkeiten von mehr als 400 MHz), auf denen Windows NT, OpenVMS, Linux oder Digital UNIX laufen können.

Die Mehrzahl der VAX-Server im Internet sind ältere Modelle. Viele befinden sich in Universitäts-Bibliotheken und ermöglichen den Benutzern die Suche in elektronischen Katalogen. Aller Wahrscheinlichkeit nach sind die meisten älteren VAX-Rechner mindestens so sicher wie ihre Unix-Entsprechungen. Das ist deshalb so, weil man über das VAX/VMS- System und seine Sicherheit so viel weiß. Wenn es ein Sicherheitsloch gibt, dann nur deswegen, weil der Administrator es übersehen hat.

20.2 Die Sicherheit von VMS

Sicherheitsaspekte werden von VMS gut unterstützt. Z.B. gibt es eine sehr effektive Zugriffskontrolle. (Ob diese vom Systemadministrator auch richtig umgesetzt wird, ist allerdings eine andere Frage.) Die Zugriffskontrolle von VMS ist mindestens so umfassend wie die der Novell-NetWare-Plattform. Hier sind einige der Werte, die kontrolliert werden können:

Das ist wirklich nur ein Bruchteil der in VMS verfügbaren Zugriffskontrollen. Es gibt mehrere Ebenen von Privilegien, und diese können Gruppen zugeordnet werden. Gruppen wiederum können z.B. auf bestimmte Ressourcen beschränkt sein. Die Zugriffskontrolle ist bei VMS ein sehr komplexes Thema. Es gibt sehr viele Optionen. Das ist auch der Grund, warum Cracker überhaupt eine halbwegs reelle Chance haben, ein Sicherheitsloch zu finden. Manchmal kann die Komplexität selbst ein Sicherheitsrisiko darstellen. Cracker sind sich dessen sehr wohl bewußt:

Der größte Vorteil von VMS ist seine Flexibilität. Der Systemverwalter hat die Wahl zwischen einer Menge von Sicherheits-Features, die er implementieren oder ignorieren kann. Zum Glück für die Cracker scheinen alle die wirklich wichtigen zu ignorieren. Es ist möglich, alle, bestimmte oder keine der erzeugten Dateien zu schützen. Es ist außerdem möglich, allgemeine oder eingeschränkte Paßwörter zu verwenden oder überhaupt keine Paßwörter. Zugriffscodes können global oder eingeschränkt sein. Die Log-Datei kann ignoriert, nur zu Protokollierungszwecken verwendet oder als Tool zur Sicherheitskontrolle eingesetzt werden.

Wegweiser:

Der obige Paragraph ist ein Auszug aus Lex Luthors »Advanced Hacking VAX's VMS« (Legion of Doom. 1. Juni 1985). Sie finden ihn online unter http://www.mdc.net/~trent/hackvax.txt.

Dieses Dokument ist einer der maßgeblichen Texte zum Knacken des VMS-Systems. Es stammt von Lex Luthor (natürlich ein Pseudonym), der 1984 eine Mailbox mit Namen Legion of Doom einrichtete. Aus einigen der Benutzer und weiteren Personen versammelte Luthor eine Cracker-Gruppe um sich, die denselben Namen trug. Legion of Doom führten einige der außergewöhnlichsten Cracks aller Zeiten durch. Sie veröffentlichten viele elektronische Magazine im Internet, die die Kunst des Knackens vereinfachten, darunter das LoD Technical Journal. Die US-Regierung führte gegen Mitglieder der Gruppe einen nur vorübergehend erfolgreichen Feldzug. Heute sind die früheren LoD-Mitglieder ein kleiner Bestandteil der Internet-Folklore.

Wegweiser:

Vielleicht eines der besten im Internet verfügbaren Dokumente über die Sicherung eines VMS-Rechners wurde weder von einem Cracker noch von einem Hacker geschrieben: »A Practical Exercise in Securing an OpenVMS System«, von Rob McMillan vom Prentice Centre, The University Of Queensland. Sie finden es unter http://nsi.org/Library/Compsec/openvms.txt .

Ein VAX- (oder beliebiges VMS-basiertes) System anzugreifen, ist etwas ganz anderes, als ein Unix-System zu attackieren. Erstens einmal ist das Konzept der Paßwortdatei ein anderes, und auch ihre Struktur unterscheidet sich von ihrem Unix-Äquivalent. Unix-Systeme haben eine /etc/passwd, die Benutzernamen, Paßwort, Login-Shell und Gruppe definiert. Das VMS-System dagegen verwendet eine Datei, die nicht nur diese Werte, sondern viele weitere Variablen definiert:

Jede DEC, auf der VMS läuft, bewahrt die Benutzerprofile in einer Datei namens SYSUAF (System User Authorization File) auf. Für jeden Benutzer des Systems, auch für den Systemverwalter, gibt es einen Datensatz, der dem Computer mitteilt, wann und wie ein Benutzer sich in das System einloggen kann. Er enthält auch Einzelheiten zu Paßwort-Alterung, Paßwortlängen und allen Möglichkeiten, die einem Benutzer nach dem Einloggen zur Verfügung stehen.

Wegweiser:

Der obige Absatz ist ein Auszug aus »The Five Minute Guide to VMS Security: Product Review PC-DEC-Audit« (AudIT Magazine. 1994).

Man darf nicht außer acht lassen, daß diese ausführliche Paßwortdatei auch Nachteile hat. Einer davon ist dieser: Wenn ein Cracker sich Zugriff auf diese Datei verschafft und sie knackt (mit Hilfe der später in diesem Kapitel beschriebenen Utilities), ist das ganze System sofort einbruchgefährdet. Die Wahrscheinlichkeit, daß so etwas passiert, ist allerdings gering.

Der Benutzer wird übrigens durch die Verwendung eines Benutzer-Identifikationscodes (UIC - user identification code) identifiziert. Das ist eine ganz ähnliche Methode wie GID bei Unix. Der Code identifiziert den Benutzer und zu welchen Gruppen er gehören darf. Wie Sie sich vielleicht schon gedacht haben, kommt der UIC aus der zentralen Datenbank:

Wenn Sie sich in ein System einloggen, kopiert das Betriebssystem Ihren UIC von Ihrer UAF (User Authorization File) in die UAF des Systems (SYSUAF.DAT) und weist sie Ihrem Prozeß zu. Sie dient für die Dauer des Prozesses als Identifikation.

Wegweiser:

Der obige Abschnitt ist ein Auszug aus »OpenVMS Guide to System Security: Contents of a User's Security Profile. 4.1.1.3 How Your Process Acquires a UIC«, den Sie unter http://wawona.ethz.ch/OpenVMS_docu/ssb71/6346/ 6346p004.htm#heading_4.1.1 finden.

20.3 Einige alte Sicherheitslöcher

Im folgenden werde ich einige bekannte Sicherheitslöcher aufführen.

20.3.1 Sicherheitsloch Mountd

Wenn innerhalb weniger Sekunden zwei aufeinanderfolgende mount-d-s -Befehle ausgesendet werden, und bevor ein anderer Host eine solche Anforderung gemacht hat, wird der Anforderung Folge geleistet. Dies wurde zuerst vom CERT im März 1994 berichtet und gilt für VAX-Rechner, auf denen eine beliebige Variante von Digital UNIX läuft.

20.3.2 Sicherheitsloch Monitor-Utility

Bei VMS gibt es ein Utility namens Monitor. Der Zweck des Programms ist es, Klassen von systemweiten Leistungsdaten zu überwachen (entweder von einem bereits laufenden Prozeß oder von einem zuvor kompilierten Monitor-File). Das Sicherheitsloch war zwar nicht kritisch, aber dennoch bedenklich:

Autorisierte Benutzer eines Systems können unter bestimmten Voraussetzungen mit Hilfe des Monitor-Utilitys ihre Privilegien unbefugt ausweiten. Bei einem unautorisierten Zugriff auf ein System besteht die Gefahr einer Beschädigung der Systemumgebung. Dieses Problem wird jedoch keinen unbefugten Zugang ermöglichen, da Personen, die versuchen, sich unbefugt Zugang zu verschaffen, dieser weiterhin von den normalen VMS-Sicherheitsmechanismen verweigert wird.

Wegweiser:

Der obige Abschnitt ist ein Auszug aus einem CERT-Advisory mit dem Titel »VMS Monitor Vulnerability«. Sie finden es online unter http:// www.arc.com/database/Security_Bulletins/CERT/CA-92:16.VMS.Monitor.vulnerability.

Dies war ein lokales und nicht besonders kritisches Problem. Für spezifische Informationen über dieses Loch (und den Fix) sollten Sie sich die entsprechende Defense data Network Advisory besorgen.

Wegweiser:

Die Defense data Network Advisory zu diesem Sicherheitsloch finden Sie im DDN Security Bulletin 9223, ftp://nic.mil/scc/sec-9223.txt.

20.3.3 Historische Probleme: Der Wank-Wurm-Vorfall

Im Herbst 1989 tauchte ein Wurm auf, der DecNet-Rechner gefährdete. Auf infizierten Rechnern gab das Programm auf dem Terminal eine Meldung aus, daß die Maschine »Wanked« sei. Die Meldung gab vor, von den Worms Against Nuclear Killers (WANK) zu stammen. Im CERT-Advisory wurde folgendes über den Wank-Wurm geschrieben:

Dieser Wurm betrifft nur DEC-VMS-Systeme und wird über DecNet-Protokolle verbreitet, nicht über TCP/IP. Wenn ein VMS-System andere Netzwerkverbindungen hatte, war der Wurm nicht so programmiert, daß er Nutzen aus diesen Verbindungen ziehen konnte. Der Wurm ist dem Wurm HI.COM (bzw. Father Christmas) aus dem letzten Jahr sehr ähnlich.

Wegweiser:

Der obige Abschnitt ist ein Auszug aus einem CERT-Advisory mit dem Titel »'WANK' Worm On SPAN Network«. Sie finden es online unter http:// www.arc.com/database/Security_Bulletins/CERT/CA-89:04.dec- net.wank.worm.

In diesem Advisory befindet sich auch eine Analyse des Wurms von R. Kevin Oberman vom Engineering Department of Lawrence Livermore National Laboratory. Obermans Bericht wurde offensichtlich in Eile abgefaßt, aber er ist trotzdem recht vollständig. Er berichtete, daß der Wurm nicht unglaublich komplex sei, aber gefährlich sein könnte, wenn er einen privilegierten Account angreifen würde. Der Wurm würde in ein System eindringen, prüfen, ob es bereits infiziert ist, und wenn dies nicht der Fall ist, einige oder alle der folgenden Dinge ausführen:

Oberman fügte seiner Analyse ein schnell gehacktes Programm bei, das den Wank-Worm aufhalten würde. Der Quellcode dieses Programms kann immer noch online in den Original- Advisories eingesehen werden.

Wegweiser:

Das CERT-Advisory finden Sie unter http://www.arc.com/database/ Security_Bulletins/CERT/CA-89:04.decnet.wank.worm.

Was wirklich interessant ist, ist der geringe Grad an Ernsthaftigkeit dieser Advisory. Denken Sie einmal nach: Es war weniger als ein Jahr her, daß der Morris-Wurm im Internet Wellen geschlagen hatte. Die bloße Erwähnung eines Wurms konnte in diesen Monaten schon eine Panik auslösen. Seltsamerweise hielten einige Administratoren diesen Wurm jedoch wegen seines seltsamen Namens für einen Scherz.

Außerdem war der Wank-Wurm für einen großen Teil des Internet nicht von Bedeutung. Da der Wurm nur diejenigen betraf, die DEC-Protokolle verwendeten (und nicht TCP/IP), war die Anzahl potentieller Opfer begrenzt. Obwohl diese Zahl im Verhältnis zum gesamten Internet relativ klein war, gab es doch eine Menge Sites, die DecNet verwendeten.

Die Ankunft des Wurms fiel zeitlich mit Berichten über Demonstranten in Florida zusammen, die versuchten, den Start eines atomgetriebenen Nutzlast-Shuttles zu verhindern. Es wird angenommen, daß der Wurm ebenfalls ein Protest gegen den Start war. Der Wank-Wurm breitete sich gemächlicher aus als der Internet-Wurm; er löste weniger Alarme aus und erzeugte weniger Hysterie... Eine Methode zur Bekämpfung des Wurms wurde von Bernard Perrot vom Institut de Physique Nucleaire in Orsay, Frankreich, entwickelt. Perrots Plan war es, in einer Datei eines Typs, den der Wurm wahrscheinlich angreifen würde, eine Bombe zu verstecken. Wenn der Wurm dann versuchen würde, Informationen aus der Datei zu ziehen, würde er selbst angegriffen und zerstört werden.

Wegweiser:

Der obige Text stammt aus einem Artikel von Paul Mungo und Bryan Glough mit dem Titel »Approaching Zero: The Extraordinary Underworld of Hakkers, Phreakers, Virus Writers, and Keyboard Criminals«. Sie finden ihn online unter http://www.feist.com/~tqdb/h/aprozero.txt.

20.4 Überwachung und Protokollierung

Die Überwachungsmöglichkeiten in der VMS-Umgebung sind hochentwickelt. Es gibt verschiedene Methoden, die Überwachung zu implementieren, und die Entscheidung für die eine oder andere ist im wesentlichen eine Frage des persönlichen Geschmacks. Per Voreinstellung protokolliert VMS alle Logins und Login-Versuche, Änderungen der Systemprivilegien und so weiter. Die Default-Konfiguration bietet ein Mindestmaß an Protokollierung.

Dieses Mindestmaß läßt sich bei Bedarf jedoch schnell ausweiten. Der Systemoperator kann spezielle Zugriffskontrollen für einzelne Dateien oder Verzeichnisse, einen Benutzeraccount oder Prozesse errichten. Wenn im Zusammenhang mit diesen Zugriffskontrollen eine unerwünschte oder verdächtige Aktivität auftritt, wird ein Alarm ausgelöst. Der Systemoperator kann die Art dieses Alarms bestimmen. (Z.B. leiten viele Systemoperatoren Alarmmeldungen an eine bestimmte Konsole um, damit sie jederzeit eingesehen und geprüft werden können.) Natürlich kann eine schwere Paranoia in einer solchen Umgebung dazu führen, daß man einiges an Plattenspeicher opfern muß. Z.B. kann ein Systemoperator das System sogar einen Alarm erzeugen lassen, wenn jemand bloß versucht hat, auf eine Datei zuzugreifen, für die er keine Berechtigungen hat.

Ein Beispiel dafür wäre, daß ein Benutzer versucht, sich eine Datei anzusehen (oder auflisten zu lassen), für die er keine Berechtigungen hat. Das wäre das gleiche, als würde bei Unix jedesmal ein Alarm ausgelöst, wenn ein Shell-Benutzer versucht, auf eine im Eigentum von Root befindliche Datei oder ein Verzeichnis zuzugreifen. Interessant dabei ist, daß der Alarm als Antwort auf eine Verletzung von gegen den Benutzer eingestellte Richtlinien erzeugt werden kann, im Gegensatz zu globalen Beschränkungen für Dateien. Ich bin mir nicht sicher, aber ich glaube, das VMS-Modell ist das sicherere von beiden.

Die Protokollierungsmöglichkeiten von VMS sind recht vielfältig. Sie können fast alles überwachen, vom Zugriff auf eine Datei bis hin zum Starten eines protokollbasierten Prozesses durch einen Benutzer. (Sie können sogar protokollieren lassen, wenn Benutzer versuchen, die Zeiteinstellung zu ändern.) Zusätzlich zu diesen eingebauten Möglichkeiten stehen einige Utilities zur Verfügung (von denen ich einige später in diesem Kapitel noch ansprechen werde), die Terminal-Sitzungen verfolgen und auf Inaktivität und anderes unerwünschtes Verhalten überwachen können.

Einige Utilities erleichtern das Knacken der VMS-Plattform oder können verhindern, daß ein Cracker aufgespürt wird. Wie bei den anderen Systemen auch, sind diese Utilities manchmal sowohl für den Systemoperator als auch den Cracker von großem Nutzen.

20.4.1 watchdog.com

watchdog.com wurde von einem Cracker namens Bagpuss geschrieben. Der Zweck des Programms ist simpel: Es beobachtet Benutzer beim An- und Abmelden auf dem Rechner. Es ist ein Frühwarnsystem, das Sie warnen kann, wenn der Systemoperator (oder ein ähnlich privilegierter Benutzer) sich einloggt.

Wegweiser:

Den Quellcode und eine vollständige Erklärung von watchdog.com finden Sie unter http://www.wordserf.co.uk/mh/vaxhackpro.html.

20.4.2 Stealth

Stealth wurde ebenfalls von Bagpuss geschrieben. Der Zweck dieses Utilities ist es, zu verhindern, daß man entdeckt wird, wenn jemand (vielleicht der Systemoperator) den Befehl SHOW USER erteilt. Dieser Befehl ist der Kombination der Befehle W, WHO und PS bei Unix ziemlich ähnlich. Er identifiziert die gegenwärtig eingeloggten Benutzer und ihren Status. Stealth verhindert, daß der Benutzer auf eine solche Anfrage hin sichtbar wird.

Wegweiser:

Den Quellcode für Stealth finden Sie unter http://www.wordserf.co.uk/mh/ vaxhackpro.html.

20.4.3 GUESS_PASSWORD

GUESS_PASSWORD dient zum Knacken der Paßwort-Datei des VMS-Systems. Das Programm funktioniert ziemlich gut, aber man muß sich fragen, ob es wirklich einen Sinn hat. Es ist heutzutage sehr unwahrscheinlich, daß ein Systemadministrator die Datei SYSUAF.DAT (in der sich die Paßwörter befinden) ungeschützt läßt. Wenn ein Cracker eine solche ungeschützte Paßwortdatei finden sollte, könnte ihm dieses Utility jedenfalls beim Knacken helfen.

Wegweiser:

GUESS_PASSWORD (mit Quellcode) erhalten Sie unter http://www.uniud.it/ftp/vms/uaf.zip .

20.4.4 WATCHER

WATCHER ist ein Utility zum Herumspionieren, das im allgemeinen von Systemadministratoren verwendet wird. Es dient zum Beobachten von Terminal-Sitzungen. Für die Sicherheit ist dies sehr hilfreich. WATCHER überwacht, wie lange an einem Terminal keine Aktivität stattgefunden hat. Der Systemadministrator (oder der Benutzer) kann einen Zeitraum einstellen, nach dem ungenutzte Sitzungen automatisch beendet werden. (Inaktive Terminal- Sitzungen sind ein Sicherheitsrisiko. Cracker beobachten Accounts, die über längere Zeiträume hinweg inaktiv sind. Diese Accounts sind beliebte Angriffspunkte.)

Wegweiser:

WATCHER finden Sie unter ftp://ftp.wku.edu/madgoat/WATCHER.zip.

20.4.5 Checkpass

Checkpass ist ein Tool, das die relative Stärke oder Schwäche eines bestimmten Paßworts in der Datei SYSUAF.DAT untersucht. Es ist für Version 5.4 und höher geeignet.

Wegweiser:

Checkpass finden Sie unter ftp://www.decus.org/pub/lib/vs0127/checkpass/check.zip .

20.4.6 Crypt

Crypt ist ein DES-Verschlüsselungsmodul für das VMS-Betriebssystem. Interessanterweise unterstützt es auch Unix und DOS. Es wurde (wie auch das vorhergehende Utility) von M. Edward Nieland entwickelt, der diese Tools hauptsächlich in C und Fortran geschrieben hat.

Wegweiser:

Das CRYPT-Utility finden Sie unter ftp://www.decus.org/pub/lib/vs0127/ crypt/crypt.zip.

20.4.7 DIAL

Das Rückrufmodul DIAL soll verhindern, daß sich unautorisierte entfernte Benutzer Zugang zu Ihrem System verschaffen können. In der Dokumentation von DIAL ist dies so erklärt:

Nur zuvor autorisierte Benutzer können von den Telefonnummern ihres Arbeitsplatzes aus über DIAL Zugang zu dem System erlangen. Sobald der Zugriff gewährt wurde, wird die Verbindung unterbrochen und der Benutzer unter seiner autorisierten Telefonnummer zurückgerufen. Dies ermöglicht dem Benutzer über öffentliche Telefonleitungen kostenlosen Zugang zu seinem Account.

Das System funktioniert mit Hilfe einer Datei, die alle gültigen Benutzer und ihre Telefonnummern enthält. (Dies könnte eine Methode sein, die Sicherheit zu durchbrechen. Wenn Sie Zugriff auf diese Datei bekommen, können Sie DIAL umgehen.) DIAL wurde von Roger Talkov von Emulex in C verfaßt.

Wegweiser:

DIAL finden Sie unter ftp://www.decus.org/pub/lib/v00149/dial.zip.

20.4.8 CALLBACK.EXE

CALLBACK.EXE wurde von Robert Eden von Texas Utilities in Fortran geschrieben. Es hat im wesentlichen die gleiche Funktion wie DIAL.

Wegweiser:

CALLBACK.EXE finden Sie unter http://www.openvms.digital.com/cd/ CALLBACK/CALLBACK.EXE.

20.4.9 TCPFILTER (G. Gerard)

TCPFILTER ist ein Utility, das ausgehende Verbindungen einschränkt. Das ist in der Dokumentation wie folgt beschrieben:

...ermöglicht das Filtern von ausgehenden UCX-TCP/IP-Verbindungen. Jeder Versuch eines ausgehenden Anrufs wird mittels einer Adreßtabelle verifiziert und dann erlaubt oder untersagt. Die Validierung des Anrufs kann durch zwei unterschiedliche Mechanismen erfolgen: mit Zugriffskontroll-Listen (ACL) oder mit Image-Namen. Die Verwendung von Zugriffskontroll-Listen ermöglicht die Kontrolle jedes Benutzers über einen Bezeichner.

Wegweiser:

Der obige Abschnitt ist ein Auszug aus einer Datei mit Namen TCPFILTER.DOC von G. Gerard. Sie finden sie online unter http://www.openvms.digital.com/cd/TCPFILTER/.

Ich sollte vielleicht darauf hinweisen, daß mit dem Begriff Anruf ausgehende TCP/IP-Verbindungsanforderungen gemeint sind, d.h. Sie können Verbindungsanforderungen auf bestimmte IP-Adressen beschränken, basierend auf Benutzer-informationen in der Zugriffskontroll-Liste. So könnten Sie z.B. jeden Zugang zu externen Hacker- oder Cracker-Mailboxen unterbinden.

Wegweiser:

TCPFILTER finden Sie unter http://www.openvms.digital.com/cd/TCPFILTER/TCP.COM .

20.5 Andere Zeiten

Die VAX/VMS-Kombination war einmal sehr beliebt, und, wie ich bereits sagte, wird OpenVMS immer noch gerne verwendet. Dennoch haben Veränderungen in der Computer-Industrie und dem öffentlichen Bedarf sich auf die Stellung von VMS im Internet ausgewirkt. Zusammen mit Digitals Engagement mit Microsoft, eine geeignete Architektur für Windows NT zu entwickeln, haben diese Änderungen dazu geführt, daß die Verwendung von VMS zurückgegangen ist. Das ist seltsam, da heute der Quellcode von VMS verfügbar ist. Wie ich anderswo in diesem Buch bereits erwähnt habe, hat man bei einem Betriebssystem, dessen Quellcode verfügbar ist, sehr gute Möglichkeiten zu einer Feineinstellung der Sicherheitsvorkehrungen.

Da auf Digital-Alpha-Rechnern jetzt sowohl Microsoft Windows NT als auch Digital UNIX laufen, wird VMS wahrscheinlich in den Hintergrund rücken. Dies gilt besonders im Hinblick auf Digital UNIX, da dies ein 64-Bit-System ist. Stellen Sie sich einmal ein 64-Bit- System vor, das mit 600 MHz läuft. Das ist meiner Meinung nach die leistungsfähigste Konfiguration, die dem durchschnittlichen Benutzer momentan zur Verfügung steht. Ein solcher Rechner (mit mindestens 64 Mbyte RAM ausgestattet) ist meines Erachtens dem Pentium oder dem MMX weit überlegen. Die Tage des alten VAX/VMS sind wohl gezählt.

Der Cracker von heute weiß wahrscheinlich nur wenig über diese Systeme. Unix - und später Windows NT - wurde mehr Aufmerksamkeit zuteil. Wenn ich jemanden damit beauftragen wollte, einen VAX zu knacken, würde ich nach jemandem in der Altersklasse Mitte dreißig oder älter suchen. Sicherlich hat der Aufstieg des PC dazu beigetragen, daß heute so wenige etwas über die VMS-Sicherheit wissen. Die meisten jungen Leute arbeiten heutzutage mit PCs oder Macintosh-Rechnern. Deshalb kommt man kaum noch mit VAX in Berührung, außer vielleicht bei Bibliotheksservern und anderen Datenbank-Rechnern.

Unterm Strich ist VMS eine interessante, langlebige und relativ sichere Plattform. Außerdem hat DEC über die Sicherheitsschwachstellen von VAX/VMS immer ziemliches Stillschweigen bewahrt. Wenn Sie alle bekannten Advisories zu VAX/VMS einmal durchgehen, werden Sie sehen, daß DEC sich immer geweigert hat, Informationen bekanntzugeben, die auch für Cracker nützlich sein könnten. Das war eine schlaue Vorgehensweise, die es von jeher schwer gemacht hat, VAX-Server zu knacken. Wenn der Systemadministrator von VAX auf Draht war, hatte ein Cracker nicht viel zu lachen.

20.6 Zusammenfassung

VAX/VMS ist heute ein recht antiquiertes System. Aber es ist noch nicht ganz aus dem Rennen. OpenVMS hat sehr viel zu bieten. Wenn Sie eine Karriere im Bereich der Internet- Sicherheit anstreben, sollten Sie zumindest einen Einsteigerkurs zu VMS besuchen. Wenn Sie wie ich das direkte Ausprobieren bevorzugen, legen Sie sich eine gebrauchte VAX zu und versuchen Sie, diese zu knacken. Solche Systeme werden heute praktisch umsonst in misc.forsale.computers.workstation angeboten. Einige Verkäufer haben sogar noch die Original-Installationsmedien.

Insgesamt ist die Sicherheit von VAX meiner Meinung nach fortschrittlich und sogar ein bißchen elegant. In vielen Ländern der Welt ist die VAX immer noch sehr beliebt. Sich mit der VAX-Sicherheit zu befassen, ist sicher keine Zeitverschwendung.

20.7 Informationsquellen

VAX Security: Protecting the System and the Data. Sandler und Badgett. John Wiley & Sons. ISBN: 0-471-51507-8.

A Retrospective on the VAX VMM Security Kernel. Paul A. Karger, Mary E. Zurko, Douglas W. Bonin, Andrew H. Mason und Clifford E. Kahn. IEEE Transactions on Software Engineering , 17(11):1147-1163. November 1991.

Database Security. S. Castano, M. G. Fugini, G. Martella und P. Samarati. Addison-Wesley Publishing Company. 1995. (Gutes Kapitel über VAX/VMS.)

Security Guidance for VAX/VMS Systems. Debra L. Banning. Sparta, Inc. 14th National Computer Security Conference, Washington, D.C., Oktober 1991.

A Practical Exercise in Securing an OpenVMS System. Rob McMillan. Prentice Centre, The University Of Queensland. http://nsi.org/Library/Compsec/openvms.txt

How VMS Keeps Out Intruders. Tanya Candia. Computers & Security, 9(6):499-502. Oktober 1990.

ESNET/DECNET Security Policy Procedures and Guidelines. D. T. Caruso und C. E. Bemis, Jr.. ESnet/DecNet Security Revised Draft. Dezember 1989. http://www.es.net/pub/esnet- doc/esnet-decnet-security.txt

Approaching Zero. The Extraordinary Underworld of Hackers, Phreakers, Virus Writers, and Keyboard Criminals. Paul Mungo und Bryan Glough. http://www.feist.com/~tqdb/h/ aprozero.txt

VMS Monitor Vulnerability. CERT-Advisory. CA-92:16. 22. September 1992. http:// www.arc.com/database/Security_Bulletins/CERT/CA-92:16.VMS.Monitor.vulnerability



vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisKapitelanfangnächstes Kapitel