This help contains the following topics:

·     Introduction

¡     Security zone

¡     Whitelist

¡     Client verification

·     Restrictions and guidelines

·     Configure security zones

¡     Configure a security zone

¡     Configure the whitelist

¡     Configure client verification

Introduction

Security zone

A security zone is a collection of interfaces that have the same security requirements. You can configure security zones to implement security zone-based security management.

Security zone members

A security zone can include the following types of members:

·     Layer 2 interface-VLAN combination

·     Layer 3 interface:

¡     Layer 3 Ethernet interface

¡     Layer 3 logical interface, such as a Layer 3 subinterface

Security zone-based packet processing rules

The following table describes how the device handles packets when security zone-based security management is configured:

Packets	Action
Packets between an interface that is in a security zone and an interface that is not in any security zone	Discard.
Packets between two interfaces that are in the same security zone	Discard by default.
Packets between two interfaces that belong to different security zones	Forward or discard, depending on the matching security control policy. If no policy is applied or the policy does not exist or does not take effect, the packets are discarded.
Packets between two interfaces that are not in any security zone	Discard.
Packets originated from or destined for the device itself	Forward or discard, depending on the matching object policy. By default, these packets are discarded.

 

Whitelist

This feature exempts packets sourced from the subnets specified in the whitelisted address object group from attack detection. Packets from the whitelisted address are directly forwarded whether they are attack packets or not.

The whitelist can contain only one address object group. The address object group can only be manually added to or deleted from the whitelist.

Client verification

The client verification feature protects servers against TCP, DNS, HTTP, and SIP flood attacks. The device enabled with client verification is located between the client and the protected server, and verifies the connection initiated by the client.

IP addresses protected by client verification can be manually added or automatically learned:

·     You can manually add protected IP addresses. The device performs client verification when it receives the first packet destined for a protected IP address.

·     The client verification can automatically add victims' IP addresses to the protected IP list when collaborating with flood attack detection. Make sure client verification is specified as the flood attack prevention action.

The device directly forwards packets from trusted IP addresses.

TCP client verification

The TCP client verification feature protects TCP servers against the following flood attacks:

·     SYN.

·     ACK.

·     SYN-ACK.

·     FIN.

·     RST.

TCP client verification can operate in the following modes:

·     Safe reset—Enables unidirectional TCP proxy for packets only from TCP connection initiators. The unidirectional TCP proxy is sufficient for most scenarios because attacks are often seen from clients.

·     SYN cookie—Enables bidirectional TCP proxy for TCP clients and servers.

The safe reset mode functions as follows:

1.     After receiving a SYN packet destined for a protected server, the TCP proxy sends back a SYN ACK packet with an invalid sequence number.

2.     If the TCP proxy receives an RST packet from the client, the client is verified as legitimate.

3.     The TCP proxy adds the client's IP address to the trusted IP list. The client initiates the connection again and the TCP proxy directly forwards the TCP packets to the server.

The safe reset mode requires that TCP clients comply with the TCP protocol suite. The TCP proxy will deny a legitimate client to access the server if the client does not comply with the TCP protocol suite. With client verification, the TCP connection establishment takes more time than normal TCP connection establishment.

SYN cookie mode requires two TCP connections to be established as follows:

4.     After receiving a SYN packet from a client to a protected server, the TCP proxy sends back a SYN ACK packet with the window size 0. If the client responds with an ACK packet, the client is verified as legitimate. The proxy device establishes a TCP connection with the client.

5.     The TCP proxy device establishes a connection with the server through a new three-way handshake that has a different window size. This connection uses a different sequence number from the connection between the client and proxy device.

In SYN cookie mode, the TCP proxy is the server proxy that communicates with clients and the client proxy that communicates with server. Choose this mode when the following requirements are met:

·     The TCP proxy device is deployed on the key path that passes through the ingress and egress of the protected server.

·     All packets exchanged between clients and server pass through the TCP proxy device.

DNS client verification

The DNS client verification feature protects DNS servers against DNS flood attacks. It is configured on the device where packets from the DNS clients to the DNS servers pass through. The device with DNS client verification feature configured is called a DNS client authenticator.

The DNS client verification functions as follows:

1.     Upon receiving a UDP DNS query destined for a protected server, the DNS client authenticator responds with a DNS truncate (TC) packet. The DNS truncate packet requires the client to initiate a query in a TCP packet.

2.     When the authenticator receives a DNS query in a TCP SYN packet to port 53 from the client, the authenticator responds with a SYN-ACK packet that contains an incorrect sequence number.

3.     When the authenticator receives a RST packet from the client, the authenticator verifies the client as legitimate.

