AkamaiWAF_UserGuide

Akamai® Kona Security Solutions™Web Application Firewall User Guide

Akamai ConfidentialFor Customer Use Under NDA Only

May 7, 2014

Akamai Technologies, Inc.Akamai Customer Care: 1-877-425-2832 or, for routine requests, e-mail [email protected]

Luna Control Center™, for customers and resellers: http://control.akamai.com

Web Application Firewall User GuideCopyright © 2013–2014 Akamai Technologies, Inc. All Rights Reserved.

Reproduction in whole or in part in any form or medium without express written permission is prohibited. Akamai, the Akamai wave logo, Faster Forward and the names of certain Akamai products referenced herein are trademarks or service marks of Akamai Technolo-gies, Inc. Third party trademarks and service marks contained herein are the property of their respective owners and are not used to imply endorsement of Akamai Technologies, Inc. or its services. While every precaution has been taken in the preparation of this docu-ment, Akamai Technologies, Inc. assumes no responsibility for errors, omissions, or for damages resulting from the use of the informa-tion herein. The information in these documents is believed to be accurate as of the date of this publication but is subject to change without notice. The information in this document is subject to the confidentiality provisions of the Terms & Conditions governing your use of Akamai services and/or other agreements you have with Akamai.

Adobe and ColdFusion are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Apache Struts is a trademark of The Apache Software Foundation.

Microsoft is a registered trademark of Microsoft Corporation in the United States and/or other countries.

MongoDB is a registered trademark of MongoDB, Inc.

Oracle, JavaScript, and WebLogic are registered trademarks of Oracle and/or its affiliates.

Ruby on Rails is a registered trademark of David Heinemeier Hansson. All rights reserved.

Trustwave and ModSecurity are registered trademarks of Trustwave in the United States and/or other countries.

UNIX is a registered trademark of The Open Group

WordPress is a registered trademark of Automattic, Inc.

Zope is a registered trademark of Zope Corpotation

All other product and service names mentioned herein are the trademarks of their respective owners.

US Headquarters8 Cambridge Center

Cambridge, MA 02142

Tel: 617.444.3000Fax: 617.444.3001

US Toll free 877.4AKAMAI (877.425.2624)

For a list of offices around the world, see: http://www.akamai.com/en/html/about/locations.html

http://control.akamai.com

http://www.akamai.com/en/html/about/locations.html

ContentsPREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

About This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1Other Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

CHAPTER 1. INTRODUCING WEB APPLICATION FIREWALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Eligible Akamai Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

CHAPTER 2. PROVISIONING WEB APPLICATION FIREWALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Accessing Luna Control Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Creating WAF Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Accessing WAF Configuration Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Using the Quick Configuration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Creating Configurations Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

Step 1—Creating a Firewall Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18Step 2—Creating Web Application Firewall Rate Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Step 3—Creating a Rate Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46Step 4—Enabling Rate Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49Step 5—Creating Match Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50Step 6—Activating the WAF Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53

Deactivating Web Application Firewall Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55Using Custom Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55

Enabling Custom Rules in a Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55Modifying WAF Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

Editing a WAF Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57Editing Rate Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58Editing Firewall Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59Editing and Deleting Match Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75

Upgrading the Rule Set from CRS, Version 1.6.1 to KRS, Version 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . .78Creating a New WAF Configuration Version from an Existing One . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86Deleting a WAF Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

Modifying Rate Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88Editing Rate Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88Creating New Rate Categories from Existing Rate Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94

Creating and Modifying Network Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95Creating Network Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95Activating Network Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99Modifying Network Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100

Resolving Network List Modification Conflicts (Merging Lists). . . . . . . . . . . . . . . . . . . . . . . . . . . . .102Required Postprovisioning Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103

