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

ACOS 5.2.
1-P3
DDoS Mitigation Guide (for ADC)
September, 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 10
Application Access Management 11
Login Portal 11
Online Certificate Status Protocol (OCSP) 11
Authentication Relay 11
AAA Health Monitoring and Load Balancing 12
Online Certificate Status Protocol 12
DDoS Mitigation 12
Attack Detection and Prevention using ZBAR 13
Single CPU Attack Prevention 14
Policy-Based SLB 14
SYN Cookies 14
IP Limiting 15
ICMP Rate Limiting 15
Web Application Firewall 15
Slowloris Prevention 16
DNS Application Firewall 16
DNSSEC 16
SSL Insight 16
Geo-location-based VIP Access 17
Chapter 2: IP Anomaly Filtering 18

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

Overview 25
Configuring a Black/White List 25
Configuration Details and Examples 26
Example Black/White List 28
Dynamic Black/White-list Client Entries 28
Connection Limit for Dynamic Entries 29
Aging of Dynamic Entries 29
Wildcard Address Support in PBSLB Policies Bound to Virtual Ports 30
Configuring System-wide PBSLB 30
Options for System-wide PBSLB Policies 30
Using the GUI to Configure System-wide PBSLB 31
Using the CLI to Configure System-wide PBSLB 31
Displaying and Clearing System-wide PBSLB Information 32
Configuring PBSLB for Individual Virtual Ports 32
Configuration Details 32
Using the GUI to Configure PBSLB for Individual Virtual Ports 33
Using the CLI to Configure PBSLB for Individual Virtual Ports 35
Configuration Example for Sockstress Attack Protection 36
PBSLB Statistics Display 36
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 48
Details 48
Using the GUI to Configure SYN-cookie Buffering 49
Using the CLI to Configure SYN-cookie Buffering 49
Viewing SYN-cookie Statistics 49
Using the GUI to View SYN-cookie Statistics 50
Using the CLI to View SYN-cookie Statistics 50
L4 SYN attack 50
L4 TCP Established 50
Examples 51
CLI Example 1: View Attack Prevention Statistics 51
CLI Example 2: View SYN Attack Counter 52
CLI Example 3: View Legitimate Session Counter 53
CLI Example 4: View SYN-cookie Buffering Statistics 53
SYN Attack Counter Support for L3V 53
Chapter 5: IP Limiting 55
Overview of IP Limiting 56
Understanding Class Lists 56
5
Contents
Class List Syntax 57

IP Address Matching 58
Example Class Lists 59
Configuring Class Lists 60
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 61
Using the CLI to Configure a Class List 61
Understanding IP Limiting Rules 61
Parameters 62
Match IP Address 63
Request Limiting and Request-Rate Limiting in Class Lists 64
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 65
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 66
Example 2: System GLID 66
Example 3: System-wide Policy Template 66
Configuring Source IP Limiting 66
CLI Examples - Configuration 67
Configuring System-wide IP Limiting With a Single Class 68
Configuring System-wide IP Limiting With Multiple Classes 68
Configuring IP Limiting on a Virtual Server 69
Configuring IP Limiting on a Virtual Port 70
Configuring Class List Entries That Age Out 70
CLI Examples - Display 71
Viewing Class-Lists 72
Viewing IP Limiting Rules 72
Viewing IP Limiting Statistics 72
Chapter 6: ICMP Rate Limiting 73

ICMP Rate Limiting Overview 74
Configuring ICMP Rate Limiting 74
6
Contents
ICMP Rate Limiting Parameters 74

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 84

Overview of DNS Response Rate Limiting (RRL) 85
Details 85
DNS Reflection Attacks 85
Challenges of Stopping DNS Reflection Attacks 86
ACOS Mitigation of DNS Reflection Attacks 86
Two-tiered Rate-limiting System for DNS Queries 87
Configuration Parameters for DNS RRL 87
Setting the Rate Limits 87
Protecting System Resources 88
Allowing Valid DNS Queries to Pass 88
More Information 88
Limitations 89
Configuration Example 90
7
Contents
Using the GUI to Configure DNS RRL 90

Using the CLI to Configure and Monitor DNS RRL 91
Chapter 10: DNSSEC Support 93

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

Overview of Location-based VIP Access 115
Configuration Using a Class List 115
Configuration Using a Black/White List 117
Details 117
Configuring the Black/White List 118
Methods 118
8
Contents
Using the GUI 119

