CCNA Security Chapter 4 ACLs 筆記

CCNA Security Chapter 4-ACLs

Access control lists (ACLs) are widely used in computer networking and in network security for mitigating network attacks and controlling network traffic.

Configuring Standard and Extended ACLs with CLI

Standard ACLs : ACLs numbered 1-99 or 1300-1999 are standard IPv4 ACLs. Standard       ACLs match packets by examining the source IP address field in the IP header of that packet. These ACLs are used to filter packets based solely on Layer 3 source information.

Syntax for Standard ACLs:

Router(config)# access-list {1-99} {permit|deny} source-addr [source-wildcard]

Extended ACLs: Give greater flexibility and control over network access than standard 

                           ACLs.

Syntax for Extended ACLs:

Router(config)# access-list {100-199} {permit|deny} protocol source-addr [source-wildcard]

                         [operator operand] destination-addr [destination-wildcard] [operator operand]

                         [established]

It is possible to create a named ACL instead of a numbered ACL. Named ACLs must be specified as either standard or extended. 

Router(config)# ip access-list [standard | extended] name_of_ACL

Once the ACL statements are created, the administrator activates the ACL on an interface with the ip access-group command, specifying the name of the ACL.

Router(config-if)# ip access-group access-list-name {in | out}

Using Standard and Extended ACLs

Determining whether to use standard or extended ACLs is based on the overall objective of the entire ACL. 

For Example :

A scenario in which all traffic from a single subnet, 172.16.4.0, must be denied access to another subnet, but all other traffic should be permitted. 

A standard ACL can be applied outbound on interface Fa0/0:

R1(config)# access-list 1 deny 172.16.4.0 0.0.0.255

R1(config)# access-list 1 permit any

R1(config)# interface FastEthernet 0/0

R1(config-if)# ip access-group 1 out

As compared to standard ACLs, extended ACLs allow for specific types of traffic to be denied or permitted. 

For Example :

A scenario in which FTP traffic from one subnet must be denied on another subnet. In this case, an extended ACL is required because a specific traffic type is filtered. 

R1(config)# access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 21

R1(config)# access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 20

R1(config)# access-list 101 permit ip any any

After an ACL is created and applied, editing that ACL requires special attention. 

For example :

Delete a specific entry (ACE) from a numbered ACL, specifying the no parameter followed by the ACE will result in deleting the entire ACL. 

Router# configure terminal

Router(config)# no access-list 101

Topology and Flow for ACLs

Inbound ACLs

Outbound ACLs

In addition to flow, it is important to keep the placement of ACLs in mind. Placement depends on the type of ACL being used.

Standard ACL placement - Standard ACLs are placed as close to the destination as possible. Standard ACLs filter packets based on the source address only. Placing these ACLs too close to the source can adversely affect packets by denying all traffic, including valid traffic. 

Extended ACL placement - Extended ACLs are placed on routers as close as possible to the source that is being filtered. Placing Extended ACLs too far from the source is an inefficient use of network resources. For example, packets can be sent a long way only to be dropped or denied.

Configuring TCP Established and Reflexive ACLs

The syntax for the TCP established option in a numbered extended IP ACL is as follows:

Router(config)# access-list {100-199} {permit | deny} protocol source-addr [source-wildcard] [operator operand] destination-addr [destination-wildcard] [operator operand] [established]

The established keyword forces the router to check whether the TCP ACK or RST control flag is set. If the ACK flag is set, the TCP traffic is allowed in. 

The established option does not apply to UDP or ICMP traffic because UDP and ICMP traffic does not rely on any control flags as used with TCP traffic

Configuring Dynamic ACLs

Dynamic ACLs, also known as lock-and-key ACLs

One reason to use dynamic ACLs is to provide a specific remote user or group of remote users access to a host within the network. Another reason to use dynamic ACLs is when a subset of hosts on a local network needs to access a host on a remote network that is protected by a firewall. 

Dynamic ACLs offer these security benefits over standard and static Extended ACLs: 

• Challenge mechanism to authenticate individual users
• Simplified management in large internetworks
• Reduced router processing for ACLs
• Less opportunity for network break-ins by network hackers
• Creation of dynamic user access through a firewall, without compromising other configured security restrictions

A combination of user-prompted and automated device activities occur when a dynamic ACL is implemented and invoked.

First, a remote user must open a Telnet or SSH connection to the router. The external ACL of the router must permit this connection. The router prompts the user for a username and password, which the user must enter.

