This chapter includes the following topics:
Cisco IOS Software security and configuration
Catalyst 3550 security and configuration
Routers and Catalyst 3550 series switches are the predominant hardware components used in the CCIE Security lab exam. This chapter covers some of the basic security features that are available in Cisco IOS Software for routers and 3550 switches. The chapter is divided into two major parts:
Cisco IOS Software security
Catalyst 3550 security
The first part deals with the introduction and configuration of some of the basic router security features. The second part discusses configuration of basic security features on the 3550 switches. Although many more basic security features are available for routers and switches than those included in this chapter, here you concentrate on those features that are most likely to appear on the CCIE Security exam.
Cisco IOS Software Security
Routers are an important part of any network, and successful implementation of Cisco IOS Software security features increases router efficiency and, by association, the efficiency of the entire network. Cisco IOS Software includes a number of useful services. Unfortunately, many of them present a security concern. In this chapter, you find a short explanation of some of these services, their functionality, and how they can be misused by an attacker. Then you learn how to use the various Cisco IOS Software basic mechanisms that are designed to protect information.
Network Time Protocol Security
Network Time Protocol (NTP) is used for automatic time synchronization. Cisco networks use NTP to make timekeeping accurate and coordinated across the board. The use of NTP is highly recommended for security because having accurate time is important for intrusion and forensic analysis. NTP is typically deployed in a hierarchical fashion. All routers on the network should be made a part of the hierarchy, if possible. If an NTP hierarchy is not feasible, you should disable NTP. To prevent NTP from traversing the router altogether, apply an access list to an appropriate interface.
HTTP Server Security
To enable configuration and management of network devices remotely, Cisco IOS Software offers web-based Hypertext Transfer Protocol (HTTP) administration. Though the web-access features are quite common on Cisco routers, they facilitate not only a mechanism for monitoring and configuring but also for attacking a router. The HTTP traffic needs to be protected by securing the communication between the HTTP client and the HTTP server. Several security technologies are available for this task (HTTPS, SSL, SSH, and IPSec) which are discussed throughout this book. Of course, if web-based remote administration is not necessary, you should disable this feature.
Password Management
To control who can access the router command prompt, you can set various passwords for various access points to the router. You can configure the passwords for local console access or remote access via Telnet. This is done to prevent unauthorized changes to a router's behavior and also to protect information that can be learned by looking at the network statistics on a router. This chapter's password discussion concentrates on three types of passwords:
Enable password
Per-user passwords and privilege levels
Line passwords
Enable Password
Enable password secures the privileged EXEC mode of a router. At this level, an administrator can view and change anything on the router. That is why such access needs to be closely guarded.
Privilege Levels
Additional controls are available in Cisco IOS Software to limit administrative access with various privilege levels. You can define different privilege levels for different passwords that permit a certain subset of commands to be configured by a user. Once the password is entered, the user is able to operate at the corresponding level. Cisco IOS Software supports a total of 16 privilege levels, ranging from 0 to 15. The default levels are 1 and 15. Level 1 is basic (or nonprivileged), and 15 is the privileged EXEC mode that was discussed in the preceding section.
Line Passwords
For remote administration, you can access Cisco routers via Telnet. Telnet occurs over virtual terminal lines (vty). Most Cisco IOS Software versions have five virtual terminals—0 through 4—that support five simultaneous Telnet sessions. You should explicitly configure all the virtual terminals for security purposes. No password is configured on vty ports by default to deny all attempts to log in to a router remotely.
Access Lists
Cisco IOS Software uses access lists, also known as Access Control Lists (ACLs), as security filters to permit or deny specific traffic from entering or exiting parts of the network. Access lists are used heavily on Cisco routers for restricting access to a router's services and for filtering traffic passing through the router. The router looks at each packet and determines whether to forward or drop the packet, based on the conditions that are specified in the access lists.
Access lists can include the source and destination addresses of the traffic, the protocol type, and so on. Access lists contain a list of statements that are arranged in sequential order that establishes the matching criteria. Each packet is checked against the list in the same order that the statements are positioned. When a match is found, the router processes the packet accordingly and does not go through the remainder of the statements. Therefore, you need to call out specific conditions before the more general ones. For more on access lists, refer to Chapter 16, "Access Control Lists."
Secure Shell
Secure Shell (SSH) service is a newer Cisco IOS Software feature that is intended for use in secure remote administration. To create a secure link between a client and a server, SSH uses Rivest, Shamir, and Adelman (RSA) public key cryptography. Therefore, the communication between the administrator's host and the router is encrypted. SSH is also used to prevent various kinds of network attacks. Currently, Cisco implements only version 1 of SSH, but remember to check for future updates.
NOTE
The SSH client has been available since the Cisco IOS Software 12.1.3.T release.
Basic IOS Security Configuration
The following lessons and case studies are dedicated to basic Cisco IOS Software security configuration methods and are grouped into several scenarios, variations of which you are likely to encounter in the CCIE Security lab exam or in real life.
Lesson 15-1: Configuring Passwords, Privileges, and Logins
In this lesson, R8 is the router that needs to have basic Cisco IOS Software security features configured. Once R8 is configured, a remote host attempts to log in and perform some tasks.
This lesson covers the following configuration steps:
Step 1 Setting passwords
Step 2 Limiting connection time
Step 3 Configuring vtys and accessing the network
remotely
Step 4 Creating user accounts
Step 5 Assigning privileges
Step 6 Local authentication, authorization, and
accounting
Step 7 Remote administration with FTP
Step 8 Hiding Telnet addresses
Step 9 Verification
Step 1: Setting Passwords
First, you have to protect access to a router by setting various passwords. Prevent unauthorized login by configuring passwords on the console and virtual terminal lines. The syntax for both of them is identical, as follows:
R8(config-line)#password string
After the line passwords are set, you need to take care of the privileged EXEC level. You should not use the enable password command because it is not secure and can give away a system password. Instead, opt for the following command:
R8(config)#enable secret string
The enable secret command, as well as the username passwords described in "Creating User Accounts," later in this lesson, can be up to 25 characters long, including spaces, and are case sensitive. Example 15-1 demonstrates the application of passwords on R8. Note that both the console and the vty passwords appear scrambled. This is because service password-encryption is enabled on the router to hide the real string from a passerby.
Example 15-1 Password Application on a Router
R8#show run version 12.2 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname R8 ! enable secret 5 $1$uKVI$j1Y9WEzw7YIAWSkFwZZZB. ! line vty 0 4 password 7 1511021F0725 ! line con 0 password 7 060506324F41
Step 2: Limiting Connection Time
For security reasons, you do not want to leave the connection to any port, be it console or remote connection, logged in indefinitely. If the connections are configured to time out automatically, the administrator is logged out by a router after a specified period if he forgets to do it himself. The syntax is the same for any line and is as follows:
R8(config-line)#exec-timeout minutes seconds
In Example 15-2, the console and auxiliary (aux) port are both configured to time out after a 5-minute interval.
Example 15-2 Configuring a Timeout Period
R8#show run ! ! Output omitted for brevity ! line con 0 exec-timeout 5 0 password 7 05080F1C2243185E4B52 line aux 0 transport input all exec-timeout 5 0
NOTE
When you are in a lab-testing environment, a constant timeout can turn into a nuisance. If security is not an immediate concern, you can choose to set the timeout interval to infinity by using the exec-timeout 0 0 command. However, you should never do so in real-world networking.
Step 3: Configuring vtys and Accessing the Network Remotely
As you know, vtys are used for remote network connections to the router. Generally, all the router's vtys have the same configuration. If there are extra vtys that are not used, it is a good practice to disable them with the no line vty command.
Applying an access list to vtys can effectively limit access to the router by specifying which connections are allowed. The command for assigning an access list to vtys is as follows:
R8(config-line)#access-class access-list in
Some of the protocols supported by the vtys (for example, rlogin and web) are not secure. To minimize the security risk, you can confine the acceptable type of connection to Telnet only with the following command:
R8(config-line)#transport input [telnet]
Example 15-3 shows IP access-list 5, which permits host 192.168.1.8. Applying access-list 5 to vty lines for inbound connections means that only one particular host can Telnet to R8.
Example 15-3 The vty Configuration
R8#show run ! ! Output omitted for brevity ! access-list 5 permit 192.168.1.8 ! line vty 0 4 access-class 5 in exec-timeout 5 0 password 7 01302F377824 transport input telnet
NOTE
While configuring these commands, make sure that you are connected via an aux or console port. If you perform the commands while logged in to the router via Telnet, you might inadvertently disconnect yourself.
Step 4: Creating User Accounts
In this scenario, administrators log in according to the local router database. Each administrator receives his own username, password, and privilege level assigned, which indicates the level of control an administrator has over the router. The following command places a user in a local database:
R8(config)#username name privilege level password string
In Example 15-4, five administrators are assigned to the database. When they attempt to log in, they are authenticated by their username and corresponding password and are authorized to operate on the prescribed level.
Example 15-4 Creating a Local Database
R8#show run ! ! Output omitted for brevity ! hostname R8 ! username admin privilege 3 password 7 02100A175809 username Sam privilege 15 password 7 05080F1C2243 username Jessie privilege 15 password 7 13061E010803 username Terry privilege 15 password 7 030752180500 username Joe privilege 5 password 7 01100F175804
Step 5: Assigning Privileges
Now that you have specified privilege levels for your users, you can assign a set of commands to a privilege level. Every user at the same privilege level can execute the same set. By default, every command in the Cisco IOS Software is designated for either level 1 or level 15. Level 0 exists, but it is rarely used. It includes following five commands:
- disable
- enable
- exit
- help
- logout
To change the default level and sign up certain commands to another level, use the following command:
R8(config)#privilege exec level level available-command
Keep in mind that for security reasons, you should move some commands that allow too much freedom for a lower level to a higher level, not the other way around. If you move higher-level commands, such as the configure command, down, you might enable a user to make unauthorized changes by letting him modify his own level to a higher one. Example 15-5 shows how privilege level 3 is limited to three commands:
- telnet
- show ip route
- show startup
Example 15-5 Designating a Privilege Level
R8(config)#privilege exec level 3 <Anchor0>show start R8(config)#privilege exec level 3 show ip route R8(config)#privilege exec level 3 telnet
Step 6: Local Authentication, Authorization, and Accounting (AAA)
AAA technology is discussed in detail in Chapter 18, "AAA Services." Here, you are shown just a few AAA commands that make use of the local database that is configured in Steps 4 and 5 of this lesson. AAA has the following three separate functions:
Authentication—Authentication identifies users before admitting them into a network.
Authorization—Once a user is authenticated, authorization dictates what a user can accomplish on the network.
Accounting—Accounting tracks the user's actions and logs them to monitor resource usage.
Example 15-6 illustrates the AAA commands configured on R8. To start an AAA process, the aaa new-model command is defined. The next command, aaa authentication login default local, names a local database as the one that is used for authentication on R8. The aaa authorization config-commands command enables AAA authorization of configuration commands specified by the aaa authorization commands statement that follows. The aaa authorization exec default local command specifies the local database as the source of authorization information, and the aaa authorization commands 3 default local if-authenticated command means that provided the user has been authenticated successfully, he is authorized by the router, after looking up the local database, to use the specified privilege level 3 commands. The latter command is helpful in the debugging process. Its practical usage is discussed in "Verification," later in this lesson.
Example 15-6 AAA Configuration
R8#show run ! ! Output omitted for brevity ! hostname R8 ! aaa new-model aaa authentication login default local aaa authorization config-commands aaa authorization exec default local aaa authorization commands 3 default local if-authenticated ! username admin privilege 3 password 7 02100A175809
NOTE
User admin is authorized to operate at privilege level 3 only if the user accesses the router via vty. If the same user attempted to access R8 via console, the user would receive privilege level 15.
Step 7: Remote Administration with FTP
You can use File Transfer Protocol (FTP) to transfer configuration files to and from the router for remote administration. FTP is preferred because Trivial File Transfer Protocol (TFTP) does not support authentication and is, therefore, less secure and should not be used to transfer configuration files. The following commands are used to make the router FTP ready:
R8(config)#ip ftp source-interface interface-type number R8(config)#ip ftp username name R8(config)#ip ftp password string
The first command specifies the local interface that is set up for the FTP connection. The two subsequent commands create the username and password for authentication on the FTP server. Example 15-7 shows the FTP configuration on R8.
Example 15-7 Configuring FTP
R8#show run ! ! Output omitted for brevity ! ip ftp source-interface FastEthernet0/0 ip ftp username anonymous ip ftp password 7 1511021F0725
Step 8: Hiding Telnet Addresses
Normally, when you try to Telnet to a device, the router displays the address to which the connection is attempted along with other connection messages. This allows an unauthorized passerby to see it. To suppress the Telnet address, issue the following command:
R8(config)#service hide-telnet-address
Step 9: Verification
Example 15-8 demonstrates the output of the debug aaa authentication command followed by the debug aaa authorization command. The combination of these two commands shows the process a router goes through while authenticating and authorizing a user admin logging in from the remote host 192.168.1.6, permitted by access-list 5.
Example 15-8 Debugging AAA
R8#debug aaa authentication R8#debug aaa authorization Feb 28 17:48:46: AAA: parse name=tty66 idb type=-1 tty=-1 Feb 28 17:48:46: AAA: name=tty66 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=66 channel=0 Feb 28 17:48:46: AAA/MEMORY: create_user (0x8270E0D0) user='NULL' ruser='NULL' ds0=0 port='tty66'
rem_addr='130.100.26.2' authen_type=ASCII service=LOGIN priv=15 initial_task_id='0' Feb 28 17:48:46: AAA/AUTHEN/START (1304267484): port='tty66' list='' action=LOGIN service=LOGIN Feb 28 17:48:46: AAA/AUTHEN/START (1304267484): using "default" list Feb 28 17:48:46: AAA/AUTHEN/START (1304267484): Method=LOCAL Feb 28 17:48:46: AAA/AUTHEN (1304267484): status = GETUSER Feb 28 17:48:48: AAA/AUTHEN/CONT (1304267484): continue_login (user='(undef)') Feb 28 17:48:48: AAA/AUTHEN (1304267484): status = GETUSER Feb 28 17:48:48: AAA/AUTHEN/CONT (1304267484): Method=LOCAL Feb 28 17:48:48: AAA/AUTHEN (1304267484): status = GETPASS Feb 28 17:48:49: AAA/AUTHEN/CONT (1304267484): continue_login (user='admin') Feb 28 17:48:49: AAA/AUTHEN (1304267484): status = GETPASS Feb 28 17:48:49: AAA/AUTHEN/CONT (1304267484): Method=LOCAL Feb 28 17:48:49: AAA/AUTHEN (1304267484): status = PASS Feb 28 17:48:49: tty66 AAA/AUTHOR/EXEC (1491533337): Port='tty66' list='' service=EXEC Feb 28 17:48:49: AAA/AUTHOR/EXEC: tty66 (1491533337) user='admin' Feb 28 17:48:49: tty66 AAA/AUTHOR/EXEC (1491533337): send AV service=shell Feb 28 17:48:49: tty66 AAA/AUTHOR/EXEC (1491533337): send AV cmd* Feb 28 17:48:49: tty66 AAA/AUTHOR/EXEC (1491533337): found list "default" Feb 28 17:48:49: tty66 AAA/AUTHOR/EXEC (1491533337): Method=LOCAL Feb 28 17:48:49: AAA/AUTHOR (1491533337): Post authorization status = PASS_ADD Feb 28 17:48:49: AAA/AUTHOR/EXEC: Processing AV service=shell Feb 28 17:48:49: AAA/AUTHOR/EXEC: Processing AV cmd* Feb 28 17:48:49: AAA/AUTHOR/EXEC: Processing AV priv-lvl=3 Feb 28 17:48:49: AAA/AUTHOR/EXEC: Authorization successful
Note that the aaa authorization config-commands commands and aaa authorization commands 3 default local if-authenticated commands of this scenario's AAA configuration were not yet set at the time the debug commands from Example 15-8 were issued. This resulted in the debug output not displaying the user's activity after the user has been authorized.
Example 15-9 shows the debug command output after aaa authorization config-commands commands and aaa authorization commands 3 default local if-authenticated commands have been applied. You can see that the user has issued the show startup-config command authorized for their privilege level.
Example 15-9 Debugging AAA after the authorization config-commands Commands
R8#show debug General OS: AAA Authentication debugging is on AAA Authorization debugging is on Sep 28 17:40:45: AAA/AUTHEN (1358087791): status = GETUSER Sep 28 17:40:45: AAA/AUTHEN/CONT (1358087791): Method=LOCAL Sep 28 17:40:45: AAA/AUTHEN (1358087791): status = GETPASS Sep 28 17:40:47: AAA/AUTHEN/CONT (1358087791): continue_login (user='admin') Sep 28 17:40:47: AAA/AUTHEN (1358087791): status = GETPASS Sep 28 17:40:47: AAA/AUTHEN/CONT (1358087791): Method=LOCAL
Sep 28 17:40:47: AAA/AUTHEN (1358087791): status = PASS Sep 28 17:40:47: tty66 AAA/AUTHOR/EXEC (1731500233): Port='tty66' list='' service=EXEC Sep 28 17:40:47: AAA/AUTHOR/EXEC: tty66 (1731500233) user='admin'
Sep 28 17:40:47: tty66 AAA/AUTHOR/EXEC (1731500233): send AV service=shell Sep 28 17:40:47: tty66 AAA/AUTHOR/EXEC (1731500233): send AV cmd* Sep 28 17:40:47: tty66 AAA/AUTHOR/EXEC (1731500233): found list "default" Sep 28 17:40:47: tty66 AAA/AUTHOR/EXEC (1731500233): Method=LOCAL Sep 28 17:40:47: AAA/AUTHOR (1731500233): Post authorization status = PASS_ADD Sep 28 17:40:47: AAA/AUTHOR/EXEC: Processing AV service=shell Sep 28 17:40:47: AAA/AUTHOR/EXEC: Processing AV cmd* Sep 28 17:40:47: AAA/AUTHOR/EXEC: Processing AV priv-lvl=3 Sep 28 17:40:47: AAA/AUTHOR/EXEC: Authorization successful Sep 28 17:40:55: tty66 AAA/AUTHOR/CMD (1039984762): Port='tty66' list='' service=CMD Sep 28 17:40:55: AAA/AUTHOR/CMD: tty66 (1039984762) user='admin' Sep 28 17:40:55: tty66 AAA/AUTHOR/CMD (1039984762): send AV service=shell Sep 28 17:40:55: tty66 AAA/AUTHOR/CMD (1039984762): send AV cmd=show Sep 28 17:40:55: tty66 AAA/AUTHOR/CMD (1039984762): send AV cmd-arg=startup-config Sep 28 17:40:55: tty66 AAA/AUTHOR/CMD (1039984762): send AV cmd-arg=<cr> Sep 28 17:40:55: tty66 AAA/AUTHOR/CMD (1039984762): found list "default" Sep 28 17:40:55: tty66 AAA/AUTHOR/CMD (1039984762): Method=LOCAL Sep 28 17:40:55: AAA/AUTHOR (1039984762): Post authorization status = PASS_ADD
Lesson 15-2: Disabling Services
Many services are offered by Cisco IOS Software. Although each service carries a useful function, it could present a potential security risk. When services are not used, you need to disable them. Otherwise, they open a security hole for an attacker to manipulate. This lesson is devoted to disabling unnecessary services on R8. Keep in mind that different Cisco IOS Software releases maintain different services on or off by default. If a service is off by default, disabling it does not appear in the running configuration. It is best, however, not to make any assumptions and to explicitly disable all unneeded services, even if you think they are already disabled.
The services covered in this lesson are as follows:
- Router name and DNS name resolution
- Cisco Discovery Protocol (CDP)
- TCP and UDP small servers
- Finger server
- NTP service
- BOOTP server
- Configuration auto-loading
- Proxy ARP
- IP source routing
- IP directed broadcast
- IP unreachables, redirects, and mask replies
Router Name and DNS Name Resolution
If no Domain Name System (DNS) server is specifically mentioned in the router configuration, by default all the name queries are sent to the broadcast address of 255.255.255.255. To alter the default behavior and turn off the automatic lookup, use the following command:
R8(config)#no ip domain-lookup
Cisco Discovery Protocol
The Cisco Discovery Protocol (CDP) is a proprietary protocol that Cisco devices use to identify their directly connected neighbors. CDP is not frequently used and, like any other unnecessary local service, is considered potentially harmful to security. You can use the following commands to turn off CDP—globally and per interface:
R8(config)#no cdp run R8(config-if)#no cdp enable
Disabling CDP per interface is a nice feature because it allows you to still run CDP for the parts of the network that need it.
TCP and UDP Small Servers
Another two services that you should also turn off are the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) small servers. They are included in the list of standard TCP and UDP services that hosts should provide but are seldom needed. Use the following commands to disable TCP and UDP small servers:
R8(config)#no service tcp-small-servers
R8(config)#no service udp-small-servers
Finger Server
Next, you need to make sure that the Cisco IOS Software support for the UNIX finger protocol is disabled. Having the finger service enabled allows a user to view other active users. There are many known ways that the service can be misused and the information can fall into the wrong hands. To keep your network security in full force, you should consider turning off the finger service. After all, those who are not authorized to log in to the router have no business looking up those who do. Use the following command to disable the finger service:
R8(config)#no ip finger
NTP Service
If NTP, described earlier in "Network Time Protocol Security," is not used in the network, disable it with the following interface command:
R8(config-if)#ntp disable
BOOTP Server
In theory, BOOTP service might sound like a good idea. It is meant for use in networks where a centralized strategy of Cisco IOS Software deployment is implemented. One router can be used by other routers to load its operating system. However, the BOOTP protocol is seldom used, and it gives a hacker an opportunity to steal an IOS image. Therefore, in most situations, you should disable it using the following command:
R8(config)#no ip bootp server
Configuration Auto-Loading
The routers can find their startup configuration either in their own NVRAM or load it over the network. Obviously, loading in from elsewhere is taking a security risk. To disable the router's ability to get its configuration from the network, apply the following commands:
R8(config)#no boot network R8(config)#no service config
Proxy ARP
Proxy Address Resolution Protocol (ARP) replies are sent to an ARP request destined for another device. When an intermediate Cisco device knows the MAC address of the destination device, it can act as a proxy. When an ARP request is destined for another Layer 3 network, a proxy ARP device extends a LAN perimeter by enabling transparent access between multiple LAN segments. This presents a security problem. An attacker can issue multiple ARP requests and use up the proxy ARP device's resources when it tries to respond to these requests in a denial-of-service (DoS) attack.
Proxy ARP is enabled on Cisco router interfaces. Disable it with the following interface command whenever it is not needed:
R8(config-if)#no ip proxy-arp
NOTE
If, however, static routes use the interface as the destination instead of a next-hop router, proxy ARP is required.
IP Source Routing
An option is found in the header of every IP packet. The Cisco IOS Software examines the option and acts accordingly. Sometimes an option indicates source routing. This means that the packet is specifying its own route. Even though it is the default, this feature has several drawbacks. First, to allow source routing in the ISP environment means that a customer selects a route as they please. Also, this feature poses a known security risk, such as a hacker taking control of a packet's route and directing it through his network. So, if source routing is not necessary in your network, you should disable it on all routers by using the following command:
R8(config)#no ip source-route
IP-Directed Broadcast
If IP directed broadcast is enabled on a router's interface, it allows the interface to respond to the Internet Control Message Protocol (ICMP) requests directed to a broadcast address of its subnet. This can cause excessive traffic and possibly bring a network down, which is a tool often used by hackers in a smurf attack.
NOTE
During a smurf attack, the ping requests sent to a broadcast address are forwarded to up to 255 hosts on a subnet. Because the return address of the ping request is spoofed to be the address of the attack target, all hosts that receive the ping requests reply to the attack target, flooding it with replies.
You can turn off IP directed broadcast capability on every interface with the following command:
R8(config-if)#no ip directed-broadcast
IP Unreachables, Redirects, and Mask Replies
ICMP messages that are automatically sent by Cisco routers in response to various actions can give away a lot of information, such as routes, paths, and network conditions, to an unauthorized individual. Attackers commonly use the following three types of ICMP message response features:
Unreachable—A response to a nonbroadcast packet that uses an unknown protocol known as Protocol Unreachable, or a response to a packet that a responding device failed to deliver because there is no known route to a destination (Host Unreachable)
Redirect—A response to a packet that notifies the sender of a better route to a destination
Mask Reply—A response from a network device that knows a subnet mask for a particular subnet in an internetwork to a Mask Request message from a device that requires such knowledge
To disable the automatic messaging feature on interfaces, use the following commands:
R8(config-if)#no ip unreachables R8(config-if)#no ip redirects R8(config-if)#no ip mask-reply
Verification
Example 15-10 shows that all the services discussed in this lesson are disabled on R8. You do not see some of them in the running configuration output because of the default settings in this particular version of Cisco IOS Software.
Example 15-10 Disabling Unnecessary Services
R8#show run version 12.2 hostname R8 ! ! Output omitted for brevity ! ! username admin privilege 3 password 7 02100A175809 username Sam privilege 15 password 7 05080F1C2243 username Jessie privilege 15 password 7 13061E010803 username Terry privilege 15 password 7 030752180500 username Joe privilege 5 password 7 01100F175804 no ip source-route ! ip ftp source-interface FastEthernet0/0 ip ftp username anonymous ip ftp password 7 1511021F0725 no ip domain-lookup ! interface FastEthernet0/0 ntp disable no cdp enable ! interface FastEthernet0/1 ip address 192.168.1.1 255.255.255.0 no ip unreachables no ip redirects no ip mask-reply no cdp enable !
Lesson 15-3: Setting up a Secure HTTP Server
In this scenario, R8 needs to be configured as the HTTP server so that it allows remote management through the Cisco web browser interface. The syntax for the HTTP server command is as follows:
R8(config)#ip http server
Specifying the Port Number
You should change the HTTP port number from the default of 80 to something else to hide the HTTP server from an intruder. To modify the default, use the following command:
R8(config)#ip http port port-number
Specifying Authentication Technique
Next, you need to set up basic user authentication on your HTTP server. Although, you can use AAA services for this purpose, this example queries for the local database. The configuration of usernames and passwords in the database was discussed in the first lesson in "Configuring Passwords, Privileges, and Logins." Use the following command to set up basic user authentication on your local HTTP server:
R8(config)#ip http authentication [local]
Limiting Access to the Server
To limit access to the server, you can create an access list and then apply it to the HTTP configuration. To associate the list with the HTTP server access, generate the following command:
R(config)#ip http access-class access-list
Syslog Logging
You can choose to enable the logging of a router's events to a syslog server, including the HTTP-related activity. To specify syslog logging, use the following set of commands:
R8(config)#logging on R8(config)#logging facility [syslog] R8(config)#logging source-interface local-interface R8(config)#logging syslog-server-address R8(config)#logging trap [alerts]
The first command on the list, logging on, turns the logging on. The logging facility [syslog] command names a syslog server as the logging monitor. The logging source-interface local-interface command identifies local interface that forwards logs to the server. The logging syslog-server-address command points to the syslog server's IP address. The logging trap command sets up the trap level.
Verification
Example 15-11 displays the running configuration of R8. Notice the resolution of the HTTP commands. For example, the port number is changed to 8080. Access-list 11, permitting host 192.168.1.8, was created on R8. FastEthernet0/1 forwards logs to the server.
Example 15-11 HTTP Configuration
R8#show run ! ! Output omitted for brevity ! ip http server ip http port 8080 ip http access-class 1 ip http authentication local access-list 11 permit 192.168.1.8 ! logging facility syslog logging source-interface FastEthernet0/1 logging 192.168.1.7 logging trap alerts
Now that the HTTP server has been successfully configured, an authorized user can log in. Figures 15-1 and 15-2 show the browser login prompt and the postlogin screen, respectively.
)
Figure
15-1 HTTP Login Prompt
)
Figure
15-2 Administrator's Browser Screen
Case Study 15-1: Secure NTP Configuration
Figure 15-3 describes the network topology where R6 is a client of two NTP masters: R5 and R8. To throw in a twist, PIX2 is placed between R8 and R6. This case study is not meant as an in-depth demonstration of the NTP protocol. The main goal is to achieve a functional, secure NTP configuration between the three routers using MD5 authentication.
)
Figure
15-3 Network Topology for NTP Configuration
This case study covers the following steps:
Step 1 Setting up time
Step 2 Setting up NTP relationships
Step 3 Configuring PIX2
Step 4 Restricting NTP access
Step 5 Configuring NTP authentication
Step 6 Verification
Step 1: Setting up Time
If you are using a local router as your time synchronization source, the first task you need to complete is to set the clock on the router that is to be your server, R5 in this case. The following command establishes the time (in military format) and date on the router:
R5>clock set hh:mm:ss day month year
Then, on all participating routers, set the time zone as compared to the Coordinated Universal Time (UTC). Also, configure the routers to automatically switch to daylight-saving time when appropriate. The following two commands identify the time zone and configure daylight-saving time for that zone:
R5(config)#clock timezone zone hours [minutes] R5(config)#clock summer-time zone recurring [week day month hh:mm week day month hh:mm [offset]]
This scenario uses Pacific Standard Time (PST), offset 8 hours from the UTC. The summertime clock comes into effect on the first and ends on the second specified day every year, as shown in Example 15-12.
Example 15-12 Coordinating Clocks
R5#show run ! ! Output omitted for brevity ! clock timezone PST -8 clock summer-time PDT recurring
Step 2: Setting Up NTP Relationships
When an external NTP source is not available, as is the case with this NTP configuration scenario, you need to designate a local router as the master that is to be the source of time in the network. To appoint a router as the NTP master, use the following command:
R5(config)#ntp master [stratum]
To implement redundancy, two routers act as masters: R5 and R8. When an NTP client is configured with several NTP masters, the stratum level of a master is the deciding factor. The stratum level of R5 is 1, and the stratum level of R8 is 3; this means that R5 takes precedence over R8.
Next, you need to set up peering between routers for clock synchronization. Use the following command:
R5(config)#ntp peer ip-address
Each router in the network has been peered up with the two other routers, as shown in Example 15-13.
Example 15-13 NTP Router Relationships
R5#show run ! ! Output omitted for brevity ! ntp peer 130.100.26.8 _R8 ntp peer 140.100.56.6 _R6
Step 3: Configuring PIX2
Because R8 is separated from R6 by PIX2, the configuration is not fully functional without the firewall's involvement. For a comprehensive reference on the PIX functions and commands, see Chapter 23, "Cisco PIX Firewall." In this case study, you are offered a short explanation of the commands that are necessary to enable NTP between the routers.
In Example 15-14, you can see that inside and outside interfaces have been assigned their IP addresses. R6 was associated with IP address 130.100.26.6 with the name 130.100.26.6 R6 statement. Inside-to-outside Network Address Translation (NAT) has been enabled with the global (outside) 10 interface and nat (inside) 10 0.0.0.0 0.0.0.0 0 0 commands. The static (inside,outside) 130.100.26.8 192.168.1.1 netmask 255.255.255.255 0 0 command specifies the outside IP address to be translated to the inside for packet forwarding to R8. The route outside 0.0.0.0 0.0.0.0 R6 1 command designates R6 as the default gateway to the outside. Finally, the access list permitting NTP traffic destined for R8 has been applied to the inbound traffic of the outside interface.
Example 15-14 PIX2 Configuration for NTP
PIX2#show run ! ! Output omitted for brevity ! nameif ethernet0 outside security0 nameif ethernet1 inside security100 name 130.100.26.6 R6 interface ethernet0 10full interface ethernet1 auto access-list outside_access_in permit udp any host 130.100.26.8 eq ntp ip address outside 130.100.26.2 255.255.255.224 ip address inside 192.168.1.222 255.255.255.0 static (inside,outside) 130.100.26.8 192.168.1.1 netmask 255.255.255.255 0 0 access-group outside_access_in in interface outside global (outside) 10 interface nat (inside) 10 0.0.0.0 0.0.0.0 0 0 route outside 0.0.0.0 0.0.0.0 R6 1
Step 4: Restricting NTP Access
You can assign an access list to the NTP process to exercise better control over your NTP synchronization. For example, R6 needs to limit the sources of its NTP updates to R5 and R8 only. To allow NTP traffic from the two routers, specify an access list, such as the one in Example 15-15, allowing 140.100.56.5 and 130.100.26.8, and apply it to NTP with the following command:
R6(config)#ntp access-group [query-only | serve-only | serve | peer] access-list-number
Example 15-15 NTP Access List
R6#show run ! ! Output omitted for brevity ! interface FastEthernet0/0 ip address 130.100.26.6 255.255.255.224 ip access-group 110 in ip auth-proxy auth duplex auto speed auto ntp broadcast ! interface Serial0/0 ip address 140.100.56.6 255.255.255.192 ip ospf network point-to-point ntp broadcast no cdp enable ! ntp access-group peer 1 access-list 1 permit 140.100.56.5 access-list 1 permit 130.100.26.8 ! ntp peer 130.100.26.8 ntp peer 140.100.56.5
Step 5: Configuring NTP Authentication
You have reached the final step of this configuration. NTP supports MD5 authentication, which is useful for preserving your network's security. When MD5 authentication is enforced, your router can be sure that the NTP updates that arrived are from the authorized source. To configure NTP MD5 authentication, perform the following tasks on all the participating routers:
Step 1 Start the NTP authentication process.
Step 2 Specify the NTP authentication-key, MD5 authentication
type and string.
Step 3 Set up an NTP trusted key that matches the
authentication-key.
Step 4 Add the authentication-key to the peer statements.
To accomplish these tasks, use the following commands and review their application on the routers shown in Example 15-16:
R5(config)#ntp authenticate R5(config)#ntp authentication-key number md5 value R5(config)#ntp trusted-key key-number R5(config)#ntp peer ip-address [key keyid]
Example 15-16 MD5 Authentication of NTP
R5#show run hostname R5 ! ! Output omitted for brevity ! ntp authentication-key 6727 md5 cisco ntp authenticate ntp trusted-key 6727 ntp clock-period 17179922 ntp access-group peer 1 access-list 1 permit 130.100.26.2 access-list 1 permit 140.100.56.6 ntp master 1 ntp peer 130.100.26.8 key 6727 ntp peer 140.100.56.6 key 6727
Step 6: Verification
To verify that your NTP configuration is working properly, issue the following commands on any of the routers (see Example 15-17):
R5#show ntp associations R5#show ntp status R5#show clock
Example 15-17 Verifying NTP Operation
R5#show ntp associations address ref clock st when poll reach delay offset disp *~127.127.7.1 .LOCL. 0 540 64 0 0.0 0.00 16000. *~130.100.26.8 140.100.56.5 2 1143 64 0 21.2 -11.17 16000. *~140.100.56.6 140.100.56.5 2 236 64 0 33.1 -5.71 16000. *master (synced), # master (unsynced), + selected, - candidate, ~ configured R5#show ntp status Clock is synchronized, stratum 1, reference is 127.127.7.1 nominal freq is 250.0000 Hz, actual freq is 249.9992 Hz, precision is 2**19 reference time is AF3BF47D.EBB36EC2 (18:33:33.920 PST Sun Sep 28 2002) clock offset is -11.1668 msec, root delay is 0.00 msec root dispersion is 0.02 msec, peer dispersion is 0.02 msec R5#show clock .21:14:12.900 PDT Sat Sep 28 2002 R8#show clock .21:14:14.600 PDT Sat Sep 28 2002
NOTE
If you make any changes to the master or the client NTP configuration, they do not take effect until you restart the router in question.
Case Study 15-2: Configuring SSH
In this case study, R5 has been selected as an SSH server. After you complete the necessary configuration tasks, an SSH-enabled client—R6 in this case—can securely connect to the router for administration. (Refer to Figure 15-3 to see the topology.)
The preliminary tasks for configuring SSH are specifying a host name and a domain name for a router. As a result, two statements—hostname R5 and ip domain-name cisco.com—have been placed on R5. After taking this non-SSH-specific step, you can begin the SSH configuration procedure, which includes the following steps:
Step 1 Allowing access for a client
Step 2 Setting up usernames
Step 3 Generating RSA keys
Step 4 Fine-tuning SSH
Step 5 Verification
Step 1: Allowing Access for a Client
To limit SSH access to a known client only, create an access list that specifies the IP address of R6. The access-list 15 permit 140.100.56.6 log command is a standard access list that helps achieve the desired outcome.
The syntax for the command that assigns an inbound access list to the vtys was discussed in Lesson 15-1. When applied to this scenario, it results in the following line-mode command:
access-class 15 in
Step 2: Setting Up Usernames
The next step is to create user accounts, as described in Lesson 15-1. However, instead of using AAA, a local login has been specified here, as follows:
R5(config-line)#login local
In other words, the login local command indicates to the router that when a user is trying to connect via SSH, the router uses the local database configured with the username admin privilege 15 password cisco command to authenticate the said user.
Step 3: Generating RSA Keys
For R5 to become an SSH server, it needs to get an RSA key pair. To generate a new RSA key pair for R5, use the following command:
R5(config)#crypto key generate rsa
At the next prompt, specify R5.cisco.com as the name for the keys and the default of 512 bits accepted for the key modulus. By generating the RSA key pair, you automatically enabled SSH on the router. To exercise further control over your SSH, use the commands described in the next step.
Step 4: Fine-Tuning SSH
Authentication timeout is the interval, measured in seconds, that the server waits until a client responds with a password. The default and the maximum are both 120 seconds. In this configuration, the timeout stands at 60 seconds. The syntax for configuring the authentication timeout is as follows:
R5(config)#ip ssh timeout seconds
If a user logs in incorrectly several times, the router drops the connection. The default for authentication attempts is 3, and the maximum is 5. In this example, the default is kept, but the syntax for the command is as follows:
R5(config)#ip ssh authentication-retries number
In Lesson 15-1, you allowed Telnet as the type of connection over vtys on R8. Here, you specify SSH as the connection of choice in the following manner:
R5(config-line)#transport input ssh
Step 5: Verification
Example 15-18 shows the output of the running configuration of R5. All the steps that have been covered in this case study are displayed.
Example 15-18 SSH Configuration
R5(config)#hostname R5 R5(config)#ip domain-name cisco.com R5(config)#access-list 15 permit 140.100.56.6 log _ Only R6 R5(config)#line vty 0 4 R5(config-line)#access-class 15 in R5(config-line)#login local R5(config-line)#transport input ssh R5(config-line)#exit R5(config)#username admin privilege 15 password cisco R5(config)#crypto key generate rsa The name for the keys will be: R5.cisco.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]:512 "or hit ENTER" Generating RSA keys ... [OK] R5(config)# Sep 29 22:26:42: %SSH-5-ENABLED: SSH 1.5 has been enabled R5(config)#ip ssh authentication-retries 3 R5(config)#ip ssh time-out 60 R5(config)#
To determine whether the configuration is working, the next logical step is to try to connect to R5 from R6 via SSH. Issue the following statement on R6, as shown in Example 15-19:
ssh –c des –l admin 140.100.56.5
Type in the password at the prompt.
Example 15-19 Connecting from R6 to R5 via SSH
r6#ssh -c des -l admin 140.100.56.5 _ R5 Trying 140.100.56.5...Open password:cisco
Once you are successfully connected, you can input show ssh on R5 to verify that SSH has been successfully enabled and check that your session is using SSH. Example 15-20 shows the output of the show ssh command, which displays the status of SSH server connections, and the show ip ssh command, which demonstrates the version and configuration data for SSH.
Example 15-20 The show ssh and show ip ssh Commands on R5
R5#show ssh Connection Version Encryption State Username 0 1.5 DES Session started cisco R5#show ip ssh SSH Enabled - version 1.5 Authentication timeout: 60 secs; Authentication retries: 3
If you use the Cisco IOS Software debug ip ssh command, you can monitor the SSH operation. Example 15-21 illustrates the output of the debug ip ssh client command. The first part of the output is the display of user activity, and the second is the log line that was recorded after the user exited the SSH server.
Example 15-21 The debug ip ssh client Command Output
R5#debug ip ssh client Sep 29 22:36:52: SSH1: sent protocol version id SSH-1.5-Cisco-1.25 Sep 29 22:36:52: SSH1: protocol version id is - SSH-1.5-Cisco-1.25o ! User exits ssh router Sep 29 22:37:37: SSH1: Session terminated normally
Catalyst 3550 Security
Because the 3550 family of Catalyst switches uses the IOS-based command-line interface, the handling of the basic security features on the switch is virtually the same as it is on the router. By the time this book is released, the 3550 switches will even offer full support of routing protocol security. For now, use Access Control Lists (ACLs), covered in Chapter 16, to enforce remote administration security.
A few security concepts, however, remain specific to the Catalyst switch. Among them is the network security configuration with ACLs, mentioned in the preceding paragraph, and L2VPN, covered in Chapter 25, "Internet Service Provider Security Services." In this lesson, you concentrate on port-based traffic control configuration.
Lesson 15-4: Port-Based Traffic Control
This lesson discusses how to configure the port-based traffic control features on your switch. The lesson consists of the following configuration tasks:
- Configuring storm control
- Configuring protected ports
- Configuring port blocking
- Configuring port security
- Port security aging
Configuring Storm Control
A LAN storm takes place when packets overflow the LAN, causing unnecessary traffic and diminishing network stability. Storm control or the traffic suppression feature configured on a physical interface prevents switchports on a LAN from being overwhelmed by a broadcast, multicast, or unicast storm. Storm control screens the incoming traffic over a period of 1 second and compares the amount with the control level threshold if one exists. If the threshold is exceeded, additional traffic is blocked until the continuing monitoring determines that incoming traffic fell below the threshold level, and traffic is then allowed to be forwarded again.
The switch handles separate storm control thresholds for broadcast, multicast, and unicast traffic. Interestingly, when broadcast or unicast thresholds are reached, traffic is suppressed for only that specific type. On the other hand, when the multicast traffic rate exceeds the threshold, all incoming traffic, except spanning-tree packets, including broadcast and unicast, is throttled until the level drops below the specified threshold.
Storm control on an interface is enabled separately for each type of traffic. The configured threshold level is the percentage of total available bandwidth that you want to serve as a limit indicator. The percentage can be from 1 to 100, with an optional fraction. The higher the level, the more packets are allowed to pass through. The default is no storm control, which translates into 100 percent threshold. In contrast, a value of 0.0 means that all port traffic is blocked for a particular type. The syntax for configuring traffic suppression is as follows:
3550-A(config-if)#storm-control [broadcast | multicast | unicast] level level [.level]
Configuring Protected Ports
A protected port feature is used in those environments where no traffic can be forwarded between two ports on the same switch. This way, one neighbor connected to one port does not see the traffic that is generated by another neighbor connected to the second port. The blocking of traffic (unicast, broadcast, or multicast) only works when both ports are protected. When a protected port is communicating with an unprotected port, the traffic is forwarded in the usual manner. Once the ports are protected, traffic between them can only be forwarded by a Layer 3 device.
By default, the protected port feature is not enabled. You can configure protected ports on either a physical interface or an EtherChannel group. Once you enable the protected port feature on the latter, it is extended to all the group's ports. The following command sets port protection:
3550-A(config-if)#switchport protected
Configuring Port Blocking
The default behavior of a switch is to forward the packets with unknown destination MAC addresses to all its ports. This might not always be desirable, especially in terms of security. If you configure a port block feature, then depending on what type of traffic you specified, unicast or multicast packets are not forwarded from one port to another. Blocking unicast or multicast traffic is not automatically enabled, even on a protected port; you must manually define it.
As with the protected interface, you can configure blocking on a physical interface and an EtherChannel group. If blocking is configured on an EtherChannel, it applies to all ports in the group. To block unknown multicast or unicast packets from a port, use the following command:
3550-A(config-if)#switchport block [multicast | unicast]
Configuring Port Security
The port security feature is used to limit access to an interface to only those devices whose MAC address is identified as allowed and as long as the maximum number of allowed addresses is not already reached. In other words, if a port that is configured as secure recognizes that a station is trying to gain access, it checks whether the configured maximum number of secure MAC addresses has been exceeded. If it has not, the port checks the table of secure MAC addresses, and if the MAC address in question is not there yet, the port learns it and marks it as secure. If the preset maximum number has been reached, and the MAC address is not a member of the secure addresses, a security violation is noted. Similarly, the violation occurs when a device whose MAC address is known as secure on one secure port tries to access another secure port.
To configure a secure port, first set the physical interface's mode to "access" because an interface in the default mode cannot be configured as a secure port:
3550-B(config-if)#switchport mode access
Then, enable port security on that interface by using the following command:
3550-B(config-if)#switchport port-security
Placement of the following three commands is optional because the exact commands you choose depend on the desired functional effect. The following command specifies the maximum number of secure MAC addresses for the interface (the number ranges from 1 to 128, with 128 being default):
3550-B(config-if)#switchport port-security maximum value
Next, you can configure the interface to take one of the following actions in case of a security violation:
The protect keyword causes the packets with unknown source addresses to be dropped when the maximum threshold is reached.
The restrict keyword increments a violation counter.
The shutdown keyword, the default, deactivates the port immediately and sends an SNMP trap notification.
3550-B(config-if)#switchport port-security violation [protect | restrict | shutdown]
NOTE
If a secure port has been shut down as a result of a security violation, you can bring it out of this state by entering the errdisable recovery cause psecure-violation global configuration command, or you can manually reenable it by entering the shutdown and no shut down interface configuration commands.
Finally, to enter a secure MAC address for the interface, use the following command. If the number of manually defined addresses is less than the configured maximum, the rest are learned dynamically.
3550-B(config-if)#switchport port-security mac-address mac-address
Port Security Aging
You can define an optional security-aging feature to cause all secure addresses to become obsolete without having to manually remove each of them. The types of aging mechanisms are as follows:
Absolute—Specifies an aging period after which the secure addresses on that port are deleted
Inactivity—Discards secure addresses only if they have been inactive for the specified aging time
The aging time command includes a number of arguments. The static keyword involves the manually configured addresses for the interface. The time keyword specifies the aging time, ranging from 0 to 1440 minutes. The type identifier indicates either absolute or inactivity, as follows:
3550-B(config-if)#switchport port-security aging [static] time time type [absolute | inactivity]
Verification
The following examples display the outputs from a number of show commands on both switches that assist in the verification and monitoring of port-based traffic control.
Example 15-22 captures a portion of the 3550-A running configuration for interface FastEthernet0/1.
Example 15-22 Running Configuration of 3550-A
interface FastEthernet0/1 switchport mode access switchport port-security maximum 2 switchport port-security mac-address 1000.2000.3000 switchport port-security violation protect switchport port-security aging time 600 no ip address storm-control broadcast level 10.00 storm-control multicast level 10.00 storm-control unicast level 10.00
Example 15-23 shows a portion of the 3550-B running configuration for interface FastEthernet0/2.
Example 15-23 Running Configuration of 3550-B
interface FastEthernet0/2 switchport mode dynamic auto switchport block multicast switchport block unicast no ip address
Example 15-24 shows the output of the show interfaces fastEthernet switchport command for the 0/1 and 0/2 ports.
Example 15-24 The show interfaces fastEthernet switchport Command Output
3550-A#show interfaces fastEthernet 0/1 switchport Name: Fa0/1 Switchport: Enabled Administrative Mode: static access Operational Mode: up Administrative Trunking Encapsulation: negotiate Negotiation of Trunking: Off Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Protected: false Unknown unicast blocked: disabled Unknown multicast blocked: disabled Voice VLAN: none (Inactive) Appliance trust: none 3550-A#show interfaces fastEthernet 0/2 switchport Name: Fa0/2 Switchport: Enabled Administrative Mode: dynamic auto Operational Mode: down Administrative Trunking Encapsulation: negotiate Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Protected: false Unknown unicast blocked: enabled Unknown multicast blocked: enabled
Example 15-25 shows the output of the show storm-control command. You can use this command to view your storm control configuration per port.
Example 15-25 The show storm-control Command Output
3550-A#show storm-control Interface Filter State Level Current --------- ------------- ------- ------- Fa0/1 Forwarding 10.00% 0.00% Fa0/2 inactive 100.00% N/A Fa0/3 inactive 100.00% N/A Fa0/4 inactive 100.00% N/A Fa0/5 inactive 100.00% N/A Fa0/6 inactive 100.00% N/A Fa0/7 inactive 100.00% N/A Fa0/8 inactive 100.00% N/A Fa0/9 inactive 100.00% N/A Fa0/10 inactive 100.00% N/A
Example 15-26 shows the ports configured as secure.
Example 15-26 The show port-security Command Output
3550-A#show port-security address
Secure Mac Address Table
------------------------------------------------------------
Vlan Mac Address Type Ports
---- ----------- ---- -----
1 1000.2000.3000 SecureConfigured Fa0/1
Summary
In this chapter, you were introduced to several features of basic Cisco IOS Software and Catalyst 3550 security. On routers, these features include the following:
Password management
Disabling unnecessary services
Setting up secure HTTP and NTP services
SSH
On 3550 switches, controlling traffic on ports was also discussed.
For some of you, the basic IOS security features might have seemed too basic. Remember, however, that these service features are essential to overall network security and are, or might become, an integral part of the CCIE Security lab exam. Likewise, the HTTP and NTP case studies were included to demonstrate how you can apply security to various Cisco IOS Software services. You can consult plenty of references to find out more information. Some of them are suggested in the Appendix E, "Security-Related RFCs and Publications."
This chapter was designed to make you comfortable with basic IOS security and to help you realize that network security can be enhanced with as few as one or two commands.
Review Questions
What is the NTP standard time zone?
What is the secure alternative to Telnet?
Which command(s) protect(s) the privileged EXEC mode on a router?
How many privilege levels exist?
What does the exec-timeout 0 0 command indicate?
You can disable the Cisco Discovery Protocol (CDP) globally or per interface. True or false?
You can exercise storm control on the 3550 switch ports for which type(s) of traffic?
FAQs
-
What is basic Cisco IOS Software security?
-
Basic IOS security comprises the features that are available in Cisco IOS Software to protect your router and, in turn, your network from unauthorized activities. It is the first line of software defense that is relatively easy to implement and should always be used unless your particular circumstances dictate otherwise.
-
How do I protect my NTP services?
-
You can protect your NTP services by applying an access list to NTP for access restriction. You can also apply an access list that specifies NTP services to an interface. MD5 encryption is used for authenticating NTP peers to ensure their identity.
-
Why do I need HTTP services on the router?
-
To simplify the tasks of router access and management, HTTP offers web-based services with a browser look and feel.
-
What kind of password-management techniques does Cisco IOS Software have?
-
Cisco IOS Software supports enable passwords, which control access to administrative-level commands on a router. There are also line passwords, which control access to a router, be it locally via a console port or remotely through an auxiliary port or virtual terminal access.
-
What is the purpose of SSH?
-
SSH is an alternative to Telnet service. Telnet service sends traffic in cleartext and can easily be intercepted by an attacker. SSH is implemented to provide security by encrypting traffic between the SSH server and a client. It is available in the newer versions of Cisco IOS Software.
-
Why do I need to disable some services on the router?
-
Unused services on the router always present a security risk. They can be manipulated in a variety of ways to aid an attacker in his pursuit. If a service is not used, you should turn it off. If you must use the service, make securing that service one of your primary concerns.
-
Why do I need port security on the switch?
-
Port security on the switch is a way to limit access to a port to only those devices whose MAC addresses are explicitly allowed, either through manual configuration or by being dynamically learned.