Hardening H3C Access Controllers(V7)-6W100

HomeSupportResource CenterHardening H3C Access Controllers(V7)-6W100
Download Book
Table of Contents
Related Documents

 

Hardening H3C Access Controllers(V7)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

About this document 1

Audience· 1

Port numbering in examples· 1

Prerequisites· 1

Overview· 1

Security threats· 1

Threats to the management and control planes· 1

Threats to the data plane· 2

Security architecture· 3

Basic hardening principles· 4

Hardening the management plane· 4

Device access control 4

Securing console/USB access· 4

Securing Stelnet access· 6

Securing SNMP access· 7

Securing Web access· 9

Securing file access· 9

User management and access control 11

Using RBAC to control user access permissions· 11

Using AAA to secure user access and user management 11

Using command authorization to secure command access· 12

Password control 12

Hardening in password setting· 13

Device management 13

Disabling password recovery capability· 13

Configuring memory alarm thresholds· 13

Configuration encryption· 15

Security logs· 15

Hardening the control plane· 16

Layer 2 protocols· 16

Securing spanning tree networks· 16

ARP attack protection· 17

Enabling dynamic ARP entry check· 17

Preventing ARP flooding· 18

Preventing ARP spoofing attacks· 18

ND attack defense· 23

Source MAC consistency check· 23

Access services· 23

Securing PPP· 23

Securing PPPoE· 26

Securing L2TP· 28

Configuring 802.1X· 33

Configuring port security· 34

Hardening portal 35

DHCP security· 38

DHCP starvation attack protection· 38

DHCP user class whitelist 39

DHCP relay entry management on the DHCP relay agent 39

DHCP proxy on the DHCP relay agent 40

DHCP snooping· 40

DNS security· 41

ICMP security· 41

TCP security· 42

SYN Cookie· 42

Routing protocols· 42

Securing RIP/RIPng· 42

Multicast security· 43

Hardening IGMP snooping and MLD snooping· 43

Control plane packet rate limiting and packet-drop logging· 45

Protocol packet rate limiting· 45

WLAN access and management 46

Enabling CAPWAP tunnel encryption· 46

Configuring WLAN client access control 46

Configuring WLAN authentication to secure user access· 47

Configuring WLAN security· 49

WAPI 49

WIPS· 49

Managing user access rights for AC hierarchy networks· 50

Configuring WLAN DRS· 54

Configuring PMM·· 54

NTP access control 54

Configuring the NTP access right 54

Authenticating NTP messages· 55

Hardening the data plane· 60

Security isolation· 60

Configuring port isolation· 60

User isolation· 60

Suppressing storms and controlling storms· 61

Configuring storm suppression and storm control 61

Dropping unknown multicast data packets· 61

MAC address security management 62

Configuring blackhole MAC address entries· 62

Disabling MAC address learning· 63

Controlling and monitoring MAC address learning· 63

Assigning MAC learning priority to interfaces· 63

Enabling MAC move notifications and suppression· 64

Data flow protection· 64

Configuring IPsec· 64

Configuring GRE security mechanisms· 65

Packet filtering & Traffic filtering· 65

ACL· 65

Traffic filtering· 66

Configuring IP Source Guard· 67

ASPF· 67

Connection limits· 67

Attack detection and defense· 68

DoS attack detection and defense· 68

 


About this document

This document helps you improve the overall network security by hardening the Comware 7 ACs.

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 which might not apply to your devices.

Overview

The functions of Comware 7 network 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. If the management plane is breached,

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.

·          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.

·          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 IP source guard, 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.

Figure 1 Comware 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 attacks. These mechanisms handle packets destined for the local device as follows before delivering them from the hardware layer to the CPU:

¡  WhitelistIf 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 queuesIf a packet is not from a source in the whitelist, the hardware layer enques 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 provides a variety of security features, including:

¡  Malformed packet detection.

¡  Packet filtering.

¡  Anti-spoofing, for example IP source guard.

¡  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 provides security features including:

¡  QoS policy configurable to limit or filter traffic delivered to the control or management plane. For example, you can limit the rate of traffic sent to the control plane. You can also configure application security features to protect the control plane against 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/USB access

Security threats

The device provides the following physical interfaces: console and USB ports. By default, any user who can connect a terminal to one of the ports can log in to the device and manage the device.

By default, console login and USB login are both enabled. Console/USB login does not require authentication. The user role is network-admin for a console/USB user.

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. This authentication mode is not supported in FIPS mode.

·          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 or USB 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.

In FIPS mode, the device supports only scheme authentication. You cannot disable authentication or configure password authentication.

Examples

·          Secure console login:

# 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 User Access and Authentication Configuration Guide.

·          Secure USB login:

# Configure password authentication in USB line view.

<Sysname> system-view

[Sysname] line usb 0

[Sysname-line-usb0] authentication-mode password

# Specify a password.

[Sysname-line-usb0] set authentication password simple Plat&0631!

# Configure scheme authentication in USB line view.

<Sysname> system-view

[Sysname] line usb 0

[Sysname-line-usb0] authentication-mode scheme

# 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 User Access and Authentication 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:

a.    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.

b.    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 User Access and Authentication 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 User Access and Authentication 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 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.

[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 User Access and Authentication 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:

a.    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.

b.    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 User Access and Authentication 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 User Access and Authentication 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 User Access and Authentication 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 User Access and Authentication Configuration Guide. For information about super passwords, see RBAC in Fundamentals Configuration Guide. For more information about password control, see Security Configuration Guide.

Hardening in password setting

The device supports the following forms of passwords (or keys):

·          Plaintext formUsers enter their passwords in plaintext form, and the device stores the passwords in encrypted form or hashed form.

·          Encrypted formUsers enter their passwords in encrypted form, and the device stores the passwords in encrypted form.

·          Hashed formUsers enter their passwords in encrypted form, and the device stores the passwords in hashed form.

To improve the system security and maintainability, follow these guidelines to harden passwords:

·          Use long and complicated passwords instead of weak passwords.

·          Use a unique password for each service to prevent collateral threats to other services caused by the cracking of a service password.

·          For successful password setting, 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

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 for devices that do not support early warning

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

 

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 display commands to view the contents of an encrypted configuration file. However, you can use the display saved-configuration command to display the contents of the encrypted next-startup configuration file or use the display diff command to compare an encrypted configuration file with other configurations.

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

Layer 2 protocols

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 BPDU guard on an edge port.

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] stp port bpdu-protection enable

