HP Load Balancing Module

Transcription

1 HP Load Balancing Module Security Configuration Guide Part number: Document version: 6PW

2 Legal and notice information Copyright 2012 Hewlett-Packard Development Company, L.P. No part of this documentation may be reproduced or transmitted in any form or by any means without prior written consent of Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this material. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

3 Contents Zone configuration 1 Configuring a zone 2 Configuration task list 2 Creating a zone 2 Configuring a zone member 3 Zone configuration example 4 Virtual fragment reassembly 9 Virtual fragment reassembly overview 9 Configuring virtual fragment reassembly 9 Virtual fragment reassembly configuration example 10 Configuration guidelines 12 Blacklist configuration 13 Overview 13 Configuring the blacklist 13 Configuration task list 13 Enabling the blacklist function 14 Adding a blacklist entry manually 14 Viewing the blacklist 15 Blacklist configuration example 15 Packet inspection configuration 18 Overview 18 Configuring packet inspection 19 Packet inspection configuration example 20 Traffic abnormality detection configuration 22 Overview 22 Flood detection 22 Connection limit 23 Scanning detection 23 Configuring traffic abnormality detection 23 Configuring ICMP flood detection 23 Configuring UDP flood detection 25 Configuring SYN flood detection 26 Configuring connection limit 28 Configuring scanning detection 29 Traffic abnormality detection configuration example 30 Intrusion detection statistics 35 Overview 35 Displaying intrusion detection statistics 35 TCP proxy configuration 38 Overview 38 Introduction to SYN flood attack 38 Introduction to TCP proxy 38 How TCP proxy works 39 Configuring TCP proxy 40 Configuration task list 40 Performing global TCP proxy setting 41 i

4 Enabling TCP proxy for a security zone 41 Adding a protected IP address entry 42 Displaying information about protected IP address entries 42 TCP proxy configuration example 43 Configuration guidelines 45 ACL configuration 46 ACL overview 46 ACL categories 46 ACL numbering and naming 46 Match order 46 ACL rule comments 47 ACL rule numbering 47 Fragments filtering with ACLs 48 ACL acceleration 48 Configuring an ACL in the web 48 Configuration task list 48 Configuring a time range 49 Creating an ACL 50 Configuring a basic ACL rule 51 Configuring an advance ACL rule 52 Configuring an Ethernet frame header ACL rule 55 Configuring ACL acceleration 56 ACL configuration example 56 Configuring an ACL at the CLI 60 ACL configuration task list 60 Configuring an ACL 61 Configuring a time range 61 Configuring an IPv4 basic ACL 61 Configuring an IPv4 advanced ACL 62 Configuring an Ethernet frame header ACL 63 Copying an IPv4 ACL 64 Enabling ACL acceleration for an IPv4 ACL 64 Displaying and maintaining ACLs 64 ACL configuration examples 65 PKI configuration 67 PKI overview 67 Introduction to PKI 67 PKI terms 67 Architecture of PKI 68 Applications of PKI 69 Operation of PKI 69 Configuring PKI in the web interface 69 Configuration task list 69 Creating a PKI entity 72 Creating a PKI domain 73 Generating an RSA key pair 76 Destroying the RSA key pair 77 Retrieving and displaying a certificate 77 Requesting a local certificate 78 Retrieving and displaying a crl 79 PKI configuration examples 80 Configuring PKI in the CLI 89 PKI configuration task list 89 ii

5 Configuring an entity DN 89 Configuring a PKI domain 91 Submitting a PKI certificate request 92 Submitting a certificate request in manual mode 93 Retrieving a certificate manually 94 Configuring PKI certificate verification 94 Destroying a local RSA key pair 95 Deleting a certificate 96 Configuring an access control policy 96 Displaying and maintaining PKI 96 PKI configuration examples 97 Troubleshooting PKI 107 Failed to retrieve a CA certificate 107 Failed to request a Local certificate 108 Failed to retrieve CRLs 108 Configuration guidelines 109 Public key configuration 110 Overview 110 Public key configuration task list 111 Configuring a local asymmetric key pair on the local device 111 Creating a local asymmetric key pair 111 Displaying or exporting the local host public key 112 Destroying a local asymmetric key pair 113 Specifying the peer public key on the local device 113 Displaying and maintaining public keys 114 Public key configuration examples 114 Manually specifying the peer public key on the local device 114 Importing a public key from a public key file 116 SSL configuration 119 SSL overview 119 SSL security mechanism 119 SSL protocol stack 120 SSL configuration task list 120 Configuring an SSL server policy 121 Configuration prerequisites 121 Configuration procedure 121 SSL server policy configuration example 122 Configuring an SSL client policy 124 Configuration prerequisites 124 Configuration procedure 124 Displaying and maintaining SSL 125 Troubleshooting SSL 125 AAA configuration 126 AAA overview 126 RADIUS 127 Client/server model 127 Security and authentication mechanisms 127 Basic RADIUS message exchange process 128 RADIUS packet format 129 Extended RADIUS attributes 131 Domain-based user management 132 Protocols and standards 133 AAA configuration considerations and task list 133 iii

6 AAA configuration task list 134 RADIUS configuration task list 134 Configuring AAA 135 Configuration prerequisites 135 Creating an ISP domain 135 Configuring ISP domain attributes 135 Configuring AAA authentication methods for an ISP domain 136 Configuring AAA authorization methods for an ISP domain 138 Configuring AAA accounting methods for an ISP domain 139 Configuring local user attributes 140 Configuring user group attributes 143 Tearing down user connections 144 Configuring a NAS ID-VLAN binding 144 Displaying and maintaining AAA 144 Configuring RADIUS 145 Creating a RADIUS scheme 145 Specifying the RADIUS authentication/authorization servers 145 Specifying the RADIUS accounting servers and relevant parameters 146 Setting the shared key for RADIUS packets 147 Setting the maximum number of RADIUS request transmission attempts 147 Setting the supported RADIUS server type 148 Setting the status of RADIUS servers 148 Configuring the username format and traffic statistics units 149 Enabling the RADIUS trap function 150 Specifying the source IP address for outgoing RADIUS packets 150 Setting timers for controlling communication with RADIUS servers 151 Configuring RADIUS accounting-on 152 Specifying a security policy server 153 Enabling the listening port of the RADIUS client 153 Configuring interpretation of RADIUS class attribute as CAR parameters 153 Displaying and maintaining RADIUS 154 AAA configuration examples 154 AAA for Telnet/SSH users by a RADIUS server 154 AAA for FTP/Telnet users by the LB module itself 158 Level switching authentication for Telnet users by a RADIUS server 160 Troubleshooting AAA 164 Troubleshooting RADIUS 164 RADIUS attributes 166 Commonly used standard RADIUS attributes 166 Proprietary RADIUS sub-attributes of HP 167 Session management 169 Session management overview 169 Session management principle 169 Session management implementation 169 Session management configuration task list 170 Setting session aging times based on protocol state 170 Configuring session aging times based on application layer protocol type 171 Enabling checksum verification 171 Specifying the persistent session ACL 171 Clearing sessions manually 172 Configuring session logging 172 Configuring session log export 172 Displaying and maintaining session management 173 iv

7 Connection limit configuration 174 Connection limit overview 174 Connection limit configuration task list 174 Creating a connection limit policy 174 Configuring the connection limit policy 174 Configuring an IP address-based connection limit rule 175 Applying the connection limit policy 175 Displaying and maintaining connection limiting 175 Connection limit configuration example 176 Troubleshooting connection limiting 177 Connection limit rules with overlapping segments 177 Connection limit rules with overlapping protocol types 177 Web filtering configuration 179 Introduction to web filtering 179 URL address filtering 179 IP address-supported URL address filtering 179 URL Parameter Filtering 180 Java Blocking 180 ActiveX Blocking 181 Configuring web filtering 181 Configuring URL address filtering 181 Configuring IP address-supported URL address filtering 182 Configuring URL parameter filtering 182 Configuring Java blocking 182 Configuring ActiveX blocking 183 Displaying and maintaining web filtering 183 Web filtering configuration examples 184 URL address filtering configuration example 184 URL parameter filtering configuration example 185 Java blocking configuration example 186 Troubleshooting web filtering 187 Failed to add filtering entry or suffix keyword due to upper limit 187 Invalid characters are present in the configured parameter 188 Invalid use of wildcard 188 Invalid blocking suffix 189 ACL configuration failed 189 Unable to access the HTTP server by IP address 190 RSH configuration 191 RSH overview 191 Configuring RSH 191 Configuration prerequisites 191 Configuration procedure 191 RSH configuration example 192 Support and other resources 195 Contacting HP 195 Subscription service 195 Related information 195 Documents 195 Websites 195 Conventions 196 v

8 Index 198 vi

9 Zone configuration NOTE: The term firewall in this document refers to network devices that support load balancing. The LB module supports configuring zones only in the web interface. Traditional firewall/router policies are configured based on packet inbound and outbound interfaces on early dual-homed firewalls. With the development of firewalls, they can not only connect the internal and external network, but also connect the internal network, external network, and the Demilitarized Zone (DMZ). Also, they are providing high-density ports. A high-end firewall can provide dozens of physical interfaces to connect multiple logical subnets. In this networking environment, traditional interface-based policy configuration mode requires configuration of security policies for each interface, which brings great working loads for administrators, and thus increases probability for introducing security problems because of configurations. The industry-leading firewalls solve the above problems by configuring security policies based on zones. A zone is an abstract conception, and you can classify zones in two ways: Interface-based. A zone can include physical interfaces and logical interfaces, and also Trunk interface + VLAN. Interfaces added to the same zone have consistent security needs in security policy control. IP-address-based. You can classify zones based on IP addresses to control security policies according to the source IP address or destination IP address of service packets. NOTE: DMZ is originally a military term, which refers to the boundary between two or more military powers, where military activity is not permitted. A DMZ in a network is an area separated with the internal and external networks both logically and physically. Typically, a DMZ contains devices accessible to the Internet, such as Web servers and FTP servers. If a service packet can match a zone either based on interface or on IP address, the zone matched based on the interface is adopted. With the zone concept, security administrators can classify interfaces or IP addresses (assign them to different zones) based on their security needs, thus implementing hierarchical policy management. For example, the administrator can add the four interfaces on a firewall that connect to different subnets in the research area to Zone_RND, and the two interfaces connecting the servers to Zone_DMZ, as shown in the following figure. In this way, the administrator only needs to deploy the security policies between the two zones. If the network changes in the future, the administrator only needs to adjust the interfaces in a certain zone, without modifying the security policies. Therefore, with the concepts of zone, not only the policy maintenance is simplified, but also network services and security services are separated. 1

10 Figure 1 Zone classification Configuring a zone Configuration task list Perform the tasks in Table 1 to configure a zone. Table 1 Zone configuration task list Task Creating a zone Configuring a zone member Remarks By default, the following zones are available on the device: Management, Local, Trust, DMZ and Untrust. Required Add specified subnet address source, interfaces, Layer 2 Ethernet interface + VLAN to the created zone. Creating a zone Select Security > Zone from the navigation tree to enter the page as shown in Figure 2. Click Add to enter the page for creating a zone, as shown in Figure 3. 2

11 Figure 2 Zone Figure 3 Create a zone Table 2 Configuration items for creating a zone Item Zone ID Zone Name Preference Description Set the zone ID. Set the zone name. Set the preference of a zone. By default, packets from a high priority zone to a low priority zone are allowed to pass. Return to Zone configuration task list. Configuring a zone member Select Security > Zone from the navigation tree to enter the page as shown in Figure 2. Click the corresponding to the zone to be modified to enter the Modify Zone page, as shown in Figure 4. icon 3

12 Figure 4 Modify zone Table 3 Configuration items for modifying a zone Item Zone ID Zone Name Preference Description Displays the zone ID. Displays the zone name. Set the preference of the specified zone By default, packets from a high priority zone to a low priority zone are allowed to pass. Interface Interface VLAN Set the interfaces to be added to the zone. The interfaces that have been added to a zone are in the selected status, and the interfaces that can be added but have not been added to a zone are in the non-selected status. If the interfaces added to the zone are Layer 2 Ethernet interfaces, you must specify the range of the VLANs to be added to the zone. The VLANs cannot belong to any other zone. Return to Zone configuration task list. Zone configuration example Network requirements A company provides WWW and FTP services to the external network. You need to perform some basic configurations for the zones to prepare for the configurations of the security policies. 4

13 The internal network is a trust network and can access the server and the external network. You can deploy the internal network in the Trust zone with a higher priority and connect interface Ten-GigabitEthernet 0/0.1 on the LB card to the external network. The external network is an untrusted network, and you need to use strict security rules to control access from the external network to the internal network and the server. You can deploy the external network in the Untrust zone with a lower priority and connect interface Ten-GigabitEthernet 0/0.2 on the LB card to the external network. If you deploy the WWW server and the FTP server on the external network, security cannot be ensured; if you deploy them on the internal network, the external illegal users may use the security holes to attack the internal network. Therefore, you can deploy the servers in the DMZ zone with a priority between Trust and Untrust, and connect Ethernet interface Ten-GigabitEthernet 0/0.3 on the LB card to the servers. In this way, the server in the DMZ zone can access the external network in the Untrust zone with a lower priority, but when it accesses the internal network in the Trust zone with a higher priority, its access is controlled by the security rules. Figure 5 Network diagram for configuring zones Configuration procedure By default, the system has created the Trust, DMZ and Untrust zones, and you only need to deploy them. # Configure the Trust zone, and add interface Ten-GigabitEthernet 0/0.1 to the Trust zone. Select Security > Zone from the navigation tree and click the icon of the Trust zone to perform the following configurations, as shown in Figure 6. 5

14 Figure 6 Configure the Trust zone Select the Ten-GigabitEthernet0/0.1 option. Click Apply. # Configure the DMZ zone, and add interface Ten-GigabitEthernet 0/0.3 to the DMZ zone. Click Back to return to the page for displaying zones to perform the following configurations, as shown in Figure 7. 6

15 Figure 7 Configure the DMZ zone Click the icon of the DMZ zone. Select the Ten-GigabitEthernet0/0.3 option. Click Apply. # Configure the Untrust zone and add interface Ten-GigabitEthernet 0/0.2 to the Untrust zone. Click Back to return to the page for displaying zones. Click the icon of the Untrust zone to perform the following configurations, as shown in Figure 8. 7

16 Figure 8 Configure the Untrust zone Select the Ten-GigabitEthernet0/0.2 option. Click Apply. 8

17 Virtual fragment reassembly NOTE: The LB modules support virtual fragment reassembly in the web interface only. Virtual fragment reassembly overview To prevent service modules (such as NAT) from processing packet fragments that arrive out of order, you can enable the virtual fragment reassembly feature. This feature can virtually reassemble the fragments of a datagram through fragment checking, sequencing and caching so as to ensure that fragments arrive at service modules in order. The virtual fragment reassembly feature can also detect the following types of fragment attacks, and discard the attack fragments for security. Tiny fragment attack: If the first fragment of a datagram is very small and the transport layer protocol (such as TCP and UDP) header is in the second fragment, a tiny fragment attack is considered. Overlapping fragment attack: If two consecutive incoming fragments are identical or overlapping, an overlapping fragment attack is considered. Fragment-flood attack: If the maximum number of fragments per datagram or the maximum number of fragment queues on the device is reached, a fragment-flood attack is considered. Configuring virtual fragment reassembly Select Security > Virtual Reassembly from the navigation tree to enter the virtual fragment reassembly configuration page, as shown in Figure 9. Figure 9 Virtual fragment reassembly configuration page 9

18 Table 4 Virtual fragment reassembly configuration items Item Security Zone Enable Virtual Fragment Reassembly Specify max number of concurrent reassemblies Specify max number of fragments per reassembly Specify timeout value of the datagram being reassembled Drop all the incoming fragments Description Specify a security zone to be configured with virtual fragment reassembly. Select the check box to enable the virtual fragment reassembly feature. Specify the maximum number of concurrent reassemblies. When this value is reached, the LB module discards all subsequent packets and sends a syslog message. This option is available after the virtual fragment reassembly feature is enabled. Specify the maximum number of fragments in each reassembly. When this value is reached, the LB module discards all subsequent fragments of the reassembly and sends a syslog. This option is available after the virtual fragment reassembly feature is enabled. Set the aging time for each reassembly. If the fragments of a datagram (in a reassembly) are not reassembled within this time, all the fragments of the datagram are discarded. This option is available after the virtual fragment reassembly feature is enabled. Select the check box to discard all incoming fragments. This option is available after the virtual fragment reassembly feature is enabled. Virtual fragment reassembly configuration example Network requirements As shown in Figure 10, Host accesses Router through the LB module and NAT is enabled on interface Ten-GigabitEthernet 0/0.2 of the LB module. It is required to enable virtual fragment reassembly for security zone Trust on the LB module to ensure secure and efficient NAT. Figure 10 Network diagram for virtual fragment reassembly configuration Configuration procedure 1. Configure Host # On Host, configure a static route to Router. (Omitted) 2. Configure the LB module. # Configure IP addresses for the interfaces and assign the interfaces to security zones. (Omitted) # Configure a static address mapping. 10

19 Select Security > NAT from the navigation tree, and in the right pane select the Static NAT tab. Then click Add in the Static Address Mapping area to enter the page shown in Figure 11. Figure 11 Add a static address mapping Type for Internal IP Address. Type for Global IP Address. Click Apply. # Enable static NAT on Ten-GigabitEthernet 0/0.2. In the Interface Static Translation area of the Static NAT tab, click Add to enter the page shown in Figure 12. Figure 12 Enable static NAT on an interface Select interface Ten-GigabitEthernet 0/0.2. Click Apply. # Configure virtual fragment reassembly. Select Security > Virtual Reassembly from the navigation tree to enter the page shown in Figure

20 Figure 13 Configure virtual reassembly Select Trust for Security Zone. Select Enable Virtual Fragment Reassembly. Click Apply. After the configuration, if receiving disordered fragments from security zone Trust, the LB module will check and reassemble them. Configuration guidelines The virtual fragment reassembly feature only applies to packets incoming to a security zone. The virtual fragment reassembly feature does not support load sharing. The fragments of an IP datagram cannot arrive through different security zones. 12

21 Blacklist configuration NOTE: The LB module supports configuring the blacklist function only in the web interface. Overview Blacklist is an attack prevention mechanism that filters packets based on source IP address. Compared with ACL-based packet filtering, the blacklist feature is easier to configure and fast in filtering packets sourced from particular IP addresses. The LB module can dynamically add and remove blacklist entries. This is implemented in cooperation with the scanning detection feature. When the module detects that packets sourced from an IP address have a behavior pattern that implies a potential scanning attack, it automatically blacklists the IP address to filter subsequent packets sourced from that IP address. Blacklist entries added in this way will age out after a period of time. The module also supports adding and removing blacklist entries manually. Manually configured blacklist entries fall into two categories: permanent and non-permanent. A permanent blacklist entry is always present unless being removed manually, while a non-permanent blacklist entry has a limited lifetime depending on your configuration. When the lifetime of a non-permanent entry expires, the module removes the entry from the blacklist, allowing the packets of the IP address defined by the entry to pass through. Configuring the blacklist Configuration task list Perform the tasks in Table 5 to configure the blacklist feature. Table 5 Blacklist configuration task list Task Enabling the blacklist function Configuring the Scanning Detection Feature to Add Blacklist Entries Automatically Adding a blacklist entry manually Remarks Required By default, the blacklist function is disabled. Required Complete either of the task For more information about scanning detection configuration, see Traffic abnormality detection configuration. By default, no blacklist entries exist. TIP: If you modify a dynamic blacklist entry, the entry will turn into a manual one. 13

22 Task Viewing the blacklist Remarks Enabling the blacklist function Select Security > Intrusion Detection from the navigation tree and then select the Blacklist tab to enter the blacklist management page, as shown in Figure 14. Then, select the Enable Blacklist option and click Apply to enable the blacklist feature. Figure 14 Blacklist management page Return to Blacklist configuration task list. Adding a blacklist entry manually Select Security > Intrusion Detection from the navigation tree and then select the Blacklist tab to enter the blacklist management page. Click Add to enter the blacklist entry configuration page, as shown in Figure 15. Figure 15 Add a blacklist entry manually Table 6 lists the blacklist entry configuration items. Table 6 Blacklist entry configuration items Item IP Address Hold Time Permanence Description Specify the IP address to be blacklisted. Configure the entry to be a non-permanent one and specify a lifetime for it. Configure the entry to be a permanent one. 14

23 Return to Blacklist configuration task list. Viewing the blacklist Select Security > Intrusion Detection from the navigation tree and then select the Blacklist tab to enter the blacklist management page, where you can view the blacklist information, as shown in Figure 14. Table 7 describes the blacklist fields. Table 7 Blacklist fields Item IP Address Description Blacklisted IP address Type of the blacklist entry, which can be: Auto: Added by the scanning detection feature automatically. Add Method Manual: Added manually or modified manually. TIP: Once modified manually, an auto entry becomes a manual one. Start Time Hold Time Dropped Count Time when the blacklist entry is added. Lifetime of the blacklist entry Number of packets dropped based on the blacklist entry Return to Blacklist configuration task list. Blacklist configuration example Network requirements As shown in Figure 16, the internal network is the trusted zone and the external network is the untrusted zone. Configure the LB module so that the module: Blocks packets from Host D forever. (It is assumed that Host D is an attack source.) Blocks packets from Host C within 50 minutes, so as to control access of the host. Performs scanning detection for traffic from the untrusted zone and, upon detecting a scanning attack, blacklists the source. The scanning threshold is 4500 connections per second. Figure 16 Network diagram for blacklist configuration 15

24 Configuration procedure # Assign IP addresses to the interfaces. (Omitted) # Enable the blacklist feature. Select Security > Intrusion Detection from the navigation tree and then select the Blacklist tab to enter the blacklist management page. Perform configuration as shown in Figure 17. Figure 17 Enable the blacklist feature In the Global Configuration area, select the Enable Blacklist option. Click Apply. # Add a blacklist entry for Host D. In the Blacklist Configuration area, click Add and then perform configurations as shown in Figure 18. Figure 18 Add a blacklist entry for Host D Enter IP address Select the Permanence option. Click Apply to complete the configuration. # Add a blacklist entry for Host C. In the Blacklist Configuration area, click Add and then perform configurations as shown in Figure

25 Figure 19 Add a blacklist entry for Host C Enter IP address Select the Hold Time option and, in the box next to the option, set the lifetime of the entry to 50 minutes. Click Apply to complete the configuration. # Configure scanning detection for the untrusted zone. Select Security > Intrusion Detection from the navigation tree and then select the Scanning Detection tab. Perform the configurations shown in Figure 20. Figure 20 Configure scanning detection for the untrusted zone Select security zone Untrust. Select the Enable Scanning Detection option. Set the scanning threshold to Select the Add the source IP to the blacklist option. Click Apply to complete the configuration. Configuration verification After completing the configurations, check that: The manually added blacklist entries appear on the blacklist. You can select Security > Intrusion Detection from the navigation tree and then select the Blacklist tab to display the list. The module discards all packets from Host D before you remove the blacklist entry for the host. The module discards all packets from Host C within 50 minutes. After 50 minutes, the module forwards packets from Host C normally. Upon detecting a scanning attack from the untrusted zone, the module outputs an alarm log and adds the IP address to the blacklist. You can select Security > Intrusion Detection from the navigation tree and then select the Blacklist tab to check the blacklist for the entry. 17

26 Packet inspection configuration NOTE: The LB module supports configuring packet inspection only in the web interface. Overview A single-packet attack is also called a malformed packet attack. A single-packet attack occurs when: An attacker sends defective IP packets, such as overlapping IP fragments and packets with illegal TCP flags, to a target system, making the target system malfunction or crash when processing such packets. An attacker sends large quantities of junk packets to the network, using up the network bandwidth. With packet inspection configured, a LB module analyzes the characteristics of received packets to determine whether the packets are attack packets. Upon detecting an attack, the module logs the event and, when configured, discards the attack packets. The LB module supports detection of the following types of single packet attacks. Table 8 Types of single packet attacks supported by the LB module Attack type Fraggle Land WinNuke TCP Flag ICMP unreachable ICMP redirect Description A Fraggle attack occurs when an attacker sends large amounts of UDP echo requests with the UDP port number being 7 or Chargen packets with the UDP port number being 19, resulting in a large quantity of junk replies and finally exhausting the bandwidth of the target network. A Land attack occurs when an attacker sends a great number of TCP SYN packets with both the source and destination IP addresses being the IP address of the target, exhausting the half-open resources of the victim and thereby making the target unable to provide services normally. A WinNuke attacker sends out-of-band (OOB) data with the pointer field values overlapped to the NetBIOS port (139) of a Windows system with an established connection to introduce a NetBIOS fragment overlap, causing the system to crash. Some TCP flags are processed differently on different operating systems. A TCP flag attacker sends TCP packets with such TCP flags to a target to probe its operating system. If the operating system cannot process such packets properly, the attacker will successfully make the host crash down. Upon receiving an ICMP unreachable response, some systems conclude that the destination is unreachable and drop all subsequent packets destined for the destination. By sending ICMP unreachable packets, an ICMP unreachable attacker can cut off the connection between the target host and the network. An ICMP redirect attacker sends ICMP redirect messages to a target to modify its routing table, interfering with the normal forwarding of IP packets. 18

27 Attack type Tracert Smurf Source route Route record Large ICMP Description The Tracert program usually sends UDP packets with a large destination port number and an increasing TTL (starting from 1). The TTL of a packet is decreased by 1 when the packet passes each router. Upon receiving a packet with a TTL of 0, a router must send an ICMP time exceeded message back to the source IP address of the packet. A Tracert attacker exploits the Tracert program to figure out the network topology. A Smurf attacker sends large quantities of ICMP echo requests to the broadcast address of the target network. As a result, all hosts on the target network will reply to the requests, causing the network congested and hosts on the target network unable to provide services. A source route attack exploits the source route option in the IP header to probe the topology of a network. A route record attack exploits the route record option in the IP header to probe the topology of a network. For some hosts and network devices, large ICMP packets will cause memory allocation error and thus crash down the protocol stack. A large ICMP attacker sends large ICMP packets to a target to make it crash down. Configuring packet inspection Select Security > Intrusion Detection from the navigation tree and then select the Packet Inspection tab to enter the packet inspection page, as shown in Figure 21. Figure 21 Packet inspection configuration page Table 9 lists the items of packet inspection configuration items. Table 9 Packet inspection configuration items Item Zone Discard Packets when the specified attack is detected Description Select a zone to detect attacks from the zone. Select this option to discard detected attack packets. 19

28 Item Enable Fraggle Attack Detection Enable Land Attack Detection Enable WinNuke Attack Detection Enable TCP Flag Attack Detection Enable ICMP Unreachable Packet Attack Detection Enable ICMP Redirect Packet Attack Detection Enable Tracert Packet Attack Detection Enable Smurf Attack Detection Enable IP Packet Carrying Source Route Attack Detection Enable Route Record Option Attack Detection Enable Large ICMP Packet Attack Detection Max Packet Length Description Enable or disable detection of Fraggle attacks. Enable or disable detection of Land attacks. Enable or disable detection of WinNuke attacks. Enable or disable detection of TCP flag attacks. Enable or disable detection of ICMP unreachable attacks. Enable or disable detection of ICMP redirect attacks. Enable or disable detection of Tracert attacks. Enable or disable detection of Smurf attacks. Enable or disable detection of source route attacks. Enable or disable detection of route record attacks. Enable detection of large ICMP attacks and set the packet length limit, or disable detection of such attacks. Packet inspection configuration example Network requirements As shown in Figure 22, the internal network is the trusted zone and the external network is the untrusted zone. Configure the LB module to protect the trusted zone against Land attacks and Smurf attacks from the untrusted zone. Figure 22 Network diagram for packet inspection configuration Configuration procedure # Assign IP addresses to interfaces. (Omitted) # Enable Land attack detection and Smurf attack detection for the untrusted zone. Select Security > Intrusion Detection from the navigation tree and then select the Packet Inspection tab to enter the packet inspection configuration page. Then, perform the configurations shown in Figure

29 Figure 23 Enable Land and Smurf attack detection for the untrusted zone 1. Select Untrust from the Zone dropdown list. 2. Select Discard Packets when the specified attack is detected. 3. Select Enable Land Attack Detection. 4. Select Enable Smurf Attack Detection. 5. Click Apply to complete the configuration. Configuration verification Check that the module can detect Land and Smurf attacks from the untrusted zone, output alarm logs accordingly, and drop the attack packets. Select Security > Intrusion Detection from the navigation tree and then select the Statistics tab to view the counts of Land and Smurf attacks and the counts of dropped attack packets. 21

30 Traffic abnormality detection configuration NOTE: The LB module supports configuring traffic abnormality detection only in the web interface. Overview The traffic abnormality detection feature analyzes the characteristics of traffic to detect abnormal traffic and take countermeasures accordingly. Supported countermeasures include outputting alarm logs, dropping packets, and blacklisting the source of the packets. Flood detection A flood attack occurs when large amounts of fake packets are sent to a target system in a short period of time. A flood attack depletes the resources of the target system, making the system unable to provide services normally. The LB module can protect these types of flood attacks: ICMP flood attack: An ICMP flood attack overwhelms the target with large amounts of ICMP echo requests, such as ping packets. UDP flood attack: A UDP flood attack floods the target system with a barrage of UDP packets. SYN flood attack: A SYN flood attack exploits TCP SYN packets. Due to resource limitation, the number of TCP connections that can be created on a module is limited. A SYN flood attacker sends a barrage of spurious SYN packets with forged source IP addresses to a victim to initiate TCP connections. As the SYN_ACK packets that the victim sends in response can never get acknowledgments, large amounts of half-open connections are created and retained on the victim, making the victim inaccessible before the number of half-open connections drops to a reasonable level due to timeout of half-open connections. In this way, a SYN flood attack exhausts system resources such as memory on a system whose implementation does not limit creation of connections. Flood detection is mainly used to protect servers against flood attacks. It detects flood attacks by tracking the connection rates at which certain types of connection establishment requests are initiated to a server and the number of half-open connections on the server (the latter is for SYN flood detection only). Usually, flood detection is deployed on the module for an internal security zone and takes effect for packets entering the security zone when an attack prevention policy is configured for the security zone. If the module detects that a tracked parameter has reached or exceeded the threshold, it outputs an attack alarm log and, depending on your configuration, blocks the subsequent packets from the suspects to the server. When used to protect a specified object, an attack prevention policy supports IP address based attack protection configuration. If no specific protection object is specified, the global settings will be used for protection. 22

31 Connection limit When an internal user initiates a large number of connections to a host on the external network in a short period of time, system resources on the module will be used up soon. This will make the module unable to service other users. In addition, if an internal server receives large quantities of connection requests in a short period of time, the server will not be able to process normal connection requests from other hosts. To protect internal network resources (including hosts and servers) and distribute resources of the module reasonably, you can set connection limits based on source or destination IP addresses for security zones. When a limit based on source or destination IP address is reached or exceeded, the module will output an alarm log and discard subsequent connection requests from or to the IP address. Scanning detection A scanning attack probes the addresses and ports on a network to identify the hosts attached to the network and application ports available on the hosts and to figure out the topology of the network, so as to get ready for further attacks. Scanning detection detects scanning attempts by tracking the rates at which connections are initiated to protected systems. Usually, it is deployed on the module for the external security zone and takes effect for packets from the security zone. If detecting that a connection rate of an IP address has reached or exceeded the threshold, the module outputs an attack alarm log, blocks the subsequent connection requests from the IP address, and blacklists the IP address, depending on your configuration. Configuring traffic abnormality detection Configuring traffic abnormality detection involves the following: Configuring ICMP flood detection Configuring UDP flood detection Configuring SYN flood detection Configuring connection limit Configuring scanning detection Configuring ICMP flood detection NOTE: ICMP flood detection is mainly intended to protect servers and is usually configured for an internal zone. Select Security > Intrusion Detection from the navigation tree and then select the ICMP Flood tab to enter the ICMP flood detection configuration page, as shown in Figure 24. You can select a security zone and then view and configure ICMP flood detection rules for the security zone. 23