CLI Example 121
Enabling Full-Domain Checking 121
Details 122
Using the GUI to Configure Full-Domain Checking 123
Using the CLI to Configure Full-Domain Checking 123
Enabling PBSLB Statistics Counter Sharing 123
Details 124
Using the GUI to Enable PBSLB Statistics Counter Sharing 124
Using the CLI to Enable PBSLB Statistics Counter Sharing 124
9
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 11
Online Certificate Status Protocol 12
DDoS Mitigation 12
Attack Detection and Prevention using ZBAR 13
Single CPU Attack Prevention 14
Policy-Based SLB 14
SYN Cookies 14
IP Limiting 15
ICMP Rate Limiting 15
Web Application Firewall 15
Slowloris Prevention 16
DNS Application Firewall 16
DNSSEC 16
SSL Insight 16
Geo-location-based VIP Access 17
10
Chapter 1: Getting Started Feedback
Application Access Management

Application Access Management (AAM) is an ACOS security feature that optimizes Authentic-
ation, Authorization, and Accounting (AAA) for client-server traffic.
This following topics are covered:
Login Portal 11
Online Certificate Status Protocol (OCSP) 11
Authentication Relay 11
AAA Health Monitoring and Load Balancing 12
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 revoc-
ation 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 respon-
der for verification. 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.
11
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
verification 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 certificate 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 Cer-
tificates 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
infected with a Trojan or malware are, in turn, used to target a particular system. This pro-
cess 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 Fil-
tering.
12
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:
l Analytics infrastructure – It adaptively baselines multiple traffic metrics and creates a

monitoring entity that observes and determines the traffic baselines and sets attack
thresholds. On attack detection, it triggers the ZBAR infrastructure.
l ZBAR (Zero Day source behavior Attack Recognition) infrastructure - It dynamically
classifies the incoming traffic based on real-time traffic conditions. The ZBAR frame-
work performs clustering based on multiple metrics from the sources hitting the
attacked Destination/Destination-Service. By mapping the sources to these metrics,
ZBAR determines the miscreant source/sources, along with the associated confidence
score, suspected of causing a DDoS attack.
l 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 captured 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:
l show visibility zbar dest

l show visibility zbar dest bad-sources
13
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-shar-
ing is used to configure 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 sharing 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 ses-
sions. The purpose of the attack is to consume the target’s resources with half-open TCP ses-
sions.
When SYN cookies are enabled, the ACOS device can continue to serve legitimate clients dur-
ing TCP SYN flood attacks, while preventing illegitimate traffic from consuming system
resources.
14
NOTE: For more information about SYN cookies, see SYN Cookies.
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 mon-
itors 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) feature. WAF filters communication between end-users and Web applications to pro-
tect 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:
l Incoming user requests

l Output from Web servers
l Access to Web site content
NOTE: Fore more information about WAF, see the Web Application Fire-
wall Guide.
15
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.
NOTE: 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.
16
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, depend-
ing on the location of the client:
l Drop the traffic

l Reset the connection
l 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 data-
base that is used by Global Server Load Balancing (GSLB).
NOTE: For more information about Geo-location-based VIP access, see

Location-Based VIP Access.
17
Chapter 2: IP Anomaly Filtering
ACOS helps you detect and mitigate Distributed Denial of Service (DDoS) attacks. One of the
features, IP anomaly filtering, can protect against numerous types of attacks.
Overview of IP Anomaly Filtering 19
Configuring IP Anomaly Filtering 22
Displaying IP Anomaly Statistics 23
18
Chapter 2: IP Anomaly Filtering Feedback
Overview of IP Anomaly Filtering

IP anomaly filtering detects and drops packets that contain the common signatures of DDoS
attacks.
IP Anomaly Filters 19
IP Anomaly Filters for System-wide PBSLB 20
Threshold 21
SOCKSTRESS_CHECK Session State 21
Implementation Notes 21
IP Anomaly Filters
Users can enable the following IP anomaly filters. This section has the following sub-sections:
Frag 19
IP-option 20
Land-attack 20
Zero-length TCP Window 20
Out-of-sequence Packet 20
Ping-of-death 20
TCP-no-flag 20
TCP-SYN-FIN 20
TCP-SYN-frag 20
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.
19
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:
l Invalid HTTP or SSL payload

l Zero-length TCP window
l Out-of-sequence packet
20
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
individual basis.
NOTE: These filters are supported only for HTTP and HTTPS traffic.
NOTE: For information about system-wide PBSLB, see Configuring Sys-

tem-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 anom-
aly, 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:
l All IP anomaly filters are supported for IPv4.

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

