LRZ-Mitteilungen Nr. 3/2001

Fax: (089) 289-28761

Herausgeber: Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften

Anschrift: Leibniz-Rechenzentrum
der Bayerischen Akademie der Wissenschaften
Barer Straße 21
D-80333 München

Telefon: (089) 289-28784
Telefax: (089) 280 9460
E-Mail: lrzpost@lrz.de

Dr. Michael Wiseman
Wolfgang Beyer
Dr. Helmut Richter

Termine, Veranstaltungen, Allgemeines

Termine

Beachten Sie bitte auch unser neues Kurs- und Schulungsangebot in der vorliegenden Ausgabe der LRZ-Mitteilungen.

http://www.lrz-muenchen.de/services/schulung/kurse-ws2001/

Personalversammlung

Wegen einer Personalversammlung der Beschäftigten des Leibniz-Rechenzentrums werden am

Donnerstag, den 12. Juli 2001
von 9.00 bis ca. 11.30 Uhr

die Beratung und das Benutzersekretariat geschlossen und Mitarbeiter des LRZ nicht erreichbar sein. Die Zugänglichkeit zu den Rechnern und Arbeitsräumen wird dabei jedoch nicht eingeschränkt. Die Hotline ist in dieser Zeit mit einem "Notdienst" besetzt. Wir bitten um Ihr Verständnis.

Michael Wiseman

Stellenausschreibungen

Bitte beachten Sie unsere Stellenausschreibungen unter

http://www.lrz-muenchen.de/aktuell/stellenangebote/

Tutorial: Programming and Optimization Techniques
for Parallel Computers

Gemeinsam mit dem Regionalen Rechenzentrum Erlangen (RRZE) und dem Kompetenznetzwerk für Technisch-Wissenschaftliches Hoch- und Höchstleistungsrechnen in Bayern (KONWIHR) veranstaltet das Leibniz-Rechenzentrum unter dem Titel

Programming and Optimization Techniques for Parallel Computers

ein viertägiges Tutorial in Erlangen.

Ziel des Tutorials ist die Einführung in parallele Programmiertechniken, insbesondere für die Benutzung des Höchstleistungsrechners in Bayern (HLRB) Hitachi SR8000-F1, sowie anderer SMP (Symmetric Multi-Processing) basierter Hochleistungssysteme wie z.B. die SGI Origin3400 am RRZE, das LINUX Cluster oder die IBM SMP H70 am LRZ.

Einzelheiten finden Sie unter dem unten angegebenen URL für die Anmeldung.

Zeit: Montag - Donnerstag, 8.-11. Oktober 2001

Ort: Regionales Rechenzentrum Erlangen Martensstraße 1, 91058 Erlangen

Dozenten: Dr. Reinhold Bader (LRZ), Dr. Matthias Brehm (LRZ), Dipl.-Phys. Georg Hager (RRZE), Dr. Tim Lanfear (Hitachi Europe), Dr. Gerhard Wellein (RRZE)

Anmeldung: Die Anmeldung erfolgt über das Webformular in

http://www.lrz-muenchen.de/services/compute/hlrb/kurse/Kurs4.html

Anmeldeschluss ist der 25.9.2001.

Matthias Brehm, Ralf Ebner
Brehm@lrz.de,Ebner@lrz.de

Am LRZ abzugebende Geräte

Am LRZ werden die unten aufgeführten Geräte nicht mehr eingesetzt bzw. nicht mehr benötigt.

Die Geräte werden an Interessenten aus dem Hochschulbereich oder aus anderen Behörden kostenlos abgegeben.

Die angebotenen Netzkomponenten werden aufgrund von Netzumstrukturierungen am LRZ nicht mehr benötigt. Die weitere Verwendung der Netzkomponenten setzt profunde Kenntnisse über Netzprotokolle voraus. Eine Unterstützung beim Betrieb der Geräte kann nicht gegeben werden.

Senden Sie bitte bei Interesse eine Nachricht an die E-Mail-Adresse:

geweg@lrz-muenchen.de

Wir werden dann mit Ihnen Kontakt aufnehmen.

Alfred Läpple

Landes-, Campus- und Sammellizenzen

Amira – Datenvisualisierung, Volumenvisualisierung, Segmentierung, Oberflächenrekonstruktion

Der folgende Beitrag wendet sich an Institute, die sich für die Visualisierungssoftware Amira interessieren. Bei ausreichender Beteiligung besteht die Aussicht, durch ein Campus-Programm eine verbilligte Bezugsmöglichkeit zu schaffen.

In letzter Zeit wurden an das LRZ Anfragen nach einer verbilligten Bezugsmöglichkeit für die Visualisierungssoftware Amira herangetragen. Eine solche gibt es derzeit noch nicht. Die Firma Template Graphics Software Inc. (TGS), die den Vetrieb der am Konrad-Zuse-Zentrum für Informationstechnik in Berlin entwickelten Software übernommen hat, bietet jedoch ein Campus-Programm an, das schon bei einer moderaten Teilnehmerzahl eine nennenswerte Preisreduktion gegenüber dem Hochschullistenpreis zur Folge hätte. Da die Vereinbarung eines Campus-Programms noch einige weitere Vorteile bietet (z.B. heimische Nutzung der Lizenzen oder Support per E-Mail), möchte ich auf diesem Wege Interessenten bitten, sich mit mir in Verbindung zu setzen.

Hier die wichtigsten Rahmenbedingungen eines Campus-Programms:

• Es können Lizenzen der Amira Standard-Version oder Developer-Version bezogen werden, wobei der Preis der Developer-Version um ca. 40 % höher liegen wird. Der Preis einer einzelnen Lizenz hängt von der Anzahl der Teilnehmer ab und kann daher noch nicht genau angegeben werden. Eine Vereinbarung mit TGS wird jedoch nur dann getroffen werden, wenn sich dadurch eine deutliche Preisreduktion ergibt.
• Sollte die Campusvereinbarung des LRZ auslaufen, verbleiben die erworbenen Lizenzen im Eigentum der Institute, stehen aber nicht mehr unter Wartung. Die Mindestdauer des Campus-Programms ist ein Jahr, bei ausreichender Teilnehmerzahl kann unter Umständen eine mehrjährige Vereinbarung günstiger sein.

