No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

What Is an Access Control List

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
What Is an Access Control List

What Is an Access Control List

Introduction

This document briefly describes what ACL is. The following describes the basic concept of ACL, ACL Matching Conditions, and ACL Configuration Guidelines.

Overview of ACLs

Definition

An Access Control List (ACL) is a packet filter that filters packets based on rules. One or more rules describe the packet matching conditions, such as the source address, destination address, and port number of packets.

For packets that match the ACL rules configured on a device, the device forwards or discards these packets according to the policies used by the service module to which the ACL is applied.

Purpose

The fast growth of network technologies brings challenges to network security and Quality of Service (QoS). ACL is a security policy that is enforced on networks to prevent the following problems:

  • To prevent information leaks and unauthorized access of resources on key servers of an enterprise network
  • To prevent viruses on the Internet from entering and spreading on the enterprise intranet
  • To prevent random services from occupying network bandwidth, thereby guaranteeing bandwidth for delay-sensitive services such as voice and video

These problems are detrimental to network communication, so network security is critical.

ACL accurately identifies and controls packets on the network to manage network access behaviors, prevent network attacks, and improve bandwidth use efficiency. In this way, ACL ensures security and high service quality on networks.

Figure 1-1 shows a typical network with ACL configured.

Figure 1-1 ACL application scenario

  • To ensure financial data security, access to the financial server is allowed only from the president office; access from the R&D department to the financial server is blocked. The implementation method is as follows:

    Configure an ACL in the inbound direction of Interface 1 to block the packets from the R&D department to the financial server. The ACL does not need to be configured on Interface 2, so the packets from the president office to the financial server are allowed.

  • Protect the enterprise intranet against viruses entering and spreading from the Internet. The implementation method is as follows:

    Configure an ACL on Interface 3 to block packets that match virus signatures.

ACL Fundamentals

An ACL matches packets against the rules in contains to filter packets.

ACL Structure

Figure 1-2 shows the structure of an ACL.

Figure 1-2 ACL structure

  • ACL number: identifies a numbered ACL.

    ACLs are classified into basic ACL, advanced ACL, Layer 2 ACL, user ACL. These ACLs have different number ranges. For details, see ACL Classification.

    You can also define the name of an ACL to help you remember the ACL's purpose. In this situation, an ACL name is like a domain name that represents an IP address. Such an ACL is called named ACL.

    An ACL number can be part of an ACL name. That is, you can also specify an ACL number when you define an ACL name. If you do not specify an ACL number, the system will automatically allocate a number to an ACL. The following is an ACL name consisting of a name deny-telnet-login and a number 3998.

    #                                                                                
    acl name deny-telnet-login 3998                                                  
     rule 0 deny tcp source 10.152.0.0 0.0.63.255 destination 10.64.0.97 0 destination-port eq telnet                                                                
     rule 5 deny tcp source 10.242.128.0 0.0.127.255 destination 10.64.0.97 0 destination-port eq telnet                                                             
    #                          
  • Rule: describes packet matching conditions.
    • Rule ID: identifies an ACL rule. The rule IDs can be manually set or automatically allocated by the system.

      The ACL rule IDs range from 0 to 4294967294. The rule IDs in an ACL are allocated in an ascending order. Therefore, in Figure 1-2, rule 5 is in the first line and rule 4294967294 is in the bottom line of an ACL. The system matches packets against the rules from the first line to the bottom line, and stops matching if the packets match a rule.

    • Action: includes permit and deny.
    • Matching option: ACLs support many matching conditions, including Layer 2 Ethernet frame header information (source MAC, destination MAC, and Ethernet protocol type), Layer 3 packet information (destination address and protocol type), and Layer 4 packet information (TCP/UDP port number). For details about ACL matching conditions, see Matching Conditions.
NOTE:

If the ACL rules with the numbers beyond the acceptable range are set in the configuration file used for startup, the ACL configuration can be generated when the device starts, but some configurations do not take effect.

Matching Mechanism

The device stops matching packets against ACL rules as long as the packets match one rule, as shown in Figure 1-3.

Figure 1-3 ACL matching mechanism

The device checks whether an ACL is configured.

  • If no ACL is configured, the device returns the result "negative match."
  • If an ACL is configured, the device checks whether the ACL contains rules.
    • If the ACL does not contain rules, the device returns the result "negative match."
    • If the ACL contains rules, the device matches the packets against the rules in ascending order of rule IDs.
  • When the packets match a permit rule, the device stops matching and returns the result "positive match (permit)."
  • When the packets match a deny rule, the device stops matching and returns the result "positive match (deny)."
  • If the packets do not match any rule in the ACL, the device returns the result "negative match."

The ACL matching results include "positive match" and "negative match."

  • Positive match: Packets match a rule in an ACL.

    The result is "positive match" regardless of whether packets match a permit or deny rule in an ACL.

  • Negative match: No ACL exists, the ACL does not contain rules, or packets do not match any rule in an ACL.

ACL Classification

Based on ACL Naming Methods

ACLs are classified into:

  • Numbered ACL: This is the traditional naming method. After an ACL is created, a unique number is specified for the ACL.
  • Named ACL: An ACL is identified by a name.

You can specify a number for a created ACL. Different types of ACLs have different number ranges, as described in Table 1-1. You can also specify a name for the created ACL to help you remember the ACL's purpose. A named ACL consists of a name and number. That is, you can specify an ACL number when you define an ACL name. If you do not specify a number for a numbered ACL, the device automatically allocates a number to it.

