Home > Articles > Cisco > CCIE

This chapter is from the book

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 1Figure 15-1 HTTP Login Prompt


Figure 2Figure 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 3Figure 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

Pearson IT Certification Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Pearson IT Certification and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Pearson IT Certification products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by Adobe Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.pearsonitcertification.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020