Kapitel 11: Netzsicherheit -
Schicht 2: Data Link Layer
Inhalt
! Virtualisierung von Netzen
!
Virtual Private Networks
!
VLAN
! Point-to-Point Protocol (PPP)
!
Authentisierungsprotokolle:
!
PAP, CHAP, EAP
! Point-to-Point Tunneling Protocol (PPTP)
! Layer 2 Tunneling Protocol (L2TP)
! IEEE 802.1x
Virtual (Private) Network
!
Grundidee:
Nachbildung einer logischen Netzstruktur („Local Area Network“ oder eines „nicht öffentlichen“ Netzes) in
beliebigen Topologien/Technologien, z.B. auch über das Internet
!
Das „virtuelle“ Netz soll u.a. bezüglich Vertraulichkeit und Datenintegrität mit physischen LANs vergleichbar sein
!
Virtualisierung auf jeder Schicht des OSI-Modells möglich
Rückblick: ISO/OSI Schichtenmodell (Kapitel 2)
Anwendungs- schicht
Darstellungs- schicht
Kommunikation s-steuerungss.
Transportschicht Vermittlungs- schicht
Sicherungs- schicht
Bitübertragungs -schicht
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer 7
6 5 4 3 2 1
Network Layer
Data Link Layer
Physical Layer
Endsystem Endsystem
Transitsystem
Medium Medium
Virtual Network auf Schicht 1
!
Virtual Private Wire Service (VPWS)
" Provider bietet Punkt zu Punkt Verbindung
!
Virtual Private Line Service (VPLS)
" Provider bietet Punkt zu Multipunkt Verbindungen
!
Beispiel:
Optical Private Link oder Optical Private Network (OPN)
" Provider betreibt Glasfaserinfrastruktur
" Kunde erhält eine Wellenlänge (Farbe) in dieser Infrastruktur
" Kunde kann diese nutzen wie einen dedizierten Schicht 1 Link
" Kunde muss sich um Routing, Bridging, etc. selbst kümmern
" Über dieselben Glasfasern werden auch andere Kunden bedient
Beispiel für OPN: Large Hadron Collider
Virtual Network auf Schicht 2/3/4
!
Schicht 2:
" Virtual LAN (VLAN)
# Mehrere LAN Broadcast Domains über den selben physischen Link
# Standard: VLAN Tagging (IEEE 802.1Q)
" Virtual Private LAN Services (Achtung: Abkürzung auch VPLS)
# Verbindet physisch getrennte (V)LANs miteinander
" Point-to-Point Verbindungen
" Layer2 Tunneling Protocol
" ....
!
Schicht 3 und höher:
" IPSec
" SSL / TLS
" OpenVPN
" ...
Aufgaben der Schicht 2
!
Fehlerfreie Übertragung von Frames (Rahmen)
" Aufteilung von Bitströmen in Frames
" Fehlerkontrolle über Prüfsummen (z.B. Cyclic Redundancy Check,
CRC)
!
Flusskontrolle (Verhindert, dass der Empfänger mit Frames überflutet wird und diese verwerfen muss)
!
Medienzugriffsverfahren für gemeinsam genutztes Übertragungsmedium
" CSMA/CD bei Ethernet (IEEE 802.3)
" CSMA/CA bei WLAN (IEEE 802.11)
" .... WLAN: Problem der
„hidden stations“
Virtual LAN (VLAN)
!
LAN-Infrastruktur über mehrere Switches (Gebäude) hinweg
!
Logisch verschiedene LANs auf einer Netzkomponente
!
Wunsch nach Verkehrsseparierung
!
Heute Standard in Unternehmens- und Hochschulnetzen
" Von Switchen im Consumer-Bereich oft nicht unterstützt
VLAN: Datenpakete
!
Virtual Local Area Network (VLAN); IEEE 802.1Q
!
VLAN definiert Broadcast-Domäne
!
Idee: Erweiterung des Ethernet-Frame um sog. Tag
Frame Check Sequence
VLAN: Tag Format
!
Erweiterung des Ethernet-Frame um 32-bit Tag:
" TPID (Tag Protocol Identifier): konstant 0x8100; d.h. 802.1Q Tag
Information im Frame enthalten (2 Byte)
" PRI (Priority): Priorisierung nach 802.1p (3 Bit)
" CFI (Canonical Format Indicator): MAC Adressen in kanonischer
Form
(1 Bit); bei Ethernet 0; sonst (z.B. Token Ring) 1
" VLAN-ID: Identifizierung des VLANs („VLAN NR.“) (12 Bit)
# ID 0 = „kein VLAN“, ID 0xFFF ist reserviert
# Somit 4094 verschiedene VLANs möglich
CFI
PPP: Überblick
!
Punkt-zu-Punkt Protokoll; Entwickelt für Verbindungsaufbau über Wählleitungen
" DSL, ISDN, Modem, Mobilfunk, Funk, serielle Leitungen,....
" WAN-Verbindungen zwischen Routern
" Angelehnt an HDLC (Highlevel Data Link Control); Schicht 2 Protokoll
!
Spezifiziert in RFC 1661, 1662 und 2153
" Frame Format mit Begrenzungssymbolen (Delimiter) und Prüfsumme
" Link Control Protocol (LCP) für:
# Verbindungsauf- und -abbau
# Test
# Aushandeln der Konfiguration (u.a. Nutzdatenlänge pro Frame)
" Network Control Protocol (NCP) :
# Aushandeln der Konfiguration der unterstützten Schicht 3 Protokolle
(z.B. IP, IPX, Appletalk,...), verschiedene Schicht 3 Protokolle über einen PPP-Link möglich
PPP: Sicherheitsdienste
!
Authentifizierung optional
!
Im Rahmen der LCP-Aushandlung der Konfiguration kann jeder Partner eine Authentifizierung fordern
!
Definierte Authentifizierungsprotokolle:
" Password Authentication Protocol (PAP)
" Challenge-Handshake Authentication Protocol (CHAP)
" Extensible Authentication Protocol (EAP)
Password Authentication Protocol (PAP)
!
Spezifiziert in RFC1334
!
Authentisierende Entität kennt ID und Passwort aller Clients
!
Client wird mit LCP zur Authentisierung via PAP aufgefordert
!
Client schickt ID und Passwort im Klartext
!
Server schickt im Erfolgsfall ACK
!
Keine Verschlüsselung, Übertragung der Passwörter im Klartext
➡ Unsicheres Protokoll
RFC 1334:
„Any implementations which include a stronger authentication method (such as CHAP, described below) MUST offer to negotiate thatmethod prior to PAP.“
Challenge-Handshake Authentication Protocol: CHAP
!
(Auch) RFC1334 und RFC1994
!
Periodische Authentisierung durch 3-Way-Handshake Protokoll
!
Basiert auf gemeinsamen Geheimnis (Passwort) K
AB!
A (Authenticator) fordert B zur Authentisierung auf:
" id: 1 Byte Identifier („incrementally changing“) gegen Replay-Angriffe
" RA : Zufallszahl, H: Hash Verfahren, im Standard MD5
" 3 = success; 4 = failure
!
Auth-Request kann später beliebig neu geschickt werden
A 1, id,R
A,A B
2, id,H(id,R
A,K
AB),B
3|4, id
Sicherheitsrisiko PAP-Fallback
!
Viele Clients unterstützen immer noch Server, die nur PAP anbieten
" Für Client-Hersteller einfach zu implementieren
" Abwärtskompatibilität vom Markt gewünscht
" Die meisten Anwender kennen den Unterschied zwischen PAP,
CHAP, etc. sowieso nicht: Hauptsache, es funktioniert!
!
Man-in-the-middle-Angriff
" Client kommuniziert nicht direkt mit Server, sondern über Angreifer
" Angreifer gibt sich als „nur PAP“-Server aus
" Angreifer erhält Klartext-Passwort vom Client
" Somit kann der Angreifer u.a. als CHAP-fähiger Client gegenüber
dem richtigen Server auftreten
Extensible Authentication Protocol (EAP)
!
RFC3748 und RFC5247
!
Authentisierungs-Framework, bietet gemeinsame
Funktionen und Aushandlungsmechanismen für konkretes Verfahren (als Methode bezeichnet)
!
Rund 40 Methoden werden unterstützt:
" EAP-MD5; äquivalent zu CHAP
" EAP-OTP (One Time Password); vgl. Kapitel 8
" EAP-GTC (Generic Token Card)
" EAP-TLS (Transport Layer Security) vgl. Abschnitt über SSL/TLS
" EAP-SIM (Global System for Mobile Communications (GSM)
Subscriber Identity Modules (SIM)
!
Herstellerspezifische Methoden:
" LEAP (Cisco) Lightwight Extensible Authentication Protocol
" PEAP (Cisco, Microsoft, RSA) Protected Extensible Authentication
Prot.
" ....
EAP Grundlagen
!
EAP kann Sequenz von Verfahren verwenden
!
Verfahren muss aber vollständig abgeschlossen werden, bevor neues beginnt
!
Request - Response Schema mit Success / Failure Antwort
!
Beispiel: EAP-GTC (Generic Token Card, RFC3748)
" Nutzbar für verschiedenste Autentisierungs-Token-
Implementierungen
" Request beinhaltet Nachricht, die dem Nutzer
angezeigt wird
" Nutzer gibt Token-Information ein
" Server prüft und antwortet
Point to Point Tunneling Protocol (PPTP)
!
PPP wurde für „direkt“ verbundene Systeme entwickelt
!
Idee von PPTP (RFC2637):
" Ausdehnung von PPP über Internet
" PPTP realisiert Tunnel durch / über das Internet
" Transport von PPP PDUs in IP-Paketen
" Dazu werden PPP PDUs mit Generic Router Encapsulation Protocol
(GRE) gekapselt
" GRE ist ein Schicht 4 Protokoll
PPP Protocol Data Unit (PPP PDU) GRE
IP
Sicherungsschicht
Bitübertragungsschicht (Physical Layer)
PPTP: Anwendungsfälle
!
Eines der ersten einfach zu konfigurierenden VPN-
Protokolle mit weiter Verbreitung seit Microsoft Windows 95
!
Verbindung eines Clients mit einem Remote Access Server (RAS)
" Voluntary Tunneling
" Client setzt PPTP aktiv ein
!
Verbindung eines ISP Point of Presence (POP) mit einem PPTP Remote Access Server
" Compulsory Tunneling
" Client weiß nichts von PPTP
" ISP POP handelt als Proxy (Stellvertreter) des Clients
PPTP: Voluntary Tunneling
IP/IPX/AppleTalk PPP
GRE IP
Sicherungsschicht Bitübertragungssch.
IP/IPX/AppleTalk Sicherungsschicht
Bitübertragungssch.
PPP
PPTP
IP/IPX/AppleTalk
Client POP RAS
PPTP-Tunnel
IP/IPX/AppleTalk PPP
GRE IP
Highlevel Data Link Ctrl.
Bitübertragungssch.
PPTP: Compulsory Tunneling
IP PPP GRE IP
Sicherungsschicht Bitübertragungssch.
IP PPP
Highlevel Data Link Control
Bitübertragungssch.
IP
Sicherungsschicht
Bitübertragungssch.
PPP PPTP
IP
Client POP RAS
PPTP-Tunnel
PPTP Sicherheit
!
Von Microsoft entwickelt [RFC 2637] als Teil des Remote Access Service (RAS)
!
Microsoft-eigene Erweiterungen:
" Microsoft PPP CHAP (MS-CHAP) [RFC 2433]
" Microsoft Point to Point Encryption Protocol (MPPE) [RFC 3078]
!
Analyse von Bruce Schneier 1998; Fehler in
" Password Hashing: schwacher Algorithmus erlaubt Eve, das Passwort zu
ermitteln (Stichworte: LAN Manager Passwort und L0phtCrack)
" Challenge/Response Protokoll erlaubt Maskerade-Angriff auf RAS Server
(keine beidseitige Authentifizierung)
" Verschlüsselung: Implementierungsfehler erlaubt Dekodierung
" Verschlüsselung: Geratenes Passwort erlaubt Entschlüsselung
" Kontrollkanal: Unautorisierte Nachrichten erlauben DoS (Crash des Servers)
" Details: http://www.schneier.com/paper-pptp.pdf
!
Microsoft besserte nach: PPTP v2 und MS-CHAPv2 [RFC 2759]
Vergleich MS-CHAP v1 und v2
!
Version 1:
Client Server
KL = LAN-Manager-kompatibler Hash(Passwort) KN = Windows NT-kompatibler Hash(Passwort)
DES(KL ,C), DES(KN,C) Login Request
Challenge C Zufallszahl C
(8 Byte)
Verifikation
success oder failure
Vergleich MS-CHAP v1 und v2
!
Änderungen in der Version 2
!
Client Server
Verifikation
KN = NTHash(Passwort) PC, DES(KN,R) Login Request
Challenge C Zufallszahl C
(16 Byte)
Verifikation
success oder failure
SHA(O,R, „Pad to make it do more than one iteration“) a) Peer Authenticator Challenge
Zufallszahl PC (16 Byte)
b) R = SHA1(C, PC, username) (R sind die ersten 8 Byte)
O = SHA[ MD4(KN), DES(KN,R),
„Magic server to client constant“ ]
Sicherheit MS-CHAP v2
!
Protokoll komplizierter als nötig
!
Nutzen der „piggybacked“ Peer Authenticator Challenge PC fragwürdig
!
Fazit:
" Auch MS-CHAP v2 hat keinen integrierten Schutz vor Angriffen
" Starke Abhängigkeit von der Wahl eines „guten“ Benutzerpassworts
" Bessere Verfahren (z.B. Encrypted Key Exchange und Varianten)
waren bereits verfügbar, wurden von Microsoft aber nicht genutzt
!
Version Rollback Attack möglich:
Mallet „überzeugt“ Client und Server, MS-CHAP v1 zu
verwenden
IEEE 802.1X
!
802er Standards für Local Area Networks (LAN), insbesondere für Schicht 1 und 2, z.B.
" 802.1Q Virtual Bridged LANs (VLAN)
" 802.3 CSMA/CD (Ethernet)
" 802.5 Token Ring
" 802.6 Metropolitan Area Network
" 802.11 Wireless LAN
" 802.15 Wireless PAN (Personal Area Network)
" 802.15.1 Bluetooth
!
802.1X Port Based Network Access Control
" Authentisierung und Autorisierung in IEEE 802 Netzen
" Häufig genutzt in WLANs und (V)LANs
" Port-basierte Network Access Control
802.1X Grundlagen
!
Rollen:
" Supplicant: 802.1X Gerät, das sich authentisieren möchte
" Authenticator: Gerät, an dem der Supplicant angebunden ist (z.B.
Switch oder WLAN Access Point), erzwingt Authentisierung und beschränkt ggf. Konnektivität
" Authentication Server: führt die eigentliche Authentisierung durch
(z.B. RADIUS-Server mit LDAP-Backend)
" Port Access Entity (PAE): „Port“, an dem Supplicant angeschlossen
ist
# Uncontrolled Port:
erlaubt Authentisierung des Gerätes
# Controlled Port:
erlaubt authentisiertem Gerät Kommunikation zum LAN
LAN
Controlled Port
Uncontrolled Port
Point of Attachment
802.1X: Ablauf der Protokolle
!
Möglicher Ablauf:
1. Supplicant fordert Controlled Port 2. Authenticator fordert Authentisierung
3. Nach erfolgreicher Authentisierung wird der Port freigeschaltet
!
Supplicant oder Authenticator können Authentisierung initiieren
!
802.1X definiert keine eigenen Sicherheitsprotokolle, sondern nutzt bestehende:
" Extensible Authentication Protocol (EAP) [RFC 3748] für Geräte-
Authentisierung
" EAP-TLS [RFC 5216] z.B. zur Aushandlung eines Session Key
" RADIUS als AAA Protokoll (AAA = Authentisierung, Autorisierung und
Accounting)
Extensible Authentication Protocol (EAP)
!
Unterstützt verschiedene Auth.-Mechanismen
!
Aushandlung erst während der Authentisierung mit Auth.- Server
!
Authenticator ist nur Vermittler der Nachrichten
Radius UDP/
TCP IP
Layer 2 EAP
PPP Ethernet WLAN ...
Radius UDP/
TCP IP
Layer 2 802.1X
EAP
PPP Ethernet WLAN ...
EAP
802.1X
Ende zu Ende Authentisierung
ACK
NAK
Beispiel: WLAN-Zugang im MWN
Praxisbeispiel: Eduroam
• Eduroam ermöglicht Mitarbeitern und Studenten von partizipierenden [...]
Organisationen den Internetzugang an den Standorten aller
teilnehmenden Organisationen unter Verwendung ihres eigenen Benutzernahmen und Passwortes [aus Wikipedia]*
• Verbreitung [https://www.eduroam.org/where/]
Praxisbeispiel: eduroam
!
Weltweites Roaming in Hochschul-(WLAN-)Netzen
!
802.1X mit RADIUS-Authentifizierung an der jeweiligen Heimathochschule
Bildquelle: eduroam.be
Eduroam Funktionsweise
Eduroam Funktionsweise
Eduroam Funktionsweise
Eduroam-Sicherheit
• Fake Access Points (eduroam-spoofing)
- AP strahlt eduroam aus und simulieren Radius-Server - Gefahr Nutzerdaten und Passwörter abzugreifen
• Einfach zu erkennen durch Prüfung der Zertifikate, aber
- Ältere Android Version prüfen Zertifikate nicht (richtig)
- Konfigurationsfehler können dazu führen das Zertifikate nicht geprüft werden
• Zur Konfiguration immer das Configuration Assistant Tool (CAT) verwenden
- https://cat.eduroam.de
City-WLAN in München
!
Stadtwerke München (SWM) betreiben zusammen mit M- net „M-WLAN“
!
Eduroam wurde im April 2014 freigeschaltet
!
Alle APs erhalten eduroam
City-WLAN in München
[
https://monitoring.mwn.de/maps/wlan/]
EoC was braucht der Provider ?
• Deutsches Forschungsnetz (DFN) unterstützt EoC
- eduroam-Anbietervereinbarung mit dem DFN: regelt technische und organisatorische Randbedingungen
- kostenfrei
- Access Points
- Multi-SSID Fähigkeit: müssen (zus.) SSID „eduroam“ ausstrahlen - 802.1x mit WPA2 als Authentisierungsverfahren
- Anfragender Radius-Server beim DFN (Deutsches Forschungsnetz)
• Radius-Server Verbund
- Installation eines „radsecproxy“ (kostenfreie Software) - Musterkonfiguration und Dokumentation sind vorhanden
- Anbindung an den Verbund über ein Zertifikat des DFN (kostenlos)