Next, the router authenticates the connection using either the local username database defined with username commands, an AAA server using RADIUS or TACACS+, or the password command on the vty lines. If the authentication is successful, the Telnet or SSH connection is terminated, because the function of the connection is for authentication only. 

After the user successfully authenticates, Cisco IOS adds a dynamic ACL entry that grants the user access to the configured internal resources. It is not possible to set up per-user access policies. Instead, the administrator defines one policy for all dynamic ACL users, and this single policy is applied to all the authenticated users.

Finally, the user can access the internal resources that would otherwise be denied without the dynamic ACL entry.

There are a few basic steps for setting up a dynamic ACL: 

1. Create an Extended ACL
2. Define the authentication. 
3. Enable the dynamic authentication method.

Example :

Step 1:
R3(config)# username Student password 0 cisco

Step 2:
R3(config)# access-list 101 permit tcp any host 10.2.2.2 eq telnet
R3(config)# access-list 101  dynamic testlist timeout 15 permit ip 192.168.10.0 0.0.255 192.168.30.0 0.0.255

Step 3:
R3(config)# interface serial 0/0/1
R3(config-if)# ip access-group 101 in

Step 4:
R3(config)# line vty 0 4
R3(config-line)# login local

R3(config-line)# autocommand access-enable host timeout 5

Configuring Time-Based ACLs
Time-based ACLs offer the security professional more control over permitting or denying access to resources. Sometimes it is necessary to open a hole in the filter of a router to allow a specific type of traffic. This hole should not be allowed to remain indefinitely. For example, users could be allowed to access the Internet during lunch, but not during regular business hours. Timed ACLs enable the enforcement of this kind of policy.

Time-based ACLs are an extension of numbered and named Extended ACLs. The administrator creates time-based entries and uses the time-range parameter to specify the period of time that the ACL statement is valid. The period of time specified can be recurring or a specific instance that happens only once.


These are the commands for creating a time range:

Router(config)# time-range time_range_name
Router(config-time-range)# absolute [start_time start_date] [end_time end_date]
Router(config-time-range)# periodic day_of_the_week hh:mm to [day_of_the_week] hh:mm

The absolute command specifies a single time period for which the time range is valid. ACL statements that reference this time range are not used after this period.

The periodic command specifies a recurring time period for which the time range is valid. Multiple periodic commands are permitted within the same time range.

• Monday
• Tuesday
• Wednesday
• Thursday
• Friday
• Saturday
• Sunday
• daily (every day)
• weekdays (Monday through Friday)
• weekend (Saturday and Sunday)

Scenario :

A network administrator has a situation that requires time-based ACLs. Users are not allowed to access the Internet during business hours, except during lunch and after hours until 7 p.m. when the office closes. This is a time-based ACL that supports the requirement: 

R1(config)# time-range employee-time

R1(config-time-range)# periodic weekdays 12:00 to 13:00

R1(config-time-range)# periodic weekdays 17:00 to 19:00

R1(config-time-range)# exit

R1(config)# access-list 100 permit ip 192.168.1.0 0.0.0.255 any time-range employee-time

R1(config)# access-list 100 deny ip any any

R1(config)# interface FastEthernet 0/1

R1(config-if)# ip access-group 100 in

R1(config-if)# exit

Troubleshooting Complex ACL implementations

Verify ACL configuration, use the show access-lists command.

Router# show access-lists [access-list-number | access-list-name] 

The command output shows how many packets have been matched against each entry in the ACLs, enabling the user to monitor the particular packets that have been permitted or denied. 

To troubleshoot an ACL configuration, use the debug ip packet command. 

Router# debug ip packet [access-list-number] [detail]

The debug ip packet command is useful for analyzing the messages traveling between the local and remote hosts. IP packet debugging captures the packets that are process-switched, including received, generated, and forwarded packets.

The detail option displays detailed IP packet debugging information. This information includes the packet types and codes as well as source and destination port numbers.

Mitigating Attacks with ACLs

ACLs can be used to mitigate many network threats:

• IP address spoofing, inbound and outbound
• DoS TCP SYN attacks
• DoS smurf attacks

ACLs can also filter the following traffic:

• ICMP messages, inbound and outbound
• traceroute

Hackers use several ICMP message types to attack networks. However, various management applications use ICMP messages to gather information. Network management uses ICMP messages that are automatically generated by the router.

