Config Lab: Login Security 1
One of the first configuration items that become second nature is the configuration of basic password settings. But it is also easy to forget about the small differences in password security configuration once you get used to configuring your own lab the same way every time. This lab can give you some quick exercises on a few of those options.
The Lab Exercise
Requirements
Configure console, Telnet, and enable mode security on all four devices in the figure as follows:
- Protect console access for all device consoles with a password of ‘certskills’.
- Protect privileged mode for all devices using password “ccnaskills” while storing the password as an MD5 hash.
- Protect Telnet access by requiring a username/password combination to login. To that end, create a username ‘person’ with a password of ‘access’ using the most secure option to configure the user.
- Assume all device interfaces shown in the lab are up, working, and correctly configured with IP addresses.
- Assume routing is configured and working correctly.
Figure 1: Network Topology and Addresses
Initial Configuration
Examples 1, 2, 3, and 4 show the beginning configuration state of R1, R2, SW1, and SW2.
hostname R1
!
interface GigabitEthernet0/1
ip address 10.10.10.1 255.255.255.252
no shutdown
!
interface GigabitEthernet0/2
ip address 20.20.20.1 255.255.255.0
no shutdown
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0Example 1: R1 Config
hostname R2
!
interface GigabitEthernet0/1
ip address 10.10.10.2 255.255.255.252
no shutdown
!
interface GigabitEthernet0/2
ip address 30.30.30.1 255.255.255.0
no shutdown
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0Example 2: R2 Config
hostname SW1
!
interface vlan 1
ip address 20.20.20.10 255.255.255.0
no shutdown
!
ip default-gateway 20.20.20.1
Example 3: SW1 Config
hostname SW2
!
interface vlan 1
ip address 30.30.30.10 255.255.255.0
no shutdown
!
ip default-gateway 30.30.30.1
Example 4: SW2 Config
Answer Options - Click Tabs to Reveal
You can learn a lot and strengthen real learning of the topics by creating the configuration – even without a router or switch CLI. In fact, these labs were originally built to be used solely as a paper exercise!
To answer, just think about the lab. Refer to your primary learning material for CCNA, your notes, and create the configuration on paper or in a text editor. Then check your answer versus the answer post, which is linked at the bottom of the lab, just above the comments section.
You can also implement the lab using the Cisco Packet Tracer network simulator. With this option, you use Cisco’s free Packet Tracer simulator. You open a file that begins with the initial configuration already loaded. Then you implement your configuration and test to determine if it met the requirements of the lab.
(Use this link for more information about Cisco Packet Tracer.)
Use this workflow to do the labs in Cisco Packet Tracer:
- Download the .pkt file linked below.
- Open the .pkt file, creating a working lab with the same topology and interfaces as the lab exercise.
- Add your planned configuration to the lab.
- Test the configuration using some of the suggestions below.
You can also implement the lab using Cisco Modeling Labs – Personal (CML-P). CML-P (or simply CML) replaced Cisco Virtual Internet Routing Lab (VIRL) software in 2020, in effect serving as VIRL Version 2.
If you prefer to use CML, use a similar workflow as you would use if using Cisco Packet Tracer, as follows:
- Download the CML file (filetype .yaml) linked below.
- Import the lab’s CML file into CML and then start the lab.
- Compare the lab topology and interface IDs to this lab, as they may differ (more detail below).
- Add your planned configuration to the lab.
- Test the configuration using some of the suggestions below.
Network Device Info:
All interfaces in the topology match the lab figure.
Need a Refresher?
Want a refresher before doing the lab? Check out this video.
Lab Answers Below: Spoiler Alert
Lab Answers: Configuration (Click Tab to Reveal)
Answers
Figure 1: Network Topology and Addresses
username person secret access
!
enable secret ccnaskills
!
line con 0
password certskills
login
!
line vty 0 4
transport input telnet
login local
Example 1: R1 Config
username person secret access
!
enable secret ccnaskills
!
line con 0
password certskills
login
!
line vty 0 4
transport input telnet
login local
Example 2: R2 Config
username person secret access
!
enable secret ccnaskills
!
line con 0
password certskills
login
!
line vty 0 4
transport input telnet
login local
Example 3: SW1 Config
username person secret access
!
enable secret ccnaskills
!
line con 0
password certskills
login
!
line vty 0 4
transport input telnet
login localExample 4: SW2 Config
Commentary, Issues, and Verification Tips (Click Tabs to Reveal)
Commentary
One of the first tasks to complete when configuring a new Cisco router or switch is configuring management access. This task includes the settings that define access to the console port and defining remote access privileges into a device. Sometimes people assume this task has already been completed correctly, leaving a poor device security configuration, leaving the device open to exploitation.
The first configuration requirement asked you to secure the console with a shared password of “certskills”. The command used to configure the password on a line is the password password command, and the command to enable login using that shared password is the login subcommand on that same line. These commands should have been configured on the console of each of the devices shown in the figure. (In fact, the same security configuration should be applied to all four devices based on the requirements in this lab.)
The second configuration requirement asked you to protect privileged mode with a shared password, which means you need to configure an enable password. The enable password password command would store the password in the configuration as clear text. If the service password-encryption global command was configured, IOS would store that password as an encrypted value. Unfortunately, that encryption is easily broken.
To meet the requirements of the lab, you have to use the enable secret password command. This command supports several methods to protect the password by storing only a hash or digest of the password. By default, with no other parameters, the enable secret command stores the password using MD5. So, the enable secret ccnaskills command meets all the requirements.
The third configuration requirement asked you to protect Telnet access with a per-user username/password, specifically for only one user to begin: user ‘person’ using the password of ‘access’. The lab asks you to use the most secure method, so as with the enable password, the most secure method uses the secret parameter instead of the password parameter.
Finally, to enable support for Telnet only and to use local usernames for those Telnet users, you need a couple of other commands. First, to enable Telnet only, use the transport input telnet command on the vty lines. (Some IOS versions and devices may default to support Telnet already.) Then to tell IOS to use local usernames for Telnet users, under those same vty lines, use the login local command, which enables a device to use the local username database for access.
Note that if you are doing this lab on real gear or even on CML, your device may support by default more than the 5 vty lines 0 through 4. Some support 0 through 15 by default. The point here is to make sure and configure the correct security commands, and to support Telnet or SSH, add those commands to all the vty lines supported on each device.
Known Issues in this Lab
This section of each Config Lab Answers post hopes to help with those issues by listing any known issues with Packet Tracer related to this lab. In this case, the issues are:
| # | Summary | Detail |
| 1 | None | No known issues related to this lab. |
Why Would Cisco Packet Tracer Have Issues?
(Note: The below text is the same in every Config Lab.)
Cisco Packet Tracer (CPT) simulates Cisco routers and switches. However, CPT does not run the same software that runs in real Cisco routers and switches. Instead, developers wrote CPT to predict the output a real router or switch would display given the same topology and configuration – but without performing all the same tasks, an actual device has to do. On a positive note, CPT requires far less CPU and RAM than a lab full of devices so that you can run CPT on your computer as an app. In addition, simulators like CPT help you learn about the Cisco router/switch user interface – the Command Line Interface (CLI) – without having to own real devices.
CPT can have issues compared to real devices because CPT does not run the same software as Cisco devices. CPT does not support all commands or parameters of a command. CPT may supply output from a command that differs in some ways from what an actual device would give. Those differences can be a problem for anyone learning networking technology because you may not have experience with that technology on real gear – so you may not notice the differences. So this section lists differences and issues that we have seen when using CPT to do this lab.
Beyond comparing your answers to this lab’s Answers post, you can test in Cisco Packet Tracer (CPT) or Cisco Modeling Labs (CML). In fact, you can and should explore the lab once configured. For this lab, once you have completed the configuration, try these verification steps.
- Connect to the console, and try to login with the configured password.
- Using the PC connected to a LAN interface, Telnet into the switch, and try the Telnet password.
- From either, use the enable command to then test the enable password.