Chapter 26. Network Device Access Control and Infrastructure Security

This chapter covers the following subjects:

Access Control Lists (ACLs): This section explains how to configure and verify ACLs to secure the network infrastructure

Terminal Lines and Password Protection: This section explains how to configure and verify local network device access control through local usernames and passwords for authentication and how to configure and verify role-based access control (RBAC) through privilege levels.

Authentication, Authorization, and Accounting (AAA): This section explains how to configure and verify network device access control on IOS through an AAA TACACS+ server.

Zone-Based Firewall (ZBFW): This section explains how to configure and verify stateful firewall functionality on IOS routers.

Control Plane Policing (CoPP): This section explains how to configure and verify CoPP, which is used to protect the route processor (RP) or CPU of a router.

Device Hardening: This section provides additional configuration tips for hardening the security of IOS routers.

This chapter focuses on how to configure and verify network device access control through local authentication and authorization as well through AAA. It also explains how to configure and verify router security features such as ACLs, CoPP, and ZBFW that are used to provide device and infrastructure security.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read the entire chapter. If you miss no more than one of these self-assessment questions, you might want to move ahead to the “Exam Preparation Tasks” section. Table 26-1 lists the major headings in this chapter and the “Do I Know This Already?” quiz questions covering the material in those headings so you can assess your knowledge of these specific areas. The answers to the “Do I Know This Already?” quiz appear in Appendix A, “Answers to the ‘Do I Know This Already?’ Quiz Questions.”

Table 26-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section

Questions

Access Control Lists (ACLs)

1

Terminal Lines and Password Protection

2–6

Authentication, Authorization, and Accounting (AAA)

7–9

Zone-Based Firewall (ZBFW)

10–11

Control Plane Policing (CoPP)

12–13

Device Hardening

14

1. Which command is used to apply an ACL to an interface?

  1. ip access-group {access-list-number | name} {in|out}

  2. ip access-class {access-list-number | name} {in|out}

  3. ip access-list {access-list-number | name} {in|out}

2. Which of the following password types is the weakest?

  1. Type 5

  2. Type 7

  3. Type 8

  4. Type 9

3. What type of encryption does the command service password encryption provide?

  1. Type 0 encryption

  2. Type 5 encryption

  3. Type 7 encryption

4. What is the difference between the line configuration command login and the line configuration command login local? (Choose two.)

  1. The login command is used to enable line password authentication.

  2. The login command is used to enable username-based authentication.

  3. The login local command is used to enable line and username-based authentication.

  4. The login local command is used to enable username-based authentication.

5. Which of these commands are available to a user logged in with privilege level 0? (Choose all that apply.)

  1. disable

  2. enable

  3. show

  4. configure terminal

  5. exit

  6. logout

6. Which of the following options can be used to only allow inbound SSH access to the vty lines of a router? (Choose two.)

  1. line vty 0 4 transport output ssh

  2. line vty 0 4 transport input all

  3. line vty 0 4 transport input ssh

  4. ip access-list extended SSH permit tcp any any eq 22 line vty 0 4 access-class SSH in

7. True or false: The command aaa authorization exec default group ISE-TACACS+ if-authenticated enables authorization for all terminal lines on the router, including the console line.

  1. True

  2. False

8. Which of the following AAA functions can help log the commands executed by a user on a network device?

  1. AAA next-generation logging

  2. Authorization

  3. Accounting

  4. Auditing

9. What is the protocol of choice for network device access control?

  1. RADIUS

  2. SSHv2

  3. Telnet

  4. TACACS+

10. Which of the following options describe ZBFW? (Choose two.)

  1. Provides high security with stateless inspection functionality

  2. Provides stateful firewall functionality

  3. Is a network interface module

  4. Is an integrated IOS solution

  5. Is a security appliance similar to an ASA 5500-X

11. What are the two system-built zones for ZBFW? (Choose two.)

  1. Inside zone

  2. Twilight zone

  3. System zone

  4. Outside zone

  5. Self zone

  6. Default zone

12. Which of the following features was developed specifically to protect the CPU of a router?

  1. ZBFW

  2. AAA

  3. CoPP

  4. ACLs

13. True or false: CoPP supports input and output policies to control inbound and outbound traffic.

  1. True

  2. False

14. Which of the following are features that can be disabled to improve the overall security posture of a router?

  1. CoPP

  2. CDP

  3. ZBFW

  4. LLDP

  5. LDP

Answers to the “Do I Know This Already?” quiz:

1 A

2 B

3 C

4 A, D

5 A, B, E, F

6 C, D

7 B

8 C

9 D

10 B, D

11 E, F

12 C

13 A

14 B, D

Foundation Topics

Access Control Lists (ACLs)

Access control lists (also known as ACLs or access lists) are sequential lists of access control entries (ACEs) that perform permit or deny packet classification, based on predefined conditional matching statements. Packet classification starts at the top (lowest sequence) and proceeds down (higher sequence) until a matching pattern is identified. When a match is found, the appropriate action (permit or deny) is taken, and processing stops. At the end of every ACL is an implicit deny ACE, which denies all packets that did not match earlier in the ACL.

Note

Access lists applied on Layer 3 interfaces are sometimes referred to as router ACLs (RACLs).

ACLs can be used to provide packet classification for a variety of features, such as quality of service (QoS), Network Address Translation (NAT), or identifying networks within routing protocols. This section explores their primary use, which is to provide basic traffic filtering functionality.

While many different kinds of ACLs can be used for packet filtering, only the following types are covered in this chapter:

  • Numbered standard ACLs: These ACLs define packets based solely on the source network, and they use the numbered entries 1–99 and 1300–1999.

  • Numbered extended ACLs: These ACLs define packets based on source, destination, protocol, port, or a combination of other packet attributes, and they use the numbered entries 100–199 and 2000–2699.

  • Named ACLs: These ACLs allow standard and extended ACLs to be given names instead of numbers and are generally preferred because they can provide more relevance to the functionality of the ACL.

  • Port ACLs (PACLs): These ACLs can use standard, extended, named, and named extended MAC ACLs to filter traffic on Layer 2 switchports.

  • VLAN ACLs (VACLs): These ACLs can use standard, extended, named, and named extended MAC ACLs to filter traffic on VLANs.

ACLs use wildcard masks instead of subnet masks to classify packets that are being evaluated. For example, to match all packets with the IP address 192.168.1.0 and the subnet mask 255.255.255.0, an ACL would use an inverted subnet mask, better known as a wildcard mask, of 0.0.0.255 to match the first three octets exactly, while all the bits of the last octet could be any value between 0 and 255.

All that is required to convert a subnet mask into a wildcard mask is to subtract the subnet mask from 255.255.255.255. The following shows a subnet mask 255.255.128.0 being converted into a wildcard mask by subtracting it from 255.255.255.255. The end result is a 0.0.127.255 wildcard mask.

2552552552552552551280¯Subnet Mask00127255Wildcard Mask

ACLs have no effect until they are applied to an interface. Therefore, the next step after creating an ACL is to apply it to an interface. In addition to the interface, the direction (in or out) in which the ACL needs to be applied has to be specified. Cisco routers allow only one inbound ACL and one outbound ACL per interface.

ACLs can also be used for various other services in addition to applying to interfaces, such as route maps, class maps, NAT, SNMP, virtual terminal (vty) lines, or traffic-classification techniques.

Numbered Standard ACLs

The process for defining a numbered standard ACL for IOS nodes is as follows:

Step 1. Define the ACL by using the command access-list-number { deny | permit } source [source-wildcard] [log]. The ACL number can be 1–99 or 1300–1999.

Step 2. Apply the ACL to an interface by using the command ip access-group{acl-number} {in|out} under interface configuration mode.

The keywords any and host can be used as abbreviations for source [source-wildcard]. Using the keyword any is the equivalent to specifying 0.0.0.0 255.255.255.255, which matches all packets. For example, access-list 1 permit 0.0.0.0 255.255.255.255 is equivalent to access-list 1 permit any.

The keyword host is used to match a specific host. It is the equivalent to having specified a host IP address followed by a wildcard mask of 0.0.0.0. For example, access-list 1 permit 192.168.1.1 0.0.0.0 is equivalent to access-list 1 permit host 192.168.1.1.

The source and source-wildcard reflect a matching pattern for the network prefix that is being matched. Table 26-2 provides sample ACE entries from within the ACL configuration mode and specifies the networks that would match with a standard ACL.

Table 26-2 Standard ACL-to-Network Entries

ACE Entry

Networks

permit any

Permits all networks

permit 172.16.0.0 0.0.255.255

Permits all networks in the 172.16.0.0/16 range

permit host 192.168.1.1

Permits only the 192.168.1.1/32 network

Example 26-1 demonstrates how a numbered standard ACL is created and applied to an interface to deny traffic from the 172.16.0.0/24 subnet and from host 192.168.1.1/32 while allowing all other traffic coming into interface Gi0/1. Notice that the last ACE in the ACL explicitly permits all traffic (permit any). If this ACE is not included, all traffic will be dropped because of the implicit deny (deny any) at the end of every ACL.

Example 26-1 Creating and Applying a Numbered Standard ACL

R1(config)# access-list 1 deny 172.16.0.0 0.0.255.255
R1(config)# access-list 1 deny host 192.168.1.1
R1(config)# access-list 1 permit any
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip access-group 1 i

Numbered Extended ACLs

The process for defining a numbered extended ACL is as follows:

Step 1. Define the ACL by using the command access-list acl-number {deny|permit} protocol source source-wildcard destination destination-wildcard[protocol-options] [log | log-input]. The ACL number can be 100–199or 2000–2699.

Step 2. Apply the ACL to an interface by using the command ip access-group{acl-number} {in|out} under interface configuration mode.

As with standard ACLs, source source-wildcard and destination destination-wildcard can be defined to match a single host with the host keyword or match any subnet with the any keyword.

The protocol-options keyword differs based on the protocol specified in the ACE. For example, when TCP or UDP protocols are defined, eq, lt, and gt (equal to, less than, and greater than) keywords become available to specify ports to be matched as well as more granular options, such as SYN and ACK.

