Red Hat Summit2.3.4.3.2. Zugriffskontroll-Optionen
Benutzer von
xinetd-Diensten können wählen, ob sie die Host-Zugriffskontrolldateien der TCP-Wrapper, Zugriffskontrolle mittels der xinetd-Konfigurationsdateien oder eine Kombination aus beidem verwenden wollen. Informationen zum Gebrauch von Host-Zugriffskontrolldateien der TCP-Wrapper finden Sie in Abschnitt 2.3.2, »TCP-Wrapper Konfigurationsdateien«.
In diesem Abschnitt wird der Einsatz von
xinetd für die Kontrolle von Zugriffen auf bestimmte Dienste behandelt.
Anmerkung
Im Gegensatz zu TCP-Wrappern muss der
xinetd-Administrator nach jeder Änderung den xinetd-Dienst neu starten, damit diese wirksam werden.
Ebenfalls im Gegensatz zu TCP-Wrappern betrifft die Zugriffskontrolle durch
xinetd lediglich die Dienste, die durch xinetd kontrolliert werden.
Die
xinetd-Host-Zugriffskontrolle unterscheidet sich von der von TCP-Wrappern verwendeten Methode. Während TCP-Wrapper die gesamte Zugriffskonfiguration in zwei Dateien ablegt, /etc/hosts.allow und /etc/hosts.deny, befindet sich die xinetd-Zugriffskontrolle in den jeweiligen Dienstkonfigurationsdateien im /etc/xinetd.d/-Verzeichnis.
Die folgenden Optionen werden von
xinetd für die Host-Zugriffskontrolle unterstützt:
only_from— Erlaubt nur den aufgeführten Host-Rechnern den Zugriff auf den Dienst.no_access— Verwehrt den aufgeführten Host-Rechnern den Zugriff auf den Dienst.access_times— Der Zeitraum, in dem ein bestimmter Dienst verwendet werden darf. Der Zeitraum muss im 24-Stunden-Format, also HH:MM-HH:MM, angegeben werden.
Die Optionen
only_from und no_access können eine Liste von IP-Adressen oder Hostnamen verwenden, oder ein gesamtes Netzwerk referenzieren. Wie TCP-Wrapper kann durch die Kombination der xinetd-Zugriffskontrolle und der entsprechenden Protokollkonfiguration die Sicherheit durch das Abweisen von Anfragen von gesperrten Hosts und das Protokollieren aller Verbindungsversuche erhöht werden.
Zum Beispiel kann die folgende
/etc/xinetd.d/telnet-Datei verwendet werden, um den Telnet-Zugriff von einer bestimmten Netzwerkgruppe auf ein System zu verweigern und um die Zeitspanne, die selbst erlaubte Benutzer angemeldet sein dürfen, einzuschränken:
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
no_access = 172.16.45.0/24
log_on_success += PID HOST EXIT
access_times = 09:45-16:15
}
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
no_access = 172.16.45.0/24
log_on_success += PID HOST EXIT
access_times = 09:45-16:15
}
Wenn nun ein Client-System vom
172.16.45.0/24-Netzwerk wie etwa von 172.16.45.2 versucht, auf den Telnet-Dienst zuzugreifen, erhält es die folgende Meldung:
Connection closed by foreign host.
Connection closed by foreign host.
Außerdem werden diese Anmeldeversuche in
/var/log/messages protokolliert:
Sep 7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107 Sep 7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107 Sep 7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 duration=0(sec)
Sep 7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107
Sep 7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107
Sep 7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 duration=0(sec)
Wenn Sie TCP-Wrapper zusammen mit der Zugriffskontrolle von
xinetd verwenden, müssen Sie die Beziehung dieser beiden Zugriffskontroll-Mechanismen zueinander verstehen.
Im Folgenden wird die Abfolge der
xinetd-Vorgänge beschrieben, wenn ein Client eine Verbindung anfordert:
- Der
xinetd-Daemon greift auf die Host-Zugriffsregeln der TCP-Wrapper durch einenlibwrap.a-Bibliotheksaufruf zu. Besteht eine Deny-Regel für den Client, so wird die Verbindung nicht aufgebaut. Besteht eine Allow-Regel für den Client, wird die Verbindung anxinetdweitergegeben. - Der
xinetd-Daemon überprüft seine eigenen Zugriffskontrollregeln für denxinetd-Dienst und den angeforderten Dienst. Besteht eine Deny-Regel für den Client, wird die Verbindung nicht aufgebaut. Andernfalls startetxinetdeine Instanz des angeforderten Dienstes und gibt die Kontrolle über die Verbindung an diesen weiter.
Wichtig
Seien Sie vorsichtig bei der Verwendung von TCP-Wrapper-Zugriffskontrollen in Verbindung mit
xinetd-Zugriffskontrollen. Eine Fehlkonfiguration kann unerwünschte Auswirkungen haben.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}