Ddos Mitigation Guide (For Adc) : Acos 5.2.1-P1

ACOS 5.2.
1-P1
DDoS Mitigation Guide (for ADC)
February, 2021

© 2021 A10 Networks, Inc.CONFIDENTIAL AND PROPRIETARY- ALL RIGHTS RESERVED.

Information in this document is subject to change without notice.
PATENT PROTECTION
A10 Networks, Inc. products are protected by patents in the U.S. and elsewhere. The following website is provided
to satisfy the virtual patent marking provisions of various jurisdictions including the virtual patent marking pro-
visions of the America Invents Act. A10 Networks, Inc. products, including all Thunder Series products, are pro-
tected by one or more of U.S. patents and patents pending listed at:
a10-virtual-patent-marking.
TRADEMARKS
A10 Networks, Inc. trademarks are listed at: a10-trademarks
CONFIDENTIALITY
This document contains confidential materials proprietary to A10 Networks, Inc.. This document and information
and ideas herein may not be disclosed, copied, reproduced or distributed to anyone outside A10 Networks, Inc.
without prior written consent of A10 Networks, Inc..
DISCLAIMER
This document does not create any express or implied warranty about A10 Networks, Inc. or about its products or
services, including but not limited to fitness for a particular use and non-infringement. A10 Networks, Inc. has
made reasonable efforts to verify that the information contained herein is accurate, but A10 Networks, Inc.
assumes no responsibility for its use. All information is provided "as-is." The product specifications and features
described in this publication are based on the latest information available; however, specifications are subject to
change without notice, and certain features may not be available upon initial product release. Contact A10 Net-
works, Inc. for current information regarding its products or services. A10 Networks, Inc. products and services
are subject to A10 Networks, Inc. standard terms and conditions.
ENVIRONMENTAL CONSIDERATIONS
Some electronic components may possibly contain dangerous substances. For information on specific com-
ponent types, please contact the manufacturer of that component. Always consult local authorities for regulations
regarding proper disposal of electronic components in your area.
FURTHER INFORMATION
For additional information about A10 products, terms and conditions of delivery, and pricing, contact your nearest
A10 Networks, Inc. location, which can be found by visiting www.a10networks.com.
Table of Contents
Chapter 1: Getting Started 11
Application Access Management 12
Login Portal 12
Online Certificate Status Protocol (OCSP) 12
Authentication Relay 12
AAA Health Monitoring and Load Balancing 13
Online Certificate Status Protocol 13
DDoS Mitigation 13
Attack Detection and Prevention using ZBAR 14
Single CPU Attack Prevention 15
Policy-Based SLB 15
SYN Cookies 15
IP Limiting 16
ICMP Rate Limiting 16
Web Application Firewall 16
Slowloris Prevention 17
DNS Application Firewall 17
DNSSEC 17
SSL Insight 17
Geo-location-based VIP Access 18
Chapter 2: IP Anomaly Filtering 19

Overview of IP Anomaly Filtering 20
IP Anomaly Filters 20
Frag 20
IP-option 21
Land-attack 21
Zero-length TCP Window 21
Out-of-sequence Packet 21
Ping-of-death 21
TCP-no-flag 21
TCP-SYN-FIN 21
3
Contents
ACOS 5.2.1-P1 DDoS Mitigation Guide (For ADC)
TCP-SYN-frag 21
IP Anomaly Filters for System-wide PBSLB 21
Threshold 22
SOCKSTRESS_CHECK Session State 22
Implementation Notes 22
Configuring IP Anomaly Filtering 23
Using the GUI to Configure IP Anomaly Filtering 23
Using the CLI to Configure IP Anomaly Filtering 23
Displaying IP Anomaly Statistics 24
Using the GUI to Display IP Anomaly Statistics 24
Using the CLI to Display IP Anomaly Statistics 24
Chapter 3: Policy-based SLB 25

Overview 26
Configuring a Black/White List 26
Configuration Details and Examples 27
Example Black/White List 29
Dynamic Black/White-list Client Entries 29
Connection Limit for Dynamic Entries 30
Aging of Dynamic Entries 30
Wildcard Address Support in PBSLB Policies Bound to Virtual Ports 30
Configuring System-wide PBSLB 31
Options for System-wide PBSLB Policies 31
Using the GUI to Configure System-wide PBSLB 31
Using the CLI to Configure System-wide PBSLB 32
Displaying and Clearing System-wide PBSLB Information 32
Configuring PBSLB for Individual Virtual Ports 33
Configuration Details 33
Using the GUI to Configure PBSLB for Individual Virtual Ports 34
Using the CLI to Configure PBSLB for Individual Virtual Ports 35
Configuration Example for Sockstress Attack Protection 36
PBSLB Statistics Display 37
Chapter 4: SYN Cookies 39

Overview of SYN Cookies 40
4
Contents
SYN Flood Attacks 40

Identifying SYN Flood Attacks 40
ACOS SYN-cookie Protection 41
Dynamic SYN Cookies 42
SYN Cookie Buffering 43
SACK and MSS with Software-based SYN-cookies 43
SACK 43
MSS 44
Configuring SYN Cookies 44
Enabling SYN-cookie Support 44
Details 44
FTA Models 45
Non-FTA Models 46
Configuration with Target VIP and Client-side Router in Different Subnets 46
Modifying the Threshold for TCP Handshake Completion 47
Configuring SYN-cookie Buffering 47
Details 48
Using the GUI to Configure SYN-cookie Buffering 48
Using the CLI to Configure SYN-cookie Buffering 49
Viewing SYN-cookie Statistics 49
Using the GUI to View SYN-cookie Statistics 49
Using the CLI to View SYN-cookie Statistics 50
L4 SYN attack 50
L4 TCP Established 50
CLI Example 1: View Attack Prevention Statistics 50
CLI Example 2: View SYN Attack Counter 52
CLI Example 3: View Legitimate Session Counter 52
CLI Example 4: View SYN-cookie Buffering Statistics 52
SYN Attack Counter Support for L3V 52
Chapter 5: IP Limiting 55
Overview of IP Limiting 56
Understanding Class Lists 56
Class List Syntax 57
5
Contents
IP Address Matching 58
Example Class Lists 59
Configuring Class Lists 59
Using the GUI to Import a Class List 60
Using the GUI to Configure a Class List 60
Using the CLI to Import a Class List 60
Using the CLI to Configure a Class List 61
Understanding IP Limiting Rules 61
Parameters 61
Match IP Address 63
Request Limiting and Request-Rate Limiting in Class Lists 63
CLI Examples: Request Limiting and Request-rate Limiting Settings Are Used 64
Example 1: GLID Used in Policy Template and Bound to Virtual Port 64
Example 2: LID Used in Policy Template and Bound to Virtual Port 64
CLI Examples: Request Limiting and Request-rate Limiting Settings Are Not Used 65
Example 1: Policy Template Bound to Virtual Server Instead of Virtual Port 65
Example 2: System GLID 65
Example 3: System-wide Policy Template 66
Configuring Source IP Limiting 66
CLI Examples - Configuration 66
Configuring System-wide IP Limiting With a Single Class 67
Configuring System-wide IP Limiting With Multiple Classes 67
Configuring IP Limiting on a Virtual Server 68
Configuring IP Limiting on a Virtual Port 68
Configuring Class List Entries That Age Out 69
CLI Examples - Display 70
Viewing Class-Lists 70
Viewing IP Limiting Rules 70
Viewing IP Limiting Statistics 71
Chapter 6: ICMP Rate Limiting 73

ICMP Rate Limiting Overview 74
Configuring ICMP Rate Limiting 74
ICMP Rate Limiting Parameters 74
6
Contents
Using the GUI to Configure ICMP Rate Limiting 75

Configuring ICMP Rate Limiting on an Ethernet Interface 75
Configuring ICMP Rate Limiting in a Virtual Server Template 75
Using the CLI to Configure ICMP Rate Limiting 76
Chapter 7: HTTP Slowloris Prevention 77

Details 78
Using the GUI to Configure Request Header Timeout 78
Using the CLI to Configure Request Header Timeout 78
Chapter 8: DNS Application Firewall 79

Overview of the DNS Application Firewall 80
DNS Sanity Check 80
Sanity Checking for Virtual-Port Type UDP 80
Sanity Checking for Virtual-Port Type DNS-UDP 81
Configuring DNSSEC 81
Details 82
Using the CLI to Configure DNSSEC 82
DNS Application Firewall Setup 82
Service-Group Redirection for DNS “Any” Requests (using aFleX) 83
Chapter 9: DNS Response Rate Limiting 85

Overview of DNS Response Rate Limiting (RRL) 86
Details 86
DNS Reflection Attacks 86
Challenges of Stopping DNS Reflection Attacks 87
ACOS Mitigation of DNS Reflection Attacks 87
Two-tiered Rate-limiting System for DNS Queries 87
Configuration Parameters for DNS RRL 88
Setting the Rate Limits 88
Protecting System Resources 89
Allowing Valid DNS Queries to Pass 89
More Information 89
Limitations 89
Configuration Example 91
Using the GUI to Configure DNS RRL 91
7
Contents
Using the CLI to Configure and Monitor DNS RRL 92
Chapter 10: DNSSEC Support 95

Overview of DNSSEC Support 96
Details 96
DNS without Security 97
DNSSEC (DNS with Security) 100
Building the Chain of Trust 103
Dynamic Key Generation and Rollover 105
Key Generation and Rollover Parameters 106
Key Rollover and Distribution Process 106
Key Regeneration Log Messages 107
Importing/Exporting Key Files 108
Emergency Key Rollover 108
Changing Key Settings 109
Hardware Security Module Support 109
DNSSEC Configuration 109
Modes 109
DNSSEC Configuration Example 110
Configuring an HSM Template 110
Configuring a DNSSEC Template 110
Configuring GSLB 110
Configuring a GSLB Policy and Enable Server Mode 114
Binding the DNSSEC Template to the Zone 114
Configuring DNSSEC Standalone 114
Configuring the VIP for DNSSEC Requests 115
Chapter 11: Location-Based VIP Access 117

Overview of Location-based VIP Access 118
Configuration Using a Class List 118
Configuration Using a Black/White List 120
Details 120
Configuring the Black/White List 120
Methods 121
Using the GUI 122
8
Contents
CLI Example 123

Enabling Full-Domain Checking 124
Details 124
Using the GUI to Configure Full-Domain Checking 125
Using the CLI to Configure Full-Domain Checking 125
Enabling PBSLB Statistics Counter Sharing 126
Details 126
Using the GUI to Enable PBSLB Statistics Counter Sharing 126
Using the CLI to Enable PBSLB Statistics Counter Sharing 127
Glossary 129
9
Contents
10
Chapter 1: Getting Started
ACOS provides a suite of security features that allow you to protect your customer traffic:
The following topics are covered:
Application Access Management 12
Online Certificate Status Protocol 13
DDoS Mitigation 13
Attack Detection and Prevention using ZBAR 14
Single CPU Attack Prevention 15
Policy-Based SLB 15
SYN Cookies 15
IP Limiting 16
ICMP Rate Limiting 16
Web Application Firewall 16
Slowloris Prevention 17
DNS Application Firewall 17
DNSSEC 17
SSL Insight 17
Geo-location-based VIP Access 18
11
ACOS 5.2.1-P1 DDoS Mitigation Guide (For ADC) Feedback
Application Access Management

Application Access Management (AAM) is an ACOS security feature that optimizes Authentication,
Authorization, and Accounting (AAA) for client-server traffic.
Login Portal 12
Online Certificate Status Protocol (OCSP) 12
Authentication Relay 12
AAA Health Monitoring and Load Balancing 13
NOTE: For more information about AAM, see the Application Access Man-
agement Guide.
Login Portal
Provides a sign-on interface. By using a request-reply exchange or using a Web-based form,

ACOS obtains the your credentials and uses a backend AAA server to verify these credentials.
Online Certificate Status Protocol (OCSP)
Provides certificate verification services and eliminates the need to import certificate revocation list
(CRL) files to the ACOS device.
The CRLs are maintained on the OCSP responder (server). When a client sends its certificate as part
of a request for a secured service, ACOS first sends the certificate to the OCSP responder for veri-
fication. After the certificate is verified, the client can access secured services.
Authentication Relay
Offloads your AAA servers. ACOS contacts the backend AAA servers on behalf of the clients, and
after a server responds, ACOS caches the reply and uses this reply for subsequent client requests.
12
Feedback ACOS 5.2.1-P1 DDoS Mitigation Guide (For ADC)
AAA Health Monitoring and Load Balancing
Load balances authentication traffic among a group of AAA servers. ACOS supports custom health
checks for LDAP, RADIUS, Kerberos, and OCSP.
Online Certificate Status Protocol

Online Certificate Status Protocol (OCSP) is a network component that provides certificate veri-
fication services.
OCSP is an efficient alternative to CRLs, which is also supported by ACOS. To use CRLs with ACOS,
you must import the CRL files into the ACOS device. If you use OCSP, ACOS can also send cer-
tificate verification queries to external OCSP servers (generally called responders). This process
only occurs when a client sends a certificate as part of a request to set up a secure session to a
server application that is managed by ACOS.
NOTE: For more information about OSCP, see: Checking Client Certificates
Using OCSP in the SSL Configuration Guide and AAM with OCSP in
the Application Access Management Guide.
DDoS Mitigation
Distributed Denial of Service (DDoS) is a type of DoS attack where multiple systems that are infec-
ted with a Trojan or malware are, in turn, used to target a particular system. This process causes a
denial of service. If a hacker (attacker) mounts an attack from one host, this is classified as a DoS
attack. In a DDoS attack, many systems are used simultaneously to launch attacks against a
remote system.
ACOS includes filters that check traffic for IP anomalies that can indicate a DDoS attack.
NOTE: For more information about DDos Mitigation, see IP Anomaly

Filtering.
13
Attack Detection and Prevention using ZBAR

The ADC has combined multiple infrastructural capabilities to create an enhanced solution that
identifies volumetric and IOT DDoS attacks on the SLB virtual port. It employs mitigation policies to
provide excellent application responsiveness for the good actors. The bad sources are dropped or
rate-limited based on their computed threat score. The attack-detection command needs to be
set to enable this feature.
This solution employs the following infrastructure capabilities:
Analytics infrastructure – It adaptively baselines multiple traffic metrics and creates a mon-
itoring entity that observes and determines the traffic baselines and sets attack thresholds.
On attack detection, it triggers the ZBAR infrastructure.
ZBAR (Zero Day source behavior Attack Recognition) infrastructure - It dynamically classifies
the incoming traffic based on real-time traffic conditions. The ZBAR framework performs clus-
tering based on multiple metrics from the sources hitting the attacked Destin-
ation/Destination-Service. By mapping the sources to these metrics, ZBAR determines the
miscreant source/sources, along with the associated confidence score, suspected of caus-
ing a DDoS attack.
Packet capture infrastructure – It automatically captures a few packets from the deemed
attackers and stores them as evidence and signature extraction. You can view these cap-
tured packets using the following show command,
show visibility packet-capture packet-capture-files
The captured packets for the bad sources can also be exported using the following com-
mand,
export visibility pktcapture-file file
To enable this feature, refer to the following configuration:

ACOS (config)# slb virtual-server vip1 12.12.12.203
ACOS (config-slb vserver)# port 80 tcp
ACOS (config-slb vserver-vport)# attack-detection
Additionally, the following show commands are added to view ZBAR information:
show visibility zbar dest
show visibility zbar dest bad-sources
14
For more information, see the Application Delivery Controller Guide.
Single CPU Attack Prevention

The CPU Round Robin feature is used to mitigate the effects of Denial of Service (DoS) attacks that
target a single CPU on the ACOS device. The command system cpu-load-sharing is used to con-
figure thresholds for CPU load sharing. If a threshold exceeds, CPU load sharing is activated, and
additional CPUs are enlisted to help process the traffic and relieve the burden on the targeted CPU.
A round robin algorithm distributes packets across all the other data CPUs on the device. Load shar-
ing will remain in effect until traffic no longer exceeds the thresholds that originally activated the
feature.
NOTE: For more information about the command system cpu-load-shar-

ing, see Command Line Reference guide.
Policy-Based SLB
Policy-based SLB (PBSLB) allows you to “black list” or “white list” individual clients or client subnets.
Based on actions that you specify, ACOS will allow (white list) or drop (black list) traffic from specific
client hosts or subnets in the list.
NOTE: For more information about policy-based SLB, see Policy-based SLB.
SYN Cookies
SYN cookies provide protection against a common type of DDoS attack, the TCP SYN flood attack.
The attacker sends a high volume of TCP-SYN requests to the target device, but the attacker does
not reply to SYN-ACKs to complete the three-way handshake for any of the sessions. The purpose
of the attack is to consume the target’s resources with half-open TCP sessions.
When SYN cookies are enabled, the ACOS device can continue to serve legitimate clients during
TCP SYN flood attacks, while preventing illegitimate traffic from consuming system resources.
NOTE: For more information about SYN cookies, see SYN Cookies.
15
IP Limiting
IP limiting provides a enhanced implementation of the source IP connection limiting and con-
nection-rate limiting feature that was available in earlier releases.
NOTE: For more information about IP limiting, see IP Limiting.
ICMP Rate Limiting