32 Figure 24 ICMP flood detection configuration page Do the following to configure ICMP flood detection: 1. In the Attack Prevention Policy area, specify the protection action to be taken upon detection of an ICMP flood attack. If you do not select the Discard packets when the specified attack is detected option, the module only collects ICMP flood attack statistics. 2. In the ICMP Flood Configuration area, view the configured ICMP flood detection rules, or click Add to enter the page shown in Figure 25 to configure an ICMP flood detection rule. Figure 25 Add an ICMP flood detection rule Table 10 describes the configuration items. Table 10 ICMP flood detection configuration items Item Protected Host Configuration Global Configuration of Security Zone IP Address Connection Rate Threshold Connection Rate Threshold Description Specify the IP address of the protected host. Set the maximum ICMP connection rate for the IP address. Set the global maximum ICMP connection rate for each host in the current security zone. 24

33 NOTE: In a security zone, you can configure multiple protected hosts and one global connection rate threshold. For a host, the host-specific setting overrides the global setting of the security zone in case conflict occurs. Configuring UDP flood detection NOTE: UDP flood detection is mainly intended to protect servers and is usually configured for an internal zone. Select Security > Intrusion Detection from the navigation tree and then select the UDP Flood tab to enter the UDP flood detection configuration page, as shown in Figure 26. You can select a security zone and then view and configure UDP flood detection rules for the security zone. Figure 26 UDP flood detection configuration page Do the following to configure UDP flood detection: 1. In the Attack Prevention Policy area, specify the protection action to be taken upon detection of a UDP flood attack. If you do not select the Discard packets when the specified attack is detected option, the module only collects UDP flood attack statistics. 2. In the UDP Flood Configuration area, view the configured UDP flood detection rules, or click Add to enter the page shown in Figure 27 to configure a UDP flood detection rule. 25

34 Figure 27 Add a UDP flood detection rule Table 11 describes the configuration items. Table 11 UDP flood detection configuration items Item Protected Host Configuration Global Configuration of Security Zone IP Address Connection Rate Threshold Connection Rate Threshold Description Specify the IP address of the protected host. Set the maximum UDP connection rate for the IP address. Set the global maximum UDP connection rate for each host in the current security zone. NOTE: In a security zone, you can configure multiple protected hosts and one global connection rate threshold. For a host, the host-specific setting overrides the global setting of the security zone in case conflict occurs. Configuring SYN flood detection NOTE: SYN flood detection is mainly intended to protect servers and is usually configured for an internal zone. Select Security > Intrusion Detection from the navigation tree and then select the SYN Flood tab to enter the SYN flood detection configuration page, as shown in Figure 28. You can select a security zone and then view and configure SYN flood detection rules for the security zone. 26

35 Figure 28 SYN flood detection configuration page Do the following to configure SYN flood detection: 1. In the Attack Prevention Policy area, specify the protection actions to be taken upon detection of a SYN flood attack. If you do not select any option, the module only collects SYN flood attack statistics. The available protection actions include: a. Discard packets when the specified attack is detected. If detecting that a protected object in the security zone is under SYN flood attack, the module drops the TCP connection requests to the protected host to block subsequent TCP connections. b. Add protected IP entry to TCP Proxy: If detecting that a protected object in the security zone is under SYN flood attack, the module adds the target IP address to the protected IP list on the TCP proxy as a dynamic one, setting the port number as any. If TCP proxy is configured for the security zone, all TCP connection requests to the IP address will be processes by the TCP proxy until the protected IP entry gets aged out. Note that if you select this option, you are recommended to configure the TCP proxy feature on the page you can enter by selecting the TCP Proxy Configuration tab. 2. In the SYN Flood Configuration area, view the configured SYN flood detection rules, or click Add to enter the page shown in Figure 29 to configure a SYN flood detection rule. 27

36 Figure 29 Add a SYN flood detection rule Table 12 describes the configuration items. Table 12 SYN flood detection configuration items Item Protected Host Configuration Global Configuration of Security Zone IP Address Connection Rate Threshold Half Connection Count Connection Rate Threshold Half Connection Count Description Specify the IP address of the protected host. Set the maximum TCP connection rate for the IP address. Set the maximum number of the half-open TCP connections that can be present for the IP address. Set the global maximum TCP connection rate for each host in the current security zone. Set the global maximum number of half-open TCP connections that can be present for each host in the current security zone. NOTE: In a security zone, you can configure multiple protected hosts and one global connection rate threshold. For a host, the host-specific setting overrides the global setting of the security zone in case conflict occurs. Configuring connection limit Select Security > Intrusion Detection from the navigation tree and then select the Connection Limit tab to enter the connection limit configuration page, as shown in Figure 30. You can select a security zone and then view and configure the connection limit for the security zone. 28

37 Figure 30 Connection limit configuration page Table 13 describes the connection limit configuration items. Table 13 Connection limit configuration items Item Security Zone Discard packets when the specified attack is detected Enable connection limit per source IP Threshold Enable connection limit per dest IP Threshold Description Select a security zone to perform connection limit configuration for it. Select this option to discard subsequent packets destined for or sourced from an IP address when the number of the connections for that IP address has exceeded the limit. Select the option to set the maximum number of connections that can be present for a source IP address. Select the option to set the maximum number of connections that can be present for a destination IP address. Configuring scanning detection NOTE: Scanning detection is intended to detect scanning behaviors and is usually configured for an external zone. Scanning detection can be configured to add blacklist entries automatically. If you remove such a blacklist entry, the system will not add the entry back to the blacklist during a period of time. This is because the system considers that the subsequent packets are from the same attack. Select Security > Intrusion Detection from the navigation tree and then select the Scanning Detection tab to enter the scanning detection configuration page, as shown in Figure 31. You can select a security zone and then view and configure the scanning detection rule for the security zone. Figure 31 Scanning detection configuration page Table 14 lists the scanning detection configuration items. 29

38 Table 14 Scanning detection configuration items Item Security Zone Enable Scanning Detection Scanning Threshold Add a source IP to the blacklist Lifetime Description Select a security zone to perform scanning detection configuration for it. Select this option to enable scanning detection for the security zone. Set the maximum connection rate for a source IP address. Select this option to allow the system to blacklist a suspicious source IP address. If this option is selected, you can then set the lifetime of the blacklisted source IP addresses. TIP: Only when the blacklist feature is enabled, can the scanning detection function blacklist a suspect and discard subsequent packets from the suspect. Set the lifetime of the blacklist entry. Traffic abnormality detection configuration example Network requirements As shown in Figure 32, the internal network is the trusted zone, the subnet where the internal servers are located is the demilitarized zone (DMZ), and the external network is the untrusted zone. Configure the LB module so that the module: Protects the internal network against scanning attacks from the external network. Limits the number of connections initiated by an internal host. Limits the number of connections to the internal server. Protects the internal server against SYN flood attacks from the external network. To meet these requirements, you need to perform these configurations on the module: Configure scanning detection for the untrusted zone, enable the function to add entries to the blacklist, and set the scanning threshold to 4500 connections per second. Configure source IP address-based connection limit for the trusted zone, and set the number of connections each host can initiate to 100. Configure destination IP address-based connection limit for the DMZ, and set the number of connections the server can accommodate to Configure SYN flood detection for the DMZ, and set the connection rate of the server to 5000 connections per second (which value is proper depends on the performance of the server). And configure the module to block subsequent connections to the server after an attack is detected. 30

39 Figure 32 Network diagram for traffic abnormality detection configuration Configuration procedure # Assign IP addresses to interfaces. (Omitted) # Enable the blacklist feature. Select Security > Intrusion Detection from the navigation tree and then select the Blacklist tab and perform the configuration shown in Figure 33. Figure 33 Enable the blacklist feature In the Global Configuration area, select the Enable Blacklist option. Click Apply. # Configure scanning detection for the untrusted zone. Select Security > Intrusion Detection from the navigation tree and then select the Scanning Detection tab to enter the scanning detection configuration page and perform configurations shown in Figure 34. Figure 34 Configure scanning detection for the untrusted zone 31

40 Select zone Untrust. Select the Enable Scanning Detection option. Set the scanning threshold to 4500 connections per second. Select the Add the source IP to the blacklist option. Click Apply. # Configure connection limit for the trusted zone. Select Security > Intrusion Detection from the navigation tree and then select the Connection Limit tab to enter the connection limit configuration page and perform the configurations shown in Figure 35. Figure 35 Configure connection limit for the trusted zone Select zone Trust. Select the Discard packets when the specified attack is detected option. Select the Enable connection limit per source IP option and set the threshold to 100. Click Apply. # Configure connection limit for the DMZ as shown in Figure 36. Figure 36 Configure connection limit for the DMZ Select zone DMZ. Select the Discard packets when the specified attack is detected option. Select the Enable connection limit per dest IP option and set the threshold to Click Apply. # Configure SYN flood detection for the DMZ. Select Security > Intrusion Detection from the navigation tree and then select the SYN Flood tab to enter the SYN flood detection confirmation page and perform the configurations shown in Figure

41 Figure 37 Configure SYN flood detection for the DMZ Select zone DMZ. In the Attack Prevention Policy area, select the Discard packets when the specified attack is detected option. Click Apply. In the SYN Flood Configuration area, click Add. On the page that appears, perform the configurations shown in Figure 38. Figure 38 Specify the objects to be protected in the DMZ Select the Protected Host Configuration option. Specify the IP address as Set the connection rate threshold to 5000 connections per second. Click Apply to complete the configuration. Configuration verification After completing the previous configurations, you can verify the configurations as follows: 33

42 After a scanning attack packet is received from zone Untrust, the module should output alarm logs and add the IP address of the attacker to the blacklist. You can select Security > Intrusion Detection from the navigation tree and then select the Blacklist tab to view whether the attacker s IP address is on the blacklist. If a host in zone Trust initiates 100 or more connections, the module should output alarm logs and discard subsequent connection request packets from the host. You can select the Statistics tab to view how many times that a connection limit per source IP address has been exceeded and the number of packets dropped. If the number of connections to the server in the DMZ reaches or exceeds 10000, the module should output alarm logs and discard subsequent connection request packets. You can select the Statistics tab to view how many times that a connection limit per destination IP address has been exceeded and the number of packets dropped. If a SYN flood attack is initiated to the DMZ, the module should output alarm logs and discard the attack packets. You can select the Statistics tab to view the number of SYN flood attacks and the number of packets dropped. 34

43 Intrusion detection statistics NOTE: The LB module supports configuring intrusion detection only in the web interface. Overview Intrusion detection is an important network security feature. By analyzing the contents and behaviors of packets passing by, it can determine whether the packets are attack packets and take actions accordingly as configured. Supported actions include outputting alarm logs, discarding packets, and adding the attacker to the blacklist. The intrusion detection statistics reflect the counts of attacks as per attack type, and the counts of attack packets dropped, helping you analyze the intrusion types and quantities present to generate better network security policies. Displaying intrusion detection statistics To view intrusion detection statistics, select Security > Intrusion Detection from the navigation tree and then select the Statistics tab. On the intrusion detection statistics page, you can select a zone, and then view the counts of attacks and the counts of dropped packets in the security zone. Figure 39 Intrusion detection statistics 35

44 Table 15 describes the attack types. Table 15 Description of attack types Attack type Fraggle ICMP Redirect ICMP Unreachable Land Large ICMP Route Record Scan Source Route Smurf TCP Flag Tracert WinNuke Description A Fraggle attack occurs when an attacker sends large amounts of UDP echo requests with the UDP port number being 7 or Chargen packets with the UDP port number being 19, resulting in a large quantity of junk replies and finally exhausting the bandwidth of the target network. An ICMP redirect attacker sends ICMP redirect messages to a target to modify its routing table, interfering with the normal forwarding of IP packets. Upon receiving an ICMP unreachable response, some systems conclude that the destination is unreachable and drop all subsequent packets destined for the destination. By sending ICMP unreachable packets, an ICMP unreachable attacker can cut off the connection between the target host and the network. A Land attack occurs when an attacker sends a great number of TCP SYN packets with both the source and destination IP addresses being the IP address of the target, exhausting the half-open resources of the victim and thereby making the target unable to provide services normally. For some hosts and network devices, large ICMP packets will cause memory allocation error and thus crash down the protocol stack. A large ICMP attacker sends large ICMP packets to a target to make it crash down. A route record attack exploits the route record option in the IP header to probe the topology of a network. A scanning attack probes the addresses and ports on a network to identify the hosts attached to the network and application ports available on the hosts and to figure out the topology of the network, so as to get ready further attacks. A source route attack exploits the source route option in the IP header to probe the topology of a network. A Smurf attacker sends large quantities of ICMP echo requests to the broadcast address of the target network. As a result, all hosts on the target network will reply to the requests, causing the network congested and hosts on the target network unable to provide services. Some TCP flags are processed differently on different operating systems. A TCP flag attacker sends TCP packets with such TCP flags to a target to probe its operating system. If the operating system cannot process such packets properly, the attacker will successfully make the host crash down. The Tracert program usually sends UDP packets with a large destination port number and an increasing TTL (starting from 1). The TTL of a packet is decreased by 1 when the packet passes each router. Upon receiving a packet with a TTL of 0, a router must send an ICMP time exceeded message back to the source IP address of the packet. A Tracert attacker exploits the Tracert program to figure out the network topology. A WinNuke attacker sends out-of-band (OOB) data with the pointer field values overlapped to the NetBIOS port (139) of a Windows system with an established connection to introduce a NetBIOS fragment overlap, causing the system to crash. 36

45 Attack type SYN Flood ICMP Flood UDP Flood Number of connections per source IP exceeds the threshold Number of connections per dest IP exceeds the threshold Description A SYN flood attack exploits TCP SYN packets. Due to resource limitation, the number of TCP connections that can be created on a device is limited. A SYN flood attacker sends a barrage of spurious SYN packets to a victim to initiate TCP connections. As the SYN_ACK packets that the victim sends in response can never get acknowledgments, large amounts of half-open connections are created and retained on the victim, making the victim inaccessible before the number of half-open connections drops to a reasonable level due to timeout of half-open connections. In this way, a SYN flood attack exhausts system resources such as memory on a system whose implementation does not limit creation of connections. An ICMP flood attack overwhelms the victim with an enormous number of ICMP echo requests (such as ping packets) in a short period, preventing the victim from providing services normally. A UDP flood attack overwhelms the victim with an enormous number of UDP packets in a short period, disabling the victim from providing services normally. When an internal user initiates a large number of connections to a host on the external network in a short period of time, system resources on the device will be used up soon. This will make the device unable to service other users. If an internal server receives large quantities of connection requests in a short period of time, the server will not be able to process normal connection requests from other hosts. 37

46 TCP proxy configuration NOTE: The LB module supports configuring TCP proxy only in the web interface. Overview Introduction to SYN flood attack As a general rule, the establishment of a TCP connection is a three-way handshake: 1. The request originator sends a SYN message to the target server. 2. After receiving the SYN message, the target server establishes a TCP connection in the SYN_RECEIVED state, returns a SYN ACK message to the originator, and waits for a response. 3. After receiving the SYN ACK message, the originator returns an ACK message. Thus, the TCP connection is established. Attackers may exploit the TCP connection establishment to mount SYN flood attacks. Attackers send a large number of SYN messages to the server to establish TCP connections, but they never make any response to SYN ACK messages. As a result, a large amount of incomplete TCP connections are established, making the server unable to handle services normally. Introduction to TCP proxy The TCP proxy feature can protect the server from SYN flood attacks. The TCP client sets up a TCP connection with the TCP server through a TCP proxy. The TCP proxy intercepts SYN requests from the TCP clients and verifies whether the requests are SYN flood attack packets. If so, the TCP proxy drops the requests, thus protecting the TCP server against SYN flood attacks. TCP proxy can work in two modes: Unidirectional proxy: Only processes packets from the TCP client Bidirectional proxy: Processes packets from both the TCP client and TCP server. You can choose a proper mode according to your network scenario. As shown in Figure 40, packets from the TCP client to the server go through the TCP proxy, while packets from the TCP server to the client are transferred by the Router in between. Thus unidirectional proxy is required. 38

47 Figure 40 Network diagram for unidirectional proxy As shown in Figure 41, all packets between the TCP client and TCP server go through the TCP proxy, and thus you can configure unidirectional proxy or bidirectional proxy as desired. Figure 41 Network diagram for unidirectional/bidirectional proxy How TCP proxy works Unidirectional proxy Figure 42 shows the data exchange process of unidirectional proxy. Figure 42 Data exchange process of unidirectional proxy TCP client TCP proxy TCP server 1) SYN 2) SYN ACK (invalid sequence number) 3) RST 4) SYN (retransmitting) 7) ACK 6) SYN ACK 5) SYN (forwarding) 8) ACK (forwarding) After receiving a SYN message from a client to the protected server (such a message matches a protected IP address entry), the TCP proxy sends back a SYN ACK message with a wrong sequence number on behalf of the server, that is, using the IP address and port number of the server. If the client is legitimate, the TCP proxy will receive an RST message, and will receive a SYN message again from the client. The TCP proxy then directly forwards the SYN, SYN ACK, and ACK messages to establish a TCP connection between the client and the server. 39

48 After the TCP connection is established, the TCP proxy forwards the subsequent packets of the connection without additional processing. Bidirectional proxy Figure 43 shows the data exchange process of bidirectional proxy. Figure 43 Data exchange process of bidirectional proxy After receiving a SYN message from a client to the protected server (such a message matches a protected IP address entry), the TCP proxy sends back a SYN ACK message with the window size being 0 on behalf of the server. If the client is legitimate, the TCP proxy will receive an ACK message, and then sets up a connection between itself and the server through a three-way handshake on behalf of the client. As two TCP connections are established, different sequence numbers are used. They are translated by the TCP proxy for data exchange between the client and the server. Configuring TCP proxy Configuration task list Perform the tasks in Table 16 to configure TCP proxy. Table 16 TCP proxy configuration task list Task Performing global TCP proxy setting Enabling TCP proxy for a security zone Remarks The configuration is effect on all security zones. By default, bidirectional proxy is used. Required By default, the TCP proxy feature is disabled globally. 40

49 Task Remarks At least one method is required. Adding a protected IP address entry Configure to Automatically Add a Protected IP address Entry Displaying information about protected IP address entries You can add protected IP address entries by either of the methods: Static: Add entries manually. By default, no such entries are configured in the system. Dynamic: Select Security > Intrusion Detection from the navigation tree and then select the SYN Flood tab. Select the Add protected IP entry to TCP Proxy check box. After the configuration, the TCP proxy-enabled LB module will automatically add protected IP address entries when detecting SYN flood attacks. You can view information about all protected IP address entries. Performing global TCP proxy setting Select Security > Intrusion Detection from the navigation tree and then select the TCP Proxy Configuration tab to enter the page shown in Figure 44. The Global Configuration area allows you to perform global setting for TCP proxy. Figure 44 TCP proxy configuration Table 17 describes the global configuration items of TCP proxy. Table 17 Global configuration items of TCP proxy Item Unidirection/Bidirediction Description Set the global proxy mode of TCP proxy. Return to TCP proxy configuration task list. Enabling TCP proxy for a security zone Select Security > Intrusion Detection from the navigation tree and then select the TCP Proxy Configuration tab to enter the page shown in Figure 44. You can enable/disable the TCP proxy feature for a security zone in the Zone Configuration area. The icon indicates that the TCP proxy feature is disabled for the corresponding security zone. You can click the Enable button beside the icon to enable the feature. 41

50 The icon indicates that the TCP proxy feature is enabled for the corresponding security zone. You can click the Disable button beside the icon to disable the feature. Return to TCP proxy configuration task list. Adding a protected IP address entry Select Security > Intrusion Detection from the navigation tree and then select the Protected IP Configuration tab to enter the page that lists information about protected IP address entries and the relative statistics, as shown in Figure 45. Click Add to enter the page for configuring a protected IP address entry, as shown in Figure 46. Figure 45 Protected IP address entries Figure 46 Protected IP address entry configuration page Table 18 describes the protected IP address entry configuration items. Table 18 Protected IP address entry configuration items Item Protected IP Address Port Number Description Type the IP address to be protected by the TCP proxy. It is the destination IP address of the TCP connection. Type the destination port of the TCP connection. The option any specifies that TCP proxy services TCP connection requests to any port of the server at the destination IP address. Return to TCP proxy configuration task list. Displaying information about protected IP address entries Select Security > Intrusion Detection from the navigation tree and then select the Protected IP Configuration tab to enter the page that lists information about protected IP address entries, as shown in Figure 45. Table 19 describes information about protected IP address entries. 42

51 Table 19 Information about protected IP address entries Item Protected IP Port Number Type Lifetime(min) Number of Rejected Description IP addresses protected by the TCP proxy feature. Destination port of the TCP connection. The option any specifies that TCP proxy services TCP connection requests to any port of the server at the destination IP address. The protected IP address entries can be static or dynamic. Lifetime for the IP address entry under protection. This item is displayed as for static IP address entries. When the time reaches 0, the protected IP address entry will be deleted. Amount of requests for TCP connection requests matching the protected IP address entry but were proved to be illegitimate. Return to TCP proxy configuration task list. TCP proxy configuration example Network requirements As shown in Figure 47, configure bidirectional TCP proxy on the LB module to protect Server A, Server B, and Server C against SYN flood attacks. Add a protected IP address entry for Server A manually and configure dynamic TCP proxy for the other servers. Figure 47 Network diagram for TCP proxy configuration Server A /24 IP network XGE0/ /24 Untrust LB XGE0/ /24 Trust Server B Server C Configuration procedure # Assign IP addresses for the interfaces and then add interface Ten-GigabitEthernet 0/0.1 to zone Untrust, and Ten-GigabitEthernet 0/0.2 to zone Trust. (Omitted) # Set the TCP proxy mode to bidirectional and enable TCP proxy for zone Untrust. Select Security > Intrusion Detection from the navigation tree and then select the TCP Proxy Configuration tab. Select the bidirectional mode and enable TCP proxy for zone Untrust as shown in Figure

52 Figure 48 Select the bidirectional mode and enable TCP proxy for zone Untrust Select Bidirection for the global setting. Click Apply. In the Zone Configuration area, click Enable for the Untrust zone. # Add an IP address entry manually for protection. Select the Protected IP Configuration tab. Then on the right pane, click Add. Add an IP address entry for protection as shown in Figure 49. Figure 49 Add an IP address entry for protection Type in the Protected IP Address text box. Click Apply. # Configure the SYN flood detection feature, specifying to automatically add protected IP address entries. Select the SYN Flood tab. In the Attack Prevention Policy area, configure the action to be taken upon detecting a SYN flood attack, as shown in Figure 50. Figure 50 Configure the action to be taken upon detecting a SYN flood attack 44

53 Select Trust from the Security Zone drop-down list. Select the Add protected IP entry to TCP Proxy check box in the Attack Prevention Policy area. Click Apply. In the SYN Flood Configuration area, click Add. Configure global settings as shown in Figure 51. Figure 51 Configure global settings Select Global Configuration of Security Zone. Use the default values for the connection rate threshold and half connection count threshold. Click Apply. Configuration guidelines Follow these guidelines when configuring TCP proxy: 1. TCP proxy is effective only for incoming traffic of the security zone. 2. The performance of the web-based management system may be degraded if the system s IP address and port number are in the protected IP entry list. 45

54 ACL configuration NOTE: ACLs refer to IPv4 ACLs throughout this document. ACL overview An access control list (ACL) is a set of rules (or permit or deny statements) for identifying traffic based on criteria such as source IP address, destination IP address, and port number. ACLs are primarily used for packet filtering. You can use ACLs in firewall, routing, and other feature modules for identifying traffic. The packet drop or forwarding decisions varies with the modules that use ACLs. ACL categories Category ACL number IP version Match criteria Basic ACLs 2000 to 2999 IPv4 Source IPv4 address Advanced ACLs 3000 to 3999 IPv4 Source IPv4 address, destination IPv4 address, packet priority, protocols over IPv4, and other Layer 3 and Layer 4 header fields Ethernet frame header ACLs 4000 to 4999 IPv4 Layer 2 header fields, such as source and destination MAC addresses, 802.1p priority, and link layer protocol type ACL numbering and naming Each ACL category has a unique range of ACL numbers. When creating an ACL, you must assign it a number. In addition, you can assign the ACL a name for the ease of identification. After creating an ACL with a name, you can neither rename it nor delete its name. For an Ethernet frame header ACL, the ACL number and name must be globally unique. For an IPv4 basic or advanced ACLs, its ACL number and name must be unique among all IPv4 ACLs. Match order The rules in an ACL are sorted in a specific order. When a packet matches a rule, the device stops the match process and performs the action defined in the rule. If an ACL contains overlapping or conflicting rules, the matching result and action to take depend on the rule order. The following ACL match orders are available: config Sorts ACL rules in ascending order of rule ID. A rule with a lower ID is matched before a rule with a higher ID. If you use this approach, carefully check the rule content and order. 46

55 auto Sorts ACL rules in depth-first order. Depth-first ordering ensures that any subset of a rule is always matched before the rule. Table 20 lists the sequence of tie breakers that depth-first ordering uses to sort rules for each type of ACL. Table 20 Sort ACL rules in depth-first order ACL category IPv4 basic ACL IPv4 advanced ACL Ethernet frame header ACL Sequence of tie breakers 1. More 0s in the source IP address wildcard (more 0s means a narrower IP address range) 2. Smaller rule ID 1. Specific protocol type rather than IP (IP represents any protocol over IP) 2. More 0s in the source IP address wildcard mask 3. More 0s in the destination IP address wildcard 4. Narrower TCP/UDP service port number range 5. Smaller rule ID 1. More 1s in the source MAC address mask (more 1s means a smaller MAC address) 2. More 1s in the destination MAC address mask 3. Smaller rule ID NOTE: A wildcard mask, also called an inverse mask, is a 32-bit binary and represented in dotted decimal notation. In contrast to a network mask, the 0 bits in a wildcard mask represent do care bits, and the 1 bits represent don t care bits. If the 'do care' bits in an IP address are identical to the do care bits in an IP address criterion, the IP address matches the criterion. All don t care bits are ignored. The 0s and 1s in a wildcard mask can be noncontiguous. For example, is a valid wildcard mask. ACL rule comments You can add a comment about an ACL rule to make it easy to understand. The rule comment appears below the rule statement. ACL rule numbering What is the ACL rule numbering step If you do not assign an ID for the rule you are creating, the system automatically assigns it a rule ID. The rule numbering step sets the increment by which the system automatically numbers rules. For example, the default ACL rule numbering step is 5. If you do not assign IDs to rules you are creating, they are numbered 0, 5, 10, 15, and so on. The wider the numbering step, the more rules you can insert between two rules. By introducing a gap between rules rather than contiguously numbering rules, you have the flexibility of inserting rules in an ACL. This feature is important for a config order ACL, where ACL rules are matched in ascending order of rule ID. NOTE: The default ACL rule numbering step is 5. The web interface does not support ACL step configuration. 47

56 Automatic rule numbering and renumbering The ID automatically assigned to an ACL rule takes the nearest higher multiple of the numbering step to the current highest rule ID, starting with 0. For example, if the numbering step is 5 (the default), and there are five ACL rules numbered 0, 5, 9, 10, and 12, the newly defined rule is numbered 15. If the ACL does not contain any rule, the first rule is numbered 0. Whenever the step changes, the rules are renumbered, starting from 0. For example, if there are five rules numbered 5, 10, 13, 15, and 20, changing the step from 5 to 2 causes the rules to be renumbered 0, 2, 4, 6 and 8. Fragments filtering with ACLs Traditional packet filtering matches only first fragments of packets, and allows all subsequent non-first fragments to pass through. Attackers can fabricate non-first fragments to attack networks. To avoids the risks, the HP ACL implementation: Filters all fragments by default, including non-first fragments. Allows for matching criteria modification, for example, filters non-first fragments only. ACL acceleration ACL acceleration speeds up ACL lookup. The acceleration effect increases with the number of ACL rules. ACL acceleration uses memory. To achieve the best trade-off between memory and ACL processing performance, HP recommends you enable ACL acceleration for large ACLs. For example, when you use a large ACL for a session-based service, such as NAT, you can enable ACL acceleration to avoid session timeouts caused by ACL processing delays. Enable ACL acceleration in an ACL after you have finished editing ACL rules. ACL acceleration always uses ACL criteria that have been set before it is enabled for rule matching. It does not synchronize with any subsequent match criterion changes. Configuring an ACL in the web Configuration task list Perform the tasks in Table 21 to configure an ACL. Table 21 ACL configuration task list Task Configuring a time range Creating an ACL Remarks Required The category of the created ACL depends on the ACL number that you specify. 48

57 Task Configuring a basic ACL rule Configuring an advance ACL rule Configuring an Ethernet frame header ACL rule Remarks Required Complete one of the three tasks according to the ACL category. IMPORTANT: Within an ACL, the permit or deny statement of each rule must be unique. If the ACL rule you are creating or editing has the same deny or permit statement as another rule in the ACL, your creation or editing attempt will fail. You can edit ACL rules only when the match order is config. Necessary only when the ACL contains a large number of ACL rules. Configuring ACL acceleration IMPORTANT: Only IPv4 basic ACLs and IPv4 advanced ACLs support ACL acceleration. ACL acceleration is not available for ACLs that contain a non-contiguous wildcard mask, for example, After you modify an IPv4 ACL with ACL acceleration enabled, disable and re-enable ACL acceleration to ensure correct rule matching. Configuring a time range A time range defines a time range, which can be referenced by an ACL to control when a rule is effective. Select Security > Time Range from the navigation tree to enter a time range list page, as shown in Figure 52. Click Add to enter the time range configuration page, as shown in Figure 53. Figure 52 Time range list If the time range includes the current time, the time range is displayed as "Active" in the time range list. Otherwise, the time range is displayed as "Inactive". 49

58 Figure 53 Time range configuration page Table 22 Time range configuration items Item Name Description Type the name for the time range. Periodic Time Range Absolute Time Range Start Time End Time Sun., Mon., Tues., Wed., Thurs., Fri., and Sat. From To Set the start time of the periodic time range, in the hh:mm format (24-hour clock). Set the end time of the periodic time range, in the hh:mm format (24-hour clock). The end time must be greater than the start time. Select the day or days of the week on which the periodic time range is valid. Set the start time of the absolute time range. The time of the day is in the hh:mm format (24-hour clock), and the date is in the MM/DD/YYYY format. Set the end time of the absolute time range. The time of the day is in the hh:mm format (24-hour clock), and the date is in the MM/DD/YYYY format. The end time must be greater than the start time. Creating an ACL After you select Security > ACL from the navigation tree, all existing ACLs are displayed in the right pane, as shown in Figure 54. Click Add to enter the ACL configuration page, as shown in Figure 55. Figure 54 ACL list 50

59 Figure 55 ACL configuration page Table 23 describes the configuration items for creating an ACL. Table 23 ACL configuration items Item ACL Number Match Order Description Type a number for the ACL. The value ranges of the ACL number vary by device. Select a match order for the ACL. Available values are: Config: Sorts ACL rules in ascending order of rule ID. Auto: Sorts ACL rules in depth-first order. Return to ACL configuration task list. Configuring a basic ACL rule Select Security > ACL from the navigation tree. Then, select the basic ACL for which you want to configure ACL rules and click the corresponding icon in the Operation column to display all existing rules of the ACL, as shown in Figure 56. Click Add to enter the basic ACL rule configuration page, as shown in Table 24. Figure 56 List of basic ACL rules 51

