Telnet, as a network protocol, has some drawbacks.

  • First, and most importantly, nothing is encrypted. Everything is sent in plain text through the network for anyone to read.
  • There is no authentication to ensure that the communications are between the two desired hosts and not a third party man in the middle attack.
  • There are several major known vulnerabilities in commonly used Telnet servers.
  • Finally, developed in 1968, it is an old protocol and like FTP, suffers from issues related to the massive amount of change from the environment it was originally intended for.

So while some of these drawbacks can be mitigated through various means such as limiting its use to safe internal networks, using other forms of encryption such as IPSEC for all traffic, why ever consider using it?

The main use I found was for pushing configuration changes to a large number of embedded devices on our network. Specifically we had to make a few changes to mail settings on all of our UPS's. Telnet was the only option for configuration besides HTTP. While SSH wasn't an option in this case, some non-Unix devices can generate some strange bugs with Paramiko.

It also worth noting, that if you are not using it, some devices will have Telnet enabled by default (sometimes other protocols like FTP or Bonjour) with no password or a default easily found online. So if you're not using it, lock it down. Also if web server on the embedded device isn't using TLS/SSL everything is in plain text as well.

In my case the UPS's were on separate VLANs from our users so the risk that the traffic would be sniffed, while not impossible, was low. Be sure to assess the potential risks and do what you can to mitigate them in your own enviornment.

Some Telnet servers use a menu while other have a more open command structure. Either way, the first step is to map out all of the steps to make the necessary changes.

The two most important functions in the telnetlib module are read_until and write. write sends the input to the server. The commands need to be sent at the correct time, when the remote server is expecting the commands. If all the commands are fired off with no break the remote server will most likely just ignore everything. read_until solves this problem by reading through the received text until it finds the defined term. When listing the steps for the script to take, also include the terms for script to wait for before proceeding to the next input.

Then, using the Python telnetlib module it is a pretty straightforward to setup a script to iterate through a list of devices, connecting and making the changes.

Here is a simple generic example.


import telnetlib

hosts = [] # Enter host addresses seperated by comma

user = "" # Enter Username 
pass = "" # Enter Password, consider removing this from the	script once its ran

for host in hosts:
	telnet = telnetlib.Telnet(host) # Connect to the host
	
    telnet.read_until("User: ") # Logging in, this will vary depending on the prompt
    telnet.write(user + "\n") # \n is the character symbol for Newline which includes a return, include this at the end of each command

    telnet.read_until("Password: ")
    telnet.write(password + "\n")

	telnet.read_until("?\n") # Again this will all very by device so change the prompts to fit your needs
	telnet.write("changeemail\n")
    
    telnet.read_until("New email: \n")
    telnet.write("example@example.com \n")
    telnet.read_until("?\n"
    telnet.write("exit")
    
    print host + 'has been configured'

print "All hosts configured"

This is a quick example of some simple automation that can be setup relatively quickly and can save a lot of manual work.