Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

2.3.2. TCP-Wrapper Konfigurationsdateien

Um festzustellen, ob es einem Client erlaubt ist, sich mit einem bestimmten Dienst zu verbinden, verwenden TCP Wrapper die folgenden beiden Dateien, die auch als hosts access-Dateien bezeichnet werden:
  • /etc/hosts.allow
  • /etc/hosts.deny
Wenn bei einem TCP-wrapped Dienst eine Client-Anfrage eingeht, führt er die folgenden Schritte durch:
  1. Er referenziert /etc/hosts.allow — Der TCP-wrapped Dienst analysiert die /etc/hosts.allow-Datei sequentiell und wendet die erste Regel an, die für diesen Dienst festgelegt wurde. Wenn eine passende Regel ausfindig gemacht werden kann, erlaubt der Dienst die Verbindung. Wenn nicht, geht er zum nächsten Schritt über.
  2. Er referenziert /etc/hosts.deny — Der TCP-wrapped Dienst analysiert die /etc/hosts.deny-Datei sequentiell. Wenn eine passende Regel ausfindig gemacht werden kann, lehnt der Dienst die Verbindung ab. Wenn nicht, wird der Zugang zu diesem Dienst bewilligt.
Die folgenden Punkte sind wichtig, wenn TCP-Wrapper verwendet werden, um Netzwerkdienste zu schützen:
  • Da Zugriffsregeln in hosts.allow zuerst angewendet werden, haben diese Vorrang vor den Regeln in hosts.deny. Sollte der Zugriff zu einem Dienst in hosts.allow erlaubt sein, so wird eine den Zugriff auf diesen Dienst verbietende Regel in hosts.deny ignoriert.
  • Da alle Regeln von oben nach unten abgearbeitet werden, wird lediglich die erste auf einen Dienst passende Regel angewendet, weshalb die Reihenfolge der Regeln extrem wichtig ist.
  • Sollte keine Regel für den Dienst gefunden werden oder keine der beiden Dateien vorhanden sein, so wird der Zugriff zu diesem Dienst gewährt.
  • TCP-wrapped Dienste speichern Regeln für die Hosts-Zugriffsdateien nicht zwischen. Jegliche Änderungen an hosts.allow oder hosts.deny treten daher auch ohne Neustart der Netzwerkdienste sofort in Kraft.

Warnung

Sollte die letzte Zeile einer Hosts-Zugriffsdatei kein Zeilenvorschubzeichen sein (durch Drücken der Enter-Taste erzeugt), schlägt die letzte Regel in der Datei fehl und ein Fehler wird entweder in /var/log/messages oder /var/log/secure protokolliert. Dies ist auch der Fall für Regeln, die ohne Backslash-Zeichen auf mehrere Zeilen umgebrochen sind. Das folgende Beispiel zeigt den relevanten Teil einer Protokollmeldung für eine durch genannte Gründe fehlerhafte Regel: 
warning: /etc/hosts.allow, line 20: missing newline or line too long

2.3.2.1. Formatierung von Zugriffsregeln

