Security auf dem Application Layer

Auch auf den Transport- und Anwendungsebenen des Netzwerks existieren vielfältige Konzepte, um eine sichere Kommunikation über unsichere Verbindungen zu ermöglichen. Hierzu zählen insbesondere:

• Verschlüsselungs- und Authentifizierungsmechanismen,

• Firewalls und Proxys sowie

• Systeme zur Authentifizierung.

Transportprotokolle

Bei dem seit 1994 gemeinsam von Netscape und RSA Security entwickelten Secure-Socket-Layer-Protokoll (SSL) handelt es sich um das wohl bekannteste Sicherheitsprotokoll auf Transportebene.

Ziel ist die Bereitstellung eines privaten Kanals zwischen Kommunikationsanwendungen, um Vertraulichkeit und Integrität der Daten sowie die Authentifizierung der Partner zu gewährleisten. Hierzu implementiert SSL den RSA-Algorithmus für das Management des Sitzungsschlüssels sowie einen symmetrischen Algorithmus (etwa DES oder RC4) zur Verschlüsselung der Nutzdaten.

SSL stellt ein alternatives TCP/IP-Socket-API zur Verfügung, das über inhärente Sicherheitsmerkmale verfügt und seinerseits auf die normalen TCP-Sockets zugreift. Auf diese Weise können prinzipiell alle Anwendungen, die normalerweise über TCP/IP kommunizieren, ihre Daten auch über SSL austauschen.

SSL / TLS

In der Praxis hat sich vor allem der Einsatz von HTTP über SSL durchgesetzt. Die URL für einen SSL-basierten HTTP-Zugriff beginnt meist mit https:. Im Unterschied zu S-HTTP ist HTTPS dabei kein eigenes Protokoll, hier erfolgt lediglich der HTTP-Zugriff über SSL. Daneben existieren auch Erweiterungen, mit denen sich FTP, SMTP oder NNTP über SSL absetzen lassen. SSL setzt eine zuverlässige Übertragung auf der Transportebene voraus, so dass in der Regel der Einsatz von TCP gewählt wird.

Im Mai 1996 gründete die IETF eine Arbeitsgruppe Transport Layer Security (TLS), um ein an SSL angelehntes Protokoll zu standardisieren. Ziel war die Harmonisierung der Ansätze von Netscape (SSLv3) und Microsoft (STLP). Nach langen Diskussionen und Wirren konnte im Januar 1999 TLS als RFC 2246 verabschiedet werden. TLS und SSLv3 sind in fast allen Bereichen identisch. Viele Werkzeuge, einschließlich des Microsoft Internet Explorer, unterstützen TLS. Der Netscape Navigator bleibt jedoch bislang außen vor.

SSL liegt in einer Reihe von offenen Implementierungen vor. Insbesondere sind die Bibliotheken von OpenSSL zu nennen, die alle notwendigen Routinen zum Erstellen eigener Programme und Werkzeuge zur Generierung asymmetrischer Schlüssel und X.509-Zertifikate beinhalten.

SSL-Verbindungsaufbau

Bei SSL handelt es sich um ein verbindungsorientiertes Protokoll. Damit gliedert sich jede Kommunikation in die drei Phasen Verbindungsaufbau, Datenübertragung und Verbindungsabbau. Für den Verbindungsaufbau wird ein mehrstufiger Handshake-Prozess definiert.

Das Handshake dient sowohl zur Authentifizierung des Servers als auch für das Aushandeln der Schlüssel, die bei der nachfolgenden verschlüsselten Datenübertragung eingesetzt werden sollen. SSL besteht dabei aus einer Reihe von verschiedenen Nachrichtenarten, die mit Hilfe eines einheitlichen Record Layer übertragen werden.

Ablauf

Ein typischer SSL-Verbindungsaufbau läuft in folgenden Schritten ab:

• GET HTTPS://: Der Client ruft ein SSL-geschütztes Dokument auf dem Server auf, gekennzeichnet durch eine URL mit dem Protokollbezeichner HTTPS://.

• Handshake HelloRequest: Der Server sendet hierauf einen Hello-Request an den Client, der den eigentlichen SSL-Handshake startet.