Example 26-2 demonstrates how a numbered extended ACL is created and applied to an interface to block all Telnet and ICMP traffic as well as deny all IP traffic from host 10.1.2.2 to host 10.1.2.1. Notice how Telnet’s TCP port 23 is being matched with the eq keyword.

Example 26-2 Creating and Applying Numbered Extended ACLs

R1(config)# access-list 100 deny tcp any any eq 23
R1(config)# access-list 100 deny icmp any any
R1(config)# access-list 100 deny ip host 10.1.2.2 host 10.1.2.1
R1(config)# access-list 100 permit ip any any
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip access-group 100 in

Named ACLs

Named ACLs allow for ACLs to be named, which makes administering ACLs much easier as long as proper ACL naming conventions are followed. They function in the same way as standard and extended ACLs; the only difference is in the CLI syntax used to create them. To create and apply a named ACL, follow these steps:

Step 1. Define the ACL by using the command ip access-list standard|extended{acl-number | acl-name}. Entering this command places the CLI in ACL configuration mode.

Step 2. Configure the specific ACE in ACL configuration mode by using the command [sequence] {permit | deny} source source-wildcard.

Step 3. Apply the ACL to an interface by using the command ip access-group{ acl-number | acl-name } {in|out} under interface configuration mode.

Notice in step 1 that the CLI for named ACLs starts with ip instead of just access-list and that the standard and extended ACL keywords need to be explicitly defined.

Example 26-3 shows how named standard and extended ACLs are created and applied to an interface. The numbered ACLs in Examples 26-1 and 26-2 are included as a reference for easy comparison to named ACLs.

Example 26-3 Standard and Extended Named ACLs

Named Standard ACL
R1(config)# ip access-list standard STANDARD_ACL
R1(config-std-nacl)# deny 172.16.0.0 0.0.255.255
R1(config-std-nacl)# deny host 192.168.1.1
R1(config-ext-nacl)# permit any
R1(config-ext-nacl)# exit
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip access-group STANDARD_ACL in

Numbered Standard ACL
R1(config)# access-list 1 deny 172.16.0.0 0.0.255.255
R1(config)# access-list 1 deny host 192.168.1.1
R1(config)# access-list 1 permit any
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip access-group 1 in
Named Extended ACL
R1(config)# ip access-list extended EXTENDED_ACL
R1(config-ext-nacl)# deny tcp any any eq 23
R1(config-ext-nacl)# deny icmp any any
R1(config-ext-nacl)# deny ip host 10.1.2.2 host 10.1.2.1
R1(config-ext-nacl)# permit ip any any
R1(config-ext-nacl)# exit
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip access-group EXTENDED_ACL in

Numbered Extended ACL

R1(config)# access-list 100 deny tcp any any eq 23
R1(config)# access-list 100 deny icmp any any
R1(config)# access-list 100 deny ip host 10.1.2.2 host 10.1.2.1
R1(config)# access-list 100 permit ip any any
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip access-group 100 in

Port ACLs (PACLs) and VLAN ACLs (VACLs)

Layer 2 Cisco switches support access lists that can be applied on Layer 2 ports as well as VLANs. Access lists applied on Layer 2 ports are called port access control lists (PACLs), and access lists applied to VLANs are called VLAN access control lists (VACLs).

PACLs

The CLI syntax for configuring PACLs that are used to filter Layer 3 traffic is the same as the syntax for RACLs on any IOS router; the only difference is that PACLs also support Layer 2 MAC address-based filtering, which uses different CLI syntax. PACLs can be standard, extended, or named IPv4 ACLs for Layer 3, and they can be named MAC address ACLs for Layer 2.

PACLs have a few restrictions that vary from platform to platform. The following are some of the most common restrictions:

  • PACLs only support filtering incoming traffic on an interface (no outbound filtering support).

  • PACLs cannot filter Layer 2 control packets, such as CDP, VTP, DTP, PAgP, UDLD,and STP.

  • PACLs are supported only in hardware.

  • PACLs do not support ACLs to filter IPv6, ARP, or Multiprotocol Label Switching (MPLS) traffic.

An IPv4 PACL is applied to an interface with the ip access-group access-list in command. Example 26-4 shows a PACL applied to a Layer 2 interface Gi0/1 to block RDP, Telnet traffic, and host 10.1.2.2 access to host 10.1.2.1.

Example 26-4 Applying a PACL

R1(config)# ip access-list extended PACL
R1(config-ext-nacl)# deny tcp any any eq 23
R1(config-ext-nacl)# deny icmp any any
R1(config-ext-nacl)# deny ip host 10.1.2.2 host 10.1.2.1
R1(config-ext-nacl)# permit ip any any
R1(config-ext-nacl)# exit
R1(config)# interface GigabitEthernet0/1
R1(config-if)# switchport
R1(config-if)# ip access-group PACL in
VACLs

VACLs can filter traffic that is bridged within a VLAN or that is routed into or out of a VLAN. To create and apply a VACL, follow these steps:

Step 1. Define a VLAN access map by using the command vlan access-map name sequence. A VLAN access map consists of one or more VLAN access map sequences where each VLAN access map sequence is composed of one match and one action statement.

Step 2. Configure the match statement by using the command match { ip address{ acl-number | acl-name } | mac address acl-name }. The match statement supports standard, extended, or named IPv4 ACLs as well as named MAC address ACLs as the matching criteria.

Step 3. Configure the action statement by using the command action forward|drop [log]. The action statement specifies the action to be taken when a match occurs, which could be to forward or to drop traffic. Only dropped traffic can be logged using the log keyword.

Step 4. Apply the VACL by using the command vlan filter vlan-access-map-name vlan-list. vlan-list can be a single VLAN, a range of VLANs (such as 5–30), or a comma-separated list of multiple VLANs (such as 1,2–4,6)

Example 26-5 shows a VLAN access map applied to VLAN 20 to drop ICMP and Telnet traffic and allow other traffic. Notice that the named ACLs, ICMP and TELNET, only include ACEs with a permit statement. This is because the ACLs are only used as matching criteria by the VLAN access maps, while the VLAN access maps are configured with the action to drop the matched traffic.

Example 26-5 Creating and Applying a VACL

SW1(config)# ip access-list extended ICMP
SW1(config-ext-nacl)# permit icmp any any
SW1(config-ext-nacl)# exit

SW1(config)# ip access-list extended TELNET
SW1(config-ext-nacl)# permit tcp any any eq 23
SW1(config-ext-nacl)# exit

SW1(config)# ip access-list extended OTHER
SW1(config-ext-nacl)# permit ip any any
SW1(config-ext-nacl)# exit

SW1(config)# vlan access-map VACL_20 10
SW1(config-access-map)# match ip address ICMP
SW1(config-access-map)# action drop
SW1(config-access-map)# exit

SW1(config)# vlan access-map VACL_20 20
SW1(config-access-map)# match ip address TELNET
SW1(config-access-map)# action drop log
SW1(config-access-map)# exit

SW1(config)# vlan access-map VACL_20 30
SW1(config-access-map)# match ip address OTHER
SW1(config-access-map)# action forward

SW1(config)# vlan filter VACL_20 vlan-list 20

PACL, VACL, and RACL Interaction

When a PACL, a VACL, and a RACL are all configured in the same VLAN, the ACLs are applied in a specific order, depending on whether the incoming traffic needs to be bridged or routed:

Bridged traffic processing order (within the same VLAN):

  1. Inbound PACL on the switchport (for example, VLAN 10)

  2. Inbound VACL on the VLAN (for example, VLAN 10)

  3. Outbound VACL on the VLAN (for example, VLAN 10)

Routed traffic processing order (across VLANs):

  1. Inbound PACL on the switchport (for example, VLAN 10)

  2. Inbound VACL on the VLAN (for example, VLAN 10)

  3. Inbound ACL on the SVI (for example, SVI 10)

  4. Outbound ACL on the SVI (for example, SVI 20)

  5. Outbound VACL on the VLAN (for example, VLAN 20)

Note

As mentioned earlier, outbound PACLs are not supported.

Downloadable ACLs (dACLs) are another form of PACL that can be assigned dynamically by a RADIUS authentication server, such as Cisco ISE. After successful network access authentication, if a PACL is configured on a switchport and a dACL is assigned by Cisco ISE on the same switchport, the dACL overwrites the PACL.

Terminal Lines and Password Protection

Password protection to control or restrict access to the CLI to protect the router from unauthorized remote access and unauthorized local access is the most common type of security that needs to be implemented.

There are three basic methods to gain access to the CLI of an IOS device:

  • Console port (cty) line: On any IOS device, this appears in configuration as line con 0 and in the output of the command show line as cty. The console port is mainly used for local system access using a console terminal.

  • Auxiliary port (aux) line: This appears in the configuration as line aux 0. The aux port is mainly used for remote access into the device through a modem.

  • Virtual terminal (vty) lines: These lines are displayed by default in the configuration as line vty 0 4. They are used solely for remote Telnet and SSH connections. They are virtual because they are logical lines with no physical interface associated to them.

Example 26-6 shows what the default configuration looks like for the cty, aux, and vty lines on an IOS device.

Example 26-6 vty, cty, and aux Lines in the Running Configuration

R1# show running-config | section line
Building configuration...

line con 0                                                                           
line aux 0                                                                           
line vty 0 4                                                                         
!
End

Each of these types of terminal lines should be password protected. There are three ways to add password protection to the lines:

  • Using a password configured directly on the line: Not recommended

  • Using username-based authentication: Recommended as a fallback

  • Using an AAA server: Highly recommended and covered later in this chapter, in the section “Authentication, Authorization, and Accounting (AAA)

Password Types

