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.
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.
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.
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:
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.
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.
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:
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.
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 die Option
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:
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.
Bisher verwendeten die Beispiele immer die
Wildcard ALL
. Es gibt andere Wildcards,
welche die Funktionalität ein bisschen erweitern. 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. Das folgende
Beispiel sollte das ganze etwas klarer werden lassen:
In diesem Beispiel werden alle Verbindungen zu
sendmail
verboten, die von einer
IP-Adresse ausgehen, die nicht zum
Rechnernamen passt.
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.
Weiteres über Wildcards und deren Funktion lesen Sie bitte in der Hilfeseite hosts_access(5) nach.
Damit die gezeigten Beispiele funktionieren, müssen
Sie die erste Konfigurationszeile in der Datei
hosts.allow
auskommentieren.
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>.