Inhalt

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

1.1 Gefährdungspotential

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).

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

• Integrität der Datenübermittlung
• Rechtsverbindlichkeit elektronischer Vorgänge bei Bedarf (digitale Signatur, Zeitstempel)
• Vertraulichkeit bei der Datenübermittlung (confidentiality, user privacy)
• Zweiseitige Authentisierung der Partner (authentication), auch der Server
• Nichtanfechtbarkeit einer Transaktion (non-repudiation)
• Zugangsregelung zu Teilen einer Anwendung; zentrale Zugangskontrolle über alle Applikationen eines Unternehmens (zentraler Berechtigungsserver und single-sign-on)
• Kontrolle des eingesetzten Authentisierungsmediums gegen Missbrauch, Verlust (Schwarze Liste, Widerruf) und Vergesslichkeit
• Zeitkontrolle bestehender Client-/Serververbindungen auf Inaktivität, insbesondere bei multifunktionaler Nutzung von Endgeräten (time-out Überwachung)
• Verfügbarkeit von Zusatzdiensten, wie z. B.
1. Abwicklung von Zahlungsverkehr über das Internet
2. Zertifizierung, d. h. Verwaltung und Distribution der geheimen und öffentlichen Schlüssel für Signaturen und Verschlüsselung (Schlüssel-Management)

Zur Abwehr der Gefahren sind besonders in heterogenen System-Umgebungen²leider 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 4³. 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

2.1 E-Mail, NetNews, WWW und FTP

2.1.1 E-Mail und NetNews

• Zu sichern sind der Transport von Informationen/Nachrichten/Daten und der Abruf einer zuzustellenden Nachricht.
• Gefährdet sind das Passwort beim Senden und beim Empfangen sowie die Informationen/Nachrichten/Daten selbst.

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 Betrieb⁴.)

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, 3⁵

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

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

• Bei der Verschlüsselung von Daten müssen auch die Directories verschlüsselt sein, um z. B. Datenlöschungen zu vermeiden. Daten und Directories werden z. B. bei Windows 2000 verschlüsselt.
• Von großer Bedeutung ist die Länge der Schlüssel: 40-Bit-Schlüssel halten professionellen Entschlüsselungsversuchen nur Minuten stand, 128-Bit-Schlüssel sind so gut wie nicht und 512-Bit-Schlüssel derzeit gar nicht zu knacken (gilt für alle SSL- und sonstigen Verschlüsselungen).

Methode POP3: Einsatz von SSL⁶

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

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 (-)⁷

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

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

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

Drucker

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.

• keine fremden Programme startet, die Viren enthalten könnten,

• keine Makros sowie keine HTML-Seiten mit aktiven Inhalten (Java, ActiveX, Java-Script) zulässt,

2.2 Typische Unix-Anwendungen

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

Software:

     Clients:

ssh⁸ 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

Abhilfe:

TCP-Wrapper oder xinetd.

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

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

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

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

