En mai 2009, j'ai écrit un article sur la sécurisation de telnetd afin que seul le processus RSN puisse l'utiliser (Telnet ne peut pas vivre avec, ne peut pas vivre sans). À l'époque, je pensais au réseau de service à distance, mais on m'a récemment rappelé une autre raison très importante pour exécuter le processus telnetd : les imprimantes à distance.
Le site en question ne permet aucun accès extérieur (à l'entreprise) au système et utilisait SSH pour tous les accès interactifs, ce qui permettait de se sentir en sécurité en n'exécutant pas le processus telnetd. Tout était correctement configuré, mais lorsqu'ils se sont connectés au spooler, celui-ci a signalé que l'imprimante était hors ligne et qu'ils ne pouvaient voir aucune tentative du système pour établir une connexion TCP avec l'imprimante.
Le périphérique d'impression a été configuré avec la chaîne de paramètres "-access_layer tli_al -ip A.B.C.D,P -tcp_only ". La chaîne "-access_layer tli_al" indique au système que pour accéder au périphérique, il a besoin de la couche TLI, c'est en fait le processus telnetd. Le "-ip A.B.C.D,P" est l'adresse IP de l'imprimante et le numéro de port auquel se connecter. C'est le "-tcp_only" qui a conduit le SysAdmin à croire que telnetd n'allait pas être utilisé, puisqu'il était "tcp only". En fait, la chaîne indique simplement à telnetd de ne pas envoyer d'options telnet une fois la connexion établie.
Donc, si vous devez utiliser telnetd pour établir des connexions avec des imprimantes distantes, comment pouvez-vous vous assurer qu'il n'accepte pas non plus les connexions ? La façon la plus simple est d'avoir un fichier telnetservice vide, vous avez besoin que le fichier existe pour que telnetd démarre mais il n'est pas nécessaire de spécifier que telnetd écoutera sur n'importe quel port.
Entreprise