Westfälische Wilhelms-Universität Münster
Zentrum für Informationsverarbeitung
(Universitätsrechenzentrum)



 
 

Einzelne Vorschläge zur Sicherung der Informationsverarbeitung in heterogenen Umgebungen

Herausgegeben vom Arbeitskreis der Leiter der Hochschulrechenzentren in Nordrhein-Westfalen

Ausgabe für die Westfälische Wilhelms-Universität Münster

Änderungsstand: 17.03.2000 und am 17.05.2001 neu hinzugfügt bzw. gelöscht

Inhalt

Einführung
1.1  Gefährdungspotential
1.2  Sicherheitsziele
Spezielle Maßnahmen in Endgeräten
2.1  E-Mail, NetNews, WWW und FTP
2.1.1  E-Mail und NetNews
2.1.2  E-Mail gesichert versenden
2.1.3  E-Mailbox gesichert abfragen
2.1.4  E-Mail-Relaying und -Spam
2.1.5  Gesicherte Verbindung mit NetNews-Server
2.1.6  WWW und Anonymous FTP
2.1.7  Zugriff auf Dateien und Drucker
2.1.8  Virenscanner
2.2  Typische Unix-Anwendungen
2.3  Server (und Arbeitsplatz-Rechner)
2.3.1  Server (und Arbeitsplatzrechner) allgemein
2.3.2  PCs mit Windows NT/2000
2.3.3  Windows-Terminalserver (Microsoft)
2.4  Kerberos
2.5  Sonstiges
Login und Smart-Karte
Zertifizierung
4.1  PGP-Zertifikate
4.2  X.509 - Zertifikate
4.3  Signaturgesetz und EU-Richtlinie
Zusätzliche Maßnahmen in LANs
5.1  Kontrollierter Zugang zu Netzen
5.2  Broadcast-Medien
5.3  ELANs und VLANs
5.4  Virtual private network (VPN)
5.5  Sicherung von SNMP und Netzmanagement
5.6  Private Adressräume, NAT
5.7  Firewall-Funktionen
Intrusion Detection
DFN-CERT und BSI
Information und Ausbildung
Anhang
9.1  Auszug aus dem IT-Sicherheitskonzept der Universität Paderborn
9.2  Mitwirkende an diesem Bericht
9.3  Zusammenfassung der Arbeitsergebnisse der von der Senatskommission für das Rechenzentrum (SKR) eingesetzten Arbeitsgruppe »Sicherheit« an der RWTH Aachen
10  Literatur
11  Anmerkungen

Diese Arbeit entstand nach Vorarbeiten im Zentrum für Informationsverarbeitung in der und im Zentrum für Angewandte Informatik an der Westfälischen Wilhelms-Universität Münster. Autoren waren W. Bosse, W. Held, H.-W. Kisker, W. Lange, K. B. Mertz, S. Ost, R. Perske, G. Richter und E. Sturm. Die in Münster entstandene vorläufige Version wurde von Mitarbeiterinnen und Mitarbeitern aller Hochschulrechenzentren in NRW und unter Beteiligung eines Mitarbeiters des Bundesamtes für die Sicherheit in der Informationsverarbeitung und des DFN-CERT überarbeitet. Allen Mitautoren sei dafür gedankt. Die Ausgabe für die Westfälische Wilhelms-Universität Münster ergibt sich dadurch, dass bei einzelnen Methoden vermerkt ist, ob eine Realisierung im Zentrum für Informationsverarbeitung erfolgt ist. Andere werden durch entsprechende Korrekturen ihre jeweils lokale Ausgabe leicht erstellen können. Möglich wären aber auch Ergänzungen durch die anderen HRZ, so dass gleichzeitig Nachfragen möglich würden.

1 Einführung

Die folgende Zusammenstellung bezieht sich im Wesentlichen auf technische Aspekte zur Sicherung der Informationsverarbeitung. Die Bereiche Organisation, Infrastruktur sowie Personal sind an anderer Stelle zu behandeln.

1.1 Gefährdungspotential

Mit der Nutzung der Informationsverarbeitung (IV) sind erfahrungsgemäß leider auch Risiken verbunden. Der Datentransport im Netz unterliegt z. B. folgenden Gefahren, die ausführlicher im Anhang beschrieben werden:
  1. Unbefugte Dritte könnten Daten und Passwörter mitlesen (abhören).
  2. Unbefugte Dritte könnten die Daten verändern (fälschen).
  3. Unbefugte Dritte könnten gegenüber dem Nutzer/Absender eine falsche Identität vortäuschen (falscher Server/Empfänger).
  4. Unbefugte Dritte könnten gegenüber dem Server/Empfänger eine falsche Identität vortäuschen (falscher Client/Absender).
Die meisten Gefährdungen beruhen dabei auf anonymen Zugangsmöglichkeiten zum IV-System, auf Unwissenheit, Sorglosigkeit oder mangelnde Koordination bei disjunkten Zuständigkeiten im IV-Gesamtsystem1.

In allen Fällen sollte die Größe der Gefahr abgeschätzt werden. Dabei ist ganz wesentlich zu unterscheiden zwischen Gefährdungen durch Verursacher von außen und von innen. Letztere verlangen eine feinere Granularität der Schutzmaßnahmen. Bereits die Verfügbarkeit von Daten stellt ein Gefährdungspotential dar.

Umgekehrt sind Vorkehrungen gegen Gefährdungen vorzusehen, die aus der eigenen Institution heraus initiiert werden. Dieses Gefährdungspotential kann sowohl von inneren Stationen ausgelöst werden, als auch durch von außen missbrauchte innere Stationen.

Daneben sind Vorkehrungen gegen physische Gefährdungen (höhere Gewalt, Stromausfall oder Überspannungen, Feuer- oder Wasserschäden und Beschädigungen am Netz, etwa durch Bauarbeiten) zu treffen. Nicht außer Acht gelassen werden dürfen ebenso mögliche Gefährdungen durch Bedienungspersonal sowie böswilliges oder fahrlässiges Verhalten von Personen. Diese Probleme werden hier nicht behandelt. Dazu wird u. a. auf eine »Prüfliste für ein Sicherheitskonzept der IV, 1. Entwurf, Zentrum für Informationsverarbeitung der Westfälischen Wilhelms-Universität Münster, W. Held, H.-W. Kisker, K. B. Mertz, B. Neukäter, S. Ost, R. Perske, G. Richter, Stand: 10.98« sowie auf den Anhang verwiesen.

1.2 Sicherheitsziele

Bei der Erfassung, Verarbeitung, Speicherung und Ausgabe sowie bei jedem Transport von Daten, der häufig der elektronischen Kommunikation dient, müssen folgende Sicherheiten erreicht werden: Ein wichtiger Aspekt der Vertrauenswürdigkeit ist, dass die zur Sicherung eingesetzte Software und Hardware von unabhängiger Stelle, wenn schon nicht zertifiziert, so doch mindestens validiert ist.

Zur Abwehr der Gefahren sind besonders in heterogenen System-Umgebungen2leider vielfältige Maßnahmen erforderlich, die oftmals den Durchsatz des Betriebes beeinträchtigen und deshalb nicht immer beliebt sind.

Von vielen Verantwortlichen wird heutzutage zuerst an den Einsatz von Firewalls gedacht. Mit ihnen erreicht man in einem ersten Schritt eine deutliche Verminderung der Risiken. Unbeachtet bleiben dabei jedoch häufig die Risiken, die aus dem inneren Netz drohen. Auch die langfristigen, negativen Auswirkungen von Firewalls auf Betrieb, weitere Entwicklungen des Netzes und der Netz-Anwendungen sowie der personelle Aufwand, der zur Pflege der Firewalls notwendig ist, werden häufig zu wenig beachtet.

Dieses Dokument soll aufzeigen, dass es vielfältige, ganz konkrete Möglichkeiten gibt, einen elementareren Ansatz zu verfolgen, nämlich den einer direkten Sicherung der Kommunikation von Endsystem zu Endsystem und von Nutzer zu Nutzer sowie zwischen Nutzer und Server und von Server zu Server. Bei der Kombination der elementaren Sicherung der Kommunikation von Endsystem zu Endsystem mit Firewall-Techniken, die nicht in die Netz-Technik eingreifen, erreicht man eine Sicherheit, die über dem konventionellen Firewall-Ansatz liegt und die Kommunikationsmöglichkeiten nicht behindern muss, aber ausreichend dafür sorgt, dass das Gefährdungspotential reduziert wird.

Eine allumfassende Lösung, die möglichst vollautomatisch alle notwendigen Überprüfungen vornimmt, gibt es leider nicht. Man kann also nur punktuell und Schritt für Schritt die Gefährdungen verringern. Prüflisten (s. o.), die auch vom Bundesamt für Sicherheit in der Informationsverarbeitung (BSI) herausgegeben werden, können dabei helfen, die Übersicht zu behalten. Auch sie sind leider sehr umfangreich und damit zeitaufwändig abzuarbeiten.

Eine Firewall allein schützt nicht gegen die einleitend genannten Gefahren 1, 2 und 3 und gegen die Gefahr 4 nur in sehr eingeschränktem Maße, nämlich nur dann, wenn alle Berechtigten »innerhalb« der Firewall sitzen und wenn der Angreifer versucht, von »außerhalb« der Firewall zuzugreifen.

Verschlüsselung schützt gegen die Gefahr 1 (siehe Abschnitt 1.1), zusammen mit digitalen Signaturen auch gegen die Gefahr 2 sowie gegen die Gefahren 3 und/oder 43. Eine zusätzliche Firewall verbessert aber sehr wohl den Schutz vor Angreifern, die sich Fehler in Betriebssystemen oder anderen Softwareprodukten zunutze machen, insbesondere, wenn sie von jenseits einer Firewall angreifen.

Eine besondere Gefährdung geht von den Endgeräten (PC, Workstation) aus, wenn diese nicht genügend abgesichert sind oder wenn mit Passwörtern unsachgemäß umgegangen wird. Endsysteme werden häufig »geknackt« und dann erfolgen von diesen aus z. B. Angriffe nach innen. Ähnliches gilt für Server, obwohl dafür oftmals schon einige Vorkehrungen getroffen wurden. Auch für diese sind wesentliche Verbesserungen möglich. Primäres Ziel muss es also sein, mit Priorität die Rechner im Netz sicher zu machen. Erst danach sollte man, um den Datenaustausch nicht unnötig zu behindern, zusätzliche Sicherungsmaßnahmen im Netz selbst einführen oder, falls schon vorhanden, aktivieren.

Es muss darauf hingewiesen werden, dass eine weitreichende Sicherheit ohne zusätzliche Investitionen und ohne Einschränkungen in der Nutzung nur begrenzt zu erreichen ist. Dabei ist zu beachten, dass die Sicherung der IV eine Daueraufgabe ist, die ständig Personal bindet.