·          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 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.

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

Preventing ARP spoofing attacks

Security threats

An attacker may launch user spoofing attack or gateway spoofing attack.

·          User spoofing attackIf 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 attackIf 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.

Recording user IP address conflicts

Hardening recommendations

Use the recording user IP address conflicts to prevent user 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. For information about the log destination and output rule configuration in the information center, see the information center in System Management Configuration Guide.

Examples

# Enable recording user IP address conflicts.

<Sysname> system-view

[Sysname] arp user-ip-conflict record enable

Enabling ARP safe-guard

Security threats

If the device directly performs dynamic ARP learning upon receiving falsified ARP packets, the device learns incorrect ARP entries.

Hardening recommendations

When ARP safe-guard is enabled, the device operates as follows:

·          The device sends replies to all incoming ARP requests but do not generate corresponding ARP entries, which prevents gateway spoofing attacks.

·          The device generates ARP entries for incoming ARP replies that the device requests.

·          The device drops incoming ARP replies that are not requested by the device, which ensures that the device can learn correct ARP entries.

Examples

# Enable ARP safe-guard on GigabitEthernet 1/0/1.

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] arp safe-guard enable

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 Network Connectivity 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 checkThis 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.

¡  802.1X security entries.

¡  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 checkThis 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

Source MAC consistency check

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 System Management 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 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 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 User Access and Authentication 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

·          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 User Access and Authentication 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 User Access and Authentication 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 User Access and Authentication 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

[Sysname-Virtual-Template1] ppp authentication-mode ms-chap domain system

[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 User Access and Authentication 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

[Sysname-Virtual-Template1] ppp authentication-mode ms-chap domain system

[Sysname-Virtual-Template1] ppp authentication-mode ms-chap-v2 domain system

# Configure local or remote AAA authentication.

For more information about AAA authentication, see User Access and Authentication Configuration Guide.

Securing PPPoE

Enhancing management and control for PPPoE users

Security threats

The following security threats exist in a PPP network:

·          When a large number of users frequently come online and go offline, the device processing performance will be affected.

·          A single user establishes a large number of PPPoE sessions, which will occupy too many session resources and cause other users to fail to come online.

·          An illegal user might use the method of exhaustion to obtain the password.

Hardening recommendations

To avoid the security threats above, you can configure the following security features on the device to enhance management and control for PPPoE users:

·          Limiting the rate at which a user creates PPPoE sessions

This feature limits the rate at which a user (identified by MAC address) can create PPPoE sessions on an interface. If the number of PPPoE requests within the monitoring time exceeds the configured threshold, the device discards the excessive requests, and outputs log messages. If the blocking time is set to 0, the device does not block any requests, and it only outputs log messages.

·          Limiting the maximum number of PPPoE sessions

PPPoE can establish a session when none of the following limits are reached:

¡  Limit for a user on an interface.

¡  Limit for a VLAN on an interface.

¡  Limit on an interface.

¡  (Centralized IRF devices.) Limit on an IRF member device.

¡  (Centralized devices.) Limit on a device.

The maximum number of PPPoE sessions on a device or on a card is also limited by the device specification. If the configured number is larger than the device specification, the device specification applies. The device specification varies by device model.

·          PPPoE session count alarm thresholds

You can use this feature to set the upper alarm threshold and lower alarm threshold for the PPPoE session count. When the PPPoE session count exceeds the upper alarm threshold or drops below the lower threshold, an alarm is triggered automatically. Then, the administrator can promptly know the online user conditions of the network.

·          PPPoE user blocking

You can use this feature to prevent multiple PPPoE users from frequently coming online and going offline or prevent protocol packet attacks. After this feature is enabled, users who performs the following operations for the specified number of times within a period will be blocked:

¡  Come online.

¡  Go offline.

¡  Send PPPoE connection requests.

Packets from blocked users will be discarded during the blocking period, and will be processed after the blocking period expires.

Restrictions and guidelines

·          Maximum number of PPPoE sessions

PPPoE can establish a session when none of the limits are reached.

If the configured limit is smaller than the number of existing online sessions on the interface, the configuration succeeds. The configuration does not affect the existing online sessions. However, new sessions cannot be established on the interface.

The maximum number of PPPoE sessions supported by a device varies by license or device model.

(Centralized devices.)The maximum number of PPPoE sessions set for a device cannot be greater than the maximum number of PPPoE sessions supported by the device.

(Centralized IRF devices.) The total maximum number of PPPoE sessions set for all cards or IRF member devices cannot be greater than the maximum number of PPPoE sessions supported by the device.

Examples

·          Limiting the rate at which a user can create PPPoE sessions

# Limit the rate at which a user can create PPPoE sessions on GigabitEthernet 1/0/1.

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] pppoe-server throttle per-mac 100 80 10

·          Setting the maximum number of PPPoE sessions

¡  Set the maximum number of PPPoE sessions for a user on an interface

# Set the maximum number of PPPoE sessions for a user on GigabitEthernet 1/0/1 to 50.

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] pppoe-server session-limit per-mac 50

¡  Setting the maximum number of PPPoE sessions on a VLAN

# Set the maximum number of PPPoE sessions for a VLAN on GigabitEthernet 1/0/1.1 to 50.

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1.1

[Sysname-GigabitEthernet1/0/1.1] pppoe-server session-limit per-vlan 50

¡  Setting the maximum number of PPPoE sessions on an interface

# Set the maximum number of PPPoE sessions on GigabitEthernet 1/0/1 to 50.

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] pppoe-server session-limit 50

¡  Setting the maximum number of PPPoE sessions on a device

# (Centralized devices.) Set the maximum number of PPPoE sessions on a device to 3000.

<Sysname> system-view

[Sysname] pppoe-server session-limit total 3000

# (Centralized IRF devices.) Set the maximum number of PPPoE sessions on slot 2 to 3000.

[Sysname] pppoe-server session-limit slot 2 total 3000

# (Distributed devices in IRF mode.) Set the maximum number of PPPoE sessions on slot 2 of IRF member device 1 to 3000.

[Sysname] pppoe-server session-limit chassis 1 slot 2 total 3000

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 User Access and Authentication 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 PPP configuration in Network Connectivity Configuration Guide.

·          Configuring AAA on an LNS

For more information about configuring AAA authentication, see User Access and Authentication 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 PPP configuration in Network Connectivity Configuration Guide.

