Hardening Management Access
Before you can implement a network device and expect to be able to use it to secure your network, you must first configure the device for secure management access. There are four primary methods of interactive management access:
| Console access | Requires physical console connectivity to the device |
| VTY access | Uses the network to establish virtual console access through the use of protocols such as Telnet and SSH |
| Web-based GUI | Uses a web-based GUI over HTTP or HTTPS to manage the device |
| Auxiliary access | Uses a modem connection for out-of- band console access |
You can implement a couple common items for all the access types that will increase the security of remote management access.
The first item you can implement is service password encryption on the device. You can do this on your IOS-based equipment by running the following command at the global configuration mode of execution:
rtr-1721(config)#service password-encryption
Although the encryption method implemented can be cracked in a matter of seconds, this will protect your system from casual observation hacks (for example, someone looking over your shoulder while you are viewing the system configuration).
The second item you can implement is exec timeouts. This will cause the remote management session to terminate automatically after a period of inactivity. The ensures that people are not able to connect to the device and gain access that they shouldn t have. It also ensures that if someone forgets to log off of the system, the session is not left connected.
You can implement exec timeouts on your IOS-based devices by running the following command while in the line configuration mode of execution:
rtr-1721(config-line)#exec-timeout 5 0
This configures the exec timeout to log off any idle session after five minutes and zero seconds. You will need to run this command for each line type, console, auxiliary, and VTY. For example, if you wanted to implement an exec timeout on all line types, you could run the following commands:
rtr-1721(config)#line con 0 rtr-1721(config-line)#exec-timeout 5 0 rtr-1721(config)#line vty 0 4 rtr-1721(config-line)#exec-timeout 5 0 rtr-1721(config-line)#line aux 0 rtr-1721(config-line)#exec-timeout 5 0
For your CatOS-based devices, you can implement exec timeouts by running the following command:
Console> (enable) set logout 5
This will configure the device to log out inactive sessions after five minutes.
 |