o Thunder 6430S, Thunder 6430, and Thunder 5430S
o AX 3200-12
l DDoS protection is software-based on other models.
l DDoS detection applies only to Layer 3, Layer 4, and Layer 7 traffic.
l Layer 2 traffic is not affected by the feature. Layer 4 and Layer 7 DDoS applies only to
software releases that support Server Load Balancing (SLB).
l All IP anomaly filters, except “IP-option”, apply to IPv4 and IPv6. The “IP-option” filter
applies only to IPv4.
l The ping-of-death option drops all IP packets longer than 32000 bytes on the fol-
lowing models
l Thunder 3030S, Thunder 1030S, and Thunder 930
o 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 this chapter are disabled. You can
enable individual IP anomaly filters, on a system-wide basis.
Using the GUI to Configure IP Anomaly Filtering 22
Using the CLI to Configure IP Anomaly Filtering 22
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.
22
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 23
Using the CLI to Display IP Anomaly Statistics 23
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
command:
NOTE: For more information about these commands, see Command Line
Interface Reference Guide.
23
Chapter 3: Policy-based SLB
This chapter helps you understand and configure policy-based SLB (PBSLB).
Overview 25
Configuring a Black/White List 25
Configuring System-wide PBSLB 30
Configuring PBSLB for Individual Virtual Ports 32
Configuration Example for Sockstress Attack Protection 36
PBSLB Statistics Display 36
24
Chapter 3: Policy-based SLB Feedback
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
connection 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 virtual-

