A10 2.7.2-P8 AAM DMG Jun14 2016

APPLICATION ACCESS MANAGEMENT AND DDoS MITIGATION GUIDE
A10 Thunder Series and AX Series

ACOS 2.7.2-P8
14 June 2016
© 2016 A10 Networks, Inc. Confidential and Proprietary - All Rights Reserved
Information in this document is subject to change without notice.
Patent Protection
A10 Networks products are protected by patents in the U.S. and elsewhere. The following website is provided to satisfy the virtual pat-
ent marking provisions of various jurisdictions including the virtual patent marking provisions of the America Invents Act. A10 Net-
works' products, including all Thunder Series products, are protected by one or more of U.S. patents and patents pending listed at:
https://www.a10networks.com/company/legal-notices/a10-virtual-patent-marking.
Trademarks
The A10 logo, A10 Harmony, A10 Lightning, A10 Networks, A10 Thunder, aCloud, ACOS, Affinity, aFleX, aFlow, aGalaxy, aGAPI, aVCS, AX,
aXAPI, IDsentrie, IP-to-ID, SSL Insight, SSLi, Thunder, Thunder TPS, UASG, and vThunder are trademarks or registered trademarks of A10
Networks, Inc. in the United States and other countries. All other trademarks are property of their respective owners.
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.
A10 Networks Inc. Software License and End User Agreement

Software for all A10 Networks products contains trade secrets of A10 Networks and its subsidiaries and Customer agrees to treat Soft-
ware as confidential information.
Anyone who uses the Software does so only in compliance with the terms of the End User License Agreement (EULA), provided later in
this document or available separately. Customer shall not:
1. reverse engineer, reverse compile, reverse de-assemble or otherwise translate the Software by any means
2. sublicense, rent or lease the Software.
Disclaimer
This document does not create any express or implied warranty about A10 Networks or about its products or services, including but not
limited to fitness for a particular use and non-infringement. A10 Networks has made reasonable efforts to verify that the information
contained herein is accurate, but A10 Networks 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 sub-
ject to change without notice, and certain features may not be available upon initial product release. Contact A10 Networks for current
information regarding its products or services. A10 Networks’ products and services are subject to A10 Networks’ standard terms and
conditions.
Environmental Considerations
Some electronic components may possibly contain dangerous substances. For information on specific component types, please con-
tact the manufacturer of that component. Always consult local authorities for regulations regarding proper disposal of electronic com-
ponents in your area.
Further Information
For additional information about A10 products, terms and conditions of delivery, and pricing, contact your nearest A10 Networks loca-
tion, which can be found by visiting www.a10networks.com.
Table of Contents
Introduction ................................................................................................................................................. 9
Application Access Management................................................................................................................. 9
Online Certificate Status Protocol ..............................................................................................................10
DDoS Mitigation ...............................................................................................................................................10
Policy-based SLB...............................................................................................................................................10
SYN Cookies........................................................................................................................................................10
IP Limiting ...........................................................................................................................................................11
ICMP Rate Limiting...........................................................................................................................................11
Web Application Firewall...............................................................................................................................11
Slowloris Prevention........................................................................................................................................11
DNS Application Firewall ...............................................................................................................................12
DNSSEC ................................................................................................................................................................12
SSL Insight...........................................................................................................................................................12
Geo-location-based VIP Access ...................................................................................................................12
Application Access Management .......................................................................................................13

AAM Security Solutions..................................................................................................................................13
Login Portal ........................................................................................................................................................14
Basic HTTP Login .....................................................................................................................................................................................14
Where To Find Deployment Examples .............................................................................................................................15
Form-based Login ..................................................................................................................................................................................15
Page Types Used by Form-based Login ..........................................................................................................................15
Finding Deployment Examples ............................................................................................................................................18
Authentication Relay.......................................................................................................................................19
Where To Find Deployment Examples .............................................................................................................................19
Authorization Based on a URI ......................................................................................................................19
Configuration Overview .....................................................................................................................................................................19
Configuring the ACOS Device ...............................................................................................................................................20
Configuring the RADIUS Server ............................................................................................................................................20
Configuring the LDAP Server .................................................................................................................................................20
AAM with LDAP .........................................................................................................................................23

Overview .............................................................................................................................................................23
Login Proxy .........................................................................................................................................................23
page 3 | Document No.: 272-P8-AAM-DMG-001 - 6/14/2016

A10 Thunder Series and AX Series—Application Access Management and DDoS Mitigation Guide
Contents
Configuration ............................................................................................................................................................................................26
Authentication Relay.......................................................................................................................................28
Configuration ............................................................................................................................................................................................29
AAM with RADIUS ....................................................................................................................................33

Basic HTTP Login with RADIUS....................................................................................................................33
Form-based Login with RADIUS..................................................................................................................35
Unsuccessful Login Messages ...............................................................................................................................................37
AAM with OCSP .........................................................................................................................................39

Overview .............................................................................................................................................................39
Certificate Verification Process .......................................................................................................................................................39
ACOS Verification of Replies from OCSP Responder .........................................................................................................39
OCSP—Single Server.......................................................................................................................................40
OCSP—Multiple Servers ................................................................................................................................41
AAM with Kerberos ..................................................................................................................................45

Overview .............................................................................................................................................................45
Basic HTTP Login .....................................................................................................................................................................................46
Form-based Login ..................................................................................................................................................................................47
OCSP ...............................................................................................................................................................................................................48
Authentication Relay with Kerberos ...........................................................................................................................................49
Configuration.....................................................................................................................................................49
Required Configuration Resources ..............................................................................................................................................49
Kerberos Terminology Related to AAM ....................................................................................................52
IP Anomaly Filtering ................................................................................................................................55

Overview .............................................................................................................................................................55
IP Anomaly Filters for System-Wide PBSLB .............................................................................................................................55
Notes ..............................................................................................................................................................................................................56
Configuration.....................................................................................................................................................57
Displaying IP Anomaly Statistics.................................................................................................................57
Policy-Based SLB .......................................................................................................................................59

Overview .............................................................................................................................................................59
Configuring a Black/White List ....................................................................................................................59
Example Black/White List ...................................................................................................................................................................60
Dynamic Black/White-list Client Entries ...................................................................................................................................61
Connection Limit for Dynamic Entries ......................................................................................................................................61
Aging of Dynamic Entries ..................................................................................................................................................................61
Wildcard Address Support in PBSLB Policies Bound to Virtual Ports ......................................................................62
Document No.: 272-P8-AAM-DMG-001 - 6/14/2016 | page 4

Contents
Configuring System-Wide PBSLB................................................................................................................62

Displaying and Clearing System-Wide PBSLB Information ...........................................................................................63
Configuring PBSLB for Individual Virtual Ports......................................................................................64
Displaying PBSLB Information .....................................................................................................................69
Configuration Examples.................................................................................................................................70
Example—Sockstress Attack Protection..................................................................................................71
System-wide PBSLB Policy Configuration ................................................................................................................................71
Statistics Display .............................................................................................................................................................................71
SYN Cookies ...............................................................................................................................................75

Overview .............................................................................................................................................................75
SYN Flood Attacks ..................................................................................................................................................................................75
Identifying SYN Flood Attacks .........................................................................................................................................................75
ACOS SYN-cookie Protection ..........................................................................................................................................................76
Dynamic SYN Cookies ..........................................................................................................................................................................77
SYN Cookie Buffering ...........................................................................................................................................................................78
SACK and MSS with Software-based SYN-cookies ............................................................................................................78
SACK ......................................................................................................................................................................................................78
MSS .........................................................................................................................................................................................................78
Configuration.....................................................................................................................................................79
Enabling SYN-cookie Support ........................................................................................................................................................79
Configuration with Target VIP and Client-side Router in Different Subnets ......................................................80
Configuring Layer 2/3 SYN Cookie Support for Data Interfaces ...............................................................................81
Configuring SYN-cookie Buffering ...............................................................................................................................................82
Displaying SYN-cookie Statistics.................................................................................................................83
Using the GUI ............................................................................................................................................................................................83
Using the CLI .............................................................................................................................................................................................83
CLI Example 1: Attack Prevention Statistics ...................................................................................................................84
CLI Example 2: SYN Attack Counter ...................................................................................................................................85
CLI Example 3: Legitimate Session Counter .................................................................................................................85
CLI Example 4: SYN-cookie Buffering Statistics ...........................................................................................................85
SYN Attack Counter Support for L3V ..........................................................................................................................................86
IP Limiting ...................................................................................................................................................87
Overview .............................................................................................................................................................87
Class Lists .....................................................................................................................................................................................................87
Class List syntax ..............................................................................................................................................................................87
IP Address Matching ....................................................................................................................................................................88
Example Class Lists .......................................................................................................................................................................89
IP Limiting Rules ......................................................................................................................................................................................89
Match IP Address ...........................................................................................................................................................................90
Request Limiting and Request-rate Limiting in Class Lists ..................................................................................91

Contents
CLI Examples Using Request and Request-Rate Limiting ....................................................................................91

CLI Examples Not Using Request and Request-rate Limiting ............................................................................92
Configuring Source IP Limiting ............................................................................................................................................93
Configuring a Class List .......................................................................................................................................................................94
Using the GUI ...................................................................................................................................................................................94
Using the CLI ....................................................................................................................................................................................95
Configuring the IP Limiting Rules .................................................................................................................................................97
Using the GUI ...................................................................................................................................................................................97
Using the CLI ....................................................................................................................................................................................98
Applying Source IP Limits ...............................................................................................................................................................100
Using the GUI ................................................................................................................................................................................100
Using the CLI .................................................................................................................................................................................101
Displaying IP Limiting Information ...........................................................................................................................................101
Using the GUI ................................................................................................................................................................................101
Using the CLI .................................................................................................................................................................................101
CLI Examples—Configuration .....................................................................................................................................................102
Configure System-Wide IP Limiting With a Single Class ....................................................................................102
Configure System-Wide IP Limiting With Multiple Classes ..............................................................................102
Configure IP Limiting on a Virtual Server ....................................................................................................................103
Configure IP Limiting on a Virtual Port .........................................................................................................................104
Configure Class List Entries That Age Out ...................................................................................................................104
CLI Examples—Display ....................................................................................................................................................................105
Class Lists .........................................................................................................................................................................................105
IP Limiting Rules ..........................................................................................................................................................................106
IP Limiting Statistics ..................................................................................................................................................................107
ICMP Rate Limiting ............................................................................................................................... 109

Configuration.................................................................................................................................................. 109
ICMP Rate Limiting Parameters ...................................................................................................................................................109
Using the GUI .........................................................................................................................................................................................110
Using the CLI ..........................................................................................................................................................................................111
HTTP Slowloris Prevention ................................................................................................................. 113

Request Packet Size ...................................................................................................................................... 113
Request Header Timeout............................................................................................................................ 113
DNS Application Firewall .................................................................................................................... 115

DNS Sanity Check .......................................................................................................................................... 115
Sanity Checking for Virtual-Port Type UDP ................................................................................................................115
Sanity Checking for Virtual-Port Type DNS-UDP .....................................................................................................116
Configuration.................................................................................................................................................. 116
Configuration Examples.............................................................................................................................. 117
DNS Application Firewall Setup ..................................................................................................................................................117

Contents
Service-Group Redirection for DNS “Any” Requests (using aFleX) ........................................................................118
DNSSEC Support .................................................................................................................................... 119

Overview .......................................................................................................................................................... 119
DNS Without Security .......................................................................................................................................................................120
DNSSEC (DNS with Security) .........................................................................................................................................................121
Building the Chain of Trust ............................................................................................................................................................123
Dynamic Key Generation and Rollover ..................................................................................................................................125
Key Generation and Rollover Parameters ....................................................................................................................125
Importing/Exporting Key Files ...........................................................................................................................................127
Emergency Key Rollover ........................................................................................................................................................127
Changing Key Settings ...........................................................................................................................................................127
Hardware Security Module Support ........................................................................................................................................128
Configuration .........................................................................................................................................................................................128
Standalone Operation ......................................................................................................................................................................130
Configuration Example ....................................................................................................................................................................130
Location-Based VIP Access ................................................................................................................. 135

Overview of Location-Based VIP Access................................................................................................ 135
Configuration Using a Class List............................................................................................................... 136
Configuration Using a Black/White List................................................................................................. 137
Configuring the Black/White List ...............................................................................................................................................137
Using the GUI to Configure a Black/White List ........................................................................................................138
Using the CLI to Import a Black/White List .................................................................................................................140
Full-Domain Checking ................................................................................................................................. 141
Enabling PBSLB Statistics Counter Sharing ..........................................................................................................................142

Contents

Introduction
ACOS provides a suite of security features that allow you to protect your customer traffic
Application Access Management

Application Access Management (AAM) is an ACOS security feature that optimizes Authentication, Authorization, and
Accounting (AAA) for client-server traffic.
AAM includes the following features:
• Login Portal – Provides a sign-on interface. By using a request-reply exchange or using a Web-based form, ACOS
obtains the your credentials and uses a backend AAA server to verify these credentials.
• Online Certificate Status Protocol (OCSP) – Provides certificate verification services and eliminates the need to import
certificate revocation list (CRL) files to the ACOS device.
The CRLs are maintained on the OCSP responder (server). When a client sends its certificate as part of a request for a
secured service, ACOS first sends the certificate to the OCSP responder for 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.
• 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.
More Information
For more information about AAM, see the following chapters:
• “Application Access Management” on page 13
• “AAM with LDAP” on page 23
• “AAM with RADIUS” on page 33
• “AAM with OCSP” on page 39
• “AAM with Kerberos” on page 45

Online Certificate Status Protocol
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 (gen-
erally called responders). This process only occurs when a client sends a certificate as part of a request to set up a secure ses-
sion to a server application that is managed by ACOS.
For more information about OSCP, see “AAM with OCSP” on page 39.
DDoS Mitigation
Distributed Denial of Service (DDoS) is a type of DoS attack where multiple systems that are infected with a Trojan or mal-
ware are, in turn, used to target a particular system. This process causes a denial of service. If a hacker (attacker) mounts an
attack from one host, this is classified as a DoS attack. In a DDoS attack, many systems are used simultaneously to launch
attacks against a remote system.
ACOS includes filters that check traffic for IP anomalies that can indicate a DDoS attack.
For more information about DDos Mitigation, see “IP Anomaly Filtering” on page 55.
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.
For more information about policy-based SLB, see “Policy-Based SLB” on page 59.
SYN Cookies
SYN cookies provide protection against a common type of DDoS attack, the TCP SYN flood attack. The attacker sends a high
volume of TCP-SYN requests to the target device, but the attacker does not reply to SYN-ACKs to complete the three-way
handshake for any of the sessions. The purpose of the attack is to consume the target’s resources with half-open TCP ses-
sions.
When SYN cookies are enabled, the ACOS device can continue to serve legitimate clients during TCP SYN flood attacks, while
preventing illegitimate traffic from consuming system resources.
For more information about SYN cookies, see “SYN Cookies” on page 75.

IP Limiting
IP Limiting
IP limiting provides a enhanced implementation of the source IP connection limiting and connection-rate limiting feature
that was available in earlier releases.
For more information about IP limiting, see “IP Limiting” on page 87.
ICMP Rate Limiting

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

ACOS provides additional security for your Web servers with the Web Application Firewall (WAF) feature. WAF filters commu-
nication between end-users and Web applications to protect Web servers and sites from unauthorized access and malicious
programs.
This new layer of security examines the following types of traffic to safeguard against Web attacks and protect sensitive infor-
mation hosted on Web servers:
• Incoming user requests
• Output from Web servers
• Access to Web site content
Fore more information about WAF, see the Web Application Firewall Guide.
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.
For more information about Slowloris prevention, see “HTTP Slowloris Prevention” on page 113.

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.
For more information about DAF, see “DNS Application Firewall” on page 115.
DNSSEC
ACOS supports DNS Security Extensions (DNSSEC). In Global Server Load Balancing (GSLB) deployments, you can use DNS-
SEC with Hardware Module Security (HSM) to dynamically secure DNS resource records for GSLB zones.
For more information about DNSSEC, see “DNSSEC Support” on page 119.
NOTE: 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.
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.
For more information about SSL Insight, see “SSL Insight” in the Application Delivery and Server Load Balancing Guide.
Geo-location-based VIP Access

Geo-location-based VIP access controls the access to a VIP based on the client’s location. You can configure ACOS to perform
one of the following actions for traffic from a client, depending on the location of the client:
• Drop the traffic
• Reset the connection
• If configured by using a black/white list, send the traffic to a specific service group
ACOS determines a client’s location by looking up the client’s subnet in the geo-location database that is used by Global
Server Load Balancing (GSLB).
For more information about Geo-location-based VIP access, see “Location-Based VIP Access” on page 135.

Application Access Management
This chapter helps you understand Application Access Management (AAM).
AAM Security Solutions

You can use AAM for multiple AAA optimization solutions, and Figure 1 illustrates a high-level example.
FIGURE 1 Service Access Management example
In this example, Authentication Relay, Login Portal, and AAA health monitoring and load balancing are used together.

Login Portal
Traffic Walkthrough
Figure 1 illustrates the following traffic exchange that is initiated by a client. In this exchange, an HTTP request is sent to a
server that is managed by ACOS.
1. A client sends an HTTP request to a VIP that is managed by ACOS.
2. The Login Portal on the ACOS device intercepts the request and sends a login page to the client.
3. The client sends the username and password to ACOS.
4. Authentication Relay forwards the request to an external AAA server.
If a service group of AAA servers is configured, the group’s load-balancing method is used to select a AAA server, and
the request is forwarded to the selected AAA server.
5. Authentication Relay receives the reply.
6. If the client is successfully authenticated, ACOS SLB selects a content server for the request, and forwards the request to
the server.
7. The server sends the reply to ACOS.
8. ACOS creates a cookie, which indicates that the client was successfully authenticated.
Each subsequent request from the client should contain this cookie in the HTTP request header.
Login Portal
The Login Portal provides an interface in which end-users can log in or complete tasks such as changing a passwords.
The Login Portal provides the following ways to collect end-user credentials:
• Basic HTTP – The Login Portal sends an HTTP 401 (Unauthorized) message with response code 4, which contains a
WWW-Authenticate HTTP header. The client browser is expected to send a reply with the Authorization header,
which contains the username and password in Base64-encoded form.
• Form-based – The Login Portal uses a set of web pages to collect end-user credentials.
In both portal types, for authentication, ACOS sends the credentials from the end-user to a backend AAA server.
NOTE: For LDAP, you can change your password by using the Login Portal. For more informa-
tion about AMM and LDAP, see “AAM with LDAP” on page 23.
Basic HTTP Login

Basic HTTP login allows ACOS to obtain a username and password by sending an HTTP 401 (Not Authorized) message with
response code 4.
The following text is an example of the Authentication header that might be in the message:

