What Is an Access Control List (ACL)?

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 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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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

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.

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.

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.

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.

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.