TCP_wrappers
Bewertung 1Die Kandidaten sollten in der Lage sein, tcpwrappers so zu konfigurieren, dass Verbindungen zu spezifischen Servern nur von bestimmten Hosts oder Subnetzen aus erlaubt werden.
Schlüsseldateien, Begriffe und Hilfsmittel beinhalten:
- inetd.conf, tcpd
- hosts.allow, hosts.deny
- xinetd
Ursprünglich alleine für die Verwendung mit inetd gedacht, hat sich das Prinzip des TCP-Wrappers inzwischen auch für Stand-Alone-Dienste wie ssh durchgesetzt. Worum geht es?
Wenn ein bestimmter Dienst aufgerufen wird, so kann er - anstatt direkt aufgerufen zu werden - durch das Programm tcpd aufgerufen werden. Dazu wird einfach statt dem zu startenden Dienst der tcpd aufgerufen und ihm wird der Name des zu startenden Dienstes als Parameter mitgegeben. Das Programm tcpd überprüft jetzt anhand von Einträgen in den Dateien
- /etc/hosts.allow
- /etc/hosts.deny
ob der Dienst von dem entsprechenden Host in Anspruch genommen werden darf. Analog überprüfen auch Stand-Alone-Dienste diese beiden Dateien.
Die Überprüfung erfolgt auf eine etwas eigenwillige Weise:
- Existiert ein passender Eintrag in der Datei /etc/hosts.allow, so wird Zugriff gegeben. Wenn nicht, dann
- Existiert ein passender Eintrag in der Datei /etc/hosts.deny, so wird kein Zugriff gegeben. Wenn nicht, dann
- wird Zugriff gegeben.
Die klassische Form der TCP-Wrapper
Das Format beider Dateien ist in der Handbuchseite hosts_access(5) genauestens dargestellt, es handelt sich um Zeilen des Formats:Serverliste : Clientliste [: Shellkommando]
- Serverliste ist eine Liste von Servern (Programmnamen), oder Wildcards. Server werden mit ihrem Programmnamen - nicht über ihr Protokoll - angegeben, also z.B.: in.telnetd
- Clientliste ist eine Liste von einem oder mehreren Hostnamen, IP-Adressen, Suchmustern oder Wildcards,
- Shellkommando ist ein Kommando, das die lokale Shell ausführt, wenn der Dienst angefordert wurde und der Eintrag ausschlaggebend für seine Ausführung oder Nichtausführung war. Damit kann etwa eine Warnmeldung an root gegeben werden, wenn jemand versucht auf einen verbotenen Service zuzugreifen.
Als Suchmuster kommen zwei einfache Verfahren in Frage:
- Beginnt ein Suchmuster mit einem Punkt (z.B. .foo.bar), so gelten alle Hostnamen als Treffer, deren Ende mit dem Muster übereinstimmt also etwa hal.foo.bar
- Endet ein Suchmuster mit einem Punkt (z.B. 192.168.200.), so gelten alle Namen und Adressen als Treffer, deren erster Teil mit dem Muster übereinstimmt.
Als Wildcards können unter anderem folgende Werte verwendet werden:
- ALL
- Die universelle Wildcard, alles gilt...
- LOCAL
- Alle Hostnamen ohne Punkt (also lokale Namen) gelten.
- UNKNOWN
- Passt auf alle Usernamen, die unbekannt sind und alle Hosts, deren Namen oder Adressen nicht bekannt sind. Wird gerne in /etc/hosts.deny verwendet.
- KNOWN
- Passt auf alle Hosts und User, die bekannt sind
- EXEPT
- Ist ein Operator, um zwei Listen auszuschließen (Liste1 EXEPT Liste2) also etwa ALL EXEPT UNKNOWN
Das Shellkommando sollte grundsätzlich mit einem & beendet werden, weil sonst auf seine vollständige Abarbeitung gewartet wird, bevor ein Service evt. gestartet wird. Je nach Kommando kann das natürlich dauern...
Als zusätzliche Platzhalter in Shellkommandos können folgende Konstrukte verwendet werden:
- %a
- Die IP-Adresse des anfordernden Hosts
- %A
- Die IP-Adresse des aufgerufenen Servers
- %c
- Clientinformationen - User@Host oder User@IP-Adresse oder nur IP-Adresse des Anrufers, je nach dem, wieviel Informationen zur Verfügung stehen.
- %d
- Der Name des Daemon-Prozesses, der angefordert wurde.
- %h
- Name (oder falls nicht vorhanden IP-Adresse) des Clients
- %H
- Name (oder falls nicht vorhanden IP-Adresse) des Servers
- %p
- Die ProzessID des Daemon-Prozesses
- %s
- Serverinformationen - Daemon@Hostname oder Daemon@Adresse oder nur Daemon, je nach dem, wieviel Informationen zur Verfügung stehen.
- %u
- Der Username des Anrufers oder "unknown"
- %%
- Das %-Zeichen
Die modernere Form der Wrapper
Moderne Systeme arbeiten heute zwar immer noch mit dem dargestellten Prinzip, bieten aber auch die Möglichkeit, alle Einstellungen in nur einer der beiden Dateien vorzunehmen. Statt der Handbuchseite hosts_access(5) wird diese Methode in hosts_options(5) beschrieben. Der Aufbau der beiden Dateien sieht jetzt folgendermaßen aus:Serverliste : Clientliste [: Option ] [: Option ...]Statt einem Shellkommando können also Optionen angegeben werden. Die wichtigsten Optionen sind:
- ALLOW
- Erlaubt den angegebenen Dienst für die angegebenen Clients.
- DENY
- Verbietet den angegebenen Dienst für die angegebenen Clients.
- spawn Shellkommando
- Führt das angegebene Shellkommando aus. Wie in der klassischen Form werden die oben beschriebenen Ersetzungen vorgenommen.
- twist Shellkommando
- Führt das angegebene Shellkommando aus und schickt seine Ausgaben an den Client, anstatt den gewünschten Dienst zu starten. Wie in der klassischen Form werden die oben beschriebenen Ersetzungen vorgenommen.
- user Username[.Gruppe]
- Startet den angegebenen Dienst unter der angegebenen User (und optional Gruppen) ID.
Der Vorteil dieser Methode liegt darin, daß alle Einstellungen in einer Datei vorgenommen werden können. Da die Optionen ALLOW und DENY zur Verfügung stehen, können in /etc/hosts.allow auch Verbote ausgesprochen werden und umgekehrt.
Aber Achtung: Es gilt immer noch die oben angegebene Reihenfolge. Es nützt also nichts, einem Host etwas zu erlauben, ohne allen anderen es zu verbieten. Die Einträge werden der Reihe nach gelesen und der erste passende wird benutzt. Um also nur dem Rechner marvin.foo.bar zu erlauben, den FTP-Daemon zu benutzen, müssten wir schreiben:
in.ftpd : marvin.foo.bar : ALLOW in.ftpd : ALL : DENYWenn der Rechner marvin.foo.bar jetzt den Dienst anfordert, greift die erste Zeile und der Zugriff wird gewährt. Versucht aber ein anderer Rechner den Zugriff, so greift die erste Zeile nicht, dafür aber die zweite - der Zugriff wird verwehrt.
inetd und TCP-Wrappers
inetd kann Dienste über den tcpd aufrufen und somit die TCP-Wrapper abarbeiten.xinetd und TXP-Wrappers
xinetd benötigt nicht den tcpd, sondern bietet eine fest eingebaute Unterstützung der Abarbeitung der Dateien /etc/hosts.allow und /etc/hosts.deny.
[ Zurück zur Startseite LPI 201 ] [ Zurück zur LPI-Seite ] [ Zurück zur Hauptseite von Linux-Praxis ] [ Guestbook ] [ Kontakt ]
Diese und die darunterliegenden Seiten wurden erstellt von F. Kalhammer
© 2001 by F.Kalhammer -
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License..