60 Figure 57 Basic ACL rule configuration page Table 24 Basic ACL rule configuration items Item Description Select the Rule ID check box and type a number for the rule. Rule ID Operation If you do not specify a rule number, the system automatically assigns one for the rule. IMPORTANT: If the rule already exists, the configuration overwrites the old rule. Select the operation to be performed for packets matching the rule. Permit: Allows matching packets to pass. Deny: Denies matching packets. Select a time range for the rule. Time Range Non-first Fragments Only If you select None, the rule will always be effective. Available time ranges are configured by selecting Security > Time Range from the navigation tree. Select this check box to apply the rule to only non-first fragments. If you do no select this check box, the rule applies to all fragments and non-fragments. Select this check box to log matching packets. Logging Source IP Address Source Wildcard A log entry contains the ACL rule number, action on the matching packets, protocol that IP carries, source/destination address, source/destination port number, and number of matching packets. Select the Source IP Address check box and type a source IP address and source wildcard, in dotted decimal notation. Specify the VPN. VPN Instance If you select None, the rule applies to only non-vpn packets. The LB module does not support this configuration item. Return to ACL configuration task list. Configuring an advance ACL rule Select Security > ACL from the navigation tree. Then, select the advanced ACL for which you want to configure ACL rules and click the corresponding icon in the Operation column to list all existing rules 52

61 of the ACL, as shown in Figure 58. Click Add to enter the advanced ACL rule configuration page, as shown in Figure 59. Figure 58 List of advanced ACL rules Figure 59 Advanced ACL rule configuration page Table 25 Advanced ACL rule configuration items Item Description Select the Rule ID check box and type a number for the rule. Rule ID Operation If you do not specify the rule number, the system assigns one automatically. IMPORTANT: If the rule already exists, the configuration overwrites the old rule. Select the action to be performed for packets matching the rule. Permit: Allows matching packets to pass. Deny: Denies matching packets. 53

62 Item Description Select a time range for the rule. Time Range Non-first Fragments Only If you select None, the rule will always be effective. Available time ranges are configured by selecting Security > Time Range from the navigation tree. Select this check box to apply the rule to only non-first fragments. If you do no select this check box, the rule applies to all fragments and non-fragments. Select this check box to log matching IPv4 packets. Logging Source IP Address Source Wildcard Destination IP Address Destination Wildcard A log entry contains the ACL rule number, action on the matching packets, protocol over the IP, source/destination address, source/destination port number, and number of matching packets. Select the Source IP Address check box and type a source IP address and source wildcard, in dotted decimal notation. Select the Destination IP Address check box and type a destination IP address and destination wildcard, in dotted decimal notation. Specify the VPN. VPN Instance Protocol ICMP Message ICMP Type ICMP Code If you select None, the rule applies to only non-vpn packets. The LB module does not support this configuration item. Select the protocol to be carried over by IP. If you select 1 ICMP, you can configure the ICMP message type and code. If you select 6 TCP or 17 UDP, you can configure the TCP or UDP specific items. Specify the ICMP message type and code. These items are available only when you select 1 ICMP from the Protocol drop-down box. If you select Others from the ICMP Message drop-down box, you need to type values in the ICMP Type and ICMP Code fields. Otherwise, the two fields take the default values, which cannot be changed. If you select this check box, the rule matches packets used for establishing and maintaining TCP connections. TCP Connection Established This item is available only when you select 6 TCP from the Protocol drop-down box. A rule with this item configured matches TCP connection packets with the ACK or RST flag. Source Destination Operator Port Operator Port Select the operators and type the source port numbers and destination port numbers as required. These items are available only when you select 6 TCP or 17 UDP from the Protocol drop-down box. Different operators have different configuration requirements for the port number fields: None: The following port number fields cannot be configured. inclusive range: The following port number fields must be configured to define a port range. Other values: The first port number field must be configured and the second must not. 54

63 Item Description ToS Specify the ToS preference. IMPORTANT: Precedence DSCP Specify the IP precedence. Specify the DSCP priority. If you configure the IP precedence or ToS precedence in addition to the DSCP priority, the DSCP priority takes effect. Return to ACL configuration task list. Configuring an Ethernet frame header ACL rule Select Security > ACL from the navigation tree. Then, select the Ethernet frame header ACL for which you want to configure ACL rules from the ACL list in the right pane and click the corresponding icon in the Operation column to list all existing rules of the ACL, as shown in Figure 60. Click Add to enter the configuration page for Ethernet frame header ACL rules, as shown in Figure 61. Figure 60 List of Ethernet frame header ACL rules Figure 61 Ethernet frame header ACL rule configuration page Table 26 Ethernet frame header ACL rule configuration items Item Rule ID Description Select the Rule ID check box and type a number for the rule. If you do not specify the rule number, the system assigns one automatically. IMPORTANT: If the rule already exists, the configuration overwrites the old rule. 55

64 Item Operation Description Select the operation to be performed for packets matching the rule. Permit: Allows matching packets to pass. Deny: Denies matching packets. Select a time range for the rule. Time Range Source MAC Address Source Wildcard Destination MAC Address Destination Wildcard LSAP Type LSAP Wildcard Protocol Type Protocol Wildcard If you select None, the rule will always be effective. Available time ranges are configured by selecting Security > Time Range from the navigation tree. Select the Source MAC Address check box and specify the source MAC address and wildcard. Select the Destination MAC Address check box and specify the destination MAC address and wildcard. Select the LSAP Type check box and specify the DSAP and SSAP fields in the LLC encapsulation by configuring the following two items: LSAP Type: Specifies the encapsulation format. LSAP Wildcard: Specifies the LSAP mask. Select the Protocol Type check box and specify the link layer protocol by configuring the following two items: Protocol Type: Specifies a protocol type in Ethernet_II and Ethernet_SNAP frames. Protocol Wildcard: Specifies a protocol type mask. Return to ACL configuration task list. Configuring ACL acceleration Select Security > ACL from the navigation tree to enter the page shown in Figure 54. All existing ACLs are displayed in the right pane. You can enable or disable ACL acceleration for an ACL through the ACL Acceleration column: indicates that the ACL is not accelerated. You can click the Start Accelerating link to enable ACL acceleration. indicates that the ACL is accelerated. You can click the Stop Accelerating link to disable ACL acceleration. indicates that the ACL has been modified after it was configured with ACL acceleration. You can click the Start Accelerating link to enable ACL acceleration again, making changes to the ACL take effect. Return to ACL configuration task list. ACL configuration example Network requirements As shown in Figure 62, configure an ACL to deny hosts in the R&D and Marketing departments to access the salary server, and allow hosts in the Accounting department to access the salary server. 56

65 Figure 62 Network diagram for ACL configuration Configuration procedure # Configure an IPv4 advanced ACL. Select Security > ACL from the navigation tree, and then click Add. Type the ACL number Select the match order Config. Click Apply. Figure 63 Configure an IPv4 advanced ACL # Configure a rule to deny packets sourced from hosts in the Marketing department. From the ACL list, select ACL 3000 and click the icon in the Operation column. Then, on the page click Add to enter the ACL rule configuration page. Click the Rule ID check box, and type 0 in the text box. Select Deny from the Operation drop-down box. Select the Source IP Address check box, and type and respectively in the following text boxes. Select the Destination IP Address check box, and type and respectively in the following text boxes. Click Apply. 57

66 Figure 64 Configure a rule to deny packets sourced from hosts in the Marketing department # Configure a rule to deny packets sourced from hosts in the R&D department. On the page displaying the rules of ACL 3000, click Add. Figure 65 Advanced ACL 3000 rule list Click the Rule ID check box, and type 1 in the text box. Select Deny as the operation. Select Source IP Address check box and type and in the following text boxes. Select the Destination IP Address check box, and type and in the following text boxes. Click Apply. 58

67 Figure 66 Configure a rule to deny packets sourced from hosts in the R&D department # Configure a rule to allow packets sourced from hosts in the Accounting department to the salary server. On the page displaying rules of ACL 3000, click Add. Figure 67 Advanced ACL 3000 rule list Click the Rule ID check box, and type 2 in the text box. Select Permit as the operation. Select Source IP Address check box, and type and in the following text boxes. Select Destination IP Address check box, and type and in the following text boxes. Click Apply. 59

68 Figure 68 Configure a rule to allow hosts in the Accounting department to access the salary server Configuring an ACL at the CLI ACL configuration task list Complete the following tasks to configure an ACL: Task Configuring a time range Configuring an IPv4 basic ACL Configuring an IPv4 advanced ACL Configuring an Ethernet frame header ACL Copying an IPv4 ACL Enabling ACL acceleration for an IPv4 ACL Remarks Required Configure at least one task. IMPORTANT: Within an ACL, the permit or deny statement of each rule must be unique. If the ACL rule you are creating or editing has the same deny or permit statement as another rule in the ACL, your creation or editing attempt will fail. You can edit ACL rules only when the match order is config. 60

69 Configuring an ACL Configuring a time range You can implement ACL rules based on the time of day by applying a time range to them. A time-based ACL rule takes effect only in any time periods specified by the time range. The following basic types of time range are available: Periodic time range Recurs periodically on a day or days of the week. Absolute time range Represents only a period of time and does not recur. You can create multiple statements in a time range. The active period of a time range is calculated as follows: 1. Combining all periodic statements 2. Combining all absolute statements 3. Taking the intersection of the two statement sets as the active period of the time range You can create a maximum of 256 time ranges, each with a maximum of 32 periodic statements and 12 absolute statements. Follow these steps to configure a time range: To do Use the command Remarks Enter system view system-view Configure a time range time-range time-range-name { start-time to end-time days [ from time1 date1 ] [ to time2 date2 ] from time1 date1 [ to time2 date2 ] to time2 date2 } Required By default, no time range exists. Repeat this command with the same time range name to create multiple statements for a time range. Configuring an IPv4 basic ACL IPv4 basic ACLs match packets based only on source IP addresses. Follow these steps to configure an IPv4 basic ACL: To do Use the command Remarks Enter system view system-view Create an IPv4 basic ACL and enter its view Configure a description for the IPv4 basic ACL acl number acl-number [ name acl-name ] [ match-order { auto config } ] description text Required By default, no ACL exists. IPv4 basic ACLs are numbered in the range 2000 to You can use the acl name acl-name command to enter the view of a named IPv4 ACL. By default, an IPv4 basic ACL has no ACL description. 61

70 To do Use the command Remarks Set the rule numbering step Create or edit a rule Add or edit a rule comment step step-value rule [ rule-id ] { deny permit } [ counting fragment logging source { sour-addr sour-wildcard any } time-range time-range-name ] * rule rule-id comment text 5 by default. Required By default, an IPv4 basic ACL does not contain any rule. By default, an IPv4 ACL rule has no rule description. Configuring an IPv4 advanced ACL IPv4 advanced ACLs match packets based on source IP addresses, destination IP addresses, packet priorities, protocols over IP, and other protocol header information, such as TCP/UDP source and destination port numbers, TCP flags, ICMP message types, and ICMP message codes. Compared to IPv4 basic ACLs, IPv4 advanced ACLs allow more flexible and accurate filtering. Follow these steps to configure an IPv4 advanced ACL: To do Use the command Remarks Enter system view system-view Create an IPv4 advanced ACL and enter its view Configure a description for the IPv4 advanced ACL Set the rule numbering step acl number acl-number [ name acl-name ] [ match-order { auto config } ] description text step step-value Required By default, no ACL exists. IPv4 advanced ACLs are numbered in the range 3000 to You can use the acl name acl-name command to enter the view of a named IPv4 ACL. By default, an IPv4 advanced ACL has no ACL description. 5 by default. 62

71 To do Use the command Remarks Create or edit a rule Add or edit a rule comment rule [ rule-id ] { deny permit } protocol [ { { ack ack-value fin fin-value psh psh-value rst rst-value syn syn-value urg urg-value } * established } counting destination { dest-addr dest-wildcard any } destination-port operator port1 [ port2 ] dscp dscp fragment icmp-type { icmp-type [ icmp-code ] icmp-message } logging precedence precedence reflective source { sour-addr sour-wildcard any } source-port operator port1 [ port2 ] time-range time-range-name tos tos ] * rule rule-id comment text Required By default, an IPv4 advanced ACL does not contain any rule. By default, an IPv4 advanced ACL rule has no rule description. Configuring an Ethernet frame header ACL Ethernet frame header ACLs, also called "Layer 2 ACLs," match packets based on Layer 2 protocol header fields such as source MAC address, destination MAC address, 802.1p priority (VLAN priority), and link layer protocol type. Follow these steps to configure an Ethernet frame header ACL: To do Use the command Remarks Enter system view system-view Create an Ethernet frame header ACL and enter its view Configure a description for the Ethernet frame header ACL Set the rule numbering step Create or edit a rule acl number acl-number [ name acl-name ] [ match-order { auto config } ] description text step step-value rule [ rule-id ] { deny permit } [ cos vlan-pri counting dest-mac dest-addr dest-mask { lsap lsap-type lsap-type-mask type protocol-type protocol-type-mask } source-mac sour-addr source-mask time-range time-range-name ] * Required By default, no ACL exists. Ethernet frame header ACLs are numbered in the range 4000 to You can use the acl name acl-name command to enter the view of a named Ethernet frame header ACL. By default, an Ethernet frame header ACL has no ACL description. 5 by default. Required By default, an Ethernet frame header ACL does not contain any rule. 63

72 To do Use the command Remarks Add or edit a rule comment rule rule-id comment text By default, an Ethernet frame header ACL rule has no rule description. Copying an IPv4 ACL You can create an ACL by copying an existing ACL (source ACL). The new ACL (destination ACL) has the same properties and content as the source ACL, but not the same ACL number and name. To successfully copy an ACL, make sure that: The destination ACL number is from the same category as the source ACL number. The source ACL already exists but the destination ACL does not. Follow these steps to copy an IPv4 ACL: To do Use the command Remarks Enter system view system-view Copy an existing IPv4 ACL to create a new IPv4 ACL acl copy { source-acl-number name source-acl-name } to { dest-acl-number name dest-acl-name } Required Enabling ACL acceleration for an IPv4 ACL Follow these steps to enable ACL acceleration for an IPv4 ACL: To do Use the command Remarks Enter system view system-view Enable ACL acceleration for an IPv4 ACL acl accelerate number acl-number Required Disabled by default. The ACL must exist. Only IPv4 basic ACLs and advanced ACLs support ACL acceleration. CAUTION: ACL acceleration is not available for ACLs that contain a non-contiguous wildcard mask. After you modify an IPv4 ACL with ACL acceleration enabled, disable and re-enable ACL acceleration to ensure correct rule matching. Displaying and maintaining ACLs To do... Use the command Remarks Display configuration and match statistics for one or all IPv4 ACLs display acl { acl-number all name acl-name } Available in any view Display information about the IPv4 ACL acceleration feature display acl accelerate { acl-number all } Available in any view 64

73 To do... Use the command Remarks Display the configuration and status of one or all time ranges Clear statistics for one or all IPv4 ACLs display time-range { time-range-name all } reset acl counter { acl-number all name acl-name } Available in any view Available in user view ACL configuration examples Network requirements A company interconnects its departments through a LB module. Configure an ACL to: Permit access from the President's office at any time to the salary database server. Deny access from any other department to the database server during office hours (from 8:00 to 18:00) on working days. Figure 69 Network diagram for IPv4 ACL configuration Configuration procedure 1. Define a periodic time range. # Create a periodic time range from 8:00 to 18:00 on working days. <LB> system-view [LB] time-range work 8:0 to 18:0 working-day 2. Create an ACL to control access to the salary server. # Create an IPv4 advanced ACL numbered 3000 and enter its view. [LB] acl number 3000 # Configure a rule to permit access from the President s office to the financial database server. [LB-acl-adv-3000] rule 1 permit ip source destination # Configure a rule to deny access from any other department to the salary database server during working hours. 65

74 [LB-acl-adv-3000] rule 2 deny ip source any destination time-range trname [LB-acl-adv-3000] quit 3. Apply the ACL # Enable IPv4 firewall, and apply IPv4 ACL 3000 to filter outgoing packets on interface Ten-GigabitEthernet 0/0.4. [LB] firewall enable [LB] interface Ten-GigabitEthernet 0/0.4 [LB-Ten-GigabitEthernet0/0.4] firewall packet-filter 3000 outbound 66

75 PKI configuration PKI overview Introduction to PKI PKI terms Digital certificate CRL The Public Key Infrastructure (PKI) is a general security infrastructure for providing information security through public key technologies. PKI, also called asymmetric key infrastructure, uses a key pair to encrypt and decrypt the data. The key pair consists of a private key and a public key. The private key must be kept secret while the public key needs to be distributed. Data encrypted by one of the two keys can only be decrypted by the other. A key problem of PKI is how to manage the public keys. PKI employs the digital certificate mechanism to solve this problem. The digital certificate mechanism binds public keys to their owners, helping distribute public keys in large networks securely. With digital certificates, the PKI system provides network communication and e-commerce with security services such as user authentication, data non-repudiation, data confidentiality, and data integrity. HP's PKI system provides certificate management for IP Security (IPsec), Secure Sockets Layer (SSL). A digital certificate is a file signed by a certificate authority (CA) for an entity. It includes mainly the identity information of the entity, the public key of the entity, the name and signature of the CA, and the validity period of the certificate, where the signature of the CA ensures the validity and authority of the certificate. A digital certificate must comply with the international standard of ITU-T X.509. The most common standard is X.509 v3. This manual involves two types of certificates: local certificate and CA certificate. A local certificate is a digital certificate signed by a CA for an entity, while a CA certificate is the certificate of a CA. If multiple CAs are trusted by different users in a PKI system, the CAs will form a CA tree with the root CA at the top level. The root CA has a CA certificate signed by itself while each lower level CA has a CA certificate signed by the CA at the next higher level. An existing certificate may need to be revoked when, for example, the user name changes, the private key leaks, or the user stops the business. Revoking a certificate is to remove the binding of the public key with the user identity information. In PKI, the revocation is made through certificate revocation lists (CRLs). Whenever a certificate is revoked, the CA publishes one or more CRLs to show all certificates that have been revoked. The CRLs contain the serial numbers of all revoked certificates and provide an effective way for checking the validity of certificates. A CA may publish multiple CRLs when the number of revoked certificates is so large that publishing them in a single CRL may degrade network performance. In this case, CRL distribution points are used to indicate the URLs of these CRLs. 67

76 CA policy A CA policy is a set of criteria that a CA follows in processing certificate requests, issuing and revoking certificates, and publishing CRLs. Usually, a CA advertises its policy in the form of certification practice statement (CPS). A CA policy can be acquired through out-of-band means such as phone, disk, and . As different CAs may use different methods to check the binding of a public key with an entity, make sure that you understand the CA policy before selecting a trusted CA for certificate request. Architecture of PKI A PKI system consists of entities, a CA, a registration authority (RA) and a PKI repository, as shown in Figure 70. Figure 70 PKI architecture Entity CA RA PKI repository An entity is an end user of PKI products or services, such as a person, an organization, a device like a router or a switch, or a process running on a computer. A certificate authority (CA) is a trusted authority responsible for issuing and managing digital certificates. A CA issues certificates, specifies the validity periods of certificates, and revokes certificates as needed by publishing CRLs. A registration authority (RA) is an extended part of a CA or an independent authority. An RA can implement functions including identity authentication, CRL management, key pair generation and key pair backup. It receives registration requests, examines the qualifications of users, and decides whether the CA can assign digital certificates to the users. Sometimes, a CA assumes the registration management responsibility and therefore there is no independent RA. The PKI standard recommends that an independent RA be used for registration management to achieve higher security of application systems. A PKI repository can be a Lightweight Directory Access Protocol (LDAP) server or a common database. It stores and manages information like certificate requests, certificates, keys, CRLs and logs while providing a simple query function. 68

77 LDAP is a protocol for accessing and managing PKI information. An LDAP server stores user information and digital certificates from the RA server and provides directory navigation service. From an LDAP server, an entity can retrieve digital certificates of its own and other entities. Applications of PKI VPN Secure Web security The PKI technology can satisfy the security requirements of online transactions. As an infrastructure, PKI has a wide range of applications. Here are some application examples. A virtual private network (VPN) is a private data communication network built on the public communication infrastructure. A VPN can leverage network layer security protocols (for instance, IPsec) in conjunction with PKI-based encryption and digital signature technologies to achieve confidentiality. s require confidentiality, integrity, authentication, and non-repudiation. PKI can address these needs. The secure protocol that is developing rapidly is Secure/Multipurpose Internet Mail Extensions (S/MIME), which is based on PKI and allows for transfer of encrypted mails with signature. For Web security, two peers can establish a Secure Sockets Layer (SSL) connection first for transparent and secure communications at the application layer. With PKI, SSL enables encrypted communications between a browser and a server. Both the communication parties can verify the identity of each other through digital certificates. Operation of PKI In a PKI-enabled network, an entity can request a local certificate from the CA and the LB module can check the validity of certificate. The following describes how it works: 1. An entity submits a certificate request to the CA. 2. The RA verifies the identity of the entity and then sends the identity information and the public key with a digital signature to the CA. 3. The CA verifies the digital signature, approves the application, and issues a certificate. 4. The RA receives the certificate from the CA, sends it to the LDAP server to provide directory navigation service, and notifies the entity that the certificate is successfully issued. 5. The entity retrieves the certificate. With the certificate, the entity can communicate with other entities safely through encryption and digital signature. 6. The entity makes a request to the CA when it needs to revoke its certificate, while the CA approves the request, updates the CRLs and publishes the CRLs on the LDAP server. Configuring PKI in the web interface Configuration task list There are two PKI certificate request modes: Manual In manual mode, you need to retrieve a CA certificate, generate a local RSA key pair, and submit a local certificate request for an entity. 69

78 Auto In auto mode, an entity automatically requests a certificate through Simple Certification Enrollment Protocol (SCEP, a dedicated protocol for an entity to communicate with a CA) when it has no local certificate or the present certificate is about to expire. You can specify the PKI certificate request mode for a PKI domain. Different PKI certificate request modes require different configurations: Requesting a certificate manually Table 27 Configuration task list for requesting a certificate manually Task Remarks Required Create a PKI entity and configure the identity information. Creating a PKI entity A certificate is the binding of a public key and the identity information of an entity, where the identity information is identified by an entity distinguished name (DN). A CA identifies a certificate applicant uniquely by entity DN. The identity settings of an entity must be compliant to the CA certificate issue policy. Otherwise, the certificate request may be rejected. Required Creating a PKI domain Create a PKI domain, setting the certificate request mode to Manual. Before requesting a PKI certificate, an entity needs to be configured with some enrollment information, which is referred to as a PKI domain. A PKI domain is intended only for convenience of reference by other applications like IKE and SSL, and has only local significance. Required Generate a local RSA key pair. By default, no local RSA key pair exists. Generating an RSA key pair Generating an RSA key pair is an important step in certificate request. The key pair includes a public key and a private key. The private key is kept by the user, while the public key is transferred to the CA along with some other information. TIP: If there is already a local certificate, you need to remove the certificate before generating a new key pair, so as to keep the consistency between the key pair and the local certificate. Required Obtain the CA certificate and save it locally. For more information, see Retrieving and displaying a certificate. Retrieving the CA certificate Certificate retrieval serves two purposes: Locally store the certificates associated with the local security domain for improved query efficiency and reduced query count, Prepare for certificate verification. TIP: If there are already CA certificates locally, you cannot perform the CA certificate retrieval operation. This is to avoid possible mismatch between certificates and registration information resulting from relevant changes. To retrieve the CA certificate, you need to remove the CA certificate and local certificate first. 70

79 Task Remarks Required When requesting a certificate, an entity introduces itself to the CA by providing its identity information and public key, which will be the major components of the certificate. Requesting a local certificate A certificate request can be submitted to a CA in two ways: online and offline. In online mode, if the request is granted, the local certificate will be retrieved to the local system automatically. In offline mode, you need to retrieve the local certificate by an out-of-band means. TIP: If there is already a local certificate, you cannot perform the local certificate retrieval operation. This is to avoid possible mismatch between the local certificate and registration information resulting from relevant changes. To retrieve a new local certificate, you need to remove the CA certificate and local certificate first. Destroying the RSA key pair Destroy the existing RSA key pair and the corresponding local certificate. If the certificate to be retrieved contains an RSA key pair, you need to destroy the existing RSA key pair. Otherwise, the retrieving operation will fail. Retrieving and displaying a certificate Retrieving and displaying a crl Retrieve an existing certificate and display its information. TIP: Before retrieving a local certificate in online mode, be sure to complete LDAP server configuration. Retrieve a CRL and display its contents. Requesting a certificate automatically Table 28 Configuration task list for requesting a certificate automatically Task Remarks Required Create a PKI entity and configure the identity information. Creating a PKI entity A certificate is the binding of a public key and the identity information of an entity, where the identity information is identified by an entity distinguished name (DN). A CA identifies a certificate applicant uniquely by entity DN. The identity settings of an entity must be compliant to the CA certificate issue policy. Otherwise, the certificate request may be rejected. Required Creating a PKI domain Create a PKI domain, setting the certificate request mode to Auto. Before requesting a PKI certificate, an entity needs to be configured with some enrollment information, which is referred to as a PKI domain. A PKI domain is intended only for convenience of reference by other applications like IKE and SSL, and has only local significance. 71

80 Task Remarks Destroying the RSA key pair Destroy the existing RSA key pair and the corresponding local certificate. If the certificate to be retrieved contains an RSA key pair, you need to destroy the existing RSA key pair. Otherwise, the retrieving operation will fail. Retrieve an existing certificate and display its information. Retrieving and displaying a certificate Retrieving and displaying a crl TIP: Before retrieving a local certificate in online mode, be sure to complete LDAP server configuration. If a PKI domain already has a CA certificate, you cannot retrieve another CA certificate for it. This is in order to avoid inconsistency between the certificate and registration information due to related configuration changes. To retrieve a new CA certificate, use the pki delete-certificate command to delete the existing CA certificate and local certificate first. Retrieve a CRL and display its contents. Creating a PKI entity Select Security > PKI > Entity from the navigation tree to display existing PKI entities, as shown in Figure 71. Then, click Add to enter the PKI entity configuration page, as shown in Figure 72. Figure 71 PKI entity list Figure 72 PKI entity configuration page 72

81 Table 29 PKI entity configuration items Item Entity Name Common Name IP Address FQDN Country/Region Code State Locality Organization Organization Unit Description Type the name for the PKI entity. Type the common name for the entity. Type the IP address of the entity. Type the fully qualified domain name (FQDN) for the entity. An FQDN is a unique identifier of an entity on the network. It consists of a host name and a domain name and can be resolved to an IP address. For example, is an FQDN, where www indicates the host name and whatever.com the domain name. Type the country code for the entity. Type the state or province for the entity. Type the locality for the entity. Type the organization name for the entity. Type the unit name for the entity. Return to Configuration task list for requesting a certificate manually. Return to Configuration task list for requesting a certificate automatically. Creating a PKI domain Select Security > PKI > Domain from the navigation tree to display existing PKI domains, as shown in Figure 73. Then, click Add to enter the PKI domain configuration page, as shown in Figure 74. Figure 73 PKI domain list 73

82 Figure 74 PKI domain configuration page Table 30 PKI domain configuration items Item Domain Name Description Type the name for the PKI domain. Type the identifier of the trusted CA. An entity requests a certificate from a trusted CA. The trusted CA takes the responsibility of certificate registration, distribution, and revocation, and query. CA Identifier TIP: In offline mode, this item is optional; while in other modes, this item is required. The CA identifier is required only when you retrieve a CA certificate. It is not used during local certificate request. Select the local PKI entity. Entity Name When submitting a certificate request to a CA, an entity needs to show its identity information. Available PKI entities are those that have been configured on the Web interface you can enter by selecting Security > PKI > Entity. Institution Select the authority for certificate request. CA: Indicates that the entity requests a certificate from a CA. RA: Indicates that the entity requests a certificate from an RA. 74

83 Item Description Type the URL of the RA. The entity will submit the certificate request to the server at this URL through the SCEP protocol. The SCEP protocol is intended for communication between an entity and an authentication authority. Requesting URL In offline mode, this item is optional; while in other modes, this item is required. TIP: In offline mode, this item is optional; while in other modes, this item is required. This item does not support domain name resolution. LDAP IP Port Version Request Mode Password Encrypt Password Type the IP address, port number, and version number of the LDAP server. Usually, an LDAP server stores certificates and CRL information. In this case, the LDAP server must be configured properly Select the online certificate request mode, which can be Auto or Manual. When the certificate request mode is set to Auto, type a password for certificate revocation and select the check box to display the password in cipher text. Specify the hash algorithm and fingerprint for verification of the CA root certificate. Hash Fingerprint Polling Count Polling Interval Enable CRL Checking Upon receiving the root certificate of the CA, an entity needs to verify the fingerprint of the root certificate, namely, the hash value of the root certificate content. This hash value is unique to every certificate. If the fingerprint of the root certificate does not match the one configured for the PKI domain, the entity will reject the root certificate. TIP: The fingerprint of the CA root certificate is required when the certificate request mode is Auto, and can be omitted when the certificate request mode is Manual. If it is omitted, you need to verify the CA server by yourself. Set the polling interval and attempt limit for querying the certificate request status. After an entity makes a certificate request, the CA may need a long period of time if it verifies the certificate request in manual mode. During this period, the applicant needs to query the status of the request periodically to get the certificate as soon as possible after the certificate is signed. These two items dictate the polling operation. Select this box to specify that CRL checking is required during certificate verification. Type the CRL update period, that is, the interval at which the PKI entity downloads the latest CRLs. This item is available when the Enable CRL Checking check box is selected. CRL Update Period By default, the CRL update period depends on the next update field in the CRL file. TIP: The manually configured CRL update period takes precedent over that specified in the CRL file. 75

84 Item CRL URL Description Type the URL of the CRL distribution point. This item is available when the Enable CRL Checking check box is selected. Note that when the URL of the CRL distribution point is not set, you should acquire the CA certificate and a local certificate, and then acquire a CRL through SCEP. TIP: This item does not support domain name resolution. Return to Configuration task list for requesting a certificate manually. Return to Configuration task list for requesting a certificate automatically. Generating an RSA key pair Select Security > PKI > Certificate from the navigation tree to display existing PKI certificates, as shown in Figure 75. Click Create Key to enter the RSA key pair generation page, as shown in Figure 76. Figure 75 Certificate list Figure 76 RSA key pair generation page Table 31 Configuration items for generating an RSA key pair Item Key Length Description Type the length of the RSA keys. Return to Configuration task list for requesting a certificate manually. 76

85 Destroying the RSA key pair Select Security > PKI > Certificate from the navigation tree to display existing PKI certificates, as shown in Figure 75. Click Destroy Key to enter the RSA key pair destruction page, as shown in Figure 77. Then, click Apply to destroy the existing RSA key pair and the corresponding local certificate. Figure 77 RSA key pair destruction page Return to Configuration task list for requesting a certificate manually. Return to Configuration task list for requesting a certificate automatically. Retrieving and displaying a certificate You can download an existing CA certificate or local certificate from the CA server and save it locally. To do so, you can use two ways: online and offline. In offline mode, you need to retrieve a certificate by an out-of-band means like FTP, disk, and then import it into the local PKI system. Select Security > PKI > Certificate from the navigation tree to display existing PKI certificates, as shown in Figure 75. Click Retrieve Cert to enter the PKI certificate retrieval page, as shown in Figure 78. Figure 78 PKI certificate retrieval page Table 32 Configuration items for retrieving a PKI certificate Item Domain Name Certificate Type Enable Offline Mode Get File From Device Get File From PC Description Select the PKI domain for the certificate. Select the type of the certificate to be retrieved, which can be CA or local. Select this check box to retrieve a certificate in offline mode (that is, by an out-of-band means like FTP, disk, or ) and then import the certificate into the local PKI system. Specify the path and name of the certificate file. If the certificate file is saved on the LB module, select Get File From Device and then specify the path of the file on the LB module. If the certificate file is saved on a local PC, select Get File From PC and. then specify the path to the file and select the partition of the LB module for saving the file. 77

