5. Web Application Firewall
5. Web Application Firewall
4-GR1-P11
Web Application Firewall Guide
for A10 Thunder® Series
1 September 2022
© 2020 A10 NETWORKS, INC. CONFIDENTIAL AND PROPRIETARY- ALL RIGHTS RESERVED
Information in this document is subject to change without notice.
PATENT PROTECTION
A10 Networks products are protected by patents in the U.S. and elsewhere. The following website is provided to satisfy the virtual pat-
ent marking provisions of various jurisdictions including the virtual patent marking provisions of the America Invents Act. A10 Net-
works' products, including all Thunder Series products, are protected by one or more of U.S. patents and patents pending listed at:
https://www.a10networks.com/company/legal-notices/a10-virtual-patent-marking
TRADEMARKS
A10 Networks trademarks are listed at:
https://www.a10networks.com/company/legal-notices/a10-trademarks
CONFIDENTIALITY
This document contains confidential materials proprietary to A10 Networks, Inc. This document and information and ideas herein may
not be disclosed, copied, reproduced or distributed to anyone outside A10 Networks, Inc. without prior written consent of A10 Net-
works, Inc.
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. Sub-license, rent, or lease the Software.
DISCLAIMER
This document does not create any express or implied warranty about A10 Networks or about its products or services, including but not
limited to fitness for a particular use and non-infringement. A10 Networks has made reasonable efforts to verify that the information
contained herein is accurate, but A10 Networks assumes no responsibility for its use. All information is provided "as-is." The product
specifications and features described in this publication are based on the latest information available; however, specifications are sub-
ject to change without notice, and certain features may not be available upon initial product release. Contact A10 Networks for current
information regarding its products or services. A10 Networks’ products and services are subject to A10 Networks’ standard terms and
conditions.
ENVIRONMENTAL CONSIDERATIONS
Some electronic components may possibly contain dangerous substances. For information on specific component types, please contact
the manufacturer of that component. Always consult local authorities for regulations regarding proper disposal of electronic compo-
nents in your area.
FURTHER INFORMATION
For additional information about A10 products, terms and conditions of delivery, and pricing, contact your nearest A10 Networks loca-
tion, which can be found by visiting www.a10networks.com.
Table of Contents
OVERVIEW ........................................................................................................9
WAF Overview ................................................................................................................................ 9
WAF External Logging ................................................................................................................ 10
Protection Against Common Web Attacks ............................................................................ 10
Buffer Overflow Attacks ...........................................................................................................................10
Cookie Tampering ....................................................................................................................................... 11
Forceful Browsing ...................................................................................................................................... 11
Web Form Security Attacks ...................................................................................................................... 11
WAF Security Models ...................................................................................................................12
Positive Security Model .............................................................................................................................12
Negative Security Model ...........................................................................................................................12
Request Protection......................................................................................................................12
Compare Request URI to White List and Black List ...........................................................................13
White List ...............................................................................................................................................13
Black List ................................................................................................................................................13
URL Check ....................................................................................................................................................14
Scan Request for Threats .........................................................................................................................15
Bot Check ..............................................................................................................................................15
Form Field Consistency Check .........................................................................................................16
Referer Check .......................................................................................................................................16
HTTP Protocol Compliance Check ..................................................................................................16
HTML Cross-Site Scripting (XSS) Check ........................................................................................ 17
Buffer Overflow Check .......................................................................................................................18
HTML SQL Injection Check ................................................................................................................18
Allowed HTTP Methods Check .........................................................................................................18
Maximum Cookies Check ...................................................................................................................19
Maximum Headers Check .................................................................................................................20
Session Checks ...................................................................................................................................20
Password Security ..............................................................................................................................20
Open Redirect Mitigation .................................................................................................................. 22
Normalization Enhancements for URL Options .......................................................................... 25
WAF XML Checks ....................................................................................................................................... 26
XML Format Checks ........................................................................................................................... 27
XML Validation Checks ...................................................................................................................... 27
XML Limit Checks ...............................................................................................................................30
XML Cross-Site Scripting Checks ................................................................................................... 32
XML SQL Injection Checks ................................................................................................................ 33
WAF SOAP Checks .....................................................................................................................................34
SOAP Format Checks .........................................................................................................................34
3
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Contents
4
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Contents
5
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Contents
6
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Contents
7
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Contents
8
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
OVERVIEW
• WAF Overview
• Request Protection
• Response Protection
WAF Overview
The A10 Networks product line provides additional security for your web servers with the Web
Application Firewall (WAF) feature. The WAF filters communication between 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 website content to safeguard against web attacks and protect sensitive
information hosted on web servers.
The WAF protects against the following main threats to web servers:
• Unauthorized access and control of the web server – There are various attacks designed
to grant an attacker access to and control of a web server. If an attack is successful, the
unauthorized user can deface existing web pages, provide SMTP services to send spam, or
launch distributed denial-of-service (DDoS) attacks.
In addition, the attacker can use the compromised server to host content directly, or act as
a proxy for content hosted on another server. This type of attack can enable unauthorized
users to host illegal, online activities using your web server resources.
• Unauthorized retrieval of sensitive information – These attacks are intended to provide
unauthorized retrieval or leakage of sensitive information from your websites or back-end
databases.
9
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF External Logging
The WAF is configured via a WAF template, which includes built-in basic and policy-based
security checks for convenient and quick deployment. Within the WAF template, you can
enforce security checks to immediately provide a foundational level of protection against
common threats.
Websites are further protected from attack through checks that are defined by customizable
WAF policy files. You can configure WAF policy files for advanced countermeasures to common
attacks, such as SQL injection attacks or bots.
A buffer overflow attack occurs when a web server receives excessively long pieces of
information (for example, URLs, headers, or cookies).
If the system does not have the filters enforced to block these requests, a buffer overflow can
trigger the underlying operating system to slow down or crash. This form of attack compromises
a web server and can permit unauthorized users to access sensitive information.
The WAF can prevent buffer overflow attacks by setting an accepted maximum for aspects of
an HTTP request and blocking requests which exceed the configured limit. This includes
normalization of the URL. (For details on URL normalization, see “url-options option – This
command is used to normalize requested URLs.” on page 106.)
10
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Protection Against Common Web Attacks
Cookie Tampering
Cookie tampering occurs when a user sends a modified cookie to a web server in an attempt to
access unauthorized content. To protect against cookie tampering, enable the Cookie
Encryption check within the WAF template.
Forceful Browsing
Forceful browsing occurs when a user bypasses the hyperlinks of a website to access the URLs
of a website directly. This method is normally used to gain access to private pages, but can be
used in conjunction with other attacks to compromise a web server. To protect against forceful
browsing, enable the URL check for your website. (See “URL Check” on page 14.)
A web form security attack uses the form of a web page to issue commands to a website. The
web form may be modified to include hidden fields, HTML, or injected code to compromise the
security of a web server. A web form security attack commonly occurs through the following
methods:
• SQL Injection Attacks (SQLIA) – An SQL Injection Attack uses a web form or other mecha-
nism to send active SQL commands or SQL special characters to the website’s SQL data-
base. An SQL Injection Attack can trigger the back-end SQL database to execute SQL
commands, allowing attackers to retrieve sensitive information from the database. The
WAF includes the SQL Injection Check template option and default “sqlia_defs” policy file
to provide immediate protection from SQL Injection Attacks.
• Cross-Site Scripting (XSS) Attacks – A cross-site scripting (XSS) attack attempts to use
Javascript commands to modify web page content or obtain hidden properties from a
website. XSS can compromise the security of a web server or allow an attacker to retrieve
sensitive information. The WAF includes the XSS Check template option and default
“jscript_defs” policy file to provide immediate protection from XSS attacks.
11
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Security Models
The WAF operates based on both a positive security model and negative security model to
maximize protection.
The WAF supports several operational modes, one of which is Learning Mode. In Learning Mode,
you send known, “trusted” traffic (HTTP/HTTPS requests) to the WAF. The WAF automatically
sets the values for certain checks based on the traffic.
All operational modes support the White List Check. During the White List Check, the WAF
compares the URI of a user request against the URI patterns in the White List policy file. If there
is match, the WAF performs additional checks.
One of the additional checks performed by the WAF is comparison of the traffic to the patterns
in the Black List policy file. If there is a match, the WAF generates a data event log message. If
Active Mode is enabled, the WAF also drops the traffic.
Request Protection
The WAF scans request elements for possible threats or malicious content. Based on the
responsive action that is configured for each security check, the WAF denies the client request
12
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
completely or sanitizes the request of malicious content and forwards the sanitized request to
the web server.
The WAF filters inbound traffic through the following security checks.
The WAF examines incoming user requests against the URI White Lists and Black Lists. These
lists define rules to explicitly allow or deny traffic:
White List
The URI White List defines acceptable destination URIs allowed for incoming requests. The White
List Check compares the URI of an incoming request against the rules contained in the URI
White List policy file. Connection requests are accepted only if the URI matches a rule in the URI
White List. For more information, see “URI White List” on page 122.
Black List
A URI Black List is a WAF policy file that lists exclusion criteria for incoming requests. If the URI
of an incoming request matches a rule in the URI Black List, the request is automatically
blocked.
The URI Black List works in combination with the URI White List to restrict accessible URIs on a
website. If a URI matches acceptance criteria within the URI White List, a connection is blocked
automatically if it meets a rule in the separate URI Black List. For more information, see “URI
Black List” on page 121.
The following diagram displays the processing order for incoming requests:
13
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
In this illustration, the WAF filters 3 HTTP requests. Of these, request #3 does not meet any
criteria in the WAF template’s URI White List and is blocked.
The remaining requests are compared against the WAF template’s URI Black List and blocked if
they match at least one URI Black List rule. Of these, request #2 is denied. Request #1 is the only
request that is processed for additional security checks.
URL Check
In addition to the URI White List and Black List, you can enable the URL Check to restrict users to
a limited set of URL paths on your website. The URL Check allows clients to access a specific set
of acceptable URLs that were added to the URL-check policy file while the WAF is deployed in
Learning Mode.
Once this policy file is generated, you can manually edit the contents before switching the WAF
deployment mode from Learning to Active. At this point, users are prevented from accessing
any URLs that are not listed in this generated policy file.
14
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
If the URL Check is enforced in the WAF template, the accessible web pages must appear as
hyperlinks on your website to appear in the list. This means users can access the pages on your
website that appear as hyperlinks, but they are prevented from accessing private pages through
“forceful browsing”. For more information, see “Forceful Browsing” on page 11.
NOTE: In the example shown in Figure 1 on page 14, the URL Check would
achieve the same degree of security if a hyperlink is only provided
to the page “/site_images.jpg”.
If a client request passes the URI White and Black List Checks, the WAF scans aspects of the
HTTP request (method, version, URI, query string, headers, cookies, and content) for threats. If
the security check discovers malicious content, the request is either denied or sanitized of the
threat and forwarded to the web server. These security checks are described in more detail
below.
Bot Check
The Bot Check option uses the “bot_defs” WAF policy file for search definitions of known bot
agents. If the Bot Check is enabled in the WAF template and a match is found with the
“bot_defs” file, the request is denied automatically.
15
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
You can copy the “bot_defs” file and modify the copy to include or remove bot search terms. For
more information about WAF policy files, see “WAF Policy Files” on page 119.
Referer Check
The Referer Check validates that the referer header in a request contains web form data from
the specified web server, rather than from an outside website. This check helps to protect
against CSRF attacks. If a request fails the Referer Check, the WAF redirects the request to a
safe URL. The safe URL is any URL that you specify during configuration.
When you configure the Referer Check, you specify the domain names from which you want to
allow traffic. When ACOS receives a request addressed to the virtual port that is using the WAF,
the WAF examines the Referer field of the request.
You can select one of the following options for the Referer Check:
• Enable (full checking) – Select the Enable option to enable full checking. To pass the full
check, the request must contain a Referer header field, and the field must contain at least
one of the domain names you specify during configuration.
• Only-if-present checking – Enable this option to check the referer header of a request
only when a referer header is present. Unlike the full checking option, the only-if-present
option ensures that a request does not fail the Referer Check automatically because there
is no referer header in the request.
NOTE: The WAF issues sends a warning message to the logging servers if
a POST request (that is not chunked) has a content length of 0.
16
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
If the WAF discovers a potential cross-site scripting attack, the request is either blocked or
sanitized through the removal of potentially malicious content and forwarded for processing.
For more information about XSS, see “Web Form Security Attacks” on page 11.
NOTE: This check uses the “jscript_defs” WAF policy file for Javascript
attack patterns. If your website uses Javascript-based content
that accesses or modifies content on an outside server, A10 Net-
works recommends modifying the “jscript_defs” file to generate
the appropriate exceptions, so that this check does not block legit-
imate activity.
17
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
• Maximum parameters
• URL length
• Line length
• Query length
NOTE: The HTML SQL Injection Check scans incoming requests for attack
patterns listed in the “sqlia_defs” WAF file. Copy this file and apply
the copied file to the check to customize attack pattern search cri-
teria for the HTML SQL Injection Check. (See “SQL Injection Attack
Check” on page 120.)
• GET
• POST
• HEAD
• PUT
• OPTIONS
• DELETE
• TRACE
18
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
• PATCH
• PURGE
Web Distributed Authoring and Versioning (WebDAV) is an extension to the HTTP protocol that is
used to allow Internet users to modify files on remote a resource (e.g., a web server), using HTTP
as the communication medium.
The WAF can be configured to accept several new WebDAV HTTP methods which allows
WebDAV traffic to pass through the WAF without being dropped. In releases prior to ACOS 4.0,
the WAF had to be disabled on all relevant connections prior to attempting to use the WebDAV
methods.
As part of the ACOS 4.0 enhancements, the WAF supports the following new WebDAV HTTP
methods, in addition to the originally-supported GET and POST methods:
• PROPFIND – retrieves the hierarchical information, and properties, for a directory con-
taining a set of resources
• PROPPATCH – modifies multiple properties for a set of a resources with a single oper-
ation
• MKCOL – creates a directory for the resources
• COPY – copies a resource from one URI to another
• MOVE – moves a resource from one URI to another
• LOCK – locks a resource (can be either shared or exclusive lock)
• UNLOCK – removes the lock from a resource
• * DP parsing of the new method string
The WAF can be configured to accept these new methods by using the allowed-http-methods
CLI command within a WAF template and then specifying which of the WebDAV HTTP methods
that will be allowed to pass through the WAF.
19
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
Session Checks
To increase the security of the session between the ACOS device and the clients, the WAF offers
cookie-based session checks, or “session tracking”.
With this option enabled, the WAF uses a cookie to track user sessions. When a request is
received from a client for the first time, ACOS creates a unique ID for the session, stores it in a
table, and inserts the ID into a cookie that is returned to the client. Subsequent requests from
this client are then validated against the session ID. If the session ID does not match the saved
ID, or if the ID is coming from a different IP address than that of the original client, then the
request is rejected.
Details:
• When enabled, you must specify the Session Lifetime to determine the amount of time the
session ID will remain valid. By default, the session lifetime is 600 seconds (10 minutes),
but you can enter a range from 1–86400 seconds (24 hours).
• The session cookie is named “awaf-sid”, and it is inserted into the header of the response
sent by ACOS.
• The header appears in the following format:
Set-Cookie: awaf-sid=<session-id>; path=/' max-age=<session-lifetime>
Password Security
The WAF offers several additional password security options to control how passwords are
treated when traversing the WAF.
When a user types a password into an HTML form’s password field, the characters are typically
hidden by another character, such as an asterisk. In this way, the password characters are
masked when typed by the user. This masking prevents an observer from stealing the password
and using it at a later time to access the user’s account.
20
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
The WAF can guard against this type of “shoulder surfing” by leveraging the “password” field
type. When the deny-non-masked-passwords option is enabled, the WAF will deny the
web server’s attempt to send a form unless the field type is set to “password”.
If the form field is named “password” (or “secret”), then the field type also needs to be set to
“password” to ensure that the password characters will be hidden when typed by the end user.
(Other field types, such as “text”, will not hide the password characters as they are being
entered by the user.)
The example below shows a form that would be denied by the WAF. Note that the form field
type is set to “text”, and the form name is set “Password”. The WAF would block the web server’s
attempt to send this form because the “input type=text” means the user’s password would not
be hidden or masked as it was being typed and would thus be vulnerable to theft.
<form>
Password: <input type="text" name="Password">
</form>
The second example below shows a form that would be allowed by the WAF, because even
though the field is named “Password”, the field type has also been set to “password”, meaning
the form field would mask the characters typed by a user.
<form>
Password: <input type="password" name="Password">
</form>
To configure the WAF to prevent web servers from sending non-secure password forms to a
client, use the deny-non-masked-passwords CLI command at the WAF template
configuration level.
You can configure the WAF to block user passwords that are sent over a non-encrypted
connection. If the connection between the client and the WAF is secured with SSL/TLS, then the
user password is allowed. However, if the client attempts to submit to a form field where “input
type=password”, and if the connection is not encrypted with SSL/TLS, then the WAF will block
the transmission.
NOTE: Even if this option is enabled, the user’s password may have
already been compromised while in transit, because the WAF
blocks transmission of the password only after the client has
already entered it over an unsecured connection. In such cases,
the user’s password could have already been compromised before
reaching the WAF.
21
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
You can enable this option to prevent the WAF from allowing the transmission of user
passwords over non-SSL-encrypted connections by entering the deny-non-ssl-
passwords CLI command at the WAF template configuration level.
Modern browsers can store user passwords and make an attempt at guessing at the password
values when the user encounters a website that requires entering his or her password into a
web form field. This autocomplete behavior is controlled by the “autocomplete=on/off”
attribute, which is typically associated with the HTML form text fields.
While end users may appreciate this “autocomplete” behavior because it simplifies the process
of logging into websites, the convenience comes at the cost of making the user’s password and
the overall security of the login process, less secure.
In order to control the browser’s behavior, administrators can increase the network security by
configuring the WAF to reject the web server form if the field type is set to “password” and if the
“autocomplete=on/off” attribute is set to “on”.
To configure this option and prevent the WAF from allowing the transmission of user passwords
when the “autocomplete=on/off” attribute is set to “on”, use the deny-password-
autocomplete CLI command at the WAF template configuration level.
An unvalidated redirect occurs when a hacker uses social networking (such as email, Facebook,
Twitter) to trick unsuspecting users into clicking on a malicious hyperlink as part of a phishing
scam. Although the hyperlink appears to be from a trusted website, it contains code that
redirects users to a forged website where users may be tricked into submitting their login
credentials (username/password), credit card numbers, security codes, or other sensitive
information. Once this information is acquired, hackers may then use it to access their accounts
or attack their systems.
Although OWASP groups “unvalidated redirects or forwards” together as a single threat, these
are actually two separate-but-related threats. As such, the WAF has different ways to mitigate
both types of attacks:
• “forwards” – With this type of threat, users become victims when they are forwarded to a
malicious URL which tricks them into surrendering their login credentials. This particular
risk can be mitigated through the use of the URL check feature, which is discussed here:
“URL Check” on page 14
22
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
The WAF protects users against the threat of “unvalidated redirects” by pre-learning a white-list
of acceptable locations to which users can safely be redirected. If one of the web servers
attempts to redirect a user to a location that does not appear in the redirect white-list, then the
WAF blocks the redirect.
The Open Redirect Mitigation feature must be enabled using the redirect-wlist CLI command.
The command is used at the WAF template configuration level, and the first time the command
is used, the WAF must be deployed in Learning Mode.
NOTE: If you attempt to use the command for the first time while the WAF
is deployed in Active Mode or Passive Mode (and before the redi-
rect white-list has been created during Learning Mode), then you
will receive an error message stating that “redirect-wlist cannot be
turned on with empty list.”
Valid traffic is then injected into the WAF, which then investigates each “redirect” response
packet received from the backend web servers, where a redirect response packet is defined as
any packet having a status code ranging from 300–308.
The WAF extracts the value from the Location field of the header of the response packet and
stores it in its internal database.
When the WAF deployment mode is subsequently changed from Learning Mode to Active Mode
(or Passive Mode), the location information in the database is transferred to a persistent file
called “redirect_wlist_”. The filename will have the name of the WAF template as its prefix. For
example, the WAF template “test” would have a policy file called “_test_redirect_wlist_”.
Details:
The behavior of this option depends on which deployment mode the WAF is in:
• Learning Mode – The option must be enabled for the first time while the WAF is deployed
in Learning Mode. The information is saved in the ACOS device’s local database. At this
time, the white-list file has not yet been created, so if you wish to modify the redirect
white-list, you must change to Active or Passive Mode. Note that no action is performed
upon traffic during Learning Mode, other than using the traffic to build the redirect white-
list.
• Active Mode – Once the redirect white-list is created while the WAF is deployed in Learn-
ing Mode, you can then change the deployment mode to Active Mode. At this point, the
database is used as a white-list of allowed location headers in redirect packets. If a
response from the web server contains a redirect which is not in the white-list, the WAF
will deny (drop) the response and send the client a “403 forbidden” reply.
• Passive Mode – If the option is enabled while the WAF is deployed in Passive Mode, the
WAF leverages the existing redirect white-list to inspect traffic, but it takes no action, in
23
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
terms of blocking traffic, and simply increases the counters and generates logs for hypo-
thetical actions that would be taken if the WAF were in Active and not Passive Mode.
Configuration
To prevent unvalidated redirects, use the following CLI command at WAF template configuration
level:
redirect-wlist
NOTE: The WAF must be deployed in Learning Mode the first time the
command is used. Once the redirect white-list is created, you can
then switch to Passive Mode or Active Mode.
Display Statistics
You can display statistics for this redirect-wlist option using the show waf stats virtual-
server-name portnum CLI command, as shown in the example below, which offers three
dedicated counters associated with the redirect white-list:
The output in this example is for the WAF template that is bound to vip2, port 80. The table
below describes the relevant fields in the command output.
24
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
For example, one URL might use lower-case characters, while another URL could use a mix of
upper-case and lower-case characters. A simple corrective normalization scheme could be
used to convert the URL with the mixed set of upper-case and lower-case characters to use
only lower-case characters, as shown below.
This process of normalizing URLs is sometimes used by search engines to make comparisons of
several URLs easier. By standardizing the appearance of URLs and reducing them to canonical
form, it is easier to ensure the same URL is not cataloged twice by a web crawler.
The WAF uses URL normalization to protect web servers from certain types of attacks, which
can hide in the non-normalized, recursive encoding of the data. One example of such an attack
is the so-called “directory traversal attack,” which exploits non-sanitized file names to gain
access to sensitive directories or files.
URL Options
In addition to normalizing upper-case and lower-case, the WAF can also make the following
changes to internal URLs sent from backend servers:
• Decode Entities – Decode entities, such as < &#xx; &#ddd; &xXX in an internal URL.
• Remove Self References – Remove self-references, such as /./ and /path/../ from an
internal URL.
• Remove Spaces – Remove spaces from an internal URL.
25
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
ACOS 4.0 offers enhancements to the WAF that allow it to scrub client requests containing
eXtensible Markup Language (XML) code for anomalies. XML is commonly used for data
exchange, but hackers may exploit security holes in the XML code to attack servers.
It is important to inspect and validate client requests containing XML code to protect the
backend servers from XML transactions that could allow hackers to bypass application security,
provide malicious input, and potentially slow down or crash the servers.
When the new WAF XML checks are enabled, the WAF checks client requests for XML, and if
present, the WAF then validates the structure of the XML document using a trusted XML
schema file. In doing so, this helps to ensure that the content of the client’s XML request is well-
formed and does not contain any potential threats.
In this release, the WAF offers the following types of XML checks:
• XML Format Checks – This option uses the xml-format-check command and examines the
XML format of incoming requests and blocks requests that are not well-formed.
• XML Validation Checks – This option uses the xml-validation CLI command to validate the
XML content in a request in order to check it against an XML Schema file or WSDL file.
Running such checks on incoming XML content prevents an attacker from using spe-
cially-constructed (and invalid) XML messages to circumvent the web application’s stan-
dard security checks. If the WAF discovers that the XML content fails the validation check,
then the WAF blocks the request.
• XML Limit Checks – This option uses the xml-limit CLI to command enforce parsing limits
in order to protect the servers from various denial-of-service (DoS) attacks, such as XML
bombs and Transform Injections, both of which are defined in greater detail below.
• XML Cross-Site Scripting Checks – This option uses the xml-xss-check CLI command to
examine the headers and bodies of incoming XML requests for Javascript keywords that
might indicate possible cross-site scripting attacks. If the request contains a positive
match, then the WAF blocks the request.
• XML SQL Injection Checks – This option uses the xml-sqlia-check CLI command to exam-
ine the headers and bodies of incoming requests for inappropriate SQL special characters
and keywords that might indicate an SQL Injection Attack. If found, the WAF blocks those
requests.
26
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
xml-format-check
The XML format check verifies that incoming requests containing XML code are in compliance
with the XML 1.0 specification, which can be found at the following URL: http://www.w3.org/
TR/REC-xml/
The XML Format Check evaluates incoming XML documents for compliance with the following
rules:
• The document may contain no special XML syntax characters. For example, none of the
following characters can be included in the XML document, unless used as markup: , “<“,
“>”, and "&”
• The XML document must contain all beginning and end tags. All begin, end, and empty
element tags must be nested correctly. The XML document must not be missing any ele-
ment tags, and it cannot contain overlapping element tags.
• A single root element must contain all the other elements in the XML document.
The XML Validation Check examines client requests containing XML content to make sure that
the XML messages are valid.
If a client request contains an XML message, and the XML validation check option is enabled,
then the incoming request will be compared with an XML schema file.
An XML schema is an XML document which describes the desired structure of other XML
document. The XML schema goes beyond just defining proper XML syntax, and it defines things
such as which elements or attributes can appear in an XML document, as well as the number,
order, and relationship of child elements. It can also determine the data types associated with
the various elements and attributes that appear in an XML document.
If an incoming request is compared with the XML schema, and the WAF determines that the
request is not valid, then it is deemed a threat and the WAF blocks the request.
27
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
The option can be enabled using the following CLI command at the WAF template configuration
level:
The WAF can validate XML messages using an XML schema file. You must upload the XML
schema file that you plan to use for validation. The XML schema file can be uploaded using the
import command at the global config level of the CLI:
The use-mgmt-port option allows you to indicate the use of the management interface as the
source interface for the connection to the device.
The url option specifies the file transfer protocol, username, and directory path. You can enter
the entire URL on the command line, or you can press Enter to display a prompt for each part of
the URL. If you enter the entire URL and a password is required, you will still be prompted to
enter the password. To enter the entire URL:
• tftp://host/file
• ftp://[user@]host[:port]/file
• scp://[user@]host/file
• sftp://[user@]host/file
If you need to modify an existing XML schema file, you can do so using the following CLI
command at the global config level:
If you need to remove an existing schema file, you can do so using the following CLI command
at the global config level:
Response Validation
By default, the WAF does not validate server responses. In order to validate responses from a
protected web application, the resp-val option should be selected.
28
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
WSDL Validation
The WAF can validate SOAP messages (based on XML) using a Web Services Description
Language (WSDL) document.
For more information about WSDL Validation, please see “WAF SOAP Checks” on page 34.
29
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
XML Bomb
An XML Bomb is a denial of service attack that takes advantage of the fact that entity
references in XML documents must be expanded for evaluation. Such attacks can achieve this
goal by adding extra entity entries to the XML document, and then defining subsequent entities,
which are based on the expanded values of the previous entity. Entity expansion is a normal and
required action for XML documents, so hackers can take advantage of this loophole by using it
to exhaust system memory and CPU resources. If it is left unchecked, such an attack could
really slow performance thus causing servers to crash.
The WAF can address this issue by placing a maximum limit on the number of entity expansions
that are allowed in an XML document. Similarly, a maximum limit can be imposed on the number
of levels of entity recursion. Together, imposing these types of limits on XML documents can
contain and mitigate the harmful effects of an XML Bomb.
Transform Injection
Transform Injections are a different type of denial of service attack, and they work by taking
advantage of XSLT flow-control functions, and by creating infinite loops, or perhaps redundant
transforms, which will eventually exhaust the available memory and CPU resources that the
server can offer.
To mitigate the effects of Transform Injection attacks, the WAF can be configured to place limits
on the maximum depth of child element pairs, the amount of data contained in an element pair,
and the maximum size of an XML document.
Configuring XML Limit Parameters to Thwart XML Bombs and Transform Injections
To prevent XML Bombs, Transform Injections, and other types of DoS attacks from consuming
excessive system resources, ACOS provides the following CLI command, which can be used at
the WAF template configuration level.
The xml-limit command can be completed using any of the parameters shown below:
• max-attr number
Limits the maximum number of attributes each individual element is allowed to have.
number – Maximum number of children allowed per element. Range is 1–256. Default is 256.
30
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
• max-attr-name-len number
Limits the maximum number of any one type of element per XML document.
number – Number of elements allowed. Range is 1–8192. Default is 1024.
• max-elem-child number
Limits the maximum number of children each element is allowed, and includes other ele-
ments, character information, and comments.
number – Maximum number of children allowed per element. Range is 1–4096. Default is
1024.
• max-elem-depth depth
31
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
The option can be enabled with the following CLI command at the WAF template configuration
level:
xml-xss-check
The policy file for xml-xss-check is taken from the xss-check option, which must also be
configured. See “XSS Check” on page 120 for additional details.
The WAF checks the incoming request against the “jscript_defs” WAF policy file, which contains
a list of common Javascript commands. If the client request detects a positive match against
the Javascript commands in this policy file, then the message will be rejected. The WAF does
not currently support the ability to modify the contents in XML requests that are denied.
CLI Example
The xml-xss-check depends on configuring the xml-format-check and the xss-check within
the WAF template. The xss-check is configured to reject requests with a positive match to the
filtering criteria. The WAF template “tempwaf1” is bound to VIP “vs101”.
32
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
port 80 http
source-nat pool nat_IPv4
service-group sg-http
template waf tempwaf1
xml-sqlia-check
The policy file for xml-sqlia-check is taken from sqlia-check, which must also be configured.
See “SQL Injection Attack Check” on page 120 for additional details.
The WAF checks the incoming request against the rules contained in the WAF policy file
“sqlia_defs”. If the client request detects a positive match against the rules in the policy file,
then the message will be rejected. The WAF does not currently support the ability to modify the
contents in XML requests that are denied.
CLI Example
The xml-sqlia-check depends on configuring the xml-format-check and the sqlia-check within
the WAF template “tempwaf2”. The sqlia-check is configured to reject requests with a positive
match to the filtering criteria. The WAF template “tempwaf2” is bound to VIP “vs102”.
33
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
What is SOAP?
The Simple Object Access Protocol (SOAP) was created to allow platform-independent
communication between web services. SOAP is based on XML and typically relies on HTTP to
transmit messages.
Prior to SOAP, most applications would communicate using remote procedure calls (RPCs).
When attempting to send an RPC over the Internet to a web server, problems could occur
because RPCs would often get blocked by overzealous firewalls.
SOAP gained popularity because it offered a way for web applications to communicate over the
Internet without the messages being intercepted by firewalls. This is by virtue of the fact that
SOAP relies on HTTP to transmit messages, and HTTP is supported by virtually all Internet
browsers and servers.
A SOAP message is an ordinary XML document that contains the following elements:
• An Envelope element, which identifies this XML document as being a SOAP message
In this release, the WAF offers the following types of SOAP checks:
• SOAP Format Checks – This option uses the soap-format-check CLI command and exam-
ines the format of incoming SOAP requests and blocks those which are not well-formed.
• SOAP Validation Checks – This option uses the xml-validation wsdl CLI command to val-
idate the SOAP content in a request in order to check it against a WSDL file. If the WAF dis-
covers that the SOAP content fails the validation check, then the WAF blocks the request.
34
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
While it is not recommended, SOAP format checks can be enabled independently of XML checks.
Most of the time, however, SOAP format checks are done in tandem with XML format checks,
which makes sense, because SOAP is based on XML.
As a matter of best practices, when enabling SOAP format checks (using the soap-format-
check option), you should also enable XML format checks (using the xml-format-check
option). The reason for this is that the WAF always does the XML checks first and then adds
additional SOAP checks.
For additional information on XML format checks, see “WAF XML Checks” on page 26.
The SOAP Format Check scrubs incoming client requests to ensure that the SOAP requests are
structured in the proper format, as defined by the World Wide Web consortium in the following
Recommendation:
http://www.w3.org/TR/2007/REC-soap12-part1-20070427/
• Verifies that messages have the appropriate sections (e.g., Message, Header, Body, Fault,
etc.) and that these sections appear in the correct order.
• Verifies that the envelope uses the correct namespace (http://www.w3.org/2003/05/
soap-envelope).
• Verifies that defined attributes, such as role, encodingStyle, Code, etc., follow the defined
format.
You can enable SOAP format checks using the following CLI command at the WAF template
configuration level:
soap-format-check
35
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
In contrast with the XML schema file (which defines how the data in an XML document is
structured), the WSDL document is for SOAP documents. (Please ignore for a moment the
confusing fact that SOAP documents are based on XML1.)
The WSDL file describes functionality of a SOAP document by defining which operations are
available and how the data should be structured. The WSDL file contains the operation, such as
the methods provided by a web service, and the document describes which data types (int,
float, etc) the method can accept. Validating a SOAP document using a WSDL file ensures that
the method being called is defined for the current direction, and that the message conforms to
the schema for that message.
The WSDL validation option can be enabled using the following CLI command at the WAF
template configuration level:
You must upload the WSDL file you will use for validation. The WSDL file can be uploaded using
the import command at the global config level of the CLI:
The use-mgmt-port option allows you to indicate the use of the management interface as the
source interface for the connection to the device.
The url option specifies the file transfer protocol, username, and directory path. You can enter
the entire URL on the command line, or you can press Enter to display a prompt for each part of
the URL. If you enter the entire URL and a password is required, you will still be prompted to
enter the password. To enter the entire URL:
• tftp://host/file
• ftp://[user@]host[:port]/file
• scp://[user@]host/file
• sftp://[user@]host/file
If you need to modify an existing WSDL file, you can do so using the following CLI command at
the global config level:
1.
To explain why the command is “xml-validation wsdl” and not “soap-validation”, consider that WSDL is an extension to the
XML Schema and it assumes the presence of some type of XML RPC headers. Therefore, WSDL does not include their defini-
tion in each schema file, but it extends the XML Schema to allow for an association to occur for specific calls to specific URIs,
assuming the contents of the headers.
36
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
If you need to remove an existing WSDL file, you can do so using the following CLI command at
the global config level:
Response Validation
By default, the WAF does not validate server responses. In order to validate responses from a
protected web application, the resp-val option should be selected.
In ACOS 4.0, the WAF is enhanced by adding support for parsing and verifying JSON data in
HTTP POST operations. The WAF supports the ability to run a format check on requests
containing JSON data. This helps to ensure that the content of the request is well-formed. In
addition, the WAF supports the ability to impose JSON parsing limits in order to protect web
servers from various types of denial-of-service (DoS) attacks.
In this release, the WAF offers the following types of JSON checks:
• JSON Format Checks – This option uses the json-format-check command and examines
the JSON format of incoming requests and blocks requests that are not well-formed.
• JSON Limit Checks – This option uses the json-limit CLI to command enforce parsing
limits in order to protect the servers from various denial-of-service (DoS) attacks.
The JSON format check verifies that incoming requests containing JSON code are in
compliance with RFC 4627.
Compliance Criteria
The JSON Format Check evaluates incoming requests for compliance with the following criteria:
37
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
• All objects must contain matching braces {}, and a set of members must be separated by
commas.
• Every object member must contain a name and value, separated by a colon.
• All arrays must contain matching brackets [], and a set of values must be separated by
commas.
• Numbers must be properly formatted.
This option can be enabled using the following CLI command at the WAF template configuration
level:
json-format-check
To prevent DoS attacks from consuming excessive system resources, ACOS provides the
following CLI command, which can be used at the WAF template configuration level.
The json-limit command can be completed using any of the parameters shown below:
• max-array-value-count number
38
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
This feature enables an administrator to configure the WAF to block attacks based upon the
geo-location information of incoming requests. You can block an attack originating from a
country, region, or state that has a known history of being a hotspot for various types of WAF-
preventable attacks.
This capability allows you to limit which countries can access your resources based upon the
geo-location information associated with a request. You can create an HTTP policy that would
permit or deny traffic based upon a combination of threshold events and geo-location
information.
The WAF Geo-location Based Blocking feature allows you filter incoming client requests using
two different approaches.
The WAF geo-location feature uses an HTTP policy to apply a WAF template to an incoming
request. The geo-location database (such as an IANA file) can identify which part of the world a
certain request came from. The IANA database contains the mappings between geographic
regions and IP address ranges, as assigned by the Internet Assigned Numbers Authority. (For
more information about the IANA database, see the Global Server Load Balancing Guide.)
Using the IANA database, the WAF can evaluate incoming requests and determine that, for
example, a request with an IP of 222.111.222.111 is from, say, the North Korea. Perhaps this is a
region with rampant cyber-criminal activity. In order to prevent hackers from this region from
being able to access your web servers and steal credit card numbers, the WAF can be
configured to detect traffic from this region, and if there is a match, the traffic could be denied.
Alternatively, if this region is known to use XML bombs, then perhaps a WAF template could be
applied to the traffic that would offer protection from XML bombs and other DoS attacks using
the XML Limit Checks.
If an HTTP-policy file is used with a WAF template, and if the WAF is in Learning Mode, you can
identify the sources of various attacks. You can configure the relevant geo-locations in the
HTTP-policy file and direct the traffic through different WAF templates. This produces statistics
for the different regions, and these statistics can be used to identify the top countries where
attacks are sourced from.
39
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
You can enable the WAF Geo-location blocking feature by using the new geo-location keyword
at the HTTP policy configuration level.
CLI Example
This example shows how to configure the WAF geo-location feature using an HTTP policy. The
policy can be used to allow or deny traffic based on geo-location information. This example
creates the geo-location information for a region in China, and for a region in the United States,
and does not rely on the IANA database.
First, we will configure the GSLB geo-location IP address range for the first region (e.g., Beijing,
China)
Configure the GSLB geo-location IP address range for the second region (e.g., San Jose, USA)
Configure the real server IP and port information for server “s1”:
Configure the real server IP and port information for server “s2”:
40
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
Set up the logging template and bind it to the service group “syslog”:
Create the WAF template “waf-1", with the max parameters set to 3, and logging template called
“syslog”:
Create the WAF template “waf-2”, with credit card number masking enabled, and logging
template called “syslog”:
Create the http-policy template called “geo-policy-http-ipv4”, and within that HTTP policy
template, enable the geo-location feature for the first region you created (i.e. Beijing, China).
Bind it to the service-group “sg-http-p1”, and bind that to WAF template “waf-1”. Similarly,
enable the geo-location feature for the second region you created (i.e. San Jose, USA), and bind
it to the service-group “sg-http-p2”, and bind that to WAF template “waf-2”:
41
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Request Protection
Create the slb virtual-server configuration “vs101”, with port 80 (HTTP), and set up the source-
nat pool “nat_IPv4”, and bind both service-groups “sg-http-p1” and “sg-http-p2”. Then, bind
the HTTP-policy template we created earlier, and bind the two waf templates.
With the above configurations, the HTTP request destined to virtual server “vs101” port 80 from
clients belonging to geo-location Beijing.China will be checked against template waf waf-1.
Clients belonging to geo-location Sanjose.USA will be checked against template waf waf-2.
You can configure WAF geo-location based blocking using an ACL by creating an access control
list and using the geo-location keyword.
This example shows how to configure an IPv4 access-list with geo-location rules that would
permit all traffic to and from the United States, while denying all traffic to or from North Korea:
You can configure several key areas of the WAF using aFleX scripts. This interface is provide in
addition to the CLI and GUI, and it provides a new way to configure the WAF by allowing you to
set up a variety of WAF trigger events.
42
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Request Protection
• request violation – Violations are triggered anywhere in the code where ACOS is logging a
WAF action, such as deny, sanitize, ignore a real error, and so on. (This applies to client
requests.)
• response violation – Violations are triggered anywhere in the code where ACOS is logging
a WAF action, such as deny, sanitize, ignore a real error, and so on. (This applies to server
responses.)
• WAF deny – A deny action is triggered when there is a final deny action being applied (vio-
lations may be overridden as described below)
• WebDAV - In prior releases, ACOS contained a hard-coded list of HTTP methods that the
WAF would allow to traverse. Prior to ACOS 4.0, the WebDAV methods were not part of this
list, so whenever a WAF was applied in a customer environment in which WebDAV meth-
ods were used, the WAF would end up rejecting all of the requests that used the WebDAV
methods. The workaround was to avoid configuring WAF on this virtual port.
However, this release adds aFleX, which in turn means that the administrator can write an
aFleX script that triggers on request violation. The WAF will check the violation ID and deter-
mine that this is a violation of the allowed methods rule. Upon learning this, the WAF will call
the WAF::disable method, which will temporarily disable WAF processing (for this connec-
tion only).
• There are some cases where specific URL patterns (or other sorts of data) match some of
the expressions which are used by black lists, SQLIA, XSS, or any other pattern-matching
rules used by the WAF. A user can be aware of such false-positive violations, and bypass
this violation for the false-positive that triggered the event.
Possible Actions:
If the WAF detects traffic that violates one or more rules, aFleX commands can be configured to
seize upon this trigger in order to perform one of the following actions upon that traffic:
• Allow - This action is triggered by a violation event when the WAF is deployed in Passive
Mode and Learning Mode.
• Deny - This action is triggered by a violation event when the WAF is deployed in Active
Mode.
• Mask - This action is triggered for the event WAF_RESPONSE_VIOLATION, but only for the
following select features, such as ssn-mask, ccn-mask, and pcre-mask.
• Redirect - This action is triggered under violation events for the referer-check feature if
the WAF is deployed in Active Mode.
43
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Response Protection
• Sanitize - This action is triggered for the WAF_REQUEST_VIOLATION event for features
that support the ability to sanitize traffic, such as xss-check, sqlia-check. The action can
also be triggered for the WAF_RESPONSE_VIOLATION event.
• WAF::disable – Disables WAF processing for the connection during which the aFleX script
is triggered.
• WAF::enable – Re-enables WAF processing for the connection during which the aFleX
script is triggered.
• WAF::mode – Returns the current deployment mode in which WAF is configured (active,
passive or learning).
• WAF::template – Returns the name of the active WAF template.
• WAF::violation – Returns or logs information related to WAF violation events.
For syntax associated with these aFleX commands, please see the “WAF Commands” section in
the aFleX Reference.
WAF Events
The following Web Application Firewall (WAF) events are available:
For syntax and a list of events associated with these aFleX commands, please see the “WAF
Events” in the aFleX Reference.
Response Protection
The WAF inspects the content of outbound HTTP responses and hides aspects that can equip
an attacker with valuable information. The WAF template can further protect web servers with
the following options for HTTP responses:
• Mask Sensitive Content – Strings in a response are examined for patterns of sensitive
content, such as credit card numbers or US social security numbers. If the WAF discovers
44
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Response Protection
To protect sensitive content, the WAF masks strings in the communication between an end-
user and web server using the following options.
CCN Mask
The Credit-card Number (CCN) Mask checks web server responses for end-user credit card
numbers. This check protects user credit card information from being intercepted and viewed
by unauthorized parties. For example, the CCN mask replaces all but the final group of digits in
the card number with “x” characters. A credit card number of 4111-1111-1111-1111 would become
“xxxx-xxxx-xxxx-1111”.
To protect user credit card information, you should configure the CCN mask for each accepted
type of credit card.
45
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Response Protection
NOTE: A10 Networks recommends enabling this check for URLs that
access or transfer credit card information. For example, shopping
websites with a check-out page or websites that access back-end
databases which contain customer credit card numbers. This
check is unnecessary if the website does not have access to or use
credit card information.
SSN Mask
Similar to a CCN mask, a Social-security Number (SSN) Check masks web server replies for US
social security numbers. If enabled, the SSN check mask searches strings which appear to
match the format of US social security numbers and replaces all but the last 4 digits of the
string with “x” characters.
PCRE Mask
In addition to the preconfigured CCN and SSN checks described above, you can configure
custom masks using Perl Compatible Regular Expressions (PCRE) syntax. For example, you can
configure a mask that checks for driver’s license numbers. (For more information, see “Writing
PCRE Expressions” on page 126.)
You can configure the portions of matching strings to keep, and which portions to mask. You
also can customize the mask character (“X” by default).
Cloak Responses
The WAF can strip HTTP response headers to “cloak” server information that can equip a hacker
to target an attack on your web servers. For example, the WAF can cloak an HTTP response
header to hide what operating system is running on your servers. Information such as this can
enable a hacker to more narrowly target your servers with attacks that are specific to the
servers’ operating systems. You can cloak server information with the following WAF template
options:
• Filter Response Headers – Checks responses coming from the web server and removes
headers with server identifying information. For example:
• Server
• X-Runtime
46
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Response Protection
• X-Powered-By
• X-AspNet-Version
• X-AspNetMvc-Version
• Hide Response Codes – Conceals 4xx and 5xx response codes for outbound responses
from a web server and returns a generic error code instead. This option hides error codes
which can provide an attacker with information to specifically target web server vulnera-
bilities.
The WAF sends an error page in response. You can configure the response error page in the
Deny-Action security check section of the WAF template.
You can configure the WAF to return instrumented responses with form tags for user-
modifiable fields.
NOTE: You can use the Referer Check to further help prevent CSRF
attacks.
47
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
PCI 6.6 Compliance
Cookie Encryption
This check protects against cookie tampering by encrypting cookies before sending server
replies to end-users. Clients are then unable to view the content of encrypted cookies, which
clients could otherwise modify to gain illegal access. If the encrypted cookie is modified, then
decryption of the tampered cookie will fail when it is sent back from the client and the request
will be rejected.
You can enable encryption based on specific cookie names or for all cookies that match a PCRE
expression. The encryption uses a secret string to decrypt and encrypt cookies that are
transferred between the web server and client. (For a configuration example, see “WAF
Deployment and Logging Examples” on page 137.)
While the PCI SSC does not officially certify Web Application Firewalls, similar recognition can be
achieved through third-party companies, such as the International Computer Security
Association (ICSA) Labs.
A10 Networks has achieved WAF certification from ICSA Labs. This certification can help assure
network administrators that the ACOS WAF meets the requirements, as stated in PCI DSS
section 6.6 “Compliance for Web Apps”, the text of which appears below:
48
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
PCI 6.6 Compliance
For public-facing web applications, address new threats and vulnerabilities on an ongoing basis
and ensure these applications are protected against known attacks by either of the following
methods:
NOTE: Note: This assessment is not the same as the vulnerability scans
performed for Requirement 11.2.
• Installing an automated technical solution that detects and prevents web-based attacks
(for example, a web-application firewall) in front of public-facing web applications, to con-
tinually check all traffic.
For more information, you can access the PCI DSS at https://www.pcisecuritystandards.org/
documents/PCI_DSS_v3.pdf
PCI compliance essentially means that the WAF meets a long list of requirements. The exact set
of requirements can vary, depending on where a particular device is located in the network, as
well as which services the device offers. For the ACOS WAF, a partial list of important highlights
includes the ability to do the following:
• Restrict access to a resource (such as a web server) based on the IP address from which
the request originated
• Restrict access to particular data at the network boundaries
• Hide sensitive information, such as credit card numbers, when this data crosses a network
boundary
• Limit or prevent configuration changes (and logging each configuration change as it hap-
pens)
• Protect and store log messages
More information about PCI DSS compliance can be found at the following link:
https://www.pcisecuritystandards.org/documents/information_supplement_6.6.pdf
49
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
PCI 6.6 Compliance
50
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
This chapter describes the WAF operational modes and how to use them to deploy the WAF.
Overview
The WAF supports the following operational modes:
• Learning – Learning Mode provides a way to initially set the thresholds for certain WAF
checks based on known, valid traffic.
• Passive – Passive Mode provides passive WAF operation. All enabled WAF checks are
applied, but no WAF action is performed upon matching traffic. This mode is useful in
staging environments to identify false positives for filtering.
• Active – This is the standard operational mode. You must use Active Mode if you want the
WAF to sanitize or drop traffic based on the configured WAF policies.
Figure 5 shows a typical work flow for WAF deployment, using these modes.
CAUTION: While Learning or Passive Mode is in operation, the WAF does not
block any traffic. Only Active Mode blocks traffic.
Notes:
• Use of the Learning and Passive Modes is recommended during the deployment process.
• To access WAF data event messages, logging to external servers is required. See “WAF
Event Logging” on page 111.
• When the WAF is deployed in either learning or passive mode, traffic is not blocked. How-
ever, event log messages will list the response action (deny, allow, or sanitize) that is con-
figured in the WAF template. In addition, WAF counters will continue to increment as if the
WAF is deployed in active mode.
51
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Overview
52
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Overview
Learning Mode
Learning Mode provides a way to dynamically set certain WAF options based on traffic.
When you enable Learning Mode in a WAF template, ACOS resets the following WAF security
check values to zero:
53
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Overview
1. In Figure 6, a WAF template is configured and is bound to the HTTP/HTTPS virtual port on
the ACOS device. The domain name mapped to the VIP address by DNS is “www.exam-
ple.com”.
2. Known, valid traffic is then sent to the WAF. As traffic is received by the virtual port to which
the WAF template is bound, ACOS updates the settings for the WAF parameters listed
above.
In this example, the following HTTP request is sent:
GET / HTTP/1.1
Host: www.example.com
Connection: close
User-Agent: Mozilla/5.0
Accept-Encoding: gzip
Accept: text/html
Cache-Control: no-cache
3. When the WAF receives the request, Learning Mode updates the following checks in the
WAF template:
Buffer Overflow Check:
• Maximum headers = 7
• Max-url-len = 15
• Max-hdrs-len = 23
Allowed HTTP Methods Check = GET
URL Check (not shown in example)
4. To “lock in” the WAF template settings, change to a different mode (for example, Passive
Mode or Active Mode). You can fine-tune the template settings later, if needed.
Notes
• Beginning in ACOS release 4.0, the WAF will display the learned values in the running-con-
figuration only after the WAF deployment mode is changed from Learning Mode to Active
Mode or Passive Mode. The reason for this change in behavior relative to prior releases, is
that ACOS 4.0 introduces the Configuration Manager (CM), which acts like an internal
“staging area” for the configuration changes. Such config changes are temporarily save to
short-term memory and will remain there until an operation is committed, which happens
when the WAF is switched from Learning Mode to Passive or Active Mode. In previous
releases, config changes were saved directly into the running-config file, and there was
no internal staging area.
• Before enabling Learning Mode, make sure the WAF is not receiving production traffic.
Security checks in the WAF template are not enforced during Learning Mode and the WAF
will not deny any requests, even if a request fails a security check.
• If the setting for a check reaches its maximum configurable value, the check is set at that
value. The setting value does not increase.
54
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Overview
• The URL Check file is not created until the mode is changed from Learning to Passive or
Active. You cannot modify the URL check file while Learning Mode is enabled.
• For an example of Learning Mode, see “WAF Deployment and Logging Examples” on
page 137.
Passive Mode
Passive Mode logs traffic that matches a WAF policy file or check, but does not perform any
action on matching traffic. While the WAF is operating in Passive Mode, you can monitor the data
event log messages sent to remote logging servers, and fine-tune your template settings so
that valid traffic is not mistakenly blocked by the WAF.
Typically, Passive Mode is used in a production network to check for false positives while real
production traffic is running. A false positive occurs when valid traffic matches a WAF check,
and would be dropped during Active Mode operation.
This example shows a “false positive” match on the max-cookies check. In this example, the
WAF template allows a maximum of 3 cookie headers within a given request.
55
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Overview
3. The client sends a new request and inserts the cookies sent by the server in the request.
4. The WAF template allows a maximum of 3 cookies (3 separate cookie headers) in a given cli-
ent request. Because the client’s request contains more than 3 cookies, the request fails
the max-cookies check, and a data event log message is sent to the external log server.
However, because the WAF is operating in Passive Mode, the traffic is allowed.
Notes:
• Because the WAF is operating in Passive Mode, the client request is sent to the server
instead of being dropped. In Active Mode, the request would be dropped.
• To access WAF data event messages, logging to external servers is required. See “WAF
Event Logging” on page 111.
• During Passive Mode operation, data event logs for matching traffic will state that the
traffic was denied even though the traffic in fact is allowed. However, all WAF data event
messages include the operational mode.
56
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Overview
Active Mode
Active Mode enforces the policies (definition files) and security checks that are enabled in the
WAF template bound to the virtual port. If the action configured for a specific check is to drop
traffic that matches the check, the traffic is dropped.
1. The client sends a request. The request contains SQL code. The request is an attempt to
inject SQL code onto the server.
2. The WAF SQL Injection Check detects the SQL. Based on the configuration, the WAF rejects
(drops) the request.
3. The WAF sends a log message to the log server.
Figure 9 shows a walk-through of the WAF process as it examines the client’s request.
57
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Overview
1. First, the WAF checks the request URI against the entries in the White List. In this case, the
URI matches. The request passes to the next phase, the Black List check.
2. The request URI does not match any of the Black List entries, so is passed to the next
phase, the request checks.
3. The request passes the Allowed-HTTP-methods Check. However, the request fails the SQL
Injection Check and is denied.
58
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Setting the WAF Operational Mode
59
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Setting the WAF Operational Mode
60
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configuration Overview
The WAF operates on traffic that is addressed to the virtual IP address (VIP) and HTTP/HTTPS virtual
port of your website. To apply WAF protection to the virtual port, basic configuration is required.
Additional, advanced configuration is optional.
This chapter describes how to configure the WAF using the GUI.
Configuration Overview
This section summarizes the configuration tasks for the WAF. The following sections provide
detailed steps for each task.
Notes:
• External logging is the only mechanism supported for accessing WAF data plane log mes-
sages.
• The WAF comes with predefined WAF policy files. You can modify policy rules in the URI White
and Black Lists, or add search definitions used for the Bot Check, SQLIA check and so on. For
more information, see “WAF Policy Files” on page 119. A10 Networks highly recommends mod-
ifying WAF policy files to meet your specific security demands.
• Optionally, you can pair the WAF template with an HTTP policy template to enforce WAF secu-
rity checks based on URL, host, or cookie. (See “Overriding a WAF Template” on page 131.)
• For examples of advanced WAF configuration, see “WAF Deployment and Logging Examples”
on page 137.
61
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Bind the WAF Template to the Virtual Port
5. Click the Virtual Server Name drop-down menu and select a pre-configured VIP to
bind.
For a VIP to appear in the Virtual Server Name drop-down list, it must be configured
with one or more HTTP/HTTPS virtual ports.
6. Based on the VIP that you select, the Virtual Server IP field and Port and Protocol
fields automatically update. If desired, you can click the Port and Protocol drop-down
menu and select a different port/protocol combination from the list of HTTP or HTTPS ports
associated with this VIP.
7. Click the WAF Template drop-down menu and select the desired WAF template from the
list.
Alternatively, click the New WAF Template button to configure a new WAF template for
this WAF service. (See “Configure a WAF Template” on page 63.)
8. Click the HTTP Policy drop-down menu and select the desired HTTP template.
62
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure a WAF Template
Alternatively, click the New HTTP Policy Template button to configure a new template.
(See “Configure an HTTP Policy Template” on page 85.)
9. Click the Create button to complete the WAF service configuration.
63
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure a WAF Template
• Active – WAF enforces the checks configured in the template and sends events to the
external log server.
• Passive – WAF sends events to the external log server but does not enforce security
checks.
• Learning – WAF “learns” acceptable check parameters based on a stream of legitimate,
secure traffic. When in Learning Mode, the WAF continues sending events to the external
log server.
For more information, see “WAF Operational Modes” on page 51.
3. From the Logging Template drop-down menu, select the name of a configured logging
template to direct WAF logging activity. See “WAF Event Logging” on page 111.
4. Select the Log Successful WAF Requests checkbox if you want the WAF to log debug
messages on the successful completion of WAF requests, and not just for errors.
5. Click the Deny Action drop-down menu and specify the action to be applied when the
WAF denies a client’s request.
• HTTP Response 403 – Sends a 403 Forbidden response to the client. When this option is
selected, the default string returns a generic “Request Denied!” page to the client, but
you can clear the “Default Response 403” checkbox and enter your own response string
in the “Response URL 403” field that appears.
• HTTP Response 200 – Sends a 200 OK response to the client with the specified response
string. The default string returns a generic “Request Denied!” page to the client. When
this option is selected, the default string returns a generic “Request Denied!” page to the
client, but you can clear the “Default Response 200” checkbox and enter your own
response string in the “Response URL 200” field that appears.
• HTTP Response Redirect – Redirects the client to the specified URL.
When this option is selected, a text box appears where you can enter a response string or
redirect URL.
• Reset Connection – Sends a TCP RST to the client to end the connection.
6. When finished, click Create to save your changes.
1. Select the HTTP Request Checks tab to display the list of security options that deter-
mine how the WAF will handle HTTP requests from the client. A window similar to that
shown below appears.
64
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure a WAF Template
2. In the Allowed HTTP Methods field, click to select one or more HTTP methods (GET,
POST, and so on) that are allowed to appear in client requests.
3. Select the Bot Check checkbox to check the user-agent of incoming requests for known
bots. This check uses the list of defined bots in the “bot_defs” WAF policy file. For more
information, see “Bot Check” on page 120.
4. Select the URL Check checkbox to prevent users from accessing the URLs of your web-
site directly. The URL Check allows users to only access web pages by clicking a hyperlink
on your protected website. In the current release, the approved URL path list for the URL
Check can be configured only using Learning Mode. For a deployment example that
includes configuration of the URL Check, see “Generate Allowed URL Paths for the URL
Check” on page 141.
5. Select the HTTP Check checkbox to check that user requests are compliant with HTTP
protocols.
6. Select the Referer Check checkbox to enable referer checks, or clear the checkbox to
disable. The referer check validates that the referer header in a request contains web form
data from the specified web server, rather than from an outside website, and helps protect
against CSRF attacks. Referer Check behavior is as follows:
• Enabled – When enabled, the WAF always validates the referer header. Requests will
fail the check if there is no referer header or if the referer header is not valid.
• Disabled – The WAF will not validate requests based on the referer header.
65
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure a WAF Template
a. Select the Only If Present checkbox to display the Allowed Referer Domains
field. Then enter the fully-qualified domain names (FQDNs) from which requests are
allowed to originate.
b. In the Referer safe URL field, enter the URL for redirected requests that do not come
from the allowed referer domains.
7. Select the URI Black List Check checkbox to enable. Select the WAF Black List File
drop-down menu that appears, and select the name of a configured WAF policy file. This
option enforces the rules contained within a WAF policy file for the URI blacklist.The default
WAF policy file is “uri_blist_defs”. For more information about URI blacklists, see “URI Black
List” on page 121.
8. Select the URI White List Check checkbox to enable. Click the WAF White List File
drop-down menu that appears, and select the name of a configured WAF policy file. This
option enforces the rules contained within a WAF policy file for the URI whitelist. The default
WAF policy file is “uri_wlist_defs”. For more information about URI whitelists, see “URI White
List” on page 122.
9. When finished, click Create to save your changes.
66
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure a WAF Template
1. Select the HTML Request Checks tab to display the list of security options that can be
used to determine how the WAF will handle HTML requests from the client. A window similar
to that shown below appears.
2. Select the Decode Entities checkbox to decode entities, such as < &#xx; &#ddd; &xXX
in an internal URL.
3. Select the Decode Escaped Characters checkbox to decode escape characters, such
as \r \n \"\xXX in internal URLs.
4. Select the Decode HEX Characters checkbox to decode hexadecimal characters, such
as \%xx and \%u00yy in an internal URL.
5. Select the Remove Comments checkbox to remove comments from an internal URL.
6. Select the Remove Self-References checkbox to remove self-references, such as /./
and /path/../ from internal URLs.
7. Select the Remove Spaces checkbox to remove spaces from an internal URL.
8. When finished, click Create to save your changes.
67
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure a WAF Template
1. Select the Injection Checks tab to display the list of security options that can be used to
determine how the WAF will handle requests that do not pass the SQL injection attacks
check.
A window similar to that shown below appears.
2. In the SQL Injection Attack Check radio button, specify whether the WAF will Sani-
tize or Reject requests that do not pass the SQL Injection Attack check. This option is
used to check for harmful SQL strings and protects against SQL injection attacks.
• Selecting Reject will deny the user request.
• Selecting Sanitize will forward the request to the web server after removing the
offending SQL strings from the message.
3. Selecting either of the above radio buttons displays the SQL Injection Attack Policy
File drop-down menu. Click this drop-down and select the policy file that will be used to
perform SQL Injection Attack checks. By default, the WAF uses the list of defined SQL com-
mands in the “sqlia_defs” WAF policy file. For more information, see “SQL Injection Attack
Check” on page 120.
4. Select the XML Validation – SQL Injection Attack Check checkbox to check XML
data against the SQLIA policy file. The WAF examine the headers and bodies of incoming
requests for inappropriate SQL special characters or keywords that might indicate the pres-
ence of an SQL Injection Attack (See “XML SQL Injection Checks” on page 33 for details.)
5. When finished, click Create to save your changes.
68
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure a WAF Template
1. Select the Overflow Checks tab to display the list of security options that can be used to
determine how the WAF will handle requests that do may be attempting to flood the
resources with excessive request parameters.
A window similar to that shown below appears.
2. Clear the Disable Buffer Overflow Protection checkbox to display the buffer over-
flow protection options. These options protect against attempts to cause a buffer overflow
on the web server.
3. In the Max Cookie Length field, enter the maximum length for cookies, cookie names,
and/or cookie values allowed in a request.
4. In the Max Total Cookies Length field, enter the maximum total length for all cookies in
a request.
5. In the Max Cookie Name Length field, enter the maximum length for cookie names
allowed in a request.
69
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure a WAF Template
6. In the Max Cookie Value Length field, enter the maximum cookie value length for
cookie values allowed in a request.
7. In the Max Data to Parse field, enter the maximum amount of data that can be parsed in
a request.
8. In the Max Request Headers Length field, enter the maximum header length for head-
ers, header names, and/or header values allowed in requests.
9. In the Max Request Header Name Length field, enter the maximum header length for
header names allowed in requests.
10.In the Max Request Header Value Length field, enter the maximum header length for
header values allowed in requests.
11. In the Max URL Length field, enter the maximum URL length allowed in requests.
12. In the Max Request Line Length field, enter the maximum length for lines allowed in
requests.
13. In the Max Query Length field, enter the maximum length for queries allowed in
requests.
14.In the Max Post Size field, enter the maximum content length allowed in HTTP POST
requests.
15. In the Max HTML Parameter Name Length field, enter the maximum HTML parameter
length allowed for the parameter names.
16.In the Max HTML Parameter Value Length field, enter the maximum HTML parameter
length allowed for the parameter values.
17. In the Max HTML Parameter Total Length field, enter the maximum HTML parameter
length allowed for the total parameters.
18.In the Max MIME entities allowed field, enter the maximum number of MIME entities
allowed in the request.
19. In the Max Cookies field, enter the maximum number of cookies allowed in a request. You
can set a number ranging from 0–63. The default value is 20.
20.In the Max Headers field, enter the maximum number of header fields that are allowed in
a request. You can set a number ranging from 0–255. The default value is 20.
21. In the Max HTML Parameters field, enter the maximum number of HTML parameters
that are allowed in a request. You can set a number ranging from 0–1024. The default value
is 64.
22.When finished, click Create to save your changes.
70
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure a WAF Template
1. Select the Session Checks tab to display the list of security options that can be used to
enable session checks.
A window similar to that shown below appears.
2. Select the Session Check checkbox to enable session checks. When this option is
enabled, the WAF creates a unique ID that is inserted into a cookie and embedded in the
server’s response to the client. Future requests from the same client are validated against
this ID, and if the tracking ID (or IP address) does not match, then the request is rejected.
3. In the Session Check Lifetime field, enter a value ranging from 1–1440 minutes. The
default session lifetime is 10 minutes. For more information about Session Checks, see
“Session Checks” on page 20.
4. When finished, click Create to save your changes.
71
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure a WAF Template
1. Select the Web Services Checks tab to display the list of security options that can be
used to configure JSON and XML checks. A window similar to that shown below appears.
2. Select the Enforce JSON compliance checkbox if you wish to have the WAF scrub
incoming requests containing JSON code to verify compliance with RFC 4627. Requests will
be blocked if the JSON content is not well- formed.
3. The XSS Check uses “jscript_defs” WAF policy file to examine the content of URL, cook-
ies, and POST bodies of client requests. By default, the radio button is disabled, but you can
select one of the following actions:
• Sanitize – select this to remove the XSS script from the message and forward the
message to the web server.
• Reject – select this to deny the request.
72
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure a WAF Template
4. Select the XSS Check Policy File from the drop-down menu. By default, the XSS Check
uses the list of defined Javascript commands from the “jscript_defs” WAF policy file. (See
“XSS Check” on page 120.)
73
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure a WAF Template
JSON Limits:
When the following JSON Limit options are configured, the WAF JSON parser will enforce
parsing limits to protect backend servers from denial-of-service (DoS) attacks that are
designed to exhaust system memory or CPU resources.
5. In the JSON Limit - Max Array Value Count field, enter the maximum number of val-
ues in a single array.
The default value is 256, but you can set a number ranging from 0–4096.
6. In the JSON Limit - Max Depth field, enter the maximum recursion depth in a JSON
value.
The default value is 16, but you can set a number ranging from 0–4096.
7. In the JSON Limit - Max Object Member Count field, enter the maximum number of
members in a JSON object.
The default value is 256, but you can set a number ranging from 0–4096.
8. In the JSON Limit - Max String field, enter the maximum length of a string (in bytes) for
a name or a value in a JSON request.
The default value is 64, but you can set a number ranging from 0–4096.
9. Select the XML XSS Check checkbox to check XML data against the XSS policy file. The
XML cross-site scripting check examines the headers and bodies of incoming XML requests
for Javascript keywords that might indicate possible cross-site scripting attacks and blocks
those requests. (See “XML Cross-Site Scripting Checks” on page 32 for details.)
10.Select the XML Format Check checkbox to check the HTTP body of the message for
XML format compliance. Incoming requests containing XML code are checked for compli-
ance with the XML 1.0 specification. (See “XML Format Checks” on page 27 for details.)
11. In the XML Limit - Max Attributes field, enter the maximum number of attributes each
individual element is allowed to have.
The default is 256, but you can enter an integer from 0-256.
12. In the XML Limit - Attribute Max Length field, enter the maximum number of charac-
ters allowed per element.
The default is 128, but you can enter an integer from 0-2048.
13. In the XML Limit - Attribute Text Max Length field, enter the maximum number of
characters allowed per attribute.
The default is 128, but you can enter an integer from 0-4096.
14.In the XML Limit - CDATA Section Max Length field, enter the maximum length of
CDATA section for each element.
The default is 65535, but you can enter an integer from 0-65535.
15. In the XML Limit - Max XML Elements field, enter the maximum number of any one
type of element per XML document.
The default is 1024, but you can enter an integer from 0-8192.
74
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure a WAF Template
16.In the XML Limit - Max Element Children field, enter the maximum number of children
each element is allowed to have, including other elements, character information, and com-
ments. The default is 1024, but you can enter an integer from 0-4096.
17. In the XML Limit - Max Element Depth field, enter the maximum number of nested
levels in each element.
The default is 256, but you can enter an integer from 0-4096.
18.In the XML Limit - Max Element Name Length field, enter the maximum name length
for each element, including the XML path.
The default is 128, but you can enter an integer from 0-65535.
19. In the XML Limit - Max Entity Expansions field, enter the maximum number of entity
expansions allowed.
The default is 1024, but you can enter an integer from 0-1024.
20.In the XML Limit - Max Entity Nested Depth field, enter the maximum depth of
nested entity expansions.
The default is 32, but you can enter an integer from 0-32.
21. In the XML Limit - Max Namespace Declarations field, enter the maximum number
of namespace declarations in an XML document. The default is 16, but you can enter an
integer from 0-256.
22.In the XML Limit - Max Namespace URI Length field, enter the maximum URI length
allowed for each namespace declaration.
The default is 256, but you can enter an integer from 0-1024.
23.Select the checkbox for XML Validation - WSDL File - Resp Val if you want the WAF
to validate SOAP messages from a protected web application server using a Web Services
Description Language (WSDL) document.
• If you selected the checkbox, select the desired file from the XML Validation - WSDL
File - Resp Val drop-down menu.
• If you cleared the checkbox clear (default), optionally select the XML Validation -
WSDL File from the drop-down menu.
24.Select the checkbox for XML Validation - XML-Schema file - Resp Val if you want
the WAF to validate SOAP messages from a protected web application server using an XML
Schema file.
• If you selected the checkbox, select the desired file from the XML Validation - XML-
Schema file - Resp Val drop-down menu.
• If you cleared the checkbox clear (default), optionally select the XML Validation -
XML-Schema file from the drop-down menu.
25.Select the Enforce SOAP compliance on XML checkbox to check XML documents for
SOAP format compliance. The WAF blocks those which are not well-formed. SOAP format
checks are typically done in tandem with XML format checks. See “WAF SOAP Checks” on
page 34 for details.
26.When finished, click Create to save your changes.
75
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure a WAF Template
1. Select the Cookie Encryption Checks tab to display the list of security options that can
be used to prevent cookie tampering.
A window similar to that shown below appears.
2. In the Cookie Name field, enter the name of a cookie or PCRE expression. This option pro-
tect against cookie tampering by encrypting cookies by a specific name or for all cookies
that match a PCRE expression.
3. In the Cookie Encryption Secret field, enter a string which will be used to encrypt and
decrypt the cookies. The encryption uses a secret passphrase to decrypt and encrypt cook-
ies that are transferred between the web server and client.
4. When finished, click Create to save your changes.
76
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure a WAF Template
1. Select the Server Filter Checks tab to display the list of security options that can be
used to block or prevent the outbound responses from web server to client. A window simi-
lar to that shown below appears.
2. Select the Filter Response Headers checkbox to remove the web server’s identifying
headers in outgoing responses.
3. Select the Hide Response Codes checkbox to enable this option to cloak 4xx and 5xx
response codes for outbound responses from the web server. By default, this check uses
the “allowed_resp_codes” WAF policy file for a list of acceptable HTTP response codes. How-
ever, you can click the Hide Response Codes file drop-down menu that appears to
specify a different file. For more information, see “Allowed HTTP Response Codes” on
page 123.
4. Select the Redirect Whitelist checkbox to enable protection against unvalidated redi-
rects, which can occur if a hacker uses social networking to trick unsuspecting users into
clicking on a malicious hyperlink. The WAF must be deployed in Learning Mode when the
redirect-wlist CLI command is used for the first time so the list of acceptable locations can
be built up. The WAF pre-learns a white-list of acceptable locations to which users can
safely be redirected. If one of the web servers gets hacked and attempts to redirect a user
to a location that does not appear in the redirect white-list, then the WAF blocks the redi-
rect. See “Open Redirect Mitigation” on page 22 for details.
5. When finished, click Create to save your changes.
77
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure a WAF Template
1. Select the Content Filter Checks tab to display the configurable content filtering
options.
A window similar to that shown below appears.
2. Select the CCN Mask checkbox if you want the WAF to examine strings of outbound
replies from the web server for patterns of numerical characters that resemble credit card
numbers (CCN). If the WAF identifies a credit card number, the WAF replaces all but the last
four digits of credit card numbers with “x” characters.
NOTE: From the CLI, you can view counters for the CCN check. These
counters display the number of masked credit card numbers for
various bank providers.
3. Select the SSN Mask checkbox if you want the WAF to scan HTTP responses for strings
that resemble US Social Security numbers and masks all but the last four digits of the string
with “x” characters in a response.
4. The PCRE Mask hides strings that match the specified PCRE pattern. (See “Writing PCRE
Expressions” on page 126 for details.) In the PCRE fields, enter the following values:
• PCRE Pattern – Masks patterns in a response that match the specified PCRE pattern.
• PCRE Mask Character – Selects a character to masked the matched pattern of a string.
By default, strings are masked with an “X” character.
78
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure a WAF Template
• PCRE Keep Start – Sets the number of unmasked characters at the beginning of the
string. This can be 0-65535, the default is 0.
• PCRE Keep End – Sets the number of unmasked characters at the end of the string. This
can be 0-65535, the default is 0.
NOTE: You can configure PCRE patterns to match only on string of fixed
length. For this reason, wild-card characters that can mask exces-
sively long strings (* and +) are not supported.
If either the asterisk (*) or plus symbol (+) is detected during the syntax check, the
syntax check will automatically fail. To use an expression that matches an actual
“*” or “+” character, use an escape character (\) before the matched symbol. For
example, to search for the actual asterisk (*) or plus character (+), enter “\*” or
“\+”.
1. Select the Form Checks tab to display the list of security options that can be used to
configure web form options. A window similar to that shown below appears.
2. Select the Deny Forms Not Using POST checkbox to deny HTTP requests containing
forms if the method used is anything other than POST.
3. Select the CSRF Check checkbox to tag the fields of a web form with a nonce (a unique
FormID). This check protects against cross-site request forgery (CSRF).
79
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure a WAF Template
4. Select the Form Consistency Check checkbox to check that the user input to a web
form field conforms to the intended format for that entry. For example, it checks that a
radio button is selected versus supplying a string for that form field. WAF also parses HTTP
bodies encoded as multipart/form-data. Extracted form fields are verified against previ-
ously parsed HTML forms.
5. Select the Deny non-SSL Forms checkbox to deny user passwords sent over a non-
encrypted connection. If the connection between the client and the WAF is secured with
SSL/TLS, the user password is allowed, but if the client attempts to submit to a form field
where “input type=password”, and if the connection is not encrypted with SSL/TLS, the
WAF blocks the transmission. (For more information, see “Deny Passwords Sent Over an
Unencrypted Connection” on page 21.)
6. Select the Deny Caching of Form Responses checkbox to add “no-cache directives”
when the HTTP response contains <form> tags. “no-cache” behavior is enforced by adding
these headers: (1) Cache-Control: no-cache, no-store, must-revalidate, (2) Pragma: no-
cache, (3) Expires: 0
7. When finished, click Create to save your changes.
1. Select the Password Checks tab to display the security options related to password
options.
A window similar to that shown below appears.
2. Select the Deny non-masked password fields checkbox to prevent “shoulder surfing”
by denying the web server’s attempt to send a form through the WAF unless the field type
for the password field has been set to “password”. (See “Deny Unmasked Passwords” on
page 20.)
80
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure a WAF Template
3. Select the Deny Autocompleted Passwords checkbox to deny web server attempts
to transmit the form if one of the form fields type is set to “password” and if the “autocom-
plete=on/off” attribute is set to “on”. Enabling this option blocks browser “autocomplete”
behavior. Although convenient for users, password auto-completion weakens security by
allowing browsers to store user passwords in order to later guess the user’s password for
some websites. (For more information, see “Deny Passwords if Autocomplete is Enabled” on
page 22.)
4. Select the Deny non-SSL Passwords checkbox to deny HTTP requests containing
forms if the transmission protocol used is anything other than SSL (TLS).
5. When finished, click Create to save your changes.
81
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Create a WAF File
3. Enter a value in the Max Filesize field. Enter a value from 16–256 (KBytes). The default
value is 32Kb.
4. Click Create to create a new WAF Policy.
5. Select the one of the following tabs:
• WAF Policies – see “WAF Policy Files” on page 119 for background information.
The WAF Policy table lists the default policy files, such as “bot_defs”, “jscript_defs”, and
“sqlia_defs”. If the Bot Checks, Cross-Site Scripting (XSS) Check, or SQL Injection
Checks are enabled in a WAF template, the policy files can be used to scrub incoming
requests. For example, if the Bot Check option is enabled in the WAF template and a
82
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Create a WAF File
match is found on an incoming request (using the “bot_defs” file), the request we be
denied automatically. You can copy the “bot_defs” file and modify the contents to
include or remove bot search terms. Simply click the Edit link, make changes, and save
the new copy.
To configure, click the Create button in the WAF Policy section. A window similar to that
shown in Figure 23 on page 82 appears.
~ If selecting the Local radio button, then enter the name and definition, and then click
Create.
~ If selecting the Remote radio button, enter the name, transport protocol (e.g., TFTP,
FTP, SCP, SFTP), Host IP/FQDN, Port, Location, and user credentials (user/password) for
the server where the file is located. Then click Create.
• XML Schemas – see “WAF XML Checks” on page 26 for background information.
To configure, click the Create button in the XML Schemas section.
~ If selecting the Local radio button, then enter the name and definition, and click Create.
~ If selecting the Remote radio button, enter the name, transport protocol, Host IP/FQDN,
and path to the file. Then click Create.
• SOAP WSDLs – see “WAF SOAP Checks” on page 34 for background information.
To configure, click the Create button in the SOAP WSDL section.
~ If selecting the Local radio button, then enter the name and definition, and then click
Create.
~ If selecting the Remote radio button, enter the name, transport protocol (e.g., TFTP,
FTP, SCP, SFTP), Host IP/FQDN, Port, Location, and option credentials (user/password)
for the server where the file is located. Then click Create.
83
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Create a WAF File
FIGURE 24: WAF > Files > (WAF Policy/XML Scheme/SOAP WSDL) > Create
84
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure an HTTP Policy Template
For a general discussion of configuring an HTTP Policy Template, see “Overriding a WAF
Template” on page 131.
4. The Name field is not editable, since this example show how to update an existing HTTP
policy template.
5. In the Cookie Name field, enter the cookie name associated with this HTTP Policy.
6. In the Match Rules section of the window, click the Add button.
The Add HTTP Policy Match Rule window appears, similar to that shown below:
85
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure an HTTP Policy Template
Configure rules that match on URLs, hostnames, or cookie names. Client requests that
match a rule in the HTTP policy template are handled using the alternative WAF template
that you will later bind to the HTTP policy template.
7. To configure rules for matching:
a. Click the Type drop-down list and select one of the follow rule types:
• URL
• Host
• Cookie Name
a. Click the Match Type drop-down list and select the match operation:
• Starts With
• Ends With
• Contains
• Equals
b. In the Match field, enter the match pattern.
• Equals string – matches only if the URL, hostname, or cookie name completely
matches the specified string.
• Starts-with string – matches only if the URL, hostname, or cookie name starts with
the specified string.
• Contains string – matches if the string appears anywhere within the URL, hostname,
or cookie name.
• Ends-with string – matches only if the URL, hostname, or cookie name ends with the
specified string.
These match options are always applied in the order shown above, regardless of the
order in which the rules appear in the configuration. The WAF template associated with
the rule that matches first is used.
86
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure an HTTP Policy Template
If a template has more than one rule with the same match option (equals, starts-with,
contains, or ends-with) and a URL matches on more than one of them, the most-specific
match is always used.
c. From the Service Group drop-down menu, select the desired drop-down menu that
you wish to associate with this match rule.
d. From the WAF drop-down menu, select the WAF template to which to bind this HTTP
policy template. The WAF template you select will be used for traffic that matches the
rule.
e. Click the Add button.
f. Repeat this process for each rule you wish to add to the HTTP Policy.
8. Click the Add button to save your changes.
9. In the Geo Location Matches section of the window, click the Add button.
The Add HTTP Policy Geo Location Match Rule window appears, similar to that shown
below:
10.Enter the Geo Location. (See “Geo-location Based Blocking” on page 39 for more informa-
tion.)
11. From the Service Group drop-down menu, select the desired drop-down menu that you
wish to associate with this match rule.
12. From the WAF drop-down menu, select the WAF template to which to bind this HTTP policy
template. The WAF template you select will be used for geo-location traffic that matches
the rule.
13. Click the Add button to save your changes.
87
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Reporting
WAF Reporting
ACOS offers a reporting feature that allows you to view WAF statistics through the web GUI.
Currently, this information can be displayed using the following WAF report types:
• Top URL – indicates the most frequently accessed URLs during a specified time inter-
val.
• Top Violation – indicates the most common WAF violations that occurred during a
specified time interval. This report provides information similar to the violations listed
under the Global Stats page, such as SQL Injection Attacks and Buffer Overflows.
• Top Attacker – indicates source IP where most attacks originate during a specified
interval.
WAF Reporting provides complex information in a visual format, making it easier to see, for
example, the types of attacks that might be occurring, when they occurred, how long they
lasted, and the size or magnitude of the attack. Similarly, WAF Reporting can show you which
URLs are being accessed on your network and the times of day this is happening.
88
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Reporting
FIGURE 28: WAF > Reporting (Top 10 URLs over Last Day)
3. Click the Report Type drop-down menu and select one of the following menu items: Top
URL, Top Violation, or Top Attacker.
4. In the Top N field, enter a number between 1and 20. Example: 10 results in a “Top 10”
report.
5. Click the Time Interval drop-down menu and select one of the following tabs:
• Last Hour
• Last Day
• Last Week
• Last Month
• Last Year
• Select Period – specify the Unit (Minute, Hour, Day, Week, Month) and then enter the
Period.
• Select Date Time – enter Start and End Times by selecting a date from the calendar win-
dow.
The granularity of the history shown in a WAF report varies depending on the time interval
specified. Reports with shorter durations, (for example, the Last Day) will include more
granular information than reports that are spread out over a month.
6. Click the Apply button to generate your desired chart/graph.
89
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Reporting
A window similar to that shown in Figure 28 appears. This example displays the Top 10 Vio-
lations.
Details:
• The figure above shows a WAF Report for the Top 10 Violations during the last week. The
most common violation
(URI While List Failure) appears at the top of the chart, and the second most common
violation (Response Headers Filtered), appears in the second position from the top of the
chart, and so on.
• The horizontal axis shows Date Time, and the vertical axis is used to show the Count.
• The blue dots represent the number of times a particular violation occurred during the
time interval. In this example, a blue dot appears every hour.
• You can optionally click the green Show Charts button (at upper right) to toggle between
showing and hiding the charts.
7. (Optional) To see where attacks are coming from, you can select Top Attacker from the
Report Type, and click Apply to generate the desired chart.
A window similar to that shown in Figure 30 appears. In this example, the Top 10 Attackers
are shown. However, in this particular example, the attacks are all coming from one hypo-
thetical source IP address: 172.128.9.154.
90
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure External Logging (recommended)
FIGURE 30: WAF Report with Top 10 Attackers During Last Day
Logging of WAF events to external logging servers is supported over TCP or UDP, although UDP
is typically used for Syslog.
You can configure logging to a single server or a group of servers. If you use a group of servers,
ACOS balances the log traffic among the servers for optimal efficiency.
Configuration Overview
1. Create a server configuration for each log server. On each server, add a UDP port with the
port number on which the log server listens for log messages. (While either TCP or UDP
would work, Syslog typically uses UDP.)
2. Add the log servers to a service group. Make sure to use the round-robin load-balancing
method. (This is the default method.)
3. (Optional) If logging over TCP, configure a TCP-proxy template to customize TCP settings
for connections between ACOS and the log servers. For example, you can enable use of
keepalive probes to ensure that the TCP connections with the log servers remain estab-
lished during idle periods between logs.
4. Configure a logging template. Add the service group containing the log servers to the log-
ging template. If you configure a custom TCP-proxy template, also add that template to the
logging template.
91
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure External Logging (recommended)
External logging is activated once you bind the WAF template to a virtual port.
4. In the Name field, enter a name for the external log server.
5. In the Type radio button, select the IP version, IPv4, IPv6, or FQDN.
6. In the Host field, enter the server’s IP address or FQDN.
7. In the Port section of the window, configure the protocol port information:
a. Click the Create button.
b. Enter the following:
92
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure External Logging (recommended)
• Port Number – enter the port number in this field (514, which is the default for Sys-
log)
• Protocol – click the drop-down and select UDP protocol for this port.
• Range – enter the range of port values
• Health Check – select one of the radio buttons for Default, Disable, Monitor,
Follow Port
• Connection Limit – enter a value ranging from 1-8000000.
• Select the No Logging checkbox.
• Click Create. The port appears in the list of ports for this server.
8. Click Create again. The server appears in the list of servers.
9. Repeat this process to add additional servers, as needed.
93
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure External Logging (recommended)
6. Click the Algorithm drop-down and select the desired load balancing algorithm (e.g.,
Round Robin, Least Connection).
7. If desired, select the Health Check Disable checkbox, or if health checks are desired,
then select one from the Health Monitor drop-down menu.
8. In the Member section, click Create to add the server.
A window similar to that shown below appears:
a. For the desired Choose creation type radio button, select Existing Server.
b. Click the Server drop-down list and select the server(s) you just created in “Configure
Log Servers” on page 92.
c. Enter 514 in the Port field, since we are using Syslog. (Use the same number as speci-
fied in the server config.)
d. In the Priority field, enter an appropriate value from 1-16.
Assign a higher priority number to the primary servers, and assign lower numbers for the
servers that will be used as backups. By default, the ACOS device will not use the lower-
priority backup servers unless all of the primary servers are down. The same priority
number should be used for all the primary servers, but keep in mind that assigning the
same priority value to the primary servers will cause the logs to be load balanced across
the primary servers, and will NOT cause duplicate copies of the logs to be sent to multiple
primary servers. For a detailed discussion and background information on how Priority
works, please see the “Priority Affinity” chapter in the Application Delivery Controller
Guide.
e. (Optional) Click the Template drop-down and select an HTTP template.
f. Click the State drop-down menu and select Enable or Disable to decide if the server
will be active or not.
94
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Configure External Logging (recommended)
g. (Optional) You can select Stats Data Disable checkbox if you wish to disable statisti-
cal data collection for system resources, such as CPU, memory, disk, or interfaces.
h. Click Create button.
i. Repeat these steps for each server you wish to add to this service group.
95
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure External Logging (recommended)
9. If you configured a custom TCP-proxy template for logging over TCP, select the template
from the drop-down.
10.Click the OK button.
96
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
The WAF operates on traffic that is addressed to the virtual IP address (VIP) and HTTP/HTTPS
virtual port of your website. To apply WAF protection to the virtual port, basic configuration is
required. Additional, advanced configuration is optional.
This chapter describes how to configure the WAF using the command-line interface (CLI).
Required Configuration
The minimum required configuration for the WAF consists of the following tasks:
To create or modify a WAF template, use this command at the global configuration level of the
CLI:
For the template-name option, enter the name of an existing WAF template to modify the
template’s configuration, or an unused name to create a new WAF template. This command
enters the CLI configuration level for the template.
97
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Required Configuration
If you plan to use all the default settings for the template (including Active Mode operation) no
further template configuration is required. To customize template settings, see “Optional
Configuration” on page 101.
98
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
External Logging Configuration
The WAF template goes into operation after you bind the template to an HTTP/HTTPS port.
To bind a template to a virtual port, you must access the configuration level for the port.
1. From the global configuration level of the CLI, use the following command to access the
configuration level for the virtual server that will receive HTTP/HTTPS traffic to be secured
using the WAF:
slb virtual-server name ipaddr
2. At the configuration level for the virtual server, use the following command to access the
configuration level for the virtual port:
port port-number {http | https}
3. At the configuration level for the virtual port, use the following command to bind the WAF
template to the port:
template waf template-name
1. Create a server configuration for each log server. Add a TCP or UDP port to each server
configuration, with the port number on which the external log server listens for log mes-
sages.
a. Use the following command to add a server and access the configuration level for it:
slb server server-name ipaddr
b. Use the following command to add a TCP or UDP port to the server. Specify the port
number on which the server will listen for log traffic.
port port-num {tcp | udp}
2. Add the log servers to a service group. Make sure to use the round-robin load-balancing
method. (This is the default method.)
a. Use the following command to add the service group and access the configuration level
for it:
slb service-group group-name {tcp | udp}
99
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
External Logging Configuration
b. Use the following command to add each log server and its TCP or UDP port to the group:
member server-name portnum
100
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Optional Configuration
3. (TCP only) If logging over TCP, configure a TCP-proxy template to customize TCP settings
for connections to log servers. For example, you can enable use of keepalive probes, to
ensure that the TCP connections with the log servers remain established during idle periods
between logs.
a. Use the following command to create the TCP-proxy template and access the configu-
ration level for it:
slb template tcp-proxy template-name
b. Use the following command to add the service group containing the log servers to the
logging template:
service-group group-name
c. If you configured a TCP-proxy template, use the following command to add that tem-
plate to the logging template:
template tcp-proxy template-name
b. Use the following command to bind the logging template to the WAF template:
template logging template-name
NOTE: External logging is activated once you bind the WAF template that
uses the logging template to an HTTP/HTTPS virtual port.
Optional Configuration
This section provides syntax for the following WAF configuration options:
• Deployment mode
• Request checks
• Deny action (WAF response sent to client when a request is denied by the WAF)
101
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Optional Configuration
• Response checks
The default operational mode for WAF is active. To change the operational mode, use the
following command at the configuration level for the WAF template:
• active – The WAF enforces the security checks configured on the template and sends
events to the external log server.
• passive– The WAF sends events to the external log server only and does not enforce any
security checks.
• learning – The WAF template “learns” acceptable check parameters based on a stream of
legitimate, secure traffic. In Learning Mode, the WAF continues to send events to the
external log server.
The WAF is pre-loaded with a set of default policy files which are used for certain security
checks. For example, if you enable bot checking with the WAF template, the default “bots_def”
WAF policy file is used for a list of known bot names. (See “Bot Check” on page 120.)
Optionally, you can customize WAF policy files and apply these files to security checks. For
example, you can copy the default bots policy file, modify and import the copied file, then
update the corresponding WAF template option to use the custom policy file.
102
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Optional Configuration
To configure individual WAF security checks for requests, use the following commands:
103
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Optional Configuration
• http-resp-403 resp-string – Sends a 403 Forbidden response to the client. The default
string returns a generic “Request Denied!” page to the client.
• http-resp-200 resp-string– Sends a 200 OK response to the client with the specified
resp-string. The default string returns a generic “Request Denied!” page to the client.
• http-redirect url-string – Sends a 302 Found redirection address to the client with the
URL specified in the redirect-url.
• reset-conn – Terminates the client connection.
• deny-non-masked-passwords – Prevents “shoulder surfing” by denying the web server’s
attempt to send a form through the WAF unless the field type for the password field has
been set to “password”. See “Deny Unmasked Passwords” on page 20.
• deny-non-ssl-passwords – Denies user passwords that are sent over a non-encrypted
connection. If the connection between the client and the WAF is secured with SSL/TLS,
then the user password is allowed, but if the client attempts to submit to a form field
where “input type=password”, and if the connection is not encrypted with SSL/TLS, then
the WAF blocks the transmission. The feature is disabled by default, meaning that forms
not using the SSL/TLS protocol will not be denied. See “Deny Passwords Sent Over an
Unencrypted Connection” on page 21.
• deny-password-autocomplete – Denies web server attempts to transmit the form if one of
the form fields type is set to “password” and if the “autocomplete=on/off” attribute is set
to “on”. Enabling this option blocks browser “autocomplete” behavior. Although conve-
nient for users, password auto-completion weakens security by allowing browsers to
store user passwords in order to later guess the user’s password for some websites. See
“Deny Passwords if Autocomplete is Enabled” on page 22.
• form-consistency-check – Use this command to check that the user input to a form field
conforms to the form field tag. WAF also parses HTTP bodies encoded as multipart/form-
data. Extracted form fields are verified against previously parsed HTML forms.
• form-deny-non-post – Deny request with forms if the method is not POST.
• http-check – Use this command to check that user requests are compliant with HTTP
protocols.
• json-format-check – Checks that incoming requests containing JSON code are in compli-
ance with RFC 4627, and blocks requests if the JSON content is not well- formed.
• json-limit – Enforces parsing limits to protect backend servers against various types of
denial-of-service (DoS) attacks, which are designed to exhaust system memory or CPU
resources.
• max-array-value-count num – Limits the maximum number of values within a single
array.
• max-depth num – Limits the maximum recursion depth in a JSON value.
104
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Optional Configuration
• max-entities num – Specifies the maximum number of MIME entities allowed in request.
105
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Optional Configuration
• uri-wlist-check file-name – Enforces the rules contained within a WAF policy file for the
URI White List. For more information, see “URI White List” on page 122.
• url-check – The URL Check allows users to access web pages only by clicking hyperlinks
on your protected website, as opposed to allowing users to access hidden web pages by
typing the full URL in the browser. Select this option to prevent users from manually typ-
ing the URL for content on your website that you do not want accessible.
The list of approved URL paths is initially generated as a policy file during Learning Mode.
After this list is generated, you can customize the contents of the URL Check policy file.
For a deployment example that includes configuration of the URL Check, see “Generate
Allowed URL Paths for the URL Check” on page 141.
• url-options option – This command is used to normalize requested URLs.
The url-options command helps shorten URLs, thus preventing buffer overflows from long
URLs.
• decode-entities - Decode entities, such as <, in an internal URL.
• decode-escaped-chars - Decode escaped chars, such as \r or \n, in an internal URL.
• decode-hex-chars - Decode hexadecimal characters, such as \%xx and \%u00yy, in an
internal URL.
• remove-comments - Remove comments from an internal URL.
• remove-selfref - Remove self-references, such as /./ and /path/../, from an internal
URL.
• remove-spaces - Remove spaces from an internal URL.
NOTE: ACOS 4.0 does not support the ability to decode a plus symbol “+”
in the URL if it is being used to represent a space by the browsers.
• xml-format-check – Check HTTP body for XML format compliance. Incoming requests con-
taining XML code are checked for compliance with the XML 1.0 specification. (See “XML
Format Checks” on page 27 for details.)
• xml-limit – XML parsing limits. (See “XML Limit Checks” on page 30 for details.)
• max-attr num – Limits the maximum number of attributes/children each individual ele-
ment is allowed to have.
Range is 1–256. Default is 256.
• max-attr-name-len num – Limits the maximum length of each attribute name.
Range is 1–2048. Default is 128.
• max-attr-value-len num – Limits the maximum length of each attribute value.
Range is 1–2048. Default is 128.
• max-cdata-len num – Limits the length of the CDATA section for each element.
Range is 1–65535. Default is 65535.
106
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Optional Configuration
• max-elem num – Limits the maximum number of any one type of element per XML docu-
ment.
Range is 1–8192. Default is 1024.
• max-elem-child num – Limits the maximum number of children each element is allowed,
and includes other elements, character information, and comments. Range is 1–4096.
Default is 1024.
• max-elem-depth depth – Limits the maximum number of nested levels in each element.
Range is 1–4096. Default is 256.
• max-elem-name-len length – Limits the maximum length of name of each element, and
includes the XML path, which is in the following format: http://<site>/<path>/page.xml
Range is 1–65535. Default is 128.
• max-entity-exp num – Limits the number of entity expansions allowed.
Range is 0–1024. Default is 1024.
• max-entity-exp-depth num – Limits the maximum depth of nested entity expansions.
Range is 0–32. Default is 32.
• max-namespace num – Limits the number of namespace declarations in XML document.
Range is 0–256. Default is 16.
• max-namespace-uri-len num – Limits the URL length for each namespace declaration.
Range is 0–1024. Default is 256.
• xml-sqlia-check – Checks XML data against SQLIA policy. Checking for XML SQL Injection
attacks means the WAF examine the headers and bodies of incoming requests for inap-
propriate SQL special characters or keywords that might indicate the presence of an SQL
Injection Attack (See “XML SQL Injection Checks” on page 33 for details.)
• xml-validation xml-schema [resp-val] xml-schema-file-name – Checks incoming
requests against an XML schema file to validate the XML content. Used to prevent hackers
from using invalid XML messages that have been specially-constructed to evade applica-
tion security. (See “XML Validation Checks” on page 27 for details.)
• xml-xss-check – Checks XML data against XSS policy. The XML cross-site scripting check
examines the headers and bodies of incoming XML requests for Javascript keywords that
might indicate possible cross-site scripting attacks and blocks those requests. (See “XML
Cross-Site Scripting Checks” on page 32 for details.)
• xss-check {reject | sanitize} – Use this command to check for potential HTML XSS
scripts to protect against cross-site scripting attacks. This check uses the list of defined
Javascript commands in the “jscript_defs” WAF policy file. See “XSS Check” on page 120.
• reject – denies requests that contain cross-site scripting.
• sanitize – removes the detected XSS script and forwards the request to the web server.
107
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Optional Configuration
To configure individual WAF security checks for responses, use the following commands:
• ccn-mask – Use this command to examine strings of outbound replies from the web server
for patterns of numerical characters that resemble credit card numbers (CCN). If the WAF
identifies a credit card number, the WAF replaces all but the last four digits of credit card
numbers with “x” characters.
• cookie-encrypt – Use this command to encrypt specified cookies matching PCRE pattern.
Used to protect against cookie tampering by encrypting cookies before sending the server
replies to a client. (See “Cookie Encryption” on page 147.)
• filter-resp-hdrs – Use this command to removes the web server’s identifying headers in
outgoing responses.
• hide-resp-codes – Cloaks 4xx and 5xx response codes for outbound responses from the
web server.
If either the asterisk (*) or plus symbol (+) is detected during the
syntax check, the syntax check will automatically fail. To use an
expression that matches an actual “*” or “+” character, use an
escape character (\) before the matched symbol. For example, to
108
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Optional Configuration
search for the actual asterisk (*) or plus character (+), enter “\*” or
“\+”
• ssn-mask – Use this command to examine server responses for strings that resemble US
Social Security numbers and masks all but the last four digits of the string with “x” charac-
ters in a response.
109
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Optional Configuration
110
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
This chapter describes where WAF events are logged and the format used for WAF log
messages.
There is no external logging by default. To configure external logging, see either of the following
sections:
Deny actions are not written to the log. To view the configured
response to denied client requests, check the WAF template cur-
rently in use.
• Configuration events – Indicate that a configuration change has occurred. Typically, this
type of WAF event is generated when you configure WAF settings.
• Data events – Indicate that traffic has matched a WAF template check.
By default, only configuration events are logged to the local logging buffer on ACOS.
Data events are not logged by default. Due to the potentially high volume of data event
messages, they are accessible only by using remote logging servers. You can configure the WAF
to use a single logging server or a group of servers.
After enabling WAF logging to remote logging servers, WAF configuration events also are sent to
the remote servers. In this case, WAF configuration events are no longer sent to the local
logging buffer.
Figure 35 shows the WAF logging behavior without external logging. WAF configuration events
are logged locally. WAF data events are not logged.
111
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Event Types and Where They Are Logged
Figure 36 shows the WAF logging behavior after external logging is configured for the WAF
template. WAF configuration events and WAF data events both are logged to the external log
server.
112
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Log Format
Log Format
For optimal interoperability, WAF uses the Common Event Format (CEF), an open standard used
by other security appliances and network devices.
Timestamp CEF:version|device-vendor|device-product|
device-version|module|event-type|severity|CEF-extension
Table 2 describes the data fields that can appear in WAF logs
• bot-check
• buf-ovf
• ccn-mask
• cookie-encrypt
• csrf-check
• deny-action
• filter-resp-hdrs
• form-consistency-check
• hide-resp-codes
• http-check
• pcre-mask
• referer-check
• sqlia-check
• ssn-mask
• uri-blist-check
• uri-wlist-check
• url-check
• xss-check
113
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Log Examples
• 1 – Debug
• 2 – Info
• 3 – Notice
• 4 – Warning
• 5 – Error
• 6 – Critical
• 7 – Alert
• 8 – Emergency
CEF-extension Set of any number of key/value pairs, in any order, that further describe
the event that generated the log. The CEF extension for WAF uses the fol-
lowing elements:
• Bot Check
• Learning Mode
114
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Log Examples
spt=57253
dst=172.17.21.2
dpt=80
dhost= dhost=172.17.21.2
req=”/foooo/2.html?B92A9743=B6A273450A38B6
C7A4667E829B3DCB65&name=abc&age=10”
cs1=waf-csrf-check1 cs2=e133c0360150667e
act=learn
app=HTTP
requestMethod=GET
md=learn
115
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Log Examples
NOTE: For more log examples, see “WAF Deployment and Logging Exam-
ples” on page 137.
Bot Check
Here is an example of a WAF log that indicates the detection of a bad bot:
Here is the same message, formatted to more clearly show each field:
Oct 20 18:16:13
CEF:0
A10
AX3200
2.7.1
WAF
bot-check
6
src=20.20.25.10
spt=30842
dst=20.20.25.130
dpt=80
request=”GET /tours/index.html HTTP/1.1” 0
msg=”Bad bot detected! User-Agent drip”
cs1=w2
act=deny
md=nrm
This message indicates that an HTTP GET request from 20.20.25.10:30842 to VIP
20.20.25.130:80 contained a bot whose name matches a name in the bots WAF policy file. The
WAF template name is “w2”. Based on the WAF configuration, the request was denied. The WAF
is running in normal mode.
Learning Mode
Below are example log messages for when the WAF is deployed in learning mode:
116
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Log Examples
The first message indicates that WAF updated the header-length limit based on traffic observed
during Learning Mode. Likewise, the second message indicates that WAF updated the
maximum-headers limit. The act=learn field indicates that the value was learned. The md=lrn
field indicates that Learning Mode was enabled.
117
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Log Examples
118
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Policy Files (also referred to as WAF Definitions) give you the ability to define a set of rules
for customized security checks. WAF policy files enable you to specify security checks for
enhanced response- and request-side protection to protect against security risks, such as SQL
injection attacks or forceful browsing.
• XSS Check
• Bot Check
• SQLIA Check
If one of these checks is enabled and a WAF policy file is not specified, the default WAF policy file
is applied. These policy files are described in more detail below.
NOTE: You cannot rename, edit, or delete default files. However, you can
copy a default WAF policy file and customize it to fit your specific
demands.
119
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Pre-Loaded WAF Policies
Request Protection
The following checks point to WAF policy files for enhanced protection against incoming
requests. By default, these checks refer to the default WAF policy files, as described below.
Optionally, you can configure these checks to use customized policy files.
Bot Check
The WAF bot check option uses the “bot_defs” policy file for search definitions of known bot
agents. If bot checking is enabled in the WAF template and a match is found with the “bot_defs”
policy file, the request is denied automatically. You can add or modify the “bot_defs” policy file
to include or remove bot search terms.
XSS Check
The “jscript_defs” WAF policy file defines a list of common Javascript commands. The XSS
check uses this policy file for examining the content of URL, cookies, and POST bodies of client
requests. This type of policy file is useful for websites that use Javascript-based web content.
120
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Pre-Loaded WAF Policies
commands in the back-end SQL database and allow unauthorized users to obtain sensitive
information. If a request contains a term that matches a search definition in the “sqlia_defs”
policy file, you can configure the WAF to sanitize the request of the SQL command or deny the
request entirely.
The URI Black List takes priority over a URI White List. That is, even if a URI matches acceptance
criteria within the URI White List, a connection is blocked automatically if it meets a rule in the
separate URI Black List.
Table 5 lists URI Black List criteria in the default “uri_blist_defs” file.
121
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Pre-Loaded WAF Policies
Table 6 lists URI White List criteria in the default “uri_wlist_defs” file.
122
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Customize WAF Policy Files
Response Protection
This section describes policy-based security checks for outbound responses from the web
server.
123
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Customize WAF Policy Files
unless you are certain that the PCRE expression will achieve the
desired result.
You cannot remove or edit a pre-loaded WAF policy file. However, you can quickly duplicate an
existing file to an unused name and modify the contents.
The following sections describe writing PCRE patterns for customized WAF policies. ACOS
incorporates aspects of PCRE expressions for writing WAF policies, but does not support full
PCRE functionality.
Syntax Check
After the file is created or modified, a syntax check is automatically performed on the file. If you
modify a WAF policy file that is currently bound to a WAF template and the file does not pass the
syntax check, it is automatically restored to the previous version.
Files which do not pass the syntax check cannot be bound to a WAF template. A policy can fail a
syntax check for various reasons, including the following:
• Duplicate policies (more than one policy file containing the same PCRE expressions)
(a|b) – Incorrect
instead of
(?:a|b) – Correct
This section describes procedures to create, edit, or manage WAF policy files in the CLI.
For the file-name option, enter the name of an existing WAF policy file to edit the file, or an
unused name to create a new WAF policy. Do not include the “.waf” extension in the file
name, this is automatically applied during creation.
124
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Customize WAF Policy Files
The CLI enters the input mode for the policy file.
NOTE: You cannot modify default files. If you enter the name of a pre-
loaded WAF policy for file-name, the following message will dis-
play:
2. Type or copy-and-paste a collection of PCRE expressions for the file. If you type the script,
press the Enter key at the end of each line. For information about writing PCRE expressions,
see “Writing PCRE Expressions” on page 126.
3. To save the file and complete the input process, press the Escape key, type “:wq” or “ZZ”
and press Enter. Alternatively, use “:q!” to exit without saving the file.
Syntax Checks
After entering policy text, the CLI performs a syntax check and displays one of the following
messages:
Indicates a failed syntax check and reports the line (n) with invalid syntax.
Manage Files
The following commands allow you to manage WAF policy files.
Copy Files
Use the following command to copy a WAF policy to a new file name:
For the source-name option, use the name of an existing WAF policy.
For the destination-name option, enter an unused name for the copied file.
Rename Files
Delete Files
125
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Customize WAF Policy Files
You cannot rename, edit, or delete default files. However, you can copy a default WAF policy file
and customize it to fit your specific demands.
The following section provides guidelines for writing WAF policy files which the WAF can use to
search for attack patterns or define policy rules.
General Guidelines
This section summarizes common characters used in PCRE expressions and provides a quick
reference to basic PCRE syntax. To learn more about writing detailed PCRE expressions, consult
outside reference material.
Misconfigured PCRE expressions can negatively impact system performance. Do not apply a
PCRE expression to a WAF policy file unless you are certain the expression will achieve the
desired result.
126
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Customize WAF Policy Files
PCRE Characters
For example, (yellow | red | orange) will return true if either yellow, red, or orange
is found.
( Start of a sub-pattern.
) End of a sub-pattern.
* Quantifier for a value of 0 or more.
+ Quantifier for a value of 1 or more.
{ Start of a minimum or maximum quantifier.
} End of a minimum or maximum quantifier.
Enclose Patterns
You can enclose patterns with any non-alphanumeric character that is not a backslash \ or
whitespace. You can also use special symbols that may otherwise carry an alternative function
as long as the same symbol is used in the beginning and end of the string.
127
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Customize WAF Policy Files
Basic Syntax
WAF policy files consist of PCRE expressions and comment lines. Lines with PCRE expressions
are structured as follows:
name,PCRE expression
The name is a string which you can use to title the line. Follow the description with a comma “,”
before writing the PCRE expression. As shown below:
FromDefaultBlackList,^[^?]*[.]htx
Comments
To insert a comment into the policy file enter a pound character ‘#’ before the comment line.
example_expression,^[^?]*/[?]wp-
# comment
...
(# comment)
Example Applications
Outlined below are various examples of PCRE expressions.
Attack Patterns
You can create customized WAF policies with search criteria for attack
patterns.
• Use the " | " symbol as a separator in lists of elements. Traffic matches a policy rule if the
traffic matches any of the elements delimited by " | ". For example, "(apples | oranges)" is
read as a single object that can be triggered when either "apples" or "oranges" is found in
traffic.
• Use parentheses to enclose each separate element. For example, the set of elements
"(apples) (oranges)" is read by WAF as two individual objects: an "apples" object and an
"oranges" object.
128
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Customize WAF Policy Files
(builtbottough|bunnyslippers|capture|cegbfeieh|cherrypicker|cheesebot|chinaclaw|cicc|c
iva|clipping|collage|collector|copyrightcheck|cosmos|crescent|custo|cyberalert|deweb|d
iagem|digger|digimarc|diibot|directupdate|disco|dittospyder|download accelerator|down-
load demon|download wonder)
To add three additional known bots under the names “brewster”, “nook” and “peanut”, you would
modify the policy file similar to the following. The additions are indicated in bold:
(builtbottough|bunnyslippers|capture|cegbfeieh|cherrypicker|cheesebot|
chinaclaw|cicc|civa|clipping|collage|collector|brewster|nook|
copyrightcheck|cosmos|crescent|custo|cyberalert|deweb|diagem|
digger|digimarc|diibot|directupdate|disco|dittospyder|
download accelerator|download demon|download wonder|peanut)
Policy Rules
You can write WAF policy files to list more complicated policy rules. The following examples
illustrate the various rules that you can create as a PCRE expression.
The following example defines a rule for the URI Black List. The rule denies user requests to
access the image server at img.example.com directly:
^http://img[.]example[.]com$
The following example defines a rule for the URI Black List. The rule denies user requests to
access CGI (.cgi) or PERL (.pl) scripts directly:
^http://www[.]example[.]com/(?:[0-9A-Za-z][0-9A-Za-z_-]*/)*
[0-9A-Za-z][0-9A-Za-z_.-]*[.](?:cgi|pl)
The following PCRE expression looks for strings that resemble a California driver’s license ID
number. This policy rule can be used in conjunction with the PCRE mask option to mask strings
that match the expression:
[A-Za-z][0-9]{7,7}
129
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Customize WAF Policy Files
130
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
You can configure ACOS to override the WAF settings applied to the HTTP/HTTPS virtual port
with another set of WAF settings, using an HTTP policy template. You can configure rules in the
HTTP template to match on URLs, hostnames, or cookie names in traffic.
1. Configure a second WAF template with the alternative settings to use. See either of the fol-
lowing:
• Using the GUI – “Configure a WAF Template” on page 63
• Using the CLI – “Create a WAF Template” on page 97
2. Configure an HTTP policy template. Within the template:
• Configure match rules. You can match on one or more of the following:
• Requested URL
• Requested hostname
• Cookie name within request
• Add (bind) the second WAF template to the HTTP policy template.
3. Bind the HTTP policy template to the virtual port.
NOTE: For the WAF to operate, it is still required to bind a WAF template
directly to the virtual port, to use as the virtual port’s primary WAF
template. HTTP policy templates can be used only to override the
primary WAF template with secondary WAF template, based on the
match rules in the HTTP policy template.
131
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Configure an HTTP Policy Template
• Equals string – matches only if the URL, hostname, or cookie name completely matches
the specified string.
• Starts-with string – matches only if the URL, hostname, or cookie name starts with the
specified string.
• Contains string – matches if the specified string appears anywhere within the URL, host-
name, or cookie name.
• Ends-with string – matches only if the URL, hostname, or cookie name ends with the
specified string.
These match options are always applied in the order shown above, regardless of the order in
which the rules appear in the configuration. The WAF template associated with the rule that
matches first is used.
If a template has more than one rule with the same match option (equals, starts-with, contains,
or ends-with) and a URL matches on more than one of them, the most-specific match is always
used.
In addition to URLs, hostnames and cookies, HTTP policy also supports “geo-location”. Below is
an example of a geo location configuration with the assumption that waf-template-1 has been
previously configured.
132
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Bind the HTTP Policy Template to the Virtual Port
5. Configure match rules and other fields as desired; refer to the GUI online help for detailed
information about each field.
6. Click Create.
To configure an HTTP policy template, use the slb template http-policy command at the global
configuration level of the CLI. For more information about this command, refer to the Command
Line Interface Reference.
Use the GUI to Bind the HTTP Policy Template to a Virtual Port
133
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Bind the HTTP Policy Template to the Virtual Port
Use the CLI to Bind the HTTP Policy Template to a Virtual Port
To bind a template to a virtual service port, create the VIP and the port, as well as the service
group, and then enter the template waf command at the configuration level for the port. For
example:
For a complete CLI example, see “HTTP Virtual Port Configuration” on page 138.
134
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF STATISTICS
The sections of this chapter describe GUI and CLI procedures to display WAF statistics.
NOTE: Statistics counters increment from 0 after the most recent reboot
or from when the statistics were most recently cleared.
You can use the GUI to view global WAF statistics by:
From the CLI, use the show waf stats command to view statistics for a specific virtual server
and virtual port.
You can use the GUI to clear global WAF statistics by:
135
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Clearing WAF Statistics
• use the clear waf command to clear all “show waf” counters.
• use the clear waf stats command to clear statistics for a specific virtual server and virtual
port.
See “clear waf stats” on page 183 for more information about this CLI command.
136
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
This chapter provides some examples for WAF deployment. Since logging is a crucial part of
WAF configuration and management of the WAF, the examples include applicable log messages.
Initial Configuration
The commands in this example configure the following resources:
• Logging configuration
• WAF template
Logging Configuration
The commands in this section configure the resources required for external logging of WAF
events.
To begin, the following commands configure external logging for the WAF. A single log server is
used. Log messages are sent over TCP.
A TCP-proxy template is used to periodically send keepalive probes to the syslog port on the
server. The keepalive probes prevent the TCP session from aging out during periods of
inactivity.
137
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Initial Configuration
The following commands create the server configuration and add it to a TCP service group:
The following commands configure the TCP-proxy template, to enable keepalive messages:
The following commands configure the logging template. This includes binding the TCP-proxy
template to the logging template.
The following commands create a WAF template and bind the logging template to the WAF
template:
The following commands configure an HTTP virtual port and bind the WAF template to the port.
To begin, the following commands create server configurations for the web servers to be load
balanced and protected by the WAF:
138
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Learning
ACOS(config-real server)#exit
The following commands configure the virtual server and bind it to the service group and WAF
template:
Log Example
When done configuring, you can use the show log command to display log messages. These log
messages indicate whenever a WAF template is updated, created, or deleted. Hypothetical log
messages are shown below for illustration purposes.
ACOS(config:8)#show log
Log Buffer: 30000
Mar 24 2016 15:37:12 Info [WAF]:CEF:1|A10|AX3030|4.1.0|WAF|Mar 24 2016 15:37:11|con-
fig|2|msg="Template waf-check-doc: buf-ovf max-hdr-value-len set to 65535"
Mar 24 2016 15:37:12 Info [VCS]:dcs config seq number increase (45,0,652)
Mar 24 2016 15:37:04 Info [WAF]:CEF:1|A10|AX3030|4.1.0|WAF|Mar 24 2016 15:37:03|con-
fig|2|msg="Template waf-check-doc: bot-check ON (policy-file=bot_defs)"
Mar 24 2016 15:37:04 Info [VCS]:dcs config seq number increase (45,0,651)
Mar 24 2016 15:37:02 Info [WAF]:CEF:1|A10|AX3030|4.1.0|WAF|Mar 24 2016 15:37:01|con-
fig|2|msg="Template waf-check-doc created"
Mar 24 2016 15:37:02 Info [VCS]:dcs config seq number increase (45,0,650)
Mar 24 2016 15:36:42 Info [WAF]:CEF:1|A10|AX3030|4.1.0|WAF|Mar 24 2016 15:36:41|con-
fig|2|msg="Template waf-check-doc deleted"
NOTE: If external logging has not been configured for the WAF, then the
log messages will appear in the local log buffer of the ACOS device.
Learning
The commands in this section use Learning Mode to dynamically set some WAF options based
on traffic.
139
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Learning
NOTE: This example assumes that the VIP using the WAF template is not
yet receiving live traffic but is instead receiving known, valid traffic
sent in order to preset WAF parameters. The following caution
explains why.
CAUTION: While Learning or Passive Mode is in operation, the WAF does not
block any traffic. Only Active Mode blocks traffic.
The following commands access the configuration level for the WAF template, and change the
mode to Learning Mode:
Generate Traffic
On a client device, the following requests are generated and sent to the HTTP virtual port:
curl -v http://20.20.25.130/tours/index.html
curl -v http://20.20.25.130/batblue.html
curl -v http://20.20.25.130/file_set/dir00000/about.html
This message indicates that the GET method was observed in the first request sent to the HTTP
virtual port, and that the Allowed HTTP Methods list was updated with the method.
140
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Learning
An additional WAF parameter you can set during Learning Mode is the URL Check. The URL
Check prevents users from navigating directly to any URL paths other than the ones explicitly
defined by the URL Check policy file.
141
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Learning
4. After the URL Check policy file has been generated, change the WAF operational mode to
Active to enforce the URL Check on client requests.
Configuration Example
The following example outlines steps for customizing the URL Check in learning mode and
enforcing the check for your website.
1. The following commands set the WAF to learning mode and enable the URL Check option in
the WAF template:
ACOS(config)#waf template w1
ACOS(config-waf)#deploy-mode learning
Switching to learning mode will reset all WAF template parameters and may expose you
to attacks if done in a production environment.
Are you sure you wish to proceed? (N/Y): Y
ACOS(config-waf)#url-check
NOTE: In this example, the WAF template “w1” is bound to a virtual server
with the IP address 192.168.25.130.
2. Send secure traffic from a client. In this example, traffic from the client is sent to the follow-
ing addresses:
http://192.168.25.130/tours/index.html
http://192.168.25.130/batblue.html
http://192.168.25.130/file_set/dir00000/about.html
3. Check the logs on the external log server. The log should contain a message such as the
following, for each URL path requested:
Mar 24 16:34:40 CEF: 1|A10|AX3030|4.1.0|WAF|Mar 24 2016 15:46:12|session-
id|2|src=172.17.3.100 spt=55150 dst=172.17.3.61 dpt=8080 hst="172.17.3.61:8080"
cs1=waf-url-check cs2=90f0c225f82e4cb8 act=learn md=passive svc=http req="GET /
foooo/rest/upload/aaa.txt HTTP/1.1" 0 msg="New session created: Id=90f0c225f82e4cb8"
4. The log will contain similar messages for each URL path clients are allowed to access. The
following commands verify that the URL Check policy file is created and display the con-
tents of the file:
ACOS(config-waf)#show waf policy
Total WAF policy number: 14
Max WAF policy file size: 32K
Name Syntax Template
------------------------------------------------------------------------
_w1_url_check_ Check Bind
allowed_resp_codes Check Bind
bot_defs Check Bind
jscript_defs Check Bind
142
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Learning
...
In WAF Template:
w1 (for url-check)
Content:
Matches Value
--------------------------------------------------------------------------
1 /tours/
1 /batblue.html
1 /file_set/dir00000/
5. Change the WAF deployment mode. (See “Save Template Settings” on page 143.) When you
change the deployment mode from Learning Mode, ACOS writes the observed URL paths
into a policy file. The URL Check will start operating.
ACOS(config-waf)#waf template w1
ACOS(config-waf)#deploy-mode active
NOTE: In Passive Mode, requests for other URL paths still are allowed, but
they are logged. The URL path list is enforced only while the URL
Check is enabled and the WAF template is in Active Mode.
6. Optionally, edit the contents of the URL Check policy file to explicitly define acceptable URI
paths.
NOTE: The contents of the URL Check policy file are first generated in
Learning Mode. After which you can remove or define additional
URL paths in the policy file. You cannot create the URL Check pol-
icy file without first deploying a WAF template in Learning Mode
with the URL Check enabled.
To “lock down” WAF template settings configured by Learning Mode, change the mode. The
following command changes to Passive Mode:
143
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Response Header Filtering
ACOS(config-waf)#deploy-mode passive
In Passive Mode, WAF checks are performed but the filter actions are not applied. Requests to
the HTTP virtual port are logged but are sent to the server without being altered. (For more
information, see “WAF Operational Modes” on page 51.)
Here is an example of header fields in the HTTP response from a server. The fields shown in bold
provide information about the server OS.
Here is the same excerpt from the server response, with the OS-identifying headers removed:
The response received by the client does not contain the OS-identifying headers.
144
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
SQLIA Check
The following commands access the configuration level for the WAF template and enable
Header Response Filtering:
Messages in the external WAF log indicate when header fields are removed by Header Response
Filtering:
SQLIA Check
The SQLIA Check protects against SQL commands hidden in requests sent to database servers.
The check looks for SQL code in form arguments, URLs, and cookies. In general, these places are
not supposed to contain SQL code.
The following commands access the configuration level for the WAF template and enable the
SQLIA Check. In this example, the sanitize option is used. This option removes the SQL and
then forwards the request.
145
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Cross-site Scripting Check
ACOS(config-waf)#sqlia-check sanitize
The following log messages indicates that SQL was detected in a request:
The following commands access the configuration level for the WAF template and enable the
XSS Check. In this example, the reject option is used. This option logs the XSS attempt and then
drops the request instead of forwarding it to the server.
The following log message indicates that an XSS attempt was detected and denied:
146
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Cookie Encryption
Since the reject option is used in the configuration, a Deny page such as the one in “Deny page”
on page 147 is sent to the client.
Cookie Encryption
Cookie Encryption protects against cookie tampering by encrypting cookies before sending
server replies to clients.
You can enable encryption based on specific cookie names or for all cookies that match a PCRE
expression. The encryption uses a secret string to decrypt and encrypt cookies that are
transferred between the web server and client.
The following commands access the configuration level for WAF template “resetti” and
configure encryption for all cookies containing “hiddencookie” in the name:
The secret value “r0cc0” is used for encryption. To view the encrypted value created by the WAF
and used in responses, display the configuration:
147
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
Cookie Encryption
MuNXbAOc8EIy41dsA5zwQjLjV2wDn
...
148
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF templates allow you to easily enforce the following security filters.
149
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
GUI:
GUI:
150
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
GUI:
URI Black List Enforces the rules contained within a WAF Name of a WAF policy file
policy file for the URI Black List. For more
information about URI Black Lists, see “URI Default: uri_blist_defs
Black List” on page 121.
GUI:
Deny Action WAF response sent to the client if traffic is One of the following:
denied by the WAF template.
• http-resp-403 – Sends a 403 For-
[no] deny-action options bidden response to the client. The
resp-string default string returns a generic
“Request Denied!” page to the cli-
ent.
GUI: • http-resp-200 – Sends a 200 OK
response to the client with the
Security > WAF > WAF Templates specified resp-string. The default
> Create , and then select the General string returns a generic “Request
Denied!” page to the client.
tab, and select the Deny Action drop-
• http-redirect – Redirects the cli-
down. ent to the specified URL.
• reset-conn – Sends a TCP RST to
the client to end the connection.
Default: http-resp-403
151
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
GUI:
152
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
[no] max-parameters
GUI:
153
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
GUI:
Form Checks that user input to form fields is con- Enabled or Disabled
Consistency sistent with the intended format.
Check Default: Disabled
[no] form-consistency-check
GUI:
HTTP Check Checks that user requests are compliant Enabled or Disabled
with HTTP protocols.
Default: Disabled
[no] http-check
GUI:
154
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
GUI:
GUI:
GUI:
155
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
GUI:
Referer Check Validates that the referer header in a One of the following:
request contains web form data from the
specified web server, rather than from an • Enabled
outside website. This check protects against • Disabled
CSRF attacks. • Only-If-Present
• Enabled – Always validates the referer
header. If selected, the request fails the If this check is activated, you can set
check if there is no referer header or if the the following additional options:
referer header is invalid.
• Disabled – Configures WAF to not validate • Allowed Referer Domains – String
requests based on the referer header.
• Safe URL – String
• Only-If-Present – Validates the referer
header only if a referer header exists. If
Default: Disabled
the check finds an invalid referer header,
the request fails the check. However, the
request does not fail the check if there is
no referer header in the request.
[no] referer-check
{enable | only-if-present}
GUI:
156
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
Cross-site Checks for potential HTML XSS scripts to One of the following:
Scripting protect against cross-site scripting attacks.
(XSS) Check This check uses the list of defined Javas- • Reject
cript commands in the “jscript_defs” WAF • Disabled
policy file. See “XSS Check” on page 120. • Sanitize
GUI:
157
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
[no] url-check
GUI:
158
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
• Decode Entities
• Decode Escaped Characters
• Decode HEX Characters
• Comment Removal
• Remove Self-References
• Remove Spaces
[no] url-options
GUI:
Response Checks
CCN Mask Replaces all but the last four digits of credit Enabled or Disabled
card numbers with an “x” character.
Default: Disabled
[no] ccn-mask
GUI:
159
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
[no] ssn-mask
GUI:
[no] filter-resp-hdrs
GUI:
160
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
GUI:
Cookie Uses the specified Secret string to encrypt Cookie Name – String or PCRE
Encryption and decrypt cookies in server to client com- expression
Secret munication. For Cookie Name, you can enter
the name of a specific cookie as a string, or Cookie Encryption Secret – String
a PCRE expression to encrypt all cookies
which match the expression. Default: Not set
[no] cookie-encrypt
{cookie-name | pcre-pattern}
GUI:
161
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
162
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
This chapter lists the CLI commands for WAF. The commands are organized into the following
section:
• waf template
waf template
Description Configure a WAF template.
Parameter Description
template-name Name of the template.
163
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Template Commands
This command changes the CLI to the configuration level for the
specified WAF template, where the following commands are available.
Command Description
[no] Specifies the HTTP methods that requests are allowed to contain.
allowed-http-methods
method-list For example, method list:
Default methods are GET and POST, but you can specify the following:
• GET
• POST
• HEAD
• PUT
• OPTIONS
• TRACE
• PATCH
• DELETE
• PURGE
• PROPFIND
• PROPPATCH
• MKCOL
• COPY
• MOVE
• LOCK
• UNLOCK
[no] bot-check Checks user requests for bot activity. This check uses the specified WAF
waf-policy policy file for a list of search terms. For more information see, “Bot Check”
on page 120.
164
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Template Commands
Command Description
[no] brute-force Configure protection against brute-force attacks. The sub-options for this
option command can include the following:
• challenge-limit num – Specify the maximum number of triggers that
can occur within the test period. If this limit is breached, then the WAF
initiates all of the configured challenge-actions against the client.
Setting this field to zero disables the feature and the challenge will never
be sent. You can set a value from 0-65535. The default is 2.
• global – When enabled, this option will cause the WAF to maintain a
single counter for all clients, as opposed to having a separate counter
for each client. When enabled, all clients will be locked out for the con-
figured lockout-period once the lockout-limit is reached. Similarly, all
responses will include a challenge once the challenge-limit is
reached. This default is disabled.
• lockout-limit – This options sets the maximum number of brute-force
events (or triggers) that can occur within the test period. If the limit is
exceeded, then the WAF will deny all future requests from this client.
• You can set a value from 0-65535. The default value is 5.
• If the lockout limit is set to zero, then clients will never be locked out.
• The lockout-limit is a learned parameter, so it will be set to the maxi-
mum number of triggers within a test period seen during learning
mode.
• lockout-period – This option sets the number of seconds that a client
should be locked out. You can set a value from 0-1800. The default is
600.
• resp-codes name – This option triggers a brute-force check based on
the HTTP response code. Specify the name of the WAF policy that will be
used to define which response codes will trigger brute force checking.
You must configure this policy file prior to setting this parameter, and it
must contain a set of regular expressions that will be matched against
the response
status-code.
• resp-headers name– This option triggers a brute-force check based on
the HTTP response header names. Specify the name of the WAF policy
that will be used to define which response headers will trigger brute
force checking. You must configure this policy file prior to setting this
parameter, and it must contain a set of regular expressions that will be
matched against the response header names.
• resp-string name – This option triggers a brute-force check based on
the HTTP response string. Specify the name of the WAF policy that will be
used to define which response line messages will trigger brute force
checking. You must configure this policy file prior to setting this param-
eter, and it must contain a set of regular expressions that will be
matched against the response line messages. This default is disabled.
• test-period – This option sets the number of seconds between clear-
ing of the brute-force counters. The range is 0-600. Default is 60.
[no] brute-force- Enable brute force attack mitigation checks for this template. This option is
check disabled by default.
165
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Template Commands
Command Description
[no] buf-ovf option Checks for attempts to cause a buffer overflow on the web server. Can
include the following sub-options:
• disable – Disables buffer overflow protection. Default is Enabled.
• max-cookie-len bytes – Sets the maximum length for cookies allowed
in a request. Default is 4096.
• max-cookie-name-len bytes – Sets the maximum length for cookie
names allowed in a request. Default is 64.
• max-cookie-value-len bytes – Sets the maximum length for cookie
values allowed in a request. Default is 4096.
• max-cookies-len – Sets the maximum total length for cookies in a
request. The default value is 4096.
• max-data-parse – Sets the maximum data parsed for internal HTTP
data tests (XML, WAF, Forms). The request will not be rejected when the
limit is reached. The range is 0-262144. The default value is 65536.
• max-hdr-name-len bytes – Sets the maximum header name length for
headers allowed in requests.
• max-hdr-value-len bytes – Sets the maximum header value length
for headers allowed in requests.
• max-hdrs-len bytes – Sets the maximum header length for headers
allowed in requests.
• max-line-len bytes – Sets the maximum line length allowed in a
request. You can specify 0-16127. The default is 1024.
• max-parameter-name-len – Sets the maximum parameter name length
allowed in an HTTP request. You can specify 0-512. The default is 256.
• max-parameter-total-len – Sets the maximum parameter total length
allowed in an HTTP request. You can specify 0-102400000. The default
is 4096.
• max-parameter-value-len – Sets the maximum parameter value
length allowed in an HTTP request. You can specify 0-102400000. The
default is 4096.
• max-post-size bytes – Sets the maximum content length allowed in
HTTP POST requests. The default is 20480.
• max-query-len bytes – Sets the maximum query length allowed in a
request. The default is 1024.
• max-url-len bytes – Sets the maximum URL length allowed in
requests. The default is 1024.
[no] ccn-mask Replaces all but the last four digits of credit card numbers with “x” charac-
ters.
The default is disabled.
166
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Template Commands
Command Description
[no] challenge- The action to be taken to determine if a client is automated. Can include
actions options the following options:
167
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Template Commands
Command Description
[no] Denies user passwords that are sent over a non-encrypted connection. If
deny-non-ssl-pass- the connection between the client and the WAF is secured with SSL/TLS,
words then the user password is allowed, but if the client attempts to submit to a
form field where “input type=password”, and if the connection is not
encrypted with SSL/TLS, then the WAF blocks the transmission. The fea-
ture is disabled by default, meaning that forms not using the SSL/TLS pro-
tocol will not be denied.
The feature is disabled by default, meaning that forms not using POST will
not be denied.
[no] form-deny-non- Denies HTTP requests containing forms if the transmission protocol
ssl used is anything other than SSL (TLS). This option is disabled by
default, meaning that forms not using the SSL/TLS protocol will not
be denied.
168
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Template Commands
Command Description
[no] form-set-no- This option adds “no-cache directives” if the HTTP response
cache contains <form> tags. The feature is disabled by default, and the
“no-cache” behavior is enforced by adding the following headers:
169
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Template Commands
Command Description
[no] pcre-mask Masks patterns in a response that match the specified PCRE pattern.
options pcre-pattern • keep-end num-length – Specifies the number of unmasked charac-
ters at the end of the string. The default is 0.
• keep-start num-length – Sets the number of unmasked characters
at the beginning of the string. The default is 0.
• mask character – Selects a character to mask the matched pattern of
a string. The default is x.
[no] redirect-wlist Enables protection against unvalidated redirects, which can occur if a
hacker uses social networking to trick unsuspecting users into clicking on
a malicious hyperlink. When enabled, the WAF pre-learns a white-list of
acceptable locations to which users can safely be redirected. If one of the
web servers gets hacked and attempts to redirect a user to a location that
does not appear in the redirect white-list, then the WAF blocks the redi-
rect.
170
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Template Commands
Command Description
[no] session-check Enable cookie-based session tracking for WAF sessions.
[secs]
With this option enabled, the WAF uses a cookie to track user sessions.
When a request is received from a client for the first time, ACOS creates a
unique ID for the session, stores it in a table, and inserts the ID into a
cookie that is returned to the client.
Subsequent requests from this client are validated against the session ID.
If the session ID does not match the saved ID, or if the ID is coming from a
different IP address than that of the original client, then the request is
rejected.
The session cookie is named “awaf-sid”, and it is inserted into the header
of the response sent by the server.
The feature is disabled by default. When enabled, the default lifetime for
the session ID is 600 seconds, but you can enter a range from 1 - 86400
seconds (24 hours).
[no] soap-format- Check the XML document for SOAP format compliance.
check
For more information, see “SOAP Format Checks” on page 34.
[no] sqlia-check The feature is disabled by default, but when enabled, it checks for SQL
option strings to protect against SQL injection attacks.
• reject – Denies the request.
• sanitize – Removes suspected SQL injection scripts from requests.
[no] ssn-mask Scans content for strings that resemble US Social Security numbers and
replaces all but the last four characters of the string with “x” characters.
The feature is disabled by default.
[no] template logging Applies a configured logging template to the WAF template. The default is
template-name not set.
[no] uri-blist-check Enforces the rules contained within a WAF policy file for the URI Black List.
file-name The default is “uri_blist_defs” policy file.
171
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Template Commands
Command Description
[no] url-check Enables the URL Check. This check allows users to access web pages by
clicking hyperlinks within the website only and does not allow users to
access the URLs of a website directly.
An approved list of URL paths can be initially configured only when the
WAF is deployed in Learning Mode. For a deployment example that
includes configuration of the URL Check, see “Generate Allowed URL
Paths for the URL Check” on page 141.
For more information, see “XML SQL Injection Checks” on page 33.
[no] xml-validation Checks for XML content validation.
For more information, see “XML Cross-Site Scripting Checks” on page 32.
[no] xss-check option The feature is disabled by default, but when enabled, it checks for poten-
tial HTML XSS scripts to protect against cross-site scripting attacks.
• reject – Rejects requests with XSS patterns.
• sanitize – Removes suspected cross-site scripts from requests.
172
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Template Commands
Command Description
virtual-server-name Name of the virtual server.
portnum Virtual port number.
Default N/A
Mode All
173
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Template Commands
ACOS#show waf
Total
---------------------------------------------------------------
Requests 5666
Requests allowed 295630
Requests denied 3995
Responses denied 0
Session Check
- Success 0
- Failed 1
- None 73
Bad Bot Check
- Success 0
- Failed 0
Buffer Overflow Check
- URL too long 57
- Request line too long 18
- Query too long 0
- Cookie too long 0
- Total Cookies too long 0
- Cookie Name too long 0
- Cookie Value too long 0
- Headers too long 117
- Header Name too long 3
- Header Value too long 2460
- POST body too long 256
- Parameter name too long 0
- Parameter value too long 0
- Parameter total too long 0
- Too much data to parse 53
- Too many parameters 0
- Too many cookies 18
- Too many headers 1
- Too many MIME entities 18
Allowed HTTP Methods Check
- Success 299662
- Failed 13
HTTP Protocol Check
- Success 53
- Failed 44
Referer Check
- Success 51
174
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Template Commands
- Failed 17
- No Referer (Redirect) 51
URI Whitelist Check
- Success (Match) 36
- Failed 18
URI Blacklist Check
- Success 35
- Failed (Match) 36
URL Check
- Learned 0
- Success 54
- Failed 126
Form Consistency Check
- Success 0
- Failed 0
Form CSRF Tag Check
- Success 0
- Failed 0
CCN Mask
- Amex 0
- Diners 0
- Visa 0
- MasterCard 0
- Discover 0
- JCB 0
SSN Mask
- US SSN's masked 0
PCRE Mask
- PCRE's masked 0
Cookie Encryption
- Encrypt Success 0
- Encrypt Failed 0
- Encrypt Limit Exceeded 0
- Encrypt Skipped 0
- Decrypt Success 0
- Decrypt Failed 0
SQLIA Check
- URL Success 54
- URL Sanitized 72
- URL Rejected 36
- POST Success 0
- POST Sanitized 0
- POST Rejected 0
- XML Success 72
175
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Template Commands
- XML Failed 36
XSS Check
- Cookie Success 0
- Cookie Sanitized 0
- Cookie Rejected 0
- URL Success 18
- URL Sanitized 0
- URL Rejected 18
- POST Success 36
- POST Sanitized 18
- POST Rejected 18
- XML Success 36
- XML Failed 36
JSON Format Check
- Parse Success 882
- Parse Failure 630
- too many array values 0
- nested too deep 0
- too many object members 0
- string too long 18
XML Format Check
- Parse Success 306
- Parse Failure 252
- too many attributes 0
- attribute name too long 0
- attribute value too long 0
- CDATA field too long 18
- too many elements 0
- too many children 18
- elements nested too deep 0
- element name too long 0
- too many entity expansions 0
- entity expansions nested too deep 36
- too many namespaces 0
- namespace URI too long 0
- XML Schema success 18
- XML Schema failure 0
SOAP Format Check
- Parse Success 0
- Parse Failure 0
- WSDL Success 0
- WSDL Failure 0
Password Security Check
- Non masked passwords Rejected 0
176
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Template Commands
The number at the top of the output (vip1 80 in this example) indicates the name of the virtual
server and port number. Table 10 describes the rest of fields in the command output.
• Success – Total number of requests that had a session ID inserted into the
cookie and passed the subsequent validation checks for that same ID.
• Failed – Total number of requests that had a session ID inserted into the
cookie, failed a subsequent check for that same ID, and were denied.
• None – Number of requests that did not contain a session ID.
Bad Bot Check Counters for bot checking:
177
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Template Commands
178
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Template Commands
• Success – Number of requests that did not match criteria in the URI Black
List and were accepted.
• Failed (Match) – Number of requests that matched criteria in the URI Black
List and were denied.
URL Check URL Check counters:
• Learned – Number of URL paths learned during Learning Mode and added
to the URL Check list.
• Success – Number of requests that matched the URL Check list and were
accepted.
• Failed – Number of requests that did not match the URL Check list and
were denied.
Form Counters for web form consistency:
Consistency Check
• Success – Number of requests that passed the web form consistency
check.
• Failed – Number of requests which did not match the original structure of
the web form and were denied.
Form CSRF Tag Check Counters for the CSRF check on web form field tags in outbound responses:
• Amex
• Diners
• Visa
• MasterCard
• Discover
• JCB
179
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Template Commands
• US SSNs masked – Total number of SSN numbers that the WAF discovered
and masked.
PCRE Mask Counters for custom PCRE pattern checks:
• PCREs masked – Total number of custom PCRE string matches the WAF
discovered and masked.
Cookie Counters for cookie encryption:
Encryption
• Encrypt Success – Number of times a cookie was successfully encrypted
with the specified secret string.
• Encrypt Failed – Number of times encryption of a cookie failed.
• Encrypt Limit Exceeded – Number of times cookies were not encrypted
because of the a configured limit.
• Encrypt Skipped – Number of cookies that skipped encryption because the
remove-cookies option is enforced in the RAM caching template.
• Decrypt Success – Number of cookies in clients’ requests that were suc-
cessfully decrypted with the configured secret string.
• Decrypt Failed – Number of client requests that were rejected because
they could not be decrypted.
SQLIA Check Counters for the SQL Inject Attack (SQLIA) check:
• URL Success – Number of requests that passed the SQLIA check for the
URL.
• URL Sanitized – Total number of requests that the URL component was
sanitized of an SQL attack pattern and accepted.
• URL Failed – Number of requests that contained an SQLIA in the URL.
• POST Success – Number of requests that passed the SQLIA check for the
POST body.
• POST Sanitized – Total number of requests that the POST body component
was sanitized of an SQL attack pattern and accepted.
• POST Rejected – Total number of requests that were denied because they
contained an SQL injection attack in the POST body of a request.
• XML Success – Number of requests that passed the SQLIA check for XML.
• XML Failed – Number of requests that contained an SQLIA in the XML.
180
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Template Commands
181
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF Template Commands
182
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF Template Commands
Command Description
virtual-server-name Name of the virtual server.
portnum Virtual port number.
Default N/A
183
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF File Management Commands
Parameter Description
file-name Name of a configured WAF policy file.
184
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF File Management Commands
Parameter Description
source-name Name of a configured WAF policy file.
destination-name Name of the new, copied WAF policy file.
Default N/A
Replace file-name with the name of the WAF policy file to be deleted.
Default N/A
185
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF File Management Commands
Replace file-name with the name of the WAF policy file to be modified, or
an un-used name to create a new file.
Default N/A
Usage Editing the default WAF policy files is not allowed. However, you can
copy a default WAF policy file and customize its contents to fit your
specific demands.
Default 32K
Parameter Description
source-name This is the old name of the WAF policy file.
destination-name This is the new name of the WAF policy file.
Default N/A
186
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF File Management Commands
Parameter Description
file-name Name of a configured WSDL file.
Parameter Description
source-name Name of a configured WAF WSDL file.
destination-name Name of the new, copied WAF WSDL file.
Default N/A
Replace file-name with the name of the WAF WSDL file to be deleted.
Default N/A
187
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF File Management Commands
Replace file-name with the name of the WAF WSDL file to be modified, or
an un-used name to create a new file.
Default N/A
Default 32K
Parameter Description
source-name This is the old name of the WAF WSDL file.
destination-name This is the new name of the WAF WSDL file.
Default N/A
188
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF File Management Commands
Parameter Description
file-name Name of a configured WSDL file.
Parameter Description
source-name Name of a configured WAF XML-Schema file.
destination-name Name of the new, copied WAF XML-Schema file.
Default N/A
Default N/A
189
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF File Management Commands
Default N/A
Default 32K
Parameter Description
source-name This is the old name of the WAF XML-Schema file.
destination-name This is the new name of the WAF XML-Schema file.
Default N/A
190
Feedback ACOS 4.1.4-GR1-P11 Web Application Firewall Guide
WAF File Management Commands
Parameter Description
def-file-name Returns a list of WAF policy files with names that
partially match the specified string.
all-partitions Returns a list of WAF policy files for all partitions.
partition {shared | Returns a list of WAF policy files for the shared parti-
partition-name} tion or the specified private partition.
Default N/A
Mode All
Example The following command lists all WAF policy files, for all partitions:
191
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide FeedbackF
Fee
e
WAF File Management Commands
192
ACOS 4.1.4-GR1-P11 Web Application Firewall Guide for A10 Thunder Series
Contents
193
1