Telnet-Port-Anleitung: Legacy-Fernzugriff auf Port 23

Telnet öffnet eine TCP-Verbindung und präsentiert eine textbasierte Terminalsitzung. Nachdem der Server die Verbindung akzeptiert hat, können Client und Server Terminaloptionen aushandeln, dann sendet der Benutzer Befehle und erhält die Ausgabe als Klartext.

Diese Einfachheit ist der Grund, warum Telnet in der Geräteverwaltung, in Laboren, in Produktionsanlagen und bei Altgeräten überlebt hat. Aus diesem Grund ist es auch riskant: Ohne einen separaten verschlüsselten Tunnel kann jeder, der den Datenverkehr zwischen Client und Server erfassen kann, Anmeldeinformationen und Befehle lesen.

SSH hat Telnet für die meisten Remote-Verwaltungen ersetzt, da SSH die Sitzung verschlüsselt, den Server-Hostschlüssel überprüft und eine stärkere Authentifizierung unterstützt. SSH verwendet normalerweise den TCP-Port 22, während Telnet normalerweise den TCP-Port 23 verwendet.

Wenn das Gerät SSH unterstützt, verwenden Sie SSH anstelle von Telnet. Behalten Sie Telnet nur für Systeme bei, die nicht aktualisiert werden können, für den Zugriff auf isolierte Labore oder für kurze Notfallabläufe, bei denen bereits ausgleichende Kontrollen vorhanden sind.

Telnet erscheint immer noch auf älteren Routern und Switches, PBX-Systemen, Out-of-Band-Konsolenservern, Gebäudesteuerungen, Industriesteuerungen, Speicherarrays, Druckern und Anbietergeräten, die entwickelt wurden, bevor SSH zum Standard wurde.

Es wird auch als einfacher Diagnose-Client für rohe TCP-Dienste verwendet, obwohl moderne Tools wie NC, NCAT, Curl, OpenSSL S_Client und speziell entwickelte Protokoll-Clients normalerweise eine bessere Sichtbarkeit und weniger Überraschungen bieten.

Port 23 sollte fast nie für das öffentliche Internet zugänglich sein. Öffentliches Telnet zieht automatisierte Scans, Angriffe mit Standardkennwörtern, Botnet-Aktivitäten und opportunistische Geräteübernahmen nach sich. Wenn ein Telnet-Dienst von außerhalb eines vertrauenswürdigen Netzwerks erreichbar ist, behandeln Sie ihn als dringend zu überprüfende Gefährdung.

Wenn Telnet unvermeidbar ist, beschränken Sie es auf ein Verwaltungs-VLAN, VPN, einen Bastion-Host, eine Jumpbox, ein serielles Konsolennetzwerk oder eine Quell-IP-Zulassungsliste. Ziel ist es, Telnet nur für die Menschen und die Automatisierung erreichbar zu machen, die es wirklich benötigen.

Bevor Sie TCP 23 zulassen, prüfen Sie, warum Telnet weiterhin erforderlich ist und ob SSH, HTTPS-Verwaltung, eine Anbieter-API oder eine serielle Konsole es ersetzen können. Ermitteln Sie dann, wer von welchem ​​Netzwerk aus wie lange eine Verbindung herstellen soll und welche Protokollierung verfügbar ist.

Ein Port-Checker kann Ihnen sagen, ob TCP 23 von außen erreichbar ist, aber er kann Ihnen nicht sagen, ob die Anmeldeinformationen sicher sind oder ob das Gerät moderne Zugriffskontrollen unterstützt. Testen Sie den tatsächlichen Anmeldepfad nur von einem vertrauenswürdigen Netzwerk aus und vermeiden Sie den Versand echter Passwörter über nicht vertrauenswürdige Links.

Unter Windows kann der Telnet-Client zum Testen aktiviert werden, der Telnet-Server sollte jedoch nicht für die normale Verwaltung verwendet werden. Wenn ein Windows-System Remote-Befehlszugriff benötigt, verwenden Sie PowerShell Remoting, SSH, RDP über ein Gateway oder einen anderen verschlüsselten Verwaltungspfad.

Unter Linux sind Telnet-Serverpakete normalerweise unnötig und sollten deaktiviert bleiben. Wenn ein Legacy-Daemon ausgeführt werden muss, binden Sie ihn an eine private Schnittstelle und beschränken Sie den Zugriff mit firewalld, ufw, nftables, iptables oder einer hostbasierten Zulassungsliste.

Deaktivieren Sie Telnet auf Netzwerkgeräten und -geräten, wenn SSH- oder HTTPS-Verwaltung verfügbar ist. Wenn Herstellerbeschränkungen Telnet erzwingen, platzieren Sie das Gerät in einem eingeschränkten Verwaltungsnetzwerk und dokumentieren Sie die Ausnahme, damit sie beim nächsten Aktualisierungszyklus entfernt werden kann.

Beginnen Sie mit einer externen Portprüfung anhand des Hostnamens oder der IP-Adresse und Port 23. Wenn das Ergebnis offen ist, kann ein Remote-Client eine TCP-Verbindung zum Telnet-Listener herstellen. Das bedeutet nicht, dass es sicher ist, sich über das öffentliche Internet anzumelden.

Von einem vertrauenswürdigen Netzwerk aus können Sie das Banner mit Telnet-Host 23, nc -vz Host 23 oder ncat testen. Überprüfen Sie auf dem Server oder Gerät den Dienststatus und die Firewallregeln. Überprüfen Sie bei Appliances die Verwaltungseinstellungen, da Telnet möglicherweise getrennt von SSH oder der Webverwaltung aktiviert wird.

Wenn Port 23 geschlossen ist, ist Telnet möglicherweise deaktiviert, das Gerät unterstützt möglicherweise nur SSH, der Dienst ist möglicherweise an eine Verwaltungsschnittstelle gebunden oder eine Firewall blockiert möglicherweise den Pfad. Wenn es zu einer Zeitüberschreitung kommt, kann es sein, dass ein Router, eine ACL, eine VPN-Richtlinie, eine Cloud-Firewall oder eine Quell-IP-Einschränkung den Datenverkehr unterbricht.

Wenn der Port geöffnet ist, aber die Anmeldung fehlschlägt, überprüfen Sie das Format des Benutzernamens, den Passwortstatus, die Regeln für die Gerätezugriffsklasse, die Authentifizierung vor Ort und im Verzeichnis, die Leitungskonfiguration und die Sperreinstellungen. Bei Netzwerkgeräten sind VTY-Leitungsrichtlinien oder ACLs der Verwaltungsebene häufig die Ursache für den Fehler.

Deaktivieren Sie Telnet, wo immer möglich. Ersetzen Sie es durch SSH, HTTPS-Verwaltung, reinen VPN-Zugriff, serielle Konsole oder Anbietertools. Entfernen Sie Standardkonten, rotieren Sie freigegebene Passwörter und halten Sie die Geräte-Firmware auf dem neuesten Stand, bis die Telnet-Abhängigkeit verschwunden ist.

Wenn Telnet bestehen bleiben muss, isolieren Sie es von Benutzernetzwerken und dem Internet, protokollieren Sie Zugriffsversuche, überwachen Sie unerwartete Quelladressen und den Dokumenteneigentum. Behandeln Sie jede Telnet-Ausnahme als vorübergehende Betriebsschuld und nicht als normales Verwaltungsmuster.