A10 Networks WAF Guide

Web Application Firewall Guide

ACOS 4.1.1-P1 Web Application Firewall Guide for A10 Thunder™ Series and AX™ Series 22 November 2016

© 2016 A10 Networks, Inc. Confidential and Proprietary - All Rights Reserved Information in this document is subject to change without notice.

Patent Protection A10 Networks products are protected by patents in the U.S. and elsewhere. The following website is provided to satisfy the virtual patent marking provisions of various jurisdictions including the virtual patent marking provisions of the America I nvents 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/com https://www.a10 networks.com/company/legal-notices/a10pany/legal-notices/a10-virtual-patent-marking virtual-patent-marking..

Trademarks The A10 logo, logo, A10 Harmony, Harmony, A10 Lightning, Lightning, A10 Networks, Networks, A10 Thunder, Thunder, aCloud, aCloud, ACOS, Affinity, aFleX, aFleX, aFlow, aFlow, aGalaxy, aGAPI, aGAPI, aVCS, AX, aXAPI, IDsentrie, IP-to-ID, SSL Insight, SSLi, Thunder, Thunder TPS, UASG, and vThunder are trademarks or registered trademarks of A10 Networks, Inc. in the United States and other countries. countries. All other trademarks are property of their respective respective owners.

Confidentiality This document contains confidential confidential materials proprietary proprietary to A10 Networks, Networks, Inc. This document and information information and and ideas herein may not be disclosed, copied, rep roduced or distributed to anyone outside A10 Networks, Inc. without prior written consent of A10 Networks, Inc.

A10 Networks Inc. Software License and End User Agreement Software for all A10 Networks products contains trade secrets of A10 Networks and its subsidiaries and Customer agrees to treat Software as confidential information. Anyone who uses the Software does so only in compliance with the terms of the End User License Agreement (EULA), provided later in this document or available separately. Customer shall not: 1. reverse engineer, reverse compile, reverse de-assemble or otherwise translate the Software by any means 2. sublicense, rent or lease the Software.

Disclaimer This document document does not create create any express or implied warranty about A10 Networks Networks or about its products or services, including but but not limited to fitness for a particular use and non-infringement. A10 Networks has made reasonable efforts to verify that the information contained herein is accurate, but A10 Networks assumes no responsibility for its use. All information is provided "as-is." "as-is." The product specifications and features described in this publication are based on the latest information available; however, specifications specifications are sub ject to change without without notice, notice, and certain features features may not not be available upon upon initial product product release. Contact Contact A10 Networks Networks for current information regarding regarding its products or services. A10 Networks’ products and services are subject to A10 Networks’ standard terms and conditions.

Environmental Considerations Some electronic components may possibly contain dangerous substances. For information information on specific component types, please contact the manufacturer of that component. Always consult local authorities for regulations regarding proper disposal of electronic components in your area.

Further Information For additional information information about A10 products, terms and conditions of delivery, and pricing, contact your nearest A10 Networks location, which can be found by visiting www.a10networks.com www.a10networks.com..

© 2016 A10 Networks, Inc. Confidential and Proprietary - All Rights Reserved Information in this document is subject to change without notice.

Patent Protection A10 Networks products are protected by patents in the U.S. and elsewhere. The following website is provided to satisfy the virtual patent marking provisions of various jurisdictions including the virtual patent marking provisions of the America I nvents 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/com https://www.a10 networks.com/company/legal-notices/a10pany/legal-notices/a10-virtual-patent-marking virtual-patent-marking..

Trademarks The A10 logo, logo, A10 Harmony, Harmony, A10 Lightning, Lightning, A10 Networks, Networks, A10 Thunder, Thunder, aCloud, aCloud, ACOS, Affinity, aFleX, aFleX, aFlow, aFlow, aGalaxy, aGAPI, aGAPI, aVCS, AX, aXAPI, IDsentrie, IP-to-ID, SSL Insight, SSLi, Thunder, Thunder TPS, UASG, and vThunder are trademarks or registered trademarks of A10 Networks, Inc. in the United States and other countries. countries. All other trademarks are property of their respective respective owners.

Confidentiality This document contains confidential confidential materials proprietary proprietary to A10 Networks, Networks, Inc. This document and information information and and ideas herein may not be disclosed, copied, rep roduced or distributed to anyone outside A10 Networks, Inc. without prior written consent of A10 Networks, Inc.

A10 Networks Inc. Software License and End User Agreement Software for all A10 Networks products contains trade secrets of A10 Networks and its subsidiaries and Customer agrees to treat Software as confidential information. Anyone who uses the Software does so only in compliance with the terms of the End User License Agreement (EULA), provided later in this document or available separately. Customer shall not: 1. reverse engineer, reverse compile, reverse de-assemble or otherwise translate the Software by any means 2. sublicense, rent or lease the Software.

Disclaimer This document document does not create create any express or implied warranty about A10 Networks Networks or about its products or services, including but but not limited to fitness for a particular use and non-infringement. A10 Networks has made reasonable efforts to verify that the information contained herein is accurate, but A10 Networks assumes no responsibility for its use. All information is provided "as-is." "as-is." The product specifications and features described in this publication are based on the latest information available; however, specifications specifications are sub ject to change without without notice, notice, and certain features features may not not be available upon upon initial product product release. Contact Contact A10 Networks Networks for current information regarding regarding its products or services. A10 Networks’ products and services are subject to A10 Networks’ standard terms and conditions.

Environmental Considerations Some electronic components may possibly contain dangerous substances. For information information on specific component types, please contact the manufacturer of that component. Always consult local authorities for regulations regarding proper disposal of electronic components in your area.

Further Information For additional information information about A10 products, terms and conditions of delivery, and pricing, contact your nearest A10 Networks location, which can be found by visiting www.a10networks.com www.a10networks.com..

A10 Thunder Series and AX Series Contents

Overview ...................................... ................. .......................................... ........................................ ........................................ ......................................... ........................................ ........................................ ........................... ....... 9 WAF WAF Overview.................................. Overview.......................................................... .................................................. .................................................. ................................................... ................................................... ................................9 ........9 WAF WAF External Logging....................................................... Logging................................................................................. ................................................... .................................................... ........................................... ................10 10 Protection Against Common Web Attacks ............................................... .......................................................................... .............................................. .................................... .................10 10 Buffer Overflow Attacks ......................................................................................................................................................................10 Cookie Tampering ..................................................................................................................................................................................11 Forceful Browsing ...................................................................................................................................................................................11 Web Form Security Attacks ...............................................................................................................................................................11 WAF WAF Security Models......................................... Models................................................................. .................................................. ................................................... .................................................... ................................... ........12 12 Positive Security Model .......................................................................................................................................................................12 Negative Security Model ....................................................................................................................................................................12 Request Protection............................ Protection...................................................... .................................................. ................................................... ................................................... ..................................................13 ..........................13 Compare Request URI to White List and Black List ............................................................................................................13 White List ............................................................... ................................................................................................. ................................................................... ................................................................... ................................................................. ............................................. .............. 13 Black List ................................................................... ....................................................................................................... ................................................................. ............................................................... ................................................................. ............................................. .............. 13

URL Check ...................................................................................................................................................................................................14 Scan Request for Threats ....................................................................................................................................................................15 Bot Check ............................................................... ............................................................................................... ................................................................. .................................................................. ............................................................... ............................................... ................. 15 Form Field Consistency Check .............................................................. ............................................................................................ .................................................................. .................................................................. ................................... ..... 16 Referer Check .......................................................... ........................................................................................... .................................................................... ................................................................... ............................................................... .......................................... ........... 16 HTTP Protocol Compliance Check ...................................................................... ........................................................................................................ ................................................................. ................................................... .................... 16 HTML Cross-Site Scripting (XSS) Check .............................................................. ................................................................................................... .................................................................... ............................................. .............. 17 Buffer Overflow Over flow Check ....................................................................... ......................................................................................................... ................................................................ ............................................................. ............................................. .............. 18 HTML SQL Injection Check .................................................................... .................................................................................................... ............................................................... ............................................................... ........................................ ........ 18 Allowed HTTP HT TP Methods Check .................................................................... .................................................................................................... .................................................................. .............................................................. ............................ 18 Maximum Cookies Check ..................................................................... ....................................................................................................... ................................................................ .............................................................. ........................................ ........ 19 Maximum Headers Check .................................................................. .................................................................................................... ................................................................... ................................................................. ........................................ ........ 19 Session Checks ................................................................ .................................................................................................. ................................................................. ................................................................. ................................................................. .................................. ... 20 Password Password Security ............................................................... .................................................................................................. ................................................................. ................................................................ .............................................................. ............................ 20 Open Redirect Mitigation ............................................................... ............................................................................................... ................................................................. ................................................................ ............................................. .............. 22 Normalization Enhancements for URL Options O ptions ................................................................... ....................................................................................................... ........................................................... ....................... 24

WAF XML Checks ....................................................................................................................................................................................26 XML Format Checks ............................................................... ................................................................................................ .................................................................. ................................................................... ......................................................... ....................... 27 XML Validation Checks ............................................................. ............................................................................................. .................................................................... ................................................................... ................................................... .................... 27 XML Limit Checks ..................................................................... ....................................................................................................... ................................................................. ................................................................. ......................................................... ....................... 29 XML Cross-Site Sc ripting Checks ............................................................... .............................................................................................. ............................................................... ............................................................. ................................ ... 31 XML SQL Injection Checks ............................................................. ............................................................................................ .................................................................. .................................................................. ............................................. .............. 32

WAF SOAP Checks ..................................................................................................................................................................................33 SOAP Format Checks ............................................................ ............................................................................................ .................................................................. .................................................................. ......................................................... ......................... 33 SOAP Validation Checks ........................................................... ......................................................................................... ........................................................................ ........................................................................ .............................................. ................ 34

WAF JSON Checks ..................................................................................................................................................................................36 JSON Format Checks ............................................................. ............................................................................................ .................................................................. ..................................................................... ......................................................... ....................... 36 JSON Limit Checks ............................................................. .............................................................................................. .................................................................. ................................................................... .............................................................. ............................ 37

Geo-location Based Blocking ..........................................................................................................................................................38 Filter Requests Using an HT TP Policy .............................................................. .................................................................................................. ................................................................... ................................................... .................... 38 Filter Requests Using an ACL ................................................................ ............................................................................................... .................................................................... .................................................................... .................................. ... 41

Configuring the WAF with aFleX Scripts ..................................................................................................................................41

page 3 | ACOS 4.1.1-P1 Web Application Firewall Guide - 22 November 2016

A10 Thunder Series and AX Series Contents WAF aFleX Commands ................................................................................................................................................................................... 42 WAF Events ............................................................................................................................................................................................................. 43

Response Protection........................................................................................................................................................43 Mask Sensitive Content .......................................................................................................................................................................44 CCN Mask ................................................................................................................................................................................................................ 44 SSN Mask ................................................................................................................................................................................................................. 44 PCRE Mask ............................................................................................................................................................................................................... 45

Cloak Responses ......................................................................................................................................................................................45 Send Instrumented Responses ......................................................................................................................................................45 Cross Site Request Forgery Check ........................................................................................................................................................... 46 Form Field Consistency Check ................................................................................................................................................................... 46 Cookie Encryption .............................................................................................................................................................................................46

PCI 6.6 Compliance ..........................................................................................................................................................47 ACOS WAF achieves ICSA Certification .....................................................................................................................................47 How Does the ACOS WAF Achieve PCI DSS Compliance? ............................................................................................47

WAF Operational Modes ......................................................................................................................................49 Overview.............................................................................................................................................................................. 49 Learning Mode .........................................................................................................................................................................................51 Passive Mode .............................................................................................................................................................................................52 Active Mode ...............................................................................................................................................................................................54 Setting the WAF Operational Mode........................................................................................................................... 56

Configuring the WAF Using the GUI ................................................................................................................57 Configuration Overview................................................................................................................................................. 57 Bind the WAF Template to the Virtual Port.............................................................................................................. 58 Configure a WAF Template............................................................................................................................................ 59 Configuring General Settings ..........................................................................................................................................................59 Configuring HTTP Request Checks ..............................................................................................................................................60 Configuring HTML Request Checks ............................................................................................................................................63 Configuring Injection Checks .........................................................................................................................................................64 Configuring Overflow Checks .........................................................................................................................................................65 Configuring Session Checks ............................................................................................................................................................66 Configuring Web Service Checks .................................................................................................................................................67 Configuring Cookie Encryption Checks ...................................................................................................................................70 Configuring Server Filter Checks ...................................................................................................................................................72 Configuring Content Filter Checks ............................................................. .................................................................. ...............73 Configuring Form Checks ..................................................................................................................................................................74 Configuring Password Checks ........................................................................................................................................................75 Create a WAF File ..............................................................................................................................................................76 Configure an HTTP Policy Template...........................................................................................................................78 WAF Reporting...................................................................................................................................................................81 Configure External Logging (recommended) ........................................................................................................ 84 Configure Log Servers .........................................................................................................................................................................85 Add Server to Service Group ...........................................................................................................................................................86

ACOS 4.1.1-P1 Web Application Firewall Guide - 22 November 2016 | page 4


Configure the Logging Template .................................................................................................................................................88 Apply the Log Template to the WAF Template ............................................................................................. .......................89

Configuring the WAF Using the CLI .................................................................................................................91 Required Configuration..................................................................................................................................................91 Create a WAF Template .......................................................................................................................................................................91 Bind the WAF Template to the HTTP/HTTPS Virtual Port ...............................................................................................92 External Logging Configuration..................................................................................................................................92 Optional Configuration .................................................................................................................................................. 93 Set Deployment Mode ........................................................................................................................................................................94 Customize WAF Policy Files ..............................................................................................................................................................94 Configure Security Checks for Requests ...................................................................................................................................95 Configure Security Checks for Responses ...............................................................................................................................99

WAF Event Logging ............................................................................................................................................. 101 WAF Event Types and Where They Are Logged ...................................................................................................101 Log Format........................................................................................................................................................................103 WAF Log Examples .........................................................................................................................................................104 Basic Log Message ..............................................................................................................................................................................105 Bot Check ..................................................................................................................................................................................................105 Learning Mode ......................................................................................................................................................................................106

WAF Policy Files .................................................................................................................................................... 107 Pre-Loaded WAF Policies..............................................................................................................................................107 Request Protection .............................................................................................................................................................................108 Bot Check ..............................................................................................................................................................................................................108 XSS Check .............................................................................................................................................................................................................108 SQL Injection Attack Check ........................................................................................................................................................................108 URI Black List ........................................................................................................................................................................................................109 URI White List ......................................................................................................................................................................................................110

Response Protection ..........................................................................................................................................................................110 Allowed HT TP Response Codes ..............................................................................................................................................................110

Customize WAF Policy Files.........................................................................................................................................111 Syntax Check ..........................................................................................................................................................................................111 Using the CLI ..........................................................................................................................................................................................111 Configure Policy Files .....................................................................................................................................................................................111 Syntax Checks .....................................................................................................................................................................................................112 Manage Files .......................................................................................................................................................................................................112

Writing PCRE Expressions ...............................................................................................................................................................113 General Guidelines ..........................................................................................................................................................................................113 Example Applications ....................................................................................................................................................................................115

Overriding a WAF Template ............................................................................................................................. 117 Configure an HTTP Policy Template.........................................................................................................................117 Use the GUI to Configure an HTTP Policy Template ......................................................................................................118 Use the CLI to Configure an HTTP Policy Template .................................................................................... ...................119



Bind the HTTP Policy Template to the Virtual Port .............................................................................................119 Use the GUI to Bind the HTTP Policy Template to a Virtual Port ............................................................................ 119 Use the CLI to Bind the HTTP Policy Template to a Virtual Port ...................................................................... .......119

WAF Statistics ........................................................................................................................................................ 121 Displaying WAF Statistics.............................................................................................................................................121 Use the GUI to View WAF Statistics ...........................................................................................................................................121 Use the CLI to View WAF Statistics ............................................................................................................................................121 Clearing WAF Statistics .................................................................................................................................................121 Use the GUI to Clear WAF Statistics ..........................................................................................................................................121 Use the CLI to Clear WAF Statistics .................................................................... ....................................................................... 122

WAF Deployment and Logging Examples .................................................................................................. 123 Initial Configuration.......................................................................................................................................................123 Logging Configuration .....................................................................................................................................................................123 WAF Template Configuration .......................................................................................................................................................124 HTTP Virtual Port Configuration .................................................................................................................................................124 Learning .............................................................................................................................................................................125 Enable Learning Mode .....................................................................................................................................................................126 Generate Traffic .................................................................................................................................................................................................126 View External Log .............................................................................................................................................................................................126 View WAF Template Settings ....................................................................................................................................................................126

Generate Allowed URL Paths for the URL Check ..............................................................................................................127 Configuration Example .................................................................................................................................................................................127

Save Template Settings ....................................................................................................................................................................129 Response Header Filtering ..........................................................................................................................................129 Enable Header Response Filtering ............................................................................................................................................130 View External Log ................................................................................................................................................................................130 SQLIA Check .....................................................................................................................................................................131 Enable the SQLIA Check ..................................................................................................................................................................131 View External Log ................................................................................................................................................................................131 Cross-site Scripting Check ...........................................................................................................................................131 Enable the XSS Check .......................................................................................................................................................................132 View External Log ................................................................................................................................................................................132 Cookie Encryption ..........................................................................................................................................................133

WAF Template Reference .................................................................................................................................. 135 WAF CLI Command Reference ........................................................................................................................ 147 WAF Template Commands..........................................................................................................................................147 waf template .............................................................................................................................................................................................148 show waf stats .........................................................................................................................................................................................156 clear waf stats ...........................................................................................................................................................................................166

WAF File Management Commands..........................................................................................................................167 waf policy check .....................................................................................................................................................................................167


A10 Thunder Series and AX Series Contents waf policy copy .......................................................................................................................................................................................168 waf policy delete ....................................................................................................................................................................................168 waf policy edit ..........................................................................................................................................................................................169 waf policy max-filesize ........................................................................................................................................................................169 waf policy rename .................................................................................................................................................................................169 waf wsdl check ........................................................................................................................................................................................170 waf wsdl copy ..........................................................................................................................................................................................170 waf wsdl delete .......................................................................................................................................................................................170 waf wsdl edit .............................................................................................................................................................................................171 waf wsdl max-filesize ...........................................................................................................................................................................171 waf wsdl rename ....................................................................................................................................................................................171 waf xml-schema check .......................................................................................................................................................................172 waf xml-schema copy .........................................................................................................................................................................172 waf xml-schema delete ......................................................................................................................................................................172 waf xml-schema edit ...........................................................................................................................................................................173 waf xml-schema max-filesize .........................................................................................................................................................173 waf xml-schema rename ..................................................................................................................................................................173 show waf policy ......................................................................................................................................................................................174




A10 Thunder Series and AX Series WAF Overview

Overview

This chapter contains the following topics: •

WAF Overview

•

WAF External Logging

•

Protection Against Common Web Attacks

•

WAF Security Models

•

Request Protection

•

Response Protection

•

PCI 6.6 Compliance

WAF Overview The A10 product line provides additional security for your Web servers with the Web Application Firewall (WAF) feature. The WAF filters communication between users and Web applications to protect Web servers and sites from unauthorized access and malicious programs. This new layer of security examines incoming user requests, output from Web servers, and access to Web site 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 vario us 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 ac t as a proxy for content hosted on another server. This type of attack can enable unauthorized users to host illegal, online activities using your Web server resources.

•

Unauthorized retrieval of sensitive information – These attacks are intended to provide unauthorized retrieval or leakage of sensitive information from your Web sites or back-end databases.


A10 Thunder Series and AX Series WAF External Logging

The WAF is configured via a WAF template, which includes built-in basic and policy-based security checks for convenient and quick deployment. Within the WAF template, you can enforce security c hecks to immediately provide a foundational level of protection against common threats. Web sites are further protected from attack through checks that are defined by customizable WAF policy files. You can configure WAF policy files for advanced countermeasures to common attacks, such as SQL injection attacks or bots.

WAF External Logging The WAF includes the option for external logging of data plane events and external or local logging of control plane events. For optimal interoperability, the WAF uses the Common Event Format (CEF), an open standard used by other security appliances and network devices. WAF logging is supported over UDP and TCP. You can configure external logging to a group of one or more log servers. You can easily add more log servers if needed, simply by adding them to the log s erver group. (For more information, see “WAF Event Logging” on page 101.)

Protection Against Common Web Attacks The WAF protects your Web servers from common threats which can compromise the security of Web sites or leak sensitive information. The following sections briefly describe common threats and WAF security checks you can use to counter these attacks. More detail is provided later in this guide.

Buffer Overflow Attacks A buffer overflow attack occurs when a Web server receives excessively long pieces of information (for example, URLs, headers, or cookies). If the system does not have the filters enforced to block these requests, a buffer overflow c an trigger the underlying operating system to slow down or c rash. 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 U RL. (For details on URL normalization, see “ur l - opt i ons opt i on – This command is used to normalize requested URLs.” on page 98.)


A10 Thunder Series and AX Series Protection Against Common Web Attacks

Cookie Tampering Cookie tampering occurs when a user sends a modified cookie to a Web server in an attempt to access unauthorized content. To protect against cookie tampering, enable the Cookie Encryption check within the WAF template.

Forceful Browsing Forceful browsing occurs when a user bypasses the hyperlinks of a Web site to access the URLs of a Web site directly. This method is normally used to gain access to private pages, but can be used in conjunction with other attacks to compromise a Web server. To protect against forceful browsing, enable the URL check for your Web site. (See “URL Check” on page 14.)

Web Form Security Attacks A Web form security attack uses the form of a Web page to issue commands to a Web site. The Web form may be modified to include hidden fields, HTML, or injected code to compromise the security of a Web server. A Web form security attack commonly occurs through the following methods: •

SQL Injection Attacks (SQLIA) – An SQL Injection Attack uses a Web form or other mechanism to send active SQL commands or SQL special characters to the Web site’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 Injection Check template option and default “sqlia_defs” policy file to provide immediate protection from SQL Injection Attacks.

•

Cross-Site Scripting (XSS) Attacks – A cross-site scripting (XSS) attack attempts to use Javascript commands to modify Web page content or obtain hidden properties from a Web site. XSS can compromise the security of a Web server or allow an attacker to retrieve sensitive information. The WAF includes the XSS Check template option and default “jscript_defs” policy file to provide immediate protection from XSS attacks.


A10 Thunder Series and AX Series WAF Security Models

WAF Security Models The WAF combats common attacks against Web servers with an array of security checks to filter inbound HTTP requests. In addition to managing requests, you can apply WAF security checks to modify the responses sent back to users. The WAF operates based on both a positive security model and negative security model to maximize protection.

Positive Security Model The WAF supports several operational modes, one of which is Learning Mode. In Learning Mode, you send known, “trusted” traffic (HT TP/HTTPS requests) to the WAF. The WAF automatically sets the values for certain checks based on the traffic. All operational modes support the White List Check. During the White List Check, the WAF compares the URI of a user request against the URI patterns in the White List policy file. If there is match, the WAF performs additional checks. (For more information, see “WAF Operational Modes” on page 49.)

Negative Security Model One of the additional checks per formed by the WAF is comparison of the traffic to the patterns in the Black List policy file. If there is a match, the WAF generates a data event log message. I f Active Mode is enabled, the WAF also drops the traffic.


A10 Thunder Series and AX Series Request Protection

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.

Compare Request URI to White List and Black List The WAF examines incoming user requests against the URI White Lists and Black Lists. These lists define rules to explicitly allow or deny traffic:

White List The URI White List defines acceptable destination URIs allowed for incoming requests. The White List Check compares the URI of an incoming request against the rules contained in the URI White List policy file. Connection requests are accepted only if the URI matches a r ule in the URI White List. For more information, see “URI White List” on page 110.

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 a utomatically 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 automatically if it meets a rule in the separate URI Black List. For more information, see “URI Black List” on page 109. The following diagram displays the processing order for incoming requests:



FIGURE 1

Screen URI 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 limited set of URL paths on your Web site. The URL Check allows clients to access a specific set of acceptable URLs that were added to the URL-check policy file while the WAF is deployed in Learning Mode. Once this policy file is generated, you can manually edit its contents before switching the WAF deployment mode from Learning to Active. At this point, users will be prevented from accessing any URLs on your website that are not listed in this generated policy file. NOTE:

For a deployment example that includes configuration of the U RL Check, see “Generate Allowed URL Paths for the URL Check” on page 127.



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 Web site that appear as hyperlinks, but they are prevented from accessing private pages through “forceful browsing”. For more information, see “Forceful Browsing” on page 11. NOTE:

