Modul: VI LV-06

Transkript

1 VPN: wired and wireless Fachbereich Informatik (FB 20) Fachgruppe: Security Engineering Modul: VI LV-06 er Skriptum und Literatur: Wolfgang BÖHMER, TU-Darmstadt, Hochschulstr. 10, D Darmstadt, Dep. of Computer Science, Security Engineering Group

2 Wichtige Information zur Vorlesung und den Übungen Ziel der Vorlesung/Übungen Freiwilliges Lernen Gute und ruhige Lernatmosphäre Hausordnung während der Vorlesung 1. Mobiltelefone sind auszuschalten 2. Laptops können angeschaltet sein, um die Vorlesung zu verfolgen 3. Keine Privatgespräche mit Kommilitonen in der Vorlesung 4. Kein Essen (auch nicht vegetarisch) 5. Keine Verspätung Folie 2

3 Vorlesungsinhalt LV-06 VPN Authentifizierungsverfahren in der Praxis PPP-Verbindung als Voraussetzung für PAP und CHAP Die AAA-Sicherheitsarchitektur Radius/openRADIUS und TACAS+ DIAMETER Kerberos VPN Architekturen und Einsatzszenarien Übungen Literatur Folie 3

4 PPP-Verbindung als Voraussetzung für PAP und CHAP Point-to-Point Protocol bietet die Möglichkeit IP-Datagramme über eine serielle Leitung zu schicken. (RFC-1661) Es gibt mittlerweile zahlreiche Erweiterung und Ergänzungen PPP ist ein Standard-Verfahren zur Übertragung von Protokoll- Informationen innerhalb der Network-Layer (Kapselung) Im Wesentlichen drei Komponenten Verfahren zum Einpacken der IP-Datagramme über serielle Leitungen Link Control Protocol (LCP) zum Aufbau, Konfiguration und Test einer Layer-2-Verbindung Familie von Network Control Protocols (NCP) zur Etablierung und Konfigurierung verschiedener Network-Layer-Protokolle (BCP, IPCP, IPXCP) PPP-Session erfolgt in drei Phasen 1. Aufbau einer PPP-Leitung durch Austausch von LCP-Paketen zwischen Peers zur Konfig. und Prüfung der Verbindung 2. LCP-Pakete handeln zwischen den Peers die Maximum Recieve Unit (MRU) aus 3. Optionale Authentifizierung je nach Parameter (PAP,Chap) muss abgeschlossen bevor NCP aktiviert wird. Folie 4

5 Passwort Authentication Protocol (PAP) Zwei-Wege-Handshake Protokoll nach RFC-1334 Einsatz beim Verbindungsaufbau zwischen Endgerät und Provider (ISP) Kennung und Passwort werden im Klartext über das Netz geschickt. Keine Unterbindung bei Missbrauch (Replay-Attack) Initiative ergreift der Client Austausch zwischen zwei Peer-Instanzen Befehlssequenz eines Cisco AS5200 Router ppp authentication {chap chap pap pap chap pap} [if needed] [listenname default callin one-time] Folie 5

6 Challenge-Handshake Authentication Protocol (CHAP) CHAP-Protokoll wird in der Aufbauphase einer PPP-Verbindung genutzt Es findet eine wechselseitige Authentifizierung beider Kommunikationssysteme statt. Es wird kein Passwort direkt ausgetauscht, sondern ein dreistufiges Authentifizierungsprotokoll (Frage-Antwort- Sequenz) MD5 als Einweg-Hashfunktion wird eingesetzt um die Integrität beim Challenge-Response sicherzustellen. Die Frage-Antwort-Sequenz wird vom Authentifizierungsserver ausgelöst und nicht vom Client (anders bei PAP) CHAP als auch PAP haben den Nachteil, dass die Passwörter auf Nutzer und auf Server-Seite in einer Datenbank abgelegt werden müssen Es lassen sich mit CHAP und PAP keine unterschiedlichen Netzwerk-Rechte (Privilegien) vergeben (Problem SOHO-Lösung) Folie 6