Hackers can use ICMP echo packets to discover subnets and hosts on a protected network and to generate DoS flood attacks. Hackers can use ICMP redirect messages to alter host routing tables. Both ICMP echo and redirect messages should be blocked inbound by the router.

Several ICMP messages are recommended for proper network operation and should be allowed inbound:

• Echo reply - Allows users to ping external hosts.
• Source quench - Requests the sender to decrease the traffic rate of messages.
• Unreachable - Unreachable messages are generated for packets that are administratively denied by an ACL.

Several ICMP messages are required for proper network operation and should be allowed outbound:

• Echo - Allows users to ping external hosts.
• Parameter problem - Informs the host of packet header problems.
• Packet too big - Required for packet maximum transmission unit (MTU) discovery.
• Source quench - Throttles down traffic when necessary.

As a rule, block all other ICMP message types outbound. 

ACLs are used to block IP address spoofing, selectively permit specific services through a firewall, and to allow only required ICMP messages. 

Management protocols such as SNMP, while useful for remote monitoring and management of networked devices, can be exploited. If SNMP is necessary, exploitation of SNMP vulnerabilities can be mitigated by applying interface ACLs to filter SNMP packets from non-authorized systems. The ACL can then permit known source addresses that are destined for the IOS device itself, such as those devices within a management network. It should be noted that an exploit may still be possible if the SNMP packet is sourced from an address that has been spoofed and is permitted by the ACL. 

While these security measures are helpful, the most effective means of exploitation prevention is to disable the SNMP server on IOS devices that do not require it. To disable SNMP processing on the Cisco IOS devices, issue the command:

Router(config)# no snmp-server

IPv6 ACLs

Many networks have begun the transition to an IPv6 environment. Part of the need for the transition to IPv6 is because of the weaknesses inherent in IPv4. IPv4 was designed without a number of modern-day network requirements such as:

• Security - IPsec
• Device roaming - Mobile IP
• Quality of service - RSVP
• Address scarcity - DHCP, NAT, CIDR, VLSM

The standard ACL functionality in IPv6 is similar to standard ACLs in IPv4. These ACLs determine what traffic is blocked and what traffic is forwarded at router interfaces. They allow filtering based on source and destination addresses, inbound and outbound to a specific interface. IPv6 ACLs are defined using the ipv6 access-list command with the deny and permit keywords in global configuration mode. 

Router(config)# ipv6 access-list access-list-name

Configure each access list entry to specifically permit or deny traffic. 

Router(config-ipv6-acl)# {permit | deny} protocol {source-ipv6-prefix/prefix-length | any | host source-ipv6-address | auth} [operator [port-number]] {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address | auth} [operator [port-number]]

After the ACL statements are created, the administrator activates the ACL on an interface with the ipv6 traffic-filter command, specifying the name of the ACL and the direction of traffic to which the ACL applies. 

Router(config-if)# ipv6 traffic-filter access-list-name {in | out}

Using Object Group in ACEs

In large networks, ACLs can be large (hundreds of lines) and difficult to configure and manage, especially if the ACLs frequently change. 

Object group-based ACLs are smaller, more readable, and easier to configure and manage than conventional ACLs. 

The following guidelines and limitations apply to object groups:

• Object groups must have unique names.
• Additional objects can be appended to existing object groups
• Objects such as hosts, services, protocols can be grouped
• You cannot delete an object group or make an object group empty if it is being used in an ACE. 

Network and Service Object Group

A network object group is a group of any of the following objects: 

• Hostnames, IP addresses, or subnets
• Ranges of IP addresses
• Existing network object groups

To create a network group, enter the following commands:

Router(config)# object-group network nw_grp_id

Router(config-network-group)# description description-text | host {host-address | host-name} | network-address {/prefix-length | network-mask} | range host-address1 host-address2 | any | group-object nested-object-group-name

A service object group is a group of any of the following objects: 

• Top-level protocols (such as TCP, UDP, or ESP)
• Source and destination protocol ports (such as Telnet or SNMP)
• ICMP types (such as echo, echo-reply, or host-unreachable)
• Existing service object groups

To create a service group, enter the following commands:

Router(config)# object-group service svc_grp_id 

Router(config-service-group)# protocol | [tcp | udp | tcp-udp [source {{[eq]| lt | gt} port1 | range port1 port2}] [{[eq]| lt | gt} port1 | range port1 port2]] | icmp icmp-type

Reference :

1) CCNA Security Cisco Network Academy