There are five available password types in Cisco IOS:

  • Type 0 passwords: These passwords are the most insecure because they are not encrypted and are visible in the device configuration in plaintext. The command enable password is an example of a command that uses a type 0 password. Type 0 passwords should be avoided whenever possible.

  • Type 5 passwords: These passwords use an improved Cisco proprietary encryption algorithm that makes use of the MD5 hashing algorithm. This makes them much stronger because they are considered not reversible (uncrackable). The only way to crack type 5 passwords is by performing brute-force attacks. It is strongly recommended that you use type 5 encryption instead of type 0 or type 7 whenever possible. Type 5 encryption is applied by using the command enable secret to specify an additional layer of security over the command enable password. The command enable password should be used only on platforms with legacy IOS that do not support the command enable secret. If the command enable secret and the command enable password are configured concurrently, the command enable secret is preferred. The username secret command also uses type 5 encryption.

  • Type 7 passwords: These passwords use a Cisco proprietary Vigenere cypher encryption algorithm and are known to be weak. There are multiple online password utilities available that can decipher type 7 encrypted passwords in less than a second. Type 7 encryption is enabled by the command service password-encryption for commands that use type 0 passwords, such as the enable password, username password, and line password commands.

  • Type 8 passwords: Type 8 passwords specify a Password-Based Key Derivation Function 2 (PBKDF2) with a SHA-256 hashed secret and are considered to be uncrackable.

  • Type 9 passwords: These use the SCRYPT hashing algorithm. Just like type 8 passwords, they are considered to be uncrackable.

Note

Type 4 also exists in releases prior to IOS 15.3(3) but is not mentioned in the previous list because it is not recommended for use due to a security flaw in its implementation. Starting from IOS 15.3(3), type 4 passwords were deprecated. In release 15.3(3), type 8 and type 9 password encryption were introduced, and they are the recommended types of password protection over type 5, when available. Type 4 passwords should never be used.

Password Encryption

The service password-encryption command in global configuration mode is used to encrypt type 0 passwords in the configuration (for example, BGP passwords) or over a plaintext session such as Telnet in an effort to prevent unauthorized users from viewing the password. For example, if someone executed the command show running-configuration during a Telnet session, a protocol analyzer would be able to display the password. However, if the command service password-encryption were used, the password would be encrypted even during the same plaintext Telnet session.

Passwords configured prior to configuring the command service password-encryption are not encrypted and must be reentered into the configuration.

Password encryption is applied to all type 0 passwords, including authentication key passwords; cty, aux, and vty line passwords; and BGP neighbor passwords. The command service password-encryption is primarily useful for keeping unauthorized individuals from viewing a password in a configuration file. Unfortunately, the command service password-encryption encrypts passwords with type 7 encryption, which is easily reversible. Using plaintext password authentication should be avoided if a more secure option exists, such as using username-based authentication instead of passwords, as discussed in the next section.

Username and Password Authentication

The previous section discusses how to create encrypted passwords that can be used to authenticate a user; however, user identification can best be achieved with a combination of a username and a password. Username accounts can be used for several applications, such as console, aux, and vty lines.

To establish a username and password login authentication system, you can create usernames on a device for all device users or groups. Usernames configured from global configuration mode are stored in the device’s configuration. The login accounts created can be assigned different privilege levels and passwords. (Privilege levels are discussed in more detail later in the chapter.)

There are three different ways to configure a username on IOS:

  • Using the command username {username} password {password} configures a plaintext password (type 0).

  • Using the command username {username} secret {password} provides type 5 encryption.

  • Using the command username {username} algorithm-type {md5 | sha256 | scrypt} secret {password} provides type 5, type 8, or type 9 encryption, respectively.

Of the three username commands, the command username {username} algorithm-type {md5 | sha256 | scrypt} secret {password} is the recommended one because it allows for the highest level of password encryption (type 8 and type 9). If this command is not supported in your IOS version, then the command username {username} secret {password} should be used because it provides MD5 encryption. The command username {username} password {password} should be avoided at all costs if the IOS version supports more secure password encryption types.

Configuring Line Local Password Authentication

To enable password authentication on a line, the following two commands are required under line configuration mode:

  • password password to configure the password

  • login to enable password checking at login

In Example 26-7, a password is configured for all users attempting to connect to the cty, vty, and aux lines.

Example 26-7 vty, cty, and aux Lines with Password-Based Authentication

R1# show running-config | section line
Building configuration...

line con 0                                                                           
password My.C0n5ole.P@s5                                                             
login                                                                                
line aux 0                                                                           
password My.AuX.P@s5                                                                 
login                                                                                
line vty 0 4                                                                         
password My.vTy.P@s5                                                                 
login                                                                                
!

end

Notice that the passwords are shown in plaintext. To encrypt them, the command service password-encryption needs to be used.

Verifying Line Local Password Authentication

Example 26-8 shows an example in which the console line password is being tested. All that is required to test the password is to log off the console and log back in again using the configured console password.

Note

When performing this test, an alternate connection into the router, such as a Telnet connection, should be established just in case there is a problem logging back in to the router using the console.

Example 26-8 Console Password Test

R1# exit

Router con0 is now available

Press RETURN to get started.

User Access Verification
Password:                                                                            

! Password entered here is not displayed by the router                               


Router>

Configuring Line Local Username and Password Authentication

To enable username and password authentication, the following two commands are required:

  • The command username in global configuration mode (using one of the options shown in the “Username and Password Authentication” section, earlier in this chapter)

  • The command login local under line configuration mode to enable username-based authentication at login

Note

Username-based authentication for the aux and cty lines is only supported in combination with AAA for some IOS releases. This is covered later in this chapter, in the section “Configuring AAA for Network Device Access Control.”

Example 26-9 shows three usernames (type0, type5, and type9) with different password encryptions each that are allowed to log in to the device. Notice that the type0 user password is shown in plaintext, while type5 and type9 user passwords are encrypted.

Example 26-9 Local Username-Based Authentication for a vty Line

R1# show running-config
Building configuration...
!
! Output Omitted for Brevity                                                         

username type0 password 0 weak                                                       

username type5 secret 5 $1$b1Ju$kZbBS1Pyh4QzwXyZ1kSZ2/                               

username type9 secret 9 $9$vFpMf8elb4RVV8$seZ/bDAx1uV4yH75Z/nwUuegLJDVCc4UXOAE83JgsOc
!                                                                                    
! Output Omitted for Brevity                                                         

line con 0                                                                           
 login local                                                                         

line aux 0                                                                           
 login local                                                                         

line vty 0 4                                                                         
 login local                                                                         
!

end

Verifying Line Local Username and Password Authentication

Example 26-10 shows user type5 establishing a Telnet session from R2 into R1 using username-based authentication.

Example 26-10 Verifying Local Username-Based Authentication for vty Lines

! Telnet session initiated from R2 into R1                                           

R2# telnet 10.1.12.1
Trying 10.1.12.1 ... Open



User Access Verification


Username: type5
Password:

! Password entered is not displayed by the router                                    


R1>

Privilege Levels and Role-Based Access Control (RBAC)

