Red Hat Enterprise Linux 3: Referenzhandbuch | ||
---|---|---|
Zurück | Kapitel 16. TCP Wrappers und xinetd | Nach vorne |
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:
/etc/hosts.allow
/etc/hosts.deny
Wenn ein Verbindungsversuch zu einem "TCP wrapped" Service eingeleitet wird, wird der Service folgende Schritte durchführen:
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.
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:
Da Zugriffsregeln in hosts.allow zuerst angewendet werden, haben diese Vorrang vor den Regeln in hosts.deny. Sollte der Zugriff zu einem Service 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 gegebenen Service angewendet, weswegen die Reihenfolge der Regeln sehr wichtig ist.
Sollte keine Regel für einen gegebenen Service gefunden werden, in keiner der beiden Dateien, so wird der Zugriff zu diesem Service gewährt.
"TCP wrapped" Services 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
|
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>: ...] |
<daemon list> — Eine durch Kommas getrennte Liste von Prozessnamen (nicht Service-Namen) oder dem ALLE Wildcard (siehe Abschnitt 16.2.1.1). Die Daemon-Liste akzeptiert auch Operatoren, in Abschnitt 16.2.1.4 aufgelistet, um größere Flexibilität zu gewähren.
<client list> — Eine durch Kommas getrennte Liste von Hostnamen, Host IP-Adressen, speziellen Patterns (siehe Abschnitt 16.2.1.2), oder speziellen Wildcards (siehe Abschnitt 16.2.1.1), welche die von dieser Regel betroffenen Hosts identifizieren. Die Client-Liste akzeptiert auch Operatoren, wie in Abschnitt 16.2.1.4 aufgelistet, um größere Flexibilität zu gewähren.
<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 16.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 16.2.2).
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.
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 16.2.2.
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.
![]() | 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. |
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 diesed 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 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.
![]() | 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 Service authorisierte Benutzer davon Netzwerk-Services zu verwenden. Es ist am besten IP Adressen zu verwenden, wenn immer dies möglich ist. |
Verwenden Sie keine Hostnamen, wie portmap, 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 zu portmap-Zugriffskontrollregeln nicht sofort wirksam, ohne dass der portmap Service neu gestartet wird.
Da der Betrieb von weit verbreiteten Diensten wie NIS und NFS von portmap abhängt, bedenken Sie zuerst diese Einschränkungen.
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. |
![]() | Anmerkung |
---|---|
Aus organisatorischen Gründen, ist es normalerweise besser EXCEPT-Operatoren zu vermeiden. Dadurch können alle Administratoren schnell die gewünschten Dateien durchsuchen, um zu sehen, welche Host-Rechner Zugriff und welche keinen Zugriff auf bestimmte Services haben sollen, ohne mehrere EXCEPT-Operatoren durchsuchen zu müssen. |
Zusätzlich zu den grundlegenden Regeln, welche Zugriff gewähren oder ablehnen, unterstützt die Red Hat Enterprise Linux Implementation von TCP Wrappers 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.
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 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 |
![]() | 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. |
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.
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 weitere Informationen zur Verwendung von Shell-Befehl Optionen, sehen Sie die hosts_options man-Seite.
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.
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 desHostnamen 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 Informationen zu TCP-Wrappers, sehen Sie Abschnitt 16.5. Für weitere Information zur Sicherung von TCP-Wrappers, sehen Sie das Kapitel Server-Sicherheit im Red Hat Enterprise Linux Sicherheitshandbuch.
Zurück | Zum Anfang | Nach vorne |
TCP Wrappers und xinetd | Nach oben | xinetd |