Login Portal
WWW-Authenticate: Basic realm=”realm-name”
The client browser is expected to display a login dialog. After end-users enter their credentials, the client browser is expected
to send an HTTP reply that includes the following header, which contains the username and password in Base64-encoded
form:
Authorization: Basic QTEwOlRodW5kZXI=
Where To Find Deployment Examples

For deployment examples, see the following sections:
• “Basic HTTP Login with RADIUS” on page 33
Form-based Login
A form-based portal uses a set of Web pages that contain data forms. End-users log in and change their passwords by enter-
ing data into these forms.
Page Types Used by Form-based Login

The following types of pages are supported for form-based login.
TABLE 1 Pages for the Login Portal

Page Type Description
Login Sent by ACOS to client in response for request to secure services.
Login Failure Sent by ACOS to client if authentication fails.
Password Change Sent by ACOS to client to allow password change, if client password is found on LDAP server but is
expired.
The files for the pages must be imported onto the ACOS device. You can import the files in archive files by using the zip, tgz,
or tar file formats.
By default, ACOS does not include Login Portal Web pages, but here are some examples of simple pages.
Example Login Page
Figure 2 shows an example of a simple login page.

Login Portal
FIGURE 2 Login page (example)
Figure 3 shows the source code for the page.
FIGURE 3 Login page source (example)
Example Login Failure Page
Figure 4 shows an example of a deny page that is sent to the client when the end-user enters invalid credentials.

Login Portal
FIGURE 4 Login failure page (example)
FIGURE 5 Login failure page source (example)
Example Password Change Page
Figure 6 shows an example of password-change page, which is sent to the client when the username is valid, but the pass-
word has expired.

Login Portal
FIGURE 6 Password change page (example)
FIGURE 7 Password change page source (example)
Finding Deployment Examples

For examples of AAM deployments that use form-based login, see the following sections:
• “Form-based Login with RADIUS” on page 35

Authentication Relay
• “AAM with Kerberos” on page 45
Authentication Relay provides backend login service on behalf of authenticated clients.
ACOS uses backend AAA servers to authenticate a client’s initial request. If authentication is successful, ACOS logs into load-
balanced services for which the client is authorized, when those services are requested by the client. The end-user does not
need to enter their credentials again.
Where To Find Deployment Examples

For more information and deployment examples, see “Authentication Relay” on page 28
Authorization Based on a URI

You can add more granular authorization control to an AAM deployment with authorization that is based on a URI. This addi-
tional level of control also specifies the URIs that an end-user can access.
NOTE: The current release supports this feature for RADIUS and LDAP.
URI Access List
In this solution, end-users can access the following URI:
ACOS-device/partition/VIP/portnum/service-type
For example, an end-user might be allowed access only a specific service on a VIP load balanced by a pair of ACOS devices in
partition p1. In this case, the AAA server might have the following entries:
ACOS1/p1/10.2.4.69/80/http
ACOS2/p1/10.2.4.69/80/http
The actual syntax for the entries depends on the AAA server type (described below).
Configuration Overview
To deploy this feature, you must complete some configuration on the ACOS device and on the AAA server.

Configuring the ACOS Device

On the ACOS device, you must enable the authorization-check option in the authentication-server profile for the AAA server.
When this option is enabled, ACOS requests the end-user’s URI list from the AAA server. If the end-user is authenticated,
ACOS allows access only if the URI that is requested by the end-user is in the list that is provided by the AAA server.
Configuring the RADIUS Server

To configure your RADIUS server for URI-based authorization:
1. Edit the /etc/raddb/users file. An example of a users file:

user1 Cleartext-Password := "a10"
User-Name = "user1",
A10-AX-AUTH-URI = ACOS//vs1/80/http
user2 Cleartext-Password := "a10"
User-Name = "user2",
A10-AX-AUTH-URI = ACOS/l3v/vs1/80/http
2. Add a dictionary.a10 file and include the following attribute: A10-AX-AUTH-URI
3. Add the dictionary file in RADIUS dictionary file. Edit /etc/raddb/dictionary and add the following:
$INCLUDE /etc/raddb/dictionary.a10
4. Add the permitted URI list to each end-user account.
Below is an example of a dictionary.a10 file that contains the attribute for URI-based authorization.
# A10-Networks dictionary
# Created by Software Tools of A10 Networks.
#
VENDOR A10-Networks 22610
BEGIN-VENDOR A10-Networks
ATTRIBUTE A10-AX-AUTH-URI 6 string
END-VENDOR A10-Networks
Configuring the LDAP Server

To configure your LDAP server for URI-based authorization:
1. Copy the a10auth.schema file to the following directory:

/etc/openldap/schema
2. To include the a10auth.schema, edit the following file:

/etc/openldap/slapd.conf
For example:
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
…
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
include /etc/openldap/schema/a10.schema
include /etc/openldap/schema/a10auth.schema
3. Add a new LDAP user to include an A10-AX-AUTH-URI list,
For example:
a. Add the following line to the ldif file:

A10-AX-AUTH-URI: AX103//Avip20/80/http
b. Save the ldif file as user.ldif.
c. Enter the following command to add the new LDAP user:

ldapadd –x –D “cn=Manager,dc=example,dc=com” –W –f “user.ldif”
a10auth.schema
Here is the a10auth.schema file.
# a10auth.schema
#
# This is the ldif version of a10auth.schema to be used with cn=config.
#
AttributeType ( 1.3.6.1.4.1.22610.2.1.1
NAME 'A10-AX-AUTH-URI'
DESC 'A10-AX-AUTH-URI: ax-serial-number [a10-partition-name [a10-vip-name
[a10-vport]]]'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# This is the ldif version of a10auth.schema to be used with cn=config.

#
ObjectClass ( 1.3.6.1.4.1.22610.2.2.1 NAME 'a10UserAuth'

DESC 'a10 user authentication'

SUP top AUXILIARY MAY A10-AX-AUTH-URI )
LDIF Example:
# extended LDIF
#
# LDAPv3
# base <dc=example, dc=com> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# ldap1, User, ywang.com
dn: cn=ldap1,ou=User,dc=example,dc=com
uid: ldap1
cn:ldap1
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: a10UserAuth
sn: a10
userPassword: password_l3v
A10-AX-AUTH-URI: AX103//Avip20/80/http

AAM with LDAP
ACOS supports password update for end-users whose accounts are managed in a Lightweight Directory Access Protocol
(LDAP) database. LDAP password update is one of the solutions provided by the Application Access Management (AAM) fea-
ture suite.
Overview
The AAM Authentication Proxy features can use Basic-HTTP authentication or web-based forms to obtain end-user creden-
tials, and query backend LDAP servers to verify the credentials. If a valid end-user’s password has expired, the Login Proxy
enables the end-user to change their password and regain access.
Clients do not need to understand LDAP. Instead, when a client sends a request to a VIP for a secured service, ACOS uses
Basic-HTTP authentication or a web form to obtain end-user credentials. ACOS then sends the credentials to an LDAP server
for verification.
• If the client is authenticated by the LDAP server, ACOS allows the client to access the requested service.
• If the LDAP server returns an error message instead, ACOS does not immediately deny the end-user’s request. Instead,
ACOS logs onto the LDAP server as an account administrator. ACOS queries the account database for the password
entered by the end-user, and the password’s expiration. ACOS uses this information to determine whether the pass-
word, although currently invalid, used to ba valid but has expired.
• If the password is valid but has expired, ACOS sends a web form to the end-user, to allow them to change the pass-
word.
• If the password is invalid, ACOS denies the request.
The following sections describe some AAM solutions for LDAP:
• “Login Proxy” on page 23
• “Authentication Relay” on page 28
Login Proxy
To obtain end-user credentials, the login proxy supports both formed based and http-basic authentication. The credentials
are verified by using a backend LDAP server.
The typical login name credential is used as the first value of the distinguished name (DN). By default, the first attribute of the
DN is the Common Name (CN). The end-user object’s full DN is constructed by prepending the base DN to the first attribute.
Because the end-user object’s CN might not correspond to the login name that is used in Active Directory (AD), the following
alternate LDAP bin login names are also accepted:

Login Proxy
• username@domain.com
• Domain\username
When an end-user enters a username in one of these formats, ACOS accepts and uses this format instead of the bind DN
form.
Figure 8 shows an example deployment of this solution.
FIGURE 8 Form-based login with LDAP
Traffic Walkthrough (Valid Username and Password)
1. Client sends an initial HTTP request to VIP.
2. ACOS replies with a form that contains the username and password fields.
3. Client browser displays the form and end-users enter their username and password.
4. ACOS extracts the username and password from the form and sends the credentials to the LDAP server in a Search
request.
5. The LDAP server replies.
In this example, the username and password exist in the LDAP server’s user database.
ACOS caches the reply, so that the cached verification of credentials can be used for the next request from the same
end-user.
6. ACOS uses SLB to select a server from the Web-server service group, and sends the client’s HTTP request to the server.
(This example assumes SLB is used.)

Login Proxy
7. The server replies.
In this example, the server has the requested content and sends it in the reply.
8. ACOS forwards the server reply to the client.
Traffic Walkthrough (Valid Username and Expired Password)
This example shows the traffic flow when the username that is entered by an end-user is valid, but the password has
expired.
FIGURE 9 Form-based logon with LDAP (change password)
1. Client sends initial HTTP request to VIP.
2. ACOS replies with a form containing input fields for the end-user credentials (username and password).
3. Client browser displays the form, into which the end-user enters their username and password.
4. ACOS extracts the username and password from the form, and sends them to the LDAP server in a Search request.
5. The LDAP server finds an entry for the username and password but the password has expired.
6. ACOS sends another form to the client. The form contains input fields to change the password.
7. End-user fills in the form with their username, and old and new passwords.
8. ACOS sends the updated password to the LDAP server.
9. Now that the client is authenticated, ACOS uses SLB to select a server, then sends the client’s HTTP request to the
server.

Login Proxy
10. The server replies. In this example, the server has the requested content and sends it in the reply.
11. ACOS caches the credential verification from the LDAP server, and forwards the server reply to the client.
Configuration
Required Configuration Resources
The deployment requires the following resources:
• Zip archive of the web portal files required for end-user logon
• Logon-portal profile
• Authentication-server profile for the backend LDAP server
• Health monitor, server configuration, and service group for the backend LDAP server
• Authentication template containing the service group for the authentication server, and the authentication-logon
profile
• Server configuration and service group for the application server
• VIP configuration
CLI Example
The following commands import the logon-portal files onto the ACOS device:
ACOS(config)#import auth-portal portal.zip use-mgmt-port sftp:

Address or name of remote host []?fileserver1
User name []?admin1
Password []?********
File name [/]?portal.zip
...
The following commands configure the logon-portal profile.
ACOS(config)#authentication-logon form-based f1
ACOS(config-form-based authentication lo...)#portal portal.zip logon form.html failpage
error.html changepasswordpage changeform.html
ACOS(config-form-based authentication lo...)#action-url /mylogon.fo
ACOS(config-form-based authentication lo...)#username-variable username
ACOS(config-form-based authentication lo...)#password-variable pwd
The following commands create an authentication-server profile for the LDAP server:
ACOS(config-form-based authentication lo...)#authentication-server ldap l1

ACOS(config-ldap server)#host 172.16.2.10

Login Proxy
ACOS(config-ldap server)#base cn=Users,dc=umin,dc=com
The following commands configure an LDAP health monitor:
ACOS(config-ldap server)#exit
ACOS(config)#health monitor ldap-sr
ACOS(config-health:monitor)#method ldap run-search BaseDN dc=a10networks,dc=com query
(objectclass=*) AcceptNotFound
The following commands create an SLB server configuration for the LDAP server, and add it to a service group.
ACOS(config-health:monitor)#slb server ldap-sr 172.16.2.10

ACOS(config-real server)#port 389 tcp
ACOS(config-real server-node port)#health-check ldap-sr
ACOS(config-real server-node port)#authentication-server l1
ACOS(config-real server-node port)#slb service-group sg tcp
ACOS(config-slb svc group)#member ldap-sr:389
The following commands configure the authentication template:
ACOS(config-slb svc group)#slb template authentication t1

ACOS(config-authentication template)#logon f1
ACOS(config-authentication template)#service-group sg
The service-group command binds the template to the service group for the LDAP server. If the configuration did not
use a health monitor, server configuration, and service group for LDAP health checking, the server command would be
used instead, to bind the authentication template directly to the authentication-server profile.
The following commands add the SLB configuration.
ACOS(config-authentication template)#slb server rs_http 10.1.2.10

ACOS(config-real server-node port)#no health-check
ACOS(config-real server-node port)#slb service-group http_g_1 tcp
ACOS(config-slb svc group)#member rs_http:80
ACOS(config-slb svc group)#slb virtual-server vip_auth 10.1.2.159
ACOS(config-slb vserver)#port 80 http
ACOS(config-slb vserver-vport)#service-group http_g_1
ACOS(config-slb vserver-vport)#template authentication t1

This AAM solution uses a backend LDAP server to verify an end-user’s credentials when they first log on, then reuses those
credentials to log onto load-balanced content servers on behalf of that end-user.
In this deployment, the content servers do not need to understand LDAP. Instead, Basic-HTTP authentication is used
between ACOS and the servers.
Figure 10 shows an example.
FIGURE 10 Form-based logon with LDAP and Authentication Relay
Traffic Walkthrough (Username and Password Valid)
1. Client sends initial HTTP request to VIP.
2. ACOS replies with a form containing input fields for the end-user credentials (username and password).
3. Client browser displays the form, into which the end-user enters their username and password.
4. ACOS extracts the username and password from the form, and sends them to the LDAP server in a Search request.
5. The LDAP server replies. In this example, the username and password are present in the LDAP server’s user database.
6. ACOS uses SLB to select a server, then sends the client’s HTTP request to the server.
7. The server replies with an HTTP 401 (Not Authorized) message with response code 4, containing an Authentication
header such as the following:

8. ACOS sends an HTTP reply that includes the username and password, in Base64-encoded form, in an Authorization
header:
Authorization: Basic QTEwOlRodW5kZXI=
9. If the username and password are valid, the server replies with the requested content.
10. ACOS caches the credential verification from the LDAP server, and forwards the server reply to the client.
Configuration
• Zip archive of the web portal files required for end-user login
• Login-portal profile
• Authentication-server profile for the backend LDAP server
• Health monitor, server configuration, and service group for the backend LDAP server
• Authentication-logon profile for form-based collection of end-user credentials
• Authentication-relay profile for sending end-user credentials to content servers
• Authentication template containing the authentication-server profile and authentication-login profile
• Server configuration and service group for the application server
• VIP configuration
CLI Example
The following commands import the login-portal files onto the ACOS device:

User name []?admin1
...
The following commands configure the logon-portal profile. This is the same logon-portal profile used in “Login Proxy” on
page 23.

The following commands create an authentication-server profile for the LDAP server:
ACOS(config-form-based authentication lo...)#authentication-server ldap l1

ACOS(config-ldap server)#host 172.16.2.10
ACOS(config-ldap server)#base cn=Users,dc=umin,dc=com
The following commands create the SLB configuration for the LDAP server. This is the same configuration used in “Login
Proxy” on page 23.
ACOS(config-ldap server)#exit
ACOS(config)#health monitor ldap-sr
ACOS(config-health:monitor)#method ldap run-search BaseDN dc=a10networks,dc=com query
(objectclass=*) AcceptNotFound
ACOS(config-health:monitor)#slb server ldap-sr 172.16.2.10
ACOS(config-real server-node port)#health-check ldap-sr
ACOS(config-real server-node port)#authentication-server l1
ACOS(config-real server-node port)#slb service-group sg tcp
ACOS(config-slb svc group)#member ldap-sr:389
The following commands configure the logon-portal profile:
The following command creates an HTTP-basic logon profile, and specify the AAA realm name:
ACOS(config-form-based authentication lo...)#authentication-relay http-basic r1

ACOS(config-http basic authentication lo...)#realm example-realm
ACOS(config-http basic authentication re...)#slb template authentication t1

ACOS(config-authentication template)#service-group sg
ACOS(config-authentication template)#relay r1

The following commands add the SLB configuration. This is the same configuration used in the other AAM examples in this
chapter.



AAM with RADIUS
This chapter provides some examples of RADIUS AAA solutions that use Application Access Management (AAM) features. For
examples that use Basic HTTP logon and form-based logon, see the following sections:
• “Basic HTTP Login with RADIUS” on page 33
• “Form-based Login with RADIUS” on page 35
Basic HTTP Login with RADIUS

This solution uses a RADIUS server to verify end-user credentials before allowing access to a web server.
ACOS uses basic HTTP login to obtain the username and password from the client and sends these credentials to the back-
end RADIUS server for verification.
Figure 11 shows an example deployment of this solution.
FIGURE 11 Basic HTTP login with RADIUS
This example illustrates the successful authentication of a client request.

Basic HTTP Login with RADIUS
Traffic Walkthrough
1. The client sends an initial HTTP request to the VIP.
2. ACOS replies with an HTTP 401 (Not Authorized) message with response code 4, which contains an Authentication
header. The following text is an example of this header:
3. The client browser displays the login dialog to the end-user.
4. The end-user enters their credentials.
5. The client browser encodes the credentials in the Base64 format and sends them to ACOS.
6. ACOS decodes the username and password and sends the credentials to the RADIUS server in an Access-Request mes-
sage.
7. The RADIUS server replies.
In this example, the username and password are present in the RADIUS server’s user database. The RADIUS server
responds with an Access-Accept message.
ACOS caches the reply, so that the cached verification of credentials can be used again for the next request from the
same end-user.
8. ACOS uses SLB to select a server from the web-server service group and then sends the client’s HTTP request to the
server.
This example assumes that SLB is used.
In this example, the server has the requested content and sends the content in the reply.
The deployment in this example requires the following resources:
• An authentication-server profile for the backend RADIUS server
• An authentication-login profile for Basic HTTP login
• An authentication template containing the authentication-server profile and authentication-login profile
• A server configuration and a service group for the application server
• A VIP configuration
CLI Example
The following commands create an authentication-server profile for the RADIUS server:
ACOS(config)#authentication-server radius radius_server

ACOS(config-radius server)#host 172.16.2.10
ACOS(config-radius server)#secret a10networks

Form-based Login with RADIUS
The following command creates a Basic HTTP login profile, and specifies the AAA realm name:
ACOS(config-radius server)#authentication-logon http-basic httpbasic

ACOS(config-http basic authentication lo...)#realm example-realm
The following commands create the authentication template that will be used by the virtual port. The RADIUS server config-
uration and basic-HTTP authentication-login profile are added to the authentication template.
ACOS(config-http basic authentication lo...)#slb template authentication t1

ACOS(config-authentication template)#server radius_server
ACOS(config-authentication template)#logon httpbasic
The following commands create a server configuration for the web server to which clients will send requests and add the
server to a service group. The server configuration is then added to a service group.

