A10 2.7.1-GR1 AAM DMG Apr14 2015

Application
Access Management and
DDoS Mitigation Guide
A10 ThunderTM Series and AX Series
Document No.: D-030-01-00-0060

ACOS 2.7.1-GR1 4/14/2015
©
A10 Networks, Inc. 4/14/2015 - All Rights Reserved
Information in this document is subject to change without notice.
Trademarks
The A10 logo, A10 Harmony, A10 Lightning, A10 Networks, A10 Thunder, aCloud, ACOS, ACOS Policy Engine, Affin-
ity, aFleX, aFlow, aGalaxy, aVCS, aXAPI, IDaccess, IDsentrie, IP-to-ID, SSL Insight, 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.
Patents Protection
A10 Network products including all AX Series products are protected by one or more of the following U.S. patents:
8977749, 8943577, 8918857, 8914871, 8904512, 8897154, 8868765, 8849938, 8826372, 8813180, 8782751, 8782221,
8595819, 8595791, 8595383, 8584199, 8464333, 8423676, 8387128, 8332925, 8312507, 8291487, 8266235, 8151322,
8079077, 7979585, 7804956, 7716378, 7665138, 7647635, 7627672, 7596695, 7577833, 7552126, 7392241, 7236491,
7139267, 6748084, 6658114, 6535516, 6363075, 6324286, 5931914, 5875185, RE44701, 8392563, 8103770, 7831712,
7606912, 7346695, 7287084, 6970933, 6473802, 6374300.
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. This information may contain forward looking statements and therefore is subject to change.
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 Software 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 infor-
mation is provided "as-is." The product specifications and features described in this publication are based on the latest
information available; however, specifications are subject to change without notice, and certain features may not be avail-
able 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 contact the manufacturer of that component. Always consult local authorities for regulations regarding proper dis-
posal of electronic components in your area.
Further Information
For additional information about A10 products, terms and conditions of delivery, and pricing, contact your nearest A10
Networks location, which can be found by visiting www.a10networks.com.
A10 Thunder Series and AX Series—AAM and DDoS Mitigation Guide
Contents
Introduction 11
Overview................................................................................................................................................ 11
Application Access Management .................................................................................................... 11
Online Certificate Status Protocol ............................................................................................... 12
DDoS Mitigation .............................................................................................................................. 12
Policy-based SLB ........................................................................................................................ 12
SYN Cookies ............................................................................................................................... 12
IP Limiting .................................................................................................................................... 13
ICMP Rate Limiting ..................................................................................................................... 13
Web Application Firewall ............................................................................................................. 13
Slowloris Prevention .................................................................................................................... 14
DNS Application Firewall ............................................................................................................. 14
DNSSEC ..................................................................................................................................... 14
SSL Insight .................................................................................................................................. 14
Geo-location-based VIP Access .................................................................................................. 15
Application Access Management 17

AAM Security Solutions....................................................................................................................... 17
Logon Portal.......................................................................................................................................... 18
Basic HTTP Login ........................................................................................................................... 19
Where To Find Deployment Examples ........................................................................................ 19
Form-based Login ........................................................................................................................... 19
Page Types Used by Form-based Login ..................................................................................... 20
Logon Failure Message Enhancements ......................................................................................... 22
Error Message Customization ............................................................................................................. 23
Deployment Examples ................................................................................................................ 24
Authentication Relay ............................................................................................................................ 24
Where To Find Deployment Examples ........................................................................................ 24
Authorization Based on URI ................................................................................................................ 25
Configuration Overview .................................................................................................................. 25
ACOS Device Configuration ........................................................................................................ 25
Configuration on RADIUS Server ................................................................................................ 25
Configuration on LDAP Server .................................................................................................... 26
AAM with LDAP 29

Overview................................................................................................................................................ 29
LDAP Login Formats ...................................................................................................................... 29
Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015 5 of 224

Contents
Logon Proxy ..........................................................................................................................................30
Configuration Resources ................................................................................................................ 32
Authentication Relay.............................................................................................................................35
AAM with RADIUS 39

Basic HTTP Logon with RADIUS .........................................................................................................39
Form-based Logon with RADIUS.........................................................................................................42
AAM with OCSP 45

Overview ................................................................................................................................................45
Certificate Verification Process ...................................................................................................... 45
ACOS Verification of Replies from OCSP Responder ................................................................... 46
One OCSP Server ..................................................................................................................................46
Multiple OCSP Servers .........................................................................................................................48
AAM with Kerberos Relay 51

Overview ................................................................................................................................................51
Basic HTTP Login .......................................................................................................................... 52
Form-based Login .......................................................................................................................... 53
OCSP ............................................................................................................................................. 54
Authentication Relay with Kerberos ............................................................................................... 55
Configuration.........................................................................................................................................55
Kerberos Terminology Related to AAM...............................................................................................60
IP Anomaly Filtering 61
Overview ................................................................................................................................................61
IP Anomaly Filters for System-Wide PBSLB .................................................................................. 62
Notes .............................................................................................................................................. 63
6 of 224 Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015

Contents
Configuration ........................................................................................................................................ 64
Displaying IP Anomaly Statistics ........................................................................................................ 65
Policy-based SLB 67
Overview................................................................................................................................................ 67
Configuring a Black/White List............................................................................................................ 68
Example Black/White List ............................................................................................................... 69
Dynamic Black/White-list Client Entries .......................................................................................... 69
Connection Limit for Dynamic Entries ............................................................................................. 70
Aging of Dynamic Entries ............................................................................................................... 70
Wildcard Address Support in PBSLB Policies Bound to Virtual Ports ............................................ 71
Configuring System-Wide PBSLB....................................................................................................... 71
Displaying and Clearing System-Wide PBSLB Information ............................................................ 73
Configuring PBSLB for Individual Virtual Ports ................................................................................ 73
Displaying PBSLB Information............................................................................................................ 81
Configuration Examples ...................................................................................................................... 81
Example—Sockstress Attack Protection ........................................................................................... 82
System-wide PBSLB Policy Configuration ...................................................................................... 83
Statistics Display ......................................................................................................................... 83
SYN Cookies 87
Overview................................................................................................................................................ 87
SYN Flood Attacks .......................................................................................................................... 87
SYN Flood Attack Counter .............................................................................................................. 88
How ACOS Identifies SYN Flood Attacks ....................................................................................... 88
ACOS SYN-cookie Protection ........................................................................................................ 89
Dynamic SYN Cookies ................................................................................................................... 90
SYN Cookie Buffering ..................................................................................................................... 90
SACK and MSS with Software-based SYN-cookies ....................................................................... 91
SACK ........................................................................................................................................... 91
MSS ............................................................................................................................................. 91
Configurable MSS Source for Proxied SLB Traffic............................................................................ 91
Configuration ........................................................................................................................................ 92
Enabling SYN-cookie Support ........................................................................................................ 92
Configuration with Target VIP and Client-side Router in Different Subnets ................................... 95

Contents
Configuring Layer 2/3 SYN Cookie Support for Data Interfaces .................................................... 96
Configuring SYN-cookie Buffering .................................................................................................. 97
SYN Cookie Time Interval Statistics....................................................................................................98
Displaying SYN-cookie Statistics ................................................................................................... 99
IP Limiting 105
Overview ..............................................................................................................................................105
Class Lists .................................................................................................................................... 105
Class List syntax ....................................................................................................................... 106
IP Address Matching ................................................................................................................. 107
Example Class Lists .................................................................................................................. 107
IP Limiting Rules .......................................................................................................................... 108
Match IP Address ...................................................................................................................... 109
Request Limiting and Request-rate Limiting in Class Lists ....................................................... 110
Configuring Source IP Limiting .........................................................................................................112
Configuring a Class List ............................................................................................................... 113
Configuring the IP Limiting Rules ................................................................................................. 116
Applying Source IP Limits ............................................................................................................ 120
Displaying IP Limiting Information ................................................................................................ 122
CLI Examples—Configuration ...................................................................................................... 123
Configure System-Wide IP Limiting With a Single Class .......................................................... 123
Configure System-Wide IP Limiting With Multiple Classes ....................................................... 123
Configure IP Limiting on a Virtual Server .................................................................................. 124
Configure IP Limiting on a Virtual Port ...................................................................................... 124
Configure Class List Entries That Age Out ............................................................................... 125
CLI Examples—Display ................................................................................................................ 126
Class Lists ................................................................................................................................. 126
IP Limiting Rules ....................................................................................................................... 127
IP Limiting Statistics .................................................................................................................. 128
ICMP Rate Limiting 131

Configuration.......................................................................................................................................131
HTTP Slowloris Prevention 135

Overview ..............................................................................................................................................135
Log DDoS Attack Detection Events 137

Overview ..............................................................................................................................................137

Contents
DNS Application Firewall 139
Overview.............................................................................................................................................. 139
DNS Sanity Check............................................................................................................................... 140
Sanity Checking for Virtual-Port Type UDP ............................................................................... 140
Sanity Checking for Virtual-Port Type DNS-UDP ...................................................................... 140
Configuration ...................................................................................................................................... 141
Configuration Examples .................................................................................................................... 142
DNS Application Firewall Setup .................................................................................................... 142
Service-group Redirection for DNS “Any” Requests (using aFleX) .............................................. 143
DNSSEC Support 145

Overview.............................................................................................................................................. 145
DNS without Security .................................................................................................................... 146
DNSSEC (DNS with Security) ...................................................................................................... 149
Building the Chain of Trust ........................................................................................................... 152
Dynamic Key Generation and Rollover ......................................................................................... 155
Key Generation and Rollover Parameters ................................................................................. 155
Importing/Exporting Key Files ................................................................................................... 157
Emergency Key Rollover ........................................................................................................... 157
Changing Key Settings .............................................................................................................. 158
Hardware Security Module Support .............................................................................................. 158
Configuration ................................................................................................................................ 158
Standalone Operation ................................................................................................................... 162
Configuration Example ................................................................................................................. 163
SSL Insight 167

Overview.............................................................................................................................................. 167
SSL Operation .............................................................................................................................. 169
SSL Operation on Inside ACOS device ..................................................................................... 170
Packet Flow for SSL Insight ...................................................................................................... 172
Configuration ...................................................................................................................................... 174
Virtual Ethernet Interfaces ......................................................................................................... 174
Wildcard VIPs ............................................................................................................................... 175
Traffic Flow Through Wildcard VIPs .......................................................................................... 176
Wildcard VIPs on Inside ACOS Devices ................................................................................... 176
Wildcard VIPs on Outside ACOS devices ................................................................................. 178
Access Control Lists .................................................................................................................. 179
Service Groups .......................................................................................................................... 180
Configuring SSL Insight ................................................................................................................ 181

Contents
GUI Configuration ......................................................................................................................... 182
CLI Configuration ................................................................................................................................182
Configuring the Inside ACOS devices .......................................................................................... 182
Enabling Promiscuous VIP Mode on Ethernet Interfaces ......................................................... 183
Importing the Root CA-signed Certificate for the Content Servers ........................................... 183
Configuring the Client-SSL Template ........................................................................................ 184
Configuring the Paths Through the Traffic Inspection Devices ................................................. 184
Configuring the Wildcard VIPs .................................................................................................. 185
Configuring the Outside ACOS devices ....................................................................................... 187
Enabling Promiscuous VIP Mode on Ethernet Interfaces ......................................................... 187
Configuring the Paths Through the Traffic Inspection Devices ................................................. 187
Configuring the Service Groups for the Gateway Router .......................................................... 188
Configuring the Server-SSL Template ...................................................................................... 188
Configuring the Wildcard VIPs .................................................................................................. 188
Displaying Certificate Hash Entries .............................................................................................. 190
Configuration Example .......................................................................................................................190
CLI Example—Inside ACOS devices ........................................................................................... 191
Inside the Primary ACOS Device .............................................................................................. 191
Inside Secondary ACOS device ................................................................................................ 195
Outside Primary ACOS device .................................................................................................. 199
Outside Secondary ACOS device ............................................................................................. 203
SSL Insight Bypass.............................................................................................................................206
Configuration ................................................................................................................................ 206
Location-based VIP Access 211

Overview ..............................................................................................................................................211
Configuration Using a Class List.......................................................................................................211
Configuration by Using a Black/White List.......................................................................................213
Configuring the Black/White List .................................................................................................. 214
Full-Domain Checking ........................................................................................................................219
Enabling PBSLB Statistics Counter Sharing ................................................................................ 221

Introduction - Overview
Introduction
Overview
ACOS includes the following security features to help you protect your cus-
tomer traffic:
Application Access Management

Application Access Management (AAM) optimizes Authentication, Autho-
rization, and Accounting (AAA) for client-server traffic and includes the
following features:
• Logon Portal – A single sign-on interface for end-users. ACOS obtains
the end-user’s credentials through a basic HTTP request-reply exchange
or using a web-based form and uses a backend AAA server to verify the
credentials.
• Online Certificate Status Protocol (OCSP) – A network component that
provides certificate verification services. OCSP eliminates the need to
import certificate revocation list (CRL) files to the ACOS device.
Instead, the CRLs are maintained on the OCSP responder (server).
When a client sends its certificate as part of a request for a secured ser-
vice, ACOS sends the certificate to the OCSP responder for verification,
before allowing the client to access secured services.
• Authentication Relay – Offloads your AAA servers. ACOS contacts
backend AAA servers on behalf of clients. After a server responds,
ACOS caches the reply and uses the cached reply for subsequent client
requests.
• AAA Health Monitoring and Load Balancing – Uses ACOS SLB to load
balance authentication traffic among a group of AAA servers. ACOS
supports custom health checks for LDAP, RADIUS, Kerberos, and
OCSP.
For more information, see the following chapters:

• “Application Access Management” on page 17
• “AAM with LDAP” on page 29
• “AAM with RADIUS” on page 39

• “AAM with OCSP” on page 45
• “AAM with Kerberos Relay” on page 51
Online Certificate Status Protocol
Online Certificate Status Protocol (OCSP) is a network component that pro-

vides certificate verification services.
OCSP provides an efficient alternative to certificate revocation lists (CRLs),

also supported by ACOS. To use CRLs with ACOS, you must import the
CRL files to the ACOS device. However, if you use OCSP, ACOS sends
certificate verification queries to external OCSP servers that are also known
as responders. This process when a client sends a certificate as part of a
request to set up a secure session to a server application that is managed by
ACOS.
For more information, see “AAM with OCSP” on page 45.
DDoS Mitigation
Distributed Denial of Service (DDoS) is a type of DoS attack where multi-
ple systems that are infected with a Trojan or malware are used to target a
particular system, which causes a denial of service. A DoS attack is when a
hacker (attacker) mounts an attack from one host. In contrast, 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, see “IP Anomaly Filtering” on page 61.
Policy-based SLB
Policy-based SLB (PBSLB) allows you to “black list” or “white list” indi-
vidual 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, see “Policy-based SLB” on page 67.
SYN Cookies
SYN cookies provide protection against a common type of DDoS attack, the
TCP SYN flood attack. To conduct this type of attack, the attacker sends a

high volume of TCP-SYN requests to the target device but does not reply to
SYN-ACKs to complete the three-way handshake for any of the sessions.
The intent of the attack is to consume the target’s resources with half-open
TCP sessions.
When SYN cookies are enabled, the ACOS device can continue to serve
legitimate clients during TCP SYN flood attacks and prevent illegitimate
traffic from consuming system resources.
For more information, see “SYN Cookies” on page 87.
IP Limiting
IP limiting provides a greatly enhanced implementation of the source IP

connection limiting and connection-rate limiting feature that was available
in previous releases.
For more information, see “IP Limiting” on page 105.
ICMP Rate Limiting

ICMP rate limiting protects against ICMP-based or ICMPv6-based 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.
For more information, see “ICMP Rate Limiting” on page 131.
Web Application Firewall

ACOS provides additional security for your web servers with a Web Appli-
cation Firewall (WAF). WAF filters communication between end-users and
Web applications to protect web servers and sites from unauthorized access
and malicious programs. This new layer of security examines incoming user
requests, output from web servers, and access to web site content to safe-
guard against Web attacks and protect sensitive information hosted on web
servers.
For more information, see the Web Application Firewall Guide.

Slowloris Prevention
In addition to WAF, ACOS includes an HTTP security option that prevents
Slowloris attacks, where the attacker attempts to consume resources on the
target system with incomplete HTTP request headers.
For more information, see “HTTP Slowloris Prevention” on page 135.
DNS Application Firewall

DNS Application Firewall (DAF) 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, see “DNS Application Firewall” on page 139.
DNSSEC
ACOS supports DNS Security Extensions (DNSSEC). In Global Server
Load Balancing (GSLB) deployments, you can use DNSSEC with Hard-
ware Module Security (HSM) to dynamically secure DNS resource records
for GSLB zones.
For more information, see “DNSSEC Support” on page 145.
Note: ACOS also supports DNS caching for DNSSEC, but DNSSEC support
for caching does not require GSLB.
SSL Insight
SSL Insight (previously known as SSL Intercept) provides high-perfor-

mance SSL decryption and re-encryption. When used with third-party traf-
fic inspection devices, SI adds content-level security.
SI 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 encrypted again by ACOS and is forwarded to its desti-
nation.
For more information, see “DNS Application Firewall” on page 139.

Geo-location-based VIP Access
Geo-location-based VIP access controls access to a VIP, based on the cli-
ent’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
• Send the traffic to a specific service group, if configured by using a

black/white list
ACOS determines a client’s location by looking up the client’s subnet in the

geo-location database used by Global Server Load Balancing (GSLB).
For more information, see “Location-based VIP Access” on page 211.


Application Access Management - AAM Security Solutions
Application Access Management
This chapter describes Application Access Management (AAM).
AAM Security Solutions

You can use AAM features for a variety of AAA optimization solutions.
Figure 1 shows a high-level example of this solution.
FIGURE 1 Service Access Management example
In this example, authentication relay, a Logon Portal, AAA health monitor-

ing, and load balancing are used together.

Application Access Management - Logon Portal
Traffic Walkthrough
Figure 1 shows the following traffic exchange, which is initiated by a client
that is sending an HTTP request 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 Logon Portal on the ACOS device intercepts the request and sends a
login page to the client.
3. The client sends the login credentials (username and password) to

ACOS.
4. An authentication proxy forwards the request to an external AAA

server.
If a service group of AAA servers is configured, the group’s load-bal-
ancing method is used to select a AAA server, and the request is for-
warded 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 is expected to contain this
cookie in the HTTP request header.
Logon Portal
The Logon Portal provides one interface that end-users can log in to and
complete a variety of tasks.
The Logon Portal provides the following ways to collect user credentials:
• Basic HTTP – The Logon 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 Logon Portal uses a set of web pages to collect user
credentials.
In both portal types, ACOS sends the credentials from the end-user to a
backend AAA server for authentication.
Note: You can change your password by using the end-user password change
through the Logon Portal only for LDAP. For more information, see
“AAM with LDAP” on page 29.
Basic HTTP Login

Basic HTTP login allows ACOS to obtain an end-user’s username and pass-
word 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 response code:
WWW-Authenticate: Basic realm=”realm-name”
The client browser displays a login window in which end-users can enter
their username and password. After end-users enter their credentials, the cli-
ent browser sends 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:
• “Basic HTTP Logon with RADIUS” on page 39
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 entering the relevant information
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 Logon Portal

Page Type Description
Login Sent by ACOS to the client in response for a request to
secure services.
Login Failure Sent by ACOS to the client when authentication fails.
Password Change Sent by ACOS to the client to allow the password to be
changed when the client password is found on LDAP
server but has expired.
The files for these pages must be imported to the ACOS device. You can
import the files in archive files of any of the following formats:
• zip
• tgz
• tar
Note: By default, ACOS does not include Login Portal web pages. However,
Figure 2 and Figure 4 are some examples of some simple pages.
Example of a Simple Logon Page

Figure 2 is an example of a simple logon page.
FIGURE 2 Logon page (example)

Note: The Logon form that is used for form-based authentication includes an
error message that is displayed when the previous attempt to log on fails.
In previous releases, the same form was displayed but contained only the
username and password fields.
You can customize the error message string that is included in the Logon
form.
Figure 3 is the source code for the logon page.
FIGURE 3 Logon page source (example)
Example Logon Failure Page

Figure 4 is an example of a login failure page that is sent to the client if the
end-user credentials are not valid.
FIGURE 4 Logon failure page (example)

Figure 5 shows the source code for the login failure page.
FIGURE 5 Logon failure page source (example)
Logon Failure Message Enhancements

The error page that is returned by ACOS to a client when an end-user could
not be authenticated includes fields in which end-users can enter their user-
name and password again.
Figure 6 is an example of the source code for the page.
FIGURE 6 Login Error Page for Form-based Logon
<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 commented out as

shown above, ACOS includes the logon failure message in the form only
when applicable. If a client logon failure occurs, ACOS inserts a message
and negates the HTML comment in the form that is sent to the client, which

Application Access Management - Error Message Customization
makes the message visible on the new logon page that is presented to the
client.
The default error message string for login failures is Invalid username or
password. Please try again.
Error Message Customization

You can customize the error message string that is returned in logon forms
and include up to 127 characters.
To customize the error message for the form-based authentication-logon

profile, enter the following command:
[no] login-failure-message message-string
Change Password Page

Figure 7 is an example of password-change page that is sent to the client
when the username is valid, but the password has expired.
FIGURE 7 Change Password page (example)
Figure 8 shows the source code for the Change Password page.

Application Access Management - Authentication Relay
FIGURE 8 Change Password page source (example)
Deployment Examples
For examples of AAM deployments that use form-based login, see the fol-
lowing sections or chapters:
• “Form-based Logon with RADIUS” on page 42
• “AAM with LDAP” on page 29
Authentication Relay
Authentication relay provides a backend logon service on behalf of authen-
ticated clients.
ACOS uses backend AAA servers to authenticate a client’s initial request. If