4.     The authenticator adds the client's IP address to the trusted IP list and forwards the trusted client's subsequent packets to the server.

The DNS client verification feature requires that DNS clients comply with the TCP/IP protocol suite. The DNS client authenticator will deny a legitimate client to access the server if the client does not comply with the TCP protocol suite. With client verification, the DNS connection establishment takes more time than normal TCP connection establishment.

DNS reply source verification

The DNS reply source verification feature protects DNS clients from DNS reply flood attacks. The device with DNS reply source verification feature configured is called a DNS reply authenticator.

The DNS reply source verification functions as follows:

1.     Upon receiving a UDP DNS reply destined for a protected client, the DNS reply authenticator sends back a DNS query packet with the locally generated query ID and port number.

2.     After receiving the DNS query, a valid DNS server responds with a DNS reply that contains a new query ID and destination port.

3.     The DNS reply authenticator verifies the query ID and destination port in the reply. If the query ID and destination port are the same as the query ID and port number the authenticator has sent, the DNS server passes verification. The authenticator will forward subsequent packets from the server.

HTTP client verification

The HTTP client verification feature protects HTTP servers against HTTP flood attacks. It is configured on the device where HTTP GET or POST request packets from the HTTP clients to the HTTP servers pass through. A device with HTTP client verification feature configured is called an HTTP client authenticator.

The HTTP client authenticator uses HTTP GET requests to verify the HTTP client as follows:

1.     Upon receiving a SYN packet destined for a protected HTTP server, the HTTP client authenticator performs TCP client verification in SYN cookie mode. If the client passes the TCP client verification, a TCP connection is established between the client and the authenticator.

2.     When the authenticator receives an HTTP GET packet from the client, it performs the first redirect verification. The authenticator records the client information and responds with an HTTP Redirect packet. The HTTP Redirect packet contains a redirect URI and requires the client to terminate the TCP connection.

3.     After receiving the HTTP Redirect packet, the client terminates the TCP connection and then establishes a new TCP connection with the authenticator.

4.     When the authenticator receives the HTTP GET packet, it performs the second redirection verification. The authenticator verifies the following information:

¡     The client has passed the first redirection verification.

¡     The URI in the HTTP GET packet is the redirect URI.

5.     If the client passes the second redirection verification, the authenticator adds its IP address to the trusted IP list, and responds a Redirect packet. The Redirect packet contains the URI that the client originally carried and requires the client to terminate the TCP connection.

6.     The authenticator directly forwards the trusted client's subsequent packets to the server.

The HTTP client authenticator uses HTTP POST requests to verify the HTTP client as follows:

7.     Upon receiving a SYN packet destined for a protected HTTP server, the HTTP client authenticator performs TCP client verification in SYN Cookie mode. If the client passes the TCP client verification, a TCP connection is established between the client and the authenticator.

8.     When the authenticator receives an HTTP POST request from the client, it performs the redirect verification. The authenticator records the client information and responds with an HTTP Redirect packet. The HTTP Redirect packet contains a redirect URI and the Set-Cookie header, and requires the client to terminate the TCP connection.

9.     After receiving the HTTP Redirect packet, the client terminates the TCP connection and then establishes a new TCP connection with the authenticator.

10.     When the authenticator receives the HTTP POST request, it performs the timeout verification. The authenticator verifies the following information:

¡     The client has passed the redirection verification.

¡     The HTTP POST request contains a valid cookie.

11.     If the client passes the timeout verification, the authenticator adds its IP address to the trusted IP list, and responds with an HTTP Timeout packet. The Timeout packet contains the URI that the client originally carried and requires the client to terminate the TCP connection.

12.     The authenticator directly forwards the trusted client's subsequent packets to the server.

SIP client verification

The SIP client verification feature protects SIP servers against SIP flood attacks.

The device with SIP client verification feature configured is called a SIP client authenticator. The SIP client verification process is as follows:

1.     Upon receiving a UDP INVITE packet destined for a protected server, the SIP client authenticator sends back an OPTIONS packet with a branch value.

2.     After receiving the OPTIONS packet, the client sends a reply to the SIP client authenticator.

3.     When receiving the reply, the SIP client authenticator verifies the branch value in the reply. If the branch value in the reply packet is the same as the branch value in the OPTIONS packets that the SIP client authenticator has sent, the client passes verification. The authenticator will forward subsequent packets from the client.

A legitimate SIP client might not pass the client verification if packets sent by the SIP client do not contain complete header information due to fragmentation.

Restrictions and guidelines

·     A Layer 3 interface can be added to only one security zone.

·     A Layer 2 interface-VLAN combination can be added to only one security zone.

