Eine erste Einführung in die Sicherheit von (verteilten) Systemen

Dozent:

Prof. Dr. Michael Eichberg

Kontakt:

michael.eichberg@dhbw-mannheim.de

Version:

2024-05-09

Themen

• Transmission Control Protocol (TCP)

• Einmal-Passwörter

• Secure Shell (SSH)

• Firewalls

Aufbau einer TCP Verbindung

Dreifacher Handshake:

Ports bei TCP

• Port-Nummern werden für die Kommunikation zwischen zwei Diensten/Prozessen verwendet

• Ports sind 16 Bit Zahlen (0-65535)

• (Unix) Ports < 1024 sind privilegiert (nur root kann diese öffnen)

• einige Port-Nummern sind Standarddiensten zugeordnet

Angriffe auf TCP - Motivation

• Netzwerkprogrammierung mit TCP ist relativ komfortabel.

• Viele Dienste sind mit TCP implementiert.

• Angreifer nutzen Schwachstellen in TCP Diensten aus.

• Server haben heutzutage i. Allg. alle nicht verwendeten Dienste geschlossen. Angreifer muss verwundbare Dienste zum Beispiel durch Port Scans finden.

Port Scans: TCP Connect Scan

Port Scans: TCP SYN Scan

Port Scans: Stealth Scans

Versenden eines für den Verbindungsaufbau ungültigen TCP-Segments an einen Port:

• NULL-Scan (keine Flags)

• ACK-Scan (ACK-Flag)

• FIN-Scan (FIN-Flag)

• XMAS-Scan (alle Flags)

Laut RFC kommt RST zurück, falls Port offen. (Reaktion aber abhängig vom Betriebssystem)

Port Scans: Idle Scan [2]

Bei allen bisher betrachteten Scans kann der Scanner prinzipiell identifiziert werden. Unter Verwendung eines sog. Zombies geht es auch anders:

Sondiere IP ID des Zombies:

Starte Scan:

Port Scans: Idle Scan

Starte Scan:

Sondiere IP ID des Zombies:

Port Scans: Idle Scan - Zusammenfassung

• Angreifer sendet SYN/ACK Paket an Zombie

• der Zombie antwortet mit RST und enthüllt seine IP ID (IP Fragment Identification Number).

• Angreifer sendet SYN ("vom" Zombie) an Port des Servers

• [Port offen] Der Zielrechner antwortet mit SYN/ACK an den Zombie, wenn der Port offen ist.

  [Port geschlossen] Der Zielrechner antwortet mit RST an den Zombie, wenn der Port geschlossen ist. Dies wird vom Zombie ignoriert.

• [Port offen] Der Zombie antwortet mit RST, da er kein SYN gesendet hat und kein SYN/ACK erwartet und erhöht seine IP ID.

• Der Angreifer sendet wieder ein SYN/ACK an den Zombie, um die IP ID zu erfahren.

Port Scans mit nmap

• alle Arten von Port-Scans möglich

• auch OS fingerprinting

• 21. 21. sogar Ermittlung der Versionsnummern von Diensten

$ nmap 192.168.178.121 -Pn
Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-14 13:16 PST
Nmap scan report for Michaels-MacBook-Pro (192.168.178.121)
Host is up (0.0056s latency).
Not shown: 995 filtered tcp ports (no-response)
PORT     STATE SERVICE
53/tcp   open  domain
88/tcp   open  kerberos-sec
445/tcp  open  microsoft-ds
5000/tcp open  upnp
7000/tcp open  afs3-fileserver

Port Knocking

• Ein Knock-Daemon versteckt offene Ports auf dem Server.

• Zugriffe auf alle Ports werden im Log-File protokolliert.

• Knock-Daemon beobachtet das Log-File.

• Erst nach Erkennen einer vordefinierten (Einmal-)Klopfsequenz öffnet der Knock-Daemon den gewünschten Port für diesen Client.

• Client kann nun die Verbindung aufbauen.

Connection Hijacking

Angreifer übernimmt eine bestehende - zum Beispiel eine bereits durch (Einmal-)Passwort authentisierte - Verbindung.

Denial-of-Service (DoS) Angriffe

Ziel des Angreifers: Lahmlegen eines Dienstes oder des ganzen Systems ...