Die vorliegende Abhandlung wendet sich in erster Linie an die für das IV-System Verantwortlichen, damit sie geeignete Vorkehrungen zur Sicherheit der IV treffen können. Die vorgeschlagenen Techniken sind dabei nicht im Detail erläutert worden. Soweit sie nicht bekannt sein sollten, kann man unter den jeweiligen Begriffen ergänzend ausführliche Erläuterungen im WWW finden. Die folgende Stichwortliste soll somit dazu dienen, einen Überblick über einige wichtige Möglichkeiten zu bieten und in einem Abstimmungsprozess eine Strategie zur Realisierung dieser Methoden festzulegen. Diese Liste muss, dem Kenntnisstand folgend, fortgeschrieben und umgesetzt werden. Diese Abstimmungsprozess ist insbesondere bei größeren, heterogenen IV-Ausstattungen unverzichtbar, wenn einzelne Mitarbeiter keinen vollständigen Überblick mehr über die eingesetzten Systeme und ihre Eigenschaften haben können. Es ist empfehlenswert, in einer weiteren vertraulichen Liste (Datenbank) für den internen Betrieb die eingeführten Sicherungsmaßnahmen für das IV-System zu dokumentieren, damit der Überblick erhalten bleibt.

2 Spezielle Maßnahmen in Endgeräten

Gefährdungen der IV-Systeme kann durch Einsatz spezieller, auf die Anwendungen zugeschnittener Produkte begegnet werden:

2.1 E-Mail, NetNews, WWW und FTP

2.1.1 E-Mail und NetNews

Die vorgeschlagenen Maßnahmen gelten sowohl für E-Mail als auch für NetNews (mit NetNews Transport Protocol) Als mögliche Abhilfen ergeben sich:

E-Mails verschlüsseln.

Es gibt zwei wesentliche zueinander inkompatible Methoden zur Verschlüsselung: PGP und S/MIME. Falls es erforderlich ist, muss man beide Methoden vorhalten.

Ob eine E-Mail wirklich angekommen ist, kann derzeit nicht automatisch überprüft werden.

Inwieweit E-Mails digital signiert oder mit digitalem Zeitstempel versehen werden können, um damit weitere Sicherheit zu erreichen, wird unten beschrieben.

Methode PGP

Software:
PGP kann in fast alle E-Mail-Programme eingebunden werden und ist für Windows, Macintosh und Unix vorhanden. (In Betrieb4.)
Zertifizierung:
Auf Wunsch durch PGP-Zertifikat der WWU-Zertifizierungsstelle (CA) im ZIV oder andere CAs.
Schutzbereich:
(auf dem gesamten Transportweg der E-Mail)
Verschlüsselung: Gefahren 1, 35

Signatur: Gefahren 2, 4
Bemerkung:
Solange man die PGP-Versionen 2, 5 oder 6 mit RSA-Schlüsseln nutzt, gibt es keine Kompatibilitätsprobleme. DSS/DSH-Schlüssel werden von älteren Versionen nicht unterstützt. Bei PGP 5 und 6 sollte unbedingt die Warnmeldung vor Verwendung des ADK (Additional Description Key) eingeschaltet werden.

Methode S/MIME

Software:
Netscape Communicator (Windows, Macintosh, Unix; erprobt)
Microsoft Outlook, Outlook Express (Windows, Macintosh; vorhanden)
Zertifizierung:
Notwendig für jeden Teilnehmer, erfolgt mittels X.509-Zertifikat der WWU-Zertifizierungsstelle (CA) im ZIV oder anderer CAs.
Schutzbereich:
(auf dem gesamten Transportweg der E-Mail)
Verschlüsselung: Gefahren 1, 3

Signatur: Gefahren 2, 4

2.1.2 E-Mail gesichert versenden

Da beim Absenden keine Passwortkontrolle erfolgt, brauchen SMTP-Server nicht besonders gesichert zu werden, die vorstehend genannten Maßnahmen reichen im Prinzip aus. Trotzdem kann auch hier SSL eingesetzt werden.
Software:
     Clients:
Netscape Communicator (Windows, Macintosh, Unix; erprobt)
Microsoft Outlook, Outlook Express (Windows, Macintosh; vorhanden)
     Server:
SSL-Tunnel für SMTP-Server (vorhanden, allerdings werden Client-Zertifikate ignoriert)
Zertifizierung:
Auf Wunsch durch PGP-Zertifikat der WWU-Zertifizierungsstelle (CA) im ZIV oder andere CAs.
Schutzbereich:
(Auf dem Weg vom Absender zum ersten E-Mail-Server. Der weitere Weg zu evtl. weiteren Servern muss auf andere Weise zwischen Servern geschützt werden).
Verschlüsselung: Gefahren 1, 3

Signatur: Gefahren 2, 4
Bemerkungen:
Soweit es gewünscht wird und möglich ist, sollten SMTP-Server mit Zugangskontrollen versehen werden; dies wird derzeit jedoch von fast keiner Client-Software unterstützt. SMTP-Server sollten nur eingesetzt werden, wenn zuvor ausreichend Vorkehrungen gegen Spam-Verbreitung getroffen worden sind.

2.1.3 E-Mailbox gesichert abfragen

Es gibt mehrere Methoden, die parallel zueinander genutzt werden können. Besonders verbreitet sind POP3 und IMAP (IMAP ist leistungsfähiger als POP3) sowie Exchange (Microsoft-spezifisch).

Methode POP3: Einsatz von SSL6

POP (Post Office Protocol): POP-Server liefert E-Mail nach Abfrage vom Client an diesen aus. Auf dem Server ist die E-Mail danach nicht mehr vorhanden, wenn nicht die Parametrierung ausdrücklich anders eingestellt worden ist.
Software:
     Clients:
Microsoft Outlook, Outlook Express (Windows, Macintosh; vorhanden)
(Netscape Communicator leistet SSL derzeit nur über IMAP und nicht über POP3)
     Server:
SSL-Tunnel für AIX-POP3-Server (erprobt, allerdings werden Client-Zertifikate ignoriert)
Zertifizierung:
Notwendig für Server, erfolgt mittels SSL-X.509-Zertifikat der WWU-CA
Optional für Client, erfolgt mittels SSL-X.509-Zertifikat der WWU-CA
Schutzbereich:
(auf dem Weg zwischen Mailbox und Nutzer, der Transport vom Absender bis zur Mailbox kann durch obige Mittel geschützt werden)
Gefahren 1 (Daten und Passwörter abhören), 2 (Daten verfälschen), 3 (falschen Server vortäuschen); indirekt durch Passwortkontrolle (bei Client-Zertifikat direkt) auch 4 (falschen Client vortäuschen)
Bemerkung:
SSL kann optional zur Sicherung und parallel zu nicht mit SSL gesicherter Übertragung genutzt werden.

Methode IMAP: Einsatz von SSL

E-Mail verbleibt zunächst auf dem Server und kann dort bearbeitet werden. Sie kann aber auch direkt auf den Arbeitsplatzrechner transportiert werden. Daneben gibt es eine Reihe weiterer Vorteile von IMAP gegenüber POP.
Software:
     Clients:
Netscape Communicator (Windows, Macintosh, Unix; erprobt)
Microsoft Outlook, Outlook Express (Windows, Macintosh; erprobt)
     Server:
SSL-Tunnel für AIX-IMAP-Server (erprobt, allerdings werden Client-Zertifikate ignoriert)
Zertifizierung:
Notwendig für Server, erfolgt mittels SSL-X.509-Zertifikat der WWU-CA
Optional für Client, erfolgt mittels SSL-X.509-Zertifikat der WWU-CA
Schutzbereich:
(auf dem Weg zwischen Mailbox und Nutzer, der Transport von Absender bis Mailbox kann durch obige Mittel geschützt werden)
Gefahren 1 (Daten und Passwörter abhören), 2 (Daten verfälschen), 3 (falschen Server vortäuschen); indirekt durch Passwortkontrolle (bei Client-Zertifikat direkt) auch 4 (falschen Client vortäuschen)

Methode Exchange: Eigene Verschlüsselung der Firma Microsoft

Software:
     Clients:
Microsoft Outlook, Outlook Express (Windows, Macintosh; vorhanden)
     Server:
Microsoft Exchange (-)7
Zertifizierung:
Notwendig für Server, erfolgt mittels SSL-X.509-Zertifikat der WWU-CA
Optional für Client, erfolgt mittels SSL-X.509-Zertifikat der WWU-CA
Schutzbereich:
(auf dem Weg zwischen Mailbox und Nutzer, der Transport von Absender bis Mailbox kann durch obige Mittel geschützt werden)
Gefahren 1 (Daten und Passwörter abhören), 2 (Daten verfälschen), 3 (falschen Server vortäuschen); indirekt durch Passwortkontrolle (bei Client-Zertifikat direkt) auch 4 (falschen Client vortäuschen)

2.1.4 Email-Relaying und -Spam

Verhinderung von unerwünschter Weiterleitung (Relaying) von Mail

Methode: Zentrales Blockieren von TCP-Port 25

Software:
     Clients:
     Server/Netzkomponente:
CISCO-IOS oder Vergleichbares
Zertifizierung:
Schutzbereich:
Gefahren 2 (Daten verfälschen,  4 (falschen Client vortäuschen)

Methode: Relayfester Mailserver

Software:
    Clients:
    Server:
Nahezu alle verbreiteten Mailserver lassen sich relayfest konfigurieren, zumindest bei qmail und postfix ist dies die Voreinstellung.
Zertifizierung:
Schutzbereich:
Gefahren 2 (Daten verfälschen),  4 (falschen Client vortäuschen)
Bemerkungen:
Der Missbrauch von Mailservern durch Relaying muss zentral bekämpft werden. Alle Mailserver sind zentral zu registrieren.

Unangeforderte Email (SPAM)

Methode: Filterung

Software:
Clients:
Verschiedene Mailclients erlauben lokale Filterung
Server:
Nahezu alle verbreiteten Mailserver erlauben eine Filterung an zentraler Stelle etwa mit einer importierbaren Liste (http.//www.mail-abuse.org) oder durch Schlüsselwort-Filterung des Headers
Zertifizierung:
Schutzbereich:
Bemerkungen:
Es wird empfohlen die zentrale Filterung nur dann durchzuführen, wenn ein Benutzer entsprechende Verfügung erteilt hat. 

2.1.5 Gesicherte Verbindung mit NetNews-Server

Methode NNTP: Einsatz von SSL

Software:
     Clients:
Netscape Communicator (Windows, Macintosh, Unix; erprobt)
Microsoft Outlook, Outlook Express (Windows, Macintosh; erprobt)

Opera Software (Windows; erprobt)
     Server:
SSL-Vorsatz für INN (funktioniert, allerdings werden Client-Zertifikate ignoriert)
Zertifizierung:
Notwendig für Server, erfolgt mittels SSL-X.509-Zertifikat der WWU-CA
Optional für Client, erfolgt mittels SSL-X.509-Zertifikat der WWU-CA
Schutzbereich:
(auf dem Weg zwischen NetNews-Server und Nutzer; der Transport der Artikel (Informationen) zwischen verschiedenen NetNews-Servern ist nicht automatisch geschützt)
Gefahren 1 (Daten und Passwörter abhören), 2 (Daten verfälschen), 3 (falschen Server vortäuschen); indirekt durch Passwortkontrolle (bei Client-Zertifikat direkt) auch 4 (falschen Client vortäuschen)

2.1.6 WWW und Anonymous FTP

WWW-Datenübertragung verschlüsseln

Methode: HTTPS = HTTP mit Einsatz von SSL

Software:
     Clients:
Netscape Navigator/Communicator (Windows, Macintosh, Unix; in Betrieb)
Microsoft Internet Explorer (Windows, Macintosh; in Betrieb)

Opera Software (Windows, erprobt)
     Server:
Apache-SSL (Unix; in Betrieb)
Viele weitere (Windows, Macintosh, Unix; teilweise in Betrieb und teilweise erprobt)
Zertifizierung:
Notwendig für Server, erfolgt mittels SSL-X.509-Zertifikat der WWU-CA
Optional für Client, erfolgt mittels SSL-X.509-Zertifikat der WWU-CA
Schutzbereich:
(auf dem gesamten Transportweg der Daten)
Gefahren 1 (Daten und Passwörter abhören), 2 (Daten verfälschen), 3 (falschen Server vortäuschen); bei Client-Zertifikat auch 4 (falschen Client vortäuschen)

Verschlüsselung kann bei Netscape mit Fortify weiter verbessert werden
Bemerkungen:
Wegen der bei WWW gegebenen Verschlüsselungsmöglichkeit wird geraten wo immer nötig Gopher und anonymous FTP durch WWW zu ersetzen.
Wenn man bei anonymous FTP Upload überhaupt erlauben will, muss man auf strenge Trennung von Upload- und Download-Bereich achten. 

2.1.7 Zugriff auf Dateien und Drucker

Mehrere völlig verschiedene Bereiche: NFS, DFS, SMB/Netbios, Appletalk

Bei der Verschlüsselung von Dateien müssen u. U. auch die Directories verschlüsselt werden.

NFS durch Secure NFS ersetzen

Software:
     Clients:
Secure NFS-Client (-)
     Server:
Secure NFS-Server (-)
Zertifizierung:
inhärent: symmetrische Schlüssel werden vom Administrator nur auf beteiligte Server und Clients verteilt
Schutzbereich:
(auf dem gesamten Transportweg der Daten)
 
 

Gefahren 1 (Daten und Passwörter abhören), 2 (Daten verfälschen), 3 (falschen Server vortäuschen), 4 (falschen Client vortäuschen)

DFS: Verschlüsselung ist mit DFS vorhanden und muss lediglich aktiviert werden.

Software:
     Clients:
DFS-Clients mit Data Masking Feature (Unix (vorhanden), Windows (-))
     Server:
DFS-Server mit Data Masking Feature (Unix (vorhanden), Windows (-))
Zertifizierung:
inhärent: Client und Server müssen beim DCE-Security-Server angemeldet sein
Schutzbereich:
(auf dem gesamten Transportweg der Daten)
Gefahren 1 (Daten und Passwörter abhören), 2 (Daten verfälschen), 3 (falschen Server vortäuschen), 4 (falschen Client vortäuschen)

Andrew File System AFS

Software:
Verteiltes, transparentes Dateisystem mit starkem
Zugriffskontrollverfahren (Kerberos).
     Clients:
erhältlich z.B. von IBM für alle Plattformen UNIX, Linux und NT
     Server:
erhältlich z. B.von IBM für viele Plattformen (versch. UNIX, Linux und NT)
Zertifizierung:
inhärent: Client und Server müssen beim AFS-Security-Server angemeldet sein
Schutzbereich:
Gefahren 1 (Daten abhören), 2 (Daten verfälschen), 3 falschen Server vortäuschen, 4 (falschen Client vortäuschen)

NTFS

Absicherung über X.509 Zertifikate ab NT 5.0.

Drucker

Es ist zu sichern, dass der gewünschte Drucker und nicht ein anderer, vorgetäuschter erreicht wird, die Druckausgabe also nicht in falsche Hände gerät.

In NT-Umgebungen ist dies gesichert.

In übrigen Umgebungen kann man ein Printmanagement (z. B. mit DCE) einführen. Oder man muss über LAN-Methoden sicherstellen, dass IP-Adressen nicht verfälscht werden können.

2.1.8 Virenscanner

Methode: Filtern mit Hilfe von Virenmustern

Software:
    Clients: Unterschiedliche Anti-Virus-Programme, z.B. NAI, Sophos
    Server: Virenscanner im Mailserver z.B. Interscan Viruswall
Bemerkung:
Die Verwendung von Virenscanner mit ständig aktualisierten Virenmustern ist grundsätzlich zu empfehlen.
Wenn man sich hinreichend vorsichtig verhält und ist im Prinzip ein gewisser Virenschutz gegeben.

2.2 Typische Unix-Anwendungen

Dialog (Ersatz für Telnet, Rlogin, Rsh usw.)

Software:
     Clients:
ssh8 bzw. slogin (Unix; in Betrieb)
TeraTerm mit TTSSH (Windows ab 95; in Betrieb) u. a. m.
     Server:
sshd (Unix; in Betrieb)
Zertifizierung:
Nicht erforderlich
Schutzbereich:
(auf dem gesamten Transportweg der Daten)
Gefahren 1 (Daten und Passwörter abhören), 2 (Daten verfälschen); eingeschränkt auch 3 (falschen Server vortäuschen; es wird jedoch nur erkannt, wenn der Server gegenüber einer früheren Sitzung wechselt); indirekt durch Passwortkontrolle auch 4 (falschen Client vortäuschen)
Bemerkung:
Personen, die den Zugang zu ihren Systemen von anderen Institutionen aus nutzen wollen (z. B. auf Dienstreisen) und dort kein SSH vorfinden, sollten Telnet unbedingt mit einem Einmal-Passwort verwenden.
Es wird geprüft, ob eine LAN-weite Einführung erzwungen werden kann. Die optionale Nutzung ist möglich.

Telnet für aktive LAN-Komponenten
Aktive LAN-Komponenten wie Router, Switches, Repeater usw. lassen sich oft über Telnet ansprechen. Dies bedeutet ein großes Sicherheitsrisiko. Daher sollte man den Zugang zu aktiven LAN-Komponenten über Telnet grundsätzlich sperren. Dies ist über entsprechende Packet-Filter (als Firewall) leicht erreichbar. (Realisiert).

Dateitransfer (Ersatz für Ftp, Rcp usw.)

Software:
     Clients:
scp (Unix; in Betrieb)
Tera Term mit TTSSH (Windows ab 95; in Betrieb) u. a. m.
     Server:
sshd (Unix; in Betrieb)
Zertifizierung:
Nicht erforderlich
Schutzbereich:
(auf dem gesamten Transportweg der Daten)
Gefahren 1 (Daten und Passwörter abhören), 2 (Daten verfälschen); eingeschränkt auch 3 (falschen Server vortäuschen; es wird jedoch nur erkannt, wenn der Server gegenüber einer früheren Sitzung wechselt); indirekt durch Passwortkontrolle auch 4 (falschen Client vortäuschen)

Remote Execution (Ersatz für Rsh, Rexec usw.)

Software:
     Clients:
ssh (Unix; in Betrieb) u. a. m.
     Server:
sshd (Unix; in Betrieb)
Zertifizierung:
Nicht erforderlich
Schutzbereich:
(auf dem gesamten Transportweg der Daten)
Gefahren 1 (Daten und Passwörter abhören), 2 (Daten verfälschen); eingeschränkt auch 3 (falschen Server vortäuschen; es wird jedoch nur erkannt, wenn der Server gegenüber einer früheren Sitzung wechselt); indirekt durch Passwortkontrolle auch 4 (falschen Client vortäuschen)

Remote Procedure Call

Der inetd-Daemon eines Unix-System initiiert Server-Prozesse für eine Reihe von Diensten: ftp, telnet, rshd, rlogin, rexec, talk, pop, imap, ... . Die Standard-inetd-Implementierung realisiert weder eine Aufzeichnung über erfolgreiche/abgewiesene Verbindungen noch erlaubt sie eine Nutzungsbeschränkung.
Abhilfe:
TCP-Wrapper oder xinetd.

Tunneln anderer Applikationen, z. B. Grafikoberfläche X11

Speziallösung für Anwendungen, die nicht anders geschützt sind.
Software:
     Clients:
ssh (Unix; vorhanden) u. a. m.
     Server:
sshd (Unix; vorhanden)
Zertifizierung:
Nicht erforderlich
Schutzbereich:
(auf dem gesamten Transportweg der Daten)
Gefahren 1 (Daten und Passwörter abhören), 2 (Daten verfälschen); eingeschränkt auch 3 (falschen Server vortäuschen; es wird jedoch nur erkannt, wenn der Server gegenüber einer früheren Sitzung wechselt); indirekt durch Passwortkontrolle auch 4 (falschen Client vortäuschen)

Batch-Dienst

Es gibt immer noch sehr leistungsfähige Serversysteme, die im Batch-Betrieb genutzt werden. Dabei werden Aufträge in Form von shell-scripten mit der Angabe der benötigten Ressourcen (Zeit, Memory, Disk, usw.) in ein Warteschlangensystem eingereiht und kontrolliert durch das Batch-System zum Ablauf gebracht.

Oftmals im Einsatz ist das Network-Queueing-System (NQS) in einer der frei verfügbaren Versionen oder eine kommerzialisierte Abart davon. Die Benutzeridentifikation erfolgt lediglich durch die UNIX-UID, die aus der den Job erzeugenden interaktiven Sitzung übernommen wird. Gegebenenfalls kann ein mapping von UIDs verschiedener UNIX-Umgebungen genutzt werden. Es ist kein über dieses Minimum herausgehender Zugriffsschutz weit verbreitet.

Abhilfe:
nicht bekannt

Trusted hosts

Unter Unix gibt es das Konzept der »vertrauenswürdigen Rechner«. Hierbei wird bei Verwendung eines vertrauenswürdigen Rechners von diesem kein Passwort verlangt. Dieses Konzept ist generell als gefährlich einzustufen, da es mehrere Schwachstellen enthält. So ist es damit z. B. einfach möglich, über einen kompromittierten Rechner weitere Zugänge zu erlangen (Island-Hopping-Attack). Der Mechanismus sollte daher genauestens kontrolliert werden.

Synchronisation von Dateibäumen

Zur gesicherten Synchronisation von Dateibäumen ist Ersatz für rdist usw. zu schaffen.
Software:
Clients:
rsync (Unix, benutzt optional ssh als Transportmethode)
Server:
rsync (Unix, benutzt optional ssh als Transportmethode)
sshd (Unix)
Zertifizierung: Nicht erforderlich
Schutzbereich: (auf dem gesamten Transportweg der Daten)
Gefahren 1 (Daten und Passwörter abhören), 2 (Daten verfälschen); eingeschänkt auch 3 (falschen Server vortäuschen; es wird jedoch nur erkannt, wenn der Server gegenüber einer früheren Sitzung wechselt); indirekt durch Passwortkontrolle auch 4 (falschen Client vortäuschen)

2.3 Server (und Arbeitsplatz-Rechner)

2.3.1 Server (und Arbeitsplatzrechner) allgemein

Der Betrieb von NT-Servern (und NT-Workstations) in einem Domain-Verbund birgt eine Anzahl Sicherheitsrisiken. Prinzipiell sind vergleichbare Maßnahmen wie zur Sicherung eines UNIX-Servers notwendig, um einen sicheren NT-Betrieb darzustellen. Nur durch verschiedene recht durchgreifende, teilweise die Benutzbarkeit der Systeme einschränkende Sicherheitsrichtlinien ist eine sichere NT-Umgebung herzustellen. Windows 2000 verspricht bzgl. Sicherungsmöglichkeiten gegen absichtlichen Benutzermissbrauch Verbesserungen und sollte diesbezüglich genau untersucht werden. Eine gute und ausführliche Zusammenfassung zur Erhöhung der Sicherheit von NT-basierten Umgebungen findet sich in "Windows NT Security Guidelines", einer Studie von Trusted Systems Services im Auftrage von NSA Research. Diese ist unter dem URL http://www.trustedsystems.com/fm_Signup.htm erhältlich.

2.3.2 PCs mit Windows NT/2000

Die Betriebssysteme Windows NT und Windows 2000 erlauben an sich die Konfiguration sehr sicherer Rechnersysteme. Bekanntermaßen legt Windows aber mehr Wert auf leichte Benutzbarkeit als auf Sicherheit, und so sind die Rechner auf Grund von Voreinstellungen - insbesondere bei Anwendungsprogrammen - vielfältigen Gefahren ausgesetzt:

Im Folgenden werden die Maßnahmen besprochen, mit denen man diesen Gefahren begegnen kann. Natürlich sind nicht alle Ratschläge in jeder Situation sinnvoll. Man sollte auf jeden Fall jede Maßnahme testen, bevor sie auf ein Produktionssystem angewendet wird.

Kontrollierte Rechtevergabe

Ein Windows-Benutzer kann über so genannte Freigaben (engl. shares) anderen Benutzern Zugriff auf eigene Ordner, Laufwerke und Drucker einräumen. Hierbei ist Folgendes zu beachten:

Parallel zu den (herkömmlichen) Freigaben gibt es bei Windows NT/2000 noch die Zugriffsrechte des NTFS-Dateisystems. Diese werden unabhängig von Netzzugriffen definiert, gelten aber bei Zugriff über das Netz ebenfalls. Bei Serverinstallationen werden üblicherweise nur noch die NTFS-Rechte zur Absicherung benutzt.

Sicherheitsrichtlinien können entweder in Systemsteuerung -> Verwaltung -> Lokale Sicherheitsrichtlinien oder mit regedt32.exe direkt in der Registry gesetzt werden. Als Dokumentation empfiehlt sich aus dem Windows 2000 Server Resource Kit die "Group Policies Reference" bzw. die "Registry Reference". Folgende Punkte sollten bedacht sein:

Das so genannte "Vordefinierte Administratorkonto" kann nicht gelöscht werden und ist von der automatischen Sperre ausgenommen, die anderen Administratorkonten auf Wunsch widerfahren kann. Der Sinn ist, dass man nicht die Wartung des Systems dadurch sabotieren können soll, dass man alle Administratorkonten durch Eingabe falscher Passwörter lahmlegt.

Lokal empfiehlt sich folgende Vorgehensweise:

Auf NT-Servern sollte der Gruppe der Administratoren wie oben beschrieben das Recht "Auf diesen Rechner vom Netzwerk aus zugreifen" entzogen werden, sofern dies praktikabel ist. Dem steht oft aber schon die zentrale Software-Wartung entgegen.

Auf einem NT-Domänencontroller befindet sich das vordefinierte Administratorkonto standardmäßig nicht nur in der Gruppe der Administratoren, sondern auch in den Gruppen "Domänen-Admins" und "Domänenbenutzer". Hier empfiehlt sich das folgende Vorgehen:

Ausspionieren von Passwörtern

Die Bedrohung durch ausspionierte Passwörter ist allgemein gegeben. Hier soll nur auf Windows-spezifische Eigenheiten eingegangen werden. Von den vielen verfügbaren Werkzeugen sei hier L0phtcrack vorgestellt (gesprochen "Loftcrack", zu beziehen von http://www.l0pht.com/l0phtcrack/). Es beherrscht alle Arten der Passwortspionage und kann sowohl von Angreifern als auch von Administratoren zur Verhütung von Spionage eingesetzt werden.

Als Quelle zur Passwortspionage kommen für L0phtcrack in Frage:

Die schnellste Möglichkeit, Passwörter zu "knacken", ist die so genannte Wörterbuchattacke. L0phtcrack gibt an, 100 Passwörter gegen ein Wörterbuch von 8 MB in 1 Min. zu vergleichen (auf einem Pentium Pro 200). Diese Methode ist auch für Administratoren geeignet: Es sollten alle Benutzer, deren Passwort im Wörterbuch stehen, darauf aufmerksam gemacht werden, dass ihr Passwort per Programm leicht zu erraten ist.

Sehr viel aufwändiger ist die so genannte "Brute Force"-Methode: Lässt man L0phtcrack davon ausgehen, dass nur Kleinbuchstaben und Ziffern vorkommen, so soll es ungefähr ein Woche Rechenzeit dauern, um z. B. das Passwort take2asp1r1n herauszubekommen. Nutzt man alle 96 möglichen Zeichen in einem 14 Zeichen langen Passwort, so gelangt man allerdings schon in den Bereich von Billarden Jahren.

Aber auch mit Windows-Bordmitteln kann man Maßnahmen gegen das Ausspionieren von Passwörtern ergreifen:

Benutzung des Browsers

Bei der Benutzung eines Browsers kann zum einen die Sicherheit der Daten bedroht sein:

Außerdem kann die Privatsphäre bedroht sein:

Als browserunabhängige Rezepte kann man empfehlen, wobei die heutigen Browser manche Vorgehensweise fast impraktikabel erscheinen lassen:

Speziell für den Microsoft Internet Explorer gelten folgende Empfehlungen:

Speziell für Netscape gelten folgende Empfehlungen:

Empfangen von E-Mail

Die Hauptgefahr beim Empfangen von E-Mail besteht im Öffnen eines als Anhang mitgeschickten Programms. Nur Datenschutzprobleme gibt es im Zusammenhang mit in HTML verfasster E-Mail: Mit Hilfe von JavaScript können Daten verschickt werden, versteckter Code kann eine Bestätigung verschicken, dass die E-Mail gelesen wurde.

Empfehlenswert ist eine Dienstanweisung, E-Mail-Anhänge erst zu öffnen nach Rücksprache mit dem Absender bzw. nach Vorankündigung. Es reicht nicht, dass man den Absender kennt. Ist der Rechner des Absenders mit einem Virus infiziert, so könnte eine Mail vom Virus im Namen des Absender mit einer schon benutzten Betreff-Zeile verschickt worden sein.

Alternativ könnte man den Anhang erst abspeichern und mit einem Virenscan-Programm untersuchen. Zum Abspeichern zwänge einen auch ein Web-Mail-Interface (statt eines üblichen Mail-Programms).

Die Mindestmaßnahme zur Erkennung eines gefährlichen Anhangs ist die Verhinderung der Tarnung mit einer unvollständigen Dateinamenerweiterung: In Extras -> Ordneroptionen -> Ansicht -> "Dateinamenerweiterung bei bekannten Dateitypen ausblenden" das Häkchen entfernen! Wenn dann ein E-Mail-Anhang nicht mehr den Namen wichtig.txt, sondern wichtig.txt.vbs hat, kann man mit ziemlicher Sicherheit von einem böswillig verschickten Visual-Basic-Programm ausgehen.

Leider gilt die Ausblendregel nicht für alle Dateitypen. In der Registry sollte man außerdem noch unter HKEY_CLASSES_ROOT in den Schlüsseln piffile, ShellScrap und xnkfile den Wert "NeverShowExt" durch "AlwaysShowExt" ersetzen. (.lnk ist die Dateinamenerweiterung für Verknüpfungen; wenn man auch diese immer zeigen möchte, so tue man für lnkfile das gleiche.)

Um die Gefahr eines versehentlich geöffneten Anhangs auszuschließen, kann man die Zuordnung einer Dateinamenerweiterung zu einem Programm so ändern, dass nicht mehr ein "gefährliches" Programm aufgerufen wird (Extras -> Ordneroptionen -> Dateitypen):

Wenn man den Sicherheitsmechanismen von Word traut, sollte man:

Betrachtet man die beiden auf Windows verbreiteten Mailprogramme, so lässt sich für Netscape 4.6 an Positivem feststellen:

Negativ fällt auf:

In ähnlicher Weise inkonsequent stellt sich Outlook Express 98 dar, positiv ist:

Negativ ist festzuhalten:

Ansonsten werden die Sicherheitsmerkmale für Outlook Express im Internet Explorer eingestellt (s. o.).

Virenscanner

Auf den oben beschriebenen und anderen Wegen kann man an Programmdateien gelangen, die zum Ziel haben, Schaden auf dem PC anzurichten. Zum Aufspüren dieser - allgemein gesprochen - Viren dient Antivirensoftware. Man findet folgende Fähigkeiten:

Außerdem sind die meisten Virenscanner in der Lage Fehlalarme zu produzieren, was die Verwendbarkeit beträchtlich einschränkt.

Die Methode, einen Virus zu finden, besteht darin, so genannte Signaturen aufzuspüren, Code-Sequenzen, die für ein bestimmtes Virus typisch sind. Durch regelmäßige Aktualisierung der Signatur-Datenbank kann man die Gefahr, von einem bekannten Virus befallen zu werden, minimieren. Die oft genannte Zeitspanne "wöchentlich" erscheint angesichts der Tatsache, dass sich neue Viren innerhalb von Stunden verbreiten, zu groß.

Zusätzlich besitzen moderne Virenschutzprogramme eine so genannte Heuristik, d. h. auch neue Viren, die auf ähnliche Art vorgehen wie schon bekannte, werden erkannt.

Abgesehen vom Problem neuer Viren gibt es weitere prinzipielle Probleme, Viren zu erkennen:

Besteht der Verdacht auf einen Virusbefall des Rechners, so ist folgendermaßen vorzugehen:

Personal Firewall

Nicht nur über Browser und per E-Mail kann dem eigenen Rechner Schaden zugefügt werden, auch durch direkte Kontaktaufnahme aus dem Internet mit einem auf dem eigenen Rechner laufenden Programm kann Schaden entstehen. Dieses auf dem eigenen Rechner laufende Programm kann insgeheim laufen (ein sog. Wurm) oder ein nützliches Programm mit Nebeneffekt (ein sog. Trojanisches Pferd) sein.

Gegen solche Angriffe aus dem Internet können so genannte Firewalls (zu deutsch: Brandmauern) helfen. Folgende Funktionalitäten sind auf dem Markt anzutreffen:

Ein Paketfilter arbeitet nach bestimmten Regeln. Zu einer Paketfilterregel gehört ein Protokoll-Typ (z. B. UDP), zwei IP-Adressen von Sender und Empfänger, deren Portnummern und eine Richtung des Verbindungsaufbaus. Passt eine Regel auf einen Verbindungsaufbauwunsch, so gilt eine festgelegte Maßnahme, entweder zulassen oder unterbinden.

Als Minimalempfehlung sollte man folgende Regeln vereinbaren:

Der Nutzen eines Firewalls ist begrenzt (!):

Ein Sandkasten, der Programmen nur dann Zugriff auf das Internet erlaubt, wenn dies explizit bei der Installation so festgelegt wurde, funktioniert leider in den bekannten Produkten noch nicht richtig. Für Programmierer existieren allerdings schon Bastellösungen (c't Nr. 10/2001). Würde diese Funktionalität vom Betriebssystem zur Verfügung gestellt, wären sämtliche Firewalls überflüssig.

Bis dahin ist der beste Firewall noch die Eingabe des Kommandos

ipconfig /release

wodurch der gesamte Internetverkehr unterbunden wird.

Backup-Strategien

Was oft vergessen wird, ist die Tatsache, dass Backups im Prinzip dieselben, möglicherweise geheimen, Daten des Rechners enthalten, nur an einem anderen Ort. An diesem anderen Ort müssen also mindestens so hohe Sicherheitsstandards gelten wie am eigenen Rechner. Insbesondere das Zurückholen der Daten darf nur von demjenigen veranlasst werden, der auch das Kopieren veranlasst hatte.

Hier tut sich, wenn man nicht aufpasst, ein Scheunentor auf. Man stelle sich etwa folgendes Szenario vor:

Diese Funktionalität zeigt, dass automatisches Backup nur für Server gedacht ist, nicht für einen PC, der schon mal unbeaufsichtigt herumsteht.

Die Sicherheitsanforderungen an den Ort des Backups können gesenkt werden, wenn Backups nur verschlüsselt aufbewahrt werden.

Quellen

2.3.3 Windows-Terminalserver (Microsoft)

Verschlüsselung auf Wunsch in beide Richtungen (Server, Client)
Software:
     Clients:
Alle Windows-Varianten, Smart-Karten
     Server:
NT
Zertifizierung:
über NT-Mittel
Schutzbereich:
(auf dem gesamten Transportweg der Daten)
Gefahren 1 (Daten und Passwörter abhören), 2 (Daten verfälschen), 3 (falschen Server vortäuschen), 4 (falschen Client vortäuschen)

2.4 Kerberos

Kerberos ist ein wichtiges Instrument zur Erhöhung der Sicherheit in heterogenen IV-Umgebungen. Kerberos wird für Windows-Systeme zukünftig verfügbar sein, für Unix-Systeme gibt es bereits seit längerer Zeit Lösungen. Stichwortartig werden folgende Eigenschaften genannt:

2.5 Sonstiges

Zu sonstiges Produkten, wie unter anderem DNS, Finger und aktive Inhalte/aktive Elemente (z. B. ActiveX, Java, JavaScript, Plug Ins, Makros und Cookies), sei auf die einschlägige Literatur verwiesen.

3 Login und Smart-Karte

Identitätskontrollen finden an verschiedenen Punkten eines IV-Systems statt. Dazu gehören u. a. Windows-Login, Workstation-Login und Einwahlserver-Login.  Die Smart-Karte liefert in Kombination mit anderen Verfahren eine "starke" Authentisierung im Gegensatz zum herkömmlichen Passwort allein ("schwache" Authentifizierung). Die Smart Karte kann auch gewisse Risiken des klassischen Passwortverfahrens eliminieren. Die Smart-Karte ist also ein wichtiges Mittel zur Erhöhung der Sicherheit beim Zugang zur IV im Endsystem und ergänzt die vielfältigen übrigen Vorkehrungen. Sie ist in Zukunft aus vielfältigen Gründen der Datensicherung (Kryptographie, digitale Unterschrift, elektronischer Zahlungsverkehr, ...) unverzichtbar. Die Smart-Karte ist die Infrastruktur der öffentlichen Schlüssel. Sie dient der Aufnahme des privaten Schlüssels, sie isoliert dabei sicherheitsrelevante Rechenoperationen von anderen Systemteilen. Weitere Informationen findet man unter W. Bosse, W. Held, H.-W. Kisker, Anwendung von Smart-Karten in Betrieben, Hochschulen und Ämtern, Zentrum für Informationsverarbeitung der/Institut für Angewandte Informatik an der Westfälischen Wilhelms-Universität Münster, Entwurf vom 09.09.1999.

Realisierungen gibt es für diverse Windows-Systeme. Erste Realisierungen für Linux sind bereits verfügbar.

Bis zur Einführung von Smart-Karten müssen weiterhin Passwörter genutzt werden. Dabei sollte u. a. Folgendes beachtet werden:

  1. Server, die Passwörter verwalten, sollten von außerhalb des Hochschulnetzes nicht erreichbar sein und von innen ebenfalls gut durch Zugangs- und Dienstebeschränkungen abgesichert werden.
  2. Benutzer sollten »gute« Passwörter wählen und diese regelmäßig wechseln.
  3. Anzustreben ist, dass Software eingerichtet wird, die Hilfestellung bei der Festlegung von Passwörtern gibt und dem Nutzer anzeigt, ob das von ihm gewählte Passwort leicht erraten werden kann, damit er gegebenenfalls ein besseres wählen kann.
  4. Benutzer sollten nie für auswärtige Server die gleichen Passwörter wie für intern Authentisierungen verwenden.
  5. Um das Abhören von Passwörtern zu verhindern, sollten Passwörter möglichst nicht unverschlüsselt über das Netz geschickt werden.
Für erhöhten Sicherheitsbedarf kann man Einmal-Passwörter verwenden, entweder in Kombination mit der Smart Karte oder als Ersatz für das klassische Passwort.

Wichtig ist das Deaktivieren anonymer Login-Zugänge. Lediglich für spezielle und überprüfbare Anwendungen darf Anonymität zugelassen werden. Zum Beispiel kann ein anonymes Login an Internet-Adressen gekoppelt werden, so dass der Rechnerzugang zwar anonym, aber nur über festgelegte Arbeitsplatzrechner ermöglicht wird. Auf diese Weise kann man die Nachfrage von externen Teilnehmern einer Veranstaltung befriedigen.

Der Passworttransport zwischen Nutzer und Einwahlserver erfolgt ohne Zusatzmaßnahmen ungesichert. Der Passworttransport zwischen Einwahlserver und Securityserver erfolgt über nicht abhörbare Pfade.

Single Sign-on bedeutet, dass mit einem einzigen Login alle Server in einer Firma oder des Hochschulnetzes erreicht werden, zu dem der Nutzer grundsätzlich Zugang hat. Dies erleichtert die Arbeit der Nutzer und verbessert die Sicherheit der IV wesentlich, weil die übrigen Server z. B. über Kerberos sicher erreicht werden. Notwendig ist dazu eine vereinheitlichte Nutzerverwaltung. Mit dem Single Sign-on wird der administrative Aufwand der IV deutlich verringert.

Mit digitalen Signaturen und Zeitstempeln kann die Echtheit von Dokumenten überprüft werden. Siehe gesonderter Bericht W. Bosse, W. Held, H.-W. Kisker, Anwendung von Smart-Karten in Betrieben, Hochschulen und Ämtern, Zentrum für Informationsverarbeitung der/Institut für Angewandte Informatik an der Westfälischen Wilhelms-Universität Münster, Entwurf vom 09.08.1999

4 Zertifizierung

4.1 PGP-Zertifikate

Software:
PGP (DOS, auch: Unix, Windows, Macintosh; in Betrieb)
Aussage des Zertifikats:
Schlüssel gehört zur Person
Organisationsform:
WWW of Trust, optional hierarchisch, z. B. DFN

4.2 X.509 - Zertifikate

Zum Beispiel für SSL-Verschlüsselungen und S/MIME-Mail.
Software:
SSLeay (Unix, erprobt)
OpenSSL (Unix, erprobt)

SECUDE (Unix, erprobt)
Aussage des Zertifikats:
Schlüssel gehört zur Person bzw. zum Server bzw. zum Client
Organisationsform:
Zwingend hierarchisch, z. B. DFN

4.3 Signaturgesetz und EU-Richtlinie

Die Auswirkungen des Signaturgesetzes und der entsprechenden EU-Richtlinie für digitale Signaturen und deren Anwendungen sind hier nicht zu erläutern. Die Erlaubnis, entsprechende Zertifizierungen durchzuführen, ist an strengere Auflagen gebunden als bei den zuvor beschriebenen Verfahren. Es ist noch zu klären, wie den Anforderungen bezüglich Software, technischen Komponenten und Organisation entsprochen werden kann und muss, und für welche Anwendungen die Zertifizierung nach dem Signaturgesetz im Tagesgeschäft erforderlich ist. Denkbar ist, in Ausnahmefällen auf eine externe Zertifizierung zurückzugreifen.

5 Zusätzliche Maßnahmen in LANs

5.1 Kontrollierter Zugang zu Netzen

Soll der Zugang zu Netzen nur authentifizierten Nutzern möglich sein, bieten sich folgende Maßnahmen an:

5.2 Broadcast-Medien

Daten passieren in Ethernet-LANs oftmals alle direkt angeschlossenen Endgeräte Abhilfe: Switched-Network, möglichst IP-Switching

Die genannten Maßnahmen (bis auf LAN-Security-Geräte) bieten keinen starken Schutz, da die gängigen LAN-Switche durch Überlastung der Adresstabellen in einen Broadcast-Modus versetzt werden können.

5.3 ELANs und VLANs

ELANs und VLANs erlauben in ATM- bzw. LAN-Netzen die logische Zusammenfassung von physisch verstreut liegenden Netzbereichen (in der Regel über festgelegte LAN-Ports von Switches) und zwar weitgehend unabhängig von der Lage dieser Netzbereiche innerhalb der Gesamttopologie. Dies ist für Durchsatz und Administrierung hilfreich. Es erlaubt im Prinzip, Werden ELANs und VLANs unter dem Gesichtpunkt der Sicherheit eingesetzt, so ist auf eine sorgfältige Konfigurierung der Software zu achten, um unberechtigten Nutzern den Zugang zu einem ELAN/VLAN zu verwehren. Zusätzlich bestehen bei VLANs Zweifel an der Zuverlässigkeit in Überlastsituationen.

5.4 Virtual private network (VPN)

VPNs ermöglichen Datentransfer von Arbeitsplätzen aus über öffentliche unsichere Netze. VPNs können aber auch verwendet werden, um zwei LAN-Segmente sicher zu verbinden. Die Realisierung erfolgt über VPN-Router.

5.5 Sicherung von SNMP und Netzmanagement

Mit dem SNMP werden Netze gemanagt, z. B. Fehler lokalisiert. Über die missbräuchliche Nutzung derartiger Software sind Manipulationen an Rechnern und aktiven LAN-Komponenten möglich. Deshalb sollte kein schreibender Zugriff über SNMP zugelassen werden, da derzeit noch Mehrfachpasswörter im Klartext übertragen werden müssen. Durch Packet-Filter (Firewall) in allen aktiven LAN-Komponenten kann man sicherstellen, dass SNMP missbräuchlich allenfalls noch in einem Netz-Segment hinter der letzten aktiven LAN-Komponente zum Einsatz kommen kann. (u. a. in Münster realisiert). Wenn ein gesicherter Zugriff auf LAN-Komponenten realisiert ist (z. B. mit ssh), sollte dieser Zugangsweg zur Konfiguration verwendet werden. Ein Outband-management (wie z. B. in Dortmund mit einem separaten Terminalnetz) wird nicht überall realisiert werden können, ist aber dringend anzustreben.

5.6 Private Adressräume, NAT

5.7 Firewall-Funktionen

Firewalls sind ein umfassendes Thema, das einer getrennten Behandlung bedarf. Zahlreiche Unterlagen findet man zum Beispiel auf den WWW-Seiten des DFN-CERT. An dieser Stelle sei nur darauf hingewiesen, dass die große Zahl unterschiedlicher Produkte sich prinzipiell auf drei Typen zurückführen lässt:
  1. Packet Screen oder Packet-Filter
  2. Packet Screen mit Bastion
  3. Gateway-Firewall
Die Implementierung von Firewall-Schutzfunktionen in eigenen Geräten ist für die Architektur eines vermittelnden (Schicht-3-)Netzes grundsätzlich mit Skepsis zu betrachten.. Dies betrifft sowohl die Nutzung als auch das Management des Netzes und gilt in besonderem Maße für Applikationsgateways (vgl. auch B. Carpenter, Internet Transparency, Internet Draft Dec. 1999). Auch die Regelung von Zugriffsrechten auf Endsystemen ist naturgemäß eher bei den unter Umständen zahlreichen Systemadministratoren als bei »dem« Netzadministrator anzusiedeln und die Einführung von Applikationsgateways führt häufig zur Auseinandersetzung über die Frage, von wem diese zu administrieren seien, da ein grundsätzlicher Interessenkonflikt besteht. Das Skalierungsverhalten von Applikationsgateways, insbesondere in größeren Netzen, ist ein weiterer kritischer Gesichtspunkt. Vor diesem Hintergrund und angesichts der Schwierigkeiten allgemeiner Regelungen bei der Einführung von »Firewalls« sei auf die bereits schon sehr häufig eingesetzten Firewall-Funktionen in Endsystem (»Personal Firewall«) hingewiesen. Skalierbarkeit ist hier offensichtlich, die Administratorfragestellung ist relativ leicht zu beantworten, die Administration kann mit Einschränkungen relativ leicht spezifisch für die betroffene Nutzergruppe oder sogar dem einzelnen Nutzer »geregelt« werden und die Netzarchitekturproblematik ist nur wenig tangiert. Auch kann das Argument nur mit Einschränkungen gelten, dass die Verwaltung der Endsystemkonfiguration nicht geleistet werden könne und dass deshalb ein »Firewall« eingesetzt werden müsse - auch die Administration von Firewalls ist nicht ohne erheblichen Aufwand zu leisten.

Exemplarisch sei Software genannt, mit welcher Firewall-Funktionen in Endsystemen realisiert werden kann. Diese ist insbesondere bei Unix-Systemen bereits vielfach im Einsatz. Eine weitere Ausarbeitung dieses Themas ist noch erforderlich, wobei auch die bereits systemseitig vorhandenen Konfigurationsmöglichkeiten des Firewalling ausgearbeitet und vor allem erprobt werden müssten.

6 Intrusion Detection

In Netzen und Betriebssystemen sind viele Sicherheitslücken bekannt und gut dokumentiert. Sie können dennoch, weil die Fehler nicht beseitigt werden, immer wieder für Angriffe ausgenutzt werden. Aber auch wenn alle Sicherheitsmaßnahmen eingeführt und alle bekannten Fehler korrigiert worden sind, können neue Softwarefehler, Konfigurationsfehler, Bedienungsfehler usw. weiter zu Sicherheitslücken führen. Deshalb sind Maßnahmen vorzusehen, um diese verbleibenden Lücken möglichst frühzeitig aufzudecken.

Es gibt eine Reihe von Programmen mit deren Hilfe Sicherheitslöcher z. B. in der Konfiguration von Netzkomponenten durch simulierte Angriffe aufgedeckt werden können. SATAN ist ein älteres Programm dieser Art, SAINT ein neueres.

Von »Intrusion Detection« wird dagegen gesprochen, wenn im laufenden Betrieb durch Beobachtungsprogramme nicht nur Einbruchsversuche, sondern auch wahrscheinliche Einbrüche entdeckt werden. Dabei werden z. B. Logfiles ausgewertet und früh mögliche Einbrüche erkannt. Diese Programme können selbstlernend sein oder sie verfahren nach vom Administrator definierten Regeln und überwachen z. B. den Verkehr auf bestimmten Ports, die für besonders gefährdet erachtet werden.

Problematisch sind dabei der Datenschutz und das Einstellen von Schwellwerten zur Ausgrenzung von Fehlalarmen.

Die für Intrusion Detection verfügbaren Software-Produkte sollten, entsprechende Verabredungen mit den Nutzern vorausgesetzt, regelmäßig aktiviert werden.

Tcpwrapper, logdaemon, crack, cops, tiger, iss, nmap und saint sind beispielsweise als Produkte zu nennen.

Report-Mechanismen (z. B. Syslog) sind teilweise im Einsatz; die Vervollständigung dieser Mittel erfolgt, sobald die Zeit das zulässt. Wenn mehrere Server vorhanden sind, sollten die Reports auf einem Server zusammengeführt werden, damit die Überprüfung überhaupt möglich bleibt. Der Aufwand entsteht im Wesentlichen in der Implementierung und im Setzen der Filter.

7 DFN-CERT und BSI

Das DFN CERT und andere CERTs, geben darüber hinaus regelmäßig Hinweise zu Sicherheitsmaßnahmen. Zu den Aufgaben des DFN-Cert gehören insbesondere: Das CERT ist über "cert.dfn.de" zu erreichen (pgp-verschlüsselte E-Mails sind erwünscht.)

Es sei auch auf das Bundesamt für die Sicherheit in der Informationsverarbeitung (BSI) hingewiesen, insbesondere auf dessen umfangreiche Veröffentlichungen zu allen Aspekten der IV-Sicherheit. (Im ZIV in Münster liegen diese Daten vor).

8 Information und Ausbildung

Wohl an allen Hochschulen gibt es hochschulinterne E-Mail-Listen zur Verständigung der Systemadministratoren untereinander als dauerndes Kommunikationsinstrument. Für Systemfragen sollte eine entsprechende landesweite E-Mail-Liste reaktiviert werden. Es wird angeregt, diese Liste um eine entsprechende Liste für Sicherheitsfragen zu ergänzen. Der Nutzen regelmäßiger Treffen wird hervorgehoben, die durch virtuelle Treffen über Videokonferenzsysteme z. T. ersetzt werden können.

9 Anhang

9.1  Auszug aus dem IT-Sicherheitskonzept der Universität Paderborn
9.2  Mitwirkende an diesem Bericht
9.3  Zusammenfassung der Arbeitsergebnisse der von der Senatskommission für das Rechenzentrum (SKR) eingesetzten Arbeitsgruppe »Sicherheit« an der RWTH Aachen

9.1 Auszug aus dem IT-Sicherheitskonzept der Universität Paderborn

Dieser Teil des Anhangs ist uns dankenswerterweise von der Universität Paderborn als »Entwurf: Konzept zur Sicherheit der Informationstechnik an der Universität Paderborn (IT-Sicherheitskonzept), Autoren Prof. Heiss, C. Fries und andere« überlassen worden. Wir haben diesen Entwurf gekürzt und an unsere Bedürfnisse angepasst. Dieser Anhang wendet sich an alle, die für die Sicherheit in einer Einrichtung verantwortlich sind. Das Papier soll Problembewusstsein in den Gremien und bei den Benutzern für die Notwendigkeit von Sicherheitsmaßnahmen erzeugen, und darauf hinweisen, dass solche notwendigerweise Arbeit und Geld kosten. Es wird allgemein als hilfreich empfunden, ein solches fertiges Papier für eine Hochschule zu haben, insbesondere weil darin nicht nur technische Aspekte, sondern auch notwendige organisatorische Maßnahmen aufgeführt sind.

Gefährdung von Objekten und Diensten

Sicherheit bedeutet die Abwesenheit von Gefahr. Gefährdet sind die Integrität und Verfügbarkeit der Hardware, der Software und der Daten sowie die Vertraulichkeit der Daten. Im Blickpunkt stehen daher die IT-Systeme9 (einschließlich der auf ihnen gespeicherten Daten) als durch ihre Umgebung bedrohte Objekte und weniger als Subjekte, die durch Fehlverhalten Schaden verursachen. Die Verfügbarkeit der Systeme ist nur insofern Gegenstand dieses Dokuments, als sie durch Umgebungseinflüsse bedroht ist, z. B. durch sogenannte »denial-of-service-attacks«, die darauf abzielen, den legitimen Benutzern die Nutzung vorzuenthalten. Allgemeine Verfahren zur Erhöhung der Verfügbarkeit (z. B. durch Redundanz) werden nicht behandelt.

Neben den Endgeräten (PCs, Drucker, etc.) basiert die Funktionsfähigkeit der Informationstechnik auf dem Zusammenspiel einer Reihe von Komponenten, deren Existenz sich die Benutzer oft nicht bewusst sind. Als besonders schutzwürdige Objekte und Dienste gelten:

Eine störungsfreie Verfügbarkeit dieser Objekte und Dienste ist nur dann gewährleistet, wenn den möglichen Gefährdungen durch geeignete Maßnahmen vorgebeugt wird. Die physische Sicherheit der Komponenten ist bedroht durch allgemeine Umwelteinflüsse, höhere Gewalt sowie fahrlässiges und böswilliges Verhalten. Neben gerätespezifischen technischen Defekten können Stromausfälle und Überspannungen, Feuer/Wasserschäden, aber auch Beschädigungen des physischen Netzwerks (z. B. bei Bauarbeiten) zum Ausfall von Rechnern, Peripherie, Netzwerkkomponenten und Sicherungsmedien führen. Damit droht der Ausfall des Hochschulnetzes und Datenverlust.

Auch das Bedienpersonal stellt eine Gefährdung dar: Wartungsarbeiten an Hardwarekomponenten, Installation oder Aktualisierung von Software, die ohne sorgfältige Planung und Absprache durchgeführt werden, Fehlbedienung durch Unwissen oder Fahrlässigkeit können zum zeitweiligen Ausfall zentraler Dienste und des Hochschulnetzes führen. Auch das Auslaufen befristeter Lizenzen kann den Ausfall dringend benötigter Dienste zur Folge haben. Ist ein Ausfall eingetreten, so kann mangelnde personelle Redundanz die Behebung des Fehlers erheblich verzögern. So ist häufig das erforderliche Spezialwissen auf ein bis zwei Personen beschränkt.

Darüber hinaus sind die Komponenten in zunehmendem Maße böswilligen Angriffen ausgesetzt. Diebstähle und Vandalismus bedrohen die physische Sicherheit, Hackerangriffe von innen wie von außen die logische Sicherheit. Neben der Funktionstüchtigkeit des Gesamtnetzes ist dabei auch die Integrität und Vertraulichkeit der Benutzerdaten bedroht. Im Vergleich dazu bergen Computerviren ein eher geringes Sicherheitsrisiko, da sie zunächst nur lokal auf einzelnen PCs Schaden anrichten können.

Verantwortlichkeiten und Zuständigkeiten

Um den möglichen Gefährdungen wirksam begegnen zu können, müssen die Verantwortlichkeiten und Zuständigkeiten für alle schutzwürdigen Objekte und Dienste klar definiert und allen Beteiligten bekannt sein. Es muss möglich sein, jede von Rechnern der Universität ausgehende Aktivität einer Person zuzuordnen. Für alle existierenden Rechner und Dienste müssen verantwortliche Personen benannt sein. Zuständige Personen müssen mit entsprechenden Kompetenzen ausgestattet sein, damit sie auch gegebenenfalls erforderliche Maßnahmen ergreifen können.

Physische Sicherheit

Zur Gewährleistung der physischen Sicherheit der schutzwürdigen Objekte und Dienste müssen folgende Grundsätze eingehalten werden:

Datensicherung

Sämtliche auf Rechnern gespeicherten Daten und Programme sind den oben genannten Gefahren ausgesetzt. Diese Gefahren können durch geeignete Maßnahmen reduziert, aber nicht völlig verhindert werden. Die einzige wirksame Maßnahme gegen den Verlust von Daten besteht im Anlegen von Sicherheitskopien. Die Sicherungsmedien müssen sicher vor Vandalismus, Diebstahl, Feuer, Wasser aufbewahrt werden, am besten in speziellen Räumen auch in einem anderen Gebäude. Mit der Durchführung aller mit »Backup und Restore« verbundenen Aufgaben sollten zwei Personen vertraut (betraut) sein.

Bei Systemen mit lokaler Datenhaltung (z. B. PC unter Windows 95) ist die regelmäßige Datensicherung Aufgabe des jeweiligen Besitzers/Benutzers. Es wird dringend empfohlen, aktuelle lokale Datenbestände regelmäßig zu sichern. Bei vernetzten Systemen mit zentralisierter Datenhaltung (Fileserver) sollte eine Datensicherung automatisch durchgeführt werden. Durch geeignete Maßnahmen (Datensicherungsordnung als Teil der Nutzungsordnung, als Aushang, durch Hinweis beim Einloggen etc.) muss klargestellt sein,

  1. ob die Datensicherung nur Systemprogramme und bestimmte Server-Directories berücksichtigt, oder auch die Programme und Dokumente des Anwenders auf der Workstation,
  2. um welche Uhrzeit die Datensicherung erfolgt,
  3. wie der IT-Anwender seine Programme und Dokumente gegebenenfalls selbst sichern kann und
  4. wer im Problemfall anzusprechen ist (Name, Telefon, Raum, E-Mail).
Im ZIV erfolgt die Datensicherung täglich inkrementell.

Netze

Neue Formen des Wissenschaftsbetriebs über Hochschulen und Ländergrenzen hinweg, der schnelle Zugriff und Austausch von Informationen und die gegenseitige Nutzung von DV-Ressourcen sind erst durch Vernetzung von Computern möglich geworden. Ohne das lokale Hochschulnetz und das Internet ist Forschung, Lehre und Verwaltung heute nicht mehr denkbar. Aus diesem Grund besteht ein gemeinsames Interesse aller Mitglieder der Hochschule in der Stabilität und dem ordnungsgemäßen Funktionieren des lokalen Netzes, der benötigten Netzwerkdienste und dem Übergang vom lokalen Netz in das Internet. Allen Gefährdungen, die die Stabilität oder die Funktion des Netzwerkes beeinträchtigen können, ist daher entgegen zu wirken. Die Sicherheitsaspekte und Maßnahmen sind dabei aber stets auch vor dem Grundsatz der größtmöglichen Offenheit des Hochschulnetzes zu sehen. Dabei ist zu beachten, dass erhöhte Sicherheitsmaßnahmen kurzfristig immer Mehrarbeit für die Systemadministration, eine Umstellung der gewohnten Anwendungen für die Benutzerinnen und Benutzer und eventuell eine Beeinträchtigung der Performance und der Offenheit des Netzes bedeuten.

Beim Netzwerk und seinen Diensten müssen Eingriffe in das Hochschulnetz auf den folgenden drei Ebenen unterschieden werden

9.2 Mitwirkende an diesem Bericht

Herren
Niggemann Bundesamt für die Sicherheit in der Informationsverarbeitung, Köln Peters DFN-CERT, Hamburg
Wenzel, Schippang und Sternberger, Fernuniversität Hagen
Dieter, Fries, Universität Paderborn
Schoening, Deutsche Sporthochschule Köln
Rapp, Ziegler, Universität Dortmund
Huth, Nastoll und Schilling, Universität Essen
Münch und Hofmann, Universität Siegen
Gros, Grun, Universität Paderborn
Brett, Ministerium SWWF, Düsseldorf
Kalle, Universität Köln
Krieger, Rudolph, Zoller, Hackenberg, Wojcieszynski und Frau Brigitte Wojcieszynski, Ruhr-Ruhr-Universität Bochum
Herren
Franck und Hektor, RWTH Aachen
Hilpert und Schneider, Universität Wuppertal
Koeller, Universität Bielefeld
Elsner und Corsten, Universität Bonn
Lannert, Universität Düsseldorf
Stermann, Universität Duisburg
Held, Perske und Richter, Universität Münster

9.3 Zusammenfassung der Arbeitsergebnisse der von der Senatskommission für das Rechenzentrum (SKR) eingesetzten Arbeitsgruppe »Sicherheit« an der RWTH Aachen

In ihrer Sitzung am 2. Nov. 98 beschloß die SKR den Einsatz einer Arbeitsgruppe »Sicherheit«, bestehend aus folgenden Herren:
Herr Bolten (Vertreter der Studierenden),
Prof. Epple (Prozessleittechnik, für die Professoren),
Dr. Kahlert (Theoretische Physik D, für die wissenschaftlichen Mitarbeiter),
Herr Thevis (Informatik, für die nicht-wissensch. Mitarbeitenden) und
Herr Franck (Rechenzentrum, Koordination).
Als Ergebnis ihrer Erörterungen und Diskussionen gibt die einberufene Gruppe die nachstehenden Empfehlungen, über die generelle Einstimmigkeit herrschte bzw. erzielt werden konnte, an die SKR weiter.

Die zunehmenden Einbrüche in Rechnernetze und Rechensysteme der RWTH Aachen signalisieren dringenden Handlungsbedarf.

Im Vordergrund stehen dabei nicht (mehr) die Investitionsschäden bei den kompromittierten Systemen. Immer häufiger werden diese anschließend unter Ausnutzung von Sicherheitslücken in Form von bekannt gewordenen Unzulänglichkeiten der Betriebssysteme und Anwendungen derart umfunktioniert, dass sie als fern- und fremdgesteuerte Roboter sicherheitsbedrohende Informationen ausspionieren und/oder ihrerseits dann als Angriffswerkzeug auf (weitere) RWTH-eigene oder fremde Maschinen dienen, mit dem Ziel, auch diese zu kompromittieren usw.

Das Rechenzentrum als zentrale Einrichtung der Hochschule ist dann der Ansprechpartner für Geschädigte innerhalb und außerhalb der RWTH Aachen. Der vermeintliche Verursacher ist häufig genug selber zuvor Opfer eines erfolgreichen Angriffs geworden. Durch Attacken, die von Rechnern aus der RWTH her erfolgen, wird zudem das Image der RWTH Aachen beschädigt.

(1) Sensibilisierung des Sicherheitsbewusstseins

Es ist unumgänglich, auf allen denkbaren Ebenen das Sicherheitsbewusstsein der Verantwortlichen, der Systemadministratoren und der Endbenutzer zu sensibilisieren und zu schärfen.

Auf einer eigenen Web-Seite des Rechenzentrums (www.rwth-aachen.de/security) sind sicherheitsrelevante und die Sicherheit verbessernde Informationen systemübergreifend für alle Betroffenen im Aufbau oder bereits abrufbar. Empfehlungen für Systeminstallationen und -konfigurationen sowie Beschreibungen der aktuellen Angriffsmethoden und Hinweise auf sicherheitsrelevante »Patches« werden dort laufend aktualisiert.

Für den Endbenutzer wird an anderer Stelle (www.rwth-aachen.de/ca) beschrieben, wie auf Anwenderebene Daten (insb. elektronische Post) mittels Verschlüsselungstechniken geschützt und ihre Integrität erhöht bzw. überprüft werden kann.

In Vorträgen sind und werden verschiedene Sicherheitsaspekte dargelegt, entsprechende Kurse und/oder Workshops befinden sich in Planung.

An die Leitungen der Institute, Lehrstühle und der Hochschule angegliederten Einrichtungen, an alle in den Ausführungsbestimmungen zur Netzordnung genannten Gruppen und Ebenen muss appelliert werden, die Auswahl und die Verantwortung der Systemadministratoren stärker unter sicherheitspolitischen Aspekten zu sehen. Die Betreiber eigener LANs/Domänen haben seinerzeit ein bis zwei »Netz(werk)verantwortliche« inkl. deren Telefonnummern und e-mail-Adressen benannt, die bei Problemen als Ansprechpartner gegenüber dem Rechenzentrum fungieren sollen.

Bei dem Versuch, diese nach Einbrüchen anzusprechen und um Hilfe bei der Aufklärung zu bitten, vergeht häufig unnötig viel Zeit, weil durch Fluktuationen von Menschen und Maschinen entweder diese Personen im Institut nicht mehr tätig sind oder die e-mail-Adressen ins Leere gehen. Manchmal ist auch nach mehrfachen telefonischen Rückfragen kein kompetenter Ansprechpartner ausfindig zu machen, was die Aufklärungsarbeit nahezu unmöglich macht und bei Geschädigten insb. außerhalb der RWTH ein desolates Bild einer Technischen Hochschule hinterlässt.

Die Netzverantwortlichen müssen auf die notwendigen sicherheitspolitischen Funktionen ausdrücklich hingewiesen werden; eine laufende (kontrollierte) Aktualisierung der Namens- und Telefonliste und der Erreichbarkeit durch elektronische Post ist vordringlich.

(2) Zentrale Firewall

Die Unterkommission empfiehlt dringend den Aufbau und Betrieb eines zentralen Firewall-Systems für die länger diskutierten, nachfolgenden Aufgabenbereiche:

Dieses System soll die Funktion eines »Frühwarnsystems« erfüllen und erkannte Angriffsmuster abwehren. Es dient in erster Linie aber auch der Protokollierung - im Rahmen des gesetzlich Erlaubten - von als verdächtig eingestuften Aktivitäten, die noch der Analyse bedürfen. Wird ein Angriffsmuster erkannt, wird es iterativ in die Abwehrstrategie eingebunden, im anderen Falle die Protokollierung solcher Aktivitäten zukünftig ausgeklammert. Umgekehrt muss evt. ein erfolgreicher Einbruch die Überprüfung bzw. Erweiterung der Protokollierung ähnlicher Aktivitäten nach sich ziehen, solange die Methode des Angriffs unklar bleibt.

Keineswegs soll dieser zentralen Firewall jedoch eine Abschottungsfunktion zufallen, da die Dienste des Rechenzentrums uneingeschränkt allen Instituten zur Verfügung stehen müssen. In diesem Sinne ist es kein klassisches Firewallsystem für all die im Netz der RWTH eingebundenen Rechner. Diese Aufgabe wäre auch nicht realisierbar. Zur Absicherung institutseigener LANs wird unter dem nächsten Punkt Stellung bezogen

Bei der Dimensionierung der zentralen Maschine ist ihre einfache Skalierbarkeit hervorzuheben, um so bei ständig steigendem Bedarf an Netzkapazität mindestens die Geschwindigkeit der aktuellen B-WiN-Bandbreite durchzusetzen und nicht umgekehrt als Bremse zu wirken.

Die zugehörige Aufgaben zur Konzeptionierung, zum Aufbau und laufenden Betrieb der Maschine, zur Justierung von alarmauslösenden Funktion, Analyse von Protokollen und Angriffsmethoden sind mit dem aktuellen Personalstand des Rechenzentrum nicht zu bewältigen. Hier entsteht zusätzlicher Bedarf.

(3) Prototyp einer Firewall für LANs

Wie oben ausgeführt, kann die Abschottungsfunktion einer Firewall für kleine, in sich homogene LANs, z. B. vernetzte Abteilungsrechner in den Einrichtungen der Hochschule in Frage kommen. Die Arbeitsgruppe stellt sich vor, dass das Rechenzentrum eine Empfehlung für ein preiswertes PC-System als Prototyp einer Instituts-Firewall - evt. auf der Basis des Betriebssystems LINUX - erarbeitet, den Kern des Betriebssystem nach den neuesten sicherheitsrelevanten Erkenntnissen pflegt und für ein Ethernet-basiertes Netzwerk mit derzeit (in der Regel) noch 10Mb/s, max. 100Mb/s vorkonfektioniert.

Die Anpassung der Netztopologie sowie mögliche Betriebssystem-Updates könnten dann etwa durch einen Systemadministrator in der jeweiligen Einrichtung vollzogen werden, in Ermangelung eines solchen evt. auch durch das Rechenzentrum. Im letzten Falle wäre auch eine Abrechnung/Vergütung nach Aufwand zur Deckung der Personalkosten denkbar.

(4) Prüfung der Einbruchsicherheit (»friendly attack«)

Die Arbeitsgruppe ist sich im Klaren darüber, dass die vorgeschlagenen Maßnahmen niemals einen hundertprozentigen Schutz vor Einbrüchen bieten, sondern nur die Sicherheit vor einem Einbruch ein Stück erhöhen können. Dies mag u. a. der Grund für den Wunsch einzelner Institute sein, die Güte der Einbruchsicherheit Ihrer Rechnersysteme und Rechnernetze beurteilen zu können oder zu wollen.

Dazu hat das Rechenzentrum in der letzten Sitzung der SKR im November des vergangenen Jahres als neuen Dienst die Prüfung der Einbruchsicherheit von Abteilungsrechnern in Aussicht gestellt, im Fachjargon auch »friendly attack« genannt.

Auf ausdrückliche Anordnung würde das Rechenzentrum die Rolle des »freundlichen Attackierers« übernehmen und versuchen, sich Zugang zu den betroffenen Institutsrechnern zu verschaffen, indem es z. B. Sicherheitslücken, Unzulänglichkeit in Implementierungen und Konfigurationen aufspürt. Diese sollten dann der auftraggebenden Leitung der Hochschuleinrichtung offen dargelegt werden mit dem Ziele der anschließenden Beseitigung.

Wir regen an, an das Rektorat heranzutreten mit der Bitte, (juristisch) zu prüfen, ob sich dies in Einklang mit der bestehenden Netzordnung und den zugehörigen Ausführungsbestimmungen durchführen lässt. Sollte dies verneint werden müssen, erscheint eine Anpassung der Ausführungsbestimmungen durch das Rektorat der gangbarste und schnellste Weg.

(5) Aufbau einer Beratung

Ein wesentlicher Grunddienst des Rechenzentrum ist seit eh und je die Beratung gewesen.

Diese Notwendigkeit hat insbesondere auch in Sicherheitsfragen ihre Gültigkeit. Durch eine gute und kompetente Beratung kann im Vorfeld späterer Schaden vermieden werden.

Der Gesamtkomplex der Sicherheit in der elektronischen Kommunikation ist in beratender Form abzudecken, z. B. der sinnvolle Einsatz von Verschlüsselungstechniken, ihre Integration in bestehende (Alltags-) Anwendungen, Hilfestellungen zur Erhöhung der Sicherheit für die gängigsten Betriebssystemplattformen, schnelle und nachvollziehbare Reaktionen auf alle sicherheitsrelevanten Fragestellungen. Auch hier wird zusätzlicher Personalbedarf gesehen.

Auch ist zukünftig gerade im Sicherheitsbereich noch sehr viel Neuland zu beschreiten, als Beispiel sei an dieser Stelle nur kurz auf sichere Protokolle und deren großflächige Integration in bestehende Netzstrukturen hingewiesen.

Die oben ausgeführten fünf Punkte werden von der eingesetzten Arbeitsgruppe als die zzt. wesentlichsten angesehen. Sie sollten auch nicht nacheinander, sondern möglichst parallel angegangen werden, um den Sicherheitsgrad ein gutes Stück und so schnell wie möglich anzuheben und zu verbessern.

Aachen, den 02.02.99

10 Literatur

11 Anmerkungen

1 IV-Gesamtsystem = Menge aller IV-Geräte, IV-Netze, Software und Personen zur Betreuung.
2 Mit heterogenen System-Umgebungen sind Rechner sehr unterschiedlicher Hersteller, Betriebssys-teme und Anwendungen gemeint. Manchmal sind die Netze aus aktiven Komponenten verschiedener Hersteller zusammen geschaltet.
3 Das Problem der sicheren Verschlüsselung von Daten, die für mehrere Angehörige einer Einrichtung verfügbar sein müssen, ist unter dem Schlagwort Enterprise Key Recovery bekannt (siehe dazu z. B. den Artikel von Pohl, Cerny "Enterprise Key Recovery", Informatik Spektrum 4/99, S. 110-121).
4 An verschiedenen Produkten ist vermerkt, ob sie im Zentrum für Informationsverarbeitung (ZIV) vorhanden oder im Einsatz sind. Dies ist für Nachfrager u. U. hilfreich, weil sie erkennen können, welche Erfahrungen vorliegen.
5 Die Ziffern der Gefahren beziehen sich im Folgenden immer auf die im Abschnitt 1.1 genannten 4 verschiedenen Gefährdungen.
6 Bemerkungen zu Secure Sockets Layer (SSL) 
  1. Von Netscape eingeführt für sicheren Informations-Austausch im Internet
  2. SSL ist derzeit in einer Reihe von Anwendungen (einige E-Mail-Systeme und Netnews, WWW) eingebaut; ohne Einbau von SSL in die Produkte hat man wenig Chancen SSL zu nutzen.
  3. Verschlüsselung transparent für Nutzer, End-to-End-Verschlüsselung
  4. Kein Tunneling, Geschwindigkeit akzeptabel, durch Gateways ist eine Umsetzung zwischen SSL-geschützten und -ungeschützten Verbindungen möglich.
  5. Verschlüsselung oberhalb der Transportschicht
  6. SSL ist neuerdings unter dem Namen Transport Layer Security (TLS) standardisiert. Die mögliche Alternative S-HTTP hat sich als Ersatz von HTTP nicht durchgesetzt.
  7. Transfer zwischen Servern verschiedener Betriebssysteme funktioniert in der Regel auch, wenn SSL auf beiden im Einsatz ist.
  8. SSL unterstützt UDP nicht, SSL setzt auf TCP-Socket auf.
7 (-) bedeutet, dass keine eigene Erfahrung vorliegt.
8 Secure Shell (SSH) dient der verschlüsselten Unix/Unix-Kommunikation und ist ein Ersatz für Telnet. SSH wird auch zum sicheren File Transfer und X11-Verkehr genutzt. Schließlich ist SSH für die Unix-Server/PC-Kommunikation einsetzbar. Sobald vielfältigere Funktionalität benötigt wird, ist u.U. ein kommerzielles SSH-Produkt nötig.
9 IT und IV werden synonym verwendet.
10 USV = Unterbrechungsfreie Stromversorgung

Zentrum für Informationsverarbeitung (Universitätsrechenzentrum) / ziv@uni-muenster.de05.06.2001 / Dr. W. Held / Zum Impressum