8.3.5. TCP Wrapper

Wir hatten bereits darauf hingewiesen, daß es unabhängig von einem Firewall ratsam ist, jede einzelne Maschine gegen Einbrüche und Mißbräuche effektiv zu schützen. Einen wichtigen Beitrag dazu leisten Wrapper, die man beliebigen Servern vorschaltet und die dann eine Zugriffskontrolle sowie ein Logging realisieren. Auf UNIX-Systemen kommt sehr häufig der schon früher erwähnte TCP Wrapper von Wietse Venema zum Einsatz, der auch auf der Bastion nützliche Dienste leisten kann. Ein Anwendungsbeispiel werden wir uns im Praktikum ansehen. Nachfolgend soll es zunächst um die Erläuterung der prinzipiellen Funktionsweise gehen.

Wie Sie von den Kapiteln 6A und 6B her wissen, werden unter UNIX viele der zur Erbringung von Netzwerkdiensten benötigten Server durch den Internet-Dämon inetd gestartet, und zwar immer dann, wenn ein Klient eine Kommunikationsbeziehung zu einem Server aufbauen möchte. Dieses Konzept nutzt man nun dazu aus, um an Stelle des gewünschten Servers den TCP Wrapper tcpd zu starten, der (auch wenn man das vielleicht wegen seines Namens nicht vermuten würde) sowohl für TCP- als auch für UDP-basierte Dienste eingesetzt werden kann.

Der tcpd protokolliert jeden Verbindungswunsch unter Nutzung des UNIX-System-Loggers (Server syslogd) und führt optional eine Zugriffskontrolle sowie einige Tests zur Erkennung von Spoofing-Attacken durch, von deren Ergebnis abhängt, ob der vom Klienten angeforderte Dienst als zulässig betrachtet wird.

Wenn dies zutrifft, startet tcpd den eigentlichen Serverprozeß und beendet sich danach selbst. Folglich ist der TCP Wrapper (im Gegensatz zu den Proxy-Servern) an der nachfolgenden Kommunikation zwischen Klient und Server nicht mehr beteiligt, so daß er auch keinen Overhead verursacht.

Falls die Anfrage des Klienten unzulässig ist, lehnt sie der Wrapper ab. Dies geschieht im Standardfall dadurch, daß er den betreffenden Server nicht startet, so daß keine Kommunikation zustande kommt. In vielen Fällen ist es jedoch auch möglich, die Gegenseite darüber zu informieren, daß der Service nicht verfügbar ist, wobei der Administrator festlegen kann, wie dies geschieht.

Die über syslogd erzeugten Log-Einträge geben darüber Auskunft, wann welcher Klient welchen Dienst bzw. Server auf welchem Rechner nutzen wollte und ob dieser Wunsch akzeptiert bzw. zurückgewiesen wurde. Hier zwei Beispiele aus den Logs der Maschine ultra:

Apr  4 08:16:10 ultra telnetd[9827]: connect from wicht.informatik.tu-chemnitz.de
Jun  6 14:39:58 ultra in.tftpd[6445]: refused connect from horst.informatik.tu-chemnitz.de

Bei TCP-basierten Diensten kann mitunter sogar das Kennzeichen desjenigen Nutzers ermittelt werden, der von der Klienten-Maschine aus den Verbindungsaufbau initiiert hat. Das Kennzeichen steht dann in den Logs vor dem Rechnernamen, z.B. xyz@wicht.informatik.tu-chemnitz.de für Nutzer xyz. Um diese Information zu beschaffen, wird eine abgerüstete Version des im RFC 1413 (Identification Protocol) beschriebenen Protokolls verwendet. Es ist allerdings nur anwendbar, wenn der Klienten-Rechner diesen nicht sehr weit verbreiteten Dienst unterstützt.

Die vom TCP Wrapper erzeugten Log-Informationen können helfen, unerwünschte Aktivitäten zu entdecken, die evtl. auf eine Attacke hinweisen. Natürlich muß man sie dazu regelmäßig auswerten.

