Zusammenfassung der Vorlesung IntSi 12. Januar 2008 Zusammenfassung der Vorlesung und der wichtigsten Punkte aus den Übungen. Inhaltsverzeichnis 1 2 Verletzlichkeiten 4 1.1 4 Risiko 2.1 2.2 2.3 2.4 2.5 3 5 6 7 Formel . . . . . . . Bedrohungen . . . The Hackers Cycle TEMPEST . . . . Ressourcen . . . . 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schutzmassnamen 3.1 4 CIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Übersicht aka DIE 5 REGELN!! 4 4 4 4 4 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 MitM - Man in the Middle 5 4.1 4.2 5 5 ARP-Poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DNS-Poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Testing 6 5.1 6 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Gathering 6 6.1 6.2 6.3 6 6 6 Footprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sniffer Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Windows-Networking 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 Ziele . . . . . . . . . . . . . . . . . . . . Netzwerktypen . . . . . . . . . . . . . . Windows Networks Resource Identifier . NetBios . . . . . . . . . . . . . . . . . . WINS . . . . . . . . . . . . . . . . . . . NET-Command . . . . . . . . . . . . . . SMB/CIFS . . . . . . . . . . . . . . . . NetworkProtocolStack vs. NetBIOS over 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 7 7 8 8 8 8 Inhaltsverzeichnis 8 Crypto Basics 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 9 ZF IntSi 9 Ziele . . . . . . . . . . . . . . . . . . . . . . . Möglichkeiten der geheimen Kommunikation . Design Regeln . . . . . . . . . . . . . . . . . . Annahmen über den Angreifer . . . . . . . . Sicherheit eines Krypto-Algorithmus . . . . . Einschub Informationstheorie . . . . . . . . . Redundanz . . . . . . . . . . . . . . . . . . . Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Krypto 9.1 9.2 9.3 9.4 9.5 10 Ziele . . . . . . . . . . . . . Symmetrische Verfahren . . Asymmetrische Verfahren . Hybride Systeme . . . . . . Meet-in-the-Middle-Attacke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Überprüfen von Schlössern Key verteilen . . . . . . . zentralisiertes Vertrauen . Web of Thrust . . . . . . Registrierungsprozess . . . Zertifizierungsklassen . . . Enrolment . . . . . . . . . Revocation . . . . . . . . Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Signaturen 10.1 10.2 10.3 10.4 10.5 10.6 12 Mail-Security Email-Rep . . . . . . Chat: Mail Security . Email Signatur . . . Ressourcen . . . . . 14 14 14 15 15 15 15 16 16 16 16 . . . . . . . . 13 PKI HSR ’07 12 12 13 13 13 13 14 11.1 Ziele . . . . . . . . . . . . 11.2 Transport Layer Security 11.3 Anwendungen . . . . . . . 11.4 Funktionsweise . . . . . . 11.5 CIA . . . . . . . . . . . . 11.6 Ablauf Verbindungsaufbau 11.7 Protokoll . . . . . . . . . 11.8 SSL Proxy . . . . . . . . . 11.9 VPN over SSL . . . . . . 11.10Ressourcen . . . . . . . . 13.1 13.2 13.3 13.4 13.5 13.6 13.7 13.8 13.9 10 10 11 12 12 12 Ziele . . . . . . . . . . . . . Die Unterschrift . . . . . . . Signatur vs. Verschlüsselung DSS . . . . . . . . . . . . . Rechtlage . . . . . . . . . . Hash . . . . . . . . . . . . . 11 SSL 12.1 12.2 12.3 12.4 9 9 9 9 9 10 10 10 16 16 16 17 17 17 17 17 17 17 18 18 19 19 2 - 29 Inhaltsverzeichnis ZF IntSi 14 IAM 14.1 14.2 14.3 14.4 14.5 14.6 14.7 14.8 19 AAA . . . . . . . . . . . . . . . . Sicherheitsmechanismen . . . . . Login . . . . . . . . . . . . . . . Challenge / Response Protokolle NTLM . . . . . . . . . . . . . . . Kerberos . . . . . . . . . . . . . . Starke Passwörter . . . . . . . . Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 SSH 23 15.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2 Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3 Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 IKE 16.1 16.2 16.3 16.4 23 24 24 25 Phase 2 - Quick Mode . . . . Zukunft: IKEv2 . . . . . . . . VPN Applications . . . . . . wünschenswerte VPN features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Firewalls 25 25 26 26 26 17.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2 Netfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HSR ’07 19 19 19 20 20 21 22 22 26 27 3 - 29 1 Verletzlichkeiten Asset(Werte) Threads Vulnerability ZF IntSi Tabelle 1: Gefährdungen etc. Beispiele Mögliche Massnahmen Inhalt, Privatsphäre Sichern Angriff, Fehlverhalten nicht exponieren Bewusstsein, Schutzmechanismen Schutzmassnahmen, Ausbildung 1 Verletzlichkeiten 1.1 CIA Confidentiality gesicherter Zugriff, niemand unbefungtes liest mit Integrity gesicherter Zustand, niemand ändert etwas, Absender und Empfänger sind fix Availability gesicherte Verfügbarkeit 2 Risiko 2.1 Formel Risiko = Schaden * WSK Zwischenfall = Schaden * Bedrohung * Verletzlichkeit 2.2 Bedrohungen Informationen werden durch Sicherungsmassnahmen geschützt. Gefahr droht auf die Sicherungsmassnahmen durch Bedrohungen (threads) wie Hard/Software-Defekt, Umwelteinflüsse oder z.B. ein Backup das nie zurückgespielt wurde und deshalb nicht umbedingt funktionieren muss. Auf die Information selber wirkt insofern eine Gefahr, als Anwender sie misshandeln oder gewollt/ungewollt fremden zugänglich machen. 2.3 The Hackers Cycle Eine Verletzlichkeit macht i.d.R. folgenden Prozess durch. 1. Wird durch Insiderwissen bekannt. Tage...Jahre vergehen 2. Verletzlichkeit wird allgmein bekannt. Sog. Hacker-Phase 3. Verfügbarkeit von Exploits und Tools um Leck zu Nutzen. Sog. Script-Kiddy-Phase 2.4 TEMPEST Möglichkeit, Informationen aufgrund von Elektromagnetischer Abstrahlung eines Gerätes (CRT, LCD Monitor) wiederherzustellen. Kann verhindert werden. Mit grossem Kostenaufwand. • Telecommunications Electronics Material Protected from Emanating Spurious Transmissions • Transient Eletromagnetic Pulse Emanation Standard 2.5 Ressourcen 2.5.1 CERT Computer Emergency Response Team http://www.cert.org/ 2.5.2 NVD National Vulnerability Database http://nvd.nist.gov/ HSR ’07 4 - 29 3 Schutzmassnamen ZF IntSi 2.5.3 Weitere wichtige Ressourcen - System Administration, Networking and Security Institute http://www.sans.org/[top20/] - Security Focus http://www.securityfocus.com/ - NTBugtraq! http://www.ntbugtraq.com/ - Counterpane http://www.counterpane.com/ - Microsoft Security Notification Service http://www.microsoft.com/technet/security - Whitehats.org http://www.whitehats.com/ - Heise Online Security http://www.heise.de/security/ - Institute for Security and open Methologies http://www.isecom.org/ 3 Schutzmassnamen 3.1 Übersicht aka DIE 5 REGELN!! 1. Organisieren; Schwachtellen klären, ausbilden, sensibilisieren etc. 2. Sichern; verschlüsseln, verdoppeln etc. 3. Filtern; Datenfilter (Switch, Router, FW), Zugangssicherung 4. Kombinieren; multi-level, in-depth security 5. Überprüfen; IDS, Honey-Pot etc. 4 MitM - Man in the Middle 4.1 ARP-Poisoning Möglich wird das ARP Poisoning dadurch, dass das ARP-Protokoll scheinbar wahllos Antworten mit Informationen aufnimmt und die eigene ARP-Table damit verändert. • Würde nun ARP nur Antworten entgegennehmen, wenn es zuvor um eine solche Auskunft (ARPRequest) angefordert hat, könnte man zwar die Gefahr einschränken, aber der Angreifer könnte auch auf eine Anfrage warten und dann die Antwort generieren lassen. • Stationen, welche nur als Relais (MITM) agieren könnte man als solche zwar identifizieren, aber nicht eindeutig. • Der Switch könnte auch Antworten blocken, solange sie ohne eine solche Anfrage gesendet werden. [Optimum] 4.1.1 Konsequenzen Durch das Spoofing kann man entweder einen Man-In-The-Middle Attack durchführen, oder aber lediglich für einen art von DOS Attacke sorgen, wobei jenes eigentlich nur vorgetäuscht wird. 4.2 DNS-Poisoning Wie auch ARP-Replies können DNS-Query-Responses “gefaked” werden. In einem Netz mit Bus-topologie kann das Ziel mit den falschen Informationen direkt versehen werden, ist eine Stern-Topologie vorhanden, muss zuerst erfolgreich ein MitM gestartet werden um die falschen Informationen gewinnbringend an den Mann zu bringen. HSR ’07 5 - 29 5 Security Testing ZF IntSi 5 Security Testing 5.1 Voraussetzungen Voraussetzung für einen Sicherheitsanalysten sind • kritisches Denken • gute Beobachtungsgabe, ausdauer • starke analytische Fähigkeiten Quelle: isecom, siehe http://www.isecom.org/ 6 Information Gathering 6.1 Footprinting 6.1.1 Quellen • Suchmaschinen - allgemeine Suchmaschinen aller art - Vulnerabilities Databases - Hacker-Sites, News-Groups, Foren • whois • DNS data records • Social Engineering 6.2 Fingerprinting 6.2.1 Werkzeuge • ping (standard icmp-request) • ping sweep (fping, nmap, hping) • ping -r • traceroute Folgende Werte sind aufschlussreich für Fingerprinting des OS: - TTL-Werte die unterschiedlich sind - Sequenznummern 6.2.2 Quellen • Public Information • Sozial engineering (Websites) • DNS Host info records • Banner • SNMP, port 161 • Stack fingerprinting 6.3 Sniffer Detection Wie verhindere ich die detection meines Sniffers?! - Transceive-Leitungen kappen... Weil die Antwortzeiten ungewöhnlich lange sein können HSR ’07 6 - 29 7 Windows-Networking ZF IntSi 7 Windows-Networking 7.1 Ziele • verstehen des Protocol-Stacks • das “Network Operating System” verstehen • basic Windows Networking Kommmandos verstehen 7.2 Netzwerktypen Workgroup Arbeitsgruppe von Rechnern auf Basis von SMB. Samba ist die OpenSource Version dazu. alte structurierte Netze Haben meist einen PDC und BDC (Geschichte). Samba, Netware, Baynes. neue strukturierte Netze AD: Baumartige Strukturierung mittels dieser Datenbank möglich. 7.3 Windows Networks Resource Identifier 7.3.1 UNC Universal Naming Convention um auf Ressourcen zuzugreifen. 1 \\ servername \ accessname \ path 2 3 4 5 6 \\ servername accessname path Externe Ressource NetBios , WINS , DNS , IP - Adr . max 15 chars Computername , max . 260 chars sofern nicht anders adressierbar 7.4 NetBios • Eigentlich 16Byte, aber das letzte ist der Ressource-Type • Case insensitive • flacher Namespace WINS löst NetBios Namen in IP-Adressen um. NetBios notwendig unter Windows bis Windows98. 7.4.1 Namens, Addresauflösung Nodes: • B-Nodes : über BC (UDP) wird Name verteilt, und Addressen gesammelt, auch möglich über LMHOSTS - File • P-Nodes: Peer, verwendet WINS oder NetBIOS Name Server, registriert sich auch da. • M-Nodes: Zuerst über BC, dann einen WINS ode NetBIOS Server. • H-Nodes: Hybrid, verwendet zuerst WINS und im Fehlerfall BC. 7.4.2 Reihenfolge der Suche Reihenfolge Namensauflösung: 1. im Cache 2. WINS Server Fragen 3. MAC-BC 4. LMHOST-File 5. .hosts (Seit Windows2000) HSR ’07 7 - 29 7 Windows-Networking ZF IntSi 7.4.3 Statistiken 1 NBSTAT [[ - a RemoteName ][ - A IP address ][ - c ][ - n ][ - r ][ - R ][ - RR ][ - s ][ - S ][ intervall ]] 7.5 WINS 7.5.1 Kommunikation Sämtliche Kommunikation läuft über UDP Port 137 7.6 NET-Command Möglichkeiten: NET [ ACCOUNTS — COMPUTER — CONFIG — CONTINUE — FILE — GROUP — HELP — HELPMSG — LOCALGROUP — NAME — PAUSE — PRINT — SEND — SESSION — SHARE — START — STATISTICS — STOP — TIME — USE — USER — VIEW ] 7.6.1 der VIEW Ansatz 1 NET VIEW [\\ Computername [/ CACHE ]/ DOMAIN :[ Domaenenname ]] 7.6.2 Default-Share Böser Standard Share ipc$ . Erlaubte früher Zugriff über user “guest” ohne PW!! Erlaubte remoteshutdown und weitere böse dinge ;-) !! 7.7 SMB/CIFS Ist eigentlich ein Industriestandard, man hat dann versucht einen Internet-standard zum machen. Client/Server Protokoll, wobei diese Zuteilung dynamisch ist. Wenn ich Ressourcen zum freigeben habe bin ich entsprechend Server und sonst eben Client. 7.7.1 Sicherheit Mittels SAMBA ist es leicht machbar, nach klartext-Passswörtern zu fragen. Es ist möglich MITM Attacken zu vermeiden, indem man einen MAC (Message Authentication Code) anfügt. Performance-Verlust dadurch etwa 15%. 7.8 NetworkProtocolStack vs. NetBIOS over TCP/IP Abbildung 1: Aufbau Windows Stack HSR ’07 Abbildung 2: Aufbau Netbios over TCP 8 - 29 8 Crypto Basics ZF IntSi 8 Crypto Basics 8.1 Ziele - DH-erklären können Symmetrische AES,DES erklären können Hashes Geschichte lernen 8.2 Möglichkeiten der geheimen Kommunikation a) Kryptographie (verbergen) b) Substitution (ersetzen) b1) Chiffrierung (Buchstaben) b2) Codierung (Wörter) c Transposition (vertauschen) d) Stenographie 8.2.1 Stenographie Prinzip des verheimlichens, das überhaupt geheime Daten übertragen werden. Beispielsweise kann in einem Bild eines Hasens kann jeweils im LSB ein anderes Bild codiert werden. So kann jeweils durch das auslesen jenes das original“ wieder herausgelesen werden. ” Gewisse amerikanische Druckerhersteller drucken einen Code auf Papier wodurch auf das Gerät, Datum etc. geschlossen werden kann. 8.3 Design Regeln Kerkhoff, 1833: Die Sicherheit von Verschlüsselungsverfahren darf nur von der Geheimhaltung des Schlüssels abhängen, nicht jedoch von der Geheimhaltung des Algorithmus. Shannon, 1949: Alles muss möglichst einer Zufälligen Folge gleichen & ändert man eine Zahl/Position, muss sich möglichst alles ändern 8.4 Annahmen über den Angreifer - er kennt den secret key NICHT - er kennt details des Algorithus - er hat zugriff auf verschiedene Paare von Plain- und Chiffriertem Text (Chosen-plainext-attacks) 8.4.1 Erfolgreiche Attacke?! 56Bit Schlüssel = 256 verschiedene Schlüssel Wie merkt nun der Angreifer, dass er einen gültigen Schlüssel gefunden hat?! Sobald der Klartext Sinn macht. → Wie merkt mann denn das maschinell?! 8.5 Sicherheit eines Krypto-Algorithmus • Ein kryptographischer Algorithmus gilt als sicher, wenn der effzienteste Angriff nicht wesentlich schneller ist als eine Brute-Force Attacke • Die Sicherheit eines Kryptografischen Algorithmus’ hängt dann von der Anzahl der möglichen Schlüssel ab: je mehr Schlüssel desto sicherer!! HSR ’07 9 - 29 9 Krypto ZF IntSi 8.6 Einschub Informationstheorie Formel Informationsgehalt: I(Xi ) = log2 ( 1 )[bit] pi (Je kleiner die W’keit desto grösser der Informationsgehalt) Formel Entropie: H(X) = −sumi {pi ∗ log2 (pi )}[bit/Zeichen] Basis-Umrechnung Logarithmen: logx (y) = log10 (y) log10 (x) Redundanz: Die Differenz zwischen maximal möglichem und mittlerem Informationsgehalt heisst Redundanz. Primitive Checks auf ASCII-Codes: Parity-Bits, ist maschinell überprüfbar. Übrigens siehe Chat in [cryptoBasics] S.27!!!!!!!!!! 8.7 Redundanz Dank der Wahrscheinlichkeitsverteilung der Buchstaben kann man Codes entschlüsseln!! Dies wurde lange nicht bemerkt, ist heute aber mit Statistiken für Englisch, Deutsch etc. bestens bekannt. Eingesetzt wird diese Erkenntnis unbewusst im Morse-Alphabet, so ist das E mit nur einem punkt codiert und hat eine Wahrscheinlichkeit von 14%. 8.8 Geschichte 8.8.1 Cäsar-Code Codierung Das Alphabet wird um einen bestimmten wert ’x’ geshiftet, dh. verschoben. Danach werden beim original-Text alle Zeichen durch das enstsprechende Neue ersetzt. Bei einem Shift von 3 z.B. wird ein k mit einem n “codiert”. Decodierung Vorgehen: Häufigstes Zeichen suchen = e“. Danach sucht man das zweite Zeichen, es muss ” ein i“ oder ein n“ sein. Oder man sucht direkt den Shift. ” ” 8.8.2 Vigenère Codierung Tabelle (Quadrat) mit durchgeschiftetem Alphabet ist vorhanden. Klartext wird horizontal oben hingeschrieben, der Schlüssel vertikal links daneben (evtl. wiederholend). Das erste Zeichen des Klartexts und das erste Zeichen des Schlüssels werden codiert, in dem man den Schnittpunkt beider in der Tabelle sucht. Das resultierende Zeichen ist somit Codiert. Dieses Verfahren weiter anwenden bis kein Klartext mehr vorhanden ist. Decodierung Kann nicht ohne weiteres geknackt werden. Schwäche liegt aber in der Autokorrelation. Wird deutlich sichtbar. Die normale Decodierung erfolgt mit dem Schlüssel und der verschlüsselten Folge. Verfahren von oben umkehren. 9 Krypto [cryptoDetail] 9.1 Ziele Grundsätze der symmetischen, asymmetrischen Verfahren verstehen. Die wichtigsten Algorithmen zum diesem Thema kennen. Basis Ver- und Entschlüsselungsverfahren kennen. Selber ver- und entschlüsseln mittels sym- und asymmetrischer Verfahren. 9.2 Symmetrische Verfahren DES, IDEA, CAST, AES, RC4 HSR ’07 10 - 29 9 Krypto ZF IntSi 9.2.1 Stream Cypher Syteme Geht um XOR. Ein zufälliger Schlüssel welcher gleich lang ist wie das zu Verschlüsselnde?! nennt sich one time pad. Mögliche Anwendungen: Block Codes Counter Mode (CTR), Cipher Block Chaining Mode (CBC), Ron’s Code 4 (RC4), Rivest Register Linear Shift Register Systems (LFSR). Max Länge eines Schieberegisters ist: 2L − 1 Weil 0000... führt immer in sich selbst über. Beispiele: GSM A5. 9.2.2 Block Cypher Systeme ECB - Electronic Codebook Mode Problem: gleicher Input vorne ergibt gleinen Output hinten. Man nimmt 64Bit Input und verschlüsselt es mit 64Bit Code verschlüsselt. Wiederholungen/Periodizitäten sind also erkennbar. CBC - Cypher Block chaining Wieder werden 64Bit Input mit 64Bit verschlüsselt. Zusätzlich wird aber mittels eines Initialisierungsvektors eine zusätzliche Sicherheit eingebaut. Dieser Initialisierungsvektor muss beiden Parteien bekannt sein. Wiederum zusätzlich werden die nächsten 64Bit mit dem output der letzten 64Bit verschlüsselt. So werden Periodizitäten/Wiederholungen unkenntlich gemacht!!! Bemerkung: wird 1 Bit fehlerhaft übertragen (dem Empfänger) wird der erste Block zwar Abbildung 3: Funktionsweise CBC Verschlüsselung verfälscht, aber ab dem zweiten Schritt korrigiert sich das System selber. 9.3 Asymmetrische Verfahren Eigentlich PKI Systeme. Wichtigste Vertreter sind RSA (Rivest-Shamir-Adleman), ECC (Elliptic-Curve Cryptography). 9.3.1 Das Schlüsselproblem n2 n2 − n Schlüsselpaare bzw. 2 2 public-Keys. Wobei die public-Keys über einen sicheren Kanal verteilt werden müssen. Das Managen der Schlüssel ist relativ schwierig. Man braucht jeweils 9.3.2 PKI Public Key Infrastruktur (Siehe Wiki). 9.3.3 One-Way-Funktion Grundlegendes in den PKI Systemen. Ein Beispiel dafür ist das multiplizieren zweier grosser Primzahlen. Das Resultat ist einfach eine grosse Zahl. Das zurückrechnen ist dann relativ schwierig. 9.3.4 RSA Vorgehen bei RSA: 1. Bob wählt zwei grosse Primzahlen pB und qB welche geheim sind. Dann berechnet Bob nB = pB ∗ qB wobei nB public ist HSR ’07 11 - 29 10 Signaturen ZF IntSi 2. Bob wählt zufällig einen Verschlüsselungs-Schlüssel eB , sodass eB und (p − 1) ∗ (q − 1) den ggT = 1 haben! 3. Bob berechnet den Entschlüsselungs-Schlüssel wie folgt: dB = eB −1 mod[(pB − 1)(qB − 1)] 4. Bob verschlüsselt Nachricht M : C = M eB mod(nB ) 5. Bob entschlüsselt Code C : M = C dB mod(nB ) 9.3.5 Diffie-Hellmann Diese Herren haben eine Verfahren entwickelt um einen shared-key herzustellen: 1. grosse Primzahl ’p’ finden α < p 2. grosse Zufallszahl YA produzieren 1 3. Berechne EA = αYA ∗ mod(p) 4. EA 5. Patner ’A’ und ’B’ berechnen mittels KAB = EB YA ∗ mod(p) = EA YB ∗ mod(p) HIER FEHLT DAS BERECHNUNGSBEISPIEL AUS DEM SKRIPT [cryptoDetail] S.19 & S.21 9.4 Hybride Systeme Man erstellt einen temporären privaten session key. Die Nachricht wird mit diesem privaten session key verschlüsselt. Den privaten session key mitttels public key Verfahren austauschen. 2 9.5 Meet-in-the-Middle-Attacke Annahme: Angreifer kennt mehrere Cypher-Plaintext-Paare (C/P) Siehe [cryptoDetail] ca. S.42 http://en.wikipedia.org/wiki/Meet-in-the-middle attack 10 Signaturen [cryptoSign] 10.1 Ziele Probleme von normalen (schriftlichen) und digitalen (elektronischen) Unterschriften benennen können. Basics der digitalen Signaturen verstehen. Grundsätzliche Eigenschaften von sicheren Hash-Funktionen erklären können. 10.2 Die Unterschrift 10.2.1 wünschbare Eigenschaften auf einem Dokument 1. Integrität Nach dem unterschreiben kann das Dokument nicht mehr verändert werden (weder durch die unterschreibende Person, doch durch andere), ohne dass dies erkannt würde. 2. Authentizität Die Unterschrift kann zweifelsfrei (überprüfbar) einer bestimmten Person zugeordnet wer- den. Keine andere Person kann das Dokument so unterschreiben. 3. Unleugbarkeit Die Unterschrift beweist, dass der Unterzeichner das Dokument studiert / erstellt hat (er kann dies später nicht abstreiten) 1 http://www-fs.informatik.uni-tuebingen.de/∼reinhard/krypto/German/2.3.2.d.html 2 Beispielsweise HSR ’07 HTTPS 12 - 29 10 Signaturen ZF IntSi 4. Willenserklärend Die Unterschrift kann nur willentlich (bewusst) unter das Dokument gesetzt worden sein. 10.2.2 Elektronische Signaturen • elektronische Signatur - Daten in elektronischer Form, welche den anderen elektronischen Daten beigefügt oder mit jenen verknüpft sind. - dient zur Echtheitserklärung der anderen Daten • fortgeschrittene elektronische Signatur - ausschliesslich dem Inhaber zugeordnet - zur Identifizierung verwendbar - mit den Daten so verknüpft, dass eine nachträgliche Veränderung der Daten erkannt werden kann. • qualifizierte elektronische Signatur - beruht auf einer sicheren Signaturerstellungseinheit - beruht auf einem gültigen Zertifikat 10.3 Signatur vs. Verschlüsselung Bei der Verschlüsselung wird ein Text o.ä. von Bob mit dem öffentlichen Schlüssel von Alice verschlüsselt und versendet. Alice entschlüsselt den Text mit ihrem privaten Schlüssel. Kommt was sinnvolles raus ist die Authentizität garantiert. Bei der Signatur wird ein Textblock mit einer Signatur verschlüsselt und hinten an den Plaintext angehängt. Der Verschlüsselte Teil wird entschlüsselt und mit dem Plaintext verglichen. Stimmt dann halt überein oder nicht. 10.4 DSS Digital Signature Standard. Wird auf Basis von DSA realisiert. Seit 2000 in dieser Form bekannt. 10.5 Rechtlage 10.5.1 Handunterschrift - Text ist veränderbar + Unterschrift wird bewusster wahrgenommen. 10.5.2 Digitalte Unterschrift - Der Nachweis, dass mann NICHT unterschrieben hat, muss vom unterzeichner kommen, und nicht mehr von dem, der die Echtheit anzweifelt. + Schwer zu verändern 10.6 Hash Betrachtung der Hashes im Bezug auf die digitalen Signaturen. MAC = Message Authentication Code, keyed message Digest verwenden noch einen geheimen Teil. 10.6.1 One-Way-Function gegebenes h. Es sollte sehr schwer sein ein m zu finden, sodass h = H(M). 10.6.2 Pre-image resistant gegebener input M1, es soll schwer sein einen anderne Input M2 zu finden, sodass gilt:H(M1)=H(M2). HSR ’07 13 - 29 11 SSL ZF IntSi 10.6.3 Collsision-resistant es soll schwer sein, zwei unterschiedliche Meldungen Mx & My zu finden, sodass H(Mx)=H(My). 10.6.4 Keyed-Hash... Abbildung 4: Keyed Hash Verfahren 11 SSL [cryptoSSL] 11.1 Ziele • SSL Begriffe und Funktionsweise • Einsatzarten und kritische Punkte identifizieren • worauf zu achten ist bei SSL Zerfitikatsprüfung 11.2 Transport Layer Security Abbildung 5: Transport-Layer Security 11.3 Anwendungen • Webserver • Mailserver • OpenSSL etc. HSR ’07 14 - 29 11 SSL ZF IntSi 11.4 Funktionsweise Bei einer SSL Verbindung zu einem Webserver muss eine CA ein Schloss unterschrieben haben, welches mein Browser erkennen kann und dadurch als sicher (Schlösschen) anzeigen kann / wird. 11.5 CIA Confidentiality After the symmetric key is established in the initial handshake, the messages are encrypted using this key. Integrity Messages contain a message authentication code (MAC) ensuring the message integrity. Authentication During the handshake, the client authenticates the server by checking the signatures on the server’s certificate. 11.6 Ablauf Verbindungsaufbau Sieh [cryptoSSL] S. 13. Kc & Ks sind verwendet worden, um Reply-Attacken zu verhindern Abbildung 6: SSL Verbindungsaufbau Funktionsweise Für den Schlüsselaustausch ist DiffieHellmann sehr verbreitet. Aber auch RSA z.B. 11.6.1 Session Resume Funktioniert schneller und einfacher als ein neuer Aufbau einer Verbindung. Es wird bei der Anfrage einfach die bereits bekannte Session-ID übermittelt, diese wird dann vom Server bestätigt. 11.7 Protokoll Abbildung 7: SSL Protokoll Aufbau HSR ’07 15 - 29 12 Mail-Security ZF IntSi 11.8 SSL Proxy Diese Proxies wurden eingeführt, weil die Exportrestriktionen der USA eine Grenze von 40Bytes als Schlüssellänge eingeführt hatten. So haben Schweizer über einen localSecureProxy diese 40Byte nachträglich aufblasen können. (Zwischen Proxy und Server) 11.9 VPN over SSL SSL ist überall vorhanden und man kann genauer einschränken?! [cryptoSSL] S.26 11.10 Ressourcen • http://www.fortify.net/sslcheck.html • http://www.wastelands.gen.nz/ • Odysseus ?! 12 Mail-Security 12.1 Email-Rep Wiederholung zum shissn vo CN... bekannt eigentlich. 12.2 Chat: Mail Security • richtiger Absender (Integrity / Authentizität des Absenders) • Inhalt fälschen (Integrity) • lesen durch dritte (Confidentiality) • Bestätigung des Empfangs • richtiger Empfänger (Integrity / Authentizität des Empfängers) • Verfügbarkeit (Availability) • SPAM 12.3 Email Signatur Folgende Grafik sollte den Ablauf und die wichtigsten Details zum Thema Emai-Signatur verdeutlichen. Abbildung 8: Ablauf Email-Signatur HSR ’07 16 - 29 13 PKI ZF IntSi 12.4 Ressourcen • thawte (für freemail) 13 PKI [cryptoPKI] & [PKI] 13.1 Überprüfen von Schlössern Binding vom öffentlichen Schlüssel und Person ist sehr heikel. Normalerweise wird durch eine Personalabteilung überprüft, ob die Person auch wirklich sie ist. Stimmen diese Daten überein, wird zusammen mit einer Zertifizierungsinstitution eine digitale Signatur an den öffentlichen Schlüssel angehängt. Eine weitere Möglichkeit ist, den Hash über dem Zeritifikat zu überprüfen. Denn ändert sich ein Bit am Zertifikat, ändert sich der Hash. Wird Fingerprint genannt. Diesen Hash kann man dann auch unterschreiben lassen. 13.2 Key verteilen 1a manuell den Schlüssel aushändigen 1b Key von jemandem abholen und per Telefon vergleichen 2a Signierte Keys von einer vertrauten Person annehmen (z.b. über eine Drittperson) 2b Signierte Keys von einer vertrauten Organisation annehmen 13.2.1 Beispiel 2b Abbildung 9: PKI Sharing Beispiel 13.3 zentralisiertes Vertrauen Wünscheswert wäre eine zentrale Person/Organisation, welche alle Personen kennt, und dementsprechend alle erkennen/trusten kann. Das gibt es leider nicht. Es gibt aber Versuche, dies alles hyrarchisch anzuordnen, so sind verschiedene Root-Authorities. 13.4 Web of Thrust Jeder kennt jeden über max. 6 Freunde. & Schlüssel, welche von “Freunden” unterschrieben wurden gelten als gültig. 13.5 Registrierungsprozess 1: User generiert ein RSA Schlüsselpaar in einem CR (Certification Request) und richtet diesen an eine RA oder direkt CA 2: RA Registration Authority überprüft den CR auf die Identität des Benutzers basierend auf offiziellen Dokumenten wie ID, Ausweis etc. HSR ’07 17 - 29 13 PKI ZF IntSi 3: CA Certification Authority Unterschreibt den CR auf Basis des CR des Benutzers und der Freigabe durch das RA. 13.6 Zertifizierungsklassen 13.6.1 Klasse 0 Demo Zerfitikate zum testen. Läuft nomalerweise nach 30 Tagen aus. 13.6.2 Klasse 1 gibt an, dass diese Email-Adresse existier. Low-level Identizitäts-check. 13.6.3 Klasse 2 Für Firmen, persönliche Authentisierung nicht notwendig. Viele Webserver-Zertifikate sind von dieser Klasse. Normalerweise muss ein Handelsregisterauzug beigelegt werden. 13.6.4 Klasse 3 Neben der Überprüfung der Email wird auch eine persönliche Überprüfung vorgenommen. Man muss persönlich vorsprechen und sich mit einem Pass ausweisen. 13.6.5 Klasse 4 Höchstens bei Banken eingesetzt. 13.7 Enrolment HTML kann Keys generieren!! < keygenchallenge = “1asd231bc00 name = “mykg 00 > 13.7.1 Zertifikatsrequest Abbildung 10: PKCS Request Abbildung 11: SCEP Request 13.7.2 X500 Zerititikate X500 wurde von verschiedenen Herstellern unterschiedlich implementiert: Umlaute vermeiden, keine lan- Abbildung 12: X500 Zertifikatsbaum HSR ’07 18 - 29 14 IAM ZF IntSi gen Namen von Bundesländern etc. X.509 v3 subjectAltName → Websiten sind immer unter verschiedenen Adressen/Namen erreichbar, und das Zertifikat muss für diese einzelnen gültig sein. 13.7.3 Fileformate • Binary DER Format, (*.der, *,cer) • Base64 PEM Format, (*.pem, *.crt, *,cer), 3 DER Bytes werden in 4 PEM Bytes verwandelt. • PKCS #12 Transport Container (*.p12,*.pfx) 13.8 Revocation Sperrlisten, können immer neu oder nur incremental verteilt werden. 13.9 Ressourcen • www.rsasecurity.com, USA • www.verisign.com, USA • www.thawte.com, Südafrika • www.trustcenter.de • www.quovadis.ch 14 IAM Identity and Access Management [IAM] & [PWD] 14.1 AAA Authentication, Authorization, Accounting ⇒ in 4 Schritten • Identification (I am “Username”) • Authentication (Prove, that I am “Username”) • Authorization (Access) • Accounting (Pay for what I am using) 14.2 Sicherheitsmechanismen 2 (- oder Mehr)-Faktor Authentisierung. Basiert auf den Grunsätzen: Wissensfaktor (PW), Besitzfaktor (Token, Liste), das SEIN (biometrische Daten, Fingerprint, Sprache, Gesicht, Handumriss) 14.2.1 Angriffe Fingerprint: Klebstreifen und ein bisschen Spucke für Flächenabdrücke Iris: Foto als fake, Retina: Hochsicherheitsanwendunng Sprache: nicht sehr zuverlässig Gesichtserkennung: von der Seite täuschbar oder mit Hut/Brille etc. 14.3 Login Repetition Passwörter unter Linux/Windows: WinXP:\WINDOWS\system32\config\SAM bzw. /etc/passwd und /etc/shadow HSR ’07 19 - 29 14 IAM ZF IntSi 14.3.1 NTLM NT and LANmanager Passwort Shemes Abbildung 13: NT LANmanager Passwort Sheme 14.3.2 Unix SALT wurde hier nur präventiv gegen Rainbowtables eingeführt. Es erhöht die grösse dieser Rainbowtable um den Faktor 4096! Abbildung 14: Unix Passwort Sheme 14.4 Challenge / Response Protokolle Wird vorzugsweise für Remote-Login Verfahren und vergleichbares verwendet. Normale Sicherheitsmechanismen bieten hier wegen der Örtlichen Unabhängigkeit zuwenig Sicherheit. Folgende Bilder vergleichen Sichere Authentisierung mittels Challenge/Response Protokolle und Protokollen basierend auf digitalen Signaturen: Abbildung 15: Standard C/R Protokoll Abbildung 16: C/R mit Digitalen Signaturen 14.5 NTLM Wird in Windows-Umgebungen verwendet um Netzwerkübergreifendes Filesharing zu realisieren. Wird über den DC administriert. Folglich müssen alle Benutzer dem DC vertrauen. HSR ’07 20 - 29 14 IAM ZF IntSi 14.5.1 Funktionsweise Abbildung 17: Funktionsweise NTLM Protokoll 14.5.2 Sicherheitsanalyse • Schlüssel ist nur dem Benutzer und dem DC bekannt • Nur der echte Benutzer kann die Challenge richtig entschlüsseln • keine Wiederkehrenden Challenge-Values • + PW wird nie Plain übermittelt • + einfaches & sicheres Protokoll wenn starke Passwörter verwendet werden • − DC wird Flaschenhals, da bei jedem Zugriff die Authentifizierung aufs Neue vorgenommen werden muss. • − schwache oder kurze Passwörter können offline einfach mit einem Brute oder Dictionary Angriff geknackt werden. 14.6 Kerberos 14.6.1 Begriffe KDC Key Distribution Center Pricipal Jeder Teilnemher wird so genannt Master Key Schlüssel welcher das KDC und der Principal teilen Ticket jede gesicherte Kommunikation wird über ein Ticket markiert HSR ’07 21 - 29 14 IAM ZF IntSi 14.6.2 Funktionsweise Abbildung 18: Funktionsweise Kerberos Protokoll Abbildung 19: Session Key und Granting Ticket Ticket- Es gibt eigentlich 3 verschiedene Stufen... Diese wären in Bildern erklärt, aber es isch leider Pause und ich han erlichgseit scho gnueg bildli i deere huere Zämefassig dinne!! 14.7 Starke Passwörter 14.7.1 Entropie Entropy/Symbol = log2 (N r. of Symbols) [num/symbol] 14.7.2 Richtlinien Ein richtiges Passwort hat heute sicher min. 8 Zeichen, ist Case Sensitive und kennt Zahlen. Von Vorteil nimmt man einen Satz aus dem eigenen Alltag z.B.: und bildet ein Passwort aus den Anfangsbuchstaben der Wörter und den Zahlen die von Vorteil darin vorkommen. 14.7.3 Ressourcen • Wortlisten: http://www.totse.com/en/hack/word lists/index.html 14.8 Single Sign-On Jeder hat mehrere Passwörter in seinem Umfeld. Jedoch niemand kann sich auf Dauer Abhilfe schaffen hier Systeme wie Passwortmanager von Firefox o.ä. HSR ’07 22 - 29 15 SSH ZF IntSi 14.8.1 Datenverwaltung Es gibt verschiedenste Möglichkeiten um die Daten von Benutzern abzulegen. Ein Beispiel dafür ist der Novell Identity Manager. Ein weiteres Beispiel ist die Verwendung eines Meta-Directories: Abbildung 20: Datenhaltung mit Meta-Daten 14.8.2 IAM Folgende Begriffe aus dem Kapitel IAM sind hier zu nennen: Enterprise Information Architecture Schlüsselgeschäftsprozesse identifizieren und die Applikationen fin- den, um die Geschäftsziele zu erreichen. Zusätzlich soll für jeden Benutzer die benötigten Ressourcen erfasst werden und so in welche Sicherheitsstufe er eingetragen werden soll. Permission and Policy Management Man soll Policies über alle Zugriffsrechte erstellen. Darauf aubauend soll ein SSO über alle verwendeten Applikationen erstellt werden. Entreprise Directory Services über LDAP auf das zentrale Repository der Unternehmung zugreifen. Hierüber werden die Benutzerrechte verifziert, informationen abgerufen etc. User Authentication Vorrangig wird mit PKI gearbeitet. Workflow-Based User Provisioning Provisioning deploys access rights for employees, customers and busi- ness partners. Automated workflow systems reduce tedious manual tasks. 15 SSH Vorlesung: [SSH] 15.1 Architektur Die folgende Grafik illustriert den Aufbau des SSH2 Protokoll-Stacks. Abbildung 21: Architektur SSH 2 HSR ’07 23 - 29 15 SSH ZF IntSi 15.1.1 Transport-Layer Dieser Layer bietet eine “Algorithmus Aushandlung” an, Schlüsselaustausch und Server Authentifizierung. Es stellt eine kryptographisch gesichterte Verbindung her welche integrity, confidentiality und optional auch Kompression anbietet. Der Schlüsselaustausch findet mit Diffie-Hellman Protokoll statt. Abbildung 22: Paketaufbau von SSH2 15.1.2 Authentication-Layer Bietet div. Mechanismen zur Benutzer-Authentifizierung. Dies beinhaltet sowohl traditionelle Passwortbehandlung sowie PKI und Host-basierte Authentisierung. Passwort-basierte Autentisierung User & PW werden verschlüsselt über den Transport-Layer übertragen. Auf dem Server findet ein normales Passwort-Login statt. PKI-basierte Authentisierung User signiert eine Challenge welche vom Server geschickt wird mit seinem Private-Key. Entweder ist der Public-Teil in id rsa.pub eingetragen oder der Userkey muss im File /.ssh/authorizedk eys abgelegt sein. Alternativ kann dies auch vorgängig in einem vertrauten Zertifikat übermittelt werden. 15.1.3 Connection-Layer Bietet Interaktive Sessions, Remote-Ausführung von Kommandos, sicheres übertragen von Files mittels scp & sftp , TCP/IP und X11 Verbindungen weiterleiten. 1 2 // Interaktive Sesion ssh -l antje srv . kool . net 3 4 5 // Remote - Ausfuehrung von Kommandos ssh antje@srv . kool . net " rm *" 15.2 Forwarding Abbildung 23: SSH2 - TCP/IP Port Forwarding 15.3 Ressourcen • OpenSSH http://www.openssh.org • Portable OpenSSH http://www.openssh.org • Putty für Windowz http://www.chiark.greenend.org.uk/∼sgtatham/putty/ • WinSCP http://winscp.net/ HSR ’07 24 - 29 16 IKE ZF IntSi 16 IKE [ike] 16.1 Phase 2 - Quick Mode • IPsec Parameter aushandeln kreiert einenen IPsec SA mit dem secure channel welcher von phase 1 ISAKMP SA erstellt wurde kann wiederholend verwendet werden • ESP/AH Key Ableitung werden vom phase 1 Diffie-Hellman secret abgeleitet • Optional Perfect Forward Secret Wird “perfect secret” gewünscht, muss für jeden quick-Mode durchlauf ein frisches DH keyexchange durchgeführt werden 16.1.1 grafisch! Abbildung 24: Perfect Forward Secrecy (PFS) mit DH 16.2 Zukunft: IKEv2 16.2.1 Motivation Zu viele Meldungen, zu viele Varianten, zu komplex (laut bruce schneider dehshalb unsicher), v2 hat neue features. 16.2.2 IKEv2 Protocol IPsec SA kann mit 2 requests/responses (Paare) realisiert werden. Zusätzliche “Child-SA” brauchen 1 r/r Paar je. 16.2.3 grafisch! Abbildung 25: IKEv2 - Authentication and first Child SA HSR ’07 25 - 29 17 Firewalls ZF IntSi 16.3 VPN Applications 16.3.1 Schlüsselerzeugung openssl rand − base64 24 ( 24 3 ∗ 4 = 32 Stellen Schlüssel) 16.3.2 Road Warrior Beschreibt einen Remote-Acces Fall. Probleme: Dynamische IP’s. Authentifizierung basiert normalerweise auf RAS PK mit X.509. Virtual IP’s werden statisch oder dynamisch durch das “home”-Netz verteilt. Remote-Hosts werden demzufolge Teil eines extruded net! 16.3.3 Extranet Beschreibt den Fall von einem Netz in ein Partner-Netz. Muss gut kontrolliert werden. Erlaubt flexibles und dynamisches Setup von Extranet VPN Verbindungen. Extranet VPN fass meherere trusted domains zusammen. 16.3.4 Intranet Für Zuhause. Wireless VPN Endpunkte tunnels 100% ihres Traffics über die unsichere Luftschnitstelle. 16.4 wünschenswerte VPN features • AES Verschlüsselungen • X.509 Zertifikate • SmartCards und USB Tokens • XAUTH (Extended Authentication) [kein RFC-Standard] • IKE Mode Config [kein RFC-Standard] • IPsec Passthrough (Transparent IPsec Connection) ESP hat keine Ports, NAT damit nicht möglich!! Aber über IPsec Passthrough-Modus bekannt. (festes forwarding) • NAT Traversal (UDP encapsulation of ESP packets) Hash über IP-Adresse wird verglichen und sind diese bei sender und empfänger nicht gleich, ist NAT dazwischen. Ports werden dann in privaten bereich gemappt. • Dead Peer Detection (RFC 3706) 17 Firewalls [firewall] 17.1 Einleitung 17.1.1 Sicherheitszonen Internet (Insecure Zone) Die einzige Sicherheit bietet das Gerät selber. DMZ Normalerweise wird diese Zone durch eine Filter-Firewall geschützt. Intranet Normalerweise durch einen Proxy vom Rest getrennt. HSR ’07 26 - 29 17 Firewalls ZF IntSi 17.1.2 Firewall Arten Abbildung 26: Firewalls auf OSI Layern 17.1.3 Funktionen Zu den Funktionen von Firewalls gehören: Filtering, Inspection, Detection Logging, Alerting. Es gibt zwei verschiedene Glaubensrichtungen: 1. Deny everything that is normally explicitly permitted 2. Permit everything that is not explicitly denied 17.2 Netfilter Netfilter unter Linux kennt verschiedene Queues. INPUT, FORWARD & OUTPUT . Listing 1: Beispiele mit Iptables 1 2 3 4 // Alles erlauben ( Regel 1 von Oben ) iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT 5 6 7 8 9 // Alles verbieten ( Regel 2 von Oben ) iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP 10 11 12 13 // SSH Login von Aussen erlauben iptables -A INPUT -i eth0 -p tcp -- dport ssh -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp -- sport ssh -j ACCEPT 14 15 16 17 // Pings auf allen Interfaces erlauben iptables -A INPUT -p icmp -- icmp - type echo - request -j ACCEPT iptables -A OUTPUT -p icmp -- icmp - type echo - reply -j ACCEPT 18 19 20 // Traffic von Host X . X . X . X sperren iptables -I INPUT 1 -i eth0 -s 80.63.5.7 -j DROP 17.2.1 Proxy Dienste Circuit Level Gateway erstellt basierend auf Regeln TCP Verbindungen. Kann kein Content-Filtering. Application Level Gateway erstellt TCP direkt über den ALG. Zugriffe werden auf Baisis der Programme geregelt. Kann Content-Filtering. Im Allgemeinen werden intern und extern verschiedene Ports verwendet. 17.2.2 Stateful Ispection Technology Stateful Inspection Firewalls werden dynamsich aktualisiert. Bietet vollständige Application-Layer FirewallFunktionen an, ohne einen separaten Proxy. Einzelne Pakete werden auf geprüft auf: • Inhalt • Verbindung HSR ’07 27 - 29 17 Firewalls ZF IntSi Listing 2: Stateful inspection mit Netfilter 1 2 3 // Antwort auf TCP Pakete iptables -A OUTPUT -o eth0 -p tcp -m state -- state NEW , ESTABLISHED , RELATED -j ACCEPT iptables -A INPUT -i eth0 -p tcp -m state -- state ESTABLISHED , RELATED -j ACCEPT 4 5 6 7 // Antwort auf UDP Pakete iptables -A OUTPUT -o eth0 -p udp -m state -- state NEW , ESTABLISHED , RELATED -j ACCEPT iptables -A INPUT -i eth0 -p udp -m state -- state ESTABLISHED , RELATED -j ACCEPT 8 9 10 11 // Antwort auf ICMP iptables -A OUTPUT -o eth0 -p icmp -m state -- state NEW , ESTABLISHED , RELATED -j ACCEPT iptables -A INPUT -i eth0 -p icmp -m state -- state ESTABLISHED , RELATED -j ACCEPT 17.2.3 NAT • Ziele: Private IP-Adressen verwenden, interne Netzwerkstruktur verstecken, direkte Verbindungen unterbinden. • Typen: dynamisch Für Verbindungen von innnen nach aussen. Es sollten weniger äussere als innere Adressen vorhanden sein. statisch Für Verbindungen von aussen nach innen. Fixed 1:1 mapping der Adressen. HSR ’07 28 - 29 Literatur ZF IntSi Literatur [cryptoBasics] IntSi1-2.1-2.3-CryptoGeschichte-KlassVerfahren.pdf [cryptoDetail] IntSi1-2.4-Cryptobasics-Encryption-hei.pdf [cryptoSign] IntSi1-2.5-Cryptobasics-Signatures-hei.pdf [cryptoPKI] IntSi1-2.6-Cryptobasics-PKI-hei.pdf [cryptoSSL] IntSi1-3-TLS-SSL.pdf [PKI] IntSi1-5-PKI.pdf [IAM] IntSi1-7-IAM.pdf [PWD] IntSi1-7.5-SingleSignOn.pdf [SSH] IntSi1-8-SSH.pdf [ike] IntSi1-9.6-IKE.pdf [firewall] IntSi1-10-Firewalls.pdf Abbildungsverzeichnis 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 HSR ’07 Aufbau Windows Stack . . . . . . . . . . . Aufbau Netbios over TCP . . . . . . . . . . Funktionsweise CBC Verschlüsselung . . . . Keyed Hash Verfahren . . . . . . . . . . . . Transport-Layer Security . . . . . . . . . . SSL Verbindungsaufbau Funktionsweise . . SSL Protokoll Aufbau . . . . . . . . . . . . Ablauf Email-Signatur . . . . . . . . . . . . PKI Sharing Beispiel . . . . . . . . . . . . . PKCS Request . . . . . . . . . . . . . . . . SCEP Request . . . . . . . . . . . . . . . . X500 Zertifikatsbaum . . . . . . . . . . . . NT LANmanager Passwort Sheme . . . . . Unix Passwort Sheme . . . . . . . . . . . . Standard C/R Protokoll . . . . . . . . . . . C/R mit Digitalen Signaturen . . . . . . . . Funktionsweise NTLM Protokoll . . . . . . Funktionsweise Kerberos Protokoll . . . . . Session Key und Ticket-Granting Ticket . . Datenhaltung mit Meta-Daten . . . . . . . Architektur SSH 2 . . . . . . . . . . . . . . Paketaufbau von SSH2 . . . . . . . . . . . . SSH2 - TCP/IP Port Forwarding . . . . . . Perfect Forward Secrecy (PFS) mit DH . . IKEv2 - Authentication and first Child SA Firewalls auf OSI Layern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8 11 14 14 15 15 16 17 18 18 18 20 20 20 20 21 22 22 23 23 24 24 25 25 27 29 - 29