Access Security Guide K/KA/KB.15.15

• 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:
IPv4 ACLs can enhance network security by blocking selected traffic, and can serve as one aspect
of maintaining network security. However, because ACLs do not provide user or device
authentication, or protection from malicious manipulation of data carried in IP packet transmissions,
they should not be relied upon for a complete security solution.
NOTE: Static IPv4 ACL HP switches do not filter non-IPv4 traffic such as IPv6, AppleTalk, and
IPX. RADIUS-assigned ACLs assigned by a RADIUS server can be configured on the server to filter
both IPv4 and IPv6 traffic, but do not filter non-IP traffic.
Guidelines for planning the structure of a static ACL
After determining the filtering type (standard or extended) and ACL application (RACL, 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”
(page 306).
• 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.
Configuring standard ACLs
A standard ACL uses only source IPv4 addresses in its ACEs. This type of ACE is useful when you
need to:
• Permit or deny any IPv4 traffic based on source address only.
• Quickly control the IPv4 traffic from a specific address. This allows you to isolate IPv4 traffic
problems generated by a specific device, group of devices, or a subnet threatening to degrade
network performance. This gives you an opportunity to troubleshoot without sacrificing
performance for users outside of the problem area.
A named, standard ACL is identified by an alphanumeric string of up to 64 characters and is
created by entering the Named ACL (nacl) context. A numbered, standard ACL is identified by
318 IPv4 Access Control Lists (ACLs)