Generelle Bemerkungen zu Netzwerkdiensten TCP wrapper und Paketfilter arbeiten an der Systemgrenze, bevor die Server mit einem Paket gefüttert werden

Transkript

1 Übersicht TCP/IP-Protokollschwächen und Angriffe Service-Konfiguartion Der Unix-Boot-Prozess inetd und xinetd Zugriffskontrolle durch wrappers Lokale Paketfilter Ausgewählte Dienste: SSH Telnet SMTP DNS HTTP X System-Management 59

2 Generelle Bemerkungen zu Netzwerkdiensten TCP wrapper und Paketfilter arbeiten an der Systemgrenze, bevor die Server mit einem Paket gefüttert werden Die Server selbst können bekannte oder unbekannte Schwachstellen haben Mit jedem neuen Server steigt die Wahrscheinlichkeit, dass das System durch eine Schwachstelle kompromittiert wird Gute security policy: alle Dienste abschalten, die nicht wirklich gebraucht werden Dienst ausschalten entweder durch Auskommentierung in den entsprechenden Konfigurationsdateien oder über grafisches Interface für die Systemkonfiguration (wie SuSe YaST) Wir gehen jetzt einzelne ausgewählte Netzwerkdienste durch und besprechen kurz ihre Sicherheitsrisiken weitere werden besprochen bei Garfinkel, Spafford, Schwartz in Kapitel 12 60

3 ssh (TCP-Port 22) ssh (secure shell) ist ein kryptographisch-abgesichertes Protokoll für remote login, Kopieren von Dateien und dem sicheren Tunneln von TCP-Verbindungen Original von Tatu Ylonen, als Ersatz für rlogin und rsh heute auch populär: OpenSSH vom OpenBSD-Projekt ssh liegt mittlerweile in Version 2 vor Unterstützt RSA und DSA für die Authentifikation hat mehrere Schwachstellen der Version 1 ausgebügelt Konfigurationsdatei sshd_config Je nach Version woanders, es sollte jeweils nur eine geben! ssh benutzt Kryptographie für Host-Authentifikation Client bzw. Benutzer-Authentifikation Vertraulichkeit und Integrität des Nachrichtenverkehrs 61

4 Host-Authentifikation bei ssh Jeder ssh-host hat eine (asymmetrisches) RSA und DSA Schlüsselpaar Wird bei der Installation bzw. ersten Benutzung erzeugt Anzahl der Bits kann in sshd_config konfiguriert werden ssh-verbindungsaufbau: Aushandeln der Protokollversion (im Klartext) Aushandeln der verwendeten Kryptoalgorithmen (KEXINIT, auch im Klartext) Diffie-Hellmann-Schlüsseltausch, erzeugt gemeinsamen Schlüssel K, zunächst serverseitig (DH_GEX) Server schickt seinen öffentlichen Schlüssel zusammen mit einer Signatur auf dem Hash des Verbindungsaufbaus an den Client Client überprüft Signatur anhand von known_hosts und berechnet gemeinsamen Schlüssel K Session-keys für Verschlüsselung und Integrität werden aus K, dem Hash, der Session ID etc. berechnet ab NEWKEYS gelten die neuen Schlüssel 62

5 Verbindungsaufbau bei ssh (Beispiel) ssh -v OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003 debug1: Reading configuration data /home/gaertner/.ssh/config [...] debug1: Connecting to houston.informatik.rwth-aachen.de [ ] port 22. debug1: Connection established. [...] debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1 Debian 1:3.8.1p1-8 debug1: match: OpenSSH_3.8.1p1 Debian 1:3.8.1p1-8 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST 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 'houston.informatik.rwth-aachen.de' is known and matches the RSA host key. debug1: Found key in /home/gaertner/.ssh/known_hosts:12 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received [...] 63

6 Host-Authentifikation (Forts.) Ist der ssh-server unbekannt, wird um Bestätigung gebeten: The authenticity of host 'explorer' can't be established. RSA key fingerprint is a4:70:69:80:ac:72:7d:88:b9:a5:2c:98:58:1c:44:4a. Are you sure you want to continue connecting (yes/no)? Bei Akzeptierung wird der Host-Key der Datei ~/.ssh/known_hosts hinzugefügt Bei zukünftigen Verbindungen wird nicht nochmal nachgefragt dann wird vorausgesetzt, dass der Host mit demselben Namen auch der ist, der er bei der letzten Verbindung war Warum wird hierdurch IP-Spoofing verhindert? 64