The Cisco IOS CLI by default includes three privilege levels, each of which defines what commands are available to a user:

  • Privilege level 0: Includes the disable, enable, exit, help, and logout commands.

  • Privilege level 1: Also known as User EXEC mode. The command prompt in this mode includes a greater-than sign (R1>). From this mode it is not possible to make configuration changes; in other words, the command configure terminal is not available.

  • Privilege level 15: Also known as Privileged EXEC mode. This is the highest privilege level, where all CLI commands are available. The command prompt in this mode includes a hash sign (R1#).

Additional privilege levels ranging from 2 to 14 can also be configured to provide customized access control. The global configuration command privilege {mode} level {level} {command string} is used to change or set a privilege level for a command to any of these levels. For example, to allow a group of users to configure only specific interface configuration commands while not allowing them access to additional configuration options, a custom privilege level can be created to allow only specific interface configuration commands and share the login information for that level with the group of users.

Example 26-11 shows a configuration where the user noc is created along with the type 9 (scrypt) secret password cisco123. Notice that the privilege level is also configured to level 5 as part of the username command. In this particular case, a user logging in to the router using the username and password noc and cisco123 would be placed into privilege level 5 and would be allowed to go into any interface on the router and shut it down, unshut it, and configure an IP address on it, which are the only commands allowed under privilege level 5 in interface configuration mode.

Example 26-11 Configuring a Username with Privilege Level

R1(config)# username noc privilege 5 algorithm-type scrypt secret cisco123
R1(config)# privilege exec level 5 configure terminal
R1(config)# privilege configure level 5 interface
R1(config)# privilege interface level 5 shutdown
R1(config)# privilege interface level 5 no shutdown
R1(config)# privilege interface level 5 ip address

Verifying Privilege Levels

When you set the privilege level for a command with multiple keywords, the commands starting with the first keyword also have the specified access level. For example, if you set the no shutdown command to level 5, as shown in Example 26-11, the no command and no shutdown command are automatically set to privilege level 5, unless you set them individually to different levels. This is necessary because you can’t execute the no shutdown command unless you have access to the no command. Example 26-12 shows what the configuration shown in Example 26-11 would look like in the running configuration. It also shows a quick test to verify that the only commands allowed for privilege level 5 users are those specified by the privilege level command.

Example 26-12 Verifying Privilege Levels

R1# show running configuration

! Output Omitted for Brevity

username noc privilege 5 secret 9 $9$OvP8u.A0x8dSq8$tF9qrYHnW31826rUGJaKzt6sLxqCEcK0 
rBZTpeitGa2                                                                          

privilege interface level 5 shutdown                                                 
privilege interface level 5 ip address                                               
privilege interface level 5 ip                                                       
privilege interface level 5 no shutdown                                              
privilege interface level 5 no ip address                                            
privilege interface level 5 no ip                                                    
privilege interface level 5 no                                                       
privilege configure level 5 interface                                                
privilege exec level 5 configure terminal                                            
privilege exec level 5 configure                                                     

! Output Omitted for Brevity

R1# telnet 1.2.3.4
Trying 1.2.3.4 ... Open

User Access Verification

Username: noc
Password: cisco123

R1# show privilege
Current privilege level is 5                                                         
R1#
R1# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)# interface gigabitEthernet 0/1
R1(config-if)# ?
Interface configuration commands:
  default   Set a command to its defaults
  exit      Exit from interface configuration mode
  help      Description of the interactive help system
  ip        Interface Internet Protocol config commands                              
  no        Negate a command or set its defaults                                     
  shutdown  Shutdown the selected interface                                          

R1 (config-if)# ip ?
Interface IP configuration subcommands:
  address  Set the IP address of an interface                                        

R1(config-if)# ip address 10.1.1.1 255.255.255.0
R1(config-if)# no ?
  ip        Interface Internet Protocol config commands                              
  shutdown  Shutdown the selected interface                                          

R1(config-if)# no shutdown
R1(config-if)#
*Apr 27 18:14:23.749: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up
*Apr 27 18:14:24.750: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1,
  changed state to up
R1(config-if)#
R1(config-if)# shutdown
R1(config-if)# end
*Apr 27 18:14:38.336: %LINK-5-CHANGED: Interface GigabitEthernet0/1, changed state
  to administratively down
*Apr 27 18:14:39.336: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1,
  changed state to down
R1#
*Apr 27 18:14:40.043: %SYS-5-CONFIG_I: Configured from console by noc on vty0
  (1.2.3.4)
R1#

While using local authentication and privilege levels on the device provides adequate security, it can be cumbersome to manage on every device, and inconsistent configuration across the network is very likely. To simplify device access control and maintain consistency, a more scalable and preferred approach is to use the authentication, authorization, and accounting (AAA) framework. This can be accomplished by using an AAA server such as the Cisco Identity Services Engine (ISE).

With AAA, network devices can use the Terminal Access Controller Access-Control System Plus (TACACS+) protocol to authenticate users, authorize commands, and provide accounting information.

Since the configuration is centralized on the AAA servers, access control policies are applied consistently across the whole network; however, it is still recommended to use local authentication as a fallback mechanism in case the AAA servers become unavailable.

Controlling Access to vty Lines with ACLs

Access to the vty lines of an IOS device can be further secured by applying inbound ACLs on them, allowing access only from a restricted set of IP addresses. Outbound vty connections from an IOS device can also be controlled by applying outbound ACLs to vtys.

A best practice is to only allow IP addresses that are part of an internal or trusted network to access the vty lines. Extreme care is necessary when allowing IP addresses from external or public networks such as the Internet.

To apply a standard or an extended access list to a vty line, use the command access-class {access-list-number|access-list-name} {in|out} under line configuration mode. The in keyword applies an inbound ACL, and the out keyword applies an outbound ACL.

Verifying Access to vty Lines with ACLs

Example 26-13 demonstrates R1 using Telnet to get into R2 before and after applying an ACL to R2’s vty line. R1 is configured with IP address 10.12.1.1 and R2 with 10.12.1.2. The ACL being applied to R2’s vty line is meant to block vty access into it from R1.

Example 26-13 Verifying Access to vty Lines with ACLs

! Prior to applying an ACL to R2's vty line, R1 is allowed to telnet into R2         

R1# telnet 10.12.1.2
Trying 10.12.1.2... Open

User Access Verification

Username: noc
Password:

R2#
R2# exit


[Connection to 10.12.1.2 closed by foreign host]

! Access list to deny R1's IP address is created and applied to the vty lines 0 to 4 

R2# configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)# access-list 1 deny 10.12.1.1
R2(config)# access-list 1 permit any
R2 (config)# line vty 0 4
R2(config-line)# access-class 1 in
R2(config-line)# end
R2#
R2# show running-config | section line vty
line vty 0 4
 access-class 1 in                                                                   
 login local
R2#
*Apr 27 19:49:45.599: %SYS-5-CONFIG_I: Configured from console by console

! After applying an ACL to R2's vty line, R1 is not allowed to telnet into R2        

R1# telnet 10.12.1.2
Trying 10.12.1.2 ...

% Connection refused by remote host                                                  
R1#

Controlling Access to vty Lines Using Transport Input

Another way to further control what type of protocols are allowed to access the vty lines is to use the command transport input {all | none | telnet | ssh} under line configuration mode. Table 26-3 includes a description for each of the transport input command keywords.

Table 26-3 Transport Input Command Keyword Description

Keyword

Description

all

Allows Telnet and SSH

none

Blocks Telnet and SSH

telnet

Allows Telnet only

ssh

Allows SSH only

telnet ssh

Allows Telnet and SSH

Example 26-14 shows the vty lines from 0 to 4 configured with different transport input command keywords. Keep in mind that vty lines are evaluated from the top (vty 0) onward, and each vty line accepts only one user.

Example 26-14 vty Lines with Different transport input Keywords

line vty 0
 login local
 transport input all                                                                 
line vty 1
 login local
 transport input none                                                                
line vty 2
 login local
 transport input telnet                                                              
line vty 3
 login local
 transport input ssh                                                                 
line vty 4
 login local
 transport input telnet ssh                                                          

Note

The console port (cty line) should be provisioned with the transport input none command to block reverse Telnet into the console port.

Verifying Access to vty Lines Using Transport Input

Example 26-15 demonstrates how Telnet sessions are assigned to different vty lines on R1. R1 is configured based on the configuration shown in Example 26-14, which only allows Telnet sessions on vty 0 (input all), vty 2 (input telnet), and vty 4 (input telnet ssh).

Example 26-15 Verifying Access to vty Lines

! An asterisk to the left of the row indicates the line is in use                    
! The output below shows a user is connected into the console (cty)                  

R1# show line
   Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int
*     0 CTY              -    -      -    -    -      0       0     0/0       -
      1 AUX   9600/9600  -    -      -    -    -      0       0     0/0       -
    578 VTY              -    -      -    -    -      1       0     0/0       -
    579 VTY              -    -      -    -    -      0       0     0/0       -
    580 VTY              -    -      -    -    -      0       0     0/0       -
    581 VTY              -    -      -    -    -      0       0     0/0       -
    582 VTY              -    -      -    -    -      0       0     0/0       -
R1#

! Telnet connection from R2 into R1 is established                                   

R2# telnet 10.1.12.1
Trying 10.1.12.1 ... Open

User Access Verification
Username: noc
Password:
R1>

! The asterisk in the output of show line on R1 indicates the first vty 0 is now in  
use.                                                                                 
! vty 0 is mapped to vty 578 automatically.                                          

R1# show line
   Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int
*     0 CTY              -    -      -    -    -      0       0     0/0       -
      1 AUX   9600/9600  -    -      -    -    -      0       0     0/0       -
*   578 VTY              -    -      -    -    -      2       0     0/0       -      
    579 VTY              -    -      -    -    -      0       0     0/0       -
    580 VTY              -    -      -    -    -      0       0     0/0       -
    581 VTY              -    -      -    -    -      0       0     0/0       -
    582 VTY              -    -      -    -    -      0       0     0/0       -
R1#

! Telnet connection from R3 into R1 is established                                   

R3# telnet 10.1.13.1
Trying 10.1.13.1 ... Open

User Access Verification
Username: noc
Password:
R1>

! The output of show line on R1 indicates the vty 0 and vty 2 are now in use         
! vty 2 is mapped to vty 580                                                         

R1# show line
   Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int
*     0 CTY              -    -      -    -    -      0       0     0/0       -
      1 AUX   9600/9600  -    -      -    -    -      0       0     0/0       -
*   578 VTY              -    -      -    -    -      2       0     0/0       -      
    579 VTY              -    -      -    -    -      0       0     0/0       -
*   580 VTY              -    -      -    -    -      1       0     0/0       -      
    581 VTY              -    -      -    -    -      0       0     0/0       -
    582 VTY              -    -      -    -    -      0       0     0/0       -

R1#

! Telnet connection from R4 into R1 is established                                   

R4# telnet 10.1.14.1
Trying 10.1.14.1 ... Open

User Access Verification
Username: noc
Password:
R1>

! The output of show line on R1 indicates the vty 0, vty 2 and vty 4 are now in use  
! vty 4 is mapped to vty 582. This leaves no more vty lines available for telnet     

R1# show line
   Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int
*     0 CTY              -    -      -    -    -      0       0     0/0       -
      1 AUX   9600/9600  -    -      -    -    -      0       0     0/0       -
*   578 VTY              -    -      -    -    -      2       0     0/0       -
    579 VTY              -    -      -    -    -      0       0     0/0       -
*   580 VTY              -    -      -    -    -      1       0     0/0       -
    581 VTY              -    -      -    -    -      0       0     0/0       -
*   582 VTY              -    -      -    -    -      1       0     0/0       -

R1#

! Trying to telnet into R1 from R5 will fail since there are no more vtys available  
for telnet                                                                           

R5# telnet 10.1.15.1
Trying 10.1.15.1 ...
% Connection refused by remote host

R5#

Enabling SSH vty Access

Telnet is the most popular yet most insecure protocol used to access IOS devices for administrative purposes. Telnet session packets are sent in plaintext, and this makes it very easy to sniff and capture session information. A more reliable and secure method for device administration is to use the Secure Shell (SSH) protocol.

SSH, which provides secure encryption and strong authentication, is available in two versions:

  • SSH Version 1 (SSHv1): This is an improvement over using plaintext Telnet, but some fundamental flaws exist in its implementation, so it should be avoided in favor of SSHv2.

  • SSH Version 2 (SSHv2): This is a complete rework and stronger version of SSH that is not compatible with SSHv1. SSHv2 has many benefits and closes a security hole that is found in SSH version 1. SSH version 2 is certified under the National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS) 140-1 and 140-2 U.S. cryptographic standards and should be used where feasible.

The steps needed to configure SSH on an IOS device are as follows:

Step 1. Configure a hostname other than Router by using the command hostname {hostname name}.

Step 2. Configure a domain name by using the command ip domain-name {domain-name}.

Step 3. Generate crypto keys by using the command crypto key generate rsa. When entering this command, you are prompted to enter a modulus length. The longer the modulus, the stronger the security. However, a longer modulus takes longer to generate. The modulus length needs to be at least 768 bits for SSHv2.

Example 26-16 demonstrates SSH being configured on R1.

Example 26-16 Configuring vty Access Using SSH

