MIMCS ITS Sichs:Uebung c 11.3 at Wikia
Welcome to the MIMCS ITS Sichs:Uebung c 11.3 mini wiki at Scratchpad!
You can use the box below to create new pages for this mini-wiki. Make sure you type [[Category:MIMCS ITS Sichs:Uebung c 11.3]]
on the page before you save it to make it part of the MIMCS ITS Sichs:Uebung c 11.3 wiki (preload can be enabled to automate this task, by clicking this link and saving that page. Afterwards, you may need to purge this page, if you still see this message).
Aufgabenbeschreibung[]
Themenblock: Kapitel 11 - Zugriffskontrolle |
Präsentationstermin: 24.11.2008 |
Student: DI(FH) Patrick Renner, mailto:ic08m045@technikum-wien.at | |
Zugriffskontrolle über TCP-Wrapper Ein TCP-Wrapper sorgt für das dynamische Aktivieren von Diensten - wenn ein entsprechender Request den Sicherheitsanforderungen genügt. Als „Superdämonen" fungieren bei Linux dabei (x)inted (xinetd ist zu bevorzugen!) sowie tcpd. Das Funktionsprinzip sowie die Konfigurationsmöglichkeiten sind anhand einiger Dienste nach Wahl in der bereitgestellten Slackware Distribution (VMware Image) zu evaluieren und live (!) zu präsentieren. |
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
Theoretische Grundlagen und Funktionsweise[]
Netzwerk-basierte Services sind heutzutage aus IT-Dienstleistungsunternehmen nicht mehr wegzudenken. Der Zugriff auf diese wird aber oft unzureichend geschützt. |
Ein Beispiel: |
Beinahe jeder Web-Entwickler hat zum Debuggen oder Testen seiner programmierten Projekte einen Webserver lokal auf seinem Entwicklungsrechner laufen. Dabei bedenken aber die wenigsten, diesen auch gegen „neugierige" Kollegen abzuschirmen. |
Eine sehr einfache aber effiziente Methode gegen solche unberechtigten Zugriffe auf lokale Services bietet der TCP-Wrapper, der mittels genauer Konfiguration festlegt, wer – was – wo Zugang hat, oder „draußen" bleiben muss. |
Internet Super Daemon „inetd"[]
Wenn ein Netzwerkdienst auf einem Server installiert und konfiguriert worden ist, heißt das noch lange nicht, dass er auch bereit läuft und Anfragen entgegen nehmen kann. Die meisten Service werden nämlich aus Sicherheitsgründen von einem eigenen Internet Super Daemon namens „inetd" kontrolliert und verwaltet. |
Services können simple mittels hinzufügen im File: |
/etc/inetd.conf |
aktiviert werden: |
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd |
→ der Telnet-Daemon läuft gekappselt im Internet Super Daemon. |
Oder das Service nicht erlauben durch auskommentieren mit (#): |
#telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd |
Die Änderungen werden erst wirksam, nachdem inetd neugestarte wurde, mittels: |
# kill -HUP $(cat /var/run/inetd.pid) |
Service-Starts durch Init Scripts[]
Die restlichen Services werden über Init Scripts gestartet, in:
/etc/rc.d/ |
Auch hier gibt es die Möglichkeit einer Beschränkungsregelung, zur server-speziefischen Verwaltung. |
Entweder man entzieht dem Init Skript die Berechtigung zur Ausführung: |
# chmod -x /etc/rc.d/rc.sshd
Services die kein eigenes Init Skript besitzen werden meist durch ein allgemeines Init Skript:
/etc/rc.d/rc.inet2 |
aufgerufen:
# This must be running in order to mount NFS volumes.
# Start the RPC portmapper:
if [ -x /sbin/rpc.portmap ]; then
echo "Starting RPC portmapper: /sbin/rpc.portmap"
/sbin/rpc.portmap
fi
# Done starting the RPC portmapper.
und können durch einfaches auskommentieren des relevanten Code-Blocks disabled werden:
# This must be running in order to mount NFS volumes.
# Start the RPC portmapper:
#if [ -x /sbin/rpc.portmap ]; then
# echo "Starting RPC portmapper: /sbin/rpc.portmap"
# /sbin/rpc.portmap
#fi
# Done starting the RPC portmapper.
Die Änderungen werden erst wirksam, nach einem Neustart der Maschine mittels:
# shutdown -r now
oder wenn der Runlevel hin und zurück geändert wurde:
# telinit 1
# telinit 3
ACHTUNG: Nachdem man zum Runlevel 1 gewechselt hat muss man sich erneut auf der Console anmelden!!!
Arbeitsweise des TCP-Wrappers[]
Mit den bisher vorgestellten Grundlagen haben wir Services nur ganz oder gar nicht zur Ausführung gezwungen. Was aber, wenn wir die freigeschaltenen Dienste nur einem bestimmten Benutzer-Kreis oder nur für bestimmte Rechner zugänglich machen wollen? Ungleich ähnlich wie beim Verwenden von IP-Tables, wo Zugriffsbeschränkungen auf IP-Ebene, also einer genauen Range von IP-Adressen, eines bestimmten Netzwerk-Protokolls oder eines dezidierten Ports festgelegt werden können, stellt der TCP-Wrapper eine wesentlich feinere Granulierung für Zugangsregeln vom und zum konfigurierten Service dar. |
Der TCP-Wrapper regelt den Zugang erst auf Applikations-Ebene und liefert somit einen extra Layer an Security, wenn IP-Level-Kontrolleure (wie z.B. der Netfilter) nicht mehr alle Sicherheitsbedürfnisse abdecken kann. |
Ein Beispiel: |
Wenn durch die Rekompilierung des Kernels auf die Integration der IP-Tables-Unterstützung vergessen wurden, dann ist der Schutz auf IP-Ebene praktisch aufgehoben. Der TCP-Wrapper aber ist immer noch einsatzfähig und kann das System auf Applikations-Ebene vor Angriffen gewahren. |
Alle Zugriffe auf Netzwerkdienste, welche durch den TCP-Wrapper geschützt werden, können sehr transparent in den beiden Konfigurations-Dateien: |
/etc/hosts.allow |
und |
/etc/hosts.deny |
geregelt werden. |
Sofern man alle Services, zu/von denen die entfernten Clients Zugriff erhalten dürfen, sauber und vollständig in der „Elaubnis-Liste" eingetragen hat, kann man ruhigen Gewissens alle anderen/übrigen Service-Anfragen in der „Verweigerungs-Liste" geltend machen, mittels: |
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
/etc/hosts.allow |
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
pkgtool |
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:
# hosts.allow | This file describes the names of the hosts which are | |
# | allowed to use the local INET services, as decided by | |
# | the ’/usr/sbin/tcpd’ server. |
#
# Version: | @(#)/etc/hosts.allow | 1.00 | 05/28/93 |
#
# Author: | Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org |
#
#
# End of hosts.allow.
#
# hosts.deny | This file describes the names of the hosts which are | |
# |
| |
# | by the ’/usr/sbin/tcpd’ server. |
#
# Version: | @(#)/etc/hosts.deny | 1.00 | 05/28/93 |
#
# Author: | Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org |
#
#
# 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:
# See "man 8 inetd" for more information.
#
# If you make changes to this file, either reboot your machine or send the
# inetd a HUP signal:
# Do a "ps x" as root and look up the pid of inetd. Then do a
# "kill -HUP <pid of inetd>".
# The inetd will re-read this file whenever it gets that signal.
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# The first 4 services are really only used for debugging purposes, so
# we comment them out since they can otherwise be used for some nasty
# denial-of-service attacks. If you need them, uncomment them.
# echo | stream | tcp | nowait | root | internal | |
# echo | dgram | udp | wait | root | internal | |
# discard | stream | tcp | nowait | root | internal | |
# discard | dgram | udp | wait | root | internal | |
# daytime | stream | tcp | nowait | root | internal | |
# daytime | dgram | udp | wait | root | internal | |
# chargen | stream | tcp | nowait | root | internal | |
# chargen | dgram | udp | wait | root | internal | |
time | stream | tcp | nowait | root | internal | |
time | dgram | udp | wait | root | internal |
#
# These are standard services:
#
# Very Secure File Transfer Protocol (FTP) server.
#ftp stream tcp nowait root /usr/sbin/tcpd vsftpd
#
# Professional File Transfer Protocol (FTP) server.
#ftp stream tcp nowait root /usr/sbin/tcpd proftpd
#
# Telnet server:
(#)telnet | stream tcp nowait root /usr/sbin/tcpd | in.telnetd |
#
# 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
#
# Shell, login, exec and talk are BSD protocols
#
#shell | stream | tcp | nowait | root | /usr/sbin/tcpd | in.rshd -L |
#login | stream | tcp | nowait | root | /usr/sbin/tcpd | in.rlogind |
# exec | stream | tcp | nowait | root | /usr/sbin/tcpd | in.rexecd |
# talk | dgram | udp | wait | root | /usr/sbin/tcpd | in.talkd |
#ntalk | dgram | udp | wait | root | /usr/sbin/tcpd | in.talkd |
#
# To use the talk daemons from KDE, comment the talk and ntalk lines above
# and uncomment the ones below:
# talk dgram udp wait root /usr/sbin/tcpd /usr/bin/kotalkd
# ntalk dgram udp wait root /usr/sbin/tcpd /usr/bin/ktalkd
#
# Kerberos authenticated services
#
# klogin | stream | tcp | nowait | root | /usr/sbin/tcpd | rlogind -k |
# eklogin | stream | tcp | nowait | root | /usr/sbin/tcpd | rlogind -k -x |
# kshell | stream | tcp | nowait | root | /usr/sbin/tcpd | rshd -k |
#
# Services run ONLY on the Kerberos server
#
# krbupdate | stream | tcp | nowait | root | /usr/sbin/tcpd | registerd |
# kpasswd | stream | tcp | nowait | root | /usr/sbin/tcpd | kpasswdd |
#
# POP and IMAP mail servers
#
# Post Office Protocol version 3 (POP3) server:
#pop3 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/popa3d
# Internet Message Access Protocol (IMAP) server:
#imap2 stream tcp nowait root /usr/sbin/tcpd imapd
#
# The Internet Unix to Unix copy (UUCP) service:
# uucp | stream | tcp | nowait | uucp | /usr/sbin/tcpd | /usr/lib/uucp/uucico | -l |
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
# tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot -r blksize
#
# Internet Bootstrap Protocol (BOOTP) server:
# bootps | dgram | udp | wait | root | /usr/sbin/bootpd | bootpd |
#
# Finger, systat and netstat give out user information which may be
# valuable to potential "system crackers." Many sites choose to disable
# some or all of these services to improve security.
# Try "telnet localhost systat" and "telnet localhost netstat" to see that
# information yourself!
(#)finger | stream | tcp | nowait | nobody | /usr/sbin/tcpd | in.fingerd -u | |
# systat | stream | tcp | nowait | nobody | /usr/sbin/tcpd | /bin/ps | -auwwx |
# netstat | stream | tcp | nowait | root | /usr/sbin/tcpd | /bin/netstat | -a |
#
# Ident service is used for net authentication
##########auth | stream | tcp | wait | root | /usr/sbin/in.identd | in.identd |
#
# These are to start Samba, an smb server that can export filesystems to
# Pathworks, Lanmanager for DOS, Windows for Workgroups, Windows95, Lanmanager
# for Windows, Lanmanager for OS/2, Windows NT, etc.
# If you’re running smbd and nmbd as daemons in /etc/rc.d/rc.samba, then you
# shouldn’t uncomment these lines.
#netbios-ssn stream tcp nowait root /usr/sbin/smbd smbd
#netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd
#
#Samba Web Administration Tool:
#swat stream tcp nowait.400 root /usr/sbin/swat swat
#
# Sun-RPC based services.
# <service name/version><sock_type><rpc/prot><flags><user><server><args>
# rstatd/1-3 | dgram | rpc/udp | wait | root | /usr/sbin/tcpd | rpc.rstatd |
# rusersd/2-3 | dgram | rpc/udp | wait | root | /usr/sbin/tcpd | rpc.rusersd |
# walld/1 | dgram | rpc/udp | wait | root | /usr/sbin/tcpd | rpc.rwalld |
#
# End of inetd.conf.
Überprüfung der TCP-Wrapper-Konfiguration[]
Eine Überprüfung der TCP-Wrapper-Konfiguration kann mit Hilfe des Tools:
/usr/sbin/tcpdchk |
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:
#
# hosts | This file describes a number of hostname-to-address | |
# | mappings for the TCP/IP subsystem. It is mostly | |
# | used at boot time, when no name servers are running. | |
# | On small systems, this file can be used instead of a | |
# | "named" name server. Just add the names, addresses | |
# | and any aliases to this file... |
#
# By the way, Arnt Gulbrandsen <agulbra@nvg.unit.no> says that 127.0.0.1
# should NEVER be named with the name of the machine. It causes problems
# for some (stupid) programs, irc and reputedly talk. :^)
#
# For loopbacking.
127.0.0.1 | localhost | |
127.0.0.1 | vmwarebase.local vmwarebase | |
192.168.29.128 | vmwarebase.local vmwarebase | |
192.168.29.129 | vmwaresec.local vmwaresec |
# End of hosts.
Aufruf der Services Telnet und Finger[]
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.
Quelle[]
- Skriptum IT-Sicherheit/Sicherheitsstrukturen, Alexander Lintenhofer, 2008, Version 2.7
- Slackware Linux Essentials, slack-book-2.0, Second Edition
- Bildmaterial → http://www.fz-juelich.de