In the example shown in Figure 1 on page 14, the URL Check would achieve the same degree of security if a hyperlink is only provided to the page “/ site_images.jpg”.

Scan Request for Threats If a client request passes the URI White and Bla ck List Checks, the WAF scans aspects of the HTTP request (method, version, URI, query string, headers, cookies, and content) for threats. If the security check discovers malicious content, the request is either denied or sanitized of the threat and forwarded to the Web server. These security checks are described in more detail below. FIGURE 2

Scan requests

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 _def s ” file, the request is denied automatically. You can copy the “bot_ def s ” file and modify the copy to include o r remove bot search terms. For more information about WAF policy files, see “WAF Policy Files” on page 107.



Form Field Consistency Check The Form Field Consistency Check verifies that all of the form fields and their data types that are sent to the client as part of the form are returned unmodified in subsequent requests from the client. This check helps protect against hijacked forms to which malicio us code may have been added.

Referer Check The Referer Check validates that the referer header in a request contains Web form data from the specified Web server, rather than from an outside Web site. 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 check ing. 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.

HTTP Protocol Compliance Check Regardless of deployment mode, the WAF template automatically enforces a basic, default set of HT TP protocol checks. Enable the HTTP Protocol Compliance Check to perform the following suite of additional checks for protocol compliance: •

POST request with Content-Length: 0

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.

•

Header name with no header value

•

Several Content-Length headers

NOTE:

•

A request containing more than one Content-Length header might indicate that the request is part of an HTTP response-splitting attack.

Chunked request with Content-Length header


A10 Thunder Series and AX Series Request Protection •

Body in GET or HEAD requests

•

No Host header in HTTP/1.1 request

•

Host header contains IP address

•

Content length should be a positive number

•

Bad HTTP version

•

Maximum number of headers

•

Bad host header value

•

Maximum number of cookies

•

Invalid character in Host header

•

Header contains NULL character

•

Header contains high-ASCII character

•

POST with invalid Content-Length header

HTML Cross-Site Scripting (XSS) Check The HTML XSS Check defends against cross-site scripting (XSS) attacks. The WAF searches the headers, cookies, and POST bodies of user requests for possibl e Javascript commands. If the WAF discovers a potential cross-site scripting attack, the request is either bloc ked or sanitized of malicious content and forwarded for processing. For more information about XSS, see “Web Form Security Attacks” on page 11. NOTE:

This check uses the “jscript_defs” WAF policy file for Javascript attack patterns. If your Web site uses Javascript-based content that accesses or modifies content on an outside server, A10 Networks recommends modifying the “jscript_defs” file to generate the appropriate exceptions, so that this check does not block legitimate activity.



Buffer Overflow Check The WAF can check various elements in an HTTP request to prevent buffer overflow. You can specify the check to examine one or more of the following aspects of a request: •

Cookie length, name length, and/or value length

•

Header length, name length, and/or value length

•

Parameter length, name length, and/or value length

•

Maximum parameters

•

URL length

•

POST content size

•

Line length

•

Query length

HTML SQL Injection Check The HTML SQL Injection Check scans incoming requests for strings that resemble SQL commands or SQL special characters. If the WAF discovers a match, the request is either blocked or sanitized of SQL-code and forwarded for processing. NOTE:

The HTML SQL Injection Check scans incoming requests for attack patterns listed in the “sqlia_defs” WAF file. Copy this file and apply the copied file to the check to customize attack pattern search criteria for the HTML SQL Injection Check. (See “SQL Injection Attack Check” on page 108.)

Allowed HTTP Methods Check The Allowed HTTP Methods Check ensures that HTTP requests contain only the HTTP methods that are allowed by the WAF template. By default, only the following methods are allowed: GET, POST You can allow one or more of the following HTTP methods: GET • POST • HEAD • PUT • OPTIONS • DELETE • TRACE • CONNECT •



PURGE

Support for Additional WebDAV HTTP Methods The WAF can be configured to accept a set of 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. Web Distributed Authoring and Versioning (WebDAV) is an extension to the HT TP 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. As part of the ACOS 4.0 enhancements, the WAF now supports the following new WebDAV HTTP methods (in addition to the original GET and POST methods): •

PROPFIND – retrieves the hierarchical information, and properties, for a director y 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.

Maximum Cookies Check The Maximum Cookies Check ensures that a client request does not contain more than the maximum allowed number of cookies. By default, the maximum number of coo kies allowed in a request is 20.

Maximum Headers Check The Maximum Headers Check ensures that a client request does not contain more than the maximum allowed number of headers. By default, the maximum number of headers allowed in a request is 20.



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 inser ts the ID into a cookie that is returned to the client. Subsequent requests from this client are then validated against the session ID. If the session ID does not match the saved ID, or if the ID is coming from a different IP address than that of the original client, then the request is rejected. Details: •

Session Tracking for WAF sessions is disabled by default.

•

When enabled, you must specify the Session Lifetime to determine the amount of time the session ID will remain valid. By default, the session lifetime is 600 seconds (10 minutes), but you can enter a range from 1–86400 seconds (24 hours).

•

The session cookie is named “awaf-sid”, and it is inserted into the header of the response sent by ACOS.

•

The header appears in the following format: Set-Cookie: awaf-sid=; path=/' max-age=

Password Security The WAF offers several additional password security options to control how passwords are treated when traversing the WAF. Deny Unmasked Passwords 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-password option is enabled, the WAF will deny the web server’s attempt to send a form unless the field type is set to “password”. If the form field is named “password” (or “secret”), then the field type also needs to be set to “password” to ensure that the password characters will be hidden when typed by the end user. (Other field types, such as “text”, will not hide the password characters as they are being entered by the user.) The example below shows a form that would be denied by the WAF. Note that the form field type is set to “text”, and the form name is set “Password”. The WAF would block the web server’s attempt to send this form



because the “input type=text” means the user’s password would not be hidden or masked as it was being typed and would thus be vulnerable to theft. Passwor d:

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. Passwor d:

To configure the WAF to prevent web servers from sending non-secure password forms to a client, use the deny-non-masked-password CLI command at the WAF template configuration level.

Deny Passwords Sent Over an Unencrypted Connection You can configure the WAF to block user passwords that are sent over a non-encrypted connection. I f the connection between the client and the WAF is secured with SSL/TLS, then the user password is allowed. However, if the client attempts to submit to a form field where “input type=password”, and if the connection is not encrypted with SSL/TLS, then the WAF will block the transmission. NOTE:

Even if this option is enabled, the user’s password may have already been compromised while in transit, because the WAF blocks transmission of the password only after the client has already entered it over an unsecured connection. In such cases, the user’s password could have already been compromised before reaching the WAF.

You can enable this option to prevent the WAF from allowing the transmission of user passwords over nonSSL-encrypted connections by entering the deny-non-ssl-password CLI command at the WAF template configuration level. Deny Passwords if Autocomplete is Enabled 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 t ypically associated with the HTML form text fields. While end users may appreciate this “autocomplete” behavior because it simplifies the process of logging into websites, the convenience comes at the cost of making the user’s password and the overall security of the login process, less secure.



In order to control the browser’s behavior, administrators can increase the network security by configuring the WAF to reject the web server form if the field type is set to “password” and if the “autocomplete=on/off” attribute is set to “on”. To configure this option and prevent the WAF from allowing the transmission of user passwords when the “autocomplete=on/off” attribute is set to “on”, use the deny-password-autocomplete CLI command at the WAF template configuration level.

Open Redirect Mitigation The Open Redirect Mitigation feature offers protection against the threat of “unvalidated redirects or forwards”, which is listed as one of the Open Web Application Security Project (OWASP) “Top 10 List” of most severe security risks for 2013. An unvalidated redirect occurs when a hacker uses social networking (such as email, Facebook, Twitter, etc.) 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, the link ac tually contains code that redirects users to a forged website. At this point, users may be tricked into submitting their login credentials (username/password), credit card numbers, security codes, or other sensitive information. Hackers c an then use this information to access their accounts or attack their systems. Although OWASP groups “unvalidated redirects or forwards” together as a single threat, they are actually two separate but related threats. As such, the WAF has different ways to mitigate both types of attacks: •

“forwards” – With this type of threat, users become victims when they are for warded to a malicious URL which tricks them into surrendering their login credentials. This particular risk can be mitigated through the use of the URL check feature, which is discussed here: “URL Check” on page 14

•

“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 ser vers attempts to redirect a user to a location that does not appear in the redirect white-list, then the WAF blocks the redirect. The Open Redirect Mitigation feature must be enabled using the redirect-wlist CLI command. The command is used at the WAF template configuration level, and the first time the command is used, the WAF must be deployed in Learning Mode. NOTE:

If you attempt to use the command for the first time while the WAF is deployed in Active Mode or Passive Mode (and before the redirect white-list has been created during Learning Mode), then you will receive an error message stating that “redirect-wlist cannot be turned on with empty list.”

Valid traffic is then injected into the WAF, which then investigates each “redirect” response packet received from the backend web servers, where a redirect response packet is defined as any packet having a status code ranging from 300–308.



The WAF extracts the value from the Location field of the header of the response packet and stores it in its internal database. When the WAF deployment mode is subsequently changed from Learning Mode to Active Mode (or Passive Mode), the location information in the database is transferred to a persistent file called “redirect_wlist_”. The filename will have the name of the WAF template as its prefix. For example, the WAF template “test” would have a policy file called “_test_redirect_wlist_”. Details: The behavior of this option depends on which deployment mode the WAF is in: •

Learning Mode – The option must be enabled for the first time while the WAF is deployed in Learning Mode. The information is saved in the ACOS device’s local database. At this time, the white-list file has not yet been created, so if you wish to modify the redirect white-list, you must change to Active or Passive Mode. Note that no action is performed upon traffic during Learning Mode, other than using the traffic to build the redirect white-list.

•

Active Mode – Once the redirect white-list is created while the WAF is deployed in Learning Mode, you can then change the deployment mode to Active Mode. At this point, the database is used as a whitelist 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 blocking 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 the WAF template configuration level: redirect-wlist

NOTE:

The WAF must be deployed in Learning Mode the first time the command is used. Once the redirect white-list is created, you can then switch to Passive Mode or Active Mode.

Display Statistics You can display statistics for this redirect-wlist option using the show waf stats virtual-server-name portnum CLI command, as shown in the example below, which offers three dedicated counters associated with the redirect white-list: ACOS#show waf stats vip2 80 ...


A10 Thunder Series and AX Series Request Protection Redi r ect Whi t e Li st Check - Learned

8

- Success

2

- Fai l ed

0

...

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. TABLE 1 show waf stats fields

Field

Description

Redirect White List

Redirect counters: • 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.

Normalization Enhancements for URL Options ACOS support URL normalization, which is a process of standardizing the appearance of URLs to remove inconsistencies from one URL to another. For example, one URL might use lower-case charac ters, while another URL could use a mix of upper-case and lower-case characters. A simple corrective normalization sc heme could be used to convert the URL with the mixed set of upper-case and lower-case charac ters to use only lower-case characters, as shown below. •

Before normalization: HTTP://www.Example.com/

•

After normalization: http://www.example.com/

This process of normalizing URLs is sometimes used by search engines to make comparisons of several URLs easier. By standardizing the appearance of URLs and reducing them down to the canonical form, it is easier to ensure the same URL is not cataloged twice by a web crawler. Perhaps more relevant to its functionality in the WAF, URL normalization offers a way to protect web servers from cer tain 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 in order to gain access to sensitive director ies or files that were supposed to remain off limits.



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 charac ters, such as \r \n \"\xXX in an internal URL.

•

Decode HEX Characters – Decode hexadecimal charac ters, 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.



WAF XML Checks The WAF in ACOS 4.0 has been enhanced with the ability to scrub client requests that contain eXtensible Markup Language (XML) code for anomalies. XML is commonly used for data exchange, but hackers can exploit security holes in the XML code to attack servers. Therefore, it is important to inspect and validate client requests containing XML code to protect the backend servers from XML transactions that could allow hackers to bypass application security, provide malicious input, and potentially slow down or crash the servers. When the new WAF XML checks are enabled, the WAF checks client requests for XML, and if present, the WAF then validates the structure of the XML document using a trusted XML schema file. In doing so, this helps to ensure that the content of the client’s XML request is well-formed and does not co ntain any potential threats. Types of XML Checks 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-con structed (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 examine the headers and bodies of incoming XML requests for Javascript keywords that might indicate possible cross-site scripting attacks. If the request contains a positive match, then the WAF blocks the request.

•

XML SQL Injection Checks – This option uses the xml-sqlia-check CLI command to 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.



XML Format Checks The XML format check examines the format of incoming requests, and blocks requests if the XML content is not well-formed. The option can be enabled with the following CLI command at the WAF template configuration level: 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: •

XML documents must contain only properly-encoded Unicode characters

•

The document may contain no special XML syntax characters. For example, none of the following characters can be included in the XML document, unless used as markup: , “<“, “>”, and "&”

•

The XML document must contain all beginning and end tags. All begin, end, and empty element tags must be nested correctly. The XML document must not be missing any element tags, and it c annot contain overlapping element tags.

•

A single root element must contain all the other elements in the XML document.

XML Validation Checks The XML Validation Check is used to prevent an attacker from using invalid XML messages that have been specially-constructed to evade application security. 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 X ML document. The XML schema goes beyond just defining proper XM L syntax, and it defines things such as which elements or attributes can appear in an XML document, as well as the number, order, and relationship of child elements. It can also determine the data types associated with the various elements and attributes that appear in an XML document. If an incoming request is compared with the XML schema, and the WAF determines that the request is not valid, then it is deemed a threat and the WAF blocks the request. The option can be enabled using the following CLI command at the WAF template configuration level: xml-validation xml-schema [ resp-val] xml-schema-file-name



XML Schema Validation The WAF can validate XML messages using an XML schema file. You must upload the XML schema file that you plan to use for validation. The XML schema file can be uploaded using the import command at the global config level of the CLI: import xml-schema local-filename [ use-management-port] file-name url

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 director y path. You can enter the entire URL on the command line, or you can press Enter to display a prompt for each par t 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: waf xml-schema edit local-filename

If you need to remove an existing schema file, you can do so using the following CLI command at the global config level: waf xml-schema delete local-filename

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



XML Limit Checks When the xml-limit-check option is configured, the WAF XML parser will enforce parsing limits in order to protect backend servers against various types of denial-of-service (DoS) attacks, which are designed to exhaust system memory or CPU resources. Some examples of DoS attacks that can be prevented this way are XML Bombs and Transform Injections. XML Bomb An XML Bomb is a denial of service attack that takes advantage of the fact that entity references in XML documents must be expanded for evaluation. Such attacks can achieve this goal by adding extra entity entries to the XML document, and then defining subsequent entities, which are based on the expanded values of the previous entity. Entity expansion is a normal and required action for XML documents, so hackers can take advantage of this loophole by using it to exhaust system memory and CPU resources. If it is left unchecked, such an attack could really slow performance thus causing servers to crash. The WAF can address this issue by placing a maximum limit on the number of entity expansions that are allowed in an XML document. Similarly, a maximum limit can be imposed on the number of levels of entity recursion. Together, imposing these types of limits on XML documents can contain and mitigate the harmful effects of an XML Bomb. Transform Injection Transform Injections are a different type of denial of service attack, and they work by taking advantage of XSLT flow-control functions, and by creating infinite loops, or perhaps redundant transforms, which will eventually exhaust the available memory and CPU resources that the ser ver can offer. To mitigate the effects of Transform Injection attacks, the WAF can be configured to place limits on the maximum depth of child element pairs, the amount of data contained in an element pair, and the maximum size of an XML document. Configuring XML Limit Parameters to Thwart XML Bombs and Transform Injections To prevent XML Bombs, Transform Injections, and other types of DoS attacks from consuming excessive system resources, ACOS provides the following CLI command, which can be used at the WAF template configuration level. xml-limit parameter limit

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.

• max-attr-name-len number



Limits the maximum length of each attribute name. number

– Maximum number of characters allowed per element. Range is 1–2048. Default is 128.

• max-attr-value-len number

Limits the maximum length of each attribute value. number

– Maximum number of characters allowed per attribute. Range is 1–2048. Default is 128.

• max-cdata-len number

Limits the length of the CDATA section for each element. number

– Maximum length of CDATA section for element. Range is 1–65535. Default is 65535.

• max-elem number

Limits the maximum number of any one type of element per XML document. number

– Number of elements allowed. Range is 1–65535. Default is 65535.

• 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–65535. Default is 65535.

• max-elem-depth depth

Limits the maximum number of nested levels in each element. depth

– Maximum number of levels allowed. Range is 1–65535. Default is 256.

• max-elem-name-len length

Limits the maximum length of name of each element. length – Maximum length of each element, and includes the XML path, which is in the following format:

http:////page.xml Range is 1–65535. Default is 128. • max-entity-exp number

Limits the number of entity expansions allowed. number

– Maximum number of entity expansions all owed. Range is 0–1024. Default is 1024.

• max-entity-exp-depth number

Limits the maximum depth of nested entity expansions. number

– Maximum depth of entity expansions allowed. Range is 0–32. Default is 32.

• max-namespace number

Limits the number of namespace declarations in XML document.


A10 Thunder Series and AX Series Request Protection number

– Maximum number of namespace declarations allowed. Range is 0–256. Default is 16.

• max-namespace-uri-len number

Limits the URL length for each namespace declaration. number

– Maximum URL length allowed for each namespace declaration. Range is 0–1024. Default is

256.

XML Cross-Site Scripting Checks 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. 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 108 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 suppor t 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 po sitive match to the filtering criteria. The WAF template “tempwaf1” is bound to VIP “vs101”. waf t empl at e t empwaf 1 t empl ate l oggi ng sysl og xml - f ormat - check xml - xss- check xss- check r ej ect sl b vi r t ual - ser ver vs101 10. 12. 0. 101 por t 80 ht t p sour ce- nat pool nat_ I Pv4 ser vi ce- gr oup sg- ht t p t empl at e waf t empwaf 1



XML SQL Injection Checks To prevent XML SQL Injection Checks, the WAF examines the headers and bodies of incoming requests for inappropriate SQL special characters or keywords that might indicate the presence of an SQL Injection Attack. If the check finds any of the forbidden special characters or keywords, then the WAF will block those requests and prevent them from reaching the servers. This option can be enabled using the following CLI command at the WAF template configuration level: 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 108 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 pol icy 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”. waf t empl at e t empwaf 2 sql i a- check rej ect t empl at e l oggi ng sysl og

xml - f ormat - check

xml - sql i a- check

sl b vi r t ual - ser ver vs102 10. 12. 0. 101 por t 80 ht t p sour ce- nat pool nat_ I Pv4 ser vi ce- gr oup sg- ht t p t empl at e waf t empwaf 2



WAF SOAP Checks 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 HT TP to transmit messages. Prior to SOAP, most applications would communicate using remote procedure call s (RPCs). When attempting to send an RPC over the Internet to a web server, problems could occur because RPCs would often get blocked by overzealous firewalls. SOAP gained popularity because it offered a way for web applications to communicate over the Internet without the messages being intercepted by firewalls. This is by virtue of the fact that SOAP relies on HTTP to transmit messages, and HTTP is supported by virtually all Internet browsers and servers. Structure of a SOAP Message 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

•

A Header element, which contains the header information

•

A Body element, which contains the call and response information

•

A Fault element, which contains errors and status information

Types of SOAP Checks 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 a re 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 ag ainst a WSDL file. If the WAF discovers that the SOAP content fails the validation check, then the WAF blocks the request.

SOAP Format Checks The SOAP Format Check enhancement scrubs client requests that use SOAP for anomalies that could indicate the presence of an attack. While it is not recommended, SOAP format checks can be enabled independently of XML checks. Most of the time, however, SOAP format checks are done in tandem with XML format checks, which makes sense, because SOAP is based on XML.



As a matter of best practices, when enabling SOAP format checks (using the soap-format-check option), you should also enable XML format checks (using the xml-format-check option). The reason for this is that the WAF always does the XML checks first and then adds additional SOAP checks. For additional information on XML format checks, see “WAF XML Checks” on page 26. What is a SOAP Format Check? The SOAP Format Check scrubs incoming client requests to ensure that the SOAP requests are structured in the proper format, as defined by the World Wide Web consortium in the following Recommendation: http://www.w3.org/TR/2007/REC-soap12-part1-20070427/ The SOAP format check performs the following evaluations: •

Verifies that messages have the appropriate sectio ns (e.g., Message, Header, Body, Fault, etc.) and that these sections appear in the correct order.

•

Verifies that the envelope uses the correct namespace (http://www.w3.org/2003/05/soap-envelope).

•

Verifies that defined attributes, such as role, encodingStyle, Code, etc., follow the defined format.

You can enable SOAP format checks using the following CLI command at the WAF template configuration level: soap-format-check

NOTE:

As mentioned above, the xml-format-check option should also be enabled when enabling the soap-format-check option.

SOAP Validation Checks The WAF can validate SOAP messages using a Web Services Description Language (WSDL) document. WSDL is an XML document that is typically used to describe the behavior of a web service. 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 XML 1.)

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 ea ch schema file, but it extends the XML Schema to allow for an association to occur for specific calls to specific URIs, assuming the contents of the headers.



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 c alled is defined for the current direction, and that the message conforms to the schema for that message. The WSDL validation option can be enabled using the following CLI command at the WAF template configuration level: xml-validation wsdl [ resp-val] wsdl-file

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: import wsdl local-filename [ use-management-port] file-name url

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 director y path. You can enter the entire URL on the command line, or you can press Enter to display a prompt for each par t 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: waf wsdl edit local-filename

If you need to remove an existing WSDL file, you can do so using the following CLI command at the global config level: waf wsdl delete local-filename



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.

WAF JSON Checks In ACOS 4.0, the WAF is enhanced by adding suppor t for parsing and verifying JSON data in HTTP POST operations. The WAF supports the ability to run a format check on requests containing JSON data. This helps to ensure that the content of the request is well-formed. In addition, the WAF supports the ability to impose JSON parsing limits in order to protect web servers from various types of denial-of-service (DoS) attacks. Types of JSON Checks 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.

JSON Format Checks The JSON format check examines the format of incoming requests, and blocks requests if the JSON content is not well-formed. The JSON format check verifies that incoming requests containing JSON code are in compliance with RFC 4627. This document can be found at the following URL: http://www.ietf.org/rfc/rfc4627.txt Compliance Criteria The JSON Format Check evaluates incoming requests for compliance with the following criteria: •

The JSON document must contain only properly-encoded Unicode characters.

•

Strings must contain matching quotations and properly escaped characters.

•

All objects must contain matching braces {}, and a set of members must be separated by commas.

•

Every object member must contain a name and value, separated by a colon.



All arrays must contain matching brackets [], and a set of values must be separated by commas.

•

Numbers must be properly formatted.

This option can be enabled using the following CLI command at the WAF template configuration level: json-format-check

JSON Limit Checks When the json-limit option is configured, the WAF JSON parser will enforce parsing limits in o rder to protect backend servers against various types of denial-of-service (DoS) attacks, which are designed to exhaust system memory or CPU resources. Configuring JSON Limit Parameters to Prevent DoS Attacks 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. json-limit parameter limit

The json-limit command can be completed using any of the p arameters shown below: • max-array-value-count number

Limits the maximum number of values within a single ar ray. number

– Maximum number of values in an array. Range is 0–4096. Default is 256.

• max-depth number

Limits the maximum depth in a JSON value. number

– Maximum recursion depth in a JSON value. Range is 0–4096. Default is 16.

• max-object-member-count number

Limits the number of members in a JSON object. number

– Maximum number of values allowed. Range is 0–4096. Default is 64.

• max-string number

Limits the length of a string in a JSON request for a name or a value. number

– Maximum length of a string in bytes. Range is 0–4096. Default is 64.



Geo-location Based Blocking This feature enables an administrator to configure the WAF to block attacks based upon the geo-location information of incoming requests. You can block an attack originating from a country, region, or state that has a known history of being a hotspot for various types of WAF-preventable attacks. This capability allows you to limit which countries can access your resources based upon the geo-location information associated with a request. You can create an HTTP po licy that would permit or deny traffic based upon a combination of threshold events and geo -location information. The WAF Geo-location Based Blocking feature allows you filter incoming client requests using two different approaches. •

“Filter Requests Using an HTTP Policy” on page 38

•

“Filter Requests Using an ACL” on page 41

Filter Requests Using an HTTP Policy The WAF Geo-location Based Blocking can use HT TP policies to detect and act upon traffic from different regions. You can use this option to apply a different WAF template to requests coming from different regions. The WAF geo-location feature uses an HTTP policy to apply a WAF template to an incoming request. The geolocation database (such as an IANA file) can identify which part of the world a certain request came from. The IANA database contains the mappings between geographic regions and IP address ranges, as assigned by the Internet Assigned Numbers Authority. (For more information about the IANA database, see the Global Server Load Balancing Guide .) Using the IANA database, the WAF can evaluate incoming requests and determine that, for example, a request with an IP of 222.111.222.111 is from, say, the North Korea. Perhaps this is a region with rampant cyber-criminal activity. In order to prevent hackers from this region from being able to access your web servers and steal credit card numbers, the WAF can be configured to detect traffic from this region, and if there is a match, the traffic could be denied. Alternatively, if this region is known to use XML bo mbs, 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. Configuration Using the CLI You can enable the WAF Geo-location blocking feature by using the new geo-location keyword at the HTTP policy configuration level.


A10 Thunder Series and AX Series Request Protection ACOS- I nsi de- Pr i mary( conf i g) ( NOLI CENSE)#sl b t empl at e ht t p- pol i cy name1 ACOS- I nsi de- Pri mary( conf i g- ht t p- pol i cy) ( NOLI CENSE) #? cl ear

Cl ear or Reset Funct i ons

cooki e- name

name of cooki e t o mat ch

do

To r un exec commands i n conf i g mode

end

Exi t f r om conf i gure mode

exi t

Exi t f r om conf i gure mode or sub mode

geo- l ocat i on

Geol ocat i on name

...

CLI Example This example shows how to configure the WAF geo-location feature using an HTTP polic y. The policy can be used to allow or deny traffic based on geo-lo cation 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) gslb geo-location Beijing.China ip 172.16.3.62 172.16.3.62

