ICND1 100-105

ICND1 100-105

Understanding Cisco Router Security

We will start with physical security, followed by basic controls like implementing a password strategy, sign posting via login banners, and the use of SSH for improved and confidential configuration management.

Common Threats to Physical Installations

Information security policies should be based on risk analysis and risk management. Risk is based on the probability of threats exploiting assets with certain vulnerabilities. We have had threats to physical installations since the dawn of networking; however, these threats are augmented by some of the technology transit we see now a days. For example, it is a lot more likely to do poor handling of key electrical components in a modular device switch or router that requires installation of modules, installation of blades, and network cards to either expand its functionality or add more horsepower.

Power loss and other electrical threats become a big issue, knowing how we are consolidating devices, servers, and applications in data centers and trying to scale up to the number of connections and number of users that we want to serve. This can put a strain in our power management components and may result in a security incident, not necessarily related to a malicious attack.

Configuring Router Password

But again, the security is a multidimensional practice and so not only do we need to care about physical threats and physical security, but also access control and management control into the routers.

Configuring Router Password

RouterX(config)#no aaa new-model
RouterX(config)#line console 0
RouterX(config-line)#login
% Login disabled on line 0, until 'password' is set
RouterX(config-line)#password cisco
RouterX(config-line)#exi
RouterX(config)#line vty 0 4
RouterX(config-line)#login
% Login disabled on line 2, until 'password' is set
% Login disabled on line 3, until 'password' is set
% Login disabled on line 4, until 'password' is set
% Login disabled on line 5, until 'password' is set
% Login disabled on line 6, until 'password' is set
RouterX(config-line)#password sanjose
RouterX(config-line)#exi
RouterX(config)#enable password cisco
RouterX(config)#enable secret sanfran
RouterX(config)#service password-encryption

We have seen these commands already to configure line access into the device for management purposes. Each line can have its own password, or you can tie all of the lines to a local user database. You could even think about transporting or centralizing that user database in the form of a AAA server and have all devices querying that server in order to obtain authentication information.

Management should also be based on roles; this is what we know as role-based access control and so you should have users for certain functions in the device and other users that have access to privileged functions, which initially are set and defined by the enable and enable secret commands.

Even if you are using local authentication it is highly advisable to have users defined with appropriate privilege level. To force a user login process (Authentication) you need to switch to "AAA new-model" and to create a user. Again if you are using secret instead of password your configuration will be stronger.

RouterX(config)#aaa new-model
RouterX(config)#username admin privilege 15 secret learncisconet
RouterX(config)#
RouterX(config)#aaa authentication login default local
RouterX(config)#end
RouterX#wr
Building configuration...
[OK]
RouterX#
RouterX#quit

RouterX con0 is now available

Press RETURN to get started.

User Access Verification

Username: admin
Password:
RouterX>

Configuring the Loggin Banner

Information is power and as users get acquainted with the security policy, they will be in better position to comply with it or identify the situations in which the policies are not being fulfilled. A simple banner with this command - banner logging could convey the message of the access policy into routers and other devices for management purposes. It could also include information in terms of support and incident response.

Telnet vs. SSH Access

Confidentiality is key to any match on infrastructure. Not only are you changing passwords, which if sent in clear text could be exploited and known by malicious attackers or perhaps even nonmalicious attackers. But you are also sharing configuration files of routers and network devices and sending errors and notification massages back and forth across the network for troubleshooting purposes and for documentation purposes. Traditional tools like Telnet will not include the confidentiality mechanisms, and that is why it is recommended to move to encrypted sessions like SSH or implement cryptographic technologies that provide confidentiality, but also integrity and endpoint authentication via strong authentication.

!
ip domain-name mydomain.com
!
crypto key generate rsa
!
ip ssh version 2
!
line vty 0 4
  login local
  transport input ssh
!
!

We are talking about encryption keys and digital certificates. In configuring something like SSH, you have to consider the whole process from creation of keys to role-based access control via a local user database as shown in the figure to key management and time synchronization, so keys are not considered expired.