• Die gegenseitige Abhängigkeit von Servern sollte minimiert werden, damit nicht im Falle der Kompromittierung eines Servers andere Server in Mitleidenschaft gezogen werden.
• Server sind grundsätzlich im abhörsicheren Backbone aufzustellen. In diesem Backbone sollen gleichzeitig keine Endgeräte direkt angeschlossen werden.
• Für alle Server müssen die Administratoren/Betreuer bekannt sein. Sie müssen ihre Pflichten und Verantwortungen kennen.
• Server müssen regelmäßig gewartet und auf den neuesten Softwarestand gebracht werden, dies verhindert bereits den größten Teil der Einbrüche in diese Systeme. Durch zentralen Abschluss von Campus-Software-Verträgen können auch Institute bei der Wartung ihrer System unterstützt werden. (Revisionsverwaltung)
• E-Mail-Server dürfen nicht anonym eingerichtet und betrieben werden. Zustellung und Absendung von E-Mail von/nach außerhalb sollte nur entsprechend registrierten Servern ermöglicht werden, um das Spam-Risiko zu vermindern. Entsprechende Einstellungen können über Router oder Switches erfolgen.
• Wenn der Radius-Server (Einwahl-Server) sicher erreicht wird (Abhören allenfalls durch Netz-Provider oder bei Missbrauch über Gemeinschafts-PC), werden die übrigen Server des ZIV auch sicher erreicht. Der Einwahlvorgang kann durch Verwendung von z.B. CHAP bei Radius-Servern (Einwahl-Server) gesichert konfiguriert werden. Der Zugang zum Radius-Server vom häuslichen Arbeitsplatz aus sollte zumindest dann über den Einsatz von Smart-Karten abgesichert sein, wenn die entsprechenden Rechner von mehreren genutzt werden (z. B. Wohnheim-Wohnung).
• Die Verwendung von Shadow-Passwort-Dateien vermindert die Gefahr, dass Passwörter von internen Benutzern durch Crack-Programme ausgespäht werden.
• Server müssen regelmäßig gewartet und auf den neuesten Software-Stand gebracht werden.
• Server sind so zu konfigurieren, dass "Software mit Rootrechten" nicht missbraucht werden kann. Daher sind DFS- und NFS-Clients so einzustellen, dass setuid- und setgid-Bits sowie Device-Dateien ignoriert werden.
• Die Datenintegrität (Missbrauch durch Trojanische Pferde) kann durch TripWire gesichert werden (kryptografische Checksumme über die Daten). (Einsatz geplant).
• In Zukunft sollte man LDAP-Server ebenfalls mit SSL-Verschlüsselung nutzen.
• Terminal-Server: Clients haben sicheren Zugang zum Terminal-Server. Der Zugang zu anderen NT-Servern ist gesichert. Der Zugang zu Unix-Servern kann in Abhängigkeit von den Möglichkeiten der Unix-Server gesichert werden.
• NT-Server (und NT-Workstations)

2.3.3 Windows-Terminalserver (Microsoft)

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

• Sicheres Login für Server und für eingetragene, mit Kerberos ausgestattete Clients.
• Teilweise gibt es Kerberos-fähige Anwendungen (E-Mail, NetNews, teilweise Filetransfer).
• Kerberos überprüft Server und Clients.
• Kerberos sollte als Angebot einer Einrichtung vorgehalten werden.
• Kerberos-Server kann sowohl auf Windows NT als auch auf Unix-Servern installiert werden.
• Für Zugang zu Kerberos-Server sollte man wieder Secure Shell (ssh) verwenden.
• Kerberos-Server sind, da sie als Konzentratoren der Sicherungsmethoden gefährdet sind, besonders sicher aufzustellen. Oft muss man mehrere Kerberos-Server betreiben. Durch regelmäßige, automatische Überprüfung muss gewährleistet werden, dass jeder mögliche Diebstahl eines Gerätes schnell festgestellt wird.
• Die Anbindung von Smart-Karten an Kerberos bleibt notwendig.
• Microsoft hält Kerberos für flexibler und effizienter als die bisher in Windows eingeführten Sicherungsmechanismen, weil Verbindungen schneller erreicht werden, weil die wechselseitige Authentifizierung flexibler ist, die Delegation von Authentifizierungen flexibler ist usw. Microsoft wird deshalb Kerberos in NT Version 5 implementieren. Allerdings ist auf die Kompatibilität mit Unix-Kerberos zu achten.

2.5 Sonstiges

3 Login und Smart-Karte

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.

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