Implementing exec timeouts is particularly valuable for console connections because if someone disconnects from the console without logging out while in a privileged mode of execution, the next person who connects to the console port will automatically be in whatever mode of execution the device was left at. For example, if you disconnect while in the privileged mode of execution, the next person who connects will be in the privileged mode of execution without needing to enter a password.
| |
Securing Console Access
The first step of securing console access actually has nothing to do with configuring the device; rather, it relates to physical access. Console access requires that someone be able to physically connect to the console port on the device, typically using a PC serial connection. With physical access to the device, a hacker can do anything they want, including gaining access to the device configuration. Consequently, the first step of securing console access is to provide for the physical security of the device. The device should be placed in a locked and secured area to restrict individuals from gaining access to it.
The next step is to configure the device to require authentication of any console connections through the use of console passwords. This can be performed on your IOS-based devices by running the following commands from the global configuration mode of execution:
rtr-1721(config)#line con 0 rtr-1721(config-line)#login rtr-1721(config-line)#password <enterpassword>
For your CatOS-based devices, you can run the following command to enable a console password:
Console> (enable) set password Enter old password: < enteroldpassword > Enter new password: < enternewpassword > Retype new password: < enternewpassword >
This will require all users who connect via the console port to enter the password you defined. The drawback of this type of system is that all users share a common password. You can avoid this drawback by implementing Authentication, Authorization, and Accounting (AAA) or by using individual usernames and passwords for each user who may need to connect. We will discuss how to implement usernames and AAA in a moment.
Preventing Reverse Telnet Console Access
Reverse Telnet is sometime referred to as direct Telnet. Reverse Telnet is when the host computer initiates a Telnet session instead of accepting one, and it s a security issue for your IOS-based devices. You can prevent Reverse Telnet on your console port by running the following command at the console line configuration mode of execution:
local-rtr(config-line)#transport input none
| Note | Not all devices support this command. |
Securing VTY Access
VTY access is the traditional network-based management access using Telnet or SSH. Unlike console access, there are two aspects to securing your VTY access. The first aspect is implementing authentication. The second aspect is controlling management access to the device.
| |
Some IOS-based devices support more than five VTY lines. In those cases, you will need to repeat the commands for all VTY lines. For example, if your device supports 16 VTY lines, you would need to run line vty 5 16 and repeat the password command. This is true for all the line commands covered in this chapter.
| |
Implementing Authentication
Securing your VTY access for authentication is virtually the same as for your console, with one difference ”you must enable login before you define a password for authentication. You can do this by running the following commands from the global configuration mode of execution:
rtr-1721(config)#line vty 0 4 rtr-1721(config-line)#login rtr-1721(config-line)#password <enterpassword>
Like with console access, however, this system relies on shared passwords. We will discuss how to implement usernames and AAA in a moment.
Controlling Access
Controlling VTY access is as important as authentication, because if a system is not permitted to connect, it doesn t matter whether the user knows the password or not. You can control VTY access through the use of access lists that define what IP addresses are allowed to connect to the device.
The first step is to build the actual access control list. You can do this by running the following commands from the global configuration mode of execution:
rtr-1721(config)#access-list 70 remark ACL for VTY Access rtr-1721(config)#access-list 70 permit host 192.168.173.114 rtr-1721(config)#access-list 70 deny any log
This will create an ACL that permits 192.168.173.114 and denies all other IP addresses while logging the denial. The next step is to apply the ACL to the VTY line through the use of the access-class commands:
rtr-1721(config)#line vty 0 4 rtr-1721(config-line)#access-class 70 in
This will prevent all hosts that are not 192.168.173.114 from being able to establish a VTY connection.
| |
You can also prevent any remote administration of certain devices either by creating an ACL that denies all traffic and applying it to the VTY interface or by running the following commands on the VTY line:
rtr-1721(config-line)#transport input none rtr-1721(config-line)#exec-timeout 0 1 rtr-1721(config-line)#no exec
| |
For your CatOS-based devices, you can restrict VTY access with the set ip permit command, as follows :
Console> (enable) set ip permit enable Console> (enable) set ip permit 10.20.20.20 255.255.255.255
This will permit only the host at 10.20.20.20 to establish a VTY connection.
Telnet vs. SSH
As you know from other chapters, Telnet is less secure than SSH because Telnet does not encrypt the data being transmitted. Because of this, instead of using Telnet for VTY access, you should use SSH. You can configure SSH access on your IOS-based devices by running the following commands:
rtr-1721(config)#ip domain-name wjnconsulting.com rtr-1721(config)#crypto key generate rsa The name for the keys will be: rtr-1721.wjnconsulting.com Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 1024 % Generating 1024 bit RSA keys ...[OK] rtr-1721(config-line)#transport input ssh
The first command assigns a domain name to the device, which is required for RSA key generation. The second command generates the RSA keys needed to provide SSH access. After these two commands have been run, the device is prepared to run SSH. The final command requires that all VTY connections be established using SSH. Any other VTY connections, including Telnet connections, will be rejected.
You can configure SSH on CatOS-based devices that are running 6.0 mainline code or newer . The following commands will enable SSH connections:
Console> (enable) set ip dns domain wjnconsulting.com Default DNS domain name set to wjnconsulting.com Console> (enable) set crypto key rsa 1024 RSA keys were generated at: Tue Mar 16 2004, 17:43:30 1024 65537 15144146953605773328536717047857098506066347687468697 169639403524406206785753387015508885256996914783305378 Console> (enable) set ip permit enable Console> (enable) set ip permit 10.20.20.20 255.255.255.255 10.20.20.20 with mask 255.255.255.255 added to IP permit list.
Securing Web-Based Management Access
Web-based management is certainly the direction that most devices are headed in. Unfortunately, Cisco has had some significant security issues related to their web-based management. In addition, currently web-based management is just not at a point where it can replace the CLI. As a result, I recommend that you disable web-based management using the following commands on your IOS-based devices:
rtr-1721(config)#no ip http server rtr-1721(config)#no ip http secure-server
For your CatOS-based devices, you can disable web-based management using the following command:
Console> (enable) set ip http server disable
If you require web-based management, you should only use HTTPS because HTTP does not encrypt the data. You can enable HTTPS on your IOS-based devices by running the following commands:
rtr-1721(config)#ip http secure-server rtr-1721(config)#ip http access-class 70 rtr-1721(config)#ip http timeout-policy idle 300 life 3600 requests 1
These commands will enable HTTPS connections to the device that are permitted by ACL 70. In addition, they configure a number of timeout variables to further secure the access.
Securing Auxiliary Access
The auxiliary port is one of the most overlooked ports for device hardening. Although it is typically used for connecting a modem to provide out-of-band management to the device, it can also be used as a secondary console port. That means that if you overlook it, no matter how much you harden the console access, an attacker can potentially circumvent it.
The best recommendation I can make for hardening your auxiliary port is to simply disable it unless you are going to be using a modem. You can do this on your IOS-based devices by running the following commands at the global configuration mode of execution:
rtr-1721(config)#line aux 0 rtr-1721(config-line)#transport input none rtr-1721(config-line)#login local rtr-1721(config-line)#exec-timeout 0 1 rtr-1721(config-line)#no exec
If you are going to use the auxiliary port for out-of-band management, it should be secured in the same manner as your VTY lines.
Securing Privileged Mode Access
The privileged access mode is the mode of access that allows users to begin making changes. It is analogous to root in Linux/Unix or administrator in Microsoft Windows. Consequently, you want to secure who can access the privileged mode through the use of password authentication.
For your IOS-based devices, there are two methods of authenticating privileged mode access. The first method is through the use of the enable password command. This is a deprecated method, however, and should never be configured. The recommended method is through the use of the enable secret command. This method is recommended because it uses a more secure encryption method (the enable password method was hacked years ago, and a wealth of online password crackers are available that can crack enable password in less than a second). You can configure the enable secret password by running the following command at the global configuration mode:
rtr-1721(config)#enable secret <enterpassword>
The enable secret is stored in the configuration as an MD5 hash, and many password-cracking tools are available out there to perform dictionary attacks against an MD5 hash, such as Cain and Abel. This is why you should follow good password guidelines and not use a password that is susceptible to a dictionary attack.
Also, because the enable secret is the most secure method to encrypt your passwords, you should not use the same password anywhere else in the router configuration. Because the rest of the passwords are not encrypted as well, you could be throwing away the security you had for the MD5 hash by having the same password used and stored for some other type of authentication on your router.
You can configure your CatOS-based devices with an enable password to protect the privileged mode of execution by running the following command:
Console> (enable) set enablepass Enter old password: < enteroldpassword > Enter new password: < enternewpassword > Retype new password: < enternewpassword >
Although this will secure the privileged EXEC mode, this method has the same drawback as the previous authentication methods, namely the use of shared passwords. To address this drawback, however, you can implement usernames and AAA as described in the next section.
Implementing Usernames and AAA
By default, and as most of us were taught, logon and enable secret passwords are how to implement authentication on your network devices. Although they are better than nothing, the truth is that shared passwords are really pretty insecure . Because multiple people have the password, no accountability is available to determine who may have made a change to the device. In addition, anytime someone leaves the organization, you have to change all shared passwords throughout the enterprise. A much better solution is to implement usernames or, even more preferably, AAA on your network devices.
Implementing local usernames on your IOS-based devices is a pretty straightforward process. The first step is to create the usernames on the device by running the following command:
rtr-1721(config)#username <entername> privilege 15 password <enterpassword>
You can specify a privilege level from 0 to 15 for each user you have created. The second step is to configure the various access methods to use the local user accounts for authentication. You can do this by running the following command at all of the line configuration modes of operation for the device:
rtr-1721(config-line)#login local rtr-1721(config-line)#no password
The last line removes any shared password that may have been configured.
An even better solution is to implement AAA on the device. AAA on IOS-based devices is covered in exhaustive detail in Chapter 9.
Your CatOS-based devices can also be configured with AAA authentication. You can enable AAA authentication by running the following commands to enable authentication using TACACS+:
Console> (enable) set authentication enable tacacs enable primary Console> (enable) set authentication enable local enable Console> (enable) set authentication login tacacs enable primary Console> (enable) set authentication login local enable Console> (enable) set tacacs server 10.20.20.20 primary Console> (enable) set tacacs key <enterkey>
If you wanted to configure the device to use RADIUS, you would simply replace tacacs with radius .
Implementing Banners
As mentioned in Chapter 3, logon banners should be implemented to set the appropriate expectations of privacy and acceptable use of the system, resources, data, and network access capabilities.
You can enable banners on your IOS-based devices by running the command banner motd ^ . This will configure the device to use a caret (^) as a delimiting character. All data you enter until you type another ^ will be made the banner text. For example, to implement the sample banner text from Chapter 3, you would type the following:
rtr-1721(config)#banner motd ^ Enter TEXT message. End with the character '^'. This system is for the use of authorized users only. Individuals using this computer system without authority, or in excess of their authority, are subject to having all of their activities on this system monitored and recorded by system personnel. In the course of monitoring individuals improperly using this system, or in the course of system maintenance the activities of authorized users may also be monitored. Anyone using this system expressly consents to such monitoring and is advised that if such monitoring reveals possible evidence of criminal activity, system personnel may provide the evidence of such monitoring to law enforcement officials. Report suspected violations to the system security officer^
For your CatOS-based devices, you can implement a banner in a similar fashion by running the command set banner motd ^ followed by the banner text. End the text by repeating the delimiter , in this case the ^ character.
EAN: N/A
Pages: 125