NOTE:

The name of a named ACL cannot be modified. Deleting an ACL name will delete the ACL.

Repeated ACL names can only be used between basic ACL and basic ACL6, and between advanced ACL and advanced ACL6.

Based on IP Protocol Versions

ACLs are classified into:

  • ACL4: filters IPv4 packets. It is also called ACL.
  • ACL6: filters IPv6 packets. It is also called IPv6 ACL.

In this document, ACL refers to ACL4, ACL6, and the ACL supporting both IPv4 and IPv6 packet filtering. Table 1-1 describes how each type of ACLs supports IPv4 and IPv6 packets.

Based on ACL Rule Definition Methods

Table 1-1 describes the ACLs based on rule definition methods.

Table 1-1 ACL classification based on ACL rule definition methods

Category

IP Version

Rule Definition Description

Number Range

Basic ACL

IPv4

Defines rules based on source IP addresses, fragmentation information, and time ranges.

2000-2999

Advanced ACL

IPv4

Defines rules based on source IPv4 addresses, destination IPv4 addresses, IPv4 protocol types, ICMP types, TCP source/destination port numbers, UDP source/destination port numbers, and time ranges.

3000-3999

Layer 2 ACL

IPv4&IPv6

Defines rules based on information in Ethernet frame headers of packets, such as the source MAC addresses, destination MAC addresses, and Layer 2 protocol types.

4000-4999

User-defined ACL

IPv4&IPv6

Defines rules based on packet headers, offsets, character string masks, and user-defined character strings. The ACL performs an AND operation on the packet bytes from a certain position behind the packet header and the character string mask. Then, the ACL compares the extracted character string against the user-defined character string.

5000-5999

User ACL

IPv4

Defines rules based on source IPv4 addresses/destination IPv4 addresses, IPv4 protocol types, ICMP types, TCP source/destination port numbers, and UDP source/destination port numbers.

6000-6031

Basic ACL6

IPv6

Defines rules based on source IPv6 addresses, fragmentation information, and time ranges.

2000-2999

Advanced ACL6

IPv6

Defines rules based on source IPv6 addresses, destination IPv6 addresses, IPv6 protocol types, ICMPv6 types, TCP source/destination port numbers, UDP source/destination ports, and time ranges.

3000-3999

Step

What Is a Step

A step is an increment between neighboring rule IDs automatically allocated by the system.

If a rule is added to an empty ACL without a rule ID manually specified, the system allocates the step value as the ID to this rule. If an ACL contains rules with manually configured IDs and a new rule is added without an ID manually configured, the system allocates to this new rule the minimum multiple of the step value which is greater than the largest rule ID in the ACL. Rule IDs must be integers. For example, an ACL (basic ACL, advanced ACL, Layer 2 ACL, user ACL) contains rule 5 and rule 12, and the default step is 5. When a new rule is added to the ACL, the system allocates ID 15 to this new rule (15 is greater than 12 and is the minimum multiple of 5).

[Huawei-acl-basic-2001] display this
#                                                                                
acl number 2001              //Empty ACL                                              
#                                                                                
return                             
[Huawei-acl-basic-2001] rule deny source 10.1.1.0 0.0.0.255 //Configure the first rule without specifying an ID. 
[Huawei-acl-basic-2001] display this
#                                                                                
acl number 2001                                                                  
 rule 5 deny source 10.1.1.0 0.0.0.255         
#                                                                                
return          
[Huawei-acl-basic-2001] rule 12 deny source 10.2.2.0 0.0.0.255 //Configure a rule with ID 12. 
[Huawei-acl-basic-2001] display this
#                                                                                
acl number 2001                                                                  
 rule 5 deny source 10.1.1.0 0.0.0.255                                            
 rule 12 deny source 10.2.2.0 0.0.0.255                                           
#                                                                                
return                                    
[Huawei-acl-basic-2001] rule deny source 10.3.3.0 0.0.0.255 //Configure another rule without specifying an ID. 
[Huawei-acl-basic-2001] display this
#                                                                                
acl number 2001                                                                  
 rule 5 deny source 10.1.1.0 0.0.0.255                                            
 rule 12 deny source 10.2.2.0 0.0.0.255                                           
rule 15 deny source 10.3.3.0 0.0.0.255 
#                                                                                
return                         

If the step value of an ACL is changed, the system reallocates IDs to rules in the ACL. For example, when the step value is changed to 2, the system allocates 2, 4, 6... to rules. After the step is restored to the default value, the system reallocates IDs to the rules using the default step, that is, 5, 10, 15....

[Huawei-acl-basic-2001] display acl 2001
Basic ACL 2001, 3 rules                                                          
Acl's step is 5
 rule 5 deny source 10.1.1.0 0.0.0.255                           
 rule 12 deny source 10.2.2.0 0.0.0.255                          
 rule 15 deny source 10.3.3.0 0.0.0.255 
[Huawei-acl-basic-2001] step 2 //Set the step to 2 
[Huawei-acl-basic-2001] display acl 2001
Basic ACL 2001, 3 rules                                                          
Acl's step is 2  
 rule 2 deny source 10.1.1.0 0.0.0.255                           
 rule 4 deny source 10.2.2.0 0.0.0.255                           
 rule 6 deny source 10.3.3.0 0.0.0.255                           
[Huawei-acl-basic-2001] undo step //Restore the default step. 
[Huawei-acl-basic-2001] display acl 2001
Basic ACL 2001, 3 rules                                                          
Acl's step is 5 
 rule 5 deny source 10.1.1.0 0.0.0.255                           
 rule 10 deny source 10.2.2.0 0.0.0.255                          
 rule 15 deny source 10.3.3.0 0.0.0.255                                                                    

