15.2. TCP Wrappers Konfigurationsdateien

Um zu bestimmen, ob es einer Client-Maschine erlaubt ist, zu einem gewissen Service zu verbinden, verwenden TCP Wrappers die folgenden zwei Dateien, die auch Hosts-Zugriffsdateien gennant werden:

Wenn ein Verbindungsversuch zu einem "TCP wrapped" Service eingeleitet wird, wird der Service folgende Schritte durchführen:

  1. Der Service wird zuerst /etc/hosts.allow untersuchen. — Der "TCP wrapped" Service arbeitet die Datei /etc/hosts.allow sequentiell ab, und wendet die erste für diesen Service angegebene Regel an. Sollte dieser eine solche Regel finden, erlaubt dieser die Verbindung. Wenn nicht, wird dieser zum Schritt 2 übergehen.

  2. Der Service untersucht /etc/hosts.deny. — Der "TCP wrapped" Service arbeitet die Datei /etc/hosts.deny sequentiell ab. Sollte es eine entsprechende Regel finden, wird die Verbindung abgelehnt. Wenn nicht, wird die Verbindung erlaubt.

Die folgenden Punkte sind wichtig, wenn TCP Wrappers verwendet werden um Netzwerk-Services zu schützen:

15.2.1. Formatieren von Zugriffsregeln