Configuring L2TP-based EAD

Hardening recommendations

To perform further security check for users that pass the L2TP authentication in some network environments that require high security, configure this feature and use the security policy server. Users that pass EAD authentication can access network resources. Users that fail EAD authentication can only access the resources in the quarantine areas.

Restrictions and guidelines

EAD authentication fails if no or incorrect ACLs or rules are configured on the authentication server even if EAD is enabled on the LNS.

The LNS can use different ACLs to filter packets from different clients.

As a best practice, use EAD authentication for clients on the Internet, and do not use this feature for clients on a LAN.

Examples

# Enable L2TP-based EAD.

<Sysname> system-view

[Sysname] interface virtual-template 10

[Sysname-Virtual-Template10] ppp access-control enable

# Configure portal.

For more information, see Security Configuration Guide.

# Configure AAA.

For more information about AAA authentication, see User Access and Authentication Configuration Guide.

# Configure the security policy server.

For more information, see CAMS EAD Security Policy Manager Help and IMC EAD Security Policy Manager Help.

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.

·          If multiple LACs are connected to one LNS, the LACs might send L2TP tunnel establishment requests at the same time. A large number of session establishment requests are also sent through each tunnel. In this situation, users cannot come online because the LNS fails to process request packets correctly.

·          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

Configuring 802.1X

802.1X quiet function

Security threats

The device authenticates clients that have failed 802.1X authentication immediately after they initiate a reauthentication. The device might be overwhelmed if it receives a large number of messages that contain incorrect authentication information (for example, incorrect username or password) in a short time.

Hardening recommendations

To protect the device against malicious 802.1X clients, enable the quiet timer. The quiet timer enables the device to wait a period of time before it processes any reauthentication request from a client that has failed 802.1X authentication.

Set the quiet timer depending on the network conditions.

·          In a vulnerable network, set the quiet timer to a high value.

·          In a high-performance network with quick authentication response, set the quiet timer to a low value.

Examples

# Enable the quiet timer and set the quiet timer to 100 seconds.

<Sysname> system-view

[Sysname] dot1x quiet-period

[Sysname] dot1x timer quiet-period 100

Online user handshake security

Security threats

Online 802.1X users can use illegal client software to bypass iNode security check, such as proxy detection and dual network interface cards (NICs) detection.

Hardening recommendations

Enable online user handshake security on a port to identify users that are using the iNode client to exchange handshake packets with the device. If a user fails the handshake security checking, the device sets the user to the offline state.

Restrictions and guidelines

To use the online user handshake security feature, you must enable the online user handshake feature.

The online user handshake security feature takes effect only on a network where the iNode client and IMC server are used.

Examples

# Enable online user handshake security on GigabitEthernet 1/0/1.

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] dot1x handshake

[Sysname-GigabitEthernet1/0/1] dot1x handshake secure

Configuring port security

Port security combines and extends 802.1X and MAC authentication to provide MAC-based network access control. Use port security on a port if its attached network contains both 802.1X and MAC authentication users.

Port security provides the following security features:

·          Need to know (NTK)This feature prevents traffic interception by checking the destination MAC address in the outbound frames. The feature ensures that frames are sent only to the following hosts:

¡  Hosts that have passed authentication.

¡  Hosts whose MAC addresses have been learned or configured on the device.

·          Intrusion protectionThis feature checks the source MAC address in inbound frames for illegal frames, and takes a predefined action on each detected illegal frame. The action can be disabling the port temporarily, disabling the port permanently, or blocking frames from the illegal MAC address for a period set by the MAC block timer.

A frame is illegal if its source MAC address cannot be learned in a port security mode or it is from a client that has failed authentication.

·          Port security modes—Port security supports the following categories of security modes:

¡  MAC learning control—Includes two modes: autoLearn and secure. MAC address learning is permitted on a port in autoLearn mode and disabled in secure mode.

¡  Authentication—Security modes in this category perform MAC authentication, 802.1X authentication, or a combination of these two authentication methods.

Upon receiving a frame, the port in a security mode searches the MAC address table for the source MAC address. If a match is found, the port forwards the frame. If no match is found, the port learns the MAC address or performs authentication, depending on the security mode. If the frame is illegal, the port takes the predefined NTK or intrusion protection action, or sends SNMP notifications. Outgoing frames are not restricted by port security's NTK action unless they trigger the NTK feature.

Table 2 describes how to use the port security modes in combination with the security features to fulfill your security purposes.

Table 2 Port security modes

Purpose

Security mode

Features that can be triggered

Turning off the port security feature

noRestrictions (the default mode)

In this mode, port security is disabled on the port and access to the port is not restricted.

N/A

Controlling MAC address learning

autoLearn

NTK/intrusion protection

secure

Performing 802.1X authentication

userLogin

N/A

userLoginSecure

NTK/intrusion protection

userLoginSecureExt

userLoginWithOUI

Performing MAC authentication

macAddressWithRadius

NTK/intrusion protection

Performing a combination of MAC authentication and 802.1X authentication

Or

macAddressOrUserLoginSecure

NTK/intrusion protection

macAddressOrUserLoginSecureExt

Else

macAddressElseUserLoginSecure

macAddressElseUserLoginSecureExt

 

For more information about port security, see User Access and Authentication Configuration Guide.

Hardening portal

Controlling portal user access

Security threats

On a portal network, the following security threats might exist:

·          If an attacker frequently initiates HTTP or HTTPS requests, the device needs to redirect a large number of HTTP or HTTPS requests, which causes resource insufficiency.

·          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-redirectThis 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.

·          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.

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

·          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

Enabling validity check on wireless clients

Hardening recommendations

In wireless networks where the AP forwards client traffic, the AC does not have ARP entries for clients. Therefore, the AC cannot use ARP entries to check the validity of portal clients. To ensure that valid users can perform portal authentication, you must enable wireless client validity check on the AC.

This feature enables the AC to validate a client by looking up the client information in the WLAN snooping table, DHCP snooping table, and ARP table. If the client information exists, the AC determines the client to be valid for portal authentication.

Examples

# Enable validity check on wireless clients.

<Sysname> system-view

[Sysname] portal host-check enable

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 or service templates 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

·          Limit the number of portal users on a service template:

¡  IPv4:

# Set the maximum number to 100 for IPv4 portal users on service template service1.

<Sysname> system-view

[Sysname] wlan service-template service1

