Das FreeBSD-Handbuch
Zurück	Kapitel 14. Sicherheit	Weiter

14.6. TCP-Wrapper

Beigetragen von Tom Rhodes.

Wahrscheinlich hat jeder, der inetd(8) kennt, schon mal von den TCP-Wrappern gehört. Die wenigsten erkennen den vollen Nutzen der TCP-Wrapper in einer Netzumgebung. Es scheint, dass die meisten Leute Netzverbindungen mit einer Firewall absichern wollen. Auch wenn eine Firewall ein mächtiges Instrument ist, gibt es Sachen, die eine Firewall nicht kann. Eine Firewall kann beispielsweise keine Nachricht an den Verbindungsursprung senden. Genau das und mehr können aber die TCP-Wrapper. Im Folgenden werden die Funktionen der TCP-Wrapper und Beispiele für deren Konfiguration vorgestellt.

Die TCP-Wrapper erweitern die Steuerungsmöglichkeiten, die inetd über die Dienste unter seiner Kontrolle hat. Beispielsweise können Verbindungen protokolliert, Nachrichten zurückgesandt oder nur interne Verbindungen angenommen werden. Die TCP-Wrapper bieten nicht nur eine weitere Sicherheitsschicht, die teilweise auch von Firewalls geboten wird, sie bieten darüber hinaus Funktionen zur Steuerung von Verbindungen, die eine Firewall nicht bietet.

Die erweiterten Funktionen der TCP-Wrapper sind kein Firewall-Ersatz. Sie sollten zusammen mit einer Firewall und anderen Sicherheitsvorkehrungen eingesetzt werden. Die TCP-Wrapper sind eine weitere Sicherheitsschicht zum Schutz eines Systems.

Da die Wrapper die Funktion von inetd erweitern, wird im Folgenden vorausgesetzt, dass Sie den Abschnitt über die inetd-Konfiguration schon gelesen haben.

Anmerkung: Streng genommen handelt es sich bei den von inetd(8) gestarteten Programmen nicht um “Daemonen”. Da sich diese Bezeichnung aber eingebürgert hat, wird sie auch in diesem Abschnitt verwendet.

14.6.1. TCP-Wrapper einrichten

Um die TCP-Wrapper unter FreeBSD zu benutzen, muss nur der inetd aus rc.conf mit den voreingestellten Optionen -Ww gestartet werden. Die Konfigurationsdatei /etc/hosts.allow darf keine Fehler enthalten; falls doch, werden die Fehler mit syslogd(8) protokolliert.

Anmerkung: Im Gegensatz zu anderen Implementationen der TCP-Wrapper wird vom Gebrauch der Datei hosts.deny abgeraten. Die Konfiguration sollte sich vollständig in der Datei /etc/hosts.allow befinden.

In der einfachsten Konfiguration werden Dienste abhängig vom Inhalt der Datei /etc/hosts.allow erlaubt oder gesperrt. Unter FreeBSD wird in der Voreinstellung jeder von inetd gestartete Dienst erlaubt. Sehen wir uns zunächst die Grundkonfiguration an.

Eine Konfigurationszeile ist wie folgt aufgebaut: Dienst : Adresse : Aktion. Dienst ist der von inetd gestartete Dienst (auch Daemon genannt). Die Adresse kann ein gültiger Rechnername, eine IP-Adresse oder eine IPv6-Adresse in Klammern ([ ]) sein. Der Wert allow im Feld Aktion erlaubt Zugriffe, der Wert deny verbietet Zugriffe. Die Zeilen in hosts.allow werden für jede Verbindung der Reihe nach abgearbeitet. Trifft eine Zeile auf eine Verbindung zu, wird die entsprechende Aktion ausgeführt und die Abarbeitung ist beendet.

Es gibt noch weitere Konfigurationsoptionen, die gleich erläutert werden. Das bisher Gesagte reicht, um eine einfache Regel aufzustellen. Wenn Sie einkommende POP3-Verbindungen für den Dienst mail/qpopper erlauben wollen, erweitern Sie hosts.allow um die nachstehende Zeile:

# This line is required for POP3 connections:
qpopper : ALL : allow

Nachdem Sie die Zeile hinzugefügt haben, muss der inetd neu gestartet werden. Sie können dazu das Kommando kill(1) verwenden oder /etc/rc.d/inetd restart ausführen.

14.6.2. Erweiterte Konfiguration der TCP-Wrapper

