Config Lab: Login Security 1

 In 200-301 V1 Ch06: Switch Management, 200-301 V1 Part 2: Ethernet, 200-301 V1 Parts, Config Lab, Config Lab CCNA Vol 1 Part 2, Hands-on

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.

All about Config Labs

The blog has a series of lab exercises called “Config Labs.” Each lab presents a topology with the relevant initial configuration for each device. The lab also lists new requirements, after which you should create the additional configuration to meet those requirements. You can do the lab on paper, in a text editor, or use software tools like Cisco Packet Tracer or Cisco Modeling Labs.

Once you have created your answer, you can click various tabs at the bottom of this post to see the lab answers, comments about the lab, and other helpful information.

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 0

Example 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 0

Example 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:

  1. Download the .pkt file linked below.
  2. Open the .pkt file, creating a working lab with the same topology and interfaces as the lab exercise.
  3. Add your planned configuration to the lab.
  4. Test the configuration using some of the suggestions below.

Download this lab’s Packet Tracer File

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:

  1. Download the CML file (filetype .yaml) linked below.
  2. Import the lab’s CML file into CML and then start the lab.
  3. Compare the lab topology and interface IDs to this lab, as they may differ (more detail below).
  4. Add your planned configuration to the lab.
  5. Test the configuration using some of the suggestions below.

Download this lab’s CML file!

 

Network Device Info:

All interfaces in the topology match the lab figure.

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 local

Example 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. 

  1. Connect to the console, and try to login with the configured password.
  2. Using the PC connected to a LAN interface, Telnet into the switch, and try the Telnet password.
  3. From either, use the enable command to then test the enable password.

More Labs with Related Content!

Config Lab: Switch IP 1
Config Lab: CLI Miscellany 1
Subscribe
Notify of
guest

18 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
brahooke

Why are some of the labs locked so you can’t access the CLI? I get an error popup saying “all usable tabs are hidden or locked away by design in this power state” Is this by design and part of the challenge of the lab? Please explain.

certskills

Brahooke,
I’m not sure what you mean, as I get no such error when opening this or any other lab. The error is not intentional. Certainly, it’s not a message generated by design by me for this lab. Sorry I can’t be of more help.
Wendell

brahooke

That was my mistake Wendell. It seems there was a PT setting under Options>Preferences>Show/Hide tab that allows you to access CLI options for the devices on the topology. My apologies, even though I have completed “Introduction to Packet Tracer” my usage of the application is no where near where I need it to be.

certskills

Not a problem, Brahooke. Glad you figured it out! I still learn something about PT most months. Enjoy!

Niels

Hi there,

The latest packet tracer does not support the files for this lab. Which version should I use?

Kind regards,
Niels

certskills

Niels,
Could you tell me what version you’re using and what error message you see? Reason I ask is that with PT, newer versions of code should open older files, at least for several versions. Also, I can open the .pkt file as downloaded from this post with PT 8.0 and 8.1. However, you’re the second recent person to make a similar comment, so I’m wondering if something unusual is going on.
In short, I can’t recreate your problem.

jorge3687

Hello, in this lab you ask for a username/password combination to login to telnet, yet in the answers you dont configure the username

certskills

Hi Jorge,
Uhh, I think it’s the first line in the config section for each device in the sample config. “username person secret access”. Or am I missing your point? Let me know if so.
Wendell

GJM

Hi I got all of the configation correct except for the ‘transport input telnet’ command. I am not sure where I am missing that requirement from the scenario explained. Can you please explain where that is implied it is required in the configuration?

Charlie

Hello Grendal,

I hope all is well.

Please note, ‘Configure console, Telnet, and enable mode security on all four devices in the figure as follows…

Yet in the ‘Lab Answers Below: Spoiler Alert’. You only mentioned to configure the username on sw1 and sw2.

Should the username and password be configured on all devices

Thanks

Bernard

I have started working on each of your labs and I am getting used to it. Its great to be able to configure all of the devices and satisfying when I see that I did the same way as in your spoilers. I even checked it using show running-config and used telnet command to remotely connect to the other devices from the local unit you are currently in.
Your study plan in your book is an effective learning for me.
Thanks a lot Wendell!

Matthew Bascom

Hello,

I’m trying to confirm connectivity to SW1 via telnet. The provided topology doesn’t include a PC, so I added a PC to SW1 by using a console cable. I opened the Terminal option from the PC Desktop and confirmed the default settings for baud, data bits, parity, and stop bits. But when I clicked OK on the PC settings page, I was presented with a blank screen. Any thoughts on adding a PC to the topology to console to the switch? Thank you.

Matthew Bascom

My mistake was attaching the console cable to the PC’s FastEthernet0 port; Telnet worked after I connected the console cable to the PC’s RS 232 port.

Also, today I passed the CCNA exam! Thank you for all that you do, Wendell. Over the past four years, I’ve spent more time reading and rereading your Cisco CCNA Official Cert Guides than anything any other book.

Thank you!

Screenshot-from-2023-11-20-19-55-11
18
0
Would love your thoughts, please comment.x
()
x