• Handshake ClientHello: Der Client sendet dem Server eine Liste von unterstützten Algorithmen sowie eine Zufallszahl für die Erzeugung des Schlüssels. SSL und TLS unterstützen eine Vielzahl von Verschlüsselungsverfahren unterschiedlicher Qualität und Komplexität.

• Handshake ServerHello: Der Server sucht einen Algorithmus aus den vom Client angebotenen Verfahren aus und informiert den Client hierüber.

• Handshake Certificate: Der Server sendet seinen öffentlichen RSA-Schlüssel in einem gültigen X.509-Zertifikat an den Client.

• Handshake ServerHelloDone: Zusätzlich versendet auch der Server eine Zufallszahl, die ebenfalls für die Erzeugung des Schlüssels benötigt wird.

• Handshake ClientKeyExchange: Der Client überprüft das Zertifikat des Servers. Dann erzeugt er eine zufällige Zeichenfolge (pre_master_secret) und sendet diese verschlüsselt zum Server. Auf der Grundlage der beiden von Server und Client erzeugten Zufallszahlen und des pre_master_secret berechnen Client und Server unabhängig voneinander die Schlüssel für Verschlüsselung und die Signaturen (MAC).

• ChangeCipherSpec: Der Client informiert dann den Server, dass alle weiteren Pakete verschlüsselt übertragen werden.

• Handshake Finished: Das Finished-Paket enthält ein MAC über alle Handshake-Nachrichten an den Server. So findet der Server heraus, ob ein Man-in-the-Middle-Angriff die originalen Pakete des Client verändert hat.

• ChangeCipherSpec: Der Server informiert den Client, dass alle weiteren Pakete verschlüsselt übertragen werden.

• Handshake Finished: Auch das Finished-Paket des Servers enthält ein MAC über alle Handshake-Nachrichten an den Server. So kann auch der Client herausfinden, ob ein Man-in-the-Middle-Angriff die originalen Pakete des Servers verändert hat.

Damit ist die SSL-Verbindung aufgebaut, und die verschlüsselte Datenübertragung kann beginnen.

Anwendungsprotokolle

Komplementär zu HTTP via SSL steht mit Secure HTTP auch eine zweite Syntax zur sicheren Übertragung von HTTP-Paketen zur Verfügung. S-HTTP behandelt und schützt dabei jede HTTP-Nachricht einzeln.

Wie viele andere der hier vorgestellten Sicherheitsprotokolle bietet S-HTTP sowohl Befehle zum Aushandeln der Sicherheitsparameter ("negotiation format") als auch zur Übertragung der gesicherten Daten ("message format").

Das Nachrichtenformat von S-HTTP basiert auf der Cryptographic Message Syntax (CMS), die in RFC 2630 beschrieben ist. CMS ist eine Variante der PKCS #7, die für S/MIME entwickelt wurde. Auf beide gehen wir im Folgenden noch ein.

S-HTTP

S-HTTP-Pakete weisen das äußere Erscheinungsbild von HTTP-Requests und -Responses auf. Insbesondere nutzt S-HTTP den gleichen TCP-Port wie HTTP, versendet aber CMS-Nachrichten. Um dies dem Server mitzuteilen, wird in S-HTTP mit Secure ein spezieller Request-Typ definiert, der dem eigentlichen HTTP-Header vorangestellt wird.

Den prinzipiellen Aufbau im Vergleich zu konventionellem HTTP-Verkehr zeigt die obige Abbildung. Im Rahmen der S-HTTP-Verhandlung steht eine Vielzahl von verschiedenen Möglichkeiten zur Verfügung. Generell lassen sich eine digitale Signatur ("sign"), eine Verschlüsselung des Inhalts ("encrypt") und die symmetrische Authentifizierung des Inhalts ("auth") auswählen, wobei jeweils ein ganzer Satz von Parametern zur Anwendung kommt.

SSH

Ein Shell-Account bietet vollen Zugriff auf das Dateisystem und alle Funktionen des Rechners. Die früher dafür verwendeten Programme Telnet (über Port 23/tcp) beziehungsweise rlogin/rsh sind jedoch prinzipiell unsicher, da sie das Passwort im Klartext übertragen.