R1(config)# hostname R1
R1(config)# username cisco secret cisco
R1(config)# ip domain-name cisco.com
R1(config)# crypto key generate rsa
The name for the keys will be: R1.cisco.com
Choose the size of the key modulus in the range of 360 to 4096 for your
  General Purpose Keys. Choosing a key modulus greater than 512 may take
  a few minutes.

How many bits in the modulus [512]: 768
% Generating 768 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 1 seconds)

R1(config)#
*May  8 20:44:48.319: %SSH-5-ENABLED: SSH 1.99 has been enabled                      
R1(config)#
R1(config)# line vty 0 4
R1(config-line)# login local
R1(config-line)# end
R1#

SSH 1.99, shown in the log message in Example 26-16, indicates that SSHv1 and SSHv2 are enabled. To force the IOS SSH server to disable SSHv1 and accept only SSHv2 connections, enter the command ip ssh version 2 under global configuration mode.

Auxiliary Port

Some devices have an auxiliary (aux) port available for remote administration through a dialup modem connection. In most cases, the aux port should be disabled by using the command no exec under line aux 0.

EXEC Timeout

By default, an idle EXEC session is not terminated, which poses an enormous security risk. The command exec-timeout {minutes}{seconds} under line configuration mode can be used to disconnect idle user sessions. The default setting is 10 minutes.

Example 26-17 shows a configuration in which the exec-timeout for the console line is configured to time out after 5 minutes of inactivity and 2 minutes and 30 seconds for the vty lines.

Example 26-17 Configuring EXEC Timeout

line con 0
 exec-timeout 5 0
line vty 0 4
 exec-timeout 2 30

Note

The commands exec-timeout 0 0 and no exec-timeout disable the EXEC timeout. While using them is useful for lab environments, it is not recommended for production environments.

Absolute Timeout

The command absolute-timeout {minutes} under line configuration mode terminates an EXEC session after the specified timeout period has expired, even if the connection is being used at the time of termination. It is recommended to use it in combination with the command logout-warning {seconds} under line configuration mode to display a “line termination” warning to users about an impending forced timeout.

Example 26-18 shows the commands absolute-timeout and logout-warning configured on the vty lines.

Example 26-18 Configuring Absolute Timeout

line vty 4
 exec-timeout 2 0
 absolute-timeout 10
 logout-warning 2

Authentication, Authorization, and Accounting (AAA)

AAA is an architectural framework for enabling a set of three independent security functions:

  • Authentication: Enables a user to be identified and verified prior to being granted access to a network device and/or network services.

  • Authorization: Defines the access privileges and restrictions to be enforced for an authenticated user.

  • Accounting: Provides the ability to track and log user access, including user identities, start and stop times, executed commands (that is, CLI commands), and so on. In other words, it maintains a security log of events.

AAA requires a protocol designed to carry authentication requests and responses, including authorization results and accounting logs. There are many AAA protocols available, but the two most popular ones are Remote Authentication Dial-In User Service (RADIUS) and Terminal Access Controller Access-Control System Plus (TACACS+).

AAA is commonly used in the networking industry for the following two use cases:

  • Network device access control: As described earlier in this chapter, Cisco IOS provides local features for simple device access control, such as local username-based authentication and line password authentication. However, these features do not provide the same degree of access control and scalability that is possible with AAA. For this reason, AAA is the recommended method for access control. TACACS+ is the protocol of choice for network device access control.

  • Secure network access control: AAA can be used to obtain the identity of a device or user before that device or user is allowed to access to the network. RADIUS is the preferred protocol for secure network access. Secure network access control is covered in Chapter 25, “Secure Network Access Control.”

The following sections explain why TACACS+ is preferred for network access control while RADIUS is preferred for secure network access.

TACACS+

Cisco developed TACACS+ and released it as an open standard in the early 1990s. Although TACACS+ is mainly used for AAA device access control, it is possible to use it for some types of AAA network access.

The TACACS+ protocol uses Transmission Control Protocol (TCP) port 49 for communication between the TACACS+ clients and the TACACS+ server.

Figure 26-1 shows an end user who can access a Cisco switch using Telnet, SSH, or the console. The Cisco switch is acting as a TACACS+ client that communicates with the TACACS+ server using the TACACS+ protocol.

A figure shows a terminal user (laptop) connected to a TACACS plus Client (switch). The combination of the components is labeled "Telnet, SSH, Console." The TACACS plus Client is further connected to "TACACS plus Server (Cisco ISE)." The combination of TACACS plus Client and TACACS plus Server is labeled "TACACS plus."

Figure 26-1 TACACS+ Client/Server Communication

One of the key differentiators of TACACS+ is its capability to separate authentication, authorization, and accounting into independent functions. This is why TACACS+ is so commonly used for device administration instead of RADIUS, even though RADIUS is capable of providing network device access control.

RADIUS

RADIUS is an IETF standard AAA protocol. As with TACACS+, it follows a client/server model, where the client initiates the requests to the server. RADIUS is the AAA protocol of choice for secure network access. The reason for this is that RADIUS is the AAA transport protocol for Extensible Authentication Protocol (EAP), while TACACS+ does not support this functionality. EAP is used for secure network access and is covered in Chapter 23.

Another major difference between TACACS+ and RADIUS is that RADIUS needs to return all authorization parameters in a single reply, while TACACS+ can request authorization parameters separately and multiple times throughout a session.

For example, a network device, such as a Cisco switch or router, can request a TACACS+ server to individually authorize every command that a user tries to execute after logging in to the device. In contrast, RADIUS would require those commands to be sent in the initial authentication response, and since there could be thousands of CLI command combinations, a large authorization result list could trigger memory exhaustion on the network device. This is the main reason TACACS+ is preferred for network device access control. However, if all that is required is AAA authentication without authorization, then either RADIUS or TACACS+ can be used.

Table 26-4 provides a summary comparison of RADIUS and TACACS+.

Table 26-4 RADIUS and TACACS+ Comparison

Component

RADIUS

TACACS+

Protocol and port(s) used

Cisco’s implementation:

  • UDP: port 1645 (authentication and authorization)

  • UDP: port 1646 (accounting)

Industry standard:

  • UDP: port 1812 (authentication and authorization)

  • UDP: port 1813 (accounting)

TCP: port 49

Encryption

  • Encrypts only the password field

  • Supports EAP for 802.1x authentication

  • Encrypts the entire payload

  • Does not support EAP

Authentication and authorization

  • Combines authentication and authorization

  • Cannot be used to authorize which CLI commands can be executed individually

  • Separates authentication and authorization

  • Can be used for CLI command authorization

Accounting

Does not support network device CLI command accounting

Supports network device CLI command accounting

Primary use

Secure network access

Network device access control

For many years, the Cisco Secure Access Control Server (ACS) was the AAA server of choice for organizations that required TACACS+ for device administration and RADIUS for secure network access. However, starting with ISE 2.0, ISE has taken over as Cisco’s AAA server for both RADIUS and TACACS+.

Configuring AAA for Network Device Access Control

As previously mentioned, TACACS+ was designed for device access control by authenticating and authorizing users into network devices. There are two parts to configuring TACACS+:

  • The configuration of the device itself

  • The configuration of the TACACS+ AAA server (for example, Cisco ISE)

The following steps are for configuring an IOS device with TACACS+ for device access control. Configuration for the TACACS+ server is not included here because it is beyond the scope of this book:

Step 1. Create a local user with full privilege for fallback or to avoid being locked out after enabling AAA by using the command

         username {username} privilege 15 algorithm-type {md5 | sha256 | scrypt}
         secret {password}

Step 2. Enable AAA functions on by using with the command aaa new-model.

Step 3. Add a TACACS+ server using one of these methods, depending on the IOS version:

  • To add a TACACS+ server on IOS versions prior to 15.x, use the command

      tacacs-server host { hostname | host-ip-address } key key-string
  • To add a TACACS+ server on IOS versions 15.x and later, use the following commands:

      tacacs server name
      address ipv4 { hostname | host-ip-address }
      key key-string

Step 4. Create an AAA group by using the following commands:

         aaa group server tacacs+ group-name
         server name server-name

This creates an AAA group that includes the TACACS+ servers that are added to the group with the server name command.

Multiple server names can be added, and the order in which the servers are added to the group dictates the failover order, from top to bottom (that is, the first one added is the highest priority).

Step 5. Enable AAA login authentication by using the command

         aaa authentication login { default | custom-list-name } method1
         [ method2 . . . ]

