17.2. 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
|
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>: <client list> [: <option>: <option>: ...] |
<daemon list> — Eine durch Kommas getrennte Liste von Prozessnamen (nicht Dienst-Namen) oder dem ALL Wildcard (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:
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.
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:
sshd : client-1.example.com : allow sshd : client-2.example.com : deny |
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:
in.telnetd : .example.com \ : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \ : allow
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):
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \ : deny |
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.