Enabling WAF in Your Delivery Product (Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103Enabling WAF in Property Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105Enabling WAF with the Log Delivery Service (LDS) (Optional Step) . . . . . . . . . . . . . . . . . . . . . . . .108

CHAPTER 3. USING RULE CONDITIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109Accessing Rule Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109

Web Application Firewall User Guide. Akamai Confidential. i

Setting Up Rule Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

APPENDIX A. MODSECURITY CORE RULE SET GROUP DEFINITIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

APPENDIX B. NETWORK LAYER IP CONTROLS BEHAVIORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

APPENDIX C. REAL-TIME REPORTING POST SCHEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Lines and Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Fields Added by WAF to W3C and Combined LDS Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

APPENDIX D. RULE PROFILES COMPARISON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Risk Scoring Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Individual Rule Actions per Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

ii Web Application Firewall User Guide. Akamai Confidential.

PrefaceWelcome to the Web Application Firewall User Guide. This document provides an overview of Akamai’s Web Application Firewall (WAF), as well as details regarding its setup and use with web properties.

About This Document

This document is organized into chapters as follows:

Chapter 1. Introducing Web Application Firewall provides an overview of WAF.

Chapter 2. Provisioning Web Application Firewall gives procedures for using Aka-mai® Luna Control Center™ to set up WAF.

Chapter 3. Using Rule Conditions presents tips, guidance, and suggestions regarding WAF.

Additionally, several appendices are available at the end of this user guide to facilitate your use of the WAF product.

Other Resources

Additional information regarding the following Akamai products can be accessed through Luna Control Center (https://control.akamai.com).

Web Application Firewall-Related Documentation

Security Monitor Getting Started Guide (Support >> User and Developer

Guides >> Kona Security Solutions)

Kona Rules Descriptions (Support >> User and Developer Guides >> Kona Security Solutions)

Akamai Log Delivery Service

Akamai Log Delivery User Guide (Support >> User and Developer Guides >> Log Delivery)

Web Application Firewall User Guide. Akamai Confidential. 1

Preface

2 Web Application Firewall User Guide. Akamai Confidential.

Chapter 1. Introducing Web Application Firewall

Akamai’s Web Application Firewall (WAF) is a highly-scalable edge defense service built on Akamai’s proprietary EdgePlatform and is designed to detect and mitigate application threats within HTTP and HTTPS traffic as they attempt to pass through the EdgePlatform to reach origin data centers. WAF is also designed to scale instantly, preserving performance, filtering attack traffic close to the source, and absorbing the boundless requests from the last mile, protecting infrastructure and keeping web applications up and running. WAF’s application rule logic is based on the open source Trustwave® ModSecurity® Core Rule Set, as well as the Akamai-created Akamai Kona Rule Set, and this application layer protection is further augmented with func-tions such as rate control and network layer control, all of which are being constantly refined to offer the maximum protection available.

WAF is made up several components that offer different types of protection:

• Application Layer Controls—A collection of predefined Web Application Fire-wall rules for different types of attack categories. These rules enable inspection of Application traffic to identify and protect against attacks and vulnerability exploits.

- ModSecurity Core Rule Set 1.6.1—These rules are the unmodified ModSe-curity Core Rule Set (CRS), version 1.6.1 rules, authored by Trustwave.


Introducing Web Application Firewall

- Akamai Kona Rule Set 1.0—These rules are a mixture of rules that are solely of Akamai’s design, as well as rules based on the ModSecurity Core Rule Set, version 2.2.6 that Akamai has modified.

- Custom Rules—Allow you (via your account representative) to create pol-icy-based rules that are enforced after the execution of the Application Layer Controls and that serve as “virtual patches” for new web site vulnerabilities.

- Rule Conditions—Allow you to limit (filter) when a specific rule fires.

• Network Layer Controls—Provide enforcement of customer-defined IP block and allow lists. List updates are propagated across Akamai’s global network within minutes, enabling rapid response to attacks. Other features include restricting requests from specific IP addresses to protect your origin from applica-tion layer attacks and implementing geographic blocking. Up to 50000 CIDR entries are supported, including Network Lists.

• Rate Controls—Monitor and control the rate of requests against Akamai’s Edge servers and your origin to provide dynamic protection against application layer attacks. Rate categories can be incorporated as WAF rules allowing you to dynamically alert and/or block clients exhibiting excessive request rate behaviors. Statistics are collected for three request phases: client request, forward request, and forward response.

Eligible Akamai Products

The following Akamai products are eligible to use WAF:

• DSA (Dynamic Site Accelerator)

• DSA-Secure

• DSA-Enterprise

• DSD (Dynamic Site Delivery)

• EdgeSuite

• Kona Site Defender™ solution

• RMA (Rich Media Accelerator)

• Terra Alta™ solution

• WAA (Web Application Accelerator)

- Excluding WAX


Chapter 2. Provisioning Web Application Firewall

In This Chapter

Web Application Firewall setup begins with the initial activation of your account by Akamai. When completed, you can access it via Akamai Luna Control Center, using Luna to set all necessary parameters for your Web Application Firewall (WAF) to ade-quately protect your web applications.

Accessing Luna Control Center

The following procedures will enable you to access your Akamai account on Luna Control Center.

1. Log in to Luna Control Center.

a. Start your web browser and open https://control.akamai.com.

The Luna Control Center login page appears.

Figure 2-1. The Akamai Luna Control Center Login Page

Accessing Luna Control Center • 5

Creating WAF Configurations • 6

Deactivating Web Application Firewall Configurations • 55

Using Custom Rules • 55

Modifying WAF Configurations • 57

Modifying Rate Categories • 88

Creating and Modifying Network Lists • 95

Required Postprovisioning Tasks • 103


Provisioning Web Application Firewall

b. Enter your user ID and password, and click .

The MY AKAMAI page appears.

2. Access the desired context (account group).

a. Click .

b. From the resulting dropdown menu, select either the group with which you would like to work, or enter a search term in the text box and select a group from the list of results.

You can now proceed with the WAF provisioning process.

Creating WAF Configurations

Once logged in to Luna Control Center, you may begin setting up your Web Appli-cation Firewall to protect your digital properties. Luna Control Center offers two options for setting up your WAF configurations:

• Quick Configuration—-This is the simplest way to get started. You will be pre-sented with a few options and questions about your web site, and the wizard will set up a WAF configuration for you.

• Manual Configuration (Advanced)—Choose this if you want to manually create your own WAF configuration, including Rate Policies, Firewall Policies, and Match Targets.

Accessing WAF Configuration Creation

You will access Quick Configuration and Manual Configuration differently, depend-ing on whether you are a new or existing WAF customer.

New WAF Customers

1. Log in to Luna Control Center and select the appropriate context, if you have not done so already.

2. Navigate to the Welcome to Akamai Web Application Firewall (WAF) page.

a. In the upper navigation bar, click the CONFIGURE tab.

The Configure pop-up menu appears.

b. Under the Security heading, select WAF Configuration.



The Welcome to Akamai Web Application Firewall (WAF) page appears (if the Select Product page appears first, select the product for which you want

to enable WAF and click ).

Figure 2-2. The Welcome to Akamai Web Application Firewall (WAF) Page

3. Navigate to the Getting Started page.

a. Click .

The Getting Started page appears.

Figure 2-3. The Getting Started Page

b. Click or , depending on which method you would like to use to create your WAF configuration.

• Quick Configuration. Refer to “Using the Quick Configuration Tool” on page 11

• Manual Configuration (Advanced). Refer to “Creating Configurations Manually” on page 18



Click Rate Category Management if you would like to proceed to Rate Cat-egory creation (see “Step 2—Creating Web Application Firewall Rate Cate-gories” on page 40).

Existing WAF Customers

As an existing WAF customer, you will likely have WAF configurations in place already, though you may or may not have actually set up their parameters. The fol-lowing procedures will walk you through

the process of accessing WAF configuration whether you do or do not have your con-figuration parameters set up.


2. Navigate to the Web Application Firewall page.




The Web Application Firewall page appears (if the Select Product page appears first, select the product for which you want to enable WAF and click

).

Figure 2-4. The Web Application Firewall Page

3. Navigate to the Web Application Firewall Configuration page.

a. Click the version number belonging to an unconfigured version, or select

Edit from its Actions dropdown menu ( ).



• If you have not already set up the configuration version’s parameters, the Getting Started page appears.

Figure 2-5. The Getting Started Page

1. Click or , depending on which method you would like to use to create your WAF configura-tion.

• Manual Configuration (Advanced). Refer to “Creating Config-urations Manually” on page 18

• Quick Configuration. Refer to “Using the Quick Configura-tion Tool” on page 11



• If you have already setup at least the configuration’s parameters, the Web Application Firewall Configuration page appears.

Figure 2-6. The Web Application Firewall Configuration Page

1. Either begin manually setting up your configuration components or

click to access the Quick Configuration tool.

• For Manual Configuration (Advanced) procedures, refer to “Creating Configurations Manually” on page 18.

• For Quick Configuration procedures, refer to “Using the Quick Configuration Tool” on page 11.



Using the Quick Configuration Tool

On clicking , the Quick Configuration page appears, displaying the Resource to Protect tab.

Figure 2-7. The Quick Configuration Page with the Resource to Protect Tab Displayed

1. Complete the Resource to Protect tab.

The information on this tab is used to create a Match Target to which your Fire-wall Policy will be applied.

Note: All characters are allowed in the following fields except less than (<), greater than (>), and the character combination ${.

Note: Requests must match all three text box values (Hostname, Path, and File Exten-sions) for the firewall to be applied.

a. If desired, in the Policy Name (optional) text box, enter a name for the new configuration.



If you leave this blank, Akamai will automatically create a Policy Name for you.

b. In the Hostname text box, enter the hostname or hostnames to which you would like to apply the Firewall Policy (e.g., *.example.com or www.exam-ple.com).

These are the hostnames for which Akamai serves content (e.g., www.exam-ple.com, test-www.example.com, www.example.com.edgesuite.net, etc.) and have an associated Edge hostname and Edge configuration file defining their content-handling specifications to the Akamai Network. If you leave this field blank, the Match Target will default to all digital properties in all Edge server configuration files for which the firewall is enabled. Multiple entries must be space-delimited.

c. In the Path text box, enter any specific paths on which you would like to apply the Firewall Policy (e.g., /default.asp, a%2Cb.htm, /images/*, etc.), and select whether you would like it to be a negative or positive match by selecting or deselecting, respectively, the Negative Match check box.

Leaving the Negative Match check box deselected means the match will apply to requests for the Path text box entries. Selecting the check box means the match will apply to all paths except those in the text box. Multiple entries must be space-delimited. If you wish to apply it to all the hostname’s con-tents, leave the default /* entry.

d. In the File Extensions text box, enter any specific file extensions on which you would like to apply the Firewall Policy (e.g., html, asp, jsp, etc.), and select whether you would like it to be a negative or positive match by select-ing or deselecting, respectively, the Negative Match check box.

Leaving the Negative Match check box deselected means the match will apply to requests for the File Extensions text box entries. Selecting the check box means the match will apply to all file extensions except those in the text box. Multiple entries should be space-delimited.

e. Click .



The Rule Profile tab appears.

Figure 2-8. The Quick Configuration Page with the Rule Profile Tab Displayed

2. Complete the Rule Profile tab.

Your selections on this tab are used to select appropriate Application Layer Con-trols rules from the Kona Rule Set (KRS) to include in your Firewall Policy.

a. From the dropdown menu, select a profile to use.

• Standard Protection. This profile protects against common, high-profile web attacks (SQLi, XSS, RFI/LFI, Command Injection, and PHP Injec-tion only). With it, there is an extremely low chance of false positives, and it is suitable for customers who desire hands-free WAF configura-tions.

• Intermediate Protection. This profile also protects against common, high-profile common web attacks (SQLi, XSS, RFI/LFI, Command Injection, PHP Injection, and +DDoS Tools only). It minimizes chances of false positives, but since it is “managed,” you may choose to use cus-



tom rules to provide additional mitigation assistance. This profile is suit-able for customers for whom a good level of security is desired and a slight chance of false positives is acceptable.

• Strict Protection. This is a custom profile that requires constant rule management. In addition to the attack types mentioned in the previous profiles, it may include some HTTP protocol violations, Session Fixa-tion, and others. This profile includes a high probability of false posi-tives, and you must take care when using it in production environments.

b. Click Advanced Profile Options.

A list of advanced profile options appears, the contents of which are based on the profile your chose.

c. In the Rule Actions area, select the desired radio button:

• Perform Akamai recommended actions. Violated rules either generate an alert or deny the request altogether, depending on the Akamai’s best-determined practices.

• Log alerts only. Violated rules are logged only.

d. In the remaining areas, if available, select all check boxes that apply to your web site.

e. Click .



The Rate Limits tab appears.

Figure 2-9. The Quick Configuration Page with the Rate Limits Tab Displayed

3. Complete the Rate Limits tab.

This tab is used to add up to ten Rate Policies/Rate Categories that will be included in your Firewall Policy to limit traffic. Currently, the Quick Configura-tion tool has two preconfigured policies available to choose from that appear in the dropdown menu under the heading Akamai preset rate policies. If desired, you can choose these for two of your Rate Policies and configure others manually after you finish the configuration (see “Step 2—Creating Web Application Fire-wall Rate Categories” on page 40).

a. If desired, from the dropdown menu, select the type of Rate Policy you would like use:

• Monitor Page View Request Rate. This policy monitors for excessive page view requests. It uses the following parameters:



- Rate Category (see “Step 2—Creating Web Application Firewall Rate Categories” on page 40 for more information)

• Rate Category Type: Client Request

• Client Identifier: Client IP

• HTTP Method: Match GET, POST, and HEAD

• File Extensions: Do not match js, css, jpg, jpeg, png, gif, bmp, eot, woff, ico, swf, f4v, flv, mp3, mp4, pdf

- Rate Policy (see “Step 3—Creating a Rate Policy” on page 46 for more information)

• Average Threshold (per 2-minute window): 5

• Burst Threshold (per 5-second window): 10

• Monitor Origin Error Rate. This rule monitors for excessive errors on your origin. It uses the following parameters:

- Rate Category (see “Step 2—Creating Web Application Firewall Rate Categories” on page 40 for more information)

• Rate Category Type: Forward Response

• Client Identifier: Client IP

• HTTP Method: Match GET, POST, and HEAD

• HTTP Response Codes: Match 400, 401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 500, 501, 502, 503, 504

• All request types

- Rate Policy (see “Step 3—Creating a Rate Policy” on page 46 for more information)

• Average Threshold (per 2-minute window): 5

• Burst Threshold (per 5-second window): 10

If you have configured Rate Policies already, they will appear in this page’s dropdown menu under the heading Existing rate policies. You can later edit these Rate Policies and Rate Categories (see “Editing Rate Policies” on page 58 and “Editing Rate Categories” on page 88), as desired.

Be aware, each Rate Policy is set to Alert by default. With this, a triggered Policy generate an alerts, in contrast to a Deny setting, which denies the request altogether.

b. Click .



The Review & Finish tab appears.

Figure 2-10. The Quick Configuration Page with the Review & Finish Tab Displayed

4. Inspect the Review & Finish tab.

a. Review the information in the Review & Finish tab, and click if all is correct.

The Web Application Firewall Configuration page appears, displaying the new Rate Policy, Firewall Policy, and Match Target created by the Quick Configuration.

The names given the various configuration components are:

• Rate Policy. The names reflect those chosen in the Quick Configuration tool.

• Firewall Policy. The Policy Name will be Generated Quick Policy -[cre-ation_date], [creation_time] (GMT).



• Match Target. This is denoted by the digital property you used and also the fact that it is associated with the newly-created Firewall policy.

Creating Configurations Manually

If you desire more control over the WAF configuration creation process, you can opt to set them up manually.

Step 1—Creating a Firewall Policy







).


3. Begin creating a Web Application Firewall configuration.

a. Click the configuration’s version number or select Edit from its Actions

menu ( ).



The Web Application Firewall Configuration page appears.


b. In the Firewall Policies area, click .

The Create New Firewall Policy page appears.

Figure 2-13. The Create New Firewall Policy Page

c. In the Policy Name text box, enter a name for this policy.



This provides you a means to recognize the policy’s type and purpose. You can later change it across all versions of this WAF configuration, though not for individual versions.

d. In the Policy ID text box, enter a unique four-character identifier (e.g., 1234).

Once submitted, this is appended with an underscore ( _ ) and additional Akamai-assigned characters (e.g., 1234_5678). The complete policy ID identifies the Firewall Policy in your WAF reports.

e. From the Analysis and Reporting dropdown menu, select None or Akamai Analysis and Security Monitor.

• Akamai Analysis and Security Monitor. Events triggered by this Firewall Policy can be analyzed using Akamai Security Monitor, available on Luna Control Center (MONITOR >> Security Monitor (under the Security heading)).

f. In the Enabled Controls area, select the control types you would like to enable for the configuration (you must select at least one).

You will be able to configure each selected control on subsequent WAF con-figuration pages.

• Application Layer Controls. This allows you to apply preconfigured rule profiles (KRS 1.0 only) and/or to select individual rules, both from a rule set (CRS 1.6.1 or KRS 1.0) and a set of Akamai Common Rules, to apply to incoming requests to Akamai’s Edge servers and/or outbound responses from the Edge server to your end users. You will also choose whether violations of each rule results in an alert or a denial of access for that request.

• Network Layer Controls. This enables you to specify individual IP addresses and/or whole CIDR blocks to block or allow. It also permits you to allow and block requests from specific countries.

• Slow POST Protection. This allows you to combat slow POST attacks by designating a rate threshold (in bytes per second) that triggers either an alert or abort action for requests coming in below that threshold. You can also cause an action to be triggered if the Akamai Edge buffer does not fill within a designated period of time.

• User Validation Controls. This permits you to screen client requests for undesired automated processes such as troublesome Internet bots.

g. Click .

Depending on which control or controls you chose, either the Application Layer Controls page (displaying the WAF Rules Setup dialog box (KRS 1.0



only)), the Network Layer Controls page, the Slow POST Protection page, or the User Validation Controls page appears.

Note: These procedures continue through each control page as if all were selected.

Figure 2-14. The Application Layer Controls Page Displaying the WAF Rules Setup Dialog Box

4. Select a preset WAF Rule Profile (KRS 1.0).

a. From the Select Rules Profile dropdown menu, select the preset profile you would like to use.

• Standard Protection. This profile protects against common, high-profile web attacks (SQLi, XSS, RFI/LFI, Command Injection, and PHP Injec-tion only). With it, there is an extremely low chance of false positives, and it is suitable for customers who desire hands-free WAF configura-tions.

• Intermediate Protection. This profile also protects against common, high-profile common web attacks (SQLi, XSS, RFI/LFI, Command Injection, PHP Injection, and +DDoS Tools only). It minimizes chances of false positives, but since it is “managed,” you may choose to use cus-tom rules to provide additional mitigation assistance. This profile is suit-able for customers for whom a good level of security is desired and a slight chance of false positives is acceptable.

• Strict Protection. This is a custom profile that requires constant rule management. In addition to the attack types mentioned in the previous profiles, it may include some HTTP protocol violations, Session Fixa-tion, and others. This profile includes a high probability of false posi-tives, and you must take care when using it in production environments.

a. Click .



The dialog box closes, and the Application Layer Controls page appears with the Core Rule Set configured for the chosen Rules Profile.

Figure 2-15. The Application Layer Controls Page (Displaying Akamai Kona Rule Set, Version 1.0)

b. If desired, click .

The Advanced Profile Options dialog box appears.

c. In the Rule Actions area, select the desired radio button:

• Perform Akamai recommended actions. Violated rules either generate an alert or deny the request altogether, depending on the Akamai’s best-determined practices.

• Log alerts only. Violated rules are logged only.

d. In the remaining areas, if available, select all check boxes that apply to your

web site and click .

About the Application Layer Controls Page

On this page, you select the Kona Rules or ModSecurity rules, and/or Akamai Com-mon Rules you would like to apply to your Firewall Policy and decide how you would like violations of those rules to be handled. You can also configure the Risk Scoring feature (Kona Rule Set, version 1.0 only), which adds the scores of any rules a request



violates, checks that sum against thresholds you define, and takes the specified action (Alert or Deny) on the request, if a threshold is exceeded.

Multiple views are available by selecting a group view type in the Group by area. Indi-vidual rules can be displayed and hidden by clicking the arrow preceding each dis-played group.

• Flat. Displays all rules.

• Enabled. Displays rules grouped by enabled and disabled states.

• Author. Displays rules grouped by whether they are part of the Kona Rule Set or ModSecurity Core Rule Set, or are Akamai Common Rules.

• Rule Group. Displays rules by their categories (see Appendix A. for a list of Group definitions).

- Outbound

- Akamai Common Rules

- Request Limits

- Trojans

- SQL Injection Attacks

- Protocol Violations

- XSS Attacks

- Generic Attacks

- Protocol Anomalies

- HTTP Policy

- Tight Security

- Bad Robots

Caution: Outbound rules inspect the entire response body, which can affect end-user response time. Please use outbound rules with caution.

• Risk Groups (KRS 1.0 only). Displays rules as grouped into Akamai-determined risk categories. These categories are comprised of combinations of the rule groups and allow WAF to detect specific attack vectors, such as SQL and PHP Injection using different sensitivity thresholds.

- Total Response Score (Outbound): Outbound rules

- Total Request Score (Inbound): All rules, less Outbound and Akamai Com-mon Rules

- Invalid HTTP: HTTP Policy, Protocol Anomalies, Protocol Violations, and Request Limits rules

- Trojan: Trojans rules



- Command Injection: Generic Attacks, SQL Injection Attacks, Tight Secu-rity, and Trojans rules

- SQL Injection: Outbound and SQL Injection Attacks rules

- Cross Site Scripting (XSS): Generic Attacks, Outbound, SQL Injection Attacks, and XSS Attacks rules

- PHP Injection: Generic Attacks rules

- Remote File Inclusion: Generic Attacks rules

On this page, you can:

• Sort the displayed list by clicking a column header, which rearranges the list in alphanumeric order based on that column’s contents (clicking the header a sec-ond time reverses the order).

• Enable or disable all displayed rules by selecting or deselecting, respectively, the check box at the left-hand side of the list’s header bar (a solid check box ( ) indi-cates some, but not all, rules are enabled). This procedure also applies to the check boxes preceding each displayed group.

• View a rule’s risk score, description, and security tags by selecting it, clicking the

Actions dropdown menu button ( ), and selecting More Info.

• Display a rule’s metadata by selecting it, clicking the Actions dropdown menu

button ( ), and selecting View Metadata.

• List rules by keyword in a selected view by typing a term in the Search rules text box, which displays any rules containing that term in their ID, Title, Rule Group, or Risk Groups.

• Choose a different Rules Profile by clicking the Restore menu ( ) and select-ing Restore to Standard Protection, Restore to Intermediate Protection, or Restore to Strict Protection.

The information presented on the page includes:

- AUTHOR. Displays whether a rule is part of the Kona Rule Set or ModSe-curity Core Rule Set ( ), or is an Akamai Common Rule ( ).

- ID. The rule’s identification number. IDs beginning with 9 belong to the Kona Rule Set or ModSecurity Core Rule Set; those beginning with 3 or 6 belong to the Akamai Common Rules.

Note: ID numbers for Akamai Custom Rules also begin with 6 (see “Using Custom Rules” on page 55).

- TITLE. The rule’s descriptive long name.

- RULE GROUP. The name of the ModSecurity Core Rule Set group to which the rule belongs.



- RISK GROUPS (KRS v1.0 only). The name of the Risk Group or Groups to which the rule belongs.

- ACTION. A dropdown menu that permits you to:

• KRS v1.0: select whether the rule will be in Risk Scoring mode or will deny the request if violated, regardless of other rules’ ACTION settings.

• CRS v1.6.1: select to invoke an Alert ( ) or Deny ( ) action upon a request’s violation of the rule.

- SCORE (KRS v1.0 only). This column indicates each rule’s Risk Scoring value.

- CONDITIONS. This column indicates whether special conditions have been applied to the rule by your account representative.

5. If you wish to fine tune your selected Rule Profile, complete the Application Layer Controls page.

a. In the Group By area, select the desired view.

By default, rules are initially displayed by Risk Groups (KRS v1.0) or in Flat view (CRS v1.6.1).

b. If desired, click the arrows preceding any groups of which you would like to view specific rules.

c. Select or deselect the check box of any rules you would like to enable or dis-able, respectively, for your Firewall Policy.

Caution: Outbound rules can impact service performance if incorrectly applied. Only enable those rules relevant to your environment.

d. If you wish to change a rule’s action:

• KRS v1.0. From the rule’s ACTION dropdown menu, select Risk Scor-ing or Deny, as appropriate

• CRS v1.6.1. From the rule’s ACTION dropdown menu, select Alert or Deny, as appropriate.

e. Repeat steps 5.a. through 5.d. for any other rule groups you wish to include in your firewall.

f. (KRS v1.0 only) If you have rules in Risk Scoring mode, click Show Scoring Settings.



The Risk Scoring configuration controls appear, displaying the Risk Groups along with their current action and sensitivity settings.

Figure 2-16. The Risk Scoring Configuration Box.

Risk Scoring allows you to apply an overall action for enabled rules within a Risk Group when the sum of violated rules’ scores exceeds your defined thresholds.

i. For each Risk Group you would like to enable for the Firewall Policy, select Alert or Deny, as desired, from the ACTION dropdown menu.

If you wish to disable the Risk Group in the Firewall Policy, select Not used.

ii. For each enabled Risk Group, if you wish to alter the sensitivity thresh-old from the default, enter a new value in the appropriate SENSITIV-ITY text box.

Be certain to enter thresholds less than the total possible score of all enabled rules within the group.

Note: Each Risk Group’s Sensitivity is set to an Akamai-determined optimal default. Aka-mai recommends you retain these defaults unless you require fine tuning. Be aware, some Akamai Common Rules have individual scores of 1000. This is by design and is intended to trigger an action even if only that single rule is violated.

g. Click .



The Network Layer Controls page appears.

Figure 2-17. The Network Layer Controls Page

6. Complete the Network Layer Controls page.

This page lets you control access to your content by creating allowed and blocked lists of IP addresses and geographic regions.

Note: Network Layer Controls support both IPv4 and IPv6 IP addresses.

a. Select the IP CONTROLS tab.

The Blocked IPs and Allowed IPs windows and controls appear.



You can use each list’s Search text box to search for specific IP addresses within them.

b. In the Network layer control mode area, select the type of IP Controls you would like to use.

• Block with exceptions: Block specific IPs unless they are also allowed. This setting allows you to both block and allow specified IP addresses by entering them in the Blocked IPs and Allowed IPs lists, as appropriate. Be aware, the Allowed IPs list overrides Blocked IPs list entries. That is, if you were to add the CIDR block 192.168.0.0/24 to the Blocked IPs list and then add 192.168.0.68 to the Allowed IPs list, all addresses in the CIDR block will be disallowed except 192.168.0.68. For additional information regarding these two lists’ behaviors, see Appendix B.

Caution: If you add an entry to a list, then subsequently add it to the other, it will remain in the original list until you manually remove it. This is important to remember if you choose to block an IP address you previously added to the Allowed IPs list. Since the allowed list overrides the blocked list, the entry will continue to be allowed until you man-ually remove it from that list.

• Exclusive allow: Block all traffic except from allowed IPs. This setting blocks traffic from all IP addresses unless they are expressly specified in the Allowed IPs list.

Note: WAF configurations permit requests from IP addresses in their ALLOWED IPS lists, but those requests are still subject to and evaluated by all other WAF configuration rules and settings.

c. Add IP addresses using one or both available methods:

• Adding IP addresses or CIDR blocks individually.

1. In the IP text box belonging to the appropriate list (Blocked IPs or Allowed IPs), enter an IP address or an IP range using a CIDR

block (e.g., 192.168.0.0/24) and click .

The entry appears in the appropriate list.

2. Repeat with any remaining IP addresses you wish to add.

You can remove individual entries from these lists by selecting their

check boxes and clicking ; you can remove all entries by

clicking .

• Adding bulk CSV- or text-formatted files of IP addresses/CIDR blocks.

1. In the Bulk IP Upload section, click for the appropriate list.

2. Navigate to and select the file you wish to upload.



3. Click .

The file’s IP addresses appear in the appropriate list window.

If desired, you can create Network Lists of your BLOCKED IPS and/or

ALLOWED IPS by clicking for the desired list. Doing so displays the Create Network List dialog box where you can enter a name in

the List Name text box, then click . This action clears the window’s entries and creates an IP list that appears under the NETWORK LISTS tab (with the appropriate action: Blocked or Allowed) and also on the Network Lists page (see “Creating and Modifying Network Lists” on page 95).

d. Select the GEOGRAPHICAL CONTROLS tab, if desired.

The AVAILABLE COUNTRIES and BLOCKED COUNTRIES windows appear.

You can use the list’s Filter by text box to search for specific geographic loca-tions.

e. In the Available Countries window, select the check box of any country you wish to deny access to your content.

The chosen countries move to the Blocked Countries window. You can move them back to the Available Countries window by deselecting their check boxes.

You can also create a Network List of your Blocked Countries entries by

clicking . Doing so displays the Create Network List dialog box where you can enter a name in the List Name text box, then click

. This action clears the Blocked Countries window’s entries and creates a Geo list that appears under the NETWORK LISTS tab (with an action of Blocked) and also on the Network Lists page (see “Creating and Modifying Network Lists” on page 95).

f. Select the NETWORK LISTS tab, if desired.

The Network Lists interface appears, displaying a scrollable page with all available Network Lists.

You can use the Search lists text box to search for Network List names, or for specific IP addresses or geographic locations within your Network Lists (click



Clear Search to return to the full list view). You can also use the List Type selection area to display IP lists only, Geo lists only, or All list types.

Figure 2-18. The Network Layer Controls Page Displaying the Network Lists Tab

g. Click to add a new Network List.

The Create Network List dialog box appears.

Figure 2-19. The Create Network List Dialog Box

h. In the List name text box, enter a name for the Network List.

Duplicate names are allowed, and Akamai differentiates identically-named lists behind the scenes.

i. In the List Type area, select the IP or Geo radio button to create an IP address list or a geographic location list, respectively.



j. From the Access Control Group dropdown menu, select the Access Control Group (ACG) with which you would like to associate the Network List (available only if you have multiple ACGs).

k. Click .

The new list appears in the table, which includes the following information:

• LIST NAME—The name you gave to the list.

- . Indicates a shared Network List (see “About Shared Network Lists” on page 95 for more information).

• ITEMS—The number of entries in the list.

• MODIFIED—The local date the list was last modified (or created). The time is also displayed if the modification/creation took place today.

• LIST TYPE—Either IP (IP address) or Geo (geographic location).

• STAGING STATUS/PRODUCTION STATUS—The list’s current status on the Edge Staging and Production Networks.

- . Inactive.

- . Pending Activation.

- . Active.

- . Modified.

- Failed. The list failed for some reason to activate on the Network.

• FIREWALL POLICY—The current action the Firewall Policy will take on the list’s contents.

- Not used. The list is not enabled in the Firewall Policy.

- Block. The Firewall Policy will block the list’s contents.

- Allow. The Firewall Policy will allow the list’s contents.

l. In the table, select the list you just created, if it is not already selected.

The list is highlighted and its contents appear below the table.

m. Populate the Network List.

• IP List.

- Adding individual IP addresses.

a. In the Add text box, enter an IP address and press the Enter key.

If valid, the IP address appears in the area below the text box.

b. Repeat for any additional IP addresses you would like to include.



- Adding IP addresses in bulk.

You can use CSV (Comma-Spaced Values) files to upload IP addresses in bulk.

a. Click .

A File Upload dialog box appears.

b. Navigate to and open your CSV file.

If the file contains all valid IP addresses, they appear in the area below the text box.

c. Repeat for any additional CSV files containing IP addresses you would like to include.

• Geo List.

1. In the Add text box, begin entering a geographic location.

A list appears during your entry, presenting you with locations con-taining the string of characters you entered.

2. Select the desired location by either using the keyboard arrow keys and pressing the Enter button, or by clicking it with your mouse.

The location appears in the area below the text box.

3. Repeat for any additional locations you would like to include.

Alternatively, you can click inside the text box, which produces a com-plete list of available locations. Simply scroll to the desired entry and click it.

You can remove individual entries by clicking the x next to its name. If you

wish to remove all entries from the list, click and then in the resulting dialog box.

n. Click in the list contents area.

o. From the FIREWALL POLICY dropdown menu, select Not used, Block, or Allow, as desired.

If the list type is Geo, only Not Used and Block are available, as anything not included in the list is automatically allowed.

p. If desired, activate the Network List on either the Edge Staging or Produc-tion Networks.

i. Click .

The Activate Network List dialog box appears.

ii. Select either the Staging or Production radio button, as desired.



iii. In the Siebel Ticket text box, if applicable, enter the service incident ticket number you generated with Akamai Customer Care.

This entry is more likely made by your account representative.

iv. In the Change Notes text box, enter explanatory notes for the activation.

v. If desired, in the Notification Email text box, enter any email addresses (semicolon-delimited) to which you would like notifications sent when the Network List is deployed to the Akamai Network.

vi. Click .

The Network Lists page appears displaying the Network List in a Pend-ing Activation ( ) status. Activations take approximately 35 minutes.

q. Repeat steps 5.g. through 5.p. for any additional Network Lists you wish to create.

Additionally, you can click and:

• Select to create a new Network List based on an existing one.

• Select to rename an existing Network List.

• Select to delete a Network List that is in an Inactive or Pending Activation status.

r. Click .



The Slow POST Protection page appears.

Figure 2-20. The Slow POST Protection Page

4. Complete the Slow POST Protection page.

Be aware, some of the parameters on this page are for Akamai internal users only and are annotated as such in the following steps. In addition, the below thresh-olds are a measure of the first 8 kilobytes of the POST body.

a. From the Action dropdown menu, select whether you would like violations of the Slow Rate Threshold and Duration Threshold to generate an Alert or to Abort the connection altogether.

Note: Slow POST Protection Alert and Abort events do not currently appear in Akamai Security Monitor. They are, however, available in log lines via Akamai’s Log Delivery Ser-vice.

b. If desired, select the Slow Rate Threshold check box to set transfer rate thresholds.

Enabling this feature averages the request’s POST rate every five seconds. If the average rate is at or below a threshold you determine (e.g., 10 bytes or less per second) for a period you determine (e.g., 60 seconds), the selected Action is taken (Alert or Abort).

i. (Akamai Internal Use) In the Continuous rate of text box, enter the rate (in bytes per second up to 100) at or below which you would like to take the designated action.



ii. (Akamai Internal Use) In the During any text box, enter the number seconds (up to 1000) for which the Slow Rate Threshold should be mea-sured.

Note: For example, an average rate of 10 bytes or less per second seconds) over a 60-second period would be considered a slow POST, and the selected Action (Alert or Abort) would be applied.

c. If desired, select the Duration Threshold check box to set a transfer rate thresholds.

This feature determines how long a connection can last. If the Edge server does not receive the first eight (8) kilobytes of the POST body transfer within the specified time, the selected action (Alert or Abort) is applied.

i. (Akamai Internal Use) In the Not received within text box, enter a threshold (in seconds up to 10000).

The default is 0 seconds, which indicates the feature is disabled.

Note: Duration Threshold takes precedence over Slow Rate Threshold. In other words, even if the Edge server has been receiving data at a sufficient rate, it will apply the chosen action (Alert or Abort) if it has not received the first POST body by the time value set here.

d. Click .



The User Validation Controls page appears.

Figure 2-21. The User Validation Controls Page



User Validation allows you to screen client requests for undesired automated processes such as troublesome Internet bots.

Caution: Akamai uses the URL elements /validate/akinfo.token and /validate/akinfo.challenge internally as Match Targets. Please do not use either of these paths on your origin.

5. Complete the User Validation Controls page’s Match Conditions parameters.

a. If desired, in the Hostname text box, enter one or more hostnames to which to apply User Validation.

Entries are space-delimited (e.g., www.example.com media.example.com). Leaving this blank causes User Validation to be applied only to the host-names defined in your Match Targets (see “Step 5—Creating Match Targets” on page 50).

b. If desired, from the IP/CIDRs dropdown menu, select matches or does not match, and enter an IP address(es) and/or CIDR block(s) in the accompany-ing text box (e.g., 192.168.0.1 192.168.1.0/24).

Entries are space-delimited and will be explicitly included in (matches) or excluded from (does not match) User Validation.

c. If desired, from the Path Suffix dropdown menu, select matches or does not match, and enter any desired paths (excluding hostnames) in the accompa-nying text box (e.g., for path www.example.com/util/crawl/bot/, enter /util/crawl/bot/*).


d. If desired, from the File Extensions dropdown menu, select matches or does not match, and enter any desired file extensions in the accompanying text box (e.g, html asp jsp).


Caution: You must allow the .js extension for User Validation to work correctly.

e. If desired, from the HTTP User Agent dropdown menu, select matches or does not match, and enter any desired user agents in the accompanying text box (e.g., Mozilla MSIE Googlebot).

Entries are space-delimited and will be explicitly included in (matches) or excluded from (does not match) User Validation. Be aware, wildcards (? Or *) are not permitted.

f. If desired, select the Empty HTTP User Agent check box to match on an empty string in the User Agent header.

g. If desired, from the HTTP Request Header dropdown menu, select matches or does not match, and enter any desired non-user agent request



headers in the accompanying text box (e.g., Content-Type:image/gif Cache-Control:no-cache).

Here, matches are performed on the entire header name, but the header's value is matched as a substring in the field's value. If only a string (without the colon) is entered then it is assumed that it is a match against the presence of the header name, irrespective of its value. Be aware, wildcards (? Or *) are not permitted.

Note: If there are multiple headers with the same name and this filter is set for a positive match, it will trigger if any of the given header values matches. If the filter is set for a neg-ative match, however, this filter will only trigger if none of the headers’ values contain the value.

6. Complete the User Validation Controls page’s Configuration parameters.

a. From the Strategy dropdown menu, select Javascript.

This selection determines the method for conducting user validity tests. When client requests arrive, they are directed through a validation process requiring them to run advanced Oracle® Javascript® scripts. Since automated processes cannot run these scripts, failure to do so here results in a denial action.

Currently, only the Javascript test method is available, but other methods are expected to be forthcoming.

b. In the Percent Users text box, enter the percentage of client requests allowed by the upper section’s match conditions that you would like to have tested for user validity.

The default value here is 10, which means 10 percent (selected randomly) of the overall matched conditions will be directed through the validation pro-cess.

c. In the Validation Cookie TTL text box, enter the amount of time (in min-utes) you would like the user validation cookie to remain on the client.

A session cookie is set on the client browser after it passes the user validation test. Setting a value here helps prevent valid clients from being continually challenged. The default value here is five (5) minutes.

d. If clients will be using the POST method to pass parameters, and you wish to have the POST body preserved in the validation process, select the Pre-serve POST Parameters check box.

The Handle Credit Cards check box appears.

i. If you expect clients to pass credit card or other sensitive information in their requests, and you wish to have it redacted from the validation pro-cess, select the Handle Credit Cards check box.



If the request passes User Validation, the client then resends the request, which is allowed to continue as normal. All processes are unseen by your end user.

e. Click .

The Web Application Firewall Configuration page appears, displaying the new Firewall Policy.

Figure 2-22. The Web Application Firewall Configuration Page with a New Firewall Policy

Back on the Web Application Firewall Configuration page, you have several available options. You can now:

• return to the Web Application Firewall page by clicking Configuration Versions.

• access the Web Application Firewall Rate Category Management page by click-ing Rate Category Management.

• create another Firewall Policy by clicking or by clicking in the Firewall Policies area.

• view the Firewall Policy’s parameters by clicking its name.

• make changes to an existing Firewall Policy by clicking its Edit link.

• clone a current Firewall Policy to create a new one based on its parameters by clicking its Clone link.

• delete an existing Firewall Policy by clicking its Delete link.

• create a Match Target by clicking in the Match Target area.



• view the configuration’s metadata by clicking .

• activate the configuration on the Edge Staging and/or Production versions of

Luna Control Center by clicking .

Step 2—Creating Web Application Firewall Rate Categories

Rate Categories are part of the Akamai Web Application Firewall’s Rate Control fea-ture, which allows you to protect your Web sites and applications against DDoS (Dis-tributed Denial of Service) attacks by monitoring and controlling the rate of requests against the Akamai EdgePlatform. You can incorporate Rate Categories as WAF rules, thus enabling you to dynamically alert or block clients exhibiting excessive request rate behaviors. For example, if a client exceeds a request rate Burst Threshold or Aver-age Threshold, those requests can be blocked until their request rate decreases to acceptable values.

More specifically, Rate Categories allow you to identify groups of requests by various criteria such as URL, extension, request method, user agent, and header content. Once defined, you can associate up to ten Rate Categories with a Web Application Firewall configuration. As part of the Rate Control feature, you also set an action to take once the configurable threshold of rule-violating requests that match the Rate Category has been met. For example, you might set up a Rate Category named “Page Views” to monitor for a page view request rate, and then attach that to your Web Application Firewall via Rate Policies, specifying that if more than 10 requests per second are received that trigger firewall rules A, B, or C, that also match “Page Views,” all future requests of the same type are denied until a 10-minute violation-free window has elapsed (see “Step 3—Creating a Rate Policy” on page 46 for more information regarding the workings of Rate Policies).

1. Access the Web Application Firewall Rate Category Management page.

a. Log in to Luna Control Center and select the appropriate context, if you have not done so already.

b. In the upper navigation bar, click the CONFIGURE tab.


c. Under the Security heading, select WAF Configuration.

The Web Application Firewall page appears (if the Select Product page appears first, select the product with which you want to work and click

).

d. Click Rate Category Management.



The Web Application Firewall Rate Category Management page appears.

Figure 2-23. The Web Application Firewall Rate Category Management Page

2. Create a Rate Category.

Note: When creating a Rate Category, be aware that all its defined parameters must be met in order to trigger a firewall action based on it.

a. Click .



The Create Rate Category page appears.

Figure 2-24. The Create Rate Category Page

b. In the Rate Category Name text box, enter a unique identifier.

Note: Be aware, if you do not specify a name, all parameters you specify for this Rate Cat-egory will be deleted, and an "ALL TRAFFIC" Rate Category will be created that will apply to all WAF-enabled traffic.

c. If desired, in the Rate Category Description text box, enter a description of the Rate Category.



d. From the Rate Category Type dropdown menu, select a category type for the Rate Category.

• Client Request. Applies to client requests sent to the Akamai EdgePlat-form.

• Forward Response. Applies to origin responses to client requests. For example, you might use this to prevent your origin from being forced to continuously send 404 HTTP errors.

• Forward Request. Applies to EdgePlatform requests to your origin from a given client.

e. From the Client Identifier dropdown menu, select what you would like the category to consider for rate infringements.

• Client IP. Checks for rate infringements from individual client IP addresses.

• Client IP and User Agent. Checks rates from individual client IPs pre-senting a particular User Agent header.

• Client Session. Checks rates from individual clients’ cookie values instead of IP addresses. This can be useful if you have many users behind a common IP address.

If selected, this displays a text box in which you can specify a particular cookie or cookies.

f. If desired, select the Use X-Forwarded-For Header check box.

By default, WAF uses the requesting IP address to determine whether a Rate Category applies. There is, however, a potential to generate false positives with this, especially if requests are being sent through proxy servers or load balancers where many requests appear to come from the same IP address. The Use X-Forwarded-For Header feature allows Akamai to instead use the contents of the X-Forwarded-For header for this purpose. This eliminates this risk but introduces potential problems of its own: the header is easily spoofed, and attackers can and do exploit it. Carefully consider this before enabling the feature.

Note: All steps beyond this point are optional and allow for fine tuning your Rate Cate-gory.

g. If desired, from the IP/CIDRs dropdown menu, select matches or does not match, and enter an IP address or addresses, or a CIDR block or blocks in the accompanying text box (entries are space-delimited).

The Rate Category will trigger if entries are included in (matches) or excluded from (does not match) incoming requests.



h. If desired, in the Digital Properties text box, enter the (space-delimited) hostname(s) of digital properties to which you would like the Rate Category to apply.

Leaving this blank applies the Rate Category to all digital properties covered by the WAF configuration of which it is part.

i. If desired, In the Path area, select a radio button to designate the desired type of path matching.

This allows you to fine tune the Rate Category by limiting its application to specific paths on your digital properties.

• Do not use path matching. Limits application of the Rate Category to the top-level hostname of your digital property (e.g., www.exam-ple.com)

• Match on top-level hostnames ending in a trailing slash. Matches only on top-level hostnames ending with a slash (/). For example, www.exam-ple.com/. In effect, this causes behavior identical to the Do not use path matching setting.

• Match on requests that end in a trailing slash. Matches on any path ending with a slash (/). For example, www.example.com/ or www.exam-ple.com/products/

• Custom path match. Matches or omits a specific path or paths you des-ignate on your digital properties.

1. From the accompanying dropdown menu, select matches or does not match.

2. If desired, in the Prepend text box, enter a leading path element common to all entries you want to include in your custom path, if applicable.

Use this if all your paths are contained within a single directory. For example, you have three paths:

• www.example.com/directory1/directory2/content

• www.example.com/directory1/directory2/media

• www.example.com/directory1/directory3

In each case, /directory1 is the leading path element, and this is what you would enter in the Prepend text box.

3. In the Path text box, enter the remaining path element or elements (space-delimited) that follow the Prepend text box entry, or if you did not use Prepend, enter the full path (sans hostname) for each entry.



Using the previous step’s example, if you entered /directory1 in the Prepend text box, here you would enter/directory2/content /directory2/media directory3.

You can also use an asterisk (*) wildcard character to indicate multi-ple included subdirectories. For example, if you have a path, /directory1/directory2/directory3, and you wish to include every-thing within /directory1, you could add an entry /directory1/* here.

j. If desired, from the File Extensions dropdown menu, select matches or does not match, and enter any specific file extensions (space-delimited) you wish to include (e.g., html asp jsp).


k. If desired, from the HTTP Method dropdown menu, select matches or does not match, and select the check boxes of any HTTP methods you wish the rate category to key on.

• GET

• PUT

• POST

• HTTP_DELETE

• HEAD

l. If desired, from the HTTP User Agent dropdown menu, select matches or does not match, and enter any User Agent substrings (space-delimited) you wish to include in the Rate Category in the accompanying text box (e.g., Mozilla MSIE Googlebot).


m. If desired, from the HTTP Request Header dropdown menu, select matches or does not match, and enter a single <header>:<value> pair you would like to include in the Rate Category in the accompanying text box (e.g., Content-Type:image/gif or Cache-Control:no-cache).

Matches are made on the entire header name, but the header’s value is matched as a substring in the field’s <value>. If only a string, without the colon (:), is entered here, it is assumed to be a match against the presence of the header name, irrespective of its <value>.

Note: If there are multiple headers with the same name, and this filter is set for a positive match, it will trigger if any of the given header values match. If the filter is set for a nega-tive match, however, this filter will only trigger if none of the headers’ values contain the <value>.



n. If desired, from the HTTP Response Header dropdown menu, select matches or does not match, and enter a single <header>:<value> pair you would like to include in the Rate Category in the accompanying text box (this filter is only present if Forward Response is selected from the Rate Cat-egory Type dropdown menu).

This filter functions identically to the HTTP Request Header filter discussed in the previous step.

o. If desired, from the HTTP Response Code dropdown menu, select matches or does not match, and enter any HTTP response codes (e.g., 404 500 200) you would like to include in the Rate Category in the accompanying text box (this filter is only present if Forward Response is selected from the Rate Category Type dropdown menu).

Entries are space-delimited and will be explicitly included in (matches) or excluded from (does not match) triggers of the Rate Category.

p. Click .

The Web Application Firewall Rate Category Management page appears, populated with your new Rate Category.

After creating your first Rate Category, on the Web Application Firewall Rate Cate-gory Management page you can:

• access the Web Application Firewall page by clicking Configuration Versions.

• create another Rate Category by clicking .

• view a Rate Category’s details by clicking its Rate Category ID.

• edit a current Rate Category by clicking its Edit link.

• clone a current Rate Category to create a new one based on its parameters by clicking its Clone link.

Step 3—Creating a Rate Policy

Once you have created at least one Rate Category, you will be able to create Rate Pol-icies for your Web Application Firewall. Rate Policies allow you to associate up to ten Rate Categories with a WAF configuration.

Note: Currently, Akamai’s platform memory resources limit the number of Rate Policies/Rate Categories that may be applied at any one time.

During setup, you will assign hits-per-second thresholds for matches on the Rate Cat-egory’s defined parameters, and you can choose whether to enable an action (Alert or Deny) or to use the Rate Policy for reporting purposes only. (The action itself is set in your individual Firewall Policies on the Rate Controls page. See “Step 4—Enabling Rate Policy Actions” on page 49.) Once thresholds are exceeded, the Alert/Deny sta-tus becomes active for approximately 10 minutes after the last threshold trigger. The action then becomes inactive until another threshold trigger reactivates it. Thresh-



olds’ samplings are calculated for two-minute windows that move with the current time.






).


c. Click the version number or select Edit from the version’s Actions dropdown

menu ( ).

The Web Application Firewall Configuration page appears. Notice the page now displays a Rate Policies area.

2. Create a new Rate Policy.

a. Click in the Rate Policies area.



The Add/Edit New Rate Policy page appears.

Figure 2-26. The Add/Edit New Rate Policy Page

b. From the Rate Category dropdown menu, select the Rate Category you would like to apply to the Rate Policy.

c. In the Bursting Threshold text box, enter the average number of hits per sec-ond occurring within a five-second period that, if exceeded, triggers the desired action (Alert, Deny, or reporting only).

d. In the Average Threshold text box, enter the average number of hits per sec-ond occurring within a two-minute period that, if exceeded, triggers the desired action (Alert, Deny, or reporting only).

e. If you desire to enable Alert and Deny actions for the Rate Policy, select the Enable Alert/Deny Action check box.

Leaving this deselected causes any Rate Policy violations to be used for reporting purposes only.

f. Click .



The Web Application Firewall Configuration page reappears, displaying the newly-created Rate Policy.

Figure 2-27. The Web Application Firewall Configuration Page Populated with a Rate Policy

At this point you can create up to nine additional Rate Policies, edit or delete the existing policy by clicking its Edit or Delete links, edit its Rate Category by clicking the Rate Category name, or you can continue with the WAF Configuration creation process.

Step 4—Enabling Rate Policy Actions

After creating your Rate Policies, you must enable them, as desired, in your Firewall Policy. This includes selecting the desired action (Alert or Deny) for the Rate Policy if you set your Rate Policies up to initiate violation actions.

1. Access the Rate Controls page.

a. On the Web Application Firewall Configuration page, click your Firewall Policy’s Edit link.

The Edit Firewall Policy page appears with a newly-present Rate Controls check box at page bottom.

b. Select the Rate Controls check box and click .



The page that appears depends on which check boxes you selected on the page (Application Layer Controls, Network Layer Controls, and/or Rate Controls).

c. If necessary, continue clicking until you reach the Rate Controls page.

The Rate Controls page appears.

Figure 2-28. The Rate Controls Page

2. Enable any desired Rate Policies in your Firewall Policy.

a. Select the check box of any Rate Policies you wish to include in your Firewall Policy.

b. If, when creating Rate Policies, you selected their Enable Alert/Deny Action check boxes, from their respective Action dropdown menus, select Alert or Deny as desired.

c. Click .


Step 5—Creating Match Targets

The next step in setting up your WAF configuration is to create Match Targets. These allow you to restrict the scope of processing for the various Firewall Policies in your configuration and to focus the firewall controls on a set of incoming requests. For instance, Match Target 1 could focus on one set of requests using the controls in Fire-wall Policy A, and Match Target 2 could focus on another set of requests using Fire-wall Policy B or Policies A or C.

Match Targets are based on incoming request criteria. For example, if the request is for an object that matches a path and extension, the request is parsed for the specified firewall controls. Different Match Targets can have the same or overlapping criteria; Match Targets A and B might both show example.com/files as a target path.



Within a configuration version there must be at least one Match Target to define the origin traffic to which to apply the Firewall Policy.

1. Access the Add Match Target page.

a. On the Web Application Firewall Configuration page, click Create a New Match Target.

b. The Add Match Target page appears.

Figure 2-29. The Add Match Target Page

2. Create a Match Target.

a. In the Digital Property text box, enter the digital property hostname or hostnames to which you would like the Match Target to apply (e.g., *.exam-ple.com or www.example.com).

The digital property here is the hostname for which Akamai serves content (e.g., www.example.com, test-www.example.com, www.example.com.edge-suite.net, etc.) and has an associated Edge hostname and Edge configuration file defining its content-handling specifications to the Akamai Network. If you leave this field blank, the Match Target will default to all digital proper-



ties in all Edge server configuration files for which the firewall is enabled. Multiple entries must be space-delimited.

b. In the Paths text box, enter any specific paths on which you would like the Match Target to apply (e.g., /default.asp, a%2Cb.htm, /images/*, etc.), and select whether you would like it to be a negative or positive match by select-ing or deselecting, respectively, the Negative Match check box.

Leaving the Negative Match check box deselected means the match will apply to requests for the Path text box entries. Selecting the check box means the match will apply to all paths except those in the text box. Multiple entries must be space-delimited.

c. If you wish to change how the Firewall Policy is applied within the specified paths, in the Default File area, click Match Criteria and select the desired radio button:

• Do not match on the default file

For example, index.html.

• Match on requests for the top-level hostname that ends in a trailing slash

For example, a match will occur on www.example.com/.

• Match on all requests that end in a trailing slash

For example, a match will occur on www.example.com/, www.exam-ple.com/products/, www.example.com/products/product_A/, etc.

d. In the File Extensions text box, enter any specific file extensions on which you would like the Match Target to apply (e.g., html, asp, jsp, etc.), and select whether you would like it to be a negative or positive match by select-ing or deselecting, respectively, the Negative Match check box.


e. If desired, from the WAF Bypass Network List area, select a Network List containing IP addresses you would like to allow to circumvent the WAF con-figuration altogether.

This can only be applied to IP Network Lists, not Geo Network Lists.

f. In the Policy Name area, select from the dropdown menu the Firewall Policy you would like to call into effect for the Match Target’s parameters, and select or deselect the check box of any of the Firewall Policy’s rule sets you would like to enable or disable.

g. Click .



A dialog appears with confirmations for your path and file extension matches.

h. If all is okay, click .

The Web Application Firewall Configuration page appears, displaying the new Match Target in the Match Targets area.

From here, with regard to Match Targets, you can:

• create a new Match Target by clicking Create a New Match Target.

• edit or delete a Match Target by clicking its Edit or Delete links, respectively.

• view a Match Target’s Firewall Policy’s details by clicking the Firewall Policy’s name.

• change the sequence in which the Match Targets are considered by selecting and changing their Sequence numbers.

Note: Only the last Match Target to match a request will have its Firewall Policy applied.

Step 6—Activating the WAF Configuration

The final step in setting up your WAF configuration is to activate it on either Aka-mai’s Edge Staging Network or Production Network. The former is useful for testing your configurations without actually impacting your live production traffic; the Pro-duction Network makes your configuration live.

1. Navigate to the Web Application Firewall activation page.

a. On the Web Application Firewall page, select Activate from the Actions

menu ( ) belonging to the WAF configuration you would like to acti-vate, or on the Web Application Firewall Configuration page, click

.

The Web Application Firewall activation page appears.

2. Activate the WAF configuration.

a. Review the configuration’s content in the Match Targets area and/or by clicking the name of the associated Firewall Policy in the Policy Name col-umn.

You can also review your configuration’s metadata by clicking at page bottom.

b. In the Network area, select the radio button of the network on which you would like to activate the configuration, Production or Staging.

c. In the Change Notes text box, enter any pertinent text for the activation.

d. In the Notification Email text box, enter the e-mail address at which you would like to receive notifications when your configuration is deployed to the Akamai network.



e. Click .

One of two things will occur, depending on whether you are including shared and/or inactive Network Lists in the Firewall Policy:

• Included shared or inactive Network Lists.

- A Network List Confirmation dialog box appears.

Figure 2-30. The Network List Confirmation Dialog Box

a. If you wish to receive email notifications each time the shared Network Lists’ owners newly activate these lists (after an update, for example) on either the Edge Staging or Production Net-works, select the Subscribe to updates of these shared network lists check box.

b. Click .

An activation confirmation page appears. If you selected the check box, you will receive notifications each time the shared Network Lists are activated. If there were inactive Network Lists included in the Policy, they will be activated on the Akamai Network in question.

• No included shared or inactive Network Lists.

- An activation confirmation page appears.

f. Click .

The Web Application Firewall page appears, displaying the configuration’s activation information, including the author’s user name, activation change notes, and the activation’s status (including activation time and date, and activation duration).

This completes the WAF configuration creation process. Your configuration will become active within approximately 15 minutes on the Edge Staging Network or


Deactivating Web Application Firewall Configurations

within approximately 30 minutes on the Production Network and begin protecting your content.

Deactivating Web Application Firewall Configurations

You can deactivate a configuration by selecting Deactivate from its Actions drop-

down menu ( ) on the Web Application Firewall page. Doing so displays a deac-tivation page for the configuration.

1. Deactivate the WAF configuration.

a. In the Network area, select the radio button of the network on which you would like to deactivate the configuration, Production or Staging.

Only the network on which the configuration is currently activated should be displayed here.

b. In the Change Notes text box, enter any pertinent text for the deactivation.

c. In the Notification Email text box, enter the e-mail address at which you would like to receive notifications when your configuration is deactivated from the Akamai network.

d. Click .

A deactivation confirmation page appears.

e. Click .

The Web Application Firewall page appears.

Your configuration will become inactive within approximately 15 minutes on the Edge Staging Network or within approximately 30 minutes on the Production Net-work.

Using Custom Rules

There may be instances in which the standard rule sets do not have a rule for a spe-cific action you would like to include in your firewall. In such cases, Akamai can cre-ate Custom Rules tailored for these purposes. If you find yourself in such a situation, please contact your account representative for information on your Custom Rules options.

Enabling Custom Rules in a Firewall Policy

If your account representative has created Custom Rules for your use, you must add them to your firewall configuration before they will become active. Once Custom Rules are created for you, they will appear on a separate page as part of the configura-tion editing process.



1. Edit the Firewall Policy.

a. On the Web Application Firewall page, click Edit for the configuration ver-sion for which you would like to enable your Custom Rules, or if you would prefer to create a new configuration based on a previous version, click that version’s Create Version from v[version#] link (see “Creating a New WAF Configuration Version from an Existing One” on page 86).


2. Access the Custom Rule Controls page.

a. Either click an existing Firewall Policy’s Edit link, or click Create a New Firewall Policy, as desired.

The Edit Firewall Policy page or the Create New Firewall Policy page, respectively, appears.

b. Make any desired entries and selections, select the Application Layer con-

trols check box, and click .

The Application Layer Controls page appears.

c. Set the parameters you desire and click .

The Custom Rule Controls page appears. To view a Custom Rule’s meta-data, click its ID number.

d. Select the check box of any Custom Rules you would like to enable in the Firewall Policy, and then use the Default Action dropdown menus to select default actions (Alert or Deny) for each.

e. Click .

If you selected Network Layer Controls, Slow POST Protection, User Vali-dation controls, and/or Rate Controls on the Create New Firewall Policy/Edit Firewall Policy page, those pages will appear in turn.

f. Select and enter any desired parameters and progress until you reach the final

page with the button.

Click .

g. The Web Application Firewall Configuration page appears.

h. Click Configuration Versions.


i. Select Activate from the Actions dropdown menu ( ) belonging to the WAF configuration version you just created or edited, and follow the activa-tion procedures as outlined in “Step 6—Activating the WAF Configuration” on page 53.


Modifying WAF Configurations

The configuration is deployed to the desired network and the selected Cus-tom Rules become active.


After creating your initial WAF configuration, there may be instances in which you will want to alter it by either editing it (if available) or creating a new version based on it, or you may wish to delete it altogether. This section describes how to perform these actions.

Editing a WAF Configuration

Editing a configuration is only possible on configurations that have never been acti-vated, even if you subsequently deactivate them. For activated configurations, your only option is to create a new version from an existing version (see “Creating a New WAF Configuration Version from an Existing One” on page 86).







).




c. Click the desired version’s version number or select Edit from its Actions

dropdown menu ( ).



On this page, you can create or edit Rate Policies, Firewall Policies, and Match Tar-gets.

Editing Rate Policies

If you wish to make changes to one or more of your Rate Policies, you can do so by following these procedures (for additional information on Rate Policies, please refer to “Step 3—Creating a Rate Policy” on page 46).

1. Edit a Rate Policy.

a. Click the desired Rate Policy’s Edit link.



The Add/Edit New Rate Policy page appears.

Figure 2-33. The Add/Edit New Rate Policy Page

b. If desired, from the Rate Category dropdown menu, select a new Rate Cate-gory you would like to apply to the Rate Policy.

c. If desired, in the Bursting Threshold text box, enter a new average number of hits per second occurring within a five-second period that, if exceeded, triggers the desired action (Alert, Deny, or reporting).

d. If desired, in the Average Threshold text box, enter a new average number of hits per second occurring within a two-minute period that, if exceeded, trig-gers the desired action (Alert, Deny, or reporting).

e. If you desire to enable Alert and Deny actions for the Rate Policy, select the Enable Alert/Deny Action check box, or deselect it if you wish the Rate Pol-icy to be used for reporting purposes only.

f. Click .

The Web Application Firewall Configuration page reappears, displaying the edited Rate Policy.

Editing Firewall Policies

On the Web Application Firewall Configuration page, you can also edit your exist-ing Firewall Policies.

Additionally, you can create new Firewall Policies based on the parameters of an exist-ing Firewall Policy and then make any desired modifications to the new version. To do this, decide on which existing Firewall Policy you would like to base the new Pol-icy and click its Clone link. This displays a Clone dialog box where you enter a New

Name for the new Policy, as well as a New Firewall ID. Clicking creates the Firewall Policy clone, which is displayed in the Firewall Policies area.

1. Begin editing a Firewall Policy.

a. Click the desired Firewall Policy’s Edit link.



The Edit Firewall Policy page appears.

Figure 2-34. The Edit Firewall Policy Page

b. If desired, in the Policy Name text box, enter a new name for the policy.

c. If desired, from the Analysis and Reporting dropdown menu, select None or Akamai Analysis and Security Monitor.

• Akamai Analysis and Security Monitor. Events triggered by this Firewall Policy can be analyzed using Akamai Security Monitor, available on Luna Control Center (MONITOR >> Security Monitor (under the Security heading)).

d. In the Enabled Controls area, select the control types you would like to enable and/or disable for the configuration (you must select at least one).

You will be able to configure each selected control on subsequent WAF edit pages.

• Application Layer Controls.

• Network Layer Controls.

• Slow POST Protection.

• User Validation Controls.

• Rate Controls.

e. Click .



Depending on which control or controls you chose, either the Application Layer Controls page, the Network Layer Controls page, the Slow POST Protection page, the User Validation Controls page, or the Rate Controls page appears.

Note: These procedures continue through each control page as if all were selected.

Figure 2-35. The Application Layer Controls Page (Displaying Akamai Kona Rule Set, Version 1.0)

2. Make any desired changes to the Application Layer Controls page.

a. (KRS 1.0 only) If desired, select a new Rules Profile from the Restore menu

( ).

i. If desired, click .

The Advanced Profile Options dialog box appears.

ii. In the Rule Actions area, select the desired radio button:

- Perform Akamai recommended actions. Violated rules either gener-ate an alert or deny the request altogether, depending on the Aka-mai’s best-determined practices.

- Log alerts only. Violated rules are logged only.

iii. In the remaining areas, select all check boxes that apply to your web site

and click .



b. If desired, in the Group By area, select the desired view.

c. If desired, click the arrows preceding any groups of which you would like to view specific rules.

d. Select or deselect the check box of any rules you would like to enable or dis-able, respectively, for your Firewall Policy.

Caution: Outbound rules can impact service performance if incorrectly applied. Only enable those rules relevant to your environment.

e. If you wish to change a rule’s action:

• KRS v1.0. From the rule’s ACTION dropdown menu, select Risk Scor-ing or Deny, as appropriate

• CRS v1.6.1. From the rule’s ACTION dropdown menu, select Alert or Deny, as appropriate.

f. Repeat steps 4.a. through 4.e. for any other rule groups you wish to include in your firewall.

g. (KRS v1.0 only) If desired, if you have rules in Risk Scoring mode, click Show Scoring Settings.

The Risk Scoring configuration box appears, displaying the Risk Groups along with their current action and sensitivity settings.

Figure 2-36. The Risk Scoring Configuration Box.

i. For each Risk Group you would like to enable for the Firewall Policy, select Alert or Deny, as desired, from the ACTION dropdown menu.

If you wish to disable the Risk Group in the Firewall Policy, select Not used.



ii. For each enabled Risk Group, if you wish to alter the sensitivity thresh-old from the default, enter a new value in the appropriate SENSITIV-ITY text box.

Be certain to enter thresholds less than the total possible score of all enabled rules within the group.

Note: Each Risk Group’s Sensitivity is set to an Akamai-determined optimal default. Aka-mai recommends you retain these defaults unless you require fine tuning. Be aware, some Akamai Common Rules have individual scores of 1000. This is by design and is intended to trigger an action even if only that single rule is violated.

h. Click .



The Network Layer Controls page appears.

Figure 2-37. The Network Layer Controls Page

3. Make any desired changes to the Network Layer Controls page.

a. If desired, select the IP CONTROLS tab.

The BLOCKED IPS and ALLOWED IPS windows and controls appear.

b. If desired, in the Network layer control mode area, change the type of IP Controls you would like to use.

• Block with exceptions: Block specific IPs unless they are also allowed. This setting allows you to both block and allow specified IP addresses by



entering them in the BLOCKED IPS and ALLOWED IPS lists, as appropriate. Be aware, the ALLOWED IPS list overrides BLOCKED IPS list entries. That is, if you were to add the CIDR block 192.168.0.0/24 to the BLOCKED IPS list and then add 192.168.0.68 to the ALLOWED IPS list, all addresses in the CIDR block will be disallowed except 192.168.0.68. For additional information regarding these two lists’ behaviors, see Appendix B.

Caution: If you add an entry to a list, then subsequently add it to the other, it will remain in the original list until you manually remove it. This is important to remember if you choose to block an IP address you previously added to the ALLOWED IPS list. Since the allowed list overrides the blocked list, the entry will continue to be allowed until you man-ually remove it from that list.

• Exclusive allow: Block all traffic except from allowed IPs. This setting blocks traffic from all IP addresses unless they are expressly specified in the ALLOWED IPS list.

Note: WAF configurations permit requests from IP addresses in their ALLOWED IPS lists, but those requests are still subject to and evaluated by all other WAF configuration rules and settings.

c. As desired, add and/or delete IP addresses using one or both available meth-ods:

• Adding IP addresses or CIDR blocks individually.

1. In the IP text box belonging to the appropriate list (BLOCKED IPS or ALLOWED IPS), enter an IP address or an IP range using a

CIDR block (e.g., 192.168.0.0/24) and click .

The entry appears in the appropriate list.

2. Repeat with any remaining IP addresses you wish to add.

• Adding bulk CSV- or text-formatted files of IP addresses/CIDR blocks.

1. In the BULK IP UPLOAD section, click for the appropri-ate list.

2. Navigate to and select the file you wish to upload.

3. Click .

The file’s IP addresses appear in the appropriate list window.

• Removing IP addresses or CIDR blocks.

1. From the appropriate list (Blocked IPs or Allowed IPs) select the check box of any IP address or CIDR block you wish to remove and

click the lists’ respective buttons



You can remove all entries by clicking .

Be aware, the ALLOWED IPS list overrides BLOCKED IPS list entries. That is, if you were to add the CIDR block 192.168.0.0/24 to the BLOCKED IPS list and then add 192.168.0.68 to the ALLOWED IPS list, all addresses in the CIDR block will be disallowed except 192.168.0.68. For additional information regarding behaviors of these two lists, see Appendix B.

Caution: If you add an entry to a list, then subsequently add it to the other, it will remain in the original list until you manually remove it. This is important to consider if you choose to block a previously allowed entry. Since the allowed list overrides the blocked list, the entry will continue to be allowed until you manually remove it from that list.

d. If desired, select the GEOGRAPHICAL CONTROLS tab.

The AVAILABLE COUNTRIES and BLOCKED COUNTRIES windows appear.

e. In the AVAILABLE COUNTRIES window, select the check box of any country you wish to deny access to your content.

The chosen countries move to the BLOCKED COUNTRIES window. You can move them back to the AVAILABLE COUNTRIES window by dese-lecting their check boxes.

f. If desired, select the NETWORK LISTS tab.

The Network Lists interface appears, displaying a scrollable list of all avail-able Network Lists.

You can use the Search lists text box to search for Network List names, or for specific IP addresses or geographic locations within your Network Lists (click Clear Search to return to the full list view). You can also use the List Type selection area to display IP lists only, Geo lists only, or All list types.

g. Perform the desired operation:

• Create a new Network List.

1. Click .


2. In the List name text box, enter a name for the Network List.


3. In the List Type area, select the IP or Geo radio button to create an IP address list or a geographic location list, respectively.



4. From the ACG dropdown menu, select the Access Control Group with which you would like to associate the Network List (available only if you have multiple ACGs).

5. Click .

The new list appears in the table.

6. In the table, select the list you just created.

The list is highlighted and its contents appears below the table.

7. Populate the Network List.

• IP List, Individual Entries. In the Add text box, enter an IP address and press Enter.


• IP List, Bulk Entries. Click and navigate to and open your CSV file.


• Geo List. In the Add text box, begin entering a geographic loca-tion, and from the resulting list, select the desired location by using the arrow and Enter keys, or by clicking it with the mouse.

Alternatively, you can click inside the text box, which produces a complete list of available locations. Simply scroll to the desired entry and click it.


8. Click in the list contents area.

9. From the FIREWALL POLICY dropdown menu, select Not used, Block, or Allow, as desired.

If the list type is Geo, only Not Used and Block are available, as anything not included in the list is automatically allowed.

• Change a Network List’s contents.

1. Select the list to which you would like to make changes.

The list is highlighted and its contents appears below the table.

2. Alter the Network List.

• IP List, Add Individual Entries. In the Add text box, enter an IP address and press Enter.




• IP List, Add Bulk Entries. Click and navigate to and open your CSV file.


• Geo List, Add Entries. In the Add text box, begin entering a geographic location, and from the resulting list, select the desired location by using the arrow and Enter keys, or by click-ing it with the mouse.



• Delete Individual Entries. Click the x belonging to the entry or entries you wish to remove from the Network List.

Each entry disappears as the operation is performed.

• Delete All Entries. Click and then confirm by click-ing in the resulting dialog box.

The Network List’s contents are removed.

3. Click in the list contents area.

• Duplicate a Network List.

1. Select the list you wish to duplicate.

2. Click and select Duplicate.

The Duplicate List “[list_name]” dialog box appears.

3. In the List name text box, enter a name for the duplicate Network List

4. From the ACG dropdown menu, select the Access Control Group with which you would like to associate the duplicate Network List.

5. Click .

The duplicate list appears.

• Rename a Network List.

1. Select the list you wish to rename.

2. Click and select Rename.

The Rename List dialog box appears.



3. In the List name text box, enter a new name for the Network List

4. Click .

The list appears with the new name.

h. If desired, activate the Network List on either the Edge Staging or Produc-tion Networks.

i. Click .


ii. Select either the Staging or Production radio button, as desired.

iii. In the Siebel Ticket text box, if applicable, enter the service incident ticket number you generated with Akamai Customer Care.


iv. In the Change Notes text box, enter explanatory notes for the activation.

v. If desired, in the Notification Email text box, enter any email addresses (semicolon-delimited) to which you would like notifications sent when the Network List is deployed to the Akamai Network.

vi. Click .

The Network Lists page appears displaying the Network List in a Pend-ing Activation ( ) status. Activations take approximately 35 minutes.

i. Click .



The Slow POST Protection page appears.

Figure 2-38. The Slow POST Protection Page

5. Make any desired changes to the Slow POST Protection page.

Be aware, some of the parameters on this page are for Akamai internal users only and are annotated as such in the following steps. In addition, the below thresh-olds are a measure of the first 8 kilobytes of the POST body.

a. If desired, from the Action dropdown menu, select whether you would like violations of the Slow Rate Threshold and Duration Threshold to generate an Alert or to Abort the connection altogether.

Note: Slow POST Protection Alert and Abort events do not currently appear in Akamai Security Monitor. They are, however, available in log lines via Akamai’s Log Delivery Ser-vice.

b. If desired, select the Slow Rate Threshold check box to set transfer rate thresholds.

Enabling this feature averages the request’s POST rate every five seconds. If the average rate is at or below a threshold you determine (e.g., 10 bytes or less per second) for a period you determine (e.g., 60 seconds), the selected Action is taken (Alert or Abort).

i. (Akamai Internal Use) In the Continuous rate of text box, enter the rate (in bytes per second up to 100) at or below which you would like to take the designated action (Alert or Abort).



ii. (Akamai Internal Use) In the During any text box, enter the number seconds (up to 1000) for which the Slow Rate Threshold should be mea-sured.

Note: For example, an average rate of 10 bytes or less per second seconds) over a 60-second period would be considered a slow POST, and the selected Action (Alert or Abort) would be applied.

c. If desired, select the Duration Threshold check box to set a transfer rate thresholds.

This feature determines how long a connection can last. If the Edge server does not receive the first eight (8) kb of the POST body transfer within the specified time, the selected action (Alert or Abort) is applied.

i. (Akamai Internal Use) In the Not received within text box, enter a threshold (in seconds up to 10000).

The default is 0 seconds, which indicates the feature is disabled.

Note: Duration Threshold takes precedence over Slow Rate Threshold. In other words, even if the Edge server has been receiving data at a sufficient rate, it will apply the chosen action (Alert or Abort) if it has not received the first POST body by the time value set here.

d. Click .



The User Validation Controls page appears.

Figure 2-39. The User Validation Controls Page



6. Make any desired changes to the User Validation Controls page’s Match Condi-tions parameters.

Caution: Akamai uses the URL elements /validate/akinfo.token and /validate/akinfo.challenge internally as Match Targets. Please do not use either of these paths on your origin.

a. If desired, in the Hostname text box, enter (or remove) one or more host-names to which to apply User Validation.

Entries are space-delimited (e.g., www.example.com media.example.com). Leaving this blank causes User Validation to be applied only to the host-names defined in your Match Targets.

b. If desired, from the IP/CIDRs dropdown menu, select matches or does not match, and enter (or remove) an IP address(es) and/or CIDR block(s) in the accompanying text box (e.g., 192.168.0.1 192.168.1.0/24).


c. If desired, from the Path Suffix dropdown menu, select matches or does not match, and enter (or remove) any desired paths (excluding hostnames) in the accompanying text box (e.g., for path www.example.com/util/crawl/bot/, enter /util/crawl/bot/*).


d. If desired, from the File Extensions dropdown menu, select matches or does not match, and enter (or remove) any desired file extensions in the accompa-nying text box (e.g, html asp jsp).


Caution: You must allow the .js extension for User Validation to work correctly.

e. If desired, from the HTTP User Agent dropdown menu, select matches or does not match, and enter (or remove) any desired user agents in the accom-panying text box (e.g., Mozilla MSIE Googlebot).

Entries are space-delimited and will be explicitly included in (matches) or excluded from (does not match) User Validation. Be aware, wildcards (? Or *) are not permitted.

f. If desired, select or deselect the Empty HTTP User Agent check box to match (or not) on an empty string in the User Agent header.

g. If desired, from the HTTP Request Header dropdown menu, select matches or does not match, and enter (or remove) any desired non-user agent request headers in the accompanying text box (e.g., Content-Type:image/gif Cache-Control:no-cache).



Here, matches are performed on the entire header name, but the header's value is matched as a substring in the field's value. If only a string (without the colon) is entered then it is assumed that it is a match against the presence of the header name, irrespective of its value. Be aware, wildcards (? Or *) are not permitted.

Note: If there are multiple headers with the same name and this filter is set for a positive match, it will trigger if any of the given header values matches. If the filter is set for a neg-ative match, however, this filter will only trigger if none of the headers’ values contain the value.

7. Make any desired changes to the User Validation Controls page’s Configuration parameters.

a. If desired, in the Percent Users text box, enter the percentage of client requests allowed by the upper section’s match conditions that you would like to have tested for user validity.

b. If desired, in the Validation Cookie TTL text box, enter the amount of time (in minutes) you would like the user validation cookie to remain on the cli-ent.

c. If clients will be using the POST method to pass parameters, and you wish to have the POST body preserved in the validation process, select the Pre-serve POST Parameters check box.

The Handle Credit Cards check box appears.

i. If you expect clients to pass credit card or other sensitive information in their requests, and you wish to have it redacted from the validation pro-cess, select the Handle Credit Cards check box.

d. Click .

The Rate Controls page appears.

Figure 2-40. The Rate Controls Page



8. If desired, enable and/or disable Rate Policies in your Firewall Policy.

a. Select the check box of any Rate Policies you wish to include in your Firewall Policy.

b. If, when creating Rate Policies, you selected their Enable Alert/Deny Action check boxes, from their respective Action dropdown menus, select Alert or Deny as desired.

c. Click .

The Web Application Firewall Configuration page appears, displaying the edited firewall policy.

Editing and Deleting Match Targets

Lastly, you can edit your existing Match Targets on the Web Application Firewall Configuration page.

1. Access the Edit Match Target page.

a. On the Web Application Firewall Configuration page, click the Edit link of the Match Target to which you would like to make changes.



b. The Edit Match Target page appears.

Figure 2-41. The Edit Match Target Page

2. Edit the Match Target.

a. If desired, in the Digital Property text box, enter or remove digital property hostname or hostnames (e.g., *.example.com or www.example.com).

The digital property here is the hostname for which Akamai serves content (e.g., www.example.com, test-www.example.com, www.example.com.edge-suite.net, etc.) and has an associated Edge hostname and Edge configuration file defining its content-handling specifications to the Akamai Network. If you leave this field blank, the Match Target will default to all digital proper-ties in all Edge server configuration files for which the firewall is enabled. Multiple entries must be space-delimited.

b. If desired, in the Paths text box, enter or remove any specific paths (e.g., /default.asp, a%2Cb.htm, /images/*, etc.), and select whether you would like them to be a negative or positive match by selecting or deselecting, respectively, the Negative Match check box.



Leaving the Negative Match check box deselected means the match will apply to requests for the Path text box entries. Selecting the check box means the match will apply to all paths except those in the text box. Multiple entries must be space-delimited.

c. If you wish to change how the Firewall Policy is applied within the specified paths, in the Default File area, click Match Criteria and select the desired radio button:

• Do not match on the default file

For example, index.html.

• Match on requests for the top-level hostname that ends in a trailing slash

For example, a match will occur on www.example.com/.

• Match on all requests that end in a trailing slash

For example, a match will occur on www.example.com/, www.exam-ple.com/products/, www.example.com/products/product_A/, etc.

d. If desired, in the File Extensions text box, enter or remove any specific file extensions (e.g., html, asp, jsp, etc.), and select whether you would like them to be a negative or positive match by selecting or deselecting, respectively, the Negative Match check box.


e. If desired, from the WAF Bypass Network List area, select a Network List containing IP addresses you would like to allow to circumvent the WAF con-figuration altogether.

This can only be applied to IP Network Lists, not Geo Network Lists.

f. If desired, in the Policy Name area, select a new Firewall Policy you would like to call into effect for the Match Target’s parameters from the dropdown menu, and select or deselect the check box of any of the Firewall Policy’s rule sets you would like to enable or disable.

g. Click .

A dialog appears with confirmations for your path and file extension matches.

h. If all is okay, click .

The Web Application Firewall Configuration page appears, displaying the new Match Target in the Match Targets area.



Upgrading the Rule Set from CRS, Version 1.6.1 to KRS, Version 1.0

Akamai has adopted Kona Rule Set (KRS), version 1.0 to supersede ModSecurity Core Rule Set, version 1.6.1. To facilitate upgrading to the new rule set, Akamai pro-vides you an upgrade wizard in Luna Control Center, which will assist you in the upgrade process and is accessible via the Application Layer Controls page. On com-pletion, all CRS v1.6.1 rules will be removed from your Firewall Policy, making only KRS v1.0 rules available from that point forward. You will be able to fine tune your rule settings using the Application Layer Controls page after completing the wizard.

Note: The wizard only upgrades rules that are currently enabled in your Firewall Policy. KRS v1.0 rules that are equivalent to currently disabled CRS v1.6.1 rules will not be enabled during the upgrade process.

1. Access the Web Application Firewall Configuration page.

a. On the Web Application Firewall page, click Edit for the configuration ver-sion for which you would like to upgrade your Core Rule Set.


2. Access the Kona Rule Set, version 1.0 upgrade wizard.

a. Click Edit for the desired Firewall Policy that is using CRS, version 1.6.1.

The Edit Firewall Policy page appears.

b. Ensure the Application Layer Controls check box is selected, and click

.



The Application Layer Controls page appears with a blue band at the top of the page stating that A new version of the core rule set is now available.

Figure 2-42. The Application Layer Controls Page with the KRS Rules Upgrade Notification

c. Click .



The Upgrade to KRS 1.0 dialog box appears.

Figure 2-43. The Upgrade to KRS 1.0 Dialog Box

3. Use the upgrade wizard.

a. In the Upgrade to KRS 1.0 dialog box’s Choose the type of upgrade area, select either the Use the upgrade wizard to migrate rules or the Use the new rule profiles radio button, as desired.

• If you selected the Use the new rule profiles radio button:

1. From the dropdown menu, select the WAF profile you would like to apply to the policy.

• Standard Protection. This profile protects against common, high-profile web attacks (SQLi, XSS, RFI/LFI, Command Injection, and PHP Injection only). With it, there is an extremely low chance of false positives, and it is suitable for cus-tomers who desire hands-free WAF configurations.



• Intermediate Protection. This profile also protects against com-mon, high-profile common web attacks (SQLi, XSS, RFI/LFI, Command Injection, PHP Injection, and +DDoS Tools only). It minimizes chances of false positives, but since it is “managed,” you may choose to use custom rules to provide additional miti-gation assistance. This profile is suitable for customers for whom a good level of security is desired and a slight chance of false positives is acceptable.

• Strict Protection. This is a custom profile that requires constant rule management. In addition to the attack types mentioned in the previous profiles, it may include some HTTP protocol vio-lations, Session Fixation, and others. This profile includes a high probability of false positives, and you must take care when using it in production environments.

2. If desired, click Advanced Profile Options.

The Advanced Profile Options area expands, revealing additional options for the selected WAF profile:

a. In the Rule Actions area, select the desired radio button:

- Perform Akamai recommended actions. Violated rules either generate an alert or deny the request altogether, depending on the Akamai’s best-determined practices.

- Log alerts only. Violated rules are logged only.

b. In the remaining areas, if available, select all check boxes that apply to your web site.

3. Click .

The Upgrade to KRS 1.0 dialog box disappears, and the Applica-tion Layer Controls page reappears with the appropriate rules selected and displaying an upgrade confirmation message.

• If you selected the Use the upgrade wizard to migrate enabled rules radio button:

1. Click .

A pop-up window appears displaying either one of two possible pages.

• Core Rule Set Upgrade. This page is displayed if the Firewall Policy currently has no CRS rules enabled. Clicking

simply removes CRS version 1.6.1 and replaces it with KRS version 1.0.



• Overview. This page is displayed if the Firewall Policy does have CRS rules enabled and will begin walking you through the upgrade process.

2. If the Overview page is displayed, click .

The Identical Rules page appears, displaying any rules enabled in your Firewall Policy that are unchanged in CRS version 2.2.6.

The page displayed next depends on your Firewall Policy’s setup, namely which CRS rules you have enabled for it and how they com-pare to the new Core Rule Set. The following procedures walk through the pages as if they all apply, but you should be aware that some may not be present for your upgrade.

Note: Clicking the Cancel button at any time while using the wizard cancels the upgrade process, and your Firewall Policy will continue using CRS version 1.6.1.

Figure 2-44. The Core Rule Set Upgrade—Identical Rules Page

3. Select the check boxes of all rules you wish to continue to have enabled (rules you choose to continue to have enabled will retain the



same action (Alert or Deny) you originally set for them in version

1.6.1), deselect any rules you wish to have disabled, and click .

The Improved Rules page appears, displaying any CRS, version 1.6.1 rules that have been improved with KRS, version 1.0 (retain-ing the same ID).

Figure 2-45. The Core Rule Set Upgrade—Improved Rules Page

4. Select the check boxes of all rules you wish to continue to have enabled (rules you choose to continue to have enabled will retain the same action (Alert or Deny) you originally set for them in CRS v1.6.1), deselect any rules you wish to have disabled, and click

.



The Replacement Rules page appears, displaying, by security tag, the number of CRS, version 1.6.1 rules enabled in the Firewall Pol-icy that have been replaced by new KRS, version 1.0 rules

Figure 2-46. The Core Rule Set Upgrade—Replacement Rules Page

The Old Rules (v1.6.1) column indicates the number of affected CRS, version 1.6.1 rules and the New Rules (vKRS 1.0) column indicates the number of KRS, v1.0 rules that replace them.

On completing the upgrade process, all CRS, version 1.6.1 rules will be removed in favor of those in KRS, version 2.2.6.

5. Select the check boxes of all security tags for which you wish to enable the appropriate replacement KRS, version 1.0 rules in the Firewall Policy (all rule actions will be set to Alert regardless of their respective CRS, version 1.6.1 rules’ settings), deselect the check boxes of the security tags for which you wish to disable the appropri-

ate replacement KRS, version 1.0 rules, and click .

The Obsolete Rules page appears, displaying CRS, version 1.6.1 rules that have been deprecated with KRS, version 1.0 (in most cases, obsolete rules have been superseded by Replacement Rules).



This page is for notification purposes only and no actions can be taken on it.

Figure 2-47. The Core Rule Set Upgrade—Obsolete Rules Page

6. Click .



The Summary page appears, displaying the number of each type of rule that will be enabled (identical, improved, and replacement rules) or removed (obsolete rules).

Figure 2-48. The Core Rule Set Upgrade—Summary Page

7. Click .

The Application Layer Controls page appears with an upgrade con-firmation field at the top of the page.

Note: The upgrade will not take effect until you complete the WAF configuration editing

process by clicking on the final page.

Creating a New WAF Configuration Version from an Existing One

If you wish to create a completely new configuration version, you must do so by bas-ing it on an existing version.









).

3. Create a new configuration version.

a. Choose the existing configuration version on which you would like to base the new version and select Create Version from v[version#] from its Actions

dropdown menu ( ).

A new configuration version is created and the Web Application Firewall Configuration page appears.

b. Use the procedures outlined in “Editing a WAF Configuration” on page 57 to make all desired changes to the configuration.

On completion, the Web Application Firewall displays the new version.

At this point, you can activate the new version, if desired (see “Step 6—Activating the WAF Configuration” on page 53). You can also compare configuration versions by

selecting their check boxes and clicking .

Deleting a WAF Configuration

If you wish to delete a configuration version, you can do so on the Web Application Firewall page. Be aware, you may not delete version 1 of a configuration or any other version that is currently active on either the Edge Staging Network or the Production Network.







).



3. Delete a configuration.

a. Select Delete from the Actions dropdown menu ( ) belonging to the version you would like to remove.

A confirmation dialog box appears

b. Click .

A message appears confirming the version was deleted.

Modifying Rate Categories

After creating a WAF Rate Category, there may be instances in which you will want to alter it by either editing it or creating a new version based on it. This section describes how to perform these actions.

Editing Rate Categories

Be aware, editing a Rate Category that is associated with a WAF configuration as a Rate Policy will alter how the configuration behaves. It is not necessary to edit the configuration itself for this behavior change to occur.






The Web Application Firewall page appears (if the Select Product page appears first, select the product with which you want to work and click

).

c. In the Quick Links area, click Rate Category Management.





3. Edit a Rate Category.

a. Click the Edit link belonging to the Rate Category you wish to change.



The Edit Rate Category page appears.

Figure 2-50. The Edit Rate Category Page



b. If desired, in the Rate Category Name text box, enter a new unique identi-fier.

Note: Be aware, if you do not specify a name, all parameters you specify for this Rate Cat-egory will be deleted, and an "ALL TRAFFIC" Rate Category will be created that will apply to all WAF-enabled traffic.

c. If desired, in the Rate Category Description text box, enter a description of the Rate Category.

d. If desired, from the Rate Category Type dropdown menu, select a different category type for the Rate Category.

• Client Request. Applies to client requests sent to the Akamai EdgePlat-form.

• Forward Response. Applies to origin responses to client requests. For example, you might use this to prevent your origin from being forced to continuously send 404 HTTP errors.

• Forward Request. Applies to EdgePlatform requests to your origin from a given client.

e. If desired, from the Client Identifier dropdown menu, select what you would like the category to consider for rate infringements.

• Client IP. Checks for rate infringements from individual client IP addresses.

• Client Session. Checks rates from individual clients’ cookie values instead of IP addresses. This can be useful if you have many users behind a common IP address.

If selected, this displays a text box in which you can specify a particular cookie or cookies.

• Client IP and User Agent. Checks rates from individual client IPs pre-senting a particular User Agent header.

f. If desired, select the Use X-Forwarded-For Header check box.

By default, WAF uses the requesting IP address to determine whether a Rate Category applies. There is, however, a potential to generate false positives with this, especially if requests are being sent through proxy servers or load balancers where many requests appear to come from the same IP address. The Use X-Forwarded-For Header feature allows Akamai to instead use the contents of the X-Forwarded-For header for this purpose. This eliminates this risk but introduces potential problems of its own: the header is easily spoofed, and attackers can and do exploit it. Carefully consider this before enabling the feature.

Note: All steps beyond this point are optional and allow for fine-tuning your Rate Cate-gory.



g. If desired, from the IP/CIDRs dropdown menu, select matches or does not match, and enter (space-delimited) or remove an IP address(es) or CIDR block(s) in or from the accompanying text box.


h. If desired, in the Digital Properties text box, enter or remove the (space-delimited) hostname(s) of digital properties to which you would like the Rate Category to apply.

Leaving this blank applies the Rate Category to all digital properties covered by the WAF configuration of which it is part.

i. If desired, In the Path area, select a radio button to designate the desired type of path matching.

This allows you to fine tune the Rate Category by limiting its application to specific paths on your digital properties.

• Do not use path matching. Limits application of the Rate Category to the top-level hostname of your digital property (e.g., www.exam-ple.com)

• Match on top-level hostnames ending in a trailing slash. Matches only on top-level hostnames ending with a slash (/). For example, www.exam-ple.com/. In effect, this causes behavior identical to the Do not use path matching setting.

• Match on requests that end in a trailing slash. Matches on any path ending with a slash (/). For example, www.example.com/ or www.exam-ple.com/products/

• Custom path match. Matches or omits a specific path or paths you des-ignate on your digital properties.

1. From the accompanying dropdown menu, select matches or does not match.

2. If desired, in the Prepend text box, enter or remove a leading path element common to all entries you want to include in your custom path, if applicable.

Use this if all your paths are contained within a single directory. For example, you have three paths:

• www.example.com/directory1/directory2/content

• www.example.com/directory1/directory2/media

• www.example.com/directory1/directory3

In each case, /directory1 is the leading path element, and this is what you would enter in the Prepend text box.



3. In the Path text box, enter or remove the remaining path element or elements (space-delimited) that follow the Prepend text box entry, or if you did not use Prepend, enter or remove the full path (sans hostname) for each entry.

Using the previous step’s example, if you entered /directory1 in the Prepend text box, here you would enter/directory2/content /directory2/media directory3.

You can also use an asterisk (*) wildcard character to indicate multi-ple included subdirectories. For example, if you have a path, /directory1/directory2/directory3, and you wish to include every-thing within /directory1, you could add an entry /directory1/* here.

j. If desired, from the File Extensions dropdown menu, select matches or does not match, and enter (space-delimited) or remove any specific file extensions you wish (or do not wish) to include or exclude (e.g., html asp jsp).


k. If desired, from the HTTP Method dropdown menu, select matches or does not match, and select check boxes of any HTTP methods you wish the Rate Category to key on or deselect check boxes of any methods you want the Rate Category to no longer key on.

• GET

• PUT

• POST

• HTTP_DELETE

• HEAD

l. If desired, from the HTTP User Agent dropdown menu, select matches or does not match, and enter (space-delimited) or remove any User Agent sub-strings you wish (or do not wish) to include in the Rate Category in the accompanying text box (e.g., Mozilla MSIE Googlebot).


m. If desired, from the HTTP Request Header dropdown menu, select matches or does not match, and enter or remove the single <header>:<value> pair you would like (or not like to) to include in or exclude from the Rate Category in the accompanying text box (e.g., Con-tent-Type:image/gif or Cache-Control:no-cache).

Matches are made on the entire header name, but the header’s value is matched as a substring in the field’s <value>. If only a string, without the



colon (:), is entered here, it is assumed to be a match against the presence of the header name, irrespective of its <value>.

Note: If there are multiple headers with the same name, and this filter is set for a positive match, it will trigger if any of the given headers’ values match. If the filter is set for a neg-ative match, however, this filter will only trigger if none of the headers’ values contain the <value>.

n. Click .


Creating New Rate Categories from Existing Rate Categories

One method for creating new Rate Categories is to base it on the parameters of an existing Rate Category and then make any desired modifications to the new version.





b. Under the Security heading, select WAF Rate Category Management.

The Web Application Firewall Rate Category Management page appears (if the Select Product page appears first, select the product with which you want

to work and click ).


3. Create a new Rate Category based on an existing Rate Category.

a. Decide on which existing configuration version you would like to base the new version and click its Clone link.

The Clone Rate Category page appears.


Creating and Modifying Network Lists

b. Use the procedures outlined in “Editing Rate Categories” on page 88 to make all desired changes to the Rate Category.

c. Click .

The Web Application Firewall Rate Category Management page appears, displaying the new Rate Category.


As described in “Creating Configurations Manually” on page 18, you can create and modify Network Lists in the course of creating your WAF Firewall Policy. The pre-ferred means of managing Network Lists, however, is via the Network Lists Manage-ment page. This section describes how to perform these actions.

About Shared Network Lists

Akamai personnel have the ability to create Network Lists that they can share with you and other customers. These read-only lists are typically made up of IP addresses (or possibly geographies) belonging to known offenders sharing a common theme and, when shared, will automatically appear on your Network Lists pages (denoted by an Akamai wave ( ) icon). You, of course, are in no way obligated to use shared Net-work Lists in your Firewall Policy, but they will remain available to you at all times. Some additional items of note:

• You can create duplicates of shared Network Lists to use as your own lists.

• Shared Network Lists will never appear in an inactive state on either the Edge Staging or Production Networks.

• When you add a shared Network List to a Firewall Policy, you will be given the opportunity to be notified whenever that list is activated by its owner on either the Edge Staging or Production Networks (after the list is modified, for exam-ple).

Creating Network Lists


2. Navigate to the Network Lists Management page.



b. Under the Security heading, select Network List Management.



The Network Lists Management page appears, displaying a scrollable list of all available Network Lists.

Figure 2-52. The Network Lists Management Page (Unpopulated)

Additionally, you can use the Search lists text box to search for Network List names, or for specific IP addresses or geographic locations within your Net-work Lists (click Clear Search to return to the full list view). You can also use the List Type selection area to display IP lists only, Geo lists only, or All list types.

c. Click to add a new Network List.


Figure 2-53. The Create Network List Dialog Box

d. In the List name text box, enter a name for the Network List.


e. In the List Type area, select the IP or Geo radio button to create an IP address list or a geographic location list, respectively.

f. From the ACG dropdown menu, select the Access Control Group with which you would like to associate the Network List.



g. Click .

The new list appears in the table, which includes the following information:

• LIST NAME—The name you gave to the list.

- . Indicates a shared Network List (see “About Shared Network Lists” above).

• ITEMS—The number of entries in the list.

• MODIFIED—The local date the list was last modified (or created). The time is also displayed if the modification/creation took place today.

• LIST TYPE—Either IP (IP address) or Geo (geographic location).

• STAGING STATUS/PRODUCTION STATUS—The list’s current status on the Edge Staging and Production Networks.

- . Inactive.

- . Pending Activation.

- . Active.

- . Modified.

- Failed. For some reason the list failed to activate on the Network.

Figure 2-54. The Network Lists Management Page

h. In the table, select the list you just created if it is not already selected.

The list is highlighted and its contents appear below the table.

i. Populate the Network List.

• IP List.




a. In the Add text box, enter an IP address and press Enter.





a. Click .





• Geo List.

1. In the Add text box, begin entering a geographic location.

A list appears during your entry, presenting you with locations con-taining the string of characters you entered.

2. Select the desired location by either using the keyboard arrow keys and pressing Enter, or by clicking it with your mouse.


3. Repeat for any additional locations you would like to include.

Alternatively, you can click inside the text box, which produces a com-plete list of available locations. Simply scroll to the desired entry and click it.

You can remove individual entries by clicking the x next to its name. If you

wish to remove all entries from the list, click and then in the resulting dialog box.

j. Click in the list contents area.

k. Repeat steps 2.c. through 2.j. for any additional Network Lists you wish to create.

Additionally, you can click and:

• Select to create a new Network List based on an existing one.



• Select to rename an existing Network List.

• Select to delete a Network List that is in an Inactive or Pending Activation status.

Activating Network Lists

After creating your Network Lists, you may activate them on the Edge Staging or Production Networks to make them available for use by your Firewall Policies.

1. Activate the Network List on either the Edge Staging or Production Networks.

a. Click .


Figure 2-55. The Activate Network List Dialog Box

b. Select either the Staging or Production radio button, as desired.

c. In the Siebel Ticket text box, enter the service incident ticket number you generated with Akamai Customer Care, if applicable.


d. In the Change Notes text box, enter any desired explanatory notes for the activation (required).



e. If desired, in the Notification Email text box, enter any email addresses (semicolon-delimited) to which you would like notifications sent when the Network List is deployed to the Akamai Network.

f. Click .

The Network Lists page appears displaying the Network List in a Pending Activation status ( ). Activations take approximately 35 minutes.

Note: If you modify a Network List that is in a Pending Activation state, it will continue in that state until activated on the Akamai Network, at which time the list’s state will change to Modified ( ).

Modifying Network Lists

Be aware, you may only modify Network Lists you have created. Shared lists are uneditable except by their owners.


2. Navigate to the Network Lists Management page.



b. Under the Security heading, select WAF Network List Management.

The Network Lists Management page appears.

Figure 2-56. The Network Lists Management Page

Additionally, you can use the Search lists text box to search for Network List names, or for specific IP addresses or geographic locations within your Net-



work Lists. You can also use the List Type selection area to display IP lists only, Geo lists only, or All list types.

c. In the table, select the list you wish to edit.

The list is highlighted and its first 200 entries appear below the table. You can expand this list by an additional 200 entries by clicking at the end of the list.

d. Make any desired changes to the Network List.

• IP List.


a. In the Add text box, enter an IP address and press Enter.





a. Click .





- Deleting individual entries.

a. Click the x next to the entry in question.

- Deleting all entries.

a. Click and then in the resulting dialog box.

The list is emptied of its contents.

• Geo List.

- Adding entries.

a. In the Add text box, begin entering a geographic location.

A list appears during your entry, presenting you with locations containing the string of characters you entered.



b. Select the desired location by either using the keyboard arrow keys and pressing Enter, or by clicking it with your mouse.



c. Repeat for any additional locations you would like to include.


- Deleting individual entries.

a. Click the x next to the entry in question.

- Deleting all entries.

a. Click and then in the resulting dialog box.

The list is emptied of its contents.

e. Click in the list contents area.

The updated list appears in the Network List table. If the list was active on a network, it will display a with a status of Modified ( ).

Note: If you modify a Network List that is in a Pending Activation state, it will continue in that state until activated on the Akamai Network, at which time the list’s state will change to Modified ( ).

f. If desired, activate the Network List (see “Activating Network Lists” on page 99).

Resolving Network List Modification Conflicts (Merging Lists)

When working with Network Lists, there could be instances in which two users are modifying the same list at the same time. In such cases, if one user saves his or her changes before the other, the second user will experience a conflict when he or she attempts to save their own changes. These conflicts are resolved using the Merge Lists utility. When the second user attempts to save their list, a blue banner appears, noti-fying them The list was modified by another client, along with an accompanying

button ( ).

1. Accept the list merge.

a. Click .


Required Postprovisioning Tasks

The Merge dialog box appears displaying your changes in the Local Changes column, the other user’s changes in the Remote Changes column, and the resulting merged list in the Merged column.

Figure 2-57. The Merge Dialog Box

b. If you wish to make any changes to the merged list, do so in the Merged col-umn.

c. Click .

The Network Lists page appears, displaying the list’s merged contents.


It is very important to understand that, for Akamai Web Application Firewall to work properly with your delivery product or products, you must, in addition to provision-ing WAF itself, perform some postprovisoning tasks.

Enabling WAF in Your Delivery Product (Required)

After provisioning WAF, you must enable it using either Configuration Manager or Property Manager. The method you use will depend on which tool has been enabled for your account.

Also, because some attack vectors may be found in the referer header, host header, user agent header, or cookies, Akamai highly recommends enabling the logging of those items in your delivery product configuration (see “Enabling WAF with the Log Delivery Service (LDS) (Optional Step)”below).



Enabling WAF in Your Delivery Product Using Configuration Manager

For purpose of example, the following procedures assume a WAA product. Some steps may vary depending on the product for which you are enabling WAF.

Note: These procedures do not apply to the Kona Site Defender™ solution, as your WAF configurations are automatically enabled in that product when they are provisioned.

1. Navigate to the Web Application Accelerator Configurations page.

a. Log in to Luna Control Center and select the appropriate context.

The Group Details page appears.

b. In the upper navigation bar, click the CONFIGURE tab.


c. Under the Property heading, select Application.

The Web Application Accelerator Configurations page appears. (If the Select Product page appears, select the Web Application Accelerator radio

button and click ).

2. Enable WAF in the desired configuration.

a. Click the name of the configuration for which you would like to enable WAF.

The configuration’s Configuration History page appears.

b. Choose a configuration version to use as a baseline, and click its Create Version from [version#] link.

The Review Changes page appears.

c. Scroll down to the WEB APPLICATION FIREWALL area and click Edit.


d. Select the Enable Web Application Firewall check box and click .

The Review Changes page reappears with the new setting.

e. Scroll down to the REPORTING area and click Edit.

The Reporting Options page appears.

f. Select the Host, Referer, and User Agent check boxes, and select the Include

all cookie values radio button, and click .

The Review Changes page reappears with the new setting.

g. In the Network area, select the radio button of the network on which you would like to activate the configuration, Production or Staging.

h. In the Change Notes text box, enter any pertinent text for the activation.



i. In the Notification Email text box, enter the e-mail address at which you would like to receive notifications when your configuration is deployed to the Akamai network.

j. Click , enabling WAF for the configuration.

Repeat this procedure for any other products for which you wish to enable WAF. For more information regarding creating configurations for your WAF-eligible delivery products, refer to their respective user guides, available on Luna Control Center.

Enabling WAF in Property Manager

1. Navigate to the Property Manager page.

a. Log in to Luna Control Center and select the appropriate account (if you have access to more than one).

The MY AKAMAI page appears.

b. Using the Context Selector ( ), select the group having the property you would like to edit.

The GROUPS page appears.

c. Click the name of the property you would like to edit.

The Property Home page appears.

d. In the MANAGE VERSIONS AND ACTIVATIONS section and click the name of the property version for which you would like to configure WAF.

The Property Manager page appears.

Note: If you prefer to create a new property version, or if the version you would like to edit has already been activated, select Edit New Version from the Actions dropdown menu (

) belonging to the version on which you would like the new version based.

Note: Steps 2.a. to 2.e. do not apply to the Kona Site Defender™ solution, as your WAF behaviors are automatically enabled in that product when they are provisioned. If you have Kona Site Defender, you may proceed to step 2.f.

2. Add a WAF behavior to the property configuration.

a. Scroll to the PROPERTY CONFIGURATIONS SETTINGS section.

b. In the left-hand Rules column, select Default Rule.

c. In the Behaviors section, click .



The Add a Behavior for this Rule dialog box appears.

Figure 2-58. The Add a Behavior for this Rule page

d. In the left-hand Available Behaviors window, select Web Application Fire-wall (WAF).

Web Application Firewall (WAF) appears in the right-hand window.

e. Click .

The Property Manager page appears, and the new Web Application Firewall (WAF) behavior is displayed in the PROPERTY CONFIGURATION SETTINGS area in the Default Rule’s Behaviors column.

f. In the Web Application Firewall (WAF) box, click edit ( ).



The Web Application Firewall Configuration dialog box appears.

Figure 2-59. The Web Application Firewall Configuration Dialog Box

g. Select the desired WAF configuration file.

Note: If you have created a WAF configuration, but it is not present in the dialog box, con-tact your account representative for assistance.

h. Click .

The Property Manager page reappears displaying the configured WAF behavior.

i. Click .

The property configuration is saved.



Enabling WAF with the Log Delivery Service (LDS) (Optional Step)

Optionally, if you wish to enable log delivery for your WAF service (recommended), you must also follow these procedures prior to provisioning WAF.

1. Log in to Luna Control Center and select the appropriate context if you have not done so already.

2. Navigate to the Log Delivery Service page.



b. Select Log Delivery.

The Log Delivery Service page appears. (If the Select Product page appears,

select the appropriate delivery product’s radio button and click ).

3. Enable WAF log delivery.

c. Click Begin Log Delivery for the CP code for which you would like WAF logs delivered.

The Create New Configuration page appears.

d. In the Log Format area, select the Combined + Web App Firewall or the W3C + Web App Firewall radio button, as desired (see Appendix C. for Web App Firewall-specific field additions to Combined and W3C formats).

e. Make any additional changes you desire and complete the log delivery con-figuration.


Chapter 3. Using Rule Conditions

In This Chapter

Akamai Web Application Firewall Rule Conditions allow you to limit (filter) when a specific WAF rule fires. They are grouped and applied in two stages such that the rule is executed if all of a first set of conditions and none in a second set are met. If any conditions in the second set are met, the rule does not execute. Thus, one can think of the second set as exceptions to the first set.

Accessing Rule Conditions

You can access Rule Conditions while creating or editing your WAF Firewall Policy configuration.

1. Using the procedures in “Creating WAF Configurations” on page 6, or “Modify-ing WAF Configurations” on page 57, access the Application Layer Controls page belonging to the Firewall Policy in which you would like to insert Rule Conditions.

2. Select a rule to which you would like to add Conditions.

The rule is highlighted.

3. From the Actions dropdown menu ( ), select Edit Rule Conditions.

The Edit Rule Conditions dialog box appears.

Figure 3-1. The Edit Rule Conditions Dialog Box

After accessing Rule Conditions, you can begin configuring them using the proce-dures in the next section.

Accessing Rule Conditions • 109

Setting Up Rule Conditions • 110


Using Rule Conditions

Setting Up Rule Conditions

Using the Edit Rule Conditions dialog box, you can set any conditions for the rule you desire.

1. Access the Edit Rule Conditions dialog box using the procedures in the previous section.

2. If desired, set your desired Rule Conditions.

Note: Be aware, if you select multiple Conditions, a request must match them all for the rule to execute.

a. In the Only run this rule when the following conditions are met area, from the Select Condition... dropdown menu, select the types of Conditions you would like to set for the rule and configure them.

• Digital Property.

When selected, a second dropdown menu and a Digital Property text box appear.

1. From the dropdown menu, select matches or does not match, depending on whether you would like the Condition to match or not match, respectively, the value or values you place in the Digital Property text box.

2. In the Digital Property text box, enter one or more of your digital properties on which you would like the Condition to be applied.

This entry should appear as it does in your application’s Edge server configuration or with wildcards (e.g., www.example.com or *.exam-ple.com. Separate multiple entries with a space.

If you wish to remove an entry, click the x that precedes it.

• Path.

When selected, a second dropdown menu and a Path text box appear.

1. From the dropdown menu, select matches or does not match, depending on whether you would like the Condition to match or not match, respectively, the value or values you place in the Path text box.

2. In the Path text box, enter one or more paths on which you would like the Condition to be applied.

This entry should be URL-encoded and begin with a forward slash (/). Separate multiple entries with a space.


• Filename.



When selected, a second dropdown menu and a Filename text box appear.

1. From the dropdown menu, select matches or does not match, depending on whether you would like the Condition to match or not match, respectively, the value or values you place in the File-name text box.

2. In the Filename text box, enter one or more filenames on which you would like the Condition to be applied.

This entry should include the filename and its file extension. Sepa-rate multiple entries with a space.


• Extension.

When selected, a second dropdown menu and an Extension text box appear.

1. From the dropdown menu, select matches or does not match, depending on whether you would like the Condition to match or not match, respectively, the value or values you place in the Exten-sion text box.

2. In the Extension text box, enter one or more extensions on which you would like the Condition to be applied.

This entry should be extensions with no periods (e.g., png jpg gif ). Separate multiple entries with a space.


• Query String.

When selected, a second dropdown menu appears, along with Query Name and Query Value text boxes and related controls.

1. From the dropdown menu, select matches or does not match, depending on whether you would like the Condition to match or not match, respectively, the value or values you place in the Query Name and Query Value text boxes.

2. In the Query Name text box, enter the name of the query string variable on which you would like the Condition to be applied and select the Case sensitive check box if you would like that to apply.

Only one entry is allowed here. If you want to match on another query string variable, you must create another Rule Condition.

3. In the Query Value text box, enter the query string variable’s value on which you would like the Condition to be applied, and select the Case sensitive and/or Wildcards check boxes if you would like one or both of those to apply.



Only one entry is allowed per Rule Condition.

• IP Address.

When selected, a second dropdown menu appears, along with an IP Address text box and an Inspect XFF headers check box.

1. From the dropdown menu, select matches or does not match, depending on whether you would like the Condition to match or not match, respectively, the value or values you place in the IP Address text box.

2. In the IP Address text box, enter one or more IP addresses on which you would like the Condition to be applied.

Only valid IP addresses are accepted. If you wish to remove an entry, click the x that precedes it.

3. If you would like the Rule Condition to check for the IP address(es) in the request’s XFF header, select the Inspect XFF headers check box.

• Request Method.

When selected, a second dropdown menu and a Request Method list box appear.

1. From the dropdown menu, select matches or does not match, depending on whether you would like the condition to match or not match, respectively, the value or values you select from the Request Method list box.

2. In the Request Method list box, click inside the box and, from the resulting list, select a method on which you would like the Condi-tion to be applied (GET, POST, HEAD, PUT, or HTTP_DE-LETE).

Repeat this step for any additional methods you would like to include in the Rule Condition. If you wish to remove an entry, click the x that precedes it.

• Request Header.

When selected, two additional dropdown menus, a text box, and two check boxes appear.

1. From the Header Name dropdown menu, select user-agent or ref-erer, indicating the type of header to which you would like the Con-dition to apply

2. From the second dropdown menu, select matches or does not match, depending on whether you would like the Condition to match or not match, respectively, the value you enter in the Header Value text box.



3. In the Header Value text box, enter the value on which you would like the Condition to be applied.

Only one entry is allowed here. If you want to match on another header value, you must create another Rule Condition.

4. If desired, select the Case sensitive and/or Wildcard check boxes to indicate those options should apply.

3. If desired, set any desired matches on which to ignore the rule.

If what the rule matched on includes any values in this section, the rule’s action does not execute (Score or Deny).

Note: Not all rules have this parameter available.

a. In the Ignore the rule if it fires on any area, from the Add Match dropdown menu, select the types of Conditions you would like to set for the rule to ignore and configure them:

• Header, Cookie or Parameter Values.

When selected, a Values text box appears.

1. In the Values text box, enter one or more header, cookie, or parame-ter values on which you would like the triggered rule ignored.

Separate multiple entries with a space. If you wish to remove an entry, click the x that precedes it.

• All Header, Cookie or Parameter Names. This Condition allows you to exclude whole selectors (e.g., exclude all cookies or query/POST argu-ments). It is useful if you cannot get an exhaustive list of elements to exclude or if the list is too long. (This Condition cannot be used with the Specific Header, Cookie or Parameter Names Condition.)

When selected, a Select Condition... dropdown menu appears.

1. From the Select Condition... dropdown menu, select the Condition on which you would like the triggered rule ignored.

• Any request header.

• Any cookie.

• Any parameter name or value (POST/URI Query).

2. Repeat for any additional Conditions you would like to apply (up to three).

If you wish to remove a Condition, click the x to its far right.

• Specific Header, Cookie or Parameter Names. This Condition allows you to exclude specific selectors (e.g., a list of cookie names or query/POST arguments). It is useful if you need to exclude a specific list of ele-



ments (e.g., cookie1, cookie2, arg). (This Condition cannot be used with the All Header, Cookie, or Parameter Names Condition.)



• Request header name.

• Cookie name.

• Parameter name (POST/URI Query).

On selection of a Condition, a Name text box appears for it.

2. In the Name text box, enter one or more header, cookie, or parame-ter names, as appropriate.

Separate multiple entries with a space. If you wish to remove an entry, click the x that precedes it.

3. Repeat for any additional conditions you would like to apply (up to three).

If you wish to remove a Condition, click the x to its far right.

• Specific Header, Cookie or Parameter Name Prefix. This Condition allows you to exclude specific selectors with names beginning with a spe-cific pattern (e.g., exclude all cookie, the names of which begin with “mp_”. Be aware, pattern matches only apply to the beginning of a name. Only one condition is permitted for this Condition.


1. From the Select Condition... dropdown menu, select the condition on which you would like the triggered rule ignored.


• Cookie name.


On selection of the Condition, a Name text box appears.

2. In the Name text box, enter a header, cookie, or parameter name prefix, as appropriate. (Only one prefix is permitted.)

If you wish to clear the Condition’s values, click the x to its far right. if you wish to remove the Condition altogether, click it a second time.

• Specific Header, Cookie or Parameter Name & Value. This Condition allows you to exclude a specific selector name/value pair combination



(e.g., ignore the rule if it matched on parameter X when its value was Y). Only one Condition is permitted here.




• Cookie name.


On selection of the Condition, Name and Value text boxes appears.

2. In the Name text box, enter a header, cookie, or parameter name prefix, as appropriate. (Only one name is permitted.)

3. In the Value text box, enter a value. (Only one value is permitted.)

If you wish to clear the Condition, click the x to its far right. if you wish to remove the Condition altogether, click it a second time.

4. Click .

The Application Layer Controls page appears with the Rule Conditions applied as reflected by Yes appearing in the CONDITIONS column.




Appendix A. ModSecurity Core Rule Set Group DefinitionsGroup Description

Protocol Violations Some protocol violations are common in application layer attacks. Validating HTTP requests elim-inates a large number of application layer attacks.

Protocol Anomalies Limiting the size and length of different HTTP protocol attributes, such as the number and length of parameters or the overall length of the request can prevent many attacks, including buffer overflow and injection attacks. This rule set enables the user to set limits on many different attri-butes. Please note, however, that, since such limitations are application- and site-specific, the default rule file must be edited manually to provide these limits.

Request Limits Some common HTTP usage patterns are indicative of attacks but may also be used by nonbrows-ers for legitimate uses.

HTTP Policy Enforces protection for standard Request Methods, Content-Types, File Extensions, etc.

Bad Robots Detects requests by malicious automated programs such as robots, crawlers, and security scan-ners. Malicious automated programs collect information from a web site, consume bandwidth, and might also search for vulnerabilities on the web site. Detecting malicious crawlers is espe-cially useful against comment spam.

Generic Attacks Detects application-level attacks such as those described in the Open Web Application Security Project (OWASP) Top Ten Project (www.owasp.org). This includes attacks such as PHP and

Adobe® ColdFusion® injection attacks. Formerly, in CRS version 1.6.1, this group also included SQL and XSS attacks. Those are now in their own respective groups.

SQL Injection Attacks This group is new to the 2.x CRS and specifically covers SQL Injection attacks.

XSS Attacks This group is new to the 2.x CRS and specifically covers Cross-Site Scripting attacks.

Tight Security Provides rules that screen user-supplied inputs for malicious content or characters that leverage insufficient validation at origin.

Trojans Detection of attempts to access Trojans already installed on the system.

Outbound (Leakage) Prevents application error messages and code snippets from being sent to the user. This makes attacking the server much harder and is also a last line of defense if an attack passes through.


ModSecurity Core Rule Set Group Definitions


Appendix B. Network Layer IP Controls Behaviors

If your Firewall Policy includes Network Layer Controls, it is important to know how entries in the BLOCKED IPS and ALLOWED IPS lists on Luna Control Center’s Network Layer Controls page (see Figure 2-17 on page 27) behave in relation to one another and to your Firewall Policy as a whole.

The following table summarizes behaviors given different entry combinations:

BLOCKED IPS Entry ALLOWED IPS Entry Result

No entry 192.168.0.1 Only 192.168.0.1 is allowed. All other IP addresses are blocked.

This is called a strict whitelist.

192.168.0.1 No entry All IP addresses are allowed except 192.168.0.1

192.168.0.0/24 192.168.0.1 All IP addresses are allowed except those contained in the 192.168.0.0/24 CIDR block. Within the block, IP 192.168.0.1 is allowed.

Adding an IP address to the ALLOWED IPS list that is not within the CIDR block is super-fluous, as that address would have been allowed anyway.

192.168.0.1 192.168.0.1 All IP addresses are allowed.

The presence of address 192.168.0.1 in the ALLOWED IPS list overrides its presence in the BLOCKED IPS list.

192.168.0.1 192.168.0.2 All IP addresses are allowed except 192.168.0.1.

The presence of address 192.168.0.2 in the ALLOWED IPS list is superfluous, as it would have been allowed anyway.


Network Layer IP Controls Behaviors


Appendix C. Real-Time Reporting POST Schema

The Real-Time Reporting (RTR) POST schema is as follows:

• Each line contains a space-separated list of fields

• The first field is always a letter that describes the type of line

• Empty fields are denoted by a hyphen ( - )

• Fields are URL-encoded so as to not include characters that would make the parsing of logs ambiguous

Lines and Fields

Currently, two types of lines are supported:

• v—version number

The first line of each payload is always a “v” line.

• W—firewall policy data

A “W” line is reported for each request that triggers at least one firewall policy rule, even if the rule does not cause the request to be denied (i.e., the rule only generated an alert).

Line FieldsLine Field Notes

v v

1.0 Updated each time the W line format changes.

W Epoch time for the end of the request

Application ID The WAF policy ID you configured in Luna Control Center.

Client IP Ignore the X-Forwarded-For header unless security:fire-wall.debug.honor-xff is enabled in metadata.

Method

ARL

HTTP status code returned to the client

Request ID


Real-Time Reporting POST Schema

An example of RTR reporting values follows, assuming a policy ID of lb01_736.

Fields Added by WAF to W3C and Combined LDS Formats

When WAF logging is enabled in Akamai’s LDS (Log Delivery Service), a new field is appended to either the W3C or Combined lines. The exact format of the “Web Application Firewall Information” field is:

Where:

• <application_id> is the firewall policy ID assigned by you and Akamai in Luna Control Center.

• The rules listed between the “|” symbols and separated by a colon ( : )—a delim-iter—are rules that matched in alert mode.

• The rule after the second “|” symbol matched in deny mode.

For example, the following field shows a Firewall Policy with several matches of rules in alert mode, followed by a deny rule.

Here, the Firewall Policy identified as fw01_1234 triggered rule 960006, then rule 9600015 (both in an alert action) and ended enforcement with rule 960021 triggering a deny action.

Number of triggered rules (1 or more).

Each rule adds six fields to the line.

ID for rule #1

Deny flag for rule #1 0 or 1

Tag for rule #1

Message for rule #1

User data for rule #1

Selector for rule #1

ID for rule #2 ...

Line Field Notes

v 1.0W 1236205695.625 lb01_736 127.0.0.1 GET /L/1/16399/10s/www.example.com/index.html 400 15 1 950012 1

HTTP%20Request%20Smuggling%20Attack. WEB_ATTACK/REQUEST_SMUGGLING - REQUEST_HEADERS:Content-LengthW 1236205695.629 lb01_736 127.0.0.1 GET /L/1/16399/10s/www.example.com/index.html 400 16 1 960016 1 Content-

Length%20HTTP%20header%20is%20not%20numeric PROTOCOL_VIOLATION/INVALID_HREQ - REQUEST_HEADERS:Content-LengthW 1236205695.635 lb01_736 127.0.0.1 GET /L/1/16399/10s/www.example.com/index.html?test_arg=coalesce 200 17 1 950908 0 W

1236205696.749 lb01_736 127.0.0.1 GET /L/1/16399/10s//www.example.com/index.html 400 23 1 960016 1 Content-Length%20HTTP%20header%20is%20not%20numeric PROTOCOL_VIOLATION/INVALID_HREQ - REQUEST_HEADERS:Content-Length

W 1236205696.753 lb01_736 127.0.0.1 GET /L/1/16399/10s//www.example.com/index.html?test_arg=coalesce 200 24 1 950908 0 SQL%20Injection%20Attack WEB_ATTACK/SQL_INJECTION coalesce ARGS:test_arg

<application_id> "|" ((<alert_rule_id> ":" ) * <alert_rule_id>) ? "|" <deny_rule_id>

fw01_1234 | 960006:960015 | 960021


Appendix D. Rule Profiles Comparison

Risk Scoring Comparison

Individual Rule Actions per Profile

*Indicates the setting is not a part of the default Rule Profile. Rather, it is applied as a result of providing a particu-lar answer to a particular question in the Profile’s Advanced Options.

Risk Group Action Standard Intermediate Strict Recommended

SQL Injection Deny 19 14 14 14

Cross Site Scripting (XSS) Deny 9 9 9 9

Command Injection Deny 4 4 4 4

Invalid HTTP Deny 7 7

Remote File Inclusion Deny 4 4 4 4

PHP Injection Deny 4 4 4 4

Trojan Deny 4 4 4

Total Request Score (Inbound) Deny 30 25 20 30

Total Response Score (Outbound) Deny 2 2 2 2

Risk Group Title Standard Intermediate Strict Recommended

950000 Session Fixation Deny Deny

950001 SQL Injection Attack Risk Scoring Risk Scoring Risk Scoring Risk Scoring

950002 System Command Access Risk Scoring Risk Scoring Risk Scoring Risk Scoring


950005 Remote File Access Attempt Deny Deny Deny Deny

950006 System Command Injection Risk Scoring Risk Scoring Risk Scoring Risk Scoring

950007 Blind SQL Injection Attack Risk Scoring Risk Scoring Risk Scoring Risk Scoring

950008 Injection of Undocumented ColdFusion Tags Deny* Deny* Disabled


950010 LDAP Injection Attack Deny* Deny* Disabled

950011 SSI Injection Attack Risk Scoring Risk Scoring

950018 UPDF/XSS Injection Attack Risk Scoring Risk Scoring

950019 Email Injection Attack Deny Deny


Rule Profiles Comparison

950103 Path Traversal Attack Risk Scoring Risk Scoring Risk Scoring Risk Scoring

950107 URL Encoding Abuse Attack Attempt Risk Scoring* Risk Scoring

950108 URL Encoding Abuse Attack Attempt Deny* Risk Scoring* Risk Scoring

950109 Multiple URL Encoding Detected Risk Scoring* Risk Scoring

950110 Backdoor Access Risk Scoring Risk Scoring Risk Scoring Risk Scoring

950116 Unicode Full/Half Width Abuse Attack Attempt

Risk Scoring Risk Scoring

950117 Remote File Inclusion Attack (Remote URL with IP Address)

Risk Scoring Risk Scoring Risk Scoring Risk Scoring

950118 Remote File Inclusion Attack (Common PHP RFI Attacks)


950119 Remote File Inclusion Attack (Remote URL Ending with ‘?’)


950120 Remote File Inclusion Attack (Remote URL Detected)

Risk Scoring Risk Scoring Risk Scoring


950907 System Command Injection


950910 HTTP Response Splitting Attack (Header Injection)

Deny Deny Deny

950911 HTTP Response Splitting Attack (Response Injection

Deny Deny Deny



958000 Cross-Site Scripting (XSS) Attack Risk Scoring Risk Scoring Risk Scoring Risk Scoring





















































958230 Range: Invalid Last Byte Value Deny Deny

958231 Range: Too Many Fields Deny Deny

958291 Range: Field Exists and Begins With 0 Risk Scoring* Risk Scoring

958295 Multiple/Conflicting Connection Header Data Found

Risk Scoring* Risk Scoring





















958976 PHP Injection Attack (Common Functions) Risk Scoring Risk Scoring Risk Scoring Risk Scoring

958977 PHP Injection Attack (Configuration Over-ride)








959073 SQL Injection Attack Risk Scoring Risk Scoring

959151 PHP Injection Attack (Opening Tag) Risk Scoring Risk Scoring Risk Scoring Risk Scoring

960012 POST Request Missing Content-Length Header


960016 Content-Length HTTP header is not numeric Deny Deny Deny Deny

960020 Pragma Header Requires Cache-Control Header for HTTP/1.1 Requests


960022 Expect Header Not Allowed for HTTP 1.0 Risk Scoring* Risk Scoring

960034 HTTP Protocol Version Is Not Allowed By Pol-icy


960035 URL file extension is restricted by policy Risk Scoring Deny Deny Different

960901 Invalid character in request Risk Scoring Risk Scoring

960902 Invalid Use of Identity Encoding Risk Scoring* Risk Scoring

960904 Request Containing Content, but Missing Content-Type Header


960912 Failed to parse request body Risk Scoring Risk Scoring Risk Scoring Risk Scoring

970003 SQL Information Leakage Risk Scoring* Risk Scoring* Risk Scoring* Disabled

970004 IIS Information Leakage Risk Scoring* Risk Scoring* Risk Scoring* Disabled

970007 Zope Corporation Zope® Information Leak-age

Risk Scoring* Risk Scoring* Risk Scoring* Disabled

970008 Cold Fusion Information Leakage Risk Scoring* Risk Scoring* Risk Scoring* Disabled

970009 PHP Information Leakage Risk Scoring* Risk Scoring* Risk Scoring* Disabled

970010 Microsoft® ISA Server Existence Revealed Risk Scoring* Risk Scoring* Disabled

970013 Directory Listing Risk Scoring* Risk Scoring* Risk Scoring* Disabled

970014 ASP/JSP Source Code Leakage Risk Scoring* Risk Scoring* Disabled

970015 PHP Source Code Leakage Risk Scoring* Risk Scoring* Disabled

970016 ColdFusion Source Code Leakage Risk Scoring* Risk Scoring* Disabled

970021 Oracle WebLogic® information Disclosure Risk Scoring* Risk Scoring* Risk Scoring* Disabled

970118 Application Is Not Available (Server-Side Exceptions)

Risk Scoring* Risk Scoring* Risk Scoring* Disabled

970901 The Application Is Not Available (HTTP 5XX) Risk Scoring* Risk Scoring* Risk Scoring* Disabled

970902 PHP Source Code Leakage Risk Scoring* Risk Scoring* Disabled

970903 ASP/JSP Source Code Leakage Risk Scoring* Disabled

970904 ISS Information Leakage Risk Scoring* Risk Scoring* Risk Scoring* Disabled




973300 Possible XSS Attack Detected - HTML Tag Handler


973301 XSS Attack Detected Risk Scoring Risk Scoring Risk Scoring Risk Scoring














973315 IE XSS Filters - Attack Detected Risk Scoring Risk Scoring Risk Scoring Risk Scoring
























973336 XSS Filter - Category 1: Script Tag Vector Risk Scoring Risk Scoring Risk Scoring

973337 XSS Filter - Category 2: Event Handler Vector Risk Scoring Risk Scoring Risk Scoring

981000 Potentially Malicious iFrame Tag Detected in Output

Risk Scoring* Disabled

981001 Potentially Malicious iFrame Tag Detected in Output


981003 Malicious iFrame+JavaScript Tag in Output Risk Scoring* Disabled

981004 Potentially Obfuscated JavaScript in Output (fromCharCode)


981005 Potentially Obfuscated JavaScript in Output - eval() and unescape()


981006 Potentially Obfuscated JavaScript in Output - unescape()


981007 Potentially Obfuscated JavaScript in Output - Heap Spray


981173 Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded


981241 Conditional SQL Injection Attempts Risk Scoring Risk Scoring Risk Scoring Risk Scoring

981242 Classic SQL Injection Probes 1/2 Risk Scoring Risk Scoring Risk Scoring Risk Scoring

981243 Classic SQL Injection Probes 2/2 Risk Scoring Risk Scoring Risk Scoring Risk Scoring

981244 Basic SQL Authentication Bypass Attempts 1/3






981247 Concatenated Basic SQL Injection and SQLLFI Attempts


981248 Chained SQL Injection Attempts 1/2 Risk Scoring Risk Scoring Risk Scoring Risk Scoring

981249 Chained SQL Injection Attempts 2/2 Risk Scoring Risk Scoring Risk Scoring Risk Scoring

981250 SQL Benchmark and sleep() Injection Attempts Including Conditional Queries


981251 MySQL UDF Injection and Other Data/Struc-ture Manipulation Attempts





981252 MySQL Charset Switch and MSSQL DoS Attempts


981253 MySQL and PostgreSQL Stored Procedure/Function Injections


981254 Postgres pg_sleep() Injection, WAITFORDE-LAY Attacks and Database Shutdown Attempts


981255 MSSQL Code Execution and Information Gathering Attempts


981256 MATCH AGAINST, MERGE, EXECUTE IMME-DIATE, and HAVING Injections


981260 SQL Hex Encoding Identified Risk Scoring Risk Scoring Risk Scoring Risk Scoring

981270 Basic MongoDB® MongoDB® SQL Injection Attempts


981272 Blind SQLI Tests Using sleep() or benchmark() Risk Scoring Risk Scoring Risk Scoring Risk Scoring

981276 Basic SQL Injection - Common Attack Pay-loads


981277 Integer Overflow Attacks (Taken from Skip-fish)

Risk Scoring Risk Scoring

981300 SQL SELECT Statement Anomaly Detection Alert


981318 SQL Injection Attack: Common Injection Testing Detected


981319 SQL Injection Attack: SQL Operator Detected Risk Scoring Risk Scoring Risk Scoring Risk Scoring

981320 SQL Injection Attack: Common DB Names Detected


990002 Request Indicates a Security Scanner Scanned the Site

Deny Deny Deny Deny

990012 Rogue Web Site Crawler Deny Deny Deny


Deny Deny Deny Deny


Deny Deny Deny Deny

3000000 SQL Injection Bypass/Probing Risk Scoring Risk Scoring Risk Scoring Risk Scoring

3000001 HTTP Response Splitting (Header Injection Attempt)

Deny Deny Deny Deny

3000002 Local System File Access Attempt Risk Scoring Risk Scoring Risk Scoring Risk Scoring

3000003 PHP Code Injection Risk Scoring Risk Scoring Risk Scoring Risk Scoring

3000004 PHP Remote File Include Risk Scoring Risk Scoring Risk Scoring Deny




3000005 System Command Injection (The Open

Group’s UNIX® operating system)


3000006 SQL Injection (String Termination and Com-ment Sequence)

Risk Scoring Risk Scoring Deny Deny

3000007 System Command Injection (UNIX File Leak-age)


3000008 Pandora / Dirt Jumper DDoS Detection - HTTP GET Attacks

Deny* Deny* Deny

3000009 Ruby on Rails® YAML Injection Attack Deny* Deny* Disabled

3000010 LOIC 1.1 DoS Detection Deny* Deny* Deny

3000011 HULK DoS Attack Tool Detection Deny* Deny* Deny

3000012 The Apache Software Foundation Apache Struts™ Remote Command Execution (OGNL Injection)

Deny* Deny* Deny

3000013 System Command Injection Risk Scoring Risk Scoring Risk Scoring Risk Scoring

3000014 Apache Struts Remote Command Execution (OGNL Injection)

Deny* Deny* Deny

3000015 Detects SQL Injections that Use Time Delays Risk Scoring Risk Scoring Risk Scoring Risk Scoring

3000016 PHP Code Injection Using Data Stream Wrapper


3000017 MySQL Keywords Anomaly Detection Score Risk Scoring Risk Scoring Risk Scoring Risk Scoring

3000018 Dirt Jumper DDoS Detection - HTTP POST Attacks

Deny* Deny* Deny

3000019 Pandora DDoS Detection - HTTP POST Attacks

Deny* Deny* Deny

3000020 Local File Inclusion (and Command Injection) Using '/proc/self/environ'


3000021 Detect Attempts to Access the Automattic,

Inc. WordPress® Pingback API

Deny* Deny* Disabled

3000022 SQL Injection (DROP Statement) Risk Scoring Risk Scoring Risk Scoring Risk Scoring





Documents

AkamaiWAF_UserGuide