7 Host-Authentifikation (Forts.) Wenn ein Host, der vorher bekannt war, plötzlich einen anderen Schlüssel hat VORSICHT: Es könnte jemand spoofen (und zum Beispiel eine man-in-the-middle-attacke fahren)! ssh warnt davor mit einer drastischen Meldung Der Benutzer muss selbst die Datei ~/.ssh/known_hosts editieren, um die Warnung loszuwerden und die Verbindung herzustellen Veränderungen bzw. Erneuerung des Host-Schlüssels passiert je nach Kontext selten bis häufig: teilweise bei jedem System-Upgrade oder bei Neuinstallation von ssh Wenn der Schlüssel sich ändert, sollte man die Ursache untersuchen 65

8 Client-Authentifikation in SSH Es gibt verschiedene Authentifikationsmöglichkeiten: per Kennung und Passwort NB: Beides wird verschlüsselt übetragen per public key-kryptographie Client kann nachweisen, dass er den geheimen Schlüssel eines öffentlichen Schlüssels in der Datei ~/.ssh/authorized_keys kennt bei Zugriff von einem "trusted host" wenn sie von einem Host zugreifen, der in der Datei ~/.ssh/known_hosts steht wenn sie von einem Host zugreifen, der in der Datei /etc/hosts.equiv oder /etc/ssh/shosts.equiv steht wenn der Host nachweisen kann, dass er den geheimen Schlüssel eines öffentlichen Schlüssels in der Datei /etc/ssh_known_hosts kennt per Kerberos (wollen wir hier nicht betrachten) 66

9 Client-Authentifikation (Forts.) Authentifikationsmethoden können konfiguriert werden beste Methode wird wieder ausgehandelt Beispiel einer ssh-session (Fortsetzung) mit Option -v werden debug-meldungen über den Protokollverlauf ausgegeben mehr Meldungen mit -v -v usw. [...] debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/gaertner/.ssh/identity debug1: Trying private key: /home/gaertner/.ssh/id_rsa debug1: Offering public key: /home/gaertner/.ssh/id_dsa debug1: Server accepts key: pkalg ssh-dss blen 433 debug1: read PEM private key done: type DSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. [...] 67

10 telnet (TCP-Port 23) Klassische Dienst für ein virtual terminal Client: telnet, Server: telnetd Mit dem telnet-client kann man sich zu jedem TCP/IP- Server verbinden, der ein textbasiertes Protokoll fährt Telnet ist bekannt unsicher: Kennung und Passwort ist nicht verschlüsselt und kann sehr leicht gesnifft werden einfach die ersten 100 Bytes einer Verbindung auf Port 23 sniffen Gefahr von session hijacking (speziell bei älteren Implementierunge von telnet) Wer telnet trotzdem braucht: Einmalpasswörter verwenden! Ansonsten besser ssh benutzen 68

11 Mail (SMTP, TCP-Port 25) SMTP ist der Internet-Standard für SMTP wird in Unix-Systemen implementiert durch Programme, die Mail Transfer Agents (MTAs) genannt werden MTAs implementieren in der Regel sowohl die Client- and auch Server-Seite des Protokolls Populäre MTAs: exim, postfix, qmail, sendmail MTAs sind schwer zu konfigurieren und administrieren Zum benutzerseitigen Versenden, Abrufen und Lesen von gibt es einfacherer Programme: Message User Agents (MUAs) Beispiele: Eudora, Emacs, Microsoft Outlook, Pegasus Mail, mutt; MUAs benutzen einen MTA als "SMTP Server" Hauptprobleme bei Viren, SPAM Vertraulichkeit, Authentizität und Integrität der Nachrichten 69

12 Mail-Spoofing s sind Textnachrichten, können beliebig gescannt und verändert werden Echelon-System (siehe Bamford: Body of Secrets) Beispiel für eine Mail-Spoofing-Session mittels telnet: telnet localhost smtp [...] Connected to localhost. Escape character is '^]'. 220 explorer.local ESMTP Postfix HELO gaertner 250 explorer.local MAIL FROM: 250 Ok RCPT TO: 250 Ok DATA 354 End data with <CR><LF>.<CR><LF> Great lecture! George. 250 Ok: queued as 3CF0B85A0E QUIT 221 Bye Connection closed by foreign host. 70