Amira hat seine besonderen Stärken im Bereich Volumenvisualisierung, interaktive Segmentierung von Bildern und Rekonstruktion polygonaler Oberflächen aus den segmentierten Datensätzen. Es erfreut sich steigender Beliebtheit bei Anwendern in verschiedensten Fachrichtungen, z.B. Medizin, Biologie, Materialwissenschaften, usw. Auf der Hochleistungs-Grafikworkstation im LRZ ist eine Lizenz von Amira installiert. Bitte wenden Sie sich an mich, wenn Sie die Software testen möchten, oder sonstige Fragen zum geplanten Campus-Programm haben.

Informationen zu Amira finden Sie z.B. unter http://www.amiravis.com

Jutta Dreer
Jutta.Dreer@lrz.de

Kommunikation, Netzwerke

Neue Einwahl zu günstigen Preisen

Den Zugang über Modem oder ISDN zum Münchner Wissenschaftsnetz (MWN) und damit auch ins Internet kann das LRZ jetzt wieder zu günstigen Preisen anbieten.

Nachdem am 18.4.2001 die Telekom die Leitungen zum Unternehmen Callino abgeschaltet hatte war die direkte Einwahl in das MWN vorübergehend nur über unsere alten Zugänge zu den relativ hohen Telekom-Tarifen möglich. Nach Verhandlungen mit mehreren Firmen konnte das LRZ mit dem Internet-Anbieter Easynet eine neue Vereinbarung über einen Einwahldienst abschließen. Die Konditionen sind im Wesentlichen die gleichen wie bei der von Juli 2000 bis Mai 2001 betriebenen Lösung. Die Tarife zeigt folgende Tabelle:

Die neue, bundesweit gültige Rufnummer lautet 0192 56514. Außer dieser ist bei der Konfiguration der Verbindung nichts umzustellen. Die Abrechnung erfolgt sekundengenau wie gewohnt über die Telefonrechnung der Deutschen Telekom. Alle Nutzer mit einer im MWN gültigen Einwahlkennung (AFS-Kenung, Studentenkennung, Radius-Kennung) können den neuen Zugang sofort ohne extra Anmeldung verwenden.

Die IP-Adresse wird beim Verbindungsaufbau dynamisch zugewiesen, feste Adressen sind leider nicht möglich (insbesondere auch nicht für die Informatik der TU). Die Adressen kommen aus dem Intervall 212.224.54.1 - 212.224.55.254, welches in unseren Routern als MWN-interner Bereich konfiguriert wird. Der IP-Datenverkehr wird nicht zum LRZ geleitet, sondern über die Infrastruktur von Easynet geroutet. In der Anfangsphase könnte dabei der Durchsatz infolge von Leitungsengpässen etwas reduziert sein, Easynet hat aber bereits neue Kapazitäten bestellt. Die Anzahl der für die LRZ-Nutzer reservierten Kanäle auf der Fernsprechseite beträgt (vorerst) 270.

Das Uni@home-Angebot, also die alten Rufnummern zum normalen Telekom-Tarif, bleibt weiterhin unverändert bestehen.

Weitere Einzelheiten zum Modem/ISDN-Zugang finden Sie auf dem WWW-Server des LRZ unter

http://www.lrz.de/services/netzdienste/modem-isdn

Bei Fragen oder Problemen wenden Sie sich bitte wie gewohnt an die LRZ-Hotline, Tel. 289-28800, E-Mail: hotline@lrz.de.

Wolfgang Beyer
Beyer@lrz.de

Blockierung von E-Mails mit ausführbaren Anlagedateien

Wegen der zunehmenden Gefahr der Viren-Verbreitung durch E-Mails werden ab 26.6.2001 von den Mailrelays des LRZ keine E-Mails mit ausführbaren Anlagedateien (Attachments) mehr weitergeleitet.

Vor mehr als zwei Jahren, im März 1999, kam es mit dem Melissa-Virus zum ersten großen Ausbruch einer E-Mail-Virus-Epidemie. Weitere große Ausbrüche folgten im Mai 2000 (ILOVEYOU mit seinen unzähligen Varianten), im Februar 2001 (Anna Kournikova) und Mai 2001 (Homepage) mit jeweils entsprechendem Medienecho. Zum großen Teil  klangen diese Epidemien nach einigen Tagen ab.