Das Format der beiden Dateien /etc/hosts.allow and /etc/hosts.deny ist identisch. Jede Regel muss in einer neuen Zeile beginnen. Leere Zeilen oder Zeilen, die mit dem Rautenzeichen (#) beginnen, werden ignoriert.
Jede Regel verwendet das folgende, grundlegende Format, um den Zugriff zu Netzwerkdiensten zu steuern: 
<daemon list>: <client list> [: <option>: <option>: ...]
  • <daemon list> — Eine kommagetrennte Liste mit Prozessnamen (nicht Dienstnamen) oder der ALL-Platzhalter. Die Daemon-Liste akzeptiert auch Operatoren (siehe Abschnitt 2.3.2.1.4, »Operatoren«) für größere Flexibilität.
  • <client list> — Eine kommagetrennte Liste mit Hostnamen, Host-IP-Adressen, bestimmten Zeichenketten oder Platzhaltern, die die von der Regel betroffenen Hosts spezifizieren. Die Client-Liste akzeptiert auch Operatoren (siehe Abschnitt 2.3.2.1.4, »Operatoren«) für größere Flexibilität.
  • <option> — Eine optionale Aktion oder durch Doppelpunkte getrennte Liste von Aktionen, die ausgeführt werden, wenn eine Regel angewendet wird. Optionsfelder unterstützen Expansionen, führen Shell-Befehle aus, gewähren Zugriff oder lehnen diesen ab, und ändern das Protokollierungsverhalten.

Anmerkung

Weitere Informationen zu den oben erwähnten Begriffen finden Sie an anderen Stellen in diesem Handbuch:
Nachfolgend sehen Sie ein einfaches Beispiel für eine Hosts-Zugriffsregel: 
vsftpd : .example.com
Diese Regel weist TCP-Wrapper an, nach Verbindungen zum FTP-Daemon (vsftpd) von jedem Host in der example.com-Domain Ausschau zu halten. Wird diese Regel in hosts.allow eingefügt, so wird die Verbindung angenommen. Wird diese Regel dagegen in hosts.deny eingefügt, so wird die Verbindung abgelehnt.
Folgendes Beispiel einer Hosts-Zugriffsregel ist komplizierter und verwendet zwei Optionsfelder: 
sshd : .example.com  \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny
Beachten Sie, dass in diesem Beispiel jedem der Optionsfelder ein Backslash (\) vorausgeht. Die Verwendung eines Backslash verhindert, dass eine Regel aufgrund ihrer Länge nicht funktioniert.
Diese Beispielregel besagt, dass bei einem Verbindungsversuch zum SSH-Daemon (sshd) von einem Host in der example.com-Domain der echo-Befehl ausgeführt wird (der den Verbindungsversuch in eine spezielle Protokolldatei schreibt) und die Verbindung abgelehnt wird. Da die optionale deny-Direktive verwendet wird, wird diese Zeile den Zugriff ablehnen, auch wenn sie in der hosts.allow-Datei erscheint. Für einen detaillierteren Überblick der Optionen, siehe Abschnitt 2.3.2.2, »Optionsfelder«.
2.3.2.1.1. Platzhalter
Platzhalter erlauben TCP-Wrappern eine einfachere Übereinstimmung mit Gruppen von Daemons oder Hosts. Platzhalter werden häufig im Client-Listenfeld der Zugriffsregeln verwendet.
Die folgenden Platzhalter stehen zur Verfügung:
  • ALL — Stimmt mit allen Werten überein. Kann sowohl für die Daemon-Liste als auch für die Client-Liste verwendet werden.
  • LOCAL — Stimmt mit jedem Host überein, der keinen Punkt (.) enthält, wie z. B. localhost.
  • KNOWN — Stimmt mit jedem Host überein, dessen Host-Name und Host-Adresse oder der Benutzer bekannt sind.
  • UNKNOWN — Stimmt mit jedem Host überein, dessen Host-Name und Host-Adresse oder der Benutzer unbekannt sind.
  • PARANOID — Stimmt mit jedem Host überein, dessen Host-Name nicht mit der Host-Adresse übereinstimmt.

Wichtig

Die Platzhalter KNOWN, UNKNOWN und PARANOID sollten mit Vorsicht verwendet werden, da deren ordnungsgemäßer Betrieb von einem funktionierenden DNS-Server abhängt. Ein Problem bei der Namensauflösung kann eine Zugriffsverweigerung auf Dienste für berechtigte Benutzer zur Folge haben.
2.3.2.1.2. Muster
Muster können im Client-Listenfeld von Zugriffsregeln benutzt werden, um Gruppen von Client-Hosts genauer zu bestimmen.
Nachfolgend sehen Sie eine Liste der gängigsten Muster für Einträge in der Client-Liste:
  • Hostname beginnt mit einem Punkt (.) — Ein Punkt am Anfang eines Host-Namens bewirkt, dass auf alle Host-Rechner, die in diesem Hostnamen enden, die Regel angewendet wird. Das folgende Beispiel trifft auf jeden Host in der example.com Domain zu: 
    ALL : .example.com
  • IP-Adresse endet mit einem Punkt (.) — Ein Punkt am Ende einer IP-Adresse bewirkt, dass auf alle Hosts, deren IP-Adresse mit derselben numerischen Gruppe beginnt, die Regel angewendet wird. Das folgende Beispiel trifft auf jeden Host im 192.168.x.x-Netzwerk zu: 
    ALL : 192.168.
  • IP-Adresse/Netzmaske-Paar — Netzmasken-Ausdrücke können auch als ein Muster 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

    Wichtig

    Wenn im IPv4-Adressraum gearbeitet wird, werden paarweise Deklarationen von Adresse/Präfixlänge (prefixlen) (CIDR-Notation) nicht unterstützt. Lediglich IPv6-Regeln können dieses Format verwenden.
  • [IPv6 Adresse]/prefixlen Paar — [net]/prefixlen Paare können auch als Muster verwendet werden, um den Zugriff zu einer bestimmten Gruppe von IPv6-Adressen zu regeln. Das folgende Beispiel trifft auf jeden Host mit einem Adressbereich von 3ffe:505:2:1:: bis 3ffe:505:2:1:ffff:ffff:ffff:ffff zu: 
    ALL : [3ffe:505:2:1::]/64
  • Ein Sternchen (*) — Sternchen können für komplette Gruppen von Host-Namen oder IP-Adressen verwendet werden, solange diese nicht in einer Client-Liste verwendet werden, die bereits andere Arten von Muster verwendet. Das folgende Beispiel trifft auf alle Hosts in der example.com-Domain zu: 
    ALL : *.example.com
  • Der Schrägstrich (/) — Wenn die Client-Liste mit einem Schrägstrich beginnt, wird diese als Dateiname behandelt. Dies ist nützlich, wenn Regeln benötigt werden, die eine große Anzahl von Hosts angeben. Das folgende Beispiel verweist TCP-Wrapper auf die /etc/telnet.hosts-Datei für alle Telnet-Verbindungen: 
    in.telnetd : /etc/telnet.hosts
Es gibt noch weitere, weniger häufig verwendete Muster, die ebenfalls von TCP-Wrappern akzeptiert werden. Weitere Informationen finden Sie auf der hosts_access(5)-Handbuchseite.

Warnung

Seien Sie sehr vorsichtig bei der Verwendung von Host- und Domain-Namen. Ein Angreifer kann verschiedene Tricks anwenden, um die richtige Namensauflösung zu umgehen. Zudem hindert ein Ausfall des DNS-Dienstes sogar berechtigte Benutzer an der Verwendung von Netzwerkdiensten. Es sollten daher wann immer möglich IP-Adressen verwendet werden.
2.3.2.1.3. Portmap und TCP Wrappers
Portmaps Implementierung von TCP-Wrappern unterstützt keine Namensauflösung, was bedeutet, dass portmap keine Host-Namen zur Identifizierung von Hosts verwenden kann. Daher müssen Regeln für die Zugriffskontrolle für Portmap in hosts.allow oder hosts.deny IP-Adressen oder den Schlüsselbegriff ALL für die Spezifizierung von Hosts verwenden.
Änderungen an den portmap-Zugriffskontrollregeln werden nicht sofort wirksam. Sie müssen ggf. den portmap-Dienst neu starten.
Da der Betrieb von weit verbreiteten Diensten wie NIS und NFS von portmap abhängt, bedenken Sie diese Einschränkungen.
2.3.2.1.4. Operatoren
Die Zugriffskontrollregeln akzeptieren derzeit einen Operator, EXCEPT. Dieser kann sowohl in der Daemon- als auch in der Client-Liste einer Regel verwendet werden.
Der EXCEPT-Operator erlaubt spezifische Ausnahmen an breiter gefächerten Treffern in einer Regel.
Im folgenden Beispiel einer hosts.allow-Datei ist es allen example.com Hosts gestattet, sich mit allen Diensten mit Ausnahme von cracker.example.com zu verbinden: 
ALL: .example.com EXCEPT cracker.example.com
In einem anderen Beispiel einer hosts.allow-Datei können Clients des 192.168.0.x-Netzwerks alle Dienste benutzen, mit der Ausnahme von FTP: 
ALL EXCEPT vsftpd: 192.168.0.

Anmerkung

Der besseren Übersicht halber ist es oft besser, EXCEPT-Operatoren zu vermeiden. Dadurch können andere Administratoren schnell die gewünschten Dateien durchsuchen, um zu sehen, welche Hosts Zugriff und welche keinen Zugriff auf bestimmte Dienste haben sollen, ohne dass mehrere EXCEPT-Operatoren berücksichtigt werden müssen.