Fandom

Scratchpad

MIMCS ITS Sichs:Uebung c 11.3

215,853pages on
this wiki
Add New Page
Discuss this page0 Share

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.

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

Tcp wrapper overview

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


Installation

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

  pkgtool

verwendet:

Pkgtool main

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:


Pkgtool view

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:


192 168 29 128 client

Abbildung 4; 192.168.29.128 - Client


192 168 29 129 server

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
#  
  • not* allowed to use the local INET services, as decided
#   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:


Telnet pat at 192 168 29 129

Abbildung 6; telnet pat@192.168.29.129


Finger pat at 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

Also on Fandom

Random wikia