MIMCS ITS Sichs:Uebung c 11.3

Titelblatt

WichtigerHinweis:

Aus Gründen der besseren Lesbarkeit wird darauf verzichtet, explizit weibliche Formen wie z.B. Benutzerin zu verwenden. Mit männlichen Formen sind im Übungsbericht deshalb immer gleichermaßen männliche und weibliche Personen gemeint.

Vorbereitungen, Software
Die Übungsdurchführung wird mittels zwei vorinstallierter VMWare Slackware-Instanz bewerkstelligt, wobei eine als Client und eine als Server fungiert:

http://cis.technikum-wien.at/documents/bic/6/its/download/vm_secedu.exe

Zum Starten der Linux-Hosts wird der VMWare-Player benötigt:

http://download3.vmware.com/software/vmplayer/VMware-player-2.5.1-126130.exe

Zur besseren Darstellung (vorallem für die Präsentation über den Beamer) wird mittels Putty auf die Linux-Host zugegriffen, um die Console aus weiterer Ferne lesbar zu machen:

http://the.earth.li/ ~ sgtatham/putty/latest/x86/putty.exe

Sämtliche Files zur Installation werden mittels WinSCP auf die Host transferiert. Diese Tool wird auch zur besseren Übersicht über das Linux-Filesystem verwendet und dient zur Manipulieren der Konfigurations-Files:

http://mesh.dl.sourceforge.net/sourceforge/winscp/winscp417.exe

Als TCP-Wrapper wird folgende Slackware-Distribution verwendet:

ftp://gd.tuwien.ac.at/opsys/linux/slackware/slackware-current/slackware/n/inetd-1.79s-i486-8.tgz

Als Telnet-Client/Daemon wird folgende Slackware-Distribution verwendet:

ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/n/telnet-0.17-i486-1.tgz

Als Finger-Client/Daemon wird folgende Slackware-Distribution verwendet:

ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/n/bsd-finger-0.17-i486-1.tgz

Service-Starts durch Init Scripts
Die restlichen Services werden über Init Scripts gestartet, in:

 # chmod -x /etc/rc.d/rc.sshd

Services die kein eigenes Intit Skript besitzen werden meist durch ein allgemeines Init Skript:

aufgerufen:


 * 1) This must be running in order to mount NFS volumes.


 * 1) Start the RPC portmapper:

if [ -x /sbin/rpc.portmap ] ; then

echo "Starting RPC portmapper: /sbin/rpc.portmap"

/sbin/rpc.portmap

fi


 * 1) Done starting the RPC portmapper.

und können durch einfaches auskommentieren des relevanten Code-Blocks disabled werden:


 * 1) This must be running in order to mount NFS volumes.


 * 1) Start the RPC portmapper:


 * 1) if [ -x /sbin/rpc.portmap ] ; then


 * 1) echo "Starting RPC portmapper: /sbin/rpc.portmap"


 * 1) /sbin/rpc.portmap

# fi


 * 1) Done starting the RPC portmapper.

Die Änderungen werden erst wirksam, nach einem Neustart der Maschine mittels:


 * 1) shutdown -r now

oder wenn der Runlevel hin und zurück geändert wurde:


 * 1) telinit 1


 * 1) telinit 3

ACHTUNG: Nachdem man zum Runlevel 1 gewechselt hat muss man sich erneut auf der Console anmelden!!!

Arbeitsweise des TCP-Wrappers
ALL : ALL

Nun kann man sich also auf die erlaubten/positiven Regeln für Host, Domänen oder sogar übergreifenden IP-Ranges konzentrieren.

Üblicherweise wird man allen Verbindungsanfragen von der lokalen Maschine stattgeben wollen, mittels:

ALL : 127.0.0.1

Um z.B. einer bestimmten IP-Adresse oder -Range Zugang zum SSH-Daemon zu gewährleisten, kann man dies mittels Eintrag:

sshd : 192.168.29.128/24

sshd : 192.168.0.

in der

bewerkstelligen.

Der Weiteren ist es möglich den gesamten Zugriff auf/von einem Service auf eine bestimmte Domäne zu beschränken (allerdings muss hierbei auf die genehmigte und vertrauenswürdige Auflösung des Names durch einen entsprechenden DNS Eintrag Acht gegeben werden):

sshd : .technikum-wien.at



Abbildung 1; Quelle - http://www.fz-juelich.de

Installation
Zur Installation der zusätzlichen Linux-Slackware-Packages wurde das Tool

verwendet:



Abbildung 2; pkgtool - Main

Es bietet eine einfache grafische und menügesteuerte Oberfläche zur Übersicht der bereits installierten Packages und erlaubt darüber hinaus auch das Entfernen oder Hinzufügen von Linux-Erweiterungen:



Abbildung 3; pkgtool - View

Zur Übungsvorbereitung wurden der TCP-Wrapper, sowie ein Telnet- bzw. Finger-Daemon (siehe Kapitel 2) installiert.

