HP Networking Guide To Hardening Comware-Based Devices
HP Networking Guide To Hardening Comware-Based Devices
HP Networking Guide To Hardening Comware-Based Devices
Table of contents
Introduction 2
Management plane 2
General management plane hardening 2
Limiting access to the network with
infrastructure ACLs 5
Securing interactive management
sessions 7
Fortifying Simple Network
Management Protocol 11
Logging best practices 13
HP Comware software configuration
management 15
Control plane 16
General control plane hardening 16
Limiting the CPU impact of control
plane traffic 18
Securing BGP 20
Securing Interior Gateway Protocols 22
Securing Virtual Router Redundancy
Protocol 24
Data plane 24
General data plane hardening 24
Filtering transit traffic with Transit
ACLs 25
Anti-spoofing protections 26
Limiting the CPU impact of data plane
traffic 30
Traffic identification and traceback 30
Access control with VLAN QoS policy
and port access control lists 34
Using private VLANs 35
Port isolation 37
Introduction
This document contains information to help you secure your HP Comware OS-based devices, which will help increase the
overall security of your network. This document, which is structured around the three planes into which network device
functions can be categorized, provides an overview of each feature and references related documentation.
The three functional planes of a networkthe management plane, control plane, and data planeeach provide
different functionality that must be protected.
Management plane
The management plane consists of functions that achieve the management goals of the network. It includes interactive
management sessions using secure shell (SSH), as well as statistics gathering with SNMP, NetStream, or sFlow. When
you consider the security of a network device, it is critical that the management plane be protected. If a security incident
is able to undermine the functions of the management plane, it can be impossible for you to recover or stabilize
your network.
The sections of this document detail the security features and configurations available in Comware-based HP software
that help fortify the management plane.
SNMP
Telnet
Secure shell (SSH)
FTP
TFTP
Secure FTP
HWTACACS
RADIUS
NetStream
sFlow
NTP
Syslog
Steps must be taken to help ensure the survival of the management and control planes during security incidents. If one
of these planes is successfully exploited, all network planes can be compromised.
Password control
Password control refers to a set of functions provided by the local authentication server to control user login passwords,
super passwords, and user login status based on predefined policies. If passwords are cracked by attackers, the whole
network is compromised.
Generally, an administrator sets a password for each network user. A password is displayed in either plain text or cipher
text. A plain-text password is visible to all users logged in through the console port. In addition, a user can log in to a
device and obtain its configuration file, from which the user can view user names and plain-text passwords. Cipher-text
passwords are therefore recommended, especially when password control is no enabled.
Cipher text prevents logged-in users from viewing passwords, but the passwords can still be cracked by some software.
If a user obtains the configuration file, the user can then easily use crack software to obtain the passwords.
2
After password control is configured, a password is displayed as ***, and is saved in a special format in the
configuration file.
Users will often choose their user names or simple digits such as 123456 as their passwords. These passwords can
easily be cracked. Increasing password complexity can make it more difficult to crack passwords.
With password control, the administrator can configure the minimum password length, password composition check,
password complexity check, password update interval, password aging, early notice on pending password expiration,
login with an expired password, password history, login attempt limit, password display, authentication timeout
management, maximum account idle time, and logging. (The system logs all successful password change events and
user blacklisting events due to login failures.)
The following gives a typical configuration example of password control:
# Enable password control globally.
[Sysname] password-control enable
# Prohibit a user from logging in forever after two consecutive login failures.
[Sysname] password-control login-attempt 2 exceed lock
# Specify that a user can log in five times within 60 days after the password expires.
[Sysname] password-control expired-user-login delay 60 times 5
# Refuse any password that contains the user name or the reverse of the user name.
[Sysname] password-control complexity user-name check
# Specify that no character of the password can be repeated three or more times consecutively.
[Sysname] password-control complexity same-character check
# Set the minimum number of composition types for super passwords to 3 and the minimum number of characters of
each composition type to 5.
[Sysname] password-control super composition type-number 3 type-length 5
# Set the minimum number of password composition types to 2 and the minimum number of characters of each
password composition type to 5 for the local user.
[Sysname-luser-test] password-control composition type-number 2 type-length 5
# Set the password age time to 20 days for the local user.
[Sysname-luser-test] password-control aging 20
3
# Configure the password of the local user in interactive mode.
[Sysname-luser-test] password
Password:***********
Confirm :***********
Updating user(s) information, please wait........
[Sysname-luser-test] quit
EXEC timeout
To set the interval so that the command interpreter waits for user input before it terminates a session, issue the
idle-timeout command in interface view. The idle-timeout command must be used to log out sessions on a virtual type
terminal (VTY) or true type terminal (TTY) interface that is left idle. By default, sessions are disconnected after 10
minutes of inactivity.
#
user-interface con 0
idle-timeout 2 0
user-interface aux 0
idle-timeout 2 0
user-interface vty 0 4
idle-timeout 2 0
#
4
exclusively for the management plane. This allows the administrator to apply policies throughout the network for the
management plane. Once the loopback interface is configured on a device, it can be used by management plane
protocols such as SSH, SNMP, and syslog to send and receive traffic.
#
# Permit required connections for routing protocols and network management
#
rule permit tcp source <trusted-ebgp-peer> 0 destination <local-ebgp-address> 0
destination-port eq 179
rule permit tcp source <trusted-ebgp-peer> 0 source-port eq 179 destination <local-ebgp
address> 0
rule permit tcp source <trusted-management-stations> 0 destination-port eq 22
rule permit udp source <trusted-netmgmt-servers> 0 destination-port eq 161
#
# Deny all other IP traffic to any network device
#
rule deny ip destination <infrastructure-address-space> <wildcard>
5
# 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.
#
# 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
6
infrastructure ACLs. The example ACL that follows includes comprehensive filtering of IP fragments. The functionality
from this example must be used in conjunction with the functionality of the previous examples.
#
acl number 3001 name ACL-INFRASTRUCTURE-IN
#
# Deny IP fragments using protocol-specific ACEs to aid in classification of attack traffic
#
rule deny tcp fragment
rule deny udp fragment
rule deny icmp fragment
rule deny ip fragment
#
# Deny all other IP traffic to any network device #
rule deny ip destination <infrastructure-address-space> <wildcard>
#
# Permit transit traffic #
rule permit ip
#
For more information regarding ACL handling of fragmented IP packets, see Filtering IP fragments.
#
To adopt username/password authentication, configure the following:
#
user-interface con 0
authentication-mode password
set authentication password cipher password
7
idle-timeout 1 0
user privilege level 3
#
To access the AUX port remotely, the user must first pass local password authentication by default. You can configure
AAA to authenticate users accessing the AUX port as follows:
#
user-interface aux 0
authentication-mode scheme
idle-timeout 1 0
user privilege level 3
#
You can disable authentication so that users can access the device through the AUX port directly as follows:
#
user-interface aux 0
authentication-mode none
user privilege level 3
idle-timeout 1 0
#
Note: Set a short time value with the idle-timeout command to ensure that users who no longer use the TTYs or VTYs
are logged out in time. The default time value is 10 minutes.
8
Warning banners
In some legal jurisdictions, it can be impossible to prosecute and illegal to monitor malicious users unless they have
been notified that they are not permitted to use the system. One method to provide this notification is to place this
information into a banner message that is configured with the HP Comware software header legal command.
Legal notification requirements are complex, vary by jurisdiction and situation, and should be discussed with legal
counsel. Even within jurisdictions, legal opinions can differ. In cooperation with counsel, a banner can provide some or all
of the necessary information.
The notice should indicate that the system is to be logged into or used only by specifically authorized personnel; it can
also contain information about who can authorize use:
Notice that any unauthorized use of the system is unlawful and can be subject to civil and criminal penalties.
Notice that any use of the system can be logged or monitored without further notice and that the resulting logs can be
used as evidence in court.
Specific notices required by local laws.
From a security point of view, rather than a legal one, a login banner should not contain any specific information
about the router name, model, software, or ownership. This information can be abused by malicious users.
Note: You can use the undo copyright-info enable command to disable displaying copyright information upon login.
9
Authentication, authorization, and accounting with HWTACACS
HWTACACS and RADIUS both provide authentication, authorization, and accounting services. They have many common
features in implementing AAA, such as using the client/server model, using shared keys for user information security,
and having good flexibility and extensibility. They also have differences, which are listed below.
HWTACACS RADIUS
Uses TCP, providing more reliable networking transmission. Uses UDP, providing higher transport efficiency.
Encrypts the entire packet except for the HWTACACS header. Encrypts only the user password field in an authentication packet.
Protocol packets are complicated, and authorization is Protocol packets are simple, and authorization is combined with
independent of authentication. Authentication and authentication.
authorization can be deployed on different HWTACACS
servers.
Supports authorization of configuration commands. Which Does not support authorization of configuration commands.
commands a user can use depends on both the user level Which commands a user can use depends on the users level. A
and AAA authorization. A user can use only commands that user can use all the commands of, or lower than, their user level.
are not only of, or lower than, their user level but also
authorized by the HWTACACS server.
10
Authentication fallback
If all authentication servers are unavailable, local authentication can be used.
Local authentication can use the password control function to secure user passwords.
#
Note that the preceding community string examples have been chosen to clearly explain the use of these strings.
For production environments, community strings should be chosen with caution and should consist of a series of
alphabetical, numerical, and nonalphanumeric symbols.
For more information about this feature, see SNMP in the Network Management and Monitoring Command
Reference Guide.
#
snmp-agent community read READONLY acl 2001
11
snmp-agent community write READWRITE acl 2002
#
For more information, see the snmp-server community command in SNMP in the Network Management and
Monitoring Command Reference Guide.
SNMP Views
SNMP Views are a security feature that can permit or deny access to certain SNMP MIBs. Once a view is created and
applied to a community string with the snmp-agent community command, if you access MIB data, you are restricted to
the permissions that are defined by the view. When appropriate, you are advised to use views to limit SNMP users to the
data that they require.
The configuration example that follows restricts SNMP access with the community string LIMITED to the MIB data that is
located in the system group:
#
snmp-agent mib-view included VIEW-SYSTEM-ONLY system
#
snmp-agent community read LIMITED mib-view VIEW-SYSTEM-ONLY
#
For more information, see SNMP in the Network Management and Monitoring Command Reference Guide.
SNMP Version 3
SNMP Version 3 (SNMPv3) is defined by RFC3410, RFC3411, RFC3412, RFC3413, RFC3414, and RFC3415, and is an
interoperable standards-based protocol for network management. SNMPv3 provides secure access to devices by
authenticating and optionally encrypting packets over the network. Where supported, SNMPv3 can be used to add
another layer of security when deploying SNMP. SNMPv3 consists of three primary configuration options:
no authentication
This mode does not require any authentication or any encryption of SNMP packets.
authentication
This mode requires authentication of the SNMP packet without encryption.
privacy
This mode requires both authentication and encryption (privacy) of each SNMP packet.
An authoritative engine ID must exist before the SNMPv3 security mechanisms authentication or authentication and
encryption can be used for handling SNMP packets. By default, the engine ID is generated locally. The engine ID can be
displayed with the display snmp-agent local-engineid command as shown in this example:
#
[HP]display snmp-agent local-engineid
SNMP local EngineID: 800063A203000FE2000002
#
Note that if the engine ID is changed, all SNMP user accounts must be reconfigured. The next step is to configure an
SNMPv3 group. This command configures an HP Comware device for SNMPv3 with an SNMP server group AUTHGROUP
and enables only authentication for this group by using the authentication keyword:
#
snmp-agent group v3 AUTHGROUP authentication
#
This command configures an HP Comware device for SNMPv3 with an SNMP server group PRIVGROUP and enables both
authentication and encryption for this group by using the privacy keyword:
#
snmp-agent group v3 PRIVGROUP privacy
12
#
This command configures an SNMPv3 user snmpv3user with an MD5 authentication password of authpassword and a
3DES encryption password of privpassword:
#
snmp-agent usm-user v3 snmpv3user PRIVGROUP authentication-mode md5 authpas
sword privacy-mode 3des privpassword
#
Additionally, it is recommended that SNMPv1/v2 be disabled whenever SNMPv3 is configured for an additional level of
security. For more information, see SNMP in the Network Management and Monitoring Command Reference Guide.
#
For more information on log correlation, see Information Center in the Network Management and Monitoring
Configuration Guide.
Logging level
Each log message that is generated by an HP Comware device is assigned one of eight severity levels that range from
level 0 (emergencies) through level 7 (debug). Unless specifically required, you are advised to avoid logging at level 7.
Logging at level 7 produces an elevated CPU load on the device that can lead to device and network instability.
The system-view configuration command info-center source default channel loghost log level is used to specify which
logging messages are sent to remote syslog servers. The level specified indicates the lowest severity message that is
sent. For buffered logging, the info-center source default channel logbuffer log level command is used.
This configuration example limits log messages that are sent to remote syslog servers and the local log buffer to
severities 6 (informational) through 0 (emergencies):
#
info-center source default channel logbuffer log level informational
info-center source default channel loghost log level informational
#
For more information, see Information Center in the Network Management and Monitoring Command Reference Guide.
13
Do not log to console or monitor sessions
With HP Comware software, it is possible to send log messages to monitor sessions and to the console. Monitor sessions
are interactive management sessions in which the EXEC command terminal monitor has been issued. However, sending
such messages can elevate the CPU load of a Comware device and therefore is not recommended.
Instead, you are advised to send logging information to the local log buffer, which can be viewed by using the display
logbuffer command.
Use the system-view configuration commands info-center source default channel console log state off and
info-center source default channel monitor log state off to disable logging to the console and monitor sessions. The
following configuration example shows the use of these commands:
#
info-center source default channel console log state off
info-center source default channel monitor log state off
#
server:
#
info-center loghost <ip-address>
#
For more information on log correlation, see Information Center in the Network Management and Monitoring
Configuration Guide.
#
For more information, see Information Center in the Network Management and Monitoring Command Reference Guide.
#
For more information, see Information Center in the Network Management and Monitoring Command Reference Guide.
14
Configure logging timestamps
Configuring logging timestamps helps you correlate events across network devices. It is important to implement a
correct and consistent logging timestamp configuration to ensure that you are able to correlate logging data. Logging
timestamps should be configured to include the date and time with millisecond precision and to include the time zone in
use on the device.
The following example includes the configuration of logging timestamps with the time from system boot:
#
info-center timestamp log boot
#
Use the info-center timestamp loghost command to configure the format of logging timestamps sent to the log host.
For more information, see Information Center in the Network Management and Monitoring Command Reference Guide.
#
Although the configuration archive functionality can store up to 10 backup configurations, you are advised to consider
the space requirements before using the maximum command.
For more information, see Configuration File Management in the Fundamentals Command Reference Guide.
#
For more information, see Configuration File Management and Device Management in the Fundamentals Command
Reference Guide.
15
Configuration change notification
The configuration change notification feature can log the configuration changes made to an HP Comware device. You can
display the change trap with the display trapbuffer command. Use the snmp-agent trap enable command to enable
configuration change notification.
#
[HP]display trapbuffer
Trapping buffer configuration and contents:enabled
Allowed max buffer size : 1024
Actual buffer size : 1024
Channel number : 3 , channel name : trapbuffer
Dropped messages : 0
Overwritten messages : 0
Current messages : 31
Control plane
Control plane functions consist of the protocols and processes that communicate between network devices to move
data from source to destination, including routing protocols such as the Border Gateway Protocol, as well as protocols
like ICMP and the Resource Reservation Protocol (RSVP).
It is important that events in the management and data planes do not adversely affect the control plane. If a data plane
event such as a DoS attack impacts the control plane, the entire network can become unstable. This information about
HP Comware software features and configurations can help ensure the resilience of the control plane.
IP ICMP redirects
An ICMP redirect message can be generated by a router when a packet is received and transmitted on the same
interface. In this situation, the router forwards the packet and sends an ICMP redirect message back to the sender of the
original packet. This behavior allows the sender to bypass the router and forward future packets directly to the
destination (or to a router closer to the destination). In a properly functioning IP network, a router sends redirects only
to hosts on its own local subnets. In other words, ICMP redirects should never go beyond a Layer 3 boundary.
16
There are two types of ICMP redirect messages: redirect for a host address and redirect for an entire subnet. A malicious
user can exploit the ability of the router to send ICMP redirects by continually sending packets to the router, forcing the
router to respond with ICMP redirect messages. This produces an adverse impact on the CPU and on the performance of
the router. In order to prevent the router from sending ICMP redirects, use the undo ip redirects command.
For more information on ICMP redirects, see IP Performance Optimization in the Layer-3 IP Services Command
Reference Guide.
ICMP unreachables
Generating ICMP unreachable messages can increase CPU load on the device. ICMP unreachable message generation can
be disabled using the undo ip unreachables command.
ICMP TTL-expiry
Generating ICMP timeout messages can increase CPU load on the device. ICMP TTL timeout message generation can be
disabled using the undo ip ttl-expires command.
Proxy ARP
Proxy ARP is the technique in which one device, usually a router, answers ARP requests that are intended for another
device. By "faking" its identity, the router accepts responsibility for routing packets to the real destination. Proxy ARP
can help machines on a subnet reach remote subnets without configuring routing or a default gateway. Proxy ARP is
defined in RFC 1027.
There are several disadvantages to utilizing proxy ARP. Doing so can result in an increase in the amount of ARP traffic on
the network segment, as well as resource exhaustion and man-in-the-middle attacks. Proxy ARP presents a resource
exhaustion attack vector because each proxied ARP request consumes a small amount of memory. An attacker can
exhaust all available memory by sending a large number of ARP requests.
Man-in-the-middle attacks enable a host on the network to spoof the MAC address of the router, resulting in
unsuspecting hosts sending traffic to the attacker. Proxy ARP can be disabled using the undo proxy-arp enable
command in interface view.
For more information on this feature, see ARP Configuration in the Layer-3 IP Services Command Reference Guide.
17
Limiting the CPU impact of control plane traffic
Protecting the control plane is critical. Because application performance and the end-user experience can suffer without
the presence of data and management traffic, the survivability of the control plane helps ensure that the other two
planes are maintainable and operational.
#
user-interface vty 0 4
acl [ ipv6 ] acl-number { inbound | outbound }
18
For more information about ACL, see ACL in the Security Command Reference Guide.
HTTPS ACLs
Use the ip https acl command to control HTTPS access with an ACL. Only the clients permitted by the ACL can access the
HTTPS server on the device.
#
Apply a QoS policy. For more information, see QoS in the ACL and QoS Configuration Guide.
qos apply policy policy-name { inbound | outbound }
SYN Cookie
Protection against Naptha attacks
In an SYN flood attack, the attacking host sends a large number of SYN messages to the server to establish TCP
connections, but it never makes any response. The server establishes a large number of incomplete TCP connections and
is unable to handle services normally.
The SYN Cookie feature can prevent SYN flood attacks. After receiving a TCP connection request, the server directly
returns a SYN ACK message, instead of establishing an incomplete TCP connection. Only after receiving an ACK message
from the client can the server establish a connection, and then enter the ESTABLISHED state.
Follow these steps to enable the SYN Cookie feature:
#
tcp syn-cookie enable
#
A Naptha attack uses the six TCP connection states (CLOSING, ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, LAST_ACK, and
SYN_RECEIVED), and while an SYN flood attack uses only the SYN_RECEIVED state.
The Naptha attacker controls a huge number of hosts to establish TCP connections with the server, keep these
connections in the same state (any of the six), and request for no data so as to exhaust the memory resources of the
server. As a result, the server cannot process normal services.
Follow these steps to enable the protection against Naptha attacks:
#
tcp anti-naptha enable
tcp state { closing | established | fin-wait-1 | fin-wait-2 | last-ack | syn-received }
connection-number number
19
#
For more information on these two features, see TCP and ICMP Attack Protection in the Security Configuration Guide.
Securing BGP
Border Gateway Protocol (BGP) is the routing foundation of the Internet. As such, any organization with more than
modest connectivity requirements often finds itself utilizing BGP. BGP is often targeted by attackers because of its
ubiquity and the set-and-forget nature of BGP configurations in smaller organizations. However, there are many BGP-
specific security features that can be leveraged to increase the security of a BGP configuration.
The following section provides an overview of the most important BGP security features. Where appropriate,
configuration recommendations are made.
#
When BGP packets are received, the TTL value is checked and must be greater than 255 minus the hop-count specified.
For more information, see Configuring GTSM for BGP in BGP in the Layer-3 IP Routing Configuration Guide.
#
For more information, see Enabling MD5 Authentication for TCP Connections in BGP in the Layer-3 IP Routing
Configuration Guide.
20
In order to prevent memory exhaustion, it is important to configure the maximum number of prefixes that is accepted on
a per-peer basis. It is recommended that a limit be configured for each BGP peer.
When configuring this feature using the peer route-limit command in BGP view, one argument is required: the maximum
number of prefixes that are accepted before a peer is shut down. Optionally, a number from 1 to 100 can also be
entered. This number represents the percentage of the maximum prefix value at which point a log message is sent.
#
bgp <asn>
peer <ip-address> as-number <remote-asn>
peer <ip-address> route-limit <shutdown-threshold> <log-percent>
#
For more information, see Limiting Prefixes Received from a Peer/Peer Group in BGP in the Layer-3 IP Routing
Configuration Guide.
#
bgp <asn>
peer <ip-address> ip-prefix BGP-PL-INBOUND import
peer <ip-address> ip-prefix BGP-PL-OUTBOUND export
#
For more information, see Configuring BGP Route Distribution/Reception Filtering Policies in BGP in the Layer-3 IP
Routing Configuration Guide.
#
bgp <asn>
peer <ip-address> as-number 65501
21
peer <ip-address> as-path-acl 1 import
peer <ip-address> as-path-acl 2 export
#
For more information, see Configuring RIPv2 Message Authentication in RIP in the Layer-3 IP Routing
Configuration Guide.
Following is an example configuration for OSPF router authentication using MD5:
#
interface <interface>
ospf authentication-mode md5 <key-id> <password>
#
ospf <process-id>
area 0
authentication-mode md5
#
For more information, see Configuring OSPF Authentication in OSPF in the Layer-3 IP Routing Configuration Guide.
Following is an example configuration for IS-IS router authentication using MD5:
#
interface <interface>
isis authentication-mode md5 <password>
#
isis <process-id>
22
area-authentication-mode md5 <password>
domain-authentication-mode md5 <password>
#
For more information, see Enhancing IS-IS Network Security in ISIS in the Layer-3 IP Routing Configuration Guide.
Silent-interface commands
Information leaks, or the introduction of false information into an IGP, can be mitigated through use of the
silent-interface command, which assists in controlling the advertisement of routing information. You are advised
not to advertise any information to networks that are outside your administrative control.
The following example demonstrates usage of this feature:
#
ospf <process-id>
silent-interface all
undo silent-interface <interface>
Route filtering
To reduce the possibility of introducing false routing information to the network, you must utilize route filtering. Unlike
the silent-interface command, routing occurs on interfaces once route filtering is enabled, but the information that is
advertised or processed is limited.
For RIP, using the filter-policy command with the export key word limits what information is advertised, while use of
the import key word limits what updates are processed. The filter-policy command is available for OSPF, but it does not
prevent a router from propagating filtered routes. Instead, the filter command can be used.
The following RIP example filters outbound advertisements with the filter-policy command and a prefix list:
#
ip ip-prefix <list-name> index 10 permit <ip-address> <mask-length>
#
rip <process-id>
silent-interface all
undo silent-interface <interface>
filter-policy ip-prefix <list-name> export <interface>
#
The following RIP example filters inbound updates with a prefix list:
#
ip ip-prefix <list-name> index 10 permit <ip-address> <mask-length>
#
rip <process-id>
silent-interface all
undo silent-interface <interface>
filter-policy ip-prefix <list-name> import <interface>
#
For more information, see Configuring Inbound/Outbound Route Filtering in RIP in the Layer-3 IP Routing
Configuration Guide.
The following OSPF example utilizes a prefix list with the OSPF-specific filter command:
#
23
ip ip-prefix <list-name> index 10 permit <ip-address> <mask-length>
#
ospf <process-id>
area <area-id>
filter ip-prefix <list-name> import
#
For more information on OSPF Area Border Router (ABR) Type 3 link-state advertisements filtering, see Configuring ABR
Type-3 LSA Filtering in OSPF in the Layer-3 IP Routing Configuration Guide.
#
For more information, see VRRP in the High Availability Configuration Guide.
Data plane
Although the data plane is responsible for moving data from source to destination, within the context of security, the
data plane is the least important of the three planes. It is for this reason that when you are securing a network device, it
is important to protect the management and control planes in preference over the data plane.
However, within the data plane itself, there are many features and configuration options that can help secure traffic.
The sections that follow detail these features and options so that you can more easily secure your network.
24
#
undo ip redirects
#
For more information on the undo ip redirects command, see IP Performance Optimization in the Layer-3 IP Services
Configuration Guide.
#
For more information about the ip forward-broadcast command, see IP Performance Optimization Configuration in
the Layer-3 IP Services Configuration Guide.
#
# Permit ICMP packets from trusted networks only
#
rule permit icmp source <trusted-networks>
#
# Deny all other ICMP traffic.
#
rule deny icmp
25
Filtering IP fragments
As detailed previously in the Limiting access to the network with infrastructure ACLs section of this document, the
filtering of fragmented IP packets can pose a challenge to security devices.
Because of the nonintuitive nature of fragment handling, IP fragments are often inadvertently permitted by 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 should be explicitly filtered at the top of any configured traffic ACLs. The
example ACL that follows includes comprehensive filtering of IP fragments. The functionality illustrated in this example
must be used in conjunction with the functionality of the previous examples:
#
acl number 3000 name ACL-TRANSIT-IN
#
# Deny IP fragments using protocol-specific ACEs to aid in classification of attack traffic.
#
rule deny tcp fragment
rule deny udp fragment
rule deny icmp fragment
rule deny ip fragment
Anti-spoofing protections
Many attacks utilize source IP address spoofing to be effective or to conceal the true source of an attack and hinder
accurate traceback. HP Comware provides Unicast Reverse Path Forwarding (URPF) and IP Source Guard (IPSG) to deter
attacks that rely on source IP address spoofing. In addition, ACLs and null routing are often deployed as a manual means
of spoofing prevention.
IP Source Guard is effective at reducing spoofing for networks that are under direct administrative control by performing
switch port, MAC address, and source address verification. URPF provides source network verification and can reduce
spoofed attacks from networks that are not under direct administrative control. Port security can be used in order
to validate MAC addresses at the access layer. ARP detection mitigates attack vectors that utilize ARP poisoning on
local segments.
URPF
URPF enables a device to verify that the source address of a forwarded packet can be reached through the interface that
received the packet. You must not rely on URPF as the only protection against spoofing. Spoofed packets could enter the
network through a URPF-enabled interface if an appropriate return route to the source IP address exists.
URPF can be configured in one of two modes: loose or strict. In cases where there is asymmetric routing, loose mode
configuration is preferred because strict mode is known to drop packets in these situations.
The following example illustrates configuration of this feature:
#
interface Ethernet0/1/0
ip urpf loose
#
URPF can be configured globally or on the interface, depending on the device model.
For more information about the configuration and use of URPF, see URPF in the Security Configuration Guide.
IP source guard
IP source guard is an effective means of spoofing prevention in Layer 2 access mode.
26
After receiving a packet, an IP source guard-enabled port obtains the key attributes (source IP address, source MAC
address, and VLAN tag) of the packet and then looks up the binding entries of the IP source guard for a match. If there is
a match, the port forwards the packet; otherwise, the port discards the packet. You can enable this feature on a port
connected to terminals to block illegal access (such as IP spoofing) and improve port security.
HP IP source guard supports static and dynamic entries. You can configure static entries in scenarios where there are
only a few hosts in a LAN and their IP addresses are manually configured. For example, you can configure a static entry
on a port that connects a server so that the port receives and sends packets from/to only the server.
Following is an example of static entry configuration:
#
# Configure Ethernet 1/2 on Device B to allow only packets from host A with MAC address 00010203-0406 and IP
address 192.168.1.1 to pass.
<DeviceB> system-view
[DeviceB] interface ethernet 1/2
[DeviceB-Ethernet1/2] user-bind ip-address 192.168.0.1 mac-address 0001-0203-0406
[DeviceB-Ethernet1/2] quit
#
Dynamic IP source guard entries are generated dynamically according to client entries on the DHCP snooping or DHCP
relay agent device. They are suitable for scenarios where many hosts are in a LAN and DHCP is used to allocate IP
addresses to the hosts. Once DHCP allocates an IP address to a client, IP source guard automatically adds the entry to
allow the client to access the network. A person using an IP address not obtained through DHCP cannot access the
network. Dynamic IPv6 source guard entries are obtained from client entries on the ND snooping device.
Following is a dynamic entry configuration example (DHCP snooping must have been enabled.)
#
# Enable dynamic entry generation on Ethernet 1/1.
[Device] interface ethernet 1/1
[Device-Ethernet1/1] ip check source ip-address mac-address
[Device-Ethernet1/1] quit
Port security
Port security is a MAC address-based network access control mechanism. It is an extension to IEEE 802.1X and MAC
authentication. It prevents access from unauthorized devices by checking the source MAC address of inbound traffic and
access to unauthorized devices by checking the destination MAC address of outbound traffic.
With port security enabled, frames whose source MAC addresses cannot be learned by the device in a security mode
are considered illegal. The events that users do not pass IEEE 802.1X authentication or MAC authentication are
considered illegal.
Upon detection of illegal frames or events, the device takes the predefined action automatically. While enhancing the
system security, this reduces your maintenance burden greatly. The illegal packets include:
27
The following table describes the port security modes.
The following configuration example enables MAC address learning on a port and sets the maximum number of MAC
addresses the port can learn to 10:
#
[HP]port-security enable
Please wait............................ Done.
[HP-Ethernet0/4/1]port-security max-mac-count 10
[HP-Ethernet0/4/1]port-security port-mode autolearn
[HP-Ethernet0/4/1]di th
#
interface Ethernet0/4/1
port link-mode bridge
port-security max-mac-count 10
port-security port-mode autolearn
28
ARP Detection
ARP Detection can be utilized to mitigate ARP poisoning attacks on local segments. An ARP poisoning attack is a method
in which an attacker sends falsified ARP information to a local segment. This information is designed to corrupt the ARP
cache of other devices. Often an attacker uses ARP poisoning in order to perform a man-in-the-middle attack.
ARP Detection intercepts and validates the IP-to-MAC address relationship of all ARP packets on untrusted ports.
In DHCP environments, ARP Detection utilizes the data that is generated by the DHCP snooping feature. In 802.1X
environments, ARP Detection can use the user data generated by the 802.1x feature. ARP packets that are received
on trusted interfaces are not validated and invalid packets on untrusted interfaces are discarded.
In non-DHCP or non-802.1X environments, the configuration of static client entries is required. Even if in DHCP
environments, there may be some users such as servers or printers that use manually configured IP addresses. In such
environments, static client entries are also the requisites when enabling ARP Detection.
The following command enables DHCP snooping:
#
dhcp-snooping
#
Once DHCP snooping has been enabled, the following commands enable ARP Detection:
#
vlan 1
arp detection enable
#
In non-DHCP or non-802.1x environments, static client entries on a port are required to enable ARP Detection. The
following example demonstrates the basic configuration of a static client entry:
#
interface Ethernet0/4/0
user-bind ip-address <X.X.X.X> mac-address <H-H-H> vlan <VLAN ID>
#
For more information on how to configure ARP Detection, see ARP Attack Protection in the Security Configuration
Guide.
Anti-spoofing ACLs
Manually configured ACLs can provide static anti-spoofing protection against attacks that utilize known unused and
untrusted address space. Commonly, these anti-spoofing ACLs are applied to ingress traffic at network boundaries as
a component of a larger ACL. Anti-spoofing ACLs require regular monitoring because they can frequently change.
Spoofing can be reduced in traffic originating from the local network by applying outbound ACLs that limit the traffic
to valid local addresses.
The following example demonstrates how ACLs can be used to limit IP spoofing. This ACL is applied in bound on the
desired interface:
#
acl number 3001 name ACL-ANTISPOOF-IN
rule deny ip source 10.0.0.0 0.255.255.255
rule deny ip source 192.168.0.0 0.0.255.255
#
# For Switch, port ACL command is packet-filter
interface <interface>
packet-filter name ACL-ANTISPOOF-IN inbound
29
firewall packet-filter name ACL-ANTISPOOF-IN inbound
NetStream
NetStream identifies anomalous and security-related network activity by tracking network flows. NetStream data can be
viewed and analyzed via the CLI, or the data can be exported to a NetStream collector and data analyzer for aggregation
and analysis. A NetStream data analyzer, through long-term trending, can provide network behavior and usage analysis.
NetStream, which can be configured on both routers and switches, functions by performing analysis on specific
attributes within IP packets and creating flows. Version 9 is the most flexible format and allows users to define
templates with different statistics fields.
The following example illustrates the basic configuration of this feature. NetStream can be enabled on an interface, or
through QoS policy or port mirroring. Different devices choose one of the approaches based on device model:
Approach I, enable NetStream on an interface.
#
interface Ethernet0/1/0
ip netstream { inbound | outbound }
30
Approach II, enable NetStream through QoS policy.
#
ip netstream { inbound | outbound }
#
traffic behavior <behavior-name>
mirror-to interface net-stream <interface-number>
#
Approach III, enable NetStream through port mirroring.
#
ip { inbound | outbound }
#
interface Ethernet0/1/0
ip netstream mirror-to interface net-stream <interface-numbr>
#
Following is an example of NetStream output from the CLI. The If(Direc) attribute can be beneficial in traceback:
#
<Sysname> display ip netstream cache
IP netstream cache information:
Stream active timeout (in minutes) : 60
Stream inactive timeout (in seconds) : 10
Stream max entry number : 1000
IP active stream entry number : 1
MPLS active stream entry number : 2
L2 active stream entry number : 1
IPL2 active stream entry number : 1
IP stream entries been counted : 10
MPLS stream entries been counted : 20
L2 stream entries been counted : 10
IPL2 stream entries been counted : 20
Last statistics reset time : 01/01/2000, 00:01:02
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 >4608
.000 .000 .027 .000 .027 .000 .000 .000 .000 .000 .000 .000
31
TCP-FTPD 3200453 1006 5 193 45 33
TCP-WWW 546778274 11170 887 12 8 32
TCP-other 49148540 3752 79 47 30 32
UDP-DNS 117240379 570 190 3 7 34
UDP-other 45502422 2272 73 30 8 37
ICMP 14837957 125 24 5 12 34
IP-other 77406 5 0 47 52 27
#
For more information on NetStream capabilities, see NetStream in the Network Management and Monitoring
Configuration Guide.
sFlow
sFlow is a traffic monitoring technology used to collect and analyze traffic statistics.
The sFlow system involves an sFlow agent and a remote sFlow collector. The sFlow agent collects traffic statistics and
packet information from sFlow-enabled interfaces, and encapsulates them into sFlow packets. When the sFlow packet
buffer is full, or the age time of sFlow packets is reached, the sFlow agent sends the packets to a specified sFlow
collector. The sFlow collector analyzes the sFlow packets and displays the results.
sFlow has the following two sampling mechanisms:
32
#
sflow collector < collector-id > ip < ip-address >
#
Specify an IP address for the sFlow agent, and the sFlow version.
#
sflow agent { ip ip-address | ipv6 ipv6-address }
sflow version { 4 | 5 }
#
Configure flow sampling:
#
interface Ethernet0/1/0
sflow sampling-mode { determine | random }
sflow sampling-rate < rate >
sflow flow max-header < length >
sflow flow collector < collector-id >
#
Configure counter sampling:
#
interface Ethernet0/1/1
sflow counter interval < seconds >
sflow counter collector < collector-id >
#
For more information about sFlow, see sFlow in the Network Management and Monitoring Configuration Guide.
Classification ACLs
Classification ACLs provide visibility into traffic that traverses an interface. Classification ACLs do not alter the security
policy of a network and are typically constructed to classify individual protocols, source addresses, or destinations. For
example, a match item that permits all traffic could be separated into specific protocols or ports. This more granular
classification of traffic into specific match items can help provide an understanding of the network traffic because each
traffic category has its own hit counter. An administrator may also separate the implicit deny at the end of an ACL into
granular match items to help identify the types of denied traffic.
An administrator can expedite an incident response by using classification ACLs with display acl and reset acl
counter commands.
The following example illustrates the configuration of a classification ACL to identify traffic:
#
acl number 3002 name ACL-SMB-CLASSIFY
description Classification of SMB specific TCP traffic
rule deny tcp destination-port eq 139
rule deny tcp destination-port eq 445
rule deny ip
#
Use the display acl command to view the configuration of ACL 3002. (The ACL counters can be cleared by using the reset
acl counter command.)
#
33
[HP] display acl 3002
Advanced ACL 3002, named ACL-SMB-CLASSIFY, 3 rules,
Classification of SMB specific TCP traffic
ACL's step is 5
rule 0 deny tcp destination-port eq 139 (10 times)
rule 5 deny tcp destination-port eq 445 (10 times)
rule 10 deny ip (205 times)
Access control with VLAN QoS policy and port access control lists
VLAN access control lists (VACLs), or VLAN QoS policy and port ACLs (PACLs), provide the capability to enforce access
control on non-routed traffic closer to endpoint devices than ACLs applied to routed interfaces.
The sections that follow provide an overview of the features, benefits, and potential usage scenarios of VACLs
and PACLs.
#
[HP]traffic behavior<name>
[HP-behavior-b1] <permit|deny>
[HP]traffic classifier <name>
[HP-classifier-b1] if-match <acl-name>
[HP]qos policy <name>
[HP-qospolicy-c1]classifier <name> behavior <name>
#
[HP]qos vlan-policy <policy-name> vlan 100 inbound
34
rule permit <protocol> <source-address> <source-port> <destination-address>
<destination-port>
#
interface <interface>
packet-filter name <acl-name> inbound
Isolated VLANs
The configuration of a secondary VLAN as an isolated VLAN completely prevents communication between devices in
the secondary VLAN. There may only be one isolated VLAN per primary VLAN, and only promiscuous ports may
communicate with ports in an isolated VLAN. Isolated VLANs should be used on untrusted networks such as networks
that support guests.
This configuration example configures VLAN 11 as an isolated VLAN and associates it to the primary VLAN, VLAN 20. The
following example also configures interface GigabitEthernet1/0/1 as an isolated port in VLAN 11:
#
vlan 11
isolated-vlan enable
#
vlan 20
isolate-user-vlan enable
#
interface GigabitEthernet1/0/1
description *** Port in Isolated VLAN ***
port isolate-user-vlan host
port access vlan 11
#
isolate-user-vlan 20 secondary 11
35
Community VLANs
A secondary VLAN that is configured as a community VLAN allows communication among members of the VLAN as well
as with any promiscuous ports in the primary VLAN. However, no communication is possible between any two
community VLANs or from a community VLAN to an isolated VLAN. Community VLANs must be used to group servers
that need connectivity with one another, but where connectivity to all other devices in the VLAN is not required. This
scenario is common in a publicly accessible network or anywhere that servers provide content to untrusted clients.
The following example configures a single community VLAN and configures switch port GigabitEthernet1/0/2 as a
member of that VLAN. The community VLAN, VLAN 12, is a secondary VLAN to primary VLAN 20.
Note: A secondary VLAN is considered a community VLAN by default.
#
vlan 12
#
vlan 20
isolate-user-vlan enable
#
interface GigabitEthernet1/0/2
description *** Port in Community VLAN ***
port isolate-user-vlan host
port access vlan 12
#
isolate-user-vlan 20 secondary 12
Promiscuous ports
Switch ports that are placed into the primary VLAN are known as promiscuous ports. Promiscuous ports can
communicate with all other ports in the primary and secondary VLANs. Router or firewall interfaces are the most
common devices found on these VLANs.
The following configuration example combines the previous isolated and community VLAN examples and adds the
configuration of interface GigabitEthernet1/0/12 as a promiscuous port:
#
vlan 11
isolated-vlan enable
#
vlan 12
#
vlan 20
isolate-user-vlan enable
#
interface GigabitEthernet1/0/1
description *** Port in Isolated VLAN ***
port isolate-user-vlan host
port access vlan 11
#
interface GigabitEthernet1/0/2
description *** Port in Community VLAN ***
port isolate-user-vlan host
36
port access vlan 12
#
interface GigabitEthernet1/0/12
port link-mode bridge
description *** Promiscuous Port ***
port isolate-user-vlan promiscuous
port link-type hybrid
port hybrid vlan 11 to 12 20 tagged
#
isolate-user-vlan 20 secondary 11 12
#
When implementing PVLANs, it is important to ensure that the Layer 3 configuration in place supports the restrictions
that are imposed by PVLANs and does not allow the PVLAN configuration to be subverted.
Layer 3 filtering using a router ACL or firewall can prevent the subversion of the PVLAN configuration.
Port isolation
Port isolation is another Layer 2 security feature that limits connectivity between workstation or servers within a VLAN.
Without port isolation, all devices on a Layer 2 VLAN can communicate freely.
Networking situations exist where security can be aided by limiting communication between devices on a single VLAN.
For example, port isolation is often used to prohibit communication between servers in a publicly accessible subnet.
Should a single server become compromised, the lack of connectivity to other servers due to the application of port
isolation may help limit the compromise to the one server.
Port isolation includes isolated ports, uplink port, and isolation groups. HP Comware supports creating multiple isolation
groups, each of which can contain multiple isolated ports and one uplink port.
Layer 2 traffic is isolated among member ports in an isolation group.
Note: Not all product models support uplink and isolation group functions.
Isolated ports
The configuration of some ports in a VLAN as isolated ports completely prevents communication between devices
in the VLAN. Isolated ports should be used on untrusted networks that only access the Internet without needing to
communicate with each other.
The following configuration example configures all the ports of VLAN 20 as isolated ports. Interface
GigabitEthernet1/0/10 and GigabitEthernet1/0/11 are in VLAN 20:
#
interface GigabitEthernet1/0/10
description *** Isolated Port ***
port access vlan 20
port-isolate enable
#
interface GigabitEthernet1/0/11
description *** Isolated Port ***
port access vlan 20
port-isolate enable
#
37
Uplink port
The uplink port of an isolation group can communicate with isolated ports in the group so that the isolated ports can
access other networks through the uplink port without needing Layer 3 forwarding. If your device does not support an
uplink port feature, the isolated ports in a Layer 2 VLAN need Layer 3 forwarding to access other networks. The
following configuration example configures G1/0/10 and G1/0/11 in VLAN 20 as isolated ports, and configures
Ten-GigabitEthernet1/0/49 as the uplink port.
#
interface GigabitEthernet1/0/10
description *** Isolated Port ***
port access vlan 20
port-isolate enable
#
interface GigabitEthernet1/0/11
description *** Isolated Port ***
port access vlan 20
port-isolate enable
#
interface Ten-GigabitEthernet1/0/49
description *** Uplink Port ***
port access vlan 20
port-isolate uplink-port
#
Isolation groups
This configuration example configures G1/0/10 and G1/0/11 in VLAN 20 as isolated ports in isolation group 1, and
configures Ten-GigabitEthernet1/0/49 as the uplink port of isolation group 1; configures G1/0/20 and G1/0/21 in
VLAN 20 as isolated ports in isolation group 2; and configures TenGigabitEthernet1/0/50 as the uplink port of isolation
group 2.
#
interface GigabitEthernet1/0/10
description *** Isolated Port of Group1 ***
port access vlan 20
port-isolate enable group 1
#
interface GigabitEthernet1/0/11
description *** Isolated Port of Group1 ***
port access vlan 20
port-isolate enable group 1
#
#
interface GigabitEthernet1/0/20
description *** Isolated Port of Group2 ***
port access vlan 20
port-isolate enable group 2
#
interface GigabitEthernet1/0/21
38
description *** Isolated Port of Group2 ***
port access vlan 20
port-isolate enable group 2
#
interface Ten-GigabitEthernet1/0/49
description *** Uplink Port of Group1 ***
port access vlan 20
port-isolate uplink-port group 1
#
interface Ten-GigabitEthernet1/0/50
description *** Uplink Port of Group2 ***
port access vlan 20
port-isolate uplink-port group 2
#
For more information about port isolation, see Port Isolation in the Layer-2 LAN Switching Configuration Guide.
39
Keywords: secure, management plane, control plane, data plane
Abstract: This document describes how to secure HP Comware devices.
Acronyms:
Get connected
hp.com/go/getconnected
Current HP driver, support, and security alerts
delivered directly to your desktop
Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only
warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein
should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.