7 CHAP-Handshake-Protokollauszug (i) Verbindungsaufbau vom ppp-client, initiiert durch ein ping-paket: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jun 9 10:45:02 linux kernel: OPEN: > ICMP Jun 9 10:45:02 linux kernel: ippp0: dialing 1 XXXXXXXXXXX... Jun 9 10:45:02 linux isdnlog: Jun 09 10:45:02 * tei 100 calling PPP_Server with PPP_Client RING (Data) Jun 9 10:45:02 linux isdnlog: Jun 09 10:45:02 tei 100 PPP_Server with PPP_Client Time:Sun Jun 9 10:45: Jun 9 10:45:02 linux isdnlog: Jun 09 10:45:02 tei 100 calling PPP_Server with PPP_Client INTERFACE ippp0 calling XXXXXXXXXXX Jun 9 10:45:02 linux isdnlog: Jun 09 10:45:02 tei 100 calling PPP_Server with PPP_Client CONNECT (Data) Jun 9 10:45:03 linux kernel: isdn_net: ippp0 connected Aushandeln der Verbindungsparameter: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jun 9 10:45:03 linux ipppd[258]: Local number: XXXXXX, Remote number: XXXXXXXXXXX, Type: outgoing Jun 9 10:45:03 linux ipppd[258]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 2, linkunit: 0, fd: 7 Jun 9 10:45:03 linux ipppd[258]: sent [0][LCP ConfReq id=0x1 <mru 1524> <magic 0x8cd703b8> <pcomp> <accomp>] Jun 9 10:45:03 linux ipppd[258]: rcvd [0][LCP ConfReq id=0x1 <mru 1524> <auth chap md5> <magic 0x3e5abaa1> <MPmrru 1500> <MPdiscr: 0x4 [ ]>] Jun 9 10:45:03 linux ipppd[258]: sent [0][LCP ConfRej id=0x1 <MPmrru 1500>] Jun 9 10:45:03 linux ipppd[258]: rcvd [0][LCP ConfRej id=0x1 <pcomp> <accomp>] Jun 9 10:45:03 linux ipppd[258]: sent [0][LCP ConfReq id=0x2 <mru 1524> <magic 0x8cd703b8>] Jun 9 10:45:03 linux ipppd[258]: rcvd [0][LCP ConfReq id=0x2 <mru 1524> <auth chap md5> <magic 0x3e5abaa1> <MPdiscr: 0x4 [ ]>] Jun 9 10:45:03 linux ipppd[258]: sent [0][LCP ConfAck id=0x2 <mru 1524> <auth chap md5> <magic 0x3e5abaa1> <MPdiscr: 0x4 [ ]>] Jun 9 10:45:03 linux ipppd[258]: rcvd [0][LCP ConfAck id=0x2 <mru 1524> <magic 0x8cd703b8>] Jun 9 10:45:03 linux ipppd[258]: lcp layer is UP Folie 7

8 CHAP-Handshake-Protokollauszug (ii) Die Authentifizierung mittels Challenge-Response: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jun 9 10:45:03 linux ipppd[258]: rcvd [0][CHAP Challenge id= 0x3b <107b4b0eab2fa a546a7d84960b9e681e82cfef86282ee0efea47cb8d255sf338b7c35>, name = "server"] Jun 9 10:45:03 linux ipppd[258]: ChapReceiveChallenge: Rcvd id 59. Jun 9 10:45:03 linux ipppd[258]: ChapReceiveChallenge: received name field: 'server' Jun 9 10:45:03 linux ipppd[258]: sent [0][CHAP Response id=0x3b <3f e d904344f5b76>, name = "client"] Jun 9 10:45:03 linux ipppd[258]: rcvd [0][CHAP Success id=0x3b "Welcome to server."] Jun 9 10:45:03 linux ipppd[258]: ChapReceiveSuccess: Rcvd id 59. Jun 9 10:45:03 linux ipppd[258]: Remote message: Welcome to server. Aushandeln der IP-Adressen: ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jun 9 10:45:03 linux ipppd[258]: MPPP negotiation, He: No We: No Jun 9 10:45:03 linux ipppd[258]: sent [0][IPCP ConfReq id=0x1 <addr > <compress VJ 0f 01>] Jun 9 10:45:03 linux ipppd[258]: CCP enabled! Trying CCP. Jun 9 10:45:03 linux ipppd[258]: CCP: got ccp-unit 0 for link 0 (Compression Control Protocol) Jun 9 10:45:03 linux ipppd[258]: sent [0][CCP ConfReq id=0x1 <LZS (RFC) hists 8 check 3] Jun 9 10:45:03 linux ipppd[258]: rcvd [0][IPCP ConfReq id=0x1 <addr >] Jun 9 10:45:03 linux ipppd[258]: sent [0][IPCP ConfAck id=0x1 <addr >] Jun 9 10:45:03 linux ipppd[258]: rcvd [0][IPCP ConfRej id=0x1 <compress VJ 0f 01>] Jun 9 10:45:03 linux ipppd[258]: sent [0][IPCP ConfReq id=0x2 <addr >] Jun 9 10:45:03 linux ipppd[258]: rcvd [0][LCP ProtRej id=0x3 80 fd ] Jun 9 10:45:03 linux ipppd[258]: rcvd [0][IPCP ConfAck id=0x2 <addr >] Jun 9 10:45:03 linux ipppd[258]: local IP address Jun 9 10:45:03 linux ipppd[258]: remote IP address Folie 8