[Sysname-wlan-st-service1] portal ipv4-max-user 100

¡  IPv6:

# Set the maximum number to 100 for IPv6 portal users on service template service1.

<Sysname> system-view

[Sysname] wlan service-template service1

[Sysname-wlan-st-service1] 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

DHCP security

DHCP starvation attack protection

Security threats

A DHCP starvation attack occurs when an attacker constantly sends forged DHCP requests using different MAC addresses in the chaddr field to a DHCP server. This exhausts the IP address resources of the DHCP server so legitimate DHCP clients cannot obtain IP addresses. The DHCP server might also fail to work because of exhaustion of system resources.

Hardening recommendations

To relieve a DHCP starvation attack that uses DHCP packets encapsulated with different source MAC addresses, set the MAC learning limit and disable unknown frame forwarding when the MAC learning limit is reached.

To prevent a DHCP starvation attack that uses DHCP requests encapsulated with the same source MAC address, enable MAC address check on the DHCP relay agent). This feature compares the chaddr field of a received DHCP request with the source MAC address in the frame header. If they are the same, the DHCP relay agent verifies this request as legal and processes it. If they are not the same, the device discards the DHCP request.

Examples

# Enable MAC address check on the DHCP relay agent.

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] dhcp relay check mac-address

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, authorized ARP, and IP source guard.

·          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

DHCP snooping

DHCP snooping is a security feature for DHCP.

DHCP snooping works between the DHCP client and server, or between the DHCP client and DHCP relay agent. It guarantees that DHCP clients obtain IP addresses from authorized DHCP servers. Also, it records IP-to-MAC bindings of DHCP clients (called DHCP snooping entries) for security purposes.

DHCP snooping defines trusted and untrusted ports to make sure clients obtain IP addresses only from authorized DHCP servers.

·          Trusted—A trusted port can forward DHCP messages correctly to make sure the clients get IP addresses from authorized DHCP servers.

·          Untrusted—An untrusted port discards received DHCP-ACK and DHCP-OFFER messages to prevent unauthorized servers from assigning IP addresses.

DHCP snooping reads DHCP-ACK messages received from trusted ports and DHCP-REQUEST messages to create DHCP snooping entries. A DHCP snooping entry includes the MAC and IP addresses of a client, the port that connects to the DHCP client, and the VLAN. DHCP snooping entries can be used by ARP detection and IP source guard. For more information about DHCP snooping and DHCPv6 snooping, see Network Connectivity Configuration Guide.

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

SYN Cookie

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

Multicast security

Hardening IGMP snooping and MLD snooping

Configuring a multicast group policy

Security threats

The device cannot provide multicast services to legal users when it has a large number of invalid multicast entries that are created based on IGMP or MLD reports from malicious users.

Hardening recommendations

To control the multicast groups that hosts can join, configure a multicast group policy on the Layer 2 device that is enabled with IGMP snooping or MLD snooping. When a host sends an IGMP or MLD report to request a multicast program, the Layer 2 device uses the multicast group policy to filter the report. The Layer 2 device adds the port of the host to the outgoing port list only if the report is permitted by the multicast group policy.

Examples

# Configure a multicast group policy for VLAN 2 so that hosts in VLAN 2 can join only multicast group 225.1.1.1.

<Sysname> system-view

[Sysname] acl basic 2000

[Sysname-acl-ipv4-basic-2000] rule permit source 225.1.1.1 0

[Sysname-acl-ipv4-basic-2000] quit

[Sysname] igmp-snooping

[Sysname-igmp-snooping] group-policy 2000 vlan 2

# Configure an IPv6 multicast group policy for VLAN 2 so that hosts in VLAN 2 can join only IPv6 multicast group FF03::101.

<Sysname> system-view

[Sysname] acl ipv6 basic 2000

[Sysname-acl-ipv6-basic-2000] rule permit source ff03::101 128

[Sysname-acl-ipv6-basic-2000] quit

[Sysname] mld-snooping

[Sysname-mld-snooping] group-policy 2000 vlan 2

# On GigabitEthernet 1/0/1, configure a multicast group policy for VLAN 2 so that hosts in VLAN 2 can join only multicast group 225.1.1.1.

<Sysname> system-view

[Sysname] acl basic 2000

[Sysname-acl-ipv4-basic-2000] rule permit source 225.1.1.1 0

[Sysname-acl-ipv4-basic-2000] quit

[Sysname] interface gigabitethernet1/0/1

[Sysname-GigabitEthernet1/0/1] igmp-snooping group-policy 2000 vlan 2

# On GigabitEthernet 1/0/1, configure an IPv6 multicast group policy for VLAN 2 so that hosts in VLAN 2 can join only IPv6 multicast group FF03::101.

<Sysname> system-view

[Sysname] acl ipv6 basic 2000

[Sysname-acl-ipv6-basic-2000] rule permit source ff03::101 128

[Sysname-acl-ipv6-basic-2000] quit

[Sysname] interface gigabitethernet1/0/1

[Sysname-GigabitEthernet1/0/1] mld-snooping group-policy 2000 vlan 2

Disabling a port from becoming a dynamic router port

Security threats

A receiver host might send IGMP general queries or PIM hello messages for testing purposes. On the Layer 2 device, the port that receives IGMP general queries or PIM hello messages becomes a dynamic router port. Before the aging timer for the port expires, the following problems might occur:

·          All multicast data for the VLAN to which the port belongs flows to the port. Then, the port forwards the data to attached receiver hosts. The receiver hosts will receive multicast data that they do not want to receive.

·          The port forwards the IGMP general queries or PIM hello messages to its upstream Layer 3 devices. These messages might affect the multicast routing protocol state (such as the IGMP querier or DR election) on the Layer 3 devices. This might further cause network interruption.

The same security threats also exist in an IPv6 multicast network.

Hardening recommendations

To resolve the issue, disable a port that receives IGMP/MLD general queries or IPv4/IPv6 PIM hello message from becoming a dynamic router port. The port will not become a dynamic router port even if it receives such messages. This feature improves network security and enhances the control over receiver hosts.

Examples

# Disable GigabitEthernet 1/0/1 from becoming a dynamic router port in VLAN 2.

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] igmp-snooping router-port-deny vlan 2

# Disable GigabitEthernet 1/0/1 from becoming a dynamic router port in VLAN 2.

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] mld-snooping router-port-deny vlan 2

Control plane packet rate limiting and packet-drop logging