Die TCP-Wrapper besitzen weitere Optionen, die bestimmen, wie Verbindungen behandelt werden. In einigen Fällen ist es gut, wenn bestimmten Rechnern oder Diensten eine Nachricht geschickt wird. In anderen Fällen soll vielleicht der Verbindungsaufbau protokolliert oder eine E-Mail an einen Administrator versandt werden. Oder ein Dienst soll nur für das lokale Netz bereitstehen. Dies alles ist mit so genannten Wildcards, Metazeichen und der Ausführung externer Programme möglich und wird in den nächsten zwei Abschnitten erläutert.

14.6.2.1. Externe Kommandos ausführen

Stellen Sie sich vor, eine Verbindung soll verhindert werden und gleichzeitig soll demjenigen, der die Verbindung aufgebaut hat, eine Nachricht geschickt werden. Auf welche Art müssen die TCP-Wrapper konfiguriert werden? Die Option twist führt beim Verbindungsaufbau ein Kommando aus. In der Datei hosts.allow ist ein Beispiel für diese Option enthalten:

# Alle anderen Dienste sind geschützt
ALL : ALL \
        : severity auth.info \
        : twist /bin/echo "You are not welcome to use %d from %h."

Für jeden Dienst, der nicht vorher in der Datei hosts.allow konfiguriert wurde, wird die Meldung “You are not allowed to use daemon from hostname.” zurückgegegeben. Dies ist besonders nützlich, wenn Sie die Gegenstelle sofort benachrichtigen wollen, nachdem die Verbindung getrennt wurde. Beachten Sie, dass der Text der Meldung in Anführungszeichen (") stehen muss, es gibt keine Ausnahmen zu dieser Regel.

Warnung: Ein so konfigurierter Server ist anfällig für Denial-of-Service-Angriffe. Ein Angreifer kann die gesperrten Dienste mit Verbindungsanfragen überfluten.

Um einem Denial-of-Service-Angriff zu entgehen, benutzen Sie die Option spawn. Wie die Option twist verbietet spawn die Verbindung und führt externe Kommandos aus. Allerdings sendet die Option spawn der Gegenstelle keine Rückmeldung. Sehen Sie sich die nachstehende Konfigurationsdatei an:

# Verbindungen von example.com sind gesperrt:
ALL : .example.com \
    : spawn (/bin/echo %a from %h attempted to access %d >> \
      /var/log/connections.log) \
    : deny

Damit sind Verbindungen von der Domain *.example.com gesperrt. Jeder Verbindungsaufbau wird zudem in der Datei /var/log/connections.log protokolliert. Das Protokoll enthält den Rechnernamen, die IP-Adresse und den Dienst, der angesprochen wurde.

In der Konfigurationsdatei wurde beispielsweise das Metazeichen %a verwendet. Es gibt weitere Metazeichen, die in der Hilfeseite hosts_access(5) beschrieben werden.

14.6.2.2. Wildcards

Bisher verwendeten die Beispiele immer die Wildcard ALL. Die Wildcard ALL passt beispielsweise auf jeden Dienst, jede Domain oder jede IP-Adresse. Eine andere Wildcard ist PARANOID. Sie passt auf jeden Rechner dessen IP-Adresse möglicherweise gefälscht ist. Dies ist dann der Fall, wenn der Verbindungsaufbau von einer IP-Adresse erfolgt, die nicht zu dem übermittelten Rechnernamen passt. Für solche Fälle werden mit der Wildcard PARANOID Aktionen festgelegt, beispielsweise:

# Block possibly spoofed requests to sendmail:
sendmail : PARANOID : deny

In diesem Beispiel werden alle Verbindungen zu sendmail verboten, die von einer IP-Adresse ausgehen, die nicht zum Rechnernamen passt.

Achtung: Die Wildcard PARANOID kann einen Dienst unbrauchbar machen, wenn der Client oder der Server eine fehlerhafte DNS-Konfiguration besitzt. Setzen Sie die Wildcard bitte umsichtig ein.

Weiteres über Wildcards und deren Funktion lesen Sie bitte in der Hilfeseite hosts_access(5) nach.

In der Voreinstellung sind alle Dienste erlaubt. Damit die gezeigten Beispiele funktionieren, müssen Sie die erste Konfigurationszeile in der Datei hosts.allow auskommentieren.

Zurück	Zum Anfang	Weiter
Einmalpasswörter	Nach oben	KerberosIV