Latest

Home / ccna / Cisco / CCNA RnS Article #18: Secure Switch Management Plane!

CCNA RnS Article #18: Secure Switch Management Plane!

July 10, 2023 ,

 

CCNA RnS Article #18: Switch Management Configuration

In this article, I am going to talk about the Basic Management Configurations that one needs to configure to manage & secure the switch in a network.

Whatever a switch performs, falls into one of the categories of Data Plane, Control Plane, and Management Plane. User data forwarding from one port to another is an example of a Data Plane and this is what we need a switch for. How data forwarding is to be done, and what port should be in the forwarding state or blocking state are examples of Control Plane configuration. The last Management plane deals with the device itself, not about how to forward and learn network topologies. This article is all about Management Plane Configuration settings.

Securing Switch Access

We already discussed CLI access that can be accessed through the console port. By default, anyone who wants to access switch CLI using direct console access doesn’t require any password. Considering the switch is stored in a secured closet in the network room, this may be ok for the enterprise. However, when a network admin needs to access a switch remotely, CLI access needs to be secured. This CLI access can be protected using the –

  • User and Enable Mode Passwords
  • Creating a local user database with usernames
  • Using an External Centralized Authentication Server
  • Secure Remote Access using SSH

The Cisco devices by default allow full access to any user accessing the switch directly using the console connection. However, a network administrator trying to access a device via Telnet or SSH needs to provide the correct username and password to access the device. Securing both console and remote access connection is always a best practice.

Command to secure User-mode CLI access using console & remote access (VTY)–

Switch# config t

Switch(config)#line console 0

!login command means simply shared password for user

Switch(config-line)#login

Switch(config-line)#password cisco@123

Switch(config-line)#line vty 0 4

Switch(config-line)#login

Switch(config-line)#password cisco@123

Switch(config-line)#end

Switch# wr

When the above commands are executed on a device (switch or router), users will be presented with a prompt to specify the password before giving CLI access to the user. Passwords are case-sensitive meaning cisco@123 is not the same as Cisco@123.

Command to secure the Enable mode CLI access using enable password

Switch# config t

Switch(config)#enable secret Cisco@123

Switch(config)#end

Switch# wr

When the above enable password is configured, the user will be prompted for a password before full access is provided to the user. Till now whatever we have configured to secure CLI access, works well with the Lab environment however in a production environment, we need more security. For example, there may be multiple team members working on a network and need access. The above example will ask for the same password for all the users and there is no way to differentiate who configured what. In case of misconfiguration, it is not possible to identify who did misconfiguration.  

For a small network size, you can build local usernames and passwords for your small team members. Anyone who wants access from the team needs to use his username and password to access the device.

Configuring local username database for securing CLI access

With local username configuration on the device, you ensure the user needs to provide the username and the respective password before he gets access to USER MODE. Enable secret password remains the same and this setting doesn’t replace Enable password.

Switch# config t

Switch(config)#username mohan secret mohan@cisco123

Switch(config)#username sohan secret sohan@cisco123

Switch(config)#line vty 0 4

Switch(config)#login local

Switch(config)#line console 0

Switch(config)#login local

Switch(config)#end

Switch# wr

 

When the above configuration is executed on the device, the user will be prompted with a username and then a password. To successfully access the CLI, both username and password should match else the user would not be allowed to access the CLI.

SW2# telnet 192.168.1.1

Trying 192.168.1.1 ... Open


User Access Verification 

Username: mohan

Password:

SW1> enable

Password:

SW1# configure terminal

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

SW1(config)#^Z

SW1#

Securing CLI access with External Authentication Server

In a network with thousands of devices with tens of network admins, changing the credential for any user becomes a big project if it is locally configured on the device. This is time-consuming, labor-intensive, and error-prone. The Solution is to have a centralized authentication server. In this approach, you just need to define the username & password in one place at one time and you are done for all users and devices.

This external Authentication Server is known as Authentication, Authorization, and Accounting (AAA) server. This allows a centralized credential repository for users. Forced password management can also be done using self-service without calling the network security team. AAA Server uses RADIUS/TACACS+ protocols to talk to switch whether a user is valid or not. Let’s try to understand the interaction with an example. Let’s say Sohan wants to access a switch using his username & password communicated by the security team. The switch sends the username & password to the AAA server. AAA Server checks the local database and confirms whether the user is valid or not. If valid, access to CLI is approved else rejected. The valid user gets CLI access.

Figure 1: Authentication using AAA Server

If you have noticed, there are multiple protocols being used – the user to switch Telnet/SSH and switch to the AAA server is TACACS+/RADUS.

I hope you find this informative, see you soon with the second part of this article on SSH configuration & other management plane configurations!

 Continue Reading...