Grafisch stellt sich der Ablauf bei der Nutzung von tcpd so dar:

Die folgende Liste beschreibt die einzelnen Schritte detaillierter:

  1. Nach dem Start ermittelt der Wrapper die Adressen und Portnummern der beiden Kommunikationspartner.

  2. Sofern es der Administrator anweist, wird versucht herauszufinden, ob ein Spoofing des Hostnamens oder der Adresse vorliegt. Dazu ermittelt der tcpd über das DNS zunächst den zur Adresse gehörenden Rechnernamen und läßt diesen in einer zweiten DNS-Anfrage auf die Adresse abbilden (Venema nennt das "asking for a second opinion"). Ergeben sich hierbei Unstimmigkeiten, liegt offenbar eine Attacke vor. Dies führt zur Zurückweisung der Anfrage und wird wie oben gezeigt protokolliert. In den Logs wird auch die genaue Ursache der Ablehnung (z.B. host name/address mismatch...) vermerkt.

  3. Im nächsten, ebenfalls optionalen Schritt überprüft der Wrapper, ob das erste vom Klienten empfangene IP-Paket irgendwelche Optionen hat. Von besonderem Interesse ist dabei die bei der Diskussion der Firewall-Architekturen schon erwähnte Option Source Routing, die gern für Angriffe genutzt wird. Ist sie vorhanden, generiert der tcpd entsprechende Log-Einträge und beendet seine Arbeit, so daß der Klient den Dienst nicht nutzen kann. Alle sonstigen Optionen werden gelöscht, verhindern aber nicht die Weiterarbeit des Wrappers.

    In modernen UNIX-Systemen (Linux 2.x, Solaris 2.x, ...) ist dieser Test nicht unbedingt nötig, da dort bereits der Betriebssystem-Kern Pakete, die die Source-Routing-Option enthalten, stoppen kann.

  4. Im Anschluß wird optional eine relativ einfache Zugriffskontrolle durchgeführt, die pro Klient, Dienst oder einer Kombination von beiden erfolgen kann. In den zwei Dateien /etc/hosts.allow und /etc/hosts.deny kann der Administrator Zugriffskontroll-Regeln spezifizieren, die angeben, wer welchen Dienst nutzen bzw. nicht nutzen darf.

    Die Dienste werden durch den TCP Wrapper über den Namen der Datei identifiziert, die den Code des Serverprogramms enthält. Sofern ein Server-Rechner mehrere IP-Adressen hat, kann man zusätzlich angeben, über welche Interfaces der Dienst genutzt werden darf. Die Klienten werden primär an Hand ihres Hostnamens oder der IP-Adresse unterschieden. Da beide relativ leicht fälschbar sind, empfiehlt es sich in der Regel, den optionalen Schritt 2 durchzuführen, um ein Spoofing möglichst zu erkennen.

    Sofern der Klient das Identification Protocol nach RFC 1413 unterstützt, kann in der Klienten-Angabe zusätzlich auch ein Nutzerkennzeichen verwendet werden. Durch Muster und Wildcards ist erreichbar, daß eine Regel für eine ganze Gruppe von Klienten und Diensten gilt. So umfaßt z.B. .tu-chemnitz.de alle Rechner der TU Chemnitz, da deren Hostnamen auf das angegebene Muster enden. Die universelle Wildcard ALL bewirkt, daß jede Angabe als passend betrachtet wird.

    Außerdem kann der Administrator optional eine Aktion spezifizieren, die auszulösen ist, wenn eine gültige Regel gefunden wurde (wenn sie "feuert"). So ist es u.a. möglich, beliebige Shell-Kommandos zu starten, die sich gut dazu nutzen lassen, einem Angreifer gewisse Fallen (Venema spricht von booby traps) zu stellen. Man könnte z.B. versuchen, die aktuell auf dem Klienten-Rechner angemeldeten Nutzer über das Kommando finger zu ermitteln und das Resultat als Mail an den Administrator senden lassen.

    Die Zugriffskontroll-Regeln in /etc/hosts.allow und /etc/hosts.deny werden immer sequentiell von vorn nach hinten ausgewertet. Über die Zulässigkeit eines Auftrags wird im Prinzip nach folgendem Algorithmus entschieden, wobei die gezeigten Schritte in der angegebenen Reihenfolge ausgeführt werden, bis das Ergebnis feststeht:

    1. Der Zugriff wird gestattet, sobald für das aus dem angesprochenen Server und dem aktuellen Klienten bestehende Paar eine passende Regel in der Datei /etc/hosts.allow gefunden wurde.

    2. Der Zugriff wird verweigert, sobald für das aus dem angesprochenen Server und dem aktuellen Klienten bestehende Paar eine passende Regel in der Datei /etc/hosts.deny gefunden wurde.

    3. Der Zugriff wird gestattet.

    Eine nicht existierende Zugriffskontroll-Datei wird behandelt, als wäre sie leer. Das heißt, die Zugriffskontrolle läßt sich vollkommen abschalten, indem man keine Zugriffskontroll-Dateien bereitstellt.

    Anmerkungen:

    Die Zugriffskontroll-Regeln sind sehr flexibel nutzbar. Für Details sei auf die zum Programm-Paket gehörenden Manual-Seiten (speziell die Dateien hosts_access.5 und hosts_options.5) verwiesen. Daneben wird, sofern man dies bei der Übersetzung des Wrappers aus den Quellen anweist, optional eine erweiterte Syntax angeboten, deren Beschreibung in der Datei hosts_options.5 zu finden ist.

    Die Anwendung dieser Erweiterungen hat u.U. eine Modifikation des gerade gezeigten Algorithmus zur Folge. So kann z.B. über die Aktionen allow und deny ganz explizit der Zugang gewährt bzw. verweigert werden, egal, ob die Regel in /etc/hosts.allow oder /etc/hosts.deny formuliert wurde. Damit besteht die Möglichkeit, alle Regeln in einer einzigen Datei zu verwalten.

    Die vom TCP Wrapper intern zur Auswertung der Zugriffskontroll-Dateien /etc/hosts.allow und /etc/hosts.deny genutzten Funktionen stehen auch in einer separaten Bibliothek namens libwrap zur Verfügung und können so leicht in andere Programme integriert werden. Dies ist vor allem für diejenigen Applikationen von Interesse, die nicht über den Internet-Dämon gestartet und daher nicht über den tcpd geschützt werden können. Deshalb existieren z.B. Versionen des im Kapitel 6B vorgestellten Port-Mappers (portmap bzw. rpcbind), die die Funktionalität der libwrap nutzen und so über dieselben Zugriffskontroll-Mechanismen wie der TCP Wrapper verfügen.

