HP Networking guide to hardening Comware-based devices
Table Of Contents
- Introduction
- Management plane
- General management plane hardening
- Limiting access to the network with infrastructure ACLs
- Securing interactive management sessions
- Fortifying Simple Network Management Protocol
- Logging best practices
- HP Comware software configuration management
- Control plane
- General control plane hardening
- Limiting the CPU impact of control plane traffic
- Securing BGP
- Securing Interior Gateway Protocols
- Securing Virtual Router Redundancy Protocol
- Data plane
- General data plane hardening
- Filtering transit traffic with Transit ACLs
- Anti-spoofing protections
- Limiting the CPU impact of data plane traffic
- Traffic identification and traceback
- Access control with VLAN QoS policy and port access control lists
- Using private VLANs
- Port isolation
6
# Permit transit traffic
#
rule permit ip
#
Once created, the ACL must be applied to all interfaces that face non-infrastructure devices. This includes interfaces that
connect to other organizations, remote access segments, user segments, and data center segments.
ICMP packet filtering
Internet Control Message Protocol (ICMP) is designed as an IP control protocol. As a result, the messages it conveys can
have far-reaching ramifications to TCP and IP protocols in general. While the network troubleshooting tools ping and
traceroute use ICMP, external ICMP connectivity is rarely needed for the proper operation of a network.
HP Comware OS software provides functionality to specifically filter ICMP messages by name or type and code. The
following example ACL, which must be used with the access control entries (ACEs) from previous examples, allows pings
from trusted management stations and NMS servers, and blocks all other ICMP packets:
#
acl number 3000 name ACL-INFRASTRUCTURE-IN
#
# Permit ICMP Echo (ping) from trusted management stations and servers #
rule permit icmp source <trusted-management-stations> 0 icmp-type echo
rule permit icmp source <trusted-netmgmt-servers> 0 icmp-type echo
#
# Deny all other IP traffic to any network device #
rule deny ip destination <infrastructure-address-space> <wildcard>
#
# Permit transit traffic #
rule permit ip
#
Filtering IP fragments
Filtering fragmented IP packets can pose a challenge to security devices. This is because the Layer 4 information that is
used to filter TCP and UDP packets is only present in the initial fragment. HP Comware software uses a specific method
to check non-initial fragments against configured access lists. HP Comware software evaluates these non-initial
fragments against the ACL and ignores any Layer 4 filtering information. This causes non-initial fragments to be
evaluated solely on the Layer 3 portion of any configured ACE.
In the example configuration that follows, if a TCP packet destined to 192.168.1.1 on port 22 is fragmented in transit,
the initial fragment is dropped as expected by the second ACE based on the Layer 4 information within the packet.
However, all remaining (non-initial) fragments are allowed by the first ACE based completely on the Layer 3 information
in the packet and ACE. This scenario is shown in this configuration:
#
acl number 3000 name ACL-FRAGMENT-EXAMPLE
rule permit tcp destination 192.168.1.1 0 destination-port eq 80
rule deny tcp destination 192.168.1.1 0 destination-port eq 22
#
Due to the nonintuitive nature of fragment handling, IP fragments are often inadvertently permitted by infrastructure
ACLs. Fragmentation is also often used in attempts to evade detection by intrusion detection systems. It is for these
reasons that IP fragments are often used in attacks, and why they must be explicitly filtered at the top of any configured