Frage 12.)
Angriff: ARP-Spoofing
Woran erkannt: Selbe MAC-Adresse bei Client (10.0.1.14) und Gateway (10.0.1.254)
Erläuterung: Angreifer sendet gefälschte ARP Response Nachrichten an von ihm gewählte Systeme um deren ARP Cache zu manipulieren.
Dabei täuscht der Angreifer vor, selbst das Gateway (Router) zu sein. Datenverkehr wird dadurch über ihn ins Internet oder zwischen den Systemen
übertragen.
"Skizze": Angreifer ----ARP-Response-(10.0.1.254 is at 00-50-56-94-57-1d)----> Opfer
Opfer ARP-Cache --> Eintragen der neuen ARP-Information
Ähnliches Angriffsszenario für IPv6: ND-Spoofing
ND-Spoofing Erklärung: Host schickt Neighbour Solicitation ins geswitchte Netzwerk, um MAC-Adresse eines anderen Systems zu erfragen.
Da Neighbour Advertisements (= Antworten) aber genau wie bei IPv4/ARP ebenfalls ungeschützt sind, kann Angreifer mit seiner MAC Adresse antworten.
Frage 13.)
a.)
Probleme:
Beide Kommunikationspartner liegen hinter einem NAT Gateway und sind nicht direkt aus dem unsicheren Netzwerk (Internet) erreichbar.
Ende-zu-Ende-Konnektivität wird gebrochen, da die NAT-Übergabestelle das Ziel eingehender Verbindungen nicht automatisch ermitteln kann.
Lösung:
NAT-Traversal --> Hole Punching
Austausch der Adressinformation über einen Rendezvous-Server + "Schlagen eines Lochs" (= Hole Punching) in die NATs,
sodass Datenverkehr der Gegenstelle wie Antworten auf Anfragen aussieht.
Voraussetungen:
Rendezvous-Server und Peers kennen jeweils die privaten und öffentlichen Endpunkte (private/public endpoints).
Adressumsetzung am NAT Endpoint-Independent Mapping (zielunabhängiges Umschreiben).
b.)
Probleme NAT/FTP:
Bei NAT-Router: Da die Hauptverbindung ausgehend ist, wird sie von der NAT Firewall erlaubt. Aber wenn der Server versucht, sich mit dem Client
rückzuverbinden, wird er von der Firewall blockiert.
FTP Passive Mode (PASV) ist weniger problematisch, weil Verbindungen nur vom Client zum Server erstellt werden, aber nicht umgekehrt.
14.)
a.)
Tunnel Mode
Transport Mode
Tunnel Mode --> Site to Site
Transport Mode --> Client to Client
Einer der Modi möglicherweise überflüssig? Begründen --> ???
b.)
AH:
Tunnel Mode / Site-to-Site: || IP-Header | AH-Header | IP-Header | TCP/UDP-Header | Anwendungsdaten ||
Transport Mode / Client-to Client: || IP-Header | AH-Header | TCP/UDP-Header | Anwendungsdaten ||
ESP:
Tunnel Mode / Site-to-Site: || IP-Header || ESP-Header | IP-Header | TCP/UDP-Header | Anwendungsdaten | ESP-Trailer | ESP-Auth ||
Transport Mode / Client-to-Client: || IP-Header | ESP-Header | TCP/UDP-Header | Anwendungsdaten | ESP-Trailer | ESP-Auth ||
Paketbereiche durch AH bzw. ESP geschützt (alles nach AH- bzw. ESP-Header)
15.)
a.)
Anomalieerkennung erkennt und meldet Abweichungen von einem definierten (manuell oder erlernt) Normalverhalten.
Z. B.: Ungewöhnliche hohe Anzahl von Verbindungen zu einem Dienst/Server. Ungewöhnlich hohes Datentransfervolumen auf einer Leitung.
Vorteile:
???
Nachteile:
???
16.)
a.)
Anfragen an die Root-Name-Server könnten nicht mehr beantwortet werden und sämtliche Websiten, die nicht im DNS-Cache des jeweiligen Computers (auf dem angefragt wird)
oder des nächsten Resolvers liegen, könnten nicht mehr aufgerufen werden.
b.)
Für den Sender eines Queries ist die Authentizität und Integrität des empfangenen Responses nicht feststellbar (bzw. nur sehr schwacher „Schutz“, z.B. Query ID).
c.)
???