13 DNS (TCP- und UDP-Port 53) DNS ist der Namensdienst, der symbolische Adressen in IP-Adressen verwandelt aber auch: Mailserver einer Domain herausbekommen Hostname zu einer IP-Adresse herausbekommen Programm: host Konfiguration des verwendeten DNS-Servers in /etc/resolv.conf Als Antwort auf eine Anfrage bekommt man Einträge aus der Nameserver-Datenbank zurückgeliefert: A = authorative address (IP-Adresse) MX = mail exchange (Mailserver einer Domäne) CNAME = canonical name (alias für den Host) NS = name server (responsible for resolving a domain) PTR = pointer record (maps IP address to hostname) PTR implementiert durch Domain IN-ADDR.ARPA Probe: host IN-ADDR.ARPA 71

14 DNS-Beispiele host i4mail i4mail.informatik.rwth-aachen.de A gaertner@houston:~$ host -a CNAME lucan.cs.purdue.edu lucan.cs.purdue.edu A gaertner@houston:~$ host -t MX cs.purdue.edu cs.purdue.edu MX 1 mailslot.cs.purdue.edu gaertner@houston:~$ host -t PTR Name: i4mail.informatik.rwth-aachen.de Address: gaertner@houston:~$ 72

15 DNS-Gefahren DNS kann sowohl per UDP (Normalfall) als auch TCP angesprochen werden TCP wird für das Auslesen der gesamten Datenbank eines Nameservers verwendet (zone transfer) Zone transfers geben (zu) viele Informationen über ein internes Netz preis viele Administratoren erlauben DNS via UDP aber nicht via TCP DNS-Einträge werden im lokalen Nameserver-Cache gehalten: Cache poisoning z.b. über DNS spoofing DNS-Server gleichen regelmäßig ihre Inhalte ab: sollte nur über authentifizierte Kanäle geschehen 73

16 HTTP (TCP-Port 80) Zugriffsprotokoll auf Seiten des WWW Client fragt beim Server nach einer Seite Server antwortet mit einer ASCII oder HTML-Seite Hier gäbe es viel mehr zu erzählen 74

17 X (TCP-Ports ) X: populäres grafisches Fenstersystem, verfügbar auf allen Unixen Jedes Display wird von einem X-Server verwaltet X-Clients kontaktieren den X-Server, wenn sie etwas anzeigen wollen populäre X-Clients: xterm, xclock,... X-Server kapselt Zugriffe auf Maus, Keyboard, Bildschirm Devices sind "world readable" jeder kann den Bildschirminhalt auslesen Besser: Rechte der Devices ändern auf den, der gerade an der Konsole eingeloggt ist Datei /etc/logindevperm enthält Liste von Devices, deren Rechte man dann ändern muss 75

18 X Security Sicherheitsmodell in X: alles oder nichts Wenn ein X-Client Zugriff auf den X-Server hat, darf er alles Gefahr: Trojanische Pferde in beliebten X-Applikationen liest das Strategiespiel gerade meinen Bildschirm aus und schneidet meine Tastaturanschläge mit? Transparentes Fenster, was den gesamten Bildschirm überlagert "secure" input in X11R4 und xterm: CTRL linke Maustaste erzeugt einen direkten Kanal zum xterm, den kein transparentes Fenster mitschneiden kann Zugriffskontrolle über xhost: mit xhost kann man Rechnern den Zugriff erlauben oder entziehen X durch einen ssh-tunnel ssh -X rechner 76

19 Zusammenfassung und Ausblick Generell sollte man beim Aufsetzen eines Internet- Rechners so wenige Dienste wie möglich laufen lassen: bietet weniger Angriffsfläche Dienste am besten auf Rechner verteilen Kompromittierung von HTTP führt dann nicht automatisch zur Komprommitierung von ssh Möglichst mehrere Verteidigungsschichten verwenden Zum Beispiel TCP Wrappers und Paketfilter Das System erst ans Netz bringen, wenn es abgesichert ist, nie vorher Herunterladen von Patches auf einem sicheren Computer Das System vorher einem Test unterziehen Security Scanner, etc., 77