Zusammenfassung der Vorlesung IntSi

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