• Eingerichtet ist im ZIV eine WWU-Zertifizierungsstelle (CA) für die Zertifizierung öffentlicher Schlüssel, die für den Anwender einfach zu erreichen ist. Es gibt eine Zertifizierung für PGP, eine weitere nach dem Standard X.509 wird gerade eingerichtet. Es ist geplant, beide in die Zertifizierungshierarchie des DFN einzubinden. Diese Zertifizierungen unterliegen besonders vertrauensvollen Randbedingungen, die nicht beliebig verteilt werden können.
• Daneben ist die Zertifizierung von Software, die Sicherheitsfunktionen erfüllen soll, besonders wichtig. Kein Diensteanbieter und kein Nutzer kann es sich derzeit allerdings leisten, nur zertifizierte Software einzusetzen, sofern er sie überhaupt erhält. Deshalb ist der öffentliche (kostenlose) Zugang zu Trust-Centern als Verteiler geprüfter Software für Clients und Sicherheitseinrichtungen für die IV-Anwender sehr wichtig für die Nutzerakzeptanz.
• Für besonders hohe Sicherheitsanforderungen, insbesondere für rechtsverbindliche Geschäftsvorgänge im Sinne des Signaturgesetzes, sind besonders strenge Maßnahmen zu ergreifen, die nur mit Hardwareeinrichtungen auf Client/Nutzerseite zu erfüllen sein werden.
• Der Nutzen von Zertifikaten erhöht sich mit der Nutzerzahl. Es sind deshalb landes- oder bundesweite Lösungen anzustreben. Dies gilt insbesondere bei der Zertifizierung von Schlüsseln auf Basis von Smartkarten.
• Es wird angestrebt Zertifikate des DFN und der Universitäten in gängige Web-Browser zu integrieren.

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

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

5 Zusätzliche Maßnahmen in LANs

5.1 Kontrollierter Zugang zu Netzen

• PPP over Ethernet, L2TP, PPTP
• Log-and-key-Verfahren (Telnet Verbindung zum Router, Accountprüfung über Radius, Freischaltung einer IP-Adresse; praktiziert in Bochum)

5.2 Broadcast-Medien

• Es besteht daher die Gefahr abgehört zu werden. Drei Möglichkeiten der Abhilfe bieten sich an:
1. Anschluss der Endgeräte an LAN-Security-fähige Geräte (Ausblenden der Daten für Nicht-Ziel-MAC-Adressen, Zulassung von Endgeräten nur an festgelegten physischen Anschlüssen)
2. Anschluss der Endgeräte an switched Ports (Switched Network)
3. Server grundsätzlich im abhörsicheren Backbone (Backbone ohne Endgeräteanschlüsse) aufstellen.
• Es besteht weiter die Gefahr der illegalen Geräteidentifizierung auf Link- und/oder Vermittlungsebene. Damit ergeben sich Missbrauchsmöglichkeiten z. B. durch Trojanische Pferde oder Datenfälschung

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

• Netzbereiche mit einheitlichen Sicherheitsregeln zu bilden,
• topologieunabhängige Sicherheitsfunktionen beim Übergang in andere Netzbereiche (Firewall-Funktionen) zu implementieren und
• Firewalls skalierbar in verschiedenen Sicherheitsstufen einzuführen.

5.4 Virtual private network (VPN)

