Login
- Released At: 09-07-2019
- Page Views:
- Downloads:
- Table of Contents
- Related Documents
-
|
|
|
Hardening Comware 7 H3C Security Devices |
|
|
|
|
|
|
Copyright © 2019 New H3C Technologies Co., Ltd. All rights reserved.
No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of New H3C Technologies Co., Ltd.
Except for the trademarks of New H3C Technologies Co., Ltd., any trademarks that may be mentioned in this document are the property of their respective owners.
The information in this document is subject to change without notice.
Contents
Threats to the management and control planes
Hardening the management plane
User management and access control
Using RBAC to control user access permissions
Using AAA to secure user access and user management
Using command authorization to secure command access
Password control and management
Disabling password recovery capability·
Disabling BootWare menu access
Configuring memory alarm thresholds
Securing spanning tree networks
Enabling dynamic ARP entry check
Preventing ARP spoofing attacks
DHCP relay entry management on the DHCP relay agent
DHCP proxy on the DHCP relay agent
ADVPN VAM protocol packet security
Authentication and encryption algorithms
Authenticating high availability protocol packets
Securing VRRP packet authentication
BFD control packet authentication
Configuring the NTP access right
Configuring storm suppression and storm control
MAC address security management
Configuring blackhole MAC address entries·
Disabling MAC address learning
Controlling and monitoring MAC address learning
Assigning MAC learning priority to interfaces
Configuring GRE security mechanisms·
Configuring IPsec to secure ADVPN packets·
Packet filtering & Traffic filtering
DoS attack detection and defense
About this document
This document helps you improve the overall network security by hardening the Comware 7 security devices.
Audience
This document is intended for:
· Network planners.
· Field technical support and servicing engineers.
· Network administrators.
Port numbering in examples
The port numbers in this document are for illustration only and might be unavailable on your device.
Prerequisites
This document is not restricted to specific software or hardware versions.
The configuration examples were created and verified in a lab environment, and all the devices were started with the factory default configuration. When you are working on a live network, make sure you understand the potential impact of every command on your network.
This document provides only generic technical information, some of which might not apply to your devices.
|
|
NOTE: All settings in the examples throughout this document are for illustration only. When you use the commands in the examples to harden your device, change the settings as appropriate to your network security requirements. |
Overview
The functions of Comware 7 security devices are categorized into the management plane, control plane, and data plane. This document helps you improve the overall network security by hardening the security of these three planes.
Security threats
Threats to the management and control planes
The management plane manages administrative access to the device through applications and protocols such as Telnet, SSH, Web, and SNMP. Protecting the management plane against unauthorized access and attacks is essential to the security of the entire network.
The control plane contains applications and protocols that are running between devices to maintain the functionality of the network architecture and facilitate the functions of the data plane. For example, routers run routing protocols such as OSPF or BGP between them to learn about routes and switches run protocols such as spanning tree protocols to learn about various paths.
Security threats to the management and control planes of a network device come from various sources, including malicious users, compromised remote network devices, and an inappropriate security policy.
The following are common security threats to the management and control planes:
· Unauthorized access.
An attacker can gain access to the device by forging the identity of the administrator or launching management session replay attacks or man-in-the-middle attacks.
To protect administrative sessions to the device, configure strong identity authentication, establish secure access channels, and perform anti-replay and message integrity check. In addition, enable operations and security event logging to record and audit administrative behavior of users.
· Weak password.
A weak password is easy to crack. As a best practice, configure a password policy to require strong passwords for administrative access.
· Sensitive information leaking
Important or confidential information might be eavesdropped on the transmission path. Stored contents might be leaked when the storage device is transferred or replaced.
To guarantee the confidentiality of sensitive information:
¡ Avoid establishing insecure administrative sessions to the device by using protocols such as Telnet, FTP, TFTP, or HTTP. Instead, establish secure administrative sessions by using protocols such as SSH, IPsec, SFTP, and HTTPS.
¡ Encrypt the startup configuration file.
¡ Format the removed storage devices before you dispose of them, making sure the removed data cannot be restored.
· Message tampering and forging.
An attacker might tamper with or replay messages on the transmission path to inject malicious data or tamper with data on a network device. For example, attackers can tamper with routing protocol packets to influent the path of packets.
To protect the control plane, configure security services including integrity check and anti-replay.
· Distributed denial of service (DDoS) attacks.
In a DDoS attack, the attacker sends a large number of packets to exhaust the device resources, including CPU, memory, sessions, and bandwidth. Busy with handling illegitimate packets, the victim network device will be unable to provide forwarding services to users.
To protect a network device against DDoS attacks:
¡ Use a whitelist to identify trusted remote devices.
¡ Use a blacklist to block traffic from suspicious remote devices.
¡ Limit the rate at which traffic is sent to the control plane.
· Misconfiguration.
Misconfiguration might result in incorrect access control, permission assignment, or authorization.
To avoid security risks introduced because of misconfiguration:
¡ Verify the configuration before deploying it.
¡ Constantly audit the device behavior after the configuration is deployed, for example, by reviewing the operation log or system log.
Threats to the data plane
The data plane forwards data from source to destination. If the data plane was attacked, the forwarding performance would downgrade significantly and in the worst case, malicious packets would spread in the network.
Common security threats to the data plane include:
· Malformed packet attacks.
Attackers can exploit the packet processing vulnerabilities in the data plane to attack the device, causing the device to malfunction or crash.
To detect and prevent potential malformed packet attacks, enable attack detection and prevention.
· DDoS attacks.
DDoS attack occurs when an attacker sends a large number of packets to exhaust the device resources, including CPU, memory, connections, and bandwidth.
To protect the device against such attacks, configure resource usage thresholds to ensure that the device always has resources for normal services. In addition, authenticate users, identify illegitimate traffic, and limit the traffic of unrecognizable users.
· Identity spoofing.
Identity spoofing is part of many attacks. Identifying spoofed identities can effectively prevent attacks. However, the openness of the network makes this job very difficult, especially on the data plane.
To identify spoofed identifies on the data plane, you can use security features such as SYN Cookie, ARP attack protection, and ND attack defense.
· Message tampering and forging.
Message integrity is critical to network functionality. False data might cause network failure or even network paralysis.
As a best practice, use security protocols such as IPsec to protect data flows in the network. Securing mechanisms include integrity check, confidentiality offset, and identity authentication.
Security architecture
Figure 1 shows the security architecture of Comware 7.
Figure 1 Comware 7 security architecture
This security architecture offers multilayer protection to ensure overall security.
If a device offers hardware forwarding, its hardware layer uses whitelist and priority queuing mechanisms to protect the control and management planes from DoS or DDoS attacks. These mechanisms handle packets destined for the local device as follows before delivering them from the hardware layer to the CPU:
¡ Whitelist—If a source is trustworthy and a session has been established to it, the source is added to the whitelist. The hardware layer preferentially delivers all its packets to the CPU.
¡ Priority queues—If a packet is not from a source in the whitelist, the hardware layer enqueues the packet in a priority queue depending on its protocol. Packets in any priority queues have lower priority than packets from a whitelist source.
· On the forwarding plane, Comware 7 provides a variety of security features, including:
¡ Malformed packet detection.
¡ Security policies.
¡ Anti-spoofing, for example uRPF.
¡ DDoS attack defense.
¡ Resource usage limits, including connection limit and ARP/ND table entry limit.
¡ Data protection protocols, such as IPsec.
· On the control and management planes, Comware 7 provides security features including:
¡ Application security features to prevent attacks such as TCP attacks, ICMP/ICMPv6 attacks, ARP attacks, and ND attacks.
¡ Security protocols or options specific to service modules for enhanced service protection.
Basic hardening principles
Enforcing security features aligned with your network environment, security needs, and protected objects is critical to the effective protection of your network. Hardening a network device with as many security features as you have would increase costs, add configuration complexities, and impact device performance without making it more secure.
To effectively protect a network device:
1. Identify major threats and risks that the network device is facing and sort them by their impact on your business.
2. Select and phase in security features to protect the network device against the identified threats and risks by their significance.
3. Constantly evaluate the protection effect after a security feature or a set of security features is introduced.
4. Depending on the evaluation conclusion, change or phase in security features until the security risks to the business are mitigate to an acceptable or minimum level.
Hardening the management plane
Device access control
Securing console access
Security threats
Hardening recommendations
Configure one of the following authentication modes in user line view or line class view immediately after you log in to the device for the first time:
· Password authentication—Requires a password for authentication. A user must provide the correct password at login.
· Scheme authentication—Uses the AAA module to provide local or remote login authentication. A user must provide the correct username and password at login.
After configuring password or scheme authentication, keep the password or username and password securely.
Restrictions and guidelines
A console login configuration change takes effect only on users who log in after the change is made. It does not affect users who are already online when the change is made.
Examples
# Configure password authentication in console line view.
<Sysname> system-view
[Sysname] line console 0
[Sysname-line-console0] authentication-mode password
# Specify a password.
[Sysname-line-console0] set authentication password simple Plat&0631!
Alternatively:
# Configure scheme authentication in console line view.
<Sysname> system-view
[Sysname] line console 0
[Sysname-line-console0] authentication-mode scheme
[Sysname-line-console0] quit
# Configure authentication methods for login users in ISP domain view.
To use local authentication, configure a local user and set the relevant attributes. To use remote authentication, configure a RADIUS, HWTACACS, or LDAP scheme. For more information, see AAA in Security Configuration Guide.
Securing Stelnet access
Security threats
Stelnet users might face the following security threats:
· An attacker might scan for and obtain the SSH service port number, and then try to Stelnet to the device again and again to log in to the device.
· The device supports a limited number of concurrent SSH users. An attacker might use spoofed IP addresses and valid usernames and passwords to Stelnet to the device, making legal users unable to Stelnet to the device.
Hardening recommendations
To protect the device against the security threats, you can use the following security policies:
· Password authentication
The SSH server authenticates a client by using the AAA mechanism. The password authentication process is as follows:
a. The client sends the server an authentication request that includes the encrypted username and password.
b. The server decrypts the request, verifies the username and password locally or through remote AAA authentication, and informs the client of the authentication result.
· Publickey authentication
The SSH server authenticates a client by verifying the digital signature of the client. The publickey authentication process is as follows:
c. The client sends the server a publickey authentication request that includes the username, public key, and public key algorithm name.
If the digital certificate of the client is required in authentication, the client also encapsulates the digital certificate in the authentication request. The digital certificate carries the public key information of the client.
d. The server verifies the client's public key.
- If the public key is invalid, the server informs the client of the authentication failure.
- If the public key is valid, the server requests the digital signature of the client. After receiving the signature, the server uses the public key to verify the signature and informs the client of the authentication result.
· Password-publickey authentication
The SSH server requires SSH2 clients to pass both password authentication and publickey authentication. An SSH1 client only needs to pass either authentication.
· Disabling the Stelnet service
Disable the Stelnet service when it is not required. The SSH service port number is easy to be found by a scanning attacker.
· Changing the SSH service port number to a non-well-known port number
By default, the SSH service port number is well-known port number 22, which is an easy target. Changing the SSH service port number reduces the risk to be attacked.
· Configuring SSH access control
Apply an ACL to control access to the SSH server, so only IPv4 SSH clients permitted by the ACL can access the SSH server.
· Limiting the number of concurrent SSH users
If the maximum number of concurrent SSH users is reached, the SSH server rejects additional connection requests.
Restrictions and guidelines
A Stelnet login configuration change takes effect only on users who log in after the change is made. It does not affect users who are already online when the change is made.
Examples
· # Configure password authentication for an SSH user.
<Sysname> system-view
[Sysname] ssh user client001 service-type stelnet authentication-type password
# For local authentication, configure a local user on the SSH server. For remote authentication, configure an SSH user on a remote authentication server, for example, a RADIUS server. For more information, see AAA in Security Configuration Guide.
· # Configure publickey authentication for an SSH user.
<Sysname> system-view
[Sysname] ssh user client002 service-type stelnet authentication-type publickey assign publickey clientkey
# Create a local user that uses the same username and assign a working directory and user roles to the user. For more information, see AAA in Security Configuration Guide.
· # Disable the Stelnet service.
<Sysname> system-view
[Sysname] undo ssh server enable
· # Change the SSH service port number to a non-well-known port number.
<Sysname> system-view
[Sysname] ssh server port 1025
· # Apply an ACL to permit only SSH access from 1.1.1.1.
<Sysname> system-view
[Sysname] acl basic 2001
[Sysname-acl-ipv4-basic-2001] rule permit source 1.1.1.1 0
[Sysname-acl-ipv4-basic-2001] quit
[Sysname] ssh server acl 2001
· # Set the maximum number of concurrent SSH users.
<Sysname> system-view
[Sysname] aaa session-limit ssh 16
Securing RESTful access
Hardening recommendations
As a best practice, use RESTful access over HTTPs, which is more secure than RESTful access over HTTP.
Examples
# Enable the RESTful access over HTTPS service.
<Sysname> system-view
[Sysname] restful https enable
Securing SNMP access
Security threats
The device might face the following threats when it acts as an SNMP agent:
· An attacker might steal SNMPv1 or SNMPv2c community names and use them to access the device.
· An attacker might eavesdrop on and tamper with SNMP packets.
· Legal users of NMSs might perform tasks mistakenly, causing the device unable to operate correctly.
Hardening recommendations
To protect the device against the security threats, you can use the following security policies:
· Disabling the SNMP agent when it is not required. By default, the SNMP agent is disabled.
· Using SNMPv3, which is more secure than SNMPv1 and SNMPv2c. SNMPv3 uses a user-based security model to secure SNMP communication. You can configure authentication and privacy mechanisms to authenticate and encrypt SNMP packets for integrity, authenticity, and confidentiality.
· Using the following modes to control access to MIB objects:
¡ View-based Access Control Model—VACM mode controls access to MIB objects by assigning MIB views to SNMP communities or users.
¡ Role based access control—RBAC mode controls access to MIB objects by assigning user roles to SNMP communities or users.
RBAC mode controls access on a per MIB object basis, and VACM mode controls access on a MIB view basis. As a best practice to enhance MIB security, use the RBAC mode.
· Applying an ACL to permit only legal NMSs to access the SNMP agent.
· Encapsulating security parameters in notifications to allow only NMSs that satisfy the requirements can receive the notifications.
Restrictions and guidelines
For an NMS to connect to the device, make sure they use the same SNMP version and community name (or username and password).
Examples
· Disable the SNMP agent:
# Disable the SNMP agent.
<Sysname> system-view
[Sysname] undo snmp-agent
· Enable SNMPv3 on the device and use a user role to control access to MIB nodes:
# Enable SNMPv3.
<Sysname> system-view
[Sysname] snmp-agent sys-info version v3
# Configure a user role that has only the following rights:
¡ Read right to objects of node snmpMIB (OID=1.3.6.1.6.3.1) and node system (OID=1.3.6.1.2.1.1).
¡ Read and write rights to objects of node interfaces (OID=1.3.6.1.2.1.2). These rights enable the device to report interface status changes to the NMS.
[Sysname] role name test
[Sysname-role-test] rule 1 permit read oid 1.3.6.1.6.3.1
[Sysname-role-test] rule 2 permit read oid 1.3.6.1.2.1.1
[Sysname-role-test] rule 3 permit read write oid 1.3.6.1.2.1.2
[Sysname-role-test] quit
# Create an SNMPv3 user, assign the configured user role to the user, and specify the authentication and encryption algorithms and passwords.
[Sysname] snmp-agent usm-user v3 RBACtest user-role test simple authentication-mode sha 123456TESTauth&! privacy-mode aes128 123456TESTencr&!
· Apply an ACL to control access to the SNMP agent.
# Create an SNMPv3 group, add a user to the group, and specify the authentication and encryption algorithms and passwords. Configure an ACL to permit only SNMPv3 access from 1.1.1.1.
<Sysname> system-view
[Sysname] acl basic 2000
[Sysname-acl-ipv4-basic-2000] rule permit source 1.1.1.1 0
[Sysname-acl-ipv4-basic-2000] rule deny source any
[Sysname-acl-ipv4-basic-2000] quit
[Sysname] snmp-agent group v3 testGroup authentication
[Sysname] snmp-agent usm-user v3 testUser testGroup simple authentication-mode sha 123456TESTauth&! privacy-mode aes128 123456TESTencr&! acl 2000
· Enable SNMP notifications.
# Enable SNMP notifications, specify the SNMP notification target host and username, and select the authentication with privacy security model.
<Sysname> system-view
[Sysname] snmp-agent trap enable
[Sysname] snmp-agent target-host trap address udp-domain 1.1.1.2 params securityname testUser v3 privacy
Securing Web access
Hardening recommendations
As a best practice, use HTTPs for Web access, which is more secure than HTTP. HTTPS uses SSL to ensure the integrity and security of data exchanged between the client and the server.
By default, the device uses a self-signed certificate and the default SSL settings. To secure Web access, you can configure an SSL server policy for HTTPS.
You can also define a certificate-based access control policy to allow only legal clients to access the Web interface.
Examples
# Configure an SSL server policy. (Details not shown. For more information, see SSL configuration in Security Configuration Guide.)
# Configure a certificate-based access control policy and add rules. (Details not shown. For more information, see PKI configuration in Security Configuration Guide.)
# Apply the SSL server policy to the HTTPS service.
<Sysname> system-view
[Sysname] ip https ssl-server-policy myssl
# Apply the certificate-based access control policy to the HTTPS service so only HTTPS clients that have obtained a certificate from the CA server can use the HTTPS service.
[Sysname] ip https certificate access-control-policy myacp
# Enable the HTTPS service.
[Sysname] ip https enable
# Configure authentication methods for login users in ISP domain view.
To use local authentication, configure a local user and set the relevant attributes. To use remote authentication, configure a RADIUS, HWTACACS, or LDAP scheme. For more information, see AAA in Security Configuration Guide.
Securing file access
Security threats
Commonly used file transfer protocols FTP and TFTP transfer files in plain text. Attackers can capture the transferred packets easily.
Hardening recommendations
To protect the device against the security threat, use Secure FTP (SFTP). Based on SSH2, SFTP uses SSH connections to provide secure file transfer. The device can act as an SFTP server, allowing a remote user to log in to the SFTP server for secure file management and transfer. The device can also act as an SFTP client, enabling a user to log in from the device to a remote device for secure file transfer.
To secure file transfer, SFTP uses the following security policies:
· Password authentication
The SSH server authenticates a client by using the AAA mechanism. The password authentication process is as follows:
a. The client sends the server an authentication request that includes the encrypted username and password.
b. The server decrypts the request, verifies the username and password locally or through remote AAA authentication, and informs the client of the authentication result.
· Publickey authentication
The SSH server authenticates a client by verifying the digital signature of the client. The publickey authentication process is as follows:
c. The client sends the server a publickey authentication request that includes the username, public key, and public key algorithm name.
If the digital certificate of the client is required in authentication, the client also encapsulates the digital certificate in the authentication request. The digital certificate carries the public key information of the client.
d. The server verifies the client's public key.
- If the public key is invalid, the server informs the client of the authentication failure.
- If the public key is valid, the server requests the digital signature of the client. After receiving the signature, the server uses the public key to verify the signature and informs the client of the authentication result.
· Password-publickey authentication
The SSH server requires SSH2 clients to pass both password authentication and publickey authentication. An SSH1 client only needs to pass either authentication.
· Changing the SSH service port number to a non-well-known port number
By default, the SSH service port number is well-known port number 22, which is an easy target. Changing the SSH service port number reduces the risk to be attacked.
· Configuring SSH access control
Apply an ACL to control access to the SSH server, so only IPv4 SSH clients permitted by the ACL can access the SSH server.
· Limiting the number of concurrent SSH users
If the maximum number of concurrent SSH users is reached, the SSH server rejects additional connection requests.
Examples
· # Enable the SFTP server, and configure an SSH user that uses password authentication.
<Sysname> system-view
[Sysname] sftp server enable
[Sysname] ssh user client001 service-type sftp authentication-type password
# For local authentication, configure a local user on the SSH server. For remote authentication, configure an SSH user on a remote authentication server, for example, a RADIUS server. For more information, see AAA in Security Configuration Guide.
· # Enable the SFTP server, and configure an SSH user that uses publickey authentication.
<Sysname> system-view
[Sysname] sftp server enable
[Sysname] ssh user client002 service-type sftp authentication-type publickey assign publickey clientkey
# Create a local user that uses the same username and assign a working directory and user roles to the user. For more information, see AAA in Security Configuration Guide.
· # Change the SSH service port number to a non-well-known port number.
<Sysname> system-view
[Sysname] ssh server port 1025
· # Apply an ACL to permit only SSH access from 1.1.1.1.
<Sysname> system-view
[Sysname] acl basic 2001
[Sysname-acl-ipv4-basic-2001] rule permit source 1.1.1.1 0
[Sysname-acl-ipv4-basic-2001] quit
[Sysname] ssh server acl 2001
· # Set the maximum number of concurrent SSH users.
<Sysname> system-view
[Sysname] aaa session-limit ssh 16
User management and access control
Using RBAC to control user access permissions
Role-based access control (RBAC) controls access permissions of users based on user roles, enabling granular control of access to the device.
With RBAC, you create user roles for different job functions (for example, different security purposes). Then, assign each user role the permission to access a set of features and system resources.
For more information about RBAC, see Fundamentals Configuration Guide.
Using AAA to secure user access and user management
Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing network access management. This feature specifies the following security functions:
· Authentication—Identifies users and verifies their validity.
· Authorization—Grants different users different rights, and controls the users' access to resources and services. For example, you can permit office users to read and print files and prevent guests from accessing files on the device.
· Accounting—Records network usage details of users, including the service type, start time, and traffic. This function enables time-based and traffic-based charging and user behavior auditing.
AAA has various implementations, including RADIUS, HWTACACS, and LDAP. RADIUS is most often used.
HWTACACS and RADIUS have many features in common, such as using a client/server model, using shared keys for data encryption, and providing flexibility and scalability. However, HWTACACS has the following advantages compared with RADIUS:
· Uses TCP, which provides reliable network transmission.
· Encrypts the entire packet except for the HWTACACS header.
· Uses complicated protocol packets and separates authorization from authentication. Authentication and authorization can be deployed on different HWTACACS servers.
· Supports authorization of configuration commands. Access to commands depends on both the user's roles and authorization. A user can use only commands that are permitted by the user roles and authorized by the HWTACACS server.
Using command authorization to secure command access
Hardening recommendations
By default, commands available for a user depend only on the user's user roles. When the authentication mode is scheme, you can configure the command authorization feature to further control a user's access to commands.
When command authorization is enabled, a user can use only commands that are permitted by both the AAA scheme and user roles.
Examples
# Enable command authorization.
<Sysname> system-view
[Sysname] line vty 0 4
[Sysname-line-vty0-4] authentication-mode scheme
[Sysname-line-vty0-4] command authorization
# Configure command authorization methods in ISP domain view. The command authorization methods can be the same as or different from the user login authorization methods. For more information about the authorization methods, see AAA configuration in Security Configuration Guide.
Password control
Security threats
A user password on the device might pose security threats in the following situations:
· If the password is short and simple, and the number of login attempts is not limited, the password might be easily cracked through a dictionary attack.
· If the password has no aging time and is idle for a long period, it can be cracked through continuous attempts.
· If the password is the initial password, it will be cracked easily. Because an initial password might be a weak password created by a single rule.
Hardening recommendations
Password control allows you to implement the following features:
· Password length, composition, and complexity.
¡ Minimum password length.
¡ Password composition policy.
¡ Password complexity checking policy.
· Password updating and expiration.
¡ Password updating.
¡ Password expiration.
¡ Early notice on pending password expiration.
¡ Login with an expired password.
¡ Password history.
· User login control.
¡ First login control.
¡ Limit on number of login attempts
¡ Maximum account idle time.
For more information about local users, see AAA in Security Configuration Guide. For information about super passwords, see RBAC in Fundamentals Configuration Guide. For more information about password control, see Security Configuration Guide.
Password control and management
The device supports the following forms of passwords (or keys):
· Plaintext form—Users enter their passwords in plaintext form, and the device stores the passwords in encrypted form or hashed form.
· Encrypted form—Users enter their passwords in encrypted form, and the device stores the passwords in encrypted form.
· Hashed form—Users enter their passwords in encrypted form, and the device stores the passwords in hashed form.
To improve system security and maintainability, follow these password control and management guidelines:
· Use long and complicated passwords instead of weak passwords.
· Use a unique password for each service, preventing one service password compromise from incurring security risks to all services.
· Make sure passwords set in encrypted or hashed form can be decrypted by the device. Typically, passwords in encrypted or hashed form are used for tests or configuration recovery. Do not use passwords in these forms for normal services.
Device management
Disabling password recovery capability
Security threats
By default, password recovery capability is enabled. If you forget the console login password or fails console login authentication, you can press Ctrl+B during device startup to access the BootWare menu and solve the issue. However, attackers can exploit this capability to access the device through the console port.
Hardening recommendations
Disable password recovery capability so console users must restore the factory-default configuration before they can configure new passwords. Restoring the factory-default configuration deletes the next-startup configuration files.
Examples
# Disable password recovery capability.
<Sysname> system-view
[Sysname] undo password-recovery enable
Disabling BootWare menu access
Security threats
By default, a console user can press Ctrl+B during device startup to access the BootWare menu. From the BootWare menu, a user can manage the device, for example, loading software and managing storage media.
Hardening recommendations
To prevent unauthorized access to the BootWare menu, disable BootWare menu access. After you disable BootWare menu access, pressing Ctrl+B opens the CLI but not the BootWare menu.
Examples
# Disable BootWare menu access.
<Sysname> undo bootrom-access enable
Disabling USB interfaces
Security threats
By default, all USB interfaces are enabled. A user can use USB interfaces to upload or download files. Important files might be illegally copied and USB disks might carry viruses.
Hardening recommendations
Enable USB interfaces only when necessary, and disable USB interfaces immediately after you finish using USB interfaces.
Restrictions and guidelines
If a USB disk is partitioned, you must use the umount command to unmount all USB partitions before you can disable USB interfaces.
Examples
# Disable USB interfaces.
<Sysname> system-view
[Sysname] usb disable
Configuring memory alarm thresholds
Security threats
When the device is running out of memory, features might not be able to install table entries or save important data, affecting correct system operation.
Hardening recommendations
To ensure correct operation and improve memory efficiency, the device monitors the amount of free memory space in real time. If the amount of free memory space reaches the minor, severe, or critical alarm threshold, the system issues an alarm to affected service modules and processes.
As shown in Table 1 and Figure 2, the device supports the following free-memory thresholds:
· Normal state threshold.
· Minor alarm threshold.
· Severe alarm threshold.
· Critical alarm threshold.
Table 1 Memory alarm notifications and memory alarm-removed notifications
|
Notification |
Triggering condition |
Remarks |
|
Minor alarm notification |
The amount of free memory space decreases below the minor alarm threshold. |
After generating and sending a minor alarm notification, the system does not generate and send any additional minor alarm notifications until the minor alarm is removed. |
|
Severe alarm notification |
The amount of free memory space decreases below the severe alarm threshold. |
After generating and sending a severe alarm notification, the system does not generate and send any additional severe alarm notifications until the severe alarm is removed. |
|
Critical alarm notification |
The amount of free memory space decreases below the critical alarm threshold. |
After generating and sending a critical alarm notification, the system does not generate and send any additional critical alarm notifications until the critical alarm is removed. |
|
Critical alarm-removed notification |
The amount of free memory space increases above the severe alarm threshold. |
N/A |
|
Severe alarm-removed notification |
The amount of free memory space increases above the minor alarm threshold. |
N/A |
|
Minor alarm-removed notification |
The amount of free memory space increases above the normal state threshold. |
N/A |
Figure 2 Memory alarm notifications and alarm-removed notifications
Restrictions and guidelines
If a memory alarm occurs, delete unused configuration items or disable some features to increase the free memory space. Because the memory space is insufficient, some configuration items might not be able to be deleted.
Examples
# Set the minor, severe, and critical free-memory alarm thresholds to 3000 MB, 2000 MB, and 1000 MB, respectively. Set the normal state threshold to 3500 MB.
<Sysname> system-view
[Sysname] memory-threshold minor 3000 severe 2000 critical 1000 normal 3500
Configuration encryption
Hardening recommendations
To protect the startup configuration file, use configuration encryption. This feature enables the device to encrypt a startup configuration file automatically when it saves the running configuration to the file. All devices running Comware 7 software use the same private key or public key to encrypt configuration files.
Any devices running Comware 7 software can decrypt the encrypted configuration files. To prevent an encrypted file from being decoded by unauthorized users, make sure the file is accessible only to authorized users.
Restrictions and guidelines
You cannot use the more command or any display commands other than the display saved-configuration command to view the contents of an encrypted configuration file.
Examples
# Enable the public-key method for configuration encryption.
<Sysname> system-view
[Sysname] configuration encrypt public-key
# Enable the private-key method for configuration encryption.
<Sysname> system-view
[Sysname] configuration encrypt private-key
Security logs
Hardening recommendations
Security logs are very important for locating and troubleshooting network problems. Generally, security logs are output together with other logs. It is difficult to identify security logs among all logs.
To resolve this issue, you can configure the device to save security logs to the security log file. After you configure this feature, the system encapsulates security-related information as both standard system logs and security logs. The standard system logs are sent to console, monitor terminal, log buffer, log host, or other destinations as configured. The security logs are sent only to the security log file.
Restrictions and guidelines
To save security logs to the security log file, configure the following features:
· Enable saving security logs to the security file.
· Set the interval at which security logs are sent to the security log file.
· Set the maximum size of the security log file.
· Set an alarm threshold for the security log file usage ratio.
To manage the security log file, you must have the security-audit user role. This user role has permissions only to security log file management operations, including the following:
· Change the directory of the security log file.
· Manually save the security logs in the security log file buffer to the security log file.
Examples
· Save security logs to the security log file:
# Enable saving security logs to the security log file.
<Sysname> system-view
[Sysname] info-center security-logfile enable
# Set the security log file saving interval to 600 seconds.
[Sysname] info-center security-logfile frequency 600
# Set the maximum size to 2 MB for the security log file.
[Sysname] info-center security-logfile size-quota 2
· Manage the security log file:
# Log in to the device with the security-audit user role.
# Set the security log file directory to flash:/test.
<Sysname> mkdir test
Creating directory flash:/test... Done.
<Sysname> system-view
[Sysname] info-center security-logfile directory flash:/test
[Sysname] quit
# Manually save the security logs in the security log file buffer to the security log file.
<Sysname> security-logfile save
The contents in the security log file buffer have been saved to the file flash:/seclog/seclog.log.
Hardening the control plane
Securing spanning tree networks
Security threats
· BPDU attack
Access ports can directly connect to user terminals (such as PCs) or file servers. The access ports are configured as edge ports to allow rapid transition. When these ports receive configuration BPDUs, the system automatically sets the ports as non-edge ports and starts a new spanning tree calculation process. This causes a change of network topology. Under normal conditions, these ports should not receive configuration BPDUs. However, if a malicious user uses configuration BPDUs to attack the devices, the network will become unstable.
· Root bridge attack
Due to possible configuration errors or malicious attacks in the network, the legal root bridge might receive a configuration BPDU with a higher priority. Another device supersedes the current legal root bridge, which causes an undesired change of the network topology. The traffic that should go over high-speed links is switched to low-speed links, resulting in network congestion.
· TC-BPDU attack
If an attacker uses TC-BPDUs to attack the device, the device will receive a large number of TC-BPDUs within a short time. Then, the device is busy with forwarding address entry flushing. This affects network stability.
Hardening recommendations
To secure spanning tree networks, you can use the following features:
· BPDU guard
The BPDU guard feature protects the system against BPDU attacks. When edge ports receive configuration BPDUs on a device with BPDU guard enabled, the device performs the following operations:
¡ Shuts down these ports.
¡ Notifies the NMS that these ports have been shut down by the spanning tree protocol.
· Root guard
The root guard feature keeps the designated role of a port on the root bridge to prevent frequent root bridge changes.
· TC-BPDU guard
TC-BPDU guard allows you to set the maximum number of immediate forwarding address entry flushes performed within 10 seconds after the device receives the first TC-BPDU. For TC-BPDUs received in excess of the limit, the device performs a forwarding address entry flush when the time period expires. This prevents frequent flushing of forwarding address entries.
Examples
· Configure BPDU guard.
# Enable BPDU guard globally.
<Sysname> system-view
[Sysname] stp bpdu-protection
· Enable root guard on an interface.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] stp root-protection
· Set the maximum number of forwarding address entry flushes that the device can perform every 10 seconds.
<Sysname> system-view
[Sysname] stp tc-protection threshold 10
ARP attack protection
Enabling dynamic ARP entry check
Security threats
The sender MAC address of valid ARP packets is a unicast address. An attacker can forge ARP packets in which the sender MAC addresses are multicast addresses. If the gateway learns ARP entries for the multicast addresses and then forwards packets based on the ARP entries, the network resources will be heavily occupied.
Hardening recommendations
To avoid such a threat, enable the dynamic ARP entry check feature.
This feature prevents the device from learning dynamic ARP entries for multicast MAC addresses. Additionally, you cannot manually add static ARP entries for multicast MAC addresses.
Examples
# Enable dynamic ARP entry check.
<Sysname> system-view
[Sysname] arp check enable
Preventing ARP flooding
Configuring unresolvable IP attack protection
Security threats
If a device receives a large number of unresolvable IP packets from a host, the following threats occur:
· The device sends a large number of ARP requests, overloading the target subnets.
· The device keeps trying to resolve the destination IP addresses, overloading its CPU.
Hardening recommendations
To protect the device from such IP attacks, you can configure the ARP source suppression feature. This feature stops resolving packets from an IP address if the number of unresolvable IP packets from the IP address exceeds the upper limit within 5 seconds. The device continues ARP resolution when the interval elapses. This feature is applicable if the attack packets have the same source addresses.
Examples
# Enable the ARP source suppression, and set the maximum number to 100 for unresolvable packets that can be processed per source IP address within 5 seconds.
<Sysname> system-view
[Sysname] arp source-suppression enable
[Sysname] arp source-suppression limit 100
Configuring source MAC-based ARP attack detection
Security threats
If the device receives a large number of ARP packets from the same MAC address, resource exhaustion will occur and the device will fail to learn new ARP entries.
Hardening recommendations
To avoid such a threat, enable the source MAC-based ARP attack detection feature.
This feature enables the device to count the number of ARP packets delivered to the CPU. If the number of packets from the same MAC address within 5 seconds exceeds a threshold, the device generates an ARP attack entry for the MAC address. If the ARP logging feature is enabled, the device handles the attack by using either of the following methods before the ARP attack entry ages out:
· Monitor—Only generates log messages.
· Filter—Generates log messages and filters out subsequent ARP packets from the MAC address.
Restrictions and guidelines
When you change the handling method from monitor to filter, the configuration takes effect immediately. When you change the handling method from filter to monitor, the device continues filtering packets that match existing attack entries.
You can exclude the MAC addresses of the gateways and servers from this detection. The device does not inspect ARP packets from those excluded devices even if they send a large number of ARP packets.
Examples
# Enable source MAC-based ARP attack detection, and specify the handling method as filter.
<Sysname> system-view
[Sysname] arp source-mac filter
To enable source MAC-based ARP attack detection and specify the monitor handling method, use the arp source-mac monitor command.
# Set the threshold for source MAC-based ARP attack detection to 30.
[Sysname] arp source-mac threshold 30
# Set the aging timer for ARP attack entries to 60 seconds.
[Sysname] arp source-mac aging-time 60
# Exclude MAC address 001e-1200-0213 from source MAC-based ARP attack detection.
[Sysname] arp source-mac exclude-mac 001e-1200-0213
# Enable logging for source MAC-based ARP attack detection.
[Sysname] arp source-mac log enable
Preventing ARP spoofing attacks
Security threats
An attacker may launch user spoofing attack or gateway spoofing attack.
· User spoofing attack—If an attacker sends a falsified ARP packet that deceives the gateway into adding a false IP-to-MAC address binding for a valid client, the client fails to receive packets from the gateway.
· Gateway spoofing attack—If an attacker sends a falsified ARP packet that deceives valid clients into adding a false IP-to-MAC binding for the gateway, the clients fail to access the gateway.
Enabling IP conflict notification
Hardening recommendations
Use the IP conflict notification feature to prevent gateway spoofing attacks.
This feature enables the device to detect and record user IP address conflicts. A conflict occurs if an incoming non-gratuitous ARP packet has the same sender IP address as an existing ARP entry but a different sender MAC address. The device generates a user IP address conflict record, logs the conflict, and sends the log to the information center.
Examples
# Enable IP conflict notification.
<Sysname> system-view
[Sysname] arp ip-conflict log prompt
Enabling ARP packet source MAC consistency check
Hardening recommendations
The ARP packet source MAC consistency check feature filters out ARP packets whose source MAC address in the Ethernet header is different from the sender MAC address in the message body. This feature ensures that the device learns correct ARP entries.
Examples
# Enable ARP packet source MAC consistency check.
<Sysname> system-view
[Sysname] arp valid-check enable
Configuring ARP active acknowledgment
Hardening recommendations
Use the ARP active acknowledgment feature to prevent user spoofing attacks.
This feature enables the device to perform validity checks before creating an ARP entry to prevent the device from generating incorrect ARP entries.
The strict mode enables the device to perform more strict validity checks as follows:
· Upon receiving an ARP request destined for the device, the device sends an ARP reply but does not create an ARP entry.
· Upon receiving an ARP reply, the device determines whether it has resolved the sender IP address:
¡ If yes, the device performs active acknowledgment. When the ARP reply is verified as valid, the gateway creates an ARP entry.
¡ If no, the device discards the packet.
Examples
# Enable strict ARP active acknowledgment in mode.
<Sysname> system-view
[Sysname] arp active-ack strict enable
Configuring authorized ARP
Hardening recommendations
Use the authorized ARP feature to prevent user spoofing attacks and to allow only authorized clients to access network resources.
This feature enables the device to generate authorized ARP entries based on the DHCP clients' address leases on the DHCP server or dynamic client entries on the DHCP relay agent. For more information about DHCP server and DHCP relay agent, see Layer 3—IP Services Configuration Guide.
Examples
# Enable authorized ARP on GigabitEthernet 1/0/1.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] arp authorized enable
Configuring ARP attack detection
Hardening recommendations
· User validity check—This feature enables the device to perform user validity check on ARP untrusted interface. Upon receiving an ARP request, the device compares the sender IP and sender MAC in the ARP packet with the matching criteria in the following items:
¡ User validity check rules.
¡ DHCP snooping entries.
If a match is found, the device forwards the ARP packet. If no match is found, the device discards the ARP packet.
· ARP packet validity check—This feature enables the device to perform ARP packet validity check on ARP untrusted interface. You can configure the device to check the following items in ARP packets:
¡ Sender MAC address—Checks whether the sender MAC address in the message body is identical to the source MAC address in the Ethernet header. If they are identical, the packet is forwarded. Otherwise, the packet is discarded.
¡ Target MAC address—Checks the target MAC address of ARP replies. If the target MAC address is all-zero, all-one, or inconsistent with the destination MAC address in the Ethernet header, the packet is considered invalid and discarded.
¡ Sender and target IP addresses—Checks the sender and target IP addresses of ARP replies, and the sender IP address of ARP requests. All-one or multicast IP addresses are considered invalid and the corresponding packets are discarded.
· ARP restricted forwarding—This feature controls the forwarding of ARP packets that are received on untrusted interfaces and have passed user validity check as follows:
¡ If the packets are ARP requests, they are forwarded through the trusted interface.
¡ If the packets are ARP replies, they are forwarded according to their destination MAC address. If no match is found in the MAC address table, they are forwarded through the trusted interface.
These features does not affect ARP trusted interfaces.
Examples
· # Configure a user validity check rule numbered 0. This rule is used to guide the device to forward only ARP packets of which the source IP address is 10.1.1.1 with subnet mask 255.255.0.0 and the source MAC address is 0001-0203-0405 with subnet mask ffff-ffff-0000.
<Sysname> system-view
[Sysname] arp detection rule 0 permit ip 10.1.1.1 255.255.0.0 mac 0001-0203-0405 ffff-ffff-0000
# Enable ARP attack detection in VLAN 10.
[Sysname] vlan 10
[Sysname-vlan10] arp detection enable
[Sysname-vlan10] quit
# Configure GigabitEthernet 1/0/1 as an ARP trusted interface.
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] arp detection trust
· # Enable ARP packet validity check by checking the target MAC addresses and IP addresses of ARP packets.
<Sysname> system-view
[Sysname] arp detection validate dst-mac ip src-mac
# Enable ARP attack detection in VLAN 10.
[Sysname] vlan 10
[Sysname-vlan10] arp detection enable
[Sysname-vlan10] quit
# Configure GigabitEthernet 1/0/1 as an ARP trusted interface.
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] arp detection trust
· # Enable ARP restricted forwarding in VLAN 2.
<Sysname> system-view
[Sysname] vlan 2
[Sysname-vlan2] arp restricted-forwarding enable
Configuring ARP scanning and fixed ARP
Hardening recommendations
ARP scanning is typically used together with the fixed ARP feature in small-scale and stable networks.
ARP scanning automatically creates ARP entries for devices in an address range. The device performs ARP scanning in the following steps:
1. Sends ARP requests for each IP address in the address range.
2. Obtains their MAC addresses through received ARP replies.
3. Creates dynamic ARP entries.
Fixed ARP converts existing dynamic ARP entries (including those generated through ARP scanning) to static ARP entries. These static ARP entries are of the same attributes as the ARP entries that are manually configured. This feature prevents ARP entries from being modified by attackers.
Restrictions and guidelines
You can set the ARP packet sending rate if the scanning range has a large number of IP addresses. This setting can avoid high CPU usage and heavy network load caused by a burst of ARP traffic.
Due to the limit on the total number of static ARP entries, some dynamic ARP entries might fail the conversion.
Examples
# Start an ARP scanning on GigabitEthernet 1/0/1.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] arp scan
[Sysname-GigabitEthernet1/0/1] quit
# Convert existing dynamic ARP entries to static ARP entries.
[Sysname] arp fixup
Configuring ARP gateway protection
Hardening recommendations
To prevent gateway spoofing attacks, configure the ARP gateway protection feature on interfaces that are not connected with a gateway.
When an interface enabled with this feature receives an ARP packet, it checks whether the sender IP address in the packet is consistent with that of any protected gateway. If yes, it discards the packet. If not, it handles the packet correctly.
Restrictions and guidelines
Do not configure both ARP gateway protection and ARP filtering on an interface.
Examples
# Enable ARP gateway protection for the gateway at 1.1.1.1 on GigabitEthernet 1/0/1.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] arp filter source 1.1.1.1
Configuring ARP filtering
Hardening recommendations
To prevent gateway spoofing and user spoofing attacks, enable the ARP filtering feature.
An interface enabled with this feature checks the sender IP and MAC addresses in a received ARP packet against permitted entries. If a match is found, the packet is handled correctly. If not, the packet is discarded.
Restrictions and guidelines
Do not configure both ARP gateway protection and ARP filtering on an interface.
Examples
# Enable ARP filtering and configure an ARP permitted entry on GigabitEthernet 1/0/1.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] arp filter binding 1.1.1.1 0e10-0213-1023
ND attack defense
Security threats
When an attacker sends a large number of ND packets to the target device, the CPU of the device will get overloaded.
Hardening recommendations
To prevent ND attack packets with inconsistent source MAC address and the source link-layer address, use the source MAC consistency check feature. The feature is typically configured on gateways.
This feature checks the source MAC address and the source link-layer address for consistency for each arriving ND message.
· If the source MAC address and the source link-layer address are not the same, the device drops the packet.
· If the addresses are the same, the device continues learning ND entries.
The ND logging feature logs source MAC inconsistency events, and it sends the log messages to the information center. The information center can then output log messages from different source modules to different destinations. For more information about the information center, see Network Management and Monitoring Configuration Guide.
Examples
# Enable source MAC consistency check for ND messages.
<Sysname> system-view
[Sysname] ipv6 nd mac-check enable
# Enable ND logging.
[Sysname] ipv6 nd check log enable
Access services
Securing PPP
Configuring PPP authentication
Hardening recommendations
To secure PPP, you can configure PPP authentication. By cooperating with AAA, PPP supports the following authentication methods:
· PAP—PAP is a two-way handshake authentication protocol using the username and password.
PAP sends username/password pairs in plain text over the network. If authentication packets are intercepted in transit, network security might be threatened. For this reason, it is suitable only for low-security environments.
· CHAP—CHAP is a three-way handshake authentication protocol.
CHAP transmits usernames but not passwords over the network. It transmits the result calculated from the password and random packet ID by using the MD5 algorithm. It is more secure than PAP. The authenticator may or may not be configured with a username. As a best practice, configure a username for the authenticator, which makes it easier for the peer to verify the identity of the authenticator.
· MS-CHAP—MS-CHAP is a three-way handshake authentication protocol.
MS-CHAP differs from CHAP in that MS-CHAP provides authentication retry. If the peer fails authentication, it is allowed to retransmit authentication information to the authenticator for reauthentication. The authenticator allows a peer to retransmit a maximum of three times.
· MS-CHAP-V2—MS-CHAP-V2 is a three-way handshake authentication protocol.
MS-CHAP-V2 differs from CHAP as follows:
¡ MS-CHAP-V2 provides two-way authentication by piggybacking a peer challenge on the Response packet and an authenticator response on the Acknowledge packet.
¡ MS-CHAP-V2 supports authentication retry. If the peer fails authentication, it is allowed to retransmit authentication information to the authenticator for reauthentication. The authenticator allows a peer to retransmit a maximum of three times.
¡ MS-CHAP-V2 supports password change. If the peer fails authentication because of an expired password, it will send the new password entered by the user to the authenticator for reauthentication.
Restrictions and guidelines
For local AAA authentication, the username and password of the peer must be configured on the authenticator. For remote AAA authentication, the username and password of the peer must be configured on the remote AAA server.
· PAP
The username and password configured for the peer must be the same as those configured on the peer by using the ppp pap local-user command.
· CHAP authentication (authenticator name is configured)
When you configure the authenticator, the username and password configured for the peer must meet the following requirements:
¡ The username configured for the peer must be the same as that configured on the peer by using the ppp chap user command.
¡ The passwords configured for the authenticator and peer must be the same.
When you configure the peer, the username and password configured for the authenticator must meet the following requirements:
¡ The username configured for the authenticator must be the same as that configured on the authenticator by using the ppp chap user command.
¡ The passwords configured for the authenticator and peer must be the same.
The peer does not support the CHAP authentication password configured by using the ppp chap password command. CHAP authentication (authenticator name is configured) will apply even if the authentication name is configured.
· CHAP authentication (authenticator name is not configured)
The username and password configured for the peer must meet the following requirements:
¡ The username configured for the peer must be the same as that configured on the peer by using the ppp chap user command.
¡ The password configured for the peer must be the same as that configured on the peer by using the ppp chap password command.
· MS-CHAP or MS-CHAP-V2 authentication
The device can only act as an authenticator for MS-CHAP or MS-CHAP-V2 authentication.
L2TP supports only MS-CHAP authentication.
MS-CHAP-V2 authentication supports password change only when using RADIUS.
As a best practice, do not set the authentication method for PPP users to none when MS-CHAP-V2 authentication is used.
The username and password of the peer configured on the authenticator or remote AAA server must be the same as those configured on the peer.
If authentication name is configured, the username configured for the authenticator on the peer must be the same as that configured on the authenticator by using the ppp chap user command.
Examples
· PAP authentication
¡ Configuring the authenticator
# Configure the authenticator to authenticate the peer by using PAP.
<Sysname> system-view
[Sysname] interface virtual-template 1
[Sysname-Virtual-Template1] ppp authentication-mode pap domain system
# Configure local or remote AAA authentication.
For more information about AAA authentication, see Security Configuration Guide.
¡ Configuring the peer
# Configure the PAP username and password sent from the peer to the authenticator when the peer is authenticated by the authenticator by using PAP.
<Sysname> system-view
[Sysname] interface virtual-template 1
[Sysname-Virtual-Template1] ppp pap local-user userb password simple passb&289
· Configuring CHAP authentication (authenticator name is configured)
¡ Configuring the authenticator
# Configure the authenticator to authenticate the peer by using CHAP.
<Sysname> system-view
[Sysname] interface virtual-template 1
[Sysname-Virtual-Template1] ppp authentication-mode chap domain system
# Configure a username for the CHAP authenticator.
[Sysname-Virtual-Template1] ppp chap user usera
# Configure local or remote AAA authentication.
For more information about AAA authentication, see Security Configuration Guide.
¡ Configuring the peer
# Configure a username for the CHAP peer.
<Sysname> system-view
[Sysname] interface virtual-template 1
[Sysname-Virtual-Template1] ppp chap user userb
# Configure local or remote AAA authentication.
For more information about AAA authentication, see Security Configuration Guide.
· Configuring CHAP authentication (authenticator name is not configured)
¡ Configuring the authenticator
# Configure the authenticator to authenticate the peer by using CHAP.
<Sysname> system-view
[Sysname] interface virtual-template 1
[Sysname-Virtual-Template1] ppp authentication-mode chap domain system
# Configure local or remote AAA authentication.
For more information about AAA authentication, see Security Configuration Guide.
¡ Configuring the peer
# Configure a username for the CHAP peer.
<Sysname> system-view
[Sysname] interface virtual-template 1
[Sysname Virtual-Template1] ppp chap user userb
# Set the CHAP authentication password.
[Sysname-Virtual-Template1] ppp chap password simple hello&358
· Configuring MS-CHAP or MS-CHAP-V2 authentication (authenticator name is configured)
¡ Configuring the peer
# Configure the authenticator to authenticate the peer by using MS-CHAP or MS-CHAP-V2.
<Sysname> system-view
[Sysname] interface virtual-template 1
MS-CHAP:
[Sysname-Virtual-Template1] ppp authentication-mode ms-chap domain system
MS-CHAP-V2:
[Sysname-Virtual-Template1] ppp authentication-mode ms-chap-v2 domain system
# Configure a username for the MS-CHAP or MS-CHAP-V2 authenticator.
[Sysname-Virtual-Template1] ppp chap user usera
# Configure local or remote AAA authentication.
For more information about AAA authentication, see Security Configuration Guide.
· Configuring MS-CHAP or MS-CHAP-V2 authentication (authenticator name is not configured)
¡ Configuring the peer
# Configure the authenticator to authenticate the peer by using MS-CHAP or MS-CHAP-V2.
<Sysname> system-view
[Sysname] interface virtual-template 1
MS-CHAP:
[Sysname-Virtual-Template1] ppp authentication-mode ms-chap domain system
MS-CHAP-V2:
[Sysname-Virtual-Template1] ppp authentication-mode ms-chap-v2 domain system
# Configure local or remote AAA authentication.
For more information about AAA authentication, see Security Configuration Guide.
Enhancing management and control for PPP users
Security threats
A user might user illegal IP addresses to access network resources in a PPP network.
Hardening recommendations
To avoid the security threats above, you can configure the IP segment match feature on the device to enhance management and control for PPP users. This feature enables the local interface to check whether its IP address and the IP address of the remote interface are in the same network segment. If they are not, IPCP negotiation fails.
Examples
# Enable the IP segment match feature on Virtual-Template 1.
<Sysname> system-view
[Sysname] interface virtual-template 1
[Sysname-Virtual-Template1] ppp ipcp remote-address match
Securing L2TP
Configuring L2TP user authentication
Hardening recommendations
To secure L2TP, configure L2TP user authentication. By cooperating with AAA, L2TP provides the following security authentication methods for users:
· AAA authentication on an LAC
You can configure AAA authentication an LAC to authenticate the remote dialup users and initiate a tunneling request only for qualified users. A tunnel will not be established for unqualified users.
For local AAA authentication, create a local user and configure a password for each remote user on the LAC. For remote AAA authentication, configure the remote username and password of each user.
· AAA authentication on an LNS
After you configure AAA authentication on an LNS, the LNS can authenticate the usernames and passwords of remote access users. If a user passes AAA authentication, the user can communicate with the LNS to access the private network.
For local AAA authentication, create a local user and configure a password for each remote user on the LAC. For remote AAA authentication, configure the remote username and password of each user.
An LNS can be configured to authenticate a user that has passed authentication on the LAC to increase security. In this case, the user is authenticated once on the LAC and once on the LNS. An L2TP tunnel can be established only when both authentications succeed.
An LNS provides the following authentication methods in ascending order of priority:
¡ Proxy authentication—The LNS uses the LAC as an authentication proxy. The LAC sends the LNS all user authentication information from users and the authentication method configured on the LAC itself. The LNS then checks the user validity according to the received information and the locally configured authentication method.
¡ Mandatory CHAP authentication—The LNS uses CHAP authentication to reauthenticate users who have passed authentication on the LAC.
¡ LCP renegotiation—The LNS ignores the LAC proxy authentication information and performs a new round of LCP negotiation with the user.
Restrictions and guidelines
When you configure AAA authentication on the LNS, follow these restrictions and guidelines:
· The mandatory CHAP authentication and LCP renegotiation methods are effective only on NAS-initiated L2TP tunnels.
· If you configure both LCP renegotiation and mandatory CHAP authentication, the LNS uses LCP renegotiation.
· If you configure neither LCP renegotiation nor mandatory CHAP authentication, the LNS uses the LAC for proxy authentication.
· When you configure mandatory CHAP authentication, follow these restrictions and guidelines
¡ For mandatory CHAP authentication to take effect, you must also configure CHAP authentication for the PPP users on the VT interface of the LNS.
¡ For users that do not support a new round of authentication, as a best practice, do not configure this feature. Otherwise, the L2TP tunnels cannot be established because the users fail to pass CHAP authentication on the LNS.
· With mandatory LCP renegotiation enabled, if the corresponding VT interface is not configured with authentication, the LNS does not perform a new round of authentication for users. In this case, the users are authenticated only once on the LAC.
Examples
· Configuring AAA on an LAC
For more information about configuring AAA authentication, see Security Configuration Guide.
To enable AAA authentication on an LAC, you also need to configure PAP or CHAP authentication for PPP users on the user access interfaces. For information about configuring PAP or CHAP, see Layer 2—WAN Access Configuration Guide.
· Configuring AAA on an LNS
For more information about configuring AAA authentication, see Security Configuration Guide.
¡ Configuring mandatory LCP renegotiation
# Force an LNS to perform LCP negotiation with users.
<Sysname> system-view
[Sysname] l2tp-group 1 mode lns
[Sysname-l2tp1] mandatory-lcp
¡ Configuring mandatory CHAP authentication
# Force the LNS to perform CHAP authentication for users.
<Sysname> system-view
[Sysname] l2tp-group 1 mode lns
[Sysname-l2tp1] mandatory-chap
# Enter VT interface view and configure the interface to authentication PPP users by using CHAP.
For more information about VT interfaces, see Layer 2—WAN Access Configuration Guide.
Securing L2TP tunnel data
Security threats
The following security threats exist in an L2TP network:
· An illegal peer establishes a tunnel to the local end to get internal data of the local end.
· An illegal user gets the AVP data (for example, tunnel negotiation parameters, session negotiation parameters, and user authentication information) transferred in plaintext.
Hardening recommendations
To avoid the security threats above, you can configure the following security features on the device:
· L2TP tunnel authentication
Tunnel authentication allows the LAC and LNS to authenticate each other. Either the LAC or the LNS can initiate a tunnel authentication request. A tunnel can be established between them only when both authentications succeed. To ensure tunnel security, enable tunnel authentication.
· Transferring AVP data in hidden mode
L2TP uses Attribute Value Pairs (AVPs) to transmit tunnel negotiation parameters, session negotiation parameters, and user authentication information. Transferring AVP data in hidden mode can hide sensitive AVP data such as user passwords.
Restrictions and guidelines
· Configuring tunnel authentication
Modifying the tunnel authentication key does not affect the normal communication of current tunnels. The tunnel authentication key change takes effect at next tunnel establishment.
· Transferring AVP data in hidden mode
This configuration takes effect only when the tunnel authentication feature is enabled.
Examples
· Configuring tunnel authentication
# Enable L2TP tunnel authentication.
<Sysname> system-view
[Sysname] l2tp-group 1 mode lns
[Sysname-l2tp1] tunnel authentication
# Specify the tunnel authentication key as &569pass1.
[Sysname-l2tp1] tunnel password simple &569pass1
· Transferring AVP data in hidden mode
# Enable L2TP tunnel authentication.
<Sysname> system-view
[Sysname] l2tp-group 1 mode lac
[Sysname-l2tp1] tunnel authentication
# Specify the tunnel authentication key as &569pass1.
[Sysname-l2tp1] tunnel password simple &569pass1
# Enable transferring AVP data in hidden mode.
[Sysname-l2tp1] tunnel avp-hidden
Securing LAC/LNS device performance
Security threats
In an L2TP network, an LNS might encounter the following security threats:
· When a user comes online, the LNS creates a VA interface for the user to exchange data with the LAC. After the user goes offline, the VA interface must be deleted. Creating and deleting VA interfaces consumes certain system resources. When the device is attacked by a large number of users frequently coming online and going offline, the device processing capability will be insufficient, and a DoS attack occurs.
· When a large number of L2TP users come online, the device performance will be affected.
· When a large number of disordered packets are processed, the device performance will be affected.
· When the number of packets received on the local end exceeds the processing capability of the local end, some users might fail to come online.
Hardening recommendations
To avoid the security threats above, you can configure the following security features on the device to reduce the influence on the device performance and ensure L2TP users can come online stably:
· Configuring a VA pool
A VA pool contains a group of VA interfaces. You can configure a VA pool to improve the performance of establishing or terminating L2TP connections. The LNS selects a VA interface from the pool for a requesting user and releases the VA interface when the user goes offline. In this way, the L2TP tunnel establishment and termination rates are improved, and the influence on the device performance when a large number of users come online or go offline is reduced.
· Setting the maximum number of ICRQ packets that the LNS can process per second
To avoid device performance degradation and make sure the LNS can processes ICRQ requests correctly, use this feature to adjust the ICRQ packet processing rate limit. ICRQ packets exceeding the limit are dropped.
· Setting the receiving window size for L2TP
To enable the device to process a larger number of disordered packets, use this feature to enlarge the receiving window size for an L2TP tunnel.
The device uses a receiving window to reorder disordered packets based on packet sequence numbers.
If the sequence number of a packet is within the receiving window but does not equal the minimum value of the window, the device performs the following operations:
a. The device buffers the packet.
b. The minimum value and maximum value of the receiving window increment by one.
c. The device continues to check the next arriving packet.
If the sequence number of a packet equals the minimum value of the receiving window, the device performs the following operations:
a. The device processes the packet.
b. The minimum value and maximum value of the receiving window increment by one.
c. The device checks buffered packets for a packet with the sequence number equal to the new minimum value of the receiving window.
d. If no required packet is found, the device checks the next arriving packet.
If the sequence number of a packet is not within the receiving window, the device drops the packet.
· Setting the sending window size for L2TP
The packet processing capability of a peer end might mismatch the receiving window size of the peer end in some networks. For example, the actual packet processing capability of the peer end is 10, but the receiving window size of the peer end is 20. To ensure stable L2TP services, you can adjust the sending window size for the device to match the actual packet processing capability of the peer end.
Restrictions and guidelines
· Configuring a VA pool
A VT interface can be associated with only one VA pool. To change the capacity of a VA pool, delete the previous configuration and reconfigure the VA pool.
Creating or deleting a VA pool takes time. During the process of creating or deleting a VA pool, users can come online or go offline, but the VA pool does not take effect.
The system might create a VA pool that contains VA interfaces less than the specified number because of insufficient resources. To view the number of available VA interfaces and the current state of the VA pool, use the display l2tp va-pool command.
Create a VA pool with an appropriate capacity, because a VA pool occupies much system memory.
Deleting a VA pool does not log off the users who are using VA interfaces in the VA pool.
· Setting the receiving window size for L2TP
In the L2TP tunnel establishment process, the device uses the value specified in L2TP group view as the receiving window size. Changing the receiving window size after an L2TP tunnel is established does not affect the established L2TP tunnel.
· Setting the sending window size for L2TP
The sending window size set in L2TP group view is obtained in the L2TP tunnel establishment process.
¡ If the sending window size is 0, the device uses the default sending window size.
¡ If the sending window size is not 0, the device uses the specified value as the sending window size.
Changing the sending window size after an L2TP tunnel is established does not affect the established L2TP tunnel.
Examples
· Configuring a VA pool
# Create a VA pool with a capacity of 1000 VA interfaces for Virtual-template 2.
<Sysname> system-view
[Sysname] l2tp virtual-template 2 va-pool 1000
· Setting the maximum number of ICRQ packets that the LNS can process per second
# Set the maximum number of ICRQ packets that the LNS can process per second to 200.
<Sysname> system-view
[Sysname] l2tp icrq-limit 200
· Setting the receiving window size for L2TP
# Set the receiving window size for L2TP group 1 to 128.
<Sysname> system-view
[Sysname] l2tp-group 1 mode lac
[Sysname-l2tp1] tunnel window receive 128
· Setting the sending window size for L2TP
# Set the sending window size for L2TP group 1 to 128.
<Sysname> system-view
[Sysname] l2tp-group 1 mode lac
[Sysname-l2tp1] tunnel window send 128
Securing portal
Controlling portal user access
Security threats
On a portal network, the following security threats might exist:
· If an attacker sends a large number of HTTP or HTTPS requests, the resources on the portal server exhaust, and the server cannot respond to authentication requests from valid users.
· An invalid user makes exhaustive password cracking attempts to guess the password of valid users.
· An invalid user accesses the network.
Hardening recommendations
To defense against the above security threats, configure the following features on the device:
· Portal HTTP and HTTPS attack defense
¡ Limiting the number of per-user redirection sessions—This feature limits the number of portal redirection sessions for a single user. If the HTTP or HTTPS redirection sessions for a user exceeds the limit, the device denies new redirection requests from the user.
¡ Portal safe-redirect—This feature filters HTTP and HTTPS requests by request method, browser type, and destination URL, and redirects only the permitted HTTP and HTTPS requests. This reduces the risk that the portal Web server cannot respond to HTTP and HTTPS requests because of overload.
· Blocking portal users that fail portal authentication—This feature blocks a portal user if the user consecutively fails authentication for the specified times within the failure detection period. All authentication requests from the user are dropped by the device till the blocking times out. The blocked portal user can perform portal authentication again when the blocking timeout time expires.
· Allowing only DHCP users to pass portal authentication—This feature allows only users with DHCP-assigned IP addresses to pass portal authentication. Users with static IP addresses cannot pass portal authentication to come online. This feature ensures that only users with valid IP addresses can access the network.
Restrictions and guidelines
The allowing only DHCP users to pass portal authentication feature takes effect only on a network where the access device also acts as the DHCP server.
In an IPv6 portal network, terminal device users might use temporary IPv6 addresses to access the network. To ensure that these IPv6 users can pass portal authentication when only users with DHCP-assigned IP addresses to pass portal authentication is enabled, disable the temporary IPv6 address feature on terminal devices.
Portal preauthentication users will not be blocked even though they consecutively fail authentication for the specified times within the failure detection period.
In wireless networks, the maximum number of portal redirection sessions for a single user takes effect only in centralized forwarding mode.
Examples
· Configure portal HTTP and HTTPS attack defense
¡ Limit the number of per-user redirection sessions:
# Set the maximum number of portal redirect sessions for a single user to 128.
<Sysname> system-view
[Sysname] portal redirect max-session per-user 128
¡ Configure portal safe-redirect:
# Enable portal safe-redirect.
<Sysname> system-view
[Sysname] portal safe-redirect enable
# Specify the GET request method for portal safe-redirect.
[Sysname] portal safe-redirect method get
# Specify browser types Chrome and Safari for portal safe-redirect.
[Sysname] portal safe-redirect user-agent Chrome
[Sysname] portal safe-redirect user-agent Safari
# Specify http://www.abc.com as a portal safe-redirect forbidden URL.
[Sysname] portal safe-redirect forbidden-url http://www.abc.com
# Specify .jpg as a portal safe-redirect forbidden filename extension.
[Sysname] portal safe-redirect forbidden-file .jpg
# Configure the default action as permit for portal safe-redirect.
[Sysname] portal safe-redirect default-action permit
# Specify http://www.abc.com as a portal safe-redirect permitted URL.
[Sysname] portal safe-redirect permit-url http://www.abc.com
· Block portal users that fail portal authentication:
# Configure the device to block a portal user if the user consecutively fails portal authentication twice within 100 minutes.
<Sysname> system-view
[Sysname] portal user-block failed-times 2 period 100
# Set the portal user blocking timeout time to 20 minutes.
[Sysname] portal user-block reactive 20
· Allow only DHCP users to pass portal authentication:
# Allow only users with DHCP-assigned IP addresses on GigabitEthernet 1/0/1 to pass portal authentication.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] portal user-dhcp-only
Limiting the number of portal users
Hardening recommendations
Control the total number of portal users to prevent system resource inefficiency caused by excessive users. When the number of online portal users exceeds the limit, the system denies authentication requests from new users.
Restrictions and guidelines
Make sure the maximum combined number of IPv4 and IPv6 portal users specified on all interfaces does not exceed the system-allowed maximum number. Otherwise, the exceeding number of portal users will not be able to log in to the device.
Examples
· Limit the global number of portal users:
# Set the maximum number of portal users allowed by the system to 100.
<Sysname> system-view
[Sysname] portal max-user 100
· Limit the number of portal users on an interface:
¡ IPv4:
# Set the maximum number to 100 for IPv4 portal users on GigabitEthernet 1/0/1.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] portal ipv4-max-user 100
¡ IPv6:
# Set the maximum number to 100 for IPv6 portal users on GigabitEthernet 1/0/1.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] portal ipv6-max-user 100
Enabling strict checking on portal authorization information
Hardening recommendations
The strict checking feature allows a portal user to stay online only when the authorization information for the user is successfully deployed. The strict checking fails if the authorized ACL or user profile does not exist on the device or the device fails to deploy the authorized ACL or user profile.
You can enable strict checking on the authorized ACL, authorized user profile, or both. If you enable both ACL checking and user profile checking, the user will be logged out if either checking fails.
Examples
# Enable strict checking on authorized ACLs on GigabitEthernet 1/0/1.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname–GigabitEthernet1/0/1] portal authorization acl strict-checking
Configuring SSL VPN
To allow remote user access to protected resources behind an SSL VPN gateway, you must first configure these resources on the gateway. Remote users can access only the resources authorized to them.
SSL VPN operates as follows:
1. The remote user establishes an HTTPS connection to the SSL VPN gateway.
In this process, the remote user and the SSL VPN gateway perform SSL certificate authentication.
2. The remote user enters the username and password.
3. The SSL VPN gateway authenticates the credentials that the user entered, and authorizes the user to access a range of resources.
4. The user selects a resource to access.
An access request for that resource is sent to the SSL VPN gateway through the SSL connection.
5. The SSL VPN gateway resolves the request and forwards the request to the corresponding internal server.
6. The SSL VPN gateway forwards the server's reply to the user through the SSL connection.
For more information about SSL VPN, see VPN Configuration Guide.
DHCP security
DHCP user class whitelist
Security threats
DHCP supports allocating IP addresses by user class. The DHCP server assigns an IP address in an address range to a client based on the user class of the client. If the client is an attack source, it can initiate an attack after obtaining an IP address.
Hardening recommendations
To allow the DHCP server to process requests only from specific clients, use the DHCP user class whitelist.
Restrictions and guidelines
· If a user class is not on the whitelist, all clients that match the user class cannot obtain IP addresses.
· The whitelist does not take effect on clients who request static IP addresses, and the server always processes their requests.
Examples
# Enable the DHCP user class whitelist in DHCP address pool 0.
<Sysname> system-view
[Sysname] dhcp server ip-pool 0
[Sysname-dhcp-pool-0] verify class
# Add user classes test1 and test2 to the user class whitelist in DHCP address pool 0.
[Sysname-dhcp-pool-0] valid class test1 test2
DHCP relay entry management on the DHCP relay agent
Security threats
The gateway device cannot work correctly if illegal clients use forged packets to attack it.
Hardening recommendations
· Recording DHCP relay entries
For some security features to use the clients' IP-to-MAC bindings on the DHCP relay agent for security check, use the recording DHCP relay entries. This feature automatically records clients' IP-to-MAC bindings (relay entries) after they obtain IP addresses through DHCP.
Some security features can use the relay entries to check incoming packets and block packets that do not match any entry. In this way, illegal hosts are not able to access external networks through the relay agent. Examples of the security features are ARP address check and authorized ARP.
· Periodic refresh of dynamic relay entries
To allow the DHCP relay agent to maintain dynamic relay entries in a timely manner, use the periodic refresh of dynamic relay entries. This feature uses the IP address of a relay entry to periodically send a DHCP-REQUEST message to the DHCP server. It maintains the relay entries depending on what it receives from the DHCP server:
¡ If the server returns a DHCP-ACK message or does not return any message within an interval, the DHCP relay agent removes the relay entry. In addition, upon receiving the DHCP-ACK message, the relay agent sends a DHCP-RELEASE message to release the IP address.
¡ If the server returns a DHCP-NAK message, the relay agent keeps the relay entry.
· Client offline detection
To enable the DHCP relay agent to detect the user online status based on the ARP entry, use the client offline detection. When an ARP entry ages out, this feature deletes the relay entry for the IP address and sends a RELEASE message to the DHCP server.
Restrictions and guidelines
The client offline detection feature does not function if an ARP entry is manually deleted.
Examples
# Enable the relay agent to record relay entries.
<Sysname> system-view
[Sysname] dhcp relay client-information record
# Enable periodic refresh of dynamic relay entries.
[Sysname] dhcp relay client-information refresh enable
# Set the refresh interval to 100 seconds.
[Sysname] dhcp relay client-information refresh interval 100
# Enable client offline detection.
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] dhcp client-detect
DHCP proxy on the DHCP relay agent
Security threats
The DHCP server cannot work correctly when illegal clients send attack packets to it.
Hardening recommendations
To isolate DHCP servers from DHCP clients and protect DHCP servers against attacks, use the DHCP proxy feature.
Upon receiving a response from the server, the DHCP proxy modifies the server's IP address as the relay interface's IP address before sending out the response. The DHCP client takes the DHCP relay agent as the DHCP server.
Examples
# Enable DHCP proxy on GigabitEthernet 1/0/1.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] dhcp select relay proxy
DNS security
Security threats
When an attacker assigns incorrect DNS suffixes and DNS server addresses to the device through DHCP, the device will fail the domain name resolution or get incorrect resolution result.
Hardening recommendations
To protect the device against attackers that act as the DHCP server to assign incorrect DNS suffix and domain name server address, specify a DNS trusted interface. This feature ensures that the device use only the DNS suffix and domain name server information obtained through the trusted interface. Information obtained through untrusted interface cannot be used for domain name resolution.
Examples
# Specify GigabitEthernet 1/0/1 as a DNS trusted interface.
<Sysname> system-view
[Sysname] dns trust-interface gigabitethernet 1/0/1
ICMP security
Security threats
The IP and transport layer protocols use ICMP error messages to report errors. If an attacker uses ICMP error messages to initiate attacks, the forwarding path of packets will be changed.
Hardening recommendations
To prevent ICMP message attacks, disable the device from sending the following ICMP error messages: ICMP redirect messages, ICMP time exceeded messages, and ICMP destination unreachable messages.
Examples
· Configure ICMPv4 security features
# Disable the device from sending ICMP redirect messages.
<Sysname> system-view
[Sysname] undo ip redirects enable
# Disable the device from sending ICMP time exceeded messages.
[Sysname] undo ip ttl-expires enable
# Disable the device from sending ICMP destination unreachable messages.
[Sysname] undo ip unreachables enable
· Configure ICMPv6 security features
# Disable the device from sending ICMPv6 destination unreachable messages.
<Sysname> system-view
[Sysname] undo ipv6 unreachables enable
# Disable the device from sending ICMPv6 time exceeded messages.
[Sysname] undo ipv6 hoplimit-expires enable
# Disable the device from sending ICMPv6 redirect messages.
[Sysname] undo ipv6 redirects enable
TCP security
Security threats
In a SYN flood attack, an attacker sends a large number of SYN packets, but they do not respond to the SYN ACK packets from the server. As a result, the server establishes a large number of TCP semi-connections and cannot handle normal services.
Hardening recommendations
SYN Cookie can protect the server from SYN flood attacks. When the server receives a SYN packet, it responds to the request with a SYN ACK packet without establishing a TCP semi-connection.
The server establishes a TCP connection and enters ESTABLISHED state only when it receives an ACK packet from the sender.
Examples
# Enable SYN Cookie.
<Sysname> system-view
[Sysname] tcp syn-cookie enable
Routing protocols
Securing RIP/RIPng
Security threats
When an attacker acts as a fake RIP/RIPng neighbor or modifies RIP/RIPng routes, incorrect route learning or network interruption might occur.
Hardening recommendations
· Enable zero field check on incoming RIPv1 and RIPng messages.
Some fields in the RIPv1 and RIPng messages must be set to zero. These fields are called "zero fields." If a zero field of a message contains a non-zero value, RIP or RIPng does not process the message if zero field check is enabled.
· Enable source IP address check on incoming RIP updates.
Upon receiving a message on an interface, RIP compares the source IP address of the message with the IP address of the interface. If they are not in the same network segment, RIP discards the message.
· Configure RIPv2 message authentication.
Message authentication enables a RIPv2 router to carry authentication information in outgoing messages and validate authentication information in incoming messages. The router drops the messages that fail the validation to ensure that it receives only the RIPv2 messages from trusted sources.
· Enable RIPng to authenticate packets by using an IPsec profile.
An IPsec profile contains inbound and outbound security parameter indexes (SPIs). RIPng compares the inbound SPI defined in the IPsec profile with the outbound SPI in the received packets. Two RIPng devices accept the packets from each other and establish a neighbor relationship only if the SPIs are the same and the relevant IPsec profiles match. For more information about IPsec profiles, see IPsec configuration in Security Configuration Guide.
Examples
# Enable zero field check on RIPv1 messages for RIP process 1.
<Sysname> system-view
[Sysname] rip
[Sysname-rip-1] checkzero
# Enable source IP address check on inbound RIP routing updates.
<Sysname> system-view
[Sysname-rip] rip 100
[Sysname-rip-100] validate-source-address
# Configure MD5 authentication on GigabitEthernet 1/0/1, and specify a plaintext key 154&rose in the format defined in RFC 2453.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] rip version 2
[Sysname-GigabitEthernet1/0/1] rip authentication-mode md5 rfc2453 plain 154&rose
# Enable zero field check on RIPng packets for RIPng 100.
<Sysname> system-view
[Sysname] ripng 100
[Sysname-ripng-100] checkzero
# Apply IPsec profile profile001 to GigabitEthernet 1/0/1.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] ripng ipsec-profile profile001
Securing OSPF/OSPFv3
Hardening recommendations
Configure OSPF/OSPFv3 authentication to prevent routing information leakage and attacks on routers. When establishing neighbor relationships, OSPF/OSPFv3 adds authentication information into sent packets and authenticates received packets. Only packets that pass the authentication can be received. An OSPF/OSPFv3 neighbor relationship cannot be established if the exchanged packets fail the authentication.
Configure OSPFv3 packet authentication by using an IPsec profile. For more information about IPsec profiles, see IPsec configuration in Security Configuration Guide.
Configure Generalized TTL Security Mechanism (GTSM) to protect a device by comparing the TTL value of an incoming OSPF packet against a valid TTL range. If the TTL value is out of the valid TTL range, the packet is discarded. The valid TTL range is 255 – the configured hop count + 1 to 255.
Examples
# Enable MD5 authentication for OSPF area 0, and set the key ID and plaintext key string to 15 and abc, respectively.
<Sysname> system-view
[Sysname] ospf 100
[Sysname-ospf-100] area 0
[Sysname-ospf-100-area-0.0.0.0] authentication-mode md5 15 plain abc
# Enable MD5 authentication for GigabitEthernet 1/0/1, and set the key ID and plaintext key string to 15 and Ab&123456, respectively.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] ospf authentication-mode md5 15 plain Ab&123456
# Configure OSPFv3 area 1 to use keychain test for packet authentication.
<Sysname> system-view
[Sysname] ospfv3 1
[Sysname-ospfv3-1] area 1
[Sysname-ospfv3-1-area-0.0.0.1] authentication-mode keychain test
# Apply IPsec profile profile001 to area 0 in OSPFv3 process 1.
<Sysname> system-view
[Sysname] ospfv3 1
[Sysname-ospfv3-1] area 0
[Sysname-ospfv3-1-area-0.0.0.0] enable ipsec-profile profile001
# Enable OSPF GTSM for GigabitEthernet1/0/1 and set the hop limit to 254.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] ospf ttl-security hops 254
Securing IS-IS
Hardening recommendations
Configure IS-IS authentication to add authentication information into sent packets and authenticate received packets. A packet is received only when it passes the authentication. IS-IS authentication includes the following:
· Neighbor relationship authentication—Authenticates hello packets to prevent IS-IS from establishing neighbor relationships with untrusted routers.
· Area authentication—Authenticates Level-1 LSPs, CSNPs, and PSNPs to prevent installing routing information learned from untrusted routers into the Level-1 LSDB.
· Routing domain authentication—Authenticates Level-2 LSPs, CSNPs, and PSNPs to prevent installing routing information learned from untrusted routers into a routing domain.
Examples
# Enable simple authentication for GigabitEthernet 1/0/1, and set the plaintext key string to Ab&123456.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] isis authentication-mode simple plain Ab&123456
# Enable simple authentication for IS-IS process 1, and set the plaintext key string to Ab&123456.
<Sysname> system-view
[Sysname] isis 1
[Sysname-isis-1] area-authentication-mode simple plain Ab&123456
# Enable simple routing domain authentication, and set the plaintext key to Ab&123456.
<Sysname> system-view
[Sysname] isis 1
[Sysname-isis-1] domain-authentication-mode simple plain Ab&123456
Securing BGP
Limiting the number of routes that can be received from a peer or peer group
Security threats
An attacker might send a large number of BGP routes to waste system resources and interrupt the network.
Hardening recommendations
Configure the maximum number of routes that can be received from a peer or peer group and the action to take when the maximum number is reached. The following actions are available:
· Tears down the BGP session to the peer or peer group and does not re-establish the session.
· Retains the session to the peer or peer group, continues to receive routes from the peer or peer group, and generates a log message.
· Retains the session to the peer or peer group, discards excessive routes, and generates a log message.
· Tears down the BGP session to the peer or peer group and re-establishes a BGP session to the peer or peer group after a specific period of time.
Examples
# In BGP IPv4 unicast address family view, set the maximum number of routes that can be received from peer 1.1.1.1 to 10000, and enable the router to tear down the session to the peer if the number is exceeded.
<Sysname> system-view
[Sysname] bgp 109
[Sysname-bgp-default] address-family ipv4 unicast
[Sysname-bgp-default-ipv4] peer 1.1.1.1 route-limit 10000
Establishing reliable BGP sessions
Security threats
An attacker might establish BGP sessions with devices, intercept and tamper with BGP packets, and affect BGP route learning.
Hardening recommendations
Configure MD5 or keychain authentication to enhance the security of the TCP connection established between BGP peers.
With MD5 authentication configured, BGP peers can establish TCP connections only when they use the same password. The MD5 algorithm is used to ensure that packets exchanged over the TCP connection between BGP peers are intact.
With keychain authentication configured, BGP peers can establish TCP connections only when the following conditions are met:
· Keychain authentication is enabled on both BGP peers.
· The keys used by the BGP peers at the same time have the same ID.
· The keys with the same ID use the same authentication algorithm and key string.
Examples
# In BGP instance view, perform MD5 authentication on the TCP connection between local router 10.1.100.1 and peer router 10.1.100.2, and set the authentication password to 358$aabbcc in plaintext form.
<Sysname> system-view
[Sysname] bgp 100
[Sysname-bgp-default] peer 10.1.100.2 password simple 358$aabbcc
# In BGP instance view, enable peer 10.1.1.1 to use keychain abc for authentication.
<Sysname> system-view
[Sysname] bgp 100
[Sysname-bgp-default] peer 10.1.1.1 as-number 100
[Sysname-bgp-default] peer 10.1.1.1 keychain abc
Configuring BGP GTSM
Security threats
An attacker might send a large number of valid IP packets to a device to exhaust the CPU resources of the device.
Hardening recommendations
Configure Generalized TTL Security Mechanism (GTSM) to protect a BGP session by comparing the TTL value of an incoming packet against a valid TTL range. If the TTL value is out of the valid TTL range, the packet is discarded. The valid TTL range is 255 – the configured hop count + 1 to 255. After GTSM is configured, packets sent by BGP have an initial TTL of 255.
Restrictions and guidelines
GTSM can provide the best protection for directly connected EBGP peers. As for IBGP peers or indirectly connected EBGP peers, the TTL of packets might be altered by intermediate devices, so the effect of GTSM depends on the security of intermediate devices.
Examples
# In BGP instance view, enable GTSM for BGP peer group test and set the maximum number of hops to a peer in the peer group to 1.
<Sysname> system-view
[Sysname] bgp 100
[Sysname-bgp-default] peer test ttl-security hops 1
Configuring IPsec for IPv6 BGP
Hardening recommendations
Configure IPsec for IPv6 BGP to prevent routing information leakage and attacks. IPsec can provide privacy, integrity, and authentication for IPv6 BGP packets exchanged between BGP peers.
When two IPv6 BGP peers are configured with IPsec (for example, Device A and Device B), Device A encapsulates an IPv6 BGP packet with IPsec before sending it to Device B. If Device B successfully receives and de-encapsulates the packet, it establishes an IPv6 BGP peer relationship with Device A or learns IPv6 BGP routes from Device A. If Device B receives but fails to de-encapsulate the packet, or receives a packet not protected by IPsec, it discards the packet.
Examples
# Configure an IPsec transform set and a manual IPsec profile. (Details not shown.) For more information, see IPsec configuration in Security Configuration Guide.
# In BGP instance view, apply IPsec profile profile001 to peer group test.
<Sysname> system-view
[Sysname] bgp 100
[Sysname-bgp-default] peer test ipsec-profile profile001
Multicast security
Hardening PIM and IPv6 PIM
Configuring a PIM hello policy
Security threats
In a PIM domain, each PIM-enabled interface on the device periodically multicasts PIM hello messages to discover PIM neighbors for maintaining the neighbor relationship and SPT. If the device receives a large number of invalid PIM hello messages, PIM neighbor relationship cannot be correctly established.
Hardening recommendations
To ensure the security of received PIM protocol packets, configure a PIM hello policy. This policy enables the device to filter PIM hello messages by using an ACL that specifies the packet source addresses. Malicious attack PIM packets are dropped.
Examples
# Configure a PIM hello policy on GigabitEthernet 1/0/1 so that only the devices on subnet 10.1.1.0/24 can become PIM neighbors of this device.
<Sysname> system-view
[Sysname] acl basic 2000
[Sysname-acl-ipv4-basic-2000] rule permit source 10.1.1.0 0.0.0.255
[Sysname-acl-ipv4-basic-2000] quit
[Sysname] interface gigabitethernet1/0/1
[Sysname-GigabitEthernet1/0/1] pim neighbor-policy 2000
# Configure an IPv6 PIM hello policy on GigabitEthernet 1/0/1 so that only the devices on subnet FE80:101::101/64 can become IPv6 PIM neighbors of this device.
<Sysname> system-view
[Sysname] acl ipv6 basic 2000
[Sysname-acl-ipv6-basic-2000] rule permit source fe80:101::101 64
[Sysname-acl-ipv6-basic-2000] quit
[Sysname] interface gigabitethernet1/0/1
[Sysname-GigabitEthernet1/0/1] ipv6 pim neighbor-policy 2000
ADVPN VAM protocol packet security
Configuring a preshared key
Hardening recommendations
To ensure that a VAM client establishes tunnels with legal VAM clients and secure data transmission, configure a preshared key for the VAM server and VAM clients in an ADVPN domain. The server and clients use the preshared key to generate initial encryption and authentication keys during connection initialization. They also use the preshared key to generate encryption and authentication keys for subsequent packets if encryption and authentication are needed.
Restrictions and guidelines
The VAM server and the VAM clients in the same ADVPN domain must have the same preshared key.
Examples
# Set the preshared key to SdU$123 in plaintext form for the VAM server in ADVPN domain 1.
<Sysname> system-view
[Sysname] vam server advpn-domain 1 id 1
[Sysname-vam-server-domain-1] pre-shared-key simple SdU$123
# Set the preshared key to SdU$123 in plaintext form for VAM client abc.
<Sysname> system-view
[Sysname] vam client name abc
[Sysname-vam-client-abc] pre-shared-key simple SdU$123
Authentication and encryption algorithms
Hardening recommendations
To secure ADVPN VAM protocol packets between a VAM server and client, specify packet authentication and encryption algorithms and their priorities on the VAM server.
The VAM server uses the specified algorithms to negotiate with the VAM client.
The VAM server and client use SHA-1 and AES-CBC-128 during connection initialization, and use the negotiated algorithms after connection initialization.
Restrictions and guidelines
The algorithm specified earlier in a command line has a higher priority.
The configuration of the commands that specify authentication and encryption algorithms does not affect registered VAM clients. It applies to subsequently registered VAM clients.
Examples
# Specify the authentication algorithms as MD5, SHA-1, and SHA-256 in descending order of priority for ADVPN domain 1.
<Sysname> system-view
[Sysname] vam server advpn-domain 1 id 1
[Sysname-vam-server-domain-1] authentication-algorithm md5 sha-1 sha-256
# Specify the encryption algorithms as AES-CBC-128 and 3DES-CBC for ADVPN domain 1, where AES-CBC-128 has a higher priority.
<Sysname> system-view
[Sysname] vam server advpn-domain 1 id 1
[Sysname-vam-server-domain-1] encryption-algorithm aes-cbc-128 3des-cbc
Identity authentication
Hardening recommendations
To prevent illegal VAM clients from registering with the VAM server in an ADVPN domain or modifying legal client information, configure AAA authentication on the server to authenticate VAM clients.
A VAM client submits its username and password to the VAM server for identity authentication during the registration process. Only VAM clients that pass identity authentication can access the ADVPN domain.
The VAM server supports PAP and CHAP methods for AAA authentication. For information about AAA configuration on the VAM server, see Security Configuration Guide.
Restrictions and guidelines
If the specified authentication ISP domain does not exist, the authentication will fail.
A newly configured authentication method does not affect registered VAM clients. It applies to subsequently registered VAM clients.
Examples
# Configure the VAM server to use CHAP to authenticate clients in ADVPN domain 1. The authentication ISP domain is the system default ISP domain.
<Sysname> system-view
[Sysname] vam server advpn-domain 1 id 1
[Sysname-vam-server-domain-1] authentication-method chap
# Configure the username as user and password as &192Qtest in plaintext form for VAM client abc.
<Sysname> system-view
[Sysname] vam client name abc
[Sysname-vam-client-abc] user user password simple &192Qtest
Authenticating high availability protocol packets
Securing VRRP packet authentication
Security threats
An unauthorized user might construct VRRP advertisement packets to attack a VRRP group, causing the VRRP group to operate incorrectly.
Hardening recommendations
To avoid attacks from unauthorized users, VRRP member routers add authentication keys in VRRP packets to authenticate one another. VRRP provides the following authentication methods:
· Simple authentication
The sender fills an authentication key into the VRRP packet, and the receiver compares the received authentication key with its local authentication key. If the two authentication keys match, the received VRRP packet is legitimate. If the keys do not match, the received packet is illegitimate.
· MD5 authentication
The sender computes a digest for the VRRP packet by using the authentication key and MD5 algorithm, and saves the result to the authentication header of the packet. The receiver performs the same operation with the authentication key and MD5 algorithm, and compares the result with the content in the authentication header. If the results match, the received VRRP packet is legitimate. If the results do not match, the received packet is illegitimate.
Restrictions and guidelines
Compared with simple authentication, MD5 authentication provides higher security and requires more system resources for digest computation.
You can configure different authentication modes and authentication keys for VRRP groups on an interface. Members of the same VRRP group must use the same authentication mode and authentication key.
IPv4 VRRPv3 does not support VRRP packet authentication. In VRRPv3, authentication mode and authentication key settings do not take effect.
Examples
# Set the authentication mode to simple and the authentication key to Sysname for VRRP group 1 on GigabitEthernet 1/0/1.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] vrrp vrid 1 authentication-mode simple plain Sysname
BFD control packet authentication
Security threats
If the device receives forged BFD packets, for example, a BFD packet with incorrect state information, the BFD session flaps.
Hardening recommendations
Configure an authentication mode for BFD control packets. The device encapsulates authentication information in BFD control packets. If the authentication information does not match the configured settings on the remote device, the BFD session cannot be established.
Examples
# Enable GigabitEthernet 1/0/1 to perform simple authentication for single-hop BFD control packets, setting the authentication key ID to 1 and plaintext key to &Pk123456.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] bfd authentication-mode simple 1 plain &Pk123456
# Configure the simple authentication mode for multihop BFD control packets, setting the authentication key ID to 1 and key to &Pk123456.
<Sysname> system-view
[Sysname] bfd multi-hop authentication-mode simple 1 plain &Pk123456
NTP/SNTP access control
Configuring the NTP access right
Security threats
On a network that uses NTP for time synchronization, unauthorized time servers can send time synchronization information to the device, causing the device to synchronize to an incorrect time.
Hardening recommendations
To protect the device from synchronizing to an unauthorized time server, configure the NTP access right. The NTP access right associated with ACLs limits the access of peer devices to the NTP services on the local device. The NTP access rights are in the following order, from the least restrictive to the most restrictive:
· Peer—Allows time requests and NTP control queries (such as alarms, authentication status, and time server information) and allows the local device to synchronize itself to a peer device.
· Server—Allows time requests and NTP control queries, but does not allow the local device to synchronize itself to a peer device.
· Synchronization—Allows only time requests and denies control queries.
· Query—Allows only NTP control queries.
When the device receives an NTP request, it matches the request against the access rights in order from the least restrictive to the most restrictive: peer, server, synchronization, and query.
· If no NTP access control is configured, the peer access right applies.
· If the IP address of the peer device matches a permit statement in an ACL, the access right is granted to the peer device. If a deny statement or no ACL is matched, no access right is granted.
· If no ACL is specified for an access right or the ACL specified for the access right is not created, the access right is not granted.
· If none of the ACLs specified for the access rights is created, the peer access right applies.
· If none of the ACLs specified for the access rights contains rules, no access right is granted.
This feature provides minimal security for a system running NTP. A more secure method is NTP authentication.
Examples
# Create and configure an ACL for NTP access control.
For information about configuring an ACL, see ACL and QoS configuration Guide.
# Configure the NTP access right (ACL 2001 for example).
<Sysname> system-view
[Sysname] ntp-service peer acl 2001
Authenticating NTP messages
Security threats
When the device uses NTP for time synchronization, it might get time information from an unauthorized time server and synchronize to an incorrect time.
Hardening recommendations
To protect the device from synchronizing to an unauthorized time server, configure NTP authentication. This feature authenticates the NTP messages for security purposes. The device receives an NTP message and gets time synchronization information from it only when the message is authenticated. If the message fails authentication, the device discards the message. This function ensures that the device does not synchronize to an unauthorized time server.
As shown in Figure 3, NTP authentication proceeds as follows:
1. The sender uses the key identified by the key ID to calculate a digest for the NTP message through the specified algorithm. Then it sends the calculated digest together with the NTP message and key ID to the receiver.
2. Upon receiving the message, the receiver performs the following actions:
a. Finds the key according to the key ID in the message.
b. Uses the key and the specified algorithm to calculate the digest for the message.
c. Compares the digest with the digest contained in the NTP message.
- If they are different, the receiver discards the message.
- If they are the same, the receiver determines whether the sender is allowed to use the authentication ID on the local end. If the sender is allowed to use the authentication ID, the receiver accepts the message. If the sender is not allowed to use the authentication ID, the receiver discards the message
Restrictions and guidelines
You can configure NTP authentication in client/server mode, symmetric active/passive mode, broadcast mode, or multicast mode. To ensure a successful NTP authentication, configure the same authentication key ID, algorithm, and key on the local device and time server. Make sure the time server is allowed to use the key ID for authentication on the local device.
NTP authentication results differ when different settings are configured on the local device and time server, as shown in Table 2, Table 3, Table 4, and Table 5. (N/A in the table means that whether the configuration is performed or not does not make any difference.)
Table 2 Results of NTP authentication in client/server mode
|
Client |
Server |
||||
|
Enable NTP authentication |
Specify the server and key |
Trusted key |
Enable NTP authentication |
Trusted key |
|
|
Successful authentication |
|||||
|
Yes |
Yes |
Yes |
Yes |
Yes |
|
|
Failed authentication |
|||||
|
Yes |
Yes |
Yes |
Yes |
No |
|
|
Yes |
Yes |
Yes |
No |
N/A |
|
|
Yes |
Yes |
No |
N/A |
N/A |
|
|
Authentication not performed |
|||||
|
Yes |
No |
N/A |
N/A |
N/A |
|
|
No |
N/A |
N/A |
N/A |
N/A |
|
Table 3 Results of NTP authentication in symmetric active/passive peer mode
|
Active peer |
Passive peer |
||||
|
Enable NTP authentication |
Specify the peer and key |
Trusted key |
Stratum level |
Enable NTP authentication |
Trusted key |
|
Successful authentication |
|||||
|
Yes |
Yes |
Yes |
N/A |
Yes |
Yes |
|
Failed authentication |
|||||
|
Yes |
Yes |
Yes |
N/A |
Yes |
No |
|
Yes |
Yes |
Yes |
N/A |
No |
N/A |
|
Yes |
No |
N/A |
N/A |
Yes |
N/A |
|
No |
N/A |
N/A |
N/A |
Yes |
N/A |
|
Yes |
Yes |
No |
Larger than the passive peer |
N/A |
N/A |
|
Yes |
Yes |
No |
Smaller than the passive peer |
Yes |
N/A |
|
Authentication not performed |
|||||
|
Yes |
No |
N/A |
N/A |
No |
N/A |
|
No |
N/A |
N/A |
N/A |
No |
N/A |
|
Yes |
Yes |
No |
Smaller than the passive peer |
No |
N/A |
Table 4 Results of NTP authentication in broadcast mode
|
Broadcast server |
Broadcast client |
|||
|
Enable NTP authentication |
Specify the server and key |
Trusted key |
Enable NTP authentication |
Trusted key |
|
Successful authentication |
||||
|
Yes |
Yes |
Yes |
Yes |
Yes |
|
Failed authentication |
||||
|
Yes |
Yes |
Yes |
Yes |
No |
|
Yes |
Yes |
Yes |
No |
N/A |
|
Yes |
Yes |
No |
Yes |
N/A |
|
Yes |
No |
N/A |
Yes |
N/A |
|
No |
N/A |
N/A |
Yes |
N/A |
|
Authentication not performed |
||||
|
Yes |
Yes |
No |
No |
N/A |
|
Yes |
No |
N/A |
No |
N/A |
|
No |
N/A |
N/A |
No |
N/A |
Table 5 Results of NTP authentication in multicast mode
|
Multicast server |
Multicast client |
|||
|
Enable NTP authentication |
Specify the server and key |
Trusted key |
Enable NTP authentication |
Trusted key |
|
Successful authentication |
||||
|
Yes |
Yes |
Yes |
Yes |
Yes |
|
Failed authentication |
||||
|
Yes |
Yes |
Yes |
Yes |
No |
|
Yes |
Yes |
Yes |
No |
N/A |
|
Yes |
Yes |
No |
Yes |
N/A |
|
Yes |
No |
N/A |
Yes |
N/A |
|
No |
N/A |
N/A |
Yes |
N/A |
|
Authentication not performed |
||||
|
Yes |
Yes |
No |
No |
N/A |
|
Yes |
No |
N/A |
No |
N/A |
|
No |
N/A |
N/A |
No |
N/A |
Examples
· Configuring NTP authentication in client/server mode
The following configuration example uses Device A as the client and Device B as the server.
a. Configure Device A.
# Enable NTP authentication.
<DeviceA> system-view
[DeviceA] ntp-service authentication enable
# Create a plaintext NTP authentication key, specifying the key ID as 42 and key value as aNiceKey.
[DeviceA] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# Configure key 42 as a trusted key.
[DeviceA] ntp-service reliable authentication-keyid 42
# Associate key 42 with NTP server 1.1.1.1 (IP address of Device B).
[DeviceA] ntp-service unicast-server 1.1.1.1 authentication-keyid 42
b. Configure Device B.
# Enable NTP authentication.
<DeviceB> system-view
[DeviceB] ntp-service authentication enable
# Create a plaintext NTP authentication key, specifying the key ID as 42 and key value as aNiceKey.
[DeviceB] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# Configure key 42 as a trusted key.
[DeviceB] ntp-service reliable authentication-keyid 42
· Configuring NTP authentication in symmetric active/passive mode
The following configuration example uses Device A as the active peer and Device B as the passive peer.
a. Configure Device A.
# Enable NTP authentication.
<DeviceA> system-view
[DeviceA] ntp-service authentication enable
# Create a plaintext NTP authentication key, specifying the key ID as 42 and key value as aNiceKey.
[DeviceA] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# Configure key 42 as a trusted key.
[DeviceA] ntp-service reliable authentication-keyid 42
# Associate key 42 with passive peer 1.1.1.1 (IP address of Device B).
[DeviceA] ntp-service unicast-peer 1.1.1.1 authentication-keyid 42
b. Configure Device B.
# Enable NTP authentication.
<DeviceB> system-view
[DeviceB] ntp-service authentication enable
# Create a plaintext NTP authentication key, specifying the key ID as 42 and key value as aNiceKey.
[DeviceB] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# Configure key 42 as a trusted key.
[DeviceB] ntp-service reliable authentication-keyid 42
· Configuring NTP authentication in broadcast mode
The following configuration example uses Device A as the broadcast client and Device B as the broadcast server.
a. Configure Device A.
# Enable NTP authentication.
<DeviceA> system-view
[DeviceA] ntp-service authentication enable
# Create a plaintext NTP authentication key, specifying the key ID as 42 and key value as aNiceKey.
[DeviceA] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# Configure key 42 as a trusted key.
[DeviceA] ntp-service reliable authentication-keyid 42
b. Configure Device B.
# Enable NTP authentication.
<DeviceB> system-view
[DeviceB] ntp-service authentication enable
# Create a plaintext NTP authentication key, specifying the key ID as 42 and key value as aNiceKey.
[DeviceB] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# Configure key 42 as a trusted key.
[DeviceB] ntp-service reliable authentication-keyid 42
# Configure Device B to operate in NTP broadcast server mode and associate key 42 with the broadcast server.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] ntp-service broadcast-server authentication-keyid 42
· Configuring NTP authentication in multicast mode
The following configuration example uses Device A as the multicast client and Device B as the multicast server.
a. Configure Device A.
# Enable NTP authentication.
<DeviceA> system-view
[DeviceA] ntp-service authentication enable
# Create a plaintext NTP authentication key, specifying the key ID as 42 and key value as aNiceKey.
[DeviceA] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# Configure key 42 as a trusted key.
[DeviceA] ntp-service reliable authentication-keyid 42
b. Configure Device B.
# Enable NTP authentication.
<DeviceB> system-view
[DeviceB] ntp-service authentication enable
# Create a plaintext NTP authentication key, specifying the key ID as 42 and key value as aNiceKey.
[DeviceB] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# Configure key 42 as a trusted key.
[DeviceB] ntp-service reliable authentication-keyid 42
# Configure Device B to operate in multicast server mode and associate key 42 with the multicast server.
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] ntp-service multicast-server 224.0.1.1 authentication-keyid 42
Authenticating SNTP messages
Security threats
When the device uses SNTP for time synchronization, it might get time information from an unauthorized time server and synchronize to an incorrect time.
Hardening recommendations
To protect the device from an unauthorized time server, configure SNTP authentication. This feature authenticates SNTP messages for security purposes. The device receives an SNTP message and gets time synchronization information from it only when the message is authenticated. If the message fails authentication, the device discards the message. This function ensures that the device does not synchronize to an unauthorized time server.
Figure 4 SNTP authentication
As shown in Figure 3, SNTP authentication proceeds as follows:
1. The sender uses the key identified by the key ID to calculate a digest for the SNTP message through the specified algorithm. Then it sends the calculated digest together with the SNTP message and key ID to the receiver.
2. Upon receiving the message, the receiver performs the following actions:
a. Finds the key according to the key ID in the message.
b. Uses the key and the specified algorithm to calculate the digest for the message.
c. Compares the digest with the digest contained in the SNTP message.
- If they are different, the receiver discards the message.
- If they are the same, the receiver determines whether the sender is allowed to use the authentication ID on the local end. If the sender is allowed to use the authentication ID, the receiver accepts the message. If the sender is not allowed to use the authentication ID, the receiver discards the message
Restrictions and guidelines
On the SNTP client, associate the specified key with the NTP server. Make sure the server is allowed to use the key ID for authentication on the client.
With authentication disabled, the SNTP client can synchronize with the NTP server regardless of whether the NTP server is enabled with authentication.
Examples
The following configuration example uses Device A as the SNTP client and Device B as the NTP server.
1. Configure Device A.
# Enable SNTP authentication.
<DeviceA> system-view
[DeviceA] sntp-service authentication enable
# Create a plaintext NTP authentication key, specifying the key ID as 42 and key value as aNiceKey.
[DeviceA] sntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# Configure key 42 as a trusted key.
[DeviceA] sntp-service reliable authentication-keyid 42
# Specify the NTP server (Device B) and associate key 42 with the NTP server.
[DeviceA] sntp-service unicast-server 1.1.1.1 authentication-keyid 42
2. Configure Device B.
# Enable NTP authentication.
<DeviceB> system-view
[DeviceB] ntp-service authentication enable
# Create a plaintext NTP authentication key, specifying the key ID as 42 and key value as aNiceKey
[DeviceB] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# Configure key 42 as a trusted key.
[DeviceB] ntp-service reliable authentication-keyid 42
Hardening the data plane
Configuring storm suppression and storm control
Security threats
If the device receives broadcast, multicast, or unknown unicast traffic, it forwards the traffic to all interfaces except the receiving interface in the broadcast domain. This might cause broadcast storm, which degrades the forwarding performance of the device.
Hardening recommendations
Use storm suppression and storm control to monitor and control incoming broadcast, multicast, or unknown unicast traffic.
The storm suppression feature ensures that the size of a particular type of traffic (broadcast, multicast, or unknown unicast traffic) does not exceed the threshold on an interface. When the broadcast, multicast, or unknown unicast traffic on the interface exceeds this threshold, the system discards packets until the traffic drops below this threshold.
The storm control feature compares broadcast, multicast, and unknown unicast traffic regularly with their respective traffic thresholds. When a particular type of traffic exceeds its upper threshold on an interface, the device can block or shut down the interface and send logs or traps.
Restrictions and guidelines
For the traffic suppression result to be determined, do not configure storm control together with storm suppression for the same type of traffic.
Examples
# On GigabitEthernet 1/0/1, enable broadcast, multicast, and unknown unicast storm suppression, and set the suppression threshold for these types of traffic to 10000 kbps.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] broadcast-suppression kbps 10000
[Sysname-GigabitEthernet1/0/1] multicast-suppression kbps 10000
[Sysname-GigabitEthernet1/0/1] unicast-suppression kbps 10000
# On GigabitEthernet 1/0/1, configure storm control as follows:
· Enable broadcast, multicast, and unicast storm control, and set the upper and lower thresholds for each type of traffic to 2000 kbps and 1500 kbps, respectively.
· Configure GigabitEthernet 1/0/1 to block a specific type of traffic when the type of traffic exceeds the upper storm control threshold.
· Enable GigabitEthernet 1/0/1 to output log messages when it detects storm control threshold events.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] storm-constrain broadcast kbps 2000 1500
[Sysname-GigabitEthernet1/0/1] storm-constrain multicast kbps 2000 1500
[Sysname-GigabitEthernet1/0/1] storm-constrain unicast kbps 2000 1500
[Sysname-GigabitEthernet1/0/1] storm-constrain control block
[Sysname-GigabitEthernet1/0/1] storm-constrain enable log
MAC address security management
Configuring blackhole MAC address entries
Hardening recommendations
To block all frames destined for or sourced from a suspicious MAC address, configure the MAC address as a blackhole MAC address entry. The device drops all frames with a source or destination MAC address that matches a blackhole MAC address entry.
Examples
# Configure 000f-e201-0101 as a blackhole MAC address entry.
<Sysname> system-view
[Sysname] mac-address blackhole 000f-e201-0101 vlan 2
Disabling MAC address learning
Hardening recommendations
MAC address learning is enabled by default. To prevent the MAC address table from being saturated when the device is under attack, disable MAC address learning. For example, you can disable MAC address learning to prevent the device from being attacked by a large number of frames with different source MAC addresses.
Examples
# Disable global MAC address learning
<Sysname> system-view
[Sysname] undo mac-address mac-learning enable
# Disable MAC address learning on VLAN 10.
<Sysname> system-view
[Sysname] vlan 10
[Sysname-vlan10] undo mac-address mac-learning enable
# Disable MAC address learning on GigabitEthernet 1/0/1.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] undo mac-address mac-learning enable
# Disable MAC address learning on VSI vpn1.
<Sysname> system-view
[Sysname] vsi vpn1
[Sysname-vsi-vpn1] undo mac-learning enable
Controlling and monitoring MAC address learning
Security threats
Malicious attackers could launch a source MAC address spoofing attack by flooding packets to a valid unicast destination, each with a different MAC source address. The MAC address table of the device would be quickly saturated with these illegitimate addresses, resulting in degraded forwarding performance and increased floods.
Hardening recommendations
To protect the device and the network from source MAC address spoofing attacks, set the MAC learning limit on ports. When the number of learned MAC address entries reaches the limit on a port, the device stops learning MAC address entries.
In addition, you can configure the actions to take after the MAC learning limit is reached, including:
· Disable forwarding unknown frames after the MAC learning limit is reached. (Unknown frames refer to frames whose source MAC addresses are not in the MAC address table.)
· Enable the MAC learning alarm feature. This feature generates a log message when the number of MAC address entries reaches the maximum or drops below 90% of the maximum.
Examples
# Configure the device to learn a maximum of 600 MAC address entries on interface GigabitEthernet 1/0/1. Disable the device from forwarding unknown frames received on the interface after the MAC learning limit on the interface is reached.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] mac-address max-mac-count 600
[Sysname-GigabitEthernet1/0/1] undo mac-address max-mac-count enable-forwarding
Assigning MAC learning priority to interfaces
Security threats
The downlink port on a switch might learn the MAC address of a gateway attached to an uplink port for the following reasons:
· The downlink port is in a loop.
· An attacker initiates a MAC address spoofing attack by sending a frame to the downlink port, with the gateway MAC address as the source MAC address.
Hardening recommendations
To prevent incorrect MAC address learning, assign high MAC learning priority to an uplink port and assign low MAC learning priority to a downlink port. The device will allow a low priority port to learn a MAC address only if that MAC address has not been learned on a high priority port.
Examples
# Assign high MAC learning priority to GigabitEthernet 1/0/1.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] mac-address mac-learning priority high
Data flow protection
Configuring IPsec
IPsec provides interoperable, high-quality, cryptography-based security for IP communications. IPsec is a security framework that includes the following protocols:
· Authentication Header (AH).
· Encapsulating Security Payload (ESP).
· Internet Key Exchange (IKE).
· Internet Key Exchange Version 2 (IKEv2).
AH and ESP are security protocols that provide security services. IKE and IKEv2 implement automatic key exchange. For more information about IPsec, see Security Configuration Guide.
Configuring GRE security mechanisms
Security threats
The device might suffer unpredictable attacks when the device receives tampered GRE packets or GRE packets forged by illegal clients.
Hardening recommendations
GRE supports the GRE key and GRE checksum security mechanisms.
· GRE key—GRE keys ensure packet validity. The sender adds a GRE key into a packet. The receiver compares the GRE key with its own GRE key. If the two keys are the same, the receiver accepts the packet. If the two keys are different, the receiver drops the packet.
· GRE checksum—GRE checksums ensure packet integrity. The sender calculates a checksum for the GRE header and payload and sends the packet containing the checksum to the tunnel peer. The receiver calculates a checksum for the received packet and compares it with that carried in the packet. If the checksums are the same, the receiver considers the packet intact and continues to process the packet. If the checksums are different, the receiver discards the packet.
Examples
# Enable GRE checksum on GRE tunnel interface 2.
<Sysname> system-view
[Sysname] interface tunnel 2 mode gre
[Sysname-Tunnel2] gre checksum
# Configure the GRE key as @bd123 for GRE tunnel interface 2.
<Sysname> system-view
[Sysname] interface tunnel 2 mode gre
[Sysname-Tunnel2] gre key @bd123
Configuring IPsec to secure ADVPN packets
Security threats
Auto Discovery Virtual Private Network (ADVPN) enables enterprise branches that use dynamic public addresses to establish a VPN network. ADVPN uses the VPN Address Management (VAM) protocol to collect, maintain, and distribute dynamic public addresses.
By default, ADVPN does not protect packets transmitted within a dynamically established VPN network. These packets are vulnerable to attacks such as eavesdropping and tampering.
Hardening recommendations
Use IPsec profiles to secure data and control packets in ADVPN tunnels.
Examples
# Configure IPsec transform sets to specify the security protocols, authentication and encryption algorithms, and the encapsulation mode. For more information, see IPsec in Security Configuration Guide.
# Configure an IKE-mode IPsec profile that uses the IPsec transform sets.
# Apply the IPsec profile to ADVPN tunnel interface 1.
<Sysname> system-view
[Sysname] interface tunnel 1 mode advpn gre
[Sysname-Tunnel1] tunnel protection ipsec profile prf1
Packet filtering & Traffic filtering
Configuring security policies
A security policy defines a set of rules for forwarding control and Deep Packet Inspection (DPI). It matches packets against the rules and takes the action stated in the rules on the matched packets.
Security policies can provide the same 5-tuple filtering functions as packet filtering, and support precise network management of packets transmitted between specific security zones based on application, protocol, and user. By partnering with DPI, it can also provide security protection services such as intrusion protection, URL filtering, data filtering, file filtering, and antivirus.
For more information about security policies, see Security Configuration Guide.
An access control list (ACL) is a set of rules for identifying traffic. ACLs work with other modules, such as packet filtering, QoS, and routing. These modules use ACLs to identify traffic and enforce predefined polices on the identified traffic to control network access and improve bandwidth efficiency.
Table 6 shows different ACL types based on criteria.
|
Type |
ACL number |
IP version |
Match criteria |
|
Basic ACLs |
2000 to 2999 |
IPv4 |
Source IPv4 address. |
|
IPv6 |
Source IPv6 address. |
||
|
Advanced ACLs |
3000 to 3999 |
IPv4 |
Source IPv4 address, destination IPv4 address, packet priority, protocol number, and other Layer 3 and Layer 4 header fields. |
|
IPv6 |
Source IPv6 address, destination IPv6 address, packet priority, protocol number, and other Layer 3 and Layer 4 header fields. |
||
|
Layer 2 ACLs |
4000 to 4999 |
IPv4 and IPv6 |
Layer 2 header fields, such as source and destination MAC addresses, 802.1p priority, and link layer protocol type. |
|
User-defined ACLs |
5000 to 5999 |
IPv4 and IPv6 |
User specified matching patterns in protocol headers. |
For more information about ACLs, see ACL and QoS Configuration Guide.
ASPF
A packet-filter firewall permits only trusted traffic. For a device to receive the return traffic for its requests, a packet-filter firewall must permit both the request and return traffic. In this situation, a malicious user might send attack packets or illegal requests to the device.
Advanced Stateful Packet Filter (ASPF) addresses the issues that a packet-filter firewall cannot solve. At the border of a network, ASPF can work with a packet-filter firewall to provide the network with a more comprehensive security policy that better meets the actual needs. The packet-filter firewall permits or denies packets according to ACL rules. The ASPF records information about the permitted packets to ensure that their return packets can pass through the packet-filter firewall.
For more information about ASPF, see Security Configuration Guide.
Security threats
The device might be overloaded or become abnormal due to external attacks, which eventually render services unavailable. This feature protects the network against attack traffic by denying the attack traffic.
Hardening recommendations
Traffic filtering is implemented through a QoS policy. You can takes a traffic filtering action (permit or deny) on a traffic class by applying the QoS policy to an interface, globally, or VLANs. For example, you can deny packets sourced from an IP address according to network status.
Examples
# Create advanced ACL 3000, and configure a rule to match packets with source IP address 10.0.0.2.
<Device> system-view
[Device] acl advanced 3000
[Device-acl-ipv4-adv-3000] rule permit ip source 10.0.0.2 0
[Device-acl-ipv4-adv-3000] quit
# Create a traffic class named classifier_1, and use ACL 3000 as the match criterion in the traffic class.
[Device] traffic classifier classifier_1
[Device-classifier-classifier_1] if-match acl 3000
[Device-classifier-classifier_1] quit
# Create a traffic behavior named behavior_1, and configure the traffic filtering action to drop packets.
[Device] traffic behavior behavior_1
[Device-behavior-behavior_1] filter deny
[Device-behavior-behavior_1] quit
# Create a QoS policy named policy, and associate traffic class classifier_1 with traffic behavior behavior_1 in the QoS policy.
[Device] qos policy policy
[Device-qospolicy-policy] classifier classifier_1 behavior behavior_1
[Device-qospolicy-policy] quit
# Apply QoS policy policy to the incoming traffic of GigabitEthernet 1/0/1.
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] qos apply policy policy inbound
Configuring IP-MAC binding
The device prevents user spoofing attacks by using an IP-MAC binding table to filter out illegitimate packets with forged source IP addresses or MAC addresses.
The IP-MAC binding table contains binding entries that bind IP addresses and MAC addresses. The device uses the binding entries to match an incoming packet. Table 7 describes the way the device processes the packet based on the match result.
Table 7 Processing of a packet based on the match result
|
Match result |
Processing of the packet |
|
The packet source IP address and source MAC address match the same IP-MAC binding entry. |
Permits the packet. |
|
Only the source IP address or source MAC address matches a binding entry. |
Drops the packet. |
|
The source IP address and source MAC address match two different binding entries. |
Drops the packet. |
|
Both the source IP address and the source MAC address of a packet match no IP-MAC binding entry. |
Processes the packet based on the default action. By default, the device permits all packets that do not match any binding entries. You can use the ip-mac binding no-match action deny command to set the default action to deny. |
For more information about IP-MAC binding, see IP-MAC binding configuration in Security Configuration Guide.
uRPF
Attackers send packets with a forged source address to access a system that uses IPv4-based authentication, in the name of authorized users or even the administrator. Even if the attackers or other hosts cannot receive any response packets, the attacks are still disruptive to the attacked target.
Attackers can also send packets with different forged source addresses or attack multiple servers simultaneously to block connections or even break down the network.
To prevent these source address spoofing attacks, use uRPF. This feature checks whether an interface that receives a packet is the output interface of the FIB entry that matches the source address of the packet. If not, uRPF considers it a spoofing attack and discards the packet.
For more information about uRPF, see Security Configuration Guide.
Connection limits
A connection is an end-to-end flow identified by the quintuple (source IP address, source port number, destination IP address, destination port number, and protocol type). The connection limit feature enables the device to monitor and limit the number of established connections in the following situations:
· An external host initiates a large number of connections to an internal server and occupies server resources. The server cannot provide services for other users.
· An external host initiates a large number of connections to the device, which degrades in performance.
· An internal host initiates a large number of connections to an external server and occupies entry resources (for example, NAT entries) of the gateway device. Other internal hosts cannot communicate with the external network.
The device uses ACLs to define the connection range to limit. In addition, you can use source IP addresses, destination IP addresses, services, or any combination of them to further limit the connections. You can also limit the connection rate.
For more information about connection limits, see Security Configuration Guide.
Attack detection and defense
DoS attack detection and defense
The gateway device deployed on the public network and its downstream hosts and servers are vulnerable to DoS attacks. Victim devices cannot respond to user requests normally.
The device supports prevents the following DoS attacks:
· Single-packet attacks—ICMP redirect, ICMP destination unreachable, ICMP type, ICMPv6 type, Land, large ICMP packet, large ICMPv6 packet, IP options, IP option abnormal, IP fragment, IP impossible packet, tiny fragment, smurf, TCP flag, Traceroute, Winnuke, UDP bomb, UDP snork, UDP fraggle, Teardrop, ping of death, and IPv6 ext-header abnormal.
· Scanning attacks—IP sweep, port scan, and distributed port scan.
· Flooding attacks—SYN flood, ACK flood, SYN-ACK flood, FIN flood, RST flood, DNS flood, DNS reply flood, HTTP flood, SIP flood, ICMP flood, ICMPv6 flood, and UDP flood.
For more information about DoS attack detection and prevention, see Attack Detection and Prevention in Security Configuration Guide.
DDoS attack defense
Hosts or servers on the Internet can initiate distributed denial of service (DDoS) attacks to crash the target network temporarily or permanently. DDoS attacks have greater volume of attack traffic than traditional DoS attacks and the DDoS attack sources are more difficult to be discovered.
To protect the system against DDoS attacks, use DDoS attack defense. In the DDoS attack defense architecture, the detection and cleaner devices are responsible for detecting and cleaning attack traffic, respectively. By using the anti-DDoS zone based cleaning policy, the DDoS attack defense feature detects and filters out DDoS traffic at different tiers to effectively defend against various types of DDoS attacks.
For more information about DDoS attack defense, see Security Configuration Guide.