How a Step Functions

Setting a step facilitates rule insertion between existing rules of an ACL.

For example, an ACL contains rule 5, rule 10, and rule 15. The network administrator wants to add a rule that denies the packets from source IP address 10.1.1.3. The rules are as follows:

rule 5 deny source 10.1.1.1 0  //Reject the packets from source IP address 10.1.1.1. 
rule 10 deny source 10.1.1.2 0 //Reject the packets from source IP address 10.1.1.2. 
rule 15 permit source 10.1.1.0 0.0.0.255 //Reject the packets from source IP address segment 10.1.1.0/24.     

The system stops matching packets once the packets matching a rule. Therefore, the packets from source addresses 10.1.1.1 and 10.1.1.2 match rule 5 and rule 10, and are discarded; the packets from source address 10.1.1.3 match rule 15, and are forwarded. To deny the packets from source IP address 10.1.1.3, add a new deny rule. You can add rule 11 before rule 15 so that the packets from source IP address 10.1.1.3 match rule 11 and are discarded. Rule 11 does not affect existing rule IDs in the ACL. The rule IDs are 5, 10, 11, and 15.

rule 5 deny source 10.1.1.1 0  //Reject the packets from source IP address 10.1.1.1. 
rule 10 deny source 10.1.1.2 0 //Reject the packets from source IP address 10.1.1.2. 
rule 11 deny source 10.1.1.3 0 //Reject the packets from source IP address 10.1.1.3.
rule 15 permit source 10.1.1.0 0.0.0.255 //Reject the packets from source IP address segment 10.1.1.0.     

To add a rule to an ACL with the step value of 1 (rule 1, rule 2, rule 3...), you must delete existing rules, add the new rule, and then reconfigure the deleted rules.

A step resolves the preceding issue and facilitates rule insertion.

Matching Order

An ACL consists of multiple deny | permit clauses, each of which describes a rule. These rules may repeat or conflict. For example, an ACL contains two rules:

rule deny ip destination 10.1.0.0 0.0.255.255 //Reject the packets destined for network segment 10.1.0.0/16. 
rule permit ip destination 10.1.1.0 0.0.0.255 //Permit the packets destined for network segment 10.1.1.0/24, which has a smaller range than 10.1.0.0/16.

The permit and deny rules conflict. If the system first matches a packet destined for 10.1.1.1 against the deny rule, the packet is discarded. However, if the system matches the packet against the permit rule first, the packet is forwarded.

Therefore, if ACL rules repeat or conflict, the matching order decides the matching result.

The device supports two matching orders: the configuration order (config) and the automatic order (auto). The default order is config.

Config Order

The system matches packets against ACL rules in ascending order of rule IDs. That is, the rule with the smallest ID is processed first.

  • If a smaller rule ID is manually specified for a rule, the rule is inserted in one of the front lines of an ACL, and the rule is processed earlier.
  • If no ID is manually specified for a rule, the system allocates an ID to the rule. The rule ID is greater than the largest rule ID in the ACL and is the minimum multiple of the step; therefore, this rule is processed last.

Auto Order

The system arranges rules according to the precision degree of the rules (depth first principle), and matches packets against the rules in descending order of precision. A rule with the highest precision defines strictest conditions, and has the highest priority. The system matches packets against this rule first. Table 1-2 describes how the auto order is applied to each type of ACL.

For details about the ACL matching conditions mentioned in Table 1-2, such as IP address wildcard mask, types of protocols carried by IP, TCP/UDP ports, Layer 2 protocol type wildcard mask, and MAC address wildcard mask, see Matching Conditions.

Table 1-2 Auto matching order

ACL Type

Matching Rules

Basic ACL and basic ACL6

  1. The rule that defines a VPN instance is processed first.
  2. The rule that defines the smallest source IP address range is processed. The wildcard mask with the most 0 bits identifies the smallest source IP address range.
  3. If the source IP address ranges are the same, the rule with the smallest ID is processed.

Advanced ACL and advanced ACL6

  1. The rule that defines a VPN instance is processed first.
  2. The rule that defines a protocol type is processed.
  3. If the protocol types are the same, the rule that defines the smallest source IP address range is processed. The wildcard mask with the most 0 bits identifies the smallest source IP address range.
  4. If the protocol types and source IP address ranges are the same, the rule that defines the smallest destination IP address range is processed. The wildcard mask with the most 0 bits identifies the smallest destination IP address range.
  5. If the protocol types, source IP address ranges, and destination IP address ranges are the same, the rule that defines the smallest Layer 4 port number (TCP/UDP port number) range is processed.
  6. If the preceding ranges are all the same, the rule with the smallest ID is processed.

Layer 2 ACL

  1. The rule with the largest L2 protocol type wildcard (with the most 1 bits in the wildcard mask) is processed first.
  2. The rule that defines the smallest source MAC address range is processed. The wildcard mask with the most 1 bits identifies the smallest source MAC address range.
  3. If the source MAC address ranges are the same, the rule that defines the smallest destination MAC address range is processed. The wildcard mask with the most 1 bits identifies the smallest destination MAC address range.
  4. If the source and destination MAC address ranges are the same, the rule with the smallest ID is processed.

