Pages

Tuesday 4 May 2021

Access Control Lists (ACLs)

Contents

  1. Introduction and Overview
  2. Standard ACLs
  3. Extended ACLs
  4. Time-based ACLs
  5. Infrastructure ACLs
  6. Reflexive ACLs
  7. Dynamic ACLs
  8. Other ACL Features
  9. IPv6

Introduction and Overview

An Access Control List (ACL) is a sequential list of rules containing permit or/and deny statements, that are used to match packets. When applied to interfaces, ACLs are used to perform a network control service. Each rule in the ACL is known as an Access Control Entry (ACE); sometimes referred to as ACL statements. Each ACE can permit or deny specific traffic. Depending on the type of ACL, each ACE contains match criteria that packets transiting the device are subjected to such as:

  • Source and destination IP address
  • IP protocols such as TCP, UDP, ICMP, OSPF, EIGRP etc
  • TCP/UDP source and destination port numbers

The original intent when introducing ACLs was packet filtering. ACLs have since been deployed to provide multiple network functions such as:

  • Quality of Server (QoS) operations such as queueing, traffic classification for policing
  • Policy-based routing (PBR)
  • Route maps
  • Network identification in routing protocols
  • Route modification/filtering
  • Management plane restrictions such as Telnet, SSH, VPN
  • Object tracking

Processing of ACLs

The following description of ACLs applies to ACLs in packet filtering. Reference may be made to the application of ACLs in other features supported by routers or multi-layer switches.

The most common application of ACLs, in enterprise networks, is in packet filtering. By default, routers do not filter traffic; they examine the destination IP address of an IPv4/IPv6 packet and refer to the routing table to determine the egress interface. When an ACL is applied to a router interface:

  • It evaluates all transiting packets
  • Determines if a packet is permitted or denied based on the ACEs.
A router processing an ACL checks the header of each packet to determine whether it matches the criteria specified in each ACE of an ACL. If a match is found, the packet is forwarded or dropped as specified in the ACE (permit or deny):
  • A permit action allows the packet through.
  • A deny action results in a dropped packet.
Sequence numbers have a default increment of 10; with the first ACE having a sequence number of 10, 2nd 20, 3rd 30 and so on. ACL entries are processed sequentially from top to bottom of the list. By default, ACLs have an implicit deny added at the bottom of the ACL and these ACLs are used for through-the-box access rules. Management ACLs control to-the-box traffic; these ACLs do not have the implicit deny at the end of the ACL.

ACLs can be applied in the inbound or outbound directions from the perspective of the router. An inbound ACL filters packets coming into an interface but before any route processing takes place. An outbound ACL filters packets after route processing. If a packet matches any of the ACEs in an ACL, the action (permit or deny) is applied and the router immediately stops processing the ACL. The first match ends the processing of an ACL regardless of whether subsequent ACEs in the ACL match the packet. Because of this, when configuring ACLs, the ordering of the ACEs is extremely important.

Note: ACLs for traffic filtering do not block local router generated traffic in the egress direction.

Ordering of ACEs

When defining network ranges to be permitted or denied by an ACL, the more specific address entries should be configured before the general entries. The most specific network address entry is that defining a specific interface IP address using the keyword host or wildcard bit 0.0.0.0. These should then be followed by the more general wildcard bits. An illustrative example is:

  • deny host 192.168.1.1
  • permit 192.168.1.0 0.0.0.127
  • deny 192.168.1.0 0.0.0.255

If the more specific addresses are entered after the more general addresses which overlap the more specific address i.e., the more specific address is a subset of the more general address, IOS will display an error message.

R2(config-std-nacl)#5 deny 192.168.3.0 0.0.0.255
% Access rule can't be configured at lower sequence num as Host at sequence 10 is part of the given address block

Wildcard Bits

ACLs use wildcard bits and not subnet masks to match binary 0s and 1s of the IP address. Wildcard bits allow for more specific matching of traffic compared to subnet masks. The bits that are set to zero in a wildcard bit must match. For example; 172.16.1.1 0.15.255.255 matches addresses in the range 172.16.1.1 172.31.255.255. Wildcard bits use the following rules to match binary 0s and 1s:

  • Wildcard bit 0: Match the corresponding bit value in the address.
  • Wildcard bit 1: Ignore the corresponding bit value in the address (do not care).

Unlike wildcard masks used in OSPF, EIGRP, wildcard bits do not have to be contiguous; they can be on or off anywhere to represent sections of the IP address that have to match and sections that do not have to match. To determine the wildcard bits to use when configuring an ACL, subtract the subnet mask value (in dotted decimal notation) from the broadcast subnet mask i.e., 255.255.255.255 (/24).

Matching Subnets

Example 1

If an IP address 192.168.1.0 has a subnet mask of 255.255.255.0, then the wilcard bits can be determined as follows:

Example 2

Given an IP address 192.168.1.30 with a subnet mask of 255.255.255.224 (/27), the wildcard bits can be determined as follows:

Example 3

Given six hosts:

  1. A with IP address 172.31.3.2
  2. B with IP address 172.31.28.128
  3. C with IP address 172.31.29.2
  4. D with IP address 172.31.30.10
  5. E with IP address 172.31.31.10
  6. F with IP address 172.31.33.3
If an ACL with ACE access-list 100 permit ip any 172.31.1.0 255.255.254.254 log is applied to an interface in the ingress direction:
  • The first and second octets of the wildcard bit indicates do not match anything. Therefore, all hosts A, B, C, D, E, and F match this criteria.
  • The third octet of the wildcard bit indicates match an odd number. This is because it has one bit set but the address it is matching has one(1) in the third octet. Hosts A, C, E, and F match this third octet.
  • The fourth octet of the wildcard bit matches an even number. Hosts A, C, and E match this 4th octet.
  • IOS will save the above ACL as 10 permit ip any 0.0.1.0 255.255.254.254 log.
Hosts A, C, and E will be permitted through as their IP addresses match this ACE.

Matching Hosts

To match a specific host's IP address, ACLs use three approaches:

  1. A wildcard bit with all 0 bits: permit 192.168.1.1 0.0.0.0
  2. The host keyword: permit host 192.168.1.1
  3. The full host IP address without a wildcard mask: permit 192.168.1.1

Matching any/all hosts

To match any IP address, ACLs use two approaches:

  • using the 255.255.255.255 wildcard bit
  • the any keyword. The any keyword denotes the IP address and wildcard bits of 0.0.0.0 0.0.0.0.