Mit SSH beziehungsweise Secure Shell bezeichnet man sowohl ein kryptographisches Protokoll als auch eine konkrete Implementierung dieses Protokolls. Ursprünglicher Designer des SSH-Protokolls und Autor der zugehörigen Software ist Tatu Ylönen aus Finnland. Er entwickelte die Secure Shell an der TU Helsinki und gründete später die Firma SSH Communications Security.

Zum Funktionsumfang von Ylönens Secure Shell gehören:

• das Login auf einer entfernten Maschine,

• die interaktive oder nicht interaktive Ausführung von Kommandos auf der entfernten Maschine sowie

• das Kopieren von Dateien zwischen verschiedenen Rechnern eines Netzes.

SSH1 vs. SSH2

SSH ermöglicht eine kryptographisch gesicherte Kommunikation über unsichere Netze und bietet ein hohes Sicherheitsniveau, zuverlässige gegenseitige Authentifizierung der Partner sowie Integrität und Vertraulichkeit der ausgetauschten Daten. SSH definiert sowohl die Verschlüsselung des gesamten Datenverkehrs als auch passwortbasierte oder Public/Private-Key-Login-Methoden ohne Einsatz von Klartext.

Gegenwärtig existieren zwei unterschiedliche und inkompatible Versionen des SSH-Protokolls: SSH 1.x und SSH 2.x. Das SSH-Protokoll 1.x ist nicht international standardisiert und mit einigen konzeptionellen Mängeln behaftet, die durch die Version 2.x behoben werden. SSH 2.x wird durch Internet Drafts der Secure Shell Working Group der IETF beschrieben.

SSH-Implementationen

Der SSH-Server läuft standardmäßig auf Port 22/tcp. Mittels Portweiterleitung (Port Forwarding) lässt sich über SSH aber auch anderer Verkehr abwickeln. So kann beispielsweise ein POP3-Client seinen Verkehr auf den lokalen SSH-Port umleiten, damit über diesen die Daten an den POP3-Server durch einen so genannten SSH-Tunnel transportiert werden.

Die in ANSI-C geschriebene, unter UNIX lauffähige SSH 1.0 wurde von Tatu Ylönen im Juni 1995 freigegeben. Bis zur Version 1.2.12 war Ylönens Software zu beliebigen Zwecken frei nutzbar, später wurden die Lizenzbedingungen restriktiver. Daher basiert beispielsweise die völlig freie OpenSSH auf der SSH 1.2.12.

Ylönens Firma SSH Communications Security beteiligt sich aktiv an der Weiterentwicklung der SSH und bietet Implementierungen des Protokolls 2.x als Produkte an, die unter bestimmten Bedingungen kostenfrei genutzt werden dürfen. Neben dieser "offiziellen" SSH-Variante gibt es eine ganze Reihe anderer Implementierungen unterschiedlicher Qualität, die zum Teil völlig unabhängig davon entstanden sind.

OpenSSH und OSSH

Mit OpenSSH und OSSH stehen zwei kostenfrei nutzbare, in C geschriebene SSH-Implementierungen für Unix zur Verfügung. Sie wurden und werden ausgehend von Tatu Ylönens Quellen der SSH 1.2.12 entwickelt und wiesen gegenüber dem Original eine ganze Reihe von Erweiterungen und Verbesserungen auf. Im Gegensatz zu Ylönens SSH unterstützen OpenSSH und SSH die beiden symmetrischen Chiffren IDEA und DES nicht.

Bei OpenSSH handelt es sich um eine Entwicklung des OpenBSD-Projekts und gehört ab dessen Version 2.6 zum Standardumfang. OpenSSH wird aktiv gepflegt und beherrscht ab Version 2.1.0 zusätzlich zum SSH-Protokoll 1.x auch das Protokoll 2.0. OSSH wird von Björn Grönvall entwickelt und steht ebenfalls für eine Vielzahl von Unix-Systemen zur Verfügung.

Auch für Windows existieren SSH-Implementationen. Zu deren bekanntesten zählt die Freeware putty, die über ein grafisches Interface sowohl SSH1 als auch SSH2 zur Verfügung stellt.