User ACL

  1. The rule that defines a protocol type is processed first.
  2. If the protocol types are the same, the source IP address ranges are compared. If all source IP addresses are IP network segments, the rule with a smaller source IP address (with more 0 bits in wildcard mask) is processed.
  3. If the protocol types and source IP address ranges are the same, the destination IP address ranges are compared. If all destination IP addresses are IP network segments, the rule with a smaller destination IP address (with more 0 bits in wildcard mask) is processed.
  4. If the protocol types, source IP address ranges, and destination IP address ranges are the same, the rule that defines the smallest Layer 4 port number (TCP/UDP port number) range is processed.
  5. If the preceding ranges are all the same, the rule with the smallest ID is processed.

If you add a rule to an ACL in auto mode, the system automatically identifies the rule priority and assigns an ID to the rule.

For example, two rules are added to advanced ACL 3001 in auto mode:

rule deny ip destination 10.1.0.0 0.0.255.255 //Reject the packets destined for network segment 10.1.0.0/16. 
rule permit ip destination 10.1.1.0 0.0.0.255 //Permit the packets destined for network segment 10.1.1.0/24, which has a smaller range than 10.1.0.0/16.

The two rules do not specify VPN instances, and specify identical protocol range and source IP address range. According to the auto matching principle in Table 1-2, the system compares the destination IP address ranges in the rules. The destination IP address range specified in the permit rule is smaller than that specified in the deny rule, so the permit rule has a higher precision. The system allocates a smaller ID to the permit rule. Therefore, the system arranges the two rules in ACL 3001 in the following order:

#                                                                             
acl number 3001 match-order auto
 rule 5 permit ip destination 10.1.1.0 0.0.0.255      
 rule 10 deny ip destination 10.1.0.0 0.0.255.255    
# 

A rule rule deny ip destination 10.1.1.1 0 is added to ACL 3001 (with a higher priority than the previous two rules because the destination IP address is a host address). The system reassigns IDs to the rules according to the rule priorities. The new order is as follows:

#                                                                       
acl number 3001 match-order auto
rule 5 deny ip destination 10.1.1.1 0            
 rule 10 permit ip destination 10.1.1.0 0.0.0.255   
 rule 15 deny ip destination 10.1.0.0 0.0.255.255  
# 

Compared with the config mode, auto mode is more complex; however, it offers advantages in some scenarios. For example, in the initial network deployment stage, the administrator has configured an ACL in auto mode to discard all IP packets in untrusted network segments to ensure network security. When more services are deployed on the network, some IP packets on these network segments need to be allowed. The administrator needs to add new rules to the ACL, but does not need to rearrange the rules to avoid incorrect packet discarding.

Time Range

Background

An ACL contains various matching conditions to filter most packets. However, networks continue to evolve and requirements change. For example, an enterprise allows employees to access only the specified websites during work hours, and to access other websites in off-hours and weekends. Here is another example. The P2P and downloading services affect other data services during the peak hours of 20:00-22:00; therefore, the network administrator is required to lower the bandwidth for the P2P and downloading services in this period.

Time-based ACL can meet the preceding requirements. The network administrators can create one or more time ranges according to users' network access behaviors and network congestion condition, and associate the time ranges with ACL rules. In this way, administrators can configure different policies in different time ranges to optimize networks.

Time Range Mode

You can associate a time range with ACL rules in either of the following ways:

  • Mode 1 - Periodic time range: defines a time range based on weeks. The associated ACL rules take effect at an interval of one week. For example, if the time range of ACL rules is 8:00-12:00 on Monday, the ACL rules take effect at 8:00-12:00 on every Monday.

    Format: time-range time-name start-time to end-time { days } &<1-7>

    • time-name: indicates the name of a time range. It is a string starting with a letter.
    • start-time to end-time: indicates the start and end time of the time range. The format is [hour:minute] to [hour:minute].
    • days: includes the following values:
  • One of Mon, Tue, Wed, Thu, Fri, Sat, and Sun or a combination of them. The value can also be numeric. For example, 0 indicates Sunday, 1 indicates Monday..., and 6 indicates Saturday.
  • working-day: from Monday to Friday.
  • daily: from Monday to Sunday.
  • off-day: Saturday and Sunday.
  • Mode 2 - Absolute time range: defines a time range from YYYY/MM/DD hh:mm to YYYY/MM/DD hh:mm. The associated ACL rules take effect only in this period.

    Format: time-range time-name from time1 date1 [ to time2 date2 ]

    • time-name: indicates the name of a time range. It is a string starting with a letter.
    • time1/time2: The format is [hour:minute].
    • date1/date2: The format is [YYYY/MM/DD], indicating year/month/date.

You can specify multiple time ranges in the same time-name parameter. The device obtains the intersection of the configured periodic or absolute time ranges.

For example, ACL 2001 is associated with time range test, which contains three sub-ranges:

# 
time-range test 8:00 to 18:00 working-day  
time-range test 14:00 to 18:00 off-day  
time-range test from 00:00 2014/01/01 to 23:59 2014/12/31  
# 
acl number 2001                                                                  
 rule 5 permit time-range test 
  • Sub-range 1: 8:00-18:00 from Monday to Friday (periodic time range)
  • Sub-range 2: 14:00-18:00 on Saturday and Sunday (periodic time range)
  • Sub-range 3: from 2014-1-1 00:00 to 2014-12-31 23:59 (absolute time range)

The time range test is: 8:00-18:00 on Monday to Friday and 14:00-18:00 every Saturday and Sunday in 2014.

Matching Conditions

The device supports various ACL matching conditions. This section describes the commonly used conditions.

