Skip to main content

Back in May of 2009 I wrote about securing telnetd so that only the RSN process has the ability to use it (Telnet can’t live with it, can’t live without it). At the time I was thinking about the remote service network but I was recently reminded of another very import reason for running the telnetd process – remote printers.

The site in question does not allow any outside (the company) access to the system and was using SSH for all interactive access so felt safe in not running the telnetd process. They had everything correctly configured but when they logged in the spooler it reported that the printer was off line and they could see no attempt by the system to set up a TCP connection with the printer.

The print device was configured with the parameter string “-access_layer tli_al -ip A.B.C.D,P -tcp_only “. The “-access_layer tli_al” tells the system that to access the device it needs the TLI layer, this is basically the telnetd process. The “-ip A.B.C.D,P” is the IP address of the printer and the port number to connect to. It was the “-tcp_only” that lead the SysAdmin to believe that telnetd was not going to be used, since it was “tcp only”. The string actually just tells telnetd to not send any telnet options after the connection is established.

So if you have to run telnetd to make connections to remote printers how can you make sure that it also doesn’t accept connections? The simplest way is to have an empty telnetservice file, you need the file to exist for telnetd to start but it doesn’t have to specify that telnetd will listen on any ports.

© 2024 Stratus Technologies.