server level. However, PBSLB does not take effect if you apply the
policy template at the virtual-server level. Only class lists are sup-
ported at the virtual-server level. To use PBSLB, you must apply
the policy template globally or on individual virtual ports.
NOTE: 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 connection counter more than
once, which results in a much lower connection limit than the con-
figured 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:
25
Configuration Details and Examples 26
Example Black/White List 28
Dynamic Black/White-list Client Entries 28
Connection Limit for Dynamic Entries 29
Aging of Dynamic Entries 29
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 impor-
ted 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 indi-
vidual 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 fol-
lowing syntax:
ipaddr [/network-mask] [group-id] [#conn-limit] [;comment-string]
The syntax is defined in the following way:
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.
26
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
Reset the connection
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 client. 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 spe-
cify, the more coarse the limit.
Example
If you specify 100, the ACOS device limits the total connections to 100.
l As another example, if you specify 1000, the device limits the connections to a max-
imum of 992 connections.
l 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.
27
Example
l If the file contains 32768, the parser uses 3276 as the value.
l As another example, if the file contains 111111, the parser will use 11111 as the value.
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
connections.
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 client address 0.0.0.0/0 (wildcard address) to the black/white list that is used by the sys-
tem-wide PBSLB policy.
When a client sends an HTTP or HTTPS connection request, the ACOS device checks the sys-
tem-wide PBSLB policy’s black/white list for the client’s IP address, with one of the following
results:
28
l If there is no entry for the client, he ACOS device creates a dynamic entry for the cli-
ent’s host address.
l 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
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 clients.
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.
29
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:
l The ACOS device does not create dynamic entries in the list.
l 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 30
Using the GUI to Configure System-wide PBSLB 31
Using the CLI to Configure System-wide PBSLB 31
Displaying and Clearing System-wide PBSLB Information 32
Options for System-wide PBSLB Policies
System-wide PBSLB policies provide the following options:
l Dynamic black/white-list client entries

l Client lockup
l IP anomaly checking and tracking, using IP anomaly filters
These options are not available in policies that are applied to individual ports.
30
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.
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 fol-
lowing limits:
l The connection limit that is configured in the specified in the Black/White list.
l 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
31
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
client 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 coun-
ters and client entries; without this option, only the statistical counters are cleared.
Configuring PBSLB for Individual Virtual Ports

Configuration Details 32
Using the GUI to Configure PBSLB for Individual Virtual Ports 33
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 indi-
vidual ports or by configuring a PBSLB policy template and binding the template to indi-
vidual virtual ports.
NOTE: This feature is supported only in software releases that support

Server Load Balancing (SLB).
32
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
following settings on individual virtual ports:
l Specify the black/white list.

l Optionally, map each group ID that used in the list to one of the following actions:
o Send the traffic to a specific service group.
o Reset the traffic.
o Drop the traffic.
l Optionally, change the action (drop or reset) that ACOS will take on connections that
exceed the specified limit.
l Optionally, if necessary, change the client address matching from source IP matching
to destination 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.
33
e. Click OK.
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.
34
Using the CLI to Configure PBSLB for Individual Virtual Ports
The following commands import black/white list “sample-bwlist.txt” to the ACOS device:
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
35
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 following conditions occur:
l The client already has 20 active connections and attempts to open a new HTTP or
HTTPS connection.
l 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
36
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
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 cli-
ents 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
37
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
This chapter describes the SYN-cookie feature and how it helps protect ACOS devices against
disruptive SYN-based flood attacks.
Overview of SYN Cookies 40
Configuring SYN Cookies 44
Viewing SYN-cookie Statistics 49
39
Chapter 4: SYN Cookies Feedback
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 ille-
gitimate 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 SYN-ACK Handshake (Legitimate Client) 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 (SYN-ACK Handshake (Hacker) ) 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” sessions, which wastes system memory and other system resources.
The state of being oversubscribed 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 iden-
tified 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 during TCP SYN flood attacks. When a client sends an SYN request, the ACOS device
41
responds with a SYN cookie. This response is a special type of SYN ACK message.
SYN cookies prevent hackers from consuming excessive system resources by encoding the
necessary 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 shorthand, 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 cli-
ent.
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:
l On-threshold – specifies the maximum number of concurrent half-open TCP con-

nections 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 cookies. You can specify 0-2147483647 half-open connections.
l Off-threshold – specifies the minimum number of concurrent half-open TCP con-
nections for which to keep SYN cookies enabled. If the number of half-open TCP con-
nections 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
allocated 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
connection. The window size also reduces during this process.
SYN Cookie Buffering is automatically enabled when SYN cookies are enabled. By default, 10
buffers are allocated to each TCP connection. Instead being dropped and requiring later re-
transmission, 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 configuration level for virtual ports. The ACOS device bases Selective Acknowledgment
(SACK) support, and the maximum segment size (MSS) setting, in software-based SYN cook-
ies on server replies to TCP health checks that are sent to the servers.
SACK
The ACOS device includes the Sack-Permitted option in TCP SYN health check packets sent
to servers.
43
l 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 servers in the service group.
l 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 service 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
features.
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 48
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 soft-
ware-based SYN cookies:
44
l Hardware-based SYN cookies can be globally enabled and applied to all virtual server
ports that are configured on the device.
l 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.
l 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:
l Hardware-based SYN cookies are a faster, easier-to-configure alternative to the soft-

ware-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.
l 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.
l 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 num-
ber of concurrent half-open TCP connections exceeds 50000 and disables SYN cookies when
the number 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, con-
figure the following items:
l On the ACOS device, configure a “dummy” VIP that is in the same subnet as the client-
side router.
l On the client-side router, configure a static route to the VIP by using the dummy VIP as
the next hop.
Hardware-based SYN Cookies – Target VIP and Client-Side Router in Different Subnets 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
47
Configuring SYN-cookie Buffering
Details 48
Using the GUI to Configure SYN-cookie Buffering 49
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 cli-
ent session. When the system memory is occupied, the number of buffers dedicated to each
TCP connection 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 alloc-
ated 10 buffers, and the TCP window size is set to 8K.
l If the first threshold is breached, the buffer is reduced to 4 buffers, and the TCP win-
dow size is reduced to 4K.
l If the next memory threshold is breached, the buffer is reduced to 2 buffers, and the
TCP window size is reduced to 2K.
l 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:
l 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.
48
l 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:
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
additional 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 50
Using the CLI to View SYN-cookie Statistics 50
49
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
additional information about the fields.
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
Examples 51
CLI Example 1: View Attack Prevention Statistics 51
CLI Example 2: View SYN Attack Counter 52
CLI Example 3: View Legitimate Session Counter 53
CLI Example 4: View SYN-cookie Buffering Statistics 53
SYN Attack Counter Support for L3V 53
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 legit-
imate clients. When SYN cookies are enabled, and a legitimate client sends a SYN request, the
50
ACOS device responds with a SYN ACK. If the ACOS device receives an ACK, the packet is con-
sidered safe.
Examples
These fields are highlighted using these examples.
CLI Example 1: View Attack Prevention Statistics

You can view SYN-cookies statistics for one sampling interval or across the following time
intervals:
l Current
l 1 second
l 5 seconds
l 30 seconds
l 1 minute
l 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 show slb attack-prevention fields displays the fields that appear in the CLI output of the
show slb attack-prevention command.
51
show slb attack-prevention fields
Field Description
SYN cookie snt Number of TCP SYN cookies sent.
SYN cookie snt Number of expanded TCP SYN cookies sent.

ts
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
l 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).
Output is only provided for the Current column.
l 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.
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
52
...
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 Estab-
lished 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 cor-
rectly in every situation. For example, while counters that are associated with software-
based SYN cookies work correctly in L3V and non-L3V deployments, counters that are asso-
ciated with hardware-based SYN cookies do not work with private partitions.
The SYN flood attack counter matrix shows the limitations that are associated with using
SYN flood attack counters under a variety of conditions.
53
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 dis-
play will function correctly, based on the status of the other conditions that are associated
with this deployment.
1 If hardware-based and software-based SYN cookies are enabled, only hardware-based SYN
cookies 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 lim-
itation with this feature.
54
Chapter 5: IP Limiting
IP limiting provides a an enhanced implementation of the source IP connection limiting and
connection-rate limiting feature. This chapter describes 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 67
CLI Examples - Display 71
55
Chapter 5: IP Limiting Feedback
Overview of IP Limiting
IP limiting provides the following benefits:
l Configuration flexibility:
You can apply source IP limiting on a system-wide basis, on individual virtual servers, or on
individual virtual ports.
l 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:
l Concurrent connections
l Connection rate
l Concurrent Layer 7 requests
l 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
template that is configured in a shared partition or in a private
partition can use a class list that is configured in the shared par-
tition.
56
Class List Syntax 57
IP Address Matching 58
Example Class Lists 59
Configuring Class Lists 60
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]
The
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 con-
figuration 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
temporarily 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-impor-
ted. Instead, the entries are allowed to con-
tinue aging normally.
;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.
Class List Syntax Parameters provides a description of each portion of the format.
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:
l Destination IP address:
Matches based on the destination IP address instead of the source IP address.
58
l IP address in HTTP request:
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:
l For individual host 1.1.1.1, use IP limiting rule 1, which is configured in a policy template.
l A policy template can be applied globally for system-wide IP limiting or to an individual
virtual server or virtual port. This is described in more detail in a later section.
l For all hosts in subnet 2.2.2.0/24, use IP limiting rule 2, which is configured in a policy
template.
l 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.
l For individual host 3.3.3.3, use IP limiting rule 3, which is configured at the global con-
figuration level.
l For individual host 4.4.4.4, do not use an IP limiting rule.
59
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 61
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.
60
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
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 62
Match IP Address 63
Request Limiting and Request-Rate Limiting in Class Lists 64
CLI Examples: Request Limiting and Request-rate Limiting Settings Are Used 64
CLI Examples: Request Limiting and Request-rate Limiting Settings Are Not Used 65
61
Configuring Source IP Limiting 66
Parameters
IP limiting rules specify connection and request limits for clients.
Each IP limiting rule has the following parameters:
l Limit ID – Number from 1-31 that identifies the rule.