Time Range

Format: time-range time-name

All ACLs support packet filtering based on time ranges. For details about time ranges, see Time Range.

Protocol Type Carried by IP

Format: protocol-number | icmp | tcp | udp | gre | igmp | ip | ipinip | ospf

An advanced ACL can filter packets based on protocol types, such as ICMP (protocol number 1), TCP (protocol number 6), UDP (protocol number 17), GRE (protocol number 47), IGMP (protocol number 2), IP (any IP layer protocol), IPinIP (protocol number 4), and OSPF (protocol number 89). The protocol number ranges from 1 to 255.

For example, to forbid user access on an interface connected to a large number of attackers, specify the protocol type as IP to discard all IP traffic on the interface. The configuration is as follows:

rule deny ip //Reject IP packets.

After transparent firewall function is enabled on a device, the transparent firewall discards all packets entering the interzone by default, including service and protocol packets. If you require the packets of a dynamic routing protocol, such as OSPF, to pass through the transparent firewall, specify the protocol type as OSPF.

rule permit ospf  //Permit OSPF packets.

Source/Destination IP Addresses and Wildcard Masks

Format of source IP address and wildcard mask: source { source-address source-wildcard | any }

Format of destination IP address and wildcard mask: destination { destination-address destination-wildcard | any }

A basic ACL can filter packets based on source IP addresses; an advanced ACL can filter packets based on both source and destination IP addresses.

When the source and destination IP addresses are specified as matching conditions, the wildcard masks must be specified for them to determine address ranges.

The IP address wildcard mask format is the same as the inverse subnet mask format (32-bit numeric string). The wildcard mask specifies the digits in the IP address to be checked. Among the bits in a mask, the value 0 indicates "check" and the value 1 indicates "not check." An IP address subnet mask must have continuous 0s and 1s, whereas a wildcard mask can have discontinuous 0s and 1s.

The wildcard mask can be 255.255.255.255 or 0 (equivalent to 0.0.0.0). The value 255.255.255.255 indicates any IP address, which is equivalent to the any keyword. The value 0 indicates that the source/destination address is a host address.

For example, configure a rule with an IP address wildcard mask specified to permit all IP packets from network segment 192.168.1.0/24:

rule 5 permit ip source 192.168.1.0 0.0.0.255

In this rule, the wildcard mask is 0.0.0.255, indicating that only the bits in the binary bytes in the first three groups in the IP address are checked. Therefore, if the first 24 bits in the source IP address are the same as the first 24 bits in the specified IP address (192.168.1), it indicates that the packets are sent from source IP address segment 192.168.1.0/24, and are permitted. Table 1-3 illustrates how the address range is calculated.

Table 1-3 Wildcard mask example

Item

Decimal

Binary

Specified IP address

192.168.1.0

11000000.10101000.00000001.00000000

Wildcard mask

0.0.0.255

00000000.00000000.00000000.11111111

Determined address range

192.168.1.*

* indicates an integer between 0 and 255.

11000000.10101000.00000001.xxxxxxxx

x can be 0 or 1.

For more examples of determining an address range by IP address and wildcard mask, see Table 1-4.

Table 1-4 Determining address ranges by IP addresses and wildcard masks

IP Address

IP Address Wildcard Mask

Determined Address Range

0.0.0.0

255.255.255.255

Any IP address

172.18.0.0

0.0.255.255

IP addresses on network segment 172.18.0.0/16

172.18.5.2

0.0.0.0

Only host address 172.18.5.2

172.18.8.0

0.0.0.7

IP addresses on network segment 172.18.8.0/29

172.18.8.8

0.0.0.7

IP addresses on network segment 172.18.8.8/29

10.1.2.0

0.0.254.255 (discontinuous 1s and 0s in wildcard mask)

IP addresses that are in the range of 10.1.0.0/24 and 10.1.254.0/24 and have an even number in the third byte, for example, 10.1.0.0/24, 10.1.2.0/24, 10.1.4.0/24, and 10.1.6.0/24

Source/Destination MAC Addresses and Wildcard Masks

Format of source MAC address and wildcard mask: source-mac source-mac-address [ source-mac-mask ]

Format of destination MAC address and wildcard mask: destination-mac dest-mac-address [ dest-mac-mask ]

Only the Layer 2 ACL can filter packets based on source and destination MAC addresses.

When the source and destination MAC addresses are specified as matching conditions, the wildcard masks can be specified for them to determine address ranges.

The formats of a MAC address wildcard mask and a MAC address are the same. Both of them are in hexadecimal format. A MAC address wildcard mask consists of six bytes (48 bits) to indicate the bits in a MAC address to be checked. Different from those in an IP address wildcard mask, the value 1 in the MAC address wildcard mask indicates "check" and the value 0 indicates "not check." If the wildcard mask is not specified, the default mask ffff-ffff-ffff is used, indicating that every bit in a MAC address is checked.

Table 1-5 illustrates how a MAC address and a wildcard mask determine an address range.

Table 1-5 Determining address ranges by MAC addresses and wildcard masks

MAC Address

MAC Address Wildcard Mask

Determined Address Range

00e0-fc01-0101

0000-0000-0000

Any MAC address

00e0-fc01-0101

ffff-ffff-ffff

Only 00e0-fc01-0101

00e0-fc01-0101

ffff-ffff-0000

00e0-fc01-0000 to 00e0-fc01-ffff

VLAN ID and Mask

Format of outer VLAN ID and mask: vlan-id vlan-id [ vlan-id-mask ]

