run level

Verlässliche Verteilte Systeme 1
Angewandte IT-Robustheit und IT-Sicherheit
Vorlesung im Wintersemester 2004/2005
Prof. Dr. Felix Gärtner
Teil 15: Sichern von TCP- und UDP-Diensten
(System Setup)
1
Lehr- und Forschungsgebiet Informatik 4, RWTH Aachen, http://www-i4.informatik.rwth-aachen.de/lufg/
Motivation
Lokale Zugriffskontrolle sichert einen Rechner vor
direktem, physischem Zugang
●
●
●
Rechner sind heute oft ans Internet angeschlossen
Zugriff auf die angebotenen Dienste aus der ganzen Welt
möglich
Man sollte nie "einfach so" einen Rechner ans Internet
anschliessen!
●
●
●
Zunächst prüfen, ob es bekannte Sicherheitsprobleme mit
dem System gibt
Ansonsten wird das System früher oder später kompromittiert
werden
Heute: sicheres System-Setup
●
●
●
Aufsetzen eines neuen Servers
Grundlage: Garfinkel, Spafford, Schwartz, Kapitel 12
2
Übersicht
Service-Konfiguartion
Der Unix-Boot-Prozess
inetd und xinetd
Zugriffskontrolle durch wrappers
Lokale Paketfilter
Ausgewählte Dienste:
●
●
●
●
●
●
●
●
●
●
●
●
SSH
Telnet
SMTP
DNS
HTTP
X
3
Unix Dienste und Ports
Unix Netzwerkdienste werden durch individuelle
Programme angeboten (Server), charakterisiert durch:
●
●
●
Server müssen irgendwann einmal gestartet werden
●
●
meist beim Boot-Vorgang, aber auch on demand
Portnummern sind beliebig, werden aber für bestimmte
Internetdienste fest vergeben
●
●
●
●
●
Protokoll (TCP oder UDP)
Portnummer
well-known ports (0-1023)
registered ports (1024-49151)
private ports (ab 49152)
Standardisierung durch IANA, siehe:
http://www.iana.org/assignments/port-numbers
●
Lokale Datenbank: /etc/services
4
/etc/services
●
●
Gegenüberstellung von Ports, Protokollen, Dienstnamen
und Aliasen
Beispiel:
# /etc/services
# Network services, Internet style
[...]
ssh
22/tcp
# SSH Remote Login Protocol
ssh
22/udp
# SSH Remote Login Protocol
telnet
23/tcp
# Telnet
telnet
23/udp
# Telnet
smtp
25/tcp mail
# Simple Mail Transfer
smtp
25/udp mail
# Simple Mail Transfer
[...]
mumps
188/tcp
# Plus Five's MUMPS
[...]
5
Port-Nummern
Server können die ihnen zugewiesene Portnummer mittels
getservbyname() aus /etc/services auslesen
●
●
●
●
Manchmal sind Portnummern auch ins Programm hart
hineincodiert
Manchmal wird die Portnummer in einer Konfigurationsdatei
spezifiziert
Manchmal ä ndert ein Server seine Portnummer zur Laufzeit
(passiert selten bei well-known ports)
Portzuweisung ist ein akzeptierter Unix-Standard, keine
technische Notwendigkeit
●
●
●
●
●
well-known ports heissen manchmal auch trusted ports
Aber auf Port 22 kann auch etwas anderes horchen als der
sshd
Windows-Maschinen müssen nicht den Unix-Standard
gehorchen
Dienste können über andere Ports getunnelt werden
6
Das Tunnel-Prinzip
●
●
Prinzipiell kann jeder Datenstrom in jeden anderen
Datenstrom hineincodiert werden
Beispiel: X-Window-Verbindungen über eine SSHVerbindung
7
Übersicht
Service-Konfiguartion
Der Unix-Boot-Prozess
inetd und xinetd
Zugriffskontrolle durch wrappers
Lokale Paketfilter
Ausgewählte Dienste:
●
●
●
●
●
●
●
●
●
●
●
●
SSH
Telnet
SMTP
DNS
HTTP
X
8
Zwei Arten von Netzwerkservern
(Netzwerk-)Server sind Prozesse, die Dienste anbieten
●
Als "Server" werden manchmal auch Rechner bezeichnet, auf
denen Server laufen
●
Zwei Arten von Servern:
●
Server, die immer laufen
●
●
●
●
Werden beim Systemstart (boot) gestartet
Normalerweise Server, die schnell reagieren sollen und hohe
Lasten erwarten
Beispiele: httpd, nsfd
Server, die bei Bedarf gestartet werden
●
●
●
●
●
Meta-Server inetd (Internet Daemon) lauscht an vielen Ports
Startet entsprechenden Server-Prozess bei eingehender
Verbindung
Spart Systemressourcen bei wenig benutzten Diensten
Beispiele: fingerd, popper
9
Systemstart (boot)
Server stehen typischerweise in /usr/sbin oder /usr/libexec
Server werden beim Systemstart in gewählter Reihenfolge
gestartet
●
●
●
●
Früher: einzelnes Shell-Skript /etc/rc mit lokalen Anteilen
in /etc/rc.local
Heute je nach System unterschiedlich
System V (Solaris, Linux):
●
●
komplexes System mit vielen Verzeichnissen und run levels
(gleich mehr dazu)
BSD-basierte Systeme:
●
●
●
Server stehen in /usr/local/etc/rc.d/
Start-Skripte /etc/rc.conf und /
etc/defaults/rc.conf
Mac OS X:
●
●
Start-Skripte in /System/Library/StartupItems/
10
Linux Bootvorgang
siehe man boot bzw. man init.d
Normalerweise fünf Phasen:
●
●
1.
2.
3.
4.
5.
Hardware boot
OS loader
kernel startup
init und inittab
boot-Skripte
Phase 1: Hardware boot
●
●
●
●
Computer liest Start-Routine aus dem BIOS
Im wesentlichen: welche boot devices sollen in welcher
Reihenfolge angesprochen werden
Anschliessend: Zugriff auf festgelegte Stelle auf einem boot
device, laden des OS loaders
11
Linux Bootvorgang (Forts.)
Phase 2: OS loader
●
OS loader ist ein kleines Programm, liegt im ersten Sektor
des boot devices (Master boot record - MBR)
Starke Platzrestriktionen, normalerweise 512 bytes inklusive
Partitionstabelle
●
●
●
●
●
●
Oft lädt der OS loader im MBR einen zweiten OS loader, der
woanders auf dem boot device liegt
Unter Linux: lilo und grub
OS loader lädt und startet das Betriebssystem
Teilweise interaktive Auswahl möglich (dual boot Systeme)
Phase 3: kernel startup
●
●
●
Betriebssystem initialisiert die devices, startet den swapper,
mountet das root Dateisystem
Startet den ersten Prozess (PID 1) mit dem Programm
/sbin/init
12
Linux Bootvorgang (Forts.)
Phase 4: init und inittab
●
Das Programm init liest die Datei /etc/inittab
Dort steht, was laufen soll in welchem run level
●
●
●
●
●
●
●
●
●
●
●
Run level 0: Level used for halting the system (nur ein erlaubter
Service: halt)
Run level 6: Level used for rebooting the system (nur ein
erlaubter Service: reboot)
Run level S: Used to switch from boot phase to single user mode
(hier hat man am Ende nur eine Konsole)
Run level 1: Used to switch from normal run level to single user
mode
Run level 2: Normalbetrieb ohne Netzwerk (mehrere Konsolen
möglich)
Run level 3: Normalbetrieb mit Netzwerk
Run level 5: Normalbetrieb mit Netzwerk und X-Window-System
Administrator kann zwischen run levels wechseln
Verweise auf einzelne Start-Skripte pro run level
13
Linux Bootvorgang (Forts.)
Phase 5: boot-Skripte (Solaris und die meisten Linuxe)
●
Jeder Dienst hat ein einzelnes Start-Skript in /etc/init.d
Skript akzeptiert als Parameter das Wort "start"
Um einzelne Skripte in bestimmten run levels zu starten:
●
●
●
●
●
●
●
●
●
●
Symbolische Links in speziellen Verzeichnissen
für run level X ist das /etc/rc.d/rcX.d/
Skripte mit dem Namen S... werden mit dem Parameter
"start" aufgerufen
Beispiel: /etc/rc.d/rc3.d/S05network
●
Beim Übergang zu run level 3 wird
/etc/init.d/network start aufgerufen
Entsprechend beim Verlassen des run levels werden die Skripte
mit Namen K... mit dem Parameter "stop" aufgerufen
chkconfig als Programm, mit dem die Skripte (und Links)
verwaltet werden (siehe man chkconfig)
Beispiel: Netzwerk von Hand neu starten:
/etc/init.d/network restart
14
Übersicht
Service-Konfiguartion
Der Unix-Boot-Prozess
inetd und xinetd
Zugriffskontrolle durch wrappers
Lokale Paketfilter
Ausgewählte Dienste:
●
●
●
●
●
●
●
●
●
●
●
●
SSH
Telnet
SMTP
DNS
HTTP
X
15
inetd
Viele Server werden nur selten benutzt
●
belegen aber trotzdem Systemressourcen (Swap-Speicher
und Einträge in der Prozesstabelle)
●
Idee: benutzen einen einzelnen Server-Prozess, der an
vielen Ports gleichzeitig horcht und bei Bedarf ServerProzesse startet
●
inetd – Internet Daemon
benutzt bind() um sich an Ports zu binden
(siehe man 2 bind)
benutzt select() um herauszubekommen, an welchem Port
sich etwas getan hat (siehe man 2 select)
startet einen Subprozess mittels fork()
gibt dem Subprozess die richtige UID
vereinfacht das Schreiben von Servern
●
●
●
●
●
●
●
●
●
können von stdin lesen und nach stdout schreiben
keine expliziten Socket-Operationen nötig
konfiguriert mittels /etc/inetd.conf
16
/etc/inetd.conf
Ausschnitt aus einem beispielhaften Konfigurationsdatei
Aufgeführt sind: service name, socket type, protocol type,
wait/nowait (ob der Server selbst die Verbindungen
bearbeitet oder ein Subprozess), user, command name
and arguments (starting with argv[0])
●
●
●
Internal = triviale Dienste (werden vom inetd selbst
bearbeitet)
# Internet server configuration
# insecure services also shown
[...]
ftpstream
tcp nowait
root
talk
dgram
udp wait
talkd
echo stream
tcp nowait
root
echo
dgram
udp nowait
[...]
/usr/sbin/ftpd ftpd
root /usr/sbin/talkd
internal
root internal
17
xinetd
Viele Unixe benutzen heute eine Alternative zu inetd:
xinetd – extended Internet service daemon
●
●
●
selbe Idee wie inetd
stellt zusätzlich Zugriffskontrolle und Logging zur Verfügung
Konfigurationsdatei /etc/xinetd.conf
●
●
●
liest rekursiv Konfigurationsdateien in /etc/inetd.d/
siehe man 5 xinetd.conf, Beispiel:
# CVS pserver (remote acces to your CVS repositories)
# /etc/inetd.d/cvs – read section on passwords in CVS manual first
service cvspserver
{
disable
socket_type
protocol
wait
user
server
server_args
}
=
=
=
=
=
=
=
yes
stream
tcp
no
root
/usr/bin/cvs
-f --allow-root=/home/cvsroot pserver
18
Beispiel /etc/xinetd.conf
# /etc/xinetd.conf
# Copyright (c) 2002 SuSE Linux AG, Nuernberg, Germany.
#
defaults
{
# specify logging:
log_type
= FILE /var/log/xinetd.log
log_on_success = HOST EXIT DURATION
log_on_failure = HOST ATTEMPT
#
only_from
= localhost
# max. 30 concurrent server instances:
instances
= 30
# max. 50 connections per second before disabling service
# and 10 seconds pause before subsequent enabling:
cps
= 50 10
}
includedir /etc/xinetd.d
19
Übersicht
Service-Konfiguartion
Der Unix-Boot-Prozess
inetd und xinetd
Zugriffskontrolle durch wrappers
Lokale Paketfilter
Ausgewählte Dienste:
●
●
●
●
●
●
●
●
●
●
●
●
SSH
Telnet
SMTP
DNS
HTTP
X
20
IP-basierte Zugriffskontrolle
Unix "out of the box" ist in der Regel ein freundliches und
naives Betriebssystem
●
●
●
die meisten Dienste sind per default angeschaltet
niemandem wird der Zugriff verweigert
Gilt nur für Dienste im internen Netzwerk
●
●
im Internet muss man genau überlegen, wem man den Zugriff
erlaubt
Einfache Zugriffskontrolle: basierend auf der IP-Adresse
des Rechners, der die Verbindung anfragt
●
●
●
nicht besonders sicher (IP spoofing), aber besser als nichts
für bessere Authentifikation benötigt man eine Infrastruktur
(z.B. Kerberos)
Verschiedene Umsetzungen:
●
●
●
TCP wrappers
Paketfilter (Firewall)
21
Prinzip eines Wrappers
Wrapper = transparentes Einpacken kritischer
Systemaufrufe durch eine zusätzliche Softwareschicht
●
●
●
kurzfristige und elegante Lösung für akute
Sicherheitsprobleme
kann nachträglich hinzugefügt werden
22
Beispiel: TCP wrappers
Software von Wietse Venema (mittlerweile Teil von viele
Linux-Distributionen, siehe man tcpd)
Idee: "whenever a request for service arrives, the inetd
daemon is tricked into running the tcpd program instead of
the desired server."
●
●
●
●
●
●
●
●
●
tcpd schreibt Zeilen in Protokolldatei
tcpd macht double reverse DNS-Lookup der IP-Adresse
kann zudem über ident oder finger prüfen, welcher Benutzer
die Verbindung aufbaut
Zugriffskontrolle aufgrund der IP-Adresse
lehnt ggf. Verbindungswunsch ab
ansonsten übergibt das Programm die Verbindung an den
echten Server
Konfiguration über die Dateien /etc/hosts.allow
und /etc/hosts.deny
23
Beispiel /etc/hosts.allow
●
#
#
#
#
#
#
#
#
Beispiel aus Garfinkel, Spafford, Schwartz, Seite 401
/etc/hosts.allow
allow ssh from sleepy.com but nowhere else
allow nothing from pirate.net
display unfriendly banner to all external finger requests
telnetd and rlogind are disabled in /etc/inetd.conf
but we list them here anyway in case someone
accidentally re-enables them
sshd : sleepy.com : allow
sshd : all : deny
in.fingerd : LOCAL : allow
in.fingerd : all : twist /usr/local/bin/ext_fingerd_message
all : .pirate.net : deny
telnetd,rlogind : all : deny
all : all : allow
24
Diskussion
Zugriffskontrolle basierend auf IP-Adresse ist schwach
●
●
IP spoofing ist heute aber schwerer als früher, weil die
Sequenznummern schwerer zu raten sind
Zwei Dateien hosts.allow und hosts.deny wegen
Rückwärtskompatibilität
●
●
●
●
●
eigentlich reicht eine
Empfehlung: alles in hosts.allow, in hosts.deny nur die
Zeile all : all : deny
Programm tcpdchk macht einen sanity check aller
Konfiguratuionsdateien (/etc/services, /
etc/inetd.conf, /etc/hosts.allow, /
etc/hosts.deny)
Mit tcpdmatch kann man eingehende Verbindungen
simulieren und die Konfiguration testen
Es gibt auch noch andere wrapper-Implementierungen
●
●
z.B. für sendmail
25
Übersicht
Service-Konfiguartion
Der Unix-Boot-Prozess
inetd und xinetd
Zugriffskontrolle durch wrappers
Lokale Paketfilter
Ausgewählte Dienste:
●
●
●
●
●
●
●
●
●
●
●
●
SSH
Telnet
SMTP
DNS
HTTP
X
26
Lokaler Paketfilter (Firewall)
Man kann mittels Software den Netzwerkverkehr von und
zum Rechner kontrollieren
●
●
●
Regeln können viele Arten von security policies für den
Netzverkehr regeln, zum Beispiel:
●
●
●
●
●
Viele Unixe sind direkt damit ausgestattet
Normalerweise implementiert als einfacher, regelbasierter
Paketfilter (auch Firewall genannt)
Per default jede eingehende ssh-Verbindung verbieten,
ausser Verbindungen von bestimmten Rechnern
Keine eingehenden HTTP-Verbindungen zulassen aber alle
ausgehenden HTTP-Verbindungen
Fehlgeschlagene Verbindungsversuche protokollieren
Regeln werden zusätzlich zu anderen Kontrollen definiert
(zum Beispiel TCP wrappers)
27
Unix-Firewalls
Paketfilter kommen in unterschiedlicher Ausführung,
haben aber im wesentlichen die gleiche Funktionalität:
●
Linux mit 2.2er kernel: ipchains
Linux mit 2.4er kernel: netfilter (auch iptables
genannt)
BSD-Systeme (inklusive Mac OS X): ipfirewall (andere
Namen: ipfw, ipf, pf)
Solaris: SunScreen
(oder die public domain Software ipfilter)
●
●
●
●
Nachteile von Firewalls:
●
Bei hohem Netzwerkverkehr kann es zu starker
Prozessorbelastung kommen
●
●
●
Normalerweise im Heimbereich kein Problem mehr (ein 486er mit
33 MHz kann locker einer voll belastete DSL-Leitung filtern)
Sie können "zu gut" sein und gewünschte Verbindungen
verhindern (zum Beispiel backups über das Netz)
28
Paketfilter-Prinzipien
Eine Firewall enthält eine Reihe von chains:
●
Beispiel: iptables hat standardmäßig drei chains:
●
●
●
●
INPUT: für Pakete direkt an den Firewall-Rechner
OUTPUT: für Pakete, die vom Firewall-Rechner selbst nach
"draußen" gehen
FORWARD: für Pakete, die nur durch den Firewall-Rechner
hindurchgeleitet werden (wenn der Rechner zum Beispiel ein
Router oder Gateway ist)
Eine chain ist eine Liste von Regeln; Regeln haben:
●
●
Regelnummer, Filter-Spezifikation, Aktion
ein ein-/ausgehendes Paket wird gegen die entsprechende
chain gehalten:
●
●
●
●
Regeln werden nacheinander durchgegangen
wenn der Filter matcht, wird die entsprechende Aktion
ausgeführt
je nach Aktion wird das Durchgehen beendet oder
weitergeführt
29
Beispiel: iptables
iptables erlaubt die Definition eigener chains
●
●
Aktionen können momentane chain verlassen und in "subchain" springen (wie Unterprozedur)
iptables kann auch verschiedene chain sets
(sogenannte tables) verwalten
●
●
●
●
filter table: normaler Paketfilter, hat INPUT, OUTPUT
und FORWARD chains
nat table: zur Implementierung von NAT
mangle table: kann Pakete gezielt verändern
Aktionen in iptables:
●
●
●
●
●
ACCEPT: Paket wird durchgelassen
DROP: Paket wird verworfen
RETURN: zurückkehren von sub-chain matching
oder Name einer benutzerdefinierten chain (dort wird dann
mit dem matching weitergemacht)
30
Beispiel: iptables (Forts.)
Normaler Aufruf:
●
iptables [-t table] -[AD] chain rule-specification
Rule specification kann sich beziehen auf Protokoll,
Quelle, Ziel, Netzwerkinterface, Verbindungszustand,
jedes Feld im IP-Paket, etc.
●
●
-A = add, -j = Aktion, -p = Protokoll, -s = Quelle, -d = Ziel,
usw.
Beispiele:
●
●
●
iptables -A INPUT -j DROP
iptables -A INPUT -p tcp -s 192.168.0.192 -j ACCEPT
Zusätzliche Kommandos:
●
●
iptables-save, iptables-restore: schreibt nach
stdout bzw. liest von stdin Firewall-Konfiguration
Konfiguriert in SuSe Linux unter:
/etc/init.d/firewall.sh
●
●
wird beim Übergang in run level 5 als eines der ersten
Dienste gestartet
31
Auszüge aus meiner /etc/init.d/firewall.sh
# Accept ourselves (loopback interface)
$IPTABLES -A INPUT -i lo -j ACCEPT
# Drop those nasty packets!
# These are all TCP flag combinations that should never,
# ever occur in the wild.
$IPTABLES -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
[...]
# Drop icmp, but only after letting certain types through
$IPTABLES -A INPUT -p icmp --icmp-type 0 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 3 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 11 -j ACCEPT
# Accept related and established connections
$IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j
ACCEPT
# Accept SSH
$IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT
# Our final trap
$IPTABLES -A INPUT -j DROP
32
Übersicht
Service-Konfiguartion
Der Unix-Boot-Prozess
inetd und xinetd
Zugriffskontrolle durch wrappers
Lokale Paketfilter
Ausgewählte Dienste:
●
●
●
●
●
●
●
●
●
●
●
●
SSH
Telnet
SMTP
DNS
HTTP
X
33
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
34
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
35
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
36
Verbindungsaufbau bei ssh (Beispiel)
gaertner@explorer:~> ssh -v [email protected]
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 [137.226.59.9] 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 [...]
37
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?
38
Host-Authentifikation (Forts.)
Wenn ein Host, der vorher bekannt war, plötzlich einen
anderen Schlüssel hat
●
●
●
●
Veränderungen bzw. Erneuerung des Host-Schlüssels
passiert je nach Kontext selten bis häufig:
●
●
●
●
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
teilweise bei jedem System-Upgrade
oder bei Neuinstallation von ssh
Wenn der Schlüssel sich ändert, sollte man die Ursache
untersuchen
39
Client-Authentifikation in SSH
Es gibt verschiedene Authentifikationsmöglichkeiten:
●
per Kennung und Passwort
●
●
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"
●
●
●
●
●
NB: Beides wird verschlüsselt übetragen
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)
40
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. [...]
41
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/IPServer 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
42
Mail (SMTP, TCP-Port 25)
SMTP ist der Internet-Standard für E-Mail
●
●
●
●
●
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
E-Mail 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 E-Mail:
●
●
●
Viren, SPAM (mehr dazu später)
Vertraulichkeit, Authentizität und Integrität der Nachrichten
43
Mail-Spoofing
E-Mails 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:
gaertner@explorer:~> telnet localhost smtp
[...] Connected to localhost.
Escape character is '^]'.
220 explorer.local ESMTP Postfix
HELO gaertner
250 explorer.local
MAIL FROM: <[email protected]>
250 Ok
RCPT TO: <[email protected]>
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.
44
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 20.19.10.128.IN-ADDR.ARPA
45
DNS-Beispiele
gaertner@houston:~$ host i4mail
i4mail.informatik.rwth-aachen.de
A
137.226.12.21
gaertner@houston:~$ host -a www.cs.purdue.edu
www.cs.purdue.edu
CNAME
lucan.cs.purdue.edu
lucan.cs.purdue.edu
A
128.10.19.20
gaertner@houston:~$ host -t MX cs.purdue.edu
cs.purdue.edu
MX
1 mailslot.cs.purdue.edu
gaertner@houston:~$ host -t PTR 137.226.12.21
Name: i4mail.informatik.RWTH-Aachen.DE
Address: 137.226.12.21
gaertner@houston:~$
46
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 gecacht:
●
●
Cache poisoning z.B. über DNS spoofing
DNS-Server gleichen regelmäßig ihre Inhalte ab:
●
●
sollte nur über authentifizierte Kanäle geschehen
47
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 gibt es viel mehr zu erzählen: siehe Vorlesung im
Sommersemester
48
X (TCP-Ports 6000-6063)
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
49
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
50
Übersicht
Service-Konfiguartion
Der Unix-Boot-Prozess
inetd und xinetd
Zugriffskontrolle durch wrappers
Lokale Paketfilter
Ausgewählte Dienste:
●
●
●
●
●
●
●
●
●
●
●
●
SSH
Telnet
SMTP
DNS
HTTP
X
51
Zusammenfassung und Ausblick
Generell sollte man beim Aufsetzen eines InternetRechners 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., kommt im nächsten Teil
52