86 Item Password Description Enter the password for protecting the private key, which was specified when the certificate was exported. After retrieving a certificate, you can click View Cert corresponding to the certificate from the PKI certificates list to display the contents of the certificate, as shown in Figure 79. Figure 79 Certificate details Return to Configuration task list for requesting a certificate manually. Return to Configuration task list for requesting a certificate automatically. Requesting a local certificate Select Security > PKI > Certificate from the navigation tree to display existing PKI certificates, as shown in Figure 75. Click Request Cert to enter the local certificate request page, as shown in Figure 80. Figure 80 Local certificate request page Table 33 Configuration items for requesting a local certificate Item Domain Name Description Select the PKI domain for the certificate. 78

87 Item Password Enable Offline Mode Description Type the password for certificate revocation. Select this check box to request a certificate in offline mode, that is, by an out-of-band means like FTP, disk, or . If you cannot request a certificate from the CA through the SCEP protocol, you can enable the offline mode. In this case, after clicking Apply, the offline certificate request information page appears, as shown in Figure 81. Submit the information to the CA to request a local certificate. Figure 81 Offline certificate request information page Return to Configuration task list for requesting a certificate manually. Retrieving and displaying a crl Select Security > PKI > CRL from the navigation tree to display CRLs, as shown in Figure 82. Figure 82 CRL Click Retrieve CRL to retrieve the CRL of a domain. Then, click View CRL for the domain to display the contents of the CRL, as shown in Figure

88 Figure 83 CRL details Return to Configuration task list for requesting a certificate manually. Return to Configuration task list for requesting a certificate automatically. PKI configuration examples Configuring a PKI entity to request a certificate from a CA (method I) 1. Network requirements As shown in Figure 84, configure the LB module to work as the PKI entity, so that: The LB module submits a local certificate request to the CA server, which runs Windows 2003 server operating system. The LB module acquires CRLs for certificate verification. Figure 84 Network diagram for configuring a PKI entity to request a certificate from a CA 2. Configure the CA server # Install the CA server component. From the start menu, select Control Panel > Add or Remove Programs, and then select Add/Remove Windows Components. Then in the pop-up dialog box, select Certificate Services and click Next to begin 80

89 the installation. # Install the SCEP add-on. Because a CA server running Windows 2003 server operating system does not support SCEP by default, it is required to install the SCEP add-on to provide the LB module with automatic certificate registration and retrieval. After the add-on is installed, a prompt dialog box appears, displaying the URL of the registration server configured on the LB module. # Modify the certificate service properties. From the start menu, select Control Panel > Administrative Tools > Certificate Authority. If the CA server and SCEP add-on have been installed successfully, there should be two certificates issued by the CA to the RA. Right-click CA server and select Properties from the shortcut menu, and select the Policy Module tab in the CA server Properties dialog box. Select the option of Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate. Then click OK. # Modify the IIS attributes. From the start menu, select Control Panel > Administrative Tools > Internet Information Services (IIS) Manager and then select Web Sites from the navigation tree. Right-click Default Web Site and select Properties. Then select the Home Directory tab. Specify the path for certificate service in the Local path text box. Besides, to avoid conflicts with existing services, it is recommended to change the TCP port number to an unused one on the Web Site tab. After the above configuration, it is also required to ensure that the system clock of the LB module and that of the CA are synchronized, so that the LB module can request certificate correctly. 3. Configure the LB module # Create a PKI entity Select Security > PKI > Entity from the navigation tree and then click Add to perform the configurations shown in Figure 85. Figure 85 Add a PKI entity Type aaa as the PKI entity name. Type LB as the common name. 81

90 Click Apply. # Create a PKI domain. Select Security > PKI > Domain from the navigation tree and then click Add to perform the configurations shown in Figure 86. Figure 86 Add a PKI domain Type torsa as the PKI domain name. Type CA server as the CA identifier. Select aaa as the local entity. Select RA as the authority for certificate request. Type as the URL for certificate request. The URL must be in the format of where host and port are the host address and port number of the CA server. Select Manual as the certificate request mode. Click Apply. The system displays Fingerprint of the root certificate not specified. No root certificate validation will occur. Continue? Click OK to confirm. # Generate an RSA key pair. Select Security > PKI > Certificate from the navigation tree and then click Create Key to perform the configurations shown in Figure 87. Figure 87 Generate an RSA key pair 82

91 Click Apply to generate an RSA key pair. # Retrieve the CA certificate. Select Security > PKI > Certificate from the navigation tree and then click Retrieve Cert to perform the configurations shown in Figure 88. Figure 88 Retrieve the certificate Select torsa as the PKI domain. Select CA as the certificate type. Click Apply. # Request a local certificate. Select Security > PKI > Certificate from the navigation tree and then click Request Cert to perform the configurations shown in Figure 89. Figure 89 Request a certificate Select torsa as the PKI domain. Select Password and then type challenge-word as the password. Click Apply. When the system displays Certificate request has been submitted, click OK to confirm. 4. Verify the configuration After the above configuration, select Security > PKI > Certificate from the navigation tree, and then click View Cert corresponding to the certificate of PKI domain torsa to view the certificate details, as shown in Figure 90. You can also click View Cert corresponding to the CA certificate of PKI domain torsa to view the CA certificate details. 83

92 Figure 90 Detailed information about the local certificate 84

93 Configuring a PKI entity to request a certificate from a CA (method II) 1. Network requirements As shown in Figure 91, configure the LB module working as the PKI entity, so that: The LB module submits a local certificate request to the CA server, which runs the RSA Keon software. The LB module acquires CRLs for certificate verification. Figure 91 Network diagram for configuring a PKI entity to request a certificate from a CA 2. Configure the CA server # Create a CA server named myca. In this example, you need to configure the basic attributes of Nickname and Subject DN on the CA server at first: Nickname Name of the trusted CA Subject DN DN information of the CA, including the Common Name (CN) Organization Unit (OU) Organization (O) Country (C) The other attributes may use the default values. # Configure extended attributes After configuring the basic attributes, you need to perform configuration on the Jurisdiction Configuration page of the CA server. This includes selecting the proper extension profiles, enabling the SCEP autovetting function, and adding the IP address list for SCEP autovetting. # Configure the CRL publishing behavior After completing the above configuration, you need to perform CRL related configurations. In this example, select the local CRL publishing mode of HTTP and set the HTTP URL to After the above configuration, make sure that the system clock of the LB module is synchronous to that of the CA, so that the LB module can request certificates and retrieve CRLs properly. 3. Configure the LB module # Create a PKI entity. Select Security > PKI > Entity from the navigation tree and then click Add to perform the configurations shown in Figure

94 Figure 92 Add a PKI entity Type aaa as the PKI entity name. Type LB as the common name. Click Apply. # Create a PKI domain. Select Security > PKI > Domain from the navigation tree and then click Add to perform the configurations shown in Figure

95 Figure 93 Add a PKI domain Type torsa as the PKI domain name. Type myca as the CA identifier. Select aaa as the local entity. Select CA as the authority for certificate request. Type as the URL for certificate request. The URL must be in the format of Jurisdiction ID, where Issuing Jurisdiction ID is a hexadecimal string generated on the CA. Select Manual as the certificate request mode. Click the expansion button before Advanced Configuration to display the advanced configuration items. Select the Enable CRL Checking check box. Type as the CRL URL. Click Apply. When the system displays Fingerprint of the root certificate not specified. No root certificate validation will occur. Continue?, click OK to confirm. # Generate an RSA key pair. Select Security > PKI > Certificate from the navigation tree and then click Create Key to perform the configurations shown in Figure

96 Figure 94 Generate an RSA key pair Click Apply to generate an RSA key pair. # Retrieve the CA certificate. Select Security > PKI > Certificate from the navigation tree and then click Retrieve Cert to perform the configurations shown in Figure 95. Figure 95 Retrieve the certificate Select torsa as the PKI domain. Select CA as the certificate type. Click Apply. # Request a local certificate. Select Security > PKI > Certificate from the navigation tree and then click Request Cert to perform the configurations shown in Figure 96. Figure 96 Request a certificate Select torsa as the PKI domain. Select Password and then type challenge-word as the password. Click Apply. When the system displays Certificate request has been submitted, click OK to confirm. # Retrieve the CRL. 88

97 After retrieving a local certificate, select Security > PKI > CRL from the navigation tree. Figure 97 Retrieve CRL Click Retrieve CRL of the PKI domain of torsa. 4. Verify the configuration After the above configuration, select Security > PKI > Certificate from the navigation tree to view detailed information about the retrieved CA certificate and local certificate, or select Security > PKI > CRL from the navigation tree to view detailed information about the retrieved CRL. Configuring PKI in the CLI PKI configuration task list Complete the following tasks to configure PKI: Task Configuring an entity DN Configuring a PKI domain Submitting a PKI certificate request Retrieving a certificate manually Configuring PKI certificate verification Destroying a local RSA key pair Deleting a certificate Configuring an access control policy Submitting a Certificate Request in Auto Mode Submitting a certificate request in manual mode Remarks Required Required Required Use either approach Configuring an entity DN A certificate is the binding of a public key and the identity information of an entity, where the identity information is identified by an entity distinguished name (DN). A CA identifies a certificate applicant uniquely by entity DN. An entity DN is defined by these parameters: Common name of the entity. Country code of the entity, a standard 2-character code. For example, CN represents China and US represents the United States of America. Fully qualified domain name (FQDN) of the entity, a unique identifier of an entity on the network. It consists of a host name and a domain name and can be resolved to an IP address. For example, is an FQDN, where www is a host name and whatever.com a domain name. 89

98 IP address of the entity. Locality where the entity resides. Organization to which the entity belongs. Unit of the entity in the organization. State where the entity resides. NOTE: The configuration of an entity DN must comply with the CA certificate issue policy. You need to determine, for example, which entity DN parameters are mandatory and which are optional. Otherwise, certificate request may be rejected. Follow these steps to configure an entity DN: To do Use the command Remarks Enter system view system-view Create an entity and enter its view Configure the common name for the entity Configure the country code for the entity Configure the FQDN for the entity Configure the IP address for the entity Configure the locality of the entity Configure the organization name for the entity Configure the unit name for the entity Configure the state or province for the entity pki entity entity-name common-name name country country-code-str fqdn name-str ip ip-address locality locality-name organization org-name organization-unit org-unit-name state state-name Required No entity exists by default. No common name is specified by default. No country code is specified by default. No FQDN is specified by default. No IP address is specified by default. No locality is specified by default. No organization is specified by default. No unit is specified by default. No state or province is specified by default. NOTE: Up to two entities can be created on a LB module. The Windows 2000 CA server has some restrictions on the data length of a certificate request. If the entity DN in a certificate request goes beyond a certain limit, the server will not respond to the certificate request. 90

99 Configuring a PKI domain Before requesting a PKI certificate, an entity needs to be configured with some enrollment information, which is referred to as a PKI domain. A PKI domain is intended only for convenience of reference by other applications like IKE and SSL, and has only local significance. A PKI domain is defined by these parameters: Trusted CA An entity requests a certificate from a trusted CA. Entity A certificate applicant uses an entity to provide its identity information to a CA. RA Generally, an independent RA is in charge of certificate request management. It receives the registration request from an entity, checks its qualification, and determines whether to ask the CA to sign a digital certificate. The RA only checks the application qualification of an entity; it does not issue any certificate. Sometimes, the registration management function is provided by the CA, in which case no independent RA is required. You are recommended to deploy an independent RA. URL of the registration server An entity sends a certificate request to the registration server through Simple Certification Enrollment Protocol (SCEP), a dedicated protocol for an entity to communicate with a CA. Polling interval and count After an applicant makes a certificate request, the CA may need a long period of time if it verifies the certificate request manually. During this period, the applicant needs to query the status of the request periodically to get the certificate as soon as possible after the certificate is signed. You can configure the polling interval and count to query the request status. IP address of the LDAP server An LDAP server is usually deployed to store certificates and CRLs. If this is the case, you need to configure the IP address of the LDAP server. Fingerprint for root certificate verification Upon receiving the root certificate of the CA, an entity needs to verify the fingerprint of the root certificate, namely, the hash value of the root certificate content. This hash value is unique to every certificate. If the fingerprint of the root certificate does not match the one configured for the PKI domain, the entity will reject the root certificate. Follow these steps to configure a PKI domain: To do Use the command Remarks Enter system view system-view Create a PKI domain and enter its view Specify the trusted CA Specify the entity for certificate request pki domain domain-name ca identifier name certificate request entity entity-name Required No PKI domain exists by default. Required No trusted CA is specified by default. Required No entity is specified by default. The specified entity must exist. 91

100 To do Use the command Remarks Specify the authority for certificate request Configure the URL of the server for certificate request Configure the polling interval and attempt limit for querying the certificate request status Specify the LDAP server Configure the fingerprint for root certificate verification certificate request from { ca ra } certificate request url url-string certificate request polling { count count interval minutes } ldap-server ip ip-address [ port port-number ] [ version version-number ] root-certificate fingerprint { md5 sha1 } string Required No authority is specified by default. Required No URL is configured by default. The polling is executed for up to 50 times at the interval of 20 minutes by default. No LDP server is specified by default. Required when the certificate request mode is auto and optional when the certificate request mode is manual. In the latter case, if you do not configure this command, the fingerprint of the root certificate must be verified manually. No fingerprint is configured by default. NOTE: Up to two PKI domains can be created on a LB module. The CA name is required only when you retrieve a CA certificate. It is not used when in local certificate request. The URL of the server for certificate request does not support domain name resolving. Submitting a PKI certificate request When requesting a certificate, an entity introduces itself to the CA by providing its identity information and public key, which will be the major components of the certificate. A certificate request can be submitted to a CA in two ways: online and offline. In offline mode, a certificate request is submitted to a CA by an out-of-band means such as phone, disk, or . Online certificate request falls into two categories: manual mode and auto mode. Submitting a Certificate Request in Auto Mode In auto mode, an entity automatically requests a certificate through the SCEP protocol when it has no local certificate or the present certificate is about to expire. Follow these steps to configure an entity to submit a certificate request in auto mode: To do Use the command Remarks Enter system view system-view Enter PKI domain view pki domain domain-name Set the certificate request mode to auto certificate request mode auto [ key-length key-length password { cipher simple } password ] * Required Manual by default 92

101 Submitting a certificate request in manual mode In manual mode, you need to retrieve a CA certificate, generate a local RSA key pair, and submit a local certificate request for an entity. The goal of retrieving a CA certificate is to verify the authenticity and validity of a local certificate. Generating an RSA key pair is an important step in certificate request. The key pair includes a public key and a private key. The private key is kept by the user, while the public key is transferred to the CA along with some other information. For more information about RSA key pair configuration, see the chapter Public key configuration. Follow these steps to submit a certificate request in manual mode: To do Use the command Remarks Enter system view system-view Enter PKI domain view pki domain domain-name Set the certificate request mode to manual certificate request mode manual Manual by default Return to system view quit Retrieve a CA certificate manually Generate a local RSA key pair Submit a local certificate request manually See Retrieving a certificate manually public-key local create rsa pki request-certificate domain domain-name [ password ] [ pkcs10 [ filename filename ] ] Required Required No local RSA or ECDSA key pair exists by default. Required NOTE: If a PKI domain already has a local certificate, creating an RSA key pair will result in inconsistency between the key pair and the certificate. To generate a new RSA key pair, delete the local certificate and then issue the public-key local create command. A newly created key pair will overwrite the existing one. If you perform the public-key local create command in the presence of a local RSA key pair, the system will ask you whether you want to overwrite the existing one. If a PKI domain has already a local certificate, you cannot request another certificate for it. This is to avoid inconsistency between the certificate and the registration information resulting from configuration changes. To request a new certificate, use the pki delete-certificate command to delete the existing local certificate and the CA certificate stored locally. When it is impossible to request a certificate from the CA through SCEP, you can save the request information by using the pki request-certificate domain command with the pkcs10 and filename keywords, and then send the file to the CA by an out-of-band means. Make sure the clocks of the entity and the CA are synchronous. Otherwise, the validity period of the certificate will be abnormal. The pki request-certificate domain configuration will not be saved in the configuration file. 93

102 Retrieving a certificate manually You can download an existing CA certificate, local certificate, or peer entity certificate from the CA server and save it locally. To do so, you can use two ways: online and offline. In offline mode, you need to retrieve a certificate by an out-of-band means like FTP, disk, and then import it into the local PKI system. Certificate retrieval serves two purposes: Locally store the certificates associated with the local security domain for improved query efficiency and reduced query count, Prepare for certificate verification. Before retrieving a local certificate in online mode, be sure to complete LDAP server configuration. Follow these steps to retrieve a certificate manually: To do Use the command Remarks Enter system view system-view Retrieve a certificate manually Online pki retrieval-certificate { ca local } domain domain-name Required Offline pki import-certificate { ca local } domain domain-name { der p12 pem } [ filename filename ] Use either command. CAUTION: If a PKI domain already has a CA certificate, you cannot retrieve another CA certificate for it. This is in order to avoid inconsistency between the certificate and registration information due to related configuration changes. To retrieve a new CA certificate, use the pki delete-certificate command to delete the existing CA certificate and local certificate first. The pki retrieval-certificate configuration will not be saved in the configuration file. Configuring PKI certificate verification A certificate needs to be verified before being used. Verifying a certificate is to check that the certificate is signed by the CA and that the certificate has neither expired nor been revoked. Before verifying a certificate, you need to retrieve the CA certificate. You can specify whether CRL checking is required in certificate verification. If you enable CRL checking, CRLs will be used in verification of a certificate. Configuring CRL-checking-enabled PKI certificate verification Follow these steps to configure CRL-checking-enabled PKI certificate verification: To do Use the command Remarks Enter system view system-view Enter PKI domain view pki domain domain-name Specify the URL of the CRL distribution point crl url url-string No CRL distribution point URL is specified by default. 94

103 To do Use the command Remarks Set the CRL update period Enable CRL checking crl update-period hours crl check enable By default, the CRL update period depends on the next update field in the CRL file. Enabled by default Return to system view quit Retrieve the CA certificate See Retrieving a certificate manually Required Retrieve CRLs pki retrieval-crl domain domain-name Required Verify the validity of a certificate pki validate-certificate { ca local } domain domain-name Required Configuring CRL-checking-disabled PKI certificate verification Follow these steps to configure CRL-checking-disabled PKI certificate verification: To do Use the command Remarks Enter system view system-view Enter PKI domain view pki domain domain-name Disable CRL checking crl check disable Required Enabled by default Return to system view quit Retrieve the CA certificate Verify the validity of the certificate See Retrieving a certificate manually pki validate-certificate { ca local } domain domain-name Required Required NOTE: The CRL update period refers to the interval at which the entity downloads CRLs from the CRL server. The CRL update period configured manually is prior to that specified in the CRLs. The pki retrieval-crl domain configuration will not be saved in the configuration file. The URL of the CRL distribution point does not support domain name resolving. Destroying a local RSA key pair A certificate has a lifetime, which is determined by the CA. When the private key leaks or the certificate is about to expire, you can destroy the old RSA key pair and then create a pair to request a new certificate. Follow these steps to destroy a local RSA key pair: To do Use the command Remarks Enter system view system-view Destroy a local RSA key pair public-key local destroy rsa Required 95

104 Deleting a certificate When a certificate requested manually is about to expire or you want to request a new certificate, you can delete the current local certificate or CA certificate. Follow these steps to delete a certificate: To do Use the command Remarks Enter system view system-view Delete certificates pki delete-certificate { ca local } domain domain-name Required Configuring an access control policy By configuring a certificate attribute-based access control policy, you can further control access to the server, providing additional security for the server. Follow these steps to configure a certificate attribute-based access control policy: To do Use the command Remarks Enter system view system-view Create a certificate attribute group and enter its view Configure an attribute rule for the certificate issuer name, certificate subject name, or alternative subject name pki certificate attribute-group group-name attribute id { alt-subject-name { fqdn ip } { issuer-name subject-name } { dn fqdn ip } } { ctn equ nctn nequ } attribute-value Required No certificate attribute group exists by default. There is no restriction on the issuer name, certificate subject name and alternative subject name by default. Return to system view quit Create a certificate attribute-based access control policy and enter its view Configure a certificate attribute-based access control rule pki certificate access-control-policy policy-name rule [ id ] { deny permit } group-name Required No access control policy exists by default. Required No access control rule exists by default. CAUTION: A certificate attribute group must exist to be associated with a rule. Displaying and maintaining PKI To do Use the command Remarks Display the contents or request status of a certificate display pki certificate { { ca local } domain domain-name request-status } Available in any view Display CRLs display pki crl domain domain-name Available in any view 96

105 To do Use the command Remarks Display information about one or all certificate attribute groups Display information about one or all certificate attribute-based access control policies display pki certificate attribute-group { group-name all } display pki certificate access-control-policy { policy-name all } Available in any view Available in any view PKI configuration examples NOTE: The SCEP add-on is required when you use the Windows Server as the CA. In this case, when configuring the PKI domain, you need to use the certificate request from ra command to specify that the entity requests a certificate from an RA. The SCEP add-on is not required when RSA Keon is used. In this case, when configuring a PKI domain, you need to use the certificate request from ca command to specify that the entity requests a certificate from a CA. Requesting a certificate from a CA running RSA Keon NOTE: The CA server runs RSA Keon in this configuration example. 1. Network requirements The LB module submits a local certificate request to the CA server. The LB module acquires the CRLs for certificate verification. Figure 98 Request a certificate from a CA running RSA Keon 2. Configure the CA server # Create a CA server named myca. In this example, you need to configure these basic attributes on the CA server at first: Nickname: Name of the trusted CA. Subject DN: DN information of the CA, including the Common Name (CN), Organization Unit (OU), Organization (O), and Country (C). The other attributes may be left using the default values. # Configure extended attributes. After configuring the basic attributes, you need to perform configuration on the jurisdiction configuration page of the CA server. This includes selecting the proper extension profiles, enabling the SCEP autovetting function, and adding the IP address list for SCEP autovetting. 97

106 # Configure the CRL distribution behavior. After completing the above configuration, you need to perform CRL related configurations. In this example, select the local CRL distribution mode of HTTP and set the HTTP URL to After the above configuration, make sure that the system clock of the LB module is synchronous to that of the CA, so that the LB module can request certificates and retrieve CRLs properly. 3. Configure the LB module Configure the entity DN # Configure the entity name as aaa and the common name as LB. <LB> system-view [LB] pki entity aaa [LB-pki-entity-aaa] common-name LB [LB-pki-entity-aaa] quit Configure the PKI domain # Create PKI domain torsa and enter its view. [LB] pki domain torsa # Configure the name of the trusted CA as myca. [LB-pki-domain-torsa] ca identifier myca # Configure the URL of the registration server in the format of Jurisdiction ID, where Issuing Jurisdiction ID is a hexadecimal string generated on the CA server. [LB-pki-domain-torsa] certificate request url # Set the registration authority to CA. [LB-pki-domain-torsa] certificate request from ca # Specify the entity for certificate request as aaa. [LB-pki-domain-torsa] certificate request entity aaa # Configure the URL for the CRL distribution point. [LB-pki-domain-torsa] crl url [LB-pki-domain-torsa] quit Generate a local key pair using RSA [LB] public-key local create rsa The range of public key size is (512 ~ 2048). NOTES: If the key modulus is greater than 512, It will take a few minutes. Press CTRL+C to abort. Input the bits in the modulus [default = 1024]: Generating Keys Apply for certificates # Retrieve the CA certificate and save it locally. 98

107 [LB] pki retrieval-certificate ca domain torsa Retrieving CA/RA certificates. Please wait a while... The trusted CA's finger print is: MD5 fingerprint:ede A273 B61A F1B A0B1 F9AB SHA1 fingerprint: 77F9 A077 2FB8 088C 550B A33C 2410 D354 23B2 73A8 Is the finger print correct?(y/n):y Saving CA/RA certificates chain, please wait a moment... CA certificates retrieval success. # Retrieve CRLs and save them locally. [LB] pki retrieval-crl domain torsa Connecting to server for retrieving CRL. Please wait a while... CRL retrieval success! # Request a local certificate manually. [LB] pki request-certificate domain torsa challenge-word Certificate is being requested, please wait... [LB] Enrolling the local certificate,please wait a while... Certificate request Successfully! Saving the local certificate to device... Done! 4. Verify your configuration # Use the following command to view information about the local certificate acquired. <LB> display pki certificate local domain torsa Certificate: Data: Version: 3 (0x2) Serial Number: 9A96A48F 9A509FD7 05FFF4DF 104AD094 Signature Algorithm: sha1withrsaencryption Issuer: C=cn O=org OU=test CN=myca Validity Not Before: Jan 8 09:26: GMT Not After : Jan 8 09:26: GMT Subject: CN=LB Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00D67D F6A CA6C4B11 F8F89138 E4E905BD 43953BA2 623A54C0 99

108 EA3CB6E0 B04649CE C9CDDD E96D9 FF4F7B73 A E583AC61 D3A5C849 CBDE350D 2A1926B7 0AE5EF5E D1D8B08A DBF C2A F EB0549 A65D9E74 0F2953F2 D4F0042F D4F FB59F3 8D4B2F6C 2B Exponent: (0x10001) X509v3 extensions: X509v3 CRL Distribution Points: URI: Signature Algorithm: sha1withrsaencryption A4 F2F74C1A 50F4100D B764D6CE B30C0133 C4363F2F 73454D51 E9F95962 EDE9E590 E7458FA6 765A0D3F C4047BC2 9C391FF0 7383C4DF 9A0CCFA AF 987B029C C857AD96 E4C E798 8FCC1E4A 3E598D E2F86C33 75B51661 B6556C5E 8F546E B C8C29AC7 E427C8E4 B9AAF5AA 80A75B3C You can also use some other display commands, including the display pki certificate ca domain and display pki crl domain commands, to view detailed information about the CA certificate and CRLs. Requesting a certificate from a CA running Windows 2003 server NOTE: The CA server runs the Windows 2003 server in this configuration example. 1. Network requirements Configure PKI entity LB to request a local certificate from the CA server. Figure 99 Request a certificate from a CA running Windows 2003 server 2. Configure the CA server Install the certificate service suites From the start menu, select Control Panel > Add or Remove Programs, and then select Add/Remove Windows Components > Certificate Services and click Next to begin the installation. Install the SCEP add-on As a CA server running the Windows 2003 server does not support SCEP by default, you need to install the SCEP add-on so that the LB module can register and obtain its certificate automatically. After the SCEP add-on installation completes, a URL is displayed, which you need to configure on the LB moduleas the URL of the server for certificate registration. 100

109 Modify the certificate service attributes From the start menu, select Control Panel > Administrative Tools > Certificate Authority. If the CA server and SCEP add-on have been installed successfully, there should be two certificates issued by the CA to the RA. Right-click on the CA server in the navigation tree and select Properties > Policy Module. Click Properties and then select Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate. Modify the Internet Information Services (IIS) attributes From the start menu, select Control Panel > Administrative Tools > Internet Information Services (IIS) Manager and then select Web Sites from the navigation tree. Right-click on Default Web Site and select Properties > Home Directory. Specify the path for certificate service in the Local path text box. In addition, you are recommended to specify an available port number as the TCP port number of the default website to avoid conflict with existing services. After completing the above configuration, check that the system clock of the LB module is synchronous to that of the CA server, ensuring that the LB module can request a certificate normally. 3. Configure the LB module Configure the entity DN # Configure the entity name as aaa and the common name as LB. <LB> system-view [LB] pki entity aaa [LB-pki-entity-aaa] common-name LB [LB-pki-entity-aaa] quit Configure the PKI domain # Create PKI domain torsa and enter its view. [LB] pki domain torsa # Configure the name of the trusted CA as myca. [LB-pki-domain-torsa] ca identifier myca # Configure the URL of the registration server in the format of certsrv/mscep/mscep.dll, where host:port indicates the IP address and port number of the CA server. [LB-pki-domain-torsa] certificate request url # Set the registration authority to RA. [LB-pki-domain-torsa] certificate request from ra # Specify the entity for certificate request as aaa. [LB-pki-domain-torsa] certificate request entity aaa Generate a local key pair using RSA [LB] public-key local create rsa The range of public key size is (512 ~ 2048). NOTES: If the key modulus is greater than 512, It will take a few minutes. Press CTRL+C to abort. Input the bits in the modulus [default = 1024]: Generating Keys

110 Apply for certificates # Retrieve the CA certificate and save it locally. [LB] pki retrieval-certificate ca domain torsa Retrieving CA/RA certificates. Please wait a while... The trusted CA's finger print is: MD5 fingerprint:766c D2C8 9E46 845B 4DCE 439C 1C1F 83AB SHA1 fingerprint:97e5 DDED AB FB DB5C E7F8 D7D7 7C9B 97B4 Is the finger print correct?(y/n):y Saving CA/RA certificates chain, please wait a moment... CA certificates retrieval success. # Request a local certificate manually. [LB] pki request-certificate domain torsa challenge-word Certificate is being requested, please wait... [LB] Enrolling the local certificate,please wait a while... Certificate request Successfully! Saving the local certificate to device... Done! 4. Verify your configuration # Use the following command to view information about the local certificate acquired. <LB> display pki certificate local domain torsa Certificate: Data: Version: 3 (0x2) Serial Number: 48FA0FD C Signature Algorithm: sha1withrsaencryption Issuer: CN=myca Validity Not Before: Nov 21 12:32: GMT Not After : Nov 21 12:42: GMT Subject: CN=LB Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00A6637A 8CDEA1AC B2E04A59 F7F6A9FE 5AEE52AE 14A392E4 E0E5D458 0D BF91E57 FA8C67AC 6CE8FEBB B 10242FDD D3947F5E 2DA70BD9 1FAF07E5 1D167CE1 FC20394F 476F5C08 C5067DF9 102