The following commands configure the VIP:


This solution is similar to the one in “Basic HTTP Login with RADIUS” on page 33, except form-based login is used instead of
basic-HTTP login.

FIGURE 12 Form-based login with RADIUS
This example shows successful authentication of a client request. All steps except 2 and 3 are the same as those in “Basic
HTTP Login with RADIUS” on page 33.
Traffic Walkthrough
1. The client sends an initial HTTP request to the VIP.
2. ACOS replies with a form that contains the input fields for the end-user username and password.
3. The client browser displays the form, into which the end-user enters their credentials.
4. ACOS extracts the credentials from the form and sends this information to the RADIUS server in an Access-Request mes-
sage.
5. The RADIUS server replies.
In this example, the username and password are present in the RADIUS server’s user database. The RADIUS server
responds with an Access-Accept message.
ACOS caches the reply, so that the cached verification of credentials can be used again for the next request from the
same end-user.
6. ACOS uses SLB to select a server from the web-server service group and sends the client’s HTTP request to the server.
This example assumes that SLB is used.
In this example, the server has the requested content and sends this content in the reply.

Unsuccessful Login Messages

If a previous login attempt failed, when you try to log in again, the Logon form includes a customizable error message,
instead of just the username and password fields.
The error page that is returned by ACOS displays entry fields so that the end-user can enter their username and password
again.
Source Code Example
The following text is an example of the source code for the error page:
<form name="logon" action="mylogon-aaa.fo" method="POST">


Username: <input type="text" name="username"><br>
Password: <input type="password" name="pwd">
<input type="submit" value="Submit">
</form>
If the $a10_login_fail_errmsg$ variable is used, but is commented out as shown above, ACOS includes the login failure
message in the form only when applicable. If a client login failure occurs, to make the message visible on the new login page
that is displayed to the client, ACOS inserts a message and negates the HTML comment in the form that is sent to the client.
The default error message string for login failures is “Invalid username or password. Please try again.” You can customize the
string by using a range of 1-127 characters.
To customize the generic message string from the configuration level for the form-based authentication-login profile, enter
the [no] login-failure-message message-string command.
• A Zip archive of the web portal files that are required for end-user login
• A Login-portal profile
• An authentication template that contains the authentication-server profile and login-portal profile
• A Server configuration and a service group for the application server
CLI Example
The following commands import the login-portal files to the ACOS device:


User name []?admin1

...
The following commands configure the login-portal profile:
The following commands create an authentication-server profile for the RADIUS server:
ACOS(config-form-based authentication lo...)#authentication-server radius radius_server

ACOS(config-radius server)#secret a10networks
This is the same authentication-server profile used in “Basic HTTP Login with RADIUS” on page 33.
ACOS(config-form-based authentication lo...)#slb template authentication t1

ACOS(config-authentication template)#server radius_server
The following commands add the SLB configuration. This is the same server, service-group, and VIP configuration that were
used in “Basic HTTP Login with RADIUS” on page 33.


AAM with OCSP
Online Certificate Status Protocol (OCSP) is a network component that provides certificate verification services.
This chapter includes the following deployment examples:
• “OCSP—Single Server” on page 40
• “OCSP—Multiple Servers” on page 41
Overview
You can use OCSP to verify client certificates for access to an HTTPS virtual port. ACOS uses OCSP to authenticate the client,
instead of a certificate revocation list (CRL) that is imported to the ACOS device. When this feature is configured, the ACOS
device acts as an authentication client in relation to the OCSP responder (server).
Certificate Verification Process

You can configure ACOS to use external OCSP responders to verify client certificates. When OCSP support is configured,
ACOS verifies client certificates in the following way:
1. When a client sends a request to set up an SSL session, ACOS sends the certificate sent by the client to an OCSP
responder for validation.
If the responder is a member of a service group, ACOS first uses the configured load-balancing method to select a
responder and sends the request to that responder.
2. The OCSP responder checks its CRL database to determine whether the certificate is valid or has been revoked.
3. The responder sends the verification result to ACOS.
4. ACOS caches the response in one of the following ways:
• If the certificate is valid, ACOS completes the SSL session setup with the client.
• If the certificate is invalid, ACOS does not complete the SSL handshake with the client.
ACOS Verification of Replies from OCSP Responder

As part of the session setup with the OCSP responder, ACOS receives a copy of the responder’s own certificate. To verify the
identity of the responder, ACOS checks the responder’s certificate.
To check the OCSP responder’s certificate, ACOS needs a copy of one of the following certificate types for the responder:

OCSP—Single Server
• CA-signed certificate – OCSP responder’s certificate is signed by a root CA.
• Intermediate certificate – OCSP responder’s certificate is signed by an intermediate CA.
NOTE: As part of configuration for OCSP support, you must still import the certificate(s) to the
ACOS device.
OCSP—Single Server
This section provides a configuration example that uses one OCSP server.
• Server certificate and key files that ACOS can present to clients during an SSL session set up between ACOS and the
clients
• An authentication-server profile for the OCSP server
• A client-SSL template
• A server configuration and a service group for the services that are requested by clients
CLI Example
The following commands import a server certificate and key to the ACOS device:
ACOS(config)# import ssl-cert-key bulk use-mgmt-port sftp:

Address or name of remote host []? fileserver1
User name []? admin1
Password []? ********
File name [/]? server.pk7
...
ACOS presents the server certificate and public key to clients as verification of the server identity. From the client’s perspec-
tive, the ACOS device where the VIP requested by the client is configured is the server.
The following commands create an authentication-server profile for the OCSP server:
NOTE: The path to an OSCP server in a URL is in the authentication requests.
ACOS(config)# authentication-server ocsp OCSP1

ACOS(config-ocsp server)# url http://10.10.10.5:778/
The url command specifies the IP address and protocol port to which ACOS will send client certificates for verification.
The following commands configure the client-SSL template:

OCSP—Multiple Servers
ACOS(config-ocsp server)# slb template client-ssl ssl1

ACOS(config-client ssl)# cert server
ACOS(config-client ssl)# key server
ACOS(config-client ssl)# ca-cert ca ocsp ocsp1
ACOS(config-client ssl)# client-certificate Require
The cert and key commands specify the local filenames for the certificate and key files that are imported to the ACOS
device. In this example, both the certificate and key are imported as one file, so the same filename is used for the certificate
and key.
The following commands add the servers and service group:
ACOS(config-client ssl)#slb server s1 20.20.20.30

ACOS(config-real server-node port)#slb server s2 20.20.20.31
ACOS(config-real server-node port)#slb service-group http tcp
ACOS(config-slb svc group)#member s1:80
The following commands add the VIP:
ACOS(config-slb svc group)#slb virtual-server http 2.1.0.100

ACOS(config-slb vserver)#port 443 https
ACOS(config-slb vserver-vport)#service-group http
ACOS(config-slb vserver-vport)#template client-ssl ssl1
The configuration example in this section uses a group of multiple OCSP servers.
• Server certificate and key files, for ACOS to present to clients during an SSL session set up between ACOS and the cli-
ents
• An authentication-server profile for each OCSP server
• Server configurations and service group for the OCSP servers
• Server configurations and service group for the services that are requested by clients

NOTE: The authentication-server profiles in this deployment are required as part of the config-
uration. But, in this deployment, the OCSP server information is in the SLB server config-
urations for the OCSP servers, instead of in the authentication-server profiles.
CLI Example
This configuration is similar to the configuration in “OCSP—Single Server” on page 40, with the addition of SLB server config-
urations and a service group for the OCSP servers. ACOS load balances certificate verification requests among the OCSP
responders in the service group.
The following commands import a server certificate and key to the ACOS device:
ACOS(config)#import ssl-cert-key bulk use-mgmt-port sftp:

User name []?admin1
File name [/]?server.pk7
...
As verification of the server identity, ACOS presents the server certificate and public key to clients. From the client’s perspec-
tive, the ACOS device where the VIP requested by the client is configured is the server.
The following commands create an authentication-server profile for each OCSP server:
ACOS(config)#authentication-server ocsp OCSP1

ACOS(config-ocsp server)#authentication-server ocsp OCSP2
Because verification requests are load balanced among multiple OCSP servers, no additional information about the servers is
required in the authentication-server profiles. Instead, the following commands create SLB server configurations for the
OCSP servers and adds the servers to a service group.
ACOS(config-ocsp server)#slb server o1 10.10.10.5

ACOS(config-real server-node port)#authentication-server OCSP1
ACOS(config-real server-node port)#slb server o2 10.10.10.6
ACOS(config-real server-node port)#authentication-server OCSP2
The url command specifies the IP address and protocol port to which ACOS sends client certificates for verification.
The following commands configure the client-SSL template. This is similar to “OCSP—Single Server” on page 40, except that
the ca-cert command refers to the OCSP service group instead of an individual authentication-server profile for a OSCP
server.
ACOS(config-real server-node port)#slb template client-ssl ssl1

ACOS(config-client ssl)#cert server
ACOS(config-client ssl)#key server
ACOS(config-client ssl)#ca-cert ca ocsp service-group ocsp
ACOS(config-client ssl)#client-certificate Require

The following commands add the SLB configuration for the web servers. This is the same configuration that is used in
“OCSP—Single Server” on page 40.
ACOS(config-client ssl)#slb server s1 20.20.20.30

ACOS(config-real server-node port)#slb server s2 20.20.20.31
ACOS(config-real server-node port)#slb service-group http tcp
ACOS(config-slb svc group)#slb virtual-server http 2.1.0.100
ACOS(config-slb vserver)#port 443 https
ACOS(config-slb vserver-vport)#service-group http
ACOS(config-slb vserver-vport)#template client-ssl ssl1


AAM with Kerberos
Kerberos single sign-on is a security solution that helps end-users access services that are protected by your Kerberos realm,
with one login. End-users do not need to log in again for subsequent requests.
Overview
This section shows an example of an AAM solution that includes Kerberos single sign-on. This solution uses the following
AAM features:
• Login Portal – This deployment collects end-user credentials in the following ways:
• Basic HTTP login

• Form-based login
• Online Certificate Status Protocol (OCSP)
• Authentication Relay with Kerberos

Overview
Basic HTTP Login

Figure 13 shows how Basic HTTP Login is used with RADIUS in this deployment.
FIGURE 13 Kerberos single sign-on - Basic HTTP login
In this deployment, ACOS uses a backend RADIUS server to authenticate access to virtual port 80 on the VIP. When a client
sends a request to HTTP port 80 on the VIP, ACOS sends an HTTP 401 (Not Authorized) message, which contains an Authenti-
cation header, to the client. ACOS sends the end-user credentials to a backend RADIUS server for authentication.
If authentication is successful, ACOS caches the credential verification from the RADIUS server and forwards the server reply
to the client. Kerberos is used to grant permission for subsequent requests for the same service.

Overview
Form-based Login
Figure 14 shows how form-based login is used with RADIUS in this deployment.
FIGURE 14 Kerberos single sign-on - form-based login
For client requests to HTTP port 8080 on the VIP, ACOS sends a web page to the client to obtain the end-user’s username and
password. ACOS then sends the end-user credentials to a backend RADIUS server for authentication.
Similar to requests to virtual port 80, if the authentication is successful, ACOS caches the credential verification from the
RADIUS server and forwards the server reply to the client. Kerberos is used to grant permission for subsequent requests for
the same service.

Overview
OCSP
Figure 15 shows how OCSP is used in this deployment.
FIGURE 15 Kerberos single sign-on - OCSP certificate verification
For client requests to HTTPS port 443, ACOS uses a backend OCSP server to validate certificates that are presented by clients.

Configuration
Authentication Relay with Kerberos

Figure 16 shows how Kerberos is used in this deployment.
FIGURE 16 Kerberos single sign-on - Kerberos ticketing
After authenticating a client, ACOS uses a Kerberos Key Distribution Center (KDC) to manage authentication for subsequent
requests from the client.
Configuration

The deployment in Figure 16 requires the following resources:
• An HTTP-Basic login for port 80:
• An authentication-login profile for a basic-HTTP login

• The form-based login for port 8080:
• A zip archive of the web portal files that are required for end-user login
• An authentication-login profile to collect end-user credentials by using the web portal files

Configuration
• An Authentication-server profile for the backend RADIUS server

• An OCSP certificate verification for port 443:
• A certificate and key to present to clients on behalf of the virtual server

• An authentication-server profile for the backend OCSP server
• The Kerberos authentication relay:
• An authentication-relay profile for the KDC

• An authentication template for each virtual port, which specifies the AAM profiles that can be used.
• The AAM file includes the following:

• Authentication-login profile
• Authentication-relay profile
• Authentication-server
• The server configuration and service group for the application server where the service principal is located.
The server principal is the service that is requested by the client.
• The VIP configuration
CLI Example
The following commands configure the Kerberos AAM deployment illustrated in Figure 16.
The following commands configure the authentication-login profiles for the initial client login by using virtual ports 80 and
8080.
ACOS(config)#authentication-logon http-basic http-basic

ACOS(config-http basic authentication lo...)#exit
The profile that is created for Basic HTTP login is used to log in by using virtual port 80. The profile for form-based portal
login, created below, is used log in by using virtual port 8080.
The following commands import the login-portal files to the ACOS device:

User name []?admin1
...
The following commands configure the login-portal profile.
ACOS(config)#authentication-logon form-based http-form


Configuration

The following commands configure the authentication-relay profile for the Kerberos server.
ACOS(config-form-based authentication lo...)#authentication-relay kerberos kdc1

ACOS(config-kerberos authentication relay)#kerberos-kdc 30.1.1.100
ACOS(config-kerberos authentication relay)#kerberos-realm EXAMPLE.COM
ACOS(config-kerberos authentication relay)#kerberos-account HTTP/acos.test.com
ACOS(config-kerberos authentication relay)#password ********
The following commands configure the authentication-server profiles. One of the profiles is for the OCSP server, which is
used to verify client certificates for clients that request access through virtual port 443. The other authentication-server pro-
file is for the RADIUS server, which is used to authenticate the access to virtual ports 80 and 8080.
ACOS(config-kerberos authentication relay)#authentication-server ocsp ocsp

ACOS(config-ocsp server)#url http://1.0.7.12:778/
ACOS(config-ocsp server)#authentication-server radius radius
ACOS(config-radius server)#secret ********
The following commands configure the application resources that will be load balanced. For simplicity, this example uses a
single server. The service-principal-name command under the configuration level for port 80 indicates the Kerberos name
of the service, which is the application that runs on the real port.
ACOS(config-radius server)#slb server http-ubuntu 1.0.7.21

ACOS(config-real server-node port)#service-principal-name HTTP/ubuntu.test.com
ACOS(config-real server-node port)#slb service-group sg-http tcp
ACOS(config-slb svc group)#member http-ubuntu:80
ACOS(config-slb svc group)#exit
The following commands configure a client-SSL template, which is used to configure authentication settings for SSL traffic
between clients and ACOS. The cert and key commands specify the server certificate and key that is used by ACOS.
ACOS presents the server certificate to clients, on behalf of the application servers. The client-certificate Require command
requires clients to present their certificates to ACOS. The ca-cert command configures ACOS to use OCSP to verify client cer-
tificates. The command refers to the authentication-server profile that was configured for the OCSP server.
ACOS(config)#import ssl-cert-key bulk use-mgmt-port sftp:

User name []?admin1
File name [/]?acos.pk7
...
ACOS(config)#slb template client-ssl client-ssl

ACOS(config-client ssl)#cert acos

Kerberos Terminology Related to AAM
ACOS(config-client ssl)#key acos

ACOS(config-client ssl)#client-certificate Require
ACOS(config-client ssl)#ca-cert ca ocsp ocsp
The following commands configure the authentication templates, which are used to identify the other AAM resources that
secure access to the virtual ports. A separate authentication template is configured for each virtual port.
ACOS(config-client ssl)#slb template authentication normal

ACOS(config-authentication template)#logon http-basic
ACOS(config-authentication template)#relay kdc1
ACOS(config-authentication template)#server radius
ACOS(config-authentication template)#slb template authentication normal-8080
ACOS(config-authentication template)#logon http-form
ACOS(config-authentication template)#server radius
ACOS(config-authentication template)#slb template authentication normal-443
The following commands configure the VIP. Each virtual port uses the same service group. However, each virtual port uses a
different authentication template, for a unique set of AAM features.
ACOS(config-authentication template)#slb virtual-server vs-http 1.0.9.100

ACOS(config-slb vserver-vport)#service-group sg-http
ACOS(config-slb vserver-vport)#template authentication normal
ACOS(config-slb vserver-vport)#port 8080 http
ACOS(config-slb vserver-vport)#template authentication normal-8080
ACOS(config-slb vserver-vport)#port 443 https
ACOS(config-slb vserver-vport)#template client-ssl client-ssl
ACOS(config-slb vserver-vport)#template authentication normal-443

This section lists common Kerberos terms and how these terms relate to AAM.
• Realm – The domain of networked services to which the Kerberos server permits or denies access.
• Kerberos Domain Controller (KDC) – The Kerberos server, which consists of the following main components:
• Authentication service – Checks the user account database for the username and password from the client. If there
is a match, the authentication service creates a Ticket Granting Ticket (TGT) for the client and sends the ticket to
ACOS. The authenticating service also sends the TGT to the ticket granting service to request a service ticket.
• Ticket granting service – Creates Service Tickets (STs) for individual client requests.

• TGT – Master ticket that verifies the identity of the client to ACOS, and ACOS uses the client’s TGT to obtain ST tickets
for specific client requests (described below).
• ST – Ticket that verifies the client’s identify to a specific service for an individual request to that service.
• Front-end server – Kerberos proxy (the ACOS device).
• Backend server – Server that is running the services that are requested by clients.
• Security Principal – Kerberos term for the client.
• Service Principal – Kerberos term for the service that is requested by the client.
• Protocol Translation – Allows the use of other protocols in addition to Kerberos for the client-server AAA exchange.
This capability uses the S42self Kerberos extension.
• Kerberos Constrained Delegation (KCD) – Allows ACOS, which is operating as a Kerberos front-end server, to use the
TGT that is granted to a client by the KDC to issue STs for service requests. This capability uses the S42proxy Kerberos
extension.


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
IP anomaly filtering detects and drops packets that contain the common signatures of DDoS attacks.
You can enable the following IP anomaly filters:
• Frag – Drops all IP fragments, which can be used to attack hosts that run IP stacks with known vulnerabilities in their
fragment reassembly code
• Invalid HTTP or SSL payload
• 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
• Out-of-sequence packet
• Ping-of-death – Drops all jumbo IP packets, which are also known as “ping of death” packets
• TCP-no-flag – Drops all TCP packets that have no TCP flags set
• TCP-SYN-FIN – Drops all TCP packets in which both the SYN and FIN flags are set
• TCP-SYN-frag – Drops incomplete (fragmented) TCP Syn packets, which can be used to launch TCP Syn flood attacks
IP Anomaly Filters for System-Wide PBSLB

