In the last post, we introduced security and the elements that make up security: confidentiality, integrity and availability. We also began with Password management on Network devices and discussed the three basic types of passwords: enable password, enable secret and username/password combination. We will continue right from where we stopped.
CCNA Training – Resources (Intense)
Our Network diagram remains the same as before (see below):
NETWORK DEVICE SECURITY (cont’d)
Remote Access Connectivity
The first topic we will discuss is remote access to network devices. As you may know, network devices can be configured locally, via console i.e. line con 0, or remotely, using telnet, SSH i.e. line VTY. When you have physical access to devices, you can connect a console cable to the device and then launch a terminal emulation application like TeraTerm, PuTTY, etc. on the connected PC. However, network devices can also be managed remotely by telnet or SSH connections. A network administrator has to be more careful when using remote access so as not to cause a lockout.
Telnet: The VTY lines on network devices (routers, switches) allow them to be remotely configured. Telnet is the simplest form of remote connection. By default, a network device will NOT accept telnet connections without a password being set. This is illustrated below when Router_US tries to initiate a telnet connection to Router_UK:
Please note that Packet Tracer only shows [Connection to x.x.x.x closed by foreign host]. However, on real devices (and GNS3), the reason will be given as: “Password required, but none set“. Let’s set up Router_UK to accept telnet connections. This is done by setting a password on the VTY lines.
‘linevty 0 4‘ above literally means “from line vty 0 to line vty 4”. It means there are five VTY lines on this network device. Therefore, we can set different passwords on different lines.
For every remote connection, one VTY line is used. It means this network device can accept a maximum of 5 simultaneous remote connections. Once the 5th line is in use, any other remote connection is rejected. Note that some network devices have 16 VTY lines (line vty 0 4 and line vty 5 15). Don’t be scared when you see this in a configuration file.
Now that we have set telnet up, let’s try connecting again using the command telnet <ip_address>:
Notice that we have now been placed in the user EXEC mode of Router_UK. By default, telnet places the remote user in user EXEC mode. This default access can be overridden as we’ll see later in this lesson.
There’s a security problem with telnet however. This is a screenshot of a live network packet capture between Router_US and Router_UK:
Telnet is not encrypted! Everything that passes through the line is in clear-text – yes, even your password. So, if an attacker is eavesdropping on the line, your password can be discovered. This brings us to the next remote access method.
SSH: Secure Shell does exactly what the name suggests: it secures. According to Cisco, “SSH is a more secure alternative to Telnet. SSH provides encryption for the session traffic between your local management device such as a PC and the networking device that you are managing. Encrypting the session traffic with SSH prevents hackers that might intercept the traffic from being able to decode it.” There are four steps to configure SSH on a network device:
Configure a hostname.
Configure a domain name.
Generate the SSH key to be used. At this stage, SSH is enabled on the network device.
Enable SSH support on the VTY lines.
After generating the RSA keys (RSA stands for Rivest, Shamir, and Adleman), SSH is automatically enabled. There are two major versions of SSH: Version 1 and Version 2. Version 2 is more secure than Version 1. Also, the key size of RSA keys must be a minimum of 768 bits before SSH version 2 can be enabled. Using the default values after issuing the crypto key generate rsa command gives you only 512 bits. Be aware of this.
What is left is enabling SSH support on the VTY lines. By default, the network device will accept SSH connections once SSH is enabled but you can use the transport input command to specify what protocols can be used to initiate remote connections to the network device. For example:
The basic command to open an SSH connection is ssh –l <username><ip_address>. The “-l” option lets you specify the username to use. So you may ask me, what username will it use? Well, this is where we see the 3rd form of password management from the previous post- username/password combination.
There needs to be a place where the username and password combinations are stored. This can be the local database of the network device or it can be external authentication servers like Windows Active Directory. We will restrict this post to the simple form of local database.
The following commands can be used to add a username/password combination to a device’s local database:
As we saw in the previous post, the difference between using the “password” or “secret” options is how it is stored in the configuration file. Passwords specified using the “password” option will be stored in plain text (or Vigenère cipher if password encryption is enabled) while passwords specified with the “secret” option will be hashed with MD5.
I’ll go ahead and create a username of “cisco” with password “cisco123”. The default configuration on VTY lines is that remote connections are authenticated using the password set on the line. This is because of the default login command specified under the line configuration. To change this default behaviour to use username/password combinations, we specify the login local command. This tells the network device to authenticate users using the local database. Use this command wisely: if you specify this command and there are no users in the local database, you would have just succeeded in performing a Denial of Service (DoS) on yourself.
Now, let’s initiate a connection from Router_UK to Router_US:
Another note of warning: Packet tracer is a simulation tool. While it requires you to specify the username when initiating an SSH connection, if the user does not exist in the local database and the default login command is still under the line configuration, it allows the connection to be initiated using the line password. Real network devices will give a “% Authentication failed.” error.
Now that we have seen the different ways to remotely connect to network devices and how usernames and passwords play a role in this connection, let’s take a look at Privilege levels. As you may have noticed, there are times when we are working in the user EXEC mode (‘>’) and other times in the privileged EXEC mode (‘#’). What are the differences and their significance?
There are two EXEC modes in Cisco networking devices: User EXEC mode and Privileged EXEC mode. By default, User EXEC mode is at privilege level 1 while Privileged EXEC mode is at level 15. The commands available in privilege level 1 are only a handful of the commands available at privilege level 15. Think of it like a school which has different classrooms. The commands in privilege level 1 can be described as the children in one classroom of the school. ALL the children in all the classrooms will be the commands available at privilege level 15.
What has this got to do with Telnet and SSH? The default mode a user is placed in after successfully opening a remote connection is the User EXEC mode. Any user in this mode (with default configuration) is limited in what they can do. So, how can a remote user gain access to privileged EXEC mode? There are three basic ways:
Enter the enable password/secret command: In the previous post, we set up these passwords. When the user enters the enable command, they are presented with a password prompt IF ONE IS CONFIGURED. This is important to note. If no enable password or enable secret is configured, the user cannot get privileged EXEC mode. Let’s see how this works by opening a connection from Router_US to Router_UK.
Now, I will take out the enable password on Router_UK and try again.
I’m sure you are learning great ways to cause Denial of Service attacks for yourself. Don’t play this trick on your network administrator; he may not be too happy.
Line privilege level: The second way to go about this is to change the privilege level of the terminal line. What this means is that everyone who logs in remotely will be placed at the level configured on the line. This does not hold true when authentication is per username/password combination as we’d see in the next point. So I’m going to set the privilege level on the line, change authentication back to using the line password and allow telnet connections.
Let’s initiate the connection again and see what happens.
Notice that I am placed in privileged EXEC mode (‘#’) immediately. Something you may want to take note here is that only privilege level 1 has the ‘>’ sign. All other levels (2-15) have the ‘#’ sign. What this means is, just because you see a ‘#’ sign doesn’t always mean you have privilege level 15.
Change the ‘privilege level 15‘ under the line configuration to ‘privilege level 2’, open a remote connection and see for yourself that you still have the ‘#’ sign. To be sure of what level you are at, issue the “show privilege” command.
User Privilege level: The line privilege level will not always scale well. First, we lose the ability to use the username/password combination. In reality, we still have the ability to use it but it doesn’t place us in privileged EXEC mode. Secondly, it does not give us per-user flexibility.
Therefore, Cisco devices allow us to assign privilege levels per user. This is done with the username<username>privilege<priv_level> command. You can set the privilege level together with the user’s password on the same line but make sure the privilege option is issued BEFORE the password (or secret) option else the password will be set to every phrase after the ‘password’ option.
Let’s create some users on Router_UK and assign privilege level to them. We will also enable local login.
Now, let us log in with these usernames and see what level we are placed in. User ‘cisco1’ first, with a privilege level of 1:
Now user ‘cisco2’ with a privilege level of 2:
Finally, user ‘cisco15’ with a privilege level of 15:
There we have the three basic ways. In more advanced topics beyond the CCNA exam, we will see how ‘AAA’ can be used to accomplish all these.
While we are on this topic of privilege levels, it is interesting to know that you can move commands around between levels. For example, the screen below shows what happens when I add the following commands to a router’s configuration:
Notice in the screen above that even though I’m still in privilege level 1, I can perform commands that have been moved to that level. This is beyond the scope of the CCNA exam but I just thought I’d let you know about the possibility.
This brings us to the end of Part 2. In this lesson, we discussed and configured Telnet and SSH and pointed out how SSH is more secure than Telnet (which sends everything unencrypted). We also mentioned that there are two versions of SSH, version 1 and version 2. We then moved on to using the local database of the network device for username/password authentication. We rounded up with the three basic ways of gaining privileged EXEC mode: enable password/secret, line privilege level and user privilege level.
In the next article, we will move to switches and configure some port security. We will also look at turning off some unnecessary services running on network devices that can be exploited by attackers. If we have time (or perhaps in a 4th and final article), we will also look at restricting who can connect remotely using ACLs and finally, do some troubleshooting.
I hope it has been fun for you but before you go, here are some questions (be careful, they are all tricky):
If you see this message on a Router, what does it tell you: ‘%SSH-5-ENABLED: SSH 1.99 has been enabled’?
What password is configured when this command is issued: “username cisco password cisco privilege 15“?
By default, what privilege level are you on when you see the ‘#’ sign?
Bonus question: How do you allow a router to accept remote connections without requiring a password?
As before, answers will be given just before the next article when adequate responses have been received.
Cisco IOS Security Configuration Guide- Configuring Security with Passwords Privileges and Logins: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_usr_cfg/configuration/12-4t/sec-cfg-sec-4cli.html
Configuring Secure Shell on Routers and Switches Running Cisco IOS:http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a00800949e2.shtml