9 AAA-Sicherheitsarchitektur Funktion eines Framework, mit drei unabhängigen Sicherheitsfunktionen die konsistent konfiguriert werden können Authentication: The process of validating the claimed identity of an end user or a device, such as a host, server, switch, router, and so on. Authorization: The act of granting access rights to a user, groups of users, system, or a process. Accounting: The methods to establish who, or what, performed a certain action, such as tracking user connection and logging system users. Quelle: Cisco Folie 9

10 AAA-Beispiel (Auszug) Cisco-Router show running-config ! Building configuration... Current configuration : 7019 bytes!! Last configuration change at 12:47:44 CET Fri Nov by ul03036! NVRAM config last updated at 12:40:50 CET Fri Nov by ul03036! version 12.1 no service single-slot-reload-enable no service pad service timestamps debug datetime localtime service timestamps log datetime localtime service password-encryption! hostname tfrr3115hsrz02! logging buffered debugging logging rate-limit console 10 except errors aaa new-model aaa authentication login default group tacacs+ local aaa authentication login console group tacacs+ enable aaa authentication enable default group tacacs+ enable aaa authentication ppp default local aaa authorization exec default group tacacs+ local aaa authorization commands 1 default group tacacs+ local aaa authorization commands 15 default group tacacs+ local aaa accounting update newinfo aaa accounting exec default start-stop group tacacs+ aaa accounting commands 1 default start-stop group tacacs+ aaa accounting commands 15 default start-stop group tacacs+ enable secret 5 <removed>! username genotel password 7 <removed> clock timezone CET 1 clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00 ip subnet-zero no ip source-route! no ip finger no ip domain-lookup interface Tunnel0 description Tunnel NCP-Gateway1 ip unnumbered FastEthernet0/0 tunnel source tunnel destination ! interface Tunnel1 description Tunnel NCP-Gateway2 ip unnumbered FastEthernet0/0 tunnel source tunnel destination !!... ip nat pool nat netmask ip nat inside source list 101 pool nat-1 overload ip classless ip route ip route ip route ip route ip route ip route ip route ip route ip route ip route ip route ip route ip route ip route ip route ip route ip route ! logging logging logging access-list 2 permit access-list 2 permit access-list 2 permit access-list 2 permit access-list 2 deny any linkup coldstart warmstart Folie 10

11 Remote Authentication Dial-In User Service (RADIUS) Client-Server-Architektur RADIUS-Server stellt einen Dämon-Prozess dar Verbindung zwischen NAS und Client basiert auf UDP Es werden folgende Schritte bei einer RADIUS Authentifizierung ausgeführt: 1. Der Benutzer wird zur Eingabe einer ID und eines PWD aufgefordert. 2. Die ID und das verschlüsselte PWD wird gemeinsam über das Netzwerk an den Radius- Server geschickt. 3. Die ID empfängt eine spezielle Nachricht vom RADIUS-Server (accept, reject, challenge, Change PWD). Folie 11

12 Vergleich RADIUS und TACACS RADIUS TACACS RADIUS setzt UDP ein TACAS+ setzt TCP/IP ein RADIUS verschlüsselt nur das Passwort in einer AAA-Anfrage. TACACS+ verschlüsselt das gesamte Paket für eine AAA-Anfrage RADIUS kombiniert Authentifizierung und Autorisation TACACS+ nutzt eine vollständige AAA-Architektur, die die AAA auch getrennt behandeln kann RADIUS unterstützt kein ARA-Zugriff, Netbios, Frame Protocol Control Protocol, NASI und X.25 PAD- Verbindung TACAS+ bietet die volle Multiprotokollunterstützung RADIUS bietet einem Nutzer keine Unterstützung zur Befehlskonfiguration bei Routern TACACS+ bietet zwei Möglichkeiten der Befehlskonfiguration an Entspricht einem Industriestandard (RFC-2138) CISCO firmenspezifisch (RFC-1492) Folie 12