l Connection limit – Maximum number of concurrent connections that are allowed for a
client. You can specify 0-1048575. Connection limit 0 immediately locks down match-
ing clients, and there is no default value.
l 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.
l 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.
l 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.
l Over-limit action – Action to take when a client exceeds at least one limit.
l The action can be one of the following:
l Drop – The ACOS device drops that traffic. If logging is enabled, the ACOS device also
generates a log message. This is the default action.
l Forward – The ACOS device forwards the traffic. If logging is enabled, the ACOS device
also generates a log message.
l 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.
l Lockout period – Number of minutes during which to apply the over-limit action after
the client 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.
62
l 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
occurrence. If you specify a logging period, the ACOS device keeps the repeated messages
for the specified 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.
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

Limiting 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 inter-
face.
Match IP Address
By default, the ACOS device matches class-list entries based on the source IP address of cli-
ent traffic. Optionally, you can also match based on one of the following options:
l Destination IP address – Matches based on the destination IP address in packets from

clients.
l 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.
63
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 settings apply only if the following conditions are true:
l The LID or GLID is used in a policy template.

l 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:
l The policy template is applied to the virtual server, instead of the virtual port.
l The settings are in a system-wide GLID.
l The settings are in a system-wide policy template.
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 set-
tings 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
64
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
settings 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
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
65
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 template 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
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:
66
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 stan-
dalone IP limiting rules.
3. For IP limiting on an individual virtual server or virtual port, configure the rules in a
policy template.
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.
l For system-wide source IP limiting, apply the policy template globally.

l For source IP limiting on an individual virtual server or virtual port, apply the policy tem-
plate 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 configure system-wide IP limiting and also configure IP limiting on a virtual server, cli-
ents 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.
Configuring System-wide IP Limiting With a Single Class 68
Configuring System-wide IP Limiting With Multiple Classes 68
Configuring IP Limiting on a Virtual Server 69
Configuring IP Limiting on a Virtual Port 70
Configuring Class List Entries That Age Out 70
67
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
clients, 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 limiting 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:

68
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
69
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:
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.
70
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
connection 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
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 72
Viewing IP Limiting Rules 72
71
Viewing IP Limiting Statistics 72
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
Interface 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.
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.
72
Chapter 6: ICMP Rate Limiting
ICMP Rate Limiting Overview 74
Configuring ICMP Rate Limiting 74
73
Chapter 6: ICMP Rate Limiting Feedback
ICMP Rate Limiting Overview

ICMP/ICMPv61 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 con-
figured 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:
l 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 packets per second.
l Maximum rate – The ICMP maximum rate is the maximum number of ICMP packets
allowed per second before the ACOS device locks up ICMP traffic.
1 Subsequent 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.
l 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. Otherwise, the ICMP rate-limiting counters are still
incremented but log messages are not generated.
NOTE: 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 configure ICMP rate limiting.
3. In the Update Ethernet page, select the checkbox in the ICMP Rate Limit field, then spe-
cify 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:
l Global configuration level

l Configuration level for a physical or virtual Ethernet interface
l 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 Feedback
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 con-
sume 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
command 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 Web Application Firewall
Guide.
78
Chapter 8: DNS Application Firewall
Overview of the DNS Application Firewall 80
DNS Sanity Check 80
Configuring DNSSEC 81
79
Chapter 8: DNS Application Firewall Feedback
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
malformed. 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.
l Drops the query.

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

l RFC 1035: Domain Names – Implementation and Specification
l 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
l Flags.qr == 0 (first bit in flags)

l Flags.opcode <=5 (bits 2 to 5 in flags)
l Flags.rcode == 0 (last 4 bits in flags)
l 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:

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

l Flags.opcode <=5
l Flags.rcode == 0
l qdcount > 0
l 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 virtual server:
82
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
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
Chapter 9: DNS Response Rate Limiting
Overview of DNS Response Rate Limiting (RRL) 85
Configuration Example 90
84
Chapter 9: DNS Response Rate Limiting Feedback
Overview of DNS Response Rate Limiting (RRL)

Details 85
DNS Reflection Attacks 85
Challenges of Stopping DNS Reflection Attacks 86
ACOS Mitigation of DNS Reflection Attacks 86
Two-tiered Rate-limiting System for DNS Queries 87
Configuration Parameters for DNS RRL 87
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 reflec-
tion 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 serv-
ers.
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
85
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 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 quer-
ies themselves, but only to the responses from the DNS server to
the victim.
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).
1 For more information about DNS Reflection attacks, see https://en.wiki-

pedia.org/wiki/Reflection_attack.
86
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 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 approximately 100 bytes for each DNS query.
All DNS queries first go to the “filter table”, and if the query is flagged as potentially mali-
cious, subsequent 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 87
Protecting System Resources 88
Allowing Valid DNS Queries to Pass 88
More Information 88
Setting the Rate Limits

DNS RRL can be configured using the following CLI parameters:
l “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.
l “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.
87
l “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 window’s interval.
l The “rate-limit entry table” is for the offenders who have exceeded the rate limits con-
figured 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
following commands in the CLI Reference for ADC.
l “slb template dns” command updated with new “response-rate-limiting” option.

l “slb common” command updated with “dns-response-rate-limiting max-table-
entries” option.
l “show” command updated with new “response-rate-limiting entries” option.
88
Limitations
This release contains the following limitations for the DNS RRL feature:
l 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)

l 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 actu-
ally 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.

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

l 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.
l Dynamic changes to age setting are in effect only after the existing filter table entry
ages out.
l DNS RRL is not supported on service-partitions.
89
NOTE: The following limitations that existed in the previous

releases are now removed:
l DNS RRL was not supported on L3V partitions. DNS RRL is now supported on L3V par-
titions.
l If you configured slb template <name> response-rate-limiting without configuring
anything underneath it, then response-rate-limiting line was not appearing in the
output 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 90
Using the CLI to Configure and Monitor DNS RRL 91
Using the GUI to Configure DNS RRL
The DNS Response Rate Limiting (RRL) feature helps prevent network equipment (DNS
authoritative servers) from becoming unwanted participants in a DNS reflection or DNS amp-
lification 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:
90
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.
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
91
The following example shows the DNS response rate limiting entries returned by the show
command:
ACOS#show dns response-rate-limiting entries