authentication is successful, ACOS logs in to load-balanced services for
which the client is authorized, when those services are requested by the cli-
ent. End-users do not need to enter their credentials again.
Where To Find Deployment Examples
For more information and deployment examples, see the following sections:
• “Authentication Relay” on page 35
• “Authentication Relay with Kerberos” on page 55

Application Access Management - Authorization Based on URI
Authorization Based on URI

You can add more granular authorization control to an AAM deployment
with authorization based on URI. This additional level of control specifies
the URIs that end-users are permitted to access.
Note: The current release supports this feature for RADIUS and LDAP.
URI Access List

The URI that an end-user is allowed to access consists of the following
string:
ACOS-device//VIP/portnum/service-type
For example, an end-user might have access only to a service on a VIP that
is load balanced by a pair of ACOS devices. In this case, the AAA server
might have the following entries for the end-user:
ACOS1//10.2.4.69/80/http
ACOS2//10.2.4.69/80/http
Note: The actual syntax for the entries depends on the type of AAA server.
Configuration Overview
Deployment of this feature requires some configuration on the ACOS
device and on the AAA server.
ACOS Device Configuration
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 has been authenticated, ACOS permits access only if the URI that
was requested by the end-user is in the list that was provided by the AAA
server.
Configuration on RADIUS Server
To configure your RADIUS server for URI-based authorization:

1. Add a dictionary.a10 file and include the A10--AUTH-URI attribute.
2. Add the permitted URI list to each end-user account.

dictionary.a10 file
Here 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--AUTH-URI 6 string
END-VENDOR A10-Networks
Configuration on LDAP Server
To configure your LDAP server for URI-based authorization:

1. Copy the a10auth.schema file and paste it in the /etc/openldap/schema
directory.
2. Edit the /etc/openldap/slapd.conf file to include the a10auth.schema:

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 a10URI list.
The following steps are an example of this procedure:
a. Add the following line to the ldif file:
a10URI: 103//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:
# a10.schema
#
# This is the ldif version of a10.schema to be used with cn=config.
#
AttributeType ( 1.3.6.1.4.1.22610.2.1.1
NAME 'a10URI'
DESC 'a10URI:ax-serial-number [a10-partition-name
[a10-vip-name [a10-vport]]]'
EQUALITY caseIgnoreMatch
SYNT 1.3.6.1.4.1.1466.115.121.1.15 )
# This is the ldif version of a10.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 a10URI )

LDIF Example:
# extended LDIF
#
# LDAPv3
# base <dc=example, dc=com> (default) with scope sub-
tree
# 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
a10URI: 103//Avip20/80/http

AAM with LDAP - Overview
AAM with LDAP
ACOS supports password update for end-users whose accounts are man-
aged in a Lightweight Directory Access Protocol (LDAP) database.
Overview
The AAM Authentication Proxy features can use Basic-HTTP authentica-
tion or web-based forms to obtain user credentials and query backend
LDAP servers to verify the credentials. If a valid end-user’s password has
expired, the Login Proxy allows end-users to change their passwords and
regain access.
LDAP Login Formats

You can use the following LDAP bind login name formats:
• username@domain.com
• Domain\username
If end-users enter their login name in one of these formats, ACOS uses the
form that is entered instead of the Bind DN form. This is because the Com-
mon Name does not match the account name in Active Directory (AD).
When a client sends a request to a VIP for a secured service, ACOS uses
Basic-HTTP authentication or a web form to prompt users for their creden-
tials. ACOS sends the credentials to an LDAP server for verification.
Remember the following points:

• If the client has been authenticated by the LDAP server, ACOS allows
the client to access the requested service.
• If the LDAP server returns an error message, ACOS does not immedi-
ately deny the end-user’s request.
ACOS logs in to the LDAP server as an account administrator and que-
ries the account database for the password that was entered by the end-
user and the password’s expiration date. ACOS uses this information to
determine whether the currently invalid password was once valid but
has since expired.

AAM with LDAP - Logon Proxy
Consider the following information about passwords:
• If the password is valid but has expired, ACOS sends a web form to
end-users and prompts them to change the password.
• If the password is invalid, ACOS denies the request.
Logon Proxy
This solution uses a form to prompt users to enter their credentials and veri-
fies the credentials by using a backend LDAP server.
Figure 9 shows an example deployment of this solution.
FIGURE 9 Form-based logon with LDAP
Traffic Walkthrough - Valid Username and Password

The following steps provide a high-level overview of the traffic flow in this
example:
1. The client sends an initial HTTP request to the VIP.
2. ACOS replies with a form with input fields for the end-user credentials.
Note: Credentials are a username and a password.

3. The client browser displays the form in which end-users enter their cre-
dentials.
4. ACOS extracts the credentials from the form and, in a search request,
sends the credentials to the LDAP server.
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 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.
Note: This example assumes SLB is used.
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.
FIGURE 10 Form-based logon with LDAP (change password)

Traffic Walkthrough - Valid Username and an Expired Password
The following steps provide a high-level over view of the traffic flow in this
example:
2. ACOS replies with a form with input fields for the end-user credentials.
dentials.
4. ACOS extracts the credentials and, in a search request, sends the creden-
tials to the LDAP server.
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 with the fields to change the
password.
7. End-users enter the username and the old and new passwords.
8. ACOS sends the updated password to the LDAP server.
9. The client is authenticated, and ACOS uses SLB to select a server and
sends the client’s HTTP request to the server.

reply.
11. ACOS caches the credential verification from the LDAP server and for-
wards the server reply to the client.
Configuration Resources
The deployment requires the following resources:
• A zip archive of the web portal files that are required for end-user logon
• A logon-portal profile
• An authentication-server profile for the backend LDAP server

• A health monitor, a server configuration, and a service group for the
backend LDAP server
• An authentication template that contains the service group for the
authentication server and the authentication-logon profile
• A server configuration and service group for the application server
• VIP configuration
CLI Example
The following commands import the logon-portal files to 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
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=a10net-
works,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 con-
figuration, and service group for LDAP health checking, the server com-
mand should be used 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

AAM with LDAP - Authentication Relay
Authentication Relay
Authentication relay uses a backend LDAP server to verify end-users’ cre-
dentials when they first log on and reuses those credentials to log in to load-
balanced content servers on behalf of the end-users. In this deployment, the
content servers do not need to understand LDAP. Instead, Basic-HTTP
authentication is used between ACOS and the servers.
Figure 11 illustrates an example of authentication relay.
FIGURE 11 Form-based logon with LDAP and Authentication Relay
Traffic Walkthrough - Valid Username and Password

example:
2. ACOS replies with a form that contains input fields for the end-user cre-
dentials.
dentials.

4. ACOS extracts the credentials from the form and, in a search request,
sends the credentials to the LDAP server.
5. The LDAP server replies.

In this example, the credentials exist in the LDAP server’s user data-
base.
6. ACOS uses SLB to select a server and sends the client’s HTTP request
to the server.
7. The server replies with an HTTP 401 (Not Authorized) message with
response code 4 that contains an Authentication header such as the fol-
lowing:
8. ACOS sends an HTTP reply that includes the credentials, in Base64-

encoded form, in an authorization header:
Authorization: Basic QTEwOlRodW5kZXI=
9. If the credentials are valid, the server replies with the requested content.
10. ACOS caches the credential verification from the LDAP server and for-
wards the server reply to the client.
• A zip archive of the web portal files that are required for end-user login.
• A login-portal profile.
• An authentication-server profile for the backend LDAP server.
• A health monitor, a server configuration, and a service group for the

backend LDAP server.
• An authentication-logon profile for a form-based collection of end-user
credentials.
• An authentication-relay profile for sending end-user credentials to con-
tent servers.
• An authentication template that contains the authentication-server pro-
file and authentication-login profile.
• A server configuration and service group for the application server.
• A 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.
Note: This is the same logon-portal profile that was used in “Logon Proxy” on
page 30.

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.
Note: This is the same configuration that was used in “Logon Proxy” on
page 30.
ACOS(config-ldap server)#exit
ACOS(config)#health monitor ldap-sr
ACOS(config-health:monitor)#method ldap run-search BaseDN dc=a10net-
works,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 command creates an HTTP-basic logon profile and specifies

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.
Note: This is the same configuration that is used in the other AAM examples in
this chapter.

AAM with RADIUS - Basic HTTP Logon with RADIUS
AAM with RADIUS
This chapter provides some examples of RADIUS AAA solutions that use
AAM features and provides information about the following logon options:
• “Basic HTTP Logon with RADIUS” on page 39
• “Form-based Logon with RADIUS” on page 42
Basic HTTP Logon 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
credentials from the client and sends the credentials to the backend
RADIUS server for verification.
Figure 12 illustrates a sample deployment in which a RADIUS server is

used.
FIGURE 12 Basic HTTP logon with RADIUS
This example shows successful authentication of a client request.

Traffic Walkthrough
The following steps provide an overview of the traffic flow in this example:
2. ACOS replies with an HTTP 401 (Not Authorized) message with

response code 4 that contains an authentication header such as the fol-
lowing text:
3. The client browser displays a login window in which end-users enter

their credentials.
The credentials are a username and a password.
Client browser encodes the credentials in Base64 format and sends the
credentials to ACOS.
4. ACOS decodes the credentials and sends the credentials to the RADIUS
server in an Access-Request message.
5. The RADIUS server replies.

In this example, the username and password exist in the RADIUS
server’s user database, and the 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.
Note: This example assumes that SLB is used.

reply.
This deployment requires the following resources:
• An authentication-server profile for the backend RADIUS server.
• An authentication-logon profile for Basic HTTP logon.

file and authentication-logon profile.
• A server configuration and a service group for the application server.
CLI Example
RADIUS server:
ACOS(config)#authentication-server radius radius_server
ACOS(config-radius server)#host 172.16.2.10
ACOS(config-radius server)#secret a10networks
The following command creates an Basic HTTP logon 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 to be used by

the virtual port:
Note: The RADIUS server configuration and basic-HTTP authentication-logon

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 sends requests and adds the server to a service group:
Note: The server configuration is then added to a service group.

The following commands configure the VIP:


AAM with RADIUS - Form-based Logon with RADIUS
Form-based Logon with RADIUS

This solution is similar to the basic HTTP logon, except that a form-based
logon is used instead of basic-HTTP logon.
FIGURE 13 Form-based logon with RADIUS
This example shows the successful authentication of a client request. All

steps except 2 and 3 are the same as those in “Basic HTTP Logon with
RADIUS” on page 39.
Traffic Walkthrough
example:
2. ACOS replies with a form with the input fields for the end-user creden-
tials.
The credentials are a username and a 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, in an Access-Request
message, sends the credentials to the RADIUS server.
5. The RADIUS server replies.

In this example, the credentials exist in the RADIUS server’s user data-
base, and 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.
Note: This example assumes SLB is used.

reply.
• A zip archive of the web portal files that are required for end-user login.
• A login-portal profile.
• An authentication-server profile for the backend RADIUS server.

file 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
...


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 that is used in “Basic HTTP

Logon with RADIUS” on page 39.

ACOS(config-form-based authentication lo...)#slb template authentication t1
ACOS(config-authentication template)#server radius_server
The following commands add the SLB configuration:
Note: This is the same server, service-group, and VIP configuration that is used
in “Basic HTTP Logon with RADIUS” on page 39.

AAM with OCSP - Overview
AAM with OCSP
Online Certificate Status Protocol (OCSP) is a network component that pro-

vides certificate verification services.
This chapter provides information about the following deployment exam-

ples:
• “One OCSP Server” on page 46
• “Multiple OCSP Servers” on page 48
Overview
You can use OCSP to verify client certificates for access to an HTTPS vir-
tual port. ACOS uses OCSP to authenticate the client, instead of a certifi-
cate 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 server.
Note: In previous releases, the path in a URI for an OCSP server was not
included in authentication requests. This limitation caused the failure of
an authentication request that was used the OSCP 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 certif-
icates in the following way:
1. When a client sends a request to set up an SSL session, ACOS sends the
certificate that is sent by the client to an OCSP responder for validation.
If the responder is a member of a service group, ACOS uses the config-
ured load-balancing method to select a responder and sends the request
to that responder.

AAM with OCSP - One OCSP Server
2. The OCSP responder checks its CRL database to determine whether the
certificate is still 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 not valid, 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 certificate. To ensure that the response from the
OCSP responder is not spoofed, ACOS verifies the identity of the responder
by checking the responder’s certificate.
To check the OCSP responder’s certificate, ACOS needs a copy of one of

the following certificate types:
• CA-signed certificate – OCSP responder’s certificate that is signed by a
root CA.
• Intermediate certificate – OCSP responder’s certificate that is signed by
an intermediate CA.
You must import the certificate(s) to the ACOS device as part of the config-
uration for OCSP support.
One OCSP Server

This section provides a configuration example that uses one OCSP server.
• Server certificate and key files that ACOS can present to clients during
the SSL session setup between ACOS and clients
• Authentication-server profile for the OCSP server
• Client-SSL template

AAM with OCSP - One OCSP Server
• Server configuration and 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:
User name []?admin1
File name [/]?server.pk7
...
ACOS presents the server certificate and public key to clients, as verifica-
tion of the server’s identity. From the client’s perspective, the ACOS device
where the VIP requested by the client is configured is the server.

OCSP server:
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:

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 imported onto the ACOS device. In this example, both the cer-
tificate and key are imported as singe 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

AAM with OCSP - Multiple OCSP Servers
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
Multiple OCSP Servers

This configuration example in this section uses a group of multiple OCSP
servers.
• Server certificate and key files that ACOS can present to clients during
an SSL session setup between ACOS and the clients
• Authentication-server profile for each OCSP server
• Server configurations and service group for the OCSP servers
• Server configurations and service group for the services requested by

clients
Note: The authentication-server profiles in this deployment are required as part

of the configuration. However, in this case, the OCSP server information
is in the SLB server configurations for the OCSP servers, instead of in the
authentication-server profiles.

CLI Example
This configuration is similar to the one in “One OCSP Server” on page 46,
with the addition of SLB server configurations and a service group for the
OCSP servers. ACOS load balances the certificate verification requests
among the OCSP responders in the service group.
The following commands import a server certificate and key to the ACOS
device:
User name []?admin1
File name [/]?server.pk7
...
ACOS presents the server certificate and public key to clients, as verifica-
tion of the server identity. From the client’s perspective, 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 will be 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 add the configurations 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 will send client certificates for verification.
The following commands configure the client-SSL template. This is similar

to the configuration in “One OCSP Server” on page 46, except the ca-cert
command refers to the OCSP service group instead of an individual authen-
tication-server profile for a single 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
The following commands add the SLB configuration for the web servers.
This is the same configuration used in “One OCSP Server” on page 46.
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 Relay - Overview
AAM with Kerberos Relay
Kerberos single sign-on is a security solution that allows end-users to access

services that are protected by your Kerberos realm with a one-time login.
Overview
This section shows an example of an AAM solution that includes Kerberos
single sign-on. This solution uses the following AAM features:
• Logon Portal, which includes one of the following ways to collect end-
user credentials:
• Basic HTTP login
• Form-based login
• Online Certificate Status Protocol (OCSP)
• Authentication relay with Kerberos

Basic HTTP Login

Figure 14 shows how Basic HTTP Login is used with RADIUS in this
deployment.
FIGURE 14 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
that contains an Authentication 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. Ker-
beros is used to grant permission for subsequent requests for the same ser-
vice.

Form-based Login
Figure 15 shows how form-based login is used with RADIUS in this
deployment.
FIGURE 15 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 sends
the credentials to a backend RADIUS server for authentication.
As is the case for requests to virtual port 80, if authentication is successful,

ACOS caches the credential verification from the RADIUS server and for-
wards the server reply to the client. Kerberos is used to grant permission for
subsequent requests for the same service.

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

AAM with Kerberos Relay - Configuration
Authentication Relay with Kerberos

Figure 17 shows how Kerberos is used in this deployment.
FIGURE 17 Kerberos single sign-on - Kerberos ticketing
After authenticating a client, ACOS uses a Kerberos Key Distribution Cen-

ter (KDC) to manage authentication for subsequent requests from the client.
Configuration
This section provides information about the resources required to configure
the example in Figure 17 and some CLI examples.

The deployment shown in Figure 17 on page 55 requires the following
resources:
• HTTP-Basic login for port 80:
• Authentication-logon profile for basic-HTTP logon
• Authentication-server profile for the backend RADIUS server
• Form-based login for port 8080:

• Zip archive of the web portal files required for end-user login
• Authentication-logon profile for collection of end-user credentials
using the web portal files
• Authentication-server profile for the backend RADIUS server
• OCSP certificate verification for port 443:

• Certificate and key to present to clients on behalf of the virtual
server
• Authentication-server profile for the backend OCSP server
• Kerberos authentication relay:

• Authentication-relay profile for the KDC
• Authentication template for each virtual port, to specify the AAM pro-
files (authentication-logon profile, authentication-relay profile, and
authentication-server) to use
• Server configuration and service group for the application server where
the service principal (service requested by the client) is located
CLI Example
The following commands configure the Kerberos AAM deployment shown
in Figure 17 on page 55.
To begin, the following commands configure the authentication-logon pro-

files for initial client login through virtual ports 80 and 8080.
ACOS(config)#authentication-logon http-basic http-basic
ACOS(config-http basic authentication lo...)#exit
The profile created above, for Basic HTTP login, will be used for login
through virtual port 80. The profile for form-based portal login, created
below, will be for login through virtual port 8080.

The following commands import the logon-portal files to the ACOS device:
User name []?admin1
...
The following commands configure the logon-portal profile.