• durch Ausnutzen von Schwachstellen (vulnerabilities, z. B. Buffer Overflow)

• durch Generierung von Überlast (Ausschöpfen von RAM, CPU, Netzwerkbandbreite, ...)

Denial-of-Service: SYN-flooding Angriff

• Angriff auf Design

• Angreifer sendet eine Verbindungsaufbauanforderung (gesetztes SYN-Flag) an Zielmaschine

• Server generiert eine halboffene TCP-Verbindung

• Angreifer wiederholt in schneller Folge dieses erste Paket zum Verbindungsaufbau

  ⇒ vollständiges Füllen der internen Systemtabelle

  ⇒ Anfragen normaler Benutzer werden zurückgewiesen

• Angreifer verwendet i. Allg. IP-Spoofing weswegen Firewalls wirkungslos sind.

• Abwehr: SYN-Cookies

SYN-Cookies - D J. Bernstein

SYN-Cookies sind speziell konstruiert initiale Sequenznummern.

Distributed Denial-of-Service (DDoS) Angriff

Opfer wird von sehr vielen Angreifern mit Nachrichten überflutet.

Ein Beispiel: Smurf-Angriff:

Distributed Denial-of-Service (DDoS) Angriff

• Bot-Netze (Botnetze) werden verwendet, um DDoS-Angriffe durchzuführen.

• Bot-Netze können viele 10.000 Rechner umfassen.

• IoT Geräte sind besonders beliebt (z. B. IP-Kameras, Smart-TVs, Smart-Home Geräte, ...), da diese oft nicht ausreichend geschützt sind und trotzdem permanent mit dem Internet verbunden sind.

• Beliebte Ziele:

  • Onlinespieleserver

  • Banking-Portale

  • politische Webseiten

• Firewalls und Intrusion Detection Systeme sind meist wirkungslos, da die Angriffe von vielen verschiedenen IP-Adressen kommen.

Distributed-Reflected-Denial-of-Service (DRDoS) Angriff

• Idee:

  • Es wird eine Anfrage an einen Server gesendet, die eine große Antwort auslöst. (z. B. hat(te) der NTP Monlist Befehl eine Antwort, die ca. 200 Fach größer ist als die Anfrage!)

  • Mittels IP-Spoofing wird die IP-Adresse des Opfers als Absenderadresse verwendet.

  • Es werden insbesondere Dienste basierend auf UDP verwendet, da hier keine Verbindung aufgebaut werden muss.

• Nehmen einen signifikanten Teil aller DDoS-Angriffe ein.

• Die Tatsache, dass die Sender legitime Server sind, erschwert die Abwehr.

• Egress Filtering kann helfen, die Verwendung von IP-Spoofing zu verhindern.

Distributed Denial-of-Service (DDoS) Angriffe - Beispiel

[...] Google's DDoS Response Team has observed the trend that distributed denial-of-service (DDoS) attacks are increasing exponentially in size. Last year, we blocked the largest DDoS attack recorded at the time. This August [2023], we stopped an even larger DDoS attack — 7½ times larger — that also used new techniques to try to disrupt websites and Internet services.

This new series of DDoS attacks reached a peak of 398 million requests per second (rps), and relied on a novel HTTP/2 “Rapid Reset” technique based on stream multiplexing that has affected multiple Internet infrastructure companies. By contrast, last year's largest-recorded DDoS attack peaked at 46 million rps.

Distributed Denial-of-Service (DDoS) Angriffe

Schutz vor DDoS-Angriffen - On-Site Robustheitsmaßnahmen

• Aufrüsten der Ressourcen (z. B. Bandbreite, CPU, RAM, ...)

• Exemplarische Sofortmaßnahmen bei aktivem Angriff:

  • Whitelisting von IP-Adressen von besonders wichtigen Clients

  • Blacklisting von IP-Adressen aus bestimmten Bereichen

  • Captchas

  • Überprüfung der Browser-Echtheit

• Anti-DDos Appliances

Schutz vor DDoS-Angriffen - Off-Site Robustheitsmaßnahmen

• Einbinden des ISP

• Einbinden spezialisierter Dienstleister (im Angriffsfall wird mittels BGP-Rerouting der Traffic an den Dienstleister umgeleitet, der dann die DDos Attacke filtert.)