Format of inner VLAN ID and mask: cvlan-id cvlan-id [ cvlan-id-mask ]

A Layer 2 ACL can filter packets based on outer and inner VLAN IDs.

When the VLAN IDs are configured as matching conditions, the VLAN mask can be specified behind the VLAN IDs to determine a VLAN range.

A VLAN mask is in the hexadecimal format, ranging from 0x0 to 0xFFF. If the VLAN mask is not specified, the default mask 0xFFF is used, indicating that every bit in the VLAN ID is checked.

Table 1-6 illustrates how a VLAN ID and a mask determine a VLAN range.

Table 1-6 Determining VLAN ranges by VLAN IDs and masks

VLAN ID

VLAN Mask

Determined VLAN Range

10

0x000

Any VLAN

10

0xFFF

Only VLAN 10

10

0xFF0

VLAN 1 to VLAN 10

TCP/UDP Port Number

Format of source port number: source-port { eq port | gt port | lt port | range port-start port-end }

Format of destination port number: destination-port { eq port | gt port | lt port | range port-start port-end }

When the protocol type of an advanced ACL is specified as TCP or UDP, the device can filter packets based on TCP or UDP source/destination port numbers.

The operators of specifying TCP/UDP port numbers are as follows:

  • eq port: equivalent to the source/destination port number.
  • gt port: greater than the destination/source port number.
  • lt port: less than the source/destination port number.
  • range port-start port-end: source/destination port number range. port-start indicates the start port number, and port-end indicates the end port number.

The TCP/UDP port numbers can be represented by numeric or character strings (alias). For example, rule deny tcp destination-port eq 80 can be represented by rule deny tcp destination-port eq www. Table 1-7 and Table 1-8 list the commonly used TCP ports and UDP ports respectively, and provide the corresponding character strings.

Table 1-7 Commonly used TCP ports and character strings

Port Number

Character String

Protocol

Description

7

echo

Echo

Echo service.

9

discard

Discard

Null service used for connectivity test.

13

daytime

Daytime

Daytime protocol.

19

CHARgen

Character generator

Character Generator Protocol.

20

ftp-data

FTP data connections

FTP data port.

21

ftp

File Transfer Protocol(FTP)

File Transfer Protocol (FTP) port.

23

telnet

Telnet

Telnet service.

25

smtp

Simple Mail Transport Protocol (SMTP)

Simple Mail Transfer Protocol (SMTP).

37

time

Time

Time protocol.

43

whois

Nickname (WHOIS)

Directory service.

49

tacacs

TAC Access Control System (TACACS)

Access control system based on TCP/IP authentication (TACACS login host protocol)

53

domain

Domain Name Service (DNS)

Domain name service.

70

gopher

Gopher

Information index protocol (document searching and indexing on the Internet)

79

finger

Finger

Queries online user information on a remote host.

80

www

World Wide Web (HTTP)

Protocol used by the WWW service. HTTP is used to browse web pages.

101

hostname

NIC hostname server

Host name service on the NIC machine.

109

pop2

Post Office Protocol v2

Email protocol version 2.

110

pop3

Post Office Protocol v3

Email protocol version 3.

111

sunrpc

Sun Remote Procedure Call (RPC)

RPC protocol of SUN. It is used to remotely execute commands and used by the network file system (NFS).

119

nntp

Network News Transport Protocol (NNTP)

Network News Transfer Protocol for retrieval of newsgroup messages. It carries USENET.

179

bgp

Border Gateway Protocol (BGP)

Border Gateway Protocol (BGP).

194

irc

Internet Relay Chat (IRC)

Internet Relay Chat (IRC) protocol.

512

exec

Exec (rsh)

Authenticates remote process.

513

login

Login (rlogin)

Remote login.

514

cmd

Remote commands

Used to execute non-interactive commands on a remote system (rshell, rcp).

515

lpd

Printer service

Line Printer Daemon. It is a print service.

517

talk

Talk

Remotely talks with server and client.

540

uucp

Unix-to-Unix Copy Program

Unix-to-Unix copy protocol.

543

klogin

Kerberos login

Kerberos login protocol version 5.

544

kshell

Kerberos shell

Kerberos Remote shell protocol version 5.

Table 1-8 Commonly used UDP ports and character strings

Port Number

Character String

Protocol

Description

7

echo

Echo

Echo service.

9

discard

Discard

Null service used for connectivity test.

37

time

Time

Time protocol.

42

nameserver

Host Name Server

Host name service.

53

dns

Domain Name Service (DNS)

Domain name service.

65

tacacs-ds

TACACS-Database Service

TACACS database service.

67

bootps

Bootstrap Protocol Server

Bootstrap Protocol (BOOTP) Server, also used by Dynamic Host Configuration Protocol (DHCP).

68

bootpc

Bootstrap Protocol Client

Bootstrap Protocol (BOOTP) Client, also used by Dynamic Host Configuration Protocol (DHCP).

69

tftp

Trivial File Transfer Protocol (TFTP)

Trivial File Transfer Protocol (TFTP).

90

dnsix

DNSIX Security Attribute Token Map

DoD Network Security for Information Exchange (DNSIX) Security Attribute Token Map.

111

sunrpc

SUN Remote Procedure Call (SUN RPC)

RPC protocol of SUN. It is used to remotely execute commands and used by the network file system (NFS).

123

ntp

Network Time Protocol (NTP)

Network Time Protocol (NTP), which may be utilized by worm virus.

137

netbios-ns

NETBIOS Name Service