ACOS(config)#authentication-logon form-based http-form
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 to be used to verify client certifi-
cates, for clients that request access through virtual port 443. The other
authentication-server profile is for the RADIUS server to be used for
authenticating 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 to be load bal-
anced:
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 (the application running 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, to configure

authentication settings for SSL traffic between clients and ACOS:
The cert and key commands specify the server certificate and key used by
ACOS. ACOS presents the server certificate to clients, on behalf of the
application servers. The client-certificate Require command requires cli-
ents to present their certificates to ACOS. The ca-cert command configures
ACOS to use OCSP to verify client certificates. The command refers to the
authentication-server profile configured above for the OCSP server.
User name []?admin1
File name [/]?acos.pk7
...
ACOS(config)#slb template client-ssl client-ssl

ACOS(config-client ssl)#cert acos
ACOS(config-client ssl)#key acos
ACOS(config-client ssl)#ca-cert ca ocsp ocsp

The following commands configure the authentication templates:
The authentication templates identify the other AAM resources to use for
securing access to the virtual ports. A separate authentication template is
configured for each of the virtual ports.
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 of the virtual ports uses the same service group. However, each virtual
port uses a different authentication template, for a unique set of AAM fea-
tures.
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

AAM with Kerberos Relay - Kerberos Terminology Related to AAM
Kerberos Terminology Related to AAM

This section lists common Kerberos terms and how they relate to AAM:
• Realm – The domain of networked services to which the Kerberos
server permits or denies access.
• Kerberos Domain Controller (KDC) – Kerberos server.
The KDC has 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 master ticket (described below) 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 individ-
ual client requests.
• Ticket Granting Ticket (TGT) – Master ticket that verifies the identity of
the client to ACOS. ACOS can use the client’s TGT to obtain ST tickets
for specific client requests (described below).
• Service Ticket (ST) – Ticket that verifies the client’s identify to a spe-
cific service, for an individual request to that service.
• Front-end server – Kerberos proxy (the ACOS device).
• Backend server – Server running the services requested by clients.
• Security Principal – Kerberos term for the client.
• Service Principal – Kerberos term for the service 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, operating as
a Kerberos front-end server, to use the TGT that is granted to a client by
the KDC to issue STs for individual service requests. This capability
uses the S42proxy Kerberos extension.

IP Anomaly Filtering - Overview
IP Anomaly Filtering
ACOS provides a suite of features for detecting and mitigating Distributed

Denial of Service (DDoS) attacks. One of these features, IP anomaly filter-
ing, is easy to configure and can protect against numerous types of attacks.
Overview
IP anomaly filtering detects and drops packets that contain the common sig-
natures 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 that have known vulnerabilities in their fragment reassembly
code
• Invalid HTTP or SSL payload
• IP-option – Drops all packets that contain any IP options
• Land-attack – Drops spoofed SYN packets containing the same IP

address as the source and destination, which 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, known as “ping of death”

packets
• TCP-no-flag – Drops all TCP packets that do not have any 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 use them without also using 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.
Filtering for these anomalies is disabled by default. However, if you config-

ure a system-wide PBSLB policy, the filters are automatically enabled. You
also can configure each filter.
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 71.
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. This threshold can be set to 1-127
occurrences of the anomaly, and the default is 10.
Note: The thresholds are not tracked by the PBSLB policies that are bound to
individual virtual ports.
SOCKSTRESS_CHECK Session State

While the ACOS device is checking a data packet against the new IP anom-
aly 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
• 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 3200-12, AX 3400, and AX 5200-11
DDoS protection is software-based on the 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 in which Server Load Balancing (SLB)
is supported.
• 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 that are longer than
32000 bytes on the following models:
• Thunder 3030S, Thunder 1030S, and Thunder 930
• AX 1030, AX 2500, AX 2600, AX 3000, and AX 3030
The option drops IP packets longer than 65535 bytes on the other mod-
els.

IP Anomaly Filtering - Configuration
Configuration
All of the IP anomaly filters that are described in this chapter are disabled
by default. You can enable individual IP anomaly filters on the entire sys-
tem.
To enable IP anomaly filters, use one of the following methods.
USING THE GUI

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

Use the following command at the global configuration level of the CLI:
ip anomaly-drop
{
bad-content [threshold] |
drop-all |
frag |
ip-option |
land-attack |
out-of-sequence [threshold] |
ping-of-death |
tcp-no-flag |
tcp-syn-fin |
tcp-syn-frag |
zero-window [threshold]
}
You can enable each option separately or enter drop-all to enable all the
options.
CLI Example
The following command enables DDoS protection against ping-of-death
attacks:
ACOS(config)#ip anomaly-drop ping-of-death

IP Anomaly Filtering - Displaying IP Anomaly Statistics
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:
clear slb l4

IP Anomaly Filtering - Displaying IP Anomaly Statistics

Policy-based SLB - Overview
Policy-based SLB
This chapter describes policy-based SLB (PBSLB) and how to configure it.
Overview
ACOS allows you to “black list” or “white list” individual clients or client
subnets. Based on actions you specify, ACOS will allow (white list) or drop
(black list) traffic from specific client hosts or subnets in the list.
For traffic that is allowed, you can specify the service group to use. You can
also specify the action to perform (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. In software releases that

support Server Load Balancing (SLB), you also can apply PBSLB on indi-
vidual virtual ports.
Note: ACOS also allows policy templates to be applied at the virtual-server

level. If you apply the policy template at the virtual-server level, PBSLB
does not take effect. 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 same list for both system-wide PBSLB and for
PBSLB on a virtual port at the same time. In this case, the ACOS device
may increase the current connection counter more than once, resulting in
a much lower connection limit than the configured value. To work around
this issue, use separate black/white lists.

Policy-based SLB - Configuring a Black/White List
Configuring a Black/White List

Client IP lists (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, add a row using
the following syntax:
ipaddr [/network-mask] [group-id] [#conn-limit] [;comment-string]

• 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 from 1 to 31 in a black/white list that identi-
fies 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 connec-
tions allowed from the client.
By default, there is no connection limit. If you set a limit, the valid range
is from 1 to 32767 connections. 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
coarser the limit. For example, if you specify 100, the ACOS device limits
the total connections to exactly 100; however, if you specify 1000, the
device limits the connections to a maximum of 992.
If the number in the file is larger than the supported maximum (32767),
the parser uses 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 uses 11111 as the value.

• The ;comment-string is a comment.
Everything to the right of the ; is ignored by the ACOS device when it
parses the file.
Example Black/White List

Here is an example 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, if the
drop action is assigned to this group, the client is black listed. The second
row black lists an entire subnet, by assigning it to the same group (4). The
third row sets the maximum number of concurrent connections for a spe-
cific host to 20. The fourth row assigns a specific host to group 2 and speci-
fies a maximum of 20 concurrent connections.
Note: The ACOS device allows up to three parser errors when reading the file.
After the third parser error, the device stops reading the file.
Dynamic Black/White-list Client Entries

The ACOS device supports dynamic client entries. To configure this fea-
ture, add client address 0.0.0.0/0 (wildcard address) to the black/white list
that is used by the system-wide PBSLB policy.
When a client sends an HTTP or HTTPS connection request, the ACOS

device checks the system-wide PBSLB policy’s black/white list for the cli-
ent’s IP address.
One of the following actions occur:

• If the list does not already have an entry for the client, the ACOS device
creates a dynamic entry for the client’s host address.
• If the list already has a dynamic entry for the client, the ACOS device
resets the timeout value for the entry.
• If the list contains 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, all clients who do not match a static entry in the list are
assigned to group 1 and are limited to 20 concurrent connections.
The ACOS device supports up to 8 million dynamic client entries for sys-
tem-wide PBSLB. Once this limit is reached, the ACOS device does not
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 individual client. In the example
above, each client that has a dynamic entry in the black/white list is allowed
to have a maximum of 20 concurrent connections.
Aging of Dynamic Entries

When the ACOS device creates a dynamic black/white list entry for a client,
the device also sets the timeout for the entry. The timeout value for the
dynamic entry decrements until the timeout reaches 0 or the client sends a
new HTTP or HTTPS connection request.
One of the following situations occurs:

• If the client sends a new HTTP or HTTPS connection request, the time-
out is reset to its full value.
• If the timeout reaches 0 and the client does not have any active connec-
tions, the dynamic entry is removed.
However, if the client has an active connection, the dynamic entry is not
removed until the client’s connection ends.
You can set the timeout to 1-127 minutes, and the default is 5 minutes.
If client-lockup is enabled, the timeout for a locked up client does not begin
decrementing until the lockup expires. For more information, see “Client
Lockup” on page 72.

Policy-based SLB - Configuring System-Wide PBSLB
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.
There are a few limitations:

• The ACOS device does not create any dynamic entries in the list.
• The connection limit applies collectively to all clients that do not have a
static entry in the list.
Configuring System-Wide PBSLB

System-wide PBSLB policies provide the following options that are not
available in policies that are applied to individual virtual ports:
• Dynamic black/white-list client entries
• Client lockup
• IP anomaly checking and tracking, using IP anomaly filters
To configure a system-wide PBSLB policy, use the following commands at

the global configuration level of the CLI:
[no] system pbslb bw-list name
This command specifies the name of the black/white list to use for the pol-
icy.
[no] system pbslb id id {drop | reset}
[logging minutes]
You can enter which action to take for 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. The minutes option specifies how often
messages can be generated.

Policy-based SLB - Configuring System-Wide PBSLB
[no] system pbslb over-limit
[reset]
[lockup minutes]
[logging minutes]
This command specifies the action to take for clients who either exceed the
connection limit that is specified in the black/white list or exceed the thresh-
old of any of the new IP anomaly filters. You can use one or both of the fol-
lowing options:
• reset – Resets all new connection attempts from the client. If you omit
this option, new connection attempts are dropped instead.
• 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. The minutes option specifies how often
messages can be generated.
[no] system pbslb timeout minutes
This command sets the timeout for dynamic black/white-list entries. 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 contin-
ues 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 con-
nection limit that is specified in the black/white list, the ACOS device con-
tinues to drop all connection attempts from the client until the lockup
expires.
The lockup option is disabled by default. You can enable it by specifying a

lockup period of 1-127 minutes.
The dynamic black/white-list entry for a client does not expire while the cli-
ent is locked up. After the lockup ends, the timeout for the entry is reset to
its full value and begins decrementing, as described in “Aging of Dynamic
Entries” on page 70.

Policy-based SLB - Configuring PBSLB for Individual Virtual Ports
Displaying and Clearing System-Wide PBSLB Information

To display information for system-wide PBSLB, use the following com-
mands:
show pbslb system
show pbslb client [ipaddr]
To clear PBSLB information, use the following commands:

clear pbslb system
clear pbslb client [entry]
If you omit the entry option, the statistics counters are cleared, but the cli-
ent entries are not cleared. To also clear the client entries, enter the entry
option.
Configuring PBSLB for Individual Virtual Ports

You can configure PBSLB parameters for virtual ports by configuring the
settings directly on a port or by configuring a PBSLB policy template and
binding the template to the virtual port.
Note: This feature is supported only in software releases that support Server
Load Balancing (SLB).
To configure PBSLB:
1. Remotely configure a black/white list or configure the list on the ACOS
device.
Note: If you remotely configured the list, import the list to the ACOS device.
2. Optionally, modify the sync interval for the list. ACOS regularly syn-
chronizes with the list to make sure the ACOS version is current.
3. Configure PBSLB settings.

You can configure the following settings on a virtual port or configure a
policy template and bind the template to virtual ports:
• Specify the black/white list.
• Optionally map each group ID that is 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 performs on
connections that exceed the limit that are specified in the list.
• Optionally, if necessary, change the client address matching from
source IP matching to destination IP matching.
Note: These steps assume that the real servers, service groups, and virtual serv-
ers have already been configured.
USING THE GUI
Configuring PBSLB Settings by Using a Policy Template

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. Select a black/white list or select create to create or import one.

If you selected create, complete the following steps:
a. Enter or select a name for the imported black/white list.
b. Select the location of the black/white list.
• To create the list using a text entry field in the GUI, select Local. In
the Definition section, complete one of the following tasks:
• Copy and paste the black/white list
• Type the black/white list
• To import a list from a remote server, select Remote, and enter the
values for the following parameters:
• Interval at which the ACOS device imports the list again. This
option ensures that changes to the list are automatically repli-
cated on the ACOS device.
• File transfer protocol to use.

• IP address or hostname of the device where the list is located.
• Path and filename of the list on the remote device.
5. Click OK.
6. To configure group options, complete the following steps:

a. In Group ID, select an ID.
b. In the Action drop-down list, select one of the following actions:
• Drop, which drops new connections until the number of concur-
rent connections on the virtual port falls below the port’s connec-
tion limit. The connection limit is set in the black/white list.
• Reset, which resets new connections until the number of concur-
rent 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. To select this option, you must create
at least one service group.
• create, which displays the configuration sections for creating a
new service group.
c. Optionally, to enable logging, select the Logging check box.
To change the logging interval, edit the number 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 the Logging check box and then select
the Log Failures check box.
The Log Failures check box appears only if you selected a service
group in the Action drop-down list.
Note: On the Virtual Service page, if the Use default server selection when
preferred method fails check box is selected on the virtual port, log mes-
sages will never be generated for server-selection failures. To ensure that
log server-selection failure messages are generated, deselect the check
box on the virtual port. Failures that occur because a client exceeds the
PBSLB connection limit are still logged.
d. Click Add.
The group settings appear in the PBSLB list.
e. Repeat the steps above for each group.

7. Select the action to take when traffic exceeds the limit:
• Drop
• Reset
8. Optionally, to match the destination traffic against the black/white list,

instead of source traffic, select the Use Destination IP check box.
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:
• Select an existing virtual server and click Edit.
• Click Add.
c. In the Port section, do one of the following:
• Click Add.
• Select an existing virtual port and click Edit.
d. In the Virtual Server Port section, in the Policy Template drop-
down list, select a PBSLB template.
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]
The following list provides additional information about the options:

• 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 repli-
cated on the ACOS device. You can specify 60 – 86400 seconds. The
default is 300 seconds.

• The load option immediately imports the list again 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 any new commands
until the load is completely finished. As a result, for large black/white
lists, loading can take a while. Do not abort the load process, because this
step can also interrupt periodic black/white-list updates. If you acciden-
tally abort the load process, repeat the command by entering the load
option and allow the load to complete.
Configuring PBSLB Settings Using a Policy Template

To configure PBSLB settings by using a policy template:
1. To configure a PBSLB template, enter the following commands:
[no] slb template policy template-name
Enter this command at the global configuration level of the CLI. The com-
mand creates the template and changes the CLI to the configuration for the
template, where the following PBSLB-related commands are available.
2. To bind a black/white list to the virtual ports that use this template, enter
[no] bw-list name file-name
3. To specify the action to take for clients in the black/white list, enter the
following commands:
[no] bw-list id id
service {service-group-name | drop | reset}
[logging [minutes] [fail]]
The following list provides additional information about the options for this
command:
• id – Group ID in the black/white list.
• service-group-name – Sends clients to the SLB service group asso-

ciated 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 generated. 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 gener-
ates only one message. This message indicates the number of times the
rule was applied since the last message. You can specify a logging inter-
val 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 configures the ACOS device to
generate log messages only when there is a failed attempt to reach a ser-
vice group. Messages are not generated for successful connections to the
service group. The fail option is disabled by default. The option is avail-
able only for PBSLB rules that use the service service-group-name
option, not for rules with the drop or reset option, since any time a drop
or reset rule affects traffic, this indicates a failure condition.
Logging is disabled by default. If you enable it, the default for minutes is
3.
The ACOS device uses the same log rate limiting and load balancing
features for PBSLB logging as those used for ACL logging.
Note: If the def-selection-if-pref-failed option is enabled on the virtual port, log

messages will never be generated for server-selection failures. To ensure
that messages are generated to log server-selection failures, disable the
def-selection-if-pref-failed option on the virtual port. This limitation does
not affect failures that occur because a client has exceeded the PBSLB
connection limit. These failures are still logged.
4. To specify the action to take for traffic that is over the limit, enter the
following command:
[no] bw-list over-limit
{lockup min | logging min | reset}
The following list provides additional information about the options for the
command:
• lockup min – Continues to apply the over-limit action to all new con-
nection attempts from the client, for the specified 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 min-
utes.

• reset – Resets new connections until the number of concurrent con-
nections on the virtual port falls below the connection limit.
5. To match the black/white list entries based on the client’s destination IP

address, enter the following command:
[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.)
6. To bind the template to a virtual port, enter the following command at

the configuration level for the port:
[no] template policy template-name
Configuring PBSLB Settings on a Virtual Port

To configure PBSLB settings on a virtual port:
1. To bind a black/white list to a virtual port, enter the following command
at the configuration level for the virtual port:
pbslb bw-list name
The name is the name that you assign to the list when you import the list.
2. To map client IP addresses in a black/white list to specific service

groups, enter the following command at the configuration level for the
virtual port:
pbslb id id
{service service-group-name | drop | reset}
[logging [minutes] [fail]]]
The following list provides additional information about the options for this
command:
• The id is a group ID in the black/white list and can be from 1 to 1,000.
• The service-group-name is the name of an SLB service group on the

ACOS device.
• The drop option immediately drops all connections from the clients in
the list.
• The reset option resets the connections from the clients in the list.
The logging option enables logging. The minutes option specifies how
often messages can be generated. 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 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 ser-
vice group. Messages are not generated for successful connections to the
service group. The fail option is disabled by default. The option is avail-
able only for PBSLB rules that use the service service-group-name
option, not for rules with the drop or reset option, since any time a drop
or reset rule affects traffic, this indicates a failure condition.
features for PBSLB logging as those used for ACL logging.
Note: If the def-selection-if-pref-failed option is enabled on the virtual port, log

messages will never be generated for server-selection failures. To ensure
that messages are generated to log server-selection failures, disable the
def-selection-if-pref-failed option on the virtual port. This limitation does
not affect failures that occur because a client is over their PBSLB connec-
tion limit. These failures are still logged.
3. To specify the action to take if the virtual port’s connection threshold is

exceeded, enter the following command at the configuration level for
the virtual port:
[no] bw-list over-limit {drop | reset}
This command specifies the action to take for traffic that is over the limit.
• drop – Drops new connections until the number of concurrent connec-
tions 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 connec-
tions on the virtual port falls below the connection limit.The connection
threshold is set in the black/white list.

Policy-based SLB - Displaying PBSLB Information
Displaying PBSLB Information

To display PBSLB information:
• To show the configuration of a PBSLB policy template, use the follow-
ing command:
show slb template policy template-name
• To show client IP addresses in a black/white list, enter the following

command:
show bw-list [name [detail | ipaddr]]
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, sta-
tistics are displayed only for that virtual server. Otherwise, statistics are
shown for all virtual servers.
Configuration Examples
The following commands import black/white list sample-bwlist.txt onto the
ACOS device:
ACOS(config)#bw-list sample-bwlist tftp://myhost/TFTP-Root/ACOS_bwlists/sam-
ple-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

Policy-based SLB - Example—Sockstress Attack Protection
The following commands configure a PBSLB template and bind it to a vir-
tual port:
AX(config)#slb template policy bw1
AX(config-policy)#bw-list name bw1
AX(config-policy)#bw-list id 2 service srvcgroup2
AX(config-policy)#bw-list id 4 drop
AX(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
ACOS(config-slb virtual server-slb virtua...)#pbslb id 2 service srvcgroup2
The following commands shows PBSLB information:

ACOS(config-slb virtual server-slb virtua...)#show pbslb
Total number of PBSLB configured: 1
Virtual Server Port Blacklist/whitelist GID Conn. # (Est Reset Drop)

PBSLB_VS1 80 sample-bwlist 2 0 0 0
4 0 0 0
80 sample-bwlist 2 0 0 0
4 0 0 0
Example—Sockstress Attack Protection

for wYou 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 either of the following situations 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, which enforces 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 shows system-wide statistics for the new IP anom-
aly 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 shows statistics for the system-wide PBSLB pol-
icy:
ACOS(config)#show pbslb system
System B/W list: bwlist-wc
(Establish Reset
Virtual Server Port Blacklist/whitelist GID Connection # Drop)
System bwlist-wc 1 12 0 0
2 0 0 0
The following command shows 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
Conn- Curr- Out- Zero Bad-c

IP S/D GID limit conn Age Lockup s -w
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 clients, the age value is 0 until the lockup expires.
After the lockup expires, the age is set to its full value (120 seconds in this
example).

The following command shows 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 6
limit):
Age: 0 second
Lockup time: 5 minute
Out of sequence: 0
Zero window: 6
Bad content: 6


SYN Cookies - Overview
SYN Cookies
This chapter describes how SYN-cookies 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 TCP SYN flood 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 replying to this attempt
at establishing a 3-way handshake with the standard ACK, an attacker
ignores the reply, which creates a “half-open” TCP connection. This con-
sumes system resources, because the device is waiting 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, and this oversubscription
prevents the device from establishing new connections with legitimate cli-
ents.

SYN Flood Attack Counter

In ACOS 2.7.1-P6, you can identify SYN flood attacks and display informa-
tion about these attacks in the show command output. The information pro-
vides administrators with greater visibility into the activity on their
networks and can be used to take the necessary actions that are required to
fend off the attack. The increased visibility offered by this feature is import-
ant, due to the increasing prevalence of Denial of Service (DoS) attacks.
The SYN Flood Attack Counter leverages hardware-based or software-

based SYN cookies to display information about SYN flood attacks as the
event is occurring on the network. Therefore, SYN cookies must be enabled
on the ACOS device for the counters to work.
How ACOS Identifies SYN Flood Attacks

Figure 18 illustrates the mechanism by which the ACOS device determines
whether a particular TCP connection is from a legitimate request or if it is
part of a SYN flood attack.
FIGURE 18 SYN-ACK handshake (Legitimate versus Hacker)
Legitimate
Request
Possible SYN
Flood attack
In Figure 18, you can see that a normal 3-way TCP handshake includes a
SYN request from the client, the SYN-ACK reply from the ACOS device,
and finally, an ACK from the client to the ACOS device.

Note: By default ACOS waits 60 seconds until age the half-open session.
The timer in Figure 18 is configurable as a half-open-idle timeout in tcp-

proxy templates.
However, the mechanism by which SYN flood attacks can cripple a net-
work is by sending many SYN requests to a network device. The device
responds to these SYN requests with SYN-ACKs but then waits for
responses from the client that never arrive. The bogus requests create many
“half-open” sessions that waste system memory and other system resources.
The oversubscribed state reduces the device’s free resources and prevents it
from accepting requests from legitimate clients. Enabling SYN cookies can
help mitigate the damage caused by such DoS attacks by preventing these
attacks from consuming system resources.
The key characteristic of SYN flood attacks is the many unacknowledged

messages from the network device to the SYN request. It is also the absence
of an ACK message from the client that identifies the packet as belonging to
a SYN flood attack. A TCP connection for which the ACOS device did not
receive an ACK from the client is identified as belonging to a SYN flood
attack, and this is the information that the ACOS device displays 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 to each SYN request,
whether or not the request is legitimate, with a SYN cookie.
Note: A SYN cookie 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 into a
TCP sequence number. Instead of storing costly state information for each
TCP session, the sequence number in the SYN cookie allows the ACOS
device to compress a lot of session information into a much smaller amount
of data.
This sequence number is sent to the client as a SYN-ACK packet. When a

legitimate client receives this information, the client replies with an ACK
that contains the sequence number, incremented by 1. After receiving the
SYN ACK that contains the sequence number from the client, the ACOS
device reconstructs the connection information and establishes a connection
with that client.

If the SYN Request is part of an attack, the attacker does not send an ACK
to the ACOS device. The ACOS device sends a SYN cookie, but the
attacker does not receive it or might choose to ignore it, and the ACOS
device does not establish a connection.
Dynamic SYN Cookies

You can configure on and off thresholds for SYN cookies. The benefit of
this feature is that when there is no TCP SYN attack, TCP options are pre-
served.
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 connec-
tions exceeds the on-threshold, the ACOS device enables SYN
cookies. You can specify up to 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 up to 2147483647 half-
open connections.
By default, hardware-based SYN cookies are disabled. When you enable

the cookies, there are no default settings for the on and off thresholds. 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
that exist on the ACOS device.
Note: It may take up to 10 milliseconds for the ACOS device to detect and
respond to the crossover of either option.
SYN Cookie Buffering

SYN Cookie Buffering optimizes performance by increasing the number 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, by default, the ACOS device allocates 10
buffers to each TCP connection and offers a TCP window size of 8K. When
memory usage increases and system resources are scarce, the number of
buffers reserved for each TCP connection is gradually reduced from 10 buf-
fers to 4 buffers, and then from 4 buffers to 2 buffers, finally down to 1 buf-
fer per TCP connection. The window size is reduced at the same pace as the
number of buffers.

SYN Cookies - Configurable MSS Source for Proxied SLB Traffic
SYN Cookie Buffering is automatically enabled when SYN cookies are
enabled. Instead being dropped and requiring later re-transmission, the
packets are stored in the memory of the ACOS device and are 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 are optional and are available at the configu-
ration level for virtual ports on certain ACOS models. The ACOS device
bases Selective Acknowledgment (SACK) support and the maximum seg-
ment 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 that are sent to servers.
Consider the following information:

• If all up servers in the service group reply with a TCP SYN-ACK that
contains a SACK option, the ACOS device uses SACK with the soft-
ware-based SYN-cookie feature for all of the 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 any of the servers in the service
group is the MSS value that is used by the ACOS device for software-based
SYN-cookies.
Configurable MSS Source for Proxied SLB Traffic

You can change the way ACOS determines the TCP MSS value to use in
proxied TCP traffic. This option specifies how the MSS value is determined
for TCP SYN-ACKs sent by ACOS from a VIP to a client.
This option applies to full-proxy SLB configurations, in which the ACOS

device is acting as a proxy for both ends of the client-server session.

SYN Cookies - Configuration
ACOS can use either of the following methods to determine the MSS value
for TCP SYN-ACKs from a VIP to a client:
• Interface MTU and MSS value received from client in SYN packet
• (Default) Interface MTU and health-check response packet from real

server
If ACOS receives different MSS sizes from multiple real servers, ACOS
bases the value on the smallest MSS value received.
Note: The current release does not support configuration of this option using the
GUI.
USING THE CLI
To configure ACOS to base the MSS in replies from VIPs to clients on the
interface MTU and MSS value received from clients in SYNs, use the fol-
lowing command at the global configuration level of the CLI:
[no] slb use-mss-tab
Configuration
The following sections describe how to enable SYN-cookie support and
configure advanced features.
Enabling SYN-cookie Support

Depending on the ACOS model, you can use hardware-based SYN cookies
or software-based SYN cookies:
• Hardware-based SYN cookies can be globally enabled and apply to all
virtual server ports configured on the device. Hardware-based SYN
cookies are available on Thunder Series models Thunder 6430S, Thun-
der 6430, and Thunder 5430S; and on AX Series models AX 2200-11,
AX 3100, AX 3200, AX 3200-11, AX 3200-12, AX 3400, and AX
5200-11.
• Software-based SYN cookies can be enabled on individual virtual ports.
This version of the feature is available on all ACOS models and soft-
ware releases that support SLB.

• Hardware-based SYN cookies are a faster, easier-to-configure alterna-
tive to the software-based SYN cookie feature available on all ACOS
platforms.
If your model supports hardware-based SYN cookies, use the hard-
ware-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. You can leave software-
based SYN cookies enabled, but the cookies 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, using
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 95.
• Software-based SYN cookies are supported only in software releases
that support SLB.
USING THE GUI

FPGA Models
To enable SYN-cookie support on FPGA models:
1. Click Config Mode > SLB > Service > Global > Settings.
2. Select Enabled next to SYN Cookie.
3. In the On Threshold field, enter the maximum number of concurrent

half-open TCP connections allowed on the ACOS device, before SYN
cookies are enabled.
4. In the Off Threshold field, enter the minimum number of concurrent

half-open TCP connections for which to keep SYN cookies enabled.
5. Click OK.
Non-FPGA Models
To enable SYN-cookie support on non-FPGA models:
1. Click Config Mode > SLB > Service > Server.
2. Click Virtual Server on the menu bar.

3. Select an existing virtual server name or click Add.
4. In the General section, enter or update the information.
5. In the Port section, 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, enter the following command at the global configuration level:
[no] syn-cookie [on-threshold num off-threshold num]
The command in the following example enables dynamic-based SYN cook-

ies when the number of concurrent half-open TCP connections exceeds
50000 and disables SYN cookies when the number falls below 30000:
AX(config)#syn-cookie on-threshold 50000 off-threshold 30000
Non-FPGA Models
To enable software-based SYN cookies, enter 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 from the
client-side router, using hardware-based SYN cookies requires some addi-
tional configuration:
• On the ACOS device, you must configure a “dummy” VIP that is in the
same subnet as the client-side router.
• On the client-side router, you must configure a static route to the VIP,
using the dummy VIP as the next hop.
Figure 19 shows an example.
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 in this example:
AX(config)#slb virtual-server dummyvip 10.10.10.154
AX(config-slb virtual server)#exit
AX(config)#syn-cookie

Note: If HA is configured, add both the target VIP and the dummy VIP to the
same HA group, so they 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 the TCP handshake completion.
USING THE CLI

To enable Layer 2/3 SYN cookies on an interface, enter the following com-
mand at the global configuration level of the CLI:
[no] ip tcp syn-cookie
The feature is disabled by default.
Note: Optionally, to modify the threshold for TCP handshake completion, enter
the following command at the global configuration 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:
ip tcp syn-cookie threshold <timeout: 1-100>
Timeout: timeout for syn-cookie, default is 4 sec
ACOS(config)#syn-cookie on-threshold 50000 off-threshold 30000
ACOS(config)#ip tcp syn-cookie ?
AX5200-11(config)#ip tcp syn-cookie ?
threshold SYN cookie expire threshold
AX5200-11(config)#ip tcp syn-cookie thr
AX5200-11(config)#ip tcp syn-cookie threshold ?
<1-100> seconds (default is 4)

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 becomes occu-
pied, the number of buffers that are dedicated to each TCP connection is
reduced. Buffer reduction happens 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 num-
ber of buffers that are allocated to each session and the TCP window size
are reduced. This reduction in the TCP window size is an attempt to prevent
the client from sending data faster than the ACOS device is capable of
receiving it.
Note: By default, each TCP session is allocated 10 buffers and the TCP window
size is set to 8K.
Here are the graduated buffers and window sizes:

• 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 buf-
fers, and the TCP window size is reduced to 2K.
• If the last 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 they are configu-
rable.

• The size of each buffer is approximately 1500 bytes.
The total number of buffers varies between models and is based on the
total memory per connection.
• If hardware-based SYN cookies are enabled, ACOS does not modify the
TCP window size, which remains hard-coded at 65K.
USING THE GUI
The current release does not support configuration of this option by using
the GUI.

SYN Cookies - SYN Cookie Time Interval Statistics
USING THE CLI

You can enter the slb buff-thresh CLI command to configure the thresholds
for system memory usage.
Note: These threshold configurations apply to software- and hardware-based

models.
• 1st threshold: slb buff-thresh hw-buff num
This command configures the first threshold, which is associated with a
reduction in the number of buffers that are allocated to each TCP con-
nection from 10 to 4.
• 2nd buffer: relieve-thresh command
This command configures the second threshold, which is associated
with a reduction in the number of buffers that are allocated to each TCP
connection from 4 to 2.
• 3rd buffer: sys-buff-low command
This command configures the third threshold, which is associated with a
reduction in the number of buffers that are allocated to each TCP con-
nection 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 Command Line Interface Reference
Guide.
SYN Cookie Time Interval Statistics

You can display SYN cookie statistics, with the number of SYN cookies
that were sent or received, plotted across various time intervals.
SYN Cookie Time Interval Statistics provides ACOS administrators with

more information about potentially harmful bursts of TCP traffic, so admin-
istrators are better prepared to protect the network against SYN flood and
other DoS attacks.

The SYN Cookie Time Interval Statistics feature is similar to the “SYN
Flood Attack Counter” on page 88 because both features help to identify
DDoS attacks and display statistics in the show command output. However,
the SYN Flood Attack Counter only displays a counter of the total number
of packets from SYN flood attacks, but the SYN Cookie Time Interval Sta-
tistics feature displays statistics for the number of packets that were
received during a specific interval.
By displaying information about SYN flood attacks as a rate, administrators

have insight into the potentially harmful activities that might be occurring
on their network. Armed with this information, administrators can take
action to defend the network against DoS attacks.
How it works
The SYN Cookie Time Interval Statistics feature uses the show slb attack-
prevention command to display output for SYN cookie statistics as a rate.
Output from the CLI command shows the number of packets that were sent
or received by the ACOS device over the following, non-editable time inter-
vals:
• Current
• 1 second
• 5 seconds
• 30 seconds
• 1 minute
• 5 minutes
Displaying SYN-cookie Statistics

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 > Applica-
tion > 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 – Shows a running counter of TCP packets that the
ACOS device considers to be from legitimate clients. When SYN cook-
ies 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: Attack Prevention Statistics

You can view SYN-cookies statistics for a sampling interval or across the
following time intervals:
• Current
• 1 second
• 5 seconds
• 30 seconds
• 1 minute
• 5 minutes

The following command shows 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
Table 2 shows the fields that appear in the CLI output of the show slb
attack-prevention command.
TABLE 2 show slb attack-prevention fields

Field Description
SYN cookie snt Number of TCP SYN cookies sent.
SYN cookie snt ts Number of expanded TCP SYN cookies sent.
SYN cookie snt fail Number of TCP SYN cookie send attempts that failed.
SYN cookie chk fail Number of TCP SYN cookies for which the responding
ACK failed the SYN cookie check.
SYN attack Total number of SYN connections that did not receive
an ACK from the client and assumed to be SYN attack.
Consider the following limitations:

• When you run the show slb attack-prevention command on an FPGA-
based model, the SYN attack field does not show output for the histori-
cal 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 you run the show slb attack-prevention command from an L3V net-
work partition on an FPGA-based model, the “SYN attack” counter dis-
plays zero for all columns.
To clear these statistics, enter the following command:

ACOS#clear slb attack-prevention

CLI Example: SYN Attack Counter
The following example shows 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: Legitimate Session Counter

The following example shows 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 and not from an attacker.
ACOS#show slb l4
Total
IP out noroute 0
TCP out RST 0
...
L4 TCP Established 1766
CLI Example: SYN-cooke Buffering Statistics

The following example shows the 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 will work correctly in both
L3V and non-L3V deployments, counters that are associated with hard-
ware-based SYN cookies will not work when used with private partitions.
Table 3 shows the limitations that are associated with using SYN flood
attack counters under a variety of conditions.
TABLE 3 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 both 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 last column summarizes the information by indicating whether the

SYN cookie counter display functions correctly, based on the status of the
other conditions that are associated with this deployment.


IP Limiting - Overview
IP Limiting
IP limiting is an enhanced implementation of the source IP connection lim-

iting and connection-rate limiting feature. This chapter describes the IP lim-
iting options and how to configure and apply them.
Overview
IP limiting provides the following benefits:
• Configuration flexibility – You can apply source IP limiting on a sys-
tem-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 cli-
ents from being limited.
• Separate limits can be configured for each of the following:
• Concurrent connections
• Connection rate
• Concurrent Layer 7 requests
• Layer 7 request rate
Note: Layer 7 request limiting applies only to the HTTP, HTTPS, and fast-
HTTP virtual port types.
Class Lists
A class list is a set of IP host or subnet addresses that are mapped to IP lim-
iting rules. The ACOS device can support up to 255 class lists, and each
class list can contain up to 8 million host IP addresses and 64,000 subnets.
Note: Class lists can be configured only in the shared partition. A policy tem-
plate that is configured in the shared or the private partition can use a
class list that is configured in the shared partition.

Class List syntax

Each entry (row) in the class list defines a client class and has the following
syntax:
ipaddr /network-mask [glid num | lid num] [age min-
utes]
[; comment-string]
Each entry consists of the following options:

• ipaddr – Specifies the host or subnet address of the client.
• The network-mask – Specifies the mask, and IPv4 and IPv6 are sup-
ported.
To configure a wildcard IP address, enter 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 you can
use to match clients. You can use a system-wide (global) IP limiting rule
or an IP limiting rule that was configured in a policy template.
• To use an IP limiting rule that was configured at the global configu-
ration level, enter the glid num option.
• To use an IP limiting rule that was configured at the same level in
the same policy template as the class list, enter the lid num option.
To exclude a host or subnet from being limited, do not specify an IP lim-
iting rule.
• age minutes – Removes a host entry from the class list after the specified
number of minutes. You can specify up to 2000 minutes.
When you assign an age value, the host entry remains in the class list for
the specified period. After the age expires (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. The traffic limiting settings in the
LID or GLID that were assigned to the host entry take effect only until
the age expires.
Note: The age option applies only to host entries, such as IPv4 /32 or IPv6 /128
and is not supported for subnet entries.
Note: If you use a class-list file that is periodically re-imported, the age for the
class-list entries that were added to the system from the file do not reset
when the class-list file is re-imported. Instead, the entries continue to age
normally. This is by design.

• ; comment-string – Contains a comment. Use a semi-colon ( ; ) in front
of the comment string.
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 that are based on
the source IP address of client traffic. Optionally, you can also match based
on the following information:
• 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 very simple class list, which matches on all clients
and uses an IP limiting rule that was 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 information:

• 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.
• For all hosts in subnet 2.2.2.0/24, use IP limiting rule 2, which is config-
ured in a policy template.
• For all hosts that do not match another entry in the class list, use IP lim-
iting 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, and 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 up to 1048575 connections. Connection limit 0 immedi-
ately locks down matching clients, and there is no default.
• Connection-rate limit – Maximum number of new connections that are
allowed for a client in the limit period.
You can specify up to 4294967295 connections. The limit period can be
100-6553500 milliseconds (ms), specified in increments of 100 ms.
There is no default.
• Request limit – Maximum number of concurrent Layer 7 requests that
are allowed for a client.
You can specify up to 1048575 requests, and there is no default.
• Request-rate limit – Maximum number of Layer 7 requests that are
allowed for a client in the limit period.
You can specify up to 4294967295 connections. The limit period can be
100-6553500 milliseconds (ms), specified in increments of 100 ms.
There is no default.
• Over-limit action – One of the following actions to take when a client
exceeds one or more of the limits:
• Drop – The ACOS device drops the traffic.
If logging is enabled, the ACOS device 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 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 any limit. The
lockout period can be up to 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. When you
specify a logging period, the ACOS device holds on to the repeated
messages for the specified period and sends one message at the end of
the period for all of the instances that occurred in the period. The log-
ging period can be up to 255 minutes. The default is 0, which means that
there is no wait period.
Note: When the class-list options request limit and request-rate limit are config-
ured in a policy template, the options are applicable only in policy tem-
plates that are bound to virtual ports. These options are not applicable in
policy templates that are bound to virtual servers or in policy templates
that are used for system-wide PBSLB. For more information, see
“Request Limiting and Request-rate Limiting in Class Lists” on page 110.
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 that are based on the
source IP address of client traffic. You can also match based on one of the
following options:
• Destination IP address – Matches based on the destination IP address in
packets from the clients.
• IP address in client packet header – Matches based on the IP address in
the specified header in packets from clients.
If you do not specify a header name, this option uses the IP address in
the X-Forwarded-For header.

Request Limiting and Request-rate Limiting in Class Lists
If a LID or GLID in a class list contains settings for request limiting or

request-rate limiting, the settings apply only if the following conditions are
true:
• The LID or GLID is used in a policy template.
• The policy template is bound to a virtual port.
The settings apply only to the virtual port.
The settings 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 all the cases listed above.
CLI Examples: Request Limiting and Request-rate Limiting Set-

tings Are Used
In the following examples, the request limiting and request-rate limiting
settings are used.
GLID Used in a Policy Template and are Bound to Virtual Port

The following configuration is valid for request limiting and request-rate
limiting. The request limiting and request-rate limiting 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-policy)#exit
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
ACOS(config-slb vserver-vport)#template policy g
LID Used in Policy Template and Bound to Virtual Port

The following configuration also is valid for request limiting and request-
rate limiting. The request limiting and request-rate limiting settings are in an
LID that is configured in a policy template that has been 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: Request Limiting and Request-rate Limiting Set-

tings Are Not Used
In the following examples, the request limiting and request-rate limiting
settings are not used.
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 to
the virtual port.
ACOS(config-slb vserver)#template policy gg

IP Limiting - Configuring Source IP Limiting
System GLID
rate limiting, because the settings are in a system GLID:
ACOS(config)#system glid 1023
System-wide Policy Template

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 the list to the
ACOS device.
2. Configure the IP limiting rules and consider the following information:

• 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, config-
ure 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 class list in at least one policy template.
• For system-wide source IP limiting, apply the policy template glob-
ally.
• 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 cli-
ent. For example, if you configure system-wide IP limiting and also config-
ure 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 virtual server that
is accessed by the client.

Configuring a Class List

You can configure a class list in one of the following ways:
• Use a text editor or another device 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 105.
USING THE GUI
Importing a Class List to the ACOS device

To import a class list to the ACOS device:
1. Click Config Mode > SLB > Service > Class List.
2. Click Import.
3. Enter the file name to use for the imported class list.
4. Select the location of the file to be imported:

• Local – The file is on the computer on which you are running the GUI,
or the file is on another computer or server in the local network.
If you selected Local, complete the following steps:
a. Click Choose File and navigate to the location of the class list.
b. Select the file and click Open.
c. Proceed to step 5
• Remote – The file is on a remote server.
If you selected Remote, complete the following steps:
a. To use the management interface as the source interface for the con-
nection to the remote device, select the Use Management Port
check box.
If you do not select this check box, the ACOS device will attempt to
reach the remote server through a data interface.
b. Select the file transfer protocol.
c. In Host, enter the directory path and filename.
d. Review the protocol port number and modify if necessary.
By default, the default port number for the selected file transfer pro-
tocol is used.

e. Enter the username and password that are required to access to the
remote server.
5. Click OK.
Configuring a Class List in the GUI

2. Click Add.
3. Enter a class list name.
4. Select where you want to save the class list:

• File – The list is saved in a stand-alone file.
• Config – The list is saved in the startup-config.
Note: If the class list contains 100 or more entries, you should select the File
option. A class list can be exported only if you select File.
5. Configure the class list entries:

a. Enter the IP address and subnet mask.
• For a host entry, enter 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.
• 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.
• Enter the rule number.
Note: Ensure that you use the same number when you configure the IP limiting
rule.
c. To make the entry temporary, enter an age value.
You can enter a value of up to 2000 minutes, and the value is
removed from the class list after the age expires.
d. Click Add.
e. Repeat for each entry.
6. Click OK.

Note: The Age option applies only to host entries, such as IPv4 /32 or IPv6 /128,
but 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 entering
the following command at the Privileged EXEC or global configuration
level of the CLI:
import class-list file-name url
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 complete URL on the command line or press Enter to dis-
play a prompt for each part of the URL. If you enter the complete URL and
a password is required, you will be prompted for the password.
To enter the entire URL:

• 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
You also can export class lists to a remote server by entering 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 commands at the
global configuration level of the CLI:
[no] class-list name [file]
The file option saves the class list as a separate file. Without this option, the
class list is saved in the startup-config instead. If the class list contains 100
or more entries, enter the file option, which is valid only when you create

the class list. After you create the list, the list remains in the startup-config
or in a separate file, depending on whether you used the file option when
you created the list.
Note: A class list can be exported only if you use the file option.
The class-list command creates the class list if it is not already configured,
and changes the CLI to the configuration level for the list:
[no] ipaddr /network-mask [glid num | lid num]

• 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 that you want to replace.
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 120.
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.

• If you apply IP limits to a virtual server or a virtual port, configure the
IP limiting rules in a policy template and apply the template to the vir-
tual server or virtual port.
• If you apply IP limits on the entire system, configure the IP limiting
rules in a PBSLB template or in standalone IP limiting rules.

USING THE GUI
Configuring IP Limiting Rules in a Policy Template

To configure IP limiting rules in a policy template:
2. Do one of the following:

• Click Add.
• Select an existing template.
3. If you are creating a new template, enter the name.
4. In the IP Limiting section, configure IP limiting.

a. Do one of the following:
• In the Class List drop-down list, select a class list.
• Click Create and create a class list.
b. Configure the limiting rules to apply to the selected class list.
For parameter information, see “IP Limiting Rules” on page 108.
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.

• Click Add and create a GLID.
• Select an existing GLID.
3. Configure the IP limiting rules.

For parameter information, see “IP Limiting Rules” on page 108.
4. Click OK.

USING THE CLI
Configuring IP Limiting Rules in a Policy Template

To configure IP limiting rules in a policy template:
1. To configure IP limiting rules in a policy template, enter the following
commands at the global configuration level of the CLI:
The command creates the template and changes the CLI to the configuration
level for the template.
2. To create an IP limiting rule and changes the CLI to the configuration

level for the rule, enter the following commands:
[no] class-list lid num
This command creates an IP limiting rule and changes the CLI to the con-
figuration level for the rule. The num option specifies the rule ID, and can
be 1-31. For information about the valid values and defaults, see “IP Limit-
ing Rules” on page 108.
3. To specify the maximum number of concurrent connections that are

allowed for the client, enter the following commands:
[no] conn-limit num
4. To specify the maximum number of new connections allowed for a cli-

ent within the specified limit period, enter the following commands:
[no] conn-rate-limit num per num-of-100ms
The commands are available at the configuration level for the IP limiting
rule.
5. To specify the maximum number of concurrent Layer 7 requests that are

allowed for a client, enter the following commands:
[no] request-limit num
6. To specify the maximum number of Layer 7 requests that are allowed

for the client in the specified limit period, enter the following com-
mands:
[no] request-rate-limit num per num-of-100ms

7. To specify the action to take when a client exceeds one or more of the
limits, enter the following commands:
[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:
1. To create the rule and change the CLI to the configuration level, enter
[no] glid num
2. Enter the following commands 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 ones available at the IP limiting rule
configuration level in policy templates. For more information, see “Config-
uring IP Limiting Rules in a Policy Template” on page 118.
Specifying the Match IP Address

By default, the ACOS device matches class-list entries based on the source
IP address of client traffic. You can also match based on one of the follow-
ing options:
• 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]}
The l3-dest option matches 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.
Applying Source IP Limits

The following subsections describe how to apply IP limiting rules to the
system or to a virtual server or a virtual port.
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 them
to multiple classes, the feature is implemented. For more information, see
the following sections:
• “Configuring a Class List in the GUI” on page 114
• “Configuring Standalone IP Limiting Rules for System-Wide IP Limit-

ing” on page 117
Applying Source IP Limiting to a Virtual Server

To apply source IP limiting to a virtual server:
1. Click Config Mode > SLB > Service > Virtual Server.

• Click Add.
• Select an existing virtual server.
3. If you are creating a new virtual server, enter the name, virtual IP
address, and other settings in the General section.

4. Select a policy template.
5. If you are creating a new virtual server, configure the virtual port set-
tings 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. Access the configuration page for the virtual server.
For information, see “Applying Source IP Limiting to a Virtual Server”
on page 120.
2. On the Virtual Server Port configuration page, select the policy tem-
plate from the Policy Template drop-down list.
3. Click OK.
4. When you complete your virtual server configuration, click OK.
USING THE CLI
Applying System-Wide Source IP Limiting

To apply source IP limits to the entire system, enter one of the following
commands at the global configuration level of the CLI:
• To to apply a combined set of limits to the entire system, enter the fol-
lowing commands:
[no] system glid num
• To apply per-client IP limiting at the system level, enter the following

commands:
[no] system template policy template-name
Note: You cannot use the system template policy command and the system
pbslb command in the same configuration.
Applying Source IP Limiting to a Virtual Server

To apply source IP limiting to a virtual server, enter the following command
at the global configuration level for the virtual server:

Applying Source IP Limiting to a Virtual Port
To apply source IP limiting to a virtual port, enter the following command at
the global configuration level for the virtual port:
Displaying IP Limiting Information
USING THE GUI
To view configuration information for the feature, navigate to the configura-

tion pages described in “Configuring the IP Limiting Rules” on page 116.
To display statistics for the feature, use the CLI. (See the following section.)
USING THE CLI

• To display configuration information for IP limiting, enter the following
commands:
show class-list [name [ipaddr]]
show glid [num]
• 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 com-

mands:
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, where the clients match the 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 the 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
ACOS(config-policy-policy lid)#over-limit reset logging
The following command imports the class list 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
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
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.

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

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
Note: 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
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.
Similarly, host 192.168.1.101 is not allowed to establish a connection

during the first 10 minutes after that host entry is created. After the age
expires, the client is no longer locked down.
CLI Examples—Display
This section shows example show command output for IP limiting.
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
Table 4 describes the fields in the command output.
TABLE 4 show class-list fields

Field Description
Name Name of the class list.
IP Number of host IP addresses in the class list.
Subnet Number of subnets in the class list.
Location Indicates whether the class list is in the startup-config or in a
standalone file:
• config – Class list is located in the startup-config.
• file – Class list is located in a standalone file.
Total Total number of class lists on the ACOS device.

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
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. However,
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 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
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:
Source Destination F Current Rate Over-limit Over-RL

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:
Source Destination F Current Rate Over- Over-RL

limit
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


ICMP Rate Limiting - Configuration
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 pack-
ets when the configured thresholds are exceeded.
Note: Unless otherwise specified, the term ICMP rate limiting also applies to
ICMPv6 rate limiting.
Configuration
You can configure ICMP rate limiting filters globally, on an Ethernet inter-
face, and in virtual server templates. If you configure ICMP rate limiting fil-
ters 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 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 maximum rate is 65535 packets per second.
• Maximum rate – The maximum number of ICMP packets that are
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 is 65535 packets per second.
• Lockup time – The number of seconds for which the ACOS device
drops all ICMP traffic, after the maximum rate is exceeded. The maxi-
mum lockup time is 16383 seconds.
Note: Specifying a maximum rate (lockup rate) and lockup time is optional. If
you do not specify them, lockup does not occur.
Log messages are generated only if the lockup option is used and a lockup
occurs. Otherwise, the ICMP rate-limiting counters are still incremented,
but log messages are not generated.
Note: The maximum rate must be higher than the normal rate.

USING THE GUI
Configuring ICMP Rate Limiting

To globally configure ICMP rate limiting:
1. Click Config Mode > Security > Network > ICMP Rate Limiting.
2. Select one of the following check boxes to activate the configuration

fields:
• ICMP Rate Limiting
• ICMPv6 Rate Limiting
3. Enter a normal rate.
4. Enter a maximum rate lockup rate.
5. Enter a maximum 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. On the LAN tab, click an interface name.
3. Select one of the following check boxes:

4. Enter the normal rate.
5. Enter the maximum lockup rate.
6. Enter the lockup time.
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 is applicable only in software releases that support SLB.
1. Click Config Mode > SLB > Service > Template > Virtual Server.

• Click Add.
• Click an existing template.
3. Select one of the following check boxes:

4. Enter a normal rate.
5. To configure the lockup time, select the Lockup Status check box, and
enter the following values:
• Lockup Rate
• Lockup Period
6. Click OK.
USING THE CLI
To configure an ICMP rate-limiting filter, enter one of the following com-

mands:
[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 these commands at 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 131.

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

HTTP Slowloris Prevention - Overview
HTTP Slowloris Prevention
Overview
ACOS includes an HTTP template option that specifies the maximum num-
ber of seconds that are allowed for all parts of a request header to be
received. If the entire request header is not received in the specified amount
of time, ACOS terminates the connection.
This option provides security against attacks such as Slowloris attacks,

which attempt to consume resources on the target system by sending HTTP
requests in multiple increments 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 be set to a maximum of 31 seconds, and

the default is 7 seconds.
USING THE GUI
Configuring the HTTP Request Wait Time

To configure the HTTP request wait time:
1. Click Config > SLB > Template > HTTP.

• Click on an existing template.
• Click Add.
3. In HTTP Request Header Wait Time, edit the value.
4. Click OK.
USING THE CLI
To change the request-header wait time in an HTTP template, enter the fol-
lowing 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.

HTTP Slowloris Prevention - Overview

Log DDoS Attack Detection Events - Overview
Log DDoS Attack Detection Events
Overview
This feature introduces the following logging commands to detect and log
security-related events:
• system anomaly log
This command logs IP anomalies.
• system attack log
• This command logs SYN/ACK attacks.

• system pbslb log
This command logs sock stress attacks.
Each of these commands can be accessed and enabled at the global configu-
ration level. By default, ACOS runs system checks every 30 seconds. If
ACOS detects any changes, the appropriate log is printed.
CLI Example
The following CLI example shows the log output that is generated by the
system anomaly log command:
Jun 23 2013 14:50:46 Warning [SYSTEM]:IP Anomaly packets matching the TCP NO
FLAG profile have been detected. Previous 531, Current 6999
Jun 23 2013 14:50:46 Warning [SYSTEM]:IP Anomaly packets matching the LAND
ATTACK profile have been detected. Previous 531, Current 6999
system attack log command:
Jun 23 2013 14:40:45 Warning [SYSTEM]:IP packets matching the TCP SYN ATTACK
profile have been detected. Previous 0, Current 820711
Jun 23 2013 14:39:45 Warning [SYSTEM]:IP packets matching the TCP ACK ATTACK
profile have been detected. Previous 0, Current 2754803
system pbslb log command:
Feb 16 2014 02:38:51 Warning [SYSTEM]:IP Anomaly packets matching the PBSLB
ZERO WINDOW profile have been detected. Previous 0, Current 12
Feb 16 2014 02:20:10 Warning [SYSTEM]:IP Anomaly packets matching the PBSLB
ZERO WINDOW profile have been detected. Previous 0, Current 11

Log DDoS Attack Detection Events - Overview

DNS Application Firewall - Overview
DNS Application Firewall
Overview
The DNS Application Firewall (DAF) provides security for DNS VIPs.
The DAF examines DNS queries addressed to a VIP to ensure that the que-
ries are formed properly (not malformed). If a malformed DNS query is
detected, depending on the action that you specified in the DNS security
policy, the ACOS device takes one of the following actions:
• 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 still keeping the queries away from the DNS
server.
This feature parses DNS queries that are based on the following RFCs:
• “RFC 1034: Domain Names – Concepts and Facilities” at
https://www.ietf.org/rfc/rfc1034.txt
• “RFC 1035: Domain Names – Implementation and Specification” at
https://www.ietf.org/rfc/rfc1035.txt
• “RFC 2671 – Extension Mechanisms for DNS (EDNS0)” at
http://tools.ietf.org/html/rfc2671

DNS Application Firewall - DNS Sanity Check
DNS Sanity Check

DNS security performs a sanity check on DNS client requests and, if appli-
cable, 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 sanity check, all of the follow-
ing 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)
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 condi-
tions must be met:
• Flags.opcode <=5
• Flags.rcode == 0
• qdcount > 0
• ancount > 0 (Answer count)

DNS Application Firewall - Configuration
Configuration
To configure DNS security for a DNS virtual port:
1. Create a DNS template and specify the DNS security action in the tem-
plate.
2. Bind the DNS template to the DNS virtual port.
USING THE GUI

1. Click Config Mode > Security > Template > DNS Firewall.
2. Click Add.
3. Enter a template name.
4. Next to DNS Template, select Enabled.
5. Select the Malformed Query check box.
6. Select one of the following actions:

• Drop
• Forward to Service group
To use this option, select a service group from the drop-down list.
7. Click OK.
USING THE CLI

1. 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.
2. To enable DNS security and specify the action to take for malformed
DNS queries, enter the following commands:
[no] malformed-query
{drop | forward service-group-name}
The drop option drops malformed queries, and the forward option
sends the queries to the specified service group.
With both options, the malformed queries are blocked from being pro-
cessed by the DNS virtual port to which the template has been applied.

DNS Application Firewall - Configuration Examples
Configuration Examples
This section includes the following examples:
• “DNS Application Firewall Setup” on page 142
• “Service-group Redirection for DNS “Any” Requests (using aFleX)” on

page 143
DNS Application Firewall Setup

The following commands configure a DNS template for DNS security and
bind the template to the DNS virtual port on a virtual server:
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 that are 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 the requests 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 - Overview
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 sup-
ports the ability to respond to client requests for the following types of well-
known resource records:
• A
• AAAA
• CNAME
• NS
• MX
• PTR
• SRV
• TXT
Placing the ACOS device in the DNS infrastructure exposes it to potential

online attacks. When DNS was originally designed, there were no mecha-
nisms to ensure the DNS infrastructure would remain secure.
In an unsecured DNS environment, the client’s DNS resolver cannot assess

the validity of the address that it receives for a domain name, so the client’s
DNS resolver cannot tell whether an address that was received for a domain
is from the legitimate owner of that domain.
This potential security hole opens the door for possible forgeries, which
makes DNS vulnerable to “man-in-the-middle” attacks, DNS cache poison-
ing attacks, and other types of 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, the Internet Engineering Task Force (IETF)
introduced a set of standards in the mid-1990s called Domain Name System
Security Extensions (DNSSEC). These additional standards add authentica-
tion to DNS and help ensure the integrity of the data that is transferred
between the client resolvers and DNS servers.
DNSSEC authenticates by using cryptographic keys and digital signatures,

which ensure that entries in the DNS tables are correct and that connections
are made to legitimate servers. The ACOS device’s implementation of
DNSSEC is based on the following RFCs:
• “DNS Security Introduction and Requirements” at
http://www.rfc-base.org/rfc-4033.html
• “Resource Records for the DNS Security Extensions” at
• “Protocol Modifications for the DNS Security Extensions” at
Note: DNSSEC for GSLB is not supported in proxy mode for this release.
DNS without Security

Figure 20 provides a visual introduction to basic DNS without DNSSEC.
The figure shows the recursive lookup process that occurs when a client
resolver requests the IP address for a particular URL. This illustration
shows how a client request works in a simple DNS environment that does
not have DNSSEC.

FIGURE 20 DNS Packet Flow without DNSSEC
A client requires access to a server in the zone1.example.org domain. 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. The user enters the domain name in the
web browser’s URL, and the IP address that is associated with this domain
is obtained in the following way:
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 if the Caching
DNS server already has the required IP address for the requested exam-
ple.org domain cached in its memory.
2. The Caching DNS server has a list of IP address-to-domain mappings,

but the list is not comprehensive.

3. Unfortunately, the Caching DNS server does not have the required IP
address.
The DNS server 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.
4. The Root DNS Server does not have the requested IP address, but in an
attempt to point the Caching DNS server in the right direction, it
responds to the request with a Name Server (NS) record.
The record 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, but again, the
TLD server points the Caching DNS server in the right direction by pro-
viding an NS record that contains the IP address for the next name
server in the DNS hierarchy, which is the authoritative DNS server for
the example.org subdomain.
7. Now that it has the IP address needed to reach the authoritative DNS
server for the example.org domain, the Caching DNS server sends a
request for zone1.example.org to this authoritative DNS server.
8. 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.
9. The Caching DNS Server sends a request to the authoritative DNS

server for the zone1.example.org domain.
10. The ACOS device, which is the authoritative DNS server for
zone1.example.org, has the IP address that the client needs. It sends the
requested IP address to the Caching DNS server.
11. 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 that is illustrated in Figure 20, except 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 directly beneath it in the DNS
hierarchy to verify that signed resource records from the Authoritative
DNS server for that zone are legitimate.
• Resource Record Signature (RRSIG) – Digitally signs another resource
record, such as an A record.
The digital signature is created by applying a hash function to the DNS
record to reduce its file size, an encryption algorithm is applied to the
hash value (using the private key), and this encrypted hash value
appears as the digital signature at the bottom of the resource record. The
RRSIG record, which contains the private key that is used to encrypt the
hash value, appears at the bottom of the record that is being signed.
While Figure 20 illustrates how basic DNS works without DNSSEC,
Figure 21 provides an updated version of this illustration by showing 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.
However, when DNSSEC is added to this scenario, the additional records

(such as DS, RRSIG, and DNSKEY) are used to sign and authenticate the
communications from the DNS servers, and prove to the client that each of
the name servers in the “chain of trust” are authoritative for their respective
domains. For more information, see “Building the Chain of Trust” on
page 152.

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 zone1.example.org IP address.
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 that is used to
store the private key to sign the NS record. 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.
The Caching DNS 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.
6. The Caching DNS server sends the address query to the Authoritative
DNS server for example.org.
7. The Authoritative DNS server for example.org does not have the
requested address, so it responds to the caching server’s request by send-
ing the NS record (signed with the RRSIG record).
This NS record contains the IP address of the Authoritative DNS server
for zone1.example.org. The server sends the DS record for the
zone1.example.org server to the Caching DNS server.
8. The Caching DNS server sends the address query to the Authoritative
DNS server for zone1.example.org, which happens to be the ACOS
device.
9. The Caching DNS server reaches the Authoritative DNS server for
zone1.example.org.
The Authoritative DNS server 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.
10. 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 check the
hash values back up the chain.
11. 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.

12. To continue assembling the chain of trust, the Caching DNS server asks
the Authoritative DNS server for example.org for its DNSKEY record.
13. The Authoritative DNS server for example.org sends its DNSKEY
record with an RRSIG record and the private key that was used to sign
the DNSKEY record.
14. The Caching DNS server then asks the TLD server for .org for its DNS-
KEY record.
15. The TLD server sends its DNSKEY record with an RRSIG record that
was used to sign the DNSKEY record.
The Caching DNS server now has all the private/public key pairs and
has validated all of the links in the chain of trust. It 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 infra-
structure. A Chain of Trust is built like a series of links, with each node
authenticating the node below it.
The 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.

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 DNS-
KEY 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 another key, the Key Signing Key (KSK),
which also belongs to this zone.

The Start of Authority (SOA) record indicates that this server is the Author-
itative 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.
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, it indicates that the packet that contains the key record may have
been tampered, 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 correctly linked to
the DS record above. In turn, the DNSKEY record for the Authoritative
DNS Server that is associated with the example.org domain is correctly
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
because of the “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 “trust anchor” minimizes the chance that a client could access a
corrupt root DNS server.
Because of this anchor, the client knows the Root DNS Server can be
trusted, and the client can infer that all of the other nodes in the Chain of
Trust can also be trusted. Because the hash values match all the way down
the line, this is an indication that the Chain of Trust is intact, and that the cli-
ent’s DNS resolver can trust the Authoritative DNS Server for zone1.exam-
ple.org, which is located at the bottom of the Chain of Trust in the DNS
hierarchy.

Dynamic Key Generation and Rollover

Because DNSSEC uses dynamic key generation and rollover, that is pro-
vided by Hardware Security Module (HSM), you must configure HSM.
Key Generation and Rollover Parameters
When HSM and DNSSEC are enabled, ACOS uses the following key gen-
eration and rollover settings for DNSSEC:
• Key size – Length of the keys in bits.
You can specify 1024-4096 bits, and the default length for ZSKs and
KSKs is 2048 bits.
• Lifetime – Maximum amount of time that 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 lifetime and rollover time each can be from 1 to 2,147,483,647 seconds,
which is approximately 68 years. Here are the default lifetime and rollover
time 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), with
rollover time 30,931,200 seconds (358 days).
Key Rollover and Distribution Process

Dynamic key generation and rollover are enabled by default when a DNS-
SEC template becomes active, and no additional configuration is required.
Figure 23 shows the rekey and rollover schedule when the default rekey and
rollover settings for ZSKs and KSKs are used.

FIGURE 23 DNSSEC - Default Rekey and Rollover
When DNSSEC is enabled, HSM generates a KSK for the GSLB zone, gen-
erates a ZSK for the zone, and signs it with the KSK. The following type of
messages appear in the log:
Note: ACOS generates the following type of messages 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
Starting at the bottom of the output, the first message indicates the success-
ful generation of a KSK for child zone test.com. The next message is a
reminder to copy the DS resource record for the key to the authoritative

DNS server for the parent zone. The third message indicates the successful
generation of the ZSK for child zone test.com. The final message indicates
the completion of the rekey process.
Although key generation and rollover are automatic, ACOS does not auto-
matically send the DS record for the new KSK to the parent zone. This part
of the process must be performed manually. If the default key generation
and rollover settings are used, this process needs to be performed once a
year.
Importing/Exporting Key Files
The commands to import or export DNSSEC key files are the same as in
previous releases:
{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 key generation to be
fully completed. 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 Guide.
Emergency Key Rollover
If necessary, to force an immediate key rollover, enter the following com-

mand at the global configuration level of the CLI:
dnssec key-rollover zone-name
{KSK {ds-ready-in-parent-zone | start} | ZSK start}
The start option initiates the rollover for the key type that you specified.
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. You can
use this option only after you or another administrator have installed the DS
record for the new KSK onto the authoritative DNS server for the parent
zone.

Changing Key Settings
To change the lifetime and rollover settings for ZSKs and KSKs, enter the
following commands at the configuration level for the DNSSEC template:
[no] ksk lifetime seconds [rollover-time seconds]
[no] zsk lifetime seconds [rollover-time seconds]
For information about the supported values, see “Key Generation and Roll-
over Parameters” on page 155.
Hardware Security Module Support

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, and this version can be
useful in testing or in environments where the additional security of a hard-
ware-based HSM is not required.
Note: HSM is required for DNSSEC, and the manual key generation of DNS-
SEC ZSKs or KSKs is not supported.
Configuration
To configure DNSSEC:
1. Configure an HSM template.
2. Configure a DNSSEC template.
3. Configure a GSLB policy.

Enable this ACOS device to act as the authoritative DNS server for
GSLB zones that use the policy.
4. 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.
5. If the ACOS device is not part of a GSLB controller group, enable

standalone operation.
6. Configure a VIP to receive DNSSEC requests.

USING THE GUI
The current release does not support DNSSEC configuration by using the
GUI.
USING THE CLI
Configuring an HSM Template

To configure an HSM template:
1. To create the HSM template and enter the configuration level in the
CLI, enter the following commands:
[no] hsm template template-name softHSM
2. To specify the passphrase (PIN) that is required to access the HSM inter-
face:
[no] password hsm-passphrase
Configuring a DNSSEC Template
To create the template and enter the configuration level of the CLI, enter the
following commands:
[no] dnssec template {default | template-name}
To modify the default DNSSEC template, enter the default option. To cre-
ate a new template, enter a different name.
The following commands are available at the configuration level for the
template.
DNSSEC Template
Command Description
[no] algorithm
{RSASHA1 |
RSASHA256 |
RSASHA512} Cryptographic algorithm that is used to encrypt
DNSSEC keys.
[no]
combinations-
limit num Maximum number of combinations per Resource
Record Set (RRset), where RRset is defined as
all the records of a particular type for a particular
domain, such as all of the “quad-A” (IPv6)

records for www.example.com.
You can specify up to 65535 combinations.

[no] dnskey-ttl
seconds Lifetime for DNSSEC key resource records. The
TTL can be a maximum of 864,000 seconds.
[no] enable-
nsec3 Enables NSEC3 support.
[no] hsm
template-name Binds an HSM template to this DNSSEC tem-
plate.
[no] ksk
keysize bits Key length for KSKs, and you can specify
1024-4096 bits.
[no] ksk
lifetime
seconds
[rollover-time
seconds] Lifetime for KSKs. The rollover-time specifies
how long you must wait before generating a
standby key to replace the current key. You can
specify a maximum of 2147483647 seconds.
Generally, you must specify a shorter rollover-

time setting than the lifetime, so that the new key
is ready when it is needed.
[no] return-
nsec-on-failure Returns an NSEC or NSEC3 record in response
to a client request for an invalid domain. As orig-
inally designed, DNSSEC exposes the list of
device names in a zone, which allows an attacker
to gain a list of network devices that could be
used to create a map of the network.
[no] signature-
validity-period
days Days for which a signature remains valid, and the
range is from 5 to 30 days.
[no] zsk
lifetime
seconds
[rollover-time
seconds] Lifetime for ZSKs, 1-2147483647 seconds. The
rollover-time specifies how long to wait before

generating a standby key to replace the current
key. The rollover-time setting also can be
1-2147483647 seconds. Generally, the rollover-
time setting should be shorter than the lifetime,
to allow the new key to be ready when needed.
Default The default DNSSEC template contains the following defaults:

• algorithm – RSASHA256
• combinations-limit – 31
• dnskey-ttl – 14,400 seconds (4 hours)
• enable-nsec3 – disabled
• hsm – Not set
• ksk keysize – 2048
• ksk lifetime – 31536000 seconds (365 days) with a rollover-time of

30931200 seconds (358 days)
• return-nsec-on-failure – enabled
• signature-validity-period – 10
• zsk keysize – 2048
• zsk lifetime – 7776000 seconds (90 days) with a rollover-time of

7171200 seconds (83 days)
Configuring a GSLB Policy

To configure a GSLB policy and enable server mode:
1. To accesses the configuration level for the policy, enter the following
commands:
[no] gslb policy {default | policy-name}
2. To enable server mode and enable an ACOS device to be the authorita-

tive DNS server for the GSLB zones that use this policy, enter the fol-
lowing command:
[no] dns server authoritative ns ptr srv sec
Binding the DNSSEC Template to the Zone

To apply DNSSEC to a zone, enter the following command at the configura-
tion level for the zone:
[no] template dnssec template-name

The other configuration requirements are the same as those without DNS-
SEC. For more information, see the Global Server Load Balancing Guide.
Enabling the Standalone Operation

To enable the ACOS device to run DNSSEC without being a member of a
GSLB controller group, enter the following command at the global configu-
ration level of the CLI:
[no] dnssec standalone
Configuring VIP for DNSSEC Requests

To creates the virtual server and accesses the configuration level for it, enter
the following commands:
[no] slb virtual-server name ipaddr
3. To add a DNS service port, enter the following commands:

[no] port portnum {udp | dns-tcp}
For DNS over UDP, enter the udp option, and for DNS over TCP, enter 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 standalone DNSSEC
operation, but you do not need to configure a GSLB controller group.
Support for standalone DNSSEC operation is optional and is disabled by

default.
USING THE GUI
The current release does not support DNSSEC configuration by using the
GUI.
USING THE CLI

To enable standalone DNSSEC operation, enter the following command at
[no] dnssec standalone

Configuration Example
Here is the configuration from a device configured for DNSSEC:
hsm template hsm1 softhsm
password encrypted /+mboU9rpJM8EIy41dsA5zwQjLjV2wDn-
PBCMuNXbAOc8EIy41dsA5zwQjLjV2wDn
!
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
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
!
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
!
slb 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
!
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

SSL Insight - Overview
SSL Insight
This chapter describes the SSL Insight feature (previously known as SSL
Intercept) and how to configure it.
Note: SSL Insight also is referred to as SSL Forward Proxy.
Overview
SSL Insight allows third-party traffic inspection devices to examine
encrypted traffic “in the clear”. The traffic inspection devices can be fire-
walls, Data Loss Prevention (DLP) appliances, email protection systems,
and so on. To perform SSL Insight, a pair of ACOS devices is placed on
either side of the traffic inspection devices.
One of the inside ACOS devices intercepts traffic from inside clients,
decrypts the traffic, and sends it to the traffic inspection devices. If the traf-
fic inspection devices allow the traffic, the devices forward the traffic to the
external ACOS device. The external ACOS device encrypts the traffic again
before sending it to its destination.
Note: You can deploy one ACOS device on either side of the traffic inspection
devices or, for redundancy, you can deploy an HA / VRRP-A set on either
side.
Figure 24 shows an example of an SSL Insight deployment.

FIGURE 24 SSL Insight Deployment
In this example, an inside client sends an email using an external, web-

based email service. The inside ACOS device uses SLB load balancing to
select a traffic inspection device, decrypts the email, and sends the
decrypted email to the traffic inspection device.
If the policies on the traffic inspection device permit the email to be sent,
the external ACOS device encrypts the email again and sends it to the exter-
nal email server. You can optionally attach a protocol analyzer to the ACOS
device and use the traffic mirroring feature to send the unencrypted traffic to
the traffic analyzer. (This is not shown in Figure 24.)

SSL Operation
Figure 25 shows a more detailed view of the SSL Insight process.
FIGURE 25 SSL Insight (walkthrough)
The following steps provide an overview of the SSL Insight process:

1. A client sets up an SSL connection with the inside ACOS device and
sends an encrypted request.
In this example, the client’s request consists of an email that will be sent
by using an external email service.
2. The inside ACOS device selects a traffic inspection device, decrypts the
request, and sends the request to the traffic inspection device.
3. The traffic inspection device inspects the request data.

In this example, the traffic inspection device allows the traffic and for-
wards it to the external ACOS device.
4. The external ACOS device encrypts the request and sends it to the exter-
nal server.
5. The server sends an encrypted reply.
6. The external ACOS device decrypts the reply and sends it back though
the same traffic inspection device.

7. If the reply traffic is allowed by the traffic inspection device, the reply is
forwarded to the inside ACOS device.
8. The inside ACOS device encrypts the reply and sends it to the client.
SSL Operation on Inside ACOS device
The inside ACOS device completes the following SSL operations for SSL
Insight:
• Negotiates the SSL sessions with inside clients
• Decrypts client traffic before sending the traffic to a traffic inspection

device
From the inside client’s perspective, the SSL session is between the client
and the external server. However, the SSL session is actually between the
inside ACOS device and the client.
SSL Insight requires inside client devices to trust the credentials of the
ACOS device. Typically, this is accomplished by importing the same self-
signed certificate and private key to the inside ACOS device that is installed
on other inside resources that need to be trusted by clients. In the client
browser certificate store, the self-signed certificate functions as a CA-
signed certificate.
The inside ACOS device uses the certificate during the SSL handshake with
inside clients, as seen in Figure 26.

FIGURE 26 SSL Operation on Inside ACOS device
The following steps provide an overview of the SSL operation:

1. The client sends a request to set up an SSL session with the external
server.
The external server is not shown in Figure 26.
2. The inside ACOS device presents the enterprise’s self-signed certificate

to the client.
If the client browser’s certificate store contains a copy of the self-signed
certificate, the client can trust the inside ACOS device and allows the
SSL session to be set up.
Server Name Extension Support

The ACOS device supports the Server Name Indication (SNI) extension for
TLS. The SNI extension enables servers that manage content for multiple
domains at the same IP address to use a separate server certificate for each
domain.
In an SSL Insight deployment, SNI support allows multiple self-signed cer-

tificates to be used. During configuration, you can map each certificate to

the domain name of an external resource that is accessed by inside clients.
SSL Operation on Outside ACOS device
The outside ACOS device completes the following SSL operations for SSL
Insight:
• Negotiates SSL sessions with external servers
• Decrypts traffic from external servers before sending the traffic to the
traffic inspection devices
• Encrypts client requests before sending the requests to external servers
Packet Flow for SSL Insight
Figure 27 provides a detailed example of the SSL Insight packet flow.

FIGURE 27 SSL Insight Packet Flow

SSL Insight - Configuration
Configuration
This section provides information about the tasks you need to complete to
configure and use SSL Insight. For configuration examples, see
“Configuration Example” on page 190.
Virtual Ethernet Interfaces
The IP interfaces on the ACOS device are configured as Virtual Ethernet

(VE) interfaces, and there are interfaces on the inside and outside ACOS
devices.
The following VE interfaces are on the outside ACOS devices:

• VE 10 – Connects the outside ACOS devices to the Internet
• VE 15 – Connects the outside ACOS devices to traffic inspection device

PSG1
• VE 16 – Connects the outside ACOS devices to traffic inspection device
PSG2
The following VE interfaces are on the inside ACOS devices:

• VE 20 – Connects the inside ACOS devices to the inside clients
• VE 15 – Connects the inside ACOS devices to traffic inspection device

PSG1
• VE 16 – Connects the inside ACOS devices to traffic inspection device
PSG2
The outside ACOS devices, the inside ACOS devices, and the traffic inspec-
tion devices all are in the same subnet.
Note: For simplicity, the management interfaces are not shown.
Promiscuous VIP Support

On each VE on the inside and outside ACOS devices, promiscuous VIP
support is enabled, which is required for wildcard VIPs. When you enable
promiscuous VIP support on a VE, the option is automatically enabled on
each Ethernet data port in the VE.

Wildcard VIPs
SSL Insight uses wildcard VIPs, which is a VIP with one of the following
addresses:
• 0.0.0.0 (IPv4)
• :: (IPv6)
A wildcard VIP can intercept traffic for any destination IP address.

Figure 28 shows how wildcard VIPs are used in SSL Insight.
FIGURE 28 SSL Insight - Wildcard VIPs
Each pair of ACOS devices has the following wildcard VIPs:

• Outbound – Intercepts traffic that is sent from the inside network to the
Internet.
• Inbound – Intercepts traffic that is sent from the Internet to a client on
the inside network.

Traffic Flow Through Wildcard VIPs
The following steps provide an overview of the traffic flow through the
wildcard VIPs:
1. The inside client at 172.16.242.36 sends an encrypted request to
mail.example.com.
2. The outbound wildcard VIP on the inside ACOS device intercepts the
SSL request.
The ACOS device decrypts the traffic and sends it to a traffic inspection
device.
3. The traffic inspection device sends the approved traffic, in the clear, to
an outside ACOS device.
4. The outbound wildcard VIP on the outside ACOS device intercepts the
traffic.
The ACOS device encrypts the traffic, and sends it to the server.
5. The server sends an encrypted reply.
6. The encrypted response traffic from the server is decrypted by the out-
side ACOS device and sent to the traffic inspection device.
7. The traffic inspection device sends the approved reply in the clear to the
inside ACOS device.
8. The decrypted response traffic from the traffic inspection device is

encrypted and sent to the client.
Wildcard VIPs on Inside ACOS Devices

This section provides information about the wildcard VIPs on the inside
ACOS devices.
Inside ACOS device – Outbound VIP

The outbound VIP on the inside ACOS devices intercepts traffic from inside
clients. The following virtual ports are configured on this VIP:
• 443 (HTTPS) – Intercepts SSL-encrypted traffic from clients.
Port 443 is bound to a service group that contains the paths through the
traffic inspection devices to the outside ACOS devices. For more infor-
mation, see “Service Groups” on page 180.
Destination NAT is disabled, and the ACOS device does not change the
source or destination IP addresses of the traffic. Port translation is

enabled and is required because the ACOS device needs to change the
destination protocol port from 443 to the port number on which the traf-
fic inspection devices listen for traffic that is decrypted by the ACOS
device.
The SSL options required for SSL Insight are configured in a client-SSL
template that is bound to this virtual port. For more information, see
“Configuring the Client-SSL Template” on page 184.
• 0 (TCP), 0 (UDP), and 0 (Others) – These wildcard ports intercept all
client traffic other than SSL-encrypted traffic. The TCP port intercepts
all other TCP traffic from clients, and the UDP port intercepts all other
UDP traffic from clients. The Others port intercepts client traffic of
types other than those listed above.
The TCP and Others wildcard ports are bound to a TCP service group
that contains the paths through the traffic inspection devices to the out-
side ACOS devices. The UDP wildcard port is bound to a UDP service
group that contains the paths through the traffic inspection devices to the
outside ACOS devices.
Destination NAT and port translation are disabled.
Inside ACOS device – Inbound VIP

The inbound VIP on the inside ACOS devices intercepts inbound traffic
allowed by the traffic inspection devices. The following virtual ports are
configured on this VIP:
• 0 (TCP)
• 0 (UDP)
• 0 (Others)
On each of these virtual ports, the destination NAT and port translation is
disabled.
Each of these virtual ports do not use a service group, but use the following
options:
• Use-rcv-hop-for-resp – This option sends reply traffic for the session
back through the same traffic inspection device to the outside ACOS
devices.
• Use-default-if-no-server – This option overrides the default ACOS
behavior when selection of a service-group member fails. By default,
the ACOS device drops the traffic.
However, since these ports do not use a service group, this option is
required to change the default behavior, which in this case, is to forward

the traffic at Layer 3. The inbound traffic that is intercepted by these vir-
tual ports is forwarded to clients at Layer 3.
Wildcard VIPs on Outside ACOS devices

This section provides information about the wildcard VIPs on the outside
ACOS devices.
Outside ACOS – Outbound VIP

The outbound VIP on the outside ACOS devices intercepts outbound traffic
that is allowed by the traffic inspection devices. The following virtual ports
are configured on this VIP:
• 8080 (HTTP) – Intercepts decrypted client traffic allowed by the traffic
inspection devices.
Port 8080 is bound to a service group that contains a member for the
gateway router to the Internet. The service group member consists of the
router’s IP address and protocol port 443.
Destination NAT is disabled, and port translation is enabled. Port trans-
lation is required because the ACOS device needs to change the destina-
tion protocol port to 443 before sending the re-encrypted traffic to the
gateway router.
The SSL option that is required for SSL Insight is configured in a
server-SSL template that is bound to this virtual port. For more informa-
tion, see “Configuring the Server-SSL Template” on page 188.
• 0 (TCP), 0 (UDP), and 0 (Others) – These wildcard ports intercept all
client traffic other than SSL-encrypted traffic. The TCP port intercepts
all other TCP traffic from clients. The UDP port intercepts all other
UDP traffic from clients. The Others port intercepts client traffic of
types other than those listed above.
The TCP and Others wildcard ports are bound to a TCP service group
that contains a member for the gateway router to the Internet. The UDP
wildcard port is bound to a UDP service group that contains a member
for the gateway router.
Destination NAT and port translation are disabled.
Each of these ports also uses the use-rcv-hop-for-resp option, which
sends reply traffic for the session back through the same hop.

Outside ACOS – Inbound VIP
The inbound VIP on the outside ACOS devices intercepts inbound traffic
from the Internet. The following virtual ports are configured on this VIP:
• 0 (TCP)
• 0 (UDP)
• 0 (Others)
On each of these virtual ports, destination NAT is disabled. Port translation

also is disabled.
The TCP and Others ports are bound to a TCP service group that contains
members for the paths through the traffic inspection devices. Likewise, the
UDP port is bound to a UDP service group that contains members for the
paths through the traffic inspection devices.
Access Control Lists

You can apply an Access Control List (ACL) to a wildcard VIP. The ACL
controls the IP addresses and protocol ports that are allowed to access the
VIP. The ACOS device can have only one wildcard VIP that does not have
an ACL applied to it.
Note: The wildcard VIPs in the example deployment in this chapter all use
ACLs.
ACLs on the Outside ACOS Device’s Wildcard VIPs

You can use the following ACLs:
• Outbound – Permits IP traffic from IP addresses in the 172.16.24.32 - 63
range to any destination IP address. This is the client address range.
• Inbound – Permits IP traffic from any source IP address to destination IP
addresses in the 172.16.24.32 - 63 range.
ACLs on the Inside ACOS Device’s Wildcard VIPs

You can use the following ACLs:
• Outbound – Denies traffic from any IP address in the 172.16.24.32 - 63
range to host address 172.16.242.33, which is the floating IP address
that is used by VRRP-A in the sample deployment.
Permits traffic from addresses in the 172.16.24.32 - 63 range to any des-
tination.
• Inbound – Permits IP traffic from any source IP address to destination IP
addresses in the 172.16.24.32 - 63 range. This is the client address
range.

How Non-matching Traffic Is Handled
The ACOS device handles traffic that does not match the ACL as follows:
• If the ACOS device’s configuration contains a wildcard VIP that does
not use an ACL, the traffic is handled by that wildcard VIP. (The config-
uration can contain one wildcard VIP that does not use an ACL. The
ACOS device does not support more than one wildcard VIP without an
ACL.)
• If the configuration does not contain a wildcard VIP with no ACL, the
traffic is routed at Layer 3.
Service Groups
The sample deployment in this chapter uses the following service groups.
The service groups for the traffic inspection devices contain members that
represent the paths through the traffic inspection devices. When you create
the real server configuration for a traffic inspection device, use the IP
address of the ACOS interface on the other side of the traffic inspection
device.
Note: Do not use the IP address of the traffic inspection device.
Service Groups on Inside ACOS Devices
On an inside ACOS device, there are TCP and UDP service groups that
each contain members with the following options:
• Name of a real server configuration that consists of the IP address of the
outside ACOS device on the other end of the traffic inspection device
• Port 0
Service Groups on Outside ACOS Devices

The following service groups are found on the outside ACOS device:
• TCP service group that contains a member that consists of the default
gateway’s IP address and port 443.
• TCP and UDP service groups that each contain a member that consists
of the default gateway’s IP address and port 0.

• TCP and UDP service groups that each contain members that consist of
the following options:
• Name of a real server configuration that consists of the IP address of
the outside ACOS device on the other end of the traffic inspection
device
• Port 0
Configuring SSL Insight

Some configuration tasks differ depending on whether the ACOS device is
on the external side of the firewalls or on the inside side. For example, the
ACOS device on the external side of the firewalls uses a client-SSL tem-
plate, whereas the ACOS device on the inside side of the firewalls uses a
server-SSL template.
Configuring the Inside ACOS Devices

To complete the configuration on the ACOS device that is connected to the
inside side of the traffic inspection devices:
1. Enable promiscuous VIP mode on the Ethernet interfaces that are con-
nected to the firewalls.
This is required by the wildcard VIPs.
2. Import the root CA-signed certificate for the content servers and the cer-
tificate’s private key.
This certificate must be one that is trusted by inside clients.
3. Configure the client-SSL template with the following required options:

• Enable SSL Insight support.
• Add the root certificate for your content servers.
• Add the root certificate’s private key.
4. Create real server configurations for the paths through the traffic inspec-
tion devices and add the devices to the TCP and UDP service groups.
5. Configure the wildcard VIPs.

SSL Insight - CLI Configuration
Configuring the Outside ACOS Devices
To complete the configuration on the ACOS device that is connected to the
external side of the firewalls:
1. Enable promiscuous VIP mode on the Ethernet interfaces that are con-
nected to the firewalls.
This is required by the wildcard VIPs.
2. Configure the server-SSL template.

The option to enable SSL Insight support is required.
3. Create real server configurations for the paths through the traffic inspec-
tion devices and add the devices to the TCP and UDP service groups.
4. Create a real server configuration for the default gateway router to the
Internet.
5. Create a separate service groups for ports 443, TCP port 0, and UDP
port 0.
6. Configure the wildcard VIPs.
GUI Configuration
For the steps to configure SSL Insight by using the GUI, see the
SSL Insight Deployment Guide.
CLI Configuration
This section provides information about configuring SSL Insight by using
the CLI.
Configuring the Inside ACOS devices

This section shows the CLI syntax to configure SSL Insight on the outside
ACOS devices.

Enabling Promiscuous VIP Mode on Ethernet Interfaces
On each Ethernet interface that is connected to a firewall, enter the follow-

ing command at the configuration level for the interface:
ip allow-promiscuous-vip
Note: If you use a Virtual Ethernet (VE) interface to connect to the traffic
inspection device, you need to enable promiscuous mode only on the VE.
The ACOS device automatically enables the promiscuous mode on each
of the Ethernet ports in the VLAN that belongs to the VE.
Importing the Root CA-signed Certificate for the Content Servers
To import the root CA-signed certificate that is used by the content servers,
and the certificate’s private key, enter the following commands at the global
configuration level:
slb ssl-load certificate file-name

[type {der | p7b | pem | pfx [password string]}]
[use-mgmt-port]
url
slb ssl-load private-key file-name

[use-mgmt-port]
url
The type option specifies the certificate file type, and the default is pem.
This option is not applicable when you import the private key.
In each command, the use-mgmt-port option uses the ACOS device’s man-
agement port to import the certificate. If you do not use this option, the
ACOS device uses a data interface instead.
url can be one of the following options:

• 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

Configuring the Client-SSL Template
To configure the client-SSL template:

1. To configure the client-SSL template, enter the following command at
slb template client-ssl template-name
2. To specify the CA-signed certificate to use for SSL connections with cli-
ents:
forward-proxy-ca-cert certificate-name
3. To specify s the private key for the CA-signed certificate, enter this
command:
forward-proxy-ca-key private-key-name
4. To enable SSL Insight support, enter the following command:

forward-proxy-enable
Mapping the Domain Names to the Server Certificates (if appli-

cable)
If the servers manage more than one domain at the same IP address, you
must map the domain names to the certificates after importing the
certificates to the ACOS device.
To map a certificate to a domain, enter the following command at the con-

figuration level for the client-SSL template:
[no] server-name domain-name
cert certificate-name key private-key-name
[partition shared]
[pass-phrase string]
Configuring the Paths Through the Traffic Inspection Devices
To configure the paths through the traffic inspection devices:

1. To begin the configuration of a path, enter the following command at
slb server server-name ipaddr
For the ipaddr, enter the IP address of the ACOS interface on the other
side of the traffic inspection device.

2. To add a TCP port, enter the following command at configuration level
for the path:
port portnum tcp
For the portnum, specify the HTTP port number you plan to add to the
wildcard VIP on the inside ACOS device.
3. To disable the Layer 4 health check, enter the following command at the
configuration level for the port:
no health-check
Note: Do not use the fire-wall command, because this command is not applica-
ble to SSL Insight.
4. To create a service group, enter the following command at the global

slb service-group group-name {tcp | udp}
This command changes the CLI to the configuration level for the service
group.
5. To add each path, enter the following command at the configuration

level for the service group:
member server-name:portnum
For the server-name, enter the name used for the real server configura-
tion for the path. For the portnum, use the same port number specified in
the server configuration.
Configuring the Wildcard VIPs

Before you configure the wildcard VIP, configure the ACLs for the wildcard
VIPs. For more information about the syntax, see the CLI Reference Guide.
Outbound VIP
To configure an outbound VIP:
1. Enter the following command at the global configuration level of the
CLI:
slb virtual-server name 0.0.0.0 [acl acl-id]
2. To add an HTTPS virtual port to the VIP, enter the following command
at the configuration level for the VIP:
port portnum https
For the portnum, specify the HTTPS port number (typically, 443).

3. To bind the service group of paths through the traffic inspection devices
to the wildcard VIP, enter the following command at the configuration
level for the virtual port:
service-group group-name
4. To bind the client-SSL template to the wildcard VIP, enter the following
command:
template client-ssl template-name
5. To disable the destination NAT, enter the following command:

no-dest-nat port-translation
The port-translation option enables the ACOS device to translate the
destination protocol port in a client HTTPS request before sending the
request to the selected firewall. For SSL Insight, the option is required
because the ACOS device decrypts the client request, and sends the
request to the firewall in the clear as an HTTP request, instead of an
HTTPS request.
Wildcard Ports
To configure wildcard ports:
1. Exit back one level to return to the server configuration level.
2. To add the wildcard ports, enter the following commands:

port 0 {tcp | udp | others}
Use the service-group command to bind the TCP and Others ports to
the TCP service group for the paths through the traffic inspection
devices. Likewise, bind the UDP port to the UDP service group.
3. To disable the destination NAT and port translation, enter the following
command:
no-dest-nat
Inbound VIP
To configure the inbound VIP, enter the following commands:
use-rcv-hop-for-resp
use-default-if-no-server
no-dest-nat

Configuring the Outside ACOS devices

This section shows the CLI syntax to configure SSL Insight on the outside
ACOS devices.
Enabling Promiscuous VIP Mode on Ethernet Interfaces
On each Ethernet interface that is connected to a firewall, enter the follow-

ing command at the configuration level for the interface:
ip allow-promiscuous-vip
Configuring the Paths Through the Traffic Inspection Devices

1. To configure paths through the traffic inspection devices:
To begin configuration of a path, enter the following command at the global

slb server server-name ipaddr
For the ipaddr, enter the IP address of the ACOS interface on the other
side of the traffic inspection device.
2. To add wildcard TCP and UDP ports, enter the following commands at
the configuration level for the path:
port 0 tcp
port 0 udp
3. To disable the Layer 4 health check for each port, enter the following
command:
no health-check
Note: Do not use the fire-wall command, because this command is not applica-
ble to SSL Insight.
4. To create a service group, enter the following command at the global

slb service-group group-name {tcp | udp}
5. To add each path, enter the following commands at the configuration

level for the service group:
member server-name:0

Configuring the Service Groups for the Gateway Router
To configure the service groups for the gateway router:

1. To configure a service group for the HTTPS port and service groups that
use wildcard ports for TCP and UDP, enter the following commands:
slb server gw-name ipaddr
port 443 tcp
port 0 tcp
port 0 udp
2. To disable the Layer 4 health check, enter the following command on

each port:
no health-check
Complete the following tasks:

• Add the member for port 443 to a TCP service group.
• Add TCP port 0 to another TCP service group.
• Add UDP port 0 to a UDP service group.
Configuring the Server-SSL Template
To configure the server SSL-template:

1. To begin configuration of the server-SSL template, enter the following
command at the global configuration level of the CLI:
slb template server-ssl template-name
2. To to enable SSL Froward Proxy support, enter the following command

at the configuration level for the template:
forward-proxy-enable
Configuring the Wildcard VIPs
To configure wildcard VIPs:

1. To configure the outbound VIP, enter the following command at the

2. To add an HTTPS virtual port to the VIP, enter the following command
at the configuration level for the VIP:
port portnum http
For the portnum, specify the HTTP port number (8080 in the sample
deployment).
3. To binds the service group for the SSL port on the gateway router to the
wildcard VIP, enter the following command at the configuration level
for the virtual port:
4. To bind the server-SSL template to the wildcard VIP, enter the following
commands:
template server-ssl template-name
5. To disables destination NAT and enables port translation, enter the fol-
lowing command:
no-dest-nat port-translation
Wildcard Ports
To configure wildcard ports:
1. Exit back one level to return to the server configuration level.
2. To add the wildcard ports, enter the following commands:

Enter the service-group command to bind the TCP and Others ports to
the TCP service group for the gateway router. Likewise, bind the UDP
port to the UDP service group for the gateway router.
3. Enter the following commands:

use-rcv-hop-for-resp
no-dest-nat
Inbound VIP
To configure the inbound VIP, enter the following commands:
no-dest-nat
Use this command to bind the port to the service group for the paths through
the traffic inspection devices.

SSL Insight - Configuration Example
Displaying Certificate Hash Entries

To display hash entries for server certificates that are created by the ACOS
device for SSL Insight, enter the following command:
show slb ssl-forward-proxy-cert
virtual-server-name portnum {all | ipaddr}
Configuration Example
The following sections show how to implement the SSL Insight deployment
in Figure 29 by using the CLI.
FIGURE 29 SSL Insight Topology Example

Note: For an example of configuring by using the GUI, see the
SSL Insight Deployment Guide.
CLI Example—Inside ACOS devices

The commands shown in this section configure the inside ACOS devices in
Figure 29.
Inside the Primary ACOS Device
The following commands access the configuration level of the CLI and
change the hostname:
ACOS>enable
Password:********
ACOS#config
ACOS(config)#hostname ACOS-Inside-Primary
Layer 2/3 Configuration

The following commands configure the VLANs:
ACOS-Inside-Primary(config)#vlan 10
ACOS-Inside-Primary(config-vlan:10)#untagged ethernet 20
ACOS-Inside-Primary(config-vlan:10)#router-interface ve 10
ACOS-Inside-Primary(config-vlan:10)#vlan 15

The following commands assign IP addresses to the VEs (router interfaces)
that are configured on the VLANs. Since VE 10 is the VE that is connected
to the inside clients, promiscuous VIP mode is enabled on this VE. The
other VEs do not use promiscuous VIP mode in this deployment.
ACOS-Inside-Primary(config-vlan:99)#interface ve 10
ACOS-Inside-Primary(config-if:ve10)#ip address 10.1.1.2 255.255.255.0
ACOS-Inside-Primary(config-if:ve10)#ip allow-promiscuous-vip
ACOS-Inside-Primary(config-if:ve10)#interface ve 15
ACOS-Inside-Primary(config-if:ve99)#exit
The following commands configure static routes to the network on the side
of the outside ACOS devices that connects to the Internet. The next-hop IP
address of each route is the floating IP address of a VRID on the outside
ACOS devices. Specifically, these are the floating IP addresses that belong
to the VRIDs for the VLANs that contain the traffic inspection devices.
ACOS-Inside-Primary(config)#ip route 20.1.1.0 /24 10.1.240.11
ACOS-Inside-Primary(config)#ip route 20.1.1.0 /24 10.1.250.11
SSL Configuration
The following commands import the root CA-signed certificate that is used
by the content servers and the certificate’s private key:
ACOS-Inside-Primary(config)#slb ssl-load certificate ca.cert.pem scp:
User name []?admin
Password []?*********
File name [/]?ca-cert.pem
ACOS-Inside-Primary(config)#slb ssl-load private-key ca.key.pem scp:
User name []?admin
Password []?*********
File name [/]?ca-certkey.pem
The following commands configure the client-SSL template:

ACOS-Inside-Primary(config)#slb template client-ssl SSLIntercept_ClientSide
ACOS-Inside-Primary(config-client SSL)#forward-proxy-ca-cert ca.cert
ACOS-Inside-Primary(config-client SSL)#forward-proxy-ca-key ca.key

Path Configuration
The following commands configure the paths through the traffic inspection
devices:
ACOS-Inside-Primary(config-client SSL)#slb server PSG1_Path 10.1.240.11
ACOS-Inside-Primary(config-real server)#port 0 tcp
ACOS-Inside-Primary(config-real server-node port)#no health-check
ACOS-Inside-Primary(config-real server-node port)#port 0 tcp
ACOS-Inside-Primary(config-real server-node port)#slb server PSG2_Path
10.1.250.11
ACOS-Inside-Primary(config-real server)#port 0 tcp
ACOS-Inside-Primary(config-real server-node port)#slb service-group LB_-
Paths_UDP udp
ACOS-Inside-Primary(config-slb svc group)#member PSG1_Path:0
ACOS-Inside-Primary(config-slb svc group)#slb service-group LB_Paths_TCP tcp
ACOS-Inside-Primary(config-slb svc group)#slb service-group SSL tcp
ACOS-Inside-Primary(config-slb svc group)#member PSG_Path:8080
ACOS-Inside-Primary(config-slb svc group)#exit
The following commands configure the wildcard VIP to intercept all out-
bound traffic that originates from the inside network:
ACOS-Inside-Primary(config)#access-list 100 permit ip any any vlan 10
ACOS-Inside-Primary(config)#slb virtual-server outbound_wildcard 0.0.0.0 acl
100
ACOS-Inside-Primary(config-slb vserver)#port 0 tcp
ACOS-Inside-Primary(config-slb vserver-vport)#name Inside1_in_to_out
ACOS-Inside-Primary(config-slb vserver-vport)#service-group LB_Paths_TCP
ACOS-Inside-Primary(config-slb vserver-vport)#no-dest-nat
ACOS-Inside-Primary(config-slb vserver-vport)#port 0 udp
ACOS-Inside-Primary(config-slb vserver-vport)#name Inside1_in_to_out_UDP

ACOS-Inside-Primary(config-slb vserver-vport)#service-group LB_Paths_UDP
ACOS-Inside-Primary(config-slb vserver-vport)#no-dest-nat
ACOS-Inside-Primary(config-slb vserver-vport)#port 443 https
ACOS-Inside-Primary(config-slb vserver-vport)#name Inside1_in_to_out_443
ACOS-Inside-Primary(config-slb vserver-vport)#service-group SSL
ACOS-Inside-Primary(config-slb vserver-vport)#template client-ssl SSLInter-
cept_ClientSide
ACOS-Inside-Primary(config-slb vserver-vport)#no-dest-nat port-translation
ACOS-Inside-Primary(config-slb vserver-vport)#exit
ACOS-Inside-Primary(config-slb vserver)#exit
ACOS-Inside-Primary(config)#
VRRP-A Configuration
The following commands specify the VRRP-A device ID for this ACOS
device, add the ACOS device to VRRP-A set 1, and enable VRRP-A on the
device:
ACOS-Inside-Primary(config)#vrrp-a device-id 1
ACOS-Inside-Primary(config)#vrrp-a set-id 1
ACOS-Inside-Primary(config)#vrrp-a enable
The following commands configure the VRID for the inside ACOS devices’
interface with the inside client network:
ACOS-Inside-Primary(config)#vrrp-a vrid default
ACOS-Inside-Primary(config-vrid-default)#floating-ip 10.1.1.1
ACOS-Inside-Primary(config-vrid-default)#priority 200
ACOS-Inside-Primary(config-vrid-default)#tracking-options
ACOS-Inside-Primary(config-vrid-tracking)#interface ethernet 1 priority-cost
60
60
60

The following commands configure the VRID for the VLAN that contains
the first traffic inspection device (PSG1):
ACOS-Inside-Primary(config-vrid-tracking)#vrrp-a vrid 15
ACOS-Inside-Primary(config-vrid)#floating-ip 10.1.240.1
ACOS-Inside-Primary(config-vrid)#priority 200
ACOS-Inside-Primary(config-vrid)#tracking-options
60
60
60
the second traffic inspection device (PSG2):
ACOS-Inside-Primary(config-vrid-tracking)#vrrp-a vrid 16
ACOS-Inside-Primary(config-vrid)#floating-ip 10.1.250.1
ACOS-Inside-Primary(config-vrid)#priority 200
ACOS-Inside-Primary(config-vrid)#tracking-options
60
60
60
ACOS-Inside-Primary(config-vrid-tracking)#exit
ACOS-Inside-Primary(config-vrid)#exit
The following command configures the VRRP-S interface that connects this
ACOS device to its VRRP-A peer:
ACOS-Inside-Primary(config)#vrrp-a interface ethernet 18 vlan 99
Inside Secondary ACOS device
The configuration on the inside secondary ACOS device is the same as the
configuration on the inside primary ACOS device, except for the following
device-specific parameters:
• Hostname – The hostname is configured with a unique value to make it
simpler to identify the device.
• VRRP-A device ID – This value must be unique in the set of ACOS
devices that are backed up by VRRP-A (the VRRP-A set).

• Interface IP addresses – The VLAN IDs are the same on both ACOS
devices, but the router interface on each VLAN has a unique IP address.
The IP address is unique on each ACOS device.
• Priority values of the VRIDs – To specify the ACOS device’s default
VRRP-A role (active or backup), each VRID on this ACOS device is
configured with a lower priority value than the same VRID on the inside
primary ACOS device.
Hostname Configuration
ACOS(config)#hostname ACOS-Inside-Secondary

ACOS-Inside-Secondary(config)#vlan 10
ACOS-Inside-Secondary(config-vlan:10)#untagged ethernet 20
ACOS-Inside-Secondary(config-vlan:10)#router-interface ve 10
ACOS-Inside-Secondary(config-vlan:10)#vlan 15
ACOS-Inside-Secondary(config-vlan:99)#interface ve 10
ACOS-Inside-Secondary(config-if:ve10)#ip address 10.1.1.3 255.255.255.0
ACOS-Inside-Secondary(config-if:ve10)#ip allow-promiscuous-vip
ACOS-Inside-Secondary(config-if:ve10)#interface ve 15
ACOS-Inside-Secondary(config-if:ve99)#exit
ACOS-Inside-Secondary(config)#ip route 20.1.1.0 /24 10.1.240.11
ACOS-Inside-Secondary(config)#ip route 20.1.1.0 /24 10.1.250.11

SSL Configuration
ACOS-Inside-Primary(config)#slb ssl-load certificate ca.cert.pem scp:
User name []?admin
Password []?*********
File name [/]?ca-cert.pem
ACOS-Inside-Primary(config)#slb ssl-load private-key ca.key.pem scp:
User name []?admin
Password []?*********
File name [/]?ca-certkey.pem
ACOS-Inside-Secondary(config)#slb template client-ssl SSLIntercept_ClientSide
ACOS-Inside-Secondary(config-client SSL template)#forward-proxy-enable
ACOS-Inside-Secondary(config-client SSL template)#forward-proxy-ca-cert
ca.cert
ACOS-Inside-Secondary(config-client SSL template)#forward-proxy-ca-key ca.key
Path Configuration
ACOS-Inside-Secondary(config-client SSL template)#slb server PSG1_Path
10.1.240.11
ACOS-Inside-Secondary(config-real server)#port 0 tcp
ACOS-Inside-Secondary(config-real server-node port)#no health-check
ACOS-Inside-Secondary(config-real server-node port)#port 0 tcp
ACOS-Inside-Secondary(config-real server-node port)#slb server PSG2_Path
10.1.250.11
ACOS-Inside-Secondary(config-real server)#port 0 tcp
ACOS-Inside-Secondary(config-real server-node port)#slb service-group LB_-
Paths_UDP udp
ACOS-Inside-Secondary(config-slb svc group)#member PSG1_Path:0
ACOS-Inside-Secondary(config-slb svc group)#slb service-group LB_Paths_TCP tcp
ACOS-Inside-Secondary(config-slb svc group)#slb service-group SSL tcp

ACOS-Inside-Secondary(config-slb svc group)#exit
ACOS-Inside-Secondary(config)#access-list 100 permit ip any any vlan 10
ACOS-Inside-Secondary(config)#slb virtual-server outbound_wildcard 0.0.0.0 acl
100
ACOS-Inside-Secondary(config-slb vserver)#port 0 tcp
ACOS-Inside-Secondary(config-slb vserver-vport)#name Inside1_in_to_out
ACOS-Inside-Secondary(config-slb vserver-vport)#service-group LB_Paths_TCP
ACOS-Inside-Secondary(config-slb vserver-vport)#no-dest-nat
ACOS-Inside-Secondary(config-slb vserver-vport)#port 0 udp
ACOS-Inside-Secondary(config-slb vserver-vport)#name Inside1_in_to_out_UDP
ACOS-Inside-Secondary(config-slb vserver-vport)#service-group LB_Paths_UDP
ACOS-Inside-Secondary(config-slb vserver-vport)#no-dest-nat
ACOS-Inside-Secondary(config-slb vserver-vport)#port 443 https
ACOS-Inside-Secondary(config-slb vserver-vport)#name Inside1_in_to_out_443
ACOS-Inside-Secondary(config-slb vserver-vport)#service-group SSL
ACOS-Inside-Secondary(config-slb vserver-vport)#template client-ssl SSLInter-
cept_ClientSide
ACOS-Inside-Secondary(config-slb vserver-vport)#no-dest-nat port-translation
ACOS-Inside-Secondary(config)#vrrp-a device-id 2
ACOS-Inside-Secondary(config)#vrrp-a set-id 1
ACOS-Inside-Secondary(config)#vrrp-a enable
ACOS-Inside-Secondary(config)#vrrp-a vrid default
ACOS-Inside-Secondary(config-vrid-default)#floating-ip 10.1.1.1
ACOS-Inside-Secondary(config-vrid-default)#priority 180
ACOS-Inside-Secondary(config-vrid-default)#tracking-options
ACOS-Inside-Secondary(config-vrid-tracking)#interface ethernet 1 priority-cost
60
60
ACOS-Inside-Secondary(config-vrid-tracking)#interface ethernet 20 priority-
cost 60
ACOS-Inside-Secondary(config-vrid-tracking)#vrrp-a vrid 15
ACOS-Inside-Secondary(config-vrid)#floating-ip 10.1.240.1
ACOS-Inside-Secondary(config-vrid)#priority 180
ACOS-Inside-Secondary(config-vrid)#tracking-options
60

60
cost 60
ACOS-Inside-Secondary(config-vrid-tracking)#vrrp-a vrid 16
ACOS-Inside-Secondary(config-vrid)#floating-ip 10.1.250.1
ACOS-Inside-Secondary(config-vrid)#priority 180
ACOS-Inside-Secondary(config-vrid)#tracking-options
60
60
cost 60
ACOS-Inside-Secondary(config)#vrrp-a interface ethernet 18 vlan 99
Outside Primary ACOS device

The following commands access the configuration level of the CLI, and
change the hostname:
ACOS>enable
Password:********
ACOS#config
ACOS(config)#hostname ACOS-Outside-Primary

ACOS-Outside-Primary(config)#vlan 15
ACOS-Outside-Primary(config-vlan:15)#untagged ethernet 1
ACOS-Outside-Primary(config-vlan:15)#router-interface ve 15
ACOS-Outside-Primary(config-vlan:15)#vlan 16

The following commands assign IP addresses to the VEs (router interfaces)
configured on the VLANs. Promiscuous VIP mode is enabled on the VEs
that are in the VLANs that contain the traffic inspection devices. The other
VEs do not use promiscuous VIP mode in this deployment.
ACOS-Outside-Primary(config-vlan:99)#interface ve 15
ACOS-Outside-Primary(config-if:ve15)#ip address 10.1.240.12 255.255.255.0
ACOS-Outside-Primary(config-if:ve15)#ip allow-promiscuous-vip
ACOS-Outside-Primary(config-if:ve15)#interface ve 16
ACOS-Outside-Primary(config-if:ve16)#ip allow-promiscuous-vip
ACOS-Outside-Primary(config-if:ve99)#exit
The following commands configure static routes to the network on the cli-
ent side of the inside ACOS devices. The next-hop IP address of each route
is the floating IP address of a VRID on the inside ACOS devices. Specifi-
cally, these are the floating IP addresses that belong to the VRIDs for the
VLANs that contain the traffic inspection devices.
ACOS-Outside-Primary(config)#ip route 10.1.1.0 /24 10.1.240.1
ACOS-Outside-Primary(config)#ip route 10.1.1.0 /24 10.1.250.1
SSL Configuration
The following commands configure the server-SSL template:
ACOS-Outside-Primary(config)#slb template server-ssl SSLIntercept_ServerSide
ACOS-Outside-Primary(config-server SSL template)#forward-proxy-enable
Path Configuration
The following commands configure the paths through the traffic inspection
devices to the router on the inside client network:
ACOS-Outside-Primary(config-client SSL template)#slb server server-gateway
20.1.1.253
ACOS-Outside-Primary(config-real server)#port 0 tcp
ACOS-Outside-Primary(config-real server-node port)#no health-check
ACOS-Outside-Primary(config-real server-node port)#port 0 udp
ACOS-Outside-Primary(config-real server-node port)#port 443 tcp

ACOS-Outside-Primary(config-real server-node port)#slb service-group SG_TCP
tcp
ACOS-Outside-Primary(config-slb svc group)#member server-gateway:0
ACOS-Outside-Primary(config-real server-node port)#slb service-group SG_UDP
udp
ACOS-Outside-Primary(config-real server-node port)#slb service-group SG_443
tcp
ACOS-Outside-Primary(config-slb svc group)#exit
The following commands configure the wildcard VIP to intercept all out-
bound traffic that originates from the inside network:
ACOS-Outside-Primary(config)#access-list 100 permit ip any any vlan 15
ACOS-Outside-Primary(config)#access-list 100 permit ip any any vlan 16
ACOS-Outside-Primary(config)#slb virtual-server outside_in_to_out 0.0.0.0 acl
100
ACOS-Outside-Primary(config-slb vserver)#port 0 tcp
ACOS-Outside-Primary(config-slb vserver-vport)#service-group SG_TCP
ACOS-Outside-Primary(config-slb vserver-vport)#use-rcv-hop-for-resp
ACOS-Outside-Primary(config-slb vserver-vport)#no-dest-nat
ACOS-Outside-Primary(config-slb vserver-vport)#port 0 udp
ACOS-Outside-Primary(config-slb vserver-vport)#service-group SG_UDP
ACOS-Outside-Primary(config-slb vserver-vport)#no-dest-nat
ACOS-Outside-Primary(config-slb vserver-vport)#port 8080 http
ACOS-Outside-Primary(config-slb vserver-vport)#name ReverseProxy_Wildcard
ACOS-Outside-Primary(config-slb vserver-vport)#service-group SG_443
ACOS-Outside-Primary(config-slb vserver-vport)#template server-ssl outside-
intercept
ACOS-Outside-Primary(config-slb vserver-vport)#no-dest-nat port-translation
The following commands specify the VRRP-A device ID for this ACOS
device, add the ACOS device to VRRP-A set 2, and enable VRRP-A on the
device:
ACOS-Outside-Primary(config)#vrrp-a device-id 3
ACOS-Outside-Primary(config)#vrrp-a set-id 2
ACOS-Outside-Primary(config)#vrrp-a enable

The following commands configure the VRID for the interface with the
inside client network:
ACOS-Outside-Primary(config)#vrrp-a vrid default
ACOS-Outside-Primary(config-vrid-default)#floating-ip 20.1.1.1
ACOS-Outside-Primary(config-vrid-default)#priority 200
ACOS-Outside-Primary(config-vrid-default)#tracking-options
ACOS-Outside-Primary(config-vrid-tracking)#interface ethernet 1 priority-cost
60
60
60
the first traffic inspection device (PSG1):
ACOS-Outside-Primary(config-vrid-tracking)#vrrp-a vrid 5
ACOS-Outside-Primary(config-vrid)#floating-ip 10.1.240.11
ACOS-Outside-Primary(config-vrid)#priority 200
ACOS-Outside-Primary(config-vrid)#tracking-options
60
60
60
the second traffic inspection device (PSG2):
ACOS-Outside-Primary(config-vrid-tracking)#vrrp-a vrid 6
ACOS-Outside-Primary(config-vrid)#floating-ip 10.1.250.11
ACOS-Outside-Primary(config-vrid)#priority 200
ACOS-Outside-Primary(config-vrid)#tracking-options
60
60
60
The following command configures the VRRP-A interface that connects

this ACOS device to its VRRP-A peer:

Outside Secondary ACOS device
The configuration on the outside secondary ACOS device is the same as the
configuration on the inside outside ACOS device, with the exception of the
following device-specific parameters:
• Hostname
• VRRP-A device ID
• Interface IP addresses
• Priority values of the VRIDs
Hostname Configuration
ACOS(config)#hostname ACOS-Outside-Secondary

ACOS-Outside-Secondary(config)#vlan 15
ACOS-Outside-Secondary(config-vlan:15)#untagged ethernet 1
ACOS-Outside-Secondary(config-vlan:15)#router-interface ve 15
ACOS-Outside-Secondary(config-vlan:15)#vlan 16
ACOS-Outside-Secondary(config-vlan:99)#interface ve 15
ACOS-Outside-Secondary(config-if:ve15)#ip address 10.1.240.13 255.255.255.0
ACOS-Outside-Secondary(config-if:ve15)#ip allow-promiscuous-vip
ACOS-Outside-Secondary(config-if:ve15)#interface ve 16
ACOS-Outside-Secondary(config-if:ve16)#ip allow-promiscuous-vip
ACOS-Outside-Secondary(config-if:ve99)#exit

ACOS-Outside-Secondary(config)#ip route 10.1.1.0 /24 10.1.240.1
ACOS-Outside-Secondary(config)#ip route 10.1.1.0 /24 10.1.250.1
SSL Configuration
ACOS-Outside-Secondary(config)#slb template server-ssl SSLIntercept_ServerSide
ACOS-Outside-Secondary(config-server SSL template)#forward-proxy-enable
Path Configuration
ACOS-Outside-Secondary(config-client SSL template)#slb server server-gateway
20.1.1.253
ACOS-Outside-Secondary(config-real server)#port 0 tcp
ACOS-Outside-Secondary(config-real server-node port)#no health-check
ACOS-Outside-Secondary(config-real server-node port)#port 0 udp
ACOS-Outside-Secondary(config-real server-node port)#port 443 tcp
ACOS-Outside-Secondary(config-real server-node port)#slb service-group SG_TCP
tcp
ACOS-Outside-Secondary(config-slb svc group)#member server-gateway:0
ACOS-Outside-Secondary(config-real server-node port)#slb service-group SG_UDP
UDP
ACOS-Outside-Secondary(config-real server-node port)#slb service-group SG_443
tcp
ACOS-Outside-Secondary(config-slb svc group)#exit
ACOS-Outside-Secondary(config)#access-list 100 permit ip any any vlan 15
ACOS-Outside-Secondary(config)#access-list 100 permit ip any any vlan 16
ACOS-Outside-Secondary(config)#slb virtual-server outside_in_to_out 0.0.0.0
acl 100
ACOS-Outside-Secondary(config-slb vserver)#port 0 tcp
ACOS-Outside-Secondary(config-slb vserver-vport)#service-group SG_TCP
ACOS-Outside-Secondary(config-slb vserver-vport)#use-rcv-hop-for-resp
ACOS-Outside-Secondary(config-slb vserver-vport)#no-dest-nat
ACOS-Outside-Secondary(config-slb vserver-vport)#port 0 udp
ACOS-Outside-Secondary(config-slb vserver-vport)#service-group SG_UDP
ACOS-Outside-Secondary(config-slb vserver-vport)#no-dest-nat
ACOS-Outside-Secondary(config-slb vserver-vport)#port 8080 http
ACOS-Outside-Secondary(config-slb vserver-vport)#name ReverseProxy_Wildcard

ACOS-Outside-Secondary(config-slb vserver-vport)#service-group SG_443
ACOS-Outside-Secondary(config-slb vserver-vport)#template server-ssl outside-
intercept
ACOS-Outside-Secondary(config-slb vserver-vport)#no-dest-nat port-translation
ACOS-Outside-Secondary(config)#vrrp-a device-id 4
ACOS-Outside-Secondary(config)#vrrp-a set-id 2
ACOS-Outside-Secondary(config)#vrrp-a enable
ACOS-Outside-Secondary(config)#vrrp-a vrid default
ACOS-Outside-Secondary(config-vrid-default)#floating-ip 20.1.1.1
ACOS-Outside-Secondary(config-vrid-default)#priority 180
ACOS-Outside-Secondary(config-vrid-default)#tracking-options
ACOS-Outside-Secondary(config-vrid-tracking)#interface ethernet 1 priority-
cost 60
cost 60
cost 60
ACOS-Outside-Secondary(config-vrid-tracking)#vrrp-a vrid 5
ACOS-Outside-Secondary(config-vrid)#floating-ip 10.1.240.11
ACOS-Outside-Secondary(config-vrid)#priority 180
ACOS-Outside-Secondary(config-vrid)#tracking-options
cost 60
cost 60
cost 60
ACOS-Outside-Secondary(config-vrid-tracking)#vrrp-a vrid 6
ACOS-Outside-Secondary(config-vrid)#floating-ip 10.1.250.11
ACOS-Outside-Secondary(config-vrid)#priority 180
ACOS-Outside-Secondary(config-vrid)#tracking-options
cost 60
cost 60
cost 60

SSL Insight - SSL Insight Bypass
SSL Insight Bypass

You can bypass SSL Insight processing for specific traffic, based on Server
Name Indication (SNI). The feature is useful for known, trusted sites for
which traffic does not need to be decrypted and inspected. For example, you
can use this feature to bypass SSL Insight processing for secured bank traf-
fic.
Configuration
To configure SSL Insight bypass, add a set of bypass rules to the client-SSL
template that is bound to the HTTPS virtual port. Each rule contains a match
option and all or part of the SNI string on which to match.
You can configure the rules in one of the following ways:

• Enter the rules directly in the CLI or GUI.
This method is useful when you have a small number of entries to add.
• Add the rules to an Aho-Corasick class list.
You can import the class list or configure it in the CLI or GUI. (This
type of class list is new in ACOS 2.7.1, and currently applies only to
SSL Insight.)
With these methods, you can configure rules that use the following match
options.
Match Options
Here are the list of match options:
• Equals – matches only if the SNI value completely matches the speci-
fied string.
• Starts-with – matches only if the SNI value starts with the specified
string.
• Contains – matches if the specified string appears anywhere within the
SNI value.
• Ends-with – matches only if the SNI value ends with the specified
string.
The match options are always applied in the order shown, regardless of the
order in which the rules appear in the configuration.

If a template has more than one rule with the same match option and an SNI
value matches on more than one of the rules, the most-specific match is
always used.
Case Sensitivity
By default, matching is case sensitive. For example, the following rule
matches on SNI strings that contain “aa” but not on strings that contain
“AA”:
forward-proxy-bypass contains aa
Optionally, you can enable or disable case-sensitive matching. In this case,

the rule shown above matches on SNI strings that contain any of the follow-
ing:
• “aa”
• “AA”
• “aA”
• “Aa”
You can disable case sensitivity on a template-wide basis. The setting

applies to all match rules within the template.
Note: The current release supports case-insensitivity only for class-list entries
that are created in the CLI.
USING THE GUI

Entering Match Rules Directly into the GUI
In the Bypass section of the configuration page for the client-SSL template,
enter the rules in the Bypass section.
To enter a match rule:

1. Click Config Mode > SLB > Template > SSL > Client SSL.
2. Select the match type.
3. Enter the match string.
4. Click Add.
5. Repeat for each rule.

Adding Match Rules Using a Class List
You can import the class list or configure it in the GUI.
Importing the Class List

To import the class list:
2. Click Import.
For more information, see the online help or GUI Reference Guide.
Configuring the Class List in the GUI

To configure the class list in the GUI:
2. Click Add.
3. Enter a list name.
4. Select the save location:

• File – Saves the list to a file that you can export.
• Config – Saves the entries in the configuration file.
5. In Type, select Explicit.
6. Select IP Address.
7. Select the IPv4 or IPv6.
Note: A class list can contain entries for only one IP version.
8. Enter the IP address entries.

For more detailed steps, see the online help or GUI Reference. The steps
are the same for IP addresses in other list types.
9. Click OK.
Applying the Class List to the Client-SSL Template

To apply the class list to the client-SSL template that is used for SSL
Insight, on the configuration page for the template, select a list from the
Class List drop-down list.

Disabling Case Sensitivity
In the Bypass section of the configuration page for the client-SSL template,
select Enabled next to Case Insensitive.
USING THE CLI
Entering Match Rules in the CLI

To configure match rules for SSL Insight bypass, use the following com-
mands at the configuration level for the client-SSL template:
[no] forward-proxy-bypass equals sni-string
[no] forward-proxy-bypass starts-with sni-string
[no] forward-proxy-bypass contains sni-string
[no] forward-proxy-bypass ends-with sni-string
Adding Match Rules by Using a Class List

To configure match rules in a class list, and apply the list to the client-SSL
template, enter the following commands:
Adding the Class List

You can import the class list or configure it in the CLI:
1. To import the list, enter the following command:
import class-list
For complete syntax information, see the CLI Reference Guide.
2. To configure the class list in the CLI, enter the following commands:
[no] class-list list-name ac [file filename]
Enter this command at the global configuration level to create the list
and access the configuration level for it. The file option saves the list as
a file that you can export. Without this option, the class-list entries are
saved in the configuration file instead.
Note: The ac option is required. This specifies that the list type is Aho-Corasick.

3. The following commands configure the rule entries.
[no] equals sni-string
[no] starts-with sni-string
[no] contains sni-string
[no] ends-with sni-string
Applying the Class List to the Client-SSL Template

To apply the class list to the client-SSL template used for SSL Insight, enter
the following commands:
1. To access the configuration level for the client SSL template, enter the
following commands:
slb template client-ssl template-name
2. To bind the class list to the template, enter the following command:
forward-proxy-bypass class-list list-name
This command binds the class list to the template.
Disabling Case Sensitivity

To disable case sensitivity for rule matching, enter the following command
at the configuration level for the template:
[no] forward-proxy-bypass case-insensitive

Location-based VIP Access - Overview
Location-based VIP Access
Overview
You can control access to a VIP that is based on the geo-location of the cli-
ent. You also can configure ACOS to perform one of the following actions
for client traffic, depending on the location of the client:
• If the traffic was configured using a black/white list, send the traffic to a
specific service group
ACOS determines a client’s location by looking up the client’s subnet in the

geo-location database that is used by Global Server Load Balancing
(GSLB).
Note: This feature requires that you 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. For more information about
loading the database, see “Loading the IANA Geo-location Database” on
page 216.
Configuration Using a Class List

This section show how to configure geo-location-based VIP access by using
a class list.
Note: Geo-location-based VIP access works only if the class list is imported as a
file. The CLI does not support configuration of class-list entries for this
application.

Location-based VIP Access - Configuration Using a Class List
Example
The following class list maps client geo-locations to limit IDs (LIDs), which
specify the maximum number of concurrent connections that are allowed
for clients in the geo-locations:
L default 1
L arin 2
L afrinic 3
L apnic 4
L lacnic 5
L ripe 6
The following commands import the class list to the ACOS device, config-
ure a policy template, and bind the template to a virtual port. The connec-
tion limits that are specified in the policy template apply to clients that send
requests to the virtual port.
This example assumes the default geo-location database (IANA) is already

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

Location-based VIP Access - Configuration by Using a Black/White List
The following command verifies operation of the policy:
ACOS#show slb geo-location statistics
M = Matched or Level, ID = Group ID

Conn = Connection number, Last = Last Matched IP
v = Exact Match, x = Fail
Virtual Port: vip1/80, c-share
--------------------------------------------------------------------------------
Max Depth: 1
Success: 6
Geo-location M ID Permit Deny Conn Last

arin v 2 5 10 2 192.168.217.13
Total: 1
TH3030B-Active#
Configuration by Using a Black/White List

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 by entering the list in
the GUI. If you configure the list by using a text editor, import the list to
the ACOS device.
2. Configure an SLB policy (PBSLB) template.

In the template, specify the black/white list name and the actions to be
performed for the group IDs in the list.
3. Verify whether the geo-location database has been loaded.

For more information about loading the database, see “Loading the
IANA Geo-location Database” on page 216.
4. Apply the policy template to the virtual port for which you want to con-
trol access.

Configuring the Black/White List

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

• The L indicates that the client’s location is determined by using informa-
tion in the geo-location database.
• The geo-location is the string in the geo-location database that is
mapped to the client’s IP address, for example, US, US.CA, or
US.CA.SanJose.
• The group-id is a number between 1 to 31 that identifies a group of cli-
ents (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.
• The #conn-limit specifies the maximum number of concurrent connec-
tions 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 spec-
ify a connection limit.
The following text is a simple example of a black/white list:

Modify bw-list to
L default 1
L arin 2
L afrinic 3
L apnic 4
L lacnic 5
L ripe 6

USING THE GUI
Configuring or Importing a Black/White List

To configure or import a black/white list:
1. Click Config Mode > SLB > Black-White List.
2. Click Add and complete one of the following tasks:

To import the list:
a. Verify that Remote is selected.
b. 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 in the GUI:

a. Select Local.
b. In Definition, type the list.
3. Click OK.
Configuring a PBSLB Template

To configure a PBSLB template:
2. Click Add.
3. Enter a name for the template.
4. In the Black-White List drop-down list, select a black/white list.
5. In the Group ID drop-down list, select a group ID.
6. In the Action drop-down list, select an action:

• Drop – Drops new connections until the number of concurrent con-
nections 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 con-
nections on the virtual port falls below the connection limit.

• service-group-name – Lists the service groups that are configured
on the ACOS device.
• create – Displays the configuration sections to create a new service
group.
7. Optionally, enable logging.

features for PBSLB logging as the features that are used for ACL log-
ging. For more information, see the “Log Rate Limiting” section in the
“Basic Setup” chapter in the System Configuration 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 the Load/Unload section, in File, enter iana.
3. Leave the Template field blank.
4. Click Add.
Note: You can also import a custom geo-location database. For information, see
the A10 Thunder Series and AX 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.
2. Complete one of the following steps:

• 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, complete one of the following steps:
• Select a port and click Edit.
• Click Add to add a new port.
5. In the PBSLB drop-down list, select a policy template.
6. Click OK and then OK again.
USING THE CLI

1. To import a black/white list to the ACOS device, enter the following
command at the global configuration level of the CLI:
bw-list name url [period seconds] [load]
The name can be up to 31 alphanumeric characters long. The url speci-
fies the file transfer protocol, directory path, and filename. The follow-
ing URL format is supported: tftp://host/file
2. To configure a PBSLB template, enter the following commands:

Enter this command at the global configuration level of the CLI. The
command creates the template and changes the CLI to the configuration
for the template, where the following PBSLB-related commands are
available.
[no] bw-list name file-name
This command binds a black/white list to the virtual ports that use this
template.
[no] bw-list id id
service {service-group-name | drop | reset}
[logging [minutes] [fail]]
This command specifies the action to take for clients in the black/white
list:
• id – Group ID in the black/white list.
• service-group-name – Sends clients to the SLB service group asso-
ciated 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.

3. To load a geo-location database, enter the following command at the
[no] gslb geo-location load
{iana | file-name csv-template-name}
4. To apply the policy template to a virtual port, enter the following com-
mand at the configuration level for the virtual port:
Displaying SLB Geo-Location Information

To display SLB geo-location information, enter the following command:
show slb geo-location
[
virtual-server-name |
virtual-port-num |
bad-only |
[depth num]
[id num]
[location string]
[statistics]
]

• The bad-only option displays only invalid or mismatched geo-location
content.
• The depth option specifies how many nodes in the geo-location data
tree to display.
For example, to display only continent and country entries and hide
individual state and city entries, specify depth 2. By default, the full tree
(all nodes) is displayed.
• The id option displays only the geo-locations mapped to the specified
black/white list group ID.
• The location option displays information only for the specified geo-
location; for example “US.CA”.

Location-based VIP Access - Full-Domain Checking
Clearing SLB Geo-Location Statistics
To clear SLB geo-location statistics, enter the following command at the
Privileged EXEC level of the CLI:
clear slb geo-location
[
virtual-server name [...]
virtual-port-num |
location {all | string}
]
CLI Example
The following command imports black/white list geolist to the ACOS
device:
ACOS(config)#import bw-list geolist scp://192.168.1.2/root/geolist
The following commands configure a policy template named geoloc and

add the black/white list to it:
Note: The template is configured to drop traffic from clients in the geo-location
mapped to group 1 in the list.
ACOS(config)#slb template policy geoloc
ACOS(config-policy)#bw-list name geolist
ACOS(config-policy)#bw-list id 1 drop
The following commands apply the policy template to port 80 on virtual

server vip1:
ACOS(config)#slb virtual-server vip1
ACOS(config-slb vserver-vport)#template policy geoloc
ACOS(config-slb vserver-vport)#show slb geo-location
Full-Domain Checking
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 connection is permitted. The permit counter is incre-
mented only for that specific geo-location level.

Table 5 provides an example set of geo-location connection limits and cur-
rent connections.
TABLE 5 Geo-location connection limit example

Current
Geo-location Connection Limit 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.
A connection request from a client at US.CA is allowed. However, a con-
nection request from a client whose location match is US is denied.
After these three clients are permitted or denied, the connection permit and
deny counters are incremented as follows:
• US – Deny counter is incremented by 1.
• US.CA – Permit counter is incremented by 1.
• US.CA.SanJose – Permit counter is incremented by 1.
When full-domain checking is enabled, the ACOS device checks the current
connection count not only for the client’s specific geo-location, but for all
geo-locations higher up in the domain tree. Based on full-domain checking,
all three connection requests from the clients in the example above are
denied because the US domain has reached its connection limit.
The counters for each domain are updated in the following way:
• US – Deny counter is incremented by 1.
• US.CA – Deny counter is incremented by 1.
USING THE GUI
You can configure the geo-location connection limit by clicking Config

Mode > Security > Template > Policy.
USING THE CLI

To enable full-domain checking for geo-location-based connection limiting,
enter the following command at the configuration level for the PBSLB tem-
plate:
geo-location full-domain-tree

Note: You should enable or disable this option before enabling PBSLB. Chang-
ing the state of this option when PBSLB is running can cause the related
statistics counters to be incorrect.
Enabling PBSLB Statistics Counter Sharing

You can enable the sharing of statistics counters for all virtual servers and
virtual ports that use a PBSLB template. The following counters are shared
by the virtual servers and virtual ports that use the template:
• Permit
• Deny
• Connection number
• Connection limit
USING THE GUI

You can configure PBSLB statistics counter sharing by clicking Config
Mode > Security > Template > Policy.
USING THE CLI

To enable the share option, use the following command at the configuration
level for the PBSLB policy template:
geo-location share
Note: You should enable or disable this option before enabling PBSLB. Chang-
ing the state of this option when PBSLB is running can cause the related
statistics counters to be incorrect.



Corporate Headquarters
A10 Networks, Inc.

3 West Plumeria
San Jose, CA 95134
Tel: +1-408-325-8668 (main)

Tel: +1-888-822-7210 (support – toll-free in USA)
Tel: +1-408-325-8676 (support – direct dial)
Fax: +1-408-325-8666
www.a10networks.com
© 2014 A10 Networks Corporation. All rights reserved.
224

A10 2.7.1-GR1 AAM DMG Apr14 2015

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.1-GR1 AAM DMG Apr14 2015

Uploaded by

Copyright:

Available Formats

Application

A10 ThunderTM Series and AX Series

Document No.: D-030-01-00-0060

A10 Networks Inc. Software License and End User Agreement

Application Access Management 17

AAM with LDAP 29

Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015 5 of 224

AAM with RADIUS 39

AAM with OCSP 45

AAM with Kerberos Relay 51

6 of 224 Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015

Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015 7 of 224

ICMP Rate Limiting 131

HTTP Slowloris Prevention 135

Log DDoS Attack Detection Events 137

8 of 224 Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015

DNSSEC Support 145

SSL Insight 167

Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015 9 of 224

Location-based VIP Access 211

10 of 224 Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015

Application Access Management

For more information, see the following chapters:

• “AAM with LDAP” on page 29

• “AAM with RADIUS” on page 39

Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015 11 of 224

• “AAM with Kerberos Relay” on page 51

Online Certificate Status Protocol

Online Certificate Status Protocol (OCSP) is a network component that pro-

OCSP provides an efficient alternative to certificate revocation lists (CRLs),

For more information, see “AAM with OCSP” on page 45.

For more information, see “IP Anomaly Filtering” on page 61.

For more information, see “Policy-based SLB” on page 67.

12 of 224 Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015

For more information, see “SYN Cookies” on page 87.

IP limiting provides a greatly enhanced implementation of the source IP

For more information, see “IP Limiting” on page 105.

ICMP Rate Limiting

For more information, see “ICMP Rate Limiting” on page 131.

Web Application Firewall

For more information, see the Web Application Firewall Guide.

Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015 13 of 224

For more information, see “HTTP Slowloris Prevention” on page 135.

DNS Application Firewall

For more information, see “DNS Application Firewall” on page 139.

For more information, see “DNSSEC Support” on page 145.

SSL Insight (previously known as SSL Intercept) provides high-perfor-

SI decrypts SSL-encrypted client traffic, and sends the decrypted traffic to a

For more information, see “DNS Application Firewall” on page 139.

14 of 224 Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015

• Reset the connection

• Send the traffic to a specific service group, if configured by using a

ACOS determines a client’s location by looking up the client’s subnet in the

For more information, see “Location-based VIP Access” on page 211.

Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015 15 of 224

16 of 224 Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015

Application Access Management

This chapter describes Application Access Management (AAM).

AAM Security Solutions

FIGURE 1 Service Access Management example

In this example, authentication relay, a Logon Portal, AAA health monitor-

Document No.: D-030-01-00-0060 - ACOS 2.7.1-GR1 4/14/2015 17 of 224

3. The client sends the login credentials (username and password) to