The following IP anomaly filters are supported for system-wide PBSLB, although you can also use them without PBSLB:
• Invalid HTTP or SSL payload
• Out-of-sequence packet
When these filters are enabled, the ACOS device checks for these anomalies in new HTTP or HTTPS connection requests from
clients.

Overview
Filtering for these anomalies is disabled by default. However, if you configure a system-wide PBSLB policy, the filters are auto-
matically enabled. You also can configure the filters on an individual basis.
NOTE: In the current release, these filters are supported only for HTTP and HTTPS traffic.
For information about system-wide PBSLB, see “Configuring System-Wide PBSLB” on page 62.
Threshold
The threshold specifies the number of times the anomaly is allowed to occur in a client’s connection requests.
If system-wide PBSLB is configured, ACOS applies the policy’s over-limit action to clients that exceed the threshold. The range
for the threshold value is 1-127 occurrences of the anomaly, and the default value is 10.
NOTE: The thresholds are not tracked by PBSLB policies that are bound to individual virtual
ports.
SOCKSTRESS_CHECK Session State
When the ACOS device checks a data packet against the new IP anomaly filters, the client’s session is in the SOCKSTRESS_-
CHECK state. You might see this state if you are viewing debug output for the client’s session.
Notes
Consider the following information when you work with IP anomaly filtering:
• All IP anomaly filters are supported for IPv4.
• All IP anomaly filters, except IP-option filtering, are supported for IPv6.
• DDoS protection is hardware-based on the following models:
• Thunder 6430S, Thunder 6430, and Thunder 5430S

• AX 2200, AX 2200-11, AX 3100, AX 3200, AX 3200-11, AX 3200-12, AX 3400, AX 5100, AX 5200, and AX 5200-11
DDoS protection is software-based on other models.
• DDoS detection applies only to Layer 3, Layer 4, and Layer 7 traffic.
Layer 2 traffic is not affected by the feature. Layer 4 and Layer 7 DDoS applies only to software releases that support
Server Load Balancing (SLB).
• All IP anomaly filters, except “IP-option”, apply to IPv4 and IPv6. The “IP-option” filter applies only to IPv4.
• The ping-of-death option drops all IP packets longer than 32000 bytes on the following models
• Thunder 3030S, Thunder 1030S, and Thunder 930

• AX 1000, AX 1030, AX 2000, AX 2100, AX 2500, AX 2600, AX 3000, and AX 3030
The option drops IP packets that are longer than 65535 bytes on the other models.

Configuration
Configuration
By default, all the IP anomaly filters that are described in this chapter are disabled. You can enable individual IP anomaly fil-
ters, on a system-wide basis.
To enable IP anomaly filters, you can use the GUI or the CLI.
Using the GUI

1. Click Config Mode > Security > Network > DDoS Protection.
2. Select each DDoS protection filter that you want to enable.
To enable all of the filters, select Drop All.
3. Click OK.
Using the CLI

Use the ip anomaly-drop command at the global configuration level of the CLI:
For example, the following command enables DDoS protection against ping-of-death attacks:
ACOS(config)#ip anomaly-drop ping-of-death
Displaying IP Anomaly Statistics

Using the GUI
Click Monitor Mode > SLB > Application > Switch. For more information, see the online help or the GUI Reference Guide.
Using the CLI

To display IP anomaly statistics, enter the following command:
show slb l4
For system-wide PBSLB, you also can enter the following command:
show pbslb client [ipaddr]
In the output of this command, the counters for a dynamic client are reset to 0 when a client’s dynamic entry ages out.
For more information, see the CLI Reference Guide.
Clearing Layer 4 SLB Statistics
To clear all Layer 4 SLB statistics, including the IP anomaly counters, enter the following command:

Displaying IP Anomaly Statistics
clear slb l4

Policy-Based SLB
This chapter helps you understand and configure policy-based SLB (PBSLB).
Overview
ACOS allows you to “black list” or “white list” individual clients or client subnets. White list traffic is allowed, and black list traf-
fic 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. For example, you 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 indi-
vidual 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 supported 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 configured value. To resolve
this issue, you should use separate black/white lists.
Configuring a Black/White List

Client IP lists, such as black/white lists, can be configured on an external device and imported to the ACOS device or can be
entered in the GUI. The actions to take on the addresses in the list are specified on the ACOS device. A black/white list can
contain up to 8 million individual host addresses and up to 64,000 subnet addresses.
For each IP address (host or subnet) in a black/white list, you can add a row by using the following syntax:
ipaddr [/network-mask] [group-id] [#conn-limit] [;comment-string]
The syntax is defined in the following way:

• The ipaddr is the host or subnet address of the client.
• The network-mask is optional. The default is 32, which means that the address is a host address.
• The group-id is a 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:

• Send the traffic to a specific service group
The default group ID is 0, which means that no group is assigned.
• The #conn-limit specifies the 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.
NOTE: The conn-limit is a coarse limit. The larger the number you specify, the more coarse
the limit. For example, if you specify 100, the ACOS device limits the total connections to
100. If you specify 1000, the device limits the connections to a maximum of 992 connec-
tions.
If the number in the file is larger than the supported maximum limit value, the parser
will use the longest set of digits in the number that you enter that makes a valid value.
For example, if the file contains 32768, the parser will use 3276 as the value. As another
example, if the file contains 111111, the parser will use 11111 as the value.
The ;comment-string is a comment. Everything to the right of the semi-colon (;) is ignored by the ACOS device when it
parses the file.
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 maxi-
mum number of concurrent connections for a specific host to 20. The fourth row assigns a specific host to group 2 and spec-
ifies a maximum of 20 concurrent connections.

NOTE: The ACOS device allows up to three parser errors when reading the file but stops read-
ing 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 (wild-
card address) to the black/white list that is used by the system-wide PBSLB policy.
When a client sends an HTTP or HTTPS connection request, the ACOS device checks the system-wide PBSLB policy’s black/
white list for the client’s IP address, with one of the following results:
• If there is no entry for the client, he ACOS device creates a dynamic entry for the client’s host address.
• If there is a dynamic entry for the client, the ACOS device resets the timeout value for the entry. (Dynamic entry aging
is described below.)
NOTE: If there is a static entry for the client’s host or subnet address, the static entry is used
instead.
Here 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 concur-
rent 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 con-
current 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 connec-
tion 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.

Configuring System-Wide PBSLB
If client-lockup is enabled, the timeout for a locked up client does not begin decreasing until the lockup expires. For more
information about client lockup, see “Client Lockup” on page 63.
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:
• The ACOS device does not create dynamic entries in the list.
• The connection limit applies collectively to all clients that do not have a static entry in the list.

System-wide PBSLB policies provide the following options:
• Dynamic black/white-list client entries
• Client lockup
• IP anomaly checking and tracking, using IP anomaly filters
These options are not available in policies that are applied to individual ports.
To configure a system-wide PBSLB policy, enter the following commands at the global configuration level of the CLI:
[no] system pbslb bw-list name
The following command specifies the name of the black/white list that you need to use for the policy:
[no] system pbslb id id {drop | reset} [logging minutes]
One of the following actions are taken on clients in a group that is configured in the black/white list.
• drop – Drops the connections.
• reset – Resets the connections.
The logging option enables logging, and the minutes option specifies how often messages can be generated.
This command specifies the action to take for clients that exceed one of the following limits:
• The connection limit that is specified in the black/white list.
• The threshold of any of the new IP anomaly filters.

[no] system pbslb over-limit [reset] [lockup minutes] [logging minutes]
For this command, you can use one or both of the following options:

• reset – Resets all new connection attempts from the client. If you omit this option, new connection attempts are
dropped.
• lockup – Continues to apply the over-limit action to all new connection attempts from the client for the specified
number of minutes.
The logging option enables logging, and the minutes option specifies how often messages can be generated.
This command sets the timeout for dynamic black/white-list entries:
[no] system pbslb timeout minutes
You can specify 1-127 minutes, and the default is 5 minutes.
NOTE: If the lockup option is used with the system pbslb over-limit command, aging of the
dynamic entry for a locked up client begins only after the lockup expires.
Client Lockup
The over-limit rule in a system-wide PBSLB policy includes an optional lockup period. If the lockup period is configured, the
ACOS device continues to enforce the over-limit action for the duration of the lockup.
For example, if the over-limit action is drop, and a client exceeds the connection limit that is specified in the black/white list,
the ACOS device continues to drop all connection attempts from the client until the lockup expires.
By default, the lockup option is disabled. To enable it, you must specify a lockup period of 1-127 minutes.
The dynamic black/white-list entry for a client does not age while the client is locked up. After the lockup ends, the timeout
for the entry is reset to its full value and begins decreasing. For more information about aging of dynamic entries, see “Aging
of Dynamic Entries” on page 61.
Displaying and Clearing System-Wide PBSLB Information

To display information for system-wide PBSLB, enter the following commands:
show pbslb system

show pbslb client [ipaddr]
To clear PBSLB information, enter the following commands:
clear pbslb system

clear pbslb client [entry]
If you do not include the entry option, the statistics counters are cleared, but the client entries are not cleared. To clear the
client entries, use the entry option.

Configuring PBSLB for Individual Virtual Ports

You can configure PBSLB parameters for virtual ports by configuring the settings on individual ports or by configuring a
PBSLB policy template and binding the template to individual virtual ports.
NOTE: This feature is supported only in software releases that support Server Load Balancing
(SLB).
These steps assume that the real servers, service groups, and virtual servers have already been configured.
To configure PBSLB:
1. Configure a black/white list remotely or on the ACOS device.
If you configure the list remotely, import the list to the ACOS device.
2. Optionally, modify the sync interval for the list.
ACOS regularly synchronizes with the list to ensure that the ACOS version is current.
3. Configure PBSLB settings.
You can configure a policy template and bind the template to virtual ports or configure the following settings on indi-
vidual virtual ports:
• Specify the black/white list.

• Optionally, map each group ID that used in the list to one of the following actions:
• Send the traffic to a specific service group.
• Reset the traffic.
• Drop the traffic.
• Optionally, change the action (drop or reset) that ACOS will take on connections that exceed the specified limit.
• Optionally, if necessary, change the client address matching from source IP matching to destination IP matching.
Using the GUI
Configuring PBSLP Settings
To configure PBSLB settings by using a policy template:
1. Click Config Mode > Security > Template > Policy.
2. Click Add.
3. Enter a template name.
4. Do one of the following from the drop-down list below the Name field:
• Select the black/white list.

• Click Create.

5. If you clicked Create, complete the following steps in the PBSLB section:
a. Enter or select the following information:
• Name that will be used for the imported black/white list.

• Location of the black/white list.
b. To create the list using a text entry field in the GUI, click Local.
c. Copy and paste or type the black/white list.
d. To import a list from a remote server, select Remote.
e. Enter values for the following parameters:
• Interval at which the ACOS device re-imports the list. This option ensures that changes to the list are automati-
cally replicated on the ACOS device.
• File transfer protocol.
• IP address or hostname of the device where the list is located.
• Path and filename of the list on the remote device.
f. Click OK.
6. To configure group options:
a. In the Group ID drop-down list, select the group.
b. In the Action drop-down list, select one of the following options:
• Drop – Drops new connections until the number of concurrent connections on the virtual port falls below the
port’s connection limit. The connection limit is set in the black/white list.
• Reset – Resets new connections until the number of concurrent connections on the virtual port falls below the
connection limit.
• service group name – Each of the service groups that are configured on the ACOS device is listed.
• Create – This option displays the configuration sections for creating a new service group.
c. Optionally, enable logging.
To change the logging interval, edit the value in the Period field. Logging generates messages to indicate that the
traffic matched the group ID.
To generate log messages only when there is a failed attempt to reach a service group, select Log Failures.
NOTE: If the Use default server selection when preferred method fails option is enabled on
the virtual port, log messages will never be generated for server-selection failures. To
ensure that messages are generated, disable the Use default server selection when
preferred method fails option on the virtual port. This limitation does not affect fail-
ures that occur because a client has exceeded the PBSLB connection limit. These failures
are still logged.
d. Click Add.

e. Repeat the steps above for each group.
7. Select one of the following actions to take when traffic exceeds the limit:
• Drop
• Reset
8. Optionally, to match destination traffic against the black/white list, instead of source traffic, select Use Destination IP.
9. Click OK.
10. To bind the PBSLB policy template to a virtual port:
a. Click Config Mode > SLB > Service > Virtual Server.
b. Do one of the following:
• Click on an existing virtual server name.

• Click Add.
c. In the Port section, do one of the following:
• Click Add.
• Select a virtual port and click Edit.
d. In the Virtual Server Port section, select the PBSLB template from the Policy Template drop-down list.
e. Click OK and then OK again.
Using the CLI
Importing a Black/White List
To import a black/white list:
Enter the following command at the global configuration level of the CLI:
bw-list name url [period seconds] [load]
Where:
• The name can be up to 31 alphanumeric characters long.
• The url specifies the file transfer protocol, directory path, and filename. The following URL format is supported:
tftp://host/file
• The period seconds option specifies how often the ACOS device re-imports the list to ensure that changes to the list
are automatically replicated on the ACOS device. You can specify 60 – 86400 seconds, and the default is 300 seconds.
• The load option immediately re-imports the list to get the latest changes. Use this option if you change the list and
want to immediately replicate the changes on the ACOS device, without waiting for the update period.

NOTE: A TFTP server is required on the computer, and the TFTP server must be running when
you enter the bw-list command.
NOTE: If you use the load option, the CLI cannot accept new commands until the load is com-
pletely finished. For large black/white lists, loading can take a while. Stopping the load
process can interrupt periodic black/white-list updates. If you accidentally stop the load
process, repeat the command with the load option and allow the load to complete.
Configuring PBSLB Settings by using a Policy Template
To configure a PBSLB template, enter the following commands:
The command creates the template and changes the CLI to the configuration for the template where the following PBSLB-
related commands are available. Enter this command at the global configuration level of the CLI:
[no] slb template policy template-name
This command binds a black/white list to the virtual ports that use this template:
[no] bw-list name file-name
This command specifies the action to take for clients in the black/white list:
[no] bw-list id id
service {service-group-name | drop | reset}
[logging [minutes] [fail]]
Where:
• id – Group ID in the black/white list.
• service-group-name – Sends clients to the SLB service group associated with this group ID on the ACOS device.
• drop – Drops connections for IP addresses that are in the specified group.
• reset – Resets connections for IP addresses that are in the specified group.
• logging [minutes] [fail] – Enables logging. The minutes option specifies how often messages can be gener-
ated. This option reduces overhead caused by frequent recurring messages.
For example, if the logging interval is set to 5 minutes, and the PBSLB rule is used 100 times in a five-minute period, the
ACOS device generates only one message. The message indicates the number of times the rule was applied since the
last message. You can specify a logging interval from 0 to 60 minutes. To send a separate message for each event, set
the interval to 0.
PBSLB rules that use the service service-group-name option also have a fail option for logging. The fail option config-
ures the ACOS device to generate log messages only when there is a failed attempt to reach a service group. Messages
are not generated for successful connections to the service group. The fail option is disabled by default.
The option is available only for PBSLB rules that use the service service-group-name option, not for rules with the drop
or reset option. When a drop or reset rule affects traffic, a failure condition is indicated.
By default, logging is disabled. If you enable it, the default value is 3 minutes.

The ACOS device uses the same log rate limiting and load balancing features for PBSLB logging as those used for ACL
logging. For more information about IP limiting, see “IP Limiting” on page 87.
NOTE: If the def-selection-if-pref-failed option is enabled on the virtual port, log messages
are never generated for server-selection failures. To ensure that these messages are gen-
erated, disable the def-selection-if-pref-failed option on the virtual port. This limita-
tion does not affect failures that occur because a client has exceeded the PBSLB
connection limit. These failures are still logged.
This command specifies the action to take for traffic that is over the limit:
[no] bw-list over-limit {lockup min | logging min | reset}
You can specify one or more of the following options:
• lockup min – Continues to apply the over-limit action to all new connection attempts from the client, for the spec-
ified number of minutes (1-127).
• logging min – Generates a log message when traffic goes over the limit. The min option specifies the log interval
and can be 1-255 minutes.
• reset – Resets new connections until the number of concurrent connections on the virtual port falls below the con-
nection limit.
This command matches black/white list entries based on the client’s destination IP address:
[no] bw-list use-destination-ip
By default, matching is based on the client’s source IP address. This option is applicable if you are using a wildcard VIP. (See
the “Wildcard VIPs” chapter in the Application Delivery and Server Load Balancing Guide.)
The following command binds the template to a virtual port:
[no] template policy template-name
Enter the command at the configuration level for the port.
Configuring PBSLB Settings Directly on a Virtual Port
The following command binds a black/white list to a virtual port:
pbslb bw-list name
Enter the following command at the configuration level for the virtual port.
Where name is the name you assign to the list when you import it.
The following command maps client IP addresses in a black/white list to specific service groups:
pbslb id id {service service-group-name | drop | reset} [logging [minutes] [fail]]]
Enter the following command at the configuration level for the virtual por.
Where:

Displaying PBSLB Information
• The id is a group ID in the black/white list and can be from 1 to 31.
• The service-group-name is the name of an SLB service group on the ACOS device.
• The drop option immediately drops all connections between the clients in the list and any servers in the service
group. The reset option resets the connections between the clients in the list and any servers in the service group.
• The logging option enables logging.
• The minutes option specifies how often messages can be generated. This option reduces overhead caused by fre-
quent recurring messages.
For example, if the logging interval is set to 5 minutes, and the PBSLB rule is used 100 times within a five-minute period,
the ACOS device generates only a single message. The message indicates the number of times the rule was applied
since the last message. You can specify a logging interval from 0 to 60 minutes. To send a separate message for each
event, set the interval to 0. The default is 3 minutes.
PBSLB rules that use the service service-group-name option also have a fail option for logging. The fail option configures the
ACOS device to generate log messages only when there is a failed attempt to reach a service group. Messages are not gener-
ated for successful connections to the service group.
By default, the fail option is disabled. The option is available only for PBSLB rules that use the service service-group-name
option, not for rules with the drop or reset option. When a drop or reset rule affects traffic, it indicates a failure condition.
The ACOS device uses the same log rate limiting and load balancing features for PBSLB logging as are used for ACL logging.
NOTE: If the def-selection-if-pref-failed option is enabled on the virtual port, log messages
are never generated for server-selection failures. To ensure that these messages are gen-
erated, disable the def-selection-if-pref-failed option on the virtual port. This limita-
tion does not affect failures that occur because a client exceeded the PBSLB connection
limit. These failures are still logged.
This command specifies the action to take if the virtual port’s connection threshold is exceeded:
[no] bw-list over-limit {drop | reset}
Enter the following command at the configuration level for the virtual port.
Where:
• drop – Drops new connections until the number of concurrent connections on the virtual port falls below the port’s
connection limit. The connection limit is set in the black/white list.
• reset – Resets new connections until the number of concurrent connections on the virtual port falls below the con-
nection limit.The connection threshold is set in the black/white list.
Displaying PBSLB Information