An example can be access-list 1 permit 0.0.0.0 255.255.255.255.

ACL Placement

The recommendation for placement of ACLs is for one ACL, per interface per direction (ingress or egress), per protocol (IPv4 or IPv6). The best location for the placement of ACLs is as close to the source of the traffic as possible. This helps with saving network bandwidth by blocking traffic before it consumes network bandwidth. However, this may depend on the network design and type of ACL:

  • Extended ACLs are usually placed near the source; undesirable traffic is denied close to the source. This minimizes the waste of available network bandwidth with traffic that will be subsequently dropped.
  • Standard ACLs are usually placed near the destination of the traffic because standard ACLs match against the source IP address and do not specify destination addresses. This reduces the possibility of inadvertently blocking traffic that should be permitted.

Additional factors that may determine the placement of ACLs include:

  • The available network bandwidth
  • Ease of configuration
  • Scope of administrative control over the network

When applying an ACL to filter traffic, the following keywords are used:

  • Interface: ip access-group [acl-name | acl-number] [in | out]
  • VTY Line: access-class [acl-name | acl-number] [in | out]

Named ACL Recommendations

ACLs may be named or numbered. If an ACL is to be defined using an ACL name, the ACL naming recommendations are advised to be used when defining the ACL name. The ACL naming recommendations include the following:

  • Name cannot contain spaces or punctuation marks.
  • ACL name cannot begin with a number
  • ACL name must be unique; ACLs of different types cannot have the same name
  • ACL name can have a mixture alphanumeric characters
  • Recommended that the ACL name be written in capital letters
  • ACL names are locally significant. Multiple routers on the network can be configured to have the same name
  • Choose names that identify the function of the ACL

Types of ACLs