• Content-Delivery-Networks (CDNs) für statische Inhalte (z. B. Cloudflare, Akamai, ...)

• Distributed Clouds

Password Sniffing

In der Anfangszeit:

unverschlüsselte Übertragung von Passwörtern (telnet, ftp, ...)

In der Übergangszeit (bzw. in bestimmten Szenarien auch heute):

Verwendung von Einmal-Passwörtern (S/Key, ...)

Heute:

Passwörter werden verschlüsselt übertragen (ssh, https, ...)

Einmal-Passwörter

Die Idee ist, dass Passwörter nur genau einmal gültig sind und nicht wiederverwendbar sind.

• Tokens (z. B. RSA SecurID)

• Codebuch: Liste von Einmal-Passwörtern, die das gemeinsame Geheimnis sind.

• S/Key: Passwort "wird mit einem Zähler kombiniert" und dann gehasht.

Das S/Key Verfahren

Einmal-Passwort-System nach Codebuch-Verfahren, dass im Original auf der kryptographischen Hashfunktion MD4 basiert.

Secure Shell (SSH)

Verschlüsselte Verbindung

SSH ermöglicht die sichere Fernanmeldung von einem Computer bei einem anderen (typischerweise über TCP über Port 22). Es bietet mehrere Optionen für eine starke Authentifizierung und schützt die Sicherheit und Integrität der Kommunikation durch starke Verschlüsselung

Secure Shell (SSH) - Protokoll

Secure Shell (SSH) - Verbindungsaufbau - Beispiel

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to example.org [1.2.3.4] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_5.8
debug1: match: OpenSSH_5.8 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'example.org' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased
debug1: Next authentication method: password
user@example.org's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8

Secure Shell (SSH) - Risiken durch mangelnde Schlüsselverwaltung

• Schlüssel werden nicht regelmäßig ausgetauscht

• Schlüssel werden nicht gelöscht, wenn sie nicht mehr benötigt werden

• viele (die meisten) Schlüssel werden nicht verwendet

• Es ist oft nicht bekannt, wer Zugriff auf welche Schlüssel hat(te)

• Es ist nicht bekannt, welche Schlüssel auf welche Systeme Zugriff haben

• Malware kann SSH-Schlüssel stehlen

• SSH Keys können ggf. privilegierten Zugriff gewähren

• SSH Keys können benutzt werden, wenn um Backdoors zu verstecken

• Server keys erlauben ggf. Man-in-the-Middle-Angriffe

SSH Tunneling

• ermöglicht die Übertragung beliebiger Netzwerkdaten über eine verschlüsselte SSH-Verbindung. z. B.

  • um ältere Anwendungen zu verschlüsseln.

  • um VPNs (Virtual Private Networks) zu implementieren

  • um über Firewalls hinweg auf Intranetdienste zuzugreifen.

• ermöglicht auch Port-forwarding (lokale Ports werden auf entfernten Rechner weitergeleitet)

SSH und Back-tunneling

• Der Angreifer richtet einen Server außerhalb des Zielnetzwerks ein

• Nach Infiltration des Zielsystems verbindet der Angreifer sich von innen mit dem externen SSH-Server.

• Diese SSH-Verbindung wird so eingerichtet, das eine TCP-Port-Weiterleitung von einem Port auf dem externen Server zu einem SSH-Port auf einem Server im internen Netzwerk möglich ist.

• Die meisten Firewalls bieten wenig bis gar keinen Schutz dagegen.

Schwachstellen in SSH

Nearly 11 million SSH servers vulnerable to new Terrapin attacks

[...] It [The Terrapin attack] manipulates sequence numbers during the handshake process to compromise the integrity of the SSH channel, particularly when specific encryption modes like ChaCha20-Poly1305 or CBC with Encrypt-then-MAC are used. [...]

By Bill Toulas

—January 3, 2024 10:06 AM

Unabhängiges Netz - Ideale Situation

Vorteile:

• keinerlei Angriffsmöglichkeiten von außen

Nachteile:

• kein Schutz gegen Insider

• kein Zugang zum Internet

Von der Notwendigkeit des Schutzes von Rechnern