Configure the GSLB geo-location IP address range for the second region (e.g., San Jose, USA) gslb geo-location Sanjose.USA ip 172.16.3.63 mask 255.255.255.255

Configure the real server IP and por t information for server “s1”: slb server s1 172.17.3.48 port 80 tcp port 443 tcp port 514 udp

Configure the real server IP and por t information for server “s2”: slb server s2 172.17.3.49 port 80 tcp port 443 tcp port 514 udp

Create the service group “sg-http-p1” and add server “s1”: slb service-group sg-http-p1 tcp member s1 80



Create the service group “sg-http-p2” and add server “s2”: slb service-group sg-http-p2 tcp member s2 80

Set up the service group “syslog” and add server “s2”: slb service-group syslog udp member s2 514

Set up the logging template and bind it to the service group “syslog”: slb template logging syslog service-group syslog

Create the WAF template “waf-1", with the max parameters set to 3, and logging template called “syslog”: waf template waf-1 max-parameters 3 template logging syslog

Create the WAF template “waf-2”, with credit card number masking enabled, and logging template called “syslog”: waf template waf-2 ccn-mask template logging 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 “sghttp-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”: slb template http-policy geo-policy-http-ipv4 geo-location Beijing.China service-group sg-http-p1 template waf waf-1 geo-location Sanjose.USA service-group sg-http-p2 template waf waf-2

Create the slb virtual-server configuration “vs101”, with port 80 (HT TP), and set up the source-nat pool “nat_IPv4”, and bind both service-groups “sg-http-p1” and “sg-http-p2”. Then, bind the HTTP-policy template we created earlier, and bind the two waf templates.


A10 Thunder Series and AX Series Request Protection slb virtual-server vs101 10.11.0.101 port 80 http source-nat pool nat_IPv4 service-group sg-http-p1 service-group sg-http-p2 template http-policy geo-policy-http-ipv4 template waf waf-1 template waf waf-2

With the above configurations, the HTTP request destined to virtual server “vs101” port 80 from clients belonging to geo-location Beijing.China will be ch ecked against template waf waf-1. Clients belonging to geo-location Sanjose.USA will be checked against template waf waf-2.

Filter Requests Using an ACL The WAF Geo-location feature also allows you to block client requests using an Access Control List (ACL). When this feature is enabled, the WAF will evaluate client requests using the source address of the incoming request, and then it will either permit or deny traffic if there is a match. You can configure WAF geo-location based bloc king 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: ACOS( conf i g) #ip access-list geo_acl_ipv4 permit geo-location Sanjose.USA any any ACOS( conf i g- access- l i st : geo_acl _i pv4) #

ACOS( conf i g- access- l i st : geo_acl _i pv4) #deny geo-location Pyongyang.NorthKorea any any

Configuring the WAF with aFleX Scripts You can configure several key areas of the WAF using aFleX scripts. This interface is provide in addition to the CLI and GUI, and it provides a new way to configure the WAF by allowing you to set up a variety of WAF trigger events. Additional new events: •

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)

Examples of possible violations: •

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 par t 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 workaround was to avoid configuring WAF on this virtual port. However, this release adds aFleX, which in turn means that the administrator can write an aFleX script that triggers on request violation. The WAF will check the violation ID and determine that this is a violation of the allowed methods rule. Upon learning this, the WAF will call the WAF::disable method, which will temporarily disable WAF processing (for this 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 fal se-positive that triggered the event.

Possible Actions: If the WAF detects traffic that violates one or more rules, aFleX commands can be co nfigured to seize upon this trigger in order to perform one of the following actions upon that traffic: •

Allow - This action is triggered by a violation event when the WAF is deployed in Passive Mode and Learning Mode.

•

Deny - This action is triggered by a violation event when the WAF is deployed in Active Mode.

•

Mask - This action is triggered for the event WAF_RESPONSE_VIOLATION, but only for the following select features, such as ssn-mask, ccn-mask, and pcre-mask.

•

Redirect - This action is triggered under violation events for the referer-check feature if the WAF is deployed in Active Mode.

•

Sanitize - This action is triggered for the WAF_REQUEST_VIOLATION event for features that support the ability to sanitize traffic, such as xss-check, sqlia-check. The action can also be triggered for the WAF_RESPONSE_VIOLATION event.

WAF aFleX Commands In ACOS 4.0, the WAF supports the following new aFleX commands: •

WAF::disable – Disables WAF processing for the connection during which the aFleX script is triggered.


A10 Thunder Series and AX Series Response Protection •

WAF::enable – Re-enables WAF processing for the connection during which the aFleX script is triggered.

•

WAF::mode – Returns the current deployment mode in which WAF is configured (active, passive or learning).

•

WAF::template – Returns the name of the active WAF template.

•

WAF::violation – Returns or logs information related to WAF violation events.

For syntax associated with these aFleX commands, please see the “WAF Commands” section in the aFleX Reference.

WAF Events The following Web Application Firewall (WAF) events are available: •

WAF_REQUEST_DENY – Triggered whenever a WAF request is denied in active deployment mode.

•

WAF_REQUEST_VIOLATION – Triggered whenever a violation occurs in a WAF request.

•

WAF_RESPONSE_VIOLATION – Triggered whenever a violation occurs in a WAF response.

For syntax and a list of events associated with these aFleX commands, please see the “ WAF Events” in the aFleX Reference.

Response Protection The WAF inspects the content of outbound HTTP responses and hides aspects that can equip an attacker with valuable information. The WAF template can further protect Web servers with the following options for HTTP responses: •

Mask Sensitive Content – Strings in a response are examined for patterns o f 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 charac ter.

•

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.

The following sections describe these steps in more detail.


A10 Thunder Series and AX Series Response Protection

Mask Sensitive Content To protect sensitive content, the WAF masks strings in the communication between an end-user and Web server using the following options. FIGURE 3

Mask sensitive content

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” charac ters. 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 a ccess or transfer credit card information. For example, shopping Web sites with a checkout page or Web sites that access back-end databases which contain customer credit card numbers. This check is unnecessary if the Web site does not have access to or use credit card information.

SSN Mask Similar to a CCN mask, a Social-security Number (SSN) Check masks Web server replies for US social security numbers. If enabled, the SSN check mask searches strings which appear to match the format of US social security numbers and replaces all but the last 4 digits of the string with “x” characters.



PCRE Mask In addition to the preconfigured CCN and SSN c hecks 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 113.) 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). 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.

NOTE:

Cloak Responses The WAF can strip HTTP response headers to “cloak” server information that can equip a hacker to target an attack on your Web servers. For example, the WAF can cloak an HTTP response header to hide what operating system is running on your servers. Information such as this can enable a hacker to more narrowly target your servers with attacks that are specific to the servers’ operating systems. You can cloak server information with the following WAF template options: •

•

Filter Response Headers – Checks responses coming from the Web server and removes headers with server identifying information. For example: •

Server

•

X-Runtime

•

X-Powered-By

•

X-AspNet-Version

•

X-AspNetMvc-Version

Hide Response Codes – Conceals 4 xx and 5 xx response codes for outbound responses from a Web server and returns a generic error code instead. This option hides error codes which can provide an attacker with information to specifically target Web server 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.

Send Instrumented Responses You can configure the WAF to return instrumented responses with form tags for user-modifiable fields.



Cross Site Request Forgery Check The Cross Site Request Forgery (CSRF) Check tags the fields of a Web form sent by a Web site to end-users with a nonce (a unique, unpredictable number for one -time use). The WAF examines the Web forms sent in user requests to ensure that the supplied nonce is correc t. You can use the Referer Check to further help prevent CSRF attacks.

NOTE:

FIGURE 4

Instrumented responses

Form Field Consistency Check The Form Field Consistency Check applies to both requests from clients and responses from servers. When this check is enabled, the WAF stores information about the intended format for Web form input fields before sending the form to clients. The WAF then checks that the response from clients supply content to the Web form that adheres to the correct format. For example, checking that a valid entry is used for drop-down menus or that a radio button is selected versus supplying a string for that form field.

Cookie Encryption This check protects against cookie tampering by encrypting cook ies before sending server replies to endusers. Clients are then unable to view the content of encrypted co okies, which clients could otherwise modify to gain illegal access. If the encrypted cookie is modified, then decryption of the tampered cookie will fail when it is sent back from the client and the request will be rejected. You can enable encryption based on specific cookie names or for all cookies that match a PCRE expression. The encryption uses a secret string to decrypt and encr ypt cookies that are transferred between the Web server and client. (For a configuration example, see “WAF Deployment and Logging Examples” on page 123.)


A10 Thunder Series and AX Series PCI 6.6 Compliance

PCI 6.6 Compliance The ACOS Web Application Firewall enables organizations to satisfy Payment Card Industry Data Security Standard (PCI DSS) requirement 6.6. The PCI Security Standards Council has developed a framework to help organizations that process, transmit, or store payment card data to secure cardholder information. The PCI DSS, the keystone of the PCI Security Standards Council’s compliance standards, sets forth twelve high level requirements designed to protect payment card data, including guidelines to detect, prevent, and respond to security incidents. By deploying the ACOS Web Application Firewall, organizations can quickly and easily achieve PCI 6.6 compliance.

ACOS WAF achieves ICSA Certification While the PCI SSC does not officially certify Web Application Firewalls, similar recognition can be achieved through third-party companies, such as the International Computer Security Association (ICSA) Labs. A10 Networks has achieved WAF certification from ICSA Labs. This certification can help assure network administrators that the ACOS WAF meets the requirements, as stated in PCI DSS section 6.6 “Compliance for Web Apps”, the text of which appears below: 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: •

Reviewing public-facing Web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and af ter any changes.

NOTE:

•

Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.

Installing an automated technical solution that detects and prevents Web-based attacks (for example, a web-application firewall) in front of public -facing web applications, to continually check all traffic.

For more information, you can access the PCI DSS at https://www.pcisecuritystandards.org/documents/ PCI_DSS_v3.pdf

How Does the ACOS WAF Achieve PCI DSS Compliance? PCI compliance essentially means that the WAF meets a long list of requirements. The exact set of requirements can vary, depending on where a particular device is located in the network, as well as which services the device offers. For the ACOS WAF, a partial list of important highlights includes the ability to do the following: •

Restrict access to a resource (such as a web server) based on the IP address from which the request originated


A10 Thunder Series and AX Series PCI 6.6 Compliance •

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)

•

Protect and store log messages

More information about PCI DSS compliance ca n be found at the following link: https://www.pcisecuritystandards.org/documents/information_supplement_6.6.pdf


A10 Thunder Series and AX Series Overview

WAF Operational Modes

This chapter describes the WAF operational modes and how to use them to deploy the WAF.

Overview The WAF supports the following operational modes: •

Learning – Learning Mode provides a way to initially set the thresholds for certain WAF checks based on known, valid traffic.

•

Passive – Passive Mode provides passive WAF operation. All enabled WAF checks are applied, but no WAF action is performed upon matching traffic. This mode is useful in staging environments to identify false positives for filtering.

•

Active – This is the standard operational mode. You must use Active Mode if you want the WAF to sanitize or drop traffic based on the configured WAF policies.

Figure 5 shows a typical work flow for WAF deployment, using these modes. CAUTION:

While Learning or Passive Mode is in operation, the WAF does not block any traffic. Only Active Mode blocks traffic.

Notes: •

Use of the Learning and Passive Modes is recommended during the deployment process.

•

To block traffic, you must deploy the WAF in Active Mode.

•

To access WAF data event messages, logging to external servers is required. See “WAF Event Logging” on page 101.

•

When the WAF is deployed in either learning or passive mode, traffic is not blocked. However, event log messages will list the response ac tion (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.



FIGURE 5

Typical Deployment Scenario

The following sections provide more details about each mode.



Learning Mode Learning Mode provides a way to dynamically set cer tain WAF options based on traffic. When you enable Learning Mode in a WAF template, ACOS resets the following WAF security check values to zero: •

Maximum Headers – set to 0

•

Maximum Cookies – set to 0

•

Buffer Overflow (max-url-len, max-hdrs-len, max-cookie -len, and max-post-size) – all set to 0

•

Allowed HTTP Methods – set to null

•

URL Check (closure list) – set to null

Figure 6 shows an example of the Learning Mode. FIGURE 6

WAF Learning Mode

1. In Figure 6, a WAF template is configured and is bound to the HT TP/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:


A10 Thunder Series and AX Series Overview GET / HTTP/ 1. 1 Host : www. exampl e. com Connect i on: cl ose User - Agent : Mozi l l a/ 5. 0 Accept - Encodi ng: gzi p Accept : t ext / ht ml Cache- Cont r ol : no- cache

3. When the WAF receives the request, Learning Mode updates the following checks in the WAF template: Buffer Overflow Check: •

Maximum headers = 7

•

Max-url-len = 15

•

Max-hdrs-len = 23

Allowed HTTP Methods Check = GET URL Check (not shown in example) 4. To “lock in” the WAF template settings, change to a different mode (for example, Passive Mode or Active Mode). You can fine-tune the template settings later, if needed. Notes •

Beginning in ACOS release 4.0, the WAF will display the learned values in the r unning-configuration only after the WAF deployment mode is changed from Learning Mode to Active Mode o r Passive Mode. The reason for this change in behavior relative to prior releases, is that ACOS 4.0 introduces the Configuration Manager (CM), which acts like an internal “staging area” for the configuration changes. Such config changes are temporarily save to shor t-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. Securit y 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 123.

Passive Mode Passive Mode logs traffic that matches a WAF policy file or check, but does not perform any action on matching traffic. While the WAF is operating in Passive Mode, you can monitor the data event log messages sent to



remote logging servers, and fine-tune your template settings so that valid traffic is not mistakenly blocked by the WAF. Typically, Passive Mode is used in a production network to check for false positives while real production traffic is running. A false positive occurs when valid traffic matches a WAF check, and would be dropped during Active Mode operation. Figure 7 shows an example of Passive Mode. FIGURE 7

WAF Passive Mode

This example shows a “false positive” match on the max-cookies check. In this example, the WAF template allows a maximum of 3 cookie headers within a given request. 1. Client sends request to server. 2. Server replies. The reply contains some cookies inserted by the server. 3. The client sends a new request and inserts the cookies sent by the server in the request. 4. The WAF template allows a maximum of 3 cookies (3 separate cookie headers) in a given client request. Because the client’s request contains more than 3 cookies, the request fails the max-cookies check , and a data event log message is sent to the external log server. However, because the WAF is operating in Passive Mode, the traffic is allowed. Notes: •

Because the WAF is operating in Passive Mode, the client request is sent to the server instead of being dropped. In Active Mode, the request would be dropped.


A10 Thunder Series and AX Series Overview •

To access WAF data event messages, logging to external servers is required. See “WAF Event Logging” on page 101.

•

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. Figure 8 shows an example of Active Mode. FIGURE 8

WAF Active Mode

In this example, a client POST request contains SQL co de. 1. The client sends a request. The request contains SQL code. The request is an attempt to inject SQL code onto the server. 2. The WAF SQL Injection Check detects the SQL. Based on the configuration, the WAF rejects (drops) the request. 3. The WAF sends a log message to the log server.



Figure 9 shows a walk-through of the WAF process as it examines the client’s request. FIGURE 9

WAF Active Mode - walk-through

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.


A10 Thunder Series and AX Series Setting the WAF Operational Mode

3. The request passes the Allowed-HTTP-methods Check. However, the request fails the SQL Injection Check and is denied.

Setting the WAF Operational Mode The WAF operational mode is one of the options you can configure within the WAF template. For configuration information, see either of the following chapters: •

“Configuring the WAF Using the GUI” on page 57

•

“Configuring the WAF Using the CLI” on page 91


A10 Thunder Series and AX Series Configuration Overview

Configuring the WAF Using the GUI

The WAF operates on traffic that is addressed to the virtual IP address (VIP) and HTTP/HT TPS virtual port of your Web site. To apply WAF protection to the vir tual 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. To apply WAF security controls to a virtual port: 1. Configure a WAF template. 2. Bind the WAF template to the virtual port. 3. (Recommended) Configure external logging. ACOS supports logging of WAF events only to external log servers. WAF events are not logged in the ACOS device’s local log buffer. (See “Configure External Logging (recommended)” on page 84.) Notes: •

External logging is the only mechanism supported for accessing WAF data plane log messages.

•

The WAF comes with predefined WAF policy files. You can modify policy rules in the URI White and Black Lists, or add search definitions used for the Bot Check, SQLIA check and so on. For more information, see “WAF Policy Files” on page 107. A10 Networks highly recommends modifying WAF policy files to meet your specific security demands.

•

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 117.)

•

For examples of advanced WAF configuration, see “WAF Deployment and Logging Examples” on page 123.


A10 Thunder Series and AX Series Bind the WAF Template to the Virtual Port

Bind the WAF Template to the Virtual Port You can bind a WAF template to an HTTP or HTTPS virtual service port as follows: 1. Hover over Security on the menu bar, then select WAF. 2. Select the WAF Bindings tab, if not already selected. 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. 3. Click Create. 4. The New WAF Binding page appears, as shown below: FIGURE 10 Security > WAF > WAF Bindings

5. Click the Virtual Server Name drop-down menu, and select the desired pre-configured VIP that you wish to bind. For a VIP to appear in the Virtual Server Name drop-down list, it must be configured with one or more HTTP/HTTPS virtual ports. 6. Based on the VIP that you select, the Virtual Server IP field and Port and Protocol fields will automatically update. If desired, you can click the Port and Protocol drop-down menu and select a different port/proto col combination from the list of HTTP or HTTPS por ts associated with this VIP. 7. Click the WAF Template drop-down menu and select the desired WAF template from the list that appears. If desired, you can click the New WAF Template button to configure a new WAF template for this WAF service. (See “Configure a WAF Template” on page 59.) 8. Click the HTTP Policy drop-down menu and select the desired HTTP template.


A10 Thunder Series and AX Series Configure a WAF Template

If desired, you can click the New HTTP Template button to configure a new WAF template for this WAF service. (See “Configure an HTTP Policy Template” on page 78.) 9. Click the Create button to complete the WAF service configuration.

Configure a WAF Template Use the following steps to configure a WAF template. 1. Hover over Security on the menu bar, then select WAF. 2. Select the WAF Templates tab. 3. Click Create. The WAF template configuration page appears, with the General tab selected, as shown below: FIGURE 11 WAF Template – General

Configuring General Settings 4. In the Name field, enter a name for the template. 5. In the Deploy Mode field, click the drop-down menu and select the operational mode for the WAF template.


A10 Thunder Series and AX Series Configure a WAF Template • Active – The WAF enforces the checks configured in the template and sends events to the external

log server. • Passive – The WAF sends events to the external log server but

does not enforce any security checks.

• Learning – The WAF template “learns” acceptable check parameters based

on a stream of legitimate, secure traffic. When in Learning Mode, the WAF continues to send events to the external log ser ver.

For more information, see “WAF Operational Modes” on page 49. 6. From the Logging Template drop-down menu, select the name of a configured logging template to direct WAF logging activity. See “WAF Event Logging” on page 101. 7. Select the Log Successful WAF Requests checkbox if you want the WAF to log debug messages on the successful completion of WAF requests, and not just for errors. 8. Click the Deny Action drop-down menu and specify the action to be applied when the WAF denies a client’s request. • HTTP Response 403 – Sends a 403 Forbidden response to the client. When this

option is selected, the default string returns a generic “Request Denied!” page to the client, but you can clear the “Default Response 403” checkbox and enter your own response str ing in the “Response URL 403” field that appears.

• HTTP Response 200 – Sends a 200 OK response to the client with the specified response string. The

default string returns a generic “Request Denied!” page to the cl ient. When this option is selected, the default string returns a generic “Request Denied!” page to the client, but you can clear the “Default Response 200” checkbox and enter your own response str ing in the “Response URL 200” field that appears. • HTTP Response Redirect – Redirects the client to the specified URL.

When this option is selected, a text box appears where you can enter a response string or redirect URL. • Reset Connection – Sends a TCP RST to the client to

end the connection.

9. When finished, click Create to save your changes.

Configuring HTTP Request Checks 1. Select the HTTP Request Checks tab to display the list of security options that can be used to determine how the WAF will handle HTTP requests from the client. A window similar to that shown below appears.



FIGURE 12 WAF Template – HTTP Request Checks

2. In the Allowed HTTP Methods field, click to select one or more HTTP methods (GET, POST, and so on) that are allowed to appear in client requests. 3. Select the Bot Check checkbox to check the user-agent of incoming requests for known bots. This check uses the list of defined bots in the “bot_defs” WAF policy file. For more information, see “Bot Check” on page 108. 4. Select the URL Check checkbox to prevent users from accessing the URLs of your website directly. The URL Check allows users to only access Web pages by clicking a hyperlink on your protected Web site. 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 127. 5. Select the HTTP Check checkbox to check that user requests are compliant with HTTP protocols. 6. Select the Referer Check checkbox to enable referer checks, or clear the checkbox to disable. The referer check validates that the referer header in a request contains Web form data from the specified Web server, rather than from an outside Web site, 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 n ot valid.

• Disabled – The WAF will not validate requests based

on the referer header.

a. Select the Only If Present checkbox to display the Allowed Referer Domains field. Then enter the fullyqualified domain names (FQDNs) from which requests are allowed to originate.



b. In the Referer safe URL field, enter the URL for redirected requests that do not come from the allowed referer domains. 7. Select the URI Black List Check checkbox to enable. Select the WAF Black List File drop-down menu that appears, and select the name of a configured WAF policy file. This option enforces the rules contained within a WAF policy file for the URI blacklist.The default WAF policy file is “uri_blist_defs”. For more information about URI blacklists, see “URI Black List” on page 109. 8. Select the URI White List Check checkbox to enable. Click the WAF White List File drop-down menu that appears, and select the name of a configured WAF policy file. This option enforces the rules contained within a WAF policy file for the URI whitelist. The default WAF policy file is “uri_wlist_defs”. For more information about URI whitelists, see “URI White List” on page 110. 9. When finished, click Create to save your changes.



Configuring HTML Request Checks 1. Select the HTML Request Checks tab to display the list of security options that can be used to determine how the WAF will handle HTML requests from the client. A window similar to that shown below appears. FIGURE 13 WAF Template – HTML Request Checks

2. Select the Decode Entities checkbox to decode entities, such as < &#xx; &#ddd; &xXX in an internal U RL. 3. Select the Decode Escaped Characters checkbox to decode escape characters, such as \r \n \"\xXX in internal URLs. 4. Select the Decode HEX Characters checkbox to decode hexadecimal characters, such as \%xx and \%u00yy in an internal URL. 5. Select the Remove Comments checkbox to remove comments from an internal URL. 6. Select the Remove Self-References checkbox to remove self-references, such as /./ and /path/../ from internal URLs. 7. Select the Remove Spaces checkbox to remove spaces from an internal URL. 8. When finished, click Create to save your changes.



Configuring Injection Checks 1. Select the Injection Checks tab to display the list of security options that can be used to determine how the WAF will handle requests that do not pass the SQL injection attacks check. A window similar to that shown below appears. FIGURE 14 WAF Template – Injection Checks

