Chapter 4: Cisco Security Best Practices
In This Chapter
Looking into the areas of management
Delving into Authentication, Authorization, and Accounting
Collecting and monitoring logs
Securing protocols
Managing the network’s configuration
Implementing physical security
Security is often the elephant in the room. Security is there, and obvious, but nobody wants to be the one who brings it up or acknowledges it. I know a company that is absolutely paranoid about security and has hoops upon hoops for people to jump through to get new equipment added to the network, but it also has remote computers that have almost no security on them that have access to the entire network with no network Access Control Lists (ACLs). Why? Because a common misconception is that if you manage ACLs on remote devices, you can get yourself in a bind by doing things wrong.
Security should never be skipped because it is too difficult or too scary. There is always some uncertainty by implementing new systems, but there is also uncertainty about the safety of your data by not implementing security systems. Given a choice, I would rather explain difficulties with a new, safer system, or even data loss by implementing a new system, rather than explain why everything was lost due to inaction.
Now, I am not saying to implement new and difficult systems for the sake of having the newest systems. This whole process of data and network security should start with an audit, followed by an evaluation of business goals and risks, and finally a review and alignment of the two. This should give you a list of deficiencies that the business determines to be actionable risks, which can then be rolled into a deployment plan. Security and data safety may involve implementing new systems that require a capital outlay for the organization, or the safety may simply be a change in business process or software and configuration changes, which has a cost in staff time or possibly consultant compensation. <Shameless plug> Remember, it is often well worth hiring a consultant, like Ed Tetz, to come to your network and implement a solution in a fraction of the time that it may take you to implement it yourself. </Shameless plug>
In this chapter, I introduce you to many of the security tools that you need to be familiar with and use to protect your network, including Authentication, Authorization, and Accounting (AAA), log collection and monitoring, secure protocols, configuration management, monitoring traffic, securing traffic with ACLs, and physical security.
Management Areas
According to Cisco, three main areas of network management play a role in your device and data security. The following are the areas of the devices that need protection through your security measures; these all relate to soft security features (as opposed to hard security features like locked doors and alarm systems) and are the
• Management plane: This is the area that is responsible for communication with the management interfaces of your devices. The management interfaces include applications and protocols, such as Secure Shell (SSH), Simple Network Management Protocol (SNMP), and Telnet.
• Control plane: This is the area that is responsible for infrastructure. The infrastructure includes applications and protocols that deal with maintaining network infrastructure between devices. Control applications and protocols include routing protocols like Enhanced Interior Gateway Routing Protocol (EIRGP), Open Shortest Path First (OSPF), and Routing Information Protocol (RIP).
• Data plane: This is the area that is directly responsible for the movement of data through the network and networking devices.
This chapter gives you guidance in how to implement security on your network, but I do not provide all the details related to implementing all these features.
Finding Out About Known Issues with Cisco Devices
The best way to find out about issues with your Cisco devices and their Internetwork Operating System (IOS) is to stay updated on Cisco advisories, which are posted to Cisco’s support website by the Product Security Incident Response Team (PSIRT). To read more about the latest advisories, visit www.cisco.com/go/psirt
.
If you do not know that you have issues with your devices, it makes it hard to keep them secured. When the advisories are posted, they detail what the issues are and the steps that need to be taken to mitigate or eliminate the risks from the issue.
Leveraging Authentication, Authorization, and Accounting
Authentication, Authorization, and Accounting (AAA) services play a critical role in securing your network resources because they offer a secure method of maintaining a central database of users and passwords. Depending on the server that you use (Remote Authentication Dial In User Service [RADIUS] or Terminal Access Controller Access-Control System [TACACS]) and the AAA servers your devices support, you cannot only authenticate users and devices, but you can also push out configuration settings to those users or devices. An example of pushing out configuration information is the association of virtual local area networks (VLANs) with users; when a user authenticates at a switch, the port they are connected to dynamically joins the VLAN that the user is supposed to be a member of. Within the Cisco ISO, AAA authentication can be used to limit the commands that are available to a user and to log the commands that a user issues.
Authentication fallback
One issue that can befall you when you implement AAA is what happens when AAA is unavailable. Your Cisco devices support a secondary authentication method for just that case arising. As secondary authentication methods, you can use the enable password, local user accounts on the device, or line authentication. In Book III, Chapter 3 and Book IV, Chapter 3, you see how to configure line passwords on the console port, AUX port, and Virtual Terminal (vty) sessions.
The preferred secondary authentication method is actually the enable password because the other types of passwords use Type 7 passwords (which I complain about shortly). The enable password can use the secret option that implements a one-way hashing algorithm, which is a more secure option. Because you need to configure the enable password, you need to protect your systems by overriding it with enable secret
. Although doing so is required only as a backdoor security option when AAA authentication is unavailable, if you are using it, you have the extra work required to support local passwords or user account on your devices.
Avoiding Type 7 passwords
Type 7 passwords were created to obscure the passwords found in the configuration files, but they were designed to support fast decryption during authentication. To support this speed, they implemented the Vigenère cipher. Unfortunately, the process for decrypting passwords are well-known; as such many tools, such as Cain & Abel, can quickly decrypt Type 7 passwords by using the toolbar tool button identified in Figure 4-1.
Figure 4-1: Using Cain & Abel to read a Type 7 password.
Even Message-Digest version 5 (MD5) and Advanced Encryption Standard (AES) hashed passwords can be cracked, but they take substantially more time because every possible password needs to be hashed and compared to the version that is hashed in the configuration files. Figure 4-2 shows Cain & Abel completing a crack on my secret password. (Keep in mind though that the password was between only five and six characters, and I gave Cain & Abel a list of the necessary letters.) If the password was between 1 and 16 characters and made up of standard letters and numbers, the brute force guessing would take upward of 9x1013 years — processing 3,000 passwords a second — on the computer that I used. Using a more powerful computer would have resulted in faster times; but really, what difference would a few thousand years make in cracking the password?
Figure 4-2: Using Cain & Abel to eventually crack an MD5 password.
To grant you a higher level of security, you can specify service password-encryption
, which encrypts future passwords in your configuration file. The service password-encryption
command is how you configure your system to use the low security Type 7 passwords. To work with the service password-encryption
command, you simply enable password encryption, and any passwords in your configuration file are encrypted (or encoded) automatically with Type 7 hashing. The service password-encryption
process is not reversed with the no service password-encryption
command because the passwords remain encrypted until you reset them. The following code shows how to set up service password-encryption
:
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1#
show running-config | include enable password
enable password enablepass
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
service password-encryption
Router1(config)#
enable password enablepass
Router1(config)#
exit
Router1#
Router1#
show running-config | include enable password
enable password 7 121C0B16100709142B3837
Router1#
show running-config
<content delete for brevity>
!
line con 0
exec-timeout 0 0
password 7 070C2E425E080A16
login
line aux 0
password 7 104F1C0115160118
login
line vty 0 4
privilege level 15
password 7 1311121E0509106A
login local
transport input telnet ssh
!
<content delete for brevity>
When dealing with usernames in your configuration file, the username secret
command may be issued in Global Configuration mode to configure your local users to have their passwords encrypted with MD5 hashing. In the following example, I created two user accounts — one with Type 7 hashing and one with MD5 hashing. Look at how they appear in the configuration file with service password-encryption
disabled initially.
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
username etetz password 0 type7pass
Router1(config)#
username etetzs secret 0 md5pass
Router1(config)#
exit
Router1#
show running-config | include etetz
username etetz password 0 type7pass
username etetzs secret 5 $1$hbNJ$QbM1G5AjnbiKVYgNFL4DN/
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
service password-encryption
Router1(config)#
exit
Router1#
show running-config | include etetz
*Apr 22 14:38:30.867: %SYS-5-CONFIG_I: Configured from console by console
username etetz password 7 02121D4B0E511F205F5D
username etetzs secret 5 $1$hbNJ$QbM1G5AjnbiKVYgNFL4DN/
Notice the difference in the preceding code example as to the appearance of the three types of passwords and how they are identified in the file, password 0
(no encrytion), password 7
(Vigenère hash), and secret 5
(MD5 hash). The encrypted passwords for the user accounts identify the hashing algorithm that was used (by the 5 or 7 preceding the password), and the passwords are displayed in encrypted text.
Centralizing Log Collection and Monitoring
George Santayana once wrote, “Those who cannot remember the past are condemned to repeat it.” This is as true today as it was over 100 years ago when he wrote it. How can you know the history of your network? By logging.
Logging allows you to see what happened to your network in the past. Regular reviewing of your logs can also identify issues before they become problems. Cisco devices, however, have limited buffer space to store logs, and when you reboot the device, you lose them.
Collecting logs in one location
The solve Cisco devices’ limited buffer space, use a Syslog server. You can find a Syslog server for Windows from Kiwi Software (now part of SolarWinds) at www.kiwisyslog.com
. You can choose from many other Syslog servers, all at different price points, ranging from free to thousands of dollars. The purpose of a Syslog server, regardless of the cost, is to collect log data from a variety of devices and consolidate it in one place where it can easily be monitored, searched, and analyzed. If you use Linux or Unix, you have a huge selection of free Syslog servers.
The Syslog server acts as a collection point for your logging activities, allowing all your network logs to be stored in one place so that you can search it easily. The Syslog server is a must for network security because without a Syslog server, your logs will remain on scattered devices and will never be reviewed or archived.
The downside is that Syslog can send a lot of small pieces of data very fast, so it uses User Datagram Protocol (UDP) and cleartext to prevent overloading the network. To prevent unauthorized users from reading those cleartext packets and to isolate your Syslog traffic, you need to use a separate management VLAN. This management VLAN should be in place already because that is where you isolate all your switch and router management traffic. Another option, in place of the management network, is to enable network layer security for all this traffic through IPSec or another type of encryption mechanism.
You can easily enable logging from the Cisco side of the equation. (The more difficult part is the configuration of the Syslog server.) Use code similar to the following example, which needs only to specify the IP address of the log server:
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
logging host 192.168.8.20
Router1(config)#
exit
Choosing a logging level
With almost all Cisco’s Enterprise-level devices are eight default logging levels that range from zero to seven. Each of these logging levels is tied to a detail in the data logging, as I specify in Table 4-1. These levels allow you to easily choose a block of data that you wish to have logged into the system logs, and then actually sends the log info via SNMP or to Syslog destinations. Take care as you increase the levels because you increase the load on your device CPU. This is especially true of level 7.
As with most things with the Cisco IOS, this is not very difficult to set up or configure. In Global Configuration mode, use two commands. logging trap
specifies which logging level should be sent to your Syslog server; logging buffered
configures the logging level that displays in the temporary buffer.
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
logging trap 6
Router1(config)#
logging buffered 6
Router1(config)#
end
Dealing with logging in the console, monitor, and buffer
Cisco makes it possible to send logging data to the console session or to the remote vty terminals that have specified that they want to see logging data by issuing the EXEC command terminal monitor
. However, if logging is also sent to the console, this command places a high load on the CPU. To control whether logging displays in the console session or the monitor sessions, use the commands no logging console
or no logging monitor
, respectively. If you want to see the log buffer, you can use the show log
command at any time while in User EXEC mode or Privileged EXEC mode.
When logging to any display, such as the console or monitor sessions, you have overhead on your Cisco device. Console logging causes overhead even if you view the console at the time but disconnect with the console left open. The recommendation is to log data only to the buffer. You can configure the buffer with the size of the buffer with the logging buffered
command. The buffer size varies with your device, but in the following example, the size is set to 32KB and with logging at level 6, or the information level:
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
logging buffered 32768 6
Router1(config)#
end
When collecting logging data in a Syslog server, the device’s interface IP address is used — and included in the data — to send logging data to the server. When the IP address changes, it can cause a lot of confusion when reviewing the logs. To keep consistency in your logs, you can configure the loopback interface with an address and then configure that interface address to be used as the logging source interface. Here is the command to configure logging to use the loopback interface address:
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
logging source-interface Loopback 0
Router1(config)#
end
When reviewing your logs and piecing together a timeline for a major network issue, your times and time reference need to all make sense. Network Time Protocol (NTP) servers for centralized time management helps keep times synchronized, and placing a time level attached to your log entries helps as well. The following command configures your logging to include date and time, down to milliseconds, and includes the time zone:
service timestamps log datetime msec show-timezone
By default, the system clock is configured for Coordinated Universal Time (UTC). However, if you prefer to use a local time zone for your devices (say, to avoid the question, “Why was that going on at that time of night?”), try using this set of commands:
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
clock timezone AST -4
Router1(config)#
service timestamps log datetime msec localtime show-timezone
Router1(config)#
end
Implementing Secure Protocols
Use secured protocols wherever they make enough sense to implement. By default and historically, many unsecured protocols have been implemented to support your Cisco devices. This is not Cisco’s fault — when Cisco implemented the protocols, no secured options were available. Over the years, as newer secured options became available, many people did not adopt them because they were comfortable with what they knew. I still have to work hard to convince some clients that SSH is not really any more complicated or difficult to implement than Telnet is.
The following table gives common unsecured protocols and the better, more secure protocol choices.
Managing Configurations
How do you manage configuration of your devices? Do you just read about the change, connect to the device, type in the change, use the write memory
command, and exit? If so, I have bad news for you; this is not the way you should do manage configuration.
The concept of change management needs to be followed rigorously for very important devices. Cisco IOS devices allow you to store configurations in text files and then apply them a section at a time. Ideally, you have a duplicate of important equipment in a networking lab, but that is a luxury few people can afford. Lacking a lab, pre-record the configuration changes you will make, including a back-out plan, such as scheduling a reboot to roll back configuration changes. If possible, have some sort of review and approval process to better track configuration changes. If your organization is large enough to have different groups within the IT department, that review and approval process needs to include people from the other IT groups, such as desktop support, because the changes you make on the network may impact user connectivity to network devices. Having the other groups aware of what is going on allows them to respond better to issues that arise as a result of the networking changes.
Simple change management processes are easy to set up. The key components of any change management system revolve around documentation, recovery processes, and communication. These key elements can typically be implemented with a few small changes in your processes.
Password management
I discuss two key features when dealing with passwords and users within your Cisco devices. If you are using local accounts, you can enable two features for password management:
• Password Retry Lockout
• Service Password Recovery
Password Retry Lockout
When users attempt to authenticate, there is no limit to how long they can try incorrectly. If you want to put a limit on the system, you need to enable a failed login lockout system. This system is built into the current Cisco IOS.
A failed login lockout is important because any users that have been granted privilege level 15 (the highest set of security rights) are not typically locked out. After enabling this feature, even these privileged user accounts are locked out if they exceed their login attempts. The number of privileged users you have should always be kept to a minimum. After locked out, these accounts are locked until you manually unlock them. To enable this, you simply need to change the AAA authentication process to use the new version AAA authentication (which supports account lockout) that Cisco cleverly calls new-model
. Do not worry, even though you change AAA authentication process, you can still specify that users will be authenticated locally and not via the AAA server, as I have in the following set of commands:
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
aaa new-model
Router1(config)#
aaa local authentication attempts max-fail 5
Router1(config)#
aaa authentication login default local
Router1(config)#
end
If an account is locked out, you can use the following command in Privileged EXEC mode to unlock an account, as in the following example. This command can apply a specific user or all
.
clear aaa local user lockout username etetz
The counter is never reset, so if you have several failed logins over a few days, reset the counter with a command specifying all accounts, or just yours. Here is the command to issue in Privileged EXEC mode:
clear aaa local user fail-attempts username etetz
Service Password Recovery
The current Cisco IOS supports a fairly new command: service password-recovery
, or perhaps more specifically, no service password-recovery
. This is a Global Configuration mode command that modifies the behavior of your password recovery process.
Anyone with console access and the ability to reboot the Cisco device can set her own enable or secret password on the device. (I cover this process in Book I, Chapter 5.) Recovery is more about being able to recover a device that has a password you have forgotten or lost by setting a new password, rather than actually recovering the password. This poses a bit of a security risk, especially because you may not notice the password has been changed. You may notice the reboots of the device, but that is all.
By adding the no service password-recovery
to your configuration, the password recovery process does not allow you to recover the password without erasing the entire configuration. If your device configuration is erased, someone has likely been messing around with your equipment. The other advantage of no service password-recovery
is that it offers you the advantage of not having your configuration fall into the wrong hands for devices you have removed from the network and prevents the password from being reset for devices that are still on the network. When the device is recovered, with the configuration lost, you know something is up with the device.
Here is the code example to enable this feature on your Cisco device:
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
no service password-recovery
Router1(config)#
end
Managing services
Many services run in the background on Cisco devices. These services are often unused for your network, but unfortunately leave holes in your system that allow attackers to gain access to it. If you are not using these services, consider disabling them on your devices.
The following small services can easily be disabled with a pair of commands, no service tcp-small-servers
and no service udp-small-servers
:
• echo
(port number 7)
• discard
(port number 9)
• daytime
(port number 13)
• chargen
(port number 19)
In addition, the following list of commands disables other common services that you likely do not need to have running on your system. Most of these commands are issued in Global Configuration mode:
• no ip finger
• no ip bootp server
• no ip dhcp boot ignore
• no service dhcp
• no mop enabled
• no ip domain-lookup
• no service pad
• no ip http server
• no ip http secure-server
• no service config
• no cdp enable
• no cdp run
• no lldp transmit
• no lldp receive
• no lldp run global
Setting up timeouts
Without setting up timeout settings for Privileged EXEC Mode, your sessions stay open indefinitely. This is especially true of the console port. I have plugged in to console ports of clients’ devices, only to find out that I am in Privileged EXEC mode or Global Configuration mode from their last session, which may have been months ago. Because they did not log out and I had access to the console port, I had no problem getting elevated permissions.
To avoid this potentially dangerous situation, you need only type a command in each of your configuration line interfaces. The command’s format is exec-timeout
<minutes> [seconds]
. The default setting disables sessions after ten minutes; exec-timeout 0
disables the timeout altogether.
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
line con 0
Router1(config)#
exec-timeout 5
Router1(config)#
line vty 0 4
Router1(config)#
exec-timeout 5
Router1(config)#
end
In addition to setting a timeout on these settings, you can force vty sessions to be encrypted via SSH. This is easy to implement with the following code example:
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
line vty 0 4
Router1(config)#
transport input ssh
Router1(config)#
end
However, if you do not need to have remote terminal access to these devices, the better option is transport input none
, which disables all vty access. In addition to this inbound access, you can create management SSH sessions from one device to another. So by connecting to one device, you can then launch a connection from that device to connect to another device. Limiting this connection may be accomplished with transport output ssh
, which limits you to an outgoing SSH session, whereas transport output none
can prevent all outbound connections.
Keeping alive TCP
Transmission Control Protocol (TCP) sessions eventually timeout, whereas the TCP keepalive
command sends periodic packets to keep these sessions alive and available. Another benefit of this command is that half-opened or orphaned connections are also dropped.
The TCP sessions that are monitored can be inbound or outbound. You can specify which direction you want these keepalive
commands to operate. The following set of commands run them in both directions:
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
service tcp-keepalive-in
Router1(config)#
service tcp-keepalive-out
Router1(config)#
end
Leaving room for management
With recent versions of the Cisco IOS, you can reserve memory space for access to the console. When your device is under attack, the typical attack profile attempts to overflow the available memory on the device to exploit weaknesses. The side effect of this is that when you attempt to connect to the console to see what is happening to the device, you find that you cannot get access because there is no memory for even the console session to operate.
Cisco provides a method to reserve a block of memory for the console. This means that when you need to launch the console session, memory is always available. In this example, I reserve 4MB of space for the console session:
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
memory reserve console 4096
Router1(config)#
end
Securing SNMP
Simple Network Management Protocol (SNMP) is one of the small IP-based services that runs on your Cisco devices. If you use SNMP on your network, you can increase your security by using strong community names (which are like passwords) or by disabling the services if you are not using them. In the following example, I set the community names to understandable names; however, in production, community names are treated like strong alphanumeric passwords.
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
snmp-server community READONLYPW RO
Router1(config)#
snmp-server community READWRITEPW RW
Router1(config)#
end
To then properly secure this traffic further, you can implement an ACL such as the following two ACLs, which restrict access to the ReadOnly connections to one segment of the network (192.168.8.0/24) and access to the ReadWrite connections to a single host (192.168.8.10).
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
access-list 90 permit 192.168.8.0 0.0.0.255
Router1(config)#
access-list 91 permit 192.168.8.10
Router1(config)#
Router1(config)#
snmp-server community READONLY RO 90
Router1(config)#
snmp-server community READWRITE RW 91
Router1(config)#
end
Replacing and rolling back
Current Cisco IOS versions allow you a few new commands to manage your configuration backups and archiving. Backup and archiving give you an easier recovery process for configuration errors. Remember, a good configuration management process (such as the IT Infrastructure Library (ITIL) configuration) helps, but backup and archiving are tools to help you as well.
If you have archived a configuration, you can replace the current running configuration with an archived copy manually or automatically. The manual process makes use of the configure replace
command issued in Privileged EXEC mode. This command replaces the running configuration with the contents of the file. If you use the command copy
<filename>
running-config
, you actually merge the two files.
To enable the archiving feature, which is strongly recommended by Cisco for all supported devices, you need only issue five easy commands. The following command set saves the archives to the specified path, automatically creates a new archive every 1,440 minutes (once a day), saves the last 14 files, and takes an extra archive when you issue the write memory
command:
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
archive
Router1(config-archive)#
path flash:archived-config
Router1(config-archive)#
maximum 14
Router1(config-archive)#
time-period 1440
Router1(config-archive)#
write-memory
Router1(config-archive)#
end
After the archiving system is configured, you can force an archive to be generated with archive config
command and see the list of archives using the show archive
command. Both of these commands are executed in Privileged EXEC mode. Here is what the commands looks like:
Router1#archive config
Router1#show archive
There are currently 5 archive configurations saved.
The next archive file will be named flash:archived-config-5
Archive # Name
0
1 flash:archived-config-1
2 flash:archived-config-2
3 flash:archived-config-3
4 flash:archived-config-4 <- Most Recent
5
6
7
8
9
10
11
12
13
14
Taking the talking stick with terminal lock
In larger IT shops, having several people who make configuration changes on your network devices is common. One thing that can happen is that they start tripping over each other in making the changes. Nothing can be more annoying than starting to make a configuration change that someone else is in middle of making. This can lead to a lot of confusion, and worse, corrupt the configuration. To avoid this problem, Cisco provides an exclusive editing option so that only one user or session can make configuration changes on a device at a time, by implementing configuration mode exclusive
.
The configuration mode exclusive
system operates in either Manual or Automatic mode. In Automatic mode, exclusive access is granted automatically to the first user who enters Configuration mode using the configure terminal
command. In Manual mode, the user needs to issue the command configure terminal lock
. To enable Automatic mode, use these commands:
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
configuration mode exclusive auto
Router1(config)#
end
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
*Apr 22 19:31:44.825: Configuration mode locked exclusively. The lock will be cleared once you exit out of configuration mode using end/exit
Router1(config)#
exit
Router1#
*Apr 22 19:32:09.617: %SYS-5-CONFIG_I: Configured from console by console
In the following code, notice that after enabling the Manual mode, you can still enter Configuration mode without engaging the lock. Enable the Manual mode as follows:
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
configuration mode exclusive manual
Router1(config)#
end
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1 (config)#
hostname NewRouter1
NewRouter1(config)#
exit
NewRouter1#
*Jun 24 20:20:44.079: %SYS-5-CONFIG_I: Configured from console by console
NewRouter1#
configure terminal lock
Enter configuration commands, one per line. End with CNTL/Z.
NewRouter1(config)#
*Jun 24 20:21:04.051: Configuration mode locked exclusively. The lock will be cleared once you exit out of configuration mode using end/exit
NewRouter1(config)#
hostname Router1
Router1(config)#
exit
Router1#
*Jun 24 20:21:31.567: %SYS-5-CONFIG_I: Configured from console by console
Using logs to tell you what is going on
Cisco allows newer IOS versions to log configuration changes that have been made on your Cisco devices. Many of the configuration management changes that have been incorporated into the IOS make it easier for IT departments to be ITIL-oriented and compliant. ITIL places a heavy focus on configuration management and change management on all your IT resources.
The hidekeys
and logging size
commands can improve the default settings by removing password data from the logs and increasing the size of the change log. Additionally, you can have this change information sent to your Syslog server. Doing so is all recommended by Cisco as part of configuration management.
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
archive
Router1(config-archive)#
log config
Router1(config-archive-log-cfg)#
logging enable
Router1(config-archive-log-cfg)#
logging size 200
Router1(config-archive-log-cfg)#
hidekeys
Router1(config-archive-log-cfg)#
notify syslog
Router1(config-archive)#
end
To view your current configuration for logging, use the following command in Privileged EXEC mode:
Router1#show archive log config all
idx sess user@line Logged command
1 1 console@console | logging enable
2 1 console@console | configure terminal
3 1 console@console | archive
4 1 console@console | log config
5 1 console@console | logging enable
6 1 console@console | logging size 200
7 1 console@console | hidekeys
8 1 console@console | notify syslog
Managing network features
Many default network features are not typically necessary and can be exploited by unnamed people who attack your network. Here are some commands you need to consider running to secure your devices:
• Router1(config)#no ip source-routing
• Router1(config-if)#no ip redirects
• Router1(config)#ip dhcp snooping
• Router1(config)#ip dhcp snooping vlan
<vlan-range>
• Router1(config-if)#ip verify source
In addition to these useful commands, consider enabling some of the port security features available on your Cisco devices. These are particularly good for your switches to prevent users from doing things they should not be doing.
Port security
Port security allows you to enable several security options related to the ports on your switch. This includes settings like the number of devices that are connected to each switch port, which can prevent users from connecting unauthorized network switches or access points. The following code example performs several actions, which include:
• Configuring ports for connecting to access devices rather than switches
• Having the device remember devices connected by a Media Access Control (MAC) address
• Setting a maximum number of possible devices
• Setting an action for violation of the restrictions, such as protect, restrict, shutdown, and shutdown VLAN
Switch1#
enable
Password:
Switch1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#
interface fastEthernet 0/1
Switch1(config-if)#
switchport
Switch1(config-if)#
switchport mode access
Switch1(config-if)#
switchport port-security
Switch1(config-if)#
switchport port-security mac-address sticky
Switch1(config-if)#
switchport port-security maximum 2
Switch1(config-if)#
switchport port-security violation shutdown
Switch1(config-if)#
end
When the port has been shutdown or disabled, you can re-enable the port or interface by issuing the shutdown
and no shutdown
commands in succession.
Anti-spoofing ACLs
Some attempted break-ins to your network are done by spoofing an IP address so that the attacker attempts to make his own outside address look like an address in your network. To deal with this issue, you can configure your router to drop or discard packets that come in from outside interfaces with purported internal addresses. This can be done with the following commands in which the external interface of the router is FastEthernet0/1
, and the internal addresses encompass the 192.168.0.0/24 and 10.0.0.0/8 networks.
Router1#
enable
Password:
Router1#
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#
ip access-list extended ACL-ANTISPOOF-IN
Router1(config-ext-nacl)#
deny ip 10.0.0.0 0.255.255.255 any
Router1(config-ext-nacl)#
deny ip 192.168.0.0 0.0.255.255 any
Router1(config-ext-nacl)#
exit
Router1(config)#
interface fastEthernet0/1
Router1(config-if)#
ip access-group ACL-ANTISPOOF-IN in
Router1(config-if)#
end
Getting Physical with Security
Obvious, but often disregarded, advice is to always secure the physical access to your network infrastructure. There are uncounted methods of disrupting your network if an attacker gains physical access to your switches and routers. Many companies either do not realize their risk or choose to ignore it by inadequate physical security.
Physical security need not be complex: Simply installing locks on doors is the key to physical security. An inexpensive lock from the hardware store is an easy start to this security process. Figure 4-3 shows a more complex (and more secure) lock that uses proximity cards.
As your security needs increase, systems, such as the one shown in Figure 4-3, allow you to control access to all areas of your building and offer logging of who opens which doors and when.
Figure 4-3: A standard proximity card and card reader.