13 AAA-Beispiel in einer realen Umgebung (RADIUS) Basis - komponenten Kunde Tools Institut RAS User ISDN/PSTN/GSM Internet Persönl. Zertifikat (Soft - o. SmartCard ) Entelligence Client Benutzertelefonbuch Basistelefonbuch NCP - Client RAS Access - Router Firewall L2 Netzinfrastruktur RAS NCP - Gateway VPN Service Radius Accounting Server DirX LDAP DirX - Server Directory Service Update Server (Telefonbuch) Tool Access - Router Admin Firewall Management NCP Client Configuration Manager Tool Radius Admin DirX Manager NCP Client Configuration Manager CA Zertifikats Server DMZ RA LRA Router Institut Tool Router Admin Firewall externe Partner DZ A-Bank Versich R+V Geno RZ - RZ Folie 13

14 DIAMETER und Mobile Dial-In Weitere AAA-Architektur RADIUS für mobile Dial-In ungeeignet. Authentifizierungsanfragen (Credentials) eines Users werden weiter gereicht. Kennzeichen des DIAMETER Protokoll SCTP ersetzt UDP Keep-alive Nachrichten Peer-to-Peer ersetzt Client/Server Zeitstempel für Nachrichten IPSec und TLS eingerichtet CMS ermöglicht End-to-End Security USER Visit ISP AAA Server NAS Home ISP AAA Server Folie 14

15 DIAMETER Architektur Wortspiel zu RADIUS DIAMETER Base Protokoll als AAA- Architektur, Schnittstellen über AVPs Applikationen Network Access REQuirements (NASREQ) zur Skalierbarkeit, Ressource Management, Erweiterung für zukünftige Technologien. Mobile IPv4, eine bessere Skalierbarkeit der Security Associations, Mobilität über die Domain-Grenzen hinweg und dynamisches Home-Agent Verfahren EAP Unterstützung NASREQ Application Mobile IP Application Mobile IP v6 Application weitere Application DIAMETER Base Protocol CMS Attribute Value Pairs (AVP) Folie 15

16 DIAMETER Protokolleigenschaften Verlässliche Transport-Protokolle (TCP oder SCTP) Verschlüsselung mit IPSec oder TLS(SSL) Der 32-Bit-AVP-Adressraum (engl.: attribute value pairs) ermöglicht mehr als 256 verschiedene Attribute, d.h. authentifizierbare Entitäten Zustandsbehaftete und zustandslose Modelle können benutzt werden Dynamisches Entdecken von Teilnehmern (DNS, SRV* und NAPTR**) Verhandlungsmöglichkeiten Fehlerbenachrichtigung Bessere Roaming-Unterstützung Leichte Erweiterbarkeit - neue Befehle und Attribute können definiert werden Basisunterstützung für Benutzersitzungen und Abrechnungen **(Naming Authority Pointer) Resource Records *SRV (Service) Resource Records Folie 16

17 Das Netzwerk- Authentifizierungsverfahren Kerberos Kennzeichen: 1. Keine Schlüssel werden übers Netz geschickt 2. Kerberos kennt die geheimen Schlüssel seiner Principals 1. Nutzer C meldet sich an seinem Computer an und fordert ein Dienst vom KDC mittels Ticket an. C->AS: Idc, Realmc, Idtgs, TS1, Nonce 2. Prüfung der Eingangsdaten gegenüber der Datenbank im KDC.Ausstelung eines Ticket- Granting Ticket AS->C: Realmc, Idc, Tickettgs, Ekc{Kc,tgs,TS2, Realmtgs, IDtgs} 3. Entschlüsselung der Daten bei C und Ausnutzung des Ticket zur Beantragung eines Dienstes 4. Verifikation bei C 5. Es liegen alle Anmeldeparameter bei C vor. Nun schickt C eine Nachricht zum Appl.-Server um den eigentlichen Dienst anzufordern. 6. Appl.-Server (SV) schickt zur Eröffnung des Appl.-Dialog s Folie 17

18 VPN-Einsatzsenarien Intranet-VPN Extranet-VPN Remote-Access-VPN Internet/Andere Öffentliche Netze Firma Firmenfiliale Partnerunternehmen Netzwerkanbieter (NSP) Mobiler Mitarbeiter Folie 18

19 VPN-Lösungen im Schichtenmodell Applika tio ns-la ye r Ve rschlüsse lung Applikationsebene (5-7) Transport/ Netzwerkebene (3-4) Ne tzwe rk-la ye r Ve rschlüsse lung Link/Physikalischeebene (1-2) Link-Layer Ve rschlüsse lung Link-Layer Ve rschlüsse lung Applikationen TCP/UDP (Transport) - S/MIME, PGP - Proxy Server - Content Screening - Virus Scanning - PKI - Kerberos, Radius - IPSEC (IKE) - SOCKS V5 - SSL, TLS IP (Internetwork) - IPSEC (AH, ESP) - Paket Filtering - NAT Network Interface (Data Link) - CHAP, PAP, MS-CHAP - Tunneling Protokolle (L2TP, PPTP, L2F) Folie 19