111 CB4D05E6 55DC11B6 9F4C014D EA D403CF 2D93BC5A 8AF3224D 1125E439 78ECEFE1 7FA9AE7B 877B50B F 6B Exponent: (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: B68E D7C44C 7ABCE3BA 9BF385F8 A448F4E1 X509v3 Authority Key Identifier: keyid:9d EADFEFA2 4A663E75 F416B6F6 D41EE4FE X509v3 CRL Distribution Points: URI: URI:file://\\l00192b\CertEnroll\CA server.crl Authority Information Access: CA Issuers - URI: CA Issuers - URI:file://\\l00192b\CertEnroll\l00192b_CA server.crt :.0.I.P.S.E.C.I.n.t.e.r.m.e.d.i.a.t.e.O.f.f.l.i.n.e Signature Algorithm: sha1withrsaencryption BFA1CBD B068840B (Omitted) You can also use some other display commands, for example, the display pki certificate ca domain command, to view detailed information about the CA certificate. Applying RSA digital signature in IKE negotiation 1. Network requirements An IPsec tunnel is set up between LB A and LB B to secure the traffic between Host A on subnet /24 and Host B on subnet /24. LB A and LB B use IKE for IPsec tunnel negotiation and RSA digital signature of a PKI certificate system for identity authentication. As shown in Figure 100, LB A and LB B use different CAs. They may also use the same CA as required. 103

112 Figure 100 Apply RSA digital signature in IKE negotiation 2. Configure LB A # Configure the entity DN. <LB A> system-view [LB A] pki entity en [LB A-pki-entity-en] ip [LB A-pki-entity-en] common-name LB A [LB A-pki-entity-en] quit # Configure the PKI domain. Note that the URL of the registration server varies with the CA server. [LB A] pki domain 1 [LB A-pki-domain-1] ca identifier CA1 [LB A-pki-domain-1] certificate request url [LB A-pki-domain-1] certificate request entity en [LB A-pki-domain-1] ldap-server ip # Set the registration authority to RA. [LB A-pki-domain-1] certificate request from ra # Configure the CRL distribution URL. This is not necessary if CRL checking is disabled. [LB A-pki-domain-1] crl url ldap:// [LB A-pki-domain-1] quit # Create a local key pair using RSA. [LB A] public-key local create rsa # Request a certificate. 104

113 [LB A] pki retrieval-certificate ca domain 1 [LB A] pki retrieval-crl domain 1 [LB A] pki request-certificate domain 1 # Configure IKE proposal 1, using RSA signature for identity authentication. [LB A] ike proposal 1 [LB A-ike-proposal-1] authentication-method rsa-signature [LB A-ike-proposal-1] quit # Specify the PKI domain for the IKE peer. [LB A] ike peer peer [LB A-ike-peer-peer] certificate domain 1 3. Configure LB B # Configure the entity DN. <LB B> system-view [LB B] pki entity en [LB B-pki-entity-en] ip [LB B-pki-entity-en] common-name LB B [LB B-pki-entity-en] quit # Configure the PKI domain. Note that the URL of the registration server varies with the CA server. [LB B] pki domain 1 [LB B-pki-domain-1] ca identifier CA2 [LB B-pki-domain-1] certificate request url [LB B-pki-domain-1] certificate request entity en [LB B-pki-domain-1] ldap-server ip # Set the registration authority to RA. [LB B-pki-domain-1] certificate request from ra # Configure the CRL distribution URL. This is not necessary if CRL checking is disabled. [LB B-pki-domain-1] crl url ldap:// [LB B-pki-domain-1] quit # Create a local key pair using RSA. [LB B] public-key local create rsa # Request a certificate. [LB B] pki retrieval-certificate ca domain 1 [LB B] pki retrieval-crl domain 1 [LB B] pki request-certificate domain 1 # Configure IKE proposal 1, using RSA signature for identity authentication. [LB B] ike proposal 1 [LB B-ike-proposal-1] authentication-method rsa-signature [LB B-ike-proposal-1] quit # Specify the PKI domain for the IKE peer. [LB B] ike peer peer [LB B-ike-peer-peer] certificate domain 1 105

114 NOTE: The above configuration procedure covers only the configurations for IKE negotiation using RSA digital signature. For an IPsec tunnel to be established, you also need to perform IPsec configurations. For information about IPsec configuration, see the chapter IPsec configuration. Configuring a certificate attribute-based access control policy 1. Network requirements The client accesses the remote HTTP Security (HTTPS) server through the HTTPS protocol. SSL is configured to ensure that only legal clients log into the HTTPS server. Create a certificate attribute-based access control policy to control access to the HTTPS server. Figure 101 Configure a certificate attribute-based access control policy NOTE: For more information about SSL configuration, see the chapter SSL configuration. For more information about HTTPS configuration, see System Management Configuration Guide. The PKI domain to be referenced by the SSL policy must be created in advance. For more information about PKI domain configuration, see Configure the PKI domain. 2. Configure the HTTPS server # Configure the SSL policy for the HTTPS server to use. <LB> system-view [LB] ssl server-policy myssl [LB-ssl-server-policy-myssl] pki-domain 1 [LB-ssl-server-policy-myssl] client-verify enable [LB-ssl-server-policy-myssl] quit 3. Configure the certificate attribute group # Create certificate attribute group mygroup1 and add two attribute rules. The first rule defines that the DN of the subject name includes the string aabbcc, and the second rule defines that the IP address of the certificate issuer is [LB] pki certificate attribute-group mygroup1 [LB-pki-cert-attribute-group-mygroup1] attribute 1 subject-name dn ctn aabbcc [LB-pki-cert-attribute-group-mygroup1] attribute 2 issuer-name ip equ [LB-pki-cert-attribute-group-mygroup1] quit # Create certificate attribute group mygroup2 and add two attribute rules. The first rule defines that the FQDN of the alternative subject name does not include the string of apple, and the second rule defines that the DN of the certificate issuer name includes the string aabbcc. 106

115 [LB] pki certificate attribute-group mygroup2 [LB-pki-cert-attribute-group-mygroup2] attribute 1 alt-subject-name fqdn nctn apple [LB-pki-cert-attribute-group-mygroup2] attribute 2 issuer-name dn ctn aabbcc [LB-pki-cert-attribute-group-mygroup2] quit 4. Configure the certificate attribute-based access control policy # Create the certificate attribute-based access control policy of myacp and add two access control rules. [LB] pki certificate access-control-policy myacp [LB-pki-cert-acp-myacp] rule 1 deny mygroup1 [LB-pki-cert-acp-myacp] rule 2 permit mygroup2 [LB-pki-cert-acp-myacp] quit 5. Apply the SSL server policy and certificate attribute-based access control policy to HTTPS service and enable HTTPS service. # Apply SSL server policy myssl to HTTPS service. [LB] ip https ssl-server-policy myssl # Apply the certificate attribute-based access control policy of myacp to HTTPS service. [LB] ip https certificate access-control-policy myacp # Enable HTTPS service. [LB] ip https enable Troubleshooting PKI Failed to retrieve a CA certificate Symptom Analysis Solution Failed to retrieve a CA certificate. Possible reasons include these: The network connection is not proper. For example, the network cable may be damaged or loose. No trusted CA is specified. The URL of the registration server for certificate request is not correct or not configured. No authority is specified for certificate request. The system clock of the LB module is not synchronized with that of the CA. Make sure that the network connection is physically proper. Check that the required commands are configured properly. Use the ping command to check that the RA server is reachable. Specify the authority for certificate request. Synchronize the system clock of the LB module with that of the CA. 107

116 Failed to request a Local certificate Symptom Failed to request a local certificate. Analysis Possible reasons include these: The network connection is not proper. For example, the network cable may be damaged or loose. No CA certificate has been retrieved. The current key pair has been bound to a certificate. No trusted CA is specified. The URL of the registration server for certificate request is not correct or not configured. No authority is specified for certificate request. Some required parameters of the entity DN are not configured. Solution Make sure that the network connection is physically proper. Retrieve a CA certificate. Regenerate a key pair. Specify a trusted CA. Use the ping command to check that the RA server is reachable. Specify the authority for certificate request. Configure the required entity DN parameters. Failed to retrieve CRLs Symptom Failed to retrieve CRLs. Analysis Possible reasons include these: The network connection is not proper. For example, the network cable may be damaged or loose. No CA certificate has been retrieved before you try to retrieve CRLs. The IP address of LDAP server is not configured. The CRL distribution URL is not configured. The LDAP server version is wrong. Solution Make sure that the network connection is physically proper. Retrieve a CA certificate. Specify the IP address of the LDAP server. Specify the CRL distribution URL. Re-configure the LDAP version. 108

117 Configuration guidelines When you configure PKI, note the following guidelines: Make sure the clocks of entities and the CA are synchronous. Otherwise, the validity period of certificates will be abnormal. The Windows 2000 CA server has some restrictions on the data length of a certificate request. If the PKI entity identity information in a certificate request goes beyond a certain limit, the server will not respond to the certificate request. The SCEP add-on is required when you use the Windows Server as the CA. In this case, you need to specify RA as the authority for certificate request when configuring the PKI domain. The SCEP add-on is not required when you use the RSA Keon software as the CA. In this case, you need to specify CA as the authority for certificate request when configuring the PKI domain. 109

118 Public key configuration NOTE: The LB module supports public key configuration at the CLI. Overview To protect data confidentiality during transmission, the data sender uses an algorithm and a key to encrypt the plain text data before sending the data out, and the receiver uses the same algorithm with the help of a key to decrypt the data, as shown in Figure 102. Figure 102 Encryption and decryption The keys that participate in the conversion between the plain text and the cipher text can be the same or different, dividing the encryption and decryption algorithms into the following types: Symmetric key algorithm The keys for encryption and decryption are the same. Asymmetric key algorithm The keys for encryption and decryption are different, one is the public key, and the other is the private key. The information encrypted with the public key can only be decrypted with the corresponding private key, and vice versa. The private key is kept secret, and the public key may be distributed widely. The private key cannot be practically derived from the public key. Asymmetric key algorithms include the Revest-Shamir-Adleman Algorithm (RSA), the Digital Signature Algorithm (DSA), and the Elliptic Curve Digital Signature Algorithm (ECDSA). The LB module supports RSA algorithm only. Asymmetric key algorithms can be used in two scenarios for two purposes: To encrypt and decrypt data The sender uses the public key of the intended receiver to encrypt the information to be sent. Only the intended receiver, the holder of the paired private key, can decrypt the information. This mechanism ensures confidentiality. To authenticate a sender Also called digital signature. The sender "signs" the information to be sent by encrypting the information with its own private key. A receiver decrypts the information with the sender's public key and, based on whether the information can be decrypted, determines the authenticity of the information. RSA can be used for data encryption and decryption, and digital signature. Asymmetric key algorithms are widely used in various applications. For example, Secure Shell (SSH), Secure Sockets Layer (SSL), and Public Key Infrastructure (PKI) use the algorithms for digital signature. 110

119 Public key configuration task list The configuration tasks enable you to manage the local asymmetric key pairs, and configure the peer host public keys on the local device. By completing these tasks, your host is ready to work with applications such as SSH and SSL to implement data encryption/decryption, or digital signature. Complete these tasks to configure public keys: Task Configuring a local asymmetric key pair on the local device Creating a local asymmetric key pair Displaying or exporting the local host public key Destroying a local asymmetric key pair Remarks Required Specifying the peer public key on the local device Configuring a local asymmetric key pair on the local device Creating a local asymmetric key pair Configuration guidelines When you create an asymmetric key pair on the local device, follow these guidelines: Create an asymmetric key pair of the proper type to work with a target application. After you enter the command, specify a proper modulus length for the key pair. The following table describes the RSA key pairs. Table 34 RSA key pairs Type Number of key pairs Modulus length Remarks RSA Two key pairs, one server key pair and one host key par. Each key pair comprises a public key and a private key 512 to 2048 bits 1024 by default To achieve high security, specify at least 768 bits. IMPORTANT: Only SSH1.5 uses the RSA server key pair. Configuration procedure Follow these steps to create a local asymmetric key pair: To do Use the command Remarks Enter system view system-view Create a local asymmetric key pair public-key local create rsa Required By default, no asymmetric key pair is created. 111

120 NOTE: Key pairs created with the public-key local create rsa command are saved automatically and can survive system reboots. Displaying or exporting the local host public key In SSH, to allow your local device to be authenticated by a peer device through digital signature, you must display or export the host public key of the local asymmetric key pair, which will then be specified on the peer device. To display or export the host public key of a local asymmetric key pair, choose one of the following methods: Displaying and recording the host public key information Displaying the host public key in a specified format and saving it to a file Exporting the host public key in a specified format to a file If your local device functions to authenticate the peer device, you must specify the peer public key on the local device. For more information, see "Specifying the peer public key on the local device." Displaying and recording the host public key information After you display the host public key, record the key information for manually configuration of the key on the peer device. Follow the step to display the public key of the local asymmetric key pair: To do Use the command Remarks Display the public keys of the local RSA key pairs display public-key local rsa public Required Available in any view. NOTE: The display public-key local rsa public command displays both the RSA server and host public keys. Recording the RSA host public key is enough. Displaying the host public key in a specified format and saving it to a file After you display the host public key in a specify format, save the key to a file, and transfer this file to the peer device. Follow these steps to display the host public key of a local asymmetric key pair in a specified format: To do Use the command Remarks Enter system view system-view Display the host public key of the local RSA key pairs in a specified format public-key local export rsa { openssh ssh1 ssh2 } Required Exporting the host public key in a specified format to a file After you export and save the host public key in a specify format to a file, transfer the file to the peer device. Follow these steps to export and save the host public key of a local asymmetric key pair to a file: 112

121 To do Use the command Remarks Enter system view system-view Export and save the host public key of the local RSA key pairs in a specific format to a file public-key local export rsa { openssh ssh1 ssh2 } filename Required Destroying a local asymmetric key pair You may need to destroy a local asymmetric key pair and generate a new pair when an intrusion event has occurred, the storage media of the device is replaced, the asymmetric key has been used for a long time, or the local certificate expires. For more information about the local certificate, see the chapter PKI configuration. Follow these steps to destroy a local asymmetric key pair: To do Use the command Remarks Enter system view system-view Destroy a local asymmetric key pair public-key local destroy rsa Required Specifying the peer public key on the local device In SSH, to enable the local device to authenticate a peer device, specify the peer public key on the local device. Take one of the following methods: Method Prerequisites Remarks Import the public key from a public key file (recommended) 1. Save the host public key of the intended asymmetric key pair in a file. 2. Transfer a copy of the file through FTP or TFTP in binary mode to the local device. During the import process, the system automatically converts the public key to a string in Public Key Cryptography Standards (PKCS) format. Manually configure the public key input or copy the key data Display and record the public key of the intended asymmetric key pair. If the peer device is an HP device, use the display public-key local rsa public command to view and record its public key. A public key displayed by other methods for the HP device may not be in a correct format. The recorded public key must be in the correct format, or the manual configuration of a format-incompliant public key will fail. Always use the first method if you are not sure about the format of the recorded public key. NOTE: The device supports up to 20 peer public keys. For information about displaying or exporting the host public key, see "Displaying or exporting the local host public key." Follow these steps to import the host public key from a public key file to the local device: To do Use the command Remarks Enter system view system-view 113

122 To do Use the command Remarks Import the host public key from the public key file public-key peer keyname import sshkey filename Required Follow these steps to manually configure the peer public key on the local device: To do Use the command Remarks Enter system view system-view Specify a name for the public key and enter public key view public-key peer keyname Required Enter public key code view public-key-code begin Configure the peer public key Return to public key view Type or copy the key public-key-code end Required Spaces and carriage returns are allowed between characters. Required When you exit public key code view, the system automatically saves the public key. Return to system view peer-public-key end Displaying and maintaining public keys To do Use the command Remarks Display the public keys of the local asymmetric key pairs Display the specified or all peer public keys on the local device display public-key local rsa public display public-key peer [ brief name publickey-name ] Public key configuration examples Available in any view Manually specifying the peer public key on the local device Network requirements As shown in Figure 103, to prevent illegal access, LB B (the local device) authenticates LB A (the peer device) through a digital signature. Before configuring authentication parameters on LB B, configure the public key of LB A on LB B. Configure LB B to use the asymmetric key algorithm of RSA to authenticate LB A. Manually specify the host public key of LB A's public key pair on LB B. Figure 103 Network diagram for manually specifying a peer public key 114

123 Configuration procedure 1. Configure LB A # Create local RSA key pairs on LB A, setting the modulus length to the default, 1024 bits. <LBA> system-view [LBA] public-key local create rsa The range of public key size is (512 ~ 2048). NOTES: If the key modulus is greater than 512, It will take a few minutes. Press CTRL+C to abort. Input the bits of the modulus[default = 1024]: Generating Keys # Display the public keys of the local RSA key pairs. [LBA] display public-key local rsa public ===================================================== Time of Key pair created: 09:50: /08/07 Key name: HOST_KEY Key type: RSA Encryption Key ===================================================== Key code: 30819F300D06092A864886F70D D D90003FA95F5A44A2A2CD3F814F 9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C 669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA DC078B2B AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A ===================================================== Time of Key pair created: 09:50: /08/07 Key name: SERVER_KEY Key type: RSA Encryption Key ===================================================== Key code: 307C300D06092A864886F70D B E7AEE D9EB2D0433B87BB61 58E35000AFB3FF310E42F109829D65BF70F BE1A3E0BC5C2C03FAAF00DFDDC63D004B4490DACBA3 CFA9E84B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F Configure LB B # Configure the host public key of LB A's RSA key pairs on LB B. In public key code view, input the host public key of LB A. The host public key is the content of HOST_KEY displayed on LB A by using the display public-key local rsa public command. <LBB> system-view [LBB] public-key peer LBa Public key view: return to System View with "peer-public-key end". [DeviceB-pkey-public-key] public-key-code begin Public key code view: return to last view with "public-key-code end". 115

124 [LBB-pkey-key-code]30819F300D06092A864886F70D D D9 0003FA95F5A44A2A2CD3F814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E 5E353B3A9AB16C9E766BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB EA DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A [LBB-pkey-key-code] public-key-code end [LBB-pkey-public-key] peer-public-key end # Display the host public key of LB A saved on LB B. [LBB] display public-key peer name LBa ===================================== Key Name : devicea Key Type : RSA Key Module: 1024 ===================================== Key Code: 30819F300D06092A864886F70D D D90003FA95F5A44A2A2CD3F814F 9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C 669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA DC078B2B AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A The output shows that the host public key of LB A saved on LB B is consistent with the one created on LB A. Importing a public key from a public key file Network requirements As shown in Figure 104, to prevent illegal access, LB B (the local device) authenticates LB A (the peer device) through a digital signature. Before configuring authentication parameters on LB B, configure the public key of LB A on LB B. Configure LB B to use the asymmetric key algorithm of RSA to authenticate LB A. Import the host public key of LB A from the public key file to LB B. Figure 104 Network diagram for importing a peer public key from a public key file Configuration procedure 1. Create key pairs on LB A and export the host public key # Create local RSA key pairs on LB A, setting the modulus length to the default, 1024 bits. <LBA> system-view [LBA] public-key local create rsa The range of public key size is (512 ~ 2048). NOTES: If the key modulus is greater than 512, It will take a few minutes. Press CTRL+C to abort. Input the bits of the modulus[default = 1024]: 116

125 Generating Keys # Display the public keys of the local RSA key pairs. [LBA] display public-key local rsa public ===================================================== Time of Key pair created: 09:50: /08/07 Key name: HOST_KEY Key type: RSA Encryption Key ===================================================== Key code: 30819F300D06092A864886F70D D D90003FA95F5A44A2A2CD3F814F 9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C 669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA DC078B2B AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A ===================================================== Time of Key pair created: 09:50: /08/07 Key name: SERVER_KEY Key type: RSA Encryption Key ===================================================== Key code: 307C300D06092A864886F70D B E7AEE D9EB2D0433B87BB61 58E35000AFB3FF310E42F109829D65BF70F BE1A3E0BC5C2C03FAAF00DFDDC63D004B4490DACBA3 CFA9E84B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F # Export the RSA host public key HOST_KEY to a file named LBa.pub. [LBA] public-key local export rsa ssh2 LBa.pub 2. Enable the FTP server function on LB A # Enable the FTP server function, create an FTP user with the username ftp, password 123, and user level 3. This user level ensures that the user has the permission to perform FTP operations. [LBA] ftp server enable [LBA] local-user ftp [LBA-luser-ftp] password simple 123 [LBA-luser-ftp] service-type ftp [LBA-luser-ftp] authorization-attribute level 3 [LBA-luser-ftp] quit 3. On LB B, get the public key file of LB A # From LB B, use FTP to log in to LB A, and get the public key file LBa.pub with the file transfer mode of binary. <LBB> ftp Trying Press CTRL+K to abort Connected to FTP service ready. 117

126 User( :(none)):ftp 331 Password required for ftp. Password: 230 User logged in. [ftp] binary 200 Type set to I. [ftp] get LBa.pub 227 Entering Passive Mode (10,1,1,1,5,148). 125 BINARY mode data connection already open, transfer starting for /LBa.pub. 226 Transfer complete. FTP: 299 byte(s) received in second(s), 1.00Kbyte(s)/sec. [ftp] quit 221 Server closing. 4. Import the host public key of LB A to LB B # Import the host public key of LB A from the key file LBa.pub to LB B. <LBB> system-view [LBB] public-key peer LBa import sshkey LBa.pub # Display the host public key of LB A on LB B. [LBB] display public-key peer name LBa ===================================== Key Name : LBa Key Type : RSA Key Module: 1024 ===================================== Key Code: 30819F300D06092A864886F70D D D90003FA95F5A44A2A2CD3F814F 9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C 669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA DC078B2B AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A The output shows that the host public key of LB A saved on LB B is consistent with the one created on LB A. 118

127 SSL configuration NOTE: The LB module supports configuring SSL only in the command line interface. SSL overview Secure Sockets Layer (SSL) is a security protocol that provides secure connection services for TCP-based application layer protocols, for example, HTTP protocol. It is widely used in E-business and online bank fields to ensure secure data transmission over the Internet. SSL security mechanism Secure connections provided by SSL have these features: Confidentiality: SSL uses a symmetric encryption algorithm to encrypt data and uses the asymmetric key algorithm of Rivest, Shamir, and Adelman (RSA) to encrypt the key to be used by the symmetric encryption algorithm. Authentication: SSL supports certificate-based identity authentication of the server and client by using the digital signatures, where the authentication of the client is optional. The SSL server and client obtain certificates from a certificate authority (CA) through the Public Key Infrastructure (PKI). Reliability: SSL uses the key-based message authentication code (MAC) to verify message integrity. A MAC algorithm transforms a message of any length to a fixed-length message. Figure 105 illustrates how SSL uses a MAC algorithm to verify message integrity. With the key, the sender uses the MAC algorithm to compute the MAC value of a message. Then, the sender suffixes the MAC value to the message and sends the result to the receiver. The receiver uses the same key and MAC algorithm to compute the MAC value of the received message, and compares the locally computed MAC value with that received. If the two matches, the receiver considers the message intact; otherwise, the receiver considers that the message has been tampered with in transit and discards the message. Figure 105 Message integrity verification by a MAC algorithm Sender Message Compute the MAC Message MAC Send to the receiver Message Key Compute the MAC Receiver MAC MAC Compare Key 119

128 NOTE: For more information about symmetric key algorithms, asymmetric key algorithm RSA and digital signature, see the chapter Public key configuration. For more information about PKI, certificate, and CA, see the chapter PKI configuration. SSL protocol stack As shown in Figure 106, the SSL protocol consists of two layers of protocols: the SSL record protocol at the lower layer and the SSL handshake protocol, change cipher spec protocol, and alert protocol at the upper layer. Figure 106 SSL protocol stack SSL record protocol: Fragments data to be transmitted, computes and adds MAC to the data, and encrypts the data before transmitting it to the peer end. SSL handshake protocol: A very important part of the SSL protocol stack, responsible for negotiating the cipher suite to be used for secure communication (including the symmetric encryption algorithm, key exchange algorithm, and MAC algorithm), securely exchanging the key between the server and client, and implementing identity authentication of the server and client. Through the SSL handshake protocol, a session is established between a client and the server. A session consists of a set of parameters, including the session ID, peer certificate, cipher suite, and master secret. SSL change cipher spec protocol: Used for notification between the client and the server that the subsequent packets are to be protected and transmitted based on the newly negotiated cipher suite and key. SSL alert protocol: Enables the SSL client and server to send alert messages to each other. An alert message contains the alert severity level and a description. SSL configuration task list Different parameters are required on the SSL server and the SSL client. Complete the following tasks to configure SSL: Task Configuring an SSL server policy Configuring an SSL client policy Remarks Required 120

129 Configuring an SSL server policy An SSL server policy is a set of SSL parameters for a server to use when booting up. An SSL server policy takes effect only after it is associated with an application layer protocol, HTTP protocol, for example. Configuration prerequisites When configuring an SSL server policy, you need to specify the PKI domain to be used for obtaining the server side certificate. Therefore, before configuring an SSL server policy, you must configure a PKI domain. For more information about PKI domain configuration, see the chapter PKI configuration. Configuration procedure Follow these steps to configure an SSL server policy: To do... Use the command... Remarks Enter system view system-view Create an SSL server policy and enter its view Specify a PKI domain for the SSL server policy Specify the cipher suite(s) for the SSL server policy to support Set the handshake timeout time for the SSL server Set the SSL connection close mode Set the maximum number of cached sessions and the caching timeout time Enable certificate-based SSL client authentication ssl server-policy policy-name pki-domain domain-name ciphersuite [ rsa_aes_128_cbc_sha rsa_des_cbc_sha rsa_rc4_128_md5 rsa_rc4_128_sha ] * handshake timeout time close-mode wait session { cachesize size timeout time } * client-verify enable Required Required By default, no PKI domain is specified for an SSL server policy. By default, an SSL server policy supports all cipher suites. 3,600 seconds by default Not wait by default The defaults are as follows: 500 for the maximum number of cached sessions, 3600 seconds for the caching timeout time. Not enabled by default 121

130 NOTE: If you enable client authentication here, you must request a local certificate for the client. Currently, SSL mainly comes in these versions: SSL 2.0, SSL 3.0, and TLS 1.0, where TLS 1.0 corresponds to SSL 3.1. When the LB module acts as an SSL server, it can communicate with clients running SSL 3.0 or TLS 1.0, and can identify Hello packets from clients running SSL 2.0. If a client running SSL 2.0 also supports SSL 3.0 or TLS 1.0 (information about supported versions is carried in the packet that the client sends to the server), the server will notify the client to use SSL 3.0 or TLS 1.0 to communicate with the server. SSL server policy configuration example Network requirements As shown in Figure 107, users can access and control the LB module through web pages. For security of the module, it is required that users use HTTPS (HTTP Security, which uses SSL) to log in to the web interface of the module and use SSL for identity authentication to ensure that data will not be eavesdropped or tampered with. To achieve the goal, perform the following configurations: Configure the module to work as the HTTPS server and request a certificate for the module. Request a certificate for Host so that the module can authenticate the identity of Host. Configure a CA server to issue certificates to the module and Host. NOTE: In this example, Windows Server works as the CA server and the Simple Certificate Enrollment Protocol (SCEP) plug-in is installed on the CA server. Before performing the following configurations, ensure that the module, Host, and CA server have IP connectivity between each other. Figure 107 Network diagram for SSL server policy configuration LB / / / /24 Host CA Configuration procedure 1. Configure the HTTPS server (the LB module) # Create a PKI entity named en, and configure the common name as http-server1 and the FQDN as ssl.security.com. <LB> system-view [LB] pki entity en [LB-pki-entity-en] common-name http-server1 122

131 [LB-pki-entity-en] fqdn ssl.security.com [LB-pki-entity-en] quit # Create PKI domain 1, specify the trusted CA as ca server, the URL of the registration server as the authority for certificate request as RA, and the entity for certificate request as en. [LB] pki domain 1 [LB-pki-domain-1] ca identifier ca server [LB-pki-domain-1] certificate request url [LB-pki-domain-1] certificate request from ra [LB-pki-domain-1] certificate request entity en [LB-pki-domain-1] quit # Create the local RSA key pairs. [LB] public-key local create rsa # Retrieve the CA certificate. [LB] pki retrieval-certificate ca domain 1 # Request a local certificate for the LB module. [LB] pki request-certificate domain 1 # Create an SSL server policy named myssl. [LB] ssl server-policy myssl # Specify the PKI domain for the SSL server policy as 1. [LB-ssl-server-policy-myssl] pki-domain 1 # Enable client authentication. [LB-ssl-server-policy-myssl] client-verify enable [LB-ssl-server-policy-myssl] quit # Configure HTTPS service to use SSL server policy myssl. [LB] ip https ssl-server-policy myssl # Enable HTTPS service. [LB] ip https enable # Create a local user named usera, and set the password to 123 and service type to telnet. [LB] local-user usera [LB-luser-usera] password simple 123 [LB-luser-usera] service-type telnet 2. Configure the HTTPS client (Host) On Host, launch IE, enter in the address bar and request a certificate for Host as prompted. 3. Verify your configuration Launch IE on the host, enter in the address bar, and select the certificate issued by the CA server. The web interface of the LB module should appear. After entering username usera and password 123, you should be able to log in to the web interface to access and manage the module. 123

132 NOTE: For more information about PKI configuration commands, see the PKI Commands in Security Command Reference. For more information about the public-key local create rsa command, see the Public Key Commands in Security Command Reference. For more information about HTTPS, see System Management Configuration Guide. Configuring an SSL client policy An SSL client policy is a set of SSL parameters for a client to use when connecting to the server. An SSL client policy takes effect only after it is associated with an application layer protocol. Configuration prerequisites If the SSL server is configured to authenticate the SSL client, when configuring the SSL client policy, you need to specify the PKI domain to be used for obtaining the certificate of the client. Therefore, before configuring an SSL client policy, you must configure a PKI domain. For more information about PKI domain configuration, see the chapter PKI configuration. Configuration procedure Follow these steps to configure an SSL client policy: To do Use the command Remarks Enter system view system-view Create an SSL client policy and enter its view Specify a PKI domain for the SSL client policy Specify the preferred cipher suite for the SSL client policy Specify the SSL protocol version for the SSL client policy ssl client-policy policy-name pki-domain domain-name prefer-cipher { rsa_aes_128_cbc_sha rsa_des_cbc_sha rsa_rc4_128_md5 rsa_rc4_128_sha } version { ssl3.0 tls1.0 } Required No PKI domain is configured by default. rsa_rc4_128_md5 by default TLS 1.0 by default NOTE: If you enable client authentication on the server, you must request a local certificate for the client. 124

133 Displaying and maintaining SSL To do Use the command Remarks Display SSL server policy information display ssl server-policy { policy-name all } Available in any Display SSL client policy information display ssl client-policy { policy-name all } view Troubleshooting SSL Symptom Analysis Solution As the SSL server, the LB module fails to handshake with the SSL client. SSL handshake failure may result from the following causes: The SSL client is configured to authenticate the SSL server, but the SSL server has no certificate or the certificate is not trusted. The SSL server is configured to authenticate the SSL client, but the SSL client has no certificate or the certificate is not trusted. The server and the client have no matching cipher suite. 1. You can issue the debugging ssl command and view the debugging information to locate the problem: If the SSL client is configured to authenticate the SSL server but the SSL server has no certificate, request one for it. If the server s certificate cannot be trusted, install on the SSL client the root certificate of the CA that issues the local certificate to the SSL server, or let the server requests a certificate from the CA that the SSL client trusts. If the SSL server is configured to authenticate the client, but the SSL client has no certificate or the certificate cannot be trusted, request and install a certificate for the client. 2. You can use the display ssl server-policy command to view the cipher suites that the SSL server policy supports. If the server and the client have no matching cipher suite, use the ciphersuite command to modify the cipher suite configuration of the SSL server. 125

134 AAA configuration NOTE: The LB module supports configuring AAA only in the command line interface. AAA overview Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing network access management. It can provide the following security functions: Authentication Identifies users and determines whether a user is valid. Authorization Grants different users different rights and controls their access to resources and services. For example, a user who has successfully logged in to the LB module can be granted read and print permissions to the files on the device. Accounting Records all network service usage information of users, including the service type, start time, and traffic. The accounting function not only provides the information required for charging, but also allows for network security surveillance. AAA usually uses a client/server model. The client runs on the network access server (NAS), which is also referred to as the access device. The server maintains user information centrally. In an AAA network, a NAS is a server for users but a client for the AAA servers. See Figure 108. Figure 108 Network diagram for AAA When a user tries to log in to the NAS, use network resources, or access other networks, the NAS authenticates the user. The NAS can transparently pass the user s authentication, authorization, and accounting information to a remote server. The RADIUS protocol defines how a NAS and a remote server exchange user information between them. In the network shown in Figure 108, there is a RADIUS server. You can determine the authentication, authorization and accounting methods according to the actual requirements. You can choose the three security functions provided by AAA as required. For example, if your company only wants employees to be authenticated before they access specific resources, you only need to configure an authentication server. If network usage information is needed, you must also configure an accounting server. AAA can be implemented through multiple protocols. The HP LB module supports using RADIUS. 126

135 RADIUS Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol that uses a client/server model. It can protect networks against unauthorized access and is often used in network environments where both high security and remote user access are required. RADIUS uses UDP as the transport protocol. It uses UDP port 1812 for authentication and UDP port 1813 for accounting. RADIUS was originally designed for dial-in user access. With the addition of new access methods, RADIUS has been extended to support additional access methods, such as Ethernet and ADSL. RADIUS provides access authentication and authorization services, and its accounting function collects and records network resource usage information. Client/server model The RADIUS client runs on the NASs located throughout the network. It passes user information to designated RADIUS servers and acts on the responses (for example, rejects or accepts user access requests). The RADIUS server runs on the computer or workstation at the network center and maintains information related to user authentication and network service access. It listens to connection requests, authenticates users, and returns user access control information (for example, rejecting or accepting the user access request) to the clients. In general, the RADIUS server maintains the following databases: Users, Clients, and Dictionary. See Figure 109. Figure 109 RADIUS server components Users: Stores user information such as the usernames, passwords, applied protocols, and IP addresses. Clients: Stores information about RADIUS clients, such as shared keys and IP addresses. Dictionary: Stores RADIUS protocol attributes and their values. Security and authentication mechanisms RADIUS uses a shared key that is never transmitted over the network to authenticate information exchanged between a RADIUS client and the RADIUS server, enhancing the information exchange security. In addition, to prevent user passwords from being intercepted on insecure networks, RADIUS encrypts passwords before transmitting them. A RADIUS server supports multiple user authentication methods, such as the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP) of the Point-to-Point Protocol (PPP). A RADIUS server can also act as the client of another AAA server to provide authentication proxy services. 127