• Vom Endnutzer zum VPN-Router muss ein sicherer Datentransfer gewährleistet sein (ssh, SunScreen Skip, ...).
• Die Authentifizierung kann relativ sicher gestaltet werden, z. B. durch public-key-Verfahren.
• Jeglicher Datenverkehr im VPN wird verschlüsselt. Die Verschlüsselung wird auch zwischen Routern durchgeführt, dadurch ergibt sich eine End-to-End-Verschlüsselung. Die Verschlüsselung ist für Nutzer transparent.
• Die Verschlüsselung erfolgt auf relativ niedriger Ebene (ISO OSI-Schicht 2 oder 3).
• Das Verschlüsselungsverfahren soll abhängig von der Anwendung so gewählt werden, dass keine nennenswerte Reduzierung der Transferrate erfolgt.
• Die Verfahren basieren auf IPSEC (= layer-3-Protokolle) oder layer-2-tunneling-Protokoll (Ebene 2).
• VPN mit layer 2 tunneling erlaubt Nutzer-Authentifizierung (IPSEC erlaubt oftmals nur Maschinen-Authentifizierung). IPSEC kann zur Lösung dieses Nachteils mit layer 2 Protokoll kombiniert werden.
• Layer 2 tunneling (zusammen mit Extensible Authentification Protocol kann vielfältige Authentifizierungsmethoden unterstützen (z. B. Einzel-Passwort, Smart-Karte, ...).
• Realisierung in oder neben einer Firewall
• VPN wird durch S/WAN (Secure Wide Area Network) gefördert.
• IPSEC gibt es für IPv4 und später für IPv6.
• Leider ist bisher kein standardisierter Schlüsseltausch festgelegt worden.
• VPN wird als Sicherheitsmaßnahme empfohlen, vor allem bei der Verbindung sicherer Subnetze über ansonsten unsichere Verbindungen.
• Das Verfahren ppp over ethernet ist noch genauer zu untersuchen.

5.5 Sicherung von SNMP und Netzmanagement

5.6 Private Adressräume, NAT

• Grundsätzlich muss die direkte Konnektivität mit anderen Internet-Bereichen durch Verwendung von reservierten Adressen (private Adressräume) ausgeschlossen werden, solange keine Netzadress-Translation (NAT) eingesetzt wird.
• NAT verbirgt Endgeräte eines IP-Adressraumes hinter einer einzigen IP-Adresse. Dies ist kombinierbar mit Firewall-Funktionen. Dadurch ergibt sich einerseits eine restriktive Zugangskontrollmöglichkeit, andererseits ist dies jedoch mit grundsätzlichen und erheblichen Einschränkungen der Netzfunktionalität verbunden.
• Private Adressräume sind generell nicht empfehlenswert, da sie das Netz intransparent machen.
• NAT ist kein Security-Verfahren.

5.7 Firewall-Funktionen

1. Packet Screen oder Packet-Filter
2. Packet Screen mit Bastion
3. Gateway-Firewall

• Viele der am Markt verfügbaren Firewalls sind eher für Anschlussgeschwindigkeiten bis 10 Mbit/s ausgelegt. Bei komplizierten Regelwerken, die zur Sicherheitsprüfung eingerichtet werden, kann sich eine Firewall zu einem »Flaschenhals« in der Kommunikation entwickeln, der dann von den Nutzern in der Regel nicht akzeptiert wird. Daher ist bei der Auswahl der Firewall der erforderliche Durchsatz zu berücksichtigen.
• Erlaubte Funktionen werden auf der Basis von Sicherheitsregeln festgelegt, welche die Kommunikationsmöglichkeiten im Grundsatz zwischen allen Endgeräten (oder Endgerätebereichen) spezifizieren. Die erste Möglichkeit ergibt sich durch eine Packet-Firewall mit Funktionen im Transportsystem.
1. Implementierung in Routern, Switches (einheitlich administriert)
2. Implementierung in Endgeräten (dezentral administriert)
• Erweiterte Funktionen auf der Basis von nutzerbezogenen Zugangsregeln (Funktionen im Anwendungssystem-Gateway) . Man unterscheidet daher grundsätzlich zwischen einfacher Firewall (Packet-Filter, statisch oder dynamisch ) und der Applikationfirewall.
1. Implementierung in speziellen Firewall-Rechnern, Skalierbarkeit ist zu beachten.
2. Bei Einsatz von Packet-Firewalls im Netz (bzw. bei allgemein netztechnischer Konnektivitätssteuerung) kombiniert mit einer nutzerbezogenen Endsystemadministration ist die gewünschte Funktionalität in der Regel auch erreichbar.
3. Bei Firewall-Rechnern muss eine Einschränkung allgemeiner Netzfunktionen hingenommen werden (z. B. IPSEC nicht möglich ohne spezielle Durchleitungsmechanismen, Multicast-IP fraglich).
• Da in vielen Fällen der Zugriff zu Daten auch von außerhalb einer Firewall notwendig bleibt, ist die Verschlüsselung der sichere Weg, der eine hohe Funktionalität beibehält (VPN, 5.3).
• Die Administrierbarkeit einer Firewall ist besonders wichtig. Andernfalls wird der Schutz nicht erreicht. Der Personalaufwand kann, wenn die Sicherungsregeln vielfältig sind und sich laufend ändern, sehr groß werden. Von den zu schützenden Instituten fehlen oft die nötigen Informationen.
• Grundsätzlich macht eine Firewall viel zusätzliche Arbeit und schränkt den Bewegungsraum im Netz ein. Außerdem darf der Aufwand für die Analyse des Firewall-Logs nicht unterschätzt werden. Es gilt wieder die Nutzen/Aufwand-Relation.
• Hersteller: Checkpoint (Software: Firewall-1, weitaus die meisten Installationen, z. B. in ????? installiert), SunScreen (z. B. in Hagen installiert), Secure Computing, Axent, Network Associates, Watchguard (Hardware Firebox II),...
• Alternativ sind Router mit Paketfilterregeln oder Linux-Packetfilter mit geeigneter Konfigurationssoftware (z. B. FCT) einsetzbar. Sie sind leicht administrierbar und preiswert verfügbar.
• Die Sicherheits-Politik muss vor Einführung einer Firewall feststehen. Erforderlich ist ein dynamisches Regelwerk, das ständig anpassbar sein muss. Es ist eine starke Hand notwendig, um nach der Einführung einer Firewall die Regeln auf Wunsch Einzelner nicht dauernd ändern zu müssen und damit die Sicherheit zu gefährden.
• Mittels demilitarisierter Zonen (DMZ) können Server so aufgestellt werden, dass die Sicherheitsregeln und damit die Administration von Firewalls vereinfacht werden.
• Ab einer bestimmten Netzgröße kann es erforderlich werden, die Granularität der Packetfilter zu verfeinern, also interne Bereiche mit weiteren Packetfiltern weiter zu segmentieren. Ziel hierbei ist es, Angriffe von »innen«, die erfahrungsgemäß 80% aller Angriffe ausmachen, auf ein reduziertes Inneres zu beschränken und damit den Schaden einzugrenzen.
• Unabhängig von einem Firewall-Einsatz bleibt es unverzichtbar, die Sicherheit der Endsysteme durch geeignete Maßnahmen (s. 2.4) sicherzustellen.

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.

• Unix: inetd, TCP-Wrapper, xinetd
• Microsoft: ZoneAlarm, ConSeal PC Firewall, McAfee Personal Firewall, Secure Desktop (SyShield), Norton Internet Security 2000 (@Guard,), BlackICE Defender, LockDown., eSafe, NetWatcher 2000 (alle Nennungen ohne jegliche Wertung!)

6 Intrusion Detection

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

• Sammeln von Vorfällen,
• Organisieren von Workshops,
• Organisieren eines response-teams,
• Pflege von E-Mail-Listen für verschiedene Probleme,
• Hilfestellung bei sicherheitsrelevanten Fällen.

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

9 Anhang

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

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-Systeme⁹ (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:

• Netzwerkkomponenten (Hochschulnetz)
• Spezialserver (z. B. Namens- und Adressumsetzung, Lizenzen, etc.)
• Remote Access Router (Modem-Zugang)
• WiN-Zugang (Außenanbindung an DFN-Wissenschaftsnetz, Internet)
• Server zur Speicherung von Benutzerdaten und Programmen (Fileserver)
• Internet-Dienste und die dazugehörigen Server (WWW, E-mail, FTP)

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.

• Die grundsätzliche Autorität und Verantwortung für den Betrieb der vernetzten IT-Systeme liegt beim Leiter des Zentrums für Informationsverarbeitung.
• Für jeden hochschulweiten Dienst ist ein Dienstverwalter zuständig und verantwortlich. Außerdem muss mindestens ein sachkundiger Stellvertreter benannt sein.
• Jedem Benutzer eines vernetzten Rechners der Hochschule ist ein eigener Account zugeordnet. Jedem Account ist umgekehrt der Benutzer namentlich zugeordnet, der für alle Handlungen und Netzaktivitäten unter diesem Account persönlich verantwortlich ist. Die Benutzer sind schriftlich zu verpflichten, die Benutzungsordnung einzuhalten. Bei lokal verwalteten autonomen Systemen (z. B. PCs), bei denen keine Anmeldung (login) stattfindet, ist der Rechner entweder einer Person fest zugeordnet (Arbeitsplatz im Dienstzimmer) und wird auch ausschließlich von ihr benutzt oder es sind Maßnahmen zu treffen, die eine eindeutige Zuordnung erlauben.

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

• Zentrale Komponenten müssen in geeigneten (USV¹⁰, Brandschutz, ggf. Klimatisierung) und angemessen gesicherten Räumen betrieben werden. Kein Zugang (Handwerker, Putzdienst) ohne Verantwortlichen, spezifischer Alarmplan (Aushang) als Handlungsanweisung für den Notfall, Raumüberwachung mit Alarmauslösung
• Netzwerkkabel sind so zu verlegen, dass sie weder durch Baumaßnahmen noch durch Vandalismus direkt gefährdet sind.
• In geschlossenen Laborräumen ist durch ein Zugangskontrollsystem sicherzustellen, dass kein Unbefugter Zugang zu den Rechnern erhält.
• In offenen Poolräumen sind die Rechner durch geeignete (u. a. bauliche) Maßnahmen gegen Diebstahl und unberechtigten Zugang zum Hochschulnetz zu sichern.

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).

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

• direkter physischer Zugriff auf das Netz durch Integration eines Rechners per Netzwerkkarte
• Zugriff auf das Netz per Wählzugang
• Wählzugänge in die Hochschule werden für Studierende und Bedienstete zentral im ZIV zur Verfügung gestellt. In begründeten Ausnahmefällen können die Leiter/innen von IV-Versorgungseinheiten ausschließlich in Absprache mit dem ZIV lokale Wähleingänge einrichten. Alle Wähleingänge müssen dem bereits genannten Grundsatz der eindeutigen Identifikation genügen. Um die Sicherheitsrisiken zu minimieren, müssen die Betreiber der Wähleingänge die Verbindungsdaten aufzeichnen und überwachen. Modems zum »Rauswählen« sind vor unbefugter Benutzung zu schützen.
• Zugriff auf das Netz per Netzwerkdienst von einem Rechner aus dem Intra- bzw. Internet.

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

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).

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