To show the configuration of a PBSLB policy template, enter the following command:
show slb template policy template-name

Configuration Examples
To show client IP addresses contained in a black/white list, enter the following command:
show bw-list [name [detail | ipaddr]]
Where:
• The name is the name you assign to the list when you import it.
• The ipaddr is the client IP address.
To show policy-based SLB statistics, enter the following command:
show pbslb [name]
The name option specifies a virtual server name.
If you use this option, statistics are displayed only for that virtual server. Otherwise, statistics are shown for all virtual servers.
The following commands import black/white list “sample-bwlist.txt” to the ACOS device:
ACOS(config)#bw-list sample-bwlist tftp://myhost/TFTP-Root/ACOS_bwlists/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 srvcgroup2
ACOS(config-policy)#bw-list id 4 drop
ACOS(config-policy)#exit
ACOS(config)#slb virtual-server PBSLB_VS1 10.10.10.69
ACOS(config-slb virtual server)#port 80 http
ACOS(config-slb virtual server-slb virtua...)#template policy bw1
The following commands configure the same PBSLB settings on a virtual port:
ACOS(config)#slb virtual-server PBSLB_VS2 10.10.10.70

ACOS(config-slb virtual server-slb virtua...)#pbslb bw-list sample-bwlist
ACOS(config-slb virtual server-slb virtua...)#pbslb id 4 drop

Example—Sockstress Attack Protection
ACOS(config-slb virtual server-slb virtua...)#pbslb id 2 service srvcgroup2
The following commands displays PBSLB information:
ACOS(config-slb virtual server-slb virtua...)#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

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:
• The client already has 20 active connections and attempts to open a new HTTP or HTTPS connection.
• 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
System-wide PBSLB Policy Configuration

The following commands configure the system-wide PBSLB policy:
ACOS(config)#system pbslb bw-list bwlist-wc

ACOS(config)#system pbslb over-limit lockup 5
ACOS(config)#system pbslb timeout 2
Configuring the system-wide PBSLB policy also automatically enables the new IP anomaly filters.
Statistics Display
The following command displays system-wide statistics for the new IP anomaly filters:
ACOS(config)#show slb l4
Total
------------------------------------------------------------------
IP out noroute 20061

TCP out RST 0

TCP out RST no SYN 0
...
Anomaly out of sequence 225408
Anomaly zero window 225361
Anomaly bad content 224639
The following command displays statistics for the system-wide PBSLB policy:
ACOS(config)#show pbslb system

System B/W list: bwlist-wc
Virtual Server Port Blacklist/whitelist GID Connection # (Establish Reset Drop)
--------------------------------------------------------------------------------
System bwlist-wc 1 12 0 0
2 0 0 0
The following command displays summary statistics for individual black/white-list clients:
ACOS#show pbslb client

GID = Group ID, S/D = Static or dynamic entry
Out-s = Out of sequence, Zero-w = Zero window, Bad-c = Bad content
IP S/D GID Conn-limit Curr-conn Age Lockup Out-s Zero-w Bad-c
------------------+---+---+----------+---------+-----+------+-----+------+----
40.40.40.168 /32 D 1 20 5 120 0 0 5 5
40.40.40.169 /32 D 1 20 6 0 5 0 6 6
40.40.40.170 /32 D 1 20 6 0 5 0 6 6
40.40.40.171 /32 D 1 20 6 0 5 0 6 6
40.40.40.172 /32 D 1 20 6 0 5 0 6 6
40.40.40.173 /32 D 1 20 2 120 0 0 2 2
40.40.40.174 /32 D 1 20 5 120 0 0 5 5
40.40.40.175 /32 D 1 20 5 120 0 0 5 5
40.40.40.160 /32 D 1 20 5 120 0 0 5 5
40.40.40.161 /32 D 1 20 6 120 0 0 6 6
40.40.40.162 /32 D 1 20 6 0 5 0 6 6
40.40.40.163 /32 D 1 20 6 0 5 0 6 6
40.40.40.164 /32 D 1 20 6 0 5 0 6 6
40.40.40.165 /32 D 1 20 5 120 0 0 5 5
The Age column indicates how many seconds are left before a dynamic entry ages out. For clients who are currently locked
out of the system, the value in the Lockup column indicates how many minutes the lockup will continue. For locked up cli-
ents, the age value is 0 until the lockup expires. After the lockup expires, the age is set to its full value. In this example, the
lockup value is 120 seconds.
The following command displays detailed statistics for a specific black/white-list client:
ACOS#show pbslb client 40.40.40.168

IP address: 40.40.40.168
Netmask length: 32

Type: Dynamic
Group ID: 1
Connection limit (0 = no limit): 1984
Current connection: 6
Age: 0 second
Lockup time: 5 minute
Out of sequence: 0
Zero window: 6
Bad content: 6


SYN Cookies
This chapter describes the SYN-cookie feature and how it helps protect ACOS devices against disruptive SYN-based flood
attacks.
Overview
SYN cookies protect against TCP SYN flood attacks. When SYN cookies are enabled, the ACOS device can continue to serve
legitimate clients during these attacks, while preventing illegitimate traffic from consuming system resources.
SYN Flood Attacks

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 con-
sumed 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 connection queue to become full.
This oversubscription prevents the device from establishing new connections with legitimate clients.
Identifying SYN Flood Attacks

Figure 17 illustrates a typical 3-way TCP handshake, including 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.
FIGURE 17 Legitimate SYN-ACK Handshake
However, SYN flood attacks (Figure 18) 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

Overview
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 18 Hacker SYN-ACK Handshake
Enabling SYN cookies mitigates the damage caused by such DoS attacks by preventing the attacks from consuming system
resources.
TCP connections for which the ACOS device did not receive an ACK from the client is identified as belonging to a SYN flood
attack, and this information is displayed with the counter in the output of the show command.
ACOS SYN-cookie Protection

By enabling SYN cookies, the ACOS device’s TCP connection queue is prevented from filling up during TCP SYN flood attacks.
When a client sends an SYN request, the ACOS device 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

Overview
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 con-
nection information and establishes a connection with that client.
If the SYN Request is part of an attack, the attacker does not send an ACK to the ACOS device. The ACOS device sends a SYN
cookie, but the attacker does not receive it (or may choose to ignore it), and the ACOS device does not establish a connec-
tion.
Dynamic SYN Cookies

You can configure on and off thresholds for SYN cookies. When there are no TCP SYN attacks, the TCP options are preserved.
You can configure the following dynamic SYN cookie options:
• On-threshold – specifies the maximum number of concurrent half-open TCP connections that are allowed on the
ACOS device, before SYN cookies are enabled. If the number of half-open TCP connections exceeds the on-threshold
value, the ACOS device enables SYN cookies. You can specify 0-2147483647 half-open connections.
• Off-threshold – specifies the minimum number of concurrent half-open TCP connections for which to keep SYN
cookies enabled. If the number of half-open TCP connections falls below this level, SYN cookies are disabled. You can
specify 0-2147483647 half-open connections.
By default, hardware-based SYN cookies are disabled. When the feature is enabled, there are no default settings for the on-
and off-threshold. If you omit the on-threshold and off-threshold options, SYN cookies are enabled and are always on,
regardless of the number of half-open TCP connections on the ACOS device.
NOTE: It may take up to 10 milliseconds for the ACOS device to detect and respond to cross-
over of either threshold.

Overview
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 con-
nection 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 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 cookies 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.
• 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.
• 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.

Configuration
Configuration
The following sections describe how to enable SYN-cookie support and configure advanced features.
Enabling SYN-cookie Support

Depending on your ACOS device model, you can use hardware-based SYN cookies or software-based SYN cookies:
• Hardware-based SYN cookies can be globally enabled and applied to all virtual server ports that are configured on
the device.
Hardware-based SYN cookies are available on Thunder 6430S, Thunder 6430, and Thunder 5430S. The cookies are also
available on AX Series models AX 2200, AX 2200-11, AX 3100, AX 3200, AX 3200-11, AX 3200-12, AX 3400, AX 5100, AX
5200, and AX 5200-11.
• Software-based SYN cookies can be enabled on individual virtual ports. This version of the feature is available on all
AX Series models.
Consider the following information:
• Hardware-based SYN cookies are a faster, easier-to-configure alternative to the software-based SYN cookie feature
available on all platforms.
If your model supports hardware-based SYN cookies, A10 Networks recommends that you use the hardware-based
version of the feature instead of the software-based version.
If both hardware-based and software-based SYN cookies are enabled, only hardware-based SYN cookies are used.
Although software-based SYN cookies can be enabled, they are not used.
If Application Delivery Partitioning (ADP) is configured, hardware-based SYN cookies apply to all partitions. The feature
is not partition-aware.
• If the target VIP is in a different subnet from the client-side router, use of hardware-based SYN cookies requires some
additional configuration.
For more information, see “Configuration with Target VIP and Client-side Router in Different Subnets” on page 80.
• Software-based SYN cookies are supported only in software releases that support SLB.
Using the GUI
FPGA Models
1. Click Config Mode > SLB > Service > Global > Settings.
2. Select Enabled next to SYN Cookie.
3. In On Threshold, enter the maximum number of concurrent half-open TCP connections that are allowed on the ACOS
device, before SYN cookies are enabled.
4. In Off Threshold, enter the minimum number of concurrent half-open TCP connections for which to keep SYN cookies
enabled.

Configuration
5. Click OK.
Non-FPGA Models
1. Click Config Mode > SLB > Service > Server.
2. Click Virtual Server.
3. Do one of the following:
• Click on an existing virtual server name.

• Click Add.
4. In General, enter or edit the information.
5. In Port, select the TCP port and click Edit or Add.
6. If you are configuring a new port, select TCP in the Type drop-down list.
7. Select Enabled next to SYN Cookie.
8. Enter or edit other values as needed for your configuration.
9. Click OK and then OK again.
Using the CLI
FPGA Models
To enable hardware-based SYN cookies on ACOS models that feature FPGAs, use the following command at the global con-
figuration level:
[no] syn-cookie [on-threshold num off-threshold num]
The command in the following example enables dynamic-based SYN cookies when the number of concurrent half-open
TCP connections exceeds 50000 and disables SYN cookies when the number falls below 30000:
ACOS(config)#syn-cookie on-threshold 50000 off-threshold 30000
Non-FPGA Models
To enable software-based SYN cookies, use the following command at the virtual-port level:
[no] syn-cookie
Configuration with Target VIP and Client-side Router in Different

Subnets
Usually, the target VIP in an SLB configuration is in the same subnet as the client-side router. However, if the target VIP is in a
different subnet, to use hardware-based SYN cookies, configure the following items:

Configuration
• On the ACOS device, configure a “dummy” VIP that is in the same subnet as the client-side router.
• On the client-side router, configure a static route to the VIP by using the dummy VIP as the next hop.
Figure 19 is an example of this deployment.
FIGURE 19 Hardware-based SYN Cookies – Target VIP and Client-side Router in Different Subnets
The following commands configure hardware-based SYN cookies on the ACOS device:
ACOS(config)#slb virtual-server dummyvip 10.10.10.154

ACOS(config-slb virtual server)#exit
ACOS(config)#syn-cookie
NOTE: If HA is configured, add both the target VIP and the dummy VIP to the same HA group,
so these VIPs will fail over to the HA peer as a unit.
Configuring Layer 2/3 SYN Cookie Support for Data Interfaces

To configure Layer 2/3 SYN cookie support:
1. Enable Layer 2/3 SYN cookies on individual interfaces.
2. Optionally, modify the threshold for TCP handshake completion.

Configuration
Using the CLI

1. To enable Layer 2/3 SYN cookies on an interface, enter the following command at the configuration level for the inter-
face:
[no] ip tcp syn-cookie
The feature is disabled by default.
2. Optionally, to modify the threshold for TCP handshake completion, enter the following command at the global config-
uration level of the CLI:
[no] ip tcp syn-cookie threshold seconds
You can specify 1-100 seconds, and the default is 4 seconds.
CLI Example
The following commands globally enable SYN cookie support and enable Layer 2/3 SYN cookies on Ethernet interfaces 4
and 5:
ACOS(config)#syn-cookie on-threshold 50000 off-threshold 30000

ACOS(config)#interface ethernet 4
ACOS(config-if: ethernet4)#ip tcp syn-cookie
ACOS(config-if: ethernet4)#interface ethernet 5
ACOS(config-if: ethernet5)#ip tcp syn-cookie
Configuring SYN-cookie Buffering

When SYN cookies are enabled, 10 buffers are available to hold overflow packets from each client session. When the system
memory is occupied, the number of buffers dedicated to each TCP 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 allocated 10 buffers, and the TCP win-
dow size is set to 8K.
• If the first threshold is breached, the buffer is reduced to 4 buffers, and the TCP window size is reduced to 4K.
• If the next memory threshold is breached, the buffer is reduced to 2 buffers, and the TCP window size is reduced to
2K.
• If the final threshold is breached, the buffer is reduced to 1 buffer, and the TCP window size is reduced to 1K.
These thresholds are based on system memory usage, and the values are configurable.
Consider the following information:
• Each buffer size is approximately 1500 bytes.
The total number of buffers varies from one model to the next and is based on the total memory per connection.

Displaying SYN-cookie Statistics
• If hardware-based SYN cookies are enabled, ACOS does not modify the TCP window size.
It remains hard-coded at 65K.
Using the GUI

The current release does not support configuring this option by using the GUI.
Using the CLI

You can enter the slb buff-thresh CLI command to configure the thresholds for system memory usage. These threshold
configurations apply to both software- and hardware-based models.
• 1st threshold: slb buff-thresh hw-buff num
The first threshold is associated with a reduction in the buffers that are allocated to each TCP connection from 10 to 4.
• 2nd buffer: relieve-thresh command
The second threshold is associated with a reduction in the buffers that are allocated to each TCP connection from 4 to
2.
• 3rd buffer: sys-buff-low command
The third threshold is associated with a reduction in the buffers that are allocated to each TCP connection from 2 to 1.
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 at the global config level:
[no] slb buff-thresh hw-buff num relieve-thresh num

sys-buff-low num
sys-buff-high num
For additional information about changing the system memory thresholds, see the slb buff-thresh command in the Com-
mand Line Interface Reference Guide.

This section describes how to view SYN-cookie statistics by using the GUI or CLI.
Using the GUI

To display SYN-cookie statistics, click Monitor Mode > SLB > Application > Switch.
Using the CLI

To display SYN-cookie statistics, enter the following commands:
• show slb attack-prevention

• show slb l4 [detail]

• show slb syn-cookie-buffer
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 legiti-
mate clients. When SYN cookies are enabled, and a legitimate client sends a SYN request, the ACOS device responds
with a SYN ACK. If the ACOS device receives an ACK, the packet is considered safe.
These fields are highlighted in examples below.
CLI Example 1: Attack Prevention Statistics

You can view SYN-cookies statistics for one sampling interval or across the following time intervals:
• Current
• 1 second
• 5 seconds
• 30 seconds
• 1 minute
• 5 minutes
The following command displays SYN-cookie statistics across multiple time intervals:
ACOS#show slb attack-prevention

Current 1 sec 5 sec 30 sec 1 min 5 min
-----------------------------------------------------------------------------
SYN cookie snt 0 0 0 0 0 0
SYN cookie snt ts 0 0 0 0 0 0
SYN cookie snt fail 0 0 0 0 0 0
SYN cookie chk fail 0 0 0 0 0 0
SYN attack 0 0 0 0 0 0
For details about the fields in this output, refer to “show slb attack-prevention” in the Command Line Interface Reference.
Limitations
• When running the show slb attack-prevention command on an FPGA-based 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.

• This feature is supported for L3V private partitions in non-FPGA-based models. If the show slb attack-prevention
command is run from an L3V network partitions on an FPGA-based model, the SYN attack counter displays zero for
all columns.
To clear these statistics, enter the clear slb attack-prevention command:
ACOS#clear slb attack-prevention
CLI Example 2: SYN Attack Counter

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

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

The following example displays output for SYN cookie buffer statistics:
ACOS#show slb syn-cookie-buffer

Maximum SYN cookie buffer size : 10
Total SYN cookie buffer queued : 0
Total SYN cookie buffer drop : 0

SYN Attack Counter Support for L3V

The SYN flood attack counter in the output for the show slb l4 command may not work correctly in every situation. For
example, while counters that are associated with software-based SYN cookies work correctly in L3V and non-L3V deploy-
ments, counters that are associated with hardware-based SYN cookies do not work with private partitions.
Table 2 shows the limitations that are associated with using SYN flood attack counters under a variety of conditions.
TABLE 2 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)* Enabled No†
*. 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.
†. “No” means that the SYN flood attack counters fail when hardware- and software-based SYN cookies are enabled at the same
time as L3V (private partitions). This is a known limitation with this feature.
The SYN cookie counter incremented? column indicates whether the SYN cookie counter display will function correctly,
based on the status of the other conditions that are associated with this deployment.

IP Limiting
IP limiting provides a an enhanced implementation of the source IP connection limiting and connection-rate limiting fea-
ture. This chapter describes the IP limiting options and how to configure and apply these options.
Overview
IP limiting provides the following benefits:
• Configuration flexibility – You can apply source IP limiting on a system-wide basis, on individual virtual servers, or on
individual virtual ports.
• Class lists – You can configure different classes of clients, and apply a separate set of IP limits to each class.
You also can exempt specific clients from being limited.
• Separate limits can be configured for each of the following items:
• Concurrent connections
• Connection rate
• Concurrent Layer 7 requests
• Layer 7 request rate
NOTE: In the current release, Layer 7 request limiting applies only to the HTTP, HTTPS, and fast-
HTTP virtual port types.
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 con-
figured in a shared partition or in a private partition can use a class list that is configured
in the shared partition.
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]