136 Basic RADIUS message exchange process Figure 110 illustrates the interaction of the host, the RADIUS client, and the RADIUS server. Figure 110 Basic RADIUS message exchange process RADIUS operates in the following manner: 1. The host initiates a connection request that carries the user s username and password to the RADIUS client. 2. Having received the username and password, the RADIUS client sends an authentication request (Access-Request) to the RADIUS server, with the user password encrypted by using the Message-Digest 5 (MD5) algorithm and the shared key. 3. The RADIUS server authenticates the username and password. If the authentication succeeds, the server sends back an Access-Accept message containing the user s authorization information. If the authentication fails, the server returns an Access-Reject message. 4. The RADIUS client permits or denies the user according to the returned authentication result. If it permits the user, it sends a start-accounting request (Accounting-Request) to the RADIUS server. 5. The RADIUS server returns a start-accounting response (Accounting-Response) and starts accounting. 6. The user accesses the network resources. 7. The host requests the RADIUS client to tear down the connection and the RADIUS client sends a stop-accounting request (Accounting-Request) to the RADIUS server. 8. The RADIUS server returns a stop-accounting response (Accounting-Response) and stops accounting for the user. 9. The user stops access to network resources. 128

137 RADIUS packet format RADIUS uses UDP to transmit messages. To ensure smooth message exchange between the RADIUS server and the client, RADIUS uses a series of mechanisms, including the timer management mechanism, the retransmission mechanism, and the backup server mechanism. Figure 111 shows the RADIUS packet format. Figure 111 RADIUS packet format 0 Code Identifier Length Authenticator (16bytes) Attribute Descriptions of the fields are as follows: 1. The Code field (1-byte long) indicates the type of the RADIUS packet. Table 35 gives the possible values and their meanings. Table 35 Main values of the Code field Code Packet type Description 1 Access-Request 2 Access-Accept 3 Access-Reject 4 Accounting-Request 5 Accounting-Response From the client to the server. A packet of this type carries user information for the server to authenticate the user. It must contain the User-Name attribute and can optionally contain the attributes of NAS-IP-Address, User-Password, and NAS-Port. From the server to the client. If all the attribute values carried in the Access-Request are acceptable, the authentication succeeds, and the server sends an Access-Accept response. From the server to the client. If any attribute value carried in the Access-Request is unacceptable, the authentication fails and the server sends an Access-Reject response. From the client to the server. A packet of this type carries user information for the server to start or stop accounting for the user. The Acct-Status-Type attribute in the packet indicates whether to start or stop accounting. From the server to the client. The server sends a packet of this type to notify the client that it has received the Accounting-Request and has successfully recorded the accounting information. 2. The Identifier field (1 byte long) is used to match request packets and response packets and to detect duplicate request packets. Request and response packets of the same type have the same identifier. 3. The Length field (2 byte long) indicates the length of the entire packet, including the Code, Identifier, Length, Authenticator, and Attribute fields. Bytes beyond this length are considered 129

138 padding and are ignored at the receiver. If the length of a received packet is less than this length, the packet is dropped. The value of this field is in the range 20 to The Authenticator field (16 byte long) is used to authenticate replies from the RADIUS server and to encrypt user passwords. There are two types of authenticators: request authenticator and response authenticator. 5. The Attributes field, variable in length, carries the specific authentication, authorization, and accounting information that defines the configuration details of the request or response. This field may contain multiple attributes, each with three sub-fields: Type, Length, and Value. Type (1 byte long) Indicates the type of the attribute. It is in the range 1 to 255. See Table 36 for commonly used attributes for RADIUS authentication, authorization and accounting. Length (1 byte long) Indicates the length of the attribute in bytes, including the Type, Length, and Value fields. Value (up to 253 bytes) Value of the attribute. Its format and content depend on the Type and Length fields. Table 36 Commonly used RADIUS attributes No. Attribute No. Attribute 1 User-Name 45 Acct-Authentic 2 User-Password 46 Acct-Session-Time 3 CHAP-Password 47 Acct-Input-Packets 4 NAS-IP-Address 48 Acct-Output-Packets 5 NAS-Port 49 Acct-Terminate-Cause 6 Service-Type 50 Acct-Multi-Session-Id 7 Framed-Protocol 51 Acct-Link-Count 8 Framed-IP-Address 52 Acct-Input-Gigawords 9 Framed-IP-Netmask 53 Acct-Output-Gigawords 10 Framed-Routing 54 (unassigned) 11 Filter-ID 55 Event-Timestamp 12 Framed-MTU (unassigned) 13 Framed-Compression 60 CHAP-Challenge 14 Login-IP-Host 61 NAS-Port-Type 15 Login-Service 62 Port-Limit 16 Login-TCP-Port 63 Login-LAT-Port 17 (unassigned) 64 Tunnel-Type 18 Reply-Message 65 Tunnel-Medium-Type 19 Callback-Number 66 Tunnel-Client-Endpoint 20 Callback-ID 67 Tunnel-Server-Endpoint 21 (unassigned) 68 Acct-Tunnel-Connection 22 Framed-Route 69 Tunnel-Password 23 Framed-IPX-Network 70 ARAP-Password 130

139 No. Attribute No. Attribute 24 State 71 ARAP-Features 25 Class 72 ARAP-Zone-Access 26 Vendor-Specific 73 ARAP-Security 27 Session-Timeout 74 ARAP-Security-Data 28 Idle-Timeout 75 Password-Retry 29 Termination-Action 76 Prompt 30 Called-Station-Id 77 Connect-Info 31 Calling-Station-Id 78 Configuration-Token 32 NAS-Identifier 79 EAP-Message 33 Proxy-State 80 Message-Authenticator 34 Login-LAT-Service 81 Tunnel-Private-Group-id 35 Login-LAT-Node 82 Tunnel-Assignment-id 36 Login-LAT-Group 83 Tunnel-Preference 37 Framed-AppleTalk-Link 84 ARAP-Challenge-Response 38 Framed-AppleTalk-Network 85 Acct-Interim-Interval 39 Framed-AppleTalk-Zone 86 Acct-Tunnel-Packets-Lost 40 Acct-Status-Type 87 NAS-Port-Id 41 Acct-Delay-Time 88 Framed-Pool 42 Acct-Input-Octets 89 (unassigned) 43 Acct-Output-Octets 90 Tunnel-Client-Auth-id 44 Acct-Session-Id 91 Tunnel-Server-Auth-id NOTE: The attribute types listed in Table 36 are defined by RFC 2865, RFC 2866, RFC 2867, and RFC For information about commonly used standard RADIUS attributes, see Commonly used standard RADIUS attributes. Extended RADIUS attributes The RADIUS protocol features excellent extensibility. Attribute 26 (Vender-Specific), an attribute defined by RFC 2865, allows a vender to define extended attributes to implement functions that the standard RADIUS protocol does not provide. A vendor can encapsulate multiple sub-attributes in the type-length-value (TLV) format in RADIUS packets for extension of applications. As shown in Figure 112, a sub-attribute encapsulated in Attribute 26 consists of the following parts: Vendor-ID Indicates the ID of the vendor. Its most significant byte is 0; the other three bytes contains a code that is compliant to RFC The vendor ID of HP is For more information about the proprietary RADIUS sub-attributes of HP, see Proprietary RADIUS sub-attributes of HP. Vendor-Type: Indicates the type of the sub-attribute. 131

140 Vendor-Length: Indicates the length of the sub-attribute. Vendor-Data: Indicates the contents of the sub-attribute. Figure 112 Segment of a RADIUS packet containing an extended attribute 0 Type Length Vendor-ID Vendor-ID (continued) Vendor-Type Vendor-Length Vendor-Data (Specified attribute value ) Domain-based user management On a NAS, each user belongs to one Internet service provider (ISP) domain. A NAS determines the ISP domain a user belongs to by the username entered by the user at login, and controls access of the user based on the AAA methods configured for the domain. If no specific AAA methods are configured for the domain, the default methods are used. See Figure 113. By default, a domain uses local authentication, local authorization, and local accounting. Figure 113 Determine the ISP domain of a user by the username NAS A user enters the username in the form of userid@domain-name or userid Username Yes Use domain domain-name to authenticate the user No Use the default domain to authenticate the user AAA allows you to manage users based on their access types: LAN users Users on a LAN who must pass 802.1X or MAC address authentication to access the network. Login users Users who want to log in to the LB module, including SSH users, Telnet users, web users, FTP users, and terminal users. To enhance the security of the LB module, AAA provides the following additional services for Login users: Level switching authentication Allows the authentication server to authenticate users who perform privilege level switching. As long as passing level switching authentication, users can switch their user privilege levels, without logging out and disconnecting current connections. For more information about user privilege level switching, see System Management Configuration Guide. You can configure different authentication, authorization, and accounting methods for different users in a domain. See Configuring AAA. 132

141 Protocols and standards The following protocols and standards are related to AAA and RADIUS: RFC 2865, Remote Authentication Dial In User Service (RADIUS) RFC 2866, RADIUS Accounting RFC 2867, RADIUS Accounting Modifications for Tunnel Protocol Support RFC 2868, RADIUS Attributes for Tunnel Protocol Support RFC 2869, RADIUS Extensions AAA configuration considerations and task list To configure AAA, you must complete these tasks on the NAS: 1. Configure the required AAA schemes. Local authentication Configure local users and the related attributes, including the usernames and passwords of the users to be authenticated. Remote authentication Configure the required RADIUS schemes. You must configure user attributes on the servers accordingly. 2. Configure AAA methods for the users ISP domains. Authentication method No authentication (none), local authentication (local), or remote authentication (scheme) Authorization method No authorization (none), local authorization (local), or remote authorization (scheme) Accounting method No accounting (none), local accounting (local), or remote accounting (scheme) Figure 114 illustrates the configuration procedure. Figure 114 AAA configuration procedure 133

142 NOTE: To control access of login users by using AAA methods, you must configure the login authentication mode for the user interfaces as scheme. For more information about the configuration command, see System Management Configuration Guide. AAA configuration task list Task Creating an ISP domain Configuring ISP domain attributes Configuring AAA authentication methods for an ISP domain Configuring AAA authorization methods for an ISP domain Configuring AAA accounting methods for an ISP domain Configuring local user attributes Configuring user group attributes Tearing down user connections Configuring a NAS ID-VLAN binding Displaying and maintaining AAA Remarks Required Required RADIUS configuration task list Task Creating a RADIUS scheme Specifying the RADIUS authentication/authorization servers Specifying the RADIUS accounting servers and relevant parameters Setting the shared key for RADIUS packets Setting the maximum number of RADIUS request transmission attempts Setting the supported RADIUS server type Setting the status of RADIUS servers Configuring the username format and traffic statistics units Enabling the RADIUS trap function Specifying the source IP address for outgoing RADIUS packets Setting timers for controlling communication with RADIUS servers Configuring RADIUS accounting-on Specifying a security policy server Enabling the listening port of the RADIUS client Configuring interpretation of RADIUS class attribute as CAR parameters Displaying and maintaining RADIUS Remarks Required Required Required 134

143 Configuring AAA Configuration prerequisites For remote authentication, authorization, or accounting, you must create the RADIUS schemes first. For RADIUS scheme configuration, see Configuring RADIUS. Creating an ISP domain In a networking scenario with multiple ISPs, the LB module may connect users of different ISPs, and users of different ISPs may have different user attributes, such as different username and password structures, different service types, and different rights. To distinguish the users of different ISPs, configure ISP domains, and configure different AAA methods and domain attributes for the ISP domains. The LB module can accommodate up to 16 ISP domains, including the system predefined ISP domain system. You can specify one of the ISP domains as the default domain. On the LB module, each user belongs to an ISP domain. If a user provides no ISP domain name at login, the LB module considers the user belongs to the default ISP domain. Follow these steps to create an ISP domain: To do Use the command Remarks Enter system view system-view Create an ISP domain and enter ISP domain view domain isp-name Required Return to system view quit Specify the default ISP domain domain default enable isp-name By default, the system has a default ISP domain named system. NOTE: To delete the ISP domain that is functioning as the default ISP domain, you must change it to a non-default ISP domain by using the undo domain default enable command. Configuring ISP domain attributes In an ISP domain, you can configure the following attributes for all users in the domain: Domain status. By placing the ISP domain to the active or blocked state, you allow or deny network service requests from users in the domain. Maximum number of online users. The LB module controls the number of online users in a domain to ensure the system performance and service reliability. Idle cut. This function enables the LB module to check the traffic of each online user in the domain at the idle timeout interval, and to log out any user in the domain whose traffic during the idle timeout period is less than the specified minimum traffic. Self-service server location. By using the information defined in this attribute, users can access the self-service server to manage their own accounts and passwords. 135

144 IP address pool for allocating addresses to PPP users. The LB module assigns IP addresses in this pool to PPP users in the domain. Default authorization user profile. If a user passes authentication but is authorized with no user profile, the LB module authorizes the default user profile of the ISP domain to the user and restricts the user s behavior based on the profile. Follow these steps to configure ISP domain attributes: To do Use the command Remarks Enter system view system-view Enter ISP domain view domain isp-name Place the ISP domain to the state of active or blocked Specify the maximum number of active users in the ISP domain Configure the idle cut function Configure the self-service server location function Specify the default authorization user profile state { active block } access-limit enable max-user-number idle-cut enable minute flow self-service-url enable url-string authorization-attribute user-profile profile-name When created, an ISP domain is in the active state by default, and users in the domain can request network services. No limit by default Disabled by default Currently, this command is effective only for LAN users. Disabled by default By default, an ISP domain has no default authorization user profile. NOTE: A self-service RADIUS server, for example, Intelligent Management Center (IMC), is required for the self-service server location function to work. With the self-service function, users can manage and control their accounting information or card numbers. A server with self-service software is a self-service server. Configuring AAA authentication methods for an ISP domain In AAA, authentication, authorization, and accounting are separate processes. Authentication refers to the interactive authentication process of username/password/user information during an access or service request. The authentication process neither sends authorization information to a supplicant nor triggers any accounting. AAA supports the following authentication methods: No authentication (none): All users are trusted and no authentication is performed. Generally, do not use this method. Local authentication (local) Authentication is performed by the LB module, which is configured with the user information, including the usernames, passwords, and attributes. Local authentication allows high speed and low cost, but the amount of information that can be stored is limited by the hardware. 136

145 Remote authentication (scheme) The LB module cooperates with a RADIUS server to authenticate users. Remote authentication provides centralized information management, high capacity, high reliability, and support for centralized authentication service for multiple NASs. You can configure local or no authentication as the backup method, which will be used when the remote server is not available. No authentication can only be configured for LAN users as the backup method of remote authentication. You can configure AAA authentication to work alone without authorization and accounting. By default, an ISP domain uses the local authentication method. Before configuring authentication methods, complete the following tasks: For RADIUS authentication, configure the RADIUS scheme to be referenced first. The local and none authentication methods do not require a scheme. Determine the access mode or service type to be configured. With AAA, you can configure an authentication method specifically for each access mode and service type, limiting the authentication protocols that can be used for access. Determine whether to configure an authentication method for all access modes or service types. Follow these steps to configure AAA authentication methods for an ISP domain: To do Use the command Remarks Enter system view system-view Enter ISP domain view domain isp-name Specify the default authentication method for all types of users Specify the authentication method for login users Specify the authentication method for privilege level switching authentication default { local none radius-scheme radius-scheme-name [ local ] } authentication login { local none radius-scheme radius-scheme-name [ local ] } authentication super { radius-scheme radius-scheme-name } local by default The default authentication method is used by default. The default authentication method is used by default. 137

146 NOTE: The authentication method specified with the authentication default command is for all types of users and has a priority lower than that for a specific access mode. With an authentication method that references a RADIUS scheme, AAA accepts only the authentication result from the RADIUS server. The Access-Accept message from the RADIUS server does include the authorization information, but the authentication process ignores the information. With the radius-scheme radius-scheme-name local keyword and argument combination configured, local authentication is the backup method and is used only when the remote server is not available. If the primary authentication method is local or none, the system performs local authentication or does not perform any authentication, and will not use any RADIUS authentication scheme. If the method for level switching authentication references a RADIUS scheme, the system uses the username configured for the corresponding privilege level on the RADIUS server for level switching authentication, rather than the original username, namely the login username or the username entered by the user. A username configured on the RADIUS server is in the format of $enab+level, where level specifies the privilege level to which the user wants to switch. For example, if user user1 of domain aaa wants to switch the privilege level to 3, the system uses $enab3@aaa for authentication when the domain name is required and uses $enab3 for authentication when the domain name is not required. Configuring AAA authorization methods for an ISP domain In AAA, authorization is a separate process at the same level as authentication and accounting. Its responsibility is to send authorization requests to the specified authorization servers and to send authorization information to users after successful authorization. Authorization method configuration is optional in AAA configuration. AAA supports the following authorization methods: No authorization (none): The LB module performs no authorization exchange. Every user is trusted and has the corresponding default rights of the system. Local authorization (local) The LB module performs authorization according to the user attributes configured for users. Remote authorization (scheme): The LB module cooperates with a RADIUS server to authorize users. RADIUS authorization is bound with RADIUS authentication. RADIUS authorization can work only after RADIUS authentication is successful, and the authorization information is carried in the Access-Accept message. You can configure local authorization or no authorization as the backup method to be used when the remote server is not available. By default, an ISP domain uses the local authorization method. If the no authorization method (none) is configured, the users are not required to be authorized, in which case an authenticated user has the default right. The default right is visiting (the lowest one) for EXEC users (that is, console users who use the console, AUX, asynchronous serial port, or Telnet to connect to the LB module, such as Telnet or SSH users. Each connection of these types is called an EXEC user). The default right for FTP users is to use the root directory of the LB module. Before configuring authorization methods, complete these three tasks: 1. For RADIUS authorization, the RADIUS authorization scheme must be the same as the RADIUS authentication scheme; otherwise, it does not take effect. 2. Determine the access mode or service type to be configured. With AAA, you can configure an authorization scheme specifically for each access mode and service type, limiting the authorization protocols that can be used for access. 138

147 3. Determine whether to configure an authorization method for all access modes or service types. Follow these steps to configure AAA authorization methods for an ISP domain: To do Use the command Remarks Enter system view system-view Enter ISP domain view domain isp-name Specify the default authorization method for all types of users Specify the command authorization method Specify the authorization method for login users authorization default { local none radius-scheme radius-scheme-name [ local ] } authorization command { local none } authorization login { local none radius-scheme radius-scheme-name [ local ] } local by default The default authorization method is used by default. The default authorization method is used by default. NOTE: The authorization method specified with the authorization default command is for all types of users and has a priority lower than that for a specific access mode. RADIUS authorization is special in that it takes effect only when the RADIUS authorization scheme is the same as the RADIUS authentication scheme. In addition, if a RADIUS authorization fails, the error message returned to the LB module says that the server is not responding. With the radius-scheme radius-scheme-name local keyword and argument combination configured, local authorization or no authorization is the backup method and is used only when the remote server is not available. If the primary authorization method is local or none, the system performs local authorization or does not perform any authorization; it will never use the RADIUS authorization scheme. The authorization information of the RADIUS server is sent to the RADIUS client along with the authentication response message; therefore, you cannot specify a separate RADIUS authorization server. If you use RADIUS for authorization and authentication, you must use the same scheme setting for authorization and authentication; otherwise, the system will prompt you with an error message. Configuring AAA accounting methods for an ISP domain In AAA, accounting is a separate process at the same level as authentication and authorization. Its responsibility is to send accounting start/update/end requests to the specified accounting server. Accounting is not required, and therefore accounting method configuration is optional. AAA supports the following accounting methods: No accounting (none): The system does not perform accounting for the users. Local accounting (local): Local accounting is implemented on the LB module. It is for collecting statistics on the number of users and controlling the number of local user connections; it does not provide statistics for user charge. Remote accounting (scheme): The LB module cooperates with a RADIUS server for accounting of users. You can configure local or no accounting as the backup method to be used when the remote server is not available. 139

148 By default, an ISP domain uses the local accounting method. Before configuring accounting methods, complete these three tasks: 1. For RADIUS accounting, configure the RADIUS scheme to be referenced first. The local and none authentication methods do not require any scheme. 2. Determine the access mode or service type to be configured. With AAA, you can configure an accounting method specifically for each access mode and service type, limiting the accounting protocols that can be used for access. 3. Determine whether to configure an accounting method for all access modes or service types. Follow these steps to configure AAA accounting methods for an ISP domain: To do Use the command Remarks Enter system view system-view Enter ISP domain view domain isp-name Enable the accounting optional feature Specify the default accounting method for all types of users Specify the accounting method for login users accounting optional accounting default { local none radius-scheme radius-scheme-name [ local ] } accounting login { local none radius-scheme radius-scheme-name [ local ] } Disabled by default local by default The default accounting method is used by default. NOTE: With the accounting optional command configured, a user that would be otherwise disconnected can still use the network resources even when no accounting server is available or communication with the current accounting server fails. The local accounting method is not used to implement accounting, but to work together with the access-limit command, which is configured in local user view, to limit the number of local user connections. However, with the accounting optional command configured, the limit on the number of local user connections is not effective. The accounting method specified with the accounting default command is for all types of users and has a priority lower than that for a specific access mode. With the radius-scheme radius-scheme-name local keyword and argument combination configured, local accounting is the backup method and is used only when the remote server is not available. If the primary accounting method is local or none, the system performs local accounting or does not perform any accounting, and will not use the RADIUS accounting scheme. In login access mode, accounting is not supported for FTP services. Configuring local user attributes To implement local user authentication, authorization, and accounting, you must create local users and configure user attributes on the LB module. The local users and attributes are stored in the local user database on the LB module. A local user is uniquely identified by a username. Configurable local user attributes are as follows: Service type 140

149 The types of the services that the user can use. Local authentication checks the service types of a local user. If none of the service types is available, the user cannot pass authentication. Service types include FTP, LAN access, SSH, Telnet and Terminal. User state Indicates whether or not a local user can request network services. There are two user states: active and blocked. A user in the active state can request network services, but a user in the blocked state cannot. Maximum number of users using the same local user account Indicates how many users can use the same local user account for local authentication. Expiration time A user must use a valid local user account to pass local authentication. When some users need to access the network temporarily, you can create a guest account and specify an expiration time for the account to control the validity of the account. User group Each local user belongs to a local user group and bears all attributes of the group, such as the password control attributes and authorization attributes. For more information about local user group, see Configuring user group attributes. Password control attributes Password control attributes help you control the security of local users passwords. Password control attributes include password aging time, minimum password length, and password composition policy. You can configure a password control attribute in system view, user group view, or local user view, making the attribute effective for all local users, all local users in a group, or only the local user. A password control attribute with a smaller effective range has a higher priority. Binding attributes Binding attributes are used for controlling the scope of users. They are checked during local authentication of a user. If the attributes of a user do not match the binding attributes configured for the local user account, the user cannot pass authentication. Binding attributes include the ISDN calling number, IP address, access port, MAC address, and native VLAN. Be cautious when deciding which binding attributes to configure for a local user. Authorization attributes Authorization attributes indicate the rights that a user has after passing local authentication. Authorization attributes include the ACL, idle cut function, user level, user role, user profile, VLAN, and FTP/SFTP work directory. Every configurable authorization attribute has its definite application environments and purposes. When configuring authorization attributes for a local user, consider which attributes are needed and which are not. For example, for PPP users, you do not need to configure the work directory attribute. You can configure an authorization attribute in user group view or local user view to make the attribute effective for all local users in the group or for only the local user. The setting of an authorization attribute in local user view takes precedence over that in user group view. Follow these steps to configure the attributes for a local user: To do Use the command Remarks Enter system view system-view 141

150 To do Use the command Remarks Set the password display mode for all local users Add a local user and enter local user view Configure a password for the local user Place the local user to the state of active or blocked Set the maximum number of users using the local user account local-user password-display-mode { auto cipher-force } local-user user-name password { cipher simple } password state { active block } access-limit max-user-number auto by default, indicating to display the password of a local user in the way indicated by the password command. Required No local user exists by default. When created, a local user is in the state of active by default, and the user can request network services. By default, there is no limit on the maximum number of users using the same local user account. Configure the password control attributes for the local user Set the password aging time Set the minimum password length Configure the password composition policy password-control aging aging-time password-control length length password-control composition type-number type-number [ type-length type-length ] By default, the setting for the user group is used. If there is no setting for the user group, the global setting is used. By default, the setting for the user group to which the user belongs is used. If there is no setting for the user group, the global setting is used. By default, the setting for the user group to which the user belongs is used. If there is no setting for the user group, the global setting is used. Specify the service types for the local user Configure the binding attributes for the local user service-type { ftp { ssh telnet terminal } * } bind-attribute { call-number call-number [ : subcall-number ] ip ip-address location port slot-number subslot-number port-number mac mac-address vlan vlan-id } * Required By default, no service is authorized to a local user. By default, no binding attribute is configured for a local user. ip, location, mac, and vlan is supported for LAN users; no binding attribute is supported for other types of local users. 142

151 To do Use the command Remarks Configure the authorization attributes for the local user Set the expiration time of the local user Specify the user group for the local user authorization-attribute { acl acl-number callback-number callback-number idle-cut minute level level user-profile profile-name vlan vlan-id work-directory directory-name } * expiration-date time group group-name By default, no authorization attribute is configured for a local user. acl, idle-cut, user-profile, and vlan are supported for LAN users; level is supported for SSH, Telnet, and terminal users; level and work-directory are supported for FTP users; no binding attribute is supported for other types of local users. Not set by default By default, a local user belongs to the default user group system. NOTE: If you configure the local-user password-display-mode cipher-force command, all existing local user passwords will be displayed in cipher text, regardless of the configuration of the password command. If you also save the configuration and restart the LB module, all existing local user passwords will always be displayed in cipher text, no matter how you configure the local-user password-display-mode command or the password command. The passwords configured after you restore the display mode to auto by using the local-user password-display-mode auto command, however, are displayed as defined by the password command. The access-limit command configured for a local user takes effect only when local accounting is used. With an authentication method that requires the username and password, including local authentication and RADIUS authentication, the commands that a login user can use after logging in depend on the level of the user. With other authentication methods, which commands are available depends on the level of the user interface. For an SSH user using public key authentication, the commands that can be used depend on the level configured on the user interface. For more information about authentication method and commands accessible to user interfaces, see System Management Configuration Guide. Configuring user group attributes User groups simplify local user configuration and management. A user group comprises a group of local users and has a set of local user attributes. You can configure local user attributes for a user group to implement centralized user attributes management for the local users in the group. Configurable user attributes include authorization attributes. By default, every newly added local user belongs to the system default user group system and bears all attributes of the group. User group system is automatically created by the LB module. Follow these steps to configure the attributes for a user group: To do Use the command Remarks Enter system view system-view Create a user group and enter user group view user-group group-name Required 143

152 To do Use the command Remarks Configure the authorization attributes for the user group authorization-attribute { acl acl-number callback-number callback-number idle-cut minute level level user-profile profile-name vlan vlan-id work-directory directory-name } * By default, no authorization attribute is configured for a user group. Tearing down user connections Follow these steps to tear down user connections: To do Use the command Remarks Enter system view system-view Tear down AAA user connections forcibly cut connection { all domain isp-name interface interface-type interface-number ip ip-address mac mac-address ucibindex ucib-index user-name user-name vlan vlan-id } Required Applicable to only LAN access at present. Configuring a NAS ID-VLAN binding The access locations of users can be identified by their access VLANs. In application scenarios where it is required to identify the access locations of users, configure NAS ID-VLAN bindings on the LB module. Then, when a user gets online, the LB module obtains the NAS ID by the access VLAN of the user and sends the NAS ID to the RADIUS server through the NAS-identifier attribute. Follow these steps to configure a NAS ID-VLAN binding: To do Use the command Remarks Enter system view system-view Create a NAS ID profile and enter NAS ID profile view Configure a NAS ID-VLAN binding aaa nas-id profile profile-name nas-id nas-identifier bind vlan vlan-id Required Required By default, no NAS ID-VLAN binding exists. Displaying and maintaining AAA To do Use the command Remarks Display the configuration information of a specified ISP domain or all ISP domains display domain [ isp-name ] Available in any view Display information about specified or all user connections Display information about specified or all local users display connection [ domain isp-name interface interface-type interface-number ip ip-address mac mac-address ucibindex ucib-index user-name user-name vlan vlan-id ] display local-user [ service-type { ftp ssh telnet terminal } state { active block } user-name user-name ] Available in any view Available in any view 144

153 To do Use the command Remarks Display configuration information about a specified user group or all user groups display user-group [ group-name ] Available in any view Configuring RADIUS A RADIUS scheme specifies the RADIUS servers that the LB module can cooperate with and defines a set of parameters that the LB module uses to exchange information with the RADIUS servers. There may be authentication/authorization servers and accounting servers, and primary servers and secondary servers. The parameters include the IP addresses of the servers, the shared keys, and the RADIUS server type. You can reference a RADIUS scheme in an AAA method. See Configuring AAA. NOTE: When there are users online, you cannot modify RADIUS parameters other than the number of retransmission attempts and the timers. Creating a RADIUS scheme Before performing other RADIUS configurations, follow these steps to create a RADIUS scheme and enter RADIUS scheme view: To do Use the command Remarks Enter system view system-view Create a RADIUS scheme and enter RADIUS scheme view radius scheme radius-scheme-name Required Not defined by default NOTE: A RADIUS scheme can be referenced by more than one ISP domain at the same time. Specifying the RADIUS authentication/authorization servers You can specify one primary authentication/authorization server and one secondary authentication/authorization servers for a RADIUS scheme so that the LB module can find a server for user authentication/authorization when using the scheme. When the primary server is not available, the secondary server is used, if any. In a scenario where redundancy is not required, specify only the primary server. In RADIUS, user authorization information is piggybacked in authentication responses sent to RADIUS clients. It is neither allowed nor needed to specify a separate RADIUS authorization server. Follow these steps to specify the RADIUS authentication/authorization servers: To do Use the command Remarks Enter system view system-view Enter RADIUS scheme view radius scheme radius-scheme-name 145

154 To do Use the command Remarks Specify the primary RADIUS authentication/authorization server Specify the secondary RADIUS authentication/authorization server primary authentication ip-address [ port-number ] [ key string ] secondary authentication ip-address [ port-number ] [ key string ] Required Configure at least one of the commands No authentication server by default NOTE: The IP addresses of the primary and secondary authentication/authorization servers for a scheme must be different from each other. Otherwise, the configuration will fail. All servers for authentication/authorization and accountings, primary or secondary, must use IP addresses of the same IP version. You can specify a RADIUS authentication/authorization server as the primary authentication/authorization server for one scheme and as the secondary authentication/authorization server for another scheme at the same time. Specifying the RADIUS accounting servers and relevant parameters You can specify one primary accounting server and one accounting servers for a RADIUS scheme. When the primary server is not available, the secondary server is used, if any. When redundancy is not required, specify only the primary server. By setting the maximum number of real-time accounting attempts for a scheme, you make the LB module disconnect users for whom no accounting response is received before the number of accounting attempts reaches the limit. You can enable buffering of non-responded stop-accounting requests to allow the LB module to buffer and resend a stop-accounting request until it receives a response or the number of stop-accounting attempts reaches the configured limit. In the latter case, the LB module discards the packet. Follow these steps to specify the RADIUS accounting servers and perform related configurations: To do Use the command Remarks Enter system view system-view Enter RADIUS scheme view Specify the primary RADIUS accounting server Specify the secondary RADIUS accounting server Enable the LB module to buffer stop-accounting requests getting no responses Set the maximum number of stop-accounting request transmission attempts radius scheme radius-scheme-name primary accounting ip-address [ port-number ] [ key string ] secondary accounting ip-address [ port-number ] [ key string ] stop-accounting-buffer enable retry stop-accounting retry-times Required Configure at least one of the commands No accounting server by default Enabled by default 500 by default 146

