So installieren und richten Sie einen Beispieldienst mit xinetd auf RHEL 8/CentOS 8 Linux ein
Xinetd, oder der Extended Internet Services Daemon, ist ein sogenannter Super-Server. Sie können ihn so konfigurieren, dass er anstelle vieler Dienste lauscht, und den Dienst, der eine eingehende Anfrage verarbeiten soll, erst dann starten, wenn sie dort tatsächlich im System ankommt – und so Ressourcen sparen. Während dies bei einem System, in dem der Datenverkehr relativ konstant ist, keine große Sache zu sein scheint, hat dieser Dienst an der Spitze eines anderen Ansatzes einige nette Vorteile, wie z. B. Protokollierung oder Zugriffskontrolle.
In diesem Artikel werden wir xinetd auf einem RHEL 8/CentOS 8 installieren und den sshd-Daemon unter seine Obhut nehmen. Nachdem wir die Einrichtung überprüft haben, werden wir die Konfiguration ein wenig anpassen, um die Zugriffskontrolle in Aktion zu sehen.
In diesem Tutorial lernen Sie:
- So installieren Sie xinetd
- So richten Sie sshd auf RHEL 8/CentOS 8 als xinetd-Dienst ein
- So erlauben Sie den Zugriff nur von einem bestimmten Netzwerk auf den sshd-Dienst von xinetd
- So prüfen Sie den Datenverkehr von xinetd-Protokolleinträgen
Zulassen des Zugriffs von einem bestimmten Netzwerksegment auf SSDD.
Verwendete Softwareanforderungen und Konventionen
So installieren Sie den xinetd-Dienst in Red Hat 8 Schritt für Schritt Anleitung
Xinetd ist in den Basis-Repositories zu finden, nachdem die offiziellen Subscription Management Repositories eingerichtet wurden. Der sshd-Server wird standardmäßig auf jedem Red Hat (und so ziemlich jeder Linux-Distribution) installiert.
Keep in mind that
sshd will be turned off during this setup. Do NOT try to complete this guide on a system you can access only with ssh, otherwise you will loose your connection to the system at the minute you turn sshd off to start the xinetd server.
Fist we need to install the xinetd daemon. We’ll use dnf:
dnf install xinetd
Wenn Ihr System aus irgendeinem Grund keine OpenSSH-Installation enthält, können Sie Pakete wie in diesem Fall das openssh-Paket auf die gleiche Weise wie oben installieren:
dnf install openssh
Xinetd wird mit einer Standardkonfigurationsdatei /etc/xinetd.conf geliefert, sowie einigen netten Beispielen im Verzeichnis /etc/xinetd.d/, die alle standardmäßig deaktiviert sind. Mit einem Texteditor wie vi oder nano erstellen wir eine neue Textdatei /etc/xinetd.d/ssh mit folgendem Inhalt (beachten Sie, dass die neue Zeile nach dem Dienstnamen obligatorisch ist):
service ssh
{
disable = no
socket_type = stream
protocol = tcp
port = 22
wait = no
user = root
server = /usr/sbin/sshd
server_args = -i
}
Wenn der sshd-Server auf dem System läuft, müssen wir ihn stoppen, sonst kann xinetd nicht an TCP-Port 22 binden. Dies ist der Schritt, bei dem die Verbindung unterbrochen wird, wenn Sie über SSH angemeldet sind.
systemctl stop sshd
Wenn wir vorhaben, sshd langfristig über xinetd zu verwenden, können wir auch den systemd-Dienst dafür deaktivieren, um zu verhindern, dass er beim Booten startet:
systemctl disable sshd
Jetzt können wir mit xinetd beginnen:
systemctl start xinetd
Und optional aktivieren Sie den Start beim Booten:
systemctl enable xinetd
Nach dem Start von xinetd können wir uns über ssh anmelden, da unser Basis-Setup keine zusätzliche Einschränkung enthält. Um den Dienst zu testen, bitten wir um eine Anmeldung auf localhost:
ssh localhost
root@localhost's password:
Last login: Sun Mar 31 17:30:07 2019 from 192.168.1.7
#
Fügen wir eine weitere Zeile zu /etc/xinetd.d/ssh hinzu, kurz vor dem schließenden Armband:
[...]
server = /usr/sbin/sshd
server_args = -i
only_from = 192.168.0.0
}
Mit dieser Einstellung stellen wir nur den Zugriff aus dem Netzsegment 192.168.*.* wieder her. Wir müssen xinetd neu starten, damit diese Konfigurationsänderung wirksam wird:
systemctl restart xinetd
Unsere Labormaschine verfügt über mehr als eine Schnittstelle. Um die obige Einschränkung zu testen, werden wir versuchen, eine Verbindung herzustellen, um eine Verbindung zu einer Schnittstelle herzustellen, die von xinetd configuration nicht zugelassen wird, und zu einer, die tatsächlich erlaubt ist:
hostname -i
fe80::6301:609f:4a45:1591%enp0s3 fe80::6f06:dfde:b513:1a0e%enp0s8 10.0.2.15 192.168.1.14 192.168.122.1
Wir werden versuchen, die Verbindung vom System selbst aus zu öffnen, sodass unsere Quell-IP-Adresse mit dem Ziel übereinstimmt, mit dem wir eine Verbindung herstellen möchten. Wenn wir versuchen, eine Verbindung zu 10.0.2.15 herzustellen, dürfen wir daher keine Verbindung herstellen:
ssh 10.0.2.15
ssh_exchange_identification: read: Connection reset by peer
Dabei liegt die Adresse 192.168.1.14 innerhalb des zulässigen Adressbereichs. Wir erhalten die Eingabeaufforderung für das Passwort und können uns anmelden:
ssh 192.168.1.14
root@192.168.1.14's password:
Da wir die Standard-Protokollierungskonfiguration nicht geändert haben, werden unsere Anmeldeversuche (oder mit anderen Worten, unsere Versuche, auf den xinetd-Dienst zuzugreifen) in /var/log/messages protokolliert. Die Log-Einträge können mit einem einfachen grep gefunden werden:
cat /var/log/messages | grep xinetd
Mar 31 18:30:13 rhel8lab xinetd[4044]: START: ssh pid=4048 from=::ffff:10.0.2.15
Mar 31 18:30:13 rhel8lab xinetd[4048]: FAIL: ssh address from=::ffff:10.0.2.15
Mar 31 18:30:13 rhel8lab xinetd[4044]: EXIT: ssh status=0 pid=4048 duration=0(sec)
Mar 31 18:30:18 rhel8lab xinetd[4044]: START: ssh pid=4050 from=::ffff:192.168.1.14
Diese Nachrichten machen es leicht zu wissen, wie auf unsere Dienste zugegriffen wurde. Es gibt zwar viele andere Optionen (einschließlich der Begrenzung gleichzeitiger Verbindungen oder des Festlegens von Timeouts nach fehlgeschlagenen Verbindungen, um DOS-Angriffe zu verhindern), aber diese einfache Einrichtung zeigt hoffentlich die Leistungsfähigkeit dieses Superservers, der das Leben des Systemadministrators erleichtern kann – insbesondere überfüllte, mit dem Internet verbundene Systeme.