Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 10

1.1 Introduction to ACL 1.1.

1 Introduction As network scale and network traffic are increasingly growing, network security and bandwidth allocation become more and more critical to network management. Packet filtering can be used to efficiently prevent illegal users from accessing networks and to control network traffic and save network resources. Access control lists (ACL) are often used to filter packets with configured matching rules. ACLs are sets of rules (or sets of permit or deny statements) that decide what packets can pass and what should be rejected based on matching criteria such as source MAC address, destination MAC address, source IP address, destination IP address, and port number. 1.1.2 Application of ACLs on the Switch The switch supports two ACL application modes: Hardware-based application: An ACL is assigned to a piece of hardware. For example, an ACL can be referenced by QoS for traffic classification. Note that when an ACL is referenced to implement QoS, the actions defined in the ACL rules, deny or permit, do not take effect; actions to be taken on packets matching the ACL depend on the traffic behavior definition in QoS. For details about traffic behavior, refer to the QoS part in this manual.

Software-based application: An ACL is referenced by a piece of upper layer software. For example, an ACL can be referenced to configure login user control behavior, thus controlling Telnet, SNMP and Web users. Note that when an ACL is reference by the upper layer software, actions to be taken on packets matching the ACL depend on those defined by the ACL rules. For details about login user control, refer to the part about login configuration in this manual.

Note: When an ACL is assigned to a piece of hardware and referenced by a QoS policy for traffic classification, the switch does not take action according to the traffic behavior definition on a packet that does not match the ACL. When an ACL is referenced by a piece of software to control Telnet, SNMP, and Web login users, the switch denies all packets that do not match the ACL.

1.2 Introduction to IPv4 ACL 1.2.1 IPv4 ACL Classification IPv4 ACLs, identified by ACL numbers, fall into four categories, as shown in Table 1-1. Table 1-1 IPv4 ACL categories Category Basic IPv4 ACL Advanced IPv4 ACL ACL number 2000 to 2999 3000 to 3999 Matching criteria Source IP address Source IP address, destination IP address, protocol carried on IP, and other Layer 3 or Layer 4 protocol header information

Ethernet frame header ACL

4000 to 4999

Layer 2 protocol header fields such as source MAC address, destination MAC address, 802.1p priority, and link layer protocol type

1.2.2 IPv4 ACL Naming When creating an IPv4 ACL, you can specify a unique name for it. Afterwards, you can identify the ACL by its name. An IPv4 ACL can have only one name. Whether to specify a name for an ACL is up to you. After creating an ACL, you cannot specify a name for it, nor can you change or remove the name of the ACL. Note: The name of an IPv4 ACL must be unique among IPv4 ACLs. However, an IPv4 ACL and an IPv6 ACL can share the same name.

1.2.3 IPv4 ACL Match Order An ACL consists of multiple rules, each of which specifies different matching criteria. These criteria may have overlapping or conflicting parts. This is where the order in which a packet is matched against the rules comes to rescue. Two match orders are available for IPv4 ACLs: config: where packets are compared against ACL rules in the order in which they are configured. auto: where depth-first match is performed. The term depth-first match has different meanings for different types of ACLs. I. Depth-first match for a basic IPv4 ACL The following shows how your switch performs depth-first match in a basic IPv4 ACL:

1) Sort rules by VPN instance first and compare packets against the rule configured with a VPN instance. 2) In case of a tie, sort rules by source IP address wildcard first and compare packets against the rule configured with more zeros in the source IP address wildcard. 3) If two rules are present with the same number of zeros in their source IP address wildcards, compare packets against the rule configured first prior to the other. II. Depth-first match for an advanced IPv4 ACL The following shows how your switch performs depth-first match in an advanced IPv4 ACL: 1) Sort rules by VPN instance first and compare packets against the rule configured with a VPN instance. 2) If two rules are present with VPN instances, look at the protocol range in addition. Then compare packets against the rule with the protocol carried on IP specified prior to the other. 3) If the protocol ranges are the same, look at source IP address wildcard. Then, compare packets against the rule configured with more zeros in the source IP address wildcard prior to the other. 4) If the numbers of zeros in the source IP address wildcards are the same, look at the destination IP address wildcards. Then, compare packets against the rule configured with more zeros in the destination IP address wildcard prior to the other. 5) If the numbers of zeros in the destination IP address wildcards are the same, look at the Layer 4 port number (TCP/UDP port number). Then compare packets against the rule configured with the lower port number prior to the other. 6) If the port numbers are the same, compare packets against the rule configured first prior to the other.

III. Depth-first match for an Ethernet frame header ACL The following shows how your switch performs depth-first match in an Ethernet frame header ACL: 1) Sort rules by source MAC address mask first and compare packets against the rule configured with more ones in the source MAC address mask prior to other rules. 2) If two rules are present with the same number of ones in their source MAC address masks, look at the destination MAC address masks. Then, compare packets against the rule configured with more ones in the destination MAC address mask prior to the other. 3) If the numbers of ones in the destination MAC address masks are the same, the one configured first is compared prior to the other. The comparison of a packet against an ACL stops once a match is found. The packet is then processed as per the rule. 1.2.4 IPv4 ACL Step I. Meaning of the step When defining rules in an IPv4 ACL, you do not necessarily assign them numbers; the system can do this automatically, and the step defines the increment between two neighboring numbers. For example, with a step of 5, rules are automatically numbered 0, 5, 10, 15, and so on. By default, the step is 5. Whenever the step changes, the rules are renumbered. Continuing with the above example, if you change the step from 5 to 2, the rules are renumbered 0, 2, 4, 6, and so on.

II. Benefits of using the step With the step and rule numbering/renumbering mechanism, you do not need to assign rules numbers when defining them. The system will assign a newly defined rule a number that is the smallest multiple of the step bigger than the currently biggest number. For example, with a step of five, if the biggest number is currently 28, the newly defined rule will get a number of 30. If the ACL has no rule defined already, the first defined rule will get a number of 0. Another benefit of using the step is that it allows you to insert new rules between existing ones as needed. For example, after creating four rules numbered 0, 5, 10, and 15 in an ACL with a step of five, you can insert a rule numbered 1. 1.2.5 Effective Period of an IPv4 ACL You can control when a rule can take effect by referencing a time range in the rule. A referenced time range can be one that has not been created yet. The rule, however, can take effect only after the time range is defined and comes active. 1.2.6 IP Fragments Filtering with IPv4 ACL Traditional packet filtering performs match operation on, rather than all IP fragments, the first ones only. All subsequent non-first fragments are handled in the way the first fragments are handled. This causes security risk as attackers may fabricate non-first fragments to attack your network. A rule defined with the fragment keyword applies to only IP fragments. Note that a rule defined with the fragment keyword matches non-last IP fragments on an SA Series LPUs (line processing units) (for example, LSQ1FP48SA) or EA Series LPUs (for example, LSQ1GP12EA) while matching non-first IP fragments on an SC Series LPUs (for example, LSQ1GP24SC). For detailed information about types of LPUs, refer to the installation manual.

2.7 IPv4 ACL Configuration Example 2.7.1 Network Requirements

As shown in Figure 2-1, a company interconnects its departments through the switch. Configure an ACL to deny access of all departments but the Presidents office to the salary query server during office hours (from 8:00 to 18:00) in working days.

2.7.2 Network Diagram President`s office 192.168.1.0/24 Salary query server 192.168.4.1

Eth2/0/1 Eth2/0/4 Eth2/0/2 Eth2/0/3 Switch

Marketing department 192.168.3.0/24 Figure 2-1 Network diagram for IPv4 ACL configuration

R&D department 192.168.2.0/24

2.7.3 Configuration Procedure

1) Create a time range for office hours # Create a periodic time range spanning 8:00 to 18:00 in working days. <Switch> system-view [Switch] time-range trname 8:00 to 18:00 working-day 2) Define an ACL to control access to the salary query server # Configure a rule to control access of the R&D Department to the salary query server. [Switch] acl number 3000 [Switch-acl-adv-3000] rule deny ip source 192.168.2.0 0.0.0.255 destination 192.168.4.1 0.0.0.0 time-range trname [Switch-acl-adv-3000] quit # Configure a rule to control access of the Marketing Department to the salary query server. [Switch] acl number 3001 [Switch-acl-adv-3001] rule deny ip source 192.168.3.0 0.0.0.255 destination 192.168.4.1 0.0.0.0 time-range trname [Switch-acl-adv-3001] quit 3) Apply the IPv4 ACL # Configure class c_rd for packets matching IPv4 ACL 3000. [Switch] traffic classifier c_rd [Switch-classifier-c_rd] if-match acl 3000 [Switch-classifier-c_rd] quit

# Configure traffic behavior b_rd to deny matching packets. [Switch] traffic behavior b_rd [Switch-behavior-b_rd] filter deny [Switch-behavior-b_rd] quit
# Configure class c_market for packets matching IPv4 ACL 3001. [Switch] traffic classifier c_market [Switch-classifier-c_market] if-match acl 3001 [Switch-classifier-c_market] quit # Configure traffic behavior b_ market to deny matching packets. [Switch] traffic behavior b_market [Switch-behavior-b_market] filter deny [Switch-behavior-b_market] quit # Configure QoS policy p_rd to use traffic behavior b_rd for class c_rd. [Switch] qos policy p_rd [Switch-qospolicy-p_rd] classifier c_rd behavior b_rd [Switch-qospolicy-p_rd] quit # Configure QoS policy p_market to use traffic behavior b_market for class c_market. [Switch] qos policy p_market [Switch-qospolicy-p_market] classifier c_market behavior b_market [Switch-qospolicy-p_market] quit # Apply QoS policy p_rd to interface Ethernet 2/0/2. [Switch] interface Ethernet 2/0/2 [Switch-Ethernet2/0/2] qos apply policy p_rd inbound [Switch-Ethernet2/0/2] quit # Apply QoS policy p_market to interface Ethernet 2/0/3. [Switch] interface Ethernet 2/0/3 [Switch-Ethernet2/0/3] qos apply policy p_market inbound

You might also like