Protocol packet rate limiting

Security threats

A device under attack will receive excessive packets of a specific protocol. In this case, the device CPU resources will be overwhelmed and are not available to valid requests.

Hardening recommendations

To prevent excessive protocol packets sent to the device CPU, use the protocol packet rate limiting feature. This feature rate limits the protocol packets that are sent to the CPU and drops packets that exceed the transmission rate. In addition to protocol packet rate limiting, you can also enable flow-based protocol packet rate limiting. This feature identifies user flows by source IP address or source MAC address, rate limits user flows, and records protocol packet statistics for you to determine whether abnormal traffic exists.

Restrictions and guidelines

You can configure both protocol-based and flow-based protocol packet rate limit for the same protocol. The device first performs flow-based protocol packet rate limit and then performs protocol-based packet rate limit.

To view the types of protocol packets that can be rate limited on the device, execute the display anti-attack protocol command in any view.

Examples

# (Centralized devices.) Enable packet rate limit.

<Sysname> system-view

[Sysname] anti-attack enable

# (Centralized IRF mode.) Enable packet rate limit on the specified slot.

[Sysname] anti-attack enable slot 1

# (Centralized devices.) Enable packet rate limit for ARP.

[Sysname] anti-attack protocol arp enable

# (Centralized IRF devices.) Enable packet rate limit for ARP on the specified slot.

[Sysname] anti-attack protocol arp enable slot 1

# (Centralized devices.) Set the maximum transmission rate to 1000 packets per second for ARP.

[Sysname] anti-attack protocol arp threshold 1000

# (Centralized IRF devices.) Set the maximum transmission rate to 1000 packets per second for ARP on the specified slot.

[Sysname] anti-attack protocol arp threshold 1000 slot 1

# (Centralized devices.) Enable flow-based packet rate limit for ARP and set the maximum transmission rate per flow to 50 packets per second.

[Sysname] anti-attack protocol arp flow-threshold 50

# (Centralized IRF devices.) Enable flow-based packet rate limit for ARP on the specified slot and set the maximum transmission rate per flow to 50 packets per second.

[Sysname] anti-attack protocol arp flow-threshold 50 slot 1

WLAN access and management

Enabling CAPWAP tunnel encryption

Security threats

Packets transmitted in unencrypted CAPWAP tunnels are prone to be attacked or intercepted.

Hardening recommendations

CAPWAP tunnel encryption uses the Datagram Transport Layer Security (DTLS) protocol to encrypt control and data packets transmitted over a CAPWAP tunnel.

When CAPWAP control tunnel encryption is enabled for an AP, the AC and the AP communicate as follows:

1.        The AC sends a discovery response with the encryption flag to the AC.

2.        The AP performs a DTLS handshake with the AC and then establishes a CAPWAP tunnel with the AC.

3.        The AC and the AP encrypt control packets transmitted in the CAPWAP control tunnel.

When CAPWAP data tunnel encryption is enabled for an AP, the AC and the AP communicate as follows:

1.        The AP exchanges encryption information including keys with the AC over the CAPWAP control tunnel upon receiving the first keepalive packet from the AC.

2.        The AC and the AP encrypt data packets transmitted in the CAPWAP data tunnel. Keepalive packets are not encrypted.

Examples

# Enable CAPWAP control tunnel encryption.

<Sysname> system-view

[Sysname] wlan ap ap1 model WA4320i-ACN

[Sysname-wlan-ap-ap1] tunnel encryption enable

This operation will restart the AP. Continue? [Y/N]

# Enable CAPWAP data tunnel encryption.

<Sysname> system-view

[Sysname] wlan ap ap1 model WA4320i-ACN

[Sysname-wlan-ap-ap1] data-tunnel encryption enable

This operation will restart the AP. Continue? [Y/N]

Configuring WLAN client access control

Security threats

Allowing rogue clients to access a WLAN might cause user information leakage and attacks on APs, such as flood attacks.

Hardening recommendations

You can configure whitelist-, blacklist-, or ACL-based access control to allow specific clients to access the WLAN.

Restrictions and guidelines

If the idle period before client reauthentication is configured, the system adds clients redirected from MAC authentication to Web authentication to the dynamic blacklist. This reduces authentication failures if the IP addresses assigned to the clients have not expired.

You can configure the dynamic blacklist to take effect on the AC or on APs. If the dynamic blacklist takes effect on the AC, all APs connected to the AC will reject clients in the dynamic blacklist. If the dynamic blacklist takes effect on APs, the AP that adds a client to the dynamic blacklist will reject the client, but the client can still associate with other APs connected to the AC.

An entry in the dynamic blacklist is removed when its aging timer expires.

As a best practice, configure the dynamic blacklist to take effect on the AC in high-density environments.

The configured aging timer takes effect only on entries newly added to the dynamic blacklist.

If the whitelist and blacklists are configured, only the whitelist takes effect.

Examples

·          Configure whitelist- and blacklist-based client access control:

# Add a MAC address to the whitelist.

<Sysname> system-view

[Sysname] wlan whitelist mac-address 001c-f0bf-9c92

# Add a MAC address to the static blacklist.

[Sysname] wlan static-blacklist mac-address 001c-f0bf-9c92

# Configure the dynamic blacklist to take effect on the AC.

[Sysname] undo wlan dynamic-blacklist active-on-ap

# Set the idle period before client reauthentication to 100 seconds.

[Sysname] wlan client reauthentication-period 100

# Set the aging time for dynamic blacklist entries to 3600 seconds.

[Sysname] wlan dynamic-blacklist lifetime 3600

·          Configure ACL-based client access control:

# Create Layer 2 ACL 4000, and create ACL rules to permit only MAC address 001e-35b2-000e and clients with OUI 000e-35.

<Sysname> system-view

[Syname] acl mac 4000

[Syname-acl-mac-4000] rule 0 permit source-mac 001e-35b2-000e ffff-ffff-ffff

[Syname-acl-mac-4000] rule 1 permit source-mac 000e-35b2-000f ffff-ff00-0000

[Syname-acl-mac-4000] rule 2 deny

[Syname-acl-mac-4000] quit

# Bind ACL 4000 to AP ap1.

[Sysname] wlan ap ap1 model WA4320i-ACN

[Sysname-wlan-ap-ap1] access-control acl 4000

# Bind ACL 4000 to service template service1.

[Sysname] wlan service-template service1