NETBIOS name service.

138

netbios-dgm

NETBIOS Datagram Service

NETBIOS datagram service.

139

netbios-ssn

NETBIOS Session Service

NETBIOS session service.

161

snmp

SNMP

Simple Network Management Protocol (SNMP).

162

snmptrap

SNMPTRAP

SNMP trap.

177

xdmcp

X Display Manager Control Protocol (XDMCP)

X Display Manager Control Protocol (XDMCP).

434

mobilip-ag

MobileIP-Agent

Mobile IP agent.

435

mobilip-mn

MobileIP-MN

Mobile IP management.

512

biff

Mail notify

Notifies user of received emails.

513

who

Who

Login user list.

514

syslog

Syslog

UNIX system log service.

517

talk

Talk

Remotely talks with server and client.

520

rip

Routing Information Protocol

RIP routing protocol.

TCP Flag

Format: tcp-flag { ack | established | fin | psh | rst | syn | urg }*

When the TCP protocol is specified in an advanced ACL, the device filters packets based on the TCP flag.

A TCP packet header contains six flag bits:

  • URG(100000): indicates that the Urgent pointer field is significant.
  • ACK(010000): indicates that the Acknowledgment field is significant.
  • PSH(001000): push function. Asks to push the buffered data to the receiving application.
  • RST(000100): resets the connection.
  • SYN(000010): synchronizes sequence numbers to initiate a connection.
  • FIN(000001): no more data from sender.

The established field in TCP flags indicates that the flag bit is ACK(010000) or RST(000100).

The ACL rule with the tcp-flag keyword specified can implement unidirectional access control. For example, it is required that users on network segment 192.168.1.0/24 can access network segment 192.168.2.0/24, but users on network segment 192.168.2.0/24 cannot access network segment 192.168.1.0/24. To meet this requirement, you can apply an ACL rule to the inbound direction of the interface connecting to network segment 192.168.2.0/24.

From TCP connection setup to teardown only the packets used for TCP connection establishment can have the ACK value of 1 and RST value of 1. According to this characteristic, configure the following ACL rules to permit the packets used for establishing TCP connections and deny other TCP packets on the network segment 192.168.2.0/24. In this way, you can limit the TCP connection requests initiated from this network segment.

  • Rule 1: Configure an ACL rule with the ack and rst keywords specified.
    rule 5 permit tcp source 192.168.2.0 0.0.0.255 tcp-flag ack  //Permit the TCP packets with the ACK value of 1.        
    rule 10 permit tcp source 192.168.2.0 0.0.0.255 tcp-flag rst //Permit the TCP packets with the RST value of 1. 
    rule 15 deny tcp source 192.168.2.0 0.0.0.255  //Reject other TCP packets.     
  • Rule 2: Configure an ACL rule with the established keyword specified.
    rule permit tcp source 192.168.2.0 0.0.0.255 tcp-flag established  //established indicates that ACK is 1 or RST is 1. The packets exchanged during TCP connection established are permitted. 
    rule deny tcp source 192.168.2.0 0.0.0.255     //Reject other TCP packets.     

IP Fragmentation

Format: none-first-fragment

A basic ACL and an advanced ACL can filter packets based on IP fragmentation information.

The fragments of an IP packet include the initial fragment and non-initial fragments. Only the initial fragment contains Layer 4 information, such as TCP and UDP port numbers. A network device checks whether a received fragment is the last fragment. If the fragment is not the last, the device allocates memory space for it, and reassembles the fragments after the last fragment is received. However, an exploit exists whereby an attacker may send fragments to a device without sending the last fragment. Because the device cannot release memory until the last fragment is received and all fragments are reassembled, if a large enough number of fragments are sent in a short period, the device cannot process other services due to insufficient memory resources. To mitigate such an attack, the device starts a reassembling timer. If reassembly cannot be finished before the timer expires, the device returns an ICMP Error packet to the sender; if reassembly cannot be finished after the timer expires, the device discards the fragments stored in memory.

To prevent fragment packet attacks, you can specify the none-first-fragment keyword in an ACL rule to block non-initial fragments.

Table 1-9 describes how the ACLs process non-fragment packets, initial fragments, and non-initial fragments.

Table 1-9 IP packet processing methods

Matching Conditions

Non-fragment Packets

Initial Fragments

Non-initial Fragments

Layer 3 information (such as source/destination IP addresses)

When packets match Layer 3 information, the matching result (permit or deny) is returned; otherwise, the next rule is processed.

When packets match Layer 3 information, the matching result (permit or deny) is returned; otherwise, the next rule is processed.

When packets match Layer 3 information, the matching result (permit or deny) is returned; otherwise, the next rule is processed.

Layer 3 information and Layer 4 information (such as TCP and UDP port numbers)

When packets match both Layer 3 and Layer 4 information, the matching result (permit or deny) is returned; otherwise, the next rule is processed.

When packets match both Layer 3 and Layer 4 information, the matching result (permit or deny) is returned; otherwise, the next rule is processed.

The packets do not match the rule, so the next rule is processed.

Layer 3 information and none-first-fragment

The packets do not match the rule, so the next rule is processed.

The packets do not match the rule, so the next rule is processed.

When packets match Layer 3 information, the matching result (permit or deny) is returned; otherwise, the next rule is processed.

For example, ACL 3012 contains the following rules:

#   
acl number 3012                                                                  
 rule 5 deny tcp destination 192.168.2.2 0 none-first-fragment                   
 rule 10 permit tcp destination 192.168.2.2 0 destination-port eq www            
 rule 15 deny ip                                                                 
