Xinetd, oder Extended Internet Services Daemon, ist ein sogenannter Superserver. Sie können es so konfigurieren, dass es anstelle vieler Dienste lauscht und den Dienst, der eine eingehende Anfrage bearbeiten soll, erst dann startet, wenn sie tatsächlich im System ankommt – und so Ressourcen spart. Während dies auf einem System mit relativ permanentem Datenverkehr keine große Sache zu sein scheint, hat dieser Dienst vor einem anderen Ansatz 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
einfügen Daemon unter seiner Obhut. 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 unter RHEL 8 / CentOS 8 als xinetd-Dienst ein
- Zugriff nur von einem bestimmten Netzwerk auf den sshd-Dienst von xinetd erlauben
- So prüfen Sie den Datenverkehr von xinetd-Protokolleinträgen
Zugriff von einem bestimmten Netzwerksegment auf sshd erlauben.
Softwareanforderungen und verwendete Konventionen
Kategorie | Anforderungen, Konventionen oder verwendete Softwareversion |
---|---|
System | RHEL 8 / CentOS 8 |
Software | xinetd 2.3.15-23, OpenSSH 7.8p1 |
Andere | Privilegierter Zugriff auf Ihr Linux-System als root oder über sudo Befehl. |
Konventionen | # – erfordert, dass bestimmte Linux-Befehle mit Root-Rechten ausgeführt werden, entweder direkt als Root-Benutzer oder durch Verwendung von sudo Befehl$ – erfordert, dass bestimmte Linux-Befehle als normaler, nicht privilegierter Benutzer ausgeführt werden |
Schritt-für-Schritt-Anleitung zur Installation des xinetd-Dienstes in Red Hat 8
Xinetd
finden Sie in den Basis-Repositories, nachdem Sie die offiziellen Subscription Management-Repositories eingerichtet haben. Die sshd
server wird standardmäßig auf jedem Red Hat (und so ziemlich jeder Linux-Distribution) installiert.
Denken Sie daran, dass
sshd
wird während dieser Einrichtung ausgeschaltet. Versuchen Sie NICHT, diese Anleitung auf einem System abzuschließen, auf das Sie nur mit ssh zugreifen können, da Sie sonst Ihre Verbindung zum System in dem Moment verlieren, in dem Sie sshd deaktivieren, um den xinetd-Server zu starten.- Als erstes müssen wir den
xinetd
installieren Dämon. Wir verwendendnf
:# dnf install xinetd
- Wenn Ihr System aus irgendeinem Grund keine OpenSSH-Installation enthält, können Sie Pakete wie in diesem Fall
openssh
installieren Paket auf die gleiche Weise wie oben:# dnf install openssh
- Xinetd wird mit einer Standardkonfigurationsdatei
/etc/xinetd.conf
geliefert , sowie einige nette Beispiele in/etc/xinetd.d/
Verzeichnis, alle standardmäßig deaktiviert. Mit einem Texteditor wievi
odernano
, 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 }
- Falls die
sshd
Server läuft auf dem System, wir müssen ihn stoppen, sonstxinetd
kann nicht an TCP-Port 22 binden. Dies ist der Schritt, bei dem Sie getrennt werden, wenn Sie über ssh angemeldet sind.# systemctl stop sshd
Wenn wir vorhaben, langfristig sshd über xinetd zu verwenden, können wir auch den
systemd
deaktivieren Dienst dafür, um zu verhindern, dass es beim Booten startet:systemctl disable sshd
- Jetzt können wir
xinetd
starten :# systemctl start xinetd
Und optional den Start beim Booten aktivieren:
# systemctl enable xinetd
- Nach dem Start von xinetd können wir uns über ssh anmelden, da unser Grundsetup keine zusätzlichen Einschränkungen enthält. Um den Dienst zu testen, bitten wir um 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 Schlussarmband:[...] server = /usr/sbin/sshd server_args = -i only_from = 192.168.0.0 }
Mit dieser Einstellung beschränken wir den Zugriff nur vom Netzwerksegment 192.168.*.*. Wir müssen xinetd neu starten, damit diese Konfigurationsänderung wirksam wird:
# systemctl restart xinetd
- Unsere Labormaschine hat mehr als eine Schnittstelle. Um die obige Einschränkung zu testen, versuchen wir, eine Verbindung zu einer Schnittstelle herzustellen, die von der xinetd-Konfiguration nicht zugelassen wird, und zu einer, die tatsächlich zugelassen wird:
# 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 zu öffnen, sodass unsere Quell-IP-Adresse dieselbe ist wie das Ziel, zu dem wir eine Verbindung herstellen möchten. Wenn wir also versuchen, eine Verbindung zu
10.0.2.15
herzustellen , dürfen wir nicht verbinden:# ssh 10.0.2.15 ssh_exchange_identification: read: Connection reset by peer
Während die Adresse
192.168.1.14
innerhalb des zulässigen Adressbereichs liegt. Wir erhalten die Passwortabfrage und können uns anmelden:# ssh 192.168.1.14 [email protected]'s password:
- Da wir die Standardprotokollierungskonfiguration nicht geändert haben, werden unsere Anmeldeversuche (oder mit anderen Worten unsere Versuche, auf den xinetd-Dienst zuzugreifen) unter
/var/log/messages
protokolliert . Die Protokolleinträge können mit einem einfachengrep
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 einfach zu erkennen, wie auf unsere Dienste zugegriffen wurde. Während es viele andere Optionen gibt (darunter das Beschränken gleichzeitiger Verbindungen oder das Festlegen von Zeitüberschreitungen nach fehlgeschlagenen Verbindungen, um DOS-Angriffe zu verhindern), zeigt dieses einfache Setup hoffentlich die Leistungsfähigkeit dieses Superservers, der das Leben des Systemadministrators erleichtern kann – insbesondere überfüllt, mit Internetzugriff Systeme.