Der TCP Wrapper ist ein vergleichsweise einfaches, effektives und auf einer breiten Palette von UNIX-Plattformen lauffähiges Programm, das weltweit vielfach genutzt wird und allgemein als zuverlässig anerkannt ist. Sein Einsatz erfordert keinerlei Änderungen an der existierenden Systemsoftware. Dies ist speziell bei kommerziellen Systemen sehr wichtig, da dort oft keine Quelltexte zur Verfügung stehen, so daß Anpassungen seitens des Anwenders nicht realisierbar sind.

Zwischen dem Wrapper und dem von ihm aktivierten Server werden keine Informationen ausgetauscht, d.h., tcpd ist applikationsunabhängig und kann viele verschiedene Arten von Servern schützen, vorausgesetzt, sie werden über den inetd gestartet. Diejenigen (wenigen) Server, bei denen das nicht der Fall ist, können leider vom TCP Wrapper nicht profitieren.

Der TCP Wrapper hat einige Begrenzungen, auf die hier kurz hingewiesen sei:

Weitere Informationen zum TCP Wrapper sowie die Software selbst bietet Wietse Venema unter dem schon an anderer Stelle erwähnten URL ftp://ftp.porcupine.org/pub/security/index.html an.


© Heino Gutschmidt, 11.6.1997
Holger Trapp, 28.6.1999