#  
  • This packet is a non-fragment packet or initial fragment: If the destination port number is 80 (WWW), this packet matches rule 10 and is permitted; otherwise, the packet matches rule 15 and is discarded.
  • The packet is a non-initial fragment: The packet matches rule 5 and is discarded.

ACL Configuration Guidelines

When configuring ACL rules, follow these guidelines:

  1. The rules in an ACL may overlap. If packets match the rules with loose conditions, the later ACL rules are not processed. In this case, packets cannot match the rules with strict conditions. Therefore, the rules with strict conditions must be arranged in front lines and those with loose conditions must be arranged towards the end.
  2. The ACL configuration guidelines vary according to the default ACL actions taken by the service modules (for details, see en-us_topic_0172867619.xml). For example, if a service module with the default action of permit must deny the packets from some IP addresses, deny rules only for these IP addresses need to be configured; a permit rule for any IP address is not required. The converse is true for a service module whose default action is deny. Table 1-10 describes the ACL configuration guidelines.
NOTE:

The following rules are for reference. Adhere to the command line syntax when configuring ACL rules.

  • rule permit xxx/rule permit xxxx: allows the specified packets to pass. xxx/xxxx indicates packet attributes, such as source IP address, source MAC address, and time range. The range xxxx involves the range xxx. For example, if xxx is an IP address, xxxx is the network segment where the IP address resides or any (any IP address); if xxx is a time range on Saturday, xxxx is all day long on weekends or from Monday to Sunday.
  • rule deny xxx/rule deny xxxx: blocks the specified packets.
  • rule permit: allows all packets to pass.
  • rule deny: blocks all packets.
Table 1-10 ACL configuration guidelines

Default ACL Action

Permit All Packets

Deny All Packets

Permit a Few Packets and Deny Most Packets

Deny a Few Packets and Permit Most Packets

permit

No ACL is required.

Configure rule deny.

Configure rule permit xxx first, and then rule deny xxxx or rule deny.

NOTE:

This guideline applies to packet filtering. When an ACL is applied to traffic policing or traffic statistics collection in a traffic policy, configure rule permit xxx if you only need to count rate or collect statistics on the specified packets.

Only rule deny xxx is required, and rule permit xxxx or rule permit is not required.

NOTE:

If rule permit is configured and ACL is applied to a traffic policy in which the behavior is deny, all packets are rejected and all services are interrupted.

deny

  • Routing and multicast module: Configure rule permit.
  • Other modules: ACL is not required.
  • Routing and multicast modules: ACL is not required.
  • Other modules: Configure rule deny.

Only rule permit xxx is required, and rule deny xxxx or rule deny is not required.

Configure rule deny xxx first, and then rule permit xxxx or rule permit.

Example:

  • Example 1: Apply an ACL to a traffic policy to filter packets from network segment 192.168.1.0/24. Reject the packets from hosts 192.168.1.2 and 192.168.1.3, and allow the packets from other hosts on network segment 192.168.1.0/24 to pass.

    The default ACL action of the traffic policy module is permit, and a few packets are denied and most packets are permitted. Therefore, you only need to configure rule deny xxx.

    # 
    acl number 2000 
     rule 5 deny source 192.168.1.2 0 
     rule 10 deny source 192.168.1.3 0 
    #
  • Example 2: Apply an ACL to a traffic policy to filter packets from network segment 192.168.1.0/24. Allow the packets from hosts 192.168.1.2 and 192.168.1.3 to pass, and reject the packets from other hosts on network segment 192.168.1.0/24.

    The default ACL action of the traffic policy module is permit, and a few packets are permitted and most packets are denied. Therefore, you need to configure rule permit xxx first, and then rule deny xxxx.

    # 
    acl number 2000 
     rule 5 permit source 192.168.1.2 0 
     rule 10 permit source 192.168.1.3 0 
     rule 15 deny source 192.168.1.0 0.0.0.255 
    #
  • Example 3: Apply an ACL to Telnet, to allow only the administrator's host (172.16.105.2) to Telnet to the device and reject other users.

    The default ACL action of the Telnet module is deny, and a few packets are permitted and most packets are denied. Therefore, you only need to configure rule permit xxx.

    # 
    acl number 2000 
     rule 5 permit source 172.16.105.2 0 
    #     
  • Example 4: Apply an ACL to Telnet, to forbid two hosts (172.16.105.3 and 172.16.105.4) to Telnet to the device and allow other user hosts to Telnet to the device.

    The default ACL action of the Telnet module is deny, and a few packets are denied and most packets are permitted. Therefore, you need to configure rule deny xxx first, and then rule permit.

    # 
    acl number 2000 
     rule 5 deny source 172.16.105.3 0 
     rule 10 deny source 172.16.105.4 0 
     rule 15 permit 
    #     
  • Example 5: Apply an ACL to FTP to prevent users from accessing the FTP server from 00:00-08:00 every Saturday.

    The default ACL action of the FTP module is deny, and a few packets are denied and most packets are permitted. Therefore, you need to configure rule deny xxx first, and then rule permit xxxx.

    # 
    time-range t1 00:00 to 08:00 Sat 
    time-range t2 00:00 to 23:59 daily 
    #  
    acl number 2000 
     rule 5 deny time-range t1 
     rule 10 permit time-range t2 
    #     

Translation
Download
Updated: 2019-06-29

Document ID: EDOC1100086647

Views: 1464

Downloads: 108

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next