[Sysname-wlan-st-service1] access-control acl 4000

Configuring WLAN authentication to secure user access

WLAN authentication is a user-based access security mechanism. This mechanism performs MAC-based identity authentication on WLAN clients to ensure access security.

WLAN authentication includes the following authentication methods:

·          802.1X authentication—Uses Extensible Authentication Protocol (EAP) to transport authentication information for the client, the authenticator, and the authentication server.

 

 

NOTE:

The "client" in this section refers to a wireless endpoint unless otherwise stated.

 

·          MAC authentication—Controls network access by authenticating source MAC addresses. MAC authentication does not require installing authentication client software on wireless clients. The authenticator initiates a MAC authentication when it detects an unknown source MAC address without requiring the client to enter a username and password. If the MAC address passes authentication, the client can access authorized network resources. If the authentication fails, the authenticator marks the MAC address as a silent MAC address and prevents the client from accessing the network.

·          OUI authentication—Examines the OUIs in the MAC addresses of clients. A client passes OUI authentication if the client's OUI matches one of the OUIs configured on the authenticator.

 

 

NOTE:

An OUI is a 24-bit number that uniquely identifies a vendor, manufacturer, or organization. In MAC addresses, the first three octets are the OUI.

Table 3 shows the WLAN authentication modes.

Table 3 WLAN authentication modes

Authentication mode

Working mechanism

Whether intrusion protection can be triggered

bypass (the default)

Does not perform authentication.

A client can access the network without being authenticated.

No

dot1x

Performs 802.1X authentication only.

A client must pass 802.1X authentication before they can access the network.

Yes

mac

Performs MAC authentication only.

A client must pass MAC authentication before they can access the network.

Yes

mac-then-dot1x

Performs MAC authentication first, and then 802.1X authentication.

If a client passes MAC authentication, 802.1X authentication is not performed.

A client can access the network if it passes either MAC authentication or 802.1X authentication.

Yes

dot1x-then-mac

Performs 802.1X authentication first, and then MAC authentication.

If a client passes 802.1X authentication, MAC authentication is not performed.

A client can access the network if it passes either 802.1X authentication or MAC authentication.

Yes

oui-then-dot1x

Performs OUI authentication first, and then 802.1X authentication.

If a client passes OUI authentication, 802.1X authentication is not performed.

A client can access the network if it passes either OUI authentication or 802.1X authentication.

Yes

 

For more information about WLAN authentication for user access, see User Access and Authentication Configuration Guide.

Configuring WLAN security

Wireless networks are prone to attacks and packet snooping. WLAN security provides link layer authentication, data encryption, and client authentication to enhance security performance.

WLAN security mechanisms include Pre Robust Security Network Association (Pre-RSNA), 802.11i, and 802.11w.

Pre-RSNA defines the original security mechanism, which is vulnerable to security attacks. To enhance WLAN security, 802.11i was introduced, but it encrypts only WLAN data traffic. Based on the 802.11i framework, 802.11w offers management frame protection to prevent attacks such as forged de-authentication and disassociation frames.

·          The pre-RSNA mechanism uses the open system and shared key algorithms for authentication and uses WEP for data encryption.

·          The 802.11i mechanism (the RSNA mechanism) provides WPA and RSN security modes. WPA implements a subset of an 802.11i draft to provide enhanced security over WEP and RSN implements the full 802.11i.

·          802.11w management frame protection protects a set of robust management frames, such as de-authentication, disassociation, and some robust action frames.

For more information about WLAN security, see WLAN Security Configuration Guide.

WAPI

WLAN Authentication and Privacy Infrastructure (WAPI) is developed by the China Broadband Wireless Internet Protocol Standard Group based on 802.11 wireless protocols.

WAPI uses digital certificates and preshared keys (PSKs) to authenticate clients, and it protects the traffic between clients and AC through the USK negotiation and MSK advertisement mechanisms.

WAPI includes the following components:

·          WLAN Authentication Infrastructure—WAI provides identity authentication and key management for WLANs.

·          WLAN Privacy Infrastructure—WPI provides a security solution for data transmission in WLANs, including data encryption, data decryption, and anti-replay.

For more information about WAPI, see WAPI configuration in WLAN Configuration Guide.

WIPS

Rogue devices in a WLAN bring security vulnerabilities and might be exploited by attackers. To protect a WLAN, configure Wireless Intrusion Prevention System (WIPS) to monitor channels, detect behaviors and devices that bring security vulnerabilities, interrupt network services, and affect network performance. WIPS can also take countermeasures against rogue devices.

For more information about WIPS, see WIPS configuration in WLAN Security Configuration Guide.

Managing user access rights for AC hierarchy networks

Security threats

In an AC hierarchy network, network issues and severe security problems will arise if every administrator is able to view or configure devices in all branches and the headquarters.

Hardening recommendations

Access right management allows you to assign different rights to administrators by configuring location identifiers for service templates, AP groups, and RRM holddown groups.

An administrator can view and manage only service templates, AP groups, and RRM holddown groups whose location identifiers are accessible to his or her user role from the CLI or Web interface. The default location identifier default-location is accessible to all user roles.

Examples

1.        Configure the central AC:

# Enable the Telnet server and AAA authentication.

<CentralAC> system-view

[CentralAC] telnet server enable

[CentralAC] line vty 0 5

[CentralAC-line-vty0-5] authentication-mode scheme

[CentralAC-line-vty0-5] quit

# Create local AC localac-b, and specify the AC model and serial ID.

[CentralAC] wlan local-ac name localac-b model WX3520H

[CentralAC-wlan-local-ac-localac-b] serial-id 210235A1BSC123000050

[CentralAC-wlan-local-ac-localac-b] quit

# Create local AC localac-c, and specify the AC model and serial ID.

[CentralAC] wlan local-ac name localac-c model WX3520H

[CentralAC-wlan-local-ac-localac-c] serial-id 210235A1BSC123000051

[CentralAC-wlan-local-ac-localac-c] quit

# Create manual AP ap1, and specify the AP model and serial ID.

[CentralAC] wlan ap ap1 model WA4320i-ACN

[CentralAC-wlan-ap-ap1] serial-id 210235A29G007C000020

# Enable AC rediscovery.

[CentralAC-wlan-ap-ap1] control-address enable

[CentralAC-wlan-ap-ap1] quit

# Create manual AP ap2, and specify the AP model and serial ID.