Source Address FQDN Hit Count
-----------------------+-------------------------+----------
10.211.3.101 test4.example.com 4
Total Entries: 15
NOTE: For more information about these configuration and how to mon-
itor these commands, see the CLI Reference for ADC Guide.
92
Chapter 10: DNSSEC Support
This chapter describes the ACOS device’s DNSSEC support.
Overview of DNSSEC Support 94
Building the Chain of Trust 101
Dynamic Key Generation and Rollover 103
Hardware Security Module Support 107
DNSSEC Configuration 107
93
Chapter 10: DNSSEC Support Feedback
Overview of DNSSEC Support

Details 94
DNS without Security 95
DNSSEC (DNS with Security) 98
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:
l A
l AAAA
l CNAME
l NS
l MX
l PTR
l SRV
l 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 infrastructure 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.
94
This potential security hole makes DNS vulnerable to “man-in-the-middle” attacks, DNS
cache poisoning 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) intro-
duced a set of standards called Domain Name System Security Extensions (DNSSEC). These
additional standards 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 legit-
imate 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 DNS Packet Flow without DNSSEC illustrates basic DNS without DNSSEC. The figure
shows the recursive lookup process 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.
95
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.
96
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.
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.ex-
ample.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.example.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.
97
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 the process illus-
trated in the DNS Packet Flow without DNSSEC, but with the notable exception that DNSSEC
uses the following additional resource record types to provide security:
l DNS Key (DNSKEY) – Public key used by an Authoritative DNS server to sign resource
records for its zone.
l 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.
l 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
pointing to lower level servers in the DNS hierarchy to move the request closer to the author-
itative 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.
98
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 client 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.
99
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.ex-
ample.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.ex-
ample.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.
100
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.
18. To continue assembling the chain of trust, the Caching DNS server asks the Author-
itative 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 DNSSEC Chain of Trust illustrates how the Chain of Trust is built in the DNSSEC infra-
structure. 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.
101
FIGURE 10-3: DNSSEC Chain of Trust
The DNSSEC Chain of Trust 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.
102
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 recreated 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.ex-
ample.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 cli-
ent 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 104
Key Rollover and Distribution Process 104
Key Regeneration Log Messages 105
103
Importing/Exporting Key Files 106
Emergency Key Rollover 106
Changing Key Settings 107
Key Generation and Rollover Parameters
When HSM and DNSSEC are enabled, ACOS uses the following key generation and rollover set-
tings for DNSSEC:
l Key size – Length of the keys in bits. You can specify 1024-4096 bits. The default
length for ZSKs and KSKs is 2048 bits.
l Lifetime – Maximum amount of time a dynamically generated key remains valid.
l Rollover time – Amount of time to wait after a new key becomes active, before gen-
erating 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:
l ZSKs – The default lifetime is 7,776,000 seconds (90 days), and the default rollover time
is 7,171,200 seconds (83 days).
l 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 DNSSEC -
Default Rekey and Rollover 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
104
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
105
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.
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 parent zone. This part of the process must be performed
manually. If the default key generation and rollover settings
are used, this process 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 authoritative 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 neces-
sary. For example, to force an immediate ZSK rollover in emergency mode:
ACOS(config)# dnssec key-rollover zone1 ZSK start
106
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
Changing Key Settings
Use the zsk lifetime and ksk lifetime commands to change the lifetime and rollover set-
tings 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 man-
agement.
The current release supports a software emulation version of HSM in ACOS. Keys are gen-
erated and stored on the ACOS device. This version can be useful for testing or for envir-
onments 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 sup-
ported. For information about external HSM support, contact A10 Networks.
DNSSEC Configuration
Modes 108
DNSSEC Configuration Example 108
107
Modes
To configure DNSSEC, the following modes or options can be considered.
DNSSEC Configuration Example
Configuring an HSM Template 108
Configuring a DNSSEC Template 108
Configuring GSLB 109
Configuring a GSLB Policy and Enable Server Mode 112
Binding the DNSSEC Template to the Zone 112
Configuring DNSSEC Standalone 113
Configuring the VIP for DNSSEC Requests 113
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
108
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
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
109

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
110

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
111

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
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
112
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
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
113
Chapter 11: Location-Based VIP Access
Overview of Location-based VIP Access 115
Configuration Using a Class List 115
Configuration Using a Black/White List 117
Enabling Full-Domain Checking 121
Enabling PBSLB Statistics Counter Sharing 123
114
Chapter 11: Location-Based VIP Access Feedback
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:
l Drop the traffic

