Professional Documents
Culture Documents
0
Web Application Firewall Guide
for A10 Thunder® Series
13 December 2019
© 2019 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 patent marking provisions of various jurisdictions including the virtual patent marking provisions of the America
Invents Act. A10 Networks' 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 Networks, Inc.
Anyone who uses the Software does so only in compliance with the terms of the End User License Agreement (EULA), pro-
vided 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 informa-
tion is provided "as-is." The product specifications and features described in this publication are based on the latest informa-
tion available; however, specifications are subject 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’ prod-
ucts and services are subject to A10 Networks’ standard terms and conditions.
ENVIRONMENTAL CONSIDERATIONS
Some electronic components may possibly contain dangerous substances. For information on specific component types,
please contact the manufacturer of that component. Always consult local authorities for regulations regarding proper dis-
posal of electronic components in your area.
FURTHER INFORMATION
For additional information about A10 products, terms and conditions of delivery, and pricing, contact your nearest A10 Net-
works location, 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 ...................................................................................................................................... 10
Forceful Browsing ...................................................................................................................................... 11
Web Form Security Attacks ..................................................................................................................... 11
WAF Security Models ...........................................................................................................11
Positive Security Model ............................................................................................................................ 11
Negative Security Model .......................................................................................................................... 12
Request Protection...............................................................................................................12
Compare Request URI to White List and Black List ............................................................................ 12
White List .............................................................................................................................................. 12
Black List .............................................................................................................................................. 12
URL Check ................................................................................................................................................... 13
Scan Request for Threats ........................................................................................................................ 14
Bot Check ............................................................................................................................................. 15
Form Field Consistency Check ........................................................................................................ 15
Referer Check ...................................................................................................................................... 15
HTTP Protocol Compliance Check .................................................................................................. 15
HTML Cross-Site Scripting (XSS) Check ........................................................................................ 16
Buffer Overflow Check ....................................................................................................................... 17
HTML SQL Injection Check ............................................................................................................... 17
Allowed HTTP Methods Check ........................................................................................................ 17
Maximum Cookies Check .................................................................................................................. 18
Maximum Headers Check ................................................................................................................. 19
Session Checks ................................................................................................................................... 19
Password Security .............................................................................................................................. 19
Open Redirect Mitigation ................................................................................................................... 21
Normalization Enhancements for URL Options ........................................................................... 23
WAF XML Checks ...................................................................................................................................... 25
XML Format Checks ........................................................................................................................... 26
XML Validation Checks ...................................................................................................................... 26
XML Limit Checks ............................................................................................................................... 28
XML Cross-Site Scripting Checks .................................................................................................... 30
XML SQL Injection Checks ................................................................................................................ 31
WAF SOAP Checks .................................................................................................................................... 32
SOAP Format Checks ......................................................................................................................... 32
page 3
ACOS 5.1.0 Web Application Firewall Guide
Contents
page 4
ACOS 5.1.0 Web Application Firewall Guide
Contents
page 5
ACOS 5.1.0 Web Application Firewall Guide
Contents
page 6
ACOS 5.1.0 Web Application Firewall Guide
Contents
page 7
ACOS 5.1.0 Web Application Firewall Guide
Contents
page 8
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Overview
Overview
• WAF Overview
• Request Protection
• Response Protection
WAF Overview
The A10 Networks product line provides additional security for your web servers with the Web Applica-
tion 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 unautho-
rized retrieval or leakage of sensitive information from your websites or back-end databases.
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.
page 9
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF External Logging FFee
e
Websites are further protected from attack through checks that are defined by customizable WAF pol-
icy files. You can configure WAF policy files for advanced countermeasures to common attacks, such
as SQL injection attacks or bots.
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 nor-
malize requested URLs.” on page 98.)
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.
page 10
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Security Models
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 con-
junction 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 13.)
• SQL Injection Attacks (SQLIA) – An SQL Injection Attack uses a web form or other mechanism to
send active SQL commands or SQL special characters to the website’s SQL database. 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 Injec-
tion 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 Javas-
cript 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 informa-
tion. The WAF includes the XSS Check template option and default “jscript_defs” policy file to pro-
vide immediate protection from XSS attacks.
The WAF operates based on both a positive security model and negative security model to maximize
protection.
page 11
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
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.
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 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.
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 pol-
icy 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 114.
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 web-
site. If a URI matches acceptance criteria within the URI White List, a connection is blocked automati-
page 12
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Request Protection
cally if it meets a rule in the separate URI Black List. For more information, see “URI Black List” on
page 113.
The following diagram displays the processing order for incoming requests:
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 lim-
ited set of URL paths on your website. The URL Check allows clients to access a specific set of accept-
able URLs that were added to the URL-check policy file while the WAF is deployed in Learning Mode.
page 13
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
Once this policy file is generated, you can manually edit the contents before switching the WAF deploy-
ment mode from Learning to Active. At this point, users are prevented from accessing any URLs that
are not listed in this generated policy file.
NOTE: For a deployment example that includes configuration of the URL Check,
see “Generate Allowed URL Paths for the URL Check” on page 131.
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 13, the URL Check would
achieve the same degree of security if a hyperlink is only provided to the
page “/site_images.jpg”.
page 14
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Request Protection
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.
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 111.
Referer Check
The Referer Check validates that the referer header in a request contains web form data from the spec-
ified 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.
page 15
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
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.
NOTE: A request containing more than one Content-Length header might indi-
cate that the request is part of an HTTP response-splitting attack.
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 informa-
tion 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 Networks recommends mod-
ifying the “jscript_defs” file to generate the appropriate exceptions, so
that this check does not block legitimate activity.
page 16
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Request Protection
• Maximum parameters
• URL length
• Line length
• Query length
NOTE: The HTML SQL Injection Check scans incoming requests for attack pat-
terns listed in the “sqlia_defs” WAF file. Copy this file and apply the cop-
ied file to the check to customize attack pattern search criteria for the
HTML SQL Injection Check. (See “SQL Injection Attack Check” on
page 112.)
• GET
• POST
• HEAD
• PUT
• OPTIONS
page 17
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
• DELETE
• TRACE
• CONNECT
• 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 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 containing
a set of resources
• PROPPATCH – modifies multiple properties for a set of a resources with a single operation
• 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.
page 18
ACOS 5.1.0 Web Application Firewall Guide
Feedback
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 vali-
dated 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 ses-
sion 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.
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”.
page 19
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
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 transmis-
sion 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.
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.
page 20
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Request Protection
While end users may appreciate this “autocomplete” behavior because it simplifies the process of log-
ging 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 config-
uring the WAF to reject the web server form if the field type is set to “password” and if the “autocom-
plete=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 com-
mand at the WAF template configuration level.
An unvalidated redirect occurs when a hacker uses social networking (such as email, Facebook, Twit-
ter) 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/pass-
word), 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 actu-
ally 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 mali-
cious 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 13
• “unvalidated redirects” – Described in detail below.
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 redi-
rect 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 redirect white-
page 21
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
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 hav-
ing 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 “redi-
rect_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 Learning 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 terms of block-
ing traffic, and simply increases the counters and generates logs for hypothetical 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 com-
mand is used. Once the redirect white-list is created, you can then switch
to Passive Mode or Active Mode.
page 22
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Request Protection
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.
• Learned – Number of redirect locations learned during Learning Mode and added to
the redirect white-list.
• Success – Number of requests that matched a URI entry in the redirect white-list and
were accepted.
• Failed – Number of requests that did not match a URI entry in the redirect white-list
and were blocked.
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.
page 23
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
This process of normalizing URLs is sometimes used by search engines to make comparisons of sev-
eral 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 directo-
ries 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.
• Decode Escaped Characters – Decode escape characters, such as \r \n \"\xXX in an internal URL.
• Decode HEX Characters – Decode hexadecimal characters, such as \%xx and \%u00yy in an
internal URL.
• Remove Comments – Remove comments from 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.
page 24
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Request Protection
It is important to inspect and validate client requests containing XML code to protect the backend serv-
ers 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 specially-constructed (and
invalid) XML messages to circumvent the web application’s standard 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 exam-
ine the headers and bodies of incoming XML requests for Javascript keywords that might indi-
cate 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 examine 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.
page 25
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
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 follow-
ing 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 element 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 attri-
butes 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.
The option can be enabled using the following CLI command at the WAF template configuration level:
page 26
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Request Protection
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 com-
mand 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.
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 32.
page 27
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
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 docu-
ments, 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 miti-
gate 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 maxi-
mum 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 exces-
sive system resources, ACOS provides the following CLI command, which can be used at the WAF tem-
plate 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.
page 28
ACOS 5.1.0 Web Application Firewall Guide
Feedback
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 elements,
character information, and comments.
number – Maximum number of children allowed per element. Range is 1–4096. Default is 1024.
• max-elem-depth depth
page 29
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
• max-namespace number
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 112 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”.
page 30
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Request Protection
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 112 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”.
page 31
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
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 Inter-
net 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 examines
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 validate
the SOAP content in a request in order to check it against a WSDL file. If the WAF discovers that
the SOAP content fails the validation check, then the WAF blocks the request.
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.
page 32
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Request Protection
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 25.
The SOAP Format Check scrubs incoming client requests to ensure that the SOAP requests are struc-
tured in the proper format, as defined by the World Wide Web consortium in the following Recommen-
dation:
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-enve-
lope).
• 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 configura-
tion level:
soap-format-check
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.
page 33
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
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:
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.
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
definition in each schema file, but it extends the XML Schema to allow for an association to occur for specific calls to spe-
cific URIs, assuming the contents of the headers.
page 34
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Request Protection
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:
• All objects must contain matching braces {}, and a set of members must be separated by com-
mas.
• 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.
This option can be enabled using the following CLI command at the WAF template configuration level:
json-format-check
page 35
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
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
This capability allows you to limit which countries can access your resources based upon the geo-loca-
tion 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 dif-
ferent approaches.
page 36
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Request Protection
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 ram-
pant 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.
You can enable the WAF Geo-location blocking feature by using the new geo-location keyword at the
HTTP policy configuration level.
page 37
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
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”:
page 38
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Request Protection
member s2 514
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 “sys-
log”:
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”:
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 tem-
plate we created earlier, and bind the two waf templates.
page 39
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Request Protection FFee
e
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:
• 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 (violations
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 methods were used,
the WAF would end up rejecting all of the requests that used the WebDAV methods. The work-
around 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 determine that this
page 40
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Request Protection
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 connection 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 follow-
ing 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.
• Sanitize - This action is triggered for the WAF_REQUEST_VIOLATION event for features that sup-
port 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 trig-
gered.
• 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.
page 41
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Response Protection FFee
e
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 follow-
ing 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 a pattern of
potentially sensitive information, the string is masked with an alternative character.
• Cloak Response Headers – The WAF removes content from HTTP response headers that can
disclose vulnerabilities about the web server.
• Return Instrumented Responses – If a web form is included in outbound responses, the WAF can
tag form fields with a nonce value before sending the reply to the outside user. The WAF then
checks subsequent requests for the nonce, to protect against CSRF.
page 42
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Response Protection
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.
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 con-
tain 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.
page 43
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Response Protection FFee
e
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 117.)
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).
NOTE: You do not need to create a specialized PCRE mask to hide US social
security numbers or credit card information. Instead, simply enable the
SSN or CCN mask options that are provided in the WAF template.
Cloak Responses
The WAF can strip HTTP response headers to “cloak” server information that can equip a hacker to tar-
get 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
• 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 pro-
vide an attacker with information to specifically target web server vulnerabilities.
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.
page 44
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Response Protection
NOTE: You can use the Referer Check to further help prevent CSRF attacks.
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 other-
wise 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 127.)
page 45
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
PCI 6.6 Compliance FFee
e
A10 Networks has achieved WAF certification from ICSA Labs. This certification can help assure net-
work 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:
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 per-
formed 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 continually
check all traffic.
For more information, you can access the PCI DSS at https://www.pcisecuritystandards.org/docu-
ments/PCI_DSS_v3.pdf
page 46
ACOS 5.1.0 Web Application Firewall Guide
Feedback
PCI 6.6 Compliance
• 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 happens)
More information about PCI DSS compliance can be found at the following link:
https://www.pcisecuritystandards.org/documents/information_supplement_6.6.pdf
page 47
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
PCI 6.6 Compliance FFee
e
page 48
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Overview
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 environ-
ments 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 103.
• When the WAF is deployed in either learning or passive mode, traffic is not blocked. However,
event log messages will list the response action (deny, allow, or sanitize) that is configured in the
WAF template. In addition, WAF counters will continue to increment as if the WAF is deployed in
active mode.
page 49
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Overview FFee
e
page 50
ACOS 5.1.0 Web Application Firewall Guide
Feedback
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 val-
ues to zero:
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.example.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:
page 51
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Overview FFee
e
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 tem-
plate:
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-configura-
tion only after the WAF deployment mode is changed from Learning Mode to Active Mode or Pas-
sive 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 con-
figuration 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.
• 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 127.
page 52
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Overview
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 mes-
sages 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 produc-
tion 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 tem-
plate allows a maximum of 3 cookie headers within a given request.
page 53
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Overview FFee
e
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 103.
• 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.
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.
page 54
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Overview
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.
page 55
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Setting the WAF Operational Mode FFee
e
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 Injec-
tion Check and is denied.
page 56
ACOS 5.1.0 Web Application Firewall Guide
Feedback
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 messages.
• The WAF comes with predefined WAF policy files. 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 111. A10 Networks highly recommends
modifying the WAF policy files to meet your specific security requirements.
• Optionally, you can pair the WAF template with an HTTP policy template to enforce WAF security
checks based on URL, host, or cookie. (See “Overriding a WAF Template” on page 121.)
• For examples of advanced WAF configuration, see “WAF Deployment and Logging Examples” on
page 127.
page 57
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Bind the WAF Template to the Virtual Port FFee
e
A table of WAF binding appears. A WAF binding is the combination of a virtual IP address, or “VIP”
and a virtual port with service type HTTP or HTTPS.
7. Click +Bind WAF Template.
8. A new Bind WAF Policy page appears, as follows:
page 58
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Bind the WAF Template to the Virtual Port
FIGURE 11 Security > WAF > WAF Bindings > Bind WAF Policy
9. Click the VIP drop-down menu and select a pre-configured VIP to bind.
For a VIP to appear in the VIP drop-down list with the virtual server names, it must be configured
with one or more HTTP/HTTPS virtual ports.
10.Based on the VIP that you select, the vPort: (port and protocol) field automatically updates. You
can also click the vPort drop-down menu and select a different port/protocol combination from
the list of HTTP or HTTPS ports associated with this VIP.
11.Click the WAF Template drop-down menu and select the desired WAF template from the list.
Alternatively, click the WAF Template tab to +Add a new WAF Template for this WAF service.
(See Add/Edit a WAF Template.)
12.Click the HTTP Policy drop-down menu and select the desired HTTP template.
Alternatively, click the New HTTP Policy Template button to configure a new template. (See
“Configure an HTTP Policy Template” on page 80.)
13.Click the Save button to complete the WAF service configuration.
page 59
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Add/Edit a WAF Template FFee
e
page 60
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Add/Edit a WAF Template
• Versions Allowed: Click left arrow to update the HTTP versions that you want to allow.
• All Versions: Select the required HTTP version from all available versions.
3. Click the Allowed HTTP Headers field, to open up a drop-down, displays the following multiple
configurations selection list:
• Headers Allowed: Click left arrow to update the HTTP headers that you want to allow.
• All Headers: Select the allowed HTTP headers from all available HTTP headers.
4. List of allowed Allowed HTTP Methods. The allowed HTTP Methods drop down displays the
following multiple configurations selection list:
• Methods Allowed: Click left arrow to update the HTTP headers that you want to allow.
• All Methods: Select the allowed HTTP headers from all available HTTP headers.
5. Select the other parameters displayed using the sliding On/Off button. For details for each field,
refer the GUI Online Help.
page 61
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Add/Edit a WAF Template FFee
e
page 62
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Add/Edit a WAF Template
2. Select the Bot Check On/Off button 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 112.
3. Select the Referer Check On/Off button to enable referer checks, or clear the On/Off button 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.
4. Select the URI Black List Check On/Off button 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 113.
5. Select the URI White List Check On/Off button 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 white-list. The default WAF policy
file is “uri_wlist_defs”. For more information about URI white-lists, see “URI White List” on page 114.
6. Configure the options under Injection Checks On/Off button to prevent access to your website
directly through SQL injection or XSS Injection attacks.
page 63
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Add/Edit a WAF Template FFee
e
7. In the SQL Injection Attack Check radio button, specify whether the WAF will Sanitize 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.
• Select Reject to deny the user request.
• Select Sanitize to forward the request to the web server after removing the offending SQL
strings from the message.
8. Select either of the above radio buttons to display the SQL Injection Attack Policy File
drop-down menu. Click this drop-down and select the policy file to perform SQL Injection Attack
checks. By default, the WAF uses the list of defined SQL commands in the “sqlia_defs” WAF policy
file. For more information, see “SQL Injection Attack Check” on page 112.
9. The XSS Check uses “jscript_defs” WAF policy file to examine the content of URL, cookies,
headers, 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.
10.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 112.)
11.Select the Session Check On/Off button 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.
12.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 19.
13.Click Save to save your changes.
page 64
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Add/Edit a WAF Template
page 65
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Add/Edit a WAF Template FFee
e
2. In the Tampering Protection drop-down, select Encrypt or Do Not Encrypt option. This option
protects against cookie tampering encrypting the cookies by a specific name or for all cookies that
match a PCRE expression.
3. If Encrypt option is selected, the Encryption Secret field is displayed. Enter the encryption
keyword in this field.
4. In the Applies to field, select the All Cookies or Session Cookies Only option which will be
used to encrypt and decrypt the cookies. The encryption uses a secret pass phrase to decrypt and
encrypt cookies that are transferred between the web server and client.
5. On/Off the HTTP Only and Secure button to enable tampering protection to HTTP or HTTPS
traffic.
page 66
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Add/Edit a WAF Template
6. To set cookies security from server, click the drop-down arrow next to Set-Cookies from Server.
7. Enter the keyword Name, Encryption Secret keyword, and select HTTP or HTTPS options.
8. Click Save to save your changes.
2. Set Apache White Space to ON to enable check for whitespace characters in URLs.
page 67
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Add/Edit a WAF Template FFee
e
3. Set Decode Entities to ON, to enable decoding of entities, such as < &#xx; &#ddd; &xXX, in an
internal URL.
4. Set Decode Escaped Characters to ON to enable decoding of escaped characters, such as \r \n
\” \xXX, in an internal URL.
5. Set Decode Unicode Characters to ON to check for evasion attempt using encoding of unicode
characters to bypass security.
6. Set Decode Plus Characters to ON to check for evasion attempt using encoding of spaces with
+ characters.
7. Set Directory Traversal to ON to check for directory traversal attempt.
8. Set High ASCII Bytes to ON to check for evasion attempt using ASCII bytes with values > 127.
9. Set Invalid Hex Encoding to ON to check for evasion attempt using invalid hex characters (not in
0-9,a-f)
10.Set Multiple Encoding Levels to check for evasion attempt using multiple levels of encoding
(0 - 7),
11.Set Multiple Slashes to check for evasion attempt using multiple slashes/backslashes.
12.Set Remove Comments to ON to remove comments from internal URL.
13.Set Remove Spaces to ON to remove spaces from internal URL.
14.Click Save to save your changes.
page 68
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Add/Edit a WAF Template
2. Select the Enforce JSON compliance, On/Off button to set 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.
page 69
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Add/Edit a WAF Template FFee
e
JSON Limits:
When the following JSON Limit options are configured, the WAF JSON parser will enforce parsing
limits to protect back end servers from denial-of-service (DoS) attacks that are designed to
exhaust system memory or CPU resources.
3. In the JSON Limit - Max Array Value Count field, enter the maximum number of values in a
single array.
The default value is 256, but you can set a number ranging from 0–4096.
4. 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.
5. 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.
6. 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.
7. The XSS Check uses “jscript_defs” WAF policy file to examine the content of URL, cookies,
headers, 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.
8. Select the XML SQLIA Check On/Off button to check XML data against the SQLIA policy file. The
XML cross-site scripting check examines the headers and bodies of incoming XML requests for
SQL keywords that might indicate possible cross-site scripting attacks and blocks those requests.
9. Select the XML XSS Check On/Off button 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 30 for details.)
10.Select the XML Format Check On/Off button to check the HTTP body of the message for XML
format compliance. Incoming requests containing XML code are checked for compliance with the
XML 1.0 specification. (See “XML Format Checks” on page 26 for details.)
11.In the XML Limit - Max Attributes field, enter the maximum number of attributes each individ-
ual 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 characters
allowed per element.
The default is 128, but you can enter an integer from 0-2048.
page 70
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Add/Edit a WAF Template
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 sec-
tion 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 ele-
ment per XML document.
The default is 1024, but you can enter an integer from 0-8192.
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 comments. 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 expan-
sions 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 name-
space 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.Click Save to save your changes.
page 71
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Add/Edit a WAF Template FFee
e
2. Select the Filter Response Headers On/Off button to remove the web server’s identifying
headers in outgoing responses.
3. Select the Hide Response Codes On/Off button 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. However, 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 114.
4. Select the Redirect Whitelist On/Off button to enable protection against unvalidated redirects,
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 redirect. See “Open Redirect Mitigation” on page 21 for
details.
5. Click Save to save your changes.
page 72
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Add/Edit a WAF Template
NOTE: View counters for the CCN check from the CLI. These counters display
the number of masked credit card numbers for various bank providers.
page 73
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Add/Edit a WAF Template FFee
e
6. Select the SSN Mask On/Off button 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.
7. Click PCRE Mask drop-down. PCRE Mask hides strings that match the specified PCRE pattern.
(See “Writing PCRE Expressions” on page 117 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.
• 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 excessively long
strings (* and +) are not supported.
If either the asterisk (*) or plus symbol (+) is detected during the syntax check, the syn-
tax 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 “\+”.
page 74
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Add/Edit a WAF Template
2. Select the CSRF Check On/Off button to tag the fields of a web form with a nonce (a unique
FormID). This check protects against cross-site request forgery (CSRF).
3. Select the Form Consistency Check On/Off button 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 previously parsed HTML forms.
4. Select the Forms Not Using POST On/Off button to deny HTTP requests containing forms if the
method used is anything other than POST.
5. Select the Non-SSL Forms On/Off button 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=pass-
word”, 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 20.)
6. Select the Caching of Form Responses On/Off button to add “no-cache directives” when the
HTTP response contains <form> tags. “no-cache” behavior is enforced when headers are added:
(1) Cache-Control: no-cache, no-store, must-revalidate, (2) Pragma: no-cache, (3) Expires: 0
page 75
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Add/Edit a WAF Template FFee
e
7. Select the Non-masked password fields On/Off button 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 19.)
8. Select the Autocompleted Passwords On/Off button to deny 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
convenient for users, password auto-completion weakens security 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 20.)
9. Select the Non-SSL Passwords On/Off button to deny HTTP requests containing forms if the
transmission protocol used is anything other than SSL (TLS).
10.Click Save to save your changes.
page 76
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Add/Edit a WAF Template
4. Specify Challenge Limit, the maximum number of triggers that can occur within the test period.
If this limit is breached, the WAF initiates all of the configured challenge-actions against the client.
If this field is set to zero, this effectively disables the feature, as the challenge will never be sent.
5. Specify Lockout Limit field to specify the number of triggers that can occur within the test
period. If the limit is exceeded, then the WAF will deny all requests from this client. 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 maximum number of triggers within a test period seen during learning mode.
6. Specify Lockout Period, the number of seconds that a client will be locked out after breaching a
threshold. If the lockout period is set to zero, then the client will be locked out for the remainder of
the current test period. In this way, this option acts similar to a general rate limit.
7. Enable Response Codes to enable the WAF policy to define which response codes will trigger
brute force checking.
8. Select the Response Codes File the WAF policy used to define which response codes will trigger
brute force checking.Select a policy file that will be used for matching prior to setting this
parameter, as none of the default listed files (e.g., bot_defs) would work. The policy file must
contain a set of regular expressions that will be matched against the response status-code.
9. Enable the Response Headers WAF policy to define which response headers will trigger brute
force checking.
10.Select a predefined Response Headers File with the WAF policy that will be used to define
which response headers will trigger brute force checking. You must supply a policy file that will be
used for matching prior to setting this parameter, as none of the default listed files (e.g., bot_defs)
would work. The policy file must contain a set of regular expressions that will be matched against
the response headers.
11.\Enable Response String WAF policy to define which response line messages will trigger brute
force checking.
12.Select the Response String File WAF policy used to define which response line messages will
trigger brute force checking. You must supply a policy file that will be used for matching prior to
setting this parameter, as none of the default listed files (e.g., bot_defs) would work. The policy file
must contain a set of regular expressions that will be matched against the response status-line.
13.Specify the Test Period number of seconds for brute-force event counting.
page 77
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Create a WAF File FFee
e
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 111 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 exam-
ple, if the Bot Check option is enabled in the WAF template and a match is found on an incom-
ing request (using the “bot_defs” file), the request we be denied automatically. You can copy the
page 78
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Create a WAF File
“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 25 on page 78 appears.
~ Select the Local radio button, to enter the name and definition, and then click Create.
~ Select the Remote radio button, to 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 25 for background information.
To configure, click the Create button in the XML Schemas section.
~ Select the Local radio button, then enter the name and definition, and click Create.
~ Select 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 32 for background information.
To configure, click the Create button in the SOAP WSDL section.
~ Select the Local radio button, then enter the name and definition, and then click Create.
~ Select 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.
FIGURE 26 WAF > Files > (WAF Policy/XML Scheme/SOAP WSDL) > Create
page 79
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Configure an HTTP Policy Template FFee
e
For a general discussion of configuring an HTTP Policy Template, see “Overriding a WAF Template” on
page 121.
page 80
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Configure an HTTP Policy Template
5. The Name field is not editable, since this example show how to update an existing HTTP policy
template.
6. In the Match Condition field, enter the condition associated with this HTTP Policy.
7. In the WAF Template section of the window, select the WAF template to bind.
8. Click the check mark under +Add Host, to save the host.
URLs
9. Under URLs section,
Configure Match Conditions on URLs, or WAF Template settings. Client requests that match a
rule in the HTTP policy template are handled using the alternative WAF template that you bind to
the HTTP policy template.
10.To configure rules for matching:
a. Click the Match Condition drop-down list and select the match operation:
• Starts With
• Ends With
• Contains
• Equals
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.
b. 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.
c. Click the check mark under Add URL button.
d. Repeat this process for each rule you wish to add to the HTTP Policy.
11.Click the Add button to save your changes.
page 81
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Reporting FFee
e
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 interval.
• 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.
page 82
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Reporting
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. Select a date from the calendar window.
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.
A window similar to that shown in Figure 28 appears. This example displays the Top 10 Violations.
page 83
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Reporting FFee
e
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 show-
ing 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 hypothetical
source IP address: 172.128.9.154.
page 84
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Configure External Logging (recommended)
Logging of WAF events to external logging servers is supported over TCP or UDP, although UDP is typi-
cally 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 con-
nections 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 established during idle periods
between logs.
4. Configure a logging template. Add the service group containing the log servers to the logging tem-
plate. If you configure a custom TCP-proxy template, also add that template to the logging tem-
plate.
5. Apply the logging template to the WAF template.
External logging is activated once you bind the WAF template to a virtual port.
page 85
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Configure External Logging (recommended) FFee
e
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:
• Port Number – enter the port number in this field (514, which is the default for Syslog)
• 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 On/Off button.
• 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.
page 86
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Configure External Logging (recommended)
page 87
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Configure External Logging (recommended) FFee
e
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 85.
c. Enter 514 in the Port field, since we are using Syslog. (Use the same number as specified 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 must 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.
g. (Optional) Select Stats Data Disable On/Off button if you wish to disable statistical data
collection for system resources, such as CPU, memory, disk, or interfaces.
h. Click Create button.
i. Repeat these steps for each server to add to this service group.
page 88
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Configure External Logging (recommended)
page 89
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Configure External Logging (recommended) FFee
e
3. Click the Edit link next to the desired WAF template name to display the General Settings. (See
Figure 12 on page 60.)
4. Click the Logging Template drop-down menu and select the logging template created.
5. Click the Update button.
page 90
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Required Configuration
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 config-
uration is optional.
This chapter describes how to configure the WAF using the command-line interface (CLI).
NOTE: For deployment examples, see “WAF Deployment and Logging Examples” on
page 127.
Required Configuration
The minimum required configuration for the WAF consists of the following tasks:
NOTE: Configuration of other SLB resources required by the virtual port, such as real serv-
ers and service groups, are not covered here. However, the deployment examples
in the guide include the commands for configuring these resources. (See “WAF
Deployment and Logging Examples” on page 127.)
For the template-name option, enter the name of an existing WAF template to modify the template’s configura-
tion, or an unused name to create a new WAF template. This command enters the CLI
configuration level for the template.
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 94.
page 91
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Required Configuration FFee
e
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
CSP protects against cross-site scripting attacks by ensuring that their trusted Content Delivery
Network, is the only origin from which script can load and execute. No plug ins can execute in the page contexts:
The new CSP HTTP response header helps reduce XSS risks on modern browsers by declaring what dynamic
resources are allowed to load through a HTTP Header. Server administrators can reduce or eliminate executable
scripts based errors, by specifying the valid domains that the browser must
consider valid.
CSP allows multiple policies for a resource, including through the CSP header, the CSP-Report-Only header and a
<meta> element. You can use the CSP header more than once.
CLI Configuration
To support OWASP Top 10 Compliance, a new configuration mode, “csp” is added in WAF template:
To configure CSP, got to WAF template configuration mode using waf-template command:
Use csp command as follows in config-waf mode to replace server CSP header if it exists:
page 92
ACOS 5.1.0 Web Application Firewall Guide
Feedback
External Logging Configuration
By default, CSP is disabled. Otherwise use “insert-always” to insert a separate CSP header.
If no CSP policy is provided, use the default value “script-src 'self'; object-src ‘self’”.
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 messages.
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}
b. Use the following command to add each log server and its TCP or UDP port to the group:
member server-name portnum
page 93
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Optional Configuration FFee
e
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 configuration 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 template 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.
NOTE: The following log is generated when external logging is configured using
command form-check {request-non-post | response-non-post}.
• For sensitive data in forms, server requests client to submit with method POST.
If POST form method is not used in HTTP response, a warning message is logged.
Optional Configuration
This section provides syntax for the following WAF configuration options:
• Deployment mode
page 94
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Optional Configuration
• Request checks
• Deny action (WAF response sent to client when a request is denied by the WAF)
• Response checks
• active – The WAF enforces the security checks configured on the template and sends events to the exter-
nal 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 112.)
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.
page 95
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Optional Configuration FFee
e
• allowed-http-methods method-list – Use this command to specify the HTTP methods (GET, POST, and
so on) that are allowed in requests.
• bot-check – Use this command 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. See “Bot Check” on page 112.
• buf-ovf option – Use this command to configure checks for attempts to cause a buffer overflow on the
web server.
• disable – Disables buffer overflow protection.
• max-cookie-len bytes – Sets the maximum length for cookies allowed in requests.
• max-cookie-name-len bytes – Sets the maximum length for cookie names in requests.
• max-cookie-value-len bytes – Sets the maximum length for cookie values in requests.
• max-cookies-len bytes – Sets the maximum total length for cookies allowed in requests.
• max-data-parse bytes – Sets the maximum data parsed for Web Application Firewall.
• max-hdr-name-len bytes - Sets the maximum header name length allowed in requests.
• max-hdr-value-len bytes - Sets the maximum header value length 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 requests.
• max-parameter-name-len bytes - Sets the maximum parameter name length allowed in requests.
• max-parameter-total-len bytes - Sets the maximum total number of parameters allowed in requests.
• max-parameter-value-len bytes - Sets the maximum parameter value length allowed in requests.
• max-post-size bytes – Sets the maximum content length allowed in HTTP POST requests.
• max-query-len bytes - Sets the maximum query length allowed in requests.
• max-url-len bytes – Sets the maximum URL length allowed in requests.
• csrf-check – Use this command to tag the fields of a web form with a nonce. This check protects against
cross-site request forgery (CSRF). “XSS Check” on page 112
• deny-action response-type – Use this command to specify the type of response string sent to a client
when WAF denies a request
• 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.
page 96
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Optional Configuration
• 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 compliance 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.
• max-object-member-count num – Limits the number of members in a JSON object.
• max-string num – Limits the length of a string in a JSON request for a name or a value.
• log-succ-reqs – Enabling this option logs a debug message on the successful completion of WAF
requests, and not just for errors.
• max-cookies num – Specifies the maximum number of cookies allowed in a request.
• max-entities num – Specifies the maximum number of MIME entities allowed in request.
page 97
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Optional Configuration FFee
e
• 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. 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 redirect. See “Open Redirect Mitigation” on
page 21 for details.
• referer-check {enable | only-if-present}
safe-referer-domain safe-redirect-url – Use this command to validate that the referer header in a
request contains web form data from the specified web server, rather than from an outside website. This
check protects against CSRF attacks.
• enable – always validates the referer header. If selected, the request fails the referer check if there is no
referer header or if the referer header is invalid.
• only-if-present – validates the referer header only if a referer header exists. If the check finds an invalid
referer header, the request fails the check. However, the request does not fail the check if there is no ref-
erer header in the request.
• session-check secs – This command creates an ID for a client request and inserts it in a cookie in the
response. Future requests from the same client are validated against the session cookie. If the ID or IP do
not match, then the request will be rejected. The default lifetime for the session ID is 600 seconds. See
“Session Checks” on page 19.
• soap-format-check – Check XML documents for SOAP format compliance and 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 32 for details.
• sqlia-check {reject | sanitize} – Use this command to check for SQL strings to protect against SQL
injection attacks. This check uses the list of defined SQL commands in the “sqlia_defs” WAF policy file. See
“SQL Injection Attack Check” on page 112.
• reject – denies requests that contain SQL injection attacks.
• sanitize – removes the SQL injection attack and forwards the request to the web server.
• uri-blist-check file-name – Enforces the rules contained within a WAF policy file for the URI Black List.
For more information see, “URI Black List” on page 113.
• 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 114.
• url-check – The URL Check allows users to access web pages only by clicking hyperlinks on your pro-
tected 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 typing 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 131.
• url-options option – This command is used to normalize requested URLs.
page 98
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Optional Configuration
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.
• decode-plus-chars - To be consistent in pattern matching inside WAF module, decode '+' into in a 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 containing XML
code are checked for compliance with the XML 1.0 specification. (See “XML Format Checks” on page 26 for
details.)
• xml-limit – XML parsing limits. (See “XML Limit Checks” on page 28 for details.)
• max-attr num – Limits the maximum number of attributes/children each individual element 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.
• max-elem num – Limits the maximum number of any one type of element per XML document.
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.
page 99
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Optional Configuration FFee
e
• 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 inappropriate SQL special characters or
keywords that might indicate the presence of an SQL Injection Attack (See “XML SQL Injection Checks” on
page 31 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 application security. (See “XML Validation Checks” on
page 26 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 30 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 112.
• reject – denies requests that contain cross-site scripting.
• sanitize – removes the detected XSS script and forwards the request to the web server.
• 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 pro-
tect against cookie tampering by encrypting cookies before sending the server replies to a client. (See
“Cookie Encryption” on page 137.)
• 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.
NOTE: Do not enter the secret-encrypted option when configuring this check. This option
is placed into the configuration by the WAF to indicate that the string is the
encrypted form.
page 100
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Optional Configuration
• pcre-mask options pcre-pattern – Use this command to masks patterns in a response that match the
specified PCRE pattern.
• For options you can enter the following:
• keep-end num-length – Specifies the number of unmasked characters 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.
• For pcre-pattern, enter a PCRE expression. (See “Writing PCRE Expressions” on page 117.)
NOTE: You can configure PCRE patterns to match only on a fixed-length string. For this
reason, wildcard characters that can mask excessively 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 “\+”
• 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” characters in a response.
page 101
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Optional Configuration FFee
e
page 102
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Event Types and Where They Are Logged
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 sec-
tions:
Deny actions are not written to the log. To view the configured response
to denied client requests, check the WAF template currently 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.
page 103
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Event Types and Where They Are Logged FFee
e
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.
page 104
ACOS 5.1.0 Web Application Firewall Guide
Feedback
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
page 105
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Log Format FFee
e
• 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
page 106
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Log Format
• 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 following ele-
ments:
• request – URL in the request. (The request only contains the URL and is not
enclosed in “” marks.)
• deny
• allow
• sanitize
• learn
page 107
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Log Examples FFee
e
• Bot Check
• Learning Mode
page 108
ACOS 5.1.0 Web Application Firewall Guide
Feedback
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
NOTE: For more log examples, see “WAF Deployment and Logging Examples”
on page 127.
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
page 109
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Log Examples FFee
e
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:
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.
page 110
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Pre-Loaded WAF Policies
WAF Policy Files (also referred to as WAF Definitions) give you the ability to define a set of rules for cus-
tomized 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.
page 111
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Pre-Loaded WAF Policies FFee
e
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 con-
figure 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, headers, and POST bodies of client
requests. This type of policy file is useful for websites that use Javascript-based web content.
page 112
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Pre-Loaded WAF Policies
The URI Black List takes priority over a URI White List. That is, even if a URI matches acceptance crite-
ria 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.
page 113
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Pre-Loaded WAF Policies FFee
e
Table 6 lists URI White List criteria in the default “uri_wlist_defs” file.
Response Protection
This section describes policy-based security checks for outbound responses from the web server.
page 114
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Customize WAF Policy Files
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 incorpo-
rates aspects of PCRE expressions for writing WAF policies, but does not support full PCRE functional-
ity.
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
page 115
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Customize WAF Policy Files FFee
e
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 auto-
matically applied during creation.
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 display:
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 117.
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
page 116
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Customize WAF Policy Files
Delete 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.
General Guidelines
This section summarizes common characters used in PCRE expressions and provides a quick refer-
ence 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.
page 117
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Customize WAF Policy Files FFee
e
PCRE Characters
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.
Basic Syntax
WAF policy files consist of PCRE expressions and comment lines. Lines with PCRE expressions are
structured as follows:
page 118
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Customize WAF Policy Files
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 sin-
gle 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.
(builtbottough|bunnyslippers|capture|cegbfeieh|cherrypicker|cheesebot|chinaclaw|cicc|civa|
clipping|collage|collector|copyrightcheck|cosmos|crescent|custo|cyberalert|deweb|diagem|di
gger|digimarc|diibot|directupdate|disco|dittospyder|download accelerator|download
demon|download wonder)
page 119
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Customize WAF Policy Files FFee
e
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}
page 120
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Configure an HTTP Policy Template
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 policy
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 following:
• Using the GUI – “Add/Edit a WAF Template” on page 60
• Using the CLI – “Create a WAF Template” on page 91
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.
page 121
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Configure an HTTP Policy Template FFee
e
• 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 speci-
fied string.
• Contains string – matches if the specified 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.
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.
page 122
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Bind the HTTP Policy Template to the Virtual Port
Use the GUI to Bind the HTTP Policy Template to a Virtual Port
To bind the HTTP policy to an existing 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 128.
page 123
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Bind the HTTP Policy Template to the Virtual Port FFee
e
page 124
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Displaying WAF Statistics
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.
page 125
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Clearing WAF Statistics FFee
e
• 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 175 for more information about this CLI command.
page 126
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Initial Configuration
This chapter provides some examples for WAF deployment. Since logging is a crucial part of WAF con-
figuration 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.
The following commands create the server configuration and add it to a TCP service group:
page 127
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Initial Configuration FFee
e
ACOS(config-real server)#exit
ACOS(config)#slb service-group waf-log tcp
ACOS(config-slb svc group)#member waf-log1 514
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 tem-
plate to the logging template.
To begin, the following commands create server configurations for the web servers to be load balanced
and protected by the WAF:
page 128
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Learning
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 mes-
sages 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 traf-
fic.
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.
page 129
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Learning FFee
e
CAUTION: While Learning or Passive Mode is in operation, the WAF does not block
any traffic. Only Active Mode blocks traffic.
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.
page 130
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Learning
page 131
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Learning FFee
e
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 following
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 follow-
ing commands verify that the URL Check policy file is created and display the contents 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
...
page 132
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Learning
Syntax: Check
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 134.) 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 policy file without first
deploying a WAF template in Learning Mode with the URL Check
enabled.
page 133
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Response Header Filtering FFee
e
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 49.)
Here is an example of header fields in the HTTP response from a server. The fields shown in bold pro-
vide information about the server OS.
Here is the same excerpt from the server response, with the OS-identifying headers removed:
page 134
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Response Header Filtering
The response received by the client does not contain the OS-identifying headers.
page 135
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
SQLIA Check FFee
e
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 sup-
posed to contain SQL code.
page 136
ACOS 5.1.0 Web Application Firewall Guide
Feedback
Cookie Encryption
ACOS(config-waf)#xss-check reject
Since the reject option is used in the configuration, a Deny page such as the one in “Deny page” on
page 137 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.
page 137
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
Cookie Encryption FFee
e
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:
NOTE: Do not enter the secret-encrypted option when configuring this check.
This option is placed into the configuration by the WAF to indicate that
the string is the encrypted form.
page 138
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF templates allow you to easily enforce the following security filters.
page 139
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
FFee
e
GUI:
page 140
ACOS 5.1.0 Web Application Firewall Guide
Feedback
GUI:
URI Black List Enforces the rules contained within a WAF pol- Name of a WAF policy file
icy file for the URI Black List. For more informa-
tion about URI Black Lists, see “URI Black List” Default: uri_blist_defs
on page 113.
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 Forbid-
[no] deny-action options den response to the client. The default
resp-string string returns a generic “Request
Denied!” page to the client.
GUI:
• http-resp-200 – Sends a 200 OK
Security > WAF > WAF Templates > response to the client with the speci-
+Add/Edit WAF Template , and then select fied resp-string. The default string
the HTTP Protocol Checks menu, and returns a generic “Request Denied!”
select the Allowed HTTP Methods page to the client.
multi-selection list and deselect methods not
allowed. • http-redirect – Redirects the client
to the specified URL.
Default: http-resp-403
page 141
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
FFee
e
• HEAD
GUI:
• PUT
Security > WAF > WAF Templates > • OPTIONS
+Add/Edit WAF Template , and then select
the Request Checks menu, and in the • DELETE
Allowed HTTP Methods field, click the
desired methods to highlight them. • TRACE
• CONNECT
• PURGE
GUI:
page 142
ACOS 5.1.0 Web Application Firewall Guide
Feedback
• Max Post Size – Sets the maximum content • Max Total Cookies Length - 4,096
length allowed in HTTP POST requests.
• Max Data To Parse - 65,536
• Max Query Length - Sets the maximum
length for queries. • Max Header Name Length - 64
• Max URL Length – Sets the maximum URL • Max Header Value Length - 4,096
length allowed in requests.
• Max Header Length – 4,096
[no] buf-ovf
{disable | • Max Line Length - 1,024
max-cookie-len |
max-cookie-name-len | • Max Parameter Name Length - 256
max-cookie-value-len |
max-cookies-len | • Max Parameter Total - 4,096
max-data-parse |
max-hdr-name-len • Max Parameter Value Length - 4,096
max-hdr-value-len |
max-hdrs-len | • Max Query Length - 1,024
max-line-len |
max-parameter-name-len | • Max URL Length – 1,024
max-parameter-total-len |
max-parameter-value-len | • Max POST content size – 20,480
max-post-size |
max-query-len |
max-url-len} [bytes]
[no] max-parameters
GUI:
page 143
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
FFee
e
GUI:
Form Checks that user input to form fields is consist- Enabled or Disabled
Consistency ent with the intended format.
Check Default: Disabled
[no] form-consistency-check
GUI:
HTTP Check Checks that user requests are compliant with Enabled or Disabled
HTTP protocols.
Default: Disabled
[no] http-check
GUI:
Session Check Checks that user requests match a unique ses- 1-1440
sion ID created for them.
Default: 10
[no] session-check [secs]
GUI:
page 144
ACOS 5.1.0 Web Application Firewall Guide
Feedback
page 145
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
FFee
e
[no] referer-check
{enable | only-if-present}
GUI:
SQL Injection Checks for SQL strings to protect against SQL One of the following:
Attack (SQLIA) injection attacks. This check uses the list of
Check defined SQL commands in the “sqlia_defs” WAF • Reject
policy file. See “SQL Injection Attack Check” on
page 112. • Disabled
page 146
ACOS 5.1.0 Web Application Firewall Guide
Feedback
URL Check Select this option to prevent users from access- Enabled or Disabled
ing the URLs of your website directly. The URL
Check allows users to only access web pages Default: Disabled
by clicking a hyperlink on your protected web-
site.
Note: 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 131.
[no] url-check
GUI:
page 147
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
FFee
e
• Decode Entities
• 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:
page 148
ACOS 5.1.0 Web Application Firewall Guide
Feedback
GUI:
Filter Response Removes the web server’s identifying headers Enabled or Disabled
Headers in responses. By default, this check uses the
“allowed_resp_codes” WAF policy file for a list Default: Disabled
of accepmenule HTTP response codes.
[no] filter-resp-hdrs
GUI:
Hide Response “Cloaks” your web servers by hiding response Enabled or Disabled
Codes codes from them instead of forwarding them to
the client. Default: Disabled
page 149
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
FFee
e
GUI:
Cookie Encryp- Uses the specified Secret string to encrypt and Cookie Name – String or PCRE expres-
tion Secret decrypt cookies in server to client communica- sion
tion. For Cookie Name, you can enter the name
of a specific cookie as a string, or a PCRE Cookie Encryption Secret – String
expression to encrypt all cookies which match
the expression. Default: Not set
[no] cookie-encrypt
{cookie-name | pcre-pattern}
GUI:
page 150
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Template Commands
This chapter lists the CLI commands for WAF. The commands are organized into the following section:
• waf template
page 151
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Template Commands FFee
e
waf
Description Enable WAF related commands for global, policy, template, WSDL, or XML
schema.
Parameter Description
global WAF global statistics sampling.
policy Manage WAF Policy files.
template Manage WAF template configuration.
wsdl Manage Web Services Definition Language files.
xml-schema Manage XML-Schema files.
Default NA
waf template
Description Configure a WAF template.
Parameter Description
template-name Name of the template.
This command changes the CLI to the configuration level for the specified
WAF template, where the following commands are available.
page 152
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Template Commands
Command Description
[no] brute-force-pro- Configures protection against brute-force attacks. The sub-options for this
tection command include the following:
• global – When enabled, this option causes the WAF to maintain a single
counter for all clients, as opposed to having a separate counter for each cli-
ent. When enabled, all clients are locked out for the configured lockout-period
once the lockout-limit is reached. Similarly, all responses include a challenge
once the challenge-limit is reached. This option is disabled by default.
• lockout-period num – This option sets the number of seconds that a client
should be locked out. Specify a value from 0-1800; default is 600.
• test-period num – This option sets the number of seconds between clear-
ing of the brute-force counters. The range is 0-600; default is 60.
• disable – This option disables brute force protections. This is the default
option.
page 153
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Template Commands FFee
e
Command Description
[no] cookie-security Configures protection to secure cookies. The sub-options for this command
include the following:
• add-http-only – This option adds ‘HttpOnly’ flag to cookies that are not in
the set-cookie-policy list. The option is ‘ON’ by default.
• add-secure – This option adds ‘Secure’ flag to cookies that are not in the
set-cookie-policy list. The option is ‘ON’ by default.
• encrypt secret – This option encrypts the cookies that are not in the set-
cookie-policy list.
• ssn-mask – This option 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] deny-action option Configures the action to be taken when the request is denied. The options for
this command include the following:
• http-redirect – This option sends a 302 Found redirection address to the
client with the URL specified in the url-string.
page 154
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Template Commands
Command Description
[no] deploy-mode option Configures deployment mode of WAF. The options for this command include
the following:
• active – This option is the standard operational mode. Use active mode if
you want the WAF to sanitize or drop traffic based on the configured WAF
policies. This is the default option.
• passive – This option 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 fil-
tering.
page 155
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Template Commands FFee
e
Command Description
[no] form-protection Configures web form protection. The sub-options for this command include the
following:
• csrf-check – This option tags the fields of a web form to protect against
Cross-Site Request Forgery (CSRF). By default, it is disabled.
• non-ssl– This option checks whether SSL is used for response with
forms.
• password-check option – This option checks for the password in the form.
• non-masked – This option checks forms that have a password field with a
textual type resulting in this field being unmasked.
• non-SSL – This option checks forms that has a password field if the form
is not sent over an SSL connection.
page 156
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Template Commands
Command Description
[no] http-limit-check Configures HTTP limit check. The sub-options for this command include the
following:
• max-entities num – This option sets the maximum number of MIME enti-
ties allowed in the request. Default value is 10.
• max-headers num – This option sets the total number of headers allowed in
the request. Default value is 64.
page 157
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Template Commands FFee
e
Command Description
[no] http-limit-check • max-param-name-length num – This option sets the maximum query/ POST
(continued) parameter name length allowed in the request. Default value is 256.
• max-params num – This option sets the total number of query/POST allowed
in the request. Default value is 64.
• max-url-length num – This option sets the maximum length of the URL.
Default value is 4096.
page 158
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Template Commands
Command Description
[no] http-protocol- Configures HTTP protocol check. The sub-options for this command include
check the following:
• allowed-headers name – This option lists the allowed HTTP headers.
Default is "".
• 0.9 – HTTP/0.9
• 1.0 – HTTP/1.0
• 1.1 – HTTP/1.1
• 2 – HTTP/2
page 159
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Template Commands FFee
e
Command Description
[no] json-check Configures check for incoming json requests. The sub-options for this com-
mand include the following:
• max-depth num – This option limits the maximum depth in a JSON value to
a maximum recursion depth ranging from 0–4096. The default value is 16.
• max-string-length num – This option limits the length of a string (in bytes)
in a JSON request for a name or a value. Range is 0–4096 and the default
value is 64.
[no] log-succ-reqs Enabling this option creates a log debug message on the successful comple-
tion of WAF requests, and not just for errors.
page 160
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Template Commands
Command Description
[no] request-check Configures request check. The sub-options for this command include the fol-
lowing:
• uri-query – This option checks for Command Injection in uri query argu-
ments.
• url-blacklist – This option specifies the name of the WAF policy list file to
blacklist.
• url-whitelist – This option specifies the name of the WAF policy list file to
whitelist.
page 161
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Template Commands FFee
e
Command Description
[no] template option The option for this command include the following:
• logging - Applies a configured logging template to the WAF template.
[no] user-tag name Configures the customized tag.
[no] xml-check Configures XML check. The sub-options for this command include the follow-
ing:
• format – This option checks HTTP body for XML format compliance.
• max-elem-depth num – This option checks maximum recursion level for ele-
ment definition. The default value is 256.
• wsdl – This option specifies a WSDL file for verifying XML body contents.
page 162
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Template Commands
csp
Description Insert HTTP header Content-Security-Policy (CSP) if necessary.
Parameter Description
<csp_name> CSP header value, for example, "script-src 'none'.
Length of string, has the range, 1 to 255.
[no] csp <csp_name> Disables the CSP.
insert-if-not-exist Only insert the header when it does not exist.
insert-always Always insert the header even when there is a header
with the same name.
Default Disabled
form-protection
Description Configure form-protection for the WAF template.
Syntax form-protection
Default NA
page 163
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Template Commands FFee
e
form-check
Description Add configuration checks whether POST method is used for RESPONSE and
REQUEST with forms.
Parameter Description
request-non-post Check whether POST is used for request with forms.
response-non-post Check whether form method POST is used for
response with forms.
Default NA
Command Description
virtual-server-name Name of the virtual server.
portnum Virtual port number.
Default N/A
Mode All
page 164
ACOS 5.1.0 Web Application Firewall Guide
Feedback
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
page 165
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Template Commands FFee
e
- 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
page 166
ACOS 5.1.0 Web Application Firewall Guide
Feedback
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
page 167
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Template Commands FFee
e
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.
• Failed – Total number of requests that were screened for bots and did not match.
page 168
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Template Commands
• URL too long – Total number of requests that included URL headers which
exceeded the configured limit.
• Request line too long - Total number of request lines that exceeded the config-
ured limit.
• Query too long - Total number of request queries that exceeded the configured
limit.
• Cookie too long – Total number of requests that included cookies which
exceeded the configured limit.
• Total Cookies too long - Total number of cookies that exceeded the configured
limit.
• Cookie Name too long - Total number of cookie names that exceeded the config-
ured limit.
• Cookie Value too long - Total number of cookie values that exceeded the config-
ured limit.
• Headers too long – Total number of requests that included headers which
exceeded the configured limit.
• Header Name too long - Total number of header names that exceeded the config-
ured limit.
• Header Value too long - Total number of header values that exceeded the config-
ured limit.
• POST body too long – Total number of POST requests with content length which
exceeded the configured limit.
• Parameter name too long - Total number of parameter names that exceeded the
configured limit.
• Parameter value too long - Total number of parameter values that exceeded the
configured limit.
• Parameter total too long - Total number of requests that exceeded the configured
limit of allowed parameters.
• Too much data to parse - Total number of request that were denied because they
exceeded the configured data limit.
• Too many parameters - Total number of requests that were denied because they
exceeded the configured parameter limit.
• Too many cookies – Total number of requests that were denied because they
exceeded the configured cookie limit.
• Too many headers – Total number of requests that were denied because they
exceeded the configured header limit.
• Too many MIME entities - Total number of requests that were denied because
they contained too many MIME entities.
page 169
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Template Commands FFee
e
• Failed – Total number of requests that contained a method that is not in the
Allowed HTTP Methods list.
HTTP Protocol Check Counters for responses that adhere to HTTP protocol:
• Failed – Number of requests that did not pass the referer header check.
• No Referer (Redirect) – Number of requests that did not contain a referer header.
URI White List Check URI White List counters:
• Success (Match) – Number of requests that matched criteria in the URI White
List and were accepted.
• Failed – Number of requests that did not match criteria in the URI White List and
were denied.
URI Black List Check URI Black List counters:
• 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:
• Failed – Number of requests which did not match the nonce for the web form
and denied.
page 170
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Template Commands
• Amex
• Diners
• Visa
• MasterCard
• Discover
• JCB
SSN Mask Counters for US social security number checks:
• 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 discov-
ered and masked.
Cookie Counters for cookie encryption:
Encryption
• Encrypt Success – Number of times a cookie was successfully encrypted with
the specified secret string.
• Encrypt Limit Exceeded – Number of times cookies were not encrypted because
of the a configured limit.
• Decrypt Failed – Number of client requests that were rejected because they
could not be decrypted.
page 171
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Template Commands FFee
e
• URL Success – Number of requests that passed the SQLIA check for the URL.
• URL Sanitized – Total number of requests that the URL component was sani-
tized of an SQL attack pattern and accepted.
• 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 con-
tained an SQL injection attack in the POST body of a request.
• XML Success – Number of requests that passed the SQLIA check for XML.
• Cookie Success – Number of requests that passed the cookie inspection portion
of the XSS check.
• URL Success – Number of requests that passed the URL inspection portion of
the XSS check.
• URL Sanitized – Number of requests that contained an XSS attack in the URL,
were sanitized, and accepted.
• URL Rejected – Number of requests that contained an XSS attack in the URL and
were denied.
• POST Success – Number of requests that passed the POST body inspection por-
tion of the XSS check.
• POST Sanitized – Number of requests that contained an XSS attack in the POST
body, were sanitized, and accepted.
• POST Rejected – Number of requests that contained an XSS attack in the POST
body and were denied.
• XML Success – Number of requests that passed the XML inspection portion of
the XSS check.
• XML Rejected – Number of requests that contained an XSS attack in the XML
and were denied.
page 172
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Template Commands
• too many array values - Number of JSON objects with too many array values.
• too many object members - Number of JSON objects with too many members.
• string too long - Number of JSON objects with invalid string lengths.
XML Format Check Stats for performing XML format parsing and validation and making sure the XML
object is well constructed.
• Parse Failure - Number of XML objects that could not be parsed due to some
error.
• too many attributes - Number of XML objects with too many attributes.
• attribute name too long - Number of XML objects with invalid attribute names.
• attribute value too long - Number of XML objects with invalid attribute values.
• CDATA field too long - Number of XML objects with invalid CDATA fields.
• too many elements - Number of XML objects with too many elements.
• too many children - Number of XML objects with too many children.
• elements nested too deep - Number of XML objects with improper nesting.
• element name too long - Number of XML objects with improper element names.
• too many entity expansions - Number of XML objects with too many entity expan-
sions.
• entity expansions nested too deep - Number of XML objects with improper entity
nesting.
• too many namespaces - Number of XML objects with too many namespaces.
• namespace URI too long - Number of XML objects with improper URI lengths.
• XML Schema failure - Number of XML schemas that could not be parsed.
page 173
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF Template Commands FFee
e
• Parse Failure - Number of SOAP messages that could not be processed due to
error.
• WSDL Failure - Number of times a SOAP message fails validation against the
WSDL file.
Password Security Counters for the Password Security check:
Check
• Non masked passwords Rejected – when a form has an input field for a pass-
word which is not masked (so when you type your password the characters are
not replaced by asterisks)
• Password autocomplete Rejected – When the password field of a form has auto-
complete turned on, which means that an unauthorized person with access to
the browser will not need to actually type in the password
Redirect Whitelist Counters for the Redirect Whitelist check:
Check
• Learned – Number of redirect locations (URIs) learned during Learning Mode and
added to the redirect white-list.
• Success – Number of requests that matched a URI entry in the redirect white-list
and were accepted.
• Failed – Number of requests that did not match a URI entry in the redirect white-
list and were blocked.
Form non-SSL Rejected Total number of forms that were rejected due to having been submitted over a non-
SSL connection.
Form non-POST Number of times a form is sent using an HTTP method other than POST.
Rejected
Form no-cache header Number of times WAF inserted a pragma to tell the client not to cache the content.
inserted
Response Code Hidden Number of times WAF masked out an HTTP response code and replaced it with a
generic 200/403.
Response headers fil- Total number of response headers that WAF sanitized and forwarded.
tered
Learning updates Number of additional rules generated from the WAF learning mechanisms when the
WAF is operating in Learning Mode.
page 174
ACOS 5.1.0 Web Application Firewall Guide
Feedback
WAF Template Commands
Command Description
virtual-server-name Name of the virtual server.
portnum Virtual port number.
Default N/A
page 175
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF File Management Commands FFee
e
Parameter Description
file-name Name of a configured WAF policy file.
page 176
ACOS 5.1.0 Web Application Firewall Guide
Feedback
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
page 177
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF File Management Commands FFee
e
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
page 178
ACOS 5.1.0 Web Application Firewall Guide
Feedback
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
page 179
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF File Management Commands FFee
e
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
page 180
ACOS 5.1.0 Web Application Firewall Guide
Feedback
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
Replace file-name with the name of the WAF XML-Schema file to be deleted.
Default N/A
page 181
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF File Management Commands FFee
e
Replace file-name with the name of the WAF XML-Schema 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 XML-Schema file.
destination-name This is the new name of the WAF XML-Schema file.
Default N/A
page 182
ACOS 5.1.0 Web Application Firewall Guide
Feedback
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
partition-name} partition or the specified private partition.
Default N/A
Mode All
Example The following command lists all WAF policy files, for all partitions:
page 183
ACOS 5.1.0 Web Application Firewall Guide
FeedbackFF
WAF File Management Commands FFee
e
page 184
ACOS 5.1.0 Web Application Firewall Guide
page 185
CONTACT US
1 a10networks.com/contact