Konfiguration
Nach erfolgreicher Kopie des VMware-Images wurde die Netzwerkkonfiguration über den VMware-Player auf „Host-only" gestellt, womit beide Linux-Boxen eine eigene IP-Adresse durch den DHCP-Server zugewiesen bekommen haben:



Abbildung 4; 192.168.29.128 - Client



Abbildung 5; 192.168.29.129 - Server

changelog
Das VMware-Image für den Server (192.168.29.129) wurde um folgende Packages erweitert:


 * TCP-Wrapper 1.79-i468-8 (Stand: 30.06.2007)


 * Telnet-Client/Daemon 0.17-i468-1 (Stand: 30.04.2007)


 * Finger-Client/Daemon 0.17-i468-1 (Stand: 30.04.2007)

Evaluierung/Testläufe
Im nun folgenden Abschnitt werden Veränderungen an verschiedenen Konfigurations-Dateien vorgenommen, welche klar machen sollen, wie der TCP-Wrapper arbeitet und was man mit dessen Hilfe für Möglichkeiten der kontrollierbaren Zugriffsberechtigung hat.

Zur Evaluierung wurden die Services Telnet und Finger auf dem Server installiert und ein neuer Benutzer namens „pat" angelegt.

Installation des Internet Super Daemon „inetd"
Nach Installation des Internet Super Daemon „inetd" als Linux-Service stellen sich die Einträge in den beiden Host-Konfigurationsdateien (relativ identisch) wie folgt dar:

#

#

#

#


 * 1) End of hosts.allow.

#

#

#

#

#


 * 1) End of hosts.deny.

Standardmäßig sind also auf Applikationseben alle Zugriffe auf bereits installierte Netzwerkdienste erlaubt, sofern sie im inetd-Configfile nicht auskommentiert wurden:


 * 1) See "man 8 inetd" for more information.

#


 * 1) If you make changes to this file, either reboot your machine or send the


 * 1) inetd a HUP signal:


 * 1) Do a "ps x" as root and look up the pid of inetd. Then do a


 * 1) "kill -HUP ".


 * 1) The inetd will re-read this file whenever it gets that signal.

#


 * 1)  < service_name >  < sock_type >     < server_path >

#


 * 1) The first 4 services are really only used for debugging purposes, so


 * 1) we comment them out since they can otherwise be used for some nasty


 * 1) denial-of-service attacks.  If you need them, uncomment them.

#


 * 1) These are standard services:

#


 * 1) Very Secure File Transfer Protocol (FTP) server.


 * 1) ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  vsftpd

#


 * 1) Professional File Transfer Protocol (FTP) server.


 * 1) ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  proftpd

#


 * 1) Telnet server:

#


 * 1) The comsat daemon notifies the user of new mail when biff is set to y:

comsat       dgram   udp     wait    root    /usr/sbin/tcpd  in.comsat

#


 * 1) Shell, login, exec and talk are BSD protocols

#

#


 * 1) To use the talk daemons from KDE, comment the talk and ntalk lines above


 * 1) and uncomment the ones below:


 * 1) talk    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/bin/kotalkd


 * 1) ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  /usr/bin/ktalkd

#


 * 1) Kerberos authenticated services

#

#


 * 1) Services run ONLY on the Kerberos server

#

#


 * 1) POP and IMAP mail servers

#


 * 1) Post Office Protocol version 3 (POP3) server:


 * 1) pop3    stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/popa3d


 * 1) Internet Message Access Protocol (IMAP) server:


 * 1) imap2   stream  tcp     nowait  root    /usr/sbin/tcpd  imapd

#


 * 1) The Internet Unix to Unix copy (UUCP) service:

#


 * 1) Tftp service is provided primarily for booting.  Most sites


 * 1) run this only on machines acting as "boot servers."


 * 1) tftp  dgram   udp     wait    root    /usr/sbin/in.tftpd  in.tftpd -s /tftpboot -r blksize

#


 * 1) Internet Bootstrap Protocol (BOOTP) server:

#


 * 1) Finger, systat and netstat give out user information which may be


 * 1) valuable to potential "system crackers."  Many sites choose to disable


 * 1) some or all of these services to improve security.


 * 1) Try "telnet localhost systat" and "telnet localhost netstat" to see that


 * 1) information yourself!

#


 * 1) Ident service is used for net authentication

#


 * 1) These are to start Samba, an smb server that can export filesystems to


 * 1) Pathworks, Lanmanager for DOS, Windows for Workgroups, Windows95, Lanmanager


 * 1) for Windows, Lanmanager for OS/2, Windows NT, etc.


 * 1) If you ’ re running smbd and nmbd as daemons in /etc/rc.d/rc.samba, then you


 * 1) shouldn ’ t uncomment these lines.


 * 1) netbios-ssn    stream  tcp     nowait  root    /usr/sbin/smbd  smbd


 * 1) netbios-ns     dgram   udp     wait    root    /usr/sbin/nmbd  nmbd

