Nel maggio 2009 ho scritto un articolo su come proteggere telnetd in modo che solo il processo RSN potesse utilizzarlo (Telnet non può vivere con esso, ma non può vivere senza di esso). All'epoca pensavo alla rete di servizi remoti, ma recentemente mi è venuto in mente un altro motivo molto importante per eseguire il processo telnetd: le stampanti remote.
Il sito in questione non consente alcun accesso esterno (all'azienda) al sistema e utilizzava SSH per tutti gli accessi interattivi, quindi riteneva sicuro non eseguire il processo telnetd. Tutto era configurato correttamente, ma quando hanno effettuato l'accesso allo spooler, questo segnalava che la stampante era offline e non era possibile vedere alcun tentativo da parte del sistema di stabilire una connessione TCP con la stampante.
Il dispositivo di stampa è stato configurato con la stringa di parametri "-access_layer tli_al -ip A.B.C.D,P -tcp_only ". Il comando "-access_layer tli_al" indica al sistema che per accedere al dispositivo è necessario il livello TLI, che corrisponde sostanzialmente al processo telnetd. "-ip A.B.C.D,P" è l'indirizzo IP della stampante e il numero di porta a cui connettersi. È stato "-tcp_only" a indurre l'amministratore di sistema a credere che telnetd non sarebbe stato utilizzato, poiché era "solo tcp". In realtà, la stringa indica semplicemente a telnetd di non inviare alcuna opzione telnet dopo che la connessione è stata stabilita.
Quindi, se devi eseguire telnetd per stabilire connessioni con stampanti remote, come puoi assicurarti che non accetti anche connessioni? Il modo più semplice è avere un file telnetservice vuoto: il file deve esistere affinché telnetd possa avviarsi, ma non è necessario che specifichi che telnetd ascolterà su alcuna porta.