Neben diesen Viren mit spektakulären Verbreitungen gibt es aber auch Dauerbrenner wie die Viren W32/Apology und W32/Hybris-B, die permanent in großer Anzahl gesichtet werden (siehe Monatsstatistiken von Sophos unter http://www.sophos.com/virusinfo/topten/ ).

Die große Ausbreitung dieser Viren ist nur dadurch möglich geworden, dass sie zusätzlich zu ihrem viralen Teil auch über eine Wurmkomponente verfügen. Das bedeutet, dass die Viren nicht mehr darauf angewiesen sind, dass ein Mensch aktiv den Transport eines Virus bewirkt, etwa durch einen FTP-Dateitransfer oder das manuelle Versenden einer E-Mail. Stattdessen sorgt die Wurmkomponente dafür, dass das Virus sich nach der Infektion weitgehend selbsttätig per E-Mail verschickt. Die meisten Viren benutzen dabei die Einträge in den Adressbuchdateien der Mailprogramme Outlook und Outlook Express von Microsoft, da diese sehr viel verwendet werden.

Trotzdem können sich die Viren nicht ganz ohne das Zutun der Menschen ausbreiten. Nachdem das Virus in der Mailbox angekommen ist, sorgt erst der Inhaber der Mailbox für die Infektion, indem er durch einen Klick auf die angehängte Anlagedatei den viralen Code zur Ausführung bringt.

Damit dieser Klick auch erfolgt und die E-Mail nicht in den Papierkorb wandert, wenden die Virenschreiber ein geschicktes "Social Engineering" an. Der Empfänger wird durch einen entsprechend verfassten Text und einen geschickt gewählten Namen der Anlagedatei dazu gebracht, sich die Anlage ansehen zu wollen. Oft wird dabei suggeriert, es handle sich bei der Anlage um erotisches Material. Politische Inhalte hingegen, wie Injustice oder Mawanella, zeigen eine wesentlich geringere Ausbreitung.

Der andere Punkt, der die Vorsicht der meisten Leute ausschaltet, ist die Tatsache, dass die E-Mail von jemandem geschickt wurde, den man kennt. Und von jemandem, den man persönlich kennt, nimmt man nicht an, dass er einem ein Virus schickt. In diesem Fall ist aber das Vertrauen, das man Bekannten und Freunden im Gegensatz zu Fremden entgegenbringt, ein schlechter Ratgeber.

Kamen beim Auftreten des Melissa-Virus nur wenige Exemplare an den Mailrelays des LRZ an, so wurden bei den anderen Ausbrüchen bereits am ersten Tag bis zu 1000 Kopien registriert. Waren wir nach den Ausbrüchen 1999 und 2000 noch der Ansicht, jeder wäre sich jetzt doch der Gefahr des sorglosen Anklickens unbekannter Anlagen bewusst, wurden wir durch die Fälle in diesem Jahr eines Besseren belehrt.

Große Sorgen bereitet uns auch die Tatsache, dass die Anzahl der neuen Viren pro Monat kontinuierlich ansteigt. So werden inzwischen pro Monat mehr als 1000 neue Viren erzeugt. Möglich geworden ist dies dadurch, dass ein großer Teil der Viren in einer interpretierten Programmiersprache wie der Makrosprache bei MS-Word oder wie Visual Basic Script geschrieben werden. Damit hat jeder, der ein Virus zugeschickt bekommt, den Quellcode des Virus in der Hand und damit die einfache Möglichkeit, eine neue Variante zu programmieren.

Die andere Entwicklung, die zu dieser großen Anzahl führt, ist die Existenz von so genannten Viren-Kits. Damit kann man ohne große Kenntnisse ein neues Virus zusammenbasteln. Beispiele sind Kournikova, Homepage und Mawanella.

Aus diesen Gründen hat sich das LRZ entschlossen, etwas gegen die Verbreitung von infizierten E-Mails zu unternehmen. Die ideale Lösung wäre der Einsatz eines in das Mailsystem integrierten Virenscanners. Diese Möglichkeit bietet das Produkt Mail*Hub von Syntegra, das wir auf den Mailrelays einsetzen, zwar an, aber nur zu exorbitant hohen Kosten. Daher können wir diesen Weg zurzeit nicht beschreiten. Da wir aber trotzdem so schnell wie möglich etwas gegen die Ausbreitung der Viren unternehmen wollen, werden wir eine andere Maßnahme ergreifen.

Alle oben genannten Viren bzw. deren Wurmanteil benutzen zur Ausbreitung E-Mails mit dem gleichen Aufbau. Die E-Mails bestehen aus zwei Teilen, einem einleitenden Textteil und einer ausführbaren Anlage (Ausnahme Melissa, hier besteht die Anlage aus einem infizierten Word-Dokument). Als ausführbar sind die Anlagen dadurch gekennzeichnet, dass der Name eine bestimmte Dateiendung aufweist. Anhand dieser Endung ist ein Mailprogramm auf einem PC mit einem Windows-Betriebssystem in der Lage, die Anlage nach einem Klick automatisch auszuführen.

Damit es nicht so weit kommen kann, ist eine einfache Gegenmaßnahme die Blockade solcher E-Mails. Das bedeutet, eine E-Mail, die eine ausführbare Anlage enthält, wird mit einer erläuternden Meldung versehen umgehend an den Absender der E-Mail zurückgeschickt und nicht an den Empfänger ausgeliefert. Dies gilt sowohl für Mails die über das Mailrelay versendet als auch empfangen werden.

Um die Auswirkungen einer solchen Maßnahme einschätzen zu können, haben wir über einen gewissen Zeitraum die Namen aller Anlagen protokolliert. Es zeigte sich, dass ungefähr eine von 1000 Mails eine ausführbare Anlage enthält.  Fast jede vierte dieser ausführbaren Anlagen konnte sicher als Virus identifiziert werden.

Auf der anderen Seite bedeutet dies, dass bei einer Blockade der ausführbaren Anlagen auf eine zu Recht zurückgewiesene E-Mail drei andere E-Mails kommen, bei denen die Anlagen eher nicht mit einem Virus infiziert sind. Eine Blockade bedeutet also auf der einen Seite einen Schutz vor Infektion von bestimmten Viren, auf der anderen Seite einen erhöhten Aufwand ein ausführbares Objekt per E-Mail zu verschicken. Diese beiden Seiten gilt es bei einem Für oder Wider einer Blockade gegeneinander abzuwägen.

Um ein ausführbares Objekt trotz der Blockade per E-Mail verschicken zu können gibt es zwei Möglichkeiten: Entweder wird der Dateiname der Anlage so gewählt, dass sie nicht mehr automatisch ausgeführt werden kann, oder das ausführbare Objekt wird gezipt und in der gezipten Form der E-Mail beigegeben. Zippen bedeutet dabei das Komprimieren und Einpacken in eine Archiv-Datei mit der Endung .zip, was mit einem Programm wie Power Archiver (auf Internet-CD des LRZ oder unter http://www.powerarchiver.com) gemacht werden kann. In beiden Fällen wird die Mail dann nicht mehr geblockt.

Vergleicht man diesen Aufwand des Versendens mit dem Aufwand den jemand treiben muss, der sich durch seine Unachtsamkeit mit einem Virus infiziert hat, so ist klar ersichtlich, dass der Aufwand den PC wieder virenfrei zu bekommen und zerstörte Daten zu restaurieren wesentlich höher ist.

Aus diesem Grund hat sich das LRZ entschieden alle E-Mails, die über die Mailrelays des LRZ laufen und eine ausführbare Anlage enthalten, zu blockieren und umgehend wieder an den Absender zurückzuschicken. Als ausführbar werden dabei Dateien mit folgenden Endungen angesehen: exe, com, bat, pif, scr, vbs.

Der Absender wird über den Grund der Abweisung informiert mit einem Hinweis auf die URL

http://www.lrz-muenchen.de/services/netzdienste/email/policy/

unter der die genauen Policies des LRZ beschrieben sind.

Wegen der hohen Dringlichkeit ist diese Maßnahme kurzfristig am

Dienstag, 26.06.2001

in Kraft getreten.

Wir sind uns im Klaren, dass dies nur eine Notlösung sein kann, bis wir in der Lage sind einen integrierten Virenscanner einzusetzen, vor allem auch deswegen, da durch diese Lösung nur ein Teil der Viren erfasst wird. So schlüpfen weiterhin alle MS-Word oder MS-Excel Makroviren oder in ein HTML-Dokument eingebettete Viren durch diese Blockade hindurch. Für diese Fälle kann man sich schützen, indem man zum Betrachten von Anlagedateien statt den Makro-fähigen Anwendungen so genannte Viewer-Programme konfiguriert, welche keine Makros ausführen und deshalb keine Viren aktivieren können. Viewer-Programme für Windows für die wichtigsten Anwendungen finden Sie auf der Internet-CD des LRZ unter \software\windows\viewer oder online unter

ftp://ftp.lrz.de/pub/comp/platforms/pc/win95/

Damit beim Starten eines Dokuments statt der zugehörigen Anwendung (z.B. Word) nur der Viewer gestartet wird, ist die Zuordnung im Windows-Explorer unter Ansicht -> Optionen -> Dateitypen -> (z.B.) Microsoft Word Document -> Bearbeiten -> Öffnen -> Bearbeiten anzupassen. Im Feld Anwendung für diesen Vorgang ist dann der Pfad für das installierte Viewer-Programm einzutragen.

Außerdem sollte man bei Programmen die dies unterstützen, den Makrovirus-Schutz aktivieren (Word 97: Extras -> Optionen -> Allgemein -> Makrovirus-Schutz, Word 2000: Extras -> Makro -> Sicherheit -> Sicherheitsstufe hoch). Empfehlenswert ist auch, Javascript und ActiveX zu deaktivieren, wenn es nicht benötigt wird, zumindest für E-Mail und News. (Outlook Express: Extras -> Optionen -> Sicherheit -> Zone für eingeschränkte Sites, Netscape Messenger: Bearbeiten -> Einstellungen -> Erweitert Haken weg bei JavaScript für Mail und Diskussionsforen aktivieren)

Michael Storz
Storz@lrz.de

Sichere Übertragung von Electronic Mails

Die Mailserver des LRZ unterstützen ab sofort die sichere Übertragung von E-Mails gemäß SSL. Wir empfehlen allen Nutzern ihre Mailprogramme entsprechend zu konfigurieren.

Bei der Nutzung des Internets sollte man sich stets bewusst sein, dass prinzipiell jegliche übertragenen Daten von Dritten abgehört werden könnten. Deshalb sollten vertrauliche Informationen, insbesondere Login-Kennungen und Passwörter, nicht im Klartext übertragen werden.

Für das Internet steht zum Zweck einer verschlüsselten Übermittlung ein Verfahren namens Secure Socket Layer (SSL) zur Verfügung. Auf den Mailservern des LRZ

wurde eine neue Softwareversion installiert, welche das sichere Empfangen von E-Mails durch SSL erlaubt. Sowohl die Übertragung der Login-Informationen als auch der Mailinhalte selbst erfolgt dabei in verschlüsselter Form.

Nicht alle Mail-Programme unterstützen SSL, manche nur in Verbindung mit einem der beiden möglichen Mailprotokolle POP3 oder IMAP. Netscape Messenger erlaubt beispielsweise (auch bei den neuesten Versionen 4.77 und 6.01) nur SSL über IMAP, aber nicht über POP. Erläuterungen zu POP und IMAP finden Sie im Beitrag Hinweise zur Nutzung von E-Mail am LRZ in den LRZ-Mitteilungen vom April 1999, online abrufbar unter

http://www.lrz-muenchen.de/services/schriften/rundschreiben/1999-02/

Die SSL-Nutzung muss im eigenen Mailprogramm konfiguriert werden, damit sie verwendet wird. Wir empfehlen allen Nutzern, die nötigen Einstellungen im eigenen Interesse vorzunehmen. Eine Übertragung mit SSL erfolgt übrigens nicht spürbar langsamer als ohne SSL.

Im Folgenden werden die Einstellungen für die am häufigsten verwendeten Mailprogramme Netscape Messenger und Outlook Express beschrieben:

Wählen Sie im Menü Bearbeiten -> Einstellungen die Rubrik Mail&Diskussionsforen und öffnen diese mit einem Doppelklick. Klicken Sie auf Mail-Server. Sie finden dann unter Server für eingehende Mail die Angabe Ihres Servers, z.B. mailin.lrz-muenchen.de. Mit Bearbeiten erscheint ein Fenster Eigenschaften des Mail-Servers. Gehen Sie auf die Rubrik IMAP, wo Sie dann Sichere Verbindung benutzen (SSL) auswählen könnnen. Die Angaben werden mit OK übernommen.

Sie sollten sich dann das Zertifikat des LRZ besorgen, mit dem sowohl IMAP-Zugriff auf E-Mail, als auch Zugriff auf WWW-Seiten abgesichert werden. Wie Sie das tun, finden Sie im nachstehenden Beitrag Neue Zertifikate für sicheren WWW-Zugang mit https in diesen Mitteilungen.

Nur wenn Sie das nicht tun, erscheint beim nächsten Aufruf von Netscape Messenger eine Folge von Fenstern über ein Neues Netsite-Zertifikat, die Sie mit Weiter bestätigen und mit Fertigstellen / Weiter / Akzeptieren des Zertifikats abschließen. Sie können diese Fensterfolge für nachfolgende Aufrufe mit Auswählen von Das vorliegende Zertifikat unbefristet annehmen (bis es abläuft) unterbinden.

Wählen Sie im Menü Extras den Eintrag Konten. In der Rubrik E-Mail markieren Sie Ihr verwendetes Konto und klicken auf Eigenschaften. Im erscheinenden Fenster wählen Sie Erweitert. Markieren Sie das Kästchen Dieser Server verwendet eine sichere Verbindung (SSL) unter der Überschrift Posteingang. Schließen Sie dann die Konfiguration durch OK und Schließen ab.

Die Verschlüsselung findet nur zwischen Mail-Programm und dem Mailserver des LRZ statt, auf dem Weg vom Absender bis zum LRZ wird die Mail im Klartext übertragen. Für weiter gehende Sicherheit bei vertraulichen Inhalten ist der Einsatz einer Verschlüsselungssoftware auf den Endsystemen wie z.B. PGP ("Pretty Good Privacy")

ftp://ftp.lrz.de/pub/comp/platforms/pc/pgp/

notwendig.

Bitte beachten Sie, dass für ausgehende Mails über den Server mailout.lrz-muenchen.de zurzeit kein SSL unterstützt wird.

Wolfgang Beyer
Beyer@lrz.de

Neue Zertifikate für sicheren WWW-Zugang mit https

Die Zertifikate für den https-Zugang auf die WWW-Server des LRZ laufen Ende Juni ab; das betrifft alle LRZ-Kunden, die solche Seiten des WWW-Servers des LRZ aufrufen, bei denen sie zu Eingaben aufgefordert werden. Hier wird kurz beschrieben, wie man sich auf die Umstellung vorbereitet. Dadurch wird gleichzeitig der gesicherte Zugriff auf E-Mail vorbereitet, wie er jetzt auch eingeführt wurde. Der restliche Artikel enthält ergänzende Hintergrundinformationen zum selben Thema, die man aber zur Umstellung nicht unbedingt braucht.

Das LRZ bietet Ihnen über WWW Werkzeuge an, mit denen Sie beispielsweise Ihr Passwort ändern oder Ihre E-Mail lesen können. Diese Werkzeuge fordern Sie zur Eingabe Ihrer LRZ-Kennung und Ihres Passworts in ein WWW-Formular auf. Um nun die Übertragung des Passworts zu verschlüsseln, wird dazu das Protokoll "https" mit entsprechenden Verschlüsselungs-Zertifikaten benutzt.

Die Gültigkeit der bisherigen LRZ-Zertifikate läuft jedoch zum 3. Juli 2001 ab, weil solche Zertifikate immer nur eine begrenzte Gültigkeit haben dürfen. Bereits einige Tage vorher, nämlich vom 28.6.2001 an, werden die betreffenden WWW-Server des LRZ ein neues Zertifikat präsentieren und damit bei denjenigen Benutzern für Überraschung sorgen, die ihren Browser nicht auf die neue Situation eingestellt haben. Was ist also zu tun?

Am einfachsten, Sie besorgen sich sofort ein neues CA-Zertifikat, indem Sie den URL

http://ssl-ca.lrz-muenchen.de/getprecerts/cacerts/pre-ssl-ca.crt

in Ihrem Browser aufrufen. Sie werden dann durch eine Reihe von Menus geführt; der Weg wird im https-Artikel auf dem WWW des LRZ

http://www.lrz-muenchen.de/services/netzdienste/www/https/

unter der Überschrift "Kann ich das LRZ als Zertifizierungsstelle vorab im Browser eintragen?" für die beiden gängigsten Browser, Netscape und Internet Explorer, ausführlich vorgeführt. Kleine Details können sich mittlerweile geändert haben oder von der Softwareversion oder der Sprache (deutsch oder englisch) abhängen. Deswegen werden hier noch einmal die wichtigen Punkte zusammengestellt:

• In einigen durchlaufenen Menüs haben Sie nur die Wahl zwischen weitermachen und ablehnen: lesen Sie alles durch und machen Sie weiter. Ablehnen können Sie ganz am Schluss immer noch.
• Den Fingerabdruck (=fingerprint) sollten Sie überprüfen; er muss den Wert A2:D4:8E:B4:6F:D5:65:9C:9C:CA:60:C6:
  E5:49:19:37 haben. Beim Internet Explorer kommen Sie zwangsläufig dort vorbei; bei Netscape müssen Sie an einer Stelle einen Button "Mehr Info" drücken, wenn Ihnen das neu zu akzeptierende Zertifikat nur ziemlich unvollständig angezeigt wird.
• An einer Stelle werden Sie gefragt, für welche Zwecke das Zertifikat gut sein soll. An dieser Stelle genügt es, den Punkt Diesen Zertifikatsaussteller zum Beglaubigen von Netsites auf Netzen akzeptieren (= Accept this Certificate Authority for Certifying network sites) auszuwählen; für andere Zwecke wird das Zertifikat nicht verwendet und Sie sollten nie zu freigebig mit Rechten umgehen. Wird einmal etwas anderes gebraucht, können Sie ja immer noch Rechte nachlegen.

Sie möchten natürlich nicht nur blind nach Rezept einige Felder anklicken, sondern auch verstehen, was da geschieht. Dazu dienen die Erläuterungen im Rest dieses Artikels. Am Ende sind dann noch Links, wo Sie weiterlesen können, wenn Sie noch mehr wissen wollen.

Mit dem SSL-Protokoll (also etwa beim WWW-Zugriff https statt http) werden zwei ganz verschiedene Dinge erreicht, die nichts miteinander zu tun haben:

• Zum einen soll die Kommunikation zwischen WWW-Client und -Server verschlüsselt ablaufen, so dass Dritte, die etwa an den Zwischenstationen mithorchen, den Inhalt nicht mitbekommen. Dazu hat der Server einen Schlüssel, den nur er selbst vollständig kennt und von dem er dem Client (und ohne Gefahr auch mithörenden Dritten) genug mitteilt, dass der ihn benutzen kann; Zertifikate kommen nicht ins Spiel.
• Zum anderen soll der Client sicher sein können, es wirklich mit dem Server zu tun zu haben, den er angewählt hat. Es könnte sich ja etwa auch um das Programm eines Eindringlings ("man in the middle") handeln, das so tut, als sei es der Server, das die Daten auch an den richtigen Server weitergibt, dabei aber mithorcht oder Informationen verändert. Gegen dieses zweite Problem hilft die Verschlüsselung nichts: es reicht nicht aus, dass das angewählte Programm irgendeinen Schlüssel verwendet, es muss auch genau der Schlüssel sein, der dem legitimen Server gehört. Das wird durch ein Zertifikat nachgewiesen, welches der Server dem Client vorlegt. Das Zertifikat bescheinigt also den Zusammenhang zwischen einem Server und dem von ihm verwendeten Schlüssel, der damit eine doppelte Funktion hat: zum Verschlüsseln gemäß dem voranstehenden Punkt und auch zur Identitätsprüfung des Servers. Das Zertifikat selbst berechtigt zu nichts; es ersetzt auch keine Schlüssel, sondern legt nur fest, welchen Schlüssel ein bestimmter Server führt. Insoweit der Schlüssel zur Identifikation des Kommunikationspartners verwendet wird, hat er eine ähnliche Funktion wie eine Unterschrift im täglichen Leben: eine Person ist "echt", wenn sie eine bestimmte Unterschrift leisten kann, und ein Server ist echt, wenn er eine bestimmte Verschlüsselung durchführen kann. In diesem Bild hat dann das Zertifikat eine ähnliche Funktion wie ein Aushang mit den Unterschriftsproben der zeichnungsberechtigten Mitarbeiter in den Geschäftsräumen einer Bank.

Damit ist allerdings das Problem der sicheren Identifikation des Kommunikationspartners nur verschoben, aber nicht gelöst, denn auch das Zertifikat muss auf Unverfälschtheit überprüft werden. Dies geschieht, indem man es auf einem Weg überprüft, der nicht in derselben Weise verfälscht werden kann, etwa durch Vergleich mit anderweitig publizierten Angaben (beispielsweise dem "Fingerabdruck", von dem oben die Rede war). Es würde hier zu weit führen, auf die möglichen Mechanismen einzugehen. Aber selbst wenn das Zertifikat nur oberflächlich überprüft wird, bietet es schon einen gewissen Schutz: Ein Eindringling müsste nicht nur eine Verbindung anzapfen, sondern gleichzeitig Zertifikate fälschen und diese Fälschung für die Lebensdauer des Zertifikats aufrecht erhalten – ein erheblich größerer Aufwand.

Jetzt wissen Sie, wie die Sache prinzipiell funktioniert, und Sie können einordnen, was geschieht, wenn Sie die oben skizzierten Schritte durchlaufen: Sie akzeptieren damit nicht etwa das vom WWW-Server des LRZ vorgelegte Zertifikat selbst, sondern das Zertifikat der Stelle, die im LRZ Zertifikate unterschreibt. Um das Bild von oben noch einmal aufzugreifen: Nicht die Unterschrift des Bankangestellten haben Sie als gültig akzeptiert, sondern den Aushang mit den Unterschriftsproben. Der Grund für das Vertrauen ist ähnlich wie bei der Bank: der Aushang ist öffentlich und dauerhaft und daher vertrauenswürdiger als eine Unterschrift, von der man nicht weiß, wann und wie sie auf ein Dokument geraten ist. Genauso bleibt das Zertifikat in Ihrem Browser und ist auf die Dauer vertrauenswürdiger als ein Schlüssel, der von Mal zu Mal beim Verbindungsaufbau festgelegt wird. Das ist ein ganz erheblicher Fortschritt gegenüber der Praxis, https-Verbindungen ohne irgendeine Überprüfung zu akzeptieren, auch wenn noch manches zu tun bleibt, will man das Maximum an erreichbarer Sicherheit anpeilen.

Der Ablauf des alten Zertifikats braucht Sie jetzt also nicht mehr zu interessieren: solange der WWW-Server noch sein altes Zertifikat präsentiert, wird es überprüft und für gültig befunden, und sobald er das neue präsentiert, ist Ihr Browser auch schon darauf vorbereitet. Für den gesicherten und verschlüsselten Zugriff auf E-Mail, wie er im Beitrag "Sichere Übertragung von Electronic Mail" in diesen Mitteilungen beschrieben ist, brauchen Sie nichts mehr zu tun: der E-Mail-Server hat zwar ein eigenes Zertifikat, Sie haben aber jetzt schon dessen Unterzeichner akzeptiert, also im Bild die Unterschrift unter dem Aushang.

Wenn Sie die oben angegebenen Schritte nicht durchlaufen, werden Sie nach der Umstellung beim Aufruf einer WWW-Seite, deren URL mit

https://www.lrz-muenchen.de/

beginnt, eine Warnung bekommen, der Unterzeichner des Zertifikats sei unbekannt. Sie haben dann dieselben Möglichkeiten wie immer bei einer solchen Meldung:

• Sie können die Verbindung ablehnen.
• Sie können sie für dieses eine Mal akzeptieren. Damit erreichen Sie die Verschlüsselung der Verbindung, überprüfen aber nicht die Identität des Kommunikationspartners. Das ist schon eine ganze Menge zusätzlicher Sicherheit gegenüber einer einfachen http-Verbindung: man-in-the-middle-Angriffe sind erheblich seltener als schlichtes Mithorchen auf unverschlüsselten Verbindungen.
• Sie können die Verbindung mit diesem WWW-Server akzeptieren, solange das Zertifikat, das Sie nicht überprüft haben, gültig ist (nicht bei Microsoft IE). Die Folgen sind dieselben wie im voranstehenden Fall.

Die korrekte und sichere Vorgehensweise ist in solchen Fällen immer, die Verbindung abzulehnen und sich das Zertifikat anderweitig zu besorgen, in diesem speziellen Fall wie eben beschrieben.

Ist es bei einem WWW-Server von außerhalb des LRZ nicht klar, wo Sie das verlangte Zertifikat herbekommen, dürfen Sie die Verbindung auch einmal wie angeboten akzeptieren. Sie sollten dies aber nur dann tun, wenn das Risiko überschaubar ist, also beispielsweise auf keinen Fall, wenn Sie danach persönliche Daten oder Passwörter in ein Formular auf diesem Server eintragen wollen. Entgegen dem ersten Eindruck ist dabei die Option "nur für dieses eine Mal" eher unsicherer als "solange Zertifikat gültig", bei der ja immerhin überprüft wird, ob das unbekannte Zertifikat wenigstens immer dasselbe bleibt.

Damit wäre kurz erklärt, was geschieht, aber nicht wie. Wenn Sie mehr wissen wollen, gibt die kurze Einführung Verschlüsseln und digital signieren von der Uni Dortmund

http://www.hrz.uni-dortmund.de/s3/sicherheit/PGP-Seiten/PPK-0.html

einen ersten Überblick. Es geht dort zwar im Detail um etwas anderes, nämlich die Sicherung des E-Mail-Verkehrs, aber die verwendeten Techniken sind sehr ähnlich wie bei der Sicherung von WWW-Zugriffen mit dem https-Protokoll. Zum Thema Zertifizierung finden Sie dort nichts, das ist aber in einem schon etwas älteren Artikel aus der Zeitschrift iX

http://www.heise.de/ix/artikel/1997/04/146/

recht schön dargestellt, auch wenn die dort entfaltete Komplexität mit vielen hierarchisch aufgebauten Zertifizierungsstellen hier am LRZ nicht zum Tragen kommt. Der WWW-Server der Fernuni Hagen enthält eine klare kurze Erklärung von SSL

http://www.fernuni-hagen.de/CA/sslinfo.html

Eine technisch detailliertere Darstellung von SSL findet sich in einer Seminararbeit der Uni Mannheim

http://www.informatik.uni-mannheim.de/~rweis/digitalesgeld/sslvortrag/sslpaper.html

Den Text des vorliegenden Beitrags finden Sie einige Monate lang auch im Aktuell-Bereich des WWW-Servers:

http://www.lrz-muenchen.de/services/netzdienste/aktuell/ali0809/

Helmut Richter
Richter@lrz.de

Bundeshöchstleistungsrechner

Rückblick auf das erste Betriebsjahr der SR8000-F1

Der vom Leibniz-Rechenzentrum betriebene Höchstleistungsrechner SR8000-F1 der Firma Hitachi ist nun seit mehr als einem Jahr in Benutzerbetrieb. Dies soll uns Anlass sein, einen Überblick über den Nutzen zu geben, den der Betrieb dieser 1.33 TeraFlop/s-Maschine erbracht hat. Es soll auch auf die – für einen Rechner dieser Größe durchaus erwarteten – Probleme eingegangen werden, die im Laufe des ersten Betriebsjahres zu lösen waren bzw. deren Lösung noch aussteht.

Die 5 Millionen CPU-Stunden, die (nach Abzug einer Reserve) pro Betriebsjahr auf der SR8000-F1 zur Verfügung stehen, sind gegenwärtig um etwa 141% überverplant: Es gibt 39 genehmigte Projekte, denen insgesamt ein Jahresbudget von 11.7 Millionen CPU-Stunden zugestanden wurde. Darüber hinaus befinden sich drei Projekte in der Beantragungs- oder Begutachtungsphase, und 25 Projekte im Umfang von 335000 CPU-Stunden pro Jahr (6.7% der CPU-Kapazität) sind durch das LRZ bzw. KONWIHR für Software-Entwicklung, Ausbildungszwecke und Benchmarking vergeben worden.

Wie durch den Lenkungsausschuss des Höchstleistungsrechners in Bayern festgelegt, sind die Nutzer der SR8000-F1 aufgefordert, nach Ablauf ihres ersten Projektjahres einen Zwischenbericht über alle bisher erfolgten Arbeiten, die verwendeten fachlichen und algorithmischen Methoden und ggf. gewonnene Resultate abzuliefern. Darüber hinaus ist ein WWW-Dokument zu erstellen, das das Projekt und seine Ergebnisse allgemein verständlich darstellt und illustriert. Letzteres wird vom LRZ der Öffentlichkeit unter der URL

http://www.lrz-muenchen.de/projekte/hlrb-projects/

zugänglich gemacht.

Die auf der SR8000-F1 im vergangenen Jahr durchgeführten Rechnungen sollen hier durch zwei Projekte kurz illustriert werden. Das erste stammt aus dem Bereich der theoretischen Festkörperphysik. Die Abbildung 1 zeigt den Unterschied zwischen isolierendem und leitendem Material, der aus einer Simulation der Wechselwirkungseigenschaften der Leitungselektronen gewonnen wurde. In letzterem können sich die Elektronen leicht entlang der abgebildeten "Bergkette" bewegen, während sie in ersterem – wie ein Wanderer – nur sehr schwer von einem "Berggipfel" zum anderen gelangen.

Abbildung 1: Von der Computersimulation zum Strom ohne Widerstand.

Das zweite Projekt entstammt der Strömungsmechanik, in der man sich inzwischen gekoppelten Systemen aus mechanischen und Strömungskomponenten zugewandt hat. Die Abbildung 2 zeigt ein Membrandach, das einer zeitlich veränderlichen Windböe ausgesetzt ist. Man interessiert sich für die Verformung des Daches unter dem Einfluss der Umströmung. Die Größe DISTz gibt die Verformung des Daches in der z-Richtung an, wobei in den dunklen Zonen das Dach angehoben wird.

Abbildung 2: Membrandach in Windbö.

Um das Betriebskonzept der SR8000-F1 für das kommende Betriebsjahr festlegen zu können, hat das LRZ im April 2001 eine Benutzerumfrage durchgeführt. Diese beinhaltete Fragen zur Nutzung der verschiedenen Dateisysteme, zur Konfiguration des NQS Batch-Queuing-Systems, zur Installation von Tools und Software sowie zur Bewertung des Supports. Insgesamt gingen 11 Antworten ein, die jedoch zum Teil im Namen ganzer Projekte abgegeben wurden. Ausdrücklich positiv bewertet wurde der Support durch das LRZ und die Firma Hitachi.

LRZ-seits werden aus den Resultaten der Umfrage folgende Konsequenzen gezogen:

• Nach dem Ausbau der SR8000-F1 auf 168 Knoten wird es vermutlich keine knotenlokalen temporären Verzeichnisse auf den reinen Batch-Knoten mehr geben. Der freiwerdende Plattenplatz steht für andere Zwecke zur Verfügung.
• Die maximalen Joblaufzeiten werden im weiteren Betriebsverlauf schrittweise heraufgesetzt. Voraussetzung dafür ist hinreichend gute Stabilität der Hard- und Software, sonst sind die Verluste an CPU-Stunden zu groß.
• Es wird in Erwägung gezogen, vor Wartungen keinen NQS-shutdown mehr durchzuführen und damit ebenfalls die Verluste an CPU-Zeit zu verkleinern. Voraussetzung hierfür ist jedoch, dass möglichst viele Jobs in sinnvoller Weise einen Restart durchführen können. Das LRZ hofft auch auf die Unterstützung des Job-Freeze Features im Batch-System durch die Firma Hitachi.

Tabelle 1: Durchschnittliche Maschinenleistung

Tabelle 1 gibt einen Überblick über die durchschnittliche Maschinenleistung im ersten Betriebsjahr:

Die auf der Maschine tatsächlich genutzte Rechenleistung ist also im Laufe des ersten Jahres deutlich angestiegen, wobei zwischendurch immer wieder ein Monat schwache Daten zeigt.

Seit Anfang des Jahres 2001 steht als wichtiges Tool nun auch der Totalview-Debugger (Version 4.0) zur Verfügung. Darüber hinaus gibt es neben Verbesserungen an den von Hitachi implementierten Bibliotheken zur linearen Algebra (BLAS, LAPACK Version 3) auch neue Versionen der proprietären Bibliothek MATRIX/MPP, insbesondere mit einer erweiterten und thread-sicheren Implementierung der Routinen zur schnellen Fourier-Transformation.

Die meisten der am LRZ bekannten Fehler in den Compilern sind in den seit Ende März verfügbaren aktuellen Releases der Fortran 90 und C-Compiler behoben, weitere Verbesserungen an den Optimierungsmöglichkeiten des C-Compilers werden schrittweise bis in den Herbst 2001 implementiert. Ein gut optimierender C++-Compiler ist leider erst für 2002 zu erwarten.

Tabelle 2 zeigt die Betriebsstabilität der SR8000-F1, wobei in der letzten Zeile die Prozentanteile aus dem Vergleichszeitraum April 2000 bis September 2000 angeführt werden. Die verbesserte Stabilität der SR8000-F1 sind der stabiler laufenden Kühlung, aber auch der Behebung von anfänglich noch vorhandenen Fehlern der Betriebssoftware zu danken.

Tabelle 2: Betrieb- und Ausfallzeiten der SR8000-F1 Oktober 2000 bis Mai 2001

Auch was die nicht in Tabelle 2 erfassten Behinderungen des Benutzerbetriebs angeht, gibt es Positives zu berichten:

• Aus subjektiver Benutzersicht ist eine deutliche Beschleunigung bei den interaktiven Antwortzeiten zu beobachten, die auf Verbesserungen im I/O-Bereich des Betriebssystems zurückgehen. Weitere Optimierungen im Bereich der internen Netzwerk-Performance sind bis zum Herbst 2001 von Hitachi angekündigt.
• Die Beschleunigung der Maschine im I/O Bereich hatte jedoch zusammen mit den entsprechenden Optimierungen an den Benutzerprogrammen einen interessanten Nebeneffekt: Das parallele Filesystem /ptmp1 lief innerhalb weniger Tage derart voll, dass die Gleitlöschung vorübergehend bereits wenige Tage alte Dateien entfernte. Daher ist es für den Nutzer dieser Filesysteme unumgänglich, solche Dateien nach ihrer Erstellung so schnell wie möglich auf das TSM (Tivoli Storage Management) zu archivieren und auf dem Filesystem zu löschen.
• Durch den Austausch des HiPPI-Adapters gegen einen Gigabit-Ethernet-Anschluss noch im Sommer dieses Jahres wird auch die noch unzureichende Netzwerk-Bandbreite nach außen behoben; Voraussetzung für diese Maßnahme ist ein Betriebssystem-Upgrade im Juni.

Zusammenfassend kann man sagen, dass – mit Ausnahme der Netzwerkanbindung – sich Stabilität und Benutzbarkeit der SR8000-F1 im zweiten Betriebshalbjahr deutlich verbessert haben. Das LRZ hofft, dieses Qualitätsniveau für das Höchstleistungsrechnen auch nach dem Ausbau der SR8000-F1 auf 168 Knoten beizubehalten; für das kommende Betriebsjahr wird es dann in erster Linie darauf ankommen, durch Optimierung der Programme die durchschnittliche Maschinenleistung noch einmal zu erhöhen.

Reinhold Bader
Bader@lrz.de

Anhang A

Schulungsveranstaltungen im Wintersemester 2001/02

LRZ-Kurskalender Oktober 2001 bis März 2002

Anhang B

Aktuelle Landes-, Campus- und Sammellizenzen am LRZ

Zurzeit können mehrere Software-Produkte für Zwecke der Lehre und Forschung zu günstigen Bedingungen über das LRZ bezogen werden.

Dieser Anhang enthält sowohl eine Kurzbeschreibung dieser Programme als auch eine Übersichtstabelle, die deren Verfügbarkeit an verschiedenen Plattformen zusammenfasst. Landeslizenzen sind gesondert gekennzeichnet. Umfangreiche Produktsammlungen sind kursiv dargestellt.

Weitere Einzelheiten sind unter

http://www.lrz-muenchen.de/services/swbezug/lizenzen

zu finden.

X: auf allen gängigen Plattformen der jeweiligen Rubrik verfügbar
+: diese Systemversion oder höher
Kursiv gedruckt sind die Namen umfangreicher Produktsammlungen