2. 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. •

Selecting Reject will deny the user request.

•

Selecting Sanitize will forward the request to the Web server after removing the offending SQL strings from the message.

3. Selecting either of the above radio buttons displays the SQL Injection Attack Policy File drop-down menu. Click this drop-down and select the policy file that will be used to perform SQL Injection Attack checks. By default, the WAF uses the list of defined SQL commands in the “sqlia_defs” WAF policy file. For more information, see “SQL Injection Attack Check” on page 108. 4. Select the XML Validation – SQL Injection Attack Check checkbox to check XML data against the SQLIA policy file. The WAF examine the headers and bodies of incoming requests for inappropriate SQL special characters or keywords that might indicate the presence of an SQL Injection Attack (See “XML SQL Injection Checks” on page 32 for details.) 5. When finished, click Create to save your changes.



Configuring Overflow Checks 1. Select the Overflow Checks tab to display the list of security options that can be used to determine how the WAF will handle requests that do may be attempting to flood the resources with excessive request parameters. A window similar to that shown below appears. FIGURE 15 WAF Template – Overflow Checks

2. Clear the Disable Buffer Overflow Protection checkbox to display the buffer overflow protection options. These options protect against attempts to cause a buffer overflow on the Web server. 3. In the Max Cookie Length field, enter the maximum length for cookies, cookie names, and/or cookie values allowed in a request. 4. In the Max Total Cookies Length field, enter the maximum total length for all cook ies in a request. 5. In the Max Cookie Name Length field, enter the maximum length for cookie names allowed in a request. 6. In the Max Cookie Value Length field, enter the maximum cookie value length for coo kie values allowed in a request. 7. In the Max Data to Parse field, enter the maximum amount of data that can be parsed in a request.



8. In the Max Request Headers Length field, enter the maximum header length for headers, header names, and/or header values allowed in requests. 9. In the Max Request Header Name Length field, enter the maximum header length for header names allowed in requests. 10.In the Max Request Header Value Length field, enter the maximum header length for header values allowed in requests. 11.In the Max URL Length field, enter the maximum URL length allowed in requests. 12.In the Max Request Line Length field, enter the maximum length for lines allowed in requests. 13.In the Max Query Length field, enter the maximum length for queries allowed in requests. 14.In the Max Post Size field, enter the maximum content length allowed in HTTP POST requests. 15.In the Max HTML Parameter Name Length field, enter the maximum HTML parameter length allowed for the parameter names. 16.In the Max HTML Parameter Value Length field, enter the maximum HTML parameter length allowed for the parameter values. 17.In the Max HTML Parameter Total Length field, enter the maximum HTML parameter length allowed for the total parameters. 18.In the Max MIME entities allowed field, enter the maximum number of MIME entities allowed in the request. 19.In the Max Cookies field, enter the maximum number of cook ies allowed in a request. You can set a number ranging from 0–63. The default value is 20. 20.In the Max Headers field, enter the maximum number of header fields that are allowed in a request. You can set a number ranging from 0–255. The default value is 20. 21.In the Max HTML Parameters field, enter the maximum number of HTML parameters that are allowed in a request. You can set a number ranging from 0–1024. The default value is 64. 22.When finished, click Create to save your changes.

Configuring Session Checks 1. Select the Session Checks tab to display the list of security options that can be used to enable session checks. A window similar to that shown below appears.



FIGURE 16 WAF Template – Session Checks

2. Select the Session Check checkbox to enable session checks. When this option is enabled, the WAF creates a unique ID that is inserted into a cookie and embedded in the server’s response to the client. Future requests from the same client are validated against this ID, and if the tracking ID (or IP address) does not match, then the request is rejected. 3. In the Session Check Lifetime field, enter a value ranging from 1–1440 minutes. The default session lifetime is 10 minutes. For more information about Session Checks, see “Session Checks” on page 20. 4. When finished, click Create to save your changes.

Configuring Web Service Checks 1. Select the Web Services Checks tab to display the list of security options that can be used to configure JSON and XML checks. A window similar to that shown below appears.



FIGURE FIGURE 17 WAF WAF Templ Template ate – Web Services Services Checks Checks

2. Sele Select ct the the Enforce JSON compliance checkbox if you wish to have the WAF scrub incoming requests containing JSON code to verify compliance with RFC 4627. Requests will be blocked if the JSON content is not well- formed. 3. The XSS Check uses uses “jscript_defs” WAF 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.

4. Sele Select ct the 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 WAF policy file. (See “XSS Check” Check” on page page 108 108.).)


A10 Thunder Series and AX Series Configure a WAF Template JSON Limits:

When the following JSON Limit options are configured, the WAF JSON parser will enforce parsing limits to protect backend servers from denial-of-service (DoS) attacks that are designed to exhaust system memory or CPU resources. 5. In th 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 you can set a number ranging from 0–4096. 6. In th 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 number ranging from 0–4096. 7. In th 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 you can set a number ranging from 0–4096. 8. In th 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 number ranging from 0–4096. 9. Sele Select ct the the XML XSS Check checkbox to check XML data against the XSS policy file. The XML cross-site scripting check examines the headers and bodies of incoming XML requests for Javascript keywords that might indicate possible cross-site scripting attacks and blocks those requests. (See “XML Cross-Site Scripting Scripti ng Checks” Checks” on page 31 31 for for details.) 10.Select the XML Format Check checkbox to check the HTTP body of the message for XML format compliance. Incoming requests containing XML code are checked for compliance with the X ML 1.0 specification. (See “XML Format Format Checks” Checks” on page 27 27 for for details.) 11.In the XML Limit - Max Attributes field, enter the maximum number of attributes each individual element is allowed to have. The default is 256, but you can enter an integer 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 integer from 0-2048. 13.In the XML Limit - Attribute Text Text Max Length field, enter the maximum number of characters allowed per attribute. The default is 128, but you can enter an integer integer from 0-4096. 14.In the XML Limit - CDATA Section Max Length field, enter the maximum length of CDA CDATA TA section for each element. The default is 65535, but you you can enter an integer from 0-65535. 15.In the XML Limit - Max XML Elements field, enter the maximum number of any one type of element per XML document. The default is 1024, but you can enter 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, charac ter 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 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 integer from 0-65535. 19.In the XML Limit - Max Entity Expansions field, enter the maximum number of entity expansions allowed. The default is 1024, but you can enter 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 integer from 0-32. 21.In the XML Limit - Max Namespace Declarations field, enter the maximum number of namespace declarations in an XML document. doc ument. 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 integer from 0-1024. 23.Select the checkbox for XML Validation - WSDL File - Resp Val if you want the WAF to validate SOAP messages from a protected web application server using a Web Services Description Language (WSDL) document. •

If you selected the checkbox, select selec t the desired file from the XML Validation - WSDL File - Resp Val drop-down menu.

•

If you cleared the checkbox clear (default), optionally select the XML Validation - WSDL File from the drop-down menu.

24.Select the checkbox for XML Validation - XML-Schema file - Resp Val if you want the WAF to validate SOAP messages from a protected web application ser ver using an XML Schema file. •

If you selected the checkbox, select selec t the desired file from the XML Validation - XML-Schema file - Resp Val drop-down menu.

•

If you cleared the checkbox clear (default), optionally select the XML Validation - XML-Schema file from the drop-down menu.

25.Select the Enforce SOAP compliance on XML checkbox to check XML documents for SOAP format compliance. The WAF WAF blocks those which are not well-formed. SOAP format checks are typically done in tandem with XML format checks. See “WAF SOAP SOAP Checks” on page 33 33 for for details. 26.When finished, click Create to save your changes.

Configuring Cookie Encryption Checks 1. Sele Select ct the the Cookie Encryption Checks tab to display the list of security options that can be used to prevent cookie tampering. A window similar to that shown below appears.



FIGURE 18 WAF Template – Cookie Encryption Checks

2. In the Cookie Name field, enter the name of a cookie or PCRE expression. This option protect against cookie tampering by encrypting cookies by a specific name or for all cookies that match a PCRE expression. 3. In the Cookie Encryption Secret field, enter a string which will be used to encrypt and decrypt the cookies. The encryption uses a secret passphrase to decrypt and encrypt cookies that are transferred between the Web server and client. 4. When finished, click Create to save your changes.



Configuring Server Filter Checks 1. Sele Select ct the the Server Filter Checks tab to display the list of security options that can be used to block or prevent the outbound responses from Web server to client. A window similar to that shown below appears. FIGURE FIGURE 19 WAF WAF Templ Template ate – Server Filter Filter Checks Checks

2. Sele Select ct the the Filter Response Headers checkbox to remove the Web server’s identifying headers in outgoing responses. 3. Sele Select ct the the Hide Response Codes checkbox to enable this option to cloak 4 xx and and 5 xx response response codes for outbound responses from the Web server. By default, this check uses the “ al l owed_r ed_r esp_codes esp_codes ” WAF policy file for a list l ist of acceptable HTTP response codes. However, However, you can click the Hide Response Codes s pecify a different file. For more information, see “Allowed HTTP HT TP file drop-down menu that appears to specify Response Respon se Codes” Codes” on page 110 110.. 4. Sele Select ct the the Redirect Whitelist checkbox 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 Redirect Mitigation” on page 22 22 for for details. 5. When When finis finished hed,, click click Create to save your changes.



Configuring Content Filter Checks 1. Sele Select ct the the Content Filter Checks tab to display the configurable content filtering optio ns. A window similar to that shown below appears. FIGURE FIGURE 20 WAF WAF Templa Template te – Conte Content nt Filter Filter Checks Checks

2. Sele Select ct the the CCN Mask checkbox checkbox if you want the WAF to examine strings of o f outbound replies from the Web server for patterns of numerical characters char acters that resemble credit card numbers (CCN). If the WAF identifies a credit card number, the WAF WAF replaces all but the last four digits of o f credit card numbers with “x” characters. NOTE:

From the CLI, you can view counters for the CCN check. These counters display the number of masked credit card numbers for various bank providers.

3. Sele Select ct the the SSN Mask checkbox checkbox if you want the WAF to scan HTTP HT TP responses for strings that resemble US Social Security numbers and masks all but the last four digits of the string with “x” characters in a response. 4. The PCRE Mask Mask hides strings strings that match match the specified specified PCRE PCRE pattern. pattern. (See “Writing PCRE Expressions” on page pa ge 11 113 3 for details.) In the PCRE fields, enter the following values: • PCRE Pattern – Masks patterns in

a response that match the specified PCRE pattern.

charac ter to masked the matched pattern of a str ing. By default, • PCRE Mask Character – Selects a character strings are masked with an “X” charac ter. • PCRE Keep Start – Sets the number of unmasked characters at

be 0-65535, the default is 0.


the beginning of the string. This can

A10 Thunder Series and AX Series Configure a WAF Template • 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 (*) o r 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 “\+”. “\+”.

5. When When finis finished hed,, click click Create to save your changes.

Configuring Form Checks 1. Sele Select ct the the Form Checks tab to display the list of security options that can be used to configure Web form options. A window similar to that shown below appears. FIGURE FIGURE 21 21 WAF WAF Templa Template te – Form Form Checks Checks

2. Sele Select ct the the Deny Forms Not Using POST checkbox to deny HTTP requests containing forms if the method used is anything other than POST. 3. Sele Select ct the the CSRF Check checkbox checkbox to tag the fields of a web form with a nonce no nce (a unique FormID). This check protects against cross-site request forgery (CSRF). 4. Sele Select ct the the Form Consistency Check checkbox checkbox to check that the user input to a Web form field conforms to the intended format for that entry. For example, it checks that a radio button is selected versus supplying a string for that form field. WAF also parses HTTP bodies encoded as multipart/form-data. Extracted form fields are verified against previously parsed HTML forms.



5. Select the Deny non-SSL Forms checkbox to deny user passwords that are sent over a non-encrypted connection. If the connection between the client and the WAF is secured with SSL/TLS, the user password is allowed, but if the client attempts to submit to a form field where “input type=password”, and if the connection is not encr ypted with SSL/TLS, the WAF blocks the transmission. (For more information, see “Deny Passwords Sent Over an Unencrypted Connection” on page 21.) 6. Select the Deny Caching of Form Responses checkbox to add “no-cache directives” if the HTTP response contains
tags. The “no-cache” behavior is enforced by adding the following headers: (1) Cache Control: no-cache, no-store, must-revalidate, (2) Pragma: no-cache, (3) Expires: 0 7. When finished, click Create to save your changes.

Configuring Password Checks 1. Select the Password Checks tab to display the list of security options related to password options. A window similar to that shown below appears. FIGURE 22 WAF Template – Password Checks

2. Select the Deny non-masked password fields checkbox to prevent “should 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”. (For more information, see “Deny Unmasked Passwords” on page 20.) 3. Select the Deny Autocompleted Passwords checkbox to deny web server attempts to transmit the form if one of the form fields type is set to “password” and if the “autocomplete=on/off” attribute is set to “on”. Enabling this option blocks browser “autocomplete” behavior. Although convenient for users, password auto-completion weakens security by allowing browsers to store user passwords in order to later guess the user’s password for some websites. (For more information, see “Deny Passwords if Autocomplete is Enabled” on page 21.) 4. Select the Deny non-SSL Passwords checkbox to deny HTTP requests containing forms if the transmission protocol used is anything other than SSL (TLS). 5. When finished, click Create to save your changes.


A10 Thunder Series and AX Series Create a WAF File

Create a WAF File You can create a WAF files that will be used to parse incoming requests that contain XML, SOAP, of JSON code. 1. Hover over Security on the menu bar, then select WAF. 2. Select the WAF Files tab. A table of WAF files appears, similar to that shown in Figure 23 below. FIGURE 23 Security > WAF > WAF Files

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 107 for background information. The WAF Policy table lists the default policy files, such as “bot_defs”, “jscript_defs”, and “sqlia_defs”. If the Bot Checks, Cross-Site Scripting (XSS) Check, or SQL Injection Checks are enabled in a WAF template, the policy files can be used to scrub incoming requests. For example, if the Bot Check option is enabled in the WAF template and a match is found on an incoming request (using the “bot_defs” file), the request we be denied automatically. You can copy the “bot_defs” file and modify the con-


A10 Thunder Series and AX Series Create a WAF File

tents to include or remove bot search terms. Simply click the Edit link, make changes, and save the new copy. To configure, click the Create button in the WAF Policy section. A window similar to that shown in Figure 23 on page 76 appears. ~ If selecting the Local radio button, then enter the name and definition, and then click Create. ~ If selecting the Remote radio button, enter the name, transport protocol (e.g., TFTP, FTP, SCP, SFTP), Host IP/FQDN, Port, Location, and user credentials (user/password) for the server where the file is located. Then click Create. •

XML Schemas – see “WAF XML Checks” on page 26 for background information. To configure, click the Create button in the XML Schemas section. ~ If selecting the Local radio button, then enter the name and definition, and click Create. ~ If selecting the Remote radio button, enter the name, transport protocol, Host IP/FQDN, and path to the file. Then click Create.

•

SOAP WSDLs – see “WAF SOAP Checks” on page 33 for background information. To configure, click the Create button in the SOAP WSDL section. ~ If selecting the Local radio button, then enter the name and definition, and then click Create. ~ If selecting the Remote radio button, enter the name, transport protocol (e.g., TFTP, FTP, SCP, SFTP), Host IP/FQDN, Port, Location, and option credentials (user/password) for the server where the file is located. Then click Create.

FIGURE 24 WAF > Files > (WAF Policy/XML Scheme/SOAP WSDL) > Create

6. Click the Update button.


A10 Thunder Series and AX Series Configure an HTTP Policy Template

Configure an HTTP Policy Template You can configure ACOS to override the WAF settings applied to the HTTP/HT TPS virtual port with another set of WAF settings, using an HTTP policy template. You can configure rules in the HT TP template to match on URLs, hostnames, or cookie names in traffic. For a general discussion of configuring an HTTP Policy Template, see “Overriding a WAF Template” on page 117.

Configure an HTTP Policy Template to Override a WAF Template You can configure an HT TP policy template as follows: 1. Hover over Security on the menu bar, then select WAF. 2. Select the HTTP Policies tab. A table listing the configured HTTP Policies appears. 3. You can create a new HTTP Policy Template by clicking the Create button, or simply click Edit link in the Actions column. The Create HTTP Policies window appears, as shown below: FIGURE 25 Create HTTP Policies

4. The Name field is not editable, since this example show how to update an existing HTTP polic y template. 5. In the Cookie Name field, enter the cookie name associated with this HT TP Policy. 6. In the Match Rules section of the window, click the Add button. The Add HTTP Policy Match Rule window appears, similar to that shown below:



FIGURE 26 Add HTTP Policy Match Rule

Configure rules that match on URLs, hostnames, or coo kie names. Client requests that match a rule in the HTTP policy template are handled using the alternative WAF template that you will later bind to the HTTP policy template. 7. To configure rules for matching: a. Click the Type drop-down list and select one of the follow rule types: •

URL

•

Host

•

Cookie Name

a. Click the Match Type drop-down list and select the match operation: •

Starts With

•

Ends With

•

Contains

•

Equals

b. In the Match field, enter the match pattern. • Equals string – matches only if the URL, hostname, or

cookie name completely matches the

specified string. • Starts-with string – matches only if the URL, hostname, or cookie name starts with the speci-

fied string. • Contains string – matches if the string appears anywhere within the URL, hostname, or cookie

name. • Ends-with string – matches only if the URL, hostname, or cookie name ends with the specified

string.



These match options are always applied in the order shown above, regardless of the order in which the rules appear in the configuration. The WAF template associated with the rule that matches first is used. If a template has more than one rule with the same match option (equals, starts-with, contains, or ends-with) and a URL matches on more than one of them, the most-specific match is always used. c. From the Service Group drop-down menu, select the desired drop-down menu that you wish to associate with this match rule. d. From the WAF drop-down menu, select the WAF template to which to bind this HT TP policy template. The WAF template you select will be used for traffic that matches the rule. e. Click the Add button. f. Repeat this process for each rule you wish to add to the HTTP Policy. 8. Click the Add button to save your changes. 9. In the Geo Location Matches section of the window, click the Add button. The Add HTTP Policy Geo Location Match Rule window appears, similar to that shown below: FIGURE 27 Add HTTP Policy Geo Location Match Rule

10.Enter the Geo Location. (See “Geo-location Based Blocking” on page 38 for more information.) 11.From the Service Group drop-down menu, select the desired drop- down menu that you wish to associate with this match rule. 12.From the WAF drop-down menu, select the WAF template to which to bind this HT TP policy template. The WAF template you select will be used for geo-location traffic that matches the rule. 13.Click the Add button to save your changes.


A10 Thunder Series and AX Series WAF Reporting

WAF Reporting ACOS offers a reporting feature that allows you to view WAF statistics through the Web GUI. Currently, this information can be displayed using the following WAF report types: • Top URL – this report type indicates the most frequently accessed URLs during a specified time inter-

val. • Top Violation – this report

type 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 – this report

type indicates the source IP where most attacks or iginated during a speci-

fied time interval. WAF Reporting can be helpful, because it provides complex information in a visual format, mak ing 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. To generate a WAF Report, follow the procedure below: 1. Hover over Security on the menu bar, then select WAF. 2. Select the Reporting tab. A window similar to that shown in Figure 28 appears.



FIGURE 28 WAF > Reporting (Top 10 URLs over Last Day)

3. Click the Report Type drop-down menu and select one of the following menu items: Top URL, Top Violation, or Top Attacker. 4. In the Top N field, enter the desired number (1–20). For example, entering 10 will result 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 the Start Time and End Time by selecting a date from the calendar window that appears.

NOTE:

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. In this example, the Top 10 Violations are shown. FIGURE 29 WAF Report with Top 10 Violations During Last Week

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 char t, and the second most common violation (Response Headers Filtered), appears in the second position from the top of the chart, and so on.

•

The horizontal axis shows Date Time, and the vertical axis is used to show the Count.

•

The blue dots represent the number of times a particular violation occurred during the time interval. In this example, a blue dot appears every hour.

•

You can optionally click the green Show Charts button (at upper right) to toggle between showing and hiding the charts.

7. (Optional) To see where attacks are coming from, you can select Top Attacker from the Report Type, and click Apply to generate the desired chart. A window similar to that shown in Figure 30 appears. In this example, the Top 10 Attackers are shown. However, in this particular example, the attacks are all coming from one hypothetical source IP address: 172.128.9.154.


A10 Thunder Series and AX Series Configure External Logging (recommended)

FIGURE 30 WAF Report with Top 10 Attackers During Last Day

Configure External Logging (recommended) Although optional, A10 Networks strongly recommends configuring external logging. It is the only mechanism supported for accessing WAF log messages. Logging of WAF events to external logging servers is suppo rted over TCP or UDP, although UDP is typically used for Syslog. You can configure logging to a single server or a group of servers. If you use a group of ser vers, ACOS balances the log traffic among the ser vers for optimal efficiency. Configuration Overview To configure web logging: 1. Create a server configuration for each log server. On each server, add a UDP port with the port number on which the log server listens for log messages. (While either TCP or UDP would work, Syslog typically uses UDP.) 2. Add the log servers to a service group. Make sure to use the round-robin load-balancing method. (This is the default method.) 3. (Optional) If logging over TCP, configure a TCP-proxy template to customize TCP settings for connections between ACOS and the log servers. For example, you can enable use of keepalive probes to ensure that the TCP connections with the log servers remain established during idle periods between logs.



4. Configure a logging template. Add the service group containing the log servers to the logging template. If you configure a custom TCP-proxy template, also add that template to the logging template. 5. Apply the logging template to the WAF template. External logging is activated once you bind the WAF template to a virtual port.

Configure Log Servers 1. Hover over ADC on the menu bar, then select SLB. 2. Select the Servers tab. 3. Click the Create button. A window similar to that shown below appears: FIGURE 31 Create WAF Logging server

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 por t information: a. Click the Create button. b. Enter the following:


A10 Thunder Series and AX Series Configure External Logging (recommended) •

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

•

Click Create. The port appears in the list of ports for this server.

8. Click Create again. The server appears in the list of servers. 9. Repeat this process to add additional servers, as needed.

Add Server to Service Group 1. Hover over ADC on the menu bar, then select SLB. 2. Select the Service Groups tab. 3. Click Create. A window similar to that shown below appears: FIGURE 32 Create Service Group

4. Enter a name for the service group in the Name field. 5. Click the Protocol drop-down and select UDP from the list. (Optionally, you could select TCP, but not recommended.)



6. Click the Algorithm drop-down and select the desired load balancing algorithm (e.g., Round Robin, Least Connection). 7. If desired, select the Health Check Disable checkbox, or if health checks are desired, then select one from the Health Monitor drop-down menu. 8. In the Member section, click Create to add the server. A window similar to that shown below appears: FIGURE 33 Adding a Member to the Service Group

a. For the desired Choose creation type radio button, select Existing Server. b. Click the Server drop-down list and select the ser ver(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 should be used for all the primary servers, but keep in mind that assigning the same priority value to the primary servers will cause the logs to be load balanced across the primary servers, and will NOT cause duplicate copies of the logs to be sent to multiple primary servers. For a detailed discussion and background information on how Priority works, please see the “Priority Affinity” chapter in the Application Delivery and Server Load Balancing 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) You can select Stats Data Disable checkbox 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 you wish to add to this service group.

Configure the Logging Template 1. Hover over ADC on the menu bar, then select Templates. 2. Select the General tab. 3. Click the Create button, and from the drop-down menu that appears, select Logging. A window similar to that shown below appears: FIGURE 34 Create Logging Template

4. In the Name field, enter a name for the template. 5. In the Format field, enter the log format. (See “WAF Log Examples” on page 104.) 6. In the Local Logging field, enter the local logging information. 7. Click the Service Group drop-down menu and select the service group that contains the log servers. 8. For the PCRE Mask radio button, select Enable or Disable. (See “Writing PCRE Expressions” on page 113 for details.) 9. If you configured a custom TCP-proxy template for logging over TCP, select the template from the dropdown. 10.Click the OK button.



Apply the Log Template to the WAF Template 1. Hover over Security on the menu bar, then select WAF. 2. Select the WAF Templates tab. 3. Click the Edit link next to the desired WAF template name to display the General Settings. (See Figure 11 on page 59.) 4. Click the Logging Template drop-down menu and select the logging template you just created. 5. Click the Update button.




A10 Thunder Series and AX Series Required Configuration

Configuring the WAF Using the CLI

The WAF operates on traffic that is addressed to the virtual IP address (VIP) and HTTP/HT TPS virtual port of your Web site. To apply WAF protection to the vir tual port, basic configuration is required. Additional, advanced configuration 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 123.