E-Mail-Verkehr

Für die Absicherung von E-Mail-Nachrichten existiert eine Reihe von Security-Mechanismen und Verfahren. In der Praxis haben davon vor allem Pretty Good Privacy (PGP) und Secure MIME (S/MIME) eine größere Verbreitung gefunden.

Kaum eine Rolle spielen dagegen beim Anwender bislang der Privacy Enhanced Mail Standard (PEM, RFC 1421 bis RFC 1424) und die MIME Object Security Services (MOSS, RFC 1847 und RFC 1848). Dies liegt nicht zuletzt an gewissen funktionalen Einschränkungen der beiden Standards.

PGP

Das kostenlos erhältliche Pretty Good Privacy (PGP) zählt zu den meistgenutzten Verschlüsselungsprogrammen im Internet. PGP realisiert hybride Verschlüsselungsverfahren, bei denen neben RSA- und Diffie-Hellman-Algorithmen wahlweise AES, CAST, Triple-DES, IDEA oder TwoFish zum Einsatz kommen.

Ein wesentlicher Grund für die weite Verbreitung von PGP war die Verfügbarkeit mit langen und damit (schon vor der Exportöffnung der USA) sicheren Schlüssellängen. Mittlerweile ist PGP in einer komfortablen grafischen Benutzeroberfläche integriert, die eine Verwendung und Administration einfach gestalten.

Ein wichtiges Merkmal bei der Verwendung öffentlicher Schlüssel ist die Authentifizierung: die Bestätigung also, dass der Schlüssel wirklich vom Absender kommt. Hierzu bietet PGP zusätzlich zur sicheren Übermittlung die Möglichkeit, ein so genanntes Web of Trust aufzubauen. Es basiert darauf, dass bereits als zuverlässig bekannte Kommunikationspartner weitere, jeweils selbst überprüfte Kontakte über ihre Signatur zertifizieren.

PGP unterstützt also sowohl Verschlüsselung ("encryption") als auch Authentifizierung ("signature"). Darüber hinaus komprimiert es den Datenstrom mit Hilfe der als Freeware verfügbaren Kompressionsroutine von Jean-Loup Gailly, Mark Adler und Richard B. Wales, die auch in PKZip 2.x der Firma PKWare eingesetzt wird.

S/MIME

Secure MIME (S/MIME) Version 2 wurde ursprünglich von den RSA Labs entwickelt und greift auf das verschlüsselte Nachrichtenformat PKCS #7 zurück. Im Gegensatz zu PGP verwendet S/MIME die weit verbreiteten X.509-Zertifikate.

Da ein solches Zertifikat nur von einer Zertifizierungsstelle beglaubigt werden kann, fallen hier in der Regel Kosten an, was die Verbreitung gegenwärtig noch hemmt, obwohl eine Vielzahl von Mail-Clients S/MIME schon unterstützt.

Firewalls

Die Hauptaufgabe einer Firewall besteht darin, die Zugriffskontrolle auf das interne Netzwerk zu zentralisieren. Aus technischer Sicht existieren zwei grundlegend verschiedene Konzepte der Firewall-Realisierung: Paketfilter und Proxy-Gateways.

Paketfilter oder Überwachungs-Router (screening router) arbeiten auf der Netzwerk- und Transportschicht und stellen die einfachste Variante einer Firewall dar. Sie werten ein- und ausgehende Datenpakete nach den Header-Informationen in IP-, ICMP-, TCP- oder UDP-Paketen aus. Auf Grund dieser Informationen treffen sie gegebenenfalls die Entscheidung, ein Paket mit einer bestimmten Zieladresse ("outbound") oder Quelladresse ("inbound") zu blockieren.

In der Regel sind die Sende- und Empfangsadresse, die Portnummer der Anwendung, TCP-Statusinformationen sowie der Nachrichtentyp bei ICMP-Nachrichten die Grundlage für eine solche Entscheidung. Das vielleicht bekannteste Beispiel hierfür sind die Access Control Lists (ACL), wie sie in Cisco-Routern Einsatz finden. Aber auch die von Linux verwendeten ipchains beziehungsweise iptables erfüllen die gleiche Funktion.