There are several types of ACLs:

  • Standard
  • Extended ACLs
  • Infrastructure
  • Transit
  • Time-based
  • Dynamic
  • IP Named
  • Reflexive
  • Context-based

    • The ACLs that are discussed in this post are: standard ACLs, extended ACLs, time-based ACLs, reflexive ACLs, and Dynamic ACLs.

    Standard Access Control Lists

    A standard ACL filters traffic based on source IP address of the packet. Standard ACLs can be named or numbered. If an ACL number is used to define the ACL, standard ACLs have two numbered ranges; 1-99 and 1300-1999 (expanded).

    Named Standard ACLs

    Named standard ACLs can be uniquely identified by the name. The name of the ACL is guided by the ACL naming recommendations previously discussed.

    Using the network diagram above, an ACL is configured to deny packets sourced from the network 192.168.8.0/22 i.e., IP addresses in the network 192.168.8.0/24, 192.168.9.0/24, 192.168.10.0/24. 192.168.11.0/24. All other packets will be permitted. To configure a named standard ACL:

    1. Define the ACL using the command ip access-list standard <ACL-name>

      R2(config)#ip access-list standard ACL_DENY_192.168.8.0/22

    2. Specify the permit or deny statements: using the command [permit | deny] {<ip-address> <wildcard-mask> | any}. If specifying a specific host IP address, use the host keyword instead of adding the wildcard bit 0.0.0.0 using the command [permit | deny] host <ip-address>

      R2(config-std-nacl)#10 deny 192.168.8.0 0.0.3.255
      R2(config-std-nacl)#permit any

    3. Apply the ACL to the interface using the interface mode command ip access-group <ACL-NAME> [in | out].

      R2(config)#interface g0/0
      R2(config-if)#ip access-group ACL_DENY_192.168.8.0/22 in

    Numbered Standard ACLs

    Numbered standard ACLs have ACL ID numbers ranging from 1 – 99 and in the expanded range 1300 – 1999. If configuring numbered ACLs using the classical approach (using command access-list <1-99|1300-1999>) any ACL whose ACL-ID matches can be considered as an ACE that is part of the same ACL with the specific matching number.

    To configure a numbered standard access control list:

    1. Configure the ACL: in global configuration mode using the command ip access-list standard <1-99 | 1300-1999>

      R2(config)#ip access-list standard 1300

      A descriptive message can be added to the ACL using the command remark <descriptive-text>. This helps with the documentation of the ACL.

      R2(config-std-nacl)#remark deny host 192.168.3.1/24

      Numbered ACLs can also be configured using the command access-list <1-99> [permit | deny] <ip-address> <wildcard bit>.

      R2(config)#access-list 1300 permit host 192.168.3.1
      R2(config)#access-list 1300 permit 192.168.3.0 0.0.0.255
      R2(config)#access-list 1300 remark Deny network 192.168.3.0/24

    2. Apply the ACL to the interface: using interface mode command ip access-group <acl-number> [ in | out ]. When applying the ACL to the interface, the direction of operation should be stated:

      R2(config)#interface g1/0
      R2(config)#ip access-group 1300 out

    Editing Numbered ACLs

    Delete Numbered ACL

    To delete a standard numbered ACL, use the command no access-list <acl-number>. This deletes the entire ACL including all its ACEs.

    If an ACL has been associated with an interface, and the ACL is subsequently deleted as demonstrated; however, the interface still references the ACL in its configuration. The traffic filtering behaviour of the interface may become unpredictable. It is recommended that when deleting an ACL, the ACL first be disassociated with the interface using the command no ip access-group [acl-number | acl-name], thereafter the ACL can be deleted.

    Modifying Existing ACE

    Only a numbered ACL created using the command ip access-list standard <acl-id | acl-name> can have its ACEs modified. To modify a standard numbered ACL:

    1. Display the ACE sequence numbers using the command show access-lists <acl-number>.
    2. Enter into the ACL editing mode using the command ip access-list standard <acl-number>
    3. Remove the ACE that is to be modified by referencing its sequence number using the ACL mode command no <acl-number>.
    4. Enter the new ACE

    Adding a new ACE

    To add a new ACE, to a named standard ACL:

    1. Display the ACL details to determine where to add the new ACE using the command show access-lists <acl-number>
    2. Enter the ACL configuration mode using the command access-list <acl-number> or ip access-list standard <acl-number>.
    3. Configure the new ACE with a desired sequence number to the existing ACL using the command <1-99> [permit | deny] <ip-address> <wildcard-mask>.

    Matching a default Route

    All routing protocols have a mechanism through which a default route can be advertised. The default route has an IP address of 0.0.0.0 and subnet mask of 0.0.0.0. To match against the default route in a standard ACL, use the ACE access-list 10 permit 0.0.0.0.

    Verification of Standard ACLs

    show access-lists / show ip access-lists

    The command show access-lists or similar alternative show ip access-lists displays configured ACLs. If any ACEs are configured with the log option, a summary of matches is included in the display.

    R2#show ip access-lists
    Standard IP access list 1300
        10 deny   192.168.3.1 log (10 matches)
        20 permit any (10 matches)
    Standard IP access list ACL_DENY_192.168.8.0/22
        10 deny   192.168.8.0, wildcard bits 0.0.3.255 (50 matches)
        20 permit any (253 matches)

    In the output of this command, the host statements are listed first in order to be efficiently processed by the IOS keeping the original sequence numbers. The range statements are listed after the host statements, in the order that they were configured along with their original sequence number. This is regardless of whether they may have a lower sequence number.

    show ip interface <interface-id>

    Displays any configured interfaces and the traffic filtering direction i.e., whether inbound or outbound.

    R2#show ip interface g0/0
    GigabitEthernet0/0 is up, line protocol is up
      Internet address is 192.168.12.2/30
      Broadcast address is 255.255.255.255
      Address determined by non-volatile memory
      MTU is 1500 bytes
      Helper address is not set
      Directed broadcast forwarding is disabled
      Multicast reserved groups joined: 224.0.0.9
      Outgoing access list is not set
      Inbound access list is ACL_DENY_192.168.8.0/22
      Proxy ARP is enabled
      Local Proxy ARP is disabled
      Security level is default
      Split horizon is enabled
      ICMP redirects are always sent
      ICMP unreachables are always sent
      ICMP mask replies are never sent
      IP fast switching is enabled
      IP fast switching on the same interface is disabled
      IP Flow switching is disabled
      IP CEF switching is enabled
      IP CEF switching turbo vector
      IP CEF turbo switching turbo vector
      IP multicast fast switching is enabled
      IP multicast distributed fast switching is disabled
      IP route-cache flags are Fast, CEF
      Router Discovery is disabled
      IP output packet accounting is disabled
      IP access violation accounting is disabled
      TCP/IP header compression is disabled
      RTP/IP header compression is disabled
      Policy routing is disabled
      Network address translation is disabled
      BGP Policy Mapping is disabled
      Input features: Access List, MCI Check
      IPv4 WCCP Redirect outbound is disabled
      IPv4 WCCP Redirect inbound is disabled
      IPv4 WCCP Redirect exclude is disabled

    Extended Access Control Lists

    Compared to standard ACLs, extended ACLs provide granular control over traffic filtering. Extended ACLs can be numbered or named. Numbered extended ACLs are configured with an ACL ID in the range from 100 - 199 and 2000 - 2699.

    Extended ACLs filter traffic based on the following parameters:

    • Protocol type i.e., IP, ICMP, EIGRP, OSPF, TCP, UDP etc.
    • Source IP address
    • Destination IP address
    • Source port number (TCP or UDP)
    • Destination port number (TCP or UDP)

    Extended ACLs support many layer 3 and layer 4 protocols. The protocols are defined using the protocol name or number. Some supported protocol names include: eigrp, esp, ip, ospf, tcp, udp, icmp, gre. The supported protocol numbers are in the range 0 - 255. TCP has a protocol number of 6, UDP 17, OSPF 89.

    With named extended ACLs, an ACE can be added or deleted within the ACL using the sequence number of the ACE. When modifying an existing ACE, it should first be deleted using the command no <sequence-number>. Then the new ACE can be entered with the same sequence number as the deleted one. Adding a new ACE without indicating the sequence number adds it to the bottom of the ACL and generates the highest sequence number for the ACE.

    The command to configure an extended ACL is ip access-list extended <100 – 199 | 1300 - 1999 | acl-name> <permit or deny> <protocol> [host] <source-network> <wildcard-bits> [<operator> port-number] <destination-network> <wildcard-bits> [<operator> port-number]

    The operator can be any of the following:

    • eq: match one specific port
    • range: to match a specified range of ports
    • gt: match ports greater than
    • lt: match ports less than

    A remark can be added to an ACL to describe the purpose of the ACL.

    Configuration

    To configure an extended ACL:

    1. Define the extended ACL:
      1. Classic numbered extended ACL: using the command access-list <100-199 | 2000-2699> [permit | deny] <protocol> <source-ip> [source-port] <destination-ip> [destination-port].
      2. Modern extended ACL: ip access-list extended <name | 100-199 | 2000-2699> [permit | deny] <protocol> <source-ip> [source-port] <destination-ip> [destination-port].

      R2(config)#ip access-list extended ACL_DENY_172.31.33.3

    2. Specify the condition, protocol, destination and source addresses: permit or match

      R2(config-ext-nacl)#deny ip 192.168.12.0 0.0.0.3 host 172.31.33.3
      R2(config-ext-nacl)#permit tcp 192.168.12.0 0.0.0.3 host 172.31.33.3 eq www
      R2(config-ext-nacl)#permit ip any any

    Accessing Layer 3 Options

    Layer-3 options are accessed using the ip keyword as the top-level protocol. These options include:

    • dscp: matches packets with given dscp value
    • fragments: Check non-initial fragments
    • log: Log matches against this entry
    • options: matches packets with a given IP Options value
    • precedence: matches packets with a given precedence value

    Accessing Layer 4/5 ACL Options

    Extended ACLs provide the ability to match on Layer-4 and/or Layer-5 information using the TCP or UDP keywords as the top-level protocol. The UDP header is very basic and does not have many options. The TCP header is extensive with several options:

    • ack: Match the ACK-bit
    • established: Match established connections.
    • fin: match the FIN bit
    • fragments: Check non-initial fragments
    • gt: Match only packets with a greater port number
    • log:
    • ttl: match packets with a specific TTL value.

    Matching on TCP/UDP Port Numbers

    Matching on TCP/UDP port numbers also matches Layer 3 (IP) options as well. When matching TCP or UDP ports keywords can be used such as www, telnet, ftp, ftp-data or port numbers. However, not all port numbers have keywords associated with them. When matching TCP/UDP, the source and/or destination port numbers are optional. If the port numbers are not specified, then all protocol traffic will be permitted or denied depending on the configured action. Session-layer(Layer-5) port numbers may be matched in a variety of ways:

    • eq <port-number>: matching on an exact port number that "equals" the supplied value
    • lt <port-number>: matching on any value less than the supplied value.
    • gt <port-number>: matching on any value greater than the supplied value.
    • neq <port-number>: matching on any value not equal to the supplied value.
    • range <lower-upper>: matching on any value in the supplied range of values.

    When matching against port numbers, the destination port follows the destination IP address and the source port follows the source IP address. If you specify the protocol, source and destination IP addresses, source and destination port, etc, for a packet to match the ACE, all these parameters have to be the same as the configured values for the ACE to be registered as a match.

    Extended ACLs and Packet Fragmentation

    When a packet is fragmented by a router, the first fragment of the packet contains the layer-3 and layer 4 header details. With subsequent fragments, the layer 3 header is copied from the first fragment; they do not contain the layer 4 header. The TCP/UDP header is maintained only in the first fragment.

    From an ACL perspective, matching on the TCP header fields matches on the first fragment of a packet. Subsequent fragments of the packet are not matched by this. If the TCP header has the fragment offset value of 0(zero), then the packet is considered the first fragment or not a fragment at all. If a packet contains a value greater than zero in the fragment offset field, then this can be considered as being a fragment. If a packet has a non-zero value for fragment offset, the router will permit the packet if the ACL is checking for packets with specific TCP header values. This can be used in suppressing DoS attacks where fragmented packets are sent without sending the first fragment.

    The fragments keyword is a layer 3 feature that can be used to query fragments.

    Extended ACLs and TCP handshake

    The TCP three-way handshake, when initiating a TCP connection, consists of the following exchanges:

    • Sender sets the SYNC flag
    • Receiver sets ACK flag
    • Sender sets ACK
    All subsequent traffic will contain ACK flags or the RESET flag set. With this in mind, the traffic to a specific network/host can be permit to be initiated from a specific host/network and blocked if it is initiated from a different network/host. The two potential solutions include:
    1. Matching on the ACK and RESET flag.
    2. Matching on the established keyword
    The two options do the same thing.

    The following configuration permits HTTP traffic initiated by host 192.168.12.1 to host 192.168.23.2. HTTP traffic initiated by host 192.168.23.2 to 192.168.12.1 is denied.

    R2(config-ext-nacl)#do show ip access-lists ACL_DENY_HTTP_192.168.23.2
    Extended IP access list ACL_DENY_HTTP_192.168.23.2
        10 permit tcp host 192.168.23.2 host 192.168.12.1 eq www established (9 matches)
        15 permit tcp host 192.168.23.2 host 192.168.12.1 ack fin (24 matches)
        30 permit ospf any any (182 matches)
        40 permit icmp host 192.168.12.1 host 172.31.33.3
        50 permit icmp host 172.31.33.3 host 192.168.12.1 echo-reply (10 matches)
        100 deny ip any any log (11 matches)

    Extended ACLs in Routing Protocols

    Interior Gateway Protocols

    When applied to interior gateway protocols for prefix filtering during redistribution, advertising etc., source fields identify the network and destination fields identify the smallest prefix length in that network range.

    When matching networks in IGPs:

    • permit ip any any : permits all networks
    • permit ip host 10.1.0.0 host 255.240.0.0 : Permits all networks in the range 10.1.0.0/12
    • permit ip host 10.1.0.0 host 255.255.0.0 : Permits all networks in the 10.1.0.0/16 range
    • permit host 10.1.1.1 : Permits only the 10.1.1.1/32 host

    BGP

    For BGP network selection, source fields identify the network and destination fields identify the network mask.

    • permit ip 10.1.0.0 0.0.0.0 255.255.0.0 0.0.0.0 : Permits only the 10.1.0.0/16 network
    • Permit ip 10.1.0.0 0.0.255.0 255.255.255.0 0.0.0.0 : Permits any 10.1.any.0 network with a /24 prefix
    • Permit ip 10.1.0.0 0.0.255.255 255.255.255.0 0.0.0.255 : Permits any 10.1.any.any network with a /24 - /32 prefix
    • permit ip 10.1.0.0 0.0.255.255 255.255.255.128 0.0.0.127 : Permits any 10.1.any.any network with a /25 - /32 prefix

    Packet Filtering using ACLs

    ACLs are applied to an interface in a given direction; ingress or egress. Ingress is when traffic is entering a router interface and egress is when traffic is exiting the router through an interface. To apply the ACL to an interface, you need to indicate the direction of traffic flow that the device should implement the ACL. Pinging a destination that is blocked by an ACL results in ICMP unreachable output indicated by U.U.U.U

    Matching a default Route

    To match against the default route in an extended ACL, use the ACE access-list 100 permit ip host 0.0.0.0 host 0.0.0.0.

    In a prefix-list, to match a default route, use the command ip prefix-list 10 permit 0.0.0.0/0.

    Time-based ACLs

    Time-based ACLs are only active during a specified time range. The time-range configured on a router references the router’s clock. Time-based ACLs consist of ACEs that are activated during configured time periods. The time periods are a feature that is separate from ACLs and are defined using the global configuration command time-range. This configured time period is then applied to an extended ACLs making it a time-based ACL. The time configured using the time-range command can be periodic or absolute:

    • Periodic: the ACE is activated at the scheduled time periods such as daily, specific days of the week, weekly, monthly, hourly, etc. The ACL gets re-activated based on the configured time.
    • Absolute: ACE gets activated for a specific duration and this occurs only once.

    When configuring a time-based ACL, it is important to ensure the accuracy of the device clock. It is recommended to use NTP to set the system clock.

    It can be set to be periodic where it becomes active or inactive at specific times of the day or on specific days of the week e.g. every Wednesday from 10am – 2pm or absolute where there is a specific starting and stopping date and time. You cannot create time-based rules that have the exact same protocol, source, destination, and service criteria of a rule that does not include a time range object. The non-time-based rule always overrides the duplicate time-based rule, as they are redundant.

    Configuration of Time-based ACLs

    1. Ensure that the clock is accurate: it is important to ensure that the system clock is accurate when configuring time-based ACLs. The clock can be set manually or preferrably through NTP:

      • Manually configuring clock: using the privileged mode command clock set hh:mm:ss dd month year
      • Using NTP: A list of NTP servers can be configured using the global configuration command ntp server <server-ip> [prefer] [version]. Current NTP version is 4. The optional prefer keyword indicates that this specific NTP server is preferred to other configured NTP servers.

    2. Configure the time-range:
      1. Define the time-range: using the command global configuration command time-range <name>:

        R1(config)#time-range TIME-RANGE_WORK-WEEK

      2. Time-range type: Decide on absolute or periodic type. Absolute activates the ACE only once for the defined duration and does not repeat. Periodic occurs repeatedly where the ACE is activated on the specified period and for the defined duration. Time values are defined in 24-hour clock.
        • Absolute: R1(config-time-range)#absolute start <hh:mm> <1-31> <Jan-Dec> <yyyy> end <hh:mm> <1-31> <Jan-Dec> <yyyy>

          R1(config-time-range)#absolute start 12:00 06 Jun 2022 end 00:00 31 Jan 2035

        • Periodic: periodic [Monday | Tuesday | Wednesday | Thursday | Friday | daily | weekdays | weekend] <hh:mm> to <hh:mm>. If the periodic value configured is a day of the week, tt is possible to set the value to a series of days periodic Monday Wednesday Friday <hh:mm> to <hh:mm>.

          R1(config-time-range)#R1(config-time-range)#periodic weekdays 00:00 to 23:30

        Curiously, IOS permits the configuration of periodic and absolute parameters values on the same ACL.

        R1#show time-range
        time-range entry: TIME-RANGE_WORK-WEEK (inactive)
           absolute start 12:00 06 June 2026 end 00:00 31 January 2035
           periodic weekdays 0:00 to 23:30

        The show time-range command will display ‘inactive’ if the current time is not within the range of the configured time.

    3. Apply the time-range to the ACL: using the keyword time-range <name_of_time-range> of the ACE ACL configuration.

      R1(config-ext-nacl)#permit ip 192.168.23.0 0.0.0.3 host 192.168.12.1 time-range TIME-RANGE_WORK_WEEK
      R1(config-ext-nacl)#permit tcp 172.16.33.0 0.0.0.255 192.168.8.0 0.0.0.255 eq www time-range TIME-RANGE_WEEKEND

    4. Apply the ACL to the interface:

      R1(config)#interface g0/0
      R1(config-if)#ip access-group 100 in

    Infrastructure ACLs

    An infrastructure ACL is an extended ACL applied to layer 3 devices residing at the edge of an enterprise network. The primary purpose is to prevent malicious traffic from entering the enterprise. It is usually applied inbound on the interface connecting to the external network. Typical ACEs configured in infrastructure ACLs include tracking TCP fragments, blocking TCP connections initiated by outside users.

    R1(config)#ip access-list extended INFRASTRUCTURE
    R1(config-ext-nacl)#deny tcp any any fragments

    Reflexive ACLs (IP Session Filtering)

    Reflexive ACLs enable a router to implement security features that firewalls implement where a network is labelled an inside network and another network labelled as an outside (and considered unsafe). Connections initiated by hosts in the inside network to hosts in the outside network are permitted. Also permitted is return traffic. Traffic initiated by hosts in the outside network is denied. Reflexive ACLs permit outbound traffic and limit inbound traffic in response to sessions that originate from the inside network. Reflexive ACLs make the edge routers operate similar to a stateful firewall protecting internal users from external threats. Internal users are permitted to access external resources but external users cannot initial connections to internal resources.

    Reflexive ACLs monitor for permitted, outgoing data of any type; they can be configured to track any protocol whether TCP, UDP, ICMP. The type of expected traffic is defined e.g., SSH, HTTPS. Reflexive ACLs are defined only with extended named IP ACLs. However, to improve the security posture of the network, they can be used in conjunction with other standard and static extended ACLs. An ACL is configured to permit the defined traffic types and the keyword reflect is added to this ACL.

    Reflexive ACLs have create a mirror-image of transmitted traffic which will be permitted upon return. The reflexive ACL creates a dynamic ACL on-the-fly where it is expecting and permitting a return packet. Return traffic is permitted because it matches the return traffic. The reflex keyword of an extended ACL causes the router to remember the traffic that matches the permitted traffic such as HTTPS session(source and destination, port numbers, IP protocol field), and monitor all return traffic. The reflexive ACLs create a mirror-image of transmitted traffic which will be permitted upon return; the return traffic is then expected to have the source and destination ports, source and destination IP addresses reversed. What was the source port in the original traffic will be the destination port in the return traffic.

    Traffic that matches the implicit deny statement of the ACL does not trigger the creation of the reflexive ACL. Only permit statements create the reflexive ACLs

    Reflexive ACLs should be applied on the interface connecting to the untrusted network/host.

    Configuration of Reflexive ACLs

    1. Configure a named extended ACL: Reflexive ACLs can only be used with named extended ACLs. The following error message is displayed when an attempt is made to configure reflexive ACL using a numbered extended ACL: % Reflexive ACLs are allowed on named ACLs only.

      R2(config)#ip access-list extended ACL_REFLEXIVE_EGRESS
      R2(config-ext-nacl)#permit ip host 192.168.12.1 host 172.31.30.10 reflect MIRROR

      The dynamic ACL MIRROR reflects the permitted traffic swapping the source IP address with destination IP address, source port with destination port of the original traffic.

    2. Create a named extended ACL for monitoring ingress traffic from untrusted sources: create a new extended named ACL and include the keyword evaluate referencing the previously configured reflexive ACL name.

      R2(config)#ip access-list extended ACL_REFLEXIVE_INGRESS
      R2(config-ext-nacl)#evaluate MIRROR

      The name must match the name previously supplied after the "reflect" keyword.
    3. Apply both ACLs to interface facing untrusted networks:

      R2(config)#interface g1/0
      R2(config-if)#ip access-group ACL_REFLEXIVE_EGRESS out
      R2(config-if)#ip access-group ACL_REFLEXIVE_INGRESS in

    To permit another protocol such as ICMP, adding the command permit icmp any any does not permit the traffic. ICMP traffic has to be tracked on the ACL using the command permit icmp any any reflect Mirror.

    Timeout Values

    Reflexive entries expire after configurable timeout value. When this happens, that same TCP, UDP return traffic that was previously permitted will be denied on the interface. Reflexive ACLs have a timeout value that expires. This value can be configured. After the expiry of the timeout value, the dynamic reflexive entry is removed and that same TCP and UDP information is no longer permitted on the interface.

    The timeout value expire under the following conditions:

    1. Graceful end of TCP session messages are received; (2 segments seen with FIN flags). The default timeout is 5 seconds.
    2. TCP reset message is received (RST). The default timeout is immediate.
    3. TCP messages no longer seen: the default timeout value is 300 seconds.
    4. For UDP, ICMP and all other protocols, the default timeout value is 300 seconds after last seen packet

    Timeout values for graceful end of TCP session and TCP session reset can not be modified. The timeout values for non-receipt of TCP messages and other protocols such as UDP, ICMP can be modified in two ways:

    1. Globally: using the global configuration command ip reflexive-list timeout <1-2147483>
    2. Modifying within ACE Entries:

      R2(config)#ip access-list extended ACL_REFLEXIVE_EGRESS
      R2(config-ext-nacl)#10 permit host 192.168.12.1 host 172.31.30.10 reflect MIRROR timeout 250
      R2(config-ext-nacl)#20 permit host 192.168.8.1 host 172.31.30.10 reflect MIRROR timeout 150
      R2(config-ext-nacl)#permit host 192.168.10.1 host 172.31.30.10 reflect MIRROR timeout 120

    The global reflexive ACL timeout values take precedence over the ACE specific timeout values.

    The mirror ACL should be active for a defined period of time. If it is indefinite, this could become a security loophole; though the default timeout values are enforced if explicit timeout values are not configured.

    Verification

    show ip access-lists

    The reflexive ACL created by the traffic can be verified using the command show ip access-list. This is used to determine if the reflexive ACL is in effect or not. Command displays the matched hosts even if the keyword "any" was used in the ACL.

    R2#show ip access-list
    Extended IP access list ACL_REFLEXIVE_EGRESS
        10 permit ip host 192.168.12.1 host 172.31.30.10 reflect MIRROR (31 matches)
        20 permit ospf any any
    Extended IP access list ACL_REFLEXIVE_INGRESS
        10 evaluate MIRROR
        20 permit ospf any any (128 matches)
    Reflexive IP access list MIRROR
         permit tcp host 172.31.30.10 eq www host 192.168.12.1 eq 63366 (5 matches) (time left 297)
    R2#        

    Using the log keyword when defining the ACL will create Syslog messages that will indicate when the ACL was created.

    debug ip access-list data-plane

    Running the command debug ip access-list data-plane is not recommended as it generates a lot of traffic on the network. To determine the timestamp when the reflexive ACL was created:

    1. Disable logging to the console no logging console.
    2. Send logs with severity of debugging to the logging buffer using the command logging buffer debug
    3. Increase buffer size: logging buffer 100000
    4. Debug ACL: debug ip access-list data-plane

      R2#debug ip access-list data-plane
      R2#
      *Jun 23 05:25:06.155: IPACL-DP: ACL check is not done due to either of invalid input interface or output interface doesnt have any acl attached or locally generated traffic
      R2#
      *Jun 23 05:25:10.375: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:25:10.375: IPACL-DP: Pkt matched permit it
      *Jun 23 05:25:10.379: IPACL-DP: Pkt is permitted in process path: interface GigabitEthernet1/0 inbound direction
      *Jun 23 05:25:11.643: IPACL-DP: Reflexive ACL: Punt the packet as we are in interrupt context
      *Jun 23 05:25:11.643: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_EGRESS seq: 10 Action: Deny
      *Jun 23 05:25:11.643: IPACL-DP: Pkt matched punt/drop it
      *Jun 23 05:25:11.643: IPACL-DP: ipaccess_fib_acl_check_inline : Pkt is punted to process path from cef path: interface GigabitEthernet1/0 outbound direction
      *Jun 23 05:25:11.651: IPACL-DP: New Reflexive acl entry created for the flow
      *Jun 23 05:25:11.651: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_EGRESS seq: 10 Action: Permit
      *Jun 23 05:25:11.651: IPACL-DP: Pkt matched permit it
      *Jun 23 05:25:11.651: IPACL-DP: Pkt is permitted in process path: interface GigabitEthernet1/0 outbound
      R2# direction
      *Jun 23 05:25:11.663: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 10 Action: Permit
      *Jun 23 05:25:11.663: IPACL-DP: Pkt matched permit it
      *Jun 23 05:25:11.663: IPACL-DP: ipaccess_fib_acl_check_inline : Pkt is permitted in cef path: interface GigabitEthernet1/0 inbound direction
      *Jun 23 05:25:11.675: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_EGRESS seq: 10 Action: Permit
      *Jun 23 05:25:11.675: IPACL-DP: Pkt matched permit it
      *Jun 23 05:25:11.675: IPACL-DP: ipaccess_fib_acl_check_inline : Pkt is permitted in cef path: interface GigabitEthernet1/0 outbound direction
      *Jun 23 05:25:11.679: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_EGRESS seq: 10 Action: Permit
      *Jun 23 05:25:11.679: IPACL-DP: Pkt matched permit it
      *Jun 23 05:25:11.679: IPACL-DP: ipaccess_fib_acl_check_inline : Pkt is permitted in cef path: interface GigabitEthernet1/0 outbound direction
      *Jun 23 05:25:11.899: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 10 Action: Permit
      *Jun 23 05:25:11
      R2#.899: IPACL-DP: Pkt matched permit it
      *Jun 23 05:25:11.899: IPACL-DP: ipaccess_fib_acl_check_inline : Pkt is permitted in cef path: interface GigabitEthernet1/0 inbound direction
      R2#
      *Jun 23 05:25:15.431: IPACL-DP: ACL check is not done due to either of invalid input interface or output interface doesnt have any acl attached or locally generated traffic
      R2#
      *Jun 23 05:25:20.031: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:25:20.031: IPACL-DP: Pkt matched permit it
      *Jun 23 05:25:20.031: IPACL-DP: Pkt is permitted in process path: interface GigabitEthernet1/0 inbound direction
      R2#
      *Jun 23 05:25:25.155: IPACL-DP: ACL check is not done due to either of invalid input interface or output interface doesnt have any acl attached or locally generated traffic
      R2#

    5. To view the ACL creation timestamp: show log | include REFLEXIVE

      R2#show log | include REFLEXIVE
      *Jun 23 05:25:29.391: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:25:38.551: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:25:48.283: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:25:57.987: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:26:06.979: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:26:11.687: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 10 Action: Permit
      *Jun 23 05:26:11.707: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_EGRESS seq: 10 Action: Permit
      *Jun 23 05:26:16.051: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:26:25.503: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:26:35.391: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:26:44.627: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:26:54.431: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:27:04.231: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:27:11.727: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 10 Action: Permit
      *Jun 23 05:27:11.743: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_EGRESS seq: 10 Action: Permit
      *Jun 23 05:27:13.699: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:27:23.415: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:27:32.779: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:27:41.851: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit
      *Jun 23 05:27:51.403: IPACL-DP: Pkt matched ACL: ACL_REFLEXIVE_INGRESS seq: 20 Action: Permit

    Dynamic Access Lists

    Dynamic ACLs are used to restrict network access to only authenticated users. Dynamic ACLs provide support for permitting access based on an authentication server. Every authentication request to a device is offloaded to a central authentication database. This might require manual configuration of each device. The device sends out an authentication request to the host before permitting access, e.g. SSH access to a network device.

    When attempting to access a network service such as HTTP server, a dynamic ACL forces the unauthenticated user to first Telnet the authentication service which may be configured on a router; SSH support can alternatively be enabled. After successful authentication, the Telnet session is closed and a dynamic ACL is created on the interface permitting access to the host with the network service.

    The dynamic ACL is removed from the interface after a configurable absolute-timeout or idle-timeout value expires. Reflexive ACLs do not have absolute timeouts where regardless of activity or inactivity, traffic is denied at the absolute timeout interval.

    Components of a dynamic access list inclide the following:

    • Connection used for authentication: Telnet, SSH
    • Extended Acces Control List (ACL) configured with dynamic entries
    • Autocommand with access-enable option: this is implemented at the user, or line level:
      • Autocommand: once authentication is successful, disconnect from the device. Autocommand then executes access-enable.
      • Access-enable: ensures that the dynamic part of the ACL gets activated.

    One use case for implementing sdynamic ACLs, if individuals require temporary access to a network device e.g., Telnet access to a router for a specified period.

    Dynamic ACL Rules

    The following guiding principles apply to the configuration and operation of dynamic ACLs:

    • Dynamic ACLs cannot be used to provide different access rights to different users.
    • Dynamic ACLs may use either an idle-timeout or absolute timeout value.
    • Autocommand access-enable may be configured either: at the username level or within the VTY line.
    • Dynamic ACLs are configured with named or numbered extended ACLs only.
    • Standard ACLs do not support dynamic ACLs.

    Configuration

    1. Create a local account: using the command username <name> password <password>

      R2(config)#username admin password cisco

      The access can be enabled through the following methods:

      • Under the local user account: using the command username <username> autocommand access-enable timeout <value>. This command temporarily present the username and password prompt.

        R2(config)#username admin autocommand access-enable timeout 5
        • autocommand: If they authenticate successfully or fail to authenticate three times unsuccessfully, close the authentication page.
        • access-enable: implement dynamic access list.
        • timeout: idle timeout value.

      • Add the autocommand directly under the VTY lines:

        R2(config)#line vty 0 4
        R2(config-line)#autocommand enable-access timeout 5

      The autocommand under the VTY line affects all users while the command under the username applies only to that specific user and not others.

    2. Create the access list: using named or numbered extended access-lists.
      1. Define the dynamic ACE:

        R2(config)#ip access-list extended 101
        R2(config-ext-nacl)#10 dynamic ACL_DYNAMIC_TELNET timeout 15 permit ip any any

        The timeout specified here is the absolute timeout value. Both timeout values can be specified. There is no default timeout value; if none of the timeout values is not defined, then there is no timeout value for the dynamic ACL resulting in access is granted in indefinitely.

        Only one ACE in an ACL can have the dynamic keyword. Typing a second one triggers an error message.

      2. Create the ACE permitting the traffic to the router:

        R2(config-ext-nacl)#30 permit tcp host 192.168.12.1 host 172.31.30.10 eq telnet

    3. Enable VTY local login:

      R2(config)#line vty 0 4
      R2(config-line)#login local

    4. Apply it to the interface pointing to the host that initiates the connection in the inbound direction: A dynamic ACL is always in the inbound direction.

      R2(config-line)#interface g0/0
      R2(config-if)#ip access-group ACL_DYNAMIC_TELNET in

    Timeout

    Two timeout parameters can be configured:

    • Idle timeout: One is enabled through the access-enable host command with the timeout keyword where the value specified is in seconds.
    • Absolute timeout: specified with the dynamic entry

    Clearing a Dynamic ACL

    If a dynamic ACL is in place and you intend to delete it, use the command clear ip access-template <acl-name|acl-number> <dynamic-ACL-name> <source> <destination> .

    If a dynamic ACL is cleared in the when a user has Telnet/SSH access, this access is disabled.

    Extending Dynamic ACL Entries

    IOS allows users to extend the life of their dynamic ACE by an additional 6 mminutes. Using the command access-list dynamic-extended, the user Telnets back into the router and receives the additional time. The extended value of 6 minutes is currently fixed and cannot be adjusted.

    Additional ACL Features

    Object Groups

    Originally designed for ASA firewalls, object groups is a feature in extended ACLs that simplify ACL management by grouping similar "objects" together e.g., pubilc_web_servers group. It allows for more modular changes; a change to an object group dynamically affects all ACEs referencing that group. Command syntax is slightly different on IOS routers than ASA firewalls.

    Traditionally, when modifying an existing ACL, the port that it is applied to is shutdown, and the ACEs of the ACL are modified. Then the port is re-enabled. Usually, this configuration is carried out during out-of-office hours. With object groups, the ACEs reference the object group. The object group can be modified and after completion, the ACL gets updated without disabling a port that references the ACL.

    On Cisco routers, there are two types of object groups:

    1. Network group: for defining IP address-related objects for example host or subnet section of an ACE can be replaced by an object group and the ACE references the object group.
    2. Service group: for defining protocols and ports such as high-level protocol, TCP/UDP port numbers,

    Configuration

    In this configuration, different object groups are configured for clients, servers and protocols.

    R2#configure terminal
    R2(config)#object-group network CLIENTS
    R2(config-network-group)#host 192.168.8.1
    R2(config-network-group)#192.168.3.0 /24
    R2(config-network-group)#192.168.12.0 0.0.0.3

    Servers

    R2(config)#object-group network SERVERS
    R2(config-network-group)#host 172.31.30.10
    R2(config-network-group)#172.31.33.3 /24

    Protocols

    R2(config)#object-group service NETWORK_SERVICES
    R2(config-service-group)#tcp eq telnet
    R2(config-service-group)#tcp eq www

    Configuring the ACL to reference the object groups in the following order:

    1. Service object group
    2. Source object group
    3. Destination object group
    permit object-group <protocol-object-group> object-group <source-object-group> object-group <destination-object-group>

    R2(config)#ip access-list extended 101
    R2(config-ext-nacl)#permit object-group NETWORK_SERVICES object-group CLIENTS object-group SERVERS

    Verification

    show object-group

    Displays the configuration of the object group.

    R2#show object-group

    Network object group CLIENTS
      host 192.168.8.1
      192.168.3.0 255.255.255.0
      192.168.12.0 255.255.255.252
              
    Service object group NETWORK_SERVICES
      tcp  eq telnet
      tcp  eq www
      ip    
              
    Network object group SERVERS
      host 172.31.30.10
      172.31.33.0 255.255.255.0

    Sequence Numbers

    When a new ACE is added to an ACL, by default, the first configured ACE is assigned a sequence number of 10. Subsequent ACEs have their sequence numbers generated in increments of 10 with the second ACE having sequence number 20, third ACE 30 and so on.

    It is possible to modify the starting sequence number of an existing ACE as well as change the sequence number increment value using the command ip access-list resequence <acl-id> <starting-seq-number> <increment>. This feature is available for all ACLs.

    R2#show ip access-lists 101
    Extended IP access list 101
        10 Dynamic Project permit ip any any
        20 permit tcp any host 172.31.30.10 eq telnet
        30 permit ospf any any (676 matches)
        40 permit object-group NETWORK_SERVICES object-group CLIENTS object-group SERVERS

    R2#ip access-list resequence 101 1000 50
    R2#show ip access-lists 101
    Extended IP access list 101
        1000 Dynamic Project permit ip any any
        1050 permit tcp any host 172.31.30.10 eq telnet
        1100 permit ospf any any (684 matches)
        1150 permit object-group NETWORK_SERVICES object-group CLIENTS object-group SERVERS

    Logging

    ACE entries can be appended with logging-related keywords: log and log-input. These commands cause log messages to be generated if a packet matches the ACE providing hit-counts and evidence of ACL activity. Logging forces packets matching the ACE entries to be process-switched resulting in increased CPU load. Additionally, printing out Syslogs increase the CPU load.

    With log:

    • Timestamp information is displayed
    • ACL number
    • Protocol
    • Source and destination address
    • Interface ACL is applied to (0/0)
    • Number of packets matched
    With log-input, additional information is displayed particularly the MAC address; this is the most recent MAC address.

    An additional descriptive text can be added to the ACE to describe the particular role of the ACE e.g. access-list 101 permit icmp any host 2.2.2.2 log-input EmailServer. This tags the ACE for traffic to the email server.

    Log Interval

    Individual ACEs can have the "log" or "log-input" keywords. When an ACL is applied to an interface, syslogs are generated:

    • Once every 5 minutes for packets matching a particular ACE. The summary of the number of packets that were matched over the last 5 minutes is displayed.
    • If any log-enabled ACE in any ACL on any interface matches a packet within one second of the initial log message, the match or matches aggregated statistics for 5 minutes are then reported.

    If you want logs for ACEs to be displayed more frequently than every 5 minutes, use the command ip access-list log-update threshold <0-2147483647> with the value being the number of hits; display a syslog after x number of packets match the ACE. This applies to all ACEs of an ACL.

    This increases the CPU Load. Even though logs for individual ACEs are only displayed every 5 minutes, every packet that matches the ACE must be process-switched.

    To reduce this; use the command ip access-list logging interval <0-214748367> . The value is in milliseconds; for all the packets that match the ACE, send packets to the CPU every nth (configured) interval.

    Filtering on Log Output

    ACL syslogs have different identifiers depending on type of traffic that triggered the log.

    LOG-CODES

    When sending ACL syslogs to logging buffer, one can filter one these identifiers:

    1. Severity: 0-7: logging buffer <severity>
    2. Filter the log output based on the applicable protocol: show log | include RP filters for TCP and UDP generated logs. This displays permitted or denied Syslogs.

    IPv6 ACLs

    By default, IPv6 access-lists add permit statements that are necessary for IPv6 to function. IPv6 ACls are only named extended ACLs. They offer similar features to IPv4 extended ACLs. IPv6 ACLs use the prefix length instead of wilcard masks to match. The host keyword can also be used with IPv6 ACLs.

    They include an implicit deny statement at the end. IPv6 will automatically add the following statements to any access-list (dies not show up in configuration):

    • permit icmp any any nd-na
    • permit icmp any any nd-ns
    • permit icmp any any router-advertisement
    • permit icmp any any router-solicitation

    The above statements allow the router to participate in the IPv6 equivalent of ARP for IPv4.

    If using an explicity deny, make sure to manually include the ICMP traffic with permit statements.

    IPv6 ACLs do not support wildcard bits; instead prefix-length is used.

    Configuration

    1. Define the ACL: using the command ipv6 access-list <ACL-NAME
    2. Configure the ACE: using the command [permit | deny] <protocol> [<source-address/prefix-length> | any | host <source-address] [operator <port-number>] [<destination-address/prefix-length> | any host <destination-addres>] [operator <port-number>] where:
      • deny | permit specifies whether to permit or deny traffic
      • protocol protocol name or number
      • source-ipv6-prefix|prefix-length
      • any: is an abbreviation for IPv6 prefix ::/0 that matches all addresses
      • host: specific IPv6 host address
      • operator: (optional) an operand that compares the source or destination ports of the specified protocol. Operands include:
        • lt: less than
        • gt: greater than
        • eq: equal to
        • neq: not equal to
        • range: range of protocol numbers
    3. Apply the ACL to the interface: using the command ipv6 traffic-filter <ACL-NAME> [in | out]

    Verification

    show ipv6 interface <interface-id>

    show access-lists

    R2#show access-lists IPv6 access list ACL6_DENY1::2 deny tcp any eq www host 1::2 sequence 10 permit icmp any any (57 matches) sequence 20 permit 89 any any (425 matches) sequence 30 permit tcp any eq www host 1::1 sequence 40 permit tcp host 3::3 host 1::1 eq www (23 matches) sequence 50

    Posted by at
    Labels: , , , ,
    Location: Kampala, Uganda

    No comments:

    Post a Comment

    Subscribe to: Post Comments (Atom)