Overview
Where:
• ipaddr – Specifies the host or subnet address of the client.
• The network-mask specifies the mask. IPv4 and IPv6 are supported.
To configure a wildcard IP address, specify 0.0.0.0 /0 or ::/0. The wildcard address matches on all addresses that do not
match any entry in the class list.
• glid num | lid num – Specifies the ID of the IP limiting rule that will be used to match clients. You can use a system-
wide (global) IP limiting rule or an IP limiting rule that is configured in a policy template.
• To use an IP limiting rule that is configured at the global configuration level, use the glid num option.
• To use an IP limiting rule that is configured at the same level (in the same policy template) as the class list, use the
lid num option.
To exclude a host or subnet from being limited, do not specify an IP limiting rule.
• 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 limit-
ing settings in the LID or GLID that are assigned to the host entry are in effect only until the age expires.
The age option applies only to host entries (IPv4 /32 or IPv6 /128). The age option is not supported for subnet entries.
NOTE: If you use a class-list file that is periodically re-imported, the age for class-list entries that
are added to the system from the file do not reset when the class-list file is re-imported.
Instead, the entries are allowed to continue aging normally.
• ; comment-string – Contains a comment. Use a semi-colon ( ; ) in front of the comment string.
NOTE: The ACOS device discards the comment string when you save the class list.
IP Address Matching
By default, the ACOS device matches the class-list entries based on the source IP address of client traffic. Optionally, you can
also match based on one of the following items:

Overview
• Destination IP address – Matches based on the destination IP address instead of the source IP address.
• 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
Here is an example with more options:
1.1.1.1 /32 lid 1

2.2.2.0 /24 lid 2 ; LID 2 applies to every single IP of this subnet
0.0.0.0 /0 lid 10 ; LID 10 applied to every undefined single IP
3.3.3.3 /32 glid 3 ; Use global LID 3
4.4.4.4 /32 ; No LID is applied (exception list)
The rows in the list specify the following:
• For individual host 1.1.1.1, use IP limiting rule 1, which is configured in a policy template.
A policy template can be applied globally for system-wide IP limiting or to an individual virtual server or virtual port.
This is described in more detail in a later section.
• For all hosts in subnet 2.2.2.0/24, use IP limiting rule 2, which is configured in a policy template.
• For all hosts that do not match another entry in the class list, use IP limiting rule 10, which is configured in a policy
template.
• For individual host 3.3.3.3, use IP limiting rule 3, which is configured at the global configuration level.
• For individual host 4.4.4.4, do not use an IP limiting rule.
IP Limiting Rules
IP limiting rules specify connection and request limits for clients.
Each IP limiting rule has the following parameters:
• Limit ID – Number from 1-31 that identifies the rule.
• Connection limit – Maximum number of concurrent connections that are allowed for a client. You can specify 0-
1048575. Connection limit 0 immediately locks down matching clients, and there is no default value.
• Connection-rate limit – Maximum number of new connections that are allowed for a client in the limit period. You
can specify 1-4294967295 connections. The limit period can be 100-6553500 milliseconds (ms), specified in incre-
ments of 100 ms. There is no default.
• Request limit – Maximum number of concurrent Layer 7 requests that are allowed for a client. You can specify 1-
1048575, and there is no default.

Overview
• Request-rate limit – Maximum number of Layer 7 requests that are allowed for a client in the limit period. You can
specify 1-4294967295 connections. The limit period can be 100-6553500 milliseconds (ms), specified in increments of
100 ms. There is no default.
• Over-limit action – Action to take when a client exceeds at least one limit.
The action can be one of the following:
• Drop – The ACOS device drops that traffic. If logging is enabled, the ACOS device also generates a log message. This
is the default action.
• Forward – The ACOS device forwards the traffic. If logging is enabled, the ACOS device also generates a log mes-
sage.
• Reset – For TCP, the ACOS device sends a TCP RST to the client. If logging is enabled, the ACOS device also generates
a log message.
• Lockout period – Number of minutes during which to apply the over-limit action after the 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.
• 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 pol-
icy templates that are used for system-wide PBSLB. For more information, see “Request
Limiting and Request-rate Limiting in Class Lists” on page 91.
The request limit and request-rate limit options apply only to HTTP, fast-HTTP, and HTTPS
virtual ports. The over-limit logging, when used with the request-limit or request-rate-
limit option, always lists Ethernet port 1 as the interface.
Match IP Address
By default, the ACOS device matches class-list entries based on the source IP address of client traffic. Optionally, you can also
match based on one of the following options:
• Destination IP address – Matches based on the destination IP address in packets from clients.
• IP address in client packet header – Matches based on the IP address in the specified header in packets from clients. If
you do not specify a header name, this option uses the IP address in the X-Forwarded-For header.

Overview
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 follow-
ing conditions are true:
• The LID or GLID is used in a policy template.
• The policy template is bound to a virtual port.
The settings apply only to the virtual port but do not apply in the following cases:
• The policy template is applied to the virtual server, instead of the virtual port.
• The settings are in a system-wide GLID.
• The settings are in a system-wide policy template.
NOTE: This limitation does not apply to connection limiting or connection-rate limiting. Those
settings are valid in the cases listed above.
CLI Examples Using Request and Request-Rate Limiting

The request limiting and request-rate limiting settings are used in the following examples:
• Example 1: GLID Used in Policy Template and Bound to Virtual Port
• Example 2: LID Used in Policy Template and Bound to Virtual Port
Example 1: GLID Used in Policy Template and Bound to Virtual Port

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

Overview
ACOS(config-slb vserver-vport)#template policy g
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 2
ACOS(config-class list)#55.1.1.100 /32 lid 31
ACOS(config)#slb template policy gg
ACOS(config-policy)#class-list name 2
ACOS(config-policy)#class-list lid 31
ACOS(config-policy-policy lid)#request-limit 10
ACOS(config-policy-policy lid)#request-rate-limit 2 per 100
ACOS(config-policy-policy lid)#exit
ACOS(config-slb vserver-vport)#template policy gg
CLI Examples Not Using Request and Request-rate Limiting

The request limiting and request-rate limiting settings are not used in the following examples:
• Example 1: Policy Template Bound to Virtual Server Instead of Virtual Port
• Example 2: System GLID
• Example 3: System-wide Policy Template
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

Overview
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 g
Configuring Source IP Limiting

To configure source IP limiting:
1. Configure a class list on the ACOS device or another device.
If you configure the class list on another device, import it to the ACOS device.
2. Configure the following IP limiting rules:
• For system-wide IP limiting, configure the rules in a policy template or in standalone IP limiting rules.
• For IP limiting on an individual virtual server or virtual port, configure the rules in a policy template.
3. 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 pol-
icy templates.
• For system-wide source IP limiting, apply the policy template globally.
• For source IP limiting on an individual virtual server or virtual port, apply the policy template to the virtual server or
virtual port.
Clients must comply with all IP limiting rules that are applicable to the client. For example, if you configure system-wide IP
limiting and also configure IP limiting on a virtual server, clients must comply with the system-wide IP limits and with the IP
limits that are applied to the individual virtual server accessed by the client.

Overview
Configuring a Class List

You can configure a class list in one of the following ways:
• Use a text editor to create the list and import the list to the ACOS device.
• Use CLI commands to create the list entries.
For class-list syntax information, see “Class Lists” on page 87.
Using the GUI
Importing a Class List to the ACOS device

1. Click Config Mode > SLB > Service > Class List.
2. Click Import.
3. In Name, enter the filename to use for the imported class list.
4. Select the import location for the file:
• Local – The file is on the computer on which you logged into the GUI or is on another computer in the local net-
work. Proceed to step 5.
• Remote – The file is on a remote server. Proceed to step 7.
5. Click Browse and go to the location of the class list.
6. Click Open and proceed to step 12.
7. To use the management interface as the source interface to connect to the remote device, select Use Management
Port. Otherwise, the ACOS device will attempt to reach the remote server through a data interface.
8. Select a file transfer protocol.
9. In Host, enter the directory path and filename.
10. If necessary, change the protocol port number n the port field.
By default, the default port number for the selected file transfer protocol is used.
11. In the User and Password, enter the username and password that are required to log in to the remote server.
12. Click OK.
Configuring a Class List in the GUI

1. Click Config Mode > SLB > Service > Class List.
2. Click Add.
3. In Name, enter a name for the class list.
4. Select the system location to save the class list:
• File – The list is saved in a stand-alone file.

Overview
• Config – The list is saved in the startup-config.
NOTE: If the class list contains at least 100 entries, you should use the File option. A class list
can be exported only if you use the File option.
5. Configure the class list entries:
a. Enter the IP address and subnet mask.
• For a host entry, use mask 255.255.255.255.

• For a wildcard entry, enter IP address 0.0.0.0 and network mask 0.0.0.0.
b. Specify the IP limiting rule to apply to the host or subnet address.
c. Select the system location of the IP limiting rule:
• Local – The IP limiting rule is configured in a policy template that will be applied to a virtual server or virtual
port.
• Global – The IP limiting rule is configured at the system (global) level and can be shared by all policy templates.
d. Enter the rule number.
NOTE: Ensure that you use the same number when configuring the IP limiting rule.
e. To make the entry temporary, assign an age.
You can specify 1-2000 minutes. The entry is removed from the class list after the age expires.
f. Click Add.
g. Repeat for each entry.
6. Click OK.
NOTE: The Age option applies only to host entries (IPv4 /32 or IPv6 /128) and is not supported
for subnet entries.
Using the CLI
Importing a Class List onto the ACOS device

After the class list is configured, import it to the ACOS device by using the following command at the Privileged EXEC or
global configuration level of the CLI:
import class-list file-name url

Overview
Where:
• The file-name specifies the name that the class list will have on the ACOS device.
• The url specifies the file transfer protocol, username (if required), and directory path.
You can enter the entire URL on the command line or press Enter to display a prompt for each part of the URL. If you enter
the entire URL and a password is required, you will be prompted for the password.
To enter the entire URL, enter one of the following commands:
• tftp://host/file
• ftp://[user@]host[:port]/file
• scp://[user@]host/file
• rcp://[user@]host/file
• http://[user@]host/file
• https://[user@]host/file
• sftp://[user@]host/file
To export class lists to a remote server, enter the following command:
export class-list file-name url
Configuring a Class List in the CLI

To configure a class list in the CLI, enter the following command:
[no] class-list name [file]
Enter this command at the global configuration level of the CLI.
The file option saves the class list as a separate file. Without this option, the class list is saved in the startup-config. If the class
list contains at least 100 entries, use the file option. The option is valid only when you create the class list. After you create
the list, depending on whether you use the file option when you create the list, the list remains in the startup-config or in a
separate file.
NOTE: A class list can be exported only if you use the file option.
The class-list command creates the class list, and if it is not configured, changes the CLI to the configuration level for the list.
[no] ipaddr /network-mask [glid num | lid num]

Overview
Remember the following tips:
• To add an entry to the class list, enter the command without “no”.
• To modify an entry, enter the command without “no”. Use the same source IP address as the entry you plan to modify.
Entries are keyed by source IP address.
• To delete an entry, enter “no” and then the source IP address.
Applying a Class List to a Policy

To apply a class list, enter the following command at the configuration level for the policy that contains the IP limiting rules
that are used by the class list:
[no] class-list name name
After you configure the IP limiting rules and class list and add the class list to the policy, you can activate the IP limits. For
more information, see “Applying Source IP Limits” on page 100.
Configuring the IP Limiting Rules

You can configure IP limiting rules in policy templates that are applied to individual clients or in system-wide IP limiting
rules that are applied to all clients.
• To apply IP limits to individual virtual servers or virtual ports, you must configure the IP limiting rules in a policy tem-
plate, then apply the template to the virtual server or virtual port.
• To apply IP limits on a system-wide basis, you can configure the IP limiting rules in a PBSLB template or in standalone
IP limiting rules.
Using the GUI

You can configure the IP limiting rules by using the web gui.
Configuring IP Limiting Rules in a Policy Template

• Click on an existing template.

• Click Add.
3. If you are creating a new template, enter a name.
4. Configure IP limiting:
a. In the Class List drop-down list, select the class list.
b. Configure the limiting rules to apply to the selected class list.
For additional information about parameters, see “IP Limiting Rules” on page 89.

Overview
5. Leave the Destination IP and Overlap options disabled.
6. Click OK.
Configuring Standalone IP Limiting Rules for System-Wide IP Limiting

To configure standalone IP limiting rules for system-wide IP limiting:
1. Click Config Mode > SLB > Service > GLID.
2. Configure the IP limiting rules.
For parameter information, see “IP Limiting Rules” on page 89.
3. Click OK.
Using the CLI
Configuring IP Limiting Rules in a Policy Template

You can configure IP limiting rules in a policy template by using the CLI.
The following command creates the template and changes the CLI to the configuration level for the template:
[no] slb template policy template-name
Enter this command at the global configuration level of the CLI. For information about the valid values and defaults, see “IP
Limiting Rules” on page 89.
The following command creates an IP limiting rule and changes the CLI to the configuration level for the rule:
[no] class-list lid num
The num option specifies the rule ID and can be 1-31.
The commands in the following section are available at the configuration level for the IP limiting rule.
The following command specifies the maximum number of concurrent connections that are allowed for a client:
[no] conn-limit num
The following command specifies the maximum number of new connections that are allowed for a client during the speci-
fied limit:
[no] conn-rate-limit num per num-of-100ms
The following command specifies the maximum number of concurrent Layer 7 requests allowed for a client:
[no] request-limit num
The following command specifies the maximum number of Layer 7 requests that are allowed for the client during the spec-
ified limit:

Overview
[no] request-rate-limit num per num-of-100ms
The following command specifies the action to take when a client exceeds one or more limits:
[no] over-limit-action [forward | reset]

[lockout minutes] [log minutes]
The command also configures lockout and enables logging.
Configuring IP Limiting Rules for System-Wide IP Limiting (without a class list)

To configure an IP limiting rule for system-wide IP limiting, enter the following commands.
[no] glid num
This command creates the rule and changes the CLI to the configuration level.
The following commands are available at this level:
[no] conn-limit num

[no] conn-rate-limit num per num-of-100ms
[no] request-limit num
[no] request-rate-limit num per num-of-100ms
[no] over-limit-action [forward | reset]
[lockout minutes] [log minutes]
These commands are the same as the commands that are available at the IP limiting rule configuration level in policy tem-
plates. For more information, see “Configuring IP Limiting Rules in a Policy Template” on page 98.
Specifying the Match IP Address

By default, the ACOS device matches class-list entries that are based on the source IP address of client traffic. Optionally, you
can also match based on one of the following items:
• Destination IP address
• IP address in client packet header
To change the match IP address to one of these options, enter the following command at the configuration level for the
PBSLB policy template:
[no] class-list client-ip {l3-dest | l7-header [header-name]}
Where:
• The l3-dest option matches is based on the destination IP address in packets from clients.
• The l7-header [header-name] option matches based on the IP address in the specified header in packets from clients.
• The header-name specifies the name of the header to use. If you do not specify a header name, the X-Forwarded-For
header is used.
NOTE: The destination-ip option applies only to black/white lists.

Overview
Applying Source IP Limits

The following section describes how to apply IP limiting rules to the system or to individual virtual servers or virtual ports.
Using the GUI
Applying System-Wide Source IP Limiting

For system-wide source IP limiting, no additional configuration is required. After you configure at least one stand-alone IP
limiting rule, and apply the rule(s) to class(es), the feature is implemented.
For more information, see the following sections:
• “Configuring a Class List in the GUI” on page 94
• “Configuring Standalone IP Limiting Rules for System-Wide IP Limiting” on page 98
Applying Source IP Limiting to a Virtual Server

1. Click Config Mode > SLB > Service > Virtual Server.
• Click on the virtual server name.

• Click Add.
3. If you are creating a new virtual server, in General Settings, enter the relevant information.
4. In the Policy Template drop-down list, select the policy template.
5. If you are creating a new virtual server, configure the virtual port settings as applicable to your deployment.
6. Click OK.
Applying Source IP Limiting to a Virtual Port

To apply source IP limiting to a virtual port:
1. Go to the configuration page for the virtual server.
For information, see “Applying Source IP Limiting to a Virtual Server” on page 100.
2. On the Virtual Server Port configuration page, in the Policy Template drop-down list, select the policy template.
3. Click OK.
4. When the virtual server configuration is complete, click OK.

Overview
Using the CLI
Applying System-Wide Source IP Limiting

The commands in this section allow you to apply source IP limits to the entire system.
The following command allows you to apply a combined set of limits to the entire system.
[no] system glid num
The following command allows you to apply per-client IP limiting at the system level:
[no] system template policy template-name
Enter the command at the global configuration level of the CLI
NOTE: The ACOS device does not support using the system template policy command and
the system pbslb command in the same configuration.
Applying Source IP Limiting to a Virtual Server

The following command allows you to apply source IP limiting to a virtual server:
Enter the command at the global configuration level for the virtual server.
Applying Source IP Limiting to a Virtual Port
The following command allows you to apply source IP limiting to a virtual port:
Enter the command at the global configuration level for the virtual port.
Displaying IP Limiting Information
Using the GUI

To view configuration information for the feature, go to the configuration pages listed in the previous sections.
To display statistics for the feature, use the CLI.
Using the CLI

To display configuration information for IP limiting, enter the following commands:
show class-list [name [ipaddr]]

show glid [num]

Overview
To display statistics for IP limiting, enter the following commands:
show pbslb
show pbslb system
show pbslb client ipaddr
show pbslb virtual-server virtual-server-name
[port port-num service-type]
To reset statistics counters for IP limiting, enter the following commands:
clear pbslb
clear pbslb system
clear pbslb client ipaddr entry
clear pbslb virtual-server virtual-server-name
[port port-num service-type [group-id group-id]]
CLI Examples—Configuration
The examples in this section show how to configure IP limiting.
Configure 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-global lid)#conn-rate-limit 10000 per 1
ACOS(config-global lid)#conn-limit 2000000
ACOS(config-global lid)#over-limit forward logging
ACOS(config-global lid)#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
Configure 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 name global_list
ACOS(config-policy-policy lid)#conn-rate-limit 20000 per 1
ACOS(config-policy-policy lid)#conn-limit 5000000

Overview
ACOS(config-policy-policy lid)#over-limit reset logging

The following command imports the class list that are used by the policy:
ACOS(config)#import class-list global_list ftp:

Address or name of remote host []?1.1.1.2
User name []?ACOSadmin
Password []?*********
File name [/]?global_list
The following command applies the policy to the system:
ACOS(config)#system template policy global_policy
Configure 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 name vs_list
ACOS(config-policy-policy lid)#conn-rate-limit 200 per 1
ACOS(config-policy-policy lid)#over-limit lockout 10 logging
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 virtual server)#template policy vs_policy

Overview
Configure 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 name vp_list
ACOS(config-policy-policy lid)#request-rate-limit 50 per 1
ACOS(config-policy-policy lid)#request-limit 60000
ACOS(config-policy-policy lid)#over-limit reset logging
The following command imports the class list that is used by the policy:
ACOS(config)#import class-list vp_list ftp:

Password []?*********
File name [/]?vp_list
The following commands apply the policy to a virtual port:
ACOS(config)#slb virtual server vs1

ACOS(config-slb virtual server-slb virtua...)#template policy vp_policy
Configure Class List Entries That Age Out