ICMP rate limiting protects against ICMP-based or ICMPv6-based DoS attacks, such as Smurf
attacks, which consist of floods of spoofed broadcast ping messages. ICMP rate limiting monitors
the rate of ICMP traffic and drops ICMP packets when the configured thresholds have been
exceeded.
NOTE: For more information about ICMP rate limiting, see ICMP Rate Lim-
iting.
Web Application Firewall

ACOS provides additional security for your Web servers with the Web Application Firewall (WAF) fea-
ture. WAF filters communication between end-users and Web applications to protect Web servers
and sites from unauthorized access and malicious programs.
This new layer of security examines the following types of traffic to safeguard against Web attacks
and protect sensitive information hosted on Web servers:
Incoming user requests

Output from Web servers
Access to Web site content
NOTE: Fore more information about WAF, see the Web Application Firewall
Guide.
16
Slowloris Prevention
In addition to the WAF, ACOS includes an HTTP security option that prevents Slowloris attacks, in
which the attacker attempts to consume resources on the target system with incomplete HTTP
request headers.
NOTE: For more information about Slowloris prevention, see HTTP Slowloris
Prevention.
DNS Application Firewall

DNS Application Firewall (WAF) filters for malformed queries. The DAF also protects against “any”
queries for all DNS records. An “any” query is a request for a DNS server to send copies of all of its
DNS records. Because this type of query can heavily consume DNS resources, it is sometimes used
as a DDoS attack.
NOTE: For more information about DAF, see DNS Application Firewall.
DNSSEC
ACOS supports DNS Security Extensions (DNSSEC). In Global Server Load Balancing (GSLB)
deployments, you can use DNSSEC with Hardware Module Security (HSM) to dynamically secure
DNS resource records for GSLB zones.
NOTE:
For more information about DNSSEC, see DNSSEC Support.
The ACOS also supports DNS caching for DNSSEC, but
DNSSEC support for caching does not require GSLB.
SSL Insight
SSL Insight (SSLi) provides high-performance SSL decryption and re-encryption. When used in
conjunction with third-party traffic inspection devices, SSLi adds content-level security.
17
SSLi decrypts SSL-encrypted client traffic and sends the decrypted traffic to a third-party traffic
inspection device. Traffic that is permitted by the traffic inspection device is re-encrypted by ACOS
and forwarded to its destination.
NOTE: For more information about SSL Insight, see “SSL Insight” in the SSL
Configuration Guide.
Geo-location-based VIP Access

Geo-location-based VIP access controls the access to a VIP based on the client’s location. You can
configure ACOS to perform one of the following actions for traffic from a client, depending on the
location of the client:
Drop the traffic

Reset the connection
If configured by using a black/white list, send the traffic to a specific service group
ACOS determines a client’s location by looking up the client’s subnet in the geo-location database
that is used by Global Server Load Balancing (GSLB).
NOTE: For more information about Geo-location-based VIP access, see Loca-
tion-Based VIP Access.
18
Chapter 2: IP Anomaly Filtering
ACOS helps you detect and mitigate Distributed Denial of Service (DDoS) attacks. One of the fea-
tures, IP anomaly filtering, can protect against numerous types of attacks.
Overview of IP Anomaly Filtering 20
Configuring IP Anomaly Filtering 23
Displaying IP Anomaly Statistics 24
19
Overview of IP Anomaly Filtering

IP anomaly filtering detects and drops packets that contain the common signatures of DDoS
attacks.
IP Anomaly Filters 20
IP Anomaly Filters for System-wide PBSLB 21
Threshold 22
SOCKSTRESS_CHECK Session State 22
Implementation Notes 22
IP Anomaly Filters
Users can enable the following IP anomaly filters. This section has the following sub-sections:
Frag 20
IP-option 21
Land-attack 21
Zero-length TCP Window 21
Out-of-sequence Packet 21
Ping-of-death 21
TCP-no-flag 21
TCP-SYN-FIN 21
TCP-SYN-frag 21
Frag
Drops all IP fragments, which can be used to attack hosts that run IP stacks with known vul-
nerabilities in their fragment reassembly code.
20
IP-option
Drops all packets with IP options.
Land-attack
Drops spoofed SYN packets that contain the same IP address as the source and destination. These
packets can be used to launch an “IP land attack”.
Zero-length TCP Window

This a type of the filtering window.
Out-of-sequence Packet
This is a type of filtering packet.
Ping-of-death
Drops all jumbo ICMP packets, which are also known as “ping of death” packets.
TCP-no-flag
Drops all TCP packets that have no TCP flags set.
TCP-SYN-FIN
Drops all TCP packets in which both the SYN and FIN flags are set.
TCP-SYN-frag
Drops incomplete (fragmented) TCP Syn packets, which can be used to launch TCP Syn flood
attacks.
IP Anomaly Filters for System-wide PBSLB
The following IP anomaly filters are supported for system-wide PBSLB, although you can also use
them without PBSLB:
Invalid HTTP or SSL payload

Zero-length TCP window
Out-of-sequence packet
21
When these filters are enabled, the ACOS device checks for these anomalies in new HTTP or HTTPS
connection requests from clients.
Filtering for these anomalies is disabled by default. However, if you configure a system-wide
PBSLB policy, the filters are automatically enabled. You also can configure the filters on an indi-
vidual basis.
NOTE:
These filters are supported only for HTTP and HTTPS traffic.
For information about system-wide PBSLB.
Threshold
The threshold specifies the number of times the anomaly is allowed to occur in a client’s con-
nection requests.
If system-wide PBSLB is configured, ACOS applies the policy’s over-limit action to clients that
exceed the threshold. The range for the threshold value is 1-127 occurrences of the anomaly, and
the default value is 10.
NOTE: The thresholds are not tracked by PBSLB policies that are bound to
individual virtual ports.
SOCKSTRESS_CHECK Session State
When the ACOS device checks a data packet against the new IP anomaly filters, the client’s session
is in the SOCKSTRESS_CHECK state. You might see this state if you are viewing debug output for
the client’s session.
Implementation Notes
Consider the following information when you work with IP anomaly filtering:
All IP anomaly filters are supported for IPv4.

All IP anomaly filters, except IP-option filtering, are supported for IPv6.
22
DDoS protection is hardware-based on the following models:

Thunder 6430S, Thunder 6430, and Thunder 5430S
AX 3200-12
DDoS protection is software-based on other models.

DDoS detection applies only to Layer 3, Layer 4, and Layer 7 traffic.
Layer 2 traffic is not affected by the feature. Layer 4 and Layer 7 DDoS applies only to soft-
ware releases that support Server Load Balancing (SLB).
All IP anomaly filters, except “IP-option”, apply to IPv4 and IPv6. The “IP-option” filter applies
only to IPv4.
The ping-of-death option drops all IP packets longer than 32000 bytes on the following
models
Thunder 3030S, Thunder 1030S, and Thunder 930
The option drops IP packets that are longer than 65535 bytes on the other models.
Configuring IP Anomaly Filtering

By default, all the IP anomaly filters that are described in topics are disabled. You can enable indi-
vidual IP anomaly filters, on a system-wide basis.
Using the GUI to Configure IP Anomaly Filtering 23
Using the CLI to Configure IP Anomaly Filtering 23
Using the GUI to Configure IP Anomaly Filtering
To use the GUI, navigate to Security >> DDoS Protection and select the anomaly for which you want
to enable protection.
Using the CLI to Configure IP Anomaly Filtering
To enable IP anomaly filters from the CLI, use the ip anomaly-drop command.
23
For example, the following command enables DDoS protection against ping-of-death attacks:
ACOS(config)# ip anomaly-drop ping-of-death
Refer to the “ip anomaly-drop” command in the Network Configuration Guide for more information
about this command.
Displaying IP Anomaly Statistics

This section describes how to view IP anomaly statistics.
Using the GUI to Display IP Anomaly Statistics 24
Using the CLI to Display IP Anomaly Statistics 24
Using the GUI to Display IP Anomaly Statistics
Navigate to ADC >> Statistics >> Switch.
NOTE: For more information, see the online Help.
Using the CLI to Display IP Anomaly Statistics
To display IP anomaly statistics, enter the show slb l4 command:
For system-wide PBSLB statistics, you use the show pbslb client command. In the output of
this command, the counters for a dynamic client are reset to 0 when a client’s dynamic entry ages
out.
To clear all Layer 4 SLB statistics, including the IP anomaly counters, enter the clear slb l4 com-
mand:
NOTE: For more information about these commands, see Command Line
Interface Reference Guide.
24
Chapter 3: Policy-based SLB
These topics helps you understand and configure policy-based SLB (PBSLB).
Overview 26
Configuring a Black/White List 26
Configuring System-wide PBSLB 31
Configuring PBSLB for Individual Virtual Ports 33
Configuration Example for Sockstress Attack Protection 36
PBSLB Statistics Display 37
25
Overview
ACOS allows you to “black list” or “white list” individual clients or client subnets. White list traffic is
allowed, and black list traffic is dropped from specific client hosts or subnets in the list.
For white list traffic, you can specify the service group to use. You also can specify the action that
will be taken (drop or reset) on new connections that exceed the configured connection threshold
for the client address.
Example
The user can configure ACOS to respond to DDoS attacks from a client by dropping excessive con-
nection attempts from the client.
You can apply PBSLB on a system-wide basis. If Server Load Balancing (SLB) is supported, you
also can apply PBSLB on individual virtual ports.
NOTE:
ACOS also allows policy templates to be applied at the vir-
tual-server level. However, PBSLB does not take effect if you
apply the policy template at the virtual- server level. Only
class lists are supported at the virtual-server level. To use
PBSLB, you must apply the policy template globally or on
individual virtual ports.
If a connection limit is specified in a black/white list, the
ACOS device does not support using the list for system-
wide PBSLB and for PBSLB on an individual virtual port. In
this case, the ACOS device may increase the current con-
nection counter more than once, which results in a much
lower connection limit than the configured value. To resolve
this issue, you should use separate black/white lists.
Configuring a Black/White List

The following sections are described in this topic:
26
Configuration Details and Examples 27
Example Black/White List 29
Dynamic Black/White-list Client Entries 29
Connection Limit for Dynamic Entries 30
Aging of Dynamic Entries 30
Wildcard Address Support in PBSLB Policies Bound to Virtual Ports 30
Configuration Details and Examples
Client IP lists, such as black/white lists, can be configured on an external device and imported to
the ACOS device or can be entered in the GUI. The actions to take on the addresses in the list are
specified on the ACOS device. A black/white list can contain up to 8 million individual host
addresses and up to 64,000 subnet addresses.
For each IP address (host or subnet) in a black/white list, you can add a row by using the following
syntax:

ipaddr [/network-mask] [group-id] [#conn-limit] [;comment-string]
The syntax is defined in the following way:
TABLE 3-1 Black/White List
Parameter Description
ipaddr Host or subnet address of the client.
network-mask Optional network mask length. The default is 32, which means that the
address is a host address.
27
group-id Number between 1 and 31 in a Black/White list that identifies a group of IP

host or subnet addresses in the list. In a PBSLB policy template on the
ACOS device, you can map the group to one of the following actions:
Drop the traffic
Send the traffic to a specific service group
The default group ID is 0, which means that no group is assigned.
#conn-limit Maximum number of concurrent connections that are allowed from the cli-
ent. By default, there is no connection limit. If you decide to set a limit, the
valid range is between 1 and 32767. On the ACOS device, you can specify
whether to reset or drop new connections that exceed this limit.
The # is required only if you do not specify a group-id.
comment-string Comment; everything to the right of the semi-colon (;) is ignored by the
ACOS device when it parses the file.
NOTE: The conn-limit is a coarse limit. The larger the number you specify,
the more coarse the limit.
Example
If you specify 100, the ACOS device limits the total connections to 100.
As another example, if you specify 1000, the device limits the connections to a maximum of
992 connections.
If the number in the file is larger than the supported maximum limit value, the parser uses the
longest set of digits in the number that you enter that makes a valid value.
Example
If the file contains 32768, the parser uses 3276 as the value.
As another example, if the file contains 111111, the parser will use 11111 as the value.
28
Example Black/White List
The following text is a sample black/white list:

10.10.1.3 4; blocking a single host. 4 is the drop group
10.10.2.0/24 4; blocking the entire 10.10.2.x subnet
192.168.1.1/32 #20 ; 20 concurrent connections max, any group ok
192.168.4.69 2 #20 ; assign to group 2, and allow 20 max
The first row assigns a specific host to group 4. On the ACOS device, the drop action is assigned to
this group, which black lists the client.
The second row black lists an entire subnet by assigning it to the same group (4).
The third row sets the maximum number of concurrent connections for a specific host to 20.
The fourth row assigns a specific host to group 2 and specifies a maximum of 20 concurrent con-
nections.
NOTE: The ACOS device allows up to three parser errors when reading the
file but stops reading after the third parser error.
Dynamic Black/White-list Client Entries
The ACOS device supports dynamic client entries. You can configure this feature by adding the cli-
ent address 0.0.0.0/0 (wildcard address) to the black/white list that is used by the system-wide
PBSLB policy.
When a client sends an HTTP or HTTPS connection request, the ACOS device checks the system-
wide PBSLB policy’s black/white list for the client’s IP address, with one of the following results:
If there is no entry for the client, he ACOS device creates a dynamic entry for the client’s host
address.
If there is a dynamic entry for the client, the ACOS device resets the timeout value for the
entry. (Dynamic entry aging is described below.)
NOTE: If there is a static entry for the client’s host or subnet address, the
static entry is used instead.
The following is an example of a wildcard address in a black/white list:

0.0.0.0/0 1 #20
29
In this example, the clients who do not match a static entry in the list are assigned to group 1 and
are limited to 20 concurrent connections.
The ACOS device supports up to 8 million dynamic client entries for system-wide PBSLB. Once this
limit is reached, the ACOS device no longer track connections or anomaly counters for additional cli-
ents.
Connection Limit for Dynamic Entries
For dynamic entries in a system-wide PBSLB policy’s black/white list, the connection limit in the list
applies to each client.
In the example above, each client that has a dynamic entry in the black/white list will be allowed to
have a maximum of 20 concurrent connections.
Aging of Dynamic Entries
When the ACOS device creates a dynamic black/white list entry for a client, the device also sets the
timeout for the entry. The timeout value for the dynamic entry decreases until the timeout reaches
0 or the client sends a new HTTP or HTTPS connection request.
If the client sends a new HTTP or HTTPS connection request, the timeout is reset to its full value. If
the timeout reaches 0 and the client does not have active connections, the dynamic entry is
removed. However, if the client has an active connection, the dynamic entry is not removed until
the client’s connection ends. You can set the timeout to 1-127 minutes, and the default is 5 minutes.
If client-lockup is enabled, the timeout for a locked up client does not begin decreasing until the
lockup expires.
Wildcard Address Support in PBSLB Policies Bound to Virtual Ports
Dynamic client entries are supported only for system-wide PBSLB policies.
You can add a wildcard address (0.0.0.0/0) to a black/white list that is used by a virtual port’s
PBSLB policy. The group ID and connection limit that are specified for the wildcard address are
applied to clients that do not match a static entry in the list.
Consider the following limitations:
30
The ACOS device does not create dynamic entries in the list.
The connection limit applies collectively to all clients that do not have a static entry in the list.
Configuring System-wide PBSLB

Options for System-wide PBSLB Policies 31
Using the GUI to Configure System-wide PBSLB 31
Using the CLI to Configure System-wide PBSLB 32
Displaying and Clearing System-wide PBSLB Information 32
Options for System-wide PBSLB Policies
System-wide PBSLB policies provide the following options:
Dynamic black/white-list client entries

Client lockup
IP anomaly checking and tracking, using IP anomaly filters
These options are not available in policies that are applied to individual ports.
Using the GUI to Configure System-wide PBSLB
To configure a system-wide PBSLB policy using the GUI, do the following:
1. Configure the PBSLB settings in an SLB policy template.

a. Navigate to ADC >> Template >> L7.
b. Click Create and select Policy from the drop-down list.
c. Specify a policy name; for example, pol1.
d. Expand the BW List section, and configure the Black/White list settings as desired.
e. Click OK.
31
2. Apply the policy template at the system level.

a. Navigate to ADC >> SLB >> Global.
b. In the System template policy field, select pol1 from the drop-down list.
c. Click Update.
Using the CLI to Configure System-wide PBSLB
To configure a system-wide PBSLB policy using the CLI, do the following:
The following example drops any connections from clients exceeding one of the following
limits:
The connection limit that is configured in the specified in the Black/White list.
The threshold of any of the new IP anomaly filters.
Logging is enabled and messages are generated two minutes.

ACOS(config)# slb template policy pol1
ACOS(config-policy)# bw-list id 1 drop logging 2
ACOS(config-policy)# bw-list over-limit lockup 5 logging 2
ACOS(config-policy)# exit
ACOS(config)#
2. Apply the policy template at the system level:
ACOS(config)# system template policy pol1
Displaying and Clearing System-wide PBSLB Information
To display information for system-wide PBSLB, enter the show pbslb system or show pbslb cli-
ent commands.
To clear PBSLB information, use the clear pbslb system or clear pbslb client commands.
Use the entry option with the clear pbslb client command to clear both statistical counters
and client entries; without this option, only the statistical counters are cleared.
32
Configuring PBSLB for Individual Virtual Ports

Configuration Details 33
Using the GUI to Configure PBSLB for Individual Virtual Ports 34
Using the CLI to Configure PBSLB for Individual Virtual Ports 35
Configuration Details
You can configure PBSLB parameters for virtual ports by configuring the settings on individual
ports or by configuring a PBSLB policy template and binding the template to individual virtual
ports.
NOTE: This feature is supported only in software releases that support

Server Load Balancing (SLB).
These steps assume that the real servers, service groups, and virtual servers have already been
configured.
To configure PBSLB:
1. Configure a black/white list remotely or on the ACOS device.

2. If you configure the list remotely, import the list to the ACOS device.
3. Optionally, modify the sync interval for the list.
4. ACOS regularly synchronizes with the list to ensure that the ACOS version is current.
5. Configure PBSLB settings.
You can configure a policy template and bind the template to virtual ports or configure the fol-
lowing settings on individual virtual ports:
Specify the black/white list.

Optionally, map each group ID that used in the list to one of the following actions:
Send the traffic to a specific service group.
Reset the traffic.
33
Drop the traffic.
Optionally, change the action (drop or reset) that ACOS will take on connections that exceed
the specified limit.
Optionally, if necessary, change the client address matching from source IP matching to des-
tination IP matching.
Using the GUI to Configure PBSLB for Individual Virtual Ports
To configure a PBSLB policy for individual virtual ports using the GUI, do the following:

a. Navigate to ADC >> Template >> L7.
b. Click Create and select Policy from the drop-down list.
c. Specify a policy name; for example, pol1.
d. Expand the BW List section, and configure the Black/White list settings as desired.
e. Click OK.
34
FIGURE 3-2 Create Policy Template
2. Apply the policy template at the virtual port level.

a. Navigate to ADC >> SLB >> Virtual Servers.
b. Click Edit in the Actions column for an existing virtual server.
c. On the Update Virtual Server page, click Edit in the Actions column for an existing virtual
port.
d. On the Update Virtual Port page, expand the Templates section.
e. Select the desired policy template from the drop-down list in the Template Policy field.
f. Click Update.
Using the CLI to Configure PBSLB for Individual Virtual Ports
The following commands import black/white list “sample-bwlist.txt” to the ACOS device:
35
ACOS(config)# import bw-list sample-bwlist tftp://myhost/TFTP-Root/ACOS_bwl-

ists/sample-bwlist.txt
ACOS(config)# show bw-list
Name Url Size(Byte) Date
------------------------------------------------------------------------------
sample-bwlist tftp://myhost/TFTP-Root/ACOS_ N/A N/A
bwlists/sample-bwlist.txt
Total: 1
The following commands configure a PBSLB template and bind it to a virtual port:
ACOS(config)# slb template policy bw1
ACOS(config-policy)# bw-list name bw1
ACOS(config-policy)# bw-list id 2 service-group srvcgroup2
ACOS(config-policy)# bw-list id 4 drop
ACOS(config)# slb virtual-server PBSLB_VS1 10.10.10.69
ACOS(config-slb vserver)# port 80 http
ACOS(config-slb vserver-vport)# template policy bw1
ACOS(config-slb vserver-vport)# exit
ACOS(config-slb vserver)# exit
The following commands displays PBSLB information:

ACOS(config-slb vserver-vport)# show pbslb
Total number of PBSLB configured: 1
Virtual Server Port Blacklist/whitelist GID Connection # (Establish Reset Drop)
------------------------------------------------------------------------------
PBSLB_VS1 80 sample-bwlist 2 0 0 0
4 0 0 0
PBSLB_VS2 80 sample-bwlist 2 0 0 0
4 0 0 0
Configuration Example for Sockstress Attack Protection

You can use system-wide PBSLB with IP anomaly filters to protect against Sockstress attacks,
which is a type of DDoS attack.
In this example, the ACOS device drops all new connection attempts from a client if one of the fol-
lowing conditions occur:
The client already has 20 active connections and attempts to open a new HTTP or HTTPS con-
nection.
36
The client exceeds any of the IP anomaly thresholds.
The lockup period is set to 5 minutes, to continue enforcing the over-limit action for 5 minutes after
the over-limit action is triggered. The timeout for dynamic black/white list entries is set to 2
minutes.
This example uses the following black/white list:

0.0.0.0/0 1 #20
PBSLB Statistics Display

The following command displays system-wide statistics for the new IP anomaly filters:
ACOS(config)# show slb l4
Total
------------------------------------------------------------------
IP out noroute 20061
TCP out RST 0
TCP out RST no SYN 0
...
Anomaly out of sequence 225408
Anomaly zero window 225361
Anomaly bad content 224639
The following command displays statistics for the system-wide PBSLB policy:
ACOS(config)# show pbslb system
System B/W list: bwlist-wc
Virtual Server Port Blacklist/whitelist GID Connection # (Establish Reset Drop)
-------------------------------------------------------------------------------
-
System bwlist-wc 1 12 0 0
2 0 0 0
The following command displays summary statistics for individual black/white-list clients:
ACOS# show pbslb client
GID = Group ID, S/D = Static or dynamic entry
Out-s = Out of sequence, Zero-w = Zero window, Bad-c = Bad content
IP S/D GID Conn-limit Curr-conn Age Lockup Out-s Zero-w Bad-c
------------------+---+---+----------+---------+-----+------+-----+------+----
40.40.40.168 /32 D 1 20 5 120 0 0 5 5
40.40.40.169 /32 D 1 20 6 0 5 0 6 6
40.40.40.170 /32 D 1 20 6 0 5 0 6 6
40.40.40.171 /32 D 1 20 6 0 5 0 6 6
37
40.40.40.172 /32 D 1 20 6 0 5 0 6 6
40.40.40.173 /32 D 1 20 2 120 0 0 2 2
40.40.40.174 /32 D 1 20 5 120 0 0 5 5
40.40.40.175 /32 D 1 20 5 120 0 0 5 5
40.40.40.160 /32 D 1 20 5 120 0 0 5 5
40.40.40.161 /32 D 1 20 6 120 0 0 6 6
40.40.40.162 /32 D 1 20 6 0 5 0 6 6
40.40.40.163 /32 D 1 20 6 0 5 0 6 6
40.40.40.164 /32 D 1 20 6 0 5 0 6 6
40.40.40.165 /32 D 1 20 5 120 0 0 5 5
The Age column indicates how many seconds are left before a dynamic entry ages out. For clients
who are currently locked out of the system, the value in the Lockup column indicates how many
minutes the lockup will continue. For locked up clients, the age value is 0 until the lockup expires.
After the lockup expires, the age is set to its full value. In this example, the lockup value is 120
seconds.
The following command displays detailed statistics for a specific black/white-list client:
ACOS# show pbslb client 40.40.40.168
IP address: 40.40.40.168
Netmask length: 32
Type: Dynamic
Group ID: 1
Connection limit (0 = no limit): 1984
Current connection: 6
Age: 0 second
Lockup time: 5 minute
Out of sequence: 0
Zero window: 6
Bad content: 6
38
Chapter 4: SYN Cookies
These topics describes the SYN-cookie feature and how it helps protect ACOS devices against dis-
ruptive SYN-based flood attacks.
Overview of SYN Cookies 40
Configuring SYN Cookies 44
Viewing SYN-cookie Statistics 49
39
Overview of SYN Cookies

SYN cookies protect against TCP SYN flood attacks. When SYN cookies are enabled, the ACOS
device can continue to serve legitimate clients during these attacks, while preventing illegitimate
traffic from consuming system resources.
SYN Flood Attacks 40
Identifying SYN Flood Attacks 40
ACOS SYN-cookie Protection 41
Dynamic SYN Cookies 42
SYN Cookie Buffering 43
SACK and MSS with Software-based SYN-cookies 43
SYN Flood Attacks
During a TCP SYN flood attack, an attacker sends many TCP SYN Requests to a network device,
such as a server. The server replies with a standard SYN-ACK message. However, rather than reply
to this attempt at establishing a 3-way handshake with the standard ACK, an attacker ignores the
reply and creates a “half-open” TCP connection. System resources are consumed because the
device waits for a response from the client that never arrives.
Under large-scale attacks, excessive half-open connections cause a network device’s TCP con-
nection queue to become full. This over-subscription prevents the device from establishing new
connections with legitimate clients.
Identifying SYN Flood Attacks
The graphics in this section illustrate how the ACOS device determines whether a particular TCP
connection is from a legitimate request or if it is part of a SYN flood attack.
The FIGURE 4-1 depicts a typical 3-way TCP handshake, which includes a SYN request from the
client, the SYN-ACK reply from the ACOS device, and finally, an ACK from the client to the ACOS
device.
40
FIGURE 4-1 SYN_ACK Handshake (Legitimate Client)
However, SYN flood attacks (FIGURE 4-2 ) can cripple a network by sending multiple SYN requests
to a network device. The device responds to these SYN requests with SYN-ACKs and waits for
responses from the client that never arrive. These bogus requests create many “half-open” ses-
sions, which wastes system memory and other system resources. The state of being over-
subscribed reduces the device’s free resources, which prevents it from accepting requests from
legitimate clients.
FIGURE 4-2 SYN-ACK Handshake (Hacker)
Enabling SYN cookies mitigates the damage caused by such DoS attacks by preventing the
attacks from consuming system resources.
TCP connections for which the ACOS device did not receive an ACK from the client is identified as
belonging to a SYN flood attack, and this information is displayed with the counter in the output of
the show command.
ACOS SYN-cookie Protection
By enabling SYN cookies, the ACOS device’s TCP connection queue is prevented from filling up dur-
ing TCP SYN flood attacks. When a client sends an SYN request, the ACOS device responds with a
41
SYN cookie. This response is a special type of SYN ACK message.
SYN cookies prevent hackers from consuming excessive system resources by encoding the neces-
sary state information for the client connection in a TCP sequence number. Rather than storing
state information for each TCP session, the sequence number in the SYN cookie acts as a short-
hand, which allows the ACOS device to compress much of the session information into a smaller
amount of data.
This sequence number is sent to the client as a SYN-ACK packet. When a legitimate client receives
this information, it replies with an ACK that contains the sequence number plus 1.
When the SYN ACK that contains the sequence number from the client is received, the ACOS
device reconstructs the connection information and establishes a connection with that client.
If the SYN Request is part of an attack, the attacker does not send an ACK to the ACOS device. The
ACOS device sends a SYN cookie, but the attacker does not receive it (or may choose to ignore it),
and the ACOS device does not establish a connection.
Dynamic SYN Cookies
You can configure on and off thresholds for SYN cookies. When there are no TCP SYN attacks, the
TCP options are preserved.
You can configure the following dynamic SYN cookie options:
On-threshold – specifies the maximum number of concurrent half-open TCP connections

that are allowed on the ACOS device, before SYN cookies are enabled. If the number of half-
open TCP connections exceeds the on-threshold value, the ACOS device enables SYN cook-
ies. You can specify 0-2147483647 half-open connections.
Off-threshold – specifies the minimum number of concurrent half-open TCP connections for
which to keep SYN cookies enabled. If the number of half-open TCP connections falls below
this level, SYN cookies are disabled. You can specify 0-2147483647 half-open connections.
By default, hardware-based SYN cookies are disabled. When the feature is enabled, there are no
default settings for the on- and off-threshold. If you omit the on-threshold and off-threshold
options, SYN cookies are enabled and are always on, regardless of the number of half-open TCP
connections on the ACOS device.
42
NOTE: It may take up to 10 milliseconds for the ACOS device to detect and
respond to crossover of either threshold.
SYN Cookie Buffering
SYN Cookie Buffering optimizes performance by increasing the amount of buffers that are alloc-
ated to TCP connections when system memory usage is low and reducing the number of buffers
when system memory usage is high.
When SYN cookies are enabled, the ACOS device allocates 10 buffers to each TCP connection, and
by default, offers a TCP window size of 8000.
When memory usage increases and system resources are scarce, the number of buffers that are
reserved for each TCP connection gradually reduces from 10 buffers to 1 buffer per TCP con-
nection. The window size also reduces during this process.
SYN Cookie Buffering is automatically enabled when SYN cookies are enabled. By default, 10 buf-
fers are allocated to each TCP connection. Instead being dropped and requiring later re-trans-
mission, the packets are stored in the ACOS device’s memory and forwarded to the real server
when the back-end connection is available.
NOTE: This feature is not supported with SLB fast-path processing.
SACK and MSS with Software-based SYN-cookies
Software-based SYN cookies is an optional feature that is available on certain AX models at the con-
figuration level for virtual ports. The ACOS device bases Selective Acknowledgment (SACK) sup-
port, and the maximum segment size (MSS) setting, in software-based SYN cookies on server
replies to TCP health checks that are sent to the servers.
SACK 43
MSS 44
SACK
The ACOS device includes the Sack-Permitted option in TCP SYN health check packets sent to serv-
ers.
43
If all of the up servers in the service group reply with a TCP SYN-ACK that contains a SACK
option, the ACOS device uses SACK with the software-based SYN-cookie feature for all serv-
ers in the service group.
If any of the up servers in the service group do not send a SACK option, the ACOS device
does not use SACK with the software-based SYN-cookie feature for any servers in the ser-
vice group.
MSS
The lowest MSS value that is supported by a server in the service group is the MSS value that is
used by the ACOS device for software-based SYN-cookies.
Configuring SYN Cookies

The following sections describe how to enable SYN-cookie support and configure advanced fea-
tures.
Enabling SYN-cookie Support 44
Configuration with Target VIP and Client-side Router in Different Subnets 46
Modifying the Threshold for TCP Handshake Completion 47
Configuring SYN-cookie Buffering 47
Enabling SYN-cookie Support
Details 44
FTA Models 45
Non-FTA Models 46
Details
Depending on the Thunder or AX model, you can use hardware-based SYN cookies or software-
based SYN cookies:
44
Hardware-based SYN cookies can be globally enabled and applied to all virtual server ports
that are configured on the device.
Hardware-based SYN cookies are available on FTA devices. See the FTA Devices section on
the A10 Hardware Install Guides website for a list of FTA Thunder and AX devices.
Software-based SYN cookies can be enabled on individual virtual ports. This version of the
feature is available on all AX models.
Consider the following information:
Hardware-based SYN cookies are a faster, easier-to-configure alternative to the software-

based SYN cookie feature available on all AX platforms.
If your AX model supports hardware-based SYN cookies, A10 Networks recommends that you use
the hardware-based version of the feature instead of the software-based version.
If both hardware-based and software-based SYN cookies are enabled, only hardware-based SYN
cookies are used. Although software-based SYN cookies can be enabled, they are not used.
If Application Delivery Partitioning (ADP) is configured, hardware-based SYN cookies apply to all
partitions. The feature is not partition-aware.
If the target VIP is in a different subnet from the client-side router, use of hardware-based
SYN cookies requires some additional configuration.
NOTE: For more information, see Configuration with Target VIP and
Client-side Router in Different Subnets.
Software-based SYN cookies are supported only in software releases that support SLB.
FTA Models
To enable hardware-based SYN cookies on ACOS models that feature FTAs, use the syn-cookie
enable command at the global configuration level:.
The command in the following example enables dynamic-based SYN cookies when the number of
concurrent half-open TCP connections exceeds 50000 and disables SYN cookies when the num-
ber falls below 30000:
ACOS(config)# syn-cookie enable on-threshold 50000 off-threshold 30000
45
Non-FTA Models
To enable software-based SYN cookies, use the syn-cookie command at the virtual-port level. For
example:
ACOS(config)# slb virtual-server vip1
ACOS(config-slb vserver)# port 80 tcp
ACOS(config-slb vserver-vport)# syn-cookie
Configuration with Target VIP and Client-side Router in Different Sub-

nets
Usually, the target VIP in an SLB configuration is in the same subnet as the client-side router.
However, if the target VIP is in a different subnet, to use hardware-based SYN cookies, configure
the following items:
On the ACOS device, configure a “dummy” VIP that is in the same subnet as the client-side
router.
On the client-side router, configure a static route to the VIP by using the dummy VIP as the
next hop.
FIGURE 4-3 is an example of this deployment.
FIGURE 4-3 Hardware-based SYN Cookies – Target VIP and Client-Side Router in Different Subnets

46
The following commands configure hardware-based SYN cookies on the ACOS device:
ACOS(config)# slb virtual-server dummyvip 10.10.10.154
ACOS(config)# syn-cookie
NOTE: If VRRP-A is configured, add both the target VIP and the dummy VIP
to the same VRID so these VIPs will fail over as a unit.
Modifying the Threshold for TCP Handshake Completion
To modify the threshold for TCP handshake completion, use the ip tcp syn-cookie threshold
global configuration command.
For example, to set the threshold to 3 seconds:

ACOS(config)# ip tcp syn-cookie threshold 3
Configuring SYN-cookie Buffering
47
Details 48
Using the GUI to Configure SYN-cookie Buffering 48
Using the CLI to Configure SYN-cookie Buffering 49
Details
When SYN cookies are enabled, 10 buffers are available to hold overflow packets from each client
session. When the system memory is occupied, the number of buffers dedicated to each TCP con-
nection is reduced. The reduction process occurs gradually and is tied to system memory usage.
There are three different thresholds that can be configured on the ACOS device. When these free
system memory thresholds are breached, the number of buffers that are allocated to each session
(and the TCP window size) are reduced. This reduction in the TCP window sized is an attempt to
prevent the client from sending data faster than the ACOS device can receive it.
The graduated buffers and window sizes appear below. By default, each TCP session is allocated
10 buffers, and the TCP window size is set to 8K.
If the first threshold is breached, the buffer is reduced to 4 buffers, and the TCP window size
is reduced to 4K.
If the next memory threshold is breached, the buffer is reduced to 2 buffers, and the TCP win-
dow size is reduced to 2K.
If the final threshold is breached, the buffer is reduced to 1 buffer, and the TCP window size is
reduced to 1K.
These thresholds are based on system memory usage, and the values are configurable.
Consider the following information:
Each buffer size is approximately 1500 bytes.
The total number of buffers varies from one model to the next and is based on the total memory per
connection.
If hardware-based SYN cookies are enabled, ACOS does not modify the TCP window size.
It remains hard-coded at 65K.
Using the GUI to Configure SYN-cookie Buffering

To configure SYN-cookie buffering using the GUI:
48
1. Navigate to the ADC >> SLB >> Global page.

2. Click the Buffer Threshold checkbox.
This reveals additional fields that can be configured.
NOTE: For more information, see the latest version of the Online Help for addi-
tional information about the fields.
Using the CLI to Configure SYN-cookie Buffering

You can enter the buff-thresh CLI command to configure the thresholds for system memory
usage. These threshold configurations apply to both software- and hardware-based models.
You do not have to change the system memory usage thresholds from the default settings.
However, you can modify these thresholds by entering the following CLI commands:
!
slb common
buff-thresh hw-buff num relieve-thresh num sys-buff-low num sys-buf-high num
For additional information about changing the system memory thresholds, see the buff-thresh
command in the Command Line Interface Reference.
Viewing SYN-cookie Statistics

This section describes how to view SYN-cookie statistics by using the GUI or CLI.
Using the GUI to View SYN-cookie Statistics 49
Using the CLI to View SYN-cookie Statistics 50
Using the GUI to View SYN-cookie Statistics
To display SYN-cookie statistics, navigate to the ADC >> Statistics >> L4 page in the GUI.
NOTE: For more information, see the latest version of the Online Help for addi-
tional information about the fields.
49
Using the CLI to View SYN-cookie Statistics
This section summarizes some of the CLI commands that can be used to view SYN-cookie stat-
istics.
L4 SYN attack 50
CLI Example 1: View Attack Prevention Statistics 50
CLI Example 2: View SYN Attack Counter 52
CLI Example 3: View Legitimate Session Counter 52
CLI Example 4: View SYN-cookie Buffering Statistics 52
SYN Attack Counter Support for L3V 52
The following fields in the output of the show slb l4 command allow you to view TCP traffic in
terms of legitimate traffic and attacks.
L4 SYN attack
Displays a running counter of the number of packets that the ACOS device considers to be from a
SYN flood attack. This assumption is based on the fact that the device did not receive an ACK from
the client.
L4 TCP Established
Displays a running counter of TCP packets that the ACOS device considers to be from legitimate cli-
ents. When SYN cookies are enabled, and a legitimate client sends a SYN request, the ACOS device
responds with a SYN ACK. If the ACOS device receives an ACK, the packet is considered safe.
CLI Example 1: View Attack Prevention Statistics

You can view SYN-cookies statistics for one sampling interval or across the following time intervals:
Current
1 second
5 seconds
30 seconds
50
1 minute
5 minutes
The following command displays SYN-cookie statistics across multiple time intervals:
ACOS# show slb attack-prevention
Current 1 sec 5 sec 30 sec 1 min 5 min
-----------------------------------------------------------------------------
SYN cookie snt 0 0 0 0 0 0
SYN cookie snt ts 0 0 0 0 0 0
SYN cookie snt fail 0 0 0 0 0 0
SYN cookie chk fail 0 0 0 0 0 0
SYN attack 0 0 0 0 0 0
The TABLE 4-4 displays the fields that appear in the CLI output of the show slb attack-pre-
vention command.
TABLE 4-4 show slb attack-prevention fields
Field Description
SYN cookie snt Number of TCP SYN cookies sent.
SYN cookie snt ts Number of expanded TCP SYN cookies sent.
SYN cookie snt Number of TCP SYN cookie send attempts that failed.
fail
SYN cookie chk Number of TCP SYN cookies for which the responding ACK failed the SYN
fail cookie check.
SYN attack Total number of SYN connections that did not receive an ACK from the client
and assumed to be SYN attack.
Limitations
When running the show slb attack-prevention command on an FTA model, the SYN
attack field does not display output for the historical counters (1s/5s/30s/1min/5min). Out-
put is only provided for the Current column.
This feature is supported for L3V private partitions in non-FTA models. If the show slb
attack-prevention command is run from an L3V network partitions on an FTA model, the
SYN attack counter displays zero for all columns.
51
NOTE: To clear these statistics, enter the clear slb attack-prevention

command.
CLI Example 2: View SYN Attack Counter

The following example displays output from the show slb l4 command. The L4 SYN attack field
indicates that 30 packets appear to have been part of a SYN flood attack.
ACOS# show slb l4
Total
------------------------------------------------------------------
IP out noroute 0
TCP out RST 0
...
L4 SYN attack 30
...
CLI Example 3: View Legitimate Session Counter

The following example displays output from the show slb l4 command. The L4 TCP Established
field indicates that 1,766 packets appear to have been from a legitimate source, not from an
attacker.
ACOS# show slb l4
Total
------------------------------------------------------------------
IP out noroute 0
TCP out RST 0
...
CLI Example 4: View SYN-cookie Buffering Statistics

The following example displays output for SYN cookie buffer statistics:
ACOS# show slb syn-cookie-buffer
Maximum SYN cookie buffer size : 10
Total SYN cookie buffer queued : 0
Total SYN cookie buffer drop : 0
SYN Attack Counter Support for L3V

The SYN flood attack counter in the output for the show slb l4 command may not work correctly
in every situation. For example, while counters that are associated with software-based SYN cook-
52
ies work correctly in L3V and non-L3V deployments, counters that are associated with hardware-
based SYN cookies do not work with private partitions.
The TABLE 4-5 shows the limitations that are associated with using SYN flood attack counters
under a variety of conditions.
TABLE 4-5 SYN flood attack counter matrix
Hardware-based Software-based L3V SYN cookie counter

SYN cookie SYN cookie Private Partitions incremented?
Enabled Disabled Disabled Yes
Disabled Enabled Disabled Yes
Disabled Enabled Enabled Yes
Enabled Enabled (irrelevant)1 Enabled No2
The SYN cookie counter incremented? column indicates whether the SYN cookie counter display
will function correctly, based on the status of the other conditions that are associated with this
deployment.
1If hardware-based and software-based SYN cookies are enabled, only hardware-based SYN cook-
ies are used. “Irrelevant” means that hardware-based SYN cookies are also enabled.
2“No” means that the SYN flood attack counters fail when hardware- and software-based SYN
cookies are enabled at the same time as L3V (private partitions). This is a known limitation with this
feature.
53
54
Chapter 5: IP Limiting
IP limiting provides a an enhanced implementation of the source IP connection limiting and con-
nection-rate limiting feature. These topics describe the IP limiting options and how to configure
and apply these options.
Overview of IP Limiting 56
Understanding Class Lists 56
Understanding IP Limiting Rules 61
CLI Examples - Configuration 66
CLI Examples - Display 70
55
Overview of IP Limiting
IP limiting provides the following benefits:
Configuration flexibility:
You can apply source IP limiting on a system-wide basis, on individual virtual servers, or on indi-
vidual virtual ports.
Class lists:
You can configure different classes of clients, and apply a separate set of IP limits to each class.
You also can exempt specific clients from being limited.
NOTE: For more information, see Understanding Class Lists.
Separate limits can be configured for each of the following items:
Concurrent connections
Connection rate
Concurrent Layer 7 requests
Layer 7 request rate
NOTE: Layer 7 request limiting applies only to the HTTP, HTTPS, and fast-
HTTP virtual port types.
Understanding Class Lists

A class list is a set of IP host or subnet addresses that are mapped to IP limiting rules. The ACOS
device can support up to 255 class lists, and each class list can contain up to 8 million host IP
addresses and 64,000 subnets.
NOTE: Class lists can be configured only in the shared partition. A policy tem-
plate that is configured in a shared partition or in a private partition
can use a class list that is configured in the shared partition.
56
Class List Syntax 57
IP Address Matching 58
Example Class Lists 59
Configuring Class Lists 59
Class List Syntax
Each row in the class list defines a client class and has the following format:

ipaddr /network-mask [glid num | lid num] [age minutes] [; comment-string]
TABLE 5-1 provides a description of each portion of the format.
TABLE 5-1 Class List Syntax Parameters
ipaddr Specifies the host or subnet address of the client. Both IPv4 and IPv6
addresses are supported.
network-mask Subnet mask for the client address.
To configure a wildcard IP address, specify 0.0.0.0 /0 (for IPv4) or ::/0 (for

IPv6). The wildcard address matches on all addresses that do not match any
entry in the class list.
glid num Specifies the ID of the IP limiting rule that will be used to match clients. A glid
configures an IP limiting rule that is configured at the global configuration
level.
lid num Specifies the ID of the IP limiting rule that will be used to match clients. A lid
configures an IP limiting rule that is configured at the same level as the class
list (in the same policy template).
57
age minutes Removes a host entry from the class list after the specified number of
minutes. You can specify 1-2000 minutes.
When you assign an age value, the host entry remains in the class list only for
the specified number of minutes. After the age reaches 0, the host entry is
removed from the class list in the next minute.
You can use the age option with IP limiting options in the LID or GLID to tem-
porarily control client access. Traffic limiting settings in the LID or GLID that
are assigned to the host entry are in effect only until the age expires.
The age option applies only to host entries (IPv4 /32 or IPv6 /128). The age
option is not supported for subnet entries.
NOTE: If you use a class-list file that is periodically re-

imported, the age for class-list entries that are
added to the system from the file do not reset
when the class-list file is re-imported. Instead,
the entries are allowed to continue aging nor-
mally.
;comment- Custom comment. Use a semi-colon (;) in front of the comment string.
string
NOTE: The ACOS device discards the comment string
when you save the class list.
IP Address Matching
By default, the ACOS device matches the class-list entries based on the source IP address of client
traffic. Optionally, you can also match based on one of the following items:
Destination IP address:
Matches based on the destination IP address instead of the source IP address.
IP address in HTTP request:
58
Matches based on the IP address in a header in the HTTP request. You can specify the header
when you enable this option.
Example Class Lists
Here is an example of a simple class list. This list matches on all clients and uses an IP limiting rule
that is configured at the global configuration level:
0.0.0.0/0 glid 1
The following is an example with more options:

1.1.1.1 /32 lid 1
2.2.2.0 /24 lid 2 ; LID 2 applies to every single IP of this subnet
0.0.0.0 /0 lid 10 ; LID 10 applied to every undefined single IP
3.3.3.3 /32 glid 3 ; Use global LID 3
4.4.4.4 /32 ; No LID is applied (exception list)
The rows in the list specify the following:
For individual host 1.1.1.1, use IP limiting rule 1, which is configured in a policy template.
A policy template can be applied globally for system-wide IP limiting or to an individual vir-
tual server or virtual port. This is described in more detail in a later section.
For all hosts in subnet 2.2.2.0/24, use IP limiting rule 2, which is configured in a policy tem-
plate.
For all hosts that do not match another entry in the class list, use IP limiting rule 10, which is
configured in a policy template.
For individual host 3.3.3.3, use IP limiting rule 3, which is configured at the global con-
figuration level.
For individual host 4.4.4.4, do not use an IP limiting rule.
Configuring Class Lists
Using the GUI to Import a Class List 60
Using the GUI to Configure a Class List 60
Using the CLI to Import a Class List 60
59
Using the CLI to Configure a Class List 61
Using the GUI to Import a Class List

To import a class list using the GUI:
1. Hover over ADC and select SLB from the menu bar.
2. Click the Class Lists tab, then select Import from the drop-down list.
3. Click Import.
4. Specify the name and location of the file you want to import. Refer to the GUI online help for
this page for more information about each field.
5. Click Import.
Using the GUI to Configure a Class List

To configure a class list using the GUI:
1. Hover over ADC and select SLB from the menu bar.
2. Click the Class Lists tab, then select Configuration from the drop-down list.
3. Click Create.
4. In the Name field, specify a class list name.
5. Complete the fields on this page as desired. Refer to the GUI online help for this page for more
information about each field.
NOTE: If the class list contains at least 100 entries, you should use the
Store as a file option. A class list can be exported only if you use
this option.
6. Click Create.
Using the CLI to Import a Class List

To import a class list using the CLI, use the import command. For example:
ACOS(config)# import class-list vs_list ftp:
Address or name of remote host []? 1.1.1.2
User name []? ACOSadmin
Password []? *********
File name [/]? vs_list
60
Using the CLI to Configure a Class List

To configure a class list in the CLI, use the class-list command. For example:
ACOS(config)# class-list examplelist
ACOS(config-class list)# 1.1.1.1 /32 glid 1
ACOS(config-class list)# 2.2.2.2 /32 glid 2
ACOS(config-class list)# 10.1.2.1 /32 lid 1
ACOS(config-class list)# 10.1.2.2 /32 lid 2
NOTE: See Class List Syntax for more information about the syntax.
Understanding IP Limiting Rules

Parameters 61
Match IP Address 63
Request Limiting and Request-Rate Limiting in Class Lists 63
CLI Examples: Request Limiting and Request-rate Limiting Settings Are Used 64
CLI Examples: Request Limiting and Request-rate Limiting Settings Are Not Used65
Configuring Source IP Limiting 66
Parameters
IP limiting rules specify connection and request limits for clients.
Each IP limiting rule has the following parameters:
61
Limit ID – Number from 1-31 that identifies the rule.

Connection limit – Maximum number of concurrent connections that are allowed for a client.
You can specify 0-1048575. Connection limit 0 immediately locks down matching clients,
and there is no default value.
Connection-rate limit – Maximum number of new connections that are allowed for a client in
the limit period. You can specify 1-2147483647 connections. The limit period can be 100-
6553500 milliseconds (ms), specified in increments of 100 ms. There is no default.
Request limit – Maximum number of concurrent Layer 7 requests that are allowed for a client.
You can specify 1-1048575, and there is no default.
Request-rate limit – Maximum number of Layer 7 requests that are allowed for a client in the
limit period. You can specify 1-4294967295 connections. The limit period can be 100-
6553500 milliseconds (ms), specified in increments of 100 ms. There is no default.
Over-limit action – Action to take when a client exceeds at least one limit.
The action can be one of the following:
Drop – The ACOS device drops that traffic. If logging is enabled, the ACOS device also gen-
erates a log message. This is the default action.
Forward – The ACOS device forwards the traffic. If logging is enabled, the ACOS device also
generates a log message.
Reset – For TCP, the ACOS device sends a TCP RST to the client. If logging is enabled, the
ACOS device also generates a log message.
Lockout period – Number of minutes during which to apply the over-limit action after the cli-
ent exceeds a limit. The lockout period is activated when a client exceeds a limit. The lockout
period can be 1-1023 minutes, and there is no default.
Logging – Generates log messages when clients exceed a limit. Logging is disabled by
default.
When you enable logging, by default, a separate message is generated for each over-limit occur-
rence. If you specify a logging period, the ACOS device keeps the repeated messages for the spe-
cified period and sends a message at the end of the period for all instances that occurred during
this period.
The logging period can be 0-255 minutes. The default is 0, which means that there is no wait
period.
62
NOTE: When configured in a policy template, the class-list options request

limit and request-rate limit are applicable only in policy templates that
are bound to virtual ports. These options are not applicable in policy
templates that are bound to virtual servers or in policy templates that
are used for system-wide PBSLB.
NOTE: For more information, see Request Limiting and Request-Rate Lim-
iting in Class Lists. The request limit and request-rate limit options
apply only to HTTP, fast-HTTP, and HTTPS virtual ports. The over-limit
logging, when used with the request- limit or request- rate- limit
option, always lists Ethernet port 1 as the interface.
Match IP Address
By default, the ACOS device matches class-list entries based on the source IP address of client
traffic. Optionally, you can also match based on one of the following options:
Destination IP address – Matches based on the destination IP address in packets from clients.
IP address in client packet header – Matches based on the IP address in the specified header
in packets from clients. If you do not specify a header name, this option uses the IP address
in the X-Forwarded-For header.
Request Limiting and Request-Rate Limiting in Class Lists
If a LID or GLID in a class list contains settings for request limiting or request-rate limiting, the set-
tings apply only if the following conditions are true:
The LID or GLID is used in a policy template.

The policy template is bound to a virtual port.
The settings apply only to the virtual port but do not apply in the following cases:
The policy template is applied to the virtual server, instead of the virtual port.
The settings are in a system-wide GLID.
The settings are in a system-wide policy template.
63
NOTE: This limitation does not apply to connection limiting or con-

nection-rate limiting. Those settings are valid in the cases listed
above.
CLI Examples: Request Limiting and Request-rate Limiting Settings

Are Used
Example 1: GLID Used in Policy Template and Bound to Virtual Port

The following configuration is valid for request limiting and request-rate limiting. These settings are
in a GLID that is used by a policy template that is bound to a virtual port.
ACOS(config)# class-list 2
ACOS(config-class list)# 5.1.1.100/32 glid 1023
ACOS(config-class list)# 55.1.1.0/24 lid 31
ACOS(config-class list)# exit
ACOS(config)# glid 1023
ACOS(config-glid:1023)# request-limit 10
ACOS(config-glid:1023)# request-rate-limit 2 per 100
ACOS(config-glid:1023)# over-limit-action reset log
ACOS(config-glid:1023)# exit
ACOS(config)# slb template policy global_policy
ACOS(config-policy)# class-list 2
ACOS(config-policy-class-list:2)# exit
ACOS(config)# slb virtual-server vs-55 55.1.1.55
ACOS(config-slb vserver)# vrid 1
ACOS(config-slb vserver-vport)# service-group vlan-80-grp
ACOS(config-slb vserver-vport)# template policy global_policy
Example 2: LID Used in Policy Template and Bound to Virtual Port

The following configuration also is valid for request limiting and request-rate limiting. These set-
tings are in a LID that is configured in a policy template that is bound to a virtual port.
ACOS(config)# class-list l2
ACOS(config-class list)# 55.1.1.100/32 lid 31
64

ACOS(config)# slb template policy poltemplate1
ACOS(config-policy)# class-list l2
ACOS(config-policy-class-list:l2)# exit
ACOS(config-policy)# class-list l3
ACOS(config-policy-class-list:l3)# lid 30
ACOS(config-policy-class-list:l3-lid:30)# request-limit 10
ACOS(config-policy-class-list:l3-lid:30)# request-rate-limit 2 per 100
ACOS(config-policy-class-list:l3-lid:30)# exit
ACOS(config-policy-class-list:l3)# exit
ACOS(config-slb vserver-vport)# template policy poltemplate1
CLI Examples: Request Limiting and Request-rate Limiting Settings

Are Not Used
Example 1: Policy Template Bound to Virtual Server Instead of Virtual Port

The following configuration is not valid for request limiting and request-rate limiting. The policy tem-
plate is bound to the virtual server instead of the virtual port.
ACOS(config-slb vserver)# template policy gg
Example 2: System GLID

The following configuration is not valid for request limiting and request-rate limiting, because the
settings are in a system GLID.
ACOS(config)# system glid 1023
65
Example 3: System-wide Policy Template

The following configuration is not valid for request limiting and request-rate limiting, because the
settings are in a policy template used for system-wide PBSLB.
ACOS(config)# system template policy pol1
Configuring Source IP Limiting
To configure source IP limiting:
1. Configure a class list on the ACOS device or another device.

2. If you configure the class list on another device, import it to the ACOS device.
a. Configure the following IP limiting rules:
b. For system-wide IP limiting, configure the rules in a policy template or in standalone IP
limiting rules.
3. For IP limiting on an individual virtual server or virtual port, configure the rules in a policy tem-
plate.
4. Apply the IP limiting rules.
You can configure multiple policy templates with different IP limiting rules. You can use a given
class list in one or more policy templates.
For system-wide source IP limiting, apply the policy template globally.

For source IP limiting on an individual virtual server or virtual port, apply the policy template
to the virtual server or virtual port.
Clients must comply with all IP limiting rules that are applicable to the client. For example, if you con-
figure system-wide IP limiting and also configure IP limiting on a virtual server, clients must comply
with the system-wide IP limits and with the IP limits that are applied to the individual virtual server
accessed by the client.
CLI Examples - Configuration

The examples in this section show how to configure IP limiting.
66
Configuring System-wide IP Limiting With a Single Class 67
Configuring System-wide IP Limiting With Multiple Classes 67
Configuring IP Limiting on a Virtual Server 68
Configuring IP Limiting on a Virtual Port 68
Configuring Class List Entries That Age Out 69
Configuring System-wide IP Limiting With a Single Class
The following commands configure a standalone IP limiting rule to be applied globally to all IP cli-
ents, which match class list “global”:
ACOS(config)# glid 1
ACOS(config-glid:1)# conn-rate-limit 10000 per 1
ACOS(config-glid:1)# conn-limit 1000000
ACOS(config-glid:1)# over-limit-action forward log
ACOS(config-glid:1)# exit
ACOS(config)# system glid 1
The following commands configure class list “global”, which matches on all clients and uses IP lim-
iting rule 1:
ACOS(config)# class-list global
ACOS(config-class list)# 0.0.0.0/0 glid 1
Configuring System-wide IP Limiting With Multiple Classes
The commands in this example configure system-wide IP limiting by using a policy template.
ACOS(config)# slb template policy global_policy
ACOS(config-policy)# class-list global
ACOS(config-policy-class-list:global)# lid 1
ACOS(config-policy-class-list:global-lid...)# conn-rate-limit 20000 per 1
ACOS(config-policy-class-list:global-lid...)# conn-limit 5000000
ACOS(config-policy-class-list:global-lid...)# over-limit reset logging
ACOS(config-policy-class-list:global-lid...)# exit
ACOS(config-policy-class-list:global)# exit
The following command imports the class list that are used by the policy:
ACOS(config)# import class-list global_list ftp:
67

Password []? *********
File name [/]? global_list
The following command applies the policy to the system:

ACOS(config)# system template policy global_policy
Configuring IP Limiting on a Virtual Server
The commands in this example configure IP limiting for a virtual server.
The following commands configure a policy template:

ACOS(config)# slb template policy vs_policy
ACOS(config-policy)# class-list vs_list
ACOS(config-policy-class-list:vs_list)# lid 1
ACOS(config-policy-class-list:vs_list-lid...)# conn-rate-limit 200 per 1
ACOS(config-policy-class-list:vs_list-lid...)# conn-limit 50000
ACOS(config-policy-class-list:vs_list-lid...)# over-limit lockout 10 logging
ACOS(config-policy-class-list:vs_list-lid...)# exit
ACOS(config-policy-class-list:vs_list)# exit
The following command imports the class list that is used by the policy:
ACOS(config)# import class-list vs_list ftp:
Password []? *********
File name [/]? vs_list
The following commands apply the policy to a virtual server:

ACOS(config)# slb virtual server vs1
ACOS(config-slb vserver)# template policy vs_policy
Configuring IP Limiting on a Virtual Port
The commands in this example configure IP limiting for a virtual port.
NOTE: In this example, IP limiting is applied to a virtual port on a virtual server

that also has IP limiting. Clients must conform to both sets of limits.
The following commands configure a policy template:
68
ACOS(config)# slb template policy vp_policy

ACOS(config-policy)# class-list vp_list
ACOS(config-policy-class-list:vp_list)# lid 1
ACOS(config-policy-class-list:vp_list-lid...)# request-rate-limit 50 per 1
ACOS(config-policy-class-list:vp_list-lid...)# request-limit 60000
ACOS(config-policy-class-list:vp_list-lid...)# over-limit reset logging
ACOS(config-policy-class-list:vp_list-lid...)# exit
ACOS(config-policy-class-list:vp_list)# exit
The following command imports the class list that is used by the policy:
ACOS(config)# import class-list vp_list ftp:
Address or name of remote host []?1.1.1.2
Password []? *********
File name [/]? vp_list
The following commands apply the policy to a virtual port:

ACOS(config)# slb virtual server vs1
ACOS(config-slb vserver-vport)# template policy vp_policy
Configuring Class List Entries That Age Out
The following commands configure a class list with 2 host entries, and assign an age value to each
entry.
ACOS(config)# class-list local
ACOS(config-class list)# 192.168.1.100 /32 lid 30 age 1
ACOS(config-class list)# 192.168.1.101 /32 lid 30 age 10
The following commands configure a policy template.
The template includes an LID that sets the connection limit to 0. The LID also resets and logs con-
nection attempts.
ACOS(config)# slb template policy 1
ACOS(config-policy)# class-list local
ACOS(config-policy-class-list:local)# lid 30
ACOS(config-policy-class-list:local-lid...)# conn-limit 0
ACOS(config-policy-class-list:local-lid...)# over-limit-action reset log
ACOS(config-policy-class-list:local-lid...)# exit
ACOS(config-policy-class-list:local)# exit
69
The following commands apply the policy template to a virtual port.

ACOS(config)# slb virtual-server vs1 192.168.1.33
ACOS(config-slb vserver-vport)# template policy 1
In the configuration above, host 192.168.1.100 is not allowed to establish a connection during the
first minute after the host entry is created. After the age expires, the host entry is removed form the
class list, and the connection limit no longer applies to the client.
Host 192.168.1.101 is not allowed to establish a connection during the first 10 minutes after that host
entry is created. Once the age expires, the client is no longer locked down.
CLI Examples - Display

Viewing Class-Lists 70
Viewing IP Limiting Rules 70
Viewing IP Limiting Statistics 71
Viewing Class-Lists
Use the show class-list command to view information about your class list configuration.
NOTE: For information, see “show class-list” in the Command Line Inter-
face Reference.
Viewing IP Limiting Rules
Use the show glid command to view the configuration of each standalone IP limiting rule.
NOTE: For information, see “ show glid ” in the Command Line Interface
Reference.
70
Viewing IP Limiting Statistics
Use the show pbslb command to view IP limiting statistics.
NOTE: For information, see “ show pbslb ” in the Command Line Interface
Reference.
71
72
Chapter 6: ICMP Rate Limiting
ICMP Rate Limiting Overview 74
Configuring ICMP Rate Limiting 74
73
ICMP Rate Limiting Overview

ICMP/ICMPv6 1 rate limiting protects against denial-of-service (DoS) attacks such as Smurf attacks,
which consist of floods of spoofed broadcast ping messages.
ICMP rate limiting monitors the rate of ICMP traffic and drops ICMP packets when the configured
thresholds are exceeded.
Configuring ICMP Rate Limiting

You can configure ICMP rate limiting filters globally, on individual Ethernet interfaces, and in virtual
server templates. If you configure ICMP rate limiting filters at more than one of these levels, all filters
are applicable.
ICMP Rate Limiting Parameters 74
Using the GUI to Configure ICMP Rate Limiting 75
Using the CLI to Configure ICMP Rate Limiting 76
ICMP Rate Limiting Parameters
ICMP rate limiting filters consist of the following parameters:
Normal rate – The ICMP normal rate is the maximum number of ICMP packets that are
allowed per second.
If the ACOS device receives more than the normal rate of ICMP packets, the excess packets
are dropped until the next one-second interval begins. The normal rate can be 1-65535 pack-
ets per second.
Maximum rate – The ICMP maximum rate is the maximum number of ICMP packets allowed
per second before the ACOS device locks up ICMP traffic.
1Subsequent references use the term “ICMP rate limiting”. Unless otherwise specified, this term also
applies to ICMPv6 rate limiting.
74
When ICMP traffic is locked up, all ICMP packets are dropped until the lockup expires. The
maximum rate can be 1-65535 packets per second.
Lockup time – The lockup time is the number of seconds for which the ACOS device drops all
ICMP traffic, after the maximum rate is exceeded.
The lockup time can be 1-16383 seconds.
NOTE: Specifying a maximum rate (lockup rate) and lockup time is optional.
If you do not specify them, lockup does not occur. Log messages are
generated only if the lockup option is used and lockup occurs. Other-
wise, the ICMP rate-limiting counters are still incremented but log
messages are not generated. The maximum rate must be larger than
the normal rate.
Using the GUI to Configure ICMP Rate Limiting
Configuring ICMP Rate Limiting on an Ethernet Interface 75
Configuring ICMP Rate Limiting in a Virtual Server Template 75
Configuring ICMP Rate Limiting on an Ethernet Interface

To configure ICMP rate limiting on an Ethernet interface:
1. Navigate to the Network >> Interfaces >> LAN page.

2. Click the Edit link in the Actions column for the Ethernet interface for which you want to con-
figure ICMP rate limiting.
3. In the Update Ethernet page, select the checkbox in the ICMP Rate Limit field, then specify
the desired ICMP rate limiting parameters.
NOTE: For descriptions of the parameters, see ICMP Rate Limiting Para-
meters.
Configuring ICMP Rate Limiting in a Virtual Server Template

To configure ICMP rate limiting in a virtual server template:
75
NOTE: This option applies only to software releases that support SLB.
1. Navigate to the ADC >> Templates >> SLB page.

2. Click Create, then select Virtual Server from the drop-down list.
3. In the Create Virtual Server Template page, specify the desired values in the fields beginning
with “ICMP” or “ICMPv6” as desired.
meters.
Using the CLI to Configure ICMP Rate Limiting
The following example configures a virtual server template that sets ICMP rate limiting:
ACOS(config)# slb template virtual-server vip-tmplt
ACOS(config-vserver)# icmp-rate-limit 25000 lockup 30000 60
You can enter the icmp-rate-limit command at any of the following configuration levels:
Global configuration level

Configuration level for a physical or virtual Ethernet interface
Configuration level for a virtual server template
meters.
To view ICMP rate limiting information, enter the following commands:

show icmp
show icmpv6
show interfaces
show slb virtual-server server-name detail
76
Chapter 7: HTTP Slowloris Prevention
Details 78
Using the GUI to Configure Request Header Timeout 78
Using the CLI to Configure Request Header Timeout 78
77
Chapter 7: HTTP Slowloris Prevention
Details
The ACOS includes an HTTP template option that specifies the maximum number of seconds
allowed for all parts of a request header to be received. If the entire request header is not received
within the specified amount of time, ACOS terminates the connection.
This option provides security against attacks such as Slowloris attacks, which attempt to consume
resources on the target system by sending HTTP requests in multiple increments, and at a slow
rate. The intent of this type of attack is to cause the target system to consume its buffer resources
with the partially completed requests.
NOTE: The request- header wait time can bet set to 1- 31 seconds. The
default is 7 seconds.
Using the GUI to Configure Request Header Timeout

To configure the request header timeout using the GUI:
1. Navigate to the ADC >> Templates >> L7 page.

2. Click Create and select HTTP from the drop-down list to create a new HTTP template.
3. On the Create HTTP Template page, select the checkbox in the Request Header Wait Time
Before Abort Connection field, then specify a timeout value in seconds (1-31, default is 7).
Using the CLI to Configure Request Header Timeout

To change the request-header wait time in an HTTP template, use the req-hdr-wait-time com-
mand at the configuration level for the template:
ACOS(config)# slb template http exampletemplate
ACOS(config-http)# req-hdr-wait-time 10
NOTE: For more HTTP security options, see the W eb Application Firewall
Guide.
78
Chapter 8: DNS Application Firewall
Overview of the DNS Application Firewall 80
DNS Sanity Check 80
Configuring DNSSEC 81
79
Overview of the DNS Application Firewall

The DNS Application Firewall (DAF) provides security for DNS VIPs.
The DAF examines DNS queries that are addressed to a VIP to ensure that the queries are not mal-
formed. If a malformed DNS query is detected, the ACOS device takes one of the following actions:
NOTE: These actions are specified in the DNS security policy.
Drops the query.

Forwards the query to another service group – This option is useful if you want to quarantine
and examine the malformed queries, while keeping the queries away from the DNS server.
This feature parses DNS queries based on the following RFCs:
RFC 1034: Domain Names – Concepts and Facilities

RFC 1035: Domain Names – Implementation and Specification
RFC 2671 – Extension Mechanisms for DNS (EDNS0)
DNS Sanity Check

The DNS security performs a sanity check on DNS client requests and, if applicable, the DNS server
replies.
Sanity Checking for Virtual-Port Type UDP 80
Sanity Checking for Virtual-Port Type DNS-UDP 81
Sanity Checking for Virtual-Port Type UDP
The DNS sanity checking on virtual-port type UDP is performed only for client requests.
For a DNS client request to pass the sanity check, all of the following conditions must be met:
80
Flags.qr == 0 (first bit in flags)

Flags.opcode <=5 (bits 2 to 5 in flags)
Flags.rcode == 0 (last 4 bits in flags)
qdcount > 0 (questions in DNS header)
Sanity Checking for Virtual-Port Type DNS-UDP
DNS sanity checking on virtual-port type DNS-UDP is performed for client requests and server
responses.
For a client request to pass the sanity check, all of the following conditions must be met:

Flags.opcode == 0 (bits 2 to 5 in flags)
Flags.rcode == 0 (last 4 bits in flags)
qdcount == 1 (questions in DNS header)
For a server response to pass the sanity check, all of the following conditions must be met:

Flags.opcode <=5
Flags.rcode == 0
qdcount > 0
ancount > 0 (Answer count)
Configuring DNSSEC
This topic contains the following section:
Details 82
Using the CLI to Configure DNSSEC 82
81
Details
To configure DNS security for a DNS virtual port:
1. Create a DNS template and specify the DNS security action in the template.
2. Bind the DNS template to the DNS virtual port.
Using the CLI to Configure DNSSEC
DNS Application Firewall Setup 82
Service-Group Redirection for DNS “Any” Requests (using aFleX) 83
DNS Application Firewall Setup

The following commands configure a DNS template for DNS security and bind the template to the
DNS virtual port on a virtual server. The drop option drops malformed queries so that they are not
processed by the DNS virtual port to which the template has been applied.
ACOS(config)# slb template dns dns-sec
ACOS(config-dns)# malformed-query drop
ACOS(config-dns)# exit
The following commands configure the real server and service group:
ACOS(config)# slb server dns-sec1 10.10.10.88
ACOS(config-real server)# port 53 udp
ACOS(config-real server-node port)# exit
ACOS(config-real server)# exit
ACOS(config)# slb service-group dns-sec-grp udp
ACOS(config-slb svc group)# member dns-sec1 53
ACOS(config-slb svc group-member:53)# exit
ACOS(config-slb svc group)# exit
The following commands bind the service group and DNS template to the DNS virtual port on a vir-
tual server:
ACOS(config)# slb virtual-server dnsvip1 192.168.1.53
ACOS(config-slb vserver)# port 53 udp
ACOS(config-slb vserver-vport)# service-group dns-sec-grp
ACOS(config-slb vserver-vport)# template dns dns-sec
82
Since the drop action is specified, malformed DNS queries sent to the virtual DNS server are
dropped by the ACOS device.
Service-Group Redirection for DNS “Any” Requests (using aFleX)

The following aFleX script can be applied to a DNS virtual port to detect DNS “any” requests and
redirect them to an alternate service group. In this example, DNS requests of type “ANY” are sent to
service group rate_limited_service_group. DNS requests of other types are sent to service
group no_rate_limit_service_group.
when DNS_REQUEST {
set record ANY
if {[DNS::question type] equals $record} {
pool rate_limited_service_group
} else {
pool no_rate_limit_service_group
}
}
83
84
Chapter 9: DNS Response Rate Limiting
Overview of DNS Response Rate Limiting (RRL) 86
Configuration Example 91
85
Overview of DNS Response Rate Limiting (RRL)

Details 86
DNS Reflection Attacks 86
Challenges of Stopping DNS Reflection Attacks 87
ACOS Mitigation of DNS Reflection Attacks 87
Two-tiered Rate-limiting System for DNS Queries 87
Configuration Parameters for DNS RRL 88
Limitations 89
Details
For some ADC deployments, it may be difficult to control the rate of DNS responses from the DNS
servers to external hosts. This vulnerability could cause your network resources to be used in DNS
reflection attacks or DNS amplification attacks.
To prevent your network equipment from becoming an unwanted participant in a DNS reflection or
amplification attack, this release introduces support for DNS Response Rate Limiting (RRL).
The DNS Response Rate Limiting is a BIND feature which applies a rate-limit to the DNS server
responses, with the goal of decreasing unnecessary load on the authoritative DNS servers.
NOTE: DNS RRL is implemented based on ISC-TN-2012-1-Draft1, which is

used by both BIND9 and NSD.
DNS Reflection Attacks
A DNS reflection attack is when a hacker hijacks multiple computers using botnets and then sends
a large number of queries to one or more DNS servers. The hacker’s DNS requests include a
spoofed source IP address, so it appears as though the DNS queries are originating from what is
essentially a fake address (that is, the address of the intended victim). The unwitting DNS server
replies to the spoofed address of the victim instead of replying to the real source of the threat.
When the hacker scales-up the attack by employing botnets, the replies from the DNS servers can
86
use up all the resources on the target’s network, preventing legitimate traffic from getting
through.1
Challenges of Stopping DNS Reflection Attacks
DNS runs on the connectionless UDP protocol, so it is difficult to check the validity of each DNS
query and drop malicious traffic in a targeted manner. However, the ACOS can employ a blunt
approach to mitigate this type of threat by applying rate limits to the traffic.
The ACOS identifies potentially malicious queries if the following are true of the DNS requests:
1. There are an excessive number of queries,

2. They are originating from the same domain,
3. They are requesting the same FQDN-to-IP mapping from the DNS server.
Once the source is flagged as potentially malicious, then ACOS can take protective action.
ACOS Mitigation of DNS Reflection Attacks
To respond to this threat, ACOS applies rate-limits to the DNS server responses associated with
those DNS requests that have been flagged as potentially malicious.
NOTE: Note that ACOS does not apply rate limits to the malicious queries
themselves, but only to the responses from the DNS server to the vic-
tim.
When this feature is enabled, ACOS monitors the DNS response rate and request rate, and it
detects any abnormal increase in the rate or frequency, which is based on the IPv4/IPv6 source
address (source IP of the request).
Two-tiered Rate-limiting System for DNS Queries
In its implementation of DNS RRL, BIND software tracks all DNS queries by placing them into one
large table. However, in order to allocate system resources in a more efficient manner, the ACOS
1For more information about DNS Reflection attacks, see https://en.wikipedia.org/wiki/Reflection_

attack.
87
implementation of DNS RRL uses a two-tiered system with two tables.
The first of the two tables is called the “filter table”, and the second of the two tables is called the
“rate-limiting entry table”. Both tables apply rate limits to DNS queries, but the “filter table” uses
only two bytes for each DNS query in its table, while the “rate-limiting entry table” uses approx-
imately 100 bytes for each DNS query.
All DNS queries first go to the “filter table”, and if the query is flagged as potentially malicious, sub-
sequent requests from that source IP + FQDN combination are stored in the second table (the rate-
limiting entry table).
Configuration Parameters for DNS RRL
Setting the Rate Limits 88
Protecting System Resources 89
Allowing Valid DNS Queries to Pass 89
More Information 89
Setting the Rate Limits

DNS RRL can be configured using the following CLI parameters:
“filter table” – This table is for the non-offenders making normal DNS requests. This is where
all normal DNS queries are processed. Rate limits can be set for this table using the filter-
response-rate command under response-rate-limiting.
“rate-limiting entry table” – This table is for the offenders making abnormal DNS requests,
who need to be monitored more closely. Only a small subset of DNS queries are placed into
this table of potential abusers. Rate limits can be set for this table using the response-rate
command under response-rate-limiting.
“window” – This option configures the rate-limiting-window, which is the time interval over
which rates are measured for response-rate and slip-rate. If the same DNS mapping is
requested too many times, similar queries from that client are dropped for the rest of the win-
dow’s interval.
88
The “rate-limit entry table” is for the offenders who have exceeded the rate limits configured
in the filter table. The sources address (and hash of the FQDN) for these requests are tracked
based on the combination of information (source IP + requested FQDN). These queries are
monitored more closely than regular DNS queries and the rate-limiting table allocates a credit
rate to each entry (for example, a credit of up to 10 requests per second), which can be used
up. Any DNS queries exceeding their credit rate are then rate-limited, meaning ACOS will
drop the traffic.
Protecting System Resources

The DNS Response Rate Limiting feature also includes configuration options to help prevent DNS
attacks from consuming too much system memory in the “rate-limiting entry table”. The command
that is used to configure this resource protective behavior is dns-response-rate-limiting max-
table-entries.
After 1000 entries in the table are used up, all other traffic is placed into an overflow bucket where
the source IP + FQDN is no longer tracked.
Allowing Valid DNS Queries to Pass

The DNR RRL feature allows a “slip rate”, so that a certain percentage of valid DNS queries are
allowed to pass through, even during an attack. The command that is used to configure this
resource protection behavior is the slip-rate option, under response-rate-limiting.
More Information
NOTE: For more information about any of these CLI commands, see the fol-
lowing commands in the CLI Reference for ADC.
“slb template dns” command updated with new “response-rate-limiting” option.

“slb common” command updated with “dns-response-rate-limiting max-table-
entries” option.
“show” command updated with new “response-rate-limiting entries” option.
Limitations
This release contains the following limitations for the DNS RRL feature:
89
Any changes to the SLB maximum table entries (CLI command: dns-response-rate-lim-
iting max-table-entries under slb common) requires disabling and then re-enabling the
template on the virtual port to which it is bound.
Use the show command to verify that all rate-limiting entries have been aged out before re-
enabling the template.
(Tracking ID: 473179)

When configuring the log-only option, if the Action is set to log-only, the counters for
Dropped, Allowed, and Slipped are incremented, even though these packets were actually
Permitted to pass.
Log-only mode offers a simulation of how many packets would be getting Dropped/Al-
lowed/Slipped if the device were not in observation mode, but while in observation mode,
none of the packets are actually getting dropped.

For the rate-limiting tables discussed here, Two-tiered Rate-limiting System for DNS Quer-
ies, users cannot see the entries in the table.
The entries in the rate-limiting tables are not yet visible via the GUI or CLI.

Due to CM limitation, if you configure slb template <name> response-rate-limiting
without configuring anything underneath, the line “response-rate-limiting” will not appear in
the output of the show running-config command.
Dynamic changes to age setting are in effect only after the existing filter table entry ages out.
DNS RRL is not supported on service-partitions.
NOTE: The following limitations that existed in the previous releases

are now removed:
DNS RRL was not supported on L3V partitions. DNS RRL is now supported on L3V partitions.
90
If you configured slb template <name> response-rate-limiting without configuring

anything underneath it, then response-rate-limiting line was not appearing in the out-
put of the show running-config command.
The updated show command now displays the entry in the rate-limiting tables.
Configuration Example
Using the GUI to Configure DNS RRL 91
Using the CLI to Configure and Monitor DNS RRL 92
Using the GUI to Configure DNS RRL
The DNS Response Rate Limiting (RRL) feature helps prevent network equipment (DNS author-
itative servers) from becoming unwanted participants in a DNS reflection or DNS amplification
attack.
To configure DNS Response Rate Limiting:
1. Navigate to the ADC > Templates > L7 Protocols menu.

2. Click Create, and select DNS from the drop-down menu.
3. From the page that appears, select the DNS Response Rate Limiting checkbox.
From this page, you can configure the options needed to enable DNS Response Rate Limiting
(RRL).
4. Click OK to save your changes.
To set limits around the amount of memory consumed during a DNS reflection attack:
1. Navigate to ADC > SLB > Global.

2. Select the DNS Response Rate Limiting checkbox.
3. From the Max Table Entries field that appears, specify the desired value.
4. Click Update to save your changes.
91
NOTE: For descriptions about these parameters, see Configuration Para-

meters for DNS RRL.
Using the CLI to Configure and Monitor DNS RRL
The following example configures DNS RRL:

ACOS(config)# slb common
ACOS(config-common)# dns-response-rate-limiting
ACOS(config-common-dns-response-rate-limi...)# max-table-entries 20000
ACOS(config-common-dns-response-rate-limi...)# exit
ACOS(config)# slb template dns DNSRRL
ACOS(config-dns)# response-rate-limiting
ACOS(config-dns-response-rate-limiting)# response-rate 5
ACOS(config-dns-response-rate-limiting)# filter-response-rate 5
ACOS(config-dns-response-rate-limiting)# slip-rate 5
ACOS(config-dns-response-rate-limiting)# enable-log
ACOS(config-dns-response-rate-limiting)# exit
ACOS(config)# slb server RS 1.1.1.1
ACOS(config-real server)# port 53 udp
ACOS(config-real server-node port)# exit
ACOS(config)# slb service-group SG udp
ACOS(config-slb svc group)# member RS 53
ACOS(config-slb svc group-member:53)# exit
ACOS(config)# slb virtual-server VS 1.1.1.2
ACOS(config-slb vserver)# port 53 dns-udp
ACOS(config-slb vserver-vport)# template dns DNSRRL
ACOS(config-slb vserver-vport)# service-group SG
The following example shows the DNS response rate limiting entries returned by the show com-
mand:
ACOS#show dns response-rate-limiting entries
Source Address FQDN Hit Count
-----------------------+-------------------------+----------
10.211.3.101 test4.example.com 4
92
Total Entries: 15
NOTE: For more information about these configuration and how to monitor
these commands, see the CLI Reference for ADC Guide.
93
94
Chapter 10: DNSSEC Support
These topics describe the ACOS device’s DNSSEC support.
Overview of DNSSEC Support 96
Building the Chain of Trust 103
Dynamic Key Generation and Rollover 105
Hardware Security Module Support 109
DNSSEC Configuration 109
95
Overview of DNSSEC Support

Details 96
DNS without Security 97
DNSSEC (DNS with Security) 100
Details
An ACOS device that is configured as a Global Server Load Balancing (GSLB) controller can act as
an authoritative DNS server for a domain zone. As the authoritative DNS server for the zone, the
ACOS device sends records in response to requests from DNS clients. The ACOS device supports
the ability to respond to client requests for the following types of records:
A
AAAA
CNAME
NS
MX
PTR
SRV
TXT
If you place the ACOS device in the DNS infrastructure, the device is exposed to potential online
attacks. When DNS was originally designed, there were no mechanisms to ensure the DNS infra-
structure would remain secure.
In an unsecured DNS environment, the client’s DNS resolver has no way to assess the validity of
the address it receives for a particular domain name, so the client’s DNS resolver cannot tell
whether an address received for a particular domain is from the legitimate owner of that domain.
96
This potential security hole makes DNS vulnerable to “man-in-the-middle” attacks, DNS cache pois-
oning attacks, and other online attacks that could be used to forge DNS data, hijack traffic, and to
potentially steal sensitive information from the user.
To close this security hole, in the 1990s, the Internet Engineering Task Force (IETF) introduced a set
of standards called Domain Name System Security Extensions (DNSSEC). These additional stand-
ards add authentication to DNS and help ensure the integrity of the data that is transferred
between the client resolvers and DNS servers.
DNSSEC offers authentication through the use of cryptographic keys and digital signatures, which
ensure that entries in DNS tables are correct and that connections are made to legitimate servers.
The ACOS device’s implementation of DNSSEC is based on RFCs 4033, 4034, and 4035.
NOTE: DNSSEC for GSLB is not supported in proxy mode.
DNS without Security
The FIGURE 10-1 illustrates basic DNS without DNSSEC. The figure shows the recursive lookup pro-
cess that occurs when a client resolver requests the IP address for a URL. Note that this illustration
shows how a client request works in a simple DNS environment without DNSSEC.
97
FIGURE 10-1 DNS Packet Flow without DNSSEC
A client (shown at upper left) requires access to a server in the domain zone1.example.org (at lower
left). The ACOS device, which is acting as the GSLB controller, is the authoritative DNS server for
the zone. To access this server, the client requires the IP address for this zone or domain.
When the user enters the domain name in the web browser’s URL, the process to obtain the IP
address that is associated with this domain is as follows:
1. The DNS resolver that is embedded in the client’s web browser sends an address request
(“A?”) to the Caching DNS server to see whether the Caching DNS server has the required IP
address cached in its memory for the requested example.org domain.
2. The Caching DNS server has a list of IP address-to-domain mappings, but the list is not com-
prehensive, and unfortunately, the Caching DNS server does not have the required IP
address.
98
It acts as a proxy for the client and makes a recursive query to the Root DNS Server, which is
located at the top of the DNS hierarchy.
3. The Root DNS Server does not have the requested IP address.
4. In an attempt to point the Caching DNS server in the right direction, it responds to the
request with a Name Server (NS) record, which contains the IP of the Top Level Domain (TLD)
server for the “.org” domain.
5. The Caching DNS server now has the IP address for the name server that manages the “.org”
domain, so it sends an address request on behalf of the client to the TLD DNS server for the
“.org” domain.
6. The TLD Server does not have the requested IP address.
7. The TLD server points the Caching DNS server in the right direction by providing an NS
record that contains the IP address for the next name server in the DNS hierarchy, which is
the authoritative DNS server for the example.org subdomain.
8. The Caching DNS server has the IP address that is needed to reach the authoritative DNS
server for the example.org domain, so the server sends a request for zone1.example.org to
this authoritative DNS server.
9. The authoritative DNS server does not have the requested information, but it can get the
Caching DNS server one step closer to its destination by providing the NS record for the
authoritative DNS server for the zone1.example.org domain.
10. The Caching DNS Server sends a request to the authoritative DNS server for the zone1.ex-
ample.org domain.
11. The ACOS device, which is the authoritative DNS server for zone1.example.org, has the IP
address that the client needs.
12. The ACOS device sends the requested IP address to the Caching DNS server.
13. The Caching DNS server sends the IP address that is provided by the ACOS device to the
DNS resolver in the client’s browser.
The client now has the IP address needed to reach the server in the zone1 subdomain.
99
DNSSEC (DNS with Security)
The FIGURE 10-2 illustrates how the DNS query process works when the security extensions are
used with DNS to provide security (DNSSEC). The process is similar to DNS packet flow without
DNSSEC, but with the notable exception that DNSSEC uses the following additional resource
record types to provide security:
DNS Key (DNSKEY) – Public key used by an Authoritative DNS server to sign resource records
for its zone.
Delegation Signer (DS) – Hash (message digest) of a public key. A DNS server uses the DS for
a zone that is directly underneath it in the DNS hierarchy to verify that signed resource
records from the Authoritative DNS server for that zone are legitimate.
Resource Record Signature (RRSIG) – Digitally signs another resource record, such as an A
record.
The digital signature is created by applying a hash function to the DNS record to reduce its file size,
an encryption algorithm is applied to the hash value (using the private key), and this encrypted
hash value appears as the digital signature at the bottom of the resource record. The RRSIG record,
which contains the private key that is used to encrypt the hash value, appears at the bottom of the
record being signed.
While the DNS Packet flow without DNSSEC shows how basic DNS works without DNSSEC, the
FIGURE 10-2 shows how the DNS lookup process works with DNSSEC.
The recursive lookup process remains largely unchanged, with the higher level DNS servers point-
ing to lower level servers in the DNS hierarchy to move the request closer to the authoritative server
for the desired domain.
However, when DNSSEC is added, the additional records such as DS, RRSIG, and DNSKE are used
to sign and authenticate the communications from the DNS servers. This step proves to the client
that each of the name servers in the “chain of trust” are authoritative for their respective domains.
NOTE: For more details, Building the Chain of Trust.
100
FIGURE 10-2 DNS Packet Flow with DNSSEC
The FIGURE 10-2 shows the resolution process for an address query from the DNS resolver on a cli-
ent for the IP address of zone1.example.org.
1. The DNS resolver on the client sends an address query for the IP address of a host under
zone1.example.org.
2. The Caching DNS server, which does not have the address, forwards the request to the root
server.
3. The root server redirects the Caching DNS server to the TLD DNS server for the .org domain.
101
This is accomplished by sending an NS record with the IP address of that TLD server. The
root server uses an RRSIG record, which is used to store the private key, to sign the NS record,
and the root server sends a copy of the DS record to the Caching DNS server, which points to
the TLD server.
4. The Caching DNS server sends the address query to the TLD server for the .org domain.
5. The TLD server does not have the requested address, so it points the Caching DNS server to
the Authoritative DNS server for example.org.
6. The TLD server sends an NS record with the IP address of the authoritative server for
example.org, and the TLD server signs the NS record with the private key in the RRSIG record.
7. The Caching DNS server sends the address query to the Authoritative DNS server for
example.org.
8. The Authoritative DNS server for example.org does not have the requested address, so it
responds to the caching server’s request by sending the NS record (signed with the RRSIG
record).
9. This NS record contains the IP address of the Authoritative DNS server for zone1.example.org.
10. The server sends the DS record for the zone1.example.org server to the Caching DNS server.
11. The Caching DNS server sends the address query to the Authoritative DNS server for
zone1.example.org, which happens to be the ACOS device.
12. The Caching DNS server has reached the Authoritative DNS server for zone1.example.org.
13. The Authoritative DNS server (which is the ACOS device) replies with an SOA record, the
requested A record, and RRSIG records that contains the private key, which is used to sign
the SOA and A records.
14. The Caching DNS server asks the ACOS device for its DNSKEY record, which is where the
public key for the zone is advertised.
15. This public key is needed to unlock the resource records and verify the hash values back up
the chain.
16. The ACOS device sends its DNSKEY record, with an RRSIG record that was used to sign the
DNSKEY record.
17. The RRSIG record contains the private key.
102
18. To continue assembling the chain of trust, the Caching DNS server asks the Authoritative
DNS server for example.org for its DNSKEY record.
19. The Authoritative DNS server for example.org sends its DNSKEY record with an RRSIG record
(with the private key) that was used to sign the DNSKEY record.
20. The Caching DNS server asks the TLD server for .org for its DNSKEY record.
21. The TLD server sends its DNSKEY record with an RRSIG record that was used to sign the
DNSKEY record.
22. The Caching DNS server now has all the private/public key pairs and has validated all of the
links in the chain of trust.
The Caching DNS server can now send the trusted response to the DNS resolver on the client.
Building the Chain of Trust

The FIGURE 10-3 illustrates how the Chain of Trust is built in the DNSSEC infrastructure. A Chain
of Trust is built like a series of links, where each node authenticates the one below it.
The presence of a Chain of Trust allows the client’s DNS resolver to know that all of the DNS servers
in the chain have vouched for one another, starting from the Root DNS Server and continuing
down to the lowest-level DNS server.
103
FIGURE 10-3 DNSSEC Chain of Trust
FIGURE 10-3 shows the Authoritative DNS Server for the zone1.example.org domain at the bottom
left, and the Root DNS Server is located at the upper right.
Starting from the lower left, the Authoritative DNS Server for the zone1.example.org domain, has a
DNS key record (DNSKEY). This DNSKEY record contains the public Zone Signing Key (ZSK) for
zone1. The ZSK is used to sign other record types, such as A records, for the zone. The DNSKEY
record is signed by the Key Signing Key (KSK), which also belongs to this zone.
The Start of Authority (SOA) record indicates that this server is the Authoritative DNS Server for
zone1. The A record provides the IP address for zone1.example.org.
104
The next level up in the DNS hierarchy corresponds to the next “label” in the example.org domain,
and it has a record called the Delegation Signer (DS). The DS record contains a hash, or message
digest, of the public Key Signing Key (KSK), which belongs to the Authoritative DNS Server for the
node below, zone1.example.org.
The DNS resolver (or the Caching DNS Server) can compare the hash value for any of the nodes in
the Chain of Trust, and the values should match. If the hash values in a DS record cannot be recre-
ated from the DNSKEY record, packet that contains the key record may have been tampered with,
cannot be trusted, and should be discarded.
However, if the hash value is correct, this indicates that the Chain of Trust is unbroken and that the
DNSKEY record for the Authoritative DNS Server that is associated with the zone1.example.org
domain is properly linked to the DS record above.
In turn, the DNSKEY record for the Authoritative DNS Server associated with the example.org
domain is properly linked to the DS record above. This process of DNSKEY records being linked with
the DS record of the node above continues all the way to the Root DNS Server.
The client’s DNS resolver knows that the Root DNS Server is legitimate due to the presence of a
“trust anchor”. This trust anchor, which consists of information for the Root DNS Server, is included
in the resolver software that is installed on the client. This minimizes the chance that a client could
access a corrupt root DNS server.
Because of this anchor, the client knows that the Root DNS Server can be trusted, and the client
can infer that the other nodes in the Chain of Trust can also be trusted. The hash values match all
the way down the line, which is an indication that the Chain of Trust is intact, and that the client’s
DNS resolver can trust the Authoritative DNS Server for zone1.example.org. The Server is located at
the bottom of the Chain of Trust in the DNS hierarchy.
Dynamic Key Generation and Rollover

DNSSEC uses dynamic key generation and rollover that are provided by HSM, and HSM con-
figuration is required.
Key Generation and Rollover Parameters 106
Key Rollover and Distribution Process 106
Key Regeneration Log Messages 107
105
Importing/Exporting Key Files 108
Emergency Key Rollover 108
Changing Key Settings 109
Key Generation and Rollover Parameters
When HSM and DNSSEC are enabled, ACOS uses the following key generation and rollover settings
for DNSSEC:
Key size – Length of the keys in bits. You can specify 1024-4096 bits. The default length for
ZSKs and KSKs is 2048 bits.
Lifetime – Maximum amount of time a dynamically generated key remains valid.
Rollover time – Amount of time to wait after a new key becomes active, before generating
that key’s replacement.
The range of values for the lifetime and rollover time is 1 to 2,147,483,647 seconds (about 68 years).
The default lifetime and rollover time differ for ZSKs and KSKs:
ZSKs – The default lifetime is 7,776,000 seconds (90 days), and the default rollover time is
7,171,200 seconds (83 days).
KSKs – The default lifetime is 31,536,000 seconds (365 days), and the rollover time is
30,931,200 seconds (358 days).
Key Rollover and Distribution Process
The features such as dynamic key generation and rollover are enabled by default when a DNSSEC
template becomes active. No additional configuration is required. The FIGURE 10-4 shows the
rekey and rollover schedule if the default rekey and rollover settings for ZSKs and KSKs are used.
FIGURE 10-4 DNSSEC - Default Rekey and Rollover

106
When DNSSEC is enabled, HSM generates a KSK for the GSLB zone, generates a ZSK for the zone,
and signs it with the KSK. The following text is an example of message that appears in the log.
Key Regeneration Log Messages
ACOS generates messages such as the following when key regeneration occurs:
Log Buffer: 30000 Jul 31 2013 06:49:13 Notice [DNS]:succeed to reload the sig-
nature of zone "test.com"
Jul 31 2013 06:48:58 Notice [CLI]: DNSSEC module:succeed to generate ZSK test.-
com_zsk_2013-07-31-06-48-58 for zone test.com
Jul 31 2013 06:48:58 Notice [CLI]: DNSSEC module:please transfer the DS RR of
zone test.com to the parent zone for the initial process.
Jul 31 2013 06:48:58 Notice [CLI]: DNSSEC module:succeed to generate KSK test.-
com_ksk_2013-07-31-06-48-57 for zone test.com
The first message, starting at the bottom, indicates a successful generation of a KSK for child zone
test.com. The next message, which is second from the bottom, is a reminder to copy the DS
resource record for the key to the authoritative DNS server for the parent zone.
107
The third message indicates a successful generation of the ZSK for child zone test.com. The final
message at the top, indicates completion of the rekey process.
CAUTION: Although key generation and rollover are automatic, ACOS does
not automatically send the DS record for the new KSK to the par-
ent zone. This part of the process must be performed manually. If
the default key generation and rollover settings are used, this pro-
cess needs to be performed once a year.
Importing/Exporting Key Files
The import command is used to import and export DNSSEC key files. For example, to import a file:
ACOS# import dnssec-dnskey zone-name scp://exampleuser@examplehost.com/file
To export a file:
ACOS# export dnssec-dnskey zone-name scp://exampleuser@examplehost.com/file
After enabling DNSSEC, wait about a minute for the key to be generated. You can use the export
dnssec-ds command to copy the DS resource record for the zone to the DNS server that is author-
itative for the parent zone.
For syntax information, see the Command Line Interface Reference.
Emergency Key Rollover
The dnssec key-rollover command allows you to force an immediate key rollover, if necessary.
For example, to force an immediate ZSK rollover in emergency mode:
ACOS(config)# dnssec key-rollover zone1 ZSK start
The start option initiates a rollover for the specified key type.
For KSK rollover, the ds-ready-in-parent-zone option indicates that the DS record for the new
KSK has been exported to the parent zone. Use this option only after you have installed the DS
record for the new KSK on the authoritative DNS server for the parent zone. For example:
ACOS(config)# dnssec key-rollover zone2 KSK ds-ready-in-parent-zone
108
Changing Key Settings
Use the zsk lifetime and ksk lifetime commands to change the lifetime and rollover settings
for ZSKs and KSKs, respectively.
Enter the commands at the configuration level for the DNSSEC template.
NOTE: For more information about the supported values, see Key Gen-
eration and Rollover Parameters.
Hardware Security Module Support

Hardware Security Module (HSM) provides additional security, while simplifying key management.
The current release supports a software emulation version of HSM in ACOS. Keys are generated
and stored on the ACOS device. This version can be useful for testing or for environments where
the additional security of a hardware-based HSM is not required.
HSM is required for DNSSEC, and manual key generation of DNSSEC ZSKs or KSKs is not supported.
For information about external HSM support, contact A10 Networks.
DNSSEC Configuration
Modes 109
DNSSEC Configuration Example 110
Modes
To configure DNSSEC, the following modes or options can be considered.
109
DNSSEC Configuration Example
Configuring an HSM Template 110
Configuring a DNSSEC Template 110
Configuring GSLB 110
Configuring a GSLB Policy and Enable Server Mode 114
Binding the DNSSEC Template to the Zone 114
Configuring DNSSEC Standalone 114
Configuring the VIP for DNSSEC Requests 115
The following are the configuration modes from a device that is configured for DNSSEC.
Configuring an HSM Template

The following commands configure an HSM template:
ACOS(config)# hsm template hsm1 softHSM
ACOS(config-template:hsm1)# password encrypted /+m-
boU9rpJM8EIy41dsA5zwQjLjV2wDnPBCMuNXbAOc8EIy41dsA5zwQjLjV2wDn
ACOS(config-template:hsm1)# exit
Configuring a DNSSEC Template

The following commands configure a DNSSEC template:
ACOS(config)# dnssec template dt1
ACOS(config-dnssec)# zsk lifetime 2400 rollover-time 1900
ACOS(config-dnssec)# ksk lifetime 2500 rollover-time 2000
ACOS(config-dnssec)# signature-validity-period 11
ACOS(config-dnssec)# dnskey-ttl 5
ACOS(config-dnssec)# hsm hsm1
ACOS(config-dnssec)# exit
Configuring GSLB
The following commands configure GSLB.
ACOS(config)# gslb service-ip vip-1 1.0.0.1
ACOS(config-service-ip:vip-1)# health-check-protocol-disable
ACOS(config-service-ip:vip-1)# health-check-disable
ACOS(config-service-ip:vip-1)# port 80 tcp
ACOS(config-service-ip:vip-1-port:tcp)# health-check-protocol-disable
110
ACOS(config-service-ip:vip-1-port:tcp)# health-check-disable
ACOS(config-service-ip:vip-1-port:tcp)# exit
ACOS(config-service-ip:vip-1)# exit
ACOS(config)# gslb service-ip ns 10.10.10.5
ACOS(config-service-ip:ns)# health-check-protocol-disable
ACOS(config-service-ip:ns)# health-check-disable
ACOS(config-service-ip:ns)# exit
111

ACOS(config)# gslb service-ip vip6-1 2001:111::1
ACOS(config-service-ip:vip6-1)# port 80 tcp
ACOS(config-service-ip:vip6-1-port:tcp)# exit
ACOS(config-service-ip:vip6-1)# exit
112

ACOS(config)# gslb site local
ACOS(config-gslb site:local)# bw-cost limit 100 threshold 10
ACOS(config-gslb site:local)# slb-dev self 127.0.0.1
ACOS(config-gslb site:local-slb dev:self)# vip-server vip1
ACOS(config-gslb site:local-slb dev:self)# exit
ACOS(config-gslb site:local)# ip-server ns
ACOS(config-gslb site:local)# ip-server vip-187
ACOS(config-gslb site:local)# exit
ACOS(config)# gslb site remote
ACOS(config-gslb site:remote)# weight 10
ACOS(config-gslb site:remote)# slb-dev site 192.168.217.1
ACOS(config-gslb site:remote-slb dev:site)# vip-server vip6-4
ACOS(config-gslb site:remote-slb dev:site)# vip-server vip-4
113
ACOS(config-gslb site:remote-slb dev:site)# exit

ACOS(config-gslb site:remote)# exit
ACOS(config)#
Configuring a GSLB Policy and Enable Server Mode

The gslb policy command configures a GSLB policy.
ACOS(config)# gslb policy gpol1
ACOS(config-policy:gpol1)# dns geoloc-alias
ACOS(config-policy:gpol1)# dns server authoritative ns ptr srv sec
The dns server command enables server mode, and also enables this ACOS device to be the
authoritative DNS server for the GSLB zones that use this policy.
Binding the DNSSEC Template to the Zone

Use the template dnssec command to bind the DNSSEC template to the zone:
ACOS(config)# gslb zone test.com
ACOS(config-zone:test.com)# policy gpol1
ACOS(config-zone:test.com)# template dnssec dt1
ACOS(config-zone:test.com)# service 0 www
ACOS(config-zone:test.com-service:www)# dns-a-record vip-2 static
ACOS(config-zone:test.com-service:www)# exit
ACOS(config-zone:test.com)# exit
ACOS(config)# gslb zone test1.com
ACOS(config-zone:test.com)# policy gpol1
ACOS(config-zone:test.com)# template dnssec dt1
ACOS(config-zone:test.com)# service 0 www
ACOS(config-zone:test.com-service:www)# exit
ACOS(config-zone:test.com)# exit
Configuring DNSSEC Standalone

The ACOS device does not need to be a member of a GSLB controller group to run DNSSEC. GSLB
is still required with standalone DNSSEC operation, but configuring a GSLB controller group is not
required.
By default, support for standalone DNSSEC operation is optional and is disabled.

ACOS(config)# dnssec standalone
114
Configuring the VIP for DNSSEC Requests

The following commands configure the virtual servers and DNS service ports:
ACOS(config-slb vserver)# port 53 udp
ACOS(config-slb vserver-vport)# name _1.1.1.1_UDP_53
ACOS(config-slb vserver-vport)# gslb-enable
ACOS(config-slb vserver)# port 53 dns-tcp
ACOS(config-slb vserver-vport)# name _1.1.1.1_DNS-TCP_53
ACOS(config-slb vserver-vport)# gslb-enable
115
116
Chapter 11: Location-Based VIP Access
Overview of Location-based VIP Access 118
Configuration Using a Class List 118
Configuration Using a Black/White List 120
Enabling Full-Domain Checking 124
Enabling PBSLB Statistics Counter Sharing 126
117
Overview of Location-based VIP Access

You can control access to a VIP that is based on the geo-location of the client. Depending on the
location of the client, you also can configure ACOS to perform one of the following actions for traffic
from a client:
Drop the traffic

Send the traffic to a specific service group (if configured using a black/white list)
ACOS determines a client’s location by looking up the client’s subnet in the geo-location database
that is used by Global Server Load Balancing (GSLB).
NOTE: This feature requires you to load a geo-location database, but does
not require any other configuration of GSLB. The ACOS system image
includes the Internet Assigned Numbers Authority (IANA) database.
By default, the IANA database is not loaded but you can easily load it.
For more information, see Loading the IANA Geo-Location Database.
Configuration Using a Class List

This section shows how to configure the geo-location-based VIP access by using a class list.
NOTE: In the current release, geo-location-based VIP access works only if

the class list is imported as a file. The CLI does not support con-
figuration of class-list entries for this application.
Example
The following class list maps client geo-locations to limit IDs (LIDs), which specify the maximum
number of concurrent connections allowed for clients in the geo-locations.
L US 1
L US.CA 2
L US.CA.SJ 3
118
The following commands import the class list to the ACOS device, configure a policy template, and
bind the template to a virtual port. The connection limits specified in the policy template apply to cli-
ents that send requests to the virtual port.
NOTE: This example assumes the default geo-location database (iana) is

loaded.
ACOS(config)# import class-list c-share tftp://192.168.32.162/
File name [/]? c-share
Importing ... Done.
ACOS(config)# slb template policy pclass
ACOS(config-policy)# class-list c-share
ACOS(config-policy-class-list:c-share)# lid 1
ACOS(config-policy-class-list:c-share-li...)# conn-limit 4
ACOS(config-policy-class-list:c-share-li...)# exit
ACOS(config-policy-class-list:c-share)# exit
ACOS(config-policy)# geo-location overlap
ACOS(config)# slb virtual-server vip1 10.1.1.155
ACOS(config-slb vserver-vport)# template policy pclass
The following command verifies the operation of the policy:

ACOS(config-policy)# show slb geo-location statistics
M = Matched or Level, ID = Group ID
Conn = Connection number, Last = Last Matched IP
v = Exact Match, x = Fail
Virtual Server: vip1/80, c-share
-------------------------------------------------------------------------------
-
max Depth: 3
Success: 3
Geo-location M ID Permit Deny Conn Last
-------------------------------------------------------------------------------
-
US.CA.SJ v 3 1 1 1 77.1.1.107
119
-------------------------------------------------------------------------------
-
Total: 1
Configuration Using a Black/White List

Details 120
Configuring the Black/White List 120
Methods 121
Using the GUI 122
CLI Example 123
Details
To configure geo-location-based access control for a VIP:
1. Configure a black/white list.
You can configure the list by using a text editor or enter the list into the GUI. If you configure
the list by using a text editor, import the list to the ACOS device.
2. Configure an SLB policy (PBSLB) template.
In the template, specify the black/white list name, and the actions to perform for the group
IDs in the list.
3. Verify that the geo-location database is loaded.
For more information about loading the geo-location database, see Loading the IANA Geo-
Location Database.
4. Apply the policy template to the virtual port for which you want to control access.
Configuring the Black/White List
120
Methods 121
Using the GUI 122
CLI Example 123
Methods
You can configure black/white lists in one of the following ways:
Remote – Use a text editor and import the list to the ACOS device.
Local – Enter the black/white list in a management GUI window.
With both methods, the syntax is the same. The black/white list must be a text file that contains
entries (rows) in the following format:
L "geo-location" group-id #conn-limit
The various parameters in the syntax are described in the TABLE 11-1 .
TABLE 11-1 Black/White List Syntax Description
L Indicates that the client’s location will be determined by using information in

the geo-location database.
geo-location String in the geo-location database that is mapped to the client’s IP address,
for example, “US”, “US.CA”, or “US.CA.SanJose”.
group-id Number from 1 to 31 that identifies a group of clients (geo-locations) in the

list. The default group ID is 0, which means no group is assigned. On the
ACOS device, the group ID specifies the action to perform on client traffic.
#conn-limit Maximum number of concurrent connections allowed from a client. The # is

required only if you do not specify a group ID. The connection limit is
optional. For simplicity, the examples in this section do not specify a con-
nection limit.
Below is a simple example of a Black/White list:

L "US" 1
L "US.CA" 2
L "JP" 3
121
Using the GUI
Creating a Black-White List
To configure Black-White list by using the GUI:
1. Navigate to ADC >> Black-white Lists.

2. Click Create and complete the fields on the Create Black-White List page.
Enter the list in the Definition field.
NOTE: For more details and information about any of the required
fields on this page, see the latest version of the GUI Online Help.
3. Click Create.
Configuring an SLB policy (PBSLB) Template
To configure an SLB policy template:
1. Navigate to ADC >> Templates > L7.

2. Click Create and select Policy from the drop-down list.
3. In the Name field, specify a template name.
4. Complete the other fields on the screen as desired.
NOTE: For more details and information about any of the required
fields on this page, see the latest version of the GUI Online Help.
5. Click OK.
Loading the IANA Geo-Location Database
To load the IANA geo-location database:
1. Navigate to GSLB >> Geo-Location Files.

2. Click Import.
3. Specify iana in the Name field.
122
4. Complete the Host and Location fields to specify the location of the file you are importing.
5. Leave the Template fields blank.
6. Click Import.
NOTE: You can also import a custom geo-location database. For more inform-
ation, see the Global Server Load Balancing Guide.
Applying the Policy Template to a Virtual Port
To apply the policy template to a new virtual port:
1. Navigate to ADC >> SLB >> Virtual Servers.

2. Click Create.
3. Specify the name and IP address of the virtual server.
4. In the Virtual Port section, click Create.
a. Specify a protocol and port number.
b. Expand the Templates section.
c. In the Template Policy field, select the desired policy template.
d. Click Create.
e. Click Update.
CLI Example
The following command imports black/white list “geolist” onto the ACOS device.
ACOS(config)# import bw-list geolist scp://192.168.1.2/root/geolist
The following commands configure a policy template named “geoloc” and add the black/white list
to it. The template is configured to drop traffic from clients in the geo-location mapped to group 1 in
the list.
ACOS(config)# slb template policy geoloc
ACOS(config-policy)# bw-list name geolist
ACOS(config-policy)# bw-list id 1 drop
The following commands apply the policy template to port 80 on virtual server “vip1”:
ACOS(config)# slb virtual-server vip1
ACOS(config-slb vserver-vport)# template policy geoloc
123
To view SLB geo-location statistics, use the show slb geo-location command.
Enabling Full-Domain Checking

Details 124
Using the GUI to Configure Full-Domain Checking 125
Using the CLI to Configure Full-Domain Checking 125
Details
By default, when a client requests a connection, the ACOS device checks the connection count
only for the specific geo-location level of the client. If the connection limit for that specific geo-loc-
ation level is not reached, the client’s connection is permitted. Similarly, the permit counter is
increased only for that specific geo-location level.
TABLE 11-2 shows an example set of geo-location connection limits and current connections.
TABLE 11-2 Geo-location connection limit example
Geo-location Connection Limit Current Con-

nections
US 100 100
US.CA 50 37
US.CA.SanJose 20 19
Using the default behavior, the connection request from the client at US.CA.SanJose is allowed
even though CA has reached its connection limit. Similarly, a connection request from a client at
US.CA is allowed. However, a connection request from a client whose location match is simply “US”
is denied.
After these three clients are permitted or denied, the connection permit and deny counters are
increased in the following way:
124
US – Deny counter is increased by 1.

US.CA – Permit counter is increased by 1.
US.CA.SanJose – Permit counter is increased by 1.
When full-domain checking is enabled, the ACOS device checks the current connection count not
only for the client’s specific geo-location, but for all geo-locations higher up in the domain tree.
Based on full-domain checking, all three connection requests from the clients in the example
above are denied. This is because the US domain has reached its connection limit. Similarly, the
counters for each domain are updated as follows:
US – Deny counter is incremented by 1.

US.CA – Deny counter is incremented by 1.
Using the GUI to Configure Full-Domain Checking
This is configurable on the configuration page for the policy template:
1. Navigate to ADC >> Templates >> L7.

3. Specify a name for the policy template.
4. Expand the Geo Location pane.
5. Select Full Domain Tree.
6. Click OK.
Using the CLI to Configure Full-Domain Checking
To enable full-domain checking for geo-location-based connection limiting, enter the geo-loc-
ation full-domain-tree command at the configuration level for the PBSLB template:
ACOS(config)# slb template policy example_policy_template
ACOS(config-policy)# geo-location full-domain-tree
NOTE: You must enable or disable this option before you enable GSLB.
Changing the state of this option while GSLB is running can cause
the related statistics counters to be incorrect.
125
Enabling PBSLB Statistics Counter Sharing

Details 126
Using the GUI to Enable PBSLB Statistics Counter Sharing 126
Using the CLI to Enable PBSLB Statistics Counter Sharing 127
Details
You can enable sharing of statistics counters for all virtual servers and virtual ports that use a
PBSLB template. This option causes the following counters to be shared by the virtual servers and
virtual ports that use the template:
Permit
Deny
Connection number
Connection limit
Using the GUI to Enable PBSLB Statistics Counter Sharing
This is configurable on the configuration page for the policy template:
1. Navigate to ADC >> Templates >> L7.

3. Specify a name for the policy template.
4. Expand the Geo Location pane.
5. Select Share.
6. Click OK.
126
Using the CLI to Enable PBSLB Statistics Counter Sharing
To enable the share option, enter the geo-location share command at the configuration level for
the PBSLB policy template:
ACOS(config)# slb template policy example_policy_template
ACOS(config-policy)# geo-location share
NOTE: You must enable or disable this option before you enable GSLB.
Changing the state of this option while GSLB is running can cause
the related statistics counters to be incorrect.
127
128
Glossary
B
destination rule
black list A policy developed for routing the

traffic and for defining service sub-
A list of usernames or IP addresses sets in outlier detection or load bal-
that have been denied access to ancing.
specific systems or protocols.
DNS
D
Domain Name System. A hier-
archical model and decentralized
DDoS
naming system that identifies com-
Distributed Denial-of-Service. A puters, resources and network-
malicious attempt that floods a tar- based services over a private net-
geted server and its surrounding work or the Internet. It specifies
infrastructure with internet traffic. information on web domain names
The purpose of DDoS attack is to associated with respective entities.
distort the normal traffic of serv-
ers, services or networks by exploit-
E
ing multiple compromised IoT
devices, computer systems, and
network resources as sources of escalation
traffic attacks. A sudden rise of potential security
problems made across multiple con-
destination object texts of networking.
An administered networking object

that contains information on con- H
figurations developed by the admin-
istrator for clients. It also HTTP
encapsulates provider-specific HyperText Transfer Protocol. An
address. underlying web protocol that
defines the way messages can be
formatted and sent, and the
actions to be taken by web servers
129
Glossary
and browsers for responding to model used for establishing host-

multiple commands. to-host communications for applic-
ations.
I
M
ICMP
mitigation
Internet Control Message Protocol.
An internet layer protocol utilized A protection and detection solu-
by network devices for diagnosis tion implemented by IT admin-
of network communication issues. istrators for safeguarding servers,
Primarily used for error reporting, networks, applications, and inform-
ICMP determines whether or not ation by minimizing the impact of
data reaches its intended des- intrusion attempts and malicious
tination in the given time. traffic without compromising on
user functionalities.
L
N
L2
NetFlow
A Data Link Layer, the second
layer in the seven-layered OSI ref- A network protocol for accu-
erence model used for designing mulating IP traffic information
network protocols. It consists MAC and monitoring network traffic by
address, frame relay, token ring using a NetFlow collector and ana-
and ethernet. lyzer. It is developed and main-
tained by Cisco.
L3
NTP
A Network Layer, the third layer in
the seven-layered OSI reference Network Time Protocol. A net-
model used for routing traffic and working protocol developed for
forwarding packets across inter- synchronizing clock times among
mediate routers. multiple computer systems and
across packet-based, variably-lat-
L4 ent data networks.
A Transport Layer, the fourth layer

of the seven-layered OSI reference
130
Glossary
P T
protected object TCP

A networking object that specifies Transmission Control Protocol. Key
the requirements for authorization part of the main IP suite protocols
or access from external network used during initial network imple-
members. mentation.
S traffic scrubbing
A unified station for cleaning data
sFlow and analysing traffic for removal
An industry standard, termed as of malicious traffic.
sampled flow, used in network
monitoring for exporting trun- U
cated packets along with interface
counters at Layer 2 of the OSI UDP
model.
User Datagram Protocol. An altern-
ative to TCP and used for setting
SSL
up connections with low-latency
Secure Sockets Layer. A set of and loss-tolerance between inter-
cryptographic protocols that net applications.
provide data transport and com-
munications security over a net- W
work.
white list
static destination
A list of usernames or IP addresses
An unchanging IP address which that have been granted access to
serves as the endpoint for packet specific systems or protocols.
forwarding.
131
Glossary
zone
A group of terminals, gateways,
and multipoint control units
(MCUs) within a specific domain of
a multimedia network. It can be
permanently configured on
devices or made relative as a
runtime entity for a specific event.
132
133

Ddos Mitigation Guide (For Adc) : Acos 5.2.1-P1

Uploaded by

Copyright:

Available Formats

Ddos Mitigation Guide (For Adc) : Acos 5.2.1-P1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ddos Mitigation Guide (For Adc) : Acos 5.2.1-P1

Uploaded by

Copyright:

Available Formats

ACOS 5.2.

© 2021 A10 Networks, Inc.CONFIDENTIAL AND PROPRIETARY- ALL RIGHTS RESERVED.

Chapter 2: IP Anomaly Filtering 19

Chapter 3: Policy-based SLB 25

Chapter 4: SYN Cookies 39

SYN Flood Attacks 40

Chapter 6: ICMP Rate Limiting 73

Using the GUI to Configure ICMP Rate Limiting 75

Chapter 7: HTTP Slowloris Prevention 77

Chapter 8: DNS Application Firewall 79

Chapter 9: DNS Response Rate Limiting 85

Using the CLI to Configure and Monitor DNS RRL 92

Chapter 10: DNSSEC Support 95

Chapter 11: Location-Based VIP Access 117

CLI Example 123

The following topics are covered:

Application Access Management 12

Online Certificate Status Protocol 13

Attack Detection and Prevention using ZBAR 14

Single CPU Attack Prevention 15

ICMP Rate Limiting 16

Web Application Firewall 16

DNS Application Firewall 17

Geo-location-based VIP Access 18

Application Access Management

The following topics are covered:

Online Certificate Status Protocol (OCSP) 12

AAA Health Monitoring and Load Balancing 13

Provides a sign-on interface. By using a request-reply exchange or using a Web-based form,

Online Certificate Status Protocol (OCSP)

AAA Health Monitoring and Load Balancing

Online Certificate Status Protocol

NOTE: For more information about DDos Mitigation, see IP Anomaly

Attack Detection and Prevention using ZBAR

This solution employs the following infrastructure capabilities:

To enable this feature, refer to the following configuration:

show visibility zbar dest

show visibility zbar dest bad-sources

For more information, see the Application Delivery Controller Guide.

Single CPU Attack Prevention

NOTE: For more information about the command system cpu-load-shar-

NOTE: For more information about IP limiting, see IP Limiting.

ICMP Rate Limiting

Web Application Firewall

Incoming user requests

DNS Application Firewall

Geo-location-based VIP Access

Drop the traffic

The following topics are covered:

Overview of IP Anomaly Filtering 20

Configuring IP Anomaly Filtering 23

Displaying IP Anomaly Statistics 24

Overview of IP Anomaly Filtering

The following topics are covered:

IP Anomaly Filters for System-wide PBSLB 21

SOCKSTRESS_CHECK Session State 22

The following topics are covered:

Zero-length TCP Window 21

Zero-length TCP Window