NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux Rerenzhandbuch- TCP Wrapper Konfigurationsdateien
Um zu bestimmen, ob es einer Client-Maschine erlaubt ist, zu einem gewissen Dienst zu verbinden, verwenden TCP Wrapper die folgenden zwei Dateien, die auch Hosts-Zugriffsdateien gennant werden:
/etc/hosts.allow
/etc/hosts.deny
Wenn ein Verbindungsversuch zu einem "TCP wrapped" Dienst eingeleitet wird, wird der Dienst folgende Schritte durchf�hren:
Referenziert auf /etc/hosts.allow. — Der "TCP wrapped" Dienst parst die /etc/hosts.allow-Datei sequentiell und wendet die erste Regel an, die f�r diesen Dienst festgelegt worden ist. Wenn eine dazu passende Regel ausfindig gemacht werden kann, erlaubt dieser Dienst die Verbindung. Wenn nicht, geht dieser zum n�chsten Schritt �ber.
Referenziert auf /etc/hosts.deny. — Der "TCP wrapped" Dienst parst die Datei /etc/hosts.deny sequentiell. Wenn eine dazu passende Regel ausfindig gemacht werden kann, lehnt dieser Dienst die Verbindung ab. Wenn nicht, wird der Zugang zu diesem Dienst bewilligt.
Die folgenden Punkte sind wichtig, wenn TCP Wrapper verwendet werden um Netzwerk-Dienste 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, wird jegliche Regel in hosts.deny, welche den Zugriff verbietet, ignoriert.
Da alle Regeln von oben nach unten abgearbeitet werden, wird lediglich die erste Regel f�r einen dazu passenden Dienst angewendet, weswegen die Reihenfolge der Regeln extrem wichtig ist.
Sollte keine Regel f�r einen gegebenen Dienst gefunden werden, in keiner der beiden Dateien, so wird der Zugriff zu diesem Dienst gew�hrt.
"TCP wrapped" Dienste speichern Regeln f�r die Hosts-Zugriffsdateien nicht zwischen, jegliche �nderungen zu hosts.allow oder hosts.deny treten deswegen sofort in Kraft.
Warnung
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
17.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-Diensten zu kontrollieren:
<daemon list> — Eine durch Kommas getrennte Liste von Prozessnamen (nicht Dienst-Namen) oder dem ALLWildcard (siehe Abschnitt 17.2.1.1). Die Daemon-Liste akzeptiert auch Operatoren (siehe dazu Abschnitt 17.2.1.4), um gr��ere Flexibilit�t zu gew�hrleisten.
<client list> — Eine durch Kommas getrennte Liste von Hostnamen, Host IP-Adressen, speziellen Patterns (siehe Abschnitt 17.2.1.2) oder speziellen Wildcards (siehe Abschnitt 17.2.1.1), welche die von dieser Regel betroffenen Hosts identifizieren. Die Client-Liste akzeptiert auch Operatoren, wie in Abschnitt 17.2.1.4 aufgelistet, um gr��ere Flexibilit�t zu gew�hrleisten.
<option> — Eine optionale Aktion oder durch Doppelpunkte getrennte Liste von Aktionen, welche ausgef�hrt werden, wenn eine Regel angewendet wird. Option-Felder unterst�tzen Expansionen (siehe Abschnitt 17.2.2.4), und k�nnen verwendet werden, um Shell-Befehle auszuf�hren, Zugriff zu gew�hren oder abzulehnen, und die Log-Methode zu �ndern (siehe Abschnitt 17.2.2).
Folgend ist eine einfaches Beispiel einer Hosts-Zugriffsregel:
vsftpd : .example.com
Diese Regel leitet TCP Wrapper 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:
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.
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, siehe Abschnitt 17.2.2.
17.2.1.1. Wildcards
Wildcards erlauben TCP Wrapper 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.
Achtung
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.
17.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
Wichtig
Wenn im IPv4 Adressraum gearbeitet wird, sind Paare von Adresse/Prefixl�nge (prefixlen) Deklarationen nicht unterst�tzt. Lediglich IPv6-Regeln k�nnen dieses Format benutzen.
[IPv6 Adresse]/prefixlen Paar — [net]/prefixlen Paare k�nnen auch als Pattern verwendet werden, um Zugriff zu einer bestimmten Gruppe von IPv6-Adressen zu kontrollieren. Das folgende Beispiel trifft auf jeden Host mit einer Adresse von 3ffe:505:2:1:: bis 3ffe:505:2:1:ffff:ffff:ffff:ffff zu:
ALL : [3ffe:505:2:1::]/64
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 Wrapper zur Datei /etc/telnet.hosts f�r alle Telnet-Verbindungen:
in.telnetd : /etc/telnet.hosts
Andere, weniger verwendete Patterns werden auch von TCP Wrappern angenommen. Siehe man-5-Seite von hosts_access f�r weitere Informationen.
Warnung
Seien Sie sehr vorsichtig beim Verwenden von Host- und Domain-Namen. Ein Angreifer k�nnte verschiedene Tricks anwenden, um die richtige Namensaufl�sung zu umgehen. Zus�tzlich verhindert eine Unterbrechung im DNS Dienst authorisierte Benutzer davon Netzwerk-Dienste zu verwenden.
Es ist am besten IP Adressen zu verwenden, wenn immer dies m�glich ist.
17.2.1.3. Portmap und TCP Wrapper
Verwenden Sie keine Hostnamen beim Erzeugen von Zugriffskontrollregeln f�r portmap, da portmaps Implementation von TCP Wrapper 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 zu portmap-Zugriffskontrollregeln nicht sofort wirksam, ohne dass der portmap Dienst neu gestartet wird.
Da der Betrieb von weit verbreiteten Diensten wie NIS und NFS von portmap abh�ngt, bedenken Sie zuerst diese Einschr�nkungen.
17.2.1.4. 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 Dienste benutzen, mit der Ausnahme von FTP:
ALL EXCEPT vsftpd: 192.168.0.
Anmerkung
Aus organisatorischen Gr�nden, ist es oft einfacher die Benutzung von EXCEPT-Operatoren zu vermeiden. Dadurch k�nnen andere 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.
17.2.2. Option-Felder
Zus�tzlich zu den grundlegenden Regeln, welche Zugriff gew�hren oder ablehnen, unterst�tzt die Red Hat Enterprise Linux Implementation von TCP Wrapper Erweiterungen zu der Zugriffskontrollsprache durch Optionsfelder. Durch Verwendung der Optionsfelder 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.
17.2.2.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 Standard-Logdatei 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 protokolliert alle Hosts aus der example.com Domain, welche versuchen zu einem SSH Dienst zu verbinden, zu der local0 Log, mit einer Priorit�t von alert:
sshd : .example.com : severity local0.alert
Anmerkung
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.
17.2.2.2. Zugriffskontrolle
Option-Felder erlauben es den 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:
Durch das 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.
17.2.2.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 Dienst von der example.com Domain aus zuzugreifen, was in eine spezielle Log-Datei geschrieben wird:
twist — Ersetzt den angeforderten Dienst mit dem angegebenen Befehl. Diese Anweisung wird oft verwendet, um Fallen f�r etwaige Eindringlinge (im Englischen auch "honey pots", auf Deutsch Honigt�pfe genannt) zu stellen. Diese kann auch verwendet werden, um Nachrichten zu verbindenden Clients zu senden. Die twist-Anweisung muss am Ende der Regelzeile stehen.
Im folgenden Beispiel, wird Clients, welche versuchen auf FTP Dienste 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 weitere Informationen zur Verwendung von Shell-Befehl Optionen, sehen Sie die hosts_options man-Seite.
17.2.2.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, wird 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, wird 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.
Sollte ein Verbindungsversuch zum SSH Daemon (sshd) von einem Host in der example.com Domain unternommen werden, f�hre den Befehl echo aus, um den Versuch in eine spezielle Logdatei zu schreiben, einschlie�lich des Hostnamens des Client (unter Verwendung der %h Expansion):
Auf �hnliche Weise k�nnen Expansionen dazu verwendet werden, um Nachrichten auf bestimmte Clients abzustimmen. Im folgenden Beispiel, wird denjenigen Clients mitgeteilt, welche versuchen auf FTP Dienste von der example.com Domain aus zuzugreifen, 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 Informationen zu TCP-Wrapper, sehen Sie Abschnitt 17.5. F�r weitere Information zur Sicherung von TCP-Wrappern siehe das Kapitel Server-Sicherheit im Red Hat Enterprise Linux Sicherheitshandbuch.
