Why Telnet is Bad

Remote network connection is critical for managing the enterprise network devices. Accessing the routers and switches is vital for the network administrators in order to execute daily operational tasks, which include (but are not limited to):

  • Creating and removing VLANs.
  • Adding and removing interfaces.
  • Shutting down or enabling interfaces.
  • Routing configuration, e.g. adding or removing static routes.


In Cisco IOS, the configuration for accessing the router is done by configuring the “lines”
for Secure Shell (SSH) and Telnet, which are the two most common remote management protocols. The "lines" can be physical ports (like AUX or Console) or virtual (like VTY).

The configuration of Telnet is a common practice, but it is advisable to use SSH. The reason for this is that Telnet data is sent in plain text in contrast to SSH, which encrypts the data. We will find out what that means in a moment with a Wireshark capture.


For these demonstrations, I will set up a very simple topology consisting of a router with a PC directly connected. The PC has Wireshark installed. Here are the initial configs:


R4

!

hostname R4

!

username cisco password cisco

!

enable secret cisco

!

interface GigabitEthernet3

ip address 192.168.109.14 255.255.255.0

!

line vty 0 4

login local

!

end


PC

!

!

The PC is configured with the 192.168.109.99/24.

!

end


Before telnetting into the router, I will start capturing the packets from the PC to the router. To enable the capture, follow these instructions:

  1. Open Wireshark.
  2. Select the “Capture” option.
  3. Click the “Interfaces” option.


After we click “Interfaces…” we will see the following window.



Select the interface you want to capture (eth0 in this case) and click “Start.”

After that, a window will open, and this is where the packets will appear. From the PC we can telnet to the router:


root@kali:~# telnet 192.168.109.14

Trying 192.168.109.14...

Connected to 192.168.109.14.

Escape character is '^]'.


User Access Verification


Username: cisco

Password: <cisco>

R4>en

Password:

R4#


After we login to the router, we can check the running-config with the show running-config command.


R4#show running-config


Now we can check the capture by right clicking on a Telnet packet and selecting “Follow TCP Stream.”



A window will open with the capture.



Click on the “Entire conversation” option and check the flow from the router’s IP to the host IP.




Now we can see the entire configuration of the router in plain text.



This demonstrates that while Telnet is widely used by administrators for remote management, it does not offer the security mechanisms like SSH, which establishes a secure connection from the host to the router.


The SSH configuration steps are as follows:


R4#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

R4(config)#ip domain-name ssh.local

R4(config)#crypto key generate rsa modulus 1024 general-keys

The name for the keys will be: R4.ssh.local


% The key modulus size is 1024 bits

% Generating 1024 bit RSA keys, keys will be non-exportable...

[OK] (elapsed time was 0 seconds)

R4(config)#username cisco password cisco

R4(config)#line vty 0 4

R4(config-line)#login local

R4(config-line)#transport input ssh


Now we can do SSH into the router.


root@kali:~# ssh -l cisco 192.168.109.14

Password: <cisco>

R4>en

Password:

R4#


If we do the same procedure for SSH, we would see the following output from the capture, which is not easily readable:



Bonus Section


1. Password vs. Secret


In the initial config of this blog post, a username and password of cisco was configured. If we do a show running-config | include username, we can see the username configured.


R4(config)#do sh run | inc username

username cisco password 0 cisco


What if we want to encrypt this password? We can do it in two ways. The first is by using the service password-encryption command.


R4(config)#service password-encryption

R4(config)#do sh run | inc username 

username cisco password 7 0822455D0A16


Even though this password was protected by MD7, this is easily breakable; we can go to the page http://www.ifm.net.nz/cookbooks/passwordcracker.html and enter the encrypted password to reverse engineer it.



In general, use the secret keyword instead of password whenever possible. For example, use enable secret instead of enable password.


Removing the username/password:


R4(config)#do sh run | inc username

username cisco password 7 0822455D0A16

R4(config)#no username cisco password 7 0822455D0A16


Adding the username/secret:


R4(config)#username cisco secret cisco

R4(config)#do sh run | inc username

username cisco secret 5 $1$DSnv$u.CyWdRcHNBvLvlexA6Iy1

 

2. Password Length Policy


Consider a good password length policy more than eight characters; but by default in IOS, we can configure passwords and secrets with a length of one character. For example:

 

R4#configure terminal

R4(config)#username cisco password o


We can see that the router accepted the password. If we Telnet into the router from the PC:


root@kali:~# telnet 192.168.109.14

Trying 192.168.109.14...

Connected to 192.168.109.14.

Escape character is '^]'.


User Access Verification


Username: cisco

Password: <o>

R4>


For this reason we can use the security passwords min-length command. If we set a length of eight, then only new passwords with a length of eight or more are going to be accepted (note that current passwords will not require modification, just new ones). For example:


R4(config)#security passwords min-length 8

R4(config)#username cisco password pass

% Invalid Password length - must contain 8 to 25 characters. Password configuration failed


3. Logging the Logins


When an attacker wants to gain access to a router, it could try different passwords (possibly some dictionary attack tools) in order to get access to the system. One way to log the user attempt would be to use the login on-success log and login on-failure log features.


R4(config)#login on-success log

R4(config)#login on-failure log


If we successfully login into the router, a message like this would appear:


%SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: cisco] [Source: 192.168.109.99] [localport: 23] at 03:07:31 UTC Wed Feb 17 2016


If the user fails to login, then the following message would appear:


%SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: cisco] [Source: 192.168.109.99] [localport: 23] [Reason: Login Authentication Failed - BadPassword] at 03:09:48 UTC Wed Feb 17 2016