• Orientierungshilfe zu Datenschutzfragen des Anschlusses von Netzen der öffentlichen Verwaltung an das Internet, erstellt vom Arbeitskreis Technik der Konferenz der Datenschutzbeauftragten des Bundes und der Länder, Überarbeitete Fassung vom September 1998
• Diverse Schriftstücke des DFN-CERT zum Thema Firewall sind über die entsprechenden WWW-Seiten des DFN abrufbar.
• BSI, IT-Grundschutzhandbuch 1998
• Bayerisches Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, Sicherheit in Verwaltungs- und Kliniknetzen, 1998
• Weitere Informationen unter http://www.sicherheit-im-internet.de/
• C. Fries und andere: Entwurf - Konzept zur Sicherheit der Informationstechnik an der Universität Paderborn (IT-Sicherheitskonzept), Paderborn, 22.03.1999
• 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
• W. Held, H.-W. Kisker, K. B. Mertz, B. Neukäter, S. Ost, R. Perske, G. Richter, Prüfliste für ein Sicherheitskonzept der IV, 1. Entwurf, Zentrum für Informationsverarbeitung der Westfälischen Wilhelms-Universität Münster, Stand: 10.98
• Diverse Abhandlungen zum Thema Sicherheit:
1. Regionales Rechenzentrum der Universität zu Köln (RRZK), http://www.uni-koeln.de/RRZK/
2. Rechenzentrum der Universität Stuttgart http://www.uni-stuttgart.de/RUS/
3. Rechenzentrum der Universität Freiburg http://www.ruf.uni-freiburg.de/rz/
4. Rechenzentrum der RWTH Aachen http://www.rwth-aachen.de/security und http://www.rz.rwth-aachen.de
• Diverse Begriffe (SSL, S/MIME, IPSEC, SSH, KERBEROS, ...) http://www.rsa.com/rsalabs/faq/html/
• Microsoft, Virtual Private Networking: An Overview, 1999, http://msdn.microsoft.com/workshop/server/feature/vpnovw.asp

11 Anmerkungen