update to local git repo
This commit is contained in:
24
Semester 6/ITSARCH/Klausurvorbereitung.md
Normal file
24
Semester 6/ITSARCH/Klausurvorbereitung.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Skripte (durch KI zusammengefasst)
|
||||
- [x] Hashfunktionen
|
||||
- [x] TLS 4.5
|
||||
- [x] Firewalling
|
||||
- [x] IP-Tables
|
||||
- [x] Exploits IDS
|
||||
- [x] IPSEC
|
||||
- [x] SSH
|
||||
# Videos
|
||||
- [x] 3- hashing und signatur
|
||||
- [ ] 5 - challenge-response
|
||||
- [ ] 6 - zertifikat
|
||||
- [ ] 7 - schlüsselhierarchien teil 1
|
||||
# Praktika
|
||||
- [x] 060 Portscans
|
||||
- [x] 010 Passwortsicherheit
|
||||
- [ ] 020 DNS-Angriff
|
||||
- [ ] 080 Mintm Attack
|
||||
- [ ] 030 RADIUS
|
||||
- [ ] 050 Firewall-Pen
|
||||
- [ ] 120 IDS
|
||||
- [ ] 160 Metasploit
|
||||
- [ ] 110 SQL-Angriffe
|
||||
- [ ] 100 XSS-Angriffe
|
||||
82
Semester 6/ITSARCH/Labore/010-Passwortsicherheit.md
Normal file
82
Semester 6/ITSARCH/Labore/010-Passwortsicherheit.md
Normal file
@@ -0,0 +1,82 @@
|
||||
# Aufgabe 1
|
||||
|
||||
Nennen Sie Maßnahmen, wie man es einem potenziellen Angreifer schwerer machen kann, das Passwort zu erraten.
|
||||
|
||||
- Längere Passwörter
|
||||
- komplexer (Zahlen, Groß- und Kleinbuchstaben)
|
||||
|
||||
# Aufgabe 2
|
||||
|
||||
Suchen Sie im Internet nach Tools für Wörterbuchangriffe. Welche On- bzw. Offline-Tools gibt es und welche Arten von Hashwerten können mit den jeweiligen Tools geknackt werden?
|
||||
|
||||
- acccheck (smb)
|
||||
- beleth (ssh)
|
||||
- cudahashcat
|
||||
- eapmd5pass (md5)
|
||||
- facebrute
|
||||
- iisbruteforcer
|
||||
- morxbook, morxbrute, morxcrack
|
||||
- oclhashcat
|
||||
- pdgmail
|
||||
- pemhack
|
||||
- sidguesser
|
||||
|
||||
# Aufgabe 3
|
||||
|
||||
„John The Ripper“ ist als freie Version erhältlich. Erläutern Sie die Funktionsweise. Welche Algorithmen zur Hash-Berechnung beherrscht „John The Ripper“? Wie viele verschiedene Crack-Modi werden unterstützt? Nennen und erläutern Sie die Unterschiede.
|
||||
|
||||
# Aufgabe 4
|
||||
|
||||
Welcher Schritt ist zunächst notwendig um auf Linux-Distributionen, die Passwörter in einer Shadow-Datei speichern, das Cracking der Passwortliste zu starten?
|
||||
|
||||
1. Zugriff auf `/etc/shadow` erhalten
|
||||
1. Nötigt `root`
|
||||
2. Kopieren von `/etc/shadow` und `/etc/passwd`
|
||||
3. Vorbereitung für Cracking
|
||||
1. `unshadow /etc/passwd /etc/shadow > unshadowed.txt`
|
||||
4. Cracking tool starten
|
||||
1. `john --wordlist=rockyou.txt unshadowed.txt`
|
||||
|
||||
# Aufgabe 5 - Praxis
|
||||
|
||||
`scp localhost:/etc/passwd ~/passwd_dump.txt`
|
||||
`scp localhost:/etc/shadow ~/shadow_dump.txt`
|
||||
|
||||
`unshadow passwd_dump.txt shadow_dump.txt > combined.txt`
|
||||
`john --wordlist=pwd.txt combined.txt --users=root --format=crypt`
|
||||
|
||||
Ergebnis: `notsafe987 (root)`
|
||||
|
||||
# Aufgabe 6
|
||||
|
||||
Mitunter kann der Vorgang zum Cracken per Brute-Force oder mit Wortlisten sehr lange dauern. Allerdings gibt es ein paar Möglichkeiten, in JTR das Cracken zu beschleunigen. Nennen Sie drei Methoden.
|
||||
|
||||
1. Liste an möglichen Wörtern einschränken
|
||||
2. Mehr Rechenleistung
|
||||
3. Multi threading
|
||||
|
||||
# Aufgabe 7
|
||||
|
||||
Für Windows-LM-/-NTLM-Passworthashes gibt es eine effektivere und i.d.R. schnellere Methode das Klartext-Passwort herauszufinden - die Rainbow Tables.
|
||||
Erklären Sie die Funktionsweise von Rainbow Tables. Welche Vorteile haben sie gegenüber Brute-Force- oder Wörterbuchattacken? Warum sind Rainbow Tables in der Regel effektiver?
|
||||
|
||||
Rainbow Tables sind vorberechnete, große Datenbanken, die Klartext-Passwörter mit ihren zugehörigen Hashwerten verknüpfen. Sie dienen dazu, das ursprüngliche Passwort zu einem gegebenen Hashwert schnell zu ermitteln, ohne jedes mögliche Passwort einzeln ausprobieren oder berechnen zu müssen
|
||||
|
||||
# Aufgabe 8
|
||||
|
||||
Die LM-/NTLM-Hashes von lokalen Benutzerkonten sind in einer SAM-Datenbank abgelegt. Wofür steht SAM und welche Funktion hat der Dienst? Kann man über die SAM-Datenbank auch Domain-Passwörter auslesen?
|
||||
|
||||
# Aufgabe 9 - Praxis
|
||||
|
||||
Versuchen Sie nun das Passwort des Accounts 'Alice' von einem fiktiven Windows10-Rechner mit dem Tool Ophcrack und einer Rainbow Table zu cracken. Laden Sie sich dazu zunächst die Rainbow Table 'vista free prohabilistic' von der Ophcrack-Webseite herunter (oder, falls die Verbindung zu langsam ist liegt die unter /root/ophcrack) und speichern Sie die Table im Ordner 'ophcrack/RainbowTables' im Home-Verzeichnis des Users 'root'.
|
||||
|
||||
In dem Ordner „ophcrack“ finden Sie außerdem einen Dump der SAM-Einträge (Security Accounts Manager) von der VM „win10-victim“.
|
||||
|
||||
**Zum Cracken soll nur das Passwort von Alice betrachtet werden, ansonsten sind die Laufzeiten zu hoch! Hierzu kann bspw. nur ein Teil des SAM-Dump verwendet werden.**
|
||||
|
||||
Starten Sie das Tool Ophcrack auf der Kommandozeile (ophcrack), laden Sie den SAM-Dump und versuchen Sie das Passwort des Accounts „Alice“ mit der heruntergeladenen Rainbow Table zu cracken.
|
||||
|
||||
|
||||
`ophcrack-cli -f nurlice.pwdmp -t Rainbowtables/vista_proba_free -n 4`
|
||||
|
||||
Ergebnis: Alice NT password 12!34
|
||||
BIN
Semester 6/ITSARCH/Labore/060-portscans.pdf
Normal file
BIN
Semester 6/ITSARCH/Labore/060-portscans.pdf
Normal file
Binary file not shown.
117
Semester 6/ITSARCH/Labore/060-portscans.qmd
Normal file
117
Semester 6/ITSARCH/Labore/060-portscans.qmd
Normal file
@@ -0,0 +1,117 @@
|
||||
#let response(body) = {
|
||||
set text(
|
||||
weight: "semibold",
|
||||
purple,
|
||||
)
|
||||
[#body]
|
||||
}
|
||||
|
||||
= 060 Portscans
|
||||
|
||||
== Aufgabe 1
|
||||
Erklären Sie die Begriffe sowie die Bedeutung Authentisierung, Autorisierung und Accounting.
|
||||
|
||||
#response[
|
||||
- Authentisierung:
|
||||
- Identitätsnachweis
|
||||
- Autorisierung:
|
||||
- Rechtevergabe
|
||||
- Accounting:
|
||||
- audit trail über logging
|
||||
]
|
||||
|
||||
#link("https://en.wikipedia.org/wiki/Authentication%2C_authorization%2C_and_accounting")[
|
||||
wikipedia: Authentication, authorization, and accounting
|
||||
]
|
||||
|
||||
== Aufgabe 2
|
||||
Was ist ein Port?
|
||||
|
||||
#response[
|
||||
Als Port versteht man einen Kommunikationsendpunkt. Auf der Softwareebene ist ein Port ein Konstrukt, mit dem man ein spezifischen Prozess oder ein network-service identifizieren kann.
|
||||
]
|
||||
|
||||
#link("https://en.wikipedia.org/wiki/Port_(computer_networking)")[
|
||||
wikipedia: Port\_(computer_networking)
|
||||
]
|
||||
|
||||
== Aufgabe 2
|
||||
Was ist ein Portscanner und wofür wird er verwendet?
|
||||
|
||||
#response[
|
||||
Ein Portscanner ist eine Applikation, die dazu dient offene Ports bei bspw. Applikationen und Servern zu ermitteln. Dieser kann sowohl von Administratoren verwendet werden um Sicherheitslücken zu ermitteln, als auch von Angreifern um sich zugriff zu schaffen.
|
||||
]
|
||||
|
||||
#link("https://en.wikipedia.org/wiki/Port_scanner")[
|
||||
wikipedia: Port_scanner
|
||||
]
|
||||
|
||||
== Aufgabe 3
|
||||
Ein Portscanner sendet eine Anfrage zur Verbindung mit einem Port eines Computers und zeichnet die Antwort auf. Es gibt drei mögliche Antworten, welche sind es?
|
||||
|
||||
#response[
|
||||
+ Open or Accepted
|
||||
+ Closed or Denied
|
||||
+ Filtered, Dropped or Blocked
|
||||
]
|
||||
|
||||
#link("https://en.wikipedia.org/wiki/Port_scanner")[
|
||||
wikipedia: Port_scanner
|
||||
]
|
||||
|
||||
== Aufgabe 4
|
||||
Welche Portscan-Techniken gibt es?
|
||||
|
||||
#response[
|
||||
- TCP
|
||||
- SYN
|
||||
- UDP
|
||||
- ACK
|
||||
- Window
|
||||
- FIN
|
||||
]
|
||||
|
||||
#link("https://en.wikipedia.org/wiki/Port_scanner")[
|
||||
wikipedia: Port_scanner
|
||||
]
|
||||
|
||||
|
||||
== Aufgabe 5
|
||||
Welche Möglichkeiten gibt es zur Erkennung von Portscannern?
|
||||
|
||||
#response[
|
||||
Mehrere Requests durch einen oder mehrere IP-Adressen an unterschiedlichen Ports (abtasten).
|
||||
]
|
||||
|
||||
== Aufgabe 6
|
||||
Welche Auswirkungen kann ein Portscan haben?
|
||||
|
||||
#response[
|
||||
- Entdeckung von offenen Ports
|
||||
- Geldstrafe lulz
|
||||
]
|
||||
|
||||
== Aufgabe 7
|
||||
An welchem Angriffs-Muster könnte man einen Portscan identifizieren und wie lässt sich dies vermeiden?
|
||||
|
||||
#response[
|
||||
+ inkrementierende Portnummer-Anfragen durch eine Person
|
||||
+ Auslastung und Testen aller Ports anhand eines Botnets
|
||||
]
|
||||
|
||||
== Aufgabe 8 - Praxis
|
||||
Welche Möglichkeiten gibt es auf einem Linux-System mit Kommandozeilenzugriff die offenen Ports herauszufinden ohne einen Portscan durchzuführen? (bspw. auf dem Kali-Container)
|
||||
|
||||
#response[
|
||||
`#netstat -lntu`
|
||||
]
|
||||
|
||||
#image("netstat.png")
|
||||
|
||||
== Aufgabe 9 - Praxis
|
||||
Führen Sie mit Hilfe der folgenden Tools jeweils einen Port-Scan für Port 20 bis 80 durch: nmap, netcat bzw. nc, echo, bash
|
||||
|
||||
#response[
|
||||
=== nmap
|
||||
#image("nmap.png")
|
||||
]
|
||||
BIN
Semester 6/ITSARCH/Labore/netstat.png
Normal file
BIN
Semester 6/ITSARCH/Labore/netstat.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
BIN
Semester 6/ITSARCH/Labore/nmap.png
Normal file
BIN
Semester 6/ITSARCH/Labore/nmap.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
131
Semester 6/ITSARCH/Skript_Notizen/Exploits IDS_IPS.md
Normal file
131
Semester 6/ITSARCH/Skript_Notizen/Exploits IDS_IPS.md
Normal file
@@ -0,0 +1,131 @@
|
||||
## 💥 EXPLOITS – GRUNDLAGEN
|
||||
### Was ist ein Exploit?
|
||||
- Ausnutzung einer **Sicherheitslücke** in Software/IT-Systemen
|
||||
- Besteht aus:
|
||||
- **Schadcode / Shellcode** (führt Payload aus)
|
||||
|
||||
- **Payload**: z. B. Fernzugriff, Malware, Download weiterer Software
|
||||
|
||||
- Oft **spezifisch** für ein bestimmtes Programm/Version
|
||||
### Lebenszyklus einer Sicherheitslücke
|
||||
1. Sicherheitslücke existiert (unbekannt)
|
||||
2. **Zero-Day-Exploit**: Lücke wird entdeckt & ausgenutzt
|
||||
3. Lücke wird veröffentlicht & gepatcht
|
||||
### Exploit-Arten
|
||||
- **ACE (Arbitrary Code Execution)**: Schadcode wird durch Schwachstelle ausgeführt
|
||||
- **RCE (Remote Code Execution)**: über präparierte Webseite/E-Mail
|
||||
- **Drive-by-Download**: unbemerktes Ausführen beim Webseitenbesuch
|
||||
---
|
||||
## 🧰 EXPLOIT FRAMEWORKS & KITS
|
||||
### Bekannte Exploit-Frameworks
|
||||
- **Metasploit**: umfangreichstes Toolkit
|
||||
- **BeEF**: Webbrowser-Exploits
|
||||
- **SET**: Social Engineering Toolkit
|
||||
- **Koadic**, **Empire**, **Merlin**: Post-Exploitation
|
||||
### Exploit Kits
|
||||
- Sammlung vieler Exploits
|
||||
- Ermittelt automatisch Schwachstellen auf Clients
|
||||
- Nutzt ggf. **Zero-Day Exploits**
|
||||
- Beispiel: Webbrowser öffnet präparierte Webseite → passender Exploit automatisch geladen
|
||||
---
|
||||
## 🧨 ANGRIFFSTECHNIKEN
|
||||
### XSS (Cross Site Scripting)
|
||||
- JavaScript-Code in Webseiten einschleusen
|
||||
- Zugriff auf Cookies, Inhalte, Benutzeraktionen
|
||||
### Pufferüberlauf (Buffer Overflow)
|
||||
- Speicherüberlauf durch zu große Eingabe
|
||||
- Shellcode überschreibt Rücksprungadresse (Stack)
|
||||
### Spoofing
|
||||
- **Identitätsfälschung** (IP/DNS/ARP Spoofing)
|
||||
- Umgehung von Firewalls
|
||||
### DoS / DDoS
|
||||
- **Denial of Service**: Dienstüberlastung (z. B. SYN-Flooding)
|
||||
- **Distributed DoS**: Angriff durch viele Systeme gleichzeitig
|
||||
---
|
||||
## 🕵️♂️ IDS / IPS – INTRUSION DETECTION / PREVENTION
|
||||
### Ziel
|
||||
- Erkennung und ggf. Verhinderung von Angriffen auf IT-Systeme
|
||||
### Unterscheidung:
|
||||
|IDS|IPS|
|
||||
|---|---|
|
||||
|Erkennung & Alarmierung|Erkennung + aktive Blockierung|
|
||||
|Passiv|Aktiv|
|
||||
|Beispiel: **Snort** als IDS|Snort mit Blockier-Funktion|
|
||||
---
|
||||
## 🧱 IDS-KOMPONENTEN
|
||||
- **Sensor**: erkennt Ereignisse (Datenquelle)
|
||||
- **Datenbank**: speichert Ereignisse
|
||||
- **Auswertestation**: analysiert, bewertet, alarmiert
|
||||
- **Managementstation**: Konfiguration & Regelpflege
|
||||
---
|
||||
## 🔎 IDS-TYPEN
|
||||
### NIDS (Netzwerkbasiert)
|
||||
- Analysiert Netzwerkverkehr
|
||||
- Erkennt z. B. Portscans, DoS, SQL-Injection
|
||||
- Nachteile: keine Analyse verschlüsselter Verbindungen (TLS), Mehrdeutigkeiten
|
||||
### HIDS (Hostbasiert)
|
||||
- Überwacht einzelnes System (Betriebssystem, Anwendungen)
|
||||
- Vorteile: sieht verschlüsselte Daten
|
||||
- Nachteile: hoher Aufwand, systembelastend, kann selbst Ziel sein
|
||||
### Hybrides IDS
|
||||
- Kombination aus NIDS & HIDS
|
||||
- Sensoren verteilt, zentrale Verwaltung
|
||||
---
|
||||
## 🧠 ERKENNUNGSMETHODEN
|
||||
### 1. **Signaturanalyse (Missbrauchsmuster)**
|
||||
- Vergleich mit bekannten Angriffsmustern
|
||||
- Vorteil: **gezielte Erkennung**
|
||||
- Nachteil: erkennt keine neuen Angriffe, false positives möglich
|
||||
### 2. **Anomalieerkennung**
|
||||
- Detektiert Abweichungen vom Normalverhalten
|
||||
- Vorteile: erkennt auch **unbekannte Angriffe**
|
||||
- Nachteile: hoher Aufwand, Datenschutzproblematik
|
||||
---
|
||||
## 🐝 HONEYPOTS
|
||||
### Definition
|
||||
- **Falle für Angreifer**
|
||||
- Stellt gezielt verwundbares System bereit
|
||||
### Arten
|
||||
|Typ|Eigenschaften|
|
||||
|---|---|
|
||||
|**High Interaction**|echtes System, realistische Analyse|
|
||||
|**Low Interaction**|emulierte Funktionen, sicherer, aber erkennbar|
|
||||
- **Client-Honeypots**: interagieren aktiv mit Servern
|
||||
- **Server-Honeypots**: lauschen passiv, analysieren eingehende Anfragen
|
||||
---
|
||||
## 🐍 SNORT – PRAKTISCHES BEISPIEL FÜR EIN IDS
|
||||
### Merkmale
|
||||
- Open Source IDS/NIPS
|
||||
- Besteht aus:
|
||||
- **Packet Sniffer**
|
||||
|
||||
- **Logger**
|
||||
|
||||
- **Detection Engine** (Regelbasierte Analyse)
|
||||
|
||||
- Erweiterbar mit:
|
||||
- Preprozessoren
|
||||
|
||||
- Add-ons
|
||||
|
||||
- Logging- und Alarmierungsmechanismen
|
||||
|
||||
### Aufbau
|
||||
1. **Packet Decoder**: liest eingehende Pakete
|
||||
2. **Preprozessor**: erkennt z. B. Portscans
|
||||
3. **Detection Engine**: vergleicht mit Regeln (Snort Rules)
|
||||
4. **Output Plugins**: Logging, Alarmierung (z. B. Datenbank, Mail)
|
||||
### Snort Rules:
|
||||
- bestehen aus Header (IP, Port, Aktion) + Optionen (Inhalt, Alarmtext)
|
||||
---
|
||||
## ✅ ZUSAMMENFASSUNG – KLAUSURRELEVANT
|
||||
- Exploits = gezielte Ausnutzung von Schwachstellen
|
||||
- Exploit Kits bündeln viele Exploits, oft Zero-Day dabei
|
||||
- IDS erkennt Angriffe, IPS verhindert sie aktiv
|
||||
- NIDS ↔ HIDS: netzwerk- vs. hostbasiert
|
||||
- Signaturerkennung: gezielt, aber blind für neue Angriffe
|
||||
- Anomalieerkennung: erkennt Neues, aber komplex
|
||||
- Snort = praxisnahes IDS, regelbasiert
|
||||
- Honeypots zur Analyse & Täuschung von Angreifern
|
||||
---
|
||||
Wenn du willst, kann ich daraus **Karteikarten**, ein **Quiz**, oder eine **Lernmatrix** erstellen – sag einfach Bescheid!
|
||||
90
Semester 6/ITSARCH/Skript_Notizen/Firewalling.md
Normal file
90
Semester 6/ITSARCH/Skript_Notizen/Firewalling.md
Normal file
@@ -0,0 +1,90 @@
|
||||
## 🔥 GRUNDLAGEN FIREWALLING
|
||||
### Was ist eine Firewall?
|
||||
- **Schutzmechanismus** zwischen vertrauenswürdigem und nicht-vertrauenswürdigem Netzwerk
|
||||
- Übernimmt die Rolle eines **Gateways**
|
||||
- Ziel: **Kommunikationsflüsse kontrollieren, filtern und absichern**
|
||||
### Ziele:
|
||||
- Zugriffskontrolle
|
||||
- Protokollierung
|
||||
- Absicherung gegen unbefugten Zugriff
|
||||
- Viren-, Makro-, & Intrusion Detection möglich
|
||||
---
|
||||
## 🔒 EINSATZBEREICHE
|
||||
1. **Outbound-Schutz** (Zugriffe vom Intranet → Internet)
|
||||
2. **Inbound öffentlich** (z. B. Webserver, Mailserver)
|
||||
3. **Inbound eingeschränkt** (z. B. VPN, Remote Work)
|
||||
---
|
||||
## 🧱 DMZ (De-Militarisierte Zone)
|
||||
- Separiertes Subnetz zwischen Internet und internem Netz
|
||||
- Über **2 Firewalls** von außen/innen abgeschottet
|
||||
- Einsatz für Server, die **von innen und außen erreichbar** sein müssen (z. B. Mail, Web)
|
||||
---
|
||||
## 🧰 FIREWALL-TYPEN IM ÜBERBLICK
|
||||
|Typ|Schicht|Merkmale|
|
||||
|---|---|---|
|
||||
|**Paketfilter (Screening)**|OSI 3–4|+ Schnell, einfach– Nur einfache Filterung (IP, Ports)– Kein Schutz gegen komplexe Angriffe|
|
||||
|**Transportschichtfilter**|OSI 4|+ Session-Überwachung– Nur legitime Sessions zugelassen|
|
||||
|**Application Gateway (ALG)**|OSI 7|+ Höchste Sicherheit+ Protokollanalyse möglich– Aufwändig, langsam, nicht skalierbar|
|
||||
|**Stateful Inspection**|OSI 3–7|+ Verbindungszustände erkennbar– komplex in Konfiguration|
|
||||
---
|
||||
## 🔄 PAKETFILTERUNG
|
||||
- Filtert anhand von:
|
||||
- Quell-/Zieladresse (IP)
|
||||
- Quell-/Zielport (TCP/UDP)
|
||||
- Protokoll (TCP, UDP, ICMP)
|
||||
- Flags (z. B. TCP-ACK)
|
||||
|
||||
- **Statisch** (nur Paketinhalt) oder **Stateful** (Zustandsbezug)
|
||||
- Vorteil: Effizient, günstig
|
||||
- Nachteil: Keine Authentifizierung, keine Applikationskontrolle
|
||||
---
|
||||
## 🧠 STATEFUL INSPECTION
|
||||
- **Verbindungsbezogenes Filtern**
|
||||
- Bezieht Kontext mit ein: Verbindung offen? Authentifiziert?
|
||||
- Vorteil: Transparent & flexibel
|
||||
- Nachteil: Komplex, keine physische Trennung, fehleranfällig
|
||||
---
|
||||
## 💻 APPLICATION LEVEL GATEWAY (ALG)
|
||||
- Arbeitet auf **Anwendungsschicht (Layer 7)**
|
||||
- Trennung von intern ↔ extern
|
||||
- Pro Dienst spezieller Proxy (FTP, HTTP, SMTP …)
|
||||
- Vorteile:
|
||||
- Vollständige Kontrolle & Protokollierung
|
||||
- Filterung auf Nutzdatenebene (z. B. Java-Applets blockieren)
|
||||
- Authentifizierung & Benutzerrechte
|
||||
|
||||
- Nachteile:
|
||||
- Rechenintensiv
|
||||
- Nicht skalierbar
|
||||
- Wartungsaufwendig
|
||||
|
||||
---
|
||||
## 🧱 PROXY & APPLICATION GATEWAYS
|
||||
- **Stellvertreterprinzip**: Proxy agiert anstelle des Clients
|
||||
- Kontrolliert & manipuliert Inhalte (URL, Mail-Betreff, Anhänge)
|
||||
- Integration in Client oder Netzwerk notwendig
|
||||
- Typisch für: SMTP, HTTP, FTP, SQL, TELNET etc.
|
||||
---
|
||||
## ⚖️ AUSWAHL EINER FIREWALL
|
||||
- Muss nur **notwendige Dienste zulassen**
|
||||
- **Transparente Sicherheit**: offene Architektur wünschenswert
|
||||
- **Resistenz gegen Angriffe**, minimaler Softwareumfang
|
||||
- Gute Produkte = weit verbreitet & getestet
|
||||
- Richtige Konfiguration = **entscheidend für Sicherheit**
|
||||
---
|
||||
## ⚠️ NACHTEILE & PROBLEME
|
||||
- Einschränkung von Nutzern/Diensten
|
||||
- Komplexität durch abweichende Portnutzung
|
||||
- Konfigurationsfehler = große Gefahr
|
||||
- Performanceverlust (Single Point of Failure möglich)
|
||||
---
|
||||
## 🚨 ANGRIFFE & UMGEHUNG
|
||||
- Ziel: Schwachstellen **hinter** der Firewall (z. B. Makros auf Client-PCs)
|
||||
- Wichtig: **IDS/IPS**-Integration + strenge Logfile-Analyse
|
||||
---
|
||||
## ✅ FIREWALL BEST PRACTICES
|
||||
- „**Alles verbieten, was nicht ausdrücklich erlaubt ist**“
|
||||
- Physische Zugriffs- & Änderungsrechte kontrollieren
|
||||
- Firewall-Logs regelmäßig auswerten
|
||||
- Konfigurationsmanagement konsequent umsetzen
|
||||
- Kombination mit anderen Schutzmaßnahmen (Antivirus, IDS, VPN etc.)
|
||||
87
Semester 6/ITSARCH/Skript_Notizen/Hash-Algorithmen.md
Normal file
87
Semester 6/ITSARCH/Skript_Notizen/Hash-Algorithmen.md
Normal file
@@ -0,0 +1,87 @@
|
||||
## 🧠 GRUNDLAGEN DER HASHFUNKTIONEN
|
||||
### Was ist eine Hashfunktion?
|
||||
- Einwegfunktion: beliebig lange Eingabe → fester Hashwert (Ausgabe).
|
||||
- Ziel: Aus Hashwert **kann nicht** auf Eingabe geschlossen werden.
|
||||
- Ein Hashwert = „digitaler Fingerabdruck“.
|
||||
### Eigenschaften einer **kryptografisch sicheren Hashfunktion**
|
||||
1. **Einweg-Eigenschaft**: h(M) einfach berechenbar, aber M aus h(M) unberechenbar.
|
||||
2. **Kollisionsresistenz**:
|
||||
- _Schwach_: Für gegebenes x ist es schwer, x′ ≠ x mit h(x) = h(x′) zu finden.
|
||||
- _Stark_: Es ist schwer, zwei beliebige x ≠ x′ mit h(x) = h(x′) zu finden.
|
||||
---
|
||||
## 🛠️ ANWENDUNGEN
|
||||
- **Passwort-Speicherung** (nur Hash, kein Klartext)
|
||||
- **Signaturen**: Signiere h(M), nicht M.
|
||||
- **Integritätsprüfung**: Prüfsummen, Manipulationserkennung (MIC, MDC)
|
||||
- **Authentifizierung**: MAC, HMAC
|
||||
---
|
||||
## 🔐 HASH-FUNKTIONSTYPEN
|
||||
|Typ|Beschreibung|
|
||||
|---|---|
|
||||
|UHF|Unkeyed Hash Function: h(M)|
|
||||
|KHF / MAC|Keyed Hash Function: h(M, k) oder h(M, s)|
|
||||
---
|
||||
## 📌 MDC & MAC UNTERSCHEIDUNG
|
||||
### MDC – Manipulation Detection Code
|
||||
- **OWHF**: One-Way Hash Function = Einweg + schwache Kollision
|
||||
- **CRHF**: Collision Resistant Hash Function = schwache + starke Kollision
|
||||
### MAC – Message Authentication Code
|
||||
- nutzt Schlüssel + Nachricht
|
||||
- Anforderungen:
|
||||
- einfache Berechnung
|
||||
- Kompression
|
||||
- resistent gegen Manipulation
|
||||
---
|
||||
## 🔁 AUFBAU EINER HASHFUNKTION
|
||||
1. Nachricht in Blöcke fester Länge teilen.
|
||||
2. Padding auf Vielfaches der Blocklänge.
|
||||
3. Iterative Verarbeitung mit Kompressionsfunktion.
|
||||
4. Ergebnis: finaler Hashwert.
|
||||
---
|
||||
## 📚 HASH-ALGORITHMEN IM VERGLEICH
|
||||
|Algorithmus|Hashlänge|Status / Schwächen|
|
||||
|---|---|---|
|
||||
|**MD2/MD4**|128 Bit|Veraltet, unsicher|
|
||||
|**MD5**|128 Bit|Kollisionen bekannt, nicht mehr sicher|
|
||||
|**SHA-1**|160 Bit|Kollisionen möglich (ab 2005), deprecated|
|
||||
|**SHA-2**|224–512 Bit|Aktuell sicher|
|
||||
|**SHA-3**|224–512 Bit|Alternative zu SHA-2 (Keccak)|
|
||||
|**RIPEMD-160**|160 Bit|Sicher, europäische Alternative|
|
||||
|**WHIRLPOOL**|512 Bit|Sicher, aber wenig untersucht|
|
||||
---
|
||||
## 🔁 HMAC (Hash-based MAC)
|
||||
- **Verwendet Hash + geheimen Schlüssel**
|
||||
- Schritte:
|
||||
1. Schlüssel ggf. kürzen/padden auf Blockgröße
|
||||
2. Zwei Pads: `ipad = 0x36`, `opad = 0x5C`
|
||||
3. HMAC = H(opad ⊕ k ∥ H(ipad ⊕ k ∥ M))
|
||||
- Einsatz in TLS, IPsec etc.
|
||||
- **Sichert Authentizität & Integrität**, **keine digitale Signatur**
|
||||
---
|
||||
## 💥 ANGRIFFE
|
||||
### Geburtstagsparadoxon
|
||||
- Wahrscheinlichkeit für Kollision steigt stark mit Anzahl an Inputs.
|
||||
- 50%-Kollisionschance bei ca. √(2^n) = 2^(n/2)
|
||||
### Angriffstypen
|
||||
|Typ|Beschreibung|
|
||||
|---|---|
|
||||
|**Pre-Image**|Gegeben h(x), finde ein x|
|
||||
|**Second Pre-Image**|Gegeben x, finde x′ ≠ x mit h(x) = h(x′)|
|
||||
|**Collision**|Finde x, x′ ≠ x mit h(x) = h(x′)|
|
||||
---
|
||||
## ❌ SICHERHEITSSCHWÄCHEN
|
||||
### MD5
|
||||
- Viele Kollisionen gefunden (z. B. durch Dobbertin, Wang, Stach)
|
||||
- Nicht mehr vertrauenswürdig
|
||||
### SHA-1
|
||||
- Kollisionen mit 2^63 Berechnungen möglich (statt 2^80)
|
||||
- Seit 2010 in den USA und vom BSI abgelehnt
|
||||
---
|
||||
## 📌 MERKREGELN FÜR DIE KLAUSUR
|
||||
- **Hash = Fingerabdruck**, nicht rückrechenbar
|
||||
- **Kollision = 2 verschiedene Eingaben → gleicher Hash**
|
||||
- **MDC = prüft Integrität**, **MAC = prüft Integrität + Authentizität**
|
||||
- **SHA-2 & SHA-3 = derzeit sicher**
|
||||
- **HMAC ≠ Signatur**, da symmetrisch!
|
||||
---
|
||||
Wenn du willst, kann ich dir auch Lernkarten (Flashcards), ein Quiz oder eine Mindmap aus diesem Material erstellen. Sag einfach Bescheid!
|
||||
86
Semester 6/ITSARCH/Skript_Notizen/IPSEC.md
Normal file
86
Semester 6/ITSARCH/Skript_Notizen/IPSEC.md
Normal file
@@ -0,0 +1,86 @@
|
||||
## 🔐 GRUNDLAGEN: IPsec (Internet Protocol Security)
|
||||
- **IPsec** ist ein **protokollbasierter Sicherheitsstandard** für IPv4 & IPv6.
|
||||
- Ziel: **Integrität, Authentizität, Vertraulichkeit & Replay-Schutz** auf IP-Ebene.
|
||||
- Arbeitet **unterhalb der Transportschicht**, daher **transparent** für Anwendungen.
|
||||
---
|
||||
## 📦 PROTOKOLL-FAMILIE
|
||||
|Protokoll|Aufgabe|
|
||||
|---|---|
|
||||
|**AH** (Authentication Header)|Authentifizierung + Integrität|
|
||||
|**ESP** (Encapsulating Security Payload)|Vertraulichkeit + optional Authentifizierung|
|
||||
|**IKE** (Internet Key Exchange)|Schlüsselaustausch & SA-Verwaltung|
|
||||
---
|
||||
## 🔐 SICHERHEITSFUNKTIONEN
|
||||
- **Integrität**: mittels HMAC (z. B. SHA-1)
|
||||
- **Authentizität**: Absenderverifikation (HMAC)
|
||||
- **Vertraulichkeit**: symmetrische Verschlüsselung (AES etc.)
|
||||
- **Anti-Replay (ARS)**: Sequenznummern + Fenster (z. B. 64 Pakete)
|
||||
---
|
||||
## 🔁 ESP-MODI
|
||||
|Modus|Einsatz|Was wird verschlüsselt|
|
||||
|---|---|---|
|
||||
|**Transport-Mode**|Host-to-Host|Nur Payload|
|
||||
|**Tunnel-Mode**|Gateway-to-Gateway / Host-to-Gateway|gesamtes IP-Paket inkl. Header|
|
||||
---
|
||||
## 🔍 AH vs. ESP
|
||||
|Merkmal|AH|ESP|
|
||||
|---|---|---|
|
||||
|Authentifiziert IP-Header|✅|❌|
|
||||
|Verschlüsselung|❌|✅ (optional)|
|
||||
|Vertraulichkeit|❌|✅|
|
||||
|NAT-Kompatibilität|❌|✅ (Tunnel-Modus)|
|
||||
---
|
||||
## 🧠 SECURITY ASSOCIATION (SA)
|
||||
- **SA** = IPsec-„Verbindung“ (einseitig)
|
||||
- Definiert:
|
||||
- Protokolle & Algorithmen (ESP/AH)
|
||||
- Schlüssel, IVs, SPI (Security Parameter Index)
|
||||
- Gültigkeit (zeitlich oder traffic-basiert)
|
||||
|
||||
- Verwaltung:
|
||||
- **SAD**: Security Association Database
|
||||
- **SPD**: Security Policy Database (Policy-Entscheidung: BYPASS, PROTECT, DISCARD)
|
||||
|
||||
---
|
||||
## 🧰 IKE – INTERNET KEY EXCHANGE
|
||||
### Funktion
|
||||
- Schlüsselmanagement + SA-Aushandlung
|
||||
- Authentifizierung per:
|
||||
- **Pre-Shared Key (PSK)**
|
||||
- **Zertifikat (X.509)**
|
||||
|
||||
### Aufbau
|
||||
|Phase|Aufgabe|Protokolle|
|
||||
|---|---|---|
|
||||
|**Phase I**|Aufbau IKE-SA (sicherer Kanal)|ISAKMP, OAKLEY|
|
||||
|**Phase II**|Aufbau IPsec-SA|schnelles Schlüsselaushandeln|
|
||||
- Unterstützt **Main Mode**, **Aggressive Mode**, **Quick Mode**
|
||||
- IKEv2: schneller, effizienter, sicherer (unterstützt EAP, MOBIKE, NAT-Traversal)
|
||||
---
|
||||
## 🔐 AUTHENTIFIZIERUNG
|
||||
### PSK
|
||||
- HMAC über:
|
||||
- PSK
|
||||
- Nonces
|
||||
- Diffie-Hellman-Werte
|
||||
- Identitäten
|
||||
|
||||
### Zertifikate
|
||||
- Digitale Zertifikate (CA-signiert)
|
||||
- Prüfung via Signatur & Public Key
|
||||
---
|
||||
## 🌐 IPsec UND IPv6
|
||||
- AH/ESP sind **integraler Bestandteil** von IPv6 (Next Header 51 / 50)
|
||||
- Erweiterbar durch **Extension Header**
|
||||
- IPsec muss **explizit aktiviert & konfiguriert** werden
|
||||
- **AH funktioniert nicht mit NAT**, **ESP im Tunnel-Modus** schon
|
||||
---
|
||||
## ✅ KLAUSURRELEVANTE KERNAUSSAGEN
|
||||
- IPsec ist unabhängig vom Transportprotokoll und arbeitet auf **Netzwerkschicht (OSI Layer 3)**.
|
||||
- **ESP schützt Payload**, **AH schützt auch IP-Header (teilweise)**.
|
||||
- **IKEv2** wird bevorzugt eingesetzt (schneller, mobiler, sicherer).
|
||||
- **Anti-Replay-Schutz** ist standardmäßig aktiv (Sequenznummern + Fenster).
|
||||
- SPD regelt, **ob IPsec angewendet wird**; SAD enthält die Parameter dazu.
|
||||
- AH & ESP sind bei IPv6 **verpflichtend**, bei IPv4 **optional**.
|
||||
---
|
||||
Möchtest du daraus ein **Quiz**, eine **Mindmap**, oder **Lernkarten** zur Wiederholung haben? Sag einfach Bescheid!
|
||||
106
Semester 6/ITSARCH/Skript_Notizen/IPTables.md
Normal file
106
Semester 6/ITSARCH/Skript_Notizen/IPTables.md
Normal file
@@ -0,0 +1,106 @@
|
||||
## 🔥 GRUNDLAGEN: IPTABLES & NETFILTER
|
||||
### Was ist iptables?
|
||||
- Linux-Tool zur Konfiguration von **netfilter** (seit Kernel 2.4)
|
||||
- Nachfolger von `ipchains`, `ipfadm`
|
||||
- **Zentrale Aufgabe**: Regeln zur Filterung und Manipulation von IP-Paketen definieren
|
||||
- Besteht aus:
|
||||
- **Tabellen** (z. B. `filter`, `nat`, `mangle`)
|
||||
- **Ketten** (z. B. `INPUT`, `OUTPUT`, `FORWARD`)
|
||||
- **Regeln**
|
||||
|
||||
---
|
||||
## 📊 TABELLEN & KETTEN
|
||||
|Tabelle|Zweck|Enthält Ketten|
|
||||
|---|---|---|
|
||||
|`filter`|Paketfilterung (Standard)|`INPUT`, `OUTPUT`, `FORWARD`|
|
||||
|`nat`|IP/Port-Umschreibung (SNAT/DNAT)|`PREROUTING`, `POSTROUTING`, `OUTPUT`|
|
||||
|`mangle`|Modifikation von Header-Daten (QoS, TTL, etc.)|alle Ketten|
|
||||
---
|
||||
## 🔄 KETTEN (CHAINS)
|
||||
|Chain|Beschreibung|
|
||||
|---|---|
|
||||
|`INPUT`|Eingehende Pakete für lokalen Rechner|
|
||||
|`OUTPUT`|Vom lokalen Rechner ausgehende Pakete|
|
||||
|`FORWARD`|Weitergeleitete Pakete (Routerbetrieb)|
|
||||
|`PREROUTING`|Vor Routingentscheidung (z. B. DNAT)|
|
||||
|`POSTROUTING`|Nach Routingentscheidung (z. B. SNAT)|
|
||||
- Ketten enthalten **Regeln**, die in Reihenfolge geprüft werden
|
||||
- Jede Kette besitzt eine **Standardregel (Policy)** (z. B. `DROP`, `ACCEPT`)
|
||||
---
|
||||
## 🧾 BEFEHLE (AUSZUG)
|
||||
|Befehl|Beschreibung|
|
||||
|---|---|
|
||||
|`-F`|Alle Regeln in Kette löschen|
|
||||
|`-X`|Benutzerdefinierte Kette löschen|
|
||||
|`-P`|Policy (Standardverhalten) setzen|
|
||||
|`-A`|Regel anhängen|
|
||||
|`-I`|Regel an Position einfügen|
|
||||
|`-D`|Regel löschen|
|
||||
|`-L`|Regeln anzeigen|
|
||||
|`-N`|Neue benutzerdefinierte Kette erstellen|
|
||||
|`-Z`|Zähler zurücksetzen|
|
||||
---
|
||||
## 🧠 WICHTIGE PARAMETER
|
||||
|Parameter|Beschreibung|Beispiel|
|
||||
|---|---|---|
|
||||
|`-p`|Protokoll (`tcp`, `udp`, `icmp`)|`-p tcp`|
|
||||
|`-s`|Quelladresse|`-s 192.168.0.0/24`|
|
||||
|`-d`|Zieladresse|`-d 10.0.0.1`|
|
||||
|`-i`|Eingangsinterface|`-i eth0`|
|
||||
|`-o`|Ausgangsinterface|`-o ppp0`|
|
||||
|`--dport`|Zielport|`--dport 22`|
|
||||
|`-j`|Zielaktion (`ACCEPT`, `DROP`, `LOG`, `REJECT`, etc.)|`-j DROP`|
|
||||
---
|
||||
## 🧪 BEISPIELE
|
||||
```sh
|
||||
iptables -A INPUT -p icmp -j DROP
|
||||
# Blockiert alle Ping-Anfragen
|
||||
```
|
||||
```sh
|
||||
iptables -I INPUT 1 -p icmp -s 192.168.0.0/24 -j ACCEPT
|
||||
# Erlaubt ICMP (Ping) aus lokalem Netz vor DROP-Regel
|
||||
```
|
||||
```sh
|
||||
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
|
||||
# SNAT bei Verlassen des Rechners über ppp0
|
||||
```
|
||||
```sh
|
||||
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
|
||||
# Portweiterleitung für transparenten Proxy
|
||||
```
|
||||
---
|
||||
## ⚙️ BENUTZERDEFINIERTE KETTEN
|
||||
Beispiel: Logging + Blocken
|
||||
```sh
|
||||
iptables -N log-drop
|
||||
iptables -A log-drop -j LOG -m limit --limit 6/minute
|
||||
iptables -A log-drop -j DROP
|
||||
iptables -A INPUT -p tcp --dport 22 -i ppp0 -j log-drop
|
||||
```
|
||||
---
|
||||
## 🧰 KOMPLETTES FIREWALL-SKRIPT (MINIMALE VARIANTE)
|
||||
```sh
|
||||
#!/bin/sh
|
||||
FW="/sbin/iptables"
|
||||
# 1. Regeln & Ketten löschen
|
||||
$FW -F
|
||||
$FW -X
|
||||
$FW -t nat -F
|
||||
# 2. Standardregeln: alles erlauben
|
||||
$FW -P INPUT ACCEPT
|
||||
$FW -P FORWARD ACCEPT
|
||||
$FW -P OUTPUT ACCEPT
|
||||
# 3. Ping blockieren
|
||||
$FW -A INPUT -p icmp -j DROP
|
||||
```
|
||||
---
|
||||
## ✅ BEST PRACTICE
|
||||
- **Besser**: „Blockiere alles, erlaube nur was nötig ist“ (Default: DROP)
|
||||
- Verwende `--state ESTABLISHED, RELATED`, um gültige Verbindungen zu erlauben
|
||||
- Speichere Regeln in Skripten (z. B. `/etc/network/firewall`) und rufe sie über `/etc/rc.local` auf
|
||||
---
|
||||
Wenn du möchtest, kann ich dir daraus auch:
|
||||
- eine **Befehlstabelle zum Auswendiglernen**
|
||||
- ein **Mini-Quiz**
|
||||
- oder eine **interaktive Übung** zur Regel-Erstellung erstellen.
|
||||
Sag einfach Bescheid!
|
||||
111
Semester 6/ITSARCH/Skript_Notizen/SSH.md
Normal file
111
Semester 6/ITSARCH/Skript_Notizen/SSH.md
Normal file
@@ -0,0 +1,111 @@
|
||||
## 🔐 SSH – Secure Shell
|
||||
### Definition & Zweck
|
||||
- SSH ist ein **sicheres Protokoll für entfernte Verbindungen** zwischen Client & Server.
|
||||
- Ersatz für unsichere Protokolle wie Telnet, FTP, R-Login, RSH, etc.
|
||||
- Unterstützt: **Datenverschlüsselung, Authentifizierung, Integrität, Komprimierung**
|
||||
- SSH agiert als **Tunnelsystem**, transportiert z. B. SMTP, POP, X11 sicher.
|
||||
---
|
||||
## 🧱 ARCHITEKTUR
|
||||
### SSH besteht aus 3 Schichten:
|
||||
1. **Transportschicht-Protokoll**:
|
||||
- Authentifiziert Server, sichert Vertraulichkeit & Integrität.
|
||||
- Optional: Kompression.
|
||||
|
||||
2. **User-Authentifizierungsprotokoll**:
|
||||
- Authentifiziert Benutzer gegenüber dem Server.
|
||||
|
||||
3. **Verbindungsprotokoll**:
|
||||
- Multiplexing mehrerer Kanäle über eine SSH-Verbindung.
|
||||
|
||||
---
|
||||
## 🔐 SICHERHEIT
|
||||
- **Verschlüsselungsalgorithmen**: AES, DES, Blowfish, ArcFour, CAST128, Twofish
|
||||
- **Key Exchange**: RSA-basierte, asymmetrische Schlüsselaustauschverfahren
|
||||
- **Authentifizierung**: asymmetrisch (Public/Private Key)
|
||||
- Keine Schlüssel werden dauerhaft gespeichert (nur temporär im Speicher)
|
||||
---
|
||||
## 🗝️ AUTHENTIFIZIERUNG
|
||||
### 1. **Host-bezogen**
|
||||
- IP-basiert (unsicher)
|
||||
- RSA-basiert:
|
||||
- Public Key wird auf Server gespeichert
|
||||
- Client beweist Besitz des Private Keys
|
||||
|
||||
### 2. **User-bezogen**
|
||||
- **RSA-Authentifizierung** mit Challenge-Response
|
||||
- **Passwort** (verschlüsselt übertragen, aber weniger sicher)
|
||||
- **RHost-RSA**: Mischung aus IP + RSA
|
||||
---
|
||||
## 🔐 SCHLÜSSELPAARE
|
||||
- Jeder Client/Host besitzt ein eigenes RSA/ECDSA-Schlüsselpaar
|
||||
- Tools: `ssh-keygen`, PuTTYgen
|
||||
- Private Key: bleibt geheim auf Client
|
||||
- Public Key: wird auf Server (z. B. in `authorized_keys`) hinterlegt
|
||||
---
|
||||
## 🔁 VERBINDUNGSAUFBAU (Ablauf)
|
||||
1. **TCP-Verbindung** vom Client zum Server
|
||||
2. **Protokoll- & Versionsaustausch**
|
||||
3. **Umstieg auf binäres SSH-Protokoll**
|
||||
4. Server sendet:
|
||||
- Public Host Key (langfristig)
|
||||
- Public Server Key (flüchtig, stündlich neu)
|
||||
|
||||
5. Austausch der unterstützten Algorithmen
|
||||
6. Client generiert 256-Bit **Sitzungsschlüssel**
|
||||
7. Verschlüsselt diesen mit beiden Server-Keys → sendet verschlüsselt
|
||||
8. Server entschlüsselt mit privaten Keys
|
||||
9. Server schickt Quittung → verschlüsselte Verbindung aktiv
|
||||
10. Client authentifiziert sich
|
||||
11. Sitzung wird eingerichtet
|
||||
---
|
||||
## 🧠 SCHLÜSSELMANAGEMENT
|
||||
- **Private Schlüssel**:
|
||||
- Nie weitergeben, mit Passphrase sichern
|
||||
- Auth Agents wie `ssh-agent`, `Pageant` speichern Keys im Speicher
|
||||
|
||||
- **Public Keys**:
|
||||
- Nur vertrauenswürdige auf Server hinterlegen
|
||||
|
||||
---
|
||||
## 🛡️ SICHERHEITSFEATURES & ABSICHERUNG
|
||||
- **MiM-Angriffe** können durch Key-Verifikation verhindert werden
|
||||
- **Passwort-Auth deaktivieren** (empfohlen):
|
||||
- Konfigurierbar in `sshd_config`: `PasswordAuthentication no`
|
||||
|
||||
- **2FA möglich**
|
||||
- Analyse-Tool: `ssh-audit` zur Prüfung von Konfiguration und Sicherheit
|
||||
---
|
||||
## 🔧 BEFEHLE (OpenSSH)
|
||||
|Befehl|Beschreibung|
|
||||
|---|---|
|
||||
|`ssh`|Verbindung zum Server|
|
||||
|`sshd`|SSH-Serverdienst|
|
||||
|`ssh-agent`|Key-Agent|
|
||||
|`ssh-add`|Keys zum Agent hinzufügen|
|
||||
|`scp`|Dateiübertragung|
|
||||
|`sftp`|sicherer FTP-Ersatz|
|
||||
|`ssh-keygen`|Schlüsselpaar erzeugen|
|
||||
|`ssh-keyscan`|Schlüssel von Hosts abrufen|
|
||||
|`sftp-server`|Serverseitige SFTP-Komponente|
|
||||
---
|
||||
## 📦 SSH-PROTOKOLLVARIANTEN
|
||||
|Variante|Merkmale|
|
||||
|---|---|
|
||||
|**SSH1**|unsicher, veraltet|
|
||||
|**SSH2**|neuer, sicherer (neu geschrieben, bessere Kryptografie)|
|
||||
|**OpenSSH**|Open-Source, nutzt OpenSSL für Krypto, unterstützt SSH1 & SSH2|
|
||||
---
|
||||
## ✅ KLAUSURRELEVANTE PUNKTE
|
||||
- SSH ersetzt unsichere Protokolle → **verschlüsselt alles**
|
||||
- Authentifizierung über **RSA/ECDSA Schlüsselpaar**
|
||||
- Sitzungsschlüssel durch asymmetrische Verschlüsselung ausgetauscht → dann symmetrisch
|
||||
- Tools wie `ssh-agent` & `ssh-add` erhöhen Sicherheit & Komfort
|
||||
- **Passwortauthentifizierung deaktivieren** (wo möglich)
|
||||
- **ssh-audit** zur Analyse verwenden
|
||||
- SSH2/OpenSSH = **Standard**, SSH1 = **veraltet**
|
||||
---
|
||||
Wenn du möchtest, kann ich dir daraus gerne:
|
||||
- **Lernkarten (Flashcards)**
|
||||
- eine **Mindmap**
|
||||
- oder ein **Mini-Quiz** erstellen.
|
||||
Sag einfach Bescheid!
|
||||
106
Semester 6/ITSARCH/Skript_Notizen/TLS 4.5.md
Normal file
106
Semester 6/ITSARCH/Skript_Notizen/TLS 4.5.md
Normal file
@@ -0,0 +1,106 @@
|
||||
## 🔐 GRUNDLAGEN VON SSL / TLS
|
||||
### Was ist SSL/TLS?
|
||||
- SSL (Secure Socket Layer): ursprünglich von Netscape entwickelt.
|
||||
- TLS (Transport Layer Security): Weiterentwicklung von SSL 3.0 durch IETF.
|
||||
- Ziel: **Ende-zu-Ende sichere Kommunikation** über TCP/IP.
|
||||
### Hauptfunktionen
|
||||
- **Datenverschlüsselung**
|
||||
- **Server-Authentifizierung**
|
||||
- **Nachrichtenintegrität (MAC / HMAC)**
|
||||
- **(Optional) Client-Authentifizierung**
|
||||
---
|
||||
## 🧱 PROTOKOLLARCHITEKTUR
|
||||
### SSL-Protokoll besteht aus:
|
||||
- **Handshake Protocol**: Aushandlung der Sicherheitsparameter
|
||||
- **Change Cipher Spec**: Aktivierung neuer Sicherheitsparameter
|
||||
- **Alert Protocol**: Fehler- und Warnmeldungen
|
||||
- **Record Protocol**: Verschlüsselung und MAC auf Anwendungsebene
|
||||
### Protokollstapel:
|
||||
SSL liegt zwischen TCP/IP und der Anwendungsschicht (z. B. HTTP, FTP).
|
||||
---
|
||||
## 🔁 VERBINDUNGSAUFBAU (SSL Handshake)
|
||||
### Ablauf
|
||||
1. **Client → Server**: `Client_Hello`
|
||||
- Protokollversion, Zufallswert, Session-ID, unterstützte Cipher Suites & Kompression
|
||||
|
||||
2. **Server → Client**: `Server_Hello`
|
||||
- Auswahl aus Vorschlägen + Server-Zertifikat (X.509)
|
||||
- optional: `Certificate_Request` → Client-Zertifikat
|
||||
- `Server_Hello_Done`
|
||||
|
||||
3. **Client → Server**:
|
||||
- Optional: `Certificate`, `Certificate_Verify` (Authentifizierung)
|
||||
- `Client_Key_Exchange`: Pre-Master Secret (verschlüsselt mit Server-Public-Key)
|
||||
- `Change_Cipher_Spec`
|
||||
- `Finished`: verifizierbarer Hash
|
||||
|
||||
4. **Server → Client**:
|
||||
- `Change_Cipher_Spec`
|
||||
- `Finished`
|
||||
|
||||
### Wichtig:
|
||||
- **Pre-Master Secret → Master Secret (384 Bit) → Key Block**
|
||||
- **Schlüssel werden symmetrisch genutzt**
|
||||
---
|
||||
## 🗝️ SCHLÜSSELERZEUGUNG
|
||||
Aus dem **Master Secret** werden erzeugt:
|
||||
- MAC-Schlüssel (Client/Server)
|
||||
- Verschlüsselungsschlüssel
|
||||
- Initialisierungsvektoren (IVs)
|
||||
**Aufteilung (Key Block)**:
|
||||
- `Client_Write_MAC_Secret`
|
||||
- `Server_Write_MAC_Secret`
|
||||
- `Client_Write_Key`
|
||||
- `Server_Write_Key`
|
||||
- `Client/Server_Write_IV`
|
||||
---
|
||||
## 📄 ZUSAMMENHÄNGE: SESSION & VERBINDUNG
|
||||
|Begriff|Beschreibung|
|
||||
|---|---|
|
||||
|**Session**|Kommunikationskanal, definiert durch Handshake|
|
||||
|**Verbindung**|Instanz mit eigener Schlüsselverwendung|
|
||||
- Mehrere Verbindungen können zu einer Session gehören.
|
||||
- Session-ID dient zur Wiederaufnahme (Session Resumption).
|
||||
---
|
||||
## 🧾 SSL RECORD LAYER
|
||||
### Verarbeitungsschritte
|
||||
1. Fragmentierung (max. 16 KB)
|
||||
2. **Optionale Kompression**
|
||||
3. **MAC-Berechnung** (z. B. mit SHA/MD5)
|
||||
4. **Verschlüsselung** mit vereinbarten Algorithmen
|
||||
5. Versand
|
||||
### Empfängerseite:
|
||||
- Umgekehrte Schritte (Decryption → MAC-Prüfung → Dekompression)
|
||||
---
|
||||
## ⚙️ WICHTIGE PROTOKOLLDETAILS
|
||||
- **Alert Protocol**: Meldet Fehler (z. B. Handshake Failure)
|
||||
- **Cipher Suites** enthalten:
|
||||
- Verschlüsselungsalgorithmus (z. B. AES, RC4, 3DES)
|
||||
- MAC-Algorithmus (MD5, SHA-1)
|
||||
- Schlüsselaustausch (z. B. RSA, Diffie-Hellman)
|
||||
- **Wiederverwendbare Sitzungen** verbessern Performance:
|
||||
- Session-ID beim `Client_Hello` senden
|
||||
- Bei Erfolg: `Server_Hello` mit derselben Session-ID
|
||||
---
|
||||
## 📦 PORTS FÜR SSL/TLS (laut IANA)
|
||||
|Dienst|SSL-Port|
|
||||
|---|---|
|
||||
|HTTPS|443|
|
||||
|SMTP|465|
|
||||
|POP3|995|
|
||||
|IMAP|993|
|
||||
|NNTP|563|
|
||||
|LDAP|636|
|
||||
|FTP|990|
|
||||
---
|
||||
## ✅ ZUSAMMENFASSUNG FÜR DIE KLAUSUR
|
||||
- TLS = Weiterentwicklung von SSL
|
||||
- Ziel: Verschlüsselung, Authentifizierung, Integrität
|
||||
- SSL-Handshake:
|
||||
- Aushandlung der Cipher Suites
|
||||
- Authentifizierung via Zertifikaten (X.509)
|
||||
- Session Keys für symmetrische Verschlüsselung
|
||||
- SSL ist **applikationsunabhängig**
|
||||
- **SSL Record Layer** = zentrale Schicht zur Absicherung der Nutzdaten
|
||||
---
|
||||
Wenn du willst, kann ich dir daraus auch **Karteikarten**, ein **Quiz**, oder eine **grafische Übersicht** (z. B. Ablaufdiagramm) für den Handshake oder die Schlüsselableitung erstellen. Sag einfach Bescheid!
|
||||
0
Semester 6/Veranstaltungsplan.md
Normal file
0
Semester 6/Veranstaltungsplan.md
Normal file
Reference in New Issue
Block a user