·     If a packet does not match any zone pair between specific security zones, the device searches for the any-to-any zone pair.

¡     If the zone pair exists, the device processes the packet by using the security policies applied to the zone pair.

¡     If the zone pair does not exist, the device discards the packet.

·     By default, the device forwards packets between the Management and Local zones.

·     For packets between the Management and Local security zones, the device uses only security control policies applied to the zone pairs of the two security zones.

Configure security zones

Configure a security zone

1.     Click the Network tab.

2.     In the navigation pane, select Security Zones.

3.     Click Create.

4.     Configure security zone parameters as needed.

Table 1 Security zone configuration items

Item	Description
Security zone name	Configure the security zone name.
VLAN members	Add VLANs to the security zone as members.
Layer 2 members	Add Layer 2 interfaces to the security zone as members.
Layer 3 members	Add Layer 3 interfaces to the security zone as members.
Attack defense policy	Specify an attack defense policy for the security zone.
Whitelist	Enable or disable the whitelist.
TCP verification	Enable or disable TCP client verification on the security zone: ·     Close—Disables TCP client verification. ·     SYN cookie—Enables bidirectional TCP proxy for TCP client verification. ·     Safe reset—Enables unidirectional TCP proxy for TCP client verification.
DNS verification	Enable or disable DNS client verification on the security zone.
DNS reply verification	Enable or disable DNS reply verification on the security zone.
HTTP verification	Enable or disable HTTP client verification on the security zone.
HTTPS verification	Enable or disable HTTPS client verification on the security zone.
SIP verification	Enable or disable SIP client verification on the security zone.
Check mode	This item is available only when uRPF is enabled. Set the uRPF mode: ·     Strict—In this mode, the source address and receiving interface of a packet must match the destination address and output interface of a FIB entry to pass strict uRPF check. ·     Loose—In this mode, the source address of a packet must match the destination address of a FIB entry to pass loose uRPF check.
Check exemption	This item is available only when uRPF is enabled. Specify an ACL for attack detection exemption. You can select an existing ACL or create a new ACL. The created ACL will be displayed on the Objects > ACLs page.
Allow using default route for uRPF check	This item is available only when uRPF is enabled. Allow using the default route for uRPF check.
Enable link layer check	This item is available only when uRPF is enabled. Enables link layer check (Ethernet link).

 

5.     Click OK. The newly created security zone is displayed on the Security Zones page.

Configure the whitelist

The whitelist feature exempts packets sourced from the IP addresses specified in the whitelisted address object group from attack detection.

Only address object groups can be manually added to or deleted from the whitelist. To configure an address object group, access the Objects > Object Groups page.

Procedure

1.     Click the Network tab.

2.     In the navigation pane, select Security Zones > Whitelist.

3.     Click Create.

4.     Add an address object group to the whitelist.

Table 2 Whitelist configuration items

Item	Description
Object group type	Select an IP version, IPv4 or IPv6.
Object group name	You can select an existing address object group or create a new one. The newly created address object group will be displayed on the Objects > Object Groups page.

 

5.     Click OK.

Configure client verification

IP addresses protected by client verification can be manually added or automatically learned. The device can automatically add victims' IP addresses to the protected IP list when client verification collaborates with flood attack detection. The device directly forwards packets from trusted IP addresses. Make sure client verification is specified as the flood attack prevention action.

Procedure

1.     Click the Network tab.

2.     In the navigation pane, select Security Zones > Client Verification.

3.     Click Create.

4.     Configure client verification.

Table 3 Client verification configuration items

Item	Description
Protocol	Protocol type for client verification: ·     TCP—Specifies TCP client verification. ·     DNS—Specifies DNS client verification. ·     DNS reply—Specifies DNS reply verification. ·     HTTP—Specifies HTTP client verification. ·     HTTPS—Specifies HTTPS client verification. ·     SIP—Specifies SIP client verification.
VRF	VRF to which the protected IP address belongs. You can select an existing VRF or create a new one. The newly created VRF will be displayed on the Network > VRF page.
IP version	Select an IP version, IPv4 or IPv6.
IP address	Protected IP address. All connection requests destined for this address are verified by the client verification feature. The attacker sends TCP connection requests, DNS queries, DNS replies, HTTP GET requests, HTTP POST requests, HTTPS request, or SIP UDP INVITE requests to the protected IP.
Port number	Number of a protected port. By default, DNS client verification protects port 53, HTTP client verification protects port 80, HTTPS client verification protects port 443, SIP client verification protects port 5060, and TCP client verification protects all ports.

 

5.     Click OK. The Client Verification page displays protected IP addresses manually added and automatically learned.