Im Mai 2009 schrieb ich über die Absicherung von telnetd, so dass nur der RSN-Prozess die Möglichkeit hat, es zu benutzen (Telnet kann nicht mit ihm leben, kann nicht ohne ihn leben). Damals dachte ich über das Remote Service Network nach, aber ich wurde kürzlich an einen anderen sehr wichtigen Grund für die Ausführung des telnetd-Prozesses erinnert - entfernte Drucker.
Der betreffende Standort erlaubt keinen Zugriff von außen (dem Unternehmen) auf das System und verwendete SSH für alle interaktiven Zugriffe, so dass man sich sicher fühlte, den telnetd-Prozess nicht auszuführen. Sie hatten alles korrekt konfiguriert, aber als sie sich beim Spooler anmeldeten, meldete dieser, dass der Drucker offline sei, und sie konnten keinen Versuch des Systems erkennen, eine TCP-Verbindung mit dem Drucker herzustellen.
Das Druckgerät wurde mit der Parameterfolge "-access_layer tli_al -ip A.B.C.D,P -tcp_only " konfiguriert. Die "-access_layer tli_al" teilt dem System mit, dass es für den Zugriff auf das Gerät die TLI-Schicht benötigt, d.h. den telnetd-Prozess. Die Option "-ip A.B.C.D,P" ist die IP-Adresse des Druckers und die Nummer des Anschlusses, zu dem eine Verbindung hergestellt werden soll. Es war das "-tcp_only", das den SysAdmin zu der Annahme verleitete, dass telnetd nicht verwendet werden würde, da es "tcp only" sei. Die Zeichenfolge weist telnetd eigentlich nur an, nach dem Verbindungsaufbau keine Telnet-Optionen zu senden.
Wenn Sie also telnetd ausführen müssen, um Verbindungen zu entfernten Druckern herzustellen, wie können Sie sicherstellen, dass es auch keine Verbindungen annimmt? Der einfachste Weg ist, eine leere telnetservice-Datei zu haben. Die Datei muss existieren, damit telnetd starten kann, aber sie muss nicht angeben, dass telnetd auf irgendwelchen Ports lauscht.