155 To do Use the command Remarks Set the maximum number of accounting request transmission attempts retry realtime-accounting retry-times 5 by default NOTE: The IP addresses of the primary and secondary accounting servers must be different from each other. Otherwise, the configuration fails. All servers for authentication/authorization and accountings, primary or secondary, must use IP addresses of the same IP version. You can specify a RADIUS accounting server as the primary accounting server for one scheme and as the secondary accounting server for another scheme at the same time. RADIUS does not support accounting for FTP users. Setting the shared key for RADIUS packets The RADIUS client and RADIUS server use the MD5 algorithm to encrypt packets exchanged between them and use shared keys to authenticate the packets. They must use the same shared key for the same type of packets. A shared key configured in this task is for all servers of the same type (accounting or authentication) in the scheme, and has a lower priority than a shared key configured individually for a RADIUS server. Follow these steps to set the shared key for RADIUS packets: To do Use the command Remarks Enter system view system-view Enter RADIUS scheme view radius scheme radius-scheme-name Set the shared key for RADIUS authentication/authorization or accounting packets key { accounting authentication } string Required No key by default NOTE: A shared key configured on the LB module must be the same as that configured on the RADIUS server. Setting the maximum number of RADIUS request transmission attempts Because RADIUS uses UDP packets to carry data, the communication process is not reliable. If a NAS receives no response from the RADIUS server before the response timeout timer expires, it is required to retransmit the RADIUS request. If the number of transmission attempts exceeds the specified limit but it still receives no response, it considers that the authentication has failed. Follow these steps to set the maximum number of RADIUS request retransmission attempts: To do Use the command Remarks Enter system view system-view Enter RADIUS scheme view radius scheme radius-scheme-name 147

156 To do Use the command Remarks Set the maximum number of RADIUS request retransmission attempts retry retry-times 3 by default NOTE: The maximum number of retransmission attempts of RADIUS packets multiplied by the RADIUS server response timeout period cannot be greater than 75. To configure the RADIUS server response timeout period, use the timer response-timeout command. Setting the supported RADIUS server type The supported RADIUS server type determines the type of the RADIUS protocol that the LB module uses to communicate with the RADIUS server. It can be standard or extended: Standard Uses the standard RADIUS protocol, compliant to RFC 2865 and RFC 2866 or later. Extended Uses the proprietary RADIUS protocol of HP. When the RADIUS server runs IMC, you must set the RADIUS server type to extended. When the RADIUS server runs third-party RADIUS server software, either RADIUS server type applies. Follow these steps to set the supported RADIUS server type: To do Use the command Remarks Enter system view system-view Enter RADIUS scheme view Specify the RADIUS server type supported by the LB module radius scheme radius-scheme-name server-type { extended standard } By default, the supported RADIUS server type is standard. NOTE: Changing the RADIUS server type will restore the unit for data flows and that for packets that are sent to the RADIUS server to the defaults. Setting the status of RADIUS servers By setting the status of RADIUS servers to blocked or active, you can control which servers the LB module will communicate with for authentication, authorization, and accounting or turn to when the current servers are not available any more. With both primary servers and secondary servers configured, the LB module chooses servers based on these rules: When the primary server and secondary server are both in active state, the LB module communicates with the primary server. If the primary server fails, the LB module changes the status of the primary server to blocked and turns to the secondary server. When the quiet timer times out, the LB module resumes the status of the primary server to active while keeping the status of the secondary server unchanged. In the case of authentication/authorization, the LB module resumes the communication with the primary server; in the case of accounting, however, the LB module keeps communicating with the secondary server if accounting has already started, no matter whether the primary server recovers or not. 148

157 When the primary server and secondary server are both in blocked state, the LB module communicates with the primary server. If the primary server is available, its status changes to active; otherwise, the status of the primary server remains the same. If one server is in active state while the other is in blocked state, the LB module only tries to communicate with the server in active state, even if the server is unavailable. By default, the LB module sets the status of each RADIUS server configured with an IP address to active. You can manually change the status of a server as needed. For example, to use the secondary server for authentication, you need to change the status of the primary server to blocked while leaving the secondary server in active state. Follow these steps to set the status of RADIUS servers: To do Use the command Remarks Enter system view system-view Enter RADIUS scheme view Set the status of the primary RADIUS authentication/authorization server Set the status of the primary RADIUS accounting server Set the status of the secondary RADIUS authentication/authorization server Set the status of the secondary RADIUS accounting server radius scheme radius-scheme-name state primary authentication { active block } state primary accounting { active block } state secondary authentication { active block } state secondary accounting { active block } active for every server configured with IP address in the RADIUS scheme NOTE: The server status set by the state command cannot be saved in the configuration file and will be restored to active every time the server restarts. Configuring the username format and traffic statistics units A username is usually in the format of userid@isp-name, where isp-name represents the name of the ISP domain the user belongs to and is used by the LB module to determine which users belong to which ISP domains. However, some earlier RADIUS servers cannot recognize usernames that contain an ISP domain name. In this case, the LB module must remove the domain name of each username before sending the username. You can set the username format on the LB module for this purpose. The LB module periodically sends accounting updates to RADIUS accounting servers to report the traffic statistics of online users. For normal and accurate traffic statistics, make sure that the unit for data flows and that for packets on the LB module are consistent with those on the RADIUS server. Follow these steps to set the username format and the traffic statistics units for a RADIUS scheme: To do Use the command Remarks Enter system view system-view Enter RADIUS scheme view radius scheme radius-scheme-name 149

158 To do Use the command Remarks Specify the format of the username to be sent to a RADIUS server Specify the unit for data flows or packets to be sent to a RADIUS server user-name-format { keep-original with-domain without-domain } data-flow-format { data { byte giga-byte kilo-byte mega-byte } packet { giga-packet kilo-packet mega-packet one-packet } }* By default, the ISP domain name is included in the username. The defaults are as follows: byte for data flows, and one-packet for data packets. NOTE: If a RADIUS scheme defines that the username is sent without the ISP domain name, do not apply the RADIUS scheme to more than one ISP domain. Otherwise, users using the same username but in different ISP domains will be considered the same user.r. For level switching authentication, the user-name-format keep-original and user-name-format without-domain commands produce the same results: they ensure that usernames sent to the RADIUS server carry no ISP domain name. Enabling the RADIUS trap function With the trap function, the LB module sends a trap message when either of the following events occurs: The status of a RADIUS server changes. If the LB module receives no response to an accounting or authentication request before the specified maximum number of RADIUS request transmission attempts is exceeded, it considers the server unreachable, sets the status of the server to block and sends a trap message. If the LB module receives a response from a RADIUS server that it considers unreachable, the LB module considers that the RADIUS server is reachable again, sets the status of the server to active, and sends a trap message. The ratio of the number of failed transmission attempts to the total number of authentication request transmission attempts reaches the threshold. This threshold ranges from 1% to 100% and defaults to 30%. This threshold can only be configured through the MIB. The failure ratio is generally small. If a trap message is triggered because the failure ratio is higher than the threshold, troubleshoot the configuration on and the communication between the LB module and the RADIUS server. Follow these steps to enable the RADIUS trap function: To do Use the command Remarks Enter system view system-view Enable the RADIUS trap function radius trap { accounting-server-down authentication-error-threshold authentication-server-down } Required Disabled by default Specifying the source IP address for outgoing RADIUS packets The source IP address of RADIUS packets that a NAS sends must match the IP address of the NAS configured on the RADIUS server. A RADIUS server identifies a NAS by its IP address. Upon receiving a RADIUS packet, a RADIUS server checks whether the source IP address of the packet is the IP address of any managed NAS. If yes, the server processes the packet. If not, the server drops the packet. 150

159 After you specify the source IP address for RADIUS packets to be sent on a NAS, if the physical port for sending the RADIUS packets fails, response packets from the RADIUS server will be able to arrive at the NAS. You can specify a source IP address for outgoing RADIUS packets in RADIUS scheme view for a specific RADIUS scheme, or in system view for all RADIUS schemes. Before sending a RADIUS packet, the LB module selects a source IP address in this order: 1. The source IP address specified for the RADIUS scheme. 2. The source IP address specified in system view. 3. The IP address of the outbound interface specified by the route. Follow these steps to specify a source IP address for all RADIUS schemes: To do Use the command Remarks Enter system view system-view Specify the source IP address for outgoing RADIUS packets System view radius nas-ip ip-address Required RADIUS scheme view radius scheme radius-scheme-name nas-ip ip-address Use either approach By default, there is no source IP address specified for RADIUS packets and the IP address of the interface for sending the RADIUS packets will be used as the source IP address of the RADIUS packets. Setting timers for controlling communication with RADIUS servers The LB module uses the following types of timers to control the communication with a RADIUS server: Server response timeout timer (response-timeout) Defines the RADIUS request retransmission interval. After sending a RADIUS request (authentication/authorization or accounting request), the LB module starts this timer. If the LB module receives no response from the RADIUS server before this timer expires, it resends the request. Server quiet timer (quiet) Defines the duration to keep an unreachable server in the blocked state. If a server is not reachable, the LB module changes the server s status to blocked, starts this timer for the server, and tries to communicate with another server in the active state. After this timer expires, the LB module changes the status of the server back to active. Real-time accounting timer (realtime-accounting) Defines the interval at which the LB module sends real-time accounting packets to the RADIUS accounting server for online users. To implement real-time accounting, the LB module must periodically send real-time accounting packets to the accounting server for online users. Follow these steps to set timers for controlling communication with RADIUS servers: To do Use the command Remarks Enter system view system-view Enter RADIUS scheme view Set the RADIUS server response timeout timer radius scheme radius-scheme-name timer response-timeout seconds 3 seconds by default 151

160 To do Use the command Remarks Set the quiet timer for the primary server Set the real-time accounting interval timer quiet minutes timer realtime-accounting minutes 5 minutes by default 12 minutes by default NOTE: The maximum number of retransmission attempts of RADIUS packets multiplied by the RADIUS server response timeout period must be less than 75 and the upper limit of this product is determined by the upper limit of the timeout time of different access modules. For an access module, the maximum number of retransmission attempts multiplied by the RADIUS server response timeout period must be smaller than the timeout time. Otherwise, stop-accounting messages cannot be buffered, and the primary/secondary server switchover cannot take place. For example, as the timeout time of voice access is 10 seconds, the product of the two parameters cannot exceed 10 seconds; as the timeout time of Telnet access is 30 seconds, the product of the two parameters cannot exceed 30 seconds. To configure the maximum number of retransmission attempts of RADIUS packets, use the retry command. Configuring RADIUS accounting-on The accounting-on feature enables the LB module to send accounting-on packets to the RADIUS server after it reboots, making the server log out users who logged in through the LB module before the reboot. Without this feature, users who were online before the reboot cannot re-log in after the reboot, because the RADIUS server considers they are already online. If a LB module sends an accounting-on packet to the RADIUS server but receives no response, it resends the packet to the server at a particular interval for a specified number of times. Follow these steps to configure the accounting-on feature for a RADIUS scheme: To do Use the command Remarks Enter system view system-view Enter RADIUS scheme view Enable accounting-on Set the number of accounting-on packet retransmission attempts Set the retransmission interval of accounting-on packets radius scheme radius-scheme-name accounting-on enable accounting-on enable send send-times accounting-on enable interval seconds Required Disabled by default 5 times by default 3 seconds by default NOTE: The accounting-on feature requires the cooperation of the HP IMC network management system. 152

161 Specifying a security policy server The core of the HP EAD solution is integration and cooperation, and the security policy server is the management and control center. Using a collection of software, the security policy server provides functions such as user management, security policy management, security status assessment, security cooperation control, and security event audit. The NAS checks the validity of received control packets and accepts only control packets from known servers. To use a security policy server that is independent of the AAA servers, you must configure the IP address of the security policy server on the NAS. To implement all EAD functions, configure both the IP address of the IMC security policy server and that of the IMC configuration platform on the NAS. Follow these steps to specify a security policy server: To do Use the command Remarks Enter system view system-view Enter RADIUS scheme view radius scheme radius-scheme-name Specify a security policy server security-policy-server ip-address Required Not specified by default NOTE: You can specify up to eight security policy servers for a RADIUS scheme. Enabling the listening port of the RADIUS client Follow these steps to enable the listening port of the RADIUS client: To do Use the command Remarks Enter system view system-view Enable the listening port of the RADIUS client radius client enable Enabled by default Configuring interpretation of RADIUS class attribute as CAR parameters According to RFC 2865, a RADIUS server assigns the RADIUS class attribute (attribute 25) to a RADIUS client. However, the RFC only requires the RADIUS client to send the attribute to the accounting server on an as is basis; it does not require the RADIUS client to interpret the attribute. Some RADIUS servers use the class attribute to deliver the assigned committed access rate (CAR) parameters. In this case, the LB module must interpret the attribute as the CAR parameters to implement user-based traffic monitoring and controlling. Follow these steps to configure the RADIUS client to interpret the class attribute as the CAR parameters: To do Use the command Remarks Enter system view system-view Enter RADIUS scheme view radius scheme radius-scheme-name 153

162 To do Use the command Remarks Specify to interpret the class attribute as the CAR parameters attribute 25 car Required Be default, RADIUS attribute 25 is not interpreted as CAR parameters. Displaying and maintaining RADIUS To do Use the command Remarks Display the configuration information of a specified RADIUS scheme or all RADIUS schemes display radius scheme [ radius-scheme-name ] Available in any view Display statistics about RADIUS packets display radius statistics Available in any view Display information about buffered stop-accounting requests that get no responses display stop-accounting-buffer { radius-scheme radius-server-name session-id session-id time-range start-time stop-time user-name user-name } Available in any view Clear RADIUS statistics reset radius statistics Available in user view Clear buffered stop-accounting requests that get no responses reset stop-accounting-buffer { radius-scheme radius-server-name session-id session-id time-range start-time stop-time user-name user-name } Available in user view AAA configuration examples AAA for Telnet/SSH users by a RADIUS server NOTE: Configuration of RADIUS authentication, authorization, and accounting for SSH users is similar to that for Telnet users. The following takes Telnet users as an example. Network requirements As shown in Figure 115, Configure an IMC server to act as the RADIUS server to provide authentication, authorization, and accounting services for Telnet users. The IP address of the RADIUS server is /24. Set the shared keys for authentication, authorization, and accounting packets exchanged between the LB module and the RADIUS server to expert and specify the ports for authentication/authorization and accounting as 1812 and 1813 respectively. Specify that a username sent to the RADIUS server carries the domain name. Add an account on the RADIUS server, with the username being hello@bbb. The Telnet user uses the username and the configured password to log in to the card and will be authorized with the privilege level of 3 after successful login. 154

163 Figure 115 Configure AAA for Telnet users through a RADIUS server RADIUS server /24 XGE0/ /24 LB XGE0/ /24 Internet Configuration procedure 1. Configure the RADIUS server(imc) NOTE: This example assumes that the RADIUS server runs IMC PLAT 5.0(E0101) or IMC UAM 5.0(E0101). # Add an access device. Log into the IMC management platform, select the Service tab, and select Access Service > Access Device from the navigation tree to enter the Access Device List page. Then, click Add to enter the Add Access Device page and perform the following configurations: Set the shared keys for authentication and accounting packets to expert Specify the ports for authentication and accounting as 1812 and 1813 respectively Select Device Management Service as the service type Select HP as the access device type Select the card from the device list or manually add the card with the IP address of Click OK to finish the operation. NOTE: The IP address of the access device must be the same as the source IP address of the RADIUS packets sent from the LB module. By default, the source IP address of a RADIUS packet is the IP address of the interface through which the packet is sent out. If the LB module uses the default IP address to send RADIUS packets, you must specify the IP address of the access device as the IP address of the outgoing interface. In this example, with the IP address of Ten-GigabitEthernet 0/0.2 being , you need to set the IP address of the access device to accordingly. If the LB module uses the source IP address specified with the nas-ip or radius nas-ip command to send RADIUS packets, you must set the IP address of the access device to the specified source IP address. 155

164 Figure 116 Add an access device # Add a user for device management. Log into the IMC management platform, select the User tab, and select Access User View > Device Mgmt User from the navigation tree to enter the All Access Users page. Then, click Add to enter the Add Device Management User page and perform the following configurations: Add a user named hello@bbb and specify the password Select Telnet as the service type Set the EXEC privilege level to 3. This value identifies the privilege level of the Telnet user after login, which is 0 by default. Specify the IP address range of the hosts to be managed as to , and click Add to finish the operation. NOTE: The IP address range of the hosts to be managed must contain the IP address of the access device added. 156

165 Figure 117 Add an account for device management 2. Configure the LB module # Configure the IP address of interface Ten-GigabitEthernet 0/0.1, through which the Telnet user accesses the card. <LB> system-view [LB] interface Ten-GigabitEthernet 0/0.1 [LB-Ten-GigabitEthernet0/0.1] ip address [LB-Ten-GigabitEthernet0/0.1] quit # Configure the IP address of interface Ten-GigabitEthernet 0/0.2, through which the card communicates with the server. [LB] interface Ten-GigabitEthernet 0/0.2 [LB-Ten-GigabitEthernet0/0.2] ip address [LB-Ten-GigabitEthernet0/0.2] quit # Enable the Telnet server on the card. [LB] telnet server enable # Configure the card to use AAA for Telnet users. [LB] user-interface vty 0 4 [LB-ui-vty0-4] authentication-mode scheme [LB-ui-vty0-4] quit # Create RADIUS scheme rad. [LB] radius scheme rad # Specify the primary authentication server. 157

166 [LB-radius-rad] primary authentication # Specify the primary accounting server. [LB-radius-rad] primary accounting # Set the shared key for authentication packets to expert. [LB-radius-rad] key authentication expert # Set the shared key for accounting packets to expert. [LB-radius-rad] key accounting expert # Specify the service type for the RADIUS server, which must be extended when the server runs IMC. [LB-radius-rad] server-type extended # Specify that a username sent to the RADIUS server carry the domain name. [LB-radius-rad] user-name-format with-domain [LB-radius-rad] quit # Configure the AAA methods for domain bbb. As RADIUS authorization information is sent to the RADIUS client in the authentication response messages, be sure to reference the same scheme for user authentication and authorization. [LB] domain bbb [LB-isp-bbb] authentication login radius-scheme rad [LB-isp-bbb] authorization login radius-scheme rad [LB-isp-bbb] accounting login radius-scheme rad [LB-isp-bbb] quit // You can achieve the same result by configuring default AAA methods for all types of users in domain bbb. [LB] domain bbb [LB-isp-bbb] authentication default radius-scheme rad [LB-isp-bbb] authorization default radius-scheme rad [LB-isp-bbb] accounting default radius-scheme rad 3. Verify the configuration After the above configuration, the Telnet user should be able to telnet to the LB module and use the configured account to enter the user interface of the card, and access all the commands of level 0 to level 3. AAA for FTP/Telnet users by the LB module itself NOTE: Configuration of local authentication and authorization for FTP users is similar to that for Telnet users. The following takes Telnet users as an example. 158

167 Network requirements As shown in Figure 118, configure the LB module to perform local authentication, authorization, and accounting for Telnet users. Figure 118 Configure local authentication/authorization/accounting for Telnet users XGE0/ /24 Internet Telnet user /24 LB Configuration procedure # Configure the IP address of interface Ten-GigabitEthernet 0/0.1, through which the Telnet user accesses the LB module. <LB> system-view [LB] interface Ten-GigabitEthernet 0/0.1 [LB-Ten-GigabitEthernet0/0.1] ip address [LB-Ten-GigabitEthernet0/0.1] quit # Enable the Telnet server on the card. [LB] telnet server enable # Configure the card to use AAA for Telnet users. [LB] user-interface vty 0 4 [LB-ui-vty0-4] authentication-mode scheme [LB-ui-vty0-4] quit # Create local user named telnet. [LB] local-user telnet [LB-luser-telnet] service-type telnet [LB-luser-telnet] password simple aabbcc [LB-luser-telnet] quit # Configure the AAA methods for the ISP domain as local authentication, authorization and accounting. [LB] domain system [LB-isp-system] authentication login local [LB-isp-system] authorization login local [LB-isp-system] accounting login local [LB-isp-system] quit # You can achieve the same result by configuring default AAA methods for all types of users. [LB-isp-system] authentication default local [LB-isp-system] authorization default local [LB-isp-system] accounting default local When telneting in to the LB module, a user uses username telnet@system for local authentication with the domain system. 159

168 Level switching authentication for Telnet users by a RADIUS server NOTE: The RADIUS server in this example runs ACSv4.0. Network requirements As shown in Figure 119, Configure the LB module to use local authentication for the Telnet user and assign the privilege level of 0 for the user to enjoy after login. Configure the LB module to use the RADIUS server and, if RADIUS authentication is not available, use local authentication instead for level switching authentication of the Telnet user. Figure 119 Configure RADIUS authentication for level switching users Configuration considerations 1. Configure the LB module to use AAA, particularly, local authentication for Telnet user authentication. Create ISP domain bbb and configure it to use local authentication for Telnet users. Create a local user account, configure the password, and assign the privilege level for the user to enjoy after login. 2. On the LB module, configure the authentication method for user privilege level switching. Specify to use RADIUS authentication and, if RADIUS authentication is not available, use local authentication for users switching from a lower level to a higher level. Configure RADIUS scheme rad and assign an IP address to the RADIUS server. Set the shared keys for message exchange and specify that usernames sent to the RADIUS server carry no domain name. Configure the domain to use RADIUS scheme rad for user privilege level switching authentication. Configure the password for local user privilege level switching authentication. Add the username and password for user privilege level switching authentication. 3. On the RADIUS server, add the username and password for user privilege level switching authentication. 160

169 Configuration procedure 1. Configure the LB module # Configure the IP address of Ten-GigabitEthernet 0/0.1, through which the Telnet user accesses the card. <LB> system-view [LB] interface Ten-GigabitEthernet 0/0.1 [LB-Ten-GigabitEthernet0/0.1] ip address [LB-Ten-GigabitEthernet0/0.1] quit # Configure the IP address of Ten-GigabitEthernet 0/0.2, through which the card communicates with the server. [LB] interface Ten-GigabitEthernet 0/0.2 [LB-Ten-GigabitEthernet0/0.2] ip address [LB-Ten-GigabitEthernet0/0.2] quit # Enable the card to provide Telnet service. [LB] telnet server enable # Configure the card to use AAA for Telnet user authentication. [LB] user-interface vty 0 4 [LB-ui-vty0-4] authentication-mode scheme [LB-ui-vty0-4] quit # Specify to use RADIUS authentication and, if RADIUS authentication is not available, use local authentication for user privilege level switching authentication. [LB] super authentication-mode scheme local # Create RADIUS scheme rad. [LB] radius scheme rad # Specify the IP address of the primary authentication server as , and the port for authentication as [LB-radius-rad] primary authentication # Set the shared key for authentication packets to expert. [LB-radius-rad] key authentication expert # Specify the service type of the RADIUS server as standard. [LB-radius-rad] server-type standard # Specify that usernames sent to the RADIUS server carry no domain name. [LB-radius-rad] user-name-format without-domain [LB-radius-rad] quit # Create ISP domain bbb. [LB] domain bbb # Configure the AAA methods for domain bbb as local authentication. [LB-isp-bbb] authentication login local # Configure the domain to use the RADIUS scheme rad for user privilege level switching authentication. [LB-isp-bbb] authentication super radius-scheme rad [LB-isp-bbb] quit # Create a local Telnet user named test. [LB] local-user test 161

170 [LB-luser-test] service-type telnet [LB-luser-test] password simple aabbcc # Configure the user level of the Telnet user to 0 after user login. [LB-luser-test] authorization-attribute level 0 [LB-luser-test] quit # Configure the password for local level switching authentication to [LB] super password simple [LB] quit 2. Configure the RADIUS server Add the username and password for user privilege level switching authentication, as shown in Table 37. Table 37 Add username and passwords for user privilege level switching authentication Username Password Switching to level $enab1 pass1 1 $enab2 pass2 2 $enab3 pass3 3 NOTE: A username configured on the RADIUS server is in the format of $enablevel, where level specifies the privilege level to which the user wants to switch. Figure 120 Configure the username for privilege level switching (take $enab1 for example) 162

171 Figure 121 List of the usernames for privilege level switching 3. Verify the configuration After the above configuration, the Telnet user should be able to telnet to the LB module and use username and password aabbcc to enter the user interface of the card, and access all level 0 commands. <LB> telnet Trying Press CTRL+K to abort Connected to ****************************************************************************** * Copyright (c) Hewlett-Packard Development Company, L.P. * * Without the owner's prior written consent, * * no decompiling or reverse-engineering shall be allowed. * ****************************************************************************** Login authentication Username:test@bbb Password: <LB>? User view commands: cluster Run cluster command display Display current system information ping Ping function quit Exit from current command view ssh2 Establish a secure shell client connection super Set the current user priority level telnet Establish one TELNET connection tracert Trace route function When switching to user privilege level 3, the Telnet user only needs to enter password pass3 as prompted. <LB> super 3 Password: User privilege level is 3, and only those commands can be used whose level is equal or less than this. Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE # If the RADIUS authentication is not available, the Telnet user needs to enter password as prompted for local authentication. <LB> super 3 163

172 Password: Enter the password for RADIUS privilege level switch authentication Error: Invalid configuration or no response from the authentication server. Info: Change authentication mode to local. Password: Enter the password for local privilege level switch authentication User privilege level is 3, and only those commands can be used whose level is equal or less than this. Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE Troubleshooting AAA Troubleshooting RADIUS Symptom 1: User authentication/authorization always fails. Analysis: Solution: 1. A communication failure exists between the NAS and the RADIUS server. 2. The username is not in the format of userid@isp-name or no default ISP domain is specified for the NAS. 3. The user is not configured on the RADIUS server. 4. The password of the user is incorrect. 5. The RADIUS server and the NAS are configured with different shared key. Check that: 1. The NAS and the RADIUS server can ping each other. 2. The username is in the userid@isp-name format and a default ISP domain is specified on the NAS. 3. The user is configured on the RADIUS server. 4. The correct password is entered. 5. The same shared key is configured on both the RADIUS server and the NAS. Symptom 2: RADIUS packets cannot reach the RADIUS server. Analysis: Solution: 1. The communication link between the NAS and the RADIUS server is down (at the physical layer and data link layer). 2. The NAS is not configured with the IP address of the RADIUS server. 3. The UDP ports for authentication/authorization and accounting are not correct. 4. The port numbers of the RADIUS server for authentication, authorization and accounting are being used by other applications. Check that: 1. The communication links between the NAS and the RADIUS server work well at both physical and link layers. 2. The IP address of the RADIUS server is correctly configured on the NAS. 164

173 3. UDP ports for authentication/authorization/accounting configured on the NAS are the same as those configured on the RADIUS server. 4. The port numbers of the RADIUS server for authentication, authorization and accounting are available. Symptom 3: A user is authenticated and authorized, but accounting for the user is not normal. Analysis: Solution: 1. The accounting port number is not correct. 2. Configuration of the authentication/authorization server and the accounting server are not correct on the NAS. For example, one server is configured on the NAS to provide all the services of authentication/authorization and accounting, but in fact the services are provided by different servers. Check that: 1. The accounting port number is correctly set. 2. The authentication/authorization server and the accounting server are correctly configured on the NAS. 165

174 RADIUS attributes Commonly used standard RADIUS attributes Table 38 Commonly used standard RADIUS attributes No. Attribute Description 1 User-Name Name of the user to be authenticated 2 User-Password 3 CHAP-Password 4 NAS-IP-Address User password for PAP authentication, present only in Access-Request packets in PAP authentication mode. Digest of the user password for CHAP authentication, present only in Access-Request packets in CHAP authentication mode. IP address for the server to identify a client. Usually, a client is identified by the IP address of the access interface of the NAS, namely the NAS IP address. This attribute is present in only Access-Request packets. 5 NAS-Port Physical port of the NAS that the user accesses 6 Service-Type Type of the service that the user has requested or type of the service to be provided 7 Framed-Protocol Encapsulation protocol 8 Framed-IP-Address IP address to be configured for the user 11 Filter-ID Name of the filter list 12 Framed-MTU Maximum transmission unit (MTU) for the data link between the user and NAS. For example, with 802.1X EAP authentication, NAS uses this attribute to notify the server of the MTU for EAP packets, so as to avoid oversized EAP packets. 14 Login-IP-Host IP address of the NAS interface that the user accesses 15 Login-Service Type of the service that the user uses for login 18 Reply-Message 26 Vendor-Specific 27 Session-Timeout Text to be displayed to the user, which can be used by the server to indicate, for example, the reason of the authentication failure. Vendor specific attribute. A packet can contain one or more such proprietary attributes, each of which can contain one or more sub-attributes. Maximum duration of service to be provided to the user before termination of the session 28 Idle-Timeout Maximum idle time permitted for the user before termination of the session 31 Calling-Station-Id Identification of the user that the NAS sends to the server. With the LAN access service provided by an HP device, this attribute carries the MAC address of the user in the format HHHH-HHHH-HHHH. 32 NAS-Identifier Identification that the NAS uses for indicating itself 166

175 No. Attribute Description 40 Acct-Status-Type 45 Acct-Authentic 60 CHAP-Challenge 61 NAS-Port-Type 79 EAP-Message Type of the Accounting-Request packet, which can be: 1: Start 2: Stop 3: Interium-Update 4: Reset-Charge 7: Accounting-On (Defined in 3GPP, the 3rd Generation Partnership Project) 8: Accounting-Off (Defined in 3GPP) 9-14: Reserved for tunnel accounting 15: Reserved for failed Authentication method used by the user, which can be: 1: RADIUS 2: Local 3: Remote CHAP challenge generated by the NAS for MD5 calculation during CHAP authentication Type of the physical port of the NAS that is authenticating the user, which can be: 15: Ethernet 16: Any type of ADSL 17: Cable (with cable for cable TV) 201: VLAN 202: ATM If the port is an ATM or Ethernet one and VLANs are implemented on it, the value of this attribute is 201. Used for encapsulating EAP packets to allow the NAS to authenticate dial-in users via EAP without having to understand the EAP protocol 80 Message-Authentic ator Used for authentication and checking of authentication packets to prevent spoofing Access-Requests. This attribute is used when RADIUS supports EAP authentication. 87 NAS-Port-Id String for describing the port of the NAS that is authenticating the user Proprietary RADIUS sub-attributes of HP Table 39 Proprietary RADIUS sub-attributes of HP No. Sub-attribute Description 1 Input-Peak-Rate Peak rate in the direction from the user to the NAS, in bps. 2 Input-Average-Rate Average rate in the direction from the user to the NAS, in bps. 3 Input-Basic-Rate Basic rate in the direction from the user to the NAS, in bps. 4 Output-Peak-Rate Peak rate in the direction from the NAS to the user, in bps. 5 Output-Average-Rat e Average rate in the direction from the NAS to the user, in bps. 6 Output-Basic-Rate Basic rate in the direction from the NAS to the user, in bps. 167

176 No. Sub-attribute Description 15 Remanent_Volume 20 Command 24 Control_Identifier Remaining, available total traffic of the connection, in different units for different server types. Operation for the session, used for session control. It can be: 1: Trigger-Request 2: Terminate-Request 3: SetPolicy 4: Result 5: PortalClear Identification for retransmitted packets. For retransmitted packets of the same session, this attribute must take the same value; while for retransmitted packets of different sessions, this attribute may take the same value. The client response of a retransmitted packet must also carry this attribute and the value of the attribute must be the same. For Accounting-Request packets of the start, stop, and interim update types, the Control-Identifier attribute, if present, makes no sense. 25 Result_Code Result of the Trigger-Request or SetPolicy operation, which can be: 0: Succeeded Any other value: Failed 26 Connect_ID Index of the user connection 28 Ftp_Directory Working directory of the FTP user. For an FTP user, when the RADIUS client acts as the FTP server, this attribute is used to set the FTP directory on the RADIUS client. 29 Exec_Privilege Priority of the EXEC user 59 NAS_Startup_Times tamp Startup time of the NAS in seconds, which is represented by the time elapsed after 00:00:00 on Jan. 1, 1970 (UTC). 60 Ip_Host_Addr IP address and MAC address of the user carried in authentication and accounting requests, in the format A.B.C.D hh:hh:hh:hh:hh:hh. A space is required between the IP address and the MAC address. 61 User_Notify Information that needs to be sent from the server to the client transparently 62 User_HeartBeat Hash value assigned after an 802.1X user passes authentication, which is a 32-byte string. This attribute is stored in the user list on the device and is used for verifying the handshake messages from the 802.1X user. This attribute exists in only Access-Accept and Accounting-Request packets. 255 Product_ID Product name 168