The following commands configure a class list with 2 host entries, and assign an age value to each entry.
ACOS(config)#class-list local
ACOS(config-class list)#192.168.1.100 /32 lid 30 age 1
ACOS(config-class list)#192.168.1.101 /32 lid 30 age 10
The following commands configure a policy template.
The template includes an LID that sets the connection limit to 0. The LID also resets and logs connection attempts.
ACOS(config)#slb template policy 1

ACOS(config-policy)#class-list name local

Overview
ACOS(config-policy-policy lid)#over-limit-action reset log

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
This section shows sample show command output for IP limiting.
For more details about the output, refer to “Show Commands” in the Command Line Interface Reference.
Class Lists
The following command displays the class-list files on the ACOS device:
ACOS#show class-list
Name IP Subnet Location
test 4 3 file
user-limit 14 4 config
Total: 2
The following command shows details for a class list:
ACOS#show class-list test

Name: test
Total single IP: 4
Total IP subnet: 3
Content:
1.1.1.1 /32 glid 1
2.2.2.2 /32 glid 2
10.1.2.1 /32 lid 1
10.1.2.2 /32 lid 2
20.1.1.0 /24 lid 1
20.1.2.0 /24 lid 2
0.0.0.0 /0 lid 31

Overview
The following commands show the closest matching entries for specific IP addresses in class list “test”:
ACOS#show class-list test 1.1.1.1

1.1.1.1 /32 glid 1
ACOS#show class-list test 1.1.1.2
0.0.0.0 /0 lid 31
The class list contains an entry for 1.1.1.1, so that entry is shown. Since the class list does not contain an entry for 1.1.1.2, but
does contain a wildcard entry (0.0.0.0), the wildcard entry is shown.
IP Limiting Rules
The following command shows the configuration of each standalone IP limiting rule:
ACOS#show glid
glid 1
conn-limit 100
conn-rate-limit 100 per 10
request-limit 1
request-rate-limit 10 per 10
over-limit-action reset log 1
glid 2
conn-limit 20000
request-limit 200
glid 30
conn-limit 10000
over-limit-action forward log
The following command shows the configuration of IP limiting rule 1:
ACOS#show glid 1
glid 1
conn-limit 100
request-limit 1

Overview
IP Limiting Statistics
The following command shows IP limiting statistics for the entire system:
ACOS#show pbslb system

System LID statistics (lid 1):
Current connection: 1
Current connection rate: 0/s
Total over connection limit number: 0
Total over connection rate limit number: 0
System class list statistics:

F = Flag (C-Connection, R-Request), Over-RL = Over rate limit
Source Destination F Current Rate Over-limit Over-RL
---------------+---------------------+-+---------+---------+----------+----------
20.1.2.1 * C 0 0 0 0
Total: 1
The following command shows IP limiting statistics for virtual servers:
ACOS#show pbslb virtual-server

Virtual server class list statistics:
---------------+---------------------+-+---------+---------+----------+----------
1.1.1.1 20.1.11.1:80 R 0 0 0 2
20.1.2.1 20.1.11.1 C 0 0 0 0
20.1.2.1 20.1.11.1:80 C 0 0 0 0
Total: 3
The following command shows IP limiting statistics for clients:
ACOS#show pbslb client

Client class list statistics:
---------------+---------------------+-+---------+---------+----------+----------
1.1.1.1 20.1.11.1:80 R 0 0 0 2
20.1.2.1 * C 0 0 0 0
20.1.2.1 20.1.11.1 C 0 0 0 0
20.1.2.1 20.1.11.1:80 C 0 0 0 0
Total: 4

Overview

ICMP Rate Limiting
ICMP/ICMPv6* rate limiting protects against denial-of-service (DoS) attacks such as Smurf attacks, which consist of floods of
spoofed broadcast ping messages.
ICMP rate limiting monitors the rate of ICMP traffic and drops ICMP packets when the configured thresholds are exceeded.
Configuration
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

ICMP rate limiting filters consist of the following parameters:
• Normal rate – The ICMP normal rate is the maximum number of ICMP packets that are allowed per second.
If the ACOS device receives more than the normal rate of ICMP packets, the excess packets are dropped until the next
one-second interval begins. The normal rate can be 1-65535 packets per second.
• Maximum rate – The ICMP maximum rate is the maximum number of ICMP packets allowed per second before the
ACOS device locks up ICMP traffic.
When ICMP traffic is locked up, all ICMP packets are dropped until the lockup expires. The maximum rate can be 1-
65535 packets per second.
• Lockup time – The lockup time is the number of seconds for which the ACOS device drops all ICMP traffic, after the
maximum rate is exceeded.
The lockup time can be 1-16383 seconds.
NOTE: Specifying a maximum rate (lockup rate) and lockup time is optional. If you do not spec-
ify them, lockup does not occur.
Log messages are generated only if the lockup option is used and lockup occurs. Other-
wise, the ICMP rate-limiting counters are still incremented but log messages are not
generated.
*.
Subsequent references use the term “ICMP rate limiting”. Unless otherwise specified, this term also applies to ICMPv6 rate limiting.

Configuration
NOTE: The maximum rate must be larger than the normal rate.
Using the GUI

Globally configuring ICMP rate limiting
To globally configure ICMP rate limiting:
1. Click Config Mode > Security > Network > ICMP Rate Limiting.
2. Select the ICMP Rate Limiting or ICMPv6 Rate Limiting check box.
3. In Normal Rate, enter the normal rate.
4. In Lockup Rate, enter the maximum rate.
5. In Lockup Period, enter the lockup time.
6. Click OK.
Configuring ICMP rate limiting on an Ethernet interface
To configure ICMP rate limiting on an Ethernet interface:
1. Click Config Mode > Network > Interface.
2. Click an interface name to display the related configuration sections.
5. In Lockup Rate, enter the maximum rate.
7. Click OK.
Configuring ICMP rate limiting in a virtual server template
To configure ICMP rate limiting in a virtual server template:
NOTE: This option applies only to software releases that support SLB.
1. Click Config Mode > SLB > Service > Template > Virtual Server.
• Do one of the following:

• Click on a template name.
• Click Add.

Configuration
4. In LockupStatus, enter the lockup time.
5. In LockupRate, enter the maximum rate.
7. Click OK.
Using the CLI

You can configure an ICMP rate-limiting filter by using the CLI.
Syntax
To configure an ICMP rate-limiting filter, enter one of the following commands:
[no] icmpv6-rate-limit normal-rate lockup max-rate lockup-time
[no] icmp-rate-limit normal-rate lockup max-rate lockup-time
You can enter the commands at any of the following configuration levels:
• Global configuration level
• Configuration level for a physical or virtual Ethernet interface
• Configuration level for a virtual server template
For descriptions of the parameters, see “ICMP Rate Limiting Parameters” on page 109.
To display ICMP rate limiting information, enter the following commands:
show icmp
show icmpv6
show interfaces
show slb virtual-server server-name detail
CLI Example
The following commands configure a virtual server template that sets ICMP rate limiting:
ACOS(config)#slb template virtual-server vip-tmplt

ACOS(config-vserver)#icmp-rate-limit 25000 lock 30000 60

Configuration

HTTP Slowloris Prevention
ACOS helps mitigate against DDoS Slowloris types of attacks in the following ways:
• “Request Packet Size” on page 113
• “Request Header Timeout” on page 113
Request Packet Size

Slowloris attacks may attempt to occupy server sessions by using asymmetric forms of request authentication, such as SSL
handshakes. SSL handshakes require more processing power from the server. In Slowloris type attacks, SSL handshakes are
completed using multiple, small messages that cause the system to run out of buffers. This consumes the server’s resources
so that legitimate clients cannot establish new sessions with the server.
When this feature is enabled, ACOS monitors the size of the request packets and the SSL client queue.While the ACOS device
waits for the request to be completed, the SSL packets are buffered in the client queue. If packets smaller than 512 bytes are
received more than 3 times while the request is not complete, then the session is flagged. Alternatively, if there are more
than 10 packets in the queue with an average packet size smaller than 256 bytes, then the session is flagged. If ACOS is under
buffer pressure, then the session is deleted. By default, this feature is disabled.
This feature applies to both HTTP and HTTPS. The feature thresholds are not configurable.
Using the GUI

This feature is not supported in the GUI.
Using the CLI

To enable ACOS to monitor request packet sizes and the SSL client queue, use the following command at the global config-
uration level:
[no] slb enable-ddos
Request Header Timeout

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.

Request Header Timeout
This option provides security against attacks such as Slowloris attacks, which attempt to consume resources on the target
system by sending HTTP requests in multiple increments, and at a slow rate. The intent of this type of attack is to cause the
target system to consume its buffer resources with the partially completed requests.
The request-header wait time can bet set to 1-31 seconds. The default is 7 seconds.
Using the GUI

On the configuration page for the HTTP template, edit the value in the HTTP Request Header Wait Time field.
Using the CLI

To change the request-header wait time in an HTTP template, use the following command at the configuration level for the
template:
[no] req-hdr-wait-time seconds
NOTE: For many more HTTP security options, see the Web Application Firewall Guide.

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.
• Drops the query
• Forwards the query to another service group – This option is useful if you want to quarantine and examine the mal-
formed queries, while keeping the queries away from the DNS server.
This feature parses DNS queries based on the following RFCs:
• RFC 1034: Domain Names – Concepts and Facilities
• RFC 1035: Domain Names – Implementation and Specification
• RFC 2671 – Extension Mechanisms for DNS (EDNS0)
DNS Sanity Check

DNS security performs a sanity check on DNS client requests and, if applicable, DNS server replies.
Sanity Checking for Virtual-Port Type UDP

DNS sanity checking on virtual-port type UDP is performed only for client requests. For a DNS client request to pass the san-
ity check, all of the following conditions must be met:
• Flags.qr == 0 (first bit in flags)
• Flags.opcode <=5 (bits 2 to 5 in flags)
• Flags.rcode == 0 (last 4 bits in flags)
• qdcount > 0 (questions in DNS header)

Configuration
Sanity Checking for Virtual-Port Type DNS-UDP

DNS sanity checking on virtual-port type DNS-UDP is performed for client requests and server responses.
For a client request to pass the sanity check, all of the following conditions must be met:
• Flags.opcode == 0 (bits 2 to 5 in flags)
• Flags.rcode == 0 (last 4 bits in flags)
• qdcount == 1 (questions in DNS header)
For a server response to pass the sanity check, all of the following conditions must be met:
• Flags.opcode <=5
• Flags.rcode == 0
• qdcount > 0
• ancount > 0 (Answer count)
Configuration
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 GUI
1. Click Config Mode > Security > Template > DNS Firewall > .
2. In Name, enter a template name.
3. Verify that Enabled is selected next to DNS Template.
4. Select Malformed Query.
5. Select the action to take for malformed queries:
• Drop
• Forward to Service group
To use this option, select the service group from the drop-down list.
6. Click OK.

Using the CLI

To configure DNS security, enter the following command at the global configuration level of the CLI:
[no] slb template dns template-name
This command creates the UDP template and changes the CLI to the configuration level for the template.
To enable DNS security and specify the action to take for malformed DNS queries, enter the following command:
[no] malformed-query {drop | forward service-group-name}
Where:
• The drop option drops malformed queries.
• The forward option sends the queries to the specified service group.
Both options block malformed queries from being processed by the DNS virtual port to which the template has been
applied.
This section includes the following examples:
• “DNS Application Firewall Setup” on page 117
• “Service-Group Redirection for DNS “Any” Requests (using aFleX)” on page 118
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 vir-
tual server:
ACOS(config)#slb template dns dns-sec

ACOS(config-dns-policy)#malformed-query drop
ACOS(config-dns-policy)#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)#exit

The following commands bind the service group and DNS template to the DNS virtual port on a virtual server:
ACOS(config)#slb virtual-server dnsvip1 192.168.1.53

ACOS(config-slb vserver)#port 53 udp
ACOS(config-slb vserver-vport)#service-group dns-sec-grp
ACOS(config-slb vserver-vport)#template dns dns-sec
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 sg_rate_limited. DNS requests of
other types are sent to service group sg_no_rate_limit.
when DNS_REQUEST {
set record ANY
if {[DNS::question type] equals $record} {
pool sg_rate_limited
} else {
pool sg_no_rate_limit
}
}

DNSSEC Support
This chapter describes the ACOS device’s DNSSEC support.
Overview
An ACOS device that is configured as a Global Server Load Balancing (GSLB) controller can act as an authoritative DNS server
for a domain zone. As the authoritative DNS server for the zone, the ACOS device sends records in response to requests from
DNS clients. The ACOS device supports the ability to respond to client requests for the following types of records:
• A
• AAAA
• CNAME
• NS
• MX
• PTR
• SRV
• TXT
If you place the ACOS device in the DNS infrastructure, the device is exposed to potential online attacks. When DNS was orig-
inally 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.
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) introduced 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 legitimate servers. The ACOS device’s implementation of DNSSEC is
based on RFCs 4033, 4034, and 4035.
NOTE: DNSSEC for GSLB is not supported in proxy mode for this release.

Overview
DNS Without Security

Figure 20 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 envi-
ronment without DNSSEC.
FIGURE 20 DNS Packet Flow without DNSSEC
A client (shown at upper left) requires access to a server in the domain zone1.example.org (at lower left). The ACOS device,
which is acting as the GSLB controller, is the authoritative DNS server for the zone. To access this server, the client requires the
IP address for this zone or domain.
When the user enters the domain name in the web browser’s URL, the process to obtain the IP address that is associated
with this domain is as follows:
1. The DNS resolver that is embedded in the client’s web browser sends an address request (“A ?”) to the Caching DNS
server to see whether the Caching DNS server has the required IP address cached in its memory for the requested
example.org domain.
2. The Caching DNS server has a list of IP address-to-domain mappings, but the list is not comprehensive, and unfortu-
nately, 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.

Overview
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 subdo-
main.
8. The Caching DNS server has the IP address that is needed to reach the authoritative DNS server for the example.org
domain, so the server sends a request for zone1.example.org to this authoritative DNS server.
9. The authoritative DNS server does not have the requested information, but it can get the Caching DNS server one step
closer to its destination by providing the NS record for the authoritative DNS server for the zone1.example.org domain.
10. The Caching DNS Server sends a request to the authoritative DNS server for the zone1.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.
DNSSEC (DNS with Security)

Figure 21 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 illustrated in Figure 20, but with the notable exception that DNSSEC uses the
following additional resource record types to provide security:
• DNS Key (DNSKEY) – Public key used by an Authoritative DNS server to sign resource records for its zone.
• Delegation Signer (DS) – Hash (message digest) of a public key. A DNS server uses the DS for a zone that is directly
underneath it in the DNS hierarchy to verify that signed resource records from the Authoritative DNS server for that
zone are legitimate.
• Resource Record Signature (RRSIG) – Digitally signs another resource record, such as an A record.
The digital signature is created by applying a hash function to the DNS record to reduce its file size, an encryption algo-
rithm 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 Figure 20 shows how basic DNS works without DNSSEC, Figure 21 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 authoritative server for the desired domain.

Overview
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. For more details, See “Building the Chain of Trust” on page 123.
FIGURE 21 DNS Packet Flow with DNSSEC
Figure 21 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.
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.

Overview
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).
This NS record contains the IP address of the Authoritative DNS server for zone1.example.org.
9. The server sends the DS record for the zone1.example.org server to the Caching DNS server.
10. The Caching DNS server sends the address query to the Authoritative DNS server for zone1.example.org, which happens
to be the ACOS device.
11. The Caching DNS server has reached the Authoritative DNS server for zone1.example.org.
12. 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.
13. The Caching DNS server asks the ACOS device for its DNSKEY record, which is where the public key for the zone is
advertised.
This public key is needed to unlock the resource records and verify the hash values back up the chain.
14. The ACOS device sends its DNSKEY record, with an RRSIG record that was used to sign the DNSKEY record.
The RRSIG record contains the private key.
15. To continue assembling the chain of trust, the Caching DNS server asks the Authoritative DNS server for example.org for
its DNSKEY record.
16. 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.
17. The Caching DNS server asks the TLD server for .org for its DNSKEY record.
18. The TLD server sends its DNSKEY record with an RRSIG record that was used to sign the DNSKEY record.
19. 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

Figure 22 illustrates how the Chain of Trust is built in the DNSSEC infrastructure. A Chain of Trust is built like a series of links,
where each node authenticates the one below it.
The presence of a Chain of Trust allows the client’s DNS resolver to know that all of the DNS servers in the chain have
vouched for one another, starting from the Root DNS Server and continuing down to the lowest-level DNS server.

Overview
FIGURE 22 DNSSEC Chain of Trust
Figure 22 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.
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.

Overview
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.example.org domain is properly linked to the DS record above.
In turn, the DNSKEY record for the Authoritative DNS Server associated with the example.org domain is properly linked to the
DS record above. This process of DNSKEY records being linked with the DS record of the node above continues all the way to
the Root DNS Server.
The client’s DNS resolver knows that the Root DNS Server is legitimate due to the presence of a “trust anchor”. This trust
anchor, which consists of information for the Root DNS Server, is included in the resolver software that is installed on the cli-
ent. This minimizes the chance that a client could access a corrupt root DNS server.
Because of this anchor, the client knows that the Root DNS Server can be trusted, and the client can infer that the other
nodes in the Chain of Trust can also be trusted. The hash values match all the way down the line, which is an indication that
the Chain of Trust is intact, and that the client’s DNS resolver can trust the Authoritative DNS Server for zone1.example.org.
The Server is located at the bottom of the Chain of Trust in the DNS hierarchy.
Dynamic Key Generation and Rollover

DNSSEC uses dynamic key generation and rollover that are provided by HSM, and HSM configuration is required.
Key Generation and Rollover Parameters

When HSM and DNSSEC are enabled, ACOS uses the following key generation and rollover settings for DNSSEC:
• Key size – Length of the keys in bits. You can specify 1024-4096 bits. The default length for ZSKs and KSKs is 2048 bits.
• Lifetime – Maximum amount of time a dynamically generated key remains valid.
• Rollover time – Amount of time to wait after a new key becomes active, before generating that key’s replacement.
The range of values for the lifetime and rollover time is 1 to 2,147,483,647 seconds (about 68 years). The default lifetime and
rollover time differ for ZSKs and KSKs:
• ZSKs – The default lifetime is 7,776,000 seconds (90 days), and the default rollover time is 7,171,200 seconds (83 days).
• KSKs – The default lifetime is 31,536,000 seconds (365 days), and the rollover time is 30,931,200 seconds (358 days).
Key Rollover and Distribution Process
Dynamic key generation and rollover are enabled by default when a DNSSEC template becomes active. No additional config-
uration is required. Figure 23 shows the rekey and rollover schedule if the default rekey and rollover settings for ZSKs and
KSKs are used.

Overview
FIGURE 23 DNSSEC - default rekey and rollover
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.
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 signature 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_k-
sk_2013-07-31-06-48-57 for zone test.com
The first message, starting at the bottom, indicates a successful generation of a KSK for child zone test.com. The next mes-
sage, 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.