[...] Züger und sein Team hätten [...] erst kürzlich ein Experiment durchgeführt, [...]. Sie hätten einen Computer "ohne jeglichen Schutz" mit dem Internet verbunden, um zu sehen, wie lange es dauere, bis er befallen sei. Konkrete Details zur Konfiguration dieses Systems werden zwar nicht genannt, angeblich war der Rechner aber schon nach 20 Minuten infiltriert.

—Golem.de 6.2.2024

Schutzschicht zwischen internem und externem Netz

• Kontrolle des Nachrichtenverkehrs durch Filterung

• begrenzte Isolation mit begrenztem Schutz

Realisierung von Virtual Private Networks (VPN)

• Aufbau einer scheinbar privaten Verbindung von Firmenteilnetzen über das (öffentliche) Internet

• Zusätzliche Verbindungsverschlüsselung zwischen den Firewalls.

Kommerzielle VPNs für Endnutzer

Schutz auf den Schichten des TCP/IP Stacks

Zentraler Schutz des gesamten internen Netzwerks durch:

• Paket Filter (Packet Filtering)

  • Blockieren bestimmter IP-Empfänger-Adressen (extern / intern)

  • Blockieren bestimmter IP-Absender-Adressen (extern / intern)

    (z. B. aus dem Internet mit internen IP-Absender-Adressen.)

  • Blockieren bestimmter Dienste; ggf. nur für bestimmte IP-Adressen

• Filter auf Anwendungsebene (Application-level Filtering)

  • inhaltsbezogene Filterung der Verkehrsdaten eines Dienstes

  • z. B. Virenfilter

  • wirkungslos bei verschlüsselten Verkehrsdaten

• Protokollierungsmöglichkeit der Kommunikation von / nach extern

Realisierungsmöglichkeiten von Firewalls

• Hardware-Firewall

  • Screening Router

  • Application Gateway (auch Bastion Host)

    • Proxy-Server für bestimmte Dienste

    • Client-Software (HTTP-Browser, telnet, ftp, ...)

    • Server-Software

• Software-Firewall (Personal Firewall)

Dual-Homed Host

Aufbau

• zwei Netzwerkkarten: ggf. private interne Adressen

• Screening Router & Gate: Packet Filter und Application-Level Filter

• Proxy-Dienste installieren

• Benutzer-Logins von extern

• Konf. der Netzwerkkarten: IP-Pakete nicht automat. weiterleiten

Screening Router

Aufbau

• programmierbarer Hardwarerouter

• simple Filterfunktionen:

• nur Paket-Header prüfen

• schnelle Auswertung ermöglicht hohen Durchsatz

• Realisierung eines Packet Filters

Bewertung

• einfach und billig

• flexibel

• schwer zu testen

• Protokollierung

• Fernwartung

• keine Inhaltsfilterung

Screened Host

Aufbau

• Screening Router blockiert:

  • Pakete von / an interne Rechner (nicht Gate)

  • Source-Routed Pakete

• von extern nur Gate sichtbar

• Pakete von intern nur via Gate

• Gate bietet Proxy-Server (z. B. für E-Mail)

Konfiguration eines Gateways

Das Ziel der Konfiguration muss eine minimale angreifbare Oberfläche sein.

• Abschalten aller nicht-benötigten Netzdienste

• Löschen aller nicht benötigter Programme

• Rechte von /bin/sh auf 500 setzen

• Rechte aller Systemverzeichnisse auf 711 setzen

• keine regulären Benutzerkennungen

• root-Login mit Einmal-Passwortsystem

• setzen von Platten- und Prozess-Quotas

• volle Protokollierung, möglichst auf Hardcopy-Gerät

• möglichst sichere, stabile und regelmäßig aktualisierte Betriebssystemversion einsetzen

Screened Subnet

Aufbau

• interner Screening Router als weiterer Schutzwall

  • blockiert Dienste, die nicht einmal bis zum Gate gelangen sollen

  • lässt nur Pakete zum / vom Gate durch

• äußeres Netz realisiert Demilitarisierte Zone (DMZ) für HTTP-Server, Mail-Server, ...

Intrusion Detection Systeme (IDS)

IDS-Erkennungstechniken

• Signaturerkennung

• statistische Analyse

• Anomalieerkennung