177 Session management NOTE: The LB module supports session management only in the command line interface Session management overview The session management feature is a common feature designed to implement session-based services such as network address translation (NAT), application specific packet filter (ASPF), and intrusion protection. This feature regards packet exchanges at transport layer as sessions and updates the status of sessions or ages out sessions according to the information in the initiators or responders packet information. Session management allows multiple features to process the same service packet respectively. It implements the following functions: Fast match between packets and sessions Management of transport layer protocol state Identification of application layer protocol types Session aging based on protocol state or application layer protocol type Persistent session Checksum verification for transport layer protocol packets Special packet match for the application layer protocols requiring port negotiation Resolution of ICMP error control packets and session match based on resolution results Session management principle The session management function tracks the status of connections by inspecting the transport layer protocol (TCP or UDP) information, and performs unified status maintenance and management of all connections. In actual applications, session management works together with ASPF to dynamically determine whether a packet can pass the firewall and enter the internal network according to connection status, thus preventing intrusion. Note that the session management function implements only connection status tracking. It itself cannot block potential attack packets. Session management implementation The session management feature implemented on the LB module provides the following functions: Supporting session creation, session status update and timeout time setting based on protocol state for such IPv4 packets as TCP, UDP, ICMP, Raw IP packets. Supporting port mapping for application layer protocols and allowing application layer protocols to use customized ports and adopt different session timeout time. 169

178 Supporting checksum verification for TCP, UDP, and ICMP packets. In case of checksum verification failure, the system will not match sessions or create sessions. Instead, other services based on session management will process the packets. Supporting ICMP error packet mapping and allowing the system to search for original sessions according to the payload of these packets. Because error packets are generated due to host errors, the mapping can help speed up the aging of the original sessions. Supporting persistent sessions, which are not aged within a long period of time. Supporting session management of control channels and dynamic data channels of application layer protocols, for example, FTP. Supporting limiting the number of session-based connections. For more information, see the chapter Connection limit configuration. Session management configuration task list Complete the following tasks to configure session management: Setting session aging times based on protocol state Configuring session aging times based on application layer protocol type Enabling checksum verification Specifying the persistent session ACL Clearing sessions manually These tasks are mutually independent and can be configured in any order. You can configure them as required. Setting session aging times based on protocol state NOTE: This aging time setting is effective to only the sessions that are being established. If the application layer protocol of a session supports session aging time configuration, the session takes the session aging time set based on the application layer protocol type as its aging time when it is in the READY/ESTABLISH state. For more information, see Configuring session aging times based on application layer protocol type. If a session entry is not matched with any packets in a specified period of time, the entry will be aged out. Follow these steps to set the session aging times based on protocol state: To do... Use the command... Remarks Enter system view system-view Set the aging time for sessions of a specified protocol and in a specified state session aging-time { accelerate fin icmp-closed icmp-open rawip-open rawip-ready syn tcp-est udp-open udp-ready } time-value Required NOTE: If there may be a large amount of sessions (more than ), too short aging times are not recommended. Otherwise, the console may be slow in response. 170

179 Configuring session aging times based on application layer protocol type NOTE: Aging times set in this task applies to only the sessions in the READY/ESTABLISH state. For sessions in the READY (with UDP) or ESTABLISH (with TCP) state, you can set the session aging times according to the types of the application layer protocols to which the sessions belong. Follow these steps to set session aging times based on application layer protocol type: To do... Use the command... Remarks Enter system view system-view Set the aging time for sessions of an application layer protocol application aging-time { dns ftp msn qq } time-value Required NOTE: If a large amount of sessions (more than ) exist, too short aging times are not recommended. Otherwise, the console may be slow in response. Enabling checksum verification To ensure that session tracking is not affected by packets with checksum errors, you can enable checksum verification for protocol packets. With checksum verification enabled, the session management feature processes only packets with correct checksums, and packets with incorrect checksums will be processed by other services based on the session management. Follow these steps to enable checksum verification for protocol packets: To do... Use the command... Remarks Enter system view system-view Enable checksum verification session checksum { all { icmp tcp udp } * } Required Disabled by default NOTE: Checksum verification may degrade the card performance. Enable it with caution. Specifying the persistent session ACL You can set some sessions that have specific characteristics as persistent sessions. The aging time of a persistent session does not vary with the session state transitions, neither will a persistent session be removed because no packets match it. A persistent session can be specified with an aging time that is longer than those of common sessions (up to 360 hours), or be configured to be a permanent connection, which will be cleared only when the session initiator or responder sends a request to close it or you clear it manually. You can set the persistent session criteria by specifying a basic or advanced access control list (ACL). All sessions permitted by the ACL are persistent sessions. 171

180 NOTE: For more information about basic and advance ACL configuration, see Security Configuration Guide. Follow these steps to specify the persistent session ACL: To do... Use the command... Remarks Enter system view system-view Specify the persistent session ACL session persist acl acl-number [ aging-time time-value ] Required Not specified by default NOTE: There can be only one persistent session ACL. Clearing sessions manually Follow the step below to clear sessions manually: To do... Use the command... Remarks Clear sessions reset session [ vd-name vd-name ] [ source-ip source-ip ] [ destination-ip destination-ip ] [ protocol-type protocol-type ] [ source-port source-port ] [ destination-port destination-port ] [ vpn-instance vpn-instance-name ] Required Available in user view Configuring session logging Session logs are used to track information about user access, IP address translation, and traffic, and can be sent to the log server in a specific format. It can help network administrators in security auditing. Configuring session log export Session logs are exported in the form of flow logs. Follow these steps to configure session log exporting: To do Use the command Remarks Enter system view system-view Specify the flow log version Specify the source IP address for UDP packets carrying flow logs Specify the IP address and UDP port number of the flow log server userlog flow export version version-number userlog flow export source-ip ip-address userlog flow export host ip-address udp-port 1.0 by default IP address of the interface sending UDP packets by default Required Not specified by default 172

181 To do Use the command Remarks Specify to export flow logs to the information center userlog flow syslog Flow logs are exported to the flow log server by default. NOTE: For information about flow log commands, see the Logging Management Commands in System Management Command Reference. Displaying and maintaining session management To do... Use the command... Remarks Display information about sessions display session table [ vd-name vd-name ] [ source-ip source-ip ] [ destination-ip destination-ip ] [ verbose ] Available in any view Display statistics about sessions display session statistics [ vd-name vd-name ] Available in any view Display session relationship table information Display configuration and statistics about logs Clear sessions display session relation-table [ vd-name vd-name ] display userlog export reset session [ vd-name vd-name ] [ source-ip source-ip ] [ destination-ip destination-ip ] [ protocol-type protocol-type ] [ source-port source-port ] [ destination-port destination-port ] [ vpn-instance vpn-instance-name ] Available in any view Available in any view Available in user view Clear session statistics reset session statistics [ vd-name vd-name ] Available in user view Clear flow logs in the buffer reset userlog flow logbuffer Available in user view 173

182 Connection limit configuration NOTE: The LB module supports the connection limit configuration only at the CLI. Connection limit overview An internal user that initiates a large quantity of connections to external networks in a short period of time occupies large amounts of system resources of the device, making other users unable to access network resources normally. An internal server that receives large numbers of connection requests within a short time cannot process them in time or accept other normal connection requests. To avoid such situations, you can configure a connection limit policy to collect statistics on and limit the number of connections. Connection limit configuration task list Complete the following tasks to configure connection limiting: Task Creating a connection limit policy Configuring an IP address-based connection limit rule Applying the connection limit policy Remarks Required Required Required Creating a connection limit policy A connection limit policy comprises a set of connection limit rules, which define the valid range and parameters for the policy. Follow these steps to create a connection limit policy: To do Use the command Remarks Enter system view system-view Create a connection limit policy and enter its view connection-limit policy policy-number Required Configuring the connection limit policy A connection limit policy contains one or more connection limit rules, each specifying an object or range for the limit. A user connection matching a rule will be limited based on the parameters in the rule. 174

183 Configuring an IP address-based connection limit rule An IP address-based connection limit rule allows you to limit the number of connections from a specified source IP address to a specified destination IP address. The limit rules are matched in ascending order of rule ID. When configuring connection limit rules for a policy, check the rules and their order carefully. HP recommends arrange the rules in ascending order of granularity and range. An IP address-based connection limit rule can be of any of these types: Source-to-destination Limits connections from a specific internal host or segment to a specific external host or segment. Source-to-any Limits connections from a specific internal host or segment to external networks. Any-to-destination Limits connections from external networks to a specific internal server. Any-to-any: Limits the total number of connections passing through the device. Follow these steps to configure an IP address-based connection limit rule: To do Use the command Remarks Enter system view system-view Enter connection limit policy view connection-limit policy policy-number Configure an IP address-based connection limit rule limit limit-id { source ip { ip-address mask-length any } [ source-vpn src-vpn-name ] destination ip { ip-address mask-length any } [ destination-vpn dst-vpn-name ] } * protocol { dns http ip tcp udp } max-connections max-num [ per-destination per-source per-source-destination ] Required Applying the connection limit policy To make a connection limit policy take effect, apply it to the LB module globally. Follow these steps to apply a connection limit policy: To do Use the command Remarks Enter system view system-view Apply a connection limit policy connection-limit apply policy policy-number Required Only one connection limit policy can be applied globally. Displaying and maintaining connection limiting To do Use the command Remarks Display information about one or all connection limit policies display connection-limit policy { policy-number all } Available in any view 175

184 Connection limit configuration example Network requirements As shown in Figure 122, a company has five public IP addresses: /24 to /24. The internal network address is /16 and two servers are on the internal network. Perform NAT configuration so that the internal users can access the Internet and external users can access the internal servers, and configure connection limiting so that: Each host on segment /24 can establish up to 100 connections to external network and all the other hosts can establish as many connections as possible. Permit up to connections from the external network to the DNS server. Permit up to connections from the external network to the Web server. Figure 122 Network diagram for connection limiting Configuration procedure NOTE: The following describes only connection limit configuraiton steps. For more information about NAT configuration and internal server configuration, see Network Management Configuration Guide. # Create a connection limit policy and enter its view. <LB> system-view [LB] connection-limit policy 0 # Configure connection limit rule 0 to limit connections from hosts on segment /24 to the external network per source address, with the upper connection limit of 100. [LB-connection-limit-policy-0] limit 0 source ip destination ip any protocol ip max-connections 100 per-source # Configure connection limit rule 1 to limit connections from the external network to the DNS server /24, with the upper connection limit of [LB-connection-limit-policy-0] limit 1 source ip any destination ip protocol dns max-connections # Configure connection limit rule 2 to limit connections from the external network to the Web server /24, with the upper connection limit of [LB-connection-limit-policy-0] limit 2 source ip any destination ip protocol http max-connections [LB-connection-limit-policy-0] quit 176

185 Verification # Apply the connection limit policy. [LB] connection-limit apply policy 0 After the configuration, use the display connection-limit policy to display the information about the connection limit policy. The following is the output: [LB] display connection-limit policy 0 Connection-limit policy 0, refcount 1, 3 limits limit 0 source ip destination ip any protocol ip max-connections 100 per-source limit 1 source ip any destination ip protocol dns max-connections limit 2 source ip any destination ip protocol http max-connections Troubleshooting connection limiting Connection limit rules with overlapping segments Symptom Analysis Solution On the LB module, create a connection limit policy and configure two rules for the policy. One limits connections from each host on segment /24 with the upper connection limit 10, and another limits connections from with the upper connection limit 100. [LB-connection-limit-policy-0] limit 0 source ip destination ip any protocol ip max-connections 10 per-source [LB-connection-limit-policy-0] limit 1 source ip destination ip any protocol ip max-connections 100 per-source With the configuration, the host can only initiate up to 10 connections to the external network. Both rules limit 0 and limit 1 contain the IP address , and the rule with a smaller ID is matched first. Rule 0 is used for connections from Rearrange the two connection limit rules by exchanging their rule IDs so that the rule for the host is matched first. Connection limit rules with overlapping protocol types Symptom Internal server provides both Web and FTP services for external users. On the LB module, create a connection limit policy and configure two rules, one limiting TCP connections to the server with the upper limit 100 and the second limiting HTTP connections to the server with the upper limit [LB-connection-limit-policy-0] limit 0 source ip any destination ip protocol tcp max-connections 100 [LB-connection-limit-policy-0] limit 1 source ip any destination ip protocol http max-connections With the configuration, 100 HTTP connections to the server can be established at most. 177

186 Analysis Both rules limit 0 and limit 1 involve HTTP connections, and the rule with a smaller ID is matched first. Rule 0 is used for HTTP connections. Solution Rearrange the two connection limit rules by exchanging their rule IDs so that the rule for HTTP connections is matched first. 178

187 Web filtering configuration NOTE: The LB module supports web filtering configuration only in the command line interface. Introduction to web filtering In legacy network security solutions, network protection is mainly against external attacks. With the popularity of network applications in every walk of life, however, the internal network also faces security threats caused by internal users access to illegal networks. To protect the internal network against such threats, the network devices must be able to filter illegal access requests from internal users. This is where the web filtering feature comes in. The web filtering feature can help devices prevent internal users from accessing unauthorized websites and block Java applets and ActiveX objects from web pages. It provides these functions: URL address filtering IP address-supported URL address filtering URL Parameter Filtering Java Blocking ActiveX Blocking URL address filtering Overview URL address filtering can help prevent internal users from accessing prohibited websites or restrict them to specific websites by checking the URL addresses contained in the web requests. Processing procedure 1. After receiving a web request, the LB module resolves the URL address in the request. 2. The module matches the URL address against the configured filtering entries. 3. If a match is found and the filtering action of the matched entry is permit, the module forwards the request. 4. If a match is found and the filtering action of the matched entry is deny, the module drops the web request and sends a TCP reset packet to both the client that sent the request and the server. 5. If no match is found, the module forwards or drops the request, depending on the default filtering action configured for URL address filtering. IP address-supported URL address filtering Overview After the URL address filtering function is enabled, the system denies all web requests that use IP addresses by default. By enabling support for IP address in URL address filtering, you can configure the 179

188 LB module to allow internal users to access the specified or all websites by using the websites IP addresses. Processing procedure After the LB module receives a web request that uses an IP address, it processes the request as follows: If URL address filtering supports IP addresses, the LB module forwards the request. The LB module permits all web requests that use the websites IP addresses to pass. If URL address filtering does not support IP addresses, the LB module checks the ACL rules for URL address filtering. If the ACL permits the IP address, the LB module forwards the request; otherwise, the LB module drops the request. URL Parameter Filtering Overview Currently, large quantities of webpages are dynamic, connected with databases, and supporting data query and modification through web requests. This makes it possible to fabricate special SQL statements in web requests to obtain confidential data from databases or break down databases by modifying database information repeatedly. This kind of attack is called SQL injection attack. To address this problem, the LB module compares the URL parameters in a web request against SQL statement keywords and some other characters that may constitute SQL statements. If a match is found, the LB module regards the request as an SQL injection attack and denies it. This protection mechanism is called URL parameter filtering. Web requests transmit parameters mainly by the "GET" and POST methods. The method used for transmitting parameters determines the positions of the URL parameters. The LB module obtains the parameters based on the parameter transmission method and then performs filtering. Currently, the LB module supports URL parameter filtering of web requests with the GET, POST or PUT method. Processing procedure After receiving a web request containing URL parameters, the LB module obtains the parameters according to the parameter transmission method and then processes the request accordingly: If the parameters are transmitted by a method other than GET, POST and PUT, the LB module directly forwards the web request. If the parameters are transmitted by the method of GET, POST or PUT, the LB module obtains the URL parameters from the web request, compares the URL parameters against the configured filtering entries. If a match is found, the LB module denies the request; otherwise, the LB module forwards the request. Java Blocking Overview Java blocking can protect networks from being attacked by malicious Java applets. After the Java blocking function is enabled, all requests for Java applets of web pages will be filtered. If Java applets in some webpages are expected, you can configure ACL rules to permit requests to Java applets of these webpages. 180

189 Processing procedure If the Java blocking function is enabled but no ACL is configured for it, the LB module replaces suffixes.class and.jar with.block in all web requests and then forwards the requests. If the Java blocking function is enabled and an ACL is configured for it, the LB module determines whether to replaces suffixes.class and.jar with.block in web requests according to the ACL rules. If the destination server in a web request is a server permitted by the ACL, no replacement occurs and the request is forwarded; otherwise, the suffix in the request is replaced with.block and then the request is forwarded. In addition to the default suffixes.class and.jar, you can add Java blocking suffixes (that is, the filename suffixes to be replaced in web requests) through command lines. ActiveX Blocking Overview ActiveX blocking can protect networks from being attacked by malicious ActiveX plugins. After the ActiveX blocking function is enabled, requests for ActiveX plugins to all webpages will be filtered. If the ActiveX plugins in some webpages are expected, you can configure ACL rules to permit requests to the ActiveX plugins of these webpages. Processing procedure If the ActiveX blocking function is enabled but no ACL is configured for it, the LB module replaces suffix.ocx with.block in all web requests and then forwards the requests. If the ActiveX blocking function is enabled and an ACL is configured for it, the LB module determines whether to replaces suffix.ocx with.block in web requests according to the ACL rules. If the destination server in a web request is a server permitted by the ACL, no replacement occurs and the request is forwarded; otherwise, the suffix is replaced with.block and then the request is forwarded. In addition to the default suffix.ocx, you can add ActiveX blocking suffixes (that is, the filename suffixes to be replaced in web requests) through command lines. Configuring web filtering IP address-supported URL filtering can take effect only after the URL address filtering is enabled. URL parameter filtering, Java blocking, and ActiveX blocking can be enabled independently. Configuring URL address filtering Follow these steps to configure URL address filtering: To do... Use the command... Remarks Enter system view system-view Enable the URL address filtering function Specify the default filtering action firewall http url-filter host enable firewall http url-filter host default { deny permit } Required Disabled by default deny by default 181

190 To do... Use the command... Remarks Add a URL address filtering entry Display information about URL address filtering firewall http url-filter host url-address { deny permit } url-address display firewall http url-filter host [ all item keywords verbose ] Required Configuring IP address-supported URL address filtering Follow these steps to configure IP address-supported URL address filtering: To do... Use the command... Remarks Enter system view system-view Enable the URL address filtering function Configure IP address-supported URL address filtering Specify an ACL for URL address filtering Display information about URL address filtering firewall http url-filter host enable firewall http url-filter host ip-address { deny permit } firewall http url-filter host acl acl-number display firewall http url-filter host [ all item keywords verbose ] Required Disabled by default Deny by default By default, no ACL is specified for URL address filtering. NOTE: The source IP addresses specified in the ACL for URL address filtering must be the IP addresses of the websites allowed to be accessed by using their IP addresses. Configuring URL parameter filtering Follow these steps to configure URL parameter filtering: To do... Use the command... Remarks Enter system view system-view Enable the URL parameter filtering function Add a URL parameter filtering entry Display information about URL parameter filtering firewall http url-filter parameter enable firewall http url-filter parameter { default keywords keywords } display firewall http url-filter parameter [ all item keywords verbose ] Required Disabled by default Required Configuring Java blocking Follow these steps to configure Java blocking: To do... Use the command... Remarks Enter system view system-view 182

191 To do... Use the command... Remarks Enable the Java blocking function Add a Java blocking suffix keyword Specify an ACL for Java blocking Display information about Java blocking firewall http java-blocking enable firewall http java-blocking suffix keywords firewall http java-blocking acl acl-number display firewall http java-blocking [ all item keywords verbose ] Required Disabled by default By default, no ACL is specified for Java blocking. NOTE: In the ACL for Java blocking, you need to configure the source IP addresses as the IP addresses of the HTTP servers allowed to be accessed, and set the action to permit. Configuring ActiveX blocking Follow these steps to configure ActiveX blocking: To do... Use the command... Remarks Enter system view system-view Enable the ActiveX blocking function Add an ActiveX blocking suffix keyword Specify an ACL for ActiveX blocking Display information about ActiveX blocking firewall http activex-blocking enable firewall http activex-blocking suffix keywords firewall http activex-blocking acl acl-number display firewall http activex-blocking [ all item keywords verbose ] Required Disabled by default By default, no ACL is specified for ActiveX blocking. NOTE: In the ACL for ActiveX blocking, you need to configure the source IP addresses as the IP addresses of the HTTP servers allowed to be accessed and set the action to permit. Displaying and maintaining web filtering To do... Use the command... Remarks Display information about URL address filtering display firewall http url-filter host [ all item keywords verbose ] Available in any view Display information about URL parameter filtering Display information about Java blocking display firewall http url-filter parameter [ all item keywords verbose ] display firewall http java-blocking [ all item keywords verbose ] Available in any view Available in any view 183

192 To do... Use the command... Remarks Display information about ActiveX blocking Clear Web filtering statistics display firewall http activex-blocking [ all item keywords verbose ] reset firewall http { activex-blocking java-blocking url-filter host url-filter parameter } counter Available in any view Available in user view Web filtering configuration examples URL address filtering configuration example Network requirements Enable the URL address filtering function on the LB module, allowing the hosts to access only using the URL address or IP address. Figure 123 Network diagram for URL address filtering configuration Configuration procedure # Configure IP addresses for the interfaces. (Omitted) # Configure the NAT policy for the outbound interface. <LB> system-view [LB] acl number 2200 [LB-acl-basic-2200] rule 0 permit source [LB-acl-basic-2200] rule 1 deny source any [LB-acl-basic-2200] quit [LB] nat address-group [LB] interface Ten-GigabitEthernet 0/0.1 [LB-Ten-GigabitEthernet0/0.1] nat outbound 2200 address-group 1 [LB-Ten-GigabitEthernet0/0.1] quit # Enable the URL address filtering function. [LB] firewall http url-filter host enable # Specify to allow users to access only and set the default filtering action to deny. [LB] firewall http url-filter host url-address permit [LB] firewall http url-filter host default deny # Specify an ACL for URL address filtering. 184

193 [LB] acl number 2000 [LB-acl-basic-2000] rule 0 permit source [LB-acl-basic-2000] rule 1 deny source any [LB-acl-basic-2000] quit # Specify to allow users to use IP addresses to access websites. [LB] firewall http url-filter host ip-address deny [LB] firewall http url-filter host acl 2000 After the above configuration, open a Web browser on a host in the LAN, enter website or and you can access this website normally. Enter other website addresses, and you are not allowed to access the corresponding websites. # Display detailed information about URL address filtering. [LB] display firewall http url-filter host verbose URL-filter host is enabled. Default method: deny. The support for IP address: deny. The configured ACL group is There are 1 packet(s) being filtered. There are 1 packet(s) being passed. # Display URL address filtering information about all filtering entries. [LB] display firewall http url-filter host all SN Match-Times Keywords URL parameter filtering configuration example Network requirements Enable the URL parameter filtering function on the LB module, and add URL parameter filtering entry group to filter HTTP requests. Figure 124 Network diagram for URL parameter filtering configuration Configuration procedure # Configure IP addresses for the interfaces. (Omitted) # Configure the NAT policy for the outbound interface. <LB> system-view [LB] acl number

194 [LB-acl-basic-2200] rule 0 permit source [LB-acl-basic-2200] rule 1 deny source any [LB-acl-basic-2200] quit [LB] nat address-group [LB] interface GigabitEthernet 0/0.1 [LB-GigabitEthernet0/0.1] nat outbound 2200 address-group 1 [LB-GigabitEthernet0/0.1] quit # Enable the URL parameter filtering function and add URL parameter filtering entry group. [LB] firewall http url-filter parameter enable [LB] firewall http url-filter parameter keywords group Use the display firewall http url-filter parameter verbose command to display detailed URL parameter filtering information. [LB] display firewall http url-filter parameter verbose URL-filter parameter is enabled. There are 1 packet(s) being filtered. There are 2 packet(s) being passed. Use the display firewall http url-filter parameter all command to display URL parameter filtering information about all filtering entries. [LB] display firewall http url-filter parameter all SN Match-Times Keywords group Java blocking configuration example Network requirements Enable Java blocking on the LB module, add suffix keyword.js, and configure the LB module to allow only Java applet requests to the website at Figure 125 Network diagram for Java blocking configuration Configuration procedure # Configure IP addresses for the interfaces. (Omitted) # Configure the NAT policy for the outbound interface. <LB> system-view [LB] acl number 2200 [LB-acl-basic-2200] rule 0 permit source

195 [LB-acl-basic-2200] rule 1 deny source any [LB-acl-basic-2200] quit [LB] nat address-group [LB] interface Ten-GigabitEthernet 0/0.1 [LB-Ten-GigabitEthernet0/0.1] nat outbound 2200 address-group 1 [LB-Ten-GigabitEthernet0/0.1] quit # Configure an ACL numbered 2100 for Java blocking. [LB] acl number 2100 [LB-acl-basic-2100] rule 0 permit source [LB-acl-basic-2100] rule 1 deny source any [LB-acl-basic-2100] quit # Enable the Java blocking function, add blocking suffix keyword.js, and specify ACL 2100 for Java blocking. [LB] firewall http java-blocking enable [LB] firewall http java-blocking suffix.js [LB] firewall http java-blocking acl 2100 Use the display firewall http java-blocking verbose command to display detailed Java blocking information. [LB] display firewall http java-blocking verbose Java blocking is enabled. The configured ACL group is There are 0 packet(s) being filtered. There are 1 packet(s) being passed. Use the display firewall http java-blocking all command to display Java blocking information about all blocking suffix keywords. [LB] display firewall http java-blocking all SN Match-Times Keywords CLASS 2 0.JAR 3 1.js The above output shows that there are three Java blocking suffix keywords, of which.class and.jar are the default ones and.js is a user-defined one and has been matched once. Troubleshooting web filtering Failed to add filtering entry or suffix keyword due to upper limit Symptom When you try to add a URL address filtering entry or URL parameter filtering entry, the system prompts you that no more entry can be added. When you add a Java blocking or ActiveX blocking suffix keyword, the system prompts you that no more keyword can be added. 187

196 Analysis The number of URL address filtering entries, URL parameter filtering entries, Java blocking suffix keywords, or ActiveX blocking suffix keywords has reached the upper limit. Solution If necessary, remove some configured entries or keywords before adding new ones. Invalid characters are present in the configured parameter Symptom Analysis Solution When you configure a URL address filtering entry or URL parameter filtering entry, the system prompts you that there are invalid characters in the configured parameter. A URL address filtering entry can contain only 0 to 9, a to z, A to Z, dot., hyphen -, underline _, and wildcards ^, $, &, and *. A URL parameter filtering entry can contain only 0 to 9, a to z, A to Z, wildcards ^, $, &, and *, and other ASCII characters with values between 31 and 127. Ensure that all entered characters are valid. Invalid use of wildcard Symptom Analysis When you configure a URL address filtering entry or URL parameter filtering entry, the system prompts you that the wildcards are not used correctly. The wildcards for URL address filtering entries and those for URL parameter filtering entries have different usage restrictions: Table 40 Wildcards for URL address filtering entries Wildcard Meaning Usage guidelines ^ $ & * Matches website addresses starting with the keyword Matches website addresses ending with the keyword Stands for a valid character other than dot. Stands for any number of valid characters and spaces excluding dot. It can be present once at the beginning of a filtering entry. It can be present once at the end of a filtering entry. It can be present multiple times at any position of a filtering entry, consecutively or inconsecutively, but cannot be used together with *. It can be present once at the beginning or in the middle of a filtering entry. It cannot be at the end and cannot be used next to ^ or $. 188

197 Table 41 Wildcards for URL parameter filtering entries Wildcard Meaning Usage guidelines ^ $ & * Matches parameters starting with the keyword Matches parameters ending with the keyword Stands for one valid character Stands for a string of up to 4 valid characters, including spaces Can be present once at the beginning of a filtering entry. It can be present once at the end of a filtering entry. It can be present multiple times at any position of a filtering entry, consecutively or inconsecutively, and cannot be used next to *. If it is present at the beginning or end of a filtering entry, it must be next to ^ or $. It can be present once in the middle of a filtering entry. Solution Use the wildcards correctly according to the above principles. Invalid blocking suffix Symptom Analysis Solution When you configure a Java blocking suffix keyword or ActiveX blocking suffix keyword, the system prompts you that there are invalid suffix keywords. A blocking suffix requires a dot. as part of it. If no dot or multiple dots are configured, the configuration fails. Configure a suffix keyword according to the description in the analysis. ACL configuration failed Symptom Analysis Solution An ACL rule uses the IP address of a host in the internal network as the source address and permits requests from the host. The ACL is referenced for URL address filtering, Java blocking or ActiveX blocking, but it does not work. For URL address filtering, Java blocking and ActiveX blocking, ACLs permit access to servers in external networks rather than hosts in the internal network. This is because the internal network is assumed to be trusted. Specify the IP address of the server in the external network as the source IP address in the ACL rule. 189

198 Unable to access the HTTP server by IP address Symptom Analysis Solution After the URL address filtering function is enabled, you cannot access the HTTP server by its IP address. By default, the URL address filtering function disables access by IP address. Web requests that use the IP address to access the HTTP server will be filtered. Configure an ACL to permit web requests to the IP address of the HTTP server. 190

199 RSH configuration NOTE: The LB module supports configuring RSH only in the command line interface. RSH overview Remote shell (RSH) allows you to execute the commands provided by the operating system (OS) on a remote host. The remote host must run the RSH daemon. The LB module can serve as an RSH client and provides the rsh command as the tool for the RSH feature. Figure 126 shows a typical application scenario. Figure 126 RSH application The RSH daemon supports authentication of an RSH client by the username. To enable or disable the RSH daemon on Windows NT, 2000, XP, or 2003, use the Services component. Configuring RSH Configuration prerequisites The remote host runs the RSH daemon to support RSH service. There is a route between the router and the remote host. Configuration procedure Execute a remote host s OS command from the LB module by executing the following command: To do Use the command Remarks Execute an OS command of a remote host rsh host [ user username ] command remote-command Required Available in user view NOTE: If RSH daemon authentication is enabled on the remote host, you must provide the username configured on the remote host in advance. 191

200 RSH configuration example Network requirements As shown in Figure 127, the LB module acts as the RSH client. The remote host runs Windows 2000 and has had RSH daemon service started. The requirement is to set the time of the host remotely from the LB module. NOTE: Windows NT, 2000, XP, and 2003 are shipped with no RSH daemon. Therefore, the RSH daemon must be obtained and installed separately on the remote host. Figure 127 Network diagram for RSH configuration Internet LB Windows 2000 host /24 Configuration procedure 1. Configure the remote host # On the remote host, check that the RSH daemon has been installed and started properly by following these steps: From the Windows control panel, open the Administrative Tools folder. (For Windows XP, if you use the category view of the Control Panel window, select Administrative Tools from Performance and Maintenance.) Figure 128 Administrative Tools folder Double-click the Services icon to display the Services window. 192

201 Figure 129 Services window Check for the Remote Shell Daemon entry. If it does not exist, install the daemon first. Look at the Status column to check whether the Remote Shell Daemon service is started. In this example, the service is not started yet. Double-click the Remote Shell Daemon service row, and then in the popped up Remote Shell Daemon Properties window, click Start to start the service, as shown in Figure 130. Figure 130 Remote Shell Daemon Properties window 2. Configure the LB module: # Configure the route to the remote host. The configuration procedure is omitted. # Set the time of the host remotely. 193