Das Format der beiden Dateien /etc/hosts.allow und /etc/hosts.deny ist gleich. Leere Zeilen oder Zeilen, die mit dem Zeichen (#) beginnen, werden nicht berücksichtigt. Jede Regel muss auf einer neuen Zeile beginnen.

Jede Regel verwendet folgendes grundlegende Format, um den Zugriff zu Netzwerk-Services zu kontrollieren:

<daemon list>: <client list> [: <option>: <option>: ...]

Folgend ist eine einfaches Beispiel einer Hosts-Zugriffsregel:

vsftpd : .example.com 

Diese Regel leitet TCP Wrappers dazu an, für Verbindungen zum FTP Daemon (vsftpd), von jedem Host in der example.com Domain, Ausschau zu halten. Sollte diese Regel in hosts.allow auftreten, wird die Verbindung angenommen. Sollte diese Regel in hosts.deny vorkommen, wird die Verbindung abgelehnt.

Folgendes Beispiel einer Hosts-Zugriffsregel ist komplizierter und verwendet zwei Option-Felder:

sshd : .example.com  \
: spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \
: deny

Beachten Sie, dass in diesem Beispiel jedem der Option-Felder ein Backslash (\) voransteht. Die Verwendung eines Backslash beugt einem Ausfallen auf Grund einer zu langen Zeile vor.

WarnungWarnung
 

Sollte die letzte Zeile einer Hosts-Zugriffsdatei keine Leerzeile sein (eine Leerzeile enthält lediglich ein Newline-Zeichen, und wurde durch Drücken der [Enter]-Taste erzeugt), wird die letzte Regel in der Datei nicht richtig abgearbeitet, und ein Fehler wird entweder nach /var/log/messages oder /var/log/secure geschrieben. Dies ist auch der Fall für Regelzeilen, welche auf mehrere Zeilen aufgeteilt werden, ohne den Backslash zu benutzen. Das folgende Beispiel zeigt den wichtigsten Teil einer Log-Meldung für eine durch genannte Gründe fehlerhafte Regel:

warning: /etc/hosts.allow, line 20: missing newline or line too long

Diese Beispielregel sagt, dass wenn ein Verbindungsversuch zum SSH Daemon (sshd) von einem Host in der example.com Domain stattfindet, führe den Befehl echo aus (welcher den Versuch in eine spezielle Log-Datei schreibt), und lehne die Verbindung ab. Da die optionale Anweisung deny verwendet wird, wird diese Zeile den Zugriff ablehnen, auch wenn sie in der Datei hosts.allow steht. Für einen detaillierteren Überblick der Optionen, sehen Sie Abschnitt 15.2.3.

15.2.1.1. Wildcards

Wildcards erlauben TCP Wrappers eine einfachere Suche von Gruppen von Daemons oder Hosts. Diese werden am häufigsten im Client-Listen-Feld der Zugriffsregel gefunden.

Die folgenden Wildcards können verwendet werden:

  • ALL — Für Alle. Kann für beide verwendet werden, die Daemon-Liste und die Client-Liste.

  • LOCAL — Für jeden Host-Rechner, der keinen Punkt (.) enthält, wie localhost.

  • KNOWN — Für jeden Host-Rechner, dessen Hostname und Hostadresse oder der Benutzer bekannt sind.

  • UNKNOWN — Für jeden Host-Rechner, dessen Hostname und Hostadresse oder der Benutzer nicht bekannt sind.

  • PARANOID — Für jeden Host-Rechner, dessen Hostname nicht mit der Hostadresse übereinstimmt.

AchtungAchtung
 

Die Wildcards KNOWN, UNKNOWN und PARANOID sollten sehr vorsichtig verwendet werden, da eine Unterbrechung in der Namenauflösung eine Zugriffsverweigerung auf Netzwerkdienste für berechtigte Benutzer zur Folge haben kann.

15.2.1.2. Patterns

Patterns können im Client-Listen-Feld von Zugriffsregeln benutzt werden, um Gruppen von Client-Hosts genauer anzugeben.

Folgend ist eine Liste der am häufigsten akzeptierten Patterns für einen Eintrag in der Client-Liste:

  • Ein mit einem Punkt (.) beginnender Hostname — Ein Punkt am Anfang eines Hostnamens bewirkt, dass für alle Host-Rechner, die in diesem Hostnamen enden, die Regel angewandt wird. Das folgende Beispiel wird auf jeden Host in der example.com Domain angewendet:

    ALL : .example.com
  • Eine mit einem Punkt (.) endende IP-Adresse — Ein Punkt am Ende einer IP-Adresse bewirkt, dass auf alle Hosts, deren IP-Adresse dementsprechend beginnt, die Regel angewendet wird. Das folgende Beispiel trifft auf alle Hosts im 192.168.x.x Netzwerk zu:

    ALL : 192.168.
  • IP Adresse/Netmask Paar — Netmask-Ausdrücke können auch als ein Pattern verwendet werden, um den Zugriff zu einer bestimmten Gruppe von IP Adressen zu regeln. Das folgende Beispiel trifft auf alle Hosts mit einer Adresse zwischen 192.168.0.0 und 192.168.1.255 zu:

    ALL : 192.168.0.0/255.255.254.0
     
  • Ein Stern (*) — Sterne können für komplette Gruppen von Hostnamen oder IP Adressen verwendet werden, solange diese nicht in einer Client-Liste verwendet werden, welche bereits andere Patterns verwendet. Das folgende Beispiel trifft auf alle Hosts in der example.com Domain zu:

    ALL : *.example.com
  • Der Slash oder Schrägstrich (/) — Wenn die Client-Liste mit einem Schrägstrich beginnt, wird diese als Dateiname behandelt. Dies ist nützlich wenn Regeln, welche eine große Anzahl von Hosts angeben, nötig sind. Das folgende Beispiel nimmt Bezug auf TCP Wrappers zur Datei /etc/telnet.hosts für alle Telnet-Verbindungen:

    in.telnetd : /etc/telnet.hosts

Andere, weniger verwendete Patterns werden auch von TCP Wrappers angenommen. Sehen Sie die man 5 Seite von hosts_access für mehr Information.

WarnungWarnung
 

Seien Sie sehr vorsichtig beim Erzeugen von Regeln, welche eine Namensauflösung erfordern, wie Host- oder Domain-Names. Ein Angreifer könnte verschiedene Tricks verwenden, um Regeln zu umgehen, die sie durch Namen spezifizieren. Außerdem, wenn Ihr System selektiven Zugriff nach Host- und Domain-Namensinformationen gewährt, könnte bei einer Unterbrechung des DNS-Dienstes auch autorisierten Benutzern der Zugriff auf Netzwerkdienste verweigert werden.

Es ist am besten, IP Adressen zu verwenden, wenn immer dies möglich ist.

15.2.1.3. Operatoren

Die Zugriffskontrollregeln kennen zur Zeit einen Operator, EXCEPT. Dieser kann sowohl in der Daemon- als auch in der Client-List einer Regel verwendet werden.

Der EXCEPT Operator erlaubt spezifische Ausnahmen in einer Regel.

Im folgenden Beispiel der Datei hosts.allow, ist es allen example.com Hosts erlaubt zu verbinden, mit der Ausnahme von cracker.example.com:

ALL: .example.com EXCEPT cracker.example.com

In einem anderen Beispiel der Datei hosts.allow, können Clients des 192.168.0.x Netzwerks alle Services benutzen, mit der Ausnahme von FTP:

ALL EXCEPT vsftpd: 192.168.0.

AnmerkungAnmerkung
 

Aus organisatorischen Gründen ist es normalerweise besser, EXCEPT-Operatoren sparsam zu verwenden, und statt dessen die Erweiterungen der Regel in die andere Zugriffskontrolldatei einzufügen. Dadurch können alle Administratoren schnell die gewünschten Dateien durchsuchen, um zu sehen, welche Host-Rechner Zugriff und welche keinen Zugriff auf bestimmte Dienste haben sollen, ohne mehrere EXCEPT-Operatoren durchsuchen zu müssen.

15.2.2. Portmap und TCP Wrappers

Verwenden Sie keine Hostnamen beim Erzeugen von Zugriffskontrollregeln für portmap, da dessen Implementation von TCP Wrappers Host Look-Ups nicht unterstützt. Aus diesem Grund, verwenden Sie ausschließlich das Schlüsselwort ALL, wenn Sie Hosts in hosts.allow oder hosts.deny angeben.

Außerdem werden Änderungen der Host-Zugriffskontrollisten, die portmap betreffen, nicht sofort wirksam sein.

Da der Betrieb von weit verbreiteten Diensten wie NIS und NFS von portmap abhängt, bedenken Sie zuerst diese Einschränkungen.

15.2.3. Option-Felder

Zusätzlich zu den grundlegenden Regeln, welche Zugriff gewähren oder ablehnen, unterstützt die Red Hat Linux Implementation von TCP Wrappers Erweiterungen zu der Zugriffskontrollsprache durch Option-Felder. Durch Verwendung der Option-Felder innerhalb einer Hosts-Zugriffsregel, können Administratoren eine Reihe von Tasks erledigen, wie dem Ändern des Log-Verhaltens, Zusammenfassen der Zugriffskontrolle und dem Ausführen von Shell-Befehlen.

15.2.3.1. Logging

Option-Felder erlauben es Administratoren die Log-Einstellungen und den Schwierigkeitsgrad für eine Regel einfach zu ändern, indem die severity-Anweisung verwendet wird.

Im folgenden Beispiel, werden Verbindungen zum SSH Daemon von jedem Host in der example.com-Domain zu der Default Log authpriv geschrieben (da kein Wert angegeben ist), und dies mit einer Priorität von emerg:

sshd : .example.com : severity emerg

Es ist auch möglich, eine Log mit der severity-Option anzugeben. Das folgende Beispiel loggt alle Hosts aus der example.com Domain, welche versuchen zu einem SSH service zu verbinden, zu der local0 Log, mit einer Priorität von alert:

sshd : .example.com : severity local0.alert

AnmerkungAnmerkung
 

In der Praxis, wird dieses Beispiel nicht arbeiten, solange der Syslog-Daemon (syslogd) nicht dazu konfiguriert ist, Log-Meldungen zu local0 zu schreiben. Sehen Sie die syslog.conf man-Seite für Informationen zum Konfigurieren von benutzerdefinierten Logs.

15.2.3.2. Zugriffskontrolle

Option-Felder erlauben es dem Administratoren, Hosts explizit anzunehmen oder abzulehnen, indem sie die allow- oder deny-Anweisung als letzte Option hinzufügen.

Die folgenden Regeln, zum Beispiel, erlauben SSH-Verbindungen von client-1.example.com, lehnen aber Verbindungsversuche von client-2.example.com ab:

sshd : client-1.example.com : allow
sshd : client-2.example.com : deny

Durch erlauben der Zugriffskontrolle auf einer pro-Regel Basis, erlaubt das Option-Feld Administratoren alle Zugriffsregeln in entweder hosts.allow oder hosts.deny zusammenzufassen. Einige halten dies für einen einfacheren Weg die Zugriffsregeln zu organisieren.

15.2.3.3. Shell-Befehle

Option-Felder erlauben Zugriffsregeln Shell-Befehle auszuführen, durch die zwei folgenden Anweisungen:

  • spawn — Startet einen Shell-Befehl als Kind-Prozess. Diese Option-Anweisung kann Aufgaben wie die Verwendung von /usr/sbin/safe_finger durchführen, um weitere Informationen über den anfragenden Client zu erhalten, oder spezielle Log-Dateien mit dem echo Befehl erzeugen.

    Im folgenden Beispiel, versuchen Clients auf einen Telnet Service von der example.com Domain aus zuzugreifen, was in eine spezielle Log-Datei geschrieben wird:

    in.telnetd : .example.com \
      : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \
      : allow
  • twist — Ersetzt den angeforderten Service mit dem angegebenen Befehl. Diese Anweisung wird oft verwendet, um Fallen für etwaige Angreifer (im Englischen auch "honey pots", Deutsch Honigtöpfe genannt) zu stellen. Diese kann auch verwendet werden um Nachrichten zu verbindenden Clients zu senden. Der twist-Befehl muss am Ende der Regelzeile stehen.

    Im folgenden Beispiel, wird Clients, welche versuchen auf FTP Services von der example.com Domain aus zuzugreifen, eine Nachricht mit Hilfe des echo Befehls gesendet:

    vsftpd : .example.com \
    : twist /bin/echo "421 Bad hacker, go away!"

Für mehr Informationen zur Verwendung von Shell-Befehl Optionen, sehen Sie die hosts_options man-Seite.

15.2.3.4. Expansionen

Expansionen, welche im Zusammenhang mit spawn und twist-Anweisungen verwendet werden, liefern Informationen über den Client, Server und die betreffenden Prozesse.

Folgend ist eine Liste der verfügbaren Expansionen:

  • %a — Die IP-Adresse des Clients.

  • %A — Die IP-Adresse des Servers.

  • %c — Verschiedene Client-Informationen, wie zum Beispiel der Benutzer- und Hostname oder der Benutzername und die IP-Adresse.

  • %d — Der Name des Daemon-Prozesses.

  • %h — Der Hostname des Clients (oder IP-Adresse, wenn der Hostname nicht verfügbar ist).

  • %H — Der Hostname des Servers (oder IP-Adresse, wenn der Hostname nicht verfügbar ist).

  • %n — Der Hostname des Clients. Wenn dieser nicht verfügbar ist, wird unknown ausgegeben. Wenn der Hostname und die Hostadresse des Clients nicht übereinstimmen, paranoid ausgegeben.

  • %N — Der Hostname des Servers. Wenn dieser nicht verfügbar ist, wird unknown ausgegeben. Wenn der Hostname und die Hostadresse des Servers nicht übereinstimmen, paranoid ausgegeben.

  • %p — Die ID des Daemonprozesses.

  • %s — Verschiedene Serverinformationen, wie zum Beispiel der Daemonprozess und die Host- oder IP-Adresse des Servers.

  • %u — Der Benutzername des Clients. Wenn dieser nicht verfügbar ist, wird unknown ausgegeben.

Die folgende Beispielregel verwendet eine Expansion in Verbindung mit dem spawn Befehl, um den Host des Clients in einer benutzerdefinierten Log-Datei zu identifizieren.

Sie leitet TCP Wrappers an, sollte ein Verbindungsversuch zum SSH Daemon (sshd) von einem Host in der example.com Domain unternommen werden, mit dem Befehl echo den Versuch in eine spezielle Log-Datei zu schreiben, einschließlich Hostname des Client (unter Verwendung von %h):

sshd : .example.com  \
: spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
: deny

Ähnlich, können Expansionen dazu verwendet werden, um Nachrichten auf bestimmte Clients abzustimmen. Im folgenden Beispiel, wird Clients, welche versuchen auf FTP Services von der example.com Domain aus zuzugreifen, mitgeteilt, dass diese vom Server ausgeschlossen wurden:

vsftpd : .example.com \
: twist /bin/echo "421 %h has been banned from this server!"

Für eine vollständige Erklärung der verfügbaren Expansionen, wie zusätzlichen Zugriffskontroll-Optionen, sehen Sie Abschnitt 5 der man-Seiten von hosts_access (man 5 hosts_access) und die man-Seite für hosts_options.

Für zusätzliche Ressourcen im Bezug zu TCP Wrappers, sehen Sie Abschnitt 15.5.