14.4. TCP-Wrapper

Beigetragen von Tom Rhodes.

TCP-Wrapper erweitern die Fähigkeiten von Abschnitt 29.2, „Der inetd Super-Server. Beispielsweise können Verbindungen protokolliert, Nachrichten zurückgesandt oder nur interne Verbindungen angenommen werden. Einige dieser Fähigkeiten können auch über eine Firewall implementiert werden, TCP-Wrapper fügen jedoch noch eine weitere Sicherheitsschicht und Kontrollmöglichkeiten hinzu, die eine Firewall nicht bieten kann.

TCP-Wrapper sollten nicht als Ersatz für eine ordentlich konfigurierte Firewall angesehen werden, sondern stattdessen in Verbindung mit einer Firewall und anderen Sicherheitsmechanismen eingesetzt werden.

14.4.1. TCP-Wrapper einrichten

Um TCP-Wrapper unter FreeBSD zu benutzen, muss der inetd(8)-Server aus rc.conf mit den Optionen -Ww gestartet werden. Anschließend muss /etc/hosts.allow richtig konfiguriert werden.

Anmerkung:

Im Gegensatz zu anderen Implementierungen 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(8) gestartete Dienst erlaubt.

Eine Konfigurationszeile ist wie folgt aufgebaut: Dienst : Adresse : Aktion. Dienst ist der von inetd(8) gestartete Dienst (auch Daemon genannt). Die Adresse ist ein gültiger Rechnername, eine IP-Adresse oder eine IPv6-Adresse in Klammern ([ ]). 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.

Um beispielsweise einkommende POP3-Verbindungen für den Dienst mail/qpopper zu erlauben, sollte hosts.allow um die nachstehende Zeile erweitert werden:

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

Nachdem Sie die Zeile hinzugefügt haben, muss inetd(8) neu gestartet werden:

# service inetd restart

14.4.2. Erweiterte Konfiguration

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.

14.4.2.1. Externe Kommandos

Stellen Sie sich vor, eine Verbindung soll verhindert werden und gleichzeitig soll demjenigen, der die Verbindung aufgebaut hat, eine Nachricht geschickt werden. Solch eine Aktion ist mit twist möglich. twist führt beim Verbindungsaufbau ein Kommando oder ein Skript aus. Ein Beispiel ist in hosts.allow 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 hosts.allow konfiguriert wurde, wird die Meldung You are not allowed to use daemon from hostname. zurückgegeben. Dies ist nützlich, wenn die Gegenstelle sofort benachrichtigt werden soll, nachdem die Verbindung getrennt wurde. Der Text der Meldung muss in Anführungszeichen (") stehen.

Warnung:

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

Eine weitere Möglichkeit bietet spawn. Wie twist verbietet spawn die Verbindung und führt externe Kommandos aus. Allerdings sendet 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 /var/log/connections.log protokolliert. Das Protokoll enthält den Rechnernamen, die IP-Adresse und den Dienst, der angesprochen wurde.

In diesem Beispiel wurden die Metazeichen %a und %h verwendet. Eine vollständige Liste der Metazeichen finden Sie in hosts_access(5).

14.4.2.2. Wildcards

Die Wildcard ALL passt 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 beispielsweise der Fall, wenn der Verbindungsaufbau von einer IP-Adresse erfolgt, die nicht zu dem übermittelten Rechnernamen passt. In diesem Beispiel werden alle Verbindungsanfragen zu sendmail(8) abgelehnt, wenn die IP-Adresse nicht zum Rechnernamen passt:

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

Achtung:

Die Wildcard PARANOID kann einen Dienst unbrauchbar machen, wenn der Client oder der Server eine fehlerhafte DNS-Konfiguration besitzt. Seien Sie daher besonders vorsichtig, wenn Sie diese Wildcard in Ihre Konfiguration aufnehmen wollen.

Weitere Informationen über Wildcards und deren Funktion finden Sie in hosts_access(5).

Damit die gezeigten Beispiele funktionieren, muss die erste Konfigurationszeile in hosts.allow auskommentiert werden.

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.

Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.