#


 * 1) Samba Web Administration Tool:


 * 1) swat           stream  tcp     nowait.400 root /usr/sbin/swat  swat

#


 * 1) Sun-RPC based services.


 * 1)  < service name/version >< sock_type >< rpc/prot >

#


 * 1) End of inetd.conf.

Überprüfung der TCP-Wrapper-Konfiguration
Eine Überprüfung der TCP-Wrapper-Konfiguration kann mit Hilfe des Tools:

erfolgen, welches ohne Fehlermeldung endet, sofern es keine Unstimmigkeiten in der Datei:

/etc/inetd.conf

gefunden hat. Andernfalls werden alle Dienste in der Fehlermeldung aufgezeigt, die aufgrund eines Fehlers (z.B. nicht/unvollständig installiert) nicht durch den TCP-Wrapper abgehandelt werden können.

Eintragen der Host-Namen
Zur besseren Veranschaulichung werden den beiden Rechnern (Client und Server) im File:

/etc/hosts

eindeutige Rechnernamen zugewiesen, über die sie sich gegenseitig durch Auflösen ihrer IP-Adresse in der Teststellung finden können:

#

#


 * 1) By the way, Arnt Gulbrandsen < agulbra@nvg.unit.no > says that 127.0.0.1


 * 1) should NEVER be named with the name of the machine.  It causes problems


 * 1) for some (stupid) programs, irc and reputedly talk. : ^ )

#


 * 1) For loopbacking.


 * 1) End of hosts.

ohne inetd-Eintrag
Beide Client-Aufrufe funktionieren nicht, da die zugehörigen Services in der TCP-Wrapper-Konfiguration auskommentiert sind!

mit inetd-Eintrag
Nach Entfernen des Kommentars (#) in beiden Zeilen:



Abbildung 6; telnet pat@192.168.29.129



Abbildung 7; finger pat@192.168.29.129

Beide Client-Aufrufe funktionieren und werden über den TCP-Wrapper „verpackt" durchgelassen!

mit hosts.deny-Eintrag
Will man nun beispielsweise nur bestimmte Services „freischalten" und alle anderen Zugriffe verweigern, so empfiehlt es sich, in der Datei:

/etc/hosts.deny

die Zeile

ALL: ALL

einzutragen, damit vorerst einmal alle Anfragen blockiert werden.

Der Aufbau für die Regel ist dabei stets:

Dienst : Rechner

mit hosts.allow-Eintrag
Als nächsten Schritt schalten wir den Netzwerkdienst Finger in der Datei:

/etc/hosts.allow

für alle Rechner (intern und extern) frei:

in.fingerd: ALL

und erlauben einen Zugriff auf unseren Server „vmwaresec" mittels Netzwerkdienst Telnet nur für den Client „vmwarebase.local":

in.telnetd: vmwarebase.local

Die Einstellungen werden sofort nach Abspeichern der Datei wirksam und von nun an sind die beiden Services wieder (bedingt) erreichbar.

Kontrolle der Services Telnet und Finger
Eine gezielte Kontrolle des jeweiligen Services kann per Tool:

/usr/sbin/tcpdmatch

gefolgt von Dienst und Server (als Aufrufparameter) bewerkstelligt werden:

root@vmwaresec > /usr/sbin/tcpdmatch in.telnetd vmwarebase.local

client:  hostname vmwarebase.local

client:  address  192.168.29.128

server:  process  in.telnetd

matched: /etc/hosts.allow line 15

access:  granted

root@vmwaresec > /usr/sbin/tcpdmatch in.telnetd vmwaresec.local

warning: vmwaresec: hostname alias

warning: (official name: localhost)

client:  hostname localhost

client:  address  127.0.0.1

server:  process  in.telnetd

matched: /etc/hosts.deny line 12

access:  denied

Diskussion
Die obigen Beispiele wurden bewusst kurz und einfach gehalten, um einen verständlichen Überblick von der Funktionalität des TCP-Wrappers zu erlangen. Mit der Installation der dokumentierten Zusatz-Software und den bereits festgehaltenen Linux-Kenntnissen, sollte es jedem Security-interessierten Studenten möglich sein, den TCP-Wrapper ganz gezielt für seine Sicherheitsbedürfnisse anzupassen und zu erweitern.

Zusammenfassung
Der TCP-Wrapper ist ein sehr einfaches Hilfsmittel das bei allen Linux-Distributionen meist schon vorinstalliert mitgeliefert wird. Er kann als Zusatz zu bestehenden Sicherheitsmechanismen agieren und schafft so eine ausgeprägtere „Awareness" im Umgang mit Netzwerkdiensten. Die Zugriffregeln sind simpel und dennoch sehr wirksam und können somit auch von weniger versierten Netzwerk-Administratoren rasch und effektiv für die jeweils zu schützende Systemlandschaft implementiert werden.