Required Configuration The minimum required configuration for the WAF consists of the following tasks: 1. Create a WAF template. 2. Bind the WAF template to the HTTP/HTTPS virtual port on the VIP. NOTE:

Configuration of other SLB resources required by the virtual por t, such as real servers 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 123.)

Create a WAF Template To create or modify a WAF template, use the following command at the global configuration level of the CLI: waf template template-name

For the template-name option, enter the name of an existing WAF template to modify the template’s configuration, or an unused name to create a new WAF template. This command enters the CLI configuration level for the template. If you plan to use all the default settings for the template (including Active Mode operation) no fur ther template configuration is required. To customize template settings, see “Optional Configuration” on page 93.


A10 Thunder Series and AX Series External Logging Configuration

Bind the WAF Template to the HTTP/HTTPS Virtual Port The WAF template goes into operation after you bind the template to an HTTP/HTTPS port. To bind a template to a virtual port, you must access the configuration level for the port. 1. From the global configuration level of the CLI, use the following command to access the configuration level for the virtual server that will receive HTTP/HTTPS traffic to be secured using the WAF: slb virtual-server name ipaddr

2. At the configuration level for the virtual server, use the following command to access the configuration level for the virtual port: port port-number {http

|

https}

3. At the configuration level for the virtual port, use the following command to bind the WAF template to the port: template waf template-name

External Logging Configuration Although optional, A10 Networks strongly recommends external logging. It is the only mechanism supported for accessing WAF data event messages. To configure external logging for WAF: 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


A10 Thunder Series and AX Series Optional Configuration

3. (TCP only) If logging over TCP, configure a TCP-proxy template to customize TCP settings for connections to log servers. For example, you can enable use of keepalive probes, to ensure that the TCP connections with the log servers remain established during idle periods between logs. a. Use the following command to create the TCP-proxy template and access the configuration level for it: slb template tcp-proxy template-name

b. Use the following command to set keep-alive probes: keepalive-probes num

4. Configure a logging template: a. Use the following command to create the logging template and access the configuration level for it: slb template logging 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

5. Bind the logging template to the WAF template: a. Use the following command to access the configuration level for the WAF template: waf template template-name

b. Use the following command to bind the logging template to the WAF template: template logging template-name

NOTE:

External logging is activated once you bind the WAF template that uses the logging template to an HTTP/HTTPS virtual port.

Optional Configuration This section provides syntax for the following WAF configuration options: •

Deployment mode

•

Custom policy files (definitions)

•

Request checks

•

Deny action (WAF response sent to client when a request is denied by the WAF)

•

Response checks



Set Deployment Mode The default operational mode for WAF is active. To change the operational mode, use the following command at the configuration level for the WAF template: deploy-mode {active | passive | learning}

You can deploy WAF in one of the following operational modes: • active – The WAF enforces the security checks configured on the template and sends events to the

external log server. • passive– The WAF sends events to the external log server only

and does not enforce any security

checks. • learning – The WAF template “learns” acceptable check p arameters based on a

stream of legitimate, secure traffic. In Learning Mode, the WAF continues to send events to the external log ser ver.

For more information, see “WAF Operational Modes” on page 49.

Customize WAF Policy Files CAUTION:

A mis-configured PCRE expression can negatively impact system performance. Do not apply a PCRE expression to a WAF policy file unless you are completely certain that the PCRE expression will achieve the desired result.

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 108.) 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. For more information, see “WAF Policy Files” on page 107.



Configure Security Checks for Requests To configure individual WAF security checks for requests, use the following commands: • allowed-http-methods method-list

– Use this command to specify the HT TP methods (GET, POST,

and so on) that are allowed in requests. – 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 108.

• bot-check

• 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 HT TP 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.

– 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 108

• csrf-check

– Use this command to specify the type of response string sent to a client when WAF denies a request

• deny-action response-type

– Sends a 403 Forbidden response to the client. The default string returns a generic “Request Denied!” page to the client.

• http-resp-403 resp-string

– Sends a 200 OK response to the client with • http-resp-200 resp-string The default string returns a generic “Request Denied!” page to the client.


the specified resp-string.

A10 Thunder Series and AX Series Optional Configuration • http-redirect url-string – Sends a 302 Found redirection address to the client with the URL spec-

ified in the redirect-url . • reset-conn – Terminates the client connection. • deny-non-masked-passwords – Prevents “should surfing” by denying the

web server’s attempt to send a form through the WAF unless the field type for the password field has been set to “password”. See “Deny Unmasked Passwords” on page 20.

• deny-non-ssl-passwords – Denies user passwords that are sent over a non-encrypted connection. If

the connection between the client and the WAF is secured with SSL/TLS, then the user password is allowed, but if the client attempts to submit to a form field where “input type=password”, and if the connection is not encrypted with SSL/TLS, then the WAF blocks the transmission. The feature is disabled by default, meaning that forms not using the SSL/TLS protocol will not be denied. See “Deny Passwords Sent Over an Unencrypted Connection” on page 21. • deny-password-autocomplete – Denies web server attempts to transmit the

form if one of the form fields type is set to “password” and if the “autocomplete=on/off” attribute is set to “on”. Enabling this option blocks browser “autocomplete” behavior. Although convenient for users, password auto-completion weakens security by allowing browsers to store user passwords in order to later guess the user’s password for some websites. See “Deny Passwords if Autocomplete is Enabled” on page 21. – Use this command to check that the user input to a form field conforms to the form field tag. WAF also parses HTTP bodies encoded as multipart/form-data. Extrac ted form fields are verified against previously parsed HTML forms.

• form-consistency-check

• form-deny-non-post

– Deny request with forms if the method is not POST.

• form-deny-non-ssl – Deny request with forms if the protocol is

not SSL.

• form-set-no-cache – Disable caching of form-containing responses. • http-check

– Use this command to check that user requests are compliant with HTTP protocols.

– 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-format-check

– Enforces parsing limits to protect backend servers against various types of denial-ofservice (DoS) attacks, which are designed to exhaust sys tem memory or CPU resources.

• json-limit

• 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 • max-string num – Limits the length of a string

object.

in a JSON request for a name or a value.

– Enabling this option logs a debug message on the successful completion of WAF requests, and not just for errors.

• log-succ-reqs

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


A10 Thunder Series and AX Series Optional Configuration • max-hdrs num – Specifies the maximum number of headers allowed in a request. • max-parameters num – Specifies the maximum number of parameters allowed in a request. • 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 co mmand 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 22 for details.

• referer-check {enable | only-if-present}

– 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 Web site. This check protects against CSRF attacks. safe-referer-domain safe-redirect-url

• 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 a n

invalid referer header, the request fails the check. However, the request does not fail the check if there is no referer header in the request. • 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 co okie. 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 20. • 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 33 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 108. • reject – denies requests that contain SQL injection attacks. • sanitize – removes the SQL injection attack and for wards 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 109. • 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 110. • url-check – The URL Check allows users to

access Web pages only by clicking hyperlinks on your protected Web site, 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 polic y file. For a deployment example



that includes configuration of the URL Check, see “Generate Allowed URL Paths for the URL Check” on page 127. • url-options option – This command is used to normalize requested URLs.

The url-options command helps shorten URLs, thus preventing buffer overflows from long URLs. • decode-entities - Decode entities, such as <, in an

internal URL.

• decode-escaped-chars - Decode escaped chars, such as

\r or \n, in an internal URL.

• decode-hex-chars - Decode hexadecimal characters, such as \%xx and \%u00yy, in an internal URL. • remove-comments - Remove comments from an internal URL. • remove-selfref - Remove self-references, such as /./ and /path/../, from an internal URL. • remove-spaces - Remove spaces from an internal URL.

NOTE:

ACOS 4.0 does not support the ability to decode a plus symbol “+” in the URL if it is being used to represent a space by the browsers.

• xml-format-check – Check HTTP body for XML format compliance. Incoming requests containing

XML code are checked for compliance with the XML 1.0 specification. (See “XML Format Checks” on page 27 for details.) • xml-limit – XML parsing limits. (See “XML Limit Checks” on page 29 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–65535. Default is 65535. • max-elem-child num – Limits the maximum number of children each element is al lowed, and

includes other elements, character information, and comments. Range is 1–65535. Default is 65535. • max-elem-depth depth – Limits the maximum number of nested levels in each

element.

Range is 1–65535. 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:////page.xml Range is 1–65535. Default is 128.


A10 Thunder Series and AX Series Optional Configuration • max-entity-exp num – Limits the number of entity expansions

allowed.

Range is 0–1024. Default is 1024. • max-entity-exp-depth num – Limits the maximum depth of nested entity expansions.

Range is 0–32. Default is 32. • max-namespace num – Limits the number of namespace declarations in

XML document.

Range is 0–256. Default is 16. • max-namespace-uri-len num – Limits the URL length for each namespace declaration.

Range is 0–1024. Default is 256. • xml-sqlia-check – Checks XML data against SQLIA policy. Checking for XML SQL Injection attacks

means the WAF examine the headers and bodies of incoming requests for inappropriate SQL special characters or keywords that might indicate the presence of an SQL Injection Attack (See “XML SQL Injection Checks” on page 32 for details.) – 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 27 for details.)

• xml-validation xml-schema [ resp-val] xml-schema-file-name

• 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 31 for details.) • xss-check {reject | sanitize} – Use this command to check for potential HTML XSS scripts to pro-

tect 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 108. • reject – denies requests that contain cross-site scripting. • sanitize – removes the detected XSS script and for wards the request to the Web server.

Configure Security Checks for Responses To configure individual WAF security checks for responses, use the following commands: – 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.

• ccn-mask

– Use this command to encrypt specified cookies matching PCRE pattern. Used to protect against cookie tampering by encrypting cookies before sending the server replies to a client. (See “Cookie Encryption” on page 133.)

• cookie-encrypt

• filter-resp-hdrs

– Use this command to removes the Web server ’s identifying headers in outgoing

responses.


A10 Thunder Series and AX Series Optional Configuration • hide-resp-codes – Cloaks 4 xx and 5 xx response codes for outbound responses from the

Web server.

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.

NOTE:

• 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. – Selects a character to mask the matched pattern of a • mask character •

string. The default is x .

For pcre-pattern, enter a PCRE expression. (See “Writing PCRE Expressions” on page 113.)

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 “\+”

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

• ssn-mask


A10 Thunder Series and AX Series WAF Event Types and Where They Are Logged

WAF Event Logging

This chapter describes where WAF events are logged and the format used for WAF log messages. There is no external logging by default. To configure external logging, see either of the following sections: •

Using the GUI – “Configure External Logging (recommended)” on page 84

•

Using the CLI – “External Logging Configuration” on page 92

NOTE:

After external logging is enabled, WAF messages for configuration events will be sent to the local log, but messages for data events will be sent to the external logging servers. Deny actions are not written to the log. To view the configured response to denied client requests, check the WAF template currently in use.

WAF Event Types and Where They Are Logged WAF log messages consist of the following basic event types: •

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 lo cal 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 ser vers. You can configure the WAF to use a single logging server or a group of servers. After you enable WAF logging to remote logging servers, WAF configuration events also are sent to the remote servers. In this case, the WAF configuration events are no longer sent to the lo cal logging buffer. Figure 35 shows the WAF logging behavior without external logging. WAF configuration events are logged locally. WAF data events are not logged.


A10 Thunder Series and AX Series WAF Event Types and Where They Are Logged

FIGURE 35 WAF logging without external log server

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. FIGURE 36 WAF logging with external log server


A10 Thunder Series and AX Series Log Format

Log Format For optimal interoperability, WAF uses the Common Event Format (CEF), an op en standard used by other security appliances and network devices. WAF log messages can contain the following fields: Timestamp

CEF: version| device-vendor | device-product|

| CEF-extension device-version| module| event-type| severity

Table 2 describes the data fields that can appear in WAF logs TABLE 2 WAF log data fields

Field

Description

Timestamp

Date and time that the log was generated, in the following format: Mon Day hh:mm:ss

CEF version device-vendor device-product device-version module event-type

CEF version. Vendor name, “A10”. A10 Thunder or AX model number. Advanced Core Operating System (ACOS) version. System module that generated the log message. For WAF messages, the module is “WAF”. WAF feature or policy on which the traffic matched. Examples: • 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


A10 Thunder Series and AX Series WAF Log Examples

TABLE 2 WAF log data fields (Continued)

Field

Description

severity

Severity of the event. • 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 ex tension for WAF uses the following elements: • src – Source IP of the request or response. • spt – Source protocol port of the request or response. • method – HTTP method used (if applicable). • req – URL in the request. •

n

– Number ( n) of bytes of content in the request

• msg – Message associated with the event type. • cs1 – Name of the template that was in use when the event was generated. • act – Action the WAF took in response to the event: • deny • allow • sanitize • learn • md – Deployment mode.

WAF Log Examples The following sections show some examples of WAF log messages. •

Basic Log Message

•

Bot Check

•

Learning Mode


A10 Thunder Series and AX Series WAF Log Examples

Basic Log Message Here is a sample log message: Dec 22 17: 13: 03 CEF: 0| A10| AX3200| 2. 7. 1| WAF| ht t p- check| 2| sr c=20. 20. 25. 10 spt =32462 dst =20. 20. 25. 130 dpt =80 r eq=" GET / t our s/ i ndex. ht ml HTTP/ 1. 1" 0 msg=" Learni ng: Updat i ng al l owed HTTP met hods" cs 1=waf 1 act =n md=l ear n

Table 3 labels each field in the message. TABLE 3 WAF log example

Field

Value

Timestamp

Dec 22 17:13:03 0 A10 AX3200 2.7.1 WAF http-check 2 src=20.20.25.10

CEF version device-vendor device-product device-version module event-type severity CEF-extension

spt=32462 dst=20.20.25.130 dpt=80 req=”GET /tours/index.html HTTP/1.1” 0 = Bytes of content in the request msg=”Learning: Updating allowed HTTP methods” cs1=waf1 act=learn md=learn

NOTE:

For more log examples, see “WAF Deployment and Logging Examples” on page 123.

Bot Check Here is an example of a WAF log that indicates the detection of a bad bot: Oct 20 18: 16: 13 CEF: 0| A10| AX3200| 2. 7. 1| WAF| bot - check| 6| sr c=20. 20. 25. 10 spt =30842 dst =20. 20. 25. 130 dpt =80 r equest =" GET / t our s/ i ndex. ht ml HTTP/ 1. 1" 0 msg=" Bad bot det ect ed! User - Agent " cs 1=w2 act =deny md=nr m

Here is the same message, formatted to more clearly show each field:


A10 Thunder Series and AX Series WAF Log Examples Oct 20 18: 16: 13 CEF: 0 A10 AX3200 2. 7. 1 WAF bot - check 6 sr c=20. 20. 25. 10 spt =30842 dst =20. 20. 25. 130 dpt =80 r equest =”GET / t our s/ i ndex. ht ml HTTP/ 1. 1” 0 msg=”Bad bot det ect ed! User - Agent dr i p” cs1=w2 act =deny md=nr m

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: Oct 19 16: 24: 43 CEF: 0| A10| AX3200| 2. 7. 1| WAF| buf - ovf | 2| sr c=20. 20. 25. 10 spt =1892 dst =20. 20. 25. 130 dpt =80 r equest =" GET / t our s/ i ndex. ht ml HTTP/ 1. 1" 0 msg=" Lear ni ng Mode: I ncr easi ng headers l engt h l i mi t f r om 0 t o 172" cs1=w2 act =l ear n md=l r n Oct 19 16: 25: 03 CEF: 0| A10| AX3200| 2. 7. 1| WAF| ht t p- check| 2| sr c=20. 20. 25. 10 spt =1892 dst =20. 20. 25. 130 dpt =80 r equest =" GET / t our s/ i ndex. ht ml HTTP/ 1. 1" 0 msg=" Lear ni ng Mode: I ncreasi ng max_hdrs f r om 0 t o 3" cs1=w2 act =l ear n md=l r n

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.


A10 Thunder Series and AX Series Pre-Loaded WAF Policies

WAF Policy Files

WAF Policy Files (also referred to as WAF Definitions) give you the ability to define a set of rules for customized security checks. WAF policy files enable you to specify security c hecks for enhanced response- and request-side protection to protect against security r isks, such as SQL injection attacks or forceful browsing. CAUTION:

Misconfigured PCRE expressions can negatively impact system performance. Do not apply a PCRE expression to a WAF policy file unless you are completely certain that the PCRE expression will achieve the desired result.

Pre-Loaded WAF Policies Default WAF policy files are pre-loaded onto ACOS to allow immediate protection against common threats. Default WAF policies apply to the following checks: •

XSS Check

•

Bot Check

•

SQLIA Check

•

URI White List

•

URI Black List

•

Hide Response Codes

If one of these checks is enabled and a WAF policy file is not specified, the default WAF policy file is ap plied. 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 its contents to fit your specific demands.



Table 4 lists pre-loaded WAF policy files TABLE 4 Pre-Loaded WAF Policy Files

Check

Policy File

Hide Response Codes Bot Check XSS Check SQLIA Check URI Black List

al l owed_r esp_codes bot _def s j sc r i pt _def s s ql i a_ def s ur i _ bl i s t _ def s ur i _ wl i s t _ def s

URI White List

Description Defines a list of permitted HTTP response codes. Defines a list of known bots. Defines a set of commonly used javascript commands. Defines common search terms for SQL injection attacks. Lists exclusion criteria for the URI Black List. See Table 5 on page 109. Lists inclusion criteria for the URI White List. See Table 6 on page 110.

Request Protection The following checks point to WAF policy files for enhanced protection against incoming requests. By default, these checks refer to the default WAF policy files, as described below. Optionally, you can configure these checks to use customized policy files.

Bot Check The WAF bot check option uses the “bot_ def s ” 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 “ j scr i pt _def s” 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 Web sites that use Javascript-based web content. NOTE:

If your Web site contains embedded Javascript, A10 Networks recommends enabling the XSS check in the WAF template.

SQL Injection Attack Check The WAF policy file “s ql i a_ def s” provides a basic collection of SQL special characters and keywords that are common to SQL injection attacks. The terms in this polic y file can trigger commands in the back-end SQL database and allow unauthorized users to obtain sensitive information. If a request contains a term that matches a search definition in the “s ql i a_ def s” policy file, you can configure the WAF to sanitize the request of the SQL command or deny the request entirely.



URI Black List A URI Black List specifies 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 takes priority over a URI White List. That is, even if a URI matches acceptance criteria within the URI White List, a connection is blocked automatically if it meets a rule in the separate URI Black List. Table 5 lists URI Black List criteria in the default “uri_blist_defs” file. TABLE 5 URI Black List – Default

Description

Attack Pattern

Access attacks

access, ^[ ^?] *( ?: ht access| access_l og) ( ?: [ . ] [ ^/ ?] * ) ? ( ? : [ ~] ) ?( ? : [ ? ] . * ) ?$ apache_di r , ^[ ^?] */ [ ?] [ SM] =[ AD]

Apache possible directory index disclosure vulnerability Command injection attack CodeRed Debug attacks Front Page server extensions buffer overflow-1 Front Page server extensions buffer overflow-2 Front Page server extensions path disclosure vulnerability HTR source disclosure Index server buffer overflow IIS executable file parsing vulnerability1 IIS executable file parsing vulnerability2 IIS executable file parsing vulnerability3 Microsoft IIS UNC mapped virtual host vulnerability Microsoft IIS UNC path disclosure vulnerability Nimbda-3 Nimbda-4 Netscape enterprise server directory indexing vulnerability Netscape enterprise server web publishing vulnerability Printer buffer overflow

cmd_ i nj , ( ? : [ / =] | \ t | \ n) ( ? : l s | r m| cat ) ( ? : [ ; ' \ " &] . * ) ?$ code_r ed, ^[ ^?] */ def aul t [ . ] i da[ ?] N+ debug, debug[ . ] [ ^/ ? ] * ( ? : | [ ? ] . * ) $ f p_sr vr _ext _bo1, ^[ ^?] *dvwssr [ . ] dl l f p_sr vr _ext _bo2, ^[ ^?] *f p30r eg[ . ] dl l f p_sr vr _ext _pb, ^[ ^?] */ _vt i _bi n/ sht ml [ . ] ht r _sd, ^[ ^?] *[ +] [ . ] ht r i dx_sr vr _bo, ^[ ^?] *[ . ] i d[ aq] i i s_exe_f p1, ^[ ^?] *[ +] di r i i s_exe_f p2, ^[ ^?] */ geor gi [ . ] asp i i s _exe_ f p3, ^[ ^? ] * [ . ] ( ? : bat | i ni | exe) ( ? : | [ ? ] . * ) $ i i s_unc_mvh, ^[ ^?] *[ . ] asp/ . * i i s_unc_pd, ^[ ^?] *[ . ] ht x ni mda3, ^[ ^?] *Admi n[ . ] dl l ni mda4, ^[ ^?] */ wi nnt / nses_di r _i dx, ^[ ^?] */ [ ?] wpnses_web_pub, ^[ ^?] */ publ i sher pr i nt _bo, ^[ ^?] */ NULL[. ] pr i nt er



TABLE 5 URI Black List – Default

Description

Attack Pattern

Password file attacks

pwd_f i l e, ^[ ^?] *( ?: passwd| passwor ds?) ( ?: [ . ] [ ^/ ?]*)?(?:[?].*)?$ s cr i pt , ^[ ^? ] * [ . ] ( ? : c gi | pl | php| bat ) ( ? : [ / ? ] . * ) ? [ | ] sys_cmd, syst em( ?: | \ t | \ n) *[ ( ?: ] uni x_ cor e , / cor e( ? : / . * ) ? $ uni x_ f i l e, [ \ \ / ] et c[ \ \ / ] ( ? : pas swd| gr oup| hos t s ) webhi t s_sd, ^[ ^?] *nul l [ . ] ht w

Script exploit System command attacks Unix core file attacks Unix file attacks Webhits source disclosure

URI White List You can configure the WAF to check the URIs of incoming requests and only accept connection attempts that meet specified criteria. A URI White List check compares the URI of an incoming request with the expressions contained in the URI Whitelist policy file. Connection requests are accepted only if the request matches a criterion in the URI White List. Table 6 lists URI White List criteria in the default “uri_wlist_defs” file.

TABLE 6 URI White List – Default

Description

Expression

URL Path Component Common file types

root , ^/ $

Common Web site scripts

s t a t i c , ^[ ^? ] +[ . ] ( ? : ht ml ? | s ht ml | j s | gi f | j pg| j peg| png| s wf | pi f | pdf | c ss | c sv) dynami c, ^[ ^?] +[ . ] ( ?: cgi | aspx?| j sp| php| pl ) ( ?: [ ?] . *) ?$

Response Protection This section describes policy-based security checks for outbound responses from the Web server.

Allowed HTTP Response Codes The WAF policy file “al l owed_r esp_codes ” lists acceptable HTTP response codes in outbound replies from the Web server. If the Hide Response Codes option is enabled within the WAF template, then response codes that do not match a value contained in the “al l owed_r esp_codes ” file are cloaked in replies.


A10 Thunder Series and AX Series Customize WAF Policy Files

Customize WAF Policy Files CAUTION:


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 how to write PCRE patterns for customized WAF policies. ACOS incorporates aspects of PCRE expressions for writing WAF policies, but does not support full PCRE functionality.

Syntax Check After the file is created or modified, a syntax check is automatically performed on the file. If yo u 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: •

Invalid PCRE syntax

•

Duplicate policies (more than one policy file containing the same PCRE expressions)

•

Pair of brackets missing the escape character sequence; for example: ( a| b) – Incorrect

instead of ( ? : a | b) – Correct

Using the CLI This section describes procedures to create, edit, or manage WAF policy files in the CLI.

Configure Policy Files To configure a WAF policy file using the CLI: 1. Enter the following command at the global configuration level: waf policy edit file-name



For the file-name option, enter the name of an existing WAF policy file to edit the file, or an unused name to create a new WAF policy. Do not include the “.waf” extension in the file name, this is automatically applied during creation. 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: Edi t i ng of def aul t WAF pol i cy f i l e not al l owed.

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 113. 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 you finish entering the policy text, the CLI performs a syntax check and displays one of the following messages: •

WAF file-name edi t ed; synt ax check passed. – Indicates the syntax is valid for file-name.

• WAF pol i cy synt ax er r or. Li ne n: –

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: waf copy source-name destination-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 Use the following command to rename a WAF policy file: waf policy rename old-name new-name

Delete Files

Enter the following command to delete a WAF policy file: waf policy delete file-name

NOTE:

You cannot rename, edit, or delete default files. However, you can copy a default WAF policy file and customize its contents to fit your specific demands.

Writing PCRE Expressions The following section provides guidelines for writing WAF policy files which the WAF can use to search for attack patterns or define policy rules.

General Guidelines This section summarizes common characters used in PCRE expressions and provides a quick reference to basic PCRE syntax. To learn more about writing detailed PCRE expressions, consult outside reference material. CAUTION:




PCRE Characters Table 7 describes frequently used characters in PCRE expressions. TABLE 7 PCRE Characters

Character

Purpose

\

Escape character. Start of a subject or line. End of a subject or line. Matches with any type of character. Character range. Use this symbol within square brackets.

^ $ . [ ] |

( ) * + { }

For example, [a-f] will indicate the range a, b, c, d, e, f. Start of a character class definition. End of a character class definition. Logical “or” operator. For example, (yellow | red | orange) will return tr ue if either yellow, red, or orange is found. Start of a sub-pattern. End of a sub-pattern. Quantifier for a value of 0 or more. Quantifier for a value of 1 or more. Start of a minimum or maximum quantifier. End of a minimum or maximum quantifier.

Enclose Patterns You can enclose patterns with any non-alphanumeric character that is not a backslash \ or whitespace. You can also use special symbols that may otherwise carry an alternative function as long as the same symbol is used in the beginning and end of the string. Table 8 displays a few valid examples of enclosed expressions: TABLE 8 PCRE Syntax – Enclose Patterns

Character

Example

+ / # % !

+posi t i ve+ / ahoy/ #numer i c# %per cent ages% ! eep!



Basic Syntax WAF policy files consist of PCRE expressions and comment lines. Lines with PCRE expressions are structured as follows: name, PCRE expression

The name is a string which you can use to title the line. Follow the description with a comma “,” before writing the PCRE expression. As shown below: FromDef aul t Bl ackLi st , ^[ ^?] *[ . ] ht x

NOTE:

Everything following the comma is included in the PCRE expression. Do not include whitespace unless this is intended as part of the expression.

Comments To insert a comment into the policy file enter a pound character ‘#’ before the comment line. exampl e_expr essi on, ^[ ^?] */ [ ?] wp# comment

...

Alternatively, you can enter a comment in-line as follows: (# comment)

The comment string is not recognized in pattern matching.

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 o f elements. Traffic matches a policy rule if the traffic matches any of the elements delimited by " | ". For example, "(apples | oranges)" is read as a single object that can be triggered when either "apples" or "oranges" is found in traffic.

•

Use parentheses to enclose each separate element. For example, the set of elements "(apples) (oranges)" is read by WAF as two individual objects: an "apples" object and an "oranges" object.

The following example uses a segment of the “bot _def s” file.


A10 Thunder Series and AX Series Customize WAF Policy Files ( bui l t bot t ough| bunnysl i pper s| capt ur e| cegbf ei eh| cher r ypi cker | cheesebot | chi nacl aw| ci cc| ci va| cl i ppi ng| col l age| col l ect or | copyr i ght check| cosmos| crescent | cust o| cyber al er t | deweb| di agem| di gger| di gi mar c| di i bot | di r ect updat e| di sco| di t t ospyder | downl oad accel erat or| downl oad demon| downl oad wonder )

To add three additional known bots under the names “brewster”, “nook” and “peanut”, you would modify the policy file similar to the following. The additions are indicated in bold: ( bui l t bot t ough| bunnysl i pper s| capt ur e| cegbf ei eh| cher r ypi cker | cheesebot | c hi nac l aw| c i c c| c i va| c l i ppi ng| c ol l age| c ol l ec t or | brewster|nook| copyri ghtcheck| cosmos| cr escent | cust o| cyberal ert | deweb| di agem| di gger | di gi mar c| di i bot | di r ectupdat e| di sco| di t t ospyder| downl oad accel er at or | downl oad demon| downl oad wonder |peanut)

Policy Rules You can write WAF policy files to list more complicated polic y 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: ^ht t p: / / i mg[ . ] exampl e[. ] 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: ^ht t p: / / www[ . ] exampl e[ . ] com/ ( ?: [ 0- 9A- Za- z] [ 0- 9A- Za- z_- ] */ ) * [ 0- 9A- Za- z ] [ 0- 9A- Za- z _ . - ] * [ . ] ( ? : c gi | 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}



Overriding a WAF Template

You can configure ACOS to override the WAF settings applied to the HTTP/HT TPS virtual port with another set of WAF settings, using an HTTP policy template. You can configure rules in the HT TP template to match on URLs, hostnames, or cookie names in traffic. To configure WAF override: 1. Configure a second WAF template with the alternative settings to use. See either of the following: •

Using the GUI – “Configure a WAF Template” on page 59

•

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.

Configure an HTTP Policy Template Within an HTTP policy template, you can configure rules that match on URLs, hostnames, or cook ie names. 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. Below are the match options:


A10 Thunder Series and AX Series Configure an HTTP Policy Template • Equals string – matches only if the URL, hostname, or cookie name completely matches the speci-

fied string. • Starts-with string – matches only if the URL, hostname, or

cookie name starts with the specified

string. • Contains string – matches if the specified string appears anywhere within the U RL, 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. ACOS( conf i g) #gsl b geo- l ocat i on Ameri ca. USA. LSG. LSG ACOS( conf i g- geo- l ocat i on: Amer i ca. USA. LSG. ) #i p 100. 100. 100. 1 mask 255. 255. 255. 255 ACOS( conf i g- geo- l ocat i on: Ameri ca. USA. LSG. ) #exi t ACOS( conf i g) #sl b t empl at e htt p- pol i cy waf - ht t p- pol i cy ACOS( conf i g- ht t p- pol i cy) #geo- l ocat i on Ameri ca. USA. LSG. LSG t empl at e waf waf - t empl at e- 1 ACOS( conf i g- ht t p- pol i cy) #exi t ACOS( conf i g) #sl b vi r t ual - server vs- geo_l ocat i on 100. 17. 3. 70 ACOS( conf i g- sl b vserver ) #por t 80 ht t p ACOS( conf i g- sl b vser ver - vpor t ) #t empl at e ht t p- pol i cy waf - ht t p- pol i cy

Use the GUI to Configure an HTTP Policy Template To configure a WAF HTTP policy template using the GUI: 1. Hover over Security on the menu bar, then select WAF. 2. Select the HTTP Policies tab. 3. Click Create. 4. Enter a name for the template in the Name field. 5. Configure match rules and other fields as desired; refer to the GUI online help for detailed information about each field.


A10 Thunder Series and AX Series Bind the HTTP Policy Template to the Virtual Port

6. Click Create.

Use the CLI to Configure an HTTP Policy Template To configure an HTTP policy template, use the slb template http-policy command at the global configuration level of the CLI. For more information about this command, refer to the Command Line Interface Reference. Below is an example of this command and HTTP policy template configuration: ACOS( conf i g) #slb template http-policy http-pol-temp1 ACOS( conf i g- ht t p- pol i cy) #url contains exampledomain template waf waf-temp1

Bind the HTTP Policy Template to the Virtual Port The HTTP policy does not take effect until you bind it to the HTTP/HT TPS 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: 1. Hover over Security on the menu bar, then select WAF. 2. Select the Bindings tab. 3. Click Create. 4. Select the virtual server name, IP address, and port and protocol to which you will bind the template. 5. In the HTTP Policy field, select the HTTP policy template you want to bind to the specified virtual port. 6. Click Create.

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 por t. For example: ACOS( conf i g) #slb virtual-server vs1 8.8.8.8 port 80 http ACOS( conf i g- sl b vser ver ) #

ACOS( conf i g- sl b vser ver - vpor t ) #template http-policy http-pol-temp1

For a complete CLI example, see “HTTP Virtual Port Configuration” on page 124.


A10 Thunder Series and AX Series Bind the HTTP Policy Template to the Virtual Port


A10 Thunder Series and AX Series 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.

Displaying WAF Statistics Use the GUI to View WAF Statistics You can use the GUI to view global WAF statistics by: 1. Hover over Security in the menu bar, then select WAF. 2. Select the Global Stats tab.

Use the CLI to View WAF Statistics From the CLI, use the show waf stats command to view statistics for a specific virtual server and virtual port. See “show waf stats” on page 156 for sample output.

Clearing WAF Statistics Use the GUI to Clear WAF Statistics You can use the GUI to clear global WAF statistics by: 1. Hover over Security in the menu bar, then select WAF. 2. Select the Global Stats tab. 3. Click Clear.


A10 Thunder Series and AX Series Clearing WAF Statistics

Use the CLI to Clear WAF Statistics From the CLI: •

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 166 for more information about this CLI command.


A10 Thunder Series and AX Series Initial Configuration

WAF Deployment and Logging Examples

This chapter provides some examples for WAF deployment. Since logging is a crucial part of WAF configuration and management of the WAF, the examples include applicable log messages. The following examples are provided: •

“Initial Configuration” on page 123

•

“Learning” on page 125

•

“Response Header Filtering” on page 129

•

“SQLIA Check” on page 131

•

“Cross-site Scripting Check” on page 131

•

“Cookie Encryption” on page 133

Initial Configuration The commands in this example configure the following resources: •

Logging configuration

•

WAF template

•

HTTP virtual port

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: ACOS( conf i g) #slb server waf-log2 10.10.10.22 port 514 tcp ACOS( conf i g- r eal server ) #


A10 Thunder Series and AX Series Initial Configuration ACOS( ( conf i g- r eal server - node port ) #exit ACOS( conf i g- r eal server ) #exit ACOS( conf i g) #slb service-group waf-log tcp member waf-log1 514 ACOS( conf i g- sl b svc gr oup) #

The following commands configure the TCP-proxy template, to enable keepalive messages: ACOS( conf i g) #slb template tcp-proxy logtcp ACOS( conf i g- t cp pr oxy) #keepalive-probes 4

The following commands configure the logging template. This includes binding the TCP-proxy template to the logging template. ACOS( conf i g- sl b) #slb template logging waf-log ACOS( conf i g- l oggi ng) #service-group waf-log tcp ACOS( conf i g- l oggi ng) #template tcp-proxy logtcp

WAF Template Configuration The following commands create a WAF template and bind the logging template to the WAF template: ACOS( conf i g) #waf template waf1 ACOS( conf i g- waf ) #template logging waf-log

HTTP Virtual Port Configuration The following commands configure an HTTP virtual port and bind the WAF template to the port. To begin, the following commands create server configurations for the web servers to be load balanced and protected by the WAF: ACOS( conf i g) #slb server http1 20.20.25.11 port 80 tcp ACOS( conf i g- r eal server ) #

ACOS( conf i g- r eal server - node por t ) #exit ACOS( conf i g- r eal server ) #exit ACOS( conf i g- waf ) #slb server http2 20.20.25.12 port 80 tcp ACOS( conf i g- r eal server ) #

ACOS( conf i g- r eal server - node por t ) #exit ACOS( conf i g- r eal server ) #exit

The following commands add the server configurations to a service group: ACOS( conf i g) #slb service-group http tcp member http1 80 ACOS( conf i g- sl b svc gr oup) # member http2 80 ACOS( conf i g- sl b svc gr oup) #


A10 Thunder Series and AX Series Learning

The following commands configure the virtual server and bind it to the service group and WAF template: ACOS( conf i g) #slb virtual-server http-vip 20.20.25.130 port 80 http ACOS( conf i g- sl b vser ver ) #

ACOS( conf i g- sl b vser ver - vpor t ) #service-group http ACOS( conf i g- sl b vser ver - vpor t ) #template waf waf1

At this point, the WAF is active. Log Example When done configuring, you can use the show log command to display log messages. These log messages indicate whenever a WAF template is updated, created, or deleted. Hypothetical log messages are shown below for illustration purposes. ACOS( conf i g: 8) #show l og Log Buf f er: 30000 Mar 24 2016 15: 37: 12 I nf o [ WAF] : CEF: 1| A10| AX3030| 4. 1. 0| WAF| Mar 24 2016 15: 37: 11| conf i g| 2| msg="Template waf-check-doc: buf-ovf max-hdr-value-len set to 65535" Mar 24 2016 15: 37: 12 I nf o

[ VCS] : dcs conf i g seq number i ncr ease ( 45, 0, 652)

Mar 24 2016 15: 37: 04 I nf o [ WAF] : CEF: 1| A10| AX3030| 4. 1. 0| WAF| Mar 24 2016 15: 37: 03| conf i g| 2| msg="Template waf-check-doc: bot-check ON (policy-file=bot_defs)" Mar 24 2016 15: 37: 04 I nf o


Mar 24 2016 15: 37: 02 I nf o [ WAF] : CEF: 1| A10| AX3030| 4. 1. 0| WAF| Mar 24 2016 15: 37: 01| conf i g| 2| msg="Template waf-check-doc created" Mar 24 2016 15: 37: 02 I nf o


Mar 24 2016 15: 36: 42 I nf o [ WAF] : CEF: 1| A10| AX3030| 4. 1. 0| WAF| Mar 24 2016 15: 36: 41| conf i g| 2| msg="Template waf-check-doc deleted"

NOTE:

If external logging has not been configured for the WAF, then the log messages will appear in the local log buffer of the ACOS device.

Learning The commands in this section use Learning Mode to dynamically set some WAF options based on traffic. NOTE:

This example assumes that the VIP using the WAF template is not yet receiving live traffic but is instead receiving known, valid traffic sent in order to preset WAF parameters. The following caution explains why.

CAUTION:

While Learning or Passive Mode is in operation, the WAF does not block any traffic. Only Active Mode blocks traffic.


A10 Thunder Series and AX Series Learning

Enable Learning Mode The following commands access the configuration level for the WAF template, and change the mode to Learning Mode: ACOS( conf i g) #waf template waf1 ACOS( conf i g- waf ) #deploy-mode learning Swi t chi ng t o l ear ni ng mode wi l l r eset al l WAF t empl at e par amet er s and may expose you t o at t acks i f done i n a pr oduct i on envi r onment . Ar e you sure you wi sh t o pr oceed? ( N/ Y) : y

Generate Traffic On a client device, the following requests are generated and sent to the HT TP virtual port: cur l - v ht t p: / / 20. 20. 25. 130/ t our s/ i ndex. ht ml cur l - v ht t p: / / 20. 20. 25. 130/ bat bl ue. ht ml cur l - v htt p: / / 20. 20. 25. 130/ f i l e_set / di r 00000/ about . ht ml

View External Log On the external log server, messages such as the following one indicate that the WAF is setting some of its parameters based on the traffic: Dec 22 17: 13: 03 CEF: 0| A10| AX3200| 2. 7. 1| WAF| http-check| 2| sr c=20. 20. 25. 10 spt =32462 dst =20. 20. 25. 130 dpt =80 r eq=" GET / t our s/ i ndex. ht ml HTTP/ 1. 1" 0 msg="Learning: Updating allowed HTTP methods" c s1=waf 1 act =n md=learn

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. Here are some more examples: Dec 22 17: 13: 03 CEF: 0| A10| AX3200| 2. 7. 1| WAF| buf-ovf| 2| sr c=20. 20. 25. 10 spt =32462 dst =20. 20. 25. 130 dpt =80 r eq=" GET / t our s/ i ndex. ht ml HTTP/ 1. 1" 0 msg="Learning: Increasing max-url-len from 0 to 17" cs1=waf 1 act =n md=learn Dec 22 17: 13: 03 CEF: 0| A10| AX3200| 2. 7. 1| WAF| buf-ovf| 2| sr c=20. 20. 25. 10 spt =32462 dst =20. 20. 25. 130 dpt =80 r eq=" GET / t our s/ i ndex. ht ml HTTP/ 1. 1" 0 msg="Learning: Increasing max-hdrs-len from 0 to 172" cs1=waf 1 act =n md=learn Dec 22 17: 13: 03 CEF: 0| A10| AX3200| 2. 7. 1| WAF| http-check| 2| sr c=20. 20. 25. 10 spt =32462 dst =20. 20. 25. 130 dpt =80 r eq=" GET / t our s/ i ndex. ht ml HTTP/ 1. 1" 0 msg="Learning: Increasing max-hdrs from 0 to 3" c s1=waf 1 act =n md=learn ...

View WAF Template Settings The following command displays the current template settings:


A10 Thunder Series and AX Series Learning ACOS( conf i g- waf ) #show def aul t - r unni ng- conf i g waf | sect i on waf waf t empl at e waf 1 al l owed- ht t p- met hods "GET POST" bot - check buf - ovf max- cooki e- l en 4096 buf - ovf max- cooki e- name- l en 64 buf - ovf max- cooki e- val ue- l en 4096 buf - ovf max- cooki es- l en 4096 buf - ovf max- dat a- par se 65536 buf - ovf max- hdr - name- l en 63 buf - ovf max- hdr - val ue- l en 4096 buf - ovf max- hdr s- l en 4096 buf - ovf max- l i ne- l en 1024 buf - ovf max- par amet er - name- l en 256 buf - ovf max- par ameter - t otal - l en 4096 ...

Generate Allowed URL Paths for the URL Check An additional WAF parameter you can set during Learning Mode is the URL Check. The URL Check prevents users from navigating directly to any URL paths other than the ones explicitly defined by the URL Check policy file. To configure the URL Check: 1. Set the WAF to Learning Mode. 2. Enable the URL Check within a WAF template. 3. Send secure traffic to the Web site. This step will generate a WAF policy file containing acceptable URL paths. 4. After the URL Check policy file has been generated, change the WAF operational mode to Active to enforce the URL Check on client requests.

Configuration Example The following example outlines steps for customizing the URL Check in learning mode and enforcing the check for your Web site. Create the URL Check Policy File 1. The following commands set the WAF to learning mode and enable the URL Check option in the WAF template: ACOS( conf i g) #waf template w1


A10 Thunder Series and AX Series Learning ACOS( conf conf i g- waf ) #deploy-mode learning Swi t chi ng t o l ear ear ni ng mode ode wi l l r eset al l WAF t empl at e par par amet er s and may exp expose ose you you t o at t acks acks i f done one i n a pr pr oducti oducti on envi envi r onm onment ent . Ar e you you sure you wi sh t o pr pr oceed oceed? ? ( N/ Y) : Y ACOS( conf conf i g- 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. 192.168.25.130.

2. Send secure traffic from a client. In this example, traffic from the client is sent to the following addresses: addresses: ht t p: / / 192. 168. 25. 130/ t our s/ i ndex. ht ml ht t p: / / 192. 168. 25. 130/ bat bl ue. ht ml ht t p: / / 192. 168. 25. 130/ f i l e_set _set / di r 00000/ about . ht ml

3. Check the logs on the external log server. The The log should contain a message such such as the following, for for each URL path requested: Mar 24 16: 16: 34: 34: 40 CEF: 1| A10| 10| AX3030 3030|| 4. 1. 0| WAF| Mar 24 2016 2016 15: 15: 46: 46: 12| 12| sess i ononi d| 2| sr c=172 172. 17. 17. 3. 100 spt =5515 55150 0 dst =172 172. 17. 17. 3. 61 dpt dpt =8080 080 hst =" 172 172. 17. 17. 3. 61: 61: 808 8080" cs1=waf - ur l - check cs2=90f 90f 0c225 0c225ff 82e4 82e4cb8 cb8 act =l ear n md=pass pass i ve svc=ht t p r eq= eq=" GET / f oooo/ oooo/ r est / upl upl oad/ oad/ aaa. aaa. t xt HTTP/ TTP/ 1. 1" 0 msg=" New sessi on cr eat eat ed: ed: I d=90f 90f 0c225f c225f 82e4 82e4cb8 cb8""

4. The log will contain similar messages for each URL path clients clients are allowed to access. The following commands verify that the URL Check policy polic y file is created and display the contents of the file: ACOS( conf conf i g- waf ) #show waf policy Tot al WAF pol i cy number : 14 Max WAF pol pol i cy f i l e si ze: 32K Name Synt ax Templ at e - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - -- - - - - - _w _ w1_ur l _ check_ Check Bi nd al l owed_r ed_r esp_code esp_codes s Check heck Bi nd bot bot _def s Check heck Bi nd j sc r i pt _ def s Check Bi nd ... ACOS( conf conf i g- waf ) #show waf policy _w1_url_check_ Name: _w1_ur _w1_ur l _c heck_ heck_ Synt Synt ax: Check heck I n WAF Templ at e: w1 ( f or ur l - che check) ck) Cont ont ent ent : Mat ches Val ue - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - -- - - - - - - - 1 / t our s/ 1 / bat bl ue. ue. ht ml 1 / f i l e_set _set / di r000 r00000/


A10 Thunder Series and AX Series Response Header Filtering

Apply the URL Check 5. Change the WAF WAF deployme deployment nt mode. mode. (See “Save Template Template Settings” on page 129 129.) .) When you change the deployment mode from Learning Mode, ACOS writes the observed URL paths into a polic y file. The URL Check will start operating. ACOS( conf conf i g- waf ) #waf template w1 ACOS( conf conf i g- 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 edit the contents 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 WAF template in Learning Mode with the URL Check enabled.

Save Template Settings To To “lock down” WAF WAF template settings configured by Learning Learning Mode, change the mode. The following command changes to Passive Mode: ACOS( conf conf i g- waf ) #deploy-mode passive

In Passive Mode, WAF WAF checks are performed per formed but the filter actions are not applied. Requests to the HTTP virtual port are logged lo gged but are sent to the server ser ver without being altered. (For more information, see “WAF Operational ation al Modes” on page page 49 49.).)

Response Header Filtering Header Response Filtering removes the Web server ’s identifying headers in outgoing responses. This information can be exploited by hackers to send an attack targeted specifically to your server’s operating system (OS). Header That Includes OS-identifying Fields Here is an example of header fields in the HT TP response from a ser ver. ver. The fields shown in bold provide information about the server OS.


A10 Thunder Series and AX Series Response Header Filtering < HTTP/ 1. 1 200 OK < Tr ansf ansf er - Encod Encodii ng: ng: chunke chunked d < Cont ont ent ent - Type Type:: t ext ext / ht ml < Ser Ser ver : hpd hpd < X- Power eded- By: Cavi ss on < X- AspNet - Vers i on: on: 1. 0 < X- AspNet spNet Mvc- Ver si on: on: 2. 0 < Cacheache- Cont ont r ol : publ publ i c, maxax- age= age=100 100 < Age: Age: 52 < Vi a: AX- CACHE- 2. 7: 130 130 < ...

Header Without OS-identifying Fields Here is the same excerpt from the server response, with the OS-identifying headers removed: < HTTP/ 1. 1 200 OK < Tr ansf ansf er - Encod Encodii ng: ng: chunke chunked d < Cont ont ent ent - Type Type:: t ext ext / ht ml < Cacheache- Cont ont r ol : publ publ i c, maxax- age= age=100 100 < Age: Age: 0 < Vi a: AX- CACHE- 2. 7: 130 130 ...

The response received by the client client does not contain the OS-identifying headers.

Enable Header Response Filtering The following commands access the configuration level level for the WAF WAF template and enable Header Response Filtering: ACOS( conf conf i g) #waf template waf1 ACOS( conf conf i g- waf ) #filter-resp-hdrs

View External Log Messages in the external WAF log indicate when header fields are removed by Header Response Filtering: Mar 24 16: 16: 39: 39: 12 CEF: 1| A10| 10| AX3030 3030|| 4. 1. 0| WAF| Mar 24 2016 2016 15: 15: 50: 50: 44| 44| sess i ononi d| 2| sr c=172. 172. 17. 17. 3. 100 spt =50621 0621 dst dst =172. 172. 17. 17. 3. 73 dp dpt =8080 080 hst =" 172 172. 17. 17. 3. 73: 808 8080" cs1=waffilter-resp-hdrs cs2=8c59e 8c59eff 7f c665d c665dbb bb act =l ear n md=act i ve svc=ht t p r eq= eq=" GET / hel hel l o. php php HTTP/ TTP/ 1. 1" 0 msg=" New sess i on cr eat ed: ed: I d=8c59e 8c59eff 7f c665d c665dbb bb"" Mar 24 16: 16: 39: 39: 12 CEF: 1| A10| 10| AX3030 3030|| 4. 1. 0| WAF| Mar 24 2016 2016 15: 15: 50: 50: 44| 44| filter-resphdrs| 6| sr c=172. 17. 3. 100 spt =50621 dst =172. 17. 3. 73 dpt dpt =8080 hst =" " cs1=waf - f i l t er- r espesp- hdr hdr s cs2=8c59e 8c59eff 7f c665d c665dbb bb act =sani t i ze md=act i ve svc=ht svc=ht t p r eq= eq=" GET / hel l o. php php HTTP/ 1. 1" 135 135


A10 Thunder Series and AX Series SQLIA Check msg="Header Server filtered"

Mar 24 16: 39: 12 CEF: 1| A10| AX3030| 4. 1. 0| WAF| Mar 24 2016 15: 50: 44| filter-resphdrs| 6| sr c=172. 17. 3. 100 spt =50621 dst =172. 17. 3. 73 dpt =8080 hst =" " cs1=waf - f i l t er- r esp- hdr s cs2=8c59ef 7f c665dbb act =sani t i ze md=act i ve svc=ht t p r eq=" GET / hel l o. php HTTP/ 1. 1" 135 msg="Header X-Powered-By filtered"

Mar 24 16: 39: 12 173. 17. 3. 14 A10 Mar 24 16: 39: 12 200. 0. 0. 14 A10

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 s upposed to contain SQL code.

Enable the SQLIA Check The following commands access the configuration level for the WAF template and enable the SQLIA Check. In this example, the sanitize option is used. This option removes the SQL and then forwards the request. ACOS( conf i g) #waf template waf1 ACOS( conf i g- waf ) #sqlia-check sanitize

View External Log The following log messages indicates that SQL was detected in a request: Mar 24 17: 13: 21 CEF: 1| A10| AX3030| 4. 1. 0| WAF| Mar 24 2016 16: 24: 52| sess i oni d| 2| sr c=172. 17. 3. 100 spt =44427 dst =172. 17. 3. 57 dpt =8080 hst =" 172. 17. 3. 57: 8080" cs1=wafsql-check-sanitize cs 2=61b6f 0af 51703b87 act =l ear n md=act i ve svc =ht t p r eq=" GET / hel l o. php?aa=bb- - HTTP/ 1. 1" 0 msg=" New ses si on cr eat ed: I d=61b6f 0af 51703b87" Mar 24 17: 13: 21 CEF: 1| A10| AX3030| 4. 1. 0| WAF| Mar 24 2016 16: 24: 52| sqliacheck| 6| sr c=172. 17. 3. 100 spt =44427 dst =172. 17. 3. 57 dpt =8080 hst =" 172. 17. 3. 57: 8080" c s1=waf-sql-check-sanitize c s2=61b6f 0af 51703b87 act=sanitize md=act i ve svc =ht t p r eq=" GET / hel l o. php?aa=bb- - HTTP/ 1. 1" 0 msg="SQLIA pattern detected! bb-- matches #1 in rule1 sanitizing.."

Mar 24 17: 13: 22 1730: : 14 A10

Cross-site Scripting Check The Cross-site Scripting Check (XSS Check) protects against cross-site scripting attacks.


A10 Thunder Series and AX Series Cross-site Scripting Check

Enable the XSS Check The following commands access the configuration level for the WAF template and enable the XSS Check. In this example, the reject option is used. This option logs the XSS attempt and then drops the request instead of forwarding it to the server. ACOS( conf i g) #waf template waf1 ACOS( conf i g- waf ) #xss-check reject

View External Log The following log message indicates that an XSS attempt was detected and denied: Mar 24 17: 17: 03 CEF: 1| A10| AX3030| 4. 1. 0| WAF| Mar 24 2016 16: 28: 35| sess i oni d| 2| sr c=172. 17. 3. 100 spt =58140 dst =172. 17. 3. 54 dpt =81 hst =" 172. 17. 3. 54: 81" cs1=waf-xsscheck cs2=f f de33f 6f f 0df a70 act =l ear n m d=act i ve svc=ht t p r eq=" POST / di gest . ht ml HTTP/ 1. 1" 9 msg=" New sessi on cr eat ed: I d=f f de33f 6f f 0df a70" Mar 24 17: 17: 03 CEF: 1| A10| AX3030| 4. 1. 0| WAF| Mar 24 2016 16: 28: 35| xsscheck| 6| sr c=172. 17. 3. 100 spt =58140 dst =172. 17. 3. 54 dpt =81 hst =" 172. 17. 3. 54: 81" cs1=wafxss-check cs2=f f de33f 6f f 0df a70 act=deny md=act i ve svc=ht t p r eq=" POST / di gest . ht ml HTTP/ 1. 1" 9 msg="Javascript pattern detected! applet matches #1 in a1" Mar 24 17: 17: 04 173. 17. 3. 221 A10

Since the reject option is used in the configuration, a Deny page such as the one in “Deny page” on page 132 is sent to the client. FIGURE 37 Deny page


A10 Thunder Series and AX Series Cookie Encryption

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 encry pt cookies that are transferred between the Web server and client. The following commands access the configuration level for WAF template “resetti” and configure encryption for all cookies containing “hiddencookie” in the name: ACOS( conf i g) #waf template resetti ACOS( conf i g- waf ) #cookie-encrypt ".*hiddencookie" r0cc0

The secret value “r0cc0” is used for encryption. To view the encrypted value created by the WAF and used in responses, display the configuration: ACOS( conf i g- waf ) #show default-running-config | section waf waf t empl at e waf 1 ... cooki e- encr ypt " . *hi ddencooki e" s ecr et - encr ypt ed m3nvbYs/ EBg8EI y41dsA5zwQj Lj V2wDnPBCMuNXbAOc8EI y41dsA5zwQj Lj V2wDn ...

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.


A10 Thunder Series and AX Series Cookie Encryption


A10 Thunder Series and AX Series

WAF Template Reference

WAF templates allow you to easily enforce the following security filters. Table 9 lists the parameters you can configure. NOTE:

This table is a reference. For configuration procedures, see either of the following: “Configuring the WAF Using the GUI” on page 57 “Configuring the WAF Using the CLI” on page 91



TABLE 9 WAF Template Options

Parameter

Description and Syntax

Supported Values

General Fields Template Name

Name of the WAF template in the ACOS configuration.

String Default: Not set

[ no] waf template template-name GUI: Deployment Mode

Security > WAF > WAF Templates > Create Sets the operational mode for the WAF template.

You can select one of the following:

[ no] deploy-mode {active | passive | learning}

• Active – Standard operational mode. You

GUI:

• Passive – Provides passive WAF opera-

Security > WAF > WAF Templates > Create, and then select the Deploy Mode drop-down. (For more information, see “WAF Operational Modes” on page 49.)

must use Active Mode if you want t he WAF to sanitize or drop traffic based on the configured WAF policies. tion. All enabled WAF checks are applied, but no WAF action is performed upon matching traffic. This mode is useful in staging environments to identify false positives for filtering. • Learning – Provides a way to initially set

the thresholds for certain WAF checks based on known, valid traffic. Logging

Applies a configured logging template to the WAF template. See “WAF Event Logging” on page 101.

Default: Active Mode Name of a logging template Default: None selected

[ no] template logging template-name GUI: Security > WAF > WAF Templates > Create, and then select the Logging Template drop-down.

Request Checks URI White List

Enforces the rules contained within a WAF policy file for the URI White List. For more information about URI White Lists, see “URI White List” on page 110.

Name of a WAF policy file Default: uri_wlist_defs

[ no] uri-wlist-check file-name GUI: Security > WAF > WAF Templates > Create, and then select the HTTP Requests Check tab, and select the checkbox for URI White List Check .



TABLE 9 WAF Template Options (Continued)

Parameter


Supported Values

URI Black List

Enforces the rules contained within a WAF policy file for the URI Black List. For more information about URI Black Lists, see “URI Black List” on page 109.

Name of a WAF policy file Default: uri_blist_defs

[ no] uri-blist-check file-name GUI: Security > WAF > WAF Templates > Create, and then select the HTTP Requests Check tab, and select the checkbox for URI Black List Check . Deny Action

WAF response sent to the client if traffic is denied by the WAF template. [ no] deny-action options resp-string

GUI: Security > WAF > WAF Templates > Create, and then select the General tab, and select the Deny Action drop-down.

One of the following: • http-resp-403 – Sends a 403 Forbidden

response to the client. The default string returns a generic “Request Denied!” page to the client. • http-resp-200 – 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 – Redirects the client to the

specified URL. • reset-conn – Sends a TCP RST to the cli-

ent to end the connection. Allowed HTTP Methods

Checks requests to ensure they contain only the HTTP methods that are allowed by this option. [ no] allowed-http-methods method-name

GUI: Security > WAF > WAF Templates > Create, and then select the HTTP Request Checks tab, and in the Allowed HTTP Methods field, click the desired methods to highlight them.

Default: http-resp-403 Valid HTTP method names: • GET • POST • HEAD • PUT • OPTIONS • DELETE • TRACE • CONNECT • PURGE

Default: GET, POST




Parameter


Supported Values

Bot Check

Checks the user-agent of incoming requests for known bots. This check uses the list of defined bots in the specified WAF policy file. See “Bot Check” on page 108.

Name of a WAF policy file Default: bot_defs Default: Disabled

[ no] bot-check file-name GUI: Security > WAF > WAF Templates > Create, and then select the HTTP Request Checks tab. Then select the Bot Check checkbox, and from the drop-down menu that appears, select the Bot Check Policy File.




Parameter


Supported Values

Disable Buffer Overflow Protection

Checks for attempts to cause a buffer overflow on the Web server.

Enabled or Disabled

• Max Cookie Length – Sets the maximum

length for cookies, cookie names, and/or cookie values allowed in a request. • Max Headers Length – Sets the maximum

header length for headers, header names, and/ or header values allowed in requests. • Max Line Length - Sets the maximum length

for lines. • Max Parameters Length - Sets the maximum

parameter length allowed for the total parameters, the parameter names, and/or the parameter values. • Max Post Size – Sets the maximum content

length allowed in HTTP POST requests. • Max Query Length - Sets the maximum length

for queries. • Max URL Length – Sets the maximum URL

length allowed in requests. [ no] buf-ovf {disable | max-cookie-len | max-cookie-name-len | max-cookie-value-len | max-cookies-len | max-data-parse | max-hdr-name-len max-hdr-value-len | max-hdrs-len | max-line-len | max-parameter-name-len | max-parameter-total-len | max-parameter-value-len | max-post-size | max-query-len | max-url-len} [ bytes]

[ no] max-parameters GUI: Security > WAF > WAF Templates > Create, and select the Overflow Checks tab.


The maximum accepted URL length can be set between 0 to 16127. The maximum accepted length for all other limits can be set between 0 to 65535. Default: Enabled If enabled, the following default values apply: • Max Cookie Length – 4,096 • Max Cookie Name Length - 64 • Max Cookie Value Length - 4,096 • Max Total Cookies Length - 4,096 • Max Data To Parse - 65,536 • Max Header Name Length - 64 • Max Header Value Length - 4,096 • Max Header Length – 4,096 • Max Line Length - 1,024 • Max Parameter Name Length - 256 • Max Parameter Total - 4,096 • Max Parameter Value Length - 4,096 • Max Query Length - 1,024 • Max URL Length – 1,024 • Max POST content size – 20,480



Parameter


Supported Values

Cross-Site Forgery (CSRF) Check

Tags fields of a web form to protect against crosssite request forgery (CSRF).

Enabled or Disabled Default: Disabled

[ no] csrf-check GUI: Security > WAF > WAF Templates > Create, and select the Form Checks tab. Then select the checkbox for CSRF Check .

Form Consistency Check

Checks that user input to form fields is consistent with the intended format.


[ no] form-consistency-check GUI: Security > WAF > WAF Templates > Create, and select the Form Checks tab. Then select the checkbox for Form Consistency Check .

HTTP Check

Checks that user requests are compliant with HTTP protocols.


[ no] http-check GUI: Security > WAF > WAF Templates > Create, and then select the HTTP Request Checks tab. Then select the checkbox for HTTP Check . Session Check

Checks that user requests match a unique session ID created for them.

1-1440 Default: 10

[ no] session-check [ secs] GUI: Security > WAF > WAF Templates > Create, and then select the Session Checks tab. Then select the checkbox for Session Check , and from the Session Check Lifetime field that appears, enter the session lifetime in minutes.




Parameter


Supported Values

Max Cookies

Specifies the maximum number of cookies a request can contain.

0-63 Default: 20

[ no] max-cookies num GUI: Security > WAF > WAF Templates > Create, and then select the Overflow Checks tab. Then enter the number in the Max Cookies field. Max Headers

Specifies the maximum number of headers a request can contain.

0-255 Default: 20

[ no] max-hdrs num GUI: Security > WAF > WAF Templates > Create, and then select the Overflow Checks tab. Then enter the number in the Max Request Headers field. Max HTML Parameters

Specifies the maximum number of parameters a request can contain. [ no] max-parameters num GUI: Security > WAF > WAF Templates > Create, and then select the Overflow Checks tab. Then enter the number in the Max HTML Parameters field.


0-1024 Default: 64



Parameter


Supported Values

Referer Check

Validates that the referer header in a request contains Web form data from the specified Web server, rather than from an outside Web site. This check protects against CSRF attacks.

One of the following:

• Enabled – Always validates the referer header. If

• Only-If-Present

selected, the request fails the check if there is no referer header or if the referer header is invalid. • Disabled – Configures WAF to not validate

requests based on the referer header. • Only-If-Present – Validates the referer header

• Enabled • Disabled

If this check is activated, you can set the following additional options: • Allowed Referer Domains – String • Safe URL – String

Default: Disabled

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 referer header in the request. [ no] referer-check {enable | only-if-present} GUI: Security > WAF > WAF Templates > Create, and then select the HTTP Request Checks tab. Then select the checkbox for Referer Check . SQL Injection Attack (SQLIA) Check

Checks 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 108.


[ no] sqlia-check {reject | sanitize}

Definition – Name of a configured WAF policy file

GUI:

Default: Disabled

• Reject • Disabled • Sanitize

Security > WAF > WAF Templates > Create, and then select the Injection Checks tab. Then select the Sanitize or Reject radio button.




Parameter


Supported Values

Cross-site Scripting (XSS) Check

Checks 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 108.


[ no] xss-check {reject | sanitize}

Default: Disabled

• Reject • Disabled • Sanitize

GUI: Security > WAF > WAF Templates > Create, and then select the Form Checks tab. Then select the checkbox for CSRF Check . URL Check

Select this option to prevent users from accessing the URLs of your website directly. The URL Check allows users to only access Web pages by cli cking 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 127. [ no] url-check GUI: Security > WAF > WAF Templates > Create, and then select the HTTP Request Checks tab. Then select the checkbox for URL Check .





Parameter


Supported Values

URL Options

Use this command to normalize request URLs. This helps shorten the URLs and helps protect web servers from attacks that 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 in order to gain access to sensitive directories or unauthorized files. See “Normalization Enhancements for URL Options” on page 24. URL Normalization Options include: • Decode Entities • Decode Escaped Characters • Decode HEX Characters • Comment Removal • Remove Self-References • Remove Spaces

[ no] url-options GUI: Security > WAF > WAF Templates > Create, and then select the HTML Request Checks tab.

Response Checks CCN Mask

Replaces all but the last four digits of credit card numbers with an “x” character.


[ no] ccn-mask GUI: Security > WAF > WAF Templates > Create, and then select the Content Filter Checks tab, and select the CCN Mask checkbox. SSN Mask

Replaces all but the last four digits of US Social Security numbers with an “x” character.


[ no] ssn-mask GUI: Security > WAF > WAF Templates > Create, and then select the Content Filter Checks tab, and select the SSN Mask checkbox.




Parameter


Supported Values

Filter Response Headers

Removes the Web server’s identifying headers in responses. By default, this check uses the “allowed_resp_codes” WAF policy file for a list of acceptable HTTP response codes.


[ no] filter-resp-hdrs GUI: Security > WAF > WAF Templates > Create, and then select the Server Filter Checks tab, and select the Filter Response Headers checkbox. Hide Response Codes

“Cloaks” your Web servers by hiding response codes from them instead of forwarding them to the client. [ no] hide-resp-codes waf-policy-file-name

GUI: Security > WAF > WAF Templates > Create, and then select the Server Filter Checks tab, and select the Hide Response Codes checkbox.


Enabled or Disabled Default: Disabled Definition – Name of a configured WAF policy file If disabled, the default policy file is “allowed_resp_codes”



Parameter


Supported Values

PCRE Mask

Cloaks patterns in a response that match the specified PCRE pattern.

You can specify the following options:

• PCRE Pattern – Specifies the pattern to search

• Mask – Single character

for in responses. • Mask – Selects a character to mask the matched

pattern of a string. • Keep Start – Sets the number of unmasked

characters at the beginning of the string. • Keep End – Specifies the number of unmasked

characters at the end of the string. [ no] pcre-mask pcre-pattern [ keep-end num-length | keep-start num-length | mask character ]

• PCRE Pattern – Valid string • Keep Start – 0-65535 • Keep End – 0-65535

Default: • PCRE Pattern – Not set • Mask – x • Keep Start – 0 • Keep End – 0

GUI: Security > WAF > WAF Templates > Create, and then select the Content Filter Checks tab. Cookie Encryption Secret

Uses the specified Secret string to encrypt and decrypt cookies in ser ver to client communication. For Cookie Name, you can enter the name of a specific cookie as a string, or a PCRE expression to encrypt all cookies which match the expression.

Cookie Name – String or PCRE expression Cookie Encryption Secret – String Default: Not set

[ no] cookie-encrypt {cookie-name | pcre-pattern} GUI: Security > WAF > WAF Templates > Create, and then select the Cookie Encryption Checks tab.


WAF CLI Command Reference

This chapter lists the CLI commands for WAF. The commands are organized into the following section: •

“WAF Template Commands” on page 147

•

“WAF File Management Commands” on page 167

WAF Template Commands The commands in this section configure WAF template parameters: •

waf template

•

show waf stats

•

clear waf stats


A10 Thunder Series and AX Series WAF Template Commands

waf template Description

Configure a WAF template.

Syntax

[ no] waf template template-name

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

Description

[ no]

Specifies the HTTP methods that requests are allowed to contain.

allowed-http-methods method-list

For example, method list : allowed-http-methods “GET POST”

Default methods are GET and POST, but you can specify the following: • GET • POST • HEAD • PUT • OPTIONS • TRACE • CONNECT • DELETE • PURGE • PROPFIND • PROPPATCH • MKCOL • COPY • MOVE • LOCK • UNLOCK

[ no] bot-check waf-policy

Checks user requests for bot activity. This check uses the specified WAF policy file for a list of search terms. For more information see, “Bot Check” on page 108. By default, bot-checks are disabled.



Command

Description

[ no] brute-force option

Configure protection against brute-force attacks. The sub-options for this command can include the following: • challenge-limit num – Specify the maximum number of triggers that

can occur within the test period. If this limit is breached, then the WAF initiates all of the configured chal l enge- act i ons against the client. Setting this field to zero disables the feature and the challenge will never be sent. You can set a value from 0-65535. The default is 2. • global – When enabled, this option will cause the WAF to maintain a single

counter for all clients, as opposed to having a separate counter for each client. When enabled, all clients will be locked out for the configured l ockout - per i od once the lockout-limit is reached. Similarly, all responses will include a challenge once the chal l enge- l i mi t is reached. This default is disabled. • lockout-limit – This options sets the maximum number of brute-force

events (or triggers) that can occur within the test period. If the limit is exceeded, then the WAF will deny all future requests from this cl ient. You can set a value from 0-65535. The default i s 5. If the lockout limit is set to zero, then clients will never be locked out. The lockout-limit is a learned parameter, so it will be set to the maximum number of triggers within a test period seen during learning mode. – This option sets the number of seconds that a client • lockout-period should be locked out. You can set a value from 0-1800. The default is 600. • resp-codes name – This option triggers a brute-force check based on the

HTTP response code. Specify the name of the WAF policy that will be used to define which response codes will trigger brute force checking. You must configure this policy file prior to setting this parameter, and it must contain a set of regular expressions that will be matched against the response status-code. • resp-headers name– This option triggers a brute-force check based on

the HTTP response header names. Specify the name of the WAF policy that will be used to define which response headers will trigg er brute force checking. You must configure this policy file prior to sett ing this parameter, and it must contain a set of regular expressions that will be matched against the response header names. • resp-string name – This option triggers a brute-force check based on

the HTTP response string. Specify the name of the WAF policy that will be used to define which response line messages will trigger brute force checking. You must configure this policy file prior to sett ing this parameter, and it must contain a set of regular expressions that will be matched against the response line messages. This default is disabled. • test-period – This option sets the number of seconds between clearing

of the brute-force counters. The range is 0-600. Default is 60. [ no] brute-force-check

Enable brute force attack mitigation checks for this template. This option is disabled by default.



Command

Description

[ no] buf-ovf option

Checks for attempts to cause a buffer overflow on the Web server. Can include the following sub-options: • disable – Disables buffer overflow protection. Default is Enabled. • max-cookie-len bytes – Sets the maximum length for cookies allowed

in a request. Default is 4096. • max-cookie-name-len bytes – Sets the maximum length for cookie

names allowed in a request. Default is 64. • max-cookie-value-len bytes – Sets the maximum length for cookie

values allowed in a request. Default is 4096. • max-cookies-len – Sets the maximum total length for cookies in a

request. The default value is 4096. • max-data-parse – Sets the maximum data parsed for internal HTTP data

tests (XML, WAF, Forms). The request will not be rejected when the limit is reached. The range is 0-262144. The default value is 65536. • max-hdr-name-len bytes – Sets the maximum header name length for

headers allowed in requests. • max-hdr-value-len bytes – Sets the maximum header value length for

headers allowed in requests. • max-hdrs-len bytes – Sets the maximum header length for headers

allowed in requests. • max-line-len bytes – Sets the maximum line length allowed in a

request. You can specify 0-16127. The default is 1024. • max-parameter-name-len – Sets the maximum parameter name length

allowed in an HTTP request. You can specify 0-512. The default is 256. • max-parameter-total-len – Sets the maximum parameter total length

allowed in an HTTP request. You can specify 0-10752. The default is 4096. • max-parameter-value-len – Sets the maximum parameter value length

allowed in an HTTP request. You can specify 0-10240. The default is 4096. • max-post-size bytes – Sets the maximum content length allowed in

HTTP POST requests. The default is 20480. • max-query-len bytes – Sets the maximum query length allowed in a

request. The default is 1024. • max-url-len bytes – Sets the maximum URL length allowed in requests.

The default is 1024. [ no] ccn-mask

Replaces all but the last four digits of credit card numbers with “x” characters. The default is disabled.



Command

Description

[ no] challenge-actions

The action to be taken to determine if a client is automated. Can include the following options: If one or more of the chal l enge- l i mi t triggers occurs within the test period, then the WAF will initiate one or more of the configured chal l enge- act i ons below:

options

• captcha – CLI option is not supported in ACOS 4.1.1. • cookie – Use Set-Cookie to determine if the client allows cookies.

This option enabled cookie-based challenges to verify whether the client will honor the “Set-Cookie requests”. Presence of this cookie will disable brute-force checking. • javascript – This option will insert a block of Javascript into HTML responses that will insert a cookie if the client contains an input device. Presence of this cookie will disable brute-force checking. [ no] cookie-encrypt cookie-name secret-value

Encrypts the specified cookie using the specified secret value. The cookiename can be the name of a specific cookie or a PCRE pattern (see “Writing PCRE Expressions” on page 113). The default is disabled. 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.

[ no] csrf-check

Tags fields of a web form to protect against Cross-site Request Forgery (CSRF). The default is disabled.

[ no] deny-action options resp-string

Specifies the action per formed by the WAF after a client request is denied: } – Sends a 403 Forbid• http-resp-403 {default | resp-string den response to the client. The default string returns a generic “Request Denied!” page to the client. (Default) } – Sends a 200 OK • http-resp-200 {default | resp-string 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 url-string. • reset-conn – Terminates the client connection.

[ no] deny-non-masked-passwords

Prevents “should 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”. (For more information, see “Deny Unmasked Passwords” on page 20.)

[ no] deny-non-ssl-passwords

Denies user passwords that are sent over a non-encr ypted connection. If the connection between the client and the WAF is secured with SSL/TLS, then the user password is allowed, but if the cl ient attempts to submit to a form field where “input type=password”, and if the connection is not encrypted with SSL/ TLS, then the WAF blocks the transmission. The feature is disabled by default, meaning that forms not using the SSL/TLS protocol will not be denied. (For more information, see “Deny Passwords Sent Over an Unencrypted Connection” on page 21.)



Command

Description

[ no]

Denies web server attempts to transmit the form if one of the form fields type is set to “password” and if the “autocomplete=on/off” attribute is set to “on”. Enabling this option blocks browser “autocomplete” behavior. Although convenient for users, password auto-completion weakens security by allowing browsers to store user passwords in order to later guess the user’s password for some websites.

deny-password-autocomplete

(For more information, see “Deny Passwords if Autocomplete is Enabled” on page 21.) [ no] deploy-mode option

Sets the operational mode for the WAF template. • active – Standard operational mode. You must use Active Mode if you

want the WAF to sanitize or drop traffic based on t he configured WAF policies. (Default) • learning – Provides a way to initially set the thresholds for certain WAF

checks based on known, valid traffic. • passive – Provides passive WAF operation. All enabled WAF checks are

applied, but no WAF action is performed upon matching traffic. This mode is useful in staging environments to identify false positives for filtering. (For more information, see “WAF Operational Modes” on page 49.) [ no] filter-resp-hdrs

Removes the Web server’s identifying headers in responses. The default is disabled.

[ no]

Verifies that user input to form fields is consistent with the intended format. The default is disabled.

form-consistency-check

[ no] form-deny-non-post

Denies HTTP requests containing forms if the method used is anything other than POST. The feature is disabled by default, meaning that forms not using POST will not be denied.

[ no] form-deny-non-ssl

Denies HTTP requests containing forms if the transmission protocol used is anything other than SSL ( TLS). This option is disabled by default, meaning that forms not using the SSL/TLS protocol will not be denied.

[ no] form-set-no-cache

This option adds “no-cache directives” if the HTTP response contains tags. The feature is disabled by default, and the “no-cache” behavior is enforced by adding the following headers: • Cache-Control: no-cache, no-store, must-revalidate • Pragma: no-cache • Expires: 0

[ no] hide-resp-codes

Cloaks 4 xx and 5 xx response codes for outbound responses from the Web server. The default is disabled.

[ no] http-check

Verifies that user requests are compliant with HT TP protocols. The default is disabled.

[no] json-format-check

Examines the format of incoming JSON requests, checks for compliance with RFC 4627, and blocks requests if the JSON content is not well-formed.



Command

Description

[ no] json-limit

Enforces parsing limits in order to protect backend servers against various types of denial-of-service (DoS) attacks, which are designed to exhaust system memory or CPU resources. Various limits can be set, including: • max-array-value-count num – Limits the maximum number of values

within a single array from 0–4096. Default is 256. • max-depth number – Limits the maximum depth in a JSON value to a

maximum recursion depth ranging from 0–4096. Default is 16. – Limits the number of members • max-object-member-count number allowed in a JSON object. Range is 0–4096. Default is 64. – Limits the length of a string (in bytes) in a JSON • max-string number request for a name or a value. Range is 0–4096. Default is 64. [ no] log-succ-reqs

Enabling this option creates a log debug message on the successful completion of WAF requests, and not just for errors.

[ no] max-cookies num

Specifies the maximum number of cookies allowed in a request. You can specify 0-63. The default value is 20.

[ no] max-entities num

Specifies the maximum number of MIME entities allowed in a request. You can specify 0–512. The default value is 10.

[ no] max-hdrs num

Specifies the maximum number of headers allowed in a request. You can specify 0–255. The default value is 20.

[ no] max-parameters num

Specifies the maximum number of parameters allowed in a request. You can specify 0–1024. The default value is 64.

[ no] pcre-mask options

Masks patterns in a response that match the specified PCRE pattern.

pcre-pattern

• 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. – Selects a character to mask the matched pattern of a • mask character string. The default is x . [ no] redirect-wlist

Enables protection against unvalidated redirects, which can occur if a hacker uses social networking to trick unsuspecting users into clicking on a malicious hyperlink. When enabled, the WAF pre-learns a white -list of acceptable locations to which users can safely be redirected. If one of the web servers gets hacked and attempts to redirect a user to a location that does not appear in the redirect white-list, then the WAF blocks the redirect. 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. See “Open Redirect Mitigation” on page 22 for details.



Command

Description

[ no] referer-check option

Validates that the referer header in a request contains Web form data from the specified Web server, rather than from an outside Web site. This check protects against CSRF attacks. The feature is disabled by default. • enable safe-referer-domain safe-url – Always validates the referer

header. If selected, the request fails the check if there i s no referer header or if the referer header is invalid. • only-if-present safe-referer-domain safe-url – 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 referer header in the request. [ no] session-check [ secs]

Enable cookie-based session tracking for WAF sessions. With this option enabled, the WAF uses a cookie to track user sessions. When a request is received from a client for the first time, ACOS creates a unique ID for the session, stores it in a table, and inserts the ID into a cookie that is returned to the client. Subsequent requests from this client are validated against the session ID. If the session ID does not match the saved ID, or if the ID is coming from a different IP address than that of the original client, then the request is rejected. The session cookie is named “awaf-sid”, and it is inserted into the header of the response sent by the server. The header appears in the following format: Set-Cookie: awaf-sid=; path=/' max-age=

The feature is disabled by default. When enabled, the default lifetime for the session ID is 600 seconds, but you can enter a range from 1 - 86400 seconds (24 hours). [ no] soap-format-check

Check the XML document for SOAP format compliance. For more information, see “SOAP Format Checks” on page 33.

[ no] sqlia-check option

The feature is disabled by default, but when enabled, it checks for SQL strings to protect against SQL injection attacks. • reject – Denies the request. • sanitize – Removes suspected SQL injection scripts from requests.

[ no] ssn-mask

Scans content for strings that resemble US Social Security numbers and replaces all but the last four characters of the string with “x” characters. The feature is disabled by default.

[ no] template logging

Applies a configured logging template to t he WAF template. The default is not set.

template-name

[ no] uri-blist-check file-name

[ no] uri-wlist-check file-name

Enforces the rules contained within a WAF policy file for the URI Black List. The default is “uri_blist_defs” policy file. For more information see, “URI Black List” on page 109. Enforces the rules contained within a WAF policy file for the URI White List. The default is “uri_wlist_defs” policy file. For more information, see “URI White List” on page 110.



Command

Description

[ no] url-check

Enables the URL Check. This check allows users to access Web pages by clicking hyperlinks within the Web site only and does not allow users to access the URLs of a Web site directly. An approved list of URL paths can be initially configured only when the WAF is deployed in Learning Mode. For a deployment example that includes configuration of the URL Check, see “Generate Allowed URL Paths for the URL Check” on page 127. The feature is disabled by default.

[ no] url-options options

Use this command to normalize request URLs. This helps shorten the URLs and prevent buffer overflows from length URLs. • decode-entities – Decode entities, such as <, in an internal URL. • decode-escaped-chars – Decode escaped chars, such as \r or \n, in an

internal URL. • decode-hex-chars – Decode hexadecimal characters, such as \%xx and

\%u00yy, in an internal URL. • remove-comments – Remove comments from an internal URL. • remove-selfref – Remove self-references, such as /./ and /path/../, from

an internal URL. • remove-spaces – Remove spaces from an internal URL.

[ no] xml-format-check

Checks the HTTP body for XML format compliance. For more information, see “XML Format Checks” on page 27.

[ no] xml-limit

Checks for XML parsing limits. For more information, see “XML Limit Checks” on page 29.

[ no] xml-sqlia-check

Check XML data against the selected SQLIA policy. For more information, see “XML SQL Injection Checks” on page 32.

[ no] xml-validation

Checks for XML content validation. For more information, see “XML Validation Checks” on page 27.

[ no] xml-xss-check

Check XML data against the specified XSS policy. For more information, see “XML Cross-Site Scripting Checks” on page 31.

[ no] xss-check option

The feature is disabled by default, but when enabled, it checks for potential HTML XSS scripts to protect against cross-site scripting attacks. • reject – Rejects requests with XSS patterns. • sanitize – Removes suspected cross-site scripts from requests.



show waf stats Description

Show WAF statistics for a specific virtual por t on a specific vir tual server.

Syntax

show waf stats virtual-server-name portnum

Command

Description

virtual-server-name

Name of the virtual ser ver.

portnum

Default

N/A

Mode

All

Virtual port number. number.



Example

The following example shows WAF WAF statistics: ACOS#s how ho w waf

Tot al Tot

- - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - Request equest s

5666 5666

Reque equest st s al l owed

2956 295630 30

Request equest s deni deni ed

3995 3995

Responses deni deni ed

0

Sess Sess i on Check heck - Success

0

- Fai l ed

1

- None

73

Bad Bot Bot Check - Success

0

- Fai l ed

0

Buf f er Overf Overf l ow Check heck - URL t oo l ong ong

57

- Request l i ne t oo l ong ong

18

- Query t oo l ong ong

0

- Cooki oki e t oo l ong ong

0

- Tot Tot al Cooki ooki es t oo l ong ong

0

- Cooki e Name t oo l ong

0

- Cooki ooki e Val ue t oo l ong ong

0

- Heade eaderr s t oo l ong ong

117

- Header eader Name t oo l ong

3

- Heade eaderr Val ue t oo l ong ong

2460 460

- POST body body t oo l ong ong

256 256

- Par amet er name t oo l ong ong

0

- Par Par amet er val val ue t oo l ong ong

0

- Par Par ameter t otal t oo l ong

0

- Too much dat dat a t o par par se

53

- Too many par amet er s

0

- Too many cooki es

18

- Too many header s

1

- Too many any MI ME ent i t i es

18

Al l owed HTTP Met hods Check Check - Succes Succes s

2996 299662 62

- Fai Fai l ed

13

HTTP TTP Pr ot ocol ocol Check heck - Success Success

53

- Fai Fai l ed

44

Ref er er Check heck - Success Success


51

A10 Thunder Series and AX Series WAF Template Commands - Fai Fai l ed

17

- No Ref er er ( Redi r ect ect )

51

URI Whi t el i st Check eck - Success ( Mat ch) ch)

36

- Fai Fai l ed

18

URI Bl ackl ckl i st Check - Success Success

35

- Fai Fai l ed ( Mat ch) ch)

36

URL Check - Lear Lear ned ned

0

- Success Success

54

- Fai Fai l ed

126

For For m Consi onsi st ency ency Che Check ck - Success

0

- Fai l ed

0

For m CSRF SRF Tag Check Check - Success

0

- Fai l ed

0

CCN Mas k - Amex

0

- Di ner s

0

- Vi s a

0

- Mast er Car d

0

- Di scove scoverr

0

- J CB

0

SSN Mas k - US SSN' s masked as ked

0

PCRE Mas k - PCR PCRE' s masked

0

Cooki ooki e Encr Encr ypt ypt i on - Encr Encr ypt ypt Success

0

- Encrypt crypt Fai Fai l ed

0

- Encr Encr ypt ypt Li mi t Excee Exceed ded

0

- Encr Encr ypt ypt Ski pped

0

- Decr ypt ypt Success Success

0

- Decrypt crypt Fai Fai l ed

0

SQLI A Check - URL Success Success

54

- URL Sani ani t i zed

72

- URL Rej ect ed

36

- POST Success Success

0

- POST Sani ani t i zed

0

- POST Rej ect ed

0

- XML Success

72


A10 Thunder Series and AX Series WAF Template Commands - XML Fai l ed

36

XSS Check - Cooki e Success

0

- Cooki e Sani t i zed

0

- Cooki e Rej ect ed

0

- URL Success

18

- URL Sani t i zed

0

- URL Rej ect ed

18

- POST Success

36

- POST Sani t i zed

18

- POST Rej ect ed

18

- XML Success

36

- XML Fai l ed

36

J SON For mat Check - Par se Success

882

- Par se Fai l ur e

630

- t oo many ar r ay val ues

0

- nest ed t oo deep

0

- t oo many obj ect member s

0

- st r i ng t oo l ong

18

XML For mat Check - Par se Success

306

- Par se Fai l ur e

252

- t oo many at t r i but es

0

- att r i but e name t oo l ong

0

- at t r i but e val ue t oo l ong

0

- CDATA f i el d t oo l ong

18

- t oo many el ement s

0

- t oo many chi l dr en

18

- el ement s nest ed t oo deep

0

- el ement name t oo l ong

0

- t oo many ent i t y expansi ons

0

- ent i t y expansi ons nest ed t oo deep

36

- t oo many namespaces

0

- namespace URI t oo l ong

0

- XML Schema success

18

- XML Schema f ai l ure

0

SOAP For mat Check - Par se Success

0

- Par se Fai l ur e

0

- WSDL Succes s

0

- WSDL Fai l ure

0

Passwor d Secur i t y Check - Non masked passwor ds Rej ect ed


0

A10 Thunder Series and AX Series WAF Template Commands - Non ss l pass wor ds Rej ect ed - Pass wor d aut ocompl et e Rej ect ed

0 0

Redi r ect Whi t el i st Check - Lear ned

0

- Success

0

- Fai l ed Br ute- f orce Check

0

- Success

0

- Fai l ed

0

For m non- SSL Rej ect ed

0

For m non- POST Rej ect ed

0

For m no- cache header i nser t ed

0

Resp code hi dden

0

Resp hdr s f i l t er ed Cooki e chal l enges

0 0

J avaScr i pt chal l enges

0

Capt cha chal l enges

0

Learni ng updat es

0

The number at the top of the output (vip1 80 in this example) indicates the name of the vir tual server and port number. Table 10 describes the rest of fields in the command output. TABLE 10 show waf stats fields

Field

Description

Requests Requests allowed Requests denied Responses denied Session Check

Total number of HTTP requests. Total number of HTTP requests allowed. Total number of HTTP requests denied due to security violations. Total number or HTTP responses denied. Session check injects a cookie into the HTTP session and makes sure that subsequent requests on this session have this cookie. • Success – Total number of requests that had a session ID inser ted into the cookie and

passed the subsequent validation checks for that same ID. • Failed – Total number of requests that had a session ID inserted into the cookie, failed

a subsequent check for that same ID, and were denied. • None – Number of requests that did not contain a session ID.

Bad Bot Check

Counters for bot checking: • Success – Total number of requests that included a bot. • Failed – Total number of requests that were screened for bots and did not match.



TABLE 10 show waf stats fields (Continued)

Field

Description

Buffer Overflow Check

Counters for buffer overflow checks: • URL too long – Total number of requests that included URL headers whi ch exceeded

the configured limit. • Request line too long - Total number of request lines that exceeded the configured

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 configured

limit. • Cookie Value too long - Total number of cookie values that exceeded the configured

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 configured

limit. • Header Value too long - Total number of header values that exceeded the configured

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

figured limit. • Parameter value too long - Total number of parameter values that exceeded the con-

figured 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

Allowed HTTP Methods Check

contained too many MIME entities. Counters for allowed HTTP methods: • Success – Total number of requests that contained only a method that is present in

the Allowed HTTP Methods list. • Failed – Total number of requests that contained a method that is not in the Allowed

HTTP Methods list.




Field

Description

HTTP Protocol Check

Counters for responses that adhere to HTTP protocol: • Success – Number of requests that followed valid HT TP protocol. • Failed – Number of requests that did not adhere to HTTP protocol.

Referer Check

Counters for referer header validation for incoming requests: • Success – Number of requests that passed t he referer header check. • Failed – Number of requests that did not pass t he 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

URI Black List Check

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

URL Check

were denied. 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 Consistency Check

Counters for Web form consistency: • 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 CSRF Tag Check

form and were denied. Counters for the CSRF check on Web form field tags in outbound responses: • Success – Number of requests that passed the check. • Failed – Number of requests which did not match the nonce for the Web form and

CCN Mask

denied. Counters for credit card numbers masked in requests. This counter is separated into the following credit card types: • Amex • Diners • Visa • MasterCard • Discover • JCB




Field

Description

SSN Mask

Counters for US social security number checks: • US SSNs masked – Total number of SSN numbers that the WAF discovered and

PCRE Mask

masked. Counters for custom PCRE pattern checks: • PCREs masked – Total number of custom PCRE string matches the WAF discovered

Cookie Encryption

and masked. Counters for cookie encryption: • Encrypt Success – Number of times a cookie was successfully encrypted with the

specified secret string. • Encrypt Failed – Number of times encr yption of a cookie failed. • Encrypt Limit Exceeded – Number of times cookies were not encrypted because of

the a configured limit. • Encrypt Skipped – Number of cookies that skipped encryption because the remove-

cookies option is enforced in the RAM caching template. • Decrypt Success – Number of cookies in clients’ requests that were successfully

decrypted with the configured secret string. • Decrypt Failed – Number of client requests that were rejected because they could not

SQLIA Check

be decrypted. Counters for the SQL Inject Attack (SQLIA) check: • URL Success – Number of requests that pass ed the SQLIA check for the URL. • URL Sanitized – Total number of requests that the URL component was sanitized of an

SQL attack pattern and accepted. • URL Failed – Number of requests that contained an SQLIA in t he URL. • POST Success – Number of requests that passed the SQLIA check for the POST body. • POST Sanitized – Total number of requests that the POST body component was sani-

tized of an SQL attack pattern and accepted. • POST Rejected – Total number of requests that were denied because they contained

an SQL injection attack in the POST body of a request. • XML Success – Number of requests that passed the SQLIA check for XML. • XML Failed – Number of requests that contained an SQLIA i n the XML.




Field

Description

XSS Check

Counters for cross-site scripting (XSS) attacks: • Cookie Success – Number of requests that passed the cookie inspection portion of

the XSS check. • Cookie Sanitized – Number of requests that contained an XSS attack in the cookie,

were sanitized, and accepted. • Cookie Rejected – Number of requests that contained an XSS attack in the cookie and

were denied. • 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 portion 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 inspecti on portion of the XSS

check. • XML Rejected – Number of requests that contained an XSS attack in the XML and

JSON Format Check

were denied. Stats for performing JSON format parsing and validation and making sure the JSON object is well constructed. • Parse Success - Number of valid JSON objects. • Parse Failure - Number of invalid JSON objects. • too many array values - Number of JSON objects with too many array values. • nested too deep - Number of JSON objects with invalid nesting. • too many object members - Number of JSON objects with too many members. • string too long - Number of JSON objects with invalid string lengths.




Field

Description

XML Format Check

Stats for performing XML format parsing and validation and making sure the XML object is well constructed. • Parse Success - Number of valid XML objects. • Parse Failure - Number of XML objects that could not be parsed due to some error. • too many attributes - Number of XML object s 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 wi th too many namespaces. • namespace URI too long - Number of XML objects with improper URI lengths. • XML Schema success - Number of XML schemas parsed successfully. • XML Schema failure - Number of XML schemas that could not be parsed.

SOAP Format Check

Validates that SOAP messages are properly constructed and also checks the provided WSDL file to make sure that the fields are aligned with the expected template. • Parse Success - Number of valid SOAP messages. • Parse Failure - Number of SOAP messages that could not be processed due to error. • WSDL Success - Number of times a SOAP message is validated against the WSDL file. • WSDL Failure - Number of times a SOAP message fails validation against the WSDL

Password Security Check

file. Counters for the Password Security check: • Non masked passwords Rejected – when a form has an input field for a password

which is not masked (so when you type your password the characters are not replaced by asterisks) • Non ssl passwords Rejected – When a form containing a password field is POSTed

over a non-SSL connection • Password autocomplete Rejected – When the password field of a form has autocom-

plete turned on, which means that an unauthorized person with access to the browser will not need to actually type in the password




Field

Description

Redirect Whitelist Check

Counters for the Redirect Whitelist 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

Form non-SSL Rejected Form non-POST Rejected Form no-cache header inserted Response Code Hidden Response headers filtered Learning updates

and were blocked. Total number of forms that were rejected due to having been submitted over a non-SSL connection. Number of times a form is sent using an HTTP method other than POST. Number of times WAF inserted a pragma to tell t he client not to cache the content. Number of times WAF masked out an HTTP response code and replaced it with a generic 200/403. Total number of response headers that WAF sanitized and forwarded. Number of additional rules generated from the WAF learning mechanisms when the WAF is operating in Learning Mode.

clear waf stats Description

Clear WAF statistics for a specific virtual port on a specific virtual server.

Syntax

clear waf stats virtual-server-name portnum

Command

Description

virtual-server-name

Name of the virtual ser ver.

portnum

Virtual port number.

Default

N/A

Mode

Privileged EXEC and all configuration levels


A10 Thunder Series and AX Series WAF File Management Commands

WAF File Management Commands The commands in this section manage WAF policy files: •

waf policy check

•

waf policy copy

•

waf policy delete

•

waf policy edit

•

waf policy max-filesize

•

waf policy rename

•

waf wsdl check

•

waf wsdl copy

•

waf wsdl delete

•

waf wsdl edit

•

waf wsdl max-filesize

•

waf wsdl rename

•

waf xml-schema check

•

waf xml-schema copy

•

waf xml-schema delete

•

waf xml-schema edit

•

waf xml-schema max-filesize

•

waf xml-schema rename

•

show waf policy

waf policy check Description

Validate a WAF policy file’s syntax.

Syntax

waf policy check file-name

Mode

Parameter

Description

file-name

Name of a configured WAF policy file.




waf policy copy Description

Copy a WAF policy file to a different file name.

Syntax

waf policy copy source-name destination-name

Parameter

Description

source-name

Name of a configured WAF policy file.

destination-name

Name of the new, copied WAF policy file.

Default

N/A

Mode


waf policy delete Description

Delete a WAF policy file.

Syntax

waf policy delete file-name

Replace file-name with the name of the WAF policy file to be deleted. Default

N/A

Mode




waf policy edit Description

Edit or create a WAF policy file from within the CLI.

Syntax

waf policy edit file-name

Replace file-name with the name of the WAF policy file to be modified, or an unused name to create a new file. Default

N/A

Mode


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.

waf policy max-filesize Description

Sets the maximum size of a WAF policy file.

Syntax

waf policy max-filesize

Default

32K

Mode


Usage

Set a maximum file size in KBytes ranging from 16-256K.

waf policy rename Description

Renames a WAF policy file.

Syntax

waf policy rename source-name destination-name

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

Mode




waf wsdl check Description

Validate a WAF WSDL file’s syntax.

Syntax

waf wsdl check file-name

Mode

Parameter

Description

file-name

Name of a configured WSDL file.


waf wsdl copy Description

Copy a WAF WSDL file to a different file name.

Syntax

waf wsdl copy source-name destination-name

Parameter

Description

source-name

Name of a configured WAF WSDL file.

destination-name

Name of the new, copied WAF WSDL file.

Default

N/A

Mode


waf wsdl delete Description

Delete a WAF WSDL file.

Syntax

waf wsdl delete file-name

Replace file-name with the name of the WAF WSDL file to be deleted. Default

N/A

Mode




waf wsdl edit Description

Edit or create a WAF WSDL file from within the CLI.

Syntax

waf wsdl edit file-name

Replace file-name with the name of the WAF WSDL file to be modified, or an unused name to create a new file. Default

N/A

Mode


waf wsdl max-filesize Description

Sets the maximum size of a WAF WSDL file.

Syntax

waf wsdl max-filesize

Default

32K

Mode


Usage


waf wsdl rename Description

Renames a WAF WSDL file.

Syntax

waf wsdl rename source-name destination-name

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

Mode




waf xml-schema check Description

Validate a WAF XML-Schema file’s syntax.

Syntax

waf xml-schema check file-name

Mode

Parameter

Description

file-name

Name of a configured WSDL file.


waf xml-schema copy Description

Copy a WAF XML-Schema file to a different file name.

Syntax

waf xml-schema copy source-name destination-name

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

Mode


waf xml-schema delete Description

Delete a WAF XML-Schema file.

Syntax

waf xml-schema delete file-name

Replace file-name with the name of the WAF XML-Schema file to be deleted. Default

N/A

Mode




waf xml-schema edit Description

Edit or create a WAF XML-Schema file from within the CLI.

Syntax

waf xml-schema edit file-name

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

Mode


waf xml-schema max-filesize Description

Sets the maximum size of a WAF XML-Schema file.

Syntax

waf xml-schema max-filesize

Default

32K

Mode


Usage


waf xml-schema rename Description

Renames a WAF XML-Schema file.

Syntax

waf xml-schema rename source-name destination-name

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

Mode




show waf policy Description

Displays WAF policy files.

Syntax

show waf policy [ def-file-name] [ all-partitions | partition {shared | partition-name}]

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 | partition-name}

Returns a list of WAF policy files for the shared partition or the specified private partition.

Default

N/A

Mode

All

Example

The following command lists all WAF policy files, for all partitions:

ACOS( conf i g- waf ) #show waf policy all-partitions Tot al WAF pol i cy number : 10 Max WAF pol i cy f i l e si ze: 32K Name

Synt ax

Templ at e

Lear ni ng

- - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - al l owed_r esp_codes

Check

Bi nd

No

bot _def s

Check

Bi nd

No

Check

No

No

sql i a_def s

Check

Bi nd

No

ur i _bl i st _def s

Check

Bi nd

No

ur i _wl i st _def s

Check

Bi nd

No

j sc r i pt _def s




A10 Networks WAF Guide

Recommend Documents