[CentralAC] wlan ap ap1 model WA4320i-ACN

[CentralAC-wlan-ap-ap1] serial-id 210235A29G007C000022

# Enable AC rediscovery.

[CentralAC-wlan-ap-ap1] control-address enable

[CentralAC-wlan-ap-ap1] quit

# Create manual AP ap3, and specify the AP model and serial ID.

[CentralAC] wlan ap ap1 model WA4320i-ACN

[CentralAC-wlan-ap-ap1] serial-id 210235A29G007C000024

# Enable AC rediscovery.

[CentralAC-wlan-ap-ap1] control-address enable

[CentralAC-wlan-ap-ap1] quit

# Create manual AP ap4, and specify the AP model and serial ID.

[CentralAC] wlan ap ap1 model WA4320i-ACN

[CentralAC-wlan-ap-ap1] serial-id 210235A29G007C000026

# Enable AC rediscovery.

[CentralAC-wlan-ap-ap1] control-address enable

[CentralAC-wlan-ap-ap1] quit

# Create VLAN-interface 100 and assign an IP address to it.

[CentralAC] interface vlan-interface 100

[CentralAC-Vlan-interface100] ip address 10.0.0.1 24

[CentralAC-Vlan-interface100] quit

# Create location identifiers areab and areac.

[CentralAC] wlan location areab

[CentralAC] wlan location areac

# Create user role b.

[CentralAC] role name b

# Configure an XML element rule and a Web menu rule.

[CentralAC-role-b] rule 1 permit read write execute xml-element

[CentralAC-role-b] rule 2 permit read write execute web-menu

# Configure location identifier areab to be accessible to user role b.

[CentralAC-role-b] location policy deny

[CentralAC-role-b-locationpolicy] permit location areab

[CentralAC-role-b-locationpolicy] quit

[CentralAC-role-b] quit

# Create user role c.

[CentralAC] role name c

# Configure an XML element rule and a Web menu rule.

[CentralAC-role-c] rule 1 permit read write execute xml-element

[CentralAC-role-c] rule 2 permit read write execute web-menu

# Configure location identifier areac to be accessible to user role c.

[CentralAC-role-c] location policy deny

[CentralAC-role-c-locationpolicy] permit location areac

[CentralAC-role-c-locationpolicy] quit

[CentralAC-role-c] quit

# Add local user admin.

[CentralAC] local-user admin

# Authorize user admin to use HTTP and HTTPS services.

[CentralAC-luser-manage-admin] service-type http https

[CentralAC-luser-manage-admin] quit

# Add local user b-admin.

[CentralAC] local-user b-admin

# Authorize user b-admin to use HTTP and HTTPS services.

[CentralAC-luser-manage-b-admin] service-type http https

# Configure a password for the user.

[CentralAC-luser-manage-b-admin] password simple badmin

# Assign user role b to user b-admin as an authorized user role.

[CentralAC-luser-manage-b-admin] authorization-attribute user-role b

# Delete the default user role.

[CentralAC-luser-manage-b-admin] undo authorization-attribute user-role network-operator

[CentralAC-luser-manage-b-admin] quit

# Add local user c-admin.

[CentralAC] local-user c-admin

# Authorize user c-admin to use HTTP and HTTPS services.

[CentralAC-luser-manage-c-admin] service-type http https

# Configure a password for the user.

[CentralAC-luser-manage-c-admin] password simple cadmin

# Assign user role c to user c-admin.

[CentralAC-luser-manage-c-admin] authorization-attribute user-role c

# Delete the default user role.

[CentralAC-luser-manage-c-admin] undo authorization-attribute user-role network-operator

[CentralAC-luser-manage-c-admin] quit

# Create AP group groupb, and add AP 1 and AP 2 to the AP group.

[CentralAC] wlan ap-group groupb

[CentralAC-wlan-ap-group-groupb] ap ap1 ap2

# Specify location identifier areab for the AP group.

[CentralAC-wlan-ap-group-groupb] location areab

[CentralAC-wlan-ap-group-groupb] quit

# Create AP group groupc, and add AP 3 and AP 4 to the AP group.

[CentralAC] wlan ap-group groupc

[CentralAC-wlan-ap-group-groupc] ap ap3 ap4

# Specify location identifier areac for the AP group.

[CentralAC-wlan-ap-group-groupc] location areac

[CentralAC-wlan-ap-group-groupc] quit

2.        Configure local AC B:

# Create VLAN-interface 100, and assign an IP address to it.

<LocalAC-B> system-view

[LocalAC-B] interface vlan-interface 100

[LocalAC-B-Vlan-interface100] ip address 10.0.0.2 24

[LocalAC-B-Vlan-interface100] quit

# Enable local AC.

[LocalAC-B] wlan local-ac enable

# Specify a central AC for the local AC.

[LocalAC-B] wlan central-ac ip 10.0.0.1

3.        Configure local AC C:

# Create VLAN-interface 100, and assign an IP address to it.

<LocalAC-C> system-view

[LocalAC-C] interface vlan-interface 100

[LocalAC-C-Vlan-interface100] ip address 10.0.0.3 24

[LocalAC-C-Vlan-interface100] quit

# Enable local AC.

[LocalAC-C] wlan local-ac enable

# Specify a central AC for the local AC.

[LocalAC-C] wlan central-ac ip 10.0.0.1

To verify the configuration from the Web interface:

# Use super username admin to log in to the central AC from the Web interface. (Details not shown.)

# Verify that you can view and manage all APs.

Figure 3 Super user page view

admin-en.png

 

# Use local username b-admin to log in to the central AC from the Web interface.

# Verify that you can view and manage only APs in area B.

Figure 4 User b-admin page view

badmin-en.png

 

# Use local username c-admin to log in to the central AC from the Web interface.

# Verify that you can view and manage only APs in area C.

Figure 5 User c-admin page view

cadmin-en.png

 

Configuring WLAN DRS

DPI report statistics (DRS) classifies and stores user application and URL session information detected by DPI and sends the information to the Oasis server as configured. This allows users to monitor user applications and URL sessions from the Oasis platform, preventing malicious applications and URLs from attacking the WLAN.

For more information about WLAN DRS, see WLAN Security Configuration Guide.

Configuring PMM

Packet monitor management (PMM) enables the device to perform the following tasks:

1.        Capture packets from the uplink interface.

2.        Decode the packets and encapsulate them in the required format.

3.        Send the packets to the designated server for audit.