l Reset the connection
l 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 data-
base 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 sys-
tem 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 max-
imum number of concurrent connections allowed for clients in the geo-locations.
L US 1
L US.CA 2
L US.CA.SJ 3
115
The following commands import the class list to the ACOS device, configure a policy tem-
plate, and bind the template to a virtual port. The connection limits specified in the policy
template apply to clients 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
116
Success: 3
Geo-location M ID Permit Deny Conn Last
-------------------------------------------------------------------------------
-
US.CA.SJ v 3 1 1 1 77.1.1.107
-------------------------------------------------------------------------------
-
Total: 1
Configuration Using a Black/White List

Details 117
Configuring the Black/White List 118
Methods 118
Using the GUI 119
CLI Example 121
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 con-
figure 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.
117
Configuring the Black/White List
Methods 118
Using the GUI 119
CLI Example 121
Methods
You can configure black/white lists in one of the following ways:
l Remote – Use a text editor and import the list to the ACOS device.
l 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 con-
tains entries (rows) in the following format:
L "geo-location" group-id #conn-limit
The various parameters in the syntax are described in the Black/White List Syntax Descrip-
tion.
Black/White List Syntax Description
L Indicates that the client’s location will be determined by using inform-

ation 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.
118
#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
connection limit.
Below is a simple example of a Black/White list:
L "US" 1
L "US.CA" 2
L "JP" 3
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.
119
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.
4. Complete the Host and Location fields to specify the location of the file you are import-
ing.
5. Leave the Template fields blank.
6. Click Import.
NOTE: You can also import a custom geo-location database.
NOTE: For more information, 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.
120
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
To view SLB geo-location statistics, use the show slb geo-location command.
Enabling Full-Domain Checking

Details 122
Using the GUI to Configure Full-Domain Checking 123
Using the CLI to Configure Full-Domain Checking 123
121
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 spe-
cific geo-location level is not reached, the client’s connection is permitted. Similarly, the per-
mit counter is increased only for that specific geo-location level.
Geo-location connection limit example shows an example set of geo-location connection lim-
its and current connections.
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:
l US – Deny counter is increased by 1.

l US.CA – Permit counter is increased by 1.
l 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:
122
l US – Deny counter is incremented by 1.

l 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-
location 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.
Enabling PBSLB Statistics Counter Sharing

Details 124
Using the GUI to Enable PBSLB Statistics Counter Sharing 124
Using the CLI to Enable PBSLB Statistics Counter Sharing 124
123
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 serv-
ers and virtual ports that use the template:
l Permit
l Deny
l Connection number
l 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.
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.
124

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

Uploaded by

Copyright:

Available Formats

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

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

Uploaded by

Copyright:

Available Formats

ACOS 5.2.

Chapter 2: IP Anomaly Filtering 18

Chapter 3: Policy-based SLB 24

Chapter 4: SYN Cookies 39

SYN Flood Attacks 40

Class List Syntax 57

Chapter 6: ICMP Rate Limiting 73

ICMP Rate Limiting Parameters 74

Chapter 7: HTTP Slowloris Prevention 77

Chapter 8: DNS Application Firewall 79

Chapter 9: DNS Response Rate Limiting 84

Using the GUI to Configure DNS RRL 90

Chapter 10: DNSSEC Support 93

Chapter 11: Location-Based VIP Access 114

Using the GUI 119

The following topics are covered:

Application Access Management 11

Online Certificate Status Protocol 12

Attack Detection and Prevention using ZBAR 13

Single CPU Attack Prevention 14

ICMP Rate Limiting 15

Web Application Firewall 15

DNS Application Firewall 16

Geo-location-based VIP Access 17

Application Access Management

This following topics are covered:

Online Certificate Status Protocol (OCSP) 11

AAA Health Monitoring and Load Balancing 12

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

Attack Detection and Prevention using ZBAR

This solution employs the following infrastructure capabilities:

l Analytics infrastructure – It adaptively baselines multiple traffic metrics and creates a

l Packet capture infrastructure – It automatically captures a few packets from the

To enable this feature, refer to the following configuration:

l show visibility zbar dest

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 policy-based SLB, see Policy-based

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

ICMP Rate Limiting

Web Application Firewall

l Incoming user requests

NOTE: For more information about Slowloris prevention, see HTTP

DNS Application Firewall

NOTE: For more information about DNSSEC, see DNSSEC Support.

Geo-location-based VIP Access

l Drop the traffic

NOTE: For more information about Geo-location-based VIP access, see

The following topics are covered:

Overview of IP Anomaly Filtering 19

Configuring IP Anomaly Filtering 22

Displaying IP Anomaly Statistics 23

Overview of IP Anomaly Filtering

This following topics are covered:

IP Anomaly Filters for System-wide PBSLB 20