Overview
The third message indicates a successful generation of the ZSK for child zone test.com. The final message at the top, indi-
cates 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 per-
formed manually. If the default key generation and rollover settings are used, this pro-
cess needs to be performed once a year.
Importing/Exporting Key Files

The following commands are used to import and export DNSSEC key files:
{export | import} dnssec-ds child-zone-name

{url-profile | {[use-mgmt-port] url}}
{export | import} dnssec-dnskey child-zone-name

{url-profile | {[use-mgmt-port] url}}
After you enable 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 CLI Reference. (The url-profile option is new in ACOS 2.7.1.)
Emergency Key Rollover

The following command allows you to force an immediate key rollover, if necessary:
dnssec key-rollover zone-name

{
KSK {ds-ready-in-parent-zone | start} |
ZSK start
}
Enter the command at the global configuration level of the CLI.
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.
Changing Key Settings

The following commands allow you to change the lifetime and rollover settings for ZSKs and KSKs:
[no] ksk lifetime seconds [rollover-time seconds]
[no] zsk lifetime seconds [rollover-time seconds]
Enter the commands at the configuration level for the DNSSEC template.

Overview
For information about the supported values, see “Key Generation and Rollover Parameters” on page 125.
Hardware Security Module Support

Hardware Security Module (HSM) provides additional security, while simplifying key management.
The current release supports a software emulation version of HSM in ACOS. Keys are generated and stored on the ACOS
device. This version can be useful for testing or for environments where the additional security of a hardware-based HSM is
not required.
HSM is required for DNSSEC, and manual key generation of DNSSEC ZSKs or KSKs is not supported. For information about
external HSM support, contact A10 Networks.
Configuration
To configure DNSSEC:
1. Configure an HSM template.
2. Configure a DNSSEC template.
3. Configure a GSLB policy.
4. Enable this ACOS device to act as the authoritative DNS server for GSLB zones that use the policy.
5. Bind the DNSSEC template to the zone.
The other configuration requirements are the same as the requirements without DNSSEC. For more information, see
the Global Server Load Balancing Guide.
6. Unless the ACOS device is part of a GSLB controller group, enable standalone operation.
7. Configure a VIP to receive DNSSEC requests.
Using the GUI

The current release does not support DNSSEC configuration using the GUI.
Using the CLI
Configuring an HSM Template
The following commands allow you to configure an HSM template.
This command creates the HSM template and changes the CLI to the configuration level for it:
[no] hsm template template-name softHSM
NOTE: The next command is available at this level.

Overview
This command specifies the passphrase (PIN) that will be required to access this HSM instance.
[no] password hsm-passphrase
Configuring a DNSSEC Template
The following commands allow you to configure a DNSSEC template.
The following command creates the template and changes the CLI to the configuration level for it:
[no] dnssec template {default | template-name}
To modify the default DNSSEC template, use the default option. Otherwise, to create a new template, use a different name.
For more information, see “dnssec template” in the Command Line Interface Reference.
Configuring a GSLB Policy
The following commands allow you to configure a GSLB policy and enable server mode.
The following command accesses the configuration level for the policy:
[no] gslb policy {default | policy-name}
NOTE: The following command is available at this level.
The folloiwng command enables server mode, and also enables this ACOS device to be the authoritative DNS server for the
GSLB zones that use this policy.
[no] dns server authoritative ns ptr srv sec
Binding the DNSSEC Template to the Zone
The following command allows you to apply DNSSEC to a zone: u
[no] template dnssec template-name
Enter the command at the configuration level for the zone to bind the DNSSEC template to the zone. The other configura-
tion requirements are the same as the requirements without DNSSEC. For more information, see the Global Server Load Bal-
ancing Guide.
Enabling the Standalone Operation (if GSLB controller group not used)
The following command enables the ACOS device to run DNSSEC without being a member of a GSLB controller group: x
[no] dnssec standalone
Enter the command at the configuration level for the zone to bind the DNSSEC template to the zone.

Overview
Configuring VIP for DNSSEC Requests
The following command allows you to configure a VIP to receive DNSSEC requests:
[no] slb virtual-server name ipaddr
This command creates the virtual server and accesses the configuration level for it.
NOTE: The following command is available at this level.
The following command allows you to add a DNS service port:
[no] port portnum {udp | dns-tcp}
For DNS over UDP, use the udp option. For DNS over TCP, use the dns-tcp option.
Standalone Operation
The ACOS device does not need to be a member of a GSLB controller group to run DNSSEC. GSLB is still required with stand-
alone DNSSEC operation, but configuring a GSLB controller group is not required.
By default, support for standalone DNSSEC operation is optional and is disabled.
Using the GUI

The current release does not support DNSSEC configuration using the GUI.
Using the CLI

The dnssec standalone global configuration command allows you to enable a standalone DNSSEC operation.
Configuration Example
Here is the configuration from a device that is configured for DNSSEC.
hsm template hsm1 softhsm

password encrypted /+mboU9rpJM8EIy41dsA5zwQjLjV2wDnPBCMuNXbAOc8EIy41dsA5zwQjLjV2wDn
!
dnssec template dt1
zsk lifetime 120000 rollover-time 119000
ksk lifetime 240000 rollover-time 220000
signature-validity-period 11
dnskey-ttl 5
hsm hsm1
!
slb virtual-server vs-1 10.105.1.111

Overview
port 53 udp
name _1.1.1.1_UDP_53
gslb-enable
port 53 dns-tcp
name _1.1.1.1_DNS-TCP_53
gslb-enable
!
gslb service-ip vip-1 1.0.0.1
no health-check
port 80 tcp
no health-check
port 21 tcp
!
no health-check
port 80 tcp
no health-check
port 21 tcp
!
no health-check
port 80 tcp
no health-check
port 21 tcp
no health-check
!
gslb service-ip ns 10.10.10.5
no health-check
!
no health-check
port 80 tcp
no health-check
port 21 tcp
no health-check
!
no health-check
port 80 tcp
no health-check
port 21 tcp
no health-check
!

Overview
no health-check
port 80 tcp
no health-check
port 21 tcp
no health-check
!
gslb service-ip vip6-1 2001:111::1
port 80 tcp
port 21 tcp
!
port 80 tcp
port 21 tcp
!
port 80 tcp
port 21 tcp
!
port 80 tcp
port 21 tcp
!
port 80 tcp
port 21 tcp
!
port 80 tcp
port 21 tcp
!
no health-check
!
gslb site local
bw-cost limit 100 threshold 10
slb-dev self 127.0.0.1
vip-server vip6-1
vip-server vip6-2
vip-server vip6-3
ip-server ns
ip-server vip-187
ip-server vip-1
ip-server vip-2
ip-server vip-3

Overview
!
gslb site remote
weight 10
slb-dev site 192.168.217.1
vip-server vip6-4
vip-server vip6-5
vip-server vip6-6
vip-server vip-4
vip-server vip-5
vip-server vip-6
!
!
gslb policy zxie
dns geoloc-alias
dns server authoritative ns ptr srv sec
!
!
gslb zone test.com
policy zxie
template dnssec dt1
service 0
service http www
dns-a-record vip-2 static
!
gslb zone test1.com
policy zxie
template dnssec dt1
service 0
service http www
!
!
dnssec standalone

Overview

Location-Based VIP Access
This chapter contains the following topics:
• Overview of Location-Based VIP Access
• Configuration Using a Class List
• Configuration Using a Black/White List
• Full-Domain Checking
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:
• Send the traffic to a specific service group (if configured using a Black/White list)
ACOS determines a client’s location by looking up the client’s subnet in the geo-location database that is used by Global
Server Load Balancing (GSLB).
NOTE: This feature requires you to load a geo-location database, but does not require any other
configuration of GSLB. The ACOS system image includes the Internet Assigned Numbers
Authority (IANA) database. By default, the IANA database is not loaded but you can eas-
ily load it. For more information, see “Loading the IANA Geo-Location Database” on
page 139.

Configuration Using a Class List
Configuration Using a Class List

This section show how to configure the geo-location-based VIP access by using a class list.
The following example class list maps client geo-locations to limit IDs (LIDs), which specify the maximum number of concur-
rent connections allowed for clients in the geo-locations.
L US 1
L US.CA 2
L US.CA.SJ 3
The following commands import the class list to the ACOS device, configure a policy template, and bind the template to a
virtual port. The connection limits specified in the policy template apply to 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:

File name [/]?c-share
Importing ... Done.
ACOS(config)#slb template policy pclass
ACOS(config-policy)#class-list name c-share
ACOS(config-policy-policy lid)#class-list lid 2
ACOS(config-policy-policy lid)#class-list lid 3
ACOS(config-policy)#geo-location overlap
ACOS(config)#slb virtual-server vip1 10.1.1.155
ACOS(config-slb vserver-vport)#template policy pclass
ACOS(config-slb vserver-vport)#exit
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

Configuration Using a Black/White List
v = Exact Match, x = Fail

Virtual Server: vip1/80, c-share
--------------------------------------------------------------------------------
max Depth: 3
Success: 3
Geo-location M ID Permit Deny Conn Last
--------------------------------------------------------------------------------
US.CA.SJ v 3 1 1 1 77.1.1.107
--------------------------------------------------------------------------------
Total: 1

To configure geo-location-based access control for a VIP:
1. Configure a Black/White list.
You can configure the list by using a text editor or enter the list into the GUI. If you configure the list by using a text edi-
tor, 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” on
page 139.
4. Apply the policy template to the virtual port for which you want to control access.
Configuring the Black/White List

You can configure Black/White lists in one of the following ways:
• Remote – Use a text editor and import the list to the ACOS device.
• Local – Enter the black/white list in a management GUI window.
With both methods, the syntax is the same. The Black/White list must be a text file that contains entries (rows) in the follow-
ing format:
L "geo-location" group-id #conn-limit

The various parameters in the syntax are described in Table 3.
TABLE 3 Black/White List Syntax Description

Parameter Description
L Indicates that the client’s location will be determined by using information in the geo-location
database.
geo-location String in the geo-location database that is mapped to the client’s IP address, for example, “US”,
“US.CA”, or “US.CA.SanJose”.
group-id Number from 1 to 31 that identifies a group of clients (geo-locations) in the list. The default
group ID is 0, which means no group is assigned. On the ACOS device, the group ID specifies the
action to perform on client traffic.
#conn-limit Maximum number of concurrent connections allowed from a client. The # is required only if you
do not specify a group ID. The connection limit is optional. For simplicity, the examples in this
section do not specify a 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 to Configure a Black/White List

This section contains the following topics:
• Configuring or Importing a Black/White List
• Configuring an SLB policy (PBSLB) template
• Loading the IANA Geo-Location Database
• Applying the Policy Template to a Virtual Port
Configuring or Importing a Black/White List

To configure or import a black/white list by using the GUI:
1. Click Config Mode > SLB > Black-White List.
2. Click Add.
3. Complete one of the following tasks:
To import the list:
a. Leave Remote selected.
b. In Name, enter a name for the list.
c. In Host, enter the hostname or IP address.
d. In Location, enter the file path and name.

To enter the file directly into the GUI:
a. Select Local.
b. In Definition, enter the list.
4. Click OK.
Configuring an SLB policy (PBSLB) template

To configure an SLB policy template:
2. Click Add.
3. In Name, enter a template name.
4. In the Black-White List drop-down list, select a list.
5. In the Group ID drop-down list, select an ID.
6. In the Action drop-down list, select an action:
• Drop – Drops new connections until the number of concurrent connections on the virtual port falls below the
port’s connection limit. (The connection limit is set in the black/white list.)
• Reset – Resets new connections until the number of concurrent connections on the virtual port falls below the
connection limit.
• service-group-name – Each of the service groups configured on the ACOS device is listed.
• Create – This option displays the configuration sections for creating a new service group.
7. Optionally, enable logging.
The ACOS device uses the same log rate limiting and load balancing features for PBSLB logging as those used for ACL
logging. For more information, see the “Log Rate Limiting” section in the “Basic Setup” chapter of the System Configura-
tion and Administration Guide.
8. Click Add.
9. Repeat step 5 through step 8 for each group ID.
10. Click OK.
Loading the IANA Geo-Location Database

To load the IANA geo-location database:
1. Click Config Mode > GSLB > Geo-location > Import.
2. In Load/Unload, in File, enter iana.
3. Leave Template blank.
4. Click Add.

NOTE: You can also import a custom geo-location database. For information, see the Thunder
Series Global Server Load Balancing Guide.
Applying the Policy Template to a Virtual Port

To apply the policy template to a virtual port:
1. Click Config Mode > SLB > Service > Virtual Server.
• Select the virtual server.

• Click Add.
3. If you are configuring a new VIP, enter the name and IP address for the server.
4. In Port, do one of the following:
• Select the port and click Edit.

• Click Add.
5. In the PBSLB Policy Template drop-down list, select the policy template.
6. Click OK and then OK again.
Using the CLI to Import a Black/White List

To import a Black/White list using the CLI:
1. Enter the import bw-list command at the global configuration level of the CLI. The following command imports
the Black/White list named “geolist” onto the ACOS device.
ACOS(config)#import bw-list geolist scp://192.168.1.2/root/geolist
2. Enter the slb template policy command to create the PBSLB template, then use the bw-list commands to con-
figure the Black-White list options. The following commands configure a policy template named “geoloc” and add the
Black/White list “geolist” to the template. 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
3. 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
ACOS(config-slb vserver-vport)#show slb geo-location

Full-Domain Checking
Viewing and Clearing SLB Geo-Location Information

To display SLB geo-location information, enter the show slb geo-location command.
To clear SLB geo-location statistics, enter the clear slb geo-location command.
For more information about these commands, refer to the Command Line Interface Reference.
By default, when a client requests a connection, the ACOS device checks the connection count only for the specific geo-
location level of the client. If the connection limit for that specific geo-location level has not been reached, the client’s con-
nection is permitted. Similarly, the permit counter is increased only for that specific geo-location level.
Table 4 shows an example set of geo-location connection limits and current connections.
TABLE 4 Geo-location connection limit example

Geo-location Connection Limit Current Connections
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:
• US – Deny counter is increased by 1.
• US.CA – Permit counter is increased by 1.
• US.CA.SanJose – Permit counter is increased by 1.
When full-domain checking is enabled, the ACOS device checks the current connection count not only for the client’s spe-
cific geo-location, but for all geo-locations higher up in the domain tree.
Based on full-domain checking, all three connection requests from the clients in the example above are denied. This is
because the US domain has reached its connection limit. Similarly, the counters for each domain are updated as follows:
• US – Deny counter is incremented by 1.
• US.CA – Deny counter is incremented by 1.
Using the GUI

This is configurable on the configuration page for the policy template. Click Config Mode > Security > Template > Policy.

Using the CLI

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.
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 incor-
rect.
Enabling PBSLB Statistics Counter Sharing

You can enable sharing of statistics counters for all virtual servers and virtual ports that use a PBSLB template. This option
causes the following counters to be shared by the virtual servers and virtual ports that use the template:
• Permit
• Deny
• Connection number
• Connection limit
Using the GUI

This is configurable on the configuration page for the policy template. Click Config Mode > Security > Template > Policy.
Using the CLI

To enable the share option, enter the geo-location share command at the configuration level for the PBSLB policy tem-
plate:
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 incor-
rect.


1
Document No.: 272-P8-AAM-DMG-001 | 6/14/2016

A10 2.7.2-P8 AAM DMG Jun14 2016

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

A10 2.7.2-P8 AAM DMG Jun14 2016

Uploaded by

Copyright:

Available Formats

APPLICATION ACCESS MANAGEMENT AND DDoS MITIGATION GUIDE

A10 Thunder Series and AX Series

A10 Networks Inc. Software License and End User Agreement

2. sublicense, rent or lease the Software.

Application Access Management .......................................................................................................13

AAM with LDAP .........................................................................................................................................23

page 3 | Document No.: 272-P8-AAM-DMG-001 - 6/14/2016

AAM with RADIUS ....................................................................................................................................33

AAM with OCSP .........................................................................................................................................39

AAM with Kerberos ..................................................................................................................................45

IP Anomaly Filtering ................................................................................................................................55

Policy-Based SLB .......................................................................................................................................59

Document No.: 272-P8-AAM-DMG-001 - 6/14/2016 | page 4

Configuring System-Wide PBSLB................................................................................................................62

SYN Cookies ...............................................................................................................................................75

page 5 | Document No.: 272-P8-AAM-DMG-001 - 6/14/2016

CLI Examples Using Request and Request-Rate Limiting ....................................................................................91

ICMP Rate Limiting ............................................................................................................................... 109

HTTP Slowloris Prevention ................................................................................................................. 113

DNS Application Firewall .................................................................................................................... 115

Document No.: 272-P8-AAM-DMG-001 - 6/14/2016 | page 6

Service-Group Redirection for DNS “Any” Requests (using aFleX) ........................................................................118

DNSSEC Support .................................................................................................................................... 119

Location-Based VIP Access ................................................................................................................. 135

page 7 | Document No.: 272-P8-AAM-DMG-001 - 6/14/2016

Document No.: 272-P8-AAM-DMG-001 - 6/14/2016 | page 8

Application Access Management

AAM includes the following features:

For more information about AAM, see the following chapters:

• “Application Access Management” on page 13

• “AAM with LDAP” on page 23

• “AAM with RADIUS” on page 33

• “AAM with OCSP” on page 39

• “AAM with Kerberos” on page 45

page 9 | Document No.: 272-P8-AAM-DMG-001 - 6/14/2016

Online Certificate Status Protocol

Document No.: 272-P8-AAM-DMG-001 - 6/14/2016 | page 10

ICMP Rate Limiting

Web Application Firewall

• Incoming user requests

• Output from Web servers

• Access to Web site content

page 11 | Document No.: 272-P8-AAM-DMG-001 - 6/14/2016

DNS Application Firewall

Geo-location-based VIP Access

• Drop the traffic

• Reset the connection

Document No.: 272-P8-AAM-DMG-001 - 6/14/2016 | page 12

This chapter helps you understand Application Access Management (AAM).

AAM Security Solutions

FIGURE 1 Service Access Management example

page 13 | Document No.: 272-P8-AAM-DMG-001 - 6/14/2016

1. A client sends an HTTP request to a VIP that is managed by ACOS.

3. The client sends the username and password to ACOS.

4. Authentication Relay forwards the request to an external AAA server.

5. Authentication Relay receives the reply.

7. The server sends the reply to ACOS.

Basic HTTP Login

Document No.: 272-P8-AAM-DMG-001 - 6/14/2016 | page 14

WWW-Authenticate: Basic realm=”realm-name”

Authorization: Basic QTEwOlRodW5kZXI=

Where To Find Deployment Examples

• “Basic HTTP Login with RADIUS” on page 33