Application Level Gateways arbeiten, wie der Name nahe legt, zusätzlich auf Anwendungsebene und können entsprechend auch anwendungsspezifische Informationen in den Filterprozess miteinbeziehen. Auf diese Weise lassen sich beispielsweise bestimmte Operationen in einzelnen Protokollen sperren. So kann man etwa über das Sperren des PUT-Befehls in FTP den Upload unerwünschter Dateien verhindern.

Proxy-Gateways

Proxy-Gateways sind wie Überwachungs-Router dezidierte Rechner, über die alle Verbindungen zwischen dem internen Netz und dem Internet geleitet werden. Im Unterschied zu den Paketfiltern trennen sie jedoch die Verbindungen am Übergang zwischen den Netzen.

Bei einem Verbindungsaufbau eines internen Client prüft der Gateway zunächst, ob er den adressierten Ziel-Host im Internet kontaktieren und den angeforderten Dienst nutzen darf. Danach führt der Proxy (Englisch: Stellvertreter) den Verbindungsaufbau stellvertretend für den internen Host aus. Der Zielrechner empfängt die Datenpakete mit der Absenderadresse des Proxy, an den er auch seine Antworten zurückschickt. Der Proxy reicht die Daten dann über seine interne Schnittstelle an den anfragenden Client weiter.

Circuit Level Gateways

Bei Circuit Level Gateways handelt es sich um Proxy-Gateways mit erweiterten Funktionen. Sie haben als anwendungsunabhängige Multiprotokoll-Proxies auf Transportebene die Aufgabe, die Verbindungsdaten zwischen internem und externem Netz zu überwachen und bei erfüllten Regeln weiterzuleiten. Circuit Level Gateways unterscheiden sich von Paketfiltern lediglich darin, dass sie die Verbindung unterbrechen und die intern verwendeten IP-Adressen per Masquerading verbergen können.

Unter IP-Masquerading versteht man die IP Network Address Translation (NAT), wie sie in RFC 3022 beschrieben ist. Diese erlaubt die Adressumsetzung zwischen den internen Adressen eines Netzwerks und der Adresszuordnung im öffentlichen Netz. Ursprünglich wurde NAT entwickelt, um im beschränkten IPv4-Adressraum weitere Hosts anschließen zu können.

Mittlerweile hat sich NAT aber eher zum Sicherheits-Feature insbesondere für kleinere Netze entwickelt, die nicht über weiter gehende Sicherheitsmechanismen wie SOCKS oder Proxy-Server verfügen. Eine genauere Beschreibung des Verfahrens finden Sie in Teil 4 dieser Artikelreihe.

SOCKS

Damit eine Internet-Anwendung trotz Eingabe der externen Zieladresse zuerst das Gateway kontaktiert, muss oft die Software intern angepasst werden. Alle Socket-Calls der Anwendung sind durch neue Aufrufe zu ersetzen, anschließend muss der Programm-Code neu kompiliert werden. SOCKS ist eine Sammlung von Werkzeugen, die entwickelt wurde, um bestehende Client-/Server-Anwendungen in Proxy-Versionen der gleichen Anwendung umzuwandeln. Die Algorithmen von SOCKS Version 5 (SOCKSv5) sind in RFC 1928 beschrieben.

Dem Anpassungsproblem kann man auch durch den Einsatz zusätzlicher Software begegnen. Das kostenlos erhältliche SocksCap von NEC arbeitet unter allen Windows-Versionen zwischen den Anwendungen und dem TCP/IP-Stack (Winsock). Dort fängt SocksCap alle Aufrufe ab und setzt sie zur Laufzeit in das SOCKS-Protokoll um. Viele Standard-Client- und -Server-Programme besitzen mittlerweile eigene Proxy-Fähigkeiten oder unterstützen generische Proxy-Systeme wie SOCKS. Dies gilt insbesondere für Anwendungen aus dem Unix-/Linux-Umfeld.

SOCKS v5

Der Verbindungsaufbau unter SOCKSv5 verläuft nach einem Muster, das auch Eingang in den Standard IEEE 802.1x gefunden hat. Hierfür beobachtet der SOCKSv5-Server einen bestimmten Port (meist 1080), an den der Client seine initiale Verbindungsanfrage sendet.

Wenn die Anfrage zugelassen und die Verbindungsanfrage erfolgreich sind, beginnt eine Authentifizierungsphase, bei der der Client nach dem Aushandeln der Authentifizierungsverfahren und -parameter seine Identität nachweisen muss.

AAA - Authentication, Authorization, Accounting

Remote Access Server (RAS) ermöglichen den Dial-in-Zugang in Firmennetze. Deren Bedeutung hat in den vergangenen Jahren erheblich zugenommen.

Entsprechend gestiegen sind damit auch die Anforderungen an die zugehörigen Sicherheitskonzepte, die sich unter dem Akronym AAA (Triple-A - Authentication, Authorization, Accounting) zusammenfassen lassen.

Als wichtigste Vertreter einer geschlossenen Lösung sind hier RADIUS und TACACS zu nennen. Bei den modernen Erweiterungen sind insbesondere EAP und 802.1X hervorzuheben.

RADIUS

In größeren Installationen ist die zentrale Pflege von Benutzerkennungen, Passwörtern und Zugriffsrechten unverzichtbar. Der Remote Authentication Dial-in User Service (RADIUS) wurde für den Nachrichtenaustausch zwischen RAS und einem Server entwickelt, der alle Benutzerdaten zentral verwaltet.

Die ursprüngliche Entwicklung stammt von der Firma Livingston Enterprises, die später von Lucent Technologies übernommen wurde. Sie basiert dabei auf Vorarbeiten der IETF Network Access Working Requirements Group. Eine IETF-Arbeitsgruppe für RADIUS wurde im Januar 1996 gegründet. Sie bereitete die Verabschiedung der RFCs 2058 und 2138 vor, die später durch RFC 2865 und RFC 2866 ergänzt wurden.

Ablauf der RADIUS-Authentifizierung

Das RADIUS-Protokoll unterstützt eine Vielzahl von Mechanismen zur Authentifizierung einwählender Benutzer und ist offen für neue Entwicklungen. Ein typischer Einsatz unter Verwendung eines RAS läuft folgendermaßen ab:

• Der mobile Client wählt sich beim RAS ein.

• Der RAS formuliert aus den Angaben des Benutzers eine Authentifizierungsanfrage (authentication request), die verschlüsselt an den RADIUS-Server übermittelt wird.

• Entsprechend der IP-Adresse wählt der RADIUS-Server den richtigen Schlüssel aus einer Datenbank aus und decodiert das Passwort. Wird ein Eintrag für die Anmeldung gefunden, übermittelt der RADIUS-Server das entschlüsselte Passwort an einen Authentifizierungsserver.

• Sind die Daten korrekt, schickt der RADIUS-Server eine Bestätigung an den RAS und übermittelt zusätzliche Informationen zur Verbindung.

• Diese werden vom RAS an den mobilen Client weitergeleitet.

TACACS

Das Akronym TACACS steht für Terminal Access Controller Access Control System. Das Verfahren wurde als RFC 1492 standardisiert. Es liegt zusätzlich in zwei von Cisco erarbeiteten Erweiterungen vor: Extended TACACS (XTACACS) und TACACS+.

TACACS ähnelt der Architektur von RADIUS dahingehend, dass ein Remote Client eine Authentifizierungsanfrage an einen RAS-Server stellt, die dieser an einen zentralen Sicherheitsserver (TACACS-Server) weiterleitet. TACACS+ erlaubt wie RADIUS den Einsatz eines separaten Access-Servers, des TACACS+-Servers.

Kerberos

Der Name des Kerberos-Protokolls beruft sich auf den dreiköpfigen Hund Zerberus, der in der griechischen Mythologie die Pforte der Unterwelt Hades bewacht und der nur von Odysseus und Herakles überwunden wird. Der Kerberos Network Authentication and Authorization Service Version 5 ist in RFC 1510 beschrieben.

Der Kerberos-Dienst wird normalerweise auf einem eigenen System betrieben und stellt ein verschlüsseltes Sicherheitssystem zur wechselseitigen Authentifizierung von Clients und Servern dar. Benutzer müssen sich zunächst bei Kerberos anmelden, bevor sie auf andere Server zugreifen dürfen.

Der Kerberos-Dienst teilt sich in zwei Bestandteile auf: den Kerberos Authentication Server (KAS), der die Authentifizierung durchführt, und den Kerberos Ticket Granting Server (TGS), der den Client mit dem Nachweis ausstattet, dass dieser auf den Dienst eines weiteren Servers im System zugreifen darf.

EAP und 802.1x

Das Extensible Authentication Protocol (EAP - RFC 2284) bildet eine wichtige Grundlage für umfassende und zentralisierte Sicherheitskonzepte. Ursprünglich wurde EAP für PPP-Links entwickelt, um eine zuverlässige Authentifizierung für Remote Access User bereitzustellen.

Bei EAP handelt es sich um ein allgemeines Protokoll, das mehrere Authentifizierungsmöglichkeiten bietet. Die Auswahl des Verfahrens findet bei PPP erst nach der Link Control Phase (LCP) in der Authentifizierungsphase statt.

Von PPP ausgehend hat EAP mittlerweile auch Zugang in den im Jahr 2001 verabschiedeten Standard IEEE 802.1x gefunden, der die physische Übertragung für LAN-Netzwerke anpasst. Die EAP-Messages werden hierzu in 802.1x-Nachrichten verpackt (EAP over LAN - EAPOL). Ziel dieses Standards ist die portbezogene Zugangskontrolle in Netzwerke (Port-Based Network Access Control).

Struktur von 802.1x

Die Idee hinter IEEE 802.1x besteht darin, einem physischen Anschluss zwei logische Anschlüsse (Ports) zuzuordnen. Der physische Anschluss leitet die empfangenen Pakete grundsätzlich an den so genannten freien Port (Uncontrolled Port) weiter.

Der kontrollierte Port (Controlled Port) lässt sich jedoch nur nach einer Authentifizierung erreichen. Diese kann über den freien Port erfolgen (siehe Abbildung). In der Regel übernimmt bei 802.1x ein RADIUS-System die Rolle des Authentifizierungs-Servers. Die EAP-Message wird dann als Attribut im RADIUS-Protokoll übertragen.

Lücken von IEEE802.1x

Der IEEE-802.1x-Standard stellt eine wichtige Weiterentwicklung im Sicherheitskonzept für Netzwerke dar. Dabei bleiben jedoch zwei wesentliche Aspekte ausgespart:

• IEEE 802.1X sieht eine Authentifizierung des Client nur vor, indem der Access Point den kontrollierten Port erst nach erfolgreicher Authentifizierung freigibt. Der Client selbst befindet sich unmittelbar im authentifizierten Modus. Dies öffnet den Weg für Angriffe von "falschen Servern", so genannten Man-in-the-Middle-Attacken.

• Die einzelnen Pakete enthalten keine Zuordnung mehr. So kann im Rahmen eines so genannten Session Hijacking ein Angriff dahingehend erfolgen, dass eine andere Station dem erfolgreich authentifizierten Client eine Disassociate-Meldung sendet, die diesen zur Beendigung der Verbindung auffordert. Der Access Point hält aber den kontrollierten Port weiterhin offen, so dass der Angreifer darüber Zugang zum Netz erhalten kann.

Allerdings erscheinen solche Angriffe insbesondere bei Dial-up-Verbindungen nicht sonderlich praktikabel: Der Kommunikationspartner lässt sich dort recht zuverlässig über die angerufene Telefonnummer identifizieren. Auch bei festverdrahteten und entsprechend nach außen abgesicherten Netzwerken bleibt das Risiko vergleichsweise gering.

Ausblick

Mit der Beschreibung der Sicherheitsmechanismen auf Transport- und Anwendungsebene haben wir schon beinahe das Ende unserer Security-Reihe erreicht.

Im nächsten und letzten Teil werden wir uns mit einer Sicherheitstechnologie beschäftigen, die derzeit immer mehr an Bedeutung gewinnt: den Virtual Private Networks (VPNs). Mit Hilfe von VPNs lassen sich externe Rechner über öffentliche Netzwerke sicher an das Unternehmensnetz anbinden. (jlu)