The supported audit servers include exands, SURFILTER, and xwtone servers.

For more information about PMM, see WLAN Security Configuration Guide.

NTP 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 Security 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.

Figure 6 NTP authentication

 

As shown in Figure 6, 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 4, Table 5, Table 6, and Table 7. (N/A in the table means that whether the configuration is performed or not does not make any difference.)

Table 4 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 5 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 6 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 7 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

Hardening the data plane

Security isolation

Configuring port isolation

Security threats

If one of the hosts connected to interfaces of a device has security threats and is attacked, the host might send a large number of unicast, multicast, or broadcast packets and even spread the virus to other hosts in the same VLAN. This will affect other hosts and occupy network bandwidth.

Hardening recommendations

To avoid this security threat, configure port isolation. Port isolation allows you to add interfaces to an isolation group. Interfaces in the same isolation group cannot communicate with each other at Layer 2. Therefore, the attack against an interface is limited to the scope of the interface, and the network security is improved.

For more information about port isolation, see Network Connectivity Configuration Guide.

User isolation

The user isolation feature isolates packets for users that use the same SSID or for users that are in the same VLAN. This feature improves user security, relieves the forwarding stress of the device, and reduces consumption of radio resources.

User isolation includes the following types:

·          SSID-based user isolation—Isolates wireless users that use the same SSID.

·          VLAN-based user isolation—Isolates wired or wireless users in the same VLAN.

For more information about user isolation, see WLAN Traffic Optimization Configuration Guide.

Suppressing storms and controlling storms

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 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.

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

Dropping unknown multicast data packets

Security threats

Unknown multicast data refers to multicast data for which no forwarding entries exist in the IGMP snooping or MLD snooping forwarding table. If the device receives unknown multicast data, it floods the data in the VLAN or VSI to which the data belongs. This might causes broadcast storm, which degrades the forwarding performance of the device.

Hardening recommendations

To avoid broadcast storm caused by flooding unknown multicast data packets, enable the dropping unknown multicast data packets feature. This feature enables the device to forward unknown multicast data only to the router port. If the device does not have a router port, unknown multicast data will be dropped.

Examples

# Enable dropping unknown IPv4 multicast data packets globally.

<Sysname> system-view

[Sysname] igmp-snooping

[Sysname-igmp-snooping] drop-unknown

# Enable dropping unknown IPv6 multicast data packets globally.

<Sysname> system-view

[Sysname] mld-snooping

[Sysname-mld-snooping] drop-unknown

# In VLAN 2, enable IGMP snooping and dropping unknown multicast data packets.

<Sysname> system-view

[Sysname] igmp-snooping

[Sysname-igmp-snooping] quit

[Sysname] vlan 2

[Sysname-vlan2] igmp-snooping enable

[Sysname-vlan2] igmp-snooping drop-unknown

# In VLAN 2, enable MLD snooping and dropping unknown IPv6 multicast data packets.

<Sysname> system-view

[Sysname] mld-snooping

[Sysname-mld-snooping] quit

[Sysname] vlan 2

[Sysname-vlan2] mld-snooping enable

[Sysname-vlan2] mld-snooping drop-unknown

# In VSI aaa, enable IGMP snooping and dropping unknown IPv4 multicast data packets.

<Sysname> system-view

[Sysname] igmp-snooping

[Sysname-igmp-snooping] quit

[Sysname] vsi aaa

[Sysname-vsi-aaa] igmp-snooping enable

[Sysname-vsi-aaa] igmp-snooping drop-unknown

# In VSI aaa, enable MLD snooping and dropping unknown IPv6 multicast data packets.

<Sysname> system-view

[Sysname] mld-snooping

[Sysname-mld-snooping] quit

[Sysname] vsi aaa

[Sysname-vsi-aaa] mld-snooping enable

[Sysname-vsi-aaa] mld-snooping drop-unknown

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 GigabitEthernet 1/0/1.

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] undo mac-address 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

Enabling MAC move notifications and suppression

Security threats

MAC move occurs when one port receives a frame with a source MAC address that has been learned on another port in the same VLAN. In this situation, the device updates the outgoing port in the MAC address entry.

Frequent MAC address moves occur if a Layer 2 loop or MAC address spoofing attack is present.

Hardening recommendations

To protect the device against Layer 2 loops and MAC address spoofing attacks:

·          Enable MAC move notification to report the MAC move events to the information center module. The information center will output the events as log or SNMP notification messages depending on your configuration.

·          Configure MAC address move suppression to shut down a port for a period if frequent MAC moves are detected on it. The port will automatically go up after the suppression interval expires. Alternatively, you can manually bring up the port.

Examples

# Enable MAC move notifications.

<Sysname> system-view

[Sysname] mac-address notification mac-move

# Enable MAC move suppression on GigabitEthernet 1/0/1.

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] mac-address notification mac-move suppression

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 User Access and Authentication 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

Packet filtering & Traffic filtering

ACL

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 8 shows different ACL types based on criteria.

Table 8 ACL types

Type

ACL number

IP version

Match criteria

WLAN client ACL

100 to 199

IPv4 and IPv6

SSID.

WLAN AP ACL

200 to 299

IPv4 and IPv6

AP MAC address and AP serial ID.

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 Security Configuration Guide.

Traffic filtering

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 Source Guard

IP source guard (IPSG) prevents spoofing attacks by using WLAN snooping entries to filter packets received by an AP. It drops packets that do not match the entries.

WLAN snooping is enabled by default on the AP. A WLAN snooping entry is an IP-MAC binding.

·          In an IPv4 network, WLAN snooping reads the clients' IP-MAC bindings from the ARP messages or DHCP packets that pass through the AP. IPSG uses only the WLAN snooping entries obtained through DHCP packets.

·          In an IPv6 network, WLAN snooping reads the clients' IP-MAC bindings from packets that pass through the AP. The packets are RA messages, NS messages, NA messages, and DHCP packets. IPSG uses all WLAN snooping entries for packet filtering.

For more information about IPSG, see IPSG configuration in Security 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.

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 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 attacksIP sweep, port scan, and distributed port scan.

·          Flooding attacks—SYN flood, ACK flood, SYN-ACK flood, FIN flood, RST flood, DNS flood, HTTP flood, ICMP flood, ICMPv6 flood, and UDP flood.

For more information about DoS attack detection and prevention, see attack detection and prevention configuration in Security Configuration Guide.