20 VPN-Gateway nach der Firewall Firewall kann eingehende verschlüsselte Pakete nicht analysieren und filtern LAN Firewall kann nicht erkennen, an welche Rechner oder Ports die verschlüsselten Pakete gerichtet sind. VPN- Gateway Virenfilter und Mail-Gateways habe Schwierigkeiten mit dieser Konstellation Firewall Probleme bei NAT bzw. Masquerading und einer Firewall wenn ein IPSec- Gateway mit AH betrieben wird Eventuell Probleme mit ESP und ISDN- Router und DSL-Router Internet VPN- Clients Folie 20

21 VPN-Gateway und Firewall auf demselbem System All-in-One-Lösung LAN BSI rät ab von dieser Lösung, da jeder zusätzliche Dienst auf der Firewall die Sicherheit beeinträchtigt z.b. Checkpoint-Lösung hat ein Modul direkt auf der Firewall implementiert Sicherheitstechnisch sinnvoll, VPN- Gateway völlig aus dem Einflußbereich des LAN und der Firewall zu entfernen (DMZ) Firewall + VPN Internet VPN- Client LAN Firewall + VPN Folie 21

22 VPN-Gateway über Netzwerkkarte mit der Firewall verbunden und steht in der DMZ IP-Forwarding muss freigeschaltet sein UDP-Port 500 muss für IKE geöffnet sein IP-Protokollnummern 50 (ESP) und 51 (AH) müssen geöffnet werden UDP-Port 1701 für L2TP und L2F muss geöffnet werden IP-Protokollnummern 47 (GRE) und 1723 (TCP) muss offen sein Firewall LAN VPN- Gateway Kritik: alle Prüfungen die zuvor auf der Firewall durchgeführt wurden, müssen nun auf dem VPN-Gateway durchgeführt werden (Fehlkonfigurationen möglich) Internet VPN- Clients Folie 22

23 VPN-Gateway vor der Firewall in einer DMZ mit zusätzlichen Router Vorteilhafte Konstellation, in dem ein Router den ein- und ausgehenden Verkehr bewacht. VPN findet Schutz hinter dem Router Firewall LAN VPN- Gateway Nur bestimmte IP-Pakete werden weitergeleitet Vom VPN-Gateway entschlüsselte IP-Pakete müssen noch die Firewall passier (Virenprüfung, -Kontrolle) Router Es wird sichergestellt, dass keine lokalen Sicherheitsregeln unterlaufen werden Internet VPN- Clients Folie 23

24 Übungen zur Vorlesung VPN Virtual Private Networks ÜBUNGEN LV-06 Folie 24

25 Übungen-LV-06-Ü01 1. Wie kann eine PPP-Verbindung beim Aufbau abgesichert werden? 2. Welche Unterschiede gibt es zwischen PAP und CHAP? 3. Welches Protokoll ist i.d.r. zu bevorzugen PAP oder CHAP? 4. Welche Unterschiede gibt es zwischen MS-CHAP und CHAP? 5. Welche Protokolle bieten eine komplette Tripel-A Unterstützung? 6. Welches sind die Nachteile von RADIUS gegenüber DIAMETER? 7. Warum kann RADIUS kein Mobile IP unterstützen? 8. Was beinhalten die AVPs, speziell das R-Flag für Mobile IP? Falls Sie eine Übung einreichen möchten, dann bitte in der folgenden Nomenklatur für die Datei LV06-Ü01-Name.pdf Folie 25

26 Literatur Huston G.: Internet Performance Survival Guide, QoS Strategies for Multiservice Networks, ISBN Comer, 1995: Internetworking with TCP/IP Vol. I., ISBN ITU-T Recommendation Series X: Data Networks and Open System Communications, Directory X.509 (03/2000) ITU-T Recommendation Series X: Data Networks and Open System Communications, Directory X.500 (02/2001) Aurand, A.: Sicherheit in CISCO- und Windows-2000-Netzwerken, Addison- Wesley-Verlag, ISBN , 2001 CISCO IOS 12.0 Network Security, CISCO Dokumentation, Verlag Markt&Technik, 2000, ISBN Stempfle, C.:RADIUS und Diameter, Seminar Mobilkommunikation SS2005 Folie 26