Method lists enable login authentication. The default keyword applies the method lists that follow (method1 [ method2 . . .) to all lines (cty, tty, aux, and so on). The custom list-name CLI assigns a custom name for the method lists that follow it. This allows different types of lines to use different login authentication methods. To apply a custom list to a line, use the command login authentication custom-list-name under line configuration mode.

Method lists are applied sequentially from left to right. For example, in the command aaa authentication login default group ISE-TACACS+ local enable, the ISE-TACACS+ server group is used for authentication since it’s the first method listed, and if the TACACS+ servers become unavailable or are unavailable, local username-based authentication is used because it is the second method from left to right. If there are no usernames defined in the configuration, then the enable password, which is third in line, would be the last resort to log in; if there is no enable password configured, the user is effectively locked out.

Step 6. Enable AAA authorization for EXEC by using the command

         aaa authorization exec { default | custom-list-name } method1
           [ method2 . . . ]

This command enables EXEC shell authorization for all lines except the console line.

Step 7. Enable AAA authorization for the console by using the command

         aaa authorization console

Authorization for the console is disabled by default to prevent unexperienced users from locking themselves out.

Step 8. Enable AAA command authorization by using the command

         aaa authorization commands {privilege level} { default | custom-
           list-name } method1 [ method2 . . . ]

This command authorizes all commands with the AAA server before executing them. Command authorization is applied on a per-privilege-level basis, so, it is necessary to configure a command authorization method list for every privilege level that requires command authorization. Command authorization is commonly configured for levels 0, 1, and 15 only. The other levels, 2 through 14, are useful only for local authorization with the privilege level command. See Example 26-19 for a sample configuration.

Step 9. Enable command authorization in global configuration mode (and all global configuration submodes) by using the command

          aaa authorization config-commands

Step 10. Enable login accounting by using the command

          aaa accounting exec { default | custom-list-name } method1
             [ method2 . . . ]

It is common to use the keyword start-stop for AAA accounting. It causes accounting to start as soon as a session starts and stop as soon as the session ends.

Step 11. Enable command accounting by using the command

         aaa accounting commands {privilege level} { default | custom-list-name }
             method1 [ method2 . . . ]

Just as with authorization, command accounting is applied per privilege level, so it is necessary to configure a command accounting method list for every privilege level that requires command accounting.

Note

When all the AAA servers become unreachable, the AAA client falls back to one of the local methods for authentication (local, enable, or line), but AAA command authorization might still be trying to reach the AAA server to authorize the commands. This prevents a user from being able to execute any more commands because he or she isn’t authorized to use other commands. For this reason, it is recommended to include the if-authenticated method at the end of every single authorization command to allow all commands to be authorized as long as the user has successfully authenticated locally.

The if-authenticated method and the none method are mutually exclusive because the none method disables authorization.

Example 26-19 shows a common AAA IOS configuration for device access control.

Example 26-19 Common AAA Configuration for Device Access Control

aaa new-model

tacacs server ISE-PRIMARY
  address 10.10.10.1
  key my.S3cR3t.k3y

tacacs server ISE-SECONDARY
  address 20.20.20.1
  key my.S3cR3t.k3y

aaa group server tacacs+ ISE-TACACS+
  server name ise-primary
  server name ise-secondary

aaa authentication login default group ISE-TACACS+ local
aaa authentication login CONSOLE-CUSTOM-AUTHENTICATION-LIST local line enable
aaa authentication enable default group ISE-TACACS+ enable
aaa authorization exec default group ISE-TACACS+ if-authenticated
aaa authorization exec CONSOLE-CUSTOM-EXEC-AUTHORIZATION-LIST none
aaa authorization commands 0 CONSOLE-CUSTOM-COMMAND-AUTHORIZATION-LIST none
aaa authorization commands 1 CONSOLE-CUSTOM-COMMAND-AUTHORIZATION-LIST none
aaa authorization commands 15 CONSOLE-CUSTOM-COMMAND-AUTHORIZATION-LIST none
aaa authorization commands 0 default group ISE-TACACS+ if-authenticated
aaa authorization commands 1 default group ISE-TACACS+ if-authenticated
aaa authorization commands 15 default group ISE-TACACS+ if-authenticated
aaa authorization console
aaa authorization config-commands
aaa accounting exec default start-stop group ISE-TACACS+
aaa accounting commands 0 default start-stop group ISE-TACACS+
aaa accounting commands 1 default start-stop group ISE-TACACS+
aaa accounting commands 15 default start-stop group ISE-TACACS+

line con 0
authorization commands 0 CONSOLE-CUSTOM-COMMAND-AUTHORIZATION-LIST
authorization commands 1 CONSOLE-CUSTOM-COMMAND-AUTHORIZATION-LIST
authorization commands 15 CONSOLE-CUSTOM-COMMAND-AUTHORIZATION-LIST
authorization exec CONSOLE-CUSTOM-EXEC-AUTHORIZATION-LIST
privilege level 15
login authentication CONSOLE-CUSTOM-AUTHENTICATION-LIST

line vty 0 4
<uses default method-lists for AAA>

Apart from the IOS configuration, the AAA server also needs to be configured with the AAA client information (hostname, IP address, and key), the login credentials for the users, and the commands the users are authorized to execute on the device.

Verifying AAA Configuration

Example 26-20 demonstrates SSH sessions being initiated from R2 into R1, using the netadmin and netops accounts. The netadmin account was configured in the AAA server with privilege 15, and netops was configured with privilege 1. The netadmin account has access to the full set of commands, while netops is very limited.

Example 26-20 Verifying AAA Configuration

! Establish SSH session from R2 into R1 using netadmin account                       
R2# ssh [email protected]
Password:
R1# show privilege
Current privilege level is 15                                                        
R1#
R1# configure terminal
R1(config)#

! Establish SSH session from R2 into R1 using netops account                         
R2# ssh [email protected]
Password:
R1> show privilege
Current privilege level is 1                                                         
R1> show version
Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.6(3)M2,
RELEASE SOFTWARE (fc2)
! Output Omitted for Brevity

R1> show running-config
Command authorization failed.                                                        

R1> enable
Command authorization failed.                                                        

Zone-Based Firewall (ZBFW)

ACLs control access based on protocol, source IP address, destination IP address, and ports. Unfortunately, they are stateless and do not inspect a packet’s payload to detect whether attackers are using a port that they have found open. Stateful firewalls are capable of looking into Layers 4 through 7 of a network packet to verify the state of the transmission. A stateful firewall can detect whether a port is being piggybacked and can mitigate DDoS intrusions.

Cisco Zone-Based Firewall (ZBFW) is the latest integrated stateful firewall technology included in IOS. ZBFW reduces the need for a firewall at a branch site to provide stateful network security.

ZBFW uses a flexible and straightforward approach to providing security by establishing security zones. Router interfaces are assigned to a specific zone, which can maintain a one-to-one or many-to-one relationship. A zone establishes a security border on the network and defines acceptable traffic that is allowed to pass between zones. By default, interfaces in the same security zone can communicate freely with each other, but interfaces in different zones cannot communicate with each other.

Figure 26-2 illustrates the concept of ZBFW and the association of interfaces to a security zone.

A laptop, Internet (Cisco Webex and Salesforce), and two servers are connected to a router. The laptop region is labeled "Inside Security Zone"; the internet region is labeled "outside security zone"; and the servers region is labeled "DMZ security zone."

Figure 26-2 Zone-Based Firewall and Security Zones

Within the ZBFW architecture, there are two system-built zones: self and default.

The Self Zone

The self zone is a system-level zone and includes all the routers’ IP addresses. By default, traffic to and from this zone is permitted to support management (for example, SSH protocol, SNMP) and control plane (for example, EIGRP, BGP) functions.

After a policy is applied to the self zone and another security zone, interzone communication must be explicitly defined.

The Default Zone

The default zone is a system-level zone, and any interface that is not a member of another security zone is placed in this zone automatically.

When an interface that is not in a security zone sends traffic to an interface that is in a security zone, the traffic is dropped. Most network engineers assume that a policy cannot be configured to permit these traffic flows, but it can, if you enable the default zone. Upon initialization of this zone, any interface not associated to a security zone is placed in this zone. When the unassigned interfaces are in the default zone, a policy map can be created between the two security zones.

ZBFW Configuration

This section explains the process for configuring a ZBFW outside zone on an Internet-facing router interface. ZBFW is configured in five steps:

Step 1. Configure the security zones by using the command zone security zone-name. A zone needs to be created for the outside zone (the Internet). The self zone is defined automatically. Example 26-21 demonstrates the configuration of a security zone.

Example 26-21 Defining the Outside Security Zone

Zone security OUTSIDE
 description OUTSIDE Zone used for Internet Interfac

Step 2. Define the inspection class map. The class map for inspection defines a method for classification of traffic. The class map is configured using the command class-map type inspect [match-all | match-any] class-name. The match-all keyword requires that network traffic match all the conditions listed in the class map to qualify (Boolean AND), whereas match-any requires that network traffic match only one of the conditions in the class map to qualify (Boolean OR). If neither keyword is specified, the match-all function is selected. Example 26-22 shows a sample configuration of inspection class maps and their associated ACLs.

Example 26-22 Inspecting the Class Map Configuration

ip access-list extended ACL-IPSEC
 permit udp any any eq non500-isakmp
 permit udp any any eq isakmp
ip access-list extended ACL-PING-AND-TRACEROUTE
 permit icmp any any echo
 permit icmp any any echo-reply
 permit icmp any any ttl-exceeded
 permit icmp any any port-unreachable
 permit udp any any range 33434 33463 ttl eq 1
ip access-list extended ACL-ESP
 permit esp any any
ip access-list extended ACL-DHCP-IN
 permit udp any eq bootps any eq bootpc
ip access-list extended ACL-GRE
 permit gre any any
!

class-map type inspect match-any CLASS-OUTSIDE-TO-SELF-INSPECT
 match access-group name ACL-IPSEC
 match access-group name ACL-PING-AND-TRACEROUTE
class-map type inspect match-any CLASS-OUTSIDE-TO-SELF-PASS
 match access-group name ACL-ESP
 match access-group name ACL-DHCP-IN
 match access-group name ACL-GR

The configuration of inspect class maps can be verified with the command show class-map type inspect [class-name], as shown in Example 26-23.

Example 26-23 Verifying the Inspect Class Map Configuration

R1# show class-map type inspect
 Class Map type inspect match-any CLASS-OUTSIDE-TO-SELF-PASS (id 2)
   Match access-group name ACL-ESP
   Match access-group name ACL-DHCP-IN
   Match access-group name ACL-GRE

 Class Map type inspect match-any CLASS-OUTSIDE-TO-SELF-INSPECT (id 1)
   Match access-group name ACL-IPSEC
   Match access-group name ACL-PING-AND-TRACEROUTE

Step 3. Define the inspection policy map, which applies firewall policy actions to the class maps defined in the policy map. The policy map is then associated to a zone pair.

The inspection policy map is defined with the command policy-map type inspect policy-name. After the policy map is defined, the various class maps are defined with the command class type inspect class-name. Under the class map, the firewall action is defined with these commands:

  • drop [log]: This default action silently discards packets that match the class map. The log keyword adds syslog information that includes source and destination information (IP address, port, and protocol).

  • pass [log]: This action makes the router forward packets from the source zone to the destination zone. Packets are forwarded in only one direction. A policy must be applied for traffic to be forwarded in the opposite direction. The pass action is useful for protocols like IPsec, Encapsulating Security Payload (ESP), and other inherently secure protocols with predictable behavior. The optional log keyword adds syslog information that includes the source and destination information.

  • inspect: The inspect action offers state-based traffic control. The router maintains connection/session information and permits return traffic from the destination zone without the need to specify it in a second policy.

The inspect policy map has an implicit class default that uses a default drop action. This provides the same implicit “deny all” as an ACL. Adding it to the configuration may simplify troubleshooting for junior network engineers.

Example 26-24 demonstrates the configuration of the inspect policy map. Notice that in the class default class, the drop command does not include the log keyword because of the potential to fill up the syslog.

Example 26-24 Configuring the Inspection Policy Map

policy-map type inspect POLICY-OUTSIDE-TO-SELF
 class type inspect CLASS-OUTSIDE-TO-SELF-INSPECT
   inspect
 class type inspect CLASS-OUTSIDE-TO-SELF-PASS
   pass
 class class-default
   drop

The inspection policy map can be verified with the command show policy-map type inspect [policy-name], as shown in Example 26-25.

Example 26-25 Verifying the Inspection Policy Map

R1# show policy-map type inspect
  Policy Map type inspect POLICY-OUTSIDE-TO-SELF
    Class CLASS-OUTSIDE-TO-SELF-INSPECT
      Inspect
    Class CLASS-OUTSIDE-TO-SELF-PASS
      Pass
    Class class-default
      Drop

Step 4. Apply a policy map to a traffic flow source to a destination by using the command zone-pair security zone-pair-name source source-zone-name destination destination-zone-name. The inspection policy map is then applied to the zone pair with the command service-policy type inspect policy-name. Traffic is statefully inspected between the source and destination, and return traffic is allowed. Example 26-26 defines the zone pairs and associates the policy map to the zone pair.

Example 26-26 Configuring the ZBFW Zone Pair

zone-pair security OUTSIDE-TO-SELF source OUTSIDE destination self
  service-policy type inspect POLICY-OUTSIDE-TO-SELF

Note

The order of the zone pair is significant; the first zone indicates the source zone, and the second zone indicates the destination zone. A second zone pair needs to be created with bidirectional traffic patterns when the pass action is selected.

Step 5. Apply the security zones to the appropriate interfaces. An interface is assigned to the appropriate zone by entering the interface configuration submode with the command interface interface-id and associating the interface to the correct zone with the command zone-member security zone-name, as defined in step 1.

Example 26-27 demonstrates the outside security zone being associated to the Internet-facing interface GigabitEthernet 0/2.

Example 26-27 Applying the Security Zone to the Interface

interface GigabitEthernet 0/2
  zone-member security OUTSID

Now that the outside-to-self policy has been fully defined, traffic statistics can be viewed with the command show policy-map type inspect zone-pair [zone-pair-name]. Example 26-28 demonstrates the verification of the configured ZBFW policy.

Example 26-28 Verifying the Outside-to-Self Policy

R1# show policy-map type inspect zone-pair

policy exists on zp OUTSIDE-TO-SELF
  Zone-pair: OUTSIDE-TO-SELF

  Service-policy inspect : POLICY-OUTSIDE-TO-SELF

    Class-map: CLASS-OUTSIDE-TO-SELF-INSPECT (match-any)
      Match: access-group name ACL-IPSEC
        2 packets, 208 bytes
        30 second rate 0 bps
      Match: access-group name ACL-PING-AND-TRACEROUTE
        0 packets, 0 bytes
        30 second rate 0 bps

   Inspect
        Packet inspection statistics [process switch:fast switch]
        udp packets: [4:8]

        Session creations since subsystem startup or last reset 2
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [2:1:0]
        Last session created 00:03:39
        Last statistic reset never
        Last session creation rate 0
        Maxever session creation rate 2
        Last half-open session total 0
        TCP reassembly statistics
        received 0 packets out-of-order; dropped 0
        peak memory usage 0 KB; current usage: 0 KB
        peak queue length 0

    Class-map: CLASS-OUTSIDE-TO-SELF-PASS (match-any)
      Match: access-group name ACL-ESP
        186 packets, 22552 bytes
        30 second rate 0 bps
      Match: access-group name ACL-DHCP-IN
        1 packets, 308 bytes
        30 second rate 0 bps
      Match: access-group name ACL-GRE
        0 packets, 0 bytes
        30 second rate 0 bps
      Pass
        187 packets, 22860 bytes

    Class-map: class-default (match-any)
      Match: any
      Drop
        30 packets, 720 bytes

Note

Making the class maps more explicit and thereby adding more of the explicit class maps to the policy map provides more visibility to the metrics.

Even though the ACLs are not used for blocking traffic, the counters do increase as packets match the ACL entries for the inspect class maps, as demonstrated in Example 26-29.

Example 26-29 ACL Counters from the Inspect Class Maps

R1# show ip access
Extended IP access list ACL-DHCP-IN
    10 permit udp any eq bootps any eq bootpc (1 match)
Extended IP access list ACL-ESP
    10 permit esp any any (170 matches)
Extended IP access list ACL-GRE
    10 permit gre any any
Extended IP access list ACL-IPSEC
    10 permit udp any any eq non500-isakmp
    20 permit udp any any eq isakmp (2 matches)
Extended IP access list ACL-PING-AND-TRACEROUTE
    10 permit icmp any any echo
    20 permit icmp any any echo-reply
    30 permit icmp any any ttl-exceeded
    40 permit icmp any any port-unreachable
    50 permit udp any any range 33434 33463 ttl eq

Verifying ZBFW

After the outside-to-self policy has been defined, it is time to verify connectivity to the Internet, as shown in Example 26-30. Notice here that a simple ping from R1 to one of Google’s Public DNS IP addresses 8.8.8.8 is failing.

Example 26-30 Verifying Outside Connectivity

R1# ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
.....                                                                                
Success rate is 0 percent (0/5)                                                      

The reason for the packet failure is that the router needs to allow locally originated packets with a self-to-outside policy. Example 26-31 demonstrates the configuration for the self-to-outside policy. ACL-IPSEC and ACL-ESP are reused from the outside-to-self policy.

Example 26-31 Configuring the Self-to-Outside Policy

ip access-list extended ACL-DHCP-OUT
permit udp any eq bootpc any eq bootps
!
ip access-list extended ACL-ICMP
permit icmp any any
!
class-map type inspect match-any CLASS-SELF-TO-OUTSIDE-INSPECT
 match access-group name ACL-IPSEC
 match access-group name ACL-ICMP

class-map type inspect match-any CLASS-SELF-TO-OUTSIDE-PASS
 match access-group name ACL-ESP
 match access-group name ACL-DHCP-OUT
!
policy-map type inspect POLICY-SELF-TO-OUTSIDE
  class type inspect CLASS-SELF-TO-OUTSIDE-INSPECT
   inspect
class type inspect CLASS-SELF-TO-OUTSIDE-PASS
   pass
class class-default
  drop log
!
zone-pair security SELF-TO-OUTSIDE source self destination OUTSIDE
 service-policy type inspect POLICY-SELF-TO-OUTSID

Now that the second policy has been configured, R1 can successfully ping 8.8.8.8, as shown in Example 26-32.

Example 26-32 Successful ping Test Between R1 and Google’s Public DNS 8.8.8.8

R31-Spoke# ping 8.8.8.8
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Control Plane Policing (CoPP)

A control plane policing (CoPP) policy is a QoS policy that is applied to traffic to or sourced by the router’s control plane CPU. CoPP policies are used to limit known traffic to a given rate while protecting the CPU from unexpected extreme rates of traffic that could impact the stability of the router.

Typical CoPP implementations use only an input policy that allows traffic to the control plane to be policed to a desired rate. In a properly planned CoPP policy, network traffic is placed into various classes, based on the type of traffic (management, routing protocols, or known IP addresses). The CoPP policy is then implemented to limit traffic to the control plane CPU to a specific rate for each class.

When defining a rate for a CoPP policy, the rate for a class may not be known without further investigation. The QoS police command uses conform, exceed, and violate actions, which can be configured to transmit or drop traffic. By choosing to transmit traffic that exceeds the policed rate, and monitoring CoPP, the policy can be adjusted over time to meet day-to-day requirements.

Understanding what is needed to define a traffic class can be achieved from protocol documentation or by performing network protocol analysis. The Cisco Embedded Packet Capture (EPC) feature can be used for this purpose because it allows you to capture network traffic and export it to a PCAP file to identify the necessary traffic classes.

Configuring ACLs for CoPP

After the network traffic has been identified, ACLs can be built for matching in a class map.

Example 26-33 demonstrates a list of ACLs matching traffic identified by EPC and network documentation. Notice that these ACLs do not restrict access and are open, allowing anyone to send traffic matching the protocols. For some types of external network traffic (such as BGP), the external network address can change and is better managed from a ZBFW perspective. A majority of these protocols are accessed only using controlled internal prefixes, minimizing the intrusion surface. Management protocols are an area that can easily be controlled by using a few jump boxes for direct access and limiting SNMP and other management protocols to a specific range of addresses residing in the NOC.

Example 26-33 Configuring an Access List for CoPP

ip access-list extended ACL-CoPP-ICMP
 permit icmp any any echo-reply
 permit icmp any any ttl-exceeded
 permit icmp any any unreachable
 permit icmp any any echo
 permit udp any any range 33434 33463 ttl eq 1
!
ip access-list extended ACL-CoPP-IPsec
 permit esp any any
 permit gre any any
 permit udp any eq isakmp any eq isakmp
 permit udp any any eq non500-isakmp
 permit udp any eq non500-isakmp any
!
ip access-list extended ACL-CoPP-Initialize
 permit udp any eq bootps any eq bootpc
!
ip access-list extended ACL-CoPP-Management
 permit udp any eq ntp any
 permit udp any any eq snmp
 permit tcp any any eq 22
 permit tcp any eq 22 any established
!
ip access-list extended ACL-CoPP-Routing
 permit tcp any eq bgp any established
 permit eigrp any host 224.0.0.10
 permit ospf any host 224.0.0.5
 permit ospf any host 224.0.0.6
 permit pim any host 224.0.0.13
 permit igmp any any

Note

The ACL-CoPP-Routing ACL in Example 26-33 does not classify unicast routing protocol packets such as unicast PIM, unicast OSPF, and unicast EIGRP.

Configuring Class Maps for CoPP

The class configuration for CoPP uses the ACLs to match known protocols being used and is demonstrated in Example 26-34.

Example 26-34 Class Configuration for CoPP

class-map match-all CLASS-CoPP-IPsec
 match access-group name ACL-CoPP-IPsec
class-map match-all CLASS-CoPP-Routing
 match access-group name ACL-CoPP-Routing
class-map match-all CLASS-CoPP-Initialize
 match access-group name ACL-CoPP-Initialize
class-map match-all CLASS-CoPP-Management
 match access-group name ACL-CoPP-Management
class-map match-all CLASS-CoPP-ICMP
 match access-group name ACL-CoPP-ICM

Configuring the Policy Map for CoPP

The policy map for how the classes operate shows how to police traffic to a given rate in order to minimize any ability to overload the router. However, finding the correct rate without impacting network stability is not a simple task. In order to guarantee that CoPP does not introduce issues, the violate action is set to transmit for all the vital classes until a baseline for normal traffic flows is established. Over time, the rate can be adjusted. Other traffic, such as ICMP and DHCP traffic, is set to drop as it should have low packet rates.

In the policy map, the class default exists and contains any unknown traffic. Under normal conditions, nothing should exist within the class default, but allowing a minimal amount of traffic within this class and monitoring the policy permits discovery of new or unknown traffic that would have otherwise been denied. Example 26-35 shows the CoPP policy.

Example 26-35 Policy Configuration for CoPP

policy-map POLICY-CoPP
 class CLASS-CoPP-ICMP
  police 8000 conform-action transmit  exceed-action transmit
         violate-action drop
 class CLASS-CoPP-IPsec
  police 64000 conform-action transmit  exceed-action transmit
         violate-action transmit
 class CLASS-CoPP-Initialize
  police 8000 conform-action transmit  exceed-action transmit
         violate-action drop
 class CLASS-CoPP-Management
  police 32000 conform-action transmit  exceed-action transmit
         violate-action transmit
 class CLASS-CoPP-Routing
  police 64000 conform-action transmit  exceed-action transmit
         violate-action transmit
 class class-default
  police 8000 conform-action transmit  exceed-action transmit
         violate-action drop

Note

Keep in mind that the policy needs to be tweaked based on the routing protocols in use in the network.

Applying the CoPP Policy Map

The CoPP policy map needs to be applied to the control plane with the command service-policy {input|output} policy-name under control plane configuration mode, as demonstrated in Example 26-36.

Example 26-36 Applying the Policy for CoPP

control-plane
 Service-policy input POLICY-CoP

Verifying the CoPP Policy

After the policy map has been applied to the control plane, it needs to be verified. In Example 26-37, traffic matching CLASS-CoPP-Routing has exceeded the configured rate. In addition, the default class sees traffic. To identify what is happening, EPC could be used again to tweak the policies, if necessary. This time, the access lists can be reversed from permit to deny as the filter to gather unexpected traffic.

Example 26-37 Verifying the Policy for CoPP

R1# show policy-map control-plane input
 Control Plane

  Service-policy input: POLICY-CoPP

    Class-map: CLASS-CoPP-ICMP (match-all)
      154 packets, 8912 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL-CoPP-ICMP
      police:
          cir 8000 bps, bc 1500 bytes, be 1500 bytes
        conformed 154 packets, 8912 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          transmit
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps

    Class-map: CLASS-CoPP-IPsec (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL-CoPP-IPsec
      police:
          cir 64000 bps, bc 2000 bytes, be 2000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          transmit
        violated 0 packets, 0 bytes; actions:
          transmit
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps

    Class-map: CLASS-CoPP-Initialize (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bp

      Match: access-group name ACL-CoPP-Initialize
      police:
          cir 8000 bps, bc 1500 bytes, be 1500 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          transmit
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps

    Class-map: CLASS-CoPP-Management (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL-CoPP-Management
      police:
          cir 32000 bps, bc 1500 bytes, be 1500 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          transmit
        violated 0 packets, 0 bytes; actions:
          transmit
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps

    Class-map: CLASS-CoPP-Routing (match-all)
      92 packets, 123557 bytes
      5 minute offered rate 4000 bps, drop rate 0000 bps
      Match: access-group name ACL-CoPP-Routing
      police:
          cir 64000 bps, bc 2000 bytes, be 2000 bytes
        conformed 5 packets, 3236 bytes; actions:
          transmit
        exceeded 1 packets, 1383 bytes; actions:
          transmit
        violated 86 packets, 118938 bytes; actions:
          transmit
        conformed 1000 bps, exceeded 1000 bps, violated 4000 bps
    Class-map: class-default (match-any)
      56 packets, 20464 bytes
      5 minute offered rate 1000 bps, drop rate 0000 bps
      Match: any
      police:
          cir 8000 bps, bc 1500 bytes, be 1500 bytes
        conformed 5 packets, 2061 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          transmit
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps

Device Hardening

In addition to all the features discussed in this chapter for providing device access control and protection, such as AAA, CoPP, and ZBFW on the routers, disabling unused services and features improves the overall security posture by minimizing the amount of information exposed externally. In addition, hardening a router reduces the amount of router CPU and memory utilization that would be required to process these unnecessary packets.

This section provides a list of additional commands that can be used to harden a router. All interface-specific commands are applied only to the interface connected to the public network. Consider the following device hardening measures:

  • Disable topology discovery tools: Tools such as Cisco Discovery Protocol (CDP) and Link Layer Discovery Protocol (LLDP) can provide unnecessary information to routers outside your control. The services can be disabled with the interface parameter commands no cdp enable, no lldp transmit, and no lldp receive.

  • Disable TCP and UDP small services: The commands service tcp-keepalive-in and service tcp-keepalive-out ensure that devices send TCP keepalives for inbound/outbound TCP sessions. This ensures that the device on the remote end of the connection is still accessible and that half-open or orphaned connections are removed from the local device.

  • Disable IP redirect services: An ICMP redirect is used to inform a device of a better path to the destination network. An IOS device sends an ICMP redirect if it detects network traffic hairpinning on it. This behavior is disabled with the interface parameter command no ip redirects.

  • Disable proxy Address Resolution Protocol (ARP): Proxy ARP is a technique that a router uses to answer ARP requests intended for a different router. The router fakes its identity and sends out an ARP response for the router that is responsible for that network. A man-in-the-middle intrusion enables a host on the network with a spoofed MAC address of the router and allows traffic to be sent to the hacker. Disabling proxy ARP on the interface is recommended and accomplished with the command no ip proxy-arp.

  • Disable service configuration: Cisco devices support automatic configuration from remote devices through TFTP and other methods. This service should be disabled with the command no service config.

  • Disable the Maintenance Operation Protocol (MOP) service: The MOP service is not needed and should be disabled globally with the command no mop enabled and with the interface parameter command no mop enabled.

  • Disable the packet assembler/disassembler (PAD) service: The PAD service is used for X.25 and is not needed. It can be disabled with the command no service pad.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 30, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in the chapter, noted with the key topics icon in the outer margin of the page. Table 26-5 lists these key topics and the page number on which each is found.

Table 26-5 Key Topics for Chapter 26

Key Topic Element

Description

Page

Section

Access control lists (ACLs)

749

List

ACL categories

749

Paragraph

Applying ACL to an interface

750

List

CLI access methods

756

List

Line password protection options

756

Section

Password types

757

List

Local username configuration options

758

List

Privilege levels

761

List

SSH versions

768

List

Authentication, authorization, and accounting (AAA)

770

List

AAA primary use cases

771

Paragraph

TACACS+ key differentiator

772

Paragraph

RADIUS key differentiators

772

Paragraph

Zone-Based Firewall (ZBFW)

777

Paragraph

ZBFW default zones

777

Section

Control plane policing (CoPP)

784

Complete Tables and Lists from Memory

Print a copy of Appendix B, “Memory Tables” (found on the companion website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix C, “Memory Tables Answer Key,” also on the companion website, includes completed tables and lists you can use to check your work.

Define Key Terms

Define the following key terms from this chapter and check your answers in the Glossary:

access controls list (ACL)

authentication, authorization, and accounting (AAA)

control plan policing (CoPP)

privilege level

Remote Authentication Dial-in User Service (RADIUS)

Secure Shell (SSH)

Telnet

Terminal Access Controller Access-Control System Plus (TACACS+)

Zone-Based Firewall (ZBFW)

Use the Command Reference to Check Your Memory

Table 26-6 lists the important commands from this chapter. To test your memory, cover the right side of the table with a piece of paper, read the description on the left side, and see how much of the command you can remember.

Table 26-6 Command Reference

Task

Command Syntax

Apply an ACL to an interface

ip access-group {access-list-number | name} {in|out}

Apply an ACL to a vty line

access-class {access-list-number|access-list-name} {in|out}

Encrypt type 0 passwords in the configuration

service password-encryption

Create a username with a type 8 and type 9 password option

username {username} algorithm-type {md5 | sha256 | scrypt} secret {password}

Enable username and password authentication on vty lines

login local

Change command privilege levels

privilege {mode} level {level}{command string}

Allow only SSH for a vty line without using an ACL

transport input ssh

Enable SSHv2 on a router

hostname {hostname name}ip domain-name {domain-name}crypto key generate rsa

Disconnect terminal line users that are idle

exec-timeout {minutes} {seconds}

Enable AAA

aaa new-model

Enable AAA authorization for the console line

aaa authorization console

AAA fallback authorization method that authorizes commands if user is successfully authenticated

if-authenticated

Enable AAA authorization for config commands

aaa authorization config-commands

Apply a ZBFW security zone to an interface

zone-member security zone-name

Apply an inspection policy map to a zonepair

service-policy type inspect policy-name

Apply a CoPP policy map to the control plane (two commands)

control planeservice-policy {input|output} policy-name

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.90.202.157