Before creating and implementing ACLs, you need to define the policies you want your ACLs to enforce, and understand how the ACL assignments will impact your network users.
|
|
|
![[NOTE: ]](images/note.gif) |
NOTE: All IPv4 traffic entering the switch on a given interface is filtered by all ACLs configured for inbound traffic on that interface. For this reason, an inbound IPv4 packet will be denied (dropped) if it has a match with either an implicit or explicit See Multiple ACLs on an interface for more detail. |
|
|
Use ACLs to block traffic from individual hosts, workgroups, or subnets, and to block access to VLANs, subnets, devices, and services.
Traffic criteria for ACLs include:
-
Switched and/or routed traffic
-
Any traffic of a specific IPv4 protocol type (0-255)
-
Any TCP traffic (only) for a specific TCP port or range of ports, including optional control of connection traffic based on whether the initial request should be allowed
-
Any UDP traffic or UDP traffic for a specific UDP port
-
Any ICMP traffic or ICMP traffic of a specific type and code
-
Any IGMP traffic or IGMP traffic of a specific type
Depending on the source and/or destination of a given IPv4 traffic type, you must also determine the ACL application(s) (static port ACL) needed to filter the traffic on the applicable switch interfaces.
Answering the following questions can help you to design and properly position IPv4 ACLs for optimum network usage.
-
What are the logical points for minimizing unwanted traffic, and what ACL application(s) should be used? In many cases it makes sense to prevent unwanted traffic from reaching the core of your network by configuring ACLs to drop the unwanted traffic at or close to the edge of the network. The earlier in the network path you can block unwanted traffic, the greater the benefit for network performance.
-
From where is the traffic coming? The source and destination of traffic you want to filter determines the ACL application to use (static port ACL and RADIUS-assigned ACL).
-
What traffic should you explicitly block? Depending on your network size and the access requirements of individual hosts, this can involve creating a large number of ACEs in a given ACL (or a large number of ACLs), which increases the complexity of your solution.
-
What traffic can you implicitly block by taking advantage of the implicit
deny ip anyto deny traffic that you have not explicitly permitted? This can reduce the number of entries needed in an ACL. -
What traffic should you permit? In some cases you will need to explicitly identify permitted traffic. In other cases, depending on your policies, you can insert an ACE with "permit any" forwarding at the end of an ACL. This means that all IPv4 traffic not specifically matched by earlier entries in the list will be permitted.
ACLs can enhance security by blocking traffic carrying an unauthorized source IPv4 address (SA). This can include:
-
Blocking access from specific devices or interfaces (port or VLAN)
-
Blocking access to or from subnets in your network
-
Blocking access to or from the internet
-
Blocking access to sensitive data storage or restricted equipment
-
Preventing specific IPv4, TCP, UDP, IGMP, and ICMP traffic types, including unauthorized access using functions such as Telnet, SSH, and web browser
You can also enhance switch management security by using ACLs to block IPv4 traffic that has the switch itself as the destination address (DA).
![[CAUTION: ]](images/caution.gif)
After determining the filtering type (standard or extended) and ACL application (VACL or static port ACL) to use at a particular point in your network, determine the order in which to apply individual ACEs to filter IPv4 traffic. For information on ACL applications, see ACL applications.
-
The sequence of ACEs is significant. When the switch uses an ACL to determine whether to permit or deny a packet on a particular VLAN, it compares the packet to the criteria specified in the individual Access Control Entries (ACEs) in the ACL, beginning with the first ACE in the list and proceeding sequentially until a match is found. When a match is found, the switch applies the indicated action (permit or deny) to the packet.
-
The first match in an ACL dictates the action on a packet. Subsequent matches in the same ACL areignored.However, if a packet is permitted by one ACL assigned to an interface, but denied by another ACL assigned to the same interface, the packet will be denied on the interface.
-
On any ACL, the switch implicitly denies IPv4 packets that are not explicitly permitted or denied by the ACEs configured in the ACL. If you want the switch to forward a packet for which there is not a match in an ACL, append an ACE that enables Permit Any forwarding as the last ACE in the ACL. This ensures that no packets reach the Implicit Deny case for that ACL.
-
Generally, you should list ACEs from the most specific (individual hosts) to the most general (subnets or groups of subnets) unless doing so permits traffic that you want dropped. For example, an ACE allowing a small group of workstations to use a specialized printer should occur earlier in an ACL than an entry used to block widespread access to the same printer.
|
A VACL filters traffic entering the switch on the VLANs to which it is assigned. |
|
|
A static port ACL filters traffic entering the switch on the ports or trunks to which it is assigned. |
|
|
At a minimum an ACL must have one, explicit "permit" or "deny" Access Control Entry. You can configure up to 2048 IPv4ACLs each for IPv4 and IPv6. The maximums are as follows:
|
|
|
In any static IPv4 ACL, the switch automatically applies an implicit For Implicit Deny operation in dynamic ACLs, see RADIUS Services Support on HP Switches. |
|
|
Entering a |
|
|
Entering a |
|
|
For a specific interface, the most recent ACL assignment using a given application replaces any previous ACL assignment using the same application on the same interface. |
|
|
These are applied per-port, per port-list, or per static trunk. Adding a port to a trunk applies the trunk's ACL configuration to the new member. If a port is configured with an ACL, the ACL must be removed before the port is added to the trunk. Also, removing a port from an ACL-configured trunk removes the ACL configuration from that port. |
|
|
These filter any IPv4 traffic entering the switch through any port belonging to the designated VLAN. VACLs do not filter traffic leaving the switch or being routed from another VLAN. |
|
|
You can assign an ACL to any VLAN that is statically configured on the switch. ACLs do not operate with dynamic VLANs. |
|
|
A VACL assigned to a VLAN applies to all physical ports on the switch belonging to that VLAN, including ports that have dynamically joined the VLAN. |
When the switch applies an ACL to IPv4 traffic, each ACE in the ACL uses an IPv4 address and ACL mask to enforce a selection policy on the packets being screened. That is, the mask determines the range of IPv4 addresses (SA only or SA/DA) that constitute a match between the policy and a packet being screened.
In common IPv4 addressing, a network (or subnet) mask defines which part of the address to use for the network number and which part to use for the hosts on the network. For example:
| Address | Mask | Network address | Host address |
|---|---|---|---|
| 10.38.252.195 | 255.255.255.0 | first three octets | The fourth octet. |
| 10.38.252.195 | 255.255.248.0 | first two octets and the left- most five bits of the third octet | The right most three bits of the third octet and all bits in the fourth octet. |
Thus, the bits set to 1 in a network mask define the part of an IPv4 address to use for the network number, and the bits set to 0 in the mask define the part of the address to use for the host number.
In an ACL, IPv4 addresses and masks provide criteria for determining whether to deny or permit a packet, or to pass it to the next ACE in the list. If there is a match, the configured deny or permit action occurs. If there is not a match, the packet is compared with the next ACE in the ACL. Thus, where a standard network mask defines how to identify the network and host numbers in an IPv4 address, the mask used with ACEs defines which bits in a packet's SA or DA must match the corresponding bits in the SA or DA listed in an ACE, and which bits can be wildcards.
-
For a given ACE, when the switch compares an IPv4 address and corresponding mask in the ACE to an IPv4 address carried in a packet:
-
A mask-bit setting of 0 ("off") requires that the corresponding bits in the packet's address and in the ACE's address must be the same. Thus, if a bit in the ACE's address is set to 1 ("on"), the same bit in the packet's address must also be 1.
-
A mask-bit setting of 1 ("on") means the corresponding bits in the packet's address and in the ACE's address do not have to be the same. Thus, if a bit in the ACE's address is set to 1, the same bit in the packet's address can be either 1 or 0 ("on" or "off").
For an example, see Example of how the mask bit settings define a match.
-
-
In any ACE, a mask of all ones means any IPv4 address is a match. Conversely, a mask of all zeros means the only match is an IPv4 address identical to the host address specified in the ACE.
-
Depending on your network, a single ACE that allows a match with more than one source or destination IPv4 address may allow a match with multiple subnets. For example, in a network with a prefix of 31.30.240 and a subnet mask of 255.255.240.0 (the leftmost 20 bits), applying an ACL mask of 0.0.31.255 causes the subnet mask and the ACL mask to overlap one bit, which allows matches with hosts in two subnets: 31.30.224.0 and 31.30.240.0.
Bit Position in the Third Octet of Subnet Mask 255.255.240.0 Bit Values 128 64 32 16 8 4 2 1 Subnet Mask Bits 1 1 1 1 n/a n/a n/a n/a Mask Bit Settings Affecting Subnet Addresses 0 0 0 1 or 0 n/a n/a n/a n/a This ACL supernetting technique can help to reduce the number of ACLs you need. You can apply it to a multinetted VLAN and to multiple VLANs. However, ensure that you exclude subnets that do not belong in the policy. If this creates a problem for your network, you can eliminate the unwanted match by making the ACEs in your ACL as specific as possible, and using multiple ACEs carefully ordered to eliminate unwanted matches.
-
Every IPv4 address and mask pair (source or destination) used in an ACE creates one of the following policies:
This policy states that every bit in every octet of a packet's SA must be the same as the corresponding bit in the SA defined in the ACE.
In this case you provide both the address and the mask. For example:
Syntax:
-
In the first three octets of a packet's SA, every bit must be set the same as the corresponding bit in the SA defined in the ACE.
-
In the last octet of a packet's SA, the first three bits must be the same as in the ACE, but the last five bits are wildcards and can be any value.
-
-
Unlike subnet masks, the wildcardbits in an ACL mask need not be contiguous. For example, 0.0.7.31 is a valid ACL mask. However, a subnet mask of 255.255.248.224 is not a valid subnet mask.
Assume an ACE where the second octet of the mask for an SA is 7 (the rightmost three bits are "on", or "1") and the second octet of the corresponding SA in the ACE is 31 (the rightmost five bits). In this case, a match occurs when the second octet of the SA in a packet being filtered has a value in the range of 24 to 31. See How the mask defines a match.
How the mask defines a match
Suppose, for example, that you have configured the ACL in An ACL with an ACE that allows only one source address to filter inbound packets on VLAN 20. Because the mask is all zeros, the ACE policy dictates that a match occurs only when the source address on such packets is identical to the address configured in the ACE.
Using an IP address and mask in an ACE provides examples of how to apply masks to meet various filtering requirements.
Using an IP address and mask in an ACE
| Address in the ACE | Mask | Policy for a match between a packet and the ACE | Allowed addresses |
|---|---|---|---|
| A: 10.38.252.195 | 0.0.0.255 | Exact match in first three octets only. |
10.38.252.<0-255> (See row A in Mask effect on selected octets of the IPv4 addresses in Table 26) |
| B: 10.38.252.195 | 0.0.7.255 | Exact match in the first two octets and the leftmost five bits (248) of the third octet. |
10.38.<248-255>.<0-255> (In the third octet, only the rightmost three bits are wildcard bits. The leftmost five bits must be a match, and in the ACE, these bits are all set to 1. See row B in Mask effect on selected octets of the IPv4 addresses in Table 26. |
| C: 10.38.252.195 | 0.0.0.0 | Exact match in all octets. |
10.38.252.195 (There are no wildcard bits in any of the octets. See row C in Mask effect on selected octets of the IPv4 addresses in Table 26.) |
| D: 10.38.252.195 | 0.15.255.255 | Exact match in the first octet and the leftmost four bits of the second octet. |
10.<32-47> .<0-255> .<0-255> (In the second octet, the rightmost four bits are wildcard bits. See row D in Mask effect on selected octets of the IPv4 addresses in Table 26.) |
Mask effect on selected octets of the IPv4 addresses in Using an IP address and mask in an ACE
| Addr | Octet | Mask | Octet range | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| A | 3 | 0 all bits | 252 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 |
| B | 3 | 7 last 3 bits | 248-255 | 1 | 1 | 1 | 1 | 1 | 0 or 1 | 0 or 1 | 0 or 1 |
| C | 4 | 0 all bits | 195 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 |
| D | 2 | 15 last 4 bits | 32-47 | 0 | 0 | 1 | 0 | 0 or 1 | 0 or 1 | 0 or 1 | 0 or 1 |
| Shaded areas indicate bit settings that must be an exact match. | |||||||||||
If there is a match between the policy in the ACE and the IPv4 address in a packet, the packet is either permitted or denied according to how the ACE is configured. If there is no match, the next ACE in the ACL is applied to the packet. The same operation applies to a destination IPv4 address used in an extended ACE.
Where an ACE includes both source and destination addresses, there is one address/ACL-mask pair for the source address, and another address/ACL-mask pair for the destination address.