Auf der Ebene 2 des OSI-Referenzmodells, dem Data Link Layer, lassen sich verschiedene Maßnahmen zur Erhöhung der Sicherheit einsetzen. Dazu zählen zum einen Authentifizierungsprotokolle, wie sie beim Aufbau von PPP-Verbindungen eingesetzt werden. Daneben existieren unterschiedliche Tunnelprotokolle, die in der Regel die Punkt-zu-Punkt-Verbindungen des Point-to-Point Protocol (PPP) tunneln. Sie werden ergänzt von Port-basierten Protokollen, die auf der Grundlage der Authentifizierung die Nutzung eines Ports freischalten. Als grundlegendes Protokoll dient in der Regel PPP, das meist für Wählverbindungen ins Internet (Dial-up Access) zum Einsatz kommt.
|
Teil 1 |
|
|---|---|
|
Teil 2 |
|
|
Teil 3 |
|
|
Teil 4 |
|
|
Teil 5 |
|
|
Teil 6 |
Authentifizierung in PPP
Beim Point-to-Point Protocol (PPP) handelt es sich um ein so genanntes "Multiprotokoll-Protokoll", das sich aus vielen Teilprotokollen zusammensetzt. Es wurde ursprünglich in RFC 1548 (PPP) und RFC 1172 (The PPP Initial Configuration Options) beschrieben.
Beide wurden 1994 durch RFC 1661 (PPP), RFC 1662 (PPP in HDLC-like Framing) und RFC 1663 (PPP Reliable Transmission) ersetzt. Später wurde mit RFC 1962 das PPP Compression Control Protocol (CCP) hinzugefügt. Das Rahmenformat von PPP zeigt oben stehende Abbildung.
Besondere Bedeutung im Zusammenhang mit der hier geführten Sicherheitsdiskussion haben das PPP Authentication Protocol (PAP, RFC 1334) und das PPP Challenge Handshake Authentication Protocol (CHAP, RFC 1994), das in einer verwandten Realisierung auch von Microsoft als Microsoft Challenge Handshake Authentication Protocol Version 2 (MS-CHAP v2, RFC 2759) vorliegt.
Ablauf
Den Ablauf des Verbindungsaufbaus mit PPP zeigt die unten stehende Abbildung. Bei der Authentifizierung unter PPP handelt es sich grundsätzlich um einen einseitigen Vorgang, da sich nur der Anrufer ausweisen muss. Der angerufene Knoten überprüft die Authentifizierung. Er selbst authentifiziert sich lediglich durch seine Verfügbarkeit unter der physischen Verbindung, also zum Beispiel durch die entsprechende Telefonnummer.
Diese manchmal auch als physische Authentifizierung bezeichnete Vorgehensweise eignet sich jedoch offensichtlich nur für zuverlässige Netze. Sie birgt Gefahren, wenn die eindeutige Erreichbarkeit nicht sichergestellt werden kann. In einem öffentlichen IP-Netzwerk lässt sich beispielsweise nicht ausschließen, dass IP-Adressen oder Routen manipuliert wurden.
Die Stellung von PPP im OSI-Referenzmodell ist zwiespältig. Zum einen eignet sich PPP für die Übertragung verschiedener Netzwerkprotokolle. So beschreiben RFC 1331 und RFC 1332 die Übertragung von IP mit Hilfe des IP Control Protocol (IPCP). Das IPX Control Protocol (IPXCP) regelt parallel die Übermittlung von IPX-Paketen. Zum anderen kann PPP seinerseits über IP oder IPX übertragen werden. Speziell beim Einsatz der im Folgenden beschriebenen Tunnelprotokolle für PPP kommt dieses Verfahren häufig zur Anwendung.
PAP
Das PPP Authentication Protocol (PAP, RFC 1334) beschreibt ein Zwei-Wege-Handshake. Das bedeutet, dass der anrufende Knoten die "username/password"-Kombination versendet, um eine Bestätigung von der Gegenstelle zu erhalten. Dies wiederholt er so lange, bis der Kommunikationspartner die Authentifizierung bestätigt oder ablehnt. Im Falle der Ablehnung wird die Verbindung abgebrochen.
Dabei ergeben sich eine ganze Reihe von Sicherheitsrisiken:
Das Passwort wird unverschlüsselt übertragen.
Der anrufende Knoten kann beliebig viele Versuche unternehmen, sich zu authentifizieren. Dies ermöglicht das Raten von Passwörtern.
Die Häufigkeit und die Geschwindigkeit der Versuche werden vom anrufenden Knoten bestimmt. Wenn ein oder mehrere Knoten gleichzeitig sehr häufig anrufen (Brute-Force-Attack), kann der zentrale Knoten in seiner eigentlichen Funktion lahmgelegt werden.
CHAP
Um die bei PAP auftretenden Sicherheitsrisiken zu verringern, wurde das PPP Challenge Handshake Authentication Protocol (CHAP, RFC 1994) entwickelt.
Es unterscheidet sich von PAP durch eine Reihe zusätzlicher Maßnahmen:
Häufigkeit und Geschwindigkeit der Authentifizierungsversuche werden im Rahmen eines Drei-Wege-Handshake vom angerufenen Knoten bestimmt, der ein Challenge (eine Herausforderung) an den anrufenden Knoten sendet.
Die Kombination "username/password" wird per MD-5 verschlüsselt.
Die Authentifizierung wird nicht nur beim Verbindungsaufbau, sondern auch periodisch während der Verbindung überprüft.
MS-CHAP v2
Microsoft hat eine eigene Variante eines Authentifizierungsprotokolls für PPTP auf den Markt gebracht, die als Microsoft Challenge Handshake Authentication Protocol version (MS-CHAP) bezeichnet wird. Nachdem die ursprüngliche Version signifikante Sicherheitslücken aufwies, liegt es nunmehr in der zweiten Version als MS-CHAP v2 vor.
Auch MS-CHAP v2 arbeitet nach einem Drei-Wege-Handshake:
Der Server, zum Beispiel ein Remote-Access-Server, sendet eine Nachricht an den anrufenden Client, die aus einem Session Identifier und einem pseudozufälligen Challenge String (Client Challenge String) besteht.
Die Antwort des Client enthält den User-Namen, einen pseudozufälligen Challenge String für den Server (Peer Challenge String), einen Session Identifier sowie einen SHA-1-Hash über den Peer Challenge String, den Session Identifier und das Benutzer-Passwort.
Der Server antwortet mit der Bestätigung oder Verweigerung der Anmeldung sowie einem SHA1-Hash über Client und Peer Challenge String, die verschlüsselte Antwort des Client und das MD-4-gehashte Passwort.
Der Client überprüft die Angaben des Servers und nutzt bei erfolgreicher Anmeldung die Verbindung. Ist die Anmeldung nicht korrekt, beendet der Client die Verbindung.
Vorteile
Gegenüber dem herkömmlichen CHAP weist MS-CHAP v2 eine Reihe von Vorteilen auf:
Es unterstützt eine wechselseitige Authentifizierung.
Die Schlüssel werden sowohl vom Benutzerpasswort als auch vom jeweiligen Challenge String abgeleitet. Auf diese Weise verwendet jede Verbindung einen unterschiedlichen Schlüssel.
Es lassen sich in Hin- und Rückrichtung unterschiedliche Schlüssel verwenden.
MS-CHAP v2 wird während der LCP-Phase beim PPP-Verbindungsaufbau ausgehandelt. Hierfür wird das Feld "LCP Option" auf Typ 3 gesetzt, das Authentifizierungsprotokoll erhält den Wert 0xC223 und der Algorithmus den Wert 0x81. Nach der erfolgreichen Beendigung der LCP-Phase nutzt MS-CHAP v2 das PPP-Protokoll 0xC223.
ECP
RFC 1968 beschreibt mit dem PPP Encryption Control Protocol (ECP) ein Verfahren zum Aushandeln von Verschlüsselungseinstellungen für PPP-Verbindungen. Nach der Konfiguration der Übertragungsparameter via LCP stimmen die Verbindungspartner über identische Nachrichtenformate die Algorithmen und die Schlüssellängen für die aktuelle Sitzung ab.
Den Algorithmen wurden von der IANA eindeutige Bezeichner zugeordnet. Ähnlich dem SSL-Handshake führt der Empfänger der verschlüsselten Nachrichten eine nach seinen Präferenzen geordnete Liste der von ihm unterstützten Algorithmen, die er dem Sender in einer Configure-Request-Nachricht übermittelt. Der Sender wählt aus der Liste die für ihn am besten geeignete Option.
Tunnelprotokolle
Historisch haben sich drei wichtige Tunnelprotokolle für PPP entwickelt. Hierbei handelt es sich um:
das Point-to-Point Tunneling Protocol (PPTP),
das Layer 2 Forwarding (L2F) und
das Layer 2 Tunneling Protocol (L2TP), das sich nunmehr als Kernprotokoll aus PPTP und L2F herauskristallisiert hat.
Da die Entwicklungen noch vergleichsweise neu sind, finden sich noch alle drei Protokolle in verschiedenen Implementierungen im Einsatz.
PPTP und L2F
Das Point-to-Point Tunneling Protocol (PPTP) wurde seit 1996 von Ascend Comm, US Robotics, 3Com, Microsoft und ECI Telematics unter Koordination durch das PPTP-Forum entwickelt. Es eignet sich für den Transfer von IP, IPX oder NetBEUI über ein IP-Netzwerk.
PPTP verpackt die PPP-Rahmen vor der Übermittlung in IP-Pakete mit der Generic Routing Encapsulation (GRE, RFC 2784) und sendet sie über ein IP-Netzwerk zum Zielknoten. GRE stellt dabei ähnlich wie TCP Sequenz- und Bestätigungsnummern sowie Mechanismen zur Flusssteuerung (über ein Sliding Window) bereit.
PPTP baut auf dem Remote Access Server für Microsoft Windows NT auf. Auch die Authentifizierung findet auf dem NT-Server statt. Durch die weite Verbreitung von Windows-9x-Clients spielt PPTP beim Aufbau von VPNs noch immer eine gewichtige Rolle. Es verwendet RC4-Verschlüsselung, die Microsoft auch als Microsoft Point-to-Point Encryption (MPPE) bezeichnet.
Das Layer2-Forwarding (L2F) wurde zunächst als proprietäre Entwicklung von Cisco bereitgestellt, aber auch recht bald von Nortel und Shiva unterstützt. Bereits im Mai 1998 als RFC 2341 verabschiedet, wird es mittlerweile aber nur noch der Kategorie "Historic" zugeordnet. L2F wurde für Tunnel von PPP- oder SLIP-Paketen vor der physischen Übertragung entwickelt.
L2TP
Das Layer2 Tunneling Protocol (L2TP) wurde vom PPTP-Forum und Cisco in Zusammenarbeit mit der IETF im August 1999 verabschiedet und liegt als RFC2661 vor.
Es eignet sich für den Transfer von IP, IPX oder NetBEUI über ein beliebiges Medium, das die Übertragung von Punkt-zu-Punkt-Datagrammen erlaubt. Hier sind zum Beispiel IP, X.25, Frame Relay oder ATM zu nennen. L2TP fasst PPTP mit L2F zusammen und beschreibt ein umfassendes Vorgehen.
Während PPTP nur Tunnel definiert, die vom Client initiiert werden, und L2F nur Tunnel erlaubt, die vom ISP veranlasst werden, ermöglicht L2TP beide Varianten. Darüber hinaus unterstützt L2TP auch die simultane Verbindung zu mehreren Adressen sowie mehrere sichere Connections.
Architektur
Der L2TP-RFC verwendet eine Reihe von spezifischen Begriffen zur Beschreibung einer Systemarchitektur:
LAC: Der L2TP Access Concentrator bildet den einen Endpunkt des L2TP-Tunnels. Wenn der LAC unmittelbar auf dem Client-Rechner läuft, dann spricht man von einem LAC-Client. Der LAC kann aber auch beim ISP implementiert sein.
LNS: Der L2TP Network Server bildet den anderen Endpunkt des L2TP-Tunnels.
NAS: Unter einem Network Access Server versteht man ein Gerät, das einen temporären Zugang für Remote-Systeme zur Verfügung stellt. Ein NAS kann gemeinsam mit einem LAC oder einer LNS implementiert sein.
Durch den L2TP-Tunnel wird ermöglicht, dass die normalerweise am Einwahlknoten des ISP endende PPP-Verbindung bis zum Übergang zwischen Internet und Unternehmensnetzwerk erweitert wird.
Ablauf der L2TP-Connection
Der Verbindungsaufbau über L2TP läuft in insgesamt acht grundlegenden Schritten ab:
Der Remote-User initiiert eine PPP-Verbindung.
Der NAS akzeptiert den Ruf.
Der NAS identifiziert den Remote-User unter Rückgriff auf seinen Authentifizierungsserver.
Ist die Authentifizierung erfolgreich, initiiert der NAS/LAC einen L2TP-Tunnel zum angestrebten LNS am Zugang zum Zielnetz.
Der LNS authentifiziert den Remote-User unter Rückgriff auf seinen Authentifizierungsserver.
War die Authentifizierung erfolgreich, bestätigt der LNS den Ruf und den L2TP-Tunnel.
Der LNS baut die PPP-Verbindung mit dem Remote-User auf.
Zwischen Remote-User und LNS können nun Datenpakete über die PPP-Verbindung versendet werden.
Tunnel und Paketformat
Es bestehen verschiedene Möglichkeiten, L2TP in den TCP-IP-Schichtaufbau zu integrieren. Den Ausgangspunkt bilden typischerweise PPP-Pakete, die eine Vielzahl von anderen Protokolldaten führen können. Diese PPP-Pakete werden nun ihrerseits in L2TP-Pakete getunnelt. Die L2TP-Pakete wiederum greifen auf einen Paketdienst zurück. RFC 2661 nennt hier Frame Relay, ATM oder auch UDP über Port 1701 als Beispiele. UDP wird seinerseits wieder über IP und, wenn es sich um eine serielle oder eine Dial-up-Verbindung handelt, auch wieder über PPP übertragen.
Natürlich stellt auch L2TP einen klassischen Header zur Verfügung. Dabei ist hervorzuheben, dass L2TP neben den Datenpaketen auch Steuerpakete versendet. Sie sind mit einem identischen Header ausgestattet; lediglich das "Type Field" unterscheidet zwischen Datenpaketen (Typ 0) und Steuerpaketen (Typ 1).
L2TP setzt selbst keine Authentifizierungs-, Integritäts- oder Verschlüsselungsmechanismen zum Schutz der getunnelten Pakete auf. Stattdessen verweist der RFC in diesem Punkt auf den IPsec-Standard. Da normale IP-Datagramme den L2TP-Tunnel umschließen, können die IPsec-Header (AH, ESP, IKE) problemlos zum Einsatz kommen. In VPN-Lösungen kommt daher meist eine Kombination aus L2TP und IPsec zum Einsatz.
AAA
Remote Access Server (RAS) ermöglichen den Dial-in-Zugang in Firmennetze. Deren Bedeutung hat in den vergangenen Jahren erheblich zugenommen.
Entsprechend zugenommen haben auch die Anforderungen an die Sicherheitskonzepte, die sich unter dem Akronym AAA zusammenfassen lassen. Das Kürzel steht für die Begriffe Authentication, Authorization und Accounting.
Als wichtigste Vertreter einer geschlossenen Lösung sind hier RADIUS und TACACS zu nennen. Zu den modernen Erweiterungen zählen insbesondere EAP und IEEE 802.1x.
RADIUS
Gerade in größeren Installationen ist die zentrale Pflege von Benutzerkennungen, Passwörtern und Zugriffsrechten unabdingbar. Der Remote Authentication Dial-In User Service (RADIUS) wurde speziell für den Nachrichtenaustausch zwischen RAS und einem Server, der alle Benutzerdaten zentral verwaltet, entwickelt.
Der ursprüngliche Entwurf stammt von der Firma Livingston Enterprises, die später von Lucent Technologies übernommen wurde, und basiert 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.
Das RADIUS-Protokoll unterstützt eine Vielzahl von Mechanismen zur Authentifizierung einwählender Benutzer und ist offen für neue Entwicklungen. Die typische Authentifizierung läuft in folgenden Schritten ab:
Der mobile Client wählt sich beim RAS ein.
Der RAS formuliert aus den Angaben des Benutzers eine Authentifizierungsanfrage, 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 dekodiert 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.
Ein weiteres typisches Einsatzszenario ist die Authentifizierung in Wireless LANs.
TACACS
Das Terminal Access Controller Access Control System (TACACS) 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 Network Access Server stellt, die dieser an einen zentralen Sicherheitsserver (TACACS-Server) weiterleitet. TACACS+ erlaubt wie RADIUS den Einsatz eines separaten Access-Servers, des TACACS+-Servers.
EAP und 802.1X
Das Extensible Authentication Protocol (EAP, RFC 2284) stellt eine wichtige Grundlage für eine umfassende und zentralisierte Sicherheitskonzeption dar. Ursprünglich wurde EAP als zuverlässige Authentifizierung der Remote-Access-User für PPP-Links entwickelt. Als allgemeines Protokoll bietet EAP mehrere Authentifizierungsmöglichkeiten. Die Auswahl des Verfahrens findet erst nach dem Link-Aufbau in der Authentifizierungsphase statt.
Von PPP ausgehend hat EAP mittlerweile auch Zugang in das 2001 verabschiedete IEEE 802.1x gefunden. Ziel dieses Standards ist die Port-bezogene Zugangskontrolle in Netzwerken (Port-based Network Access Control). Die Idee hinter 802.1x besteht darin, einem physischen Anschluss zwei logische 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) kann jedoch nur nach einer Authentifizierung erreicht werden. Diese erfolgt über den freien Port.
Die EAP-Messages werden dazu in 802.1x-Nachrichten verpackt (EAP over LAN, EAPOL). In der Regel übernimmt ein RADIUS-Server die Rolle des Authentifizierungsservers. Die EAP-Message wird dann als Attribut im RADIUS-Protokoll übertragen.
Lücken von 802.1x
IEEE 802.1x stellt eine wichtige Weiterentwicklung im Sicherheitskonzept für Netzwerke dar. Es weist jedoch zwei wesentliche Einschränkungen auf, die vor allem in drahtlosen Netzen zum Tragen kommen:
Das Verfahren sieht ausschließlich eine Authentifizierung des Client vor, indem der Zugangsserver den Verkehr über den kontrollierten Port erst nach erfolgreicher Authentifizierung freigibt. Dies öffnet den Weg für einen Angriff eines "falschen Servers", den so genannten Man-in-the-Middle-Attack.
Die einzelnen Pakete enthalten keine Zuordnung mehr. Auf dieser Grundlage kann im Rahmen eines so genannten Session Hijacking ein Angriff dahingehend erfolgen, dass eine WLAN-Station dem erfolgreich authentifizierten Client eine Disassociate-Meldung sendet, die diesen zur Beendigung der Verbindung auffordert. Der Access Point behält aber den kontrollierten Port weiterhin offen, so dass der Angreifer einen Zugang zum Netzwerk erhalten kann.
Solche Angriffe erscheinen bei einer Dial-up-Verbindung nicht praktikabel, da dort durch die Wahl der Telefonnummer der angerufene Partner nicht mehr authentifiziert werden muss. Bei festverdrahteten und entsprechend nach außen abgesicherten festverdrahteten Netzwerken hält sich das Risiko ebenfalls in Grenzen.
Ausblick
Im vorliegenden Teil unserer Reihe haben wir die Sicherheitsprotokolle auf der Verbindungsschicht des OSI-Modells besprochen. Der nächste Teil wird sich den Sicherheitsmechanismen auf der Netzwerkebene widmen. Dort kommen neben Filterprotokollen, die als Access Control Lists implementiert werden, vor allem Verschlüsselung (wie IPsec) sowie Masquerading-Protokolle zum Einsatz. Der Schwerpunkt des nächsten Kapitels unserer Reihe liegt aber auf der Darstellung der außerordentlich unübersichtlichen IPsec-Standardfamilie. (jlu)
| |
Teil 1 | |
|---|---|
Teil 2 | |
Teil 3 | |
Teil 4 | |
Teil 5 | |
Teil 6 | Security mit VPNs |