f5 Asm Operations Guide

BIG-IP Application Security Manager
Operations Guide
A Web Application Firewall that

Guards Your Critical Apps
With BIG-IP ASM, organizations gain the
flexibility they need to deploy Web Application
Firewall services close to apps to protect them
wherever they residewithin a virtual softwaredefined data center, managed cloud service
environment, public cloud, or traditional data
center.
A message from Julian Eames,

Chief Operations Officer and Executive Vice President,
F5 Business Operations
Welcome to the F5 Operations Guide series.
Our series of operations guides address real-world scenarios and challenges. The content
was written by the engineers who design, build, and support our products, as well as other
F5 professionalssome former customers worked in the field and have firsthand experience.
While no document can anticipate every question or situation, F5 endeavors to provide a
better understanding of your BIG-IP system and offer tools needed to address common
issues and conditions.
In this guide youll find recommendations, practices, and troubleshooting tips to keep your F5
products running at peak efficiency and elements that may be incorporated into your own run
books.
F5 is pleased to offer industry-leading products and services, including world-class support,
and welcomes your suggestions and feedback. Let us know how we can better serve you.
Julian Eames
ii
Contents
Acknowledgments 1
About this guide
Before using this guide
Common terms and concepts
Limits of this guide
Glossary 5
Customization 5
Issue escalation
Feedback and notifications
Document conventions
Change list
Introduction 8
Web application firewall protection
BIG-IP ASM security policy life cycle
Policy tuning details
10
Additional security checks
11
Tips and guidelines
11
Deployment Examples
15
Protect multiple applications using Automatic Policy Builder with a QA environment
16
Protect multiple applications using Automatic Policy Builder, no QA environment
22
Protect multiple applications with generic policy using manual learning
28
Protect multiple applications with the Rapid Deployment and manual learning
35
Protect applications with policy automatically built in non-production environment
42
Protect an application from DoS/DDoS attacks
50
Protect an application from web robots
54
Protect an application using WhiteHat Sentinel with the BIG-IP ASM system
60
BIG-IP ASM API/Web Services Protection
67
Web API Use Cases
67
Web services
68
RESTful API services
68
iii
Validation 78
BIG-IP ASM Event Logging
80
Log display formats
80
Remote logging
82
Policy Tuning and Enhancement
85
BIG-IP ASM 12.0 Policy Builder updates
85
Traffic Learning
85
Configuration guidelines
87
Manual learning and policy building
90
Tuning violations
92
Attack signature tuning
94
Transition enforcement mode from Transparent to Blocking
95
Session tracking and login pages
97
Compare and merge policies
Regulatory Compliance
100
103
Regulatory compliance of WAFs
103
Open Web Application Security Project Top 10
104
Payment Card Industry Data Security Standard 3.1
105
Health Information Portability and Accountability Act
107
National Institute of Standards and Technology
109
Common Deployment Topologies
112
Platforms and licenses
112
Common topology options
115
Common Management Tasks
123
Guidelines 123
Update geolocation
124
Maintain IP intelligence database
125
Back up your BIG-IP configuration information
127
Troubleshoot BIG-IP ASM
130
Use platform logs
130
Check BIG-IP ASM system health
131
iv
Bypass BIG-IP ASM
132
Handle unexpected HTTP responses
133
Monitor performance
137
Monitor CPU usage
140
Troubleshoot memory usage
142
Optimize the support experience
145
F5 technical support offerings
145
Professional services
145
GUARDIAN Professional Services Partners
146
F5 certification
146
Review self-help options
147
F5 Global Training Services
150
Engage Support
151
Send information to Support
156
Collect BIG-IP ASM data
157
Appendix 163
Considerations 163
Integrated BIG-IP APM session tracking and event logging
163
Use multiple decoding passes with evasion technique
163
BIG-IP ASM terminology
166
Resource Materials
173
Legal Notices
Publication date
175
175
Copyright 175
Trademarks 175
Patents 176
Notice 176
ACKNOWLEDGMENTS
Acknowledgments
Executive sponsor: Julian Eames, Executive Vice President and Chief Operations Officer
Publisher and project manager: Jeanne Lewis
Content and production editor: Andy Koopmans
Project team, writers, editors, and testers: Aaron Brailsford, Ido Breger, Celeste Crocker, Jack Fenimore, Ismael Goncalves,
Chad Jenison, QiHua Jiang, Josh Michaels, Lior Moscovici, Sven Mueller, Erik Novak, David Remington, Lior Rotkovitch, Ziv
Saar, Peter Scheffler, Justin Shattuck, Tzoori Tamam, and Frank Thias
BookSprints facilitator, designer, editor, and support team: Barbara Rhling, Henrik van Leeuwen, Julien Taquet, Raewyn
Whyte, and Juan Gutirrez. For information about the BookSprints process, see the Booksprints web site. (This link takes you to
an outside resource.)
Content, support, and assistance: Don Martin, Vice President, Global Services Strategic Programs; the Global Services New
Product Introduction Team, Bryan Gomes, Ilana Trager, Phillip Esparza, Derek Smithwick, Beth Naczkowski, Joe Taylor, Mark
Kramer, Andrew Pemble, Dave Bowman, Jim Williams, David Katz; and the rest of the Global Services management team.
Thanks also to the BIG-IP ASM product development team, Orit Hakim, Galit Khon, and Amatzia Yifhar; and thanks to Jill Devine
and Anjuli Lam for copy-editing assistance.
ABOUT THIS GUIDE

About this guide

This guide includes recommended maintenance, tuning, and monitoring procedures related to F5 BIG-IP Application Security
Manager versions 11.612.0.
The goal of this guide is to assist customers with keeping their BIG-IP system healthy, optimized, and performing as designed. It
was written by F5 engineers who assist customers with solving complex problems every day. Some of these engineers were
customers before joining F5. Their unique perspective and hands-on experience has been used to serve the operational and
maintenance guides F5 customers have requested.
This guide describes common information technology procedures and some that are exclusive to BIG-IP systems. There may be
procedures particular to your industry or business that are not identified. While F5 recommends the procedures outlined in this
guide, they are intended to supplement your existing operations requirements and industry standards. F5 suggests that you read
and consider the information provided to find the procedures to suit your implementation, change-management process, and
business-operations requirements. Doing so can result in higher productivity and fewer unscheduled interruptions.
See Feedback and notifications , for information on how to help improve future versions of this guide.
Before using this guide

You will get the most out in this guide if you have already completed the following items, as appropriate to your implementation:
Installed your F5 platform according to its requirements and recommendations. Search the AskF5 Knowledge Base
(support.f5.com) for platform guide to find the appropriate guide.

Followed the general environmental guidelines in the hardware platform guide to make sure of proper placement, airflow,
and cooling.
Set recommended operating thresholds for your industry, accounting for predictable changes in load. For assistance, you
can contact F5 Consulting Services.
Familiarized yourself with F5 technology concepts and reviewed and applied appropriate recommendations from the F5
BIG-IP TMOS: Operations Guide.

This guide also assumes that you have some familiarity with various L7 HTTP concepts, such as URI/URL, method, header,
cookie, status code, request, response, and parameters.
ABOUT THIS GUIDE

HTTP request components

Request syntax:
https://www.testsite.com/folder/page.
html?parameter1=value1&parameter2=value2
Table 0.1 HTTP request components
Components
Request syntax
Protocol
https
Host
www.testsite.com
Path
/folder/page.html (in the BIG-IP ASM system referred to as the URL)
Query string
parameter1=value1&parameter2=value2
Parameters
parameter1, parameter2
Parameter Values
value1, value2
Table 0.2 Additional HTTP request components important to the BIG-IP ASM system
Component
Request syntax
POST
/login.php HTTP/1.1
Referer
http://www.testsite.com/index.php
User-Agent
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; MS-RTC LM 8)
Content-Type
application/x-www-form-urlencoded
Accept-Encoding
gzip, deflate
Host
www.testsite.com
Connection
Keep-Alive
Content-Length
48
Cookie
SESSION=9899474fd85b473ca496d16b363ec3b8
Method
POST
ABOUT THIS GUIDE

Component
Request syntax
Header
Referrer, Accept-Language, User-Agent, Cookie
Cookie
SESSION
POST Query String/

Request Body

This guide does not address installation, setup, or initial configuration of your BIG-IP system or modules.
There is a wealth of documentation covering these areas in the AskF5 Knowledge Base (support.f5.com). The F5 self-help
community, DevCentral, is also a good place to find answers about initial deployment and configuration. You can find additional
resources detailed in Acknowledgments . The following figure shows where this guide can best be applied in the product life
cycle.
Figure 0.1 F5 documentation coverage
ABOUT THIS GUIDE

Glossary
The F5 Glossary page (f5.com/glossary) offers an up-to-date and complete listing and explanation of common industry and
F5-specific terms. For terms specific to BIG-IP ASM, see BIG-IP ASM terminology.
Customization
Customization may benefit your implementation. You can get help with customization from a subject matter expert, such as a
professional services consultant from F5 Consulting Services.
Issue escalation
See Optimize the support experience for issue escalation information.
If you have an F5 WebSupport contract, you can open a support case by clicking Open a support case on the AskF5
Knowledge Base (support.f5.com).
Feedback and notifications

F5 welcomes feedback and requests. You are invited to fill out and submit the surveys at the end of each chapter in the
interactive PDF version of this guide or to visit our F5 Operations Guide User Feedback survey. (This link sends you to an external
site.)
F5 operations guides are updated frequently, and new guides are being written. If you would like to be notified when new content
is available, email opsguide@f5.com and your name will be added to our distribution list for updates and new releases.
To help you easily identify and understand important information, the document in this guide uses the stylistic conventions
described here.
Examples
All examples in this document use only private IP addresses. When you set up the configurations described, you will need to use
valid IP addresses suitable to your own network in place of our sample addresses.
References to objects, names, and commands
We apply bold text to a variety of items to help you easily pick them out of a block of text. These items include interface labels, file
names, specific web addresses, directories, and IP addresses.
Configuration utility
The BIG-IP Configuration utility is the name of the graphic user interface (GUI) of the BIG-IP system and its modules. It is a
browser-based application you can use to install, configure, and monitor your BIG-IP system.
Configuration utility menus, sub-menus, links, and buttons are formatted in bold text. For more information about the
ABOUT THIS GUIDE

Configuration utility, see Introducing BIG-IP Systems in BIG-IP Systems: Getting Started Guide.
Command line syntax

We show command line input and output in Courier font.
The corresponding # prompt is not included. For example, the following command shows the configuration of the specified pool
name:
tmsh show /ltm pool my _ pool

The following table explains additional special conventions used in command line syntax:
Table 0.3 Command-line syntax conventions
Character
Description
<>
Identifies a user-defined variable parameter. For

example, if the command has <your name>, type in
your name but do not include the brackets.
[]
Indicates that syntax inside the brackets is optional.
Indicates that you can type a series of items.
TMOS shell syntax

The BIG-IP system includes a tool known as the TMOS shell (TMSH) utility that you can use to configure and manage the system
at the command line. Using the TMSH utility, you can configure system features and set up network elements. You can also
configure the BIG- IP system to manage local and global traffic that is passing through the system, and view statistics and system
performance data.
You can run the TMSH utility and issue commands in the following ways:
You can issue a single TMSH command at the BIG-IP system prompt using the following syntax:
tmsh [command] [module . . . module] [component] (options)

You can open the TMSH utility by typing tmsh at the BIG-IP system prompt:
(tmsh)#
Once at the TMSH utility prompt, you can issue the same command syntax, leaving off tmsh at the beginning.
For the sake of brevity, all TMSH utility commands provided in this guide appear in the format listed in the first bullet.
You can use the command line utilities directly on the BIG-IP system console, or you can run commands using a remote shell,
such as the SSH client or a Telnet client. For more information about command line utilities, see Bigpipe Utility Reference Guide
or the Traffic Management Shell (tmsh) Reference Guide.
6
ABOUT THIS GUIDE

Change list
Note Examples are shown in UTF8 language encoding. If you are using one
of the other language encoding character sets supported by the BIG-IP ASM
system, adapt examples as needed. For more information, see the AskF5
article SOL6335: Overview of encoding language settings for ASM.
Change list
Date
June 2016
July 2016
Chapter/Section
Change
Reason
Deployment Examples
Added chapter
New content
BIG-IP ASM Event

Logging
Added note regarding

support for multiple
remote logging profiles.
12.1 update
INTRODUCTION
Introduction
BIG-IP Application Security Manager (ASM) enables organizations to protect against the Open Web Application Security
(OWASP) Top 10 threats, application vulnerabilities, and zero-day attacks. Leading layer-7 (L7) DDoS defenses, detection and
mitigation techniques, virtual patching, and granular attack visibility work to thwart sophisticated threats before they reach your
servers.
The BIG-IP ASM system allows compliance with key regulatory standards such as Health Insurance Portability and Accountability
Act (HIPAA) and Payment Card Industry Data Security Standard (PCI DSS).
With the BIG-IP ASM system, organizations gain the flexibility they need to deploy web application firewall (WAF) services for
protecting applications wherever they residewithin a virtual software-defined data center (SDDC), managed cloud service
environment, public cloud, or traditional data center.

The BIG-IP ASM system is a WAF. In contrast to a network-layer firewall, which restricts access based on source and destination
IP addresses, IP protocols, and TCP/UDP port numbers, a WAF manages traffic based on L7 properties, such as HTTP headers,
URIs, parameters, and other web application elements.
WAFs also detect anomalous behaviors from clients attempting to access applications, mitigating the potential impact of
automated agents, bots, scanners, and brute-force attacks.
Web applications typically use a two- or three-tier model, in which the web server acts as the presentation layer for the
application. The web server receives input from the user and displays outputs, while sending transactions to either an application
tier or directly to a back-end database.
In these models, some actions performed on the web application could potentially reach the back-end database, meaning a
malicious client can gain unauthorized access to data even if the database servers themselves are not directly accessible to the
users.
Benefits of WAF protection

WAFs prevent such access to protect not only the web server, but the application infrastructure as a whole. WAFs are widely
used in both Internet-facing applications and internal applications. While most organizations use WAFs in combination with other
measures, such as secure coding practices, vulnerability assessments, and software patching and updating, even the most
secure application can benefit from WAFs because WAFs do the following:
Disallow incoming traffic from finding and targeting known vulnerabilities in web applications.
Allow a quicker and easier way to fix vulnerabilities, as revealed in web applications by scanners and penetration tests.
Detect and mitigate malicious bot access to applications.
INTRODUCTION
Prevent malicious clients from abusing web applications by exploiting flaws in business logic or the application
infrastructure.
Provide effective mitigation much faster than patching application code.
Reduce the likelihood of an unknown or undiscovered vulnerability being exploited.
Provide an additional point of control to minimize the risk of developer or administrative error.
Provide visibility into what types of attacks and scans are targeting the application.
Prevent malicious and unwanted traffic from consuming server resources.
Provide a forensic record and event correlation for triaging after a suspected security incident.
Provide behavioral mitigations, such as web scraping and bot detection, that are very difficult to implement in each
application.
Provide a consistent security posture across all of an organization's applications.
Note F5 recommends that you fix known vulnerabilities in applications when
possible.

A BIG-IP ASM security policy consists of multiple parts and layers, all serving the purpose of securing a web application. Some
elements of a BIG-IP ASM policy protect your application from specific attacks, while other elements protect against more broad
attacks.
Before you deploy an application security policy, it helps to have an understanding of exactly what you are trying to protect and
why. Defining your security problem before you start will make it easier to develop and enforce a security policy. Some use cases
require more extensive policy development and tuning, while with other use cases, a simple security policy will suffice.
The application security policy life cycle has three phases: policy deployment, policy tuning, and policy maintenance.
Phase 1: Create and deploy policy

Create a new policy using the template and policy-building mode most appropriate for your web application. Decide whether to
automate the policy building process. You can change most decisions made during this phase in later phases, but it is best to
start with the most appropriate deployment scenario.
Phase 2: Tune policy

False positive violations are identified and policy settings are adjusted to allow legitimate traffic to pass through to the protected
INTRODUCTION
application. This is necessary as some legitimate traffic may not pass set policy rules and may resemble an attack. Over time, the
security policy will become more strict, meaning that policy components that have not triggered any violations are enforced, and
acceptance occurs for elements specific to your application, such as file types, parameters, and HTTP methods.
Phase 3: Maintain policy

The security policy adapts to application changes, new security requirements, attack signature updates, and activities, prompted
by the review of logs and reports on traffic inspected by the BIG-IP ASM system. During this phase, keep the policy up-to-date
and accurate for the application it protects.
A good, finely-tuned security policy deployed according to the security requirements of your application should incur minimal
operational costs. A very strict and application-specific security policy can potentially take more time and effort to maintain,
especially in light of application changes. A generic, lightweight policy requires very little maintenance, even when applied to
multiple or different applications.

Of the three phases, policy tuning requires the most attention and skill from an administrator. Administrators can choose to
manually tune a security policy or have the BIG-IP ASM system tune the policy automatically.
Tasks included in tuning include adjusting policy blocking settings, populating entry lists, and enforcing entities and attack
signatures.
Adjust policy blocking settings

Depending on the policy's initial settings, the BIG-IP ASM system may need to disable specific violations if they block legitimate
requests. Conversely, the BIG-IP ASM system will enforce/enable violation mitigation rules as more traffic passes the policy
without triggering an alarm.
At the end of the tuning process, the policy should contain all the relevant violations. This will be true whether you started with a
fully enforced list and tuned it down ("tightened"), or you started with a blank list and enforced violations over time ("loosened").
Modular or gradual blocking

One of the most successful approaches to tuning a BIG-IP ASM policy involves modular blocking, also known as gradual
blocking. Gradual blocking allows some violations to be blocked while others are being tuned. This means you can enable policy
components with little-to-no tuning, before the tuning process begins.
Populate entity lists

In an HTTP request, all entities are L7. A BIG-IP ASM policy can contain a whitelist of these entities and disallow entities not on
that list, it can contain a blacklist of entities to disallow, including wildcards or matching generic patterns.
A BIG-IP ASM policy usually starts with catch-all wildcards (*) for the entity lists (file types, parameters, URIs, cookies, headers,
and entities.). Depending on the deployment settings, the BIG-IP ASM system will suggest specific entities to populate the lists.
10
INTRODUCTION
Tips and guidelines
Once the lists are populated, wildcards can be removed and the list enforced. Not all entity types are relevant to all security and
application requirements, so F5 recommends tuning to include only those that are important to you.
Enforce entities and attack signatures

Most policy entities have attributes in them, such as byte lengths, values, characters, and others. You can configure a security
policy to enforce those attributes.
The tuning phase for each entity is marked with a Staging flag, meaning the entity's attributes are only checked, not enforced.
Once all attributes are manually or automatically adjusted to fit legitimate application use, the staging flag can be manually or
automatically removed.
Attack signatures behave the same way. All signatures in a policy start in staging. This means that traffic will not be blocked if it
matches that signature.
Once you disable the signatures causing false positives, you can turn off staging and enforce the rest of the signatures.
Additional security checks

The BIG-IP ASM system can deploy additional security checks in order to protect the application. This is true even for malicious
traffic that does not match disallowed policy elements or attack signatures. These checks include session tracking, web
scraping, brute force protection, and denial-of-service (DoS) protection.
Session tracking includes the ability to track users and sessions according to their activities in the application, blocking them
completely, or logging their requests, whether legitimate or malicious.
Web scraping detects non-human behaviors on the website, flagging, and blocking bots with malicious intents, even if all they do
is access legitimate resources on the website.
DoS protection guards the application from heavy traffic patterns and rates that are meant to bring down the application or
database, even when each request appears to be in order and does not trigger any of the violations in the policy.
Tips and guidelines

Due to the number of available features and capabilities of the BIG-IP ASM system, administrators may feel overwhelmed. F5
recommends that you keep the following tips and guidelines in mind:
Do not allow the path to implementation to become blocked by a desire to instantly build a perfectly secure and tuned
environment. Allow for a learning curve and build your security policy to support the needs of your application and
organization.
Do not feel like you must use a feature simply because it exists.
It is better to see bad traffic than to not see it.
11
INTRODUCTION
Tips and guidelines
When zero day hits, it is better to be in blocking mode with a current policy than to have to build a new policy from scratch.
Sometimes providing basic protections for many applications is just as important as providing detailed protection for one.
The BIG-IP ASM Policy Builder creates an effective security policy and can save you a lot of time.
The BIG-IP ASM system is designed to learn while in production. If you do not have a robust QA environment, your
application users may supply the best source of legitimate traffic from which the BIG-IP system can learn.
The BIG-IP ASM system has multiple, layered protections for each attack vector. Do not over-invest time or resources on
particular mitigations.
Start with a policy that loosens security restrictions to allow all legitimate behavior and disallow malicious requests.
Tighten security restrictions over time to incrementally improve protections.
Figure 0.2 Policy adjustment over time
12
INTRODUCTION
Tips and guidelines
Note BIG-IP ASM security policies exists in either blocking mode or

transparent mode. There is no learning mode to deploy. The BIG-IP ASM
system learns the elements of your application as part of an ongoing
process.
13
Help improve this guide

Please help F5 improve this guide by responding to a few questions about this chapter.
(Note: You must be viewing this document in Adobe Acrobat Reader or similar to use this form.)
Did this chapter answer all of your questions about the subject matter?
Yes
No
If not, what information should be included that is not?

Did you find any errors pertaining to subject matter in this chapter?
Yes
No
If yes, please describe the error:

If yes, please copy and paste the paragraph containing the error here:
Did you find non-subject-matter errors in this chapter (spelling, etc.)?
Yes
No

Send
DEPLOYMENT EXAMPLES
Tips and guidelines
Deployment Examples
The following examples describe several common deployment scenarios to help guide you in configuring and tuning your BIG-IP
ASM security policy to meet the needs of similar deployments in your organization.
Important These examples are meant as learning guides only. Your
deployment, procedures, and operational needs may vary.
Each deployment example includes the following:

A description of the problem or situation the example addresses.
Background notes, where appropriate.
A list of requirements or assumptions, where appropriate.
A list of goals to be achieved by the BIG-IP ASM security policy.
A recommended approach listing configuration and tuning advisements for BIG-IP ASM features.
15
DEPLOYMENT EXAMPLES
Protect multiple applications using Automatic Policy Builder with a QA

environment
Description
You need a security policy to quickly protect multiple applications from common web application attacks. You also need the
policy to be easy to administer and to cause few false positives.
You have a Quality Assurance (QA) environment in which to build and test your security policy before moving it into production.
Goals
The security policy will achieve the following goals:
Protect multiple applications from the most common attacks.
Cause a minimum number of false positives.
Be easy to build and administer.
Be complete (ready to enforce) within 7 days.
Recommended approach
Use the Automatic Policy Builder to create a fundamental policy type, which can protect multiple applications currently in
production. Test the policy with your QA environment and then move it into your production environment when the policy is ready.
To use this approach, complete the following steps:
1. Set up a virtual server.
2. Gather information about your applications.
3. Set up your security policy using the Deployment wizard.
4. Browse applications from a trusted IP.
5. Monitor traffic.
6. Review event logs and reports.
7. Review elements added to policy.
8. Export your policy.
9. Import and validate your policy.
16
DEPLOYMENT EXAMPLES
Set up a virtual server

Set up a BIG-IP LTM virtual server with an HTTP profile assigned and a logging profile set to Log Illegal Requests.
Gather information about your applications

Find out the encoding language of your applications (UTF, for example).
Find out whether your applications are case sensitive.
Find out whether your applications use HTTP or HTTPS. If they use both, you will need to configure a virtual server for
each protocol.
Find out your applications back-end platform and database type. Youll use these to assign attack signatures.
Make sure that you need fewer than 7 days for signature staging.
Find out how many entities (file types, parameters, URLS, and cookies) your applications have.
Estimate the size of your applications. If your applications are large, F5 recommends using a slower policy-building
method.
Make sure you have trusted IP addresses in your QA environment from which you can send legitimate traffic to BIG-IP
ASM. This will speed up the policy building process. If you dont have a QA environment, see Protect multiple applications
using Automatic Policy Builder with a QA environment.
Set up your security policy using the Deployment wizard

Use the Deployment wizard to build your policy with information you gathered in the previous part.
To setup your security policy using the Deployment wizard in the Configuration utility
1. Go to Security >> Application Security: Security Polices and click Create.
The Select Local Traffic Deployment Scenario screen displays.
2. Select Existing Virtual Server and click Next.
Configure Local Traffic Settings screen displays.
3. Select the appropriate protocol type for your applications.
4. Select your QA virtual server from the HTTP Virtual Server menu and click Next.
5. Select Create a security policy automatically (recommended) and click Next.
The Configure Security Policy Properties screen opens.
6. Type a name for the policy.
17
DEPLOYMENT EXAMPLES
From the Application Language list, select the language encoding of your applications or use Auto detect and let the system
detect the language.
Important You cannot change this setting after you have created the security
policy.
7. For Security Policy is case sensitive, as appropriate for your applications, leave at the default selection
(Enabled) to retain case sensitivity or clear the checkbox to disable it.
policy.
8. For Differentiate between HTTP and HTTPS URLs, as appropriate for your applications, leave at the
default selection (Enabled) or clear the checkbox to disable this option, and click Next.
9. The Configure Attack Signatures screen displays.
10. Choose appropriate attack signatures sets from the Available Systems area as appropriate for your
applications criteria and add use the arrow keys to move them to the Assigned Systems area.
11. Leave Signature Staging Enabled, and click Next.
The Configure Automatic Policy Building screen displays.
12. Leave Policy Type and Policy Builder Learning Speed at their default values (Fundamental and
Medium).
13. For Trusted IP Addresses, enter the URLs youll use in your QA environment to test the policy, and then click
Next.
The Security Policy Configuration Summary screen displays.
14. Review the summary. If all information is correct, click Finish.
Browse applications from a trusted IP

In your QA environment, browse your applications using the trusted IP addresses you entered in the last part.
Because you are using trusted IP addresses, BIG-IP ASM automatically adds all entities to the policy on their first occurrence.
Learning suggestions are not generated from trusted traffic.
Valid traffic from your trusted IP addresses should not contain any illegal requests. Ensure your QA testers or automated tools
examine the application. Any violations caused by valid traffic are false positives and should be disabled.
Make sure that QA testers or automated tools browse the web site, clicking on all options including login pages, help pages, and
dynamic pages. The more thoroughly your test traffic interacts with the applications, the more effective the policy will be.
18
DEPLOYMENT EXAMPLES
Browsing the application from a trusted source (IP) helps ASM to build the policy faster. If you configured a trusted IP address
you can start sending traffic.
To add trusted IP addresses using the Configuration utility
1. Go to Security >> Application Security : Policy Building : Learning and Blocking Settings.
2. In the Policy Building Process area, expand Trusted IP Addresses and enter them.
3. Click Save.
4. Click Apply Policy.
When you use trusted IP addresses, BIG-IP ASM automatically adds all entities to the policy on their first occurrence. Learning
suggestions are not generated from trusted traffic.
Valid traffic from your trusted IP addresses should not contain any illegal requests. Any violations caused by valid traffic are false
positives and should be disabled.
Monitor traffic
Pass traffic through your virtual server. This can be untrusted traffic from the internet or trusted traffic from trusted IPs youve
defined. Review learning suggestions.
To manually review learning suggestions using the Configuration utility
1. Go to Security >> Application Security : Policy Building : Traffic Learning and review the requests that
caused learning suggestions.
Each learning suggestion has a learning score based on 0-100 percent scale. When a suggestion reaches 100
percent, it is accepted into the policy automatically by BIG-IP ASM.
2. Click on the magnifying glass and then click the Advanced Filter tab.
3. Under Status choose Accepted / Accepted.
A list of accepted learning suggestions is displayed.
4. Review learning suggestions.

Any learning suggestion on the traffic learning screen can be accepted, deleted, or ignored.
Requests that have a score of less than a 100% will either need more time or you can accept them manually.
Each learning suggestion has additional information that helps you decide whether or not it is a false positive
and a fine tuning of policy is needed or if it is an attack that should be blocked.
19
DEPLOYMENT EXAMPLES
Any manually accepted suggestions will be enforced when the policy is moved to blocking mode.
If you are unsure whether or not a violation is a false positive, retain the learning suggestion until more
information becomes available.
Review event logs and reports

To review event logs and reports using the Configuration utility
1. Go to Security >> Events Logs : Application : Requests. Verify logged requests are present. If your
settings are set to default for illegal requests, only requests flagged as illegal should appear.
Some requests may be flagged as staging. This indicates that they will not be blocked when you switch the
enforcement mode to blocking.
2. Go to Security >> Reporting : Application : Charts and review Request per policy statistics.
Use the Advanced filter to view information about your security policy, such as Top URLs, Top Violation in the
last day, and others.
3. Go to Security >> Application Security : File Type and review the list of file types added to the policy. Do
this also for Parameters.
Review elements added to policy

To view elements added to the policy from the trusted IP addresses using the Configuration utility
1. Go to Security >> Application Security : Policy Building : Traffic Learning and click the magnifying
glass.
2. Click the Advance Filter tab.
Export your policy

Once testing is complete and youre ready to move the policy into your production environment, youll need to export the policy
from your QA system and save it.
To export your policy using the Configuration utility
20
DEPLOYMENT EXAMPLES
1. Go to Security >> Application Security: Security Policies: Active Policies.

2. Select the policy you want to export.
3. Click Export, select your preferred export method, and click Export again.
4. Save the security policy to a location accessible by your production environment.
Import and validate your policy

In your production environment, import and activate your security policy. Once its assigned to a production server, check logs
and traffic learning to see whether it is behaving as expected.
To import and validate your policy using the Configuration utility
1. On your production system, go to Security >> Application Security: Security Policies: Active Policies
and click Import.
The Import Security Policy screen displays.
2. Select the security policy you want to import.
3. Click Choose File and navigate to security file you exported in the previous part. Select the file, choose the
Inactive Security Policies List option, and click Import.
4. Activate the policy and assign it to your production virtual server.
5. Access the application to verify proper behavior. Test application access using a variety of browsers. Delete
browser cookies between sessions.
6. Go to Security >> Event Logs : Application : Requests and review to make sure that no illegal requests/
violations have been logged.
7. Go to Security >> Application Security : Policy Building : Traffic Learning and review to make sure that
no new learning suggestions have been generated.
21
DEPLOYMENT EXAMPLES

Description
You need a security policy to quickly protect multiple applications from common web application attacks. You also need the
policy to be easy to administer and to cause few false positives.
You do not have a Quality Assurance (QA) environment available in which to build and test your security policy before moving it
into production. If you do have a QA environment, see Protect multiple application using Automatic Policy Builder with a Quality
Assurance environment.
Goals
Recommended Approach
Use the Automatic Policy Builder to create a Fundamental policy type, which can protect multiple applications currently in
production. Then test the policy with traffic and review learning suggestions, logs, and charts.
4. Browse the application from the trusted IP and review accepted learning suggestions (optional).
5. Review elements added to policy (optional).
6. Pass untrusted traffic through server and review learning suggestions.
7. Manually enforce entities.
9. Validate your policy.
22
DEPLOYMENT EXAMPLES


each protocol.

Use the deployment wizard to build your policy with information you gathered in the previous part.
The Deployment wizard opens to the Select Local Traffic Deployment Scenario screen.
4. Select your virtual server from the HTTP Virtual Server menu and click Next.
7. From the Application Language list, select the language encoding of your applications or use Auto detect
and let the system detect the language.
policy.
23
DEPLOYMENT EXAMPLES
policy.
default selection (Enabled) or clear the checkbox to disable this option, then cthen click Next.
The Configure Attack Signatures screen displays.
Medium).
Next.
Browse the application from the trusted IP and review accepted learning suggestions (optional)
3. Click Save.
24
DEPLOYMENT EXAMPLES
To view accepted learning suggestions using the Configuration utility
glass.
2. Click the Advanced Filter tab.
3. Under Status choose Accepted / Accepted and Staged.
Review elements added to policy (optional)

glass.
Pass untrusted traffic through server and review learning suggestions

Pass untrusted traffic through the server. Policy violations will trigger learning suggestions which you can review and act on. You
can also wait for the BIG-IP ASM system to automatically deal with learning suggestions and to change the policy enforcement
mode to Blocking.
25
DEPLOYMENT EXAMPLES

Manually enforce entities

To manually enforce entities using the Configuration utility
1. Go to Security >> Application Security : Policy Building : Enforcement Readiness and review the
Enforcement Readiness Summary.
2. Select the Entity Type(s) you want to enforce, and click Enforce Ready.

26
DEPLOYMENT EXAMPLES
Validate your policy

Access your applications to verify proper behavior. Test application access using a variety of browsers. Delete browser
cookies between sessions.
Review the Event Request log to make sure that no violations are triggered.
Review the Traffic Learning screen to make sure that no new learning suggestions are generated.
27
DEPLOYMENT EXAMPLES

Description
You need a widely applicable, generic security policy to protect multiple applications in a production environment. You want to
use manual learning to fine-tune the policy.
Goals
Background
Many applications are deployed solely in a production environment without a formal Quality Assurance (QA) environment and
associated test processes. In many cases, rollout of an application update may receive only limited and informal testing (such as
by a software engineer working only within their own test environment). In these cases, the value of having an application security
policy enforced by BIG-IP ASM is higher than applications than those that receive greater attention from a test perspective.
An absence of test processes may introduce difficulties in the effective use of BIG-IP ASM; however, you can use BIG-IP ASM
effectively by employing the approach detailed under Recommended Approach.
Transparent enforcement mode

In a deployment without a QA environment, tuning is done in production and false positives may occur. However, use of
Transparent enforcement mode in BIG-IP ASM guarantees that requests violating the security policy are not blocked but instead
are logged or generate alarms.
Transparent enforcement mode is not equivalent to "learning." Some amount of unblocked malicious traffic will occur in
transparent enforcement mode, but this is by design since this traffic needs to be properly identified as malicious and not
learned or whitelisted.
When deploying in an environment without a QA environment, Transparent enforcement mode is mandatory. This is because a
BIG-IP ASM policy has a reasonable chance of generating false positives until it has had a chance to be tuned, either
automatically or manually, to adapt to your application(s) and traffic.
Once your policy has been tuned (meaning the rate of change and number false positives has reached a tolerable level), you can
change the policy enforcement mode to blocking. Until then, F5 recommends keeping the policy enforcement mode set to
28
DEPLOYMENT EXAMPLES
transparent to avoid disruption of legitimate traffic which might be blocked as a false positive in blocking enforcement mode.
More tuning of learning suggestions may be required to avoid inappropriate relaxation of the policy. Since production traffic may
contain malicious requests, the policy should not adapt to allow these requests through. BIG-IP ASM learning can help simplify
your analysis by employing a score (0-100%) for each learning suggestion. This metric means that no single violation of the policy
should earn a learning score high enough to be accepted to change the policy.
Application updates
Application updates introduce a false positive risk for any web application firewall deployment. This risk is greater in a deployment
without a QA environment because there is no opportunity to validate proper operation of the application when the security policy
is in blocking enforcement mode. Therefore, you should consider using transparent enforcement mode in advance of an
application update deployment.
In summary, lack of a QA environment and a formal test process impacts the recommended approach and requires more care
and planning prior to switching the policy to blocking enforcement mode. F5 recommends using transparent enforcement mode
when significant application updates are planned.
4. Monitor traffic.
6. Manually enforce entities.
7. Browse the application from trusted IP addresses.
8. Review policy.
10. Switch to Blocking mode.

29
DEPLOYMENT EXAMPLES

each protocol.
method.

1. Click Application Security > Security Polices > Create.
4. Select your virtual server from the HTTP Virtual Server menu and click Next.
30
DEPLOYMENT EXAMPLES
policy.
policy.
default selection (Enabled) or clear the checkbox to disable this option and click Next.
Medium).
Next.
Monitor traffic
31
DEPLOYMENT EXAMPLES


Manually enforce entities

To manually enforce entities using the Configuration utility
32
DEPLOYMENT EXAMPLES
2. Select the Entity Type(s) you want to enforce, and click Enforce Ready.
Browse the application from trusted IP addresses

3. Click Save.
Review elements added to policy

glass.

33
DEPLOYMENT EXAMPLES
Note When you use Automatic Policy Builder, the security policy file types
and parameters is populated automatically.
Switch to Blocking mode

The Automatic Policy Builder will notify you when the policy is ready and has switched to Blocking enforcement mode.
Note When a policy in in Blocking enforcement mode, requests that do not
meet policy requirements are blocked.
34
DEPLOYMENT EXAMPLES
Description
You need to quickly deploy an application security policy to protect an application that is in production.
Goals
Background
BIG-IP ASM offers a wealth of policy capabilities and provides options for granular control; however if you are looking for a policy
to protect common application security issues with minimal administration responsibilities, the Rapid Deployment application
security policy may be the best choice.
The Rapid Deployment template provides protection against comon attacks and allows a single policy to manage your
applications so that you can avoid maintenance of individual policies for each of your applications and coordination with
application teams through deployments and updates.
One consequence of using a single BIG-IP ASM policy for multiple applications is that relaxation of the policy for one application
to avoid false positives affects the other applications protected by that policy. This typically results in a more relaxed security
policy, so this approach isnt appropriate for customers looking for maximum security tailored on a per-application basis.
However, the Rapid Deployment template uses numerous approaches (including signatures, request normalization, and protocol
enforcement)to detect malicious traffic and therefore even a relaxed security policy is very likely to detect malicious traffic.
Therefore, the Rapid Deployment approach is appropriate for customers looking for basic protection with minimal maintenance
that decreases over time as the policy becomes more relaxed for common false-positive scenarios.
Manual learning
Manual policy learning is often used with the Rapid Deployment template to prevent excess policy relaxation. This requires you to
review policy modifications that the product suggests, based on observing the traffic that flows through the policy.
As your policy is initially deployed in a production environment with real user traffic--including the potential for malicious traffic-the policy may run in Transparent enforcement mode until you gain confidence in the policy's reliability through tuning the policy.
35
DEPLOYMENT EXAMPLES
Policy tuning is done by reviewing manual traffic learning suggestions and the application security event logs for illegal requests.
Once you are confident in the policy's readiness, you can switch the enforcement mode to Blocking to block requests in violation
of the policy. Typically, F5 recommends making the switch after seven days or less, depending on amount of tuning the policy
receives.
Recommended Approach
Develop a Rapid Deployment Policy security policy in order to protect a web application that is in production.
4. Monitor traffic.
7. Review policy.
8. Browse the application from trusted IP addresses (optional).
9. Review elements added to policy (optional).
10. Switch to Blocking enforcement mode.
11. Validate your policy

Set up a BIG-IP LTM virtual server with an HTTP profile assigned and a logging profile set to Log Illegal Requests. F5 does not
recommend logging all requests due to the amount of data that will be logged.

each protocol.
36
DEPLOYMENT EXAMPLES

1. Click Application Security >> Security Polices > Create.
2. Choose Existing Virtual Server if you have one configured or New Virtual Server if you want to create it
now, then click Next.
3. Choose HTTP or HTTPS.
4. Verify that the right virtual server is selected and click Next.
5. Choose Create a security policy manually or use templates (advanced) and then click Next.
6. Type the name of the policy
7. Choose the application language (encoding).
8. From the Application Ready Security Policy menu choose Rapid Deployment security policy.
9. Accept the default Enforcement Readiness Period of 7 days, and click Next.
11. Accept the default (selected) setting for Signature Staging and then click Next.
Note Leave Application Signatures to Response unselected. F5
recommends adding them later.
12. Review the summary page and then click Finish.
Monitor traffic
37
DEPLOYMENT EXAMPLES
Important Any manually accepted suggestions can be enforced when the
policy is moved to blocking mode. Be careful about enforcing attack
signatures: if an attack signature is enforced and the policy is in blocking
mode, any requests which trigger it will be blocked.



38
DEPLOYMENT EXAMPLES

3. Click Save.
Review policy
glass.

39
DEPLOYMENT EXAMPLES
Manually enforce attack signatures

To manually enforce attack signatures using the Configuration utility
2. Select the attack signatures you want to enforce, and click Enforce Ready.
Browse the application from trusted IP addresses (optional)

you can start sending traffic immediately and then accept all suggestions because the traffic comes from a safe source.
3. Click Save.
Review elements added to policy (optional)

glass.
3. Under Status choose Accepted / Accepted and Staged.
Switch to Blocking enforcement mode

When you dont see any more learning suggestions on the Traffic Learning screen, you can place your policy into Blocking
mode.
40
DEPLOYMENT EXAMPLES

After the policy is applied to a virtual server, access the application to verify proper behavior. Test application access using
a variety of browsers. Delete browser cookies between sessions.
Review the Event Request log to ensure that there are no violations
Review the Traffic Learning screen to ensure that no new learning suggestions are being generated.
41
DEPLOYMENT EXAMPLES
Protect applications with policy automatically built in non-production

environment
Description
You need a security policy to protect multiple applications currently in production. You have a Quality Assurance (QA)/nonproduction environment in which you can build and test your policy before moving it into production.
Goals
Requirements
This deployment example assumes the following:
You have a configured virtual server that logs illegal request.
You have a QA/non-production environment with trusted IPs and scanning tools.
Background
A deployment using a formal QA environment with a BIG-IP ASM system in place is ideal from the perspective of effectively and
accurately developing an application security policy. In this deployment, application updates are first deployed to a nonproduction environment and then some combination of manual and automated testing is performed in order to verify proper
application behavior. Because of the testing process, the BIG-IP ASM policy is exercised and validated at the same time that the
application itself is tested.
If you want to add BIG-IP ASM protection to an existing application which undergoes regular testing in a non-production
environment F5 recommends building and enabling a BIG-IP ASM policy for the non-production traffic accessing the application.
Depending on the extent of coverage provided by testing in this environment, the security policy can be rapidly developed (if the
test coverage is high) or developed more slowly (if the test coverage is lower).
In a QA environment, F5 recommends the following:
All traffic going to the application in the QA traffic should be benign traffic as opposed to malicious or pen-test/scan
traffic.
42
DEPLOYMENT EXAMPLES
Because traffic is benign, BIG-IP ASM can use its learning capabilities to make modifications to the policy to ensure that it
is enforcing proper behavior and not interfering with proper application behavior
Learning capabilities can be manual or automatic mode. Automatic mode is recommended unless administrators can
review each policy modification to better understand the details of the policy or the operation of BIG-IP ASM itself.
In a QA environment, the policy should be configured to use Transparent enforcement mode to ensure that the test traffic
is not blocked by the security policy prior to the learning capabilities making the appropriate policy modification.
If malicious traffic (such as pen-test or application scanning) needs to be performed, ensure that this traffic is not mixed
with the benign traffic used by BIG-IP ASM for policy learning. This can be accomplished in a number of ways. Contact
your F5 account team for recommended practices.
Unless you make significant changes to your application, you should not start fresh with a new policy and learning
process with each application update. Instead, your BIG-IP ASM security policy should be left in place and allowed to
adapt to application changes.
At the end of a full testing cycle and before deploying an application update to production, the BIG-IP ASM security policy
should change to account for behavioral changes impacting the application. Deploying the modified BIG-IP ASM security
policy to the production environment at this time should significantly minimize or eliminate the possibility of the application
update causing a false positive violation of the security policy in the production environment.
In your production environment F5 recommends:
You should export your security policy from the non-production environment and deploy it to production using the
Configuration utility or TMSH at the command line. Contact F5 for automated export/import approaches.
Disable trusted IP address ranges used in your QA environment when the policy is moved to production so that the
production system wont treat trusted IP addresses specially.
While Transparent enforcement mode is recommended for a QA environment, you may want to immediately use Blocking
enforcement mode so that malicious traffic violating the security policy is blocked by BIG-IP ASM.
You can choose not use Blocking enforcement mode immediately after promotion of your application and security policy
to production. Instead you can defer blocking for a period of time after deployment to production so that you can monitor
violation data to ensure that there are not any false positives being blocked by the policy.
False positives in this deployment example are usually related to testing that doesnt exercise all aspects of the policy or
fully exercise input possibilities for application input forms. False positives that make it past a testing effort in QA can be
used as a basis for making refinements to the testing process to better improve the test coverage.
You will use the Automatic Policy Builder to create a Fundamental policy type which can protect multiple applications currently in
production.
43
DEPLOYMENT EXAMPLES

4. Monitor traffic.
7. Switch to Blocking enforcement mode.
8. Export your policy.
9. Import and validate your policy.
10. Verify there are no blocking on false positives


each protocol.
method.
Make sure you have trusted IP addresses in your QA environment from which you can send legitimate traffic to BIG-IP
ASM. This will speed up the policy building process. If you dont have a QA environment, see Protect multiple applications
using Automatic Policy Builder without a Quality Assurance environment available.

44
DEPLOYMENT EXAMPLES

4. Select your QA virtual server from the HTTP Virtual Server menu and click Next.
policy.
policy.
default selection (Enabled) or clear the checkbox to disable this option and click Next.
Choose appropriate attack signatures sets from the Available Systems area as appropriate for your applications
criteria and add use the arrow keys to move them to the Assigned Systems area.
Leave Signature Staging enabled, and click Next.
10. The Configure Automatic Policy Building screen displays.
11. Leave Policy Type set to its default value (Fundamental).
45
DEPLOYMENT EXAMPLES
12. For Policy Builder Learning Speed, select Fast.

13. For Trusted IP Addresses, choose All and then click Next.
Monitor traffic
Important Any manually accepted suggestions can be enforced when the
policy is moved to blocking mode. Be careful about enforcing attack
signatures: if an attack signature is enforced and the policy is in blocking
mode, any requests which trigger it will be blocked.

46
DEPLOYMENT EXAMPLES


3. Click Save.
glass.
47
DEPLOYMENT EXAMPLES
Switch to Blocking enforcement mode

Once the policy no longer generates learning suggestions you can change the enforcement mode to Blocking.
1. Verify that wildcards on the entities have been removed. Wildcards prevent blocking.
2. Monitor the request log to see if users are being blocked.
Note When a policy in in Blocking enforcement mode, requests that do not
meet policy requirements are blocked.
Export your policy

Once testing is complete and youre ready to move the policy into your production environment, youll need to export the policy
from your QA system and save it.
To export your policy using the Configuration utility
1. Go to Security >> Application Security: Security Policies: Active Policies.
2. Select the policy you want to export.
3. Click Export, select your preferred export method, and click Export again.
4. Save the security policy to a location accessible by your production environment.
Import and validate your policy

In your production environment, import and activate your security policy. Once its assigned to a production server, check logs
and traffic learning to see whether it is behaving as expected.
To import and validate your policy using the Configuration utility
1. On your production system, go to Security >> Application Security: Security Policies: Active Policies
and click Import.
The Import Security Policy screen displays.
2. Select the security policy you want to import.
3. Click Choose File and navigate to security file you exported in the previous part. Select the file, choose the
Inactive Security Policies List option, and click Import.
4. Activate the policy and assign it to your production virtual server.
48
DEPLOYMENT EXAMPLES
5. Access the application to verify proper behavior. Test application access using a variety of browsers. Delete
browser cookies between sessions.
6. Go to Security >> Event Logs : Application : Requests and review to make sure that no illegal requests/
violations have been logged.
7. Go to Security >> Application Security : Policy Building : Traffic Learning and review to make sure that
no new learning suggestions have been generated.
Verify there are no blocking on false positives

Monitor the Traffic Learning page and the request log to ensure legitimate traffic is not being blocked. F5 recommends
monitoring for few hours.
49
DEPLOYMENT EXAMPLES

Description
You need to protect your application from denial-of-service/distributed denial-of-service (DoS/DDoS) attacks while allowing
legitimate traffic through.
Goals
Protect an application against several types an application-layer DoS flood attacks, including
single IP to single URL,
multiple IPs to single fixed URL,
multiple IPs to multiple fixed URLs, and
multiple IPs to multiple random URLs.
Background
DoS/DDoS attacks can impair communication between users and an application and/or make the application unavailable.
BIG-IP ASM determines whether or not traffic is a DoS/DDoS attack based on calculations for transaction rates on the client side
(TPS-based) or latency on the server side (stress-based).
Note There are additional mitigation steps for DoS/DDoS attacks. This
approach focuses on latency, which refers to how long it takes for a server to
answer a request, and to transactions per section (TPS) thresholds.
DoS/DDoS attacks are increasingly common challenges for operators of Internet-based applications. These attacks focus on
disrupting legitimate user access to an application. The attacks use a variety of approaches targeting different application and
network resources that all have finite capacity, including the network itself, throughput and memory capacity of network
infrastructure as well as server/compute resources.
BIG-IP ASM incorporates sophisticated detection and mitigation technology for attacks that target HTTP-based applications
where the bulk of the attacks are targeting capacity constraints on the application server itself. BIG-IP ASM is constantly evolving
to respond to the evolving approaches used by DoS attackers.
While BIG-IP ASM is a comprehensive web application firewall product that can defend web applications against exploits of
application vulnerabilities, its ability to defend against application-layer DoS attacks is managed independently of the WAF policy.
Its defenses can be applied to an application in addition to a security policy or to an application that doesn't have a BIG-IP ASM
security policy. In general, a BIG-IP ASM DoS policy would be broadly applicable to numerous applications and doesn't require
50
DEPLOYMENT EXAMPLES
extensive customization on a per-application basis.

Two of the most common ways of detecting application layer attacks are tracking and measurement of HTTP transaction rates
(referred to as TPS [transactions per second] rates) and measuring application latency or response time, which is an indicator that
a server is under significant load.
A well-constructed BIG-IP ASM application-layer DoS profile detects and mitigates attacks that use different strategies to
overwhelm the application. Many BIG-IP ASM detection and mitigation strategies are enabled simultaneously for added security.
For example, one attack may be detected using a TPS-based approach while a low-TPS rate attack would be missed. However, if
this latter attack produces significant application load on a per transaction basis, it would be detected using BIG-IP ASM
stress-based attack detection.
TPS-based detection
TPS-based detection configures the system to look at two metrics on the client-side: Transaction rate detection interval, which is
a short term average of recent requests and the Transaction rate history interval, which is a longer-term average of requests per
second.
If the ratio of detection interval is greater than the history interval (as configured in the DoS profile), BIG-IP ASM considers the
application to be under attack.
Stress-based detection (optional)

Stress-based detection covers cases in which the server stress condition is detected, meaning server responses are slowing
down.
This mode detects attacks by monitoring the traffic rates so it may declare false positive attacks: the traffic rate was unusual and
exceeded the threshold but the server was not affected.
F5 recommends that you consider this mode to enhance your policy or if TPS-based detection is insufficient.
1. Create or edit a DoS profile and configure DoS protection.
3. Examine reports and verify whether DoS mitigation is effective.
4. Optional: Apply stress-based detection and prevention.
51
DEPLOYMENT EXAMPLES
Create or edit a DoS profile and configure DoS protection

Create or edit a DoS profile and configure DoS protection using the Configuration utility
1. Go to Security >> DoS Protection : DoS Profiles.
The DoS Profile list screen opens.
2. Click Create to create a new DoS profile or click the name of an existing DoS profile to edit it. If creating a new
profile, under the Profile Information General Settings, in theProfile Namefield type a profile name.
3. On the left, under Application Security, clickGeneral Settings, and ensure thatApplication Securityis
enabled. If Application Security is disabled, clickEditand enable it.
The screen displays additional settings.
4. Set up DoS protection based on the country where a request originates by editing theGeolocationssetting,
selecting countries to allow or disallow.
a. Move the countries for which you want the system to block traffic during a DoS attack into
theGeolocation Blacklist.
b. Move the countries that you want the system to allow (unless the requests have other problems) into
theGeolocation Whitelist.
3. Enable TPS-based detection.
a. On the left, under Application Security, clickTPS-based Detection.
b. The screen displays TPS-based DoS Detection settings.
c. Enable TPS-based DoS Detection with defaults.
4. Assign the DoS profile to a virtual server and deploy policy.

After your policy is applied, verify it by accessing your application and view reports to determine if effective mitigation is occuring.
Examine reports and verify whether DoS mitigation is effective

Verify that the correct prevention policy is applied based on attack type by viewing the transaction outcomes report.
To view transaction outcomes using the Configuration utility
1. Go to Security>>Reporting:DoS:Application:Transaction Outcomes.
52
DEPLOYMENT EXAMPLES
2. Check the amount of traffic being blocked due to DoS attacks to determine whether policy mitigation is
effective.
Note An effective prevention mitigates DoS attacks and does not fallback to
other preventions. If needed, enable CAPTCHA challenge and Client Side
Integrity Challenge to enhance the prevention.
Optional: Apply stress-based detection and prevention

Review the server latency to understand if you need to configure Stress-based detection.
Examine the following reports:
URL Latency
Server latency
If needed, edit your DoS Profile and enable Stress-based detection and prevention.
Note Use stress based detection when you want the prevention policy to be
applied when there is a latency increase on the backend server (not just RPS
increase but also greater latency in the back end)
For more information on DoS Profile configuration, see Preventing DoS Attacks on Applications in BIG-IP ASM: Implementations.
53
DEPLOYMENT EXAMPLES

Description
You need a security policy to protect your protect your applications against attacks by web robots (calledbots, for short). You
also need the policy to allow legitimate access your applications and to cause few false positive violations.
Goals
Block simple bots.
Allow legitimate clients to view and edit data.
Allow legitimate scanners to access applications.
Minimize false positive violations.
Background
Bot signatures and proactive bot defense
Bot signatures identify web robots by looking for specific patterns in the headers of incoming HTTP requests.
You can configure BIG-IP ASM to protect your web site against attacks by bots before they occur using proactive bot defense.
This feature can prevent attacks from starting instead of waiting until an attack is detected. It checks all traffic (except whitelisted
URLs) coming to the web site, not simply suspicious traffic. This DoS protection uses a set of JavaScript evaluations and bot
signatures to make sure that browsers visiting your web site are legitimate.
Starting in BIG-IP ASM 12.0, bot signatures are available and turned on automatically when you configure proactive bot defense.
This is valuable when a site needs be scanned by valid bots, such as web crawlers. If you allow bots using the bot signatures,
those bots are not blocked by proactive bot defense or any other defense mechanism.
When clients access your application for the first time, the system injects a JavaScript challenge instead of the original response
in order to test whether the client is a legitimate browser or a bot. Legitimate browsers will resend the request to the server with a
signed cookie, while bots will not resend the request to the server.
You can also configure how the system reacts to cross-domain requests. That is, if the system receives a request for non-HTML
resources (images, CSS, XML, JavaScript, and Flash) without a valid cookie, and has a Referer header with a different domain
than the host domain.
DoS L7 bot detection includes many signatures that identify bots. The signatures identify the type of bot for classification and
investigative purposes, and can distinguish between benign and malicious bots.
Bot signatures have a low rate of producing false positive results. By using the bot signature list, the accuracy of proactive bot
54
DEPLOYMENT EXAMPLES
defense can be increased with less false positives.

DNS-reverse lookup
BIG-IP ASM Proactive Bot-Defense checks to see whether a signature is benign or whether to block or report it. It also checks to
see whether a reverse-DNS lookup is needed to verify the source IP of the bot. For example, since the signature has a domain
name Google, the authenticity of the source IP for the googlebot can be verified.
Once a DNS-reverse lookup is done and verified, the request is exempted from proactive bot-defense tests. You can reduce the
chance of false positives by using the bot signatures list.
Important Proactive bot defense is intended to complement, not replace,
other mitigation methods.Proactive bot defense has limitations if your web
site uses Cross-Origin Resource Sharing (CORS), for example, with AJAX
requests.
Note To use proactive bot defense, client browsers accessing your web site
must be able to accept JavaScript.
Create and configure a layer 7 DoS profile and proactive bot defense enabled and assign the profile to a virtual server. Provision
BIG-IP Application Visibility and Reporting (AVR) and validate your policy, monitoring AVR for false positive violations.
1. Create and configure layer 7 DoS profile.
2. Enable and configure proactive bot defense.
3. Configure bot defense.
4. Assign the DoS Profile to the virtual server.
5. Provision AVR and create an analytics profile for your virtual server.
6. Monitor AVR reports.
7. Validate your DoS profile
Create and configure layer 7 DoS profile

The BIG-IP ASM DoS profile identifies and blocks bots. The DoS profile contains several features you may use to fine-tune the
55
DEPLOYMENT EXAMPLES
profile, depending on your needs.

To create a DoS profile using the Configuration utility
1. Go toSecurity>>DoS Protection:DoS Profiles.
The DoS Profiles list screen opens.
2. ClickCreate.
The Create New DoS Profile screen opens.
3. In theProfile Namefield, type the name for the profile.
4. On the left, under Application Security, clickGeneral Settings.
If Application Security is disabled, clickEditand enable it.
5. To omit certain addresses, edit theIP Address Whitelistsetting:
a. ClickEditto display additional settings.
b. Type IP addresses or subnets that do not need to be examined for DoS attack, and clickAdd.
c. When you are done, clickClose.
Note You can add up to 20 IP addresses.
6. To set up DoS protection based on the country where a request originates, edit theGeolocationssetting,
selecting countries to allow or disallow.
a. ClickEditto display additional settings.
b. Move the countries for which you want the system to block traffic during a DoS attack into
theGeolocation Blacklist.
c. Move the countries that you want the system to allow (unless the requests have other problems) into
theGeolocation Whitelist.
d. Use the Stress-Based or TPS-Based Detection settings to select appropriate mitigations by geolocation in
56
DEPLOYMENT EXAMPLES
theHow to detect attackers and which mitigation to use settings.

e. When done, clickClose.
7.
If you have written an iRule to specify how the system handles a DoS attack and recovers afterwards, enable
theTrigger iRulesetting.
8. ClickFinishedto save the DoS profile.
For more information, see Preventing DoS Attacks on Applications in BIG-IP ASM: Implementations (BIG-IP v. 12).
Note Consider configuring additional levels of DoS protection such as
TPS-based protection, stress-based protection, heavy URLs, and proactive
bot defense.
The DoS profile needs to be associated with a virtual server before it protects against DoS attacks.
Enable and configure proactive bot defense

To configure proactive bot defense using the Configuration utility
1. Go to Security>>DoS Protection:DoS Profiles.
The DoS Profiles list screen opens.
2. Click the name of an existing DoS profile (or create a new one).
The DoS Profile Properties screen for that profile opens.
3. On the left, under Application Security, clickGeneral Settings.
4. If Application Security is disabled, clickEditand enable it.
5. ClickProactive Bot Defenseto display the settings.
6. To set theOperation Modeto enable proactive bot defense, clickEditand specify Always.
Important If you enable Proactive Bot Defense and your web site uses
CORS (Cross-Origin Resource Sharing), F5 recommends that you add the
CORS URLs to the proactive bot URL whitelist.
By default, the system blocks requests from highly suspicious browsers and displays a default CAPTCHA (or visual
57
DEPLOYMENT EXAMPLES
character recognition) challenge to browsers that could be suspicious.

You can change theBlock requests from suspicious browserssetting by clearing eitherBlock Suspicious
BrowsersorUse CAPTCHA.
7. If you want to customize the CAPCHA challenge being used for TPS-based Detection, Stress-based
Detection, or Proactive Bot Defense:
a. In TPS-based Detection, Stress-based Detection, or Proactive Bot Defense, select theCAPTCHA
Challengeoption.
b. TheCAPTCHA Settingslink is displayed.
c. ClickCAPTCHA Settings.
The Application Security General Settings area opens and displays theCAPTCHA Responsesetting, which is
where you can configure the response.
8. In theGrace Periodfield, type the number of seconds to wait before the system begins bot detection.
The default value is300seconds.
The grace period allows web pages (including complex pages such as those which include images, JS, and CSS)
the time to be recognized as non-bots, receive a signed cookie, and completely load without unnecessarily
dropping requests.
The grace period begins after the signed cookie is renewed, a change is made to the configuration, or after
proactive bot defense starts as a result of a detected DoS attack or high latency.
Configure bot defense

1. In the Bot Signatures Categories section make sure that the actions (None, Block, Allow) are appropriate for both
malicious and benign bot categories.
2. If you want to allow certain bots, such as Google Desktop, disable the appropriate signatures on the Bots Signature
List.
Assign the DoS Profile to the virtual server

1. Enable the DoS Protection Profile option on your virtual server.
2. Assign the DoS profile to the virtual server.
58
DEPLOYMENT EXAMPLES
Provision AVR and create an analytics profile for your virtual server
To provision AVR and create analytics profile using the Configuration utility
1. Go to System >> Resource Provisioning and provision Application Visibility and Reporting.
2. Go to Local Traffic >> Profiles: Analytics and create an analytics profile for your virtual server.
3. In the Included Objects section, add the virtual server for which you want to collect analytics data.
4. Click Finished.
Monitor AVR reports

The reporting tools in AVR will allow you to examine statistics regarding bots that are accessing your application and make sure
that false positive violations are not being generated.
To view statistics
1. Go to Statistics >> Analytics : HTTP :Transactions.
2. From the View By drop down menu, choose DoS Bot Signatures.
or
1. Go to Security >> Reporting : DoS : Application : Transaction Outcomes.
2. At the bottom of the page, choose DoS Bot Signatures.
Validate your DoS profile

After your policy is applied to a virtual server, access the application to verify proper behavior. Test application access using a
variety of browsers. Delete browser cookies between sessions. Use tools such as ab, curl, or PhantomJS, to test for bots.
If necessary, adapt BIG-IP ASM Whitelist and Bot Signatures categories and actions. To get detailed requests, use capturing
tools like TCPdump or iRules, which log HTTP headers. For more information, see Overview of packet tracing with the tcpdump
utility and Log Http Headers on DevCentral.

Depending on the use case, you can distinguish between a logged and logged/blocked event for each defense method. During
an ongoing bot attack, load should decrease on the application server.
Check AVR reporting for blocking actions and make policy adjustments as necessary.
59
DEPLOYMENT EXAMPLES
Description
You need a security policy that allows WhiteHat Sentinel security scanning.
Goals
Integrate WhiteHat Sentinel vulnerability scanning and virtual patching into the software development lifecycle.
Protect against most common web application vulnerabilities discovered by WhiteHat Sentinel.
Reduce false positives.
Background
If your organization takes advantage of automated application scanning solutions as a means of identifying application
vulnerabilities, these vulnerabilities are typically resolved through an application update (if from a commercial vendor) or resolved
by internal application developers (if the application is internally developed and maintained). However, such resolutions may take
a long time and may introduce risk to applications running in a production environment. Because of these factors, your
organization may need to explore other means of remediating application vulnerabilities.
Vulnerability scanning benefits

Quickly mitigate commonly known vulnerabilities.
Allow engineers to understand where BIG-IP is being used during testing.
Offload positive security development that is normally done during the BIG-IP ASM policy building process, greatly
reducing the time to effective mitigation.
Ensures that proper coverage of an existing application scanning tool process is applied.
Approaches to integrate scanning

BIG-IP ASM provides correction for most application vulnerabilities and features built-in support for automated import and
remediation of vulnerabilities supported by a number of industry leading application vulnerability scanning solutions, including
WhiteHats Sentinel service.
Often, when an application vulnerability is discovered by a scanning solution, BIG-IP ASM may be available on the BIG-IP system
managing the application traffic but a BIG-IP ASM policy has not been built and applied to the application. In such cases, many
administrators want to correct the discovered vulnerabilities as quickly as possible using a BIG-IP ASM Security policy in
Blocking enforcement mode.
For rapid remediation in such cases, instead of a typical BIG-IP ASM policy-building approach, most of the security policy
featurestypically requiring customization and refinement--are disabled so that they do not block legitimate application traffic.
The policy is then exclusively devoted to remediation of discovered vulnerabilities until time allows the policy to be enhanced with
60
DEPLOYMENT EXAMPLES
other BIG-IP ASM protection capabilities such as application signatures.

If your application is already protected by BIG-IP ASM and scanning discovers vulnerabilities, you can enhance the existing policy
with explicit remediation of known application vulnerabilities. The advantage of this approach is that the vulnerabilities are
explicitly addressed through a policy addition that you can review, despite the possibility that the policy detected and mitigated
exploits targeting the vulnerability.
All of these approaches can be accommodated by the BIG-IP ASM product. In this deployment example, you build a policy solely
to remediate application vulnerabilities discovered by a scanning solution against on an application that did not have a BIG-IP
ASM security policy enabled. Note that scanning tools vary in interface and features, so this deployment example focuses on
WhiteHat Sentinel.
Scanning integrated into the software development lifecycle
The following figure shows the application development workflow, with scanning incorporated.
Figure 1.1 Software development lifecycle using scanning and virtual patching.
You need a security policy that allows security scanning.
Background/Requirements
BIG-IP ASM allows for integration with several vulnerability assessment platforms by using dynamic application security testing
(DAST). This example uses WhiteHat Sentinel, which will perform automated vulnerability assessment against any web
application and provide insights into known vulnerabilities.
Vulnerability scanning benefits

Quickly mitigate commonly known vulnerabilities.
Allow engineers to understand where BIG-IP is being used during testing.
Offload positive security development that is normally done during the BIG-IP ASM policy building process, greatly
reducing the time to effective mitigation.
Ensures that proper coverage of an existing application scanning tool process is applied.
Scanning integrated into the software development lifecycle

The following figure shows the application development workflow, with scanning incorporated.
Note Virtual patching is the term for creation of short-term policy mitigations
to guard against new exploits.
61
DEPLOYMENT EXAMPLES
1
Software developed
2
Software tested and
scanned
Application code is
changed
Virtually Patched
Application is tested
4
Application in
Production
Figure 1.1 Software development lifecycle using scanning and virtual patching.
(1) Application is developed.
(2) Application is tested and scanned.
(3) Application testing and virtual patching applied.
(4) Application enters production environment.
(5) Application code is updated.
Steps 2-5 repeat. The time scale for application development, scanning and testing, patching, and updating can vary greatly.
Requirements
BIG-IP ASM allows for integration with several vulnerability assessment platforms by using dynamic application security testing
(DAST). This example uses WhiteHat Sentinel, which will perform automated vulnerability assessment against any web
application and provide insights into known vulnerabilities.
This deployment example assumes the following:
You have a BIG-IP system with BIG-IP ASM licensed and configured to access the internet.
You have a WhiteHat Security account or API credentials.
Your web application is behind a virtual server with BIG-IP LTM installed and configured with appropriate profiles (httpsprofile preferred).
62
DEPLOYMENT EXAMPLES
2. Scan the application.
3. Import the scanner results into BIG-IP ASM.
4. Resolve violations according to the findings.
5. Evaluate false positives on the learning page with real traffic.
6. Switch policy enforcement mode to Blocking.
7. Rescan the app to verify that all vulnerabilities are mitigated.

1. Click Application Security >> Security Polices and click Create.
2. Choose Existing Virtual Server and click Next.
3. Choose HTTP or HTTPS and the virtual server and click Next.
4. ChooseCreate a security policy using third party vulnerability assessment tool output and click Next.
6. Choose the application language.
7. Select default enforcement mode Transparent.
8. If the security policy is case sensitive, select the Case sensitive check box.
9. If you want the policy to differentiate between HTTP and HTTPS URLs, select the checkbox and click
Next.
10. For Vulnerability Assessment Tool, select WhiteHat Sentinel.
11. Type the IP address of the scanner. Use the defaults for the other settings and click Next.
12. Review the summary page and click Finish.
Scan the application
63
DEPLOYMENT EXAMPLES
Log in to the WhiteHat Security (this link sends you to an external site).
Note Log in requires that you have a WhiteHat account. A free trial account
is available.
1. Use WhiteHat Sentinel to scan the application for vulnerabilities and save the results.
Import the scanner results into BIG-IP ASM

To import scanner results using the Configuration utility
1. Go to: Security >> Application Security : Vulnerability Assessment : Vulnerabilities.
2. Click Import, choose the scanner file you want to import, then click Import.
3. When import is done, click Close.
4. Click the Vulnerability name and resolve the Vulnerabilities list.
Resolve violations according to the findings

1. Resolve each violation by choosing the option most appropriate for your organizations policies and processes:
Resolve and stage places the resolution in staging to prevent false positives. For example, if an attack signature is
applied to a parameter or URL, that entity is placed in staging.
Resolve resolves the vulnerability but does not place any entities in staging.
Ignore ignores the resolution and the entity.
Cancel ignore reverses the ignore action.There is a free text area to write notes on what actions were taken to mitigate
this item.
Show resolution opens a window that explains how to manually resolve this vulnerability.
2. After the vulnerability is mitigated, the Change ASM status to mitigated option shows this item as mitigated and it is
filtered accordingly.
F5 recommends resolving all open vulnerabilities. If necessary, check ASM logs to review blocked requests or responses and
follow up.
Evaluate false positives on the learning page with real traffic

Go to Traffic learning page and review the suggestions.
Learning suggestions may have been added for entities created during the mitigation.
64
DEPLOYMENT EXAMPLES
Switch policy enforcement mode to Blocking

To change the policy enforcement mode to Blocking using the Configuration utility
1. Go to Security >> Application Security : Policy : Policy Properties.
2. For Enforcement Mode, choose Blocking.
3. Set the Enforcement Readiness Period to 0 days.
4. Click Save and then click Apply Policy.
5. For signature staging, click the Attack Signatures Configuration link.
6. Click to clear the Enable Signature Staging checkbox.
7. Click Save and then click Apply Policy.
Rescan the app to verify that all vulnerabilities are mitigated

1. Rescan the application with the mitigated findings.
2. Verify that vulnerabilities are being blocked and no new vulnerabilities have been found.
Repeat this scan every month.
Important False positives may appear as suggested vulnerability mitigations.
WhiteHat cannot account for your environment, stack, and server resources.

Once your application has moved into a validation or a production environment, the policy can be monitored for updates as
defined by your policy management process.
Policy deployment is successful when WhiteHat Sentinel scans the application with no new vulnerabilities discovered. When a
new vulnerability is discovered, you can load a new scanner export to the existing policy.
65

Yes
No

Yes
No

Yes
No

Send
BIG-IP ASM API/WEB SERVICES PROTECTION

Web API Use Cases
BIG-IP ASM API/Web Services Protection

The BIG-IP ASM system provides protection for web applications, API services, and servers. The system provides a granular
definition of security policies to analyze requests and responses associated with a RESTful API service.
You can define explicit policy entities and violation settings for specific components of an API service.
Due to the nature of APIs and API data, you need to manually create a security policy and add appropriate security entities to
protect the API service, including parameters, sensitive parameters, URLs, HTTP methods, and content profiles.
Web API Use Cases

Modern distributed APIs use Web (HTTP) interfaces to pass the remote function invocation between the client and server. There
are several ways to achieve this, but the most prominent are web services and Representational State Transfer (REST), both of
which the BIG-IP ASM system protects. The BIG-IP ASM system also protects other API methodologies.
The three fundamental use cases of web APIs are back-end to back-end (B2B) APIs, browser to back-end APIs, and mobile
application APIs.
Back-end to back-end APIs

A back-end system acts as the client, and performs transactions on another remote system acting as a server.
The client system is called back-end because it is not a browser or any other client that is expected to provide an interactive
interface or GUI to a user. Rather, it provides a back-end system that implements business logic.
Typical B2B use case examples include reseller to retailer, retailer to supplier, and credit to bank. However, the most prominent
use is for web services.
Browser to back-end APIs

Browser to back-end APIs is also commonly called AJAX.
Web application frameworks separate the presentation layer (HTML template, CSS, and front-end JavaScript code) from the
content that the user will present or the data that the user will manipulate.
Presentation layer assets are retrieved when a new page loads. Meanwhile, users retrieve content or manipulate data using HTTP
requests from within the page itself. This process and content retrieval can occur asynchronously, allowing many non-blocking
requests for content and manipulations to data to occur simultaneously.
These non-blocking requests are called AJAX requests or XmlHttpRequests (XHR) in JavaScript vocabulary.
The API client is the JavaScript code from within the page. These APIs are typically, but not exclusively, REST.
67

Mobile application APIs

In this use case, mobile applications communicate with the back-end servers using a Web API, which is typically, but not
exclusively, REST. This is similar to the browser to back-end (AJAX) use case, but here the client application is installed on the
mobile device.
Web services
Web services are the traditional standard for invoking API on the web.
They consist of multiple standards from the W3C and OASIS organizations.
Web services use XML as the representation markup language.
The following web services are most relevant to the BIG-IP ASM system:
Simple Object Access Protocol (SOAP), which is a transport protocol.
Web Services Description Language (WSDL), which is the language for defining the API.
Web service security (WSS), which encrypts and signs elements of the SOAP messages.
Security Assertion Markup Language (SAML), which is the language for authentication tokens asserting the identity of a
user.
Web services are commonly used in application-to-application use cases, but they are also used in web browsing instead of the
REST/JSON, and on mobile applications.

Representational State Transfer (REST) is a procedure and software architecture design providing a controlled set of
recommended constraints in the development of APIs for web applications and other hypermedia.
Typically, RESTful APIs use JavaScript Object Notation (JSON) as the document format used in the request and response, but
they may also use XML. You can use RESTful API services for client-to-server or server-to-server communication.
No official standards or RFC exist for REST, so developers adopt other standards and protocols that use a similar design pattern.
These standards and protocols include JSON, URI, HTTP, HTTPS, and XML. The adoption of these standards provides a solid
foundation for securing a REST API using the BIG-IP ASM system.
68

Table 2.1 Web services and REST comparison

Web Services
REST
Representation format
XML.
JSON, more rarely XML.
API methods
Part of the message.
HTTP methods following the CRUD paradigm.
Any methods can be defined.
Parameters
Always in request payload.
URI is always the "object" parameter.

GET query parameters in Query String.
Object modifying parameters in request
payload.
Use Cases
Back-end to back-end.
Browser to back-end (AJAX).

Mobile applications.
Security
Message level (WSS) and transport level

(SSL/TLS).
Only transport level (SSL/TLS).
Formal API definition

schema
WSDL, optionally enforced on the BIG-IP

ASM system.
None.
Separate static content URLs from API URLs

This section applies only to the browser to back-end server API (AJAX) use case. It also applies to web services and RESTful
procedures. In the other use cases, all traffic passing through BIG-IP ASM policy is API traffic.
In the browser to back-end server API (AJAX) use case, the web application consists of two sets of URLs, which need to be
treated differently: static content URLs and AJAX URLs.
From the BIG-IP ASM perspective, the main difference between the sets of URLs is the way in which request payload is handled:
content requests do not carry a body payload, while AJAX requests often do. In the web services use case, this applies to all
requests, while in the REST use case, POST, PUT, and PATCH are the modifying methods.
Content URLs have either Disallow, Check content signatures, or Form Data (especially for content upload cases) for the request
body handling.
JSON or XML are the body handling method for AJAX URLs. JSON or XML profiles are attached, respectively.
69

Methods used in BIG-IP ASM policies to separate the allowed URLs into content or AJAX URL groups include the following:
1. If the URI (path) patterns for the two groups are known in advance, the groups can be configured manually to one or few
wildcards for each group.
For example /resources/* catches all content URLs, and /api/* catches AJAX API URLs.
Note The same content profile (XML or JSON) applies to all RESTful URLs. If
more fine-grained control is required, you have to break the AJAX URL
wildcard into several wildcards, each with its own separate profile.
2. If you cannot easily group the URLs by URI patterns, or if the application changes often, it makes sense to have all URLs
learned and let the BIG-IP ASM system also detect the content payload automatically. Do this by activating the URL
classification setting (in BIG-IP 12.0.0), or the detect advanced protocols setting (in BIG-IP 11.6.0).
Note This method works only with automatic learning enabled.
3. If most URLs are AJAX, the static content URLs can be identified as those without a JSON or XML body. In this case, the
new URLs are learned in selective mode and the "*" URL is configured with XML or JSON body.
During the policy tuning phase, requests with payload other than AJAX or XML fail to parse correctly or to generate
violations. These requests are eventually learned as separate URLs in the policy, while the "*" URL covers AJAX traffic.
BIG-IP ASM web service handling

The BIG-IP ASM system handles web services API at three levels:
1. Parser level attacks and buffer overflows.
2. Application vulnerabilities.
3. Message-level security and server offloading.
The XML profile is the container of the XML and web services enforcement.
The following table summarizes the security actions at each level:
70

Table 2.2 Security actions at each level of web services API

Level
Parser level and

buffer overflow.
Application
vulnerabilities.
Security Action
Consideration
XML Profile
XML syntax verification.
Basic security measure that you

have to always apply.
The inclusion of any XML

profile enforces XML
syntax.
Message sizing restriction:

length, number of elements,
nesting level, and more.
F5 recommends that you apply all

defense checks and let the learning
process adjust the thresholds.
Enable and set thresholds

per each defense
measure.
WSDL or XML schema

validation.
If the server application has a WSDL

file, attach the file to the policy so
that the policy can be enforced.
Attach WSDL or XSD file to

the profile.
Restrict the allowed SOAP

methods.
WSDL is assumed, but not all

methods are allowed in all URLs to
the API.
Mark the allowed methods

from the WSDL.
For example, in some URLs you may

only allow read methods, while in
other URLs, you allow all methods,
including those that modify data.
Message-level
security.
Attack signatures in XML

element content.
F5 recommends that you enable

attack signature checks and let BIGIP ASM learning process disable
false positive signatures.
Enable attack signatures.
Handling encryption and

decryption, message
signing, and validating
signatures on either the
client or server side.
If the client application uses WSS,

the BIG-IP ASM system can pass
a message to the server without
encryption, or with shorter keys.
The same is true for signatures and
authentication.
WSS section.
Protect a REST API

REST API manipulates the state of the resources or endpoints following CRUD (Create, Read, Update, Destroy) methodology.
CRUD is expressed in HTTP methods (such as GET for reading, POST for creating, and others).
To secure your REST API, F5 recommends that you have access to the endpoints, which typically follow a URI standard. These
71

resources allow you to set the enforcement mode to Blocking immediately after you apply the security policy to your virtual
server.
When you deal with the browser to back-end server (AJAX) use case, make sure that you separate AJAX URLs from HTML and
resource URLs in your security policy.
Deployment example
This section describes a real-world deployment example based on the following assumptions:
The API follows a RESTful software design and architectural methodology.
The API uses MongoDB to store JSON documents for its data store, instead of using an SQL database.
The API service is written in NodeJS and is hosted on a Linux server.
The API service uses BIG-IP LTM as a proxy to forward SSL (HTTPS: 443) L7 traffic to the server's listening port for the
API.
The API is developed and the data store (MongoDB) is managed by a developer in your organization.
You have a specification associated with the API service outlining the stack (services/daemons) that is required for a
proper functioning API.
The API stores, contains, or returns data containing PII (Personally Identifiable Information), which must be excluded from
all logging processes.
API documentation indicates fields that are considered to be highly sensitive, which you need to obscure before logging
requests, violation requests, or responses to your logging infrastructure.
All customers have a user ID.
You use HTTP methods to view or update your customer list.
Data specification from developer

Your developer supplies you with the following sample command syntax that users can apply to update and view customer
information.
To create a new customer

Use the following command syntax::
+POST/api/v1/customers
{
"name":"CompanyAcme", "contact"{
72

"name":"JohnDoe", "phone":"+11231231234",
"email":"john.doe@companyacme.tld"
},
"active":"true"
}
To list customers

Use the following command syntax:
+GET/api/v1/customers
{
"customer":{
"id":"508FBD45934BD7BF8E0DA6BFACA0E4",
"name":"CompanyAcme", "contact":{
"name":"JohnDoe", "phone":"+11231231234",
},
"active":"true", "created":"1476909" "modified":"1476939",
}
}
R ESPONSE:
{
"customer":{

"id":"508FBD45934BD7BF8E0DA6BFACA0E4"
},
"status":"created"
} [FIGURE]
To view a specific customer

+ GET /api/v1/customers/:customer _ uuid

- RESPONSE
{
"customer": {

"id":"5088FBD459334BD7BF8E0DA6BFACA0E4",
"name":"Company Acme", "contact": {
"name":"John Doe", "phone":"+11231231234",

73


},
"active":"true",
"created":"1447669909"
"modified":"1447669939",
}
}
Create a security policy to protect REST API
The BIG-IP ASM system allows a security policy to be as explicit or general as necessary with regard to a RESTful API. However,
define your policy as specifically and explicitly as possible to reduce the risk associated with its use.
Using the data specification for the API, you can manually create an explicit policy to allow users to view certain URLs and
parameters, but not others.
The more explicit configuration and security policy rules, the more potential for false positives. However by keeping track of
updates in your API, you can keep the security policy updated to reflect new changes and available URLs or added HTTP
methods.
Note You can protect data by using the BIG-IP ASM system to deny access
from automated libraries (liburl, python, php-curl, curl, wget, and others), and
to deny known malicious bots and crawlers access to the system, as well.
Because in this example the application is built within your organization, you can set the policy enforcement mode to Blocking
immediately after applying the policy to your virtual server.
You will not use the Policy Builder in this example.
The tasks to create and apply the policy include the following:
1. Create a security policy with appropriate attack signatures enabled.
2. Create a JSON profile. Enable GET and POST HTTP methods in the security policy.
3. Enable additional HTTP methods.
4. Define accessible and inaccessible URLs for your API.
5. Modify the security policy to include the profile.
6. Delete wildcards.
74

7. Apply the policy to the virtual server and set the enforcement policy to Blocking.
To create a security policy with appropriate attack signatures enabled
1. Navigate to Security >> Application Security : Security Policies : Active Policies and click Create.
2. For Local Traffic Deployment Scenario, select Do not associate with Virtual Server, and click Next.
3. For Deployment Scenario, select Create a security policy for XML and web services manually, and
click Next.
4. Name the policy, leave Application Language at the default setting Unicode (utf-8), clear Security Policy
is case sensitive and Differentiate between HTTP and HTTPS URLs, and click Next.
Note In this example, F5 assumes that your application does not rely on
case sensitivity, uses either HTTP or HTTPS protocols, and does not need to
differentiate between the protocols. Adjust the example, as necessary, for
your use.
5. Under Available Systems, Shift-select the following attack signature options:

Unix/Linux
Apache
Node.js
jQuery
MondgoDB
Then click << to add them to Assigned Systems.

6. Clear Signature Staging, and click Next.
7. Click Finish.
To create a JSON profile
1. Navigate to Security >> Application Security : Content Profiles : JSON Profiles.
2. Give the profile a name (for example, json ) and a description.
3. For all the profile options, select Any.
75

Note For tighter security, you can set the maximum values instead of
selecting Any. You need to adjust these parameters as your API grows.
4. Click the Value Meta Characters tab and add the characters to disallow, as appropriate. For this example,
disallow the following:

EOT
BS
TAB
LF
CR
ESC
5. On the Sensitive Data Configuration tab, enter the Element names of any sensitive data that you do not
want logged. This may include any PII that you need to disallow, such as a customer name and address. For this
example, you are storing Employee Identification Numbers (EIN), which should not be displayed, so type ein, and
click Add.
6. Click Create, and click Apply Policy.
To enable methods
1. Navigate to Security >> Application Security : Headers : Methods, and click Create.
2. From Select Method, add PUT, and click Create.
3. Repeat step 2 for DELETE, OPTIONS, and PATCH.
Note In BIG-IP ASM 11.6.0, HTTP methods allow you to define global
options for permitted HTTP methods. In BIG-IP ASM 12.0.0 and later, you
can specify individual HTTP methods that the system allows for each
endpoint. Additionally, you can use an iRule to allow or deny specific HTTP
request methods against certain paths.
76

To define accessible and inaccessible URLs for your API

1. Navigate to Security >> Application Security : URLs : Allowed URLs : Allowed HTTP URLs, and click
Create.
2. Add URLs that you want the customers to be able to access. For our example, for URL Example:*, type /
customers, and add a URL Description.
3. Clear Signature Staging, and click Create.
4. For URL Example: *, change Explicit to Wildcard, and type /customers/*.
5. Clear Perform Staging.
6. In Learn Explicit Entities, select Never (wildcard only) and add a URL Description, and click Create.
To modify security policy
1. Navigate to Security >> Application Security : Parameters : Parameters List, and click Create.
2. For Parameter Value Type, select JSON value.
3. For Parameter Name, select Wildcard and type a name (for example, customer).
4. Clear Perform Staging and Allow Empty Value.
5. Click Create.
To delete wildcards
1. Navigate to Security >> Application Security : Parameters : Parameters List, select the wildcard *
parameter, and click Delete.
2. Navigate to Security >> Application Security : URLs : Allowed URLs : Allowed HTTP URLs, select the
wildcard * URL, and click Delete.
You can now apply the policy to a virtual server, and set the policy enforcement mode to Blocking.
77

Validation
Validation
You can test API URLs using smoke testing. Smoke testing allows you to use the API as if you were in a production environment.
Even if your API is still being developed, you can conduct smoke testing and regression testing in a non-production environment
to identify issues with the policy.
In this example, smoke tests are run against a sample API, learning the URIs, parameters, and various positive enforcement
entities. The enforcement mode is set to Blocking, and tests are run again. Chaos Monkey is also used to test the policy against
a variety of attack vectors, including null byte, directory traversal, disallowed HTTP methods, and others. These vectors are
tested against a variety of paths to make sure requests are blocked, alarmed, and/or logged as specified in the configuration.
78

Yes
No

Yes
No

Yes
No

Send
BIG-IP ASM EVENT LOGGING

Log display formats
BIG-IP ASM Event Logging

When appropriately configured and integrated with a security-event management process, the BIG-IP ASM system captures and
allows visibility and insights into forensic data. You can use the BIG-IP ASM pre-configured logging options or customize them.
When logging to a remote destination, see product documentation to determine whether a custom format is required.
Note F5 technology partner ArcSight sends logs in Common Event Format
(CEF), which is a standard for the Security Information and Event
Management (SIEM) industry. Many logging and reporting products can
properly consume messages in this format.
For more information and guidance, see Logging Considerations and AskF5 article SOL9435: Overview of the Storage Format
option for a remote logging profile.
Log display formats

When the BIG-IP ASM logging format and log server are appropriately configured, the system logs every violation identified in a
specific request as a single log message.
Violation logs run at the command line

In the following example violation log message at the command line, the violations for a specific request and support ID number
appear in bold text for emphasis.
Jan 10 09:15:37 bigip.f5demo.com ASM:unit _ hostname="bigip.f5demo.

com",management _ ip _ address="10.128.1.245",http _ class _ name
="/demo/dvwa.vlab.2",web _ application _ name="/demo/dvwa.vlab.2",policy _
name="/demo/dvwa.vla b.2",policy _ apply _ date="20160110
09:14:34",violations="Illegal meta character in value,Attack signature
detected,Illegal parameter value length",support _
id="623951107638431468",request _ status="blocked",response _ code="0",ip _
cli ent="10.128.10.1",route _ domain="0",method="GET",protocol="HTTP",query _
string="id=%27OR+1% 3D1. . .
Support ID
The support ID number identifies the request and is associated with the local request logs, manual learning suggestions, and the
remotely logged message.
Violations
The violations found in the previous example include the following:
Illegal meta character in value.
80

Log display formats
Attack signature detected.

Illegal parameter value length.
Violation log in the Configuration utility

In the BIG-IP ASM Configuration utility, the log for this request displays as follows:
Figure 3.1 Violations displayed on the Request Details tab in BIG-IP ASM Configuration
utility
Under the Request Details tab, the Violations area shows violations triggered by the request and identifies violation types. The
Learn column indicates whether the current security policy needs to learn this violation in order to pass it.
The log message also includes the full query string and POST data, which may be used to determine whether a formatted
request is legitimate or malicious.
81

Remote logging
Note Query string data is constrained by the maximum entry limit.
Logging both valid and violation requests may significantly increase size of your logging files...
By default, the local log storage is finite with a maximum capacity of 3 million records stored across all BIG-IP ASM security
policies and 2 GB in database table size.
Log entries are rotated out on a strict age basis. If you log multiple applications locally, it is possible for one application to
generate more than its share of messages, filling the log and pushing out entries for other applications before they can be
investigated.
The local log provides detailed information for all learning suggestions. If the log rate is too high, it is possible for the BIG-IP ASM
system to lose detailed information for learning suggestions that are current for the policy.
Remote logging
Local logging may significantly impact disk performance, especially on systems with slow disk subsystems.
F5 recommends externally logging all or at very least all illegal requests to a security information and event management (SIEM)
system for better data retention, searching, event correlation, and scalability.
For logging on remote storage, TCP and UDP are used for log delivery. UDP has lower overhead but can only log up to 1KB of
data per log entry, while TCP delivers greater reliability and allows up to 64KB of data per log entry. This greater capacity for data
makes TCP a better choice as it allows storing complete log entries.
F5 recommends using session tracking to log only violations rather than all requests. Session tracking allows you to log all
requests which cross specific violation thresholds for only specific sessions. This reduces load and data retention requirements
by capturing full requests for only suspicious activities without logging the full requests for all sessions.
When using Remote Storage type Remote in BIG-IP 11.6.0, or Comma Separated Values in BIG-IP 12.0.0, consider the order
in which the Selected Items are defined in the Storage Format.
By default, the full request is sent in the middle of the log entry. This may cause items such as violations to be lost if the log data
limit is met before they appear. You can set the Maximum Request Size and Maximum Query String Size to fix this problem.
See the following table for recommended settings.
Note BIG-IP ASM 12.1 and higher supports multiple remote logging profiles.
82

Remote logging
Table 3.1 Log format configuration options

BIG-IP ASM 12.0.0 and later
Limit Request Size
Limit Query String

Size
Specify Storage
Format
Comma-Separated Values
Yes
Yes
Yes
Key-Value Pairs
Yes
Yes
No
Common Event Format (ArcSight)
Yes
No
No
BIG-IQ
Yes
Yes
No
BIG-IP ASM 11.6.0
Limit Request Size
Limit Query
String Size
Specify Storage
Format
Remote (CSV)
Yes
Yes
Yes
Reporting Server (Key-Value Pairs)
Yes
Yes
No
ArcSight (CEF)
Yes
No
No
83

Yes
No

Yes
No

Yes
No

Send
POLICY TUNING AND ENHANCEMENT

Traffic Learning
Policy Tuning and Enhancement

The Policy Builder is the automated tool with which you create a securitypolicy. You can run the Policy Builder to build a new
security policy, or to update an existing security policy. Policy Builder combines manual and automatic tuning of BIG-IP ASM
security policies. It can run in automatic or manual mode, or it can be disabled.
BIG-IP ASM 12.0 Policy Builder updates

Several updates have been made to Policy Builder for version 12.0.0, including the following:
Staging, enforcement, and learning suggestions can be configured manually or by the BIG-IP ASM system.
Security checks Learn, Alarm, and Block are now system-wide settings integrated with Policy Builder.
An improved learning suggestions mechanism handles requests, with or without violations, for manual and automated policy
building.
Traffic Learning
Learning suggestions can result in policy changes, such as adding entities, disabling an attack signature, or making the policy
more robust based on characteristics of the traffic.
In BIG-IP 11.6.0, learning suggestions are displayed on the Traffic Learning page at Security >> Application Security: Policy
Building: Traffic Learning.
Figure 4.1 BIG-IP ASM 11.6 Manual Traffic Learning screen
In BIG-IP 12.0.0 and later, the configuration for the Enforcement Mode, Learning Mode, Policy Type, and Learning Speed
85

Traffic Learning
is on the Learning and Blocking Settings page: Security >> Application Security : Policy Building : Traffic Learning.
Figure 4.2 BIG-IP 12.0 Traffic Learning page
Table 4.1 Examples of Policy Builder Learning Suggestions

Event
Suggestion
An attack signature violation due to a false positive
Disable attack signature.
Traffic entities not in the policy, such as

parameters (and their characteristics)
Add entity to policy.
When using the manual mode in BIG-IP 11.6.0, you can modify a policy without having any correlated or weighted suggestions
from the BIG-IP ASM system.
In BIG-IP 12.0.0 and later, Policy Builder runs in the background to make it easier for you to make policy modification decisions
when in manual mode.
The BIG-IP ASM system provides suggestions based on the number of requests and how often a signature is triggered. The
system also displays a request violation rating based on statistical calculations from different sessions and client IP addresses,
with a learning score on a scale from 0 to 100 percent.
If using Policy Builder, once a suggestion reaches 100 percent, the BIG-IP ASM system automatically accepts it. If you are using
the manual policy builder, the suggestion stays on the Traffic Learning page until you accept it.
When you accept a suggestion, it is added to the policy. You also can delete suggestions. If you delete a suggestion, it is
removed and can be learned again. If you ignore the suggestion, it is hidden.
You can accept a suggestion at any time in either Policy Builder or in manual mode.
86

Note The default learning suggestion filter uses a 5-100 percent learn score
to filter out suggestions with a single occurrence or those not likely to be a
false positive.
This section covers guidelines for common configuration tasks involved in setting up a new policy.
Determine and configure sensitive parameters

Sensitive parameters include private data such as credit card numbers and other personally identifiable information (PII). F5
recommends that these parameter values be masked from logs. In some cases, masking is mandatory for regulatory compliance.
The easiest method to determine whether sensitive information exists, is to request from the application owner, a list of the
sensitive parameters for your application, such as password-based accounts, sensitive session data, and other parameters.
Another method to determine whether sensitive information exists, is to use parameter learning to create suggestions in the entity
learning section. Parameter learning accumulates parameters present on the site, which you can then examine and determine
whether each is sensitive. Parameters can be targeted by name and value.
For more information, see Masking Credit Card Numbers in Logs in BIG-IP Application Security Manager: Implementations.
Create policy templates

F5 recommends that you create a baseline policy for your environment, which includes the basic security requirements that are
embedded in the policy components. You can make these policies into a template in the BIG-IP ASM system configuration and
re-use them as a base for any future policies that you create for the environment.
For more information, see UPDATE THIS LINK
Disable case sensitivity in policies

By default, the BIG-IP ASM system is case-sensitive; however, to reduce the chance of false positives, F5 recommends that you
create policies with case sensitivity disabled.
While most web applications do not treat URIs with case sensitivity, some do. In such applications, example.html and
Example.html may see different web pages, each with their own associated content, parameters and security access controls.
In such cases, enabling case sensitivity is required.
Disable Illegal meta character in value

Unless your application requires a strict security posture, you can disable the Illegal meta character in value violation.
Enforcing against illegal meta characters involves a tuning period during which alarms are tuned down or changed to Allowed for
a specific parameter or for the policy in general.
87

Some meta characters are considered risky (such as "<" and " ' "), but most attacks taking advantage of these commonly abused
meta characters have matching attack signatures.
Configure vulnerability scanners

Vulnerability assessment services identify, classify, and report potential security holes or weaknesses in web site code. The
BIG-IP ASM system integrates with vulnerability assessment services such as IBM Security AppScan Enterprise, Hailstorm,
QualysGuard, HP WebInspect, and WhiteHat Sentinel. It also integrates with other vulnerability assessment tools through the use
of a generic scanner.
To use vulnerability assessment scanners, you need to identify and configure the scanners' IP addresses in the IP address
exception section.
For more information, see Using Vulnerability Assessment Tools for a Security Policy in BIG-IP Application Security Manager:
Getting Started.
Customize default response pages
The BIG-IP ASM system uses a default blocking response page to notify users when a request has been blocked by a security
policy. It also uses a default page to display when login violations occur.
The default blocking response contains one variable, <% TS.request.ID() %>, which BIG-IP dynamically replaces with a
support ID reference number for the specific request or response that triggered the blocking event.
You can easily create a custom blocking response page for either general violations or login-specific violations. You can style it to
match your organization or application style or branding. F5 recommends that you customize the page so at a minimum it
includes contact information and steps that users can take to address the violation.
F5 recommends that you host required assets for the blocking response page outside the BIG-IP environment serving it. For
example, you can place assets on CDN (Content Delivery Network)/"sorry server".
Because of potential Cross Origin Resource Sharing (CORS), assets stored on a CDN/"sorry server" may become unavailable to
the response page. If this happens, try placing assets like CSS stylesheets inline to the HTML markup as in the following code
example:
<!doctype html>
<html>

<head>
<meta charset="utf
8">

<meta httpequiv="XUACompatible"
content="IE=edge,chrome=1">

<title>Request Blocked | Company Acme</title>
<meta name="viewport" content="width=device

width">
88

<style type="text/css">

*, *:after, *:before {
webkitboxsizing: borderbox
mozboxsizing: borderbox
msboxsizing: borderbox boxsizing: borderbox }
html {

background: #fff

font: bold 16px/24px "Helvetica Neue Lt Std Light", "Tablet
Gothic", Helvetica, Arial, sans
serif
color: #000
}
body { width: 100% margin: 100px auto}
.logo { padding: 5px width: 100% display: block text
align: center
marginleft: 100px }
.logo img { padding: 8px max
height: 64px }
section .message { background: #fafafa color: #666 width: 410px
margin: 0 auto padding: 8px 15px 32px 15px border: 1px solid #e2e2e2}
Note F5 recommends that you serve the blocking response page assets
from a local sorry server and have the BIG-IP ASM system redirect violating
clients with the proper support ID.
F5 recommends that you do not embed images in the BIG-IP ASM response page.
For more information, see the AskF5 article SOL7825: Redirecting a blocking response support ID to an external error page and
Configuring What Happens if a Response is Blocked in BIG-IP Application Security Manager: Implementations.
Disallow malicious file types

If your application contains a dynamic list of file types, you can create a list of disallowed file types to block using one illegal file
type violation.
For most applications, F5 recommends that you block the following file types: bat, bck, bin, cfg, cmd, com, config, dat, dll,
eml, exe, exe1, exe_renamed, hta, htr, htw, ida, idc, idq, ini, log, nws, old, pol, printer, save, shtm, shtml, stm, sys,
wmz.
To disallow file types, you can enter them individually by navigating to Security >> Application Security > File Types >
Disallowed File Types Create, or you can import the following list in the XML policy configuration:
<disallowed _ file _ types>

<file _ type name="bat"/>
89

<file _ type name="bck"/>

<file _ type name="bin"/>
<file _ type name="cfg"/>
<file _ type name="cmd"/>

<file _ type name="com"/>
<file _ type name="config"/>

<file _ type name="dat"/>
<file _ type name="dll"/>
<file _ type name="eml"/>
<file _ type name="exe"/>
<file _ type name="exe1"/>
<file _ type name="exe _ renamed"/>

<file _ type name="hta"/>
<file _ type name="htr"/>
<file _ type name="htw"/>

<file _ type name="ida"/>
<file _ type name="idc"/>
<file _ type name="idq"/>

<file _ type name="ini"/>
<file _ type name="log"/>
<file _ type name="nws"/>

<file _ type name="old"/>
<file _ type name="pol"/>
<file _ type name="printer"/>

<file _ type name="save"/>
<file _ type name="shtm"/>
<file _ type name="shtml"/>

<file _ type name="stm"/>
<file _ type name="sys"/>
<file _ type name="wmz"/>
</disallowed _ file _ types>

For more information, see Adding File Types to a Security Policy in BIG-IP Application Security Manager: Implementations.

Learning suggestions provide a concise list of application components observed by the BIG-IP ASM system that are not found in
90

the security policy.

The BIG-IP ASM system generates learning suggestions for violation types that have the Learn flag enabled on the Blocking
Settings page (in BIG-IP 11.6.0) or the Learning and Blocking Settings page (in BIG-IP 12.0.0 and later).
When the system receives a request triggering a violation, it updates the Manual Traffic Learning page (in BIG-IP 11.6.0) or the
Traffic Learning page (in BIG-IP 12.0.0 and later) with learning suggestions based on information from the violating request.
You can review learning suggestions to determine whether the listed requests triggered a legitimate security policy violation or
whether you need to update the security policy to allow such requests.
Learning suggestions enable you to create policy entities based on actual traffic. They provide the number of times each violation
has occurred and a list of the requests that contain violations. From this information, you can make policy decisions.
Accept or clear learning suggestions

As part of tuning your policy, you need to decide whether to accept a learning suggestion, add it to the policy, or clear it and
remove it from learning suggestions. Consider the following questions:
Does the violating entity make sense for the application? (For example: Does the application make use of .WOFF file types?)
Can the application owner provide a summary of which entities should be allowed into the application?
How many learning suggestions exist for the given entity? Numerous occurrences may indicate a false positive.
General guidelines for manual learning suggestions

There is a limit to the number of learning suggestion records that can be stored. To avoid exceeding retention limits and losing
suggestion data, F5 recommends that you remove flags from violations once you have captured the necessary information.
Further, F5 recommends that you enable learning only for policies that you are actively modifying or configuring, or for
applications you are actively tuning.
Learning suggestion records expire at a rate determined by the number of violations set in Blocking Settings and the number of
policies using traffic learning. Since learning suggestion requests are not indefinitely retained, F5 recommends that you regularly
review suggestions on any policy that the system is actively learning, or use the Policy Builder.
To see the impact of new or updated signatures, enable learning suggestions on all or select violations when updating attack
signatures. Doing so can help ensure proper policy configuration and reduce potential false positives. Learning suggestions do
not sync or move between the BIG-IP ASM system systems and therefore can only be found on the active unit that learned the
traffic. When a failover occurs, you must fail back to the original system to access learning suggestions. Also, learning
suggestions are cleared when a system is upgraded. F5 recommends that you accept or clear all learning suggestions before
you upgrade your system.
For more information, see Refining Security Policies with Learning in BIG-IP Application Security Manager: Implementations.
91

Tuning violations
Tuning violations
Policy violations are displayed on the Policy Building: Traffic Learning page. An important part of tuning your policy is to fix
violations and manage issues associated with false positives. For example, legitimate application traffic may be disrupted if your
policy is blocking violation types that create false positives. Even if blocking for a violation is off, false positives can trigger alarms,
and an excess of improperly logged violations can create noise that may distract from real issues.
In many cases, violations show both malicious traffic and legitimate traffic. If the system is blocking legitimate traffic (a false
positive), you can address these violations by accepting the related suggestionalso known as loosening the policy--even
though malicious requests were also detected by the same violation.
This may seem counterintuitive, since the policy, by design, successfully detected and blocked malicious traffic, but it is better to
loosen the policy than to create false positives or excessive, improperly logged violations.
Tuning based on deployment environment

Use the following policy tuning guidelines for any violation, based on the deployment environment:
Non-production environment (QA or Test): Only valid traffic requests should exist in a non-production environment; however,
policy violations may still occur with a new policy or as a result of an application update.
If vulnerability scanning and penetration testing are performed, make sure to exclude that traffic from Learning to distinguish it
from legitimate traffic. Address all generated violation types, and accept all resulting learning suggestions for the security policy.
Production environment: Once a mature policy is deployed to production, most violations will likely represent malicious
attacks; however, some false positives may occur, depending on how much tuning you did before deployment. Some violation
types are more prone to false positives than others.
Other than volumetric attacks, most real attacks do not cause high volumes of traffic, so a large number of incidents associated
with a particular violation type increases the likelihood that false positives exist.
Tuning based on violation type and deployment environment
The following section lists the most common policy violation types and how to treat each, based on whether they occur in a
production or non-production environment.
Illegal File Type

Triggered by: Request accesses a file type that is not found in the security policy.
Non-production environment: Accept. This violation typically occurs when new application resources are added or new
technology is adopted in the application.
Production environment: Unless these violations occur in conjunction with a new application update, violations of this type in
a production environment are generally malicious and you should not accept as a learning suggestion or loosen the policy.
92

Tuning violations
HTTP protocol compliance failed

Triggered by: Request does not comply with a number of HTTP protocol compliance checks.
Non-production environment: Accept immediately.
Production environment: Do not accept. Regard as an attack. If data shows high number of incidents, review several of the
incidents for malicious traffic. If samples are malicious, ignore the learning suggestion and do not disable the violation. If the
incident count is low, these are very likely malicious. However, application updates or new types of clients may rarely trigger this
type of violation. If false positives are evident, disable the improper firing protocol compliance check.
Illegal Method
Triggered by: Request uses the HTTP method not allowed by the security policy.
Non-production environment: Accept immediately.
Production environment: Regard new methods triggered as attacks. If you observe a high number of incidents, review the
data for false positives. These false positives are typically caused by a new type of client accessing the application. To permit a
new client type, update the policy to allow the new method.
Evasion Technique Detected

Triggered by: the BIG-IP ASM system fails to normalize requests. Normalization is the process of decoding requests that are
encoded. Several sub-violations for this violation exist.
Non-production environment: Accept, including all sub-violations.
Production environment: False positives are not uncommon for this violation type in the production environment. If they occur
after an application update and the incident count is high, sample the incident data to confirm that it is legitimate traffic. If the
traffic is legitimate, accept the learning suggestion.
Note Evasion Technique checks are global for the policy. If you accept the
learning suggestion for any subviolation, all Evasion Technique checks will be
disabled. The risk of disabling this check is mitigated by other security
checks, which occur after normalization process.
For more information on this violation type, see AskF5 article: SOL 7929: Working with Evasion technique detected violations.
Multiple Decoding Passes sub-violation

Triggered by: Any request requiring at least the configured number of legal decoding passes to achieve normalization. A
sub-violation of the Evasion Technique Detected violation, it controls the BIG-IP ASM systems normalization process, in general,
as requests are processed. The default value for this setting is 2 decoding passes. This setting impacts operation of the
normalization process for the security policy, even if the Multiple Decoding sub-violation is not enabled.
93

If this sub-violation is disabled, requests not exceeding the configured number of decoding passes can still trigger a violation of
other security checks. If requests exceed the configured number of decoding passes, a double-encoded request matching a
signature still causes a signature violation after decoding. In the same circumstance, if the sub-violation is enabled, such requests
generate a violation for both the signature and the sub-violation.
Non-production environment: Accept.
Production environment: False positives may rarely occur due to application updates. Review incidents for false positives. If
false positives exist, accept learning suggestion, which disables the sub-violation. Since normalization (including at least two
decoding passes) of requests occurs independently of this sub-violation, the policy will likely remain effective in mitigating attacks
using multiple encoding passes in an attempt to evade detection.

Attack signaturesare rules or patterns that identify attacks or classes of attacks on a web application and its components. When
the BIG-IP ASM system receives a request, the systemapplies the attack signatures associated with the security policy to the
request. If, in the request (or response), a pattern matches one or more of the attack signatures, the system generates theAttack
signature detectedviolation. If the enforcement mode is blocking, the system also blocks the request and issues the Blocking
Response Page to the client making the request.
False positives
Indicators of potential false positives include the following:
High occurrence of a specific attack signatureparticularly a new one--triggering high volume of violations. The signature is likely
detecting a portion of application code as an attack.
Newly implemented signature registering immediate violations. When adding new signatures to a policy, either through signature
updates or through application of additional current signatures, F5 recommends that you turn on learning for the signatures. If
new signatures register immediate violations, review the requests to confirm legitimate blocking or to see if the signature is
causing a false positive.
Find and fix false positives

Find the request that triggered the violation. F5 recommends that you turn on Learning for signatures to help catch the
request that triggered the violation.
Review the request for malicious content. If possible, consult the application owner, who may be able to help determine
valid traffic from malicious traffic.
Correct the false positive. Your action depends on the nature of the false positive and your ability to fix it. There are common
methods for correcting a false positive while maintaining good security posture:
Disable the attack signature (either globally or on at the parameter level).
94

Create a user-defined attack signature (may involve a high level of complexity).

Open an F5 support case to request attack signature tuning.
For more information, see Open a support case.
If the violation is not a false positive, nothing more needs to be done.

F5 recommends that you transition a security policy's enforcement mode from Transparent to Blocking to put security settings
into effect after you have reduced the chances of false positives occurring.
The following table shows the various violation types and the recommended period they should spend in the production
environment without triggering false positives before you transition the enforcement mode to Blocking.
Table 4.2 Transition period for the BIG-IP ASM system violations
Policy Builder trusted IP
Disable
Ignore in Anomaly Detection
Enable
Ignore in Learning Suggestions
Enable
Never block this IP Address
Disable
Enable if scanner will scan and report on back-end security vulnerabilities. Illegal
Method.
Illegal HTTP Response.
Request length exceeds defined buffer size.
Modified BIG-IP ASM cookie.
Access from disallowed User/Session/IP.
Access from disallowed geolocation.
Attack signature detected. Specific signature detected. Non-human based clients
signature set (optional.)
Never log traffic from this IP Address
Disable if evidence of violation must be shown (for security auditors, for example).
Enable to reduce spam violations in event log and make it easier to find real-time
attacks in production environment.
Attack signature detected: Remove attack signatures out of staging, resolve issues
with attack signatures triggered by false positives.
Illegal Redirection Attempts.
Ignore IP Address Intelligence
Enable
95

Customize default response pages

The BIG-IP ASM system uses a default blocking response page to notify users when a request has been blocked by an
Advanced policy guideline.
Application language
Every web application has language encoding that determines thecharacter set the browsers use to both display the page and
send any submitted form data. The BIG-IP ASM system supports multiple language encodings.
You can configure the language for new web applications (or those youwant to reconfigure), and you set the language encoding
using the Deployment wizard. F5 recommends that you select the default setting,Auto detect, when it is available. The
Application Security Manager determines the acceptable character set for the application.
Note Once you set the web application language, you cannot change it
unless you reconfigure the web application completely, losing all settings. For
information about reconfiguring web applications, see Returning a web
application to a new, unconfigured state.
Application language guidelines

Make sure Policy Builder detects correct character encoding language to avoid false positives due to character encoding.
If manually setting the application language, make sure you know the character set the application will use for HTML form
submission.
For more information, see the Ask F5 article SOL6335: Overview of encoding language settings for BIG-IP ASM.
The BIG-IP ASM system checks to see if the sequence of bytes is valid within the defined encoding. Sequences not found trigger
the Failed to convert character violation.
However, the BIG-IP ASM system attempts to parse the data, even when the encoding is wrong. For example, a web application
configured with ISO-8859-8, while the web site sends pages in UTF-8 encoding, requests generated from pages contain UTF-8
encoded data. If the application cannot parse the data as ISO-8859-8, but can validate it as ISO-8859-8 characters in UTF8, the
request does not cause a Failed to convert violation.
JSON/XML considerations
By default, the BIG-IP ASM system expects HTML form data. If an application contains either XML or JSON protocols, the
security policy accounts for this using content profiles.
F5 recommends that you associate an XML/JSON content profile for generic policies that create wildcard entities.
XML/JSON for content type requests (URL)
96

For content-type-based XML/JSON, a generic content profile using header-based content validation must be associated with a
URL wildcard entity.
For more information see Adding JSON Support to an Existing Security Policy in BIG-IP Application Security Manager:
Implementations.
XML/JSON for HTML form data parameter value

For XML/JSON protection at the parameter value level, identify the specific parameter that contains the protocol, and apply a
generic content profile; this enables the BIG-IP ASM system to process the traffic appropriately.
Large file uploads

The BIG-IP ASM system has a default limitation of 10 MB for incoming HTTP requests. You can increase this limit up to 30 MB.
When an incoming request exceeds the defined buffer size, the Request length exceeds the defined buffer size violation
setting determines whether a request will be blocked or bypassed.
Set this violation to Blocking if the protected environment is not expecting large file uploads. Requests will bypass the security
policy after inspecting up to 10KB of the request (containing the requests' headers, URIs, and initial request payloads).
For more information, see the AskF5 articles: SOL935: Error Message: Request length exceeds defined buffer size and
SOL17573:The BIG-IP ASM system does not need to be disabled to allow large file uploads.
Working with external caching server (CDN)

X-Forwarded-For (XFF) headers: The traffic that passes through CDNs is usually NAT. CDNs use the initiating client IP
address HTTP request and add it as a header to that request and send it on to its destination.
You can set the BIG-IP ASM system to trust the IP address contained within the HTTP header instead of the NAT IP address from
the CDN. Trusting the X-Forwarded-For (Header name may vary depending on the CDN) is generally preferred, as you will see
the actual client IP address in the log files.
For a DoS profile, the Insert X-Forwarded-For should also be enabled. It uses a default page to display when set in the HTTP
profile used on the virtual server being protected.
Mandatory HTTP header violation searching for CDN based headers: Some HTTP headers should always appear in
traffic that was forwarded by CDN servers. These headers can be added to a policy and checked to verify that traffic came from
the CDN.

You can track user sessions using login pages that are configured in the BIG-IP ASM system, or you can have the policy retrieve
the user names from the BIG-IP APM system.
97

The advantage of using session tracking is that you can identify the user and the unique session for each request, which provides
additional data points that you can use in combination with the source IP address to investigate suspicious traffic.
Whether you create them manually or automatically, login pages define the URLs, parameters, and validation criteria required for
users to log in to the application. User and session information is included in the system logs so you can track a particular
session or user. The system can log activity, or can block a user or session if either triggers more violations than the configured
threshold allows.
Figure 4.3 BIG-IP ASM 12.0 New Login Page
You can use login pages in the following ways:

Track a specific user instead of using the authenticated session. Tracking by IP address is impractical for a number of
reasons. .
Block suspicious sessions once specific limits are triggered. You can configure limits as a number of violations per unit of
time, per user, or per session. This might be an attacker with automated scanner-tools that are generating a high rate of
alerts per time frame. If the limits are exceeded, the attacker is blocked for a specific amount of time.
98

The default blocking response contains one variable, <% TS.request.ID() %>, which BIG-IP dynamically replaces with a
support ID reference number for the specific request or response that triggered the blocking event.
You can easily create a custom blocking response page for either general violations or login-specific violations. You can style it to
match your organization or application style or branding. F5 recommends that you customize the page so at a minimum it
includes contact information and steps that users can take to address the violation.
F5 recommends that you host required assets for the blocking response page outside the BIG-IP environment serving it. For
example, you can place assets on CDN (Content Delivery Network)/"sorry server".
Because of potential Cross Origin Resource Sharing (CORS), assets stored on a CDN/"sorry server" may become unavailable to
the response page. If this happens, try placing assets like CSS stylesheets inline to the HTML markup as in the following code
example:
<!doctype html>
<html>

<head>
<meta charset="utf
8">

<meta httpequiv="XUACompatible"
content="IE=edge,chrome=1">

<title>Request Blocked | Company Acme</title>
<meta name="viewport" content="width=device

width">
<style type="text/css">

*, *:after, *:before {
webkitboxsizing: borderbox;
mozboxsizing: borderbox;
msboxsizing: borderbox;boxsizing: borderbox;}
html {

background: #fff;

font: bold 16px/24px "Helvetica Neue Lt Std Light", "Tablet
Gothic", Helvetica, Arial, sans
serif;
color: #000;
}
body { width: 100%; margin: 100px auto;}
.logo { padding: 5px; width: 100%; display: block; text
align: center;
marginleft: 100px; }
.logo img { padding: 8px; max
height: 64px; }
section .message { background: #fafafa; color: #666; width: 410px;
margin: 0 auto; padding: 8px 15px 32px 15px; border: 1px solid #e2e2e2;}
99

Note F5 recommends that you serve the blocking response page assets
from a local sorry server and have the BIG-IP ASM system redirect violating
clients with the proper support ID.
Monitoring and configuration

User tracking events are monitored through the standard Reporting UI pages within BIG-IP ASM Security.
For more information, see Configuring Application Security Session Tracking in BIG-IP Application Security Manager:
Implementations or Tracking User Sessions in BIG-IP Application Security Manager: Implementations.

You can use Policy Diff in the BIG-IP ASM system to compare two security policies, view the differences between them, and
copy the settings from one policy to the other.
The most common uses for Policy Diff are:
Auditing two policies to determine the differences between them.
Comparing and merging a production policy with a policy running in a staging environment.
Comparing two policies

The following figures show how to compare two different BIG-IP ASM policies and merge them into a new policy:
Figure 4.4 Using Policy Diff tab to merge two policies
After selecting the two policies, you can compare them.

The following figure shows the differences between the two policies. Each policy has a modified signature list. Policy /common/
production shows that /config/access is disabled and policy /common/staging shows that /dms/AggreSpy is disabled.
100

Figure 4.5 BIG-IP ASM Policy Diff screen
You can now use the Policy Diff functionality to only monitor and audit the changes, or to move the changes from the policies to
a new copy of the policy, which contains both modifications.
For more information, see Maintaining Security Policies in the BIG-IP ASM Implementations Guide.
101

Yes
No

Yes
No

Yes
No

Send
REGULATORY COMPLIANCE
Regulatory Compliance
This chapter contains guidance to enhance BIG-IP ASM security policies and improve compliance with various regulatory
regimes.
Review this chapter to determine the type of policy you want to use as your basis for compliance, then create an appropriate
security policy or create a unique policy based on your specific security needs.

You may be responsible for achieving compliance with one or more regulatory regimes. The difficulty is that regulatory regimes
are rarely specifically defined web application firewalls (WAFs).
Many regulatory compliance mandates provide few specific implementation requirements and leave areas open to interpretation.
F5 recommends using the BIG-IP ASM system to secure your web application environment with consideration for the security
posture of the organization, the sensitivity and threat surface of the applications, and the application security resources available.
Whether a particular implementation satisfies the regulations is often subject to interpretation. F5 recommends consulting
organization security policies, auditors, and regulatory bodies to determine whether applications are compliant with a particular
regime.
This chapter provides guidelines to ensure that the BIG-IP ASM system is configured and an appropriate policy is created for
implicated applications.
These guidelines are intended to:
Make sure that WAF-specific requirements are met.
Make sure that the introduction and configuration of the BIG-IP ASM system does not accidentally expose the organization
to non-compliance.
Make sure that the BIG-IP ASM system is used to achieve commonly requested regulatory requirements that are not
specific to WAFs, where the BIG-IP ASM system can improve compliance or function as a compensating control for
security purposes.
These guidelines are limited to the configuration of the BIG-IP ASM system behavior and security policy.
Regulations that govern the overall device posture and administrative controls are not within the current scope of this document.
Examples of what is not covered include overall device hardening, multi-factor requirements for administrative access, and device
patching.
103
Important These are guidelines only. Implementation of these

recommendations does not guarantee compliance.

Open Web Application Security Project (OWASP) is a comprehensive resource for secure web application coding guidance,
application testing procedures, and vulnerability categorization and mitigation strategies. OWASP periodically updates and
publishes a Top 10 list of vulnerabilities. (This link sends you to an external site.) The Top 10 list includes vulnerabilities against
which organizations should be particularly diligent to protect their applications. The BIG-IP ASM system can detect and report
exploit attempts seeking to take advantage of many of these vulnerabilities.
The following table lists BIG-IP ASM system components and capabilities that you may find useful when creating a security policy
to mitigate the listed vulnerabilities. Where applicable, the Policy Type that will automatically include the mechanism is listed in
parentheses.
Table 5.1 OWASP compliance
Vulnerability
A1
Injection flaws
BIG-IP ASM Controls
Attack signatures
Meta character restrictions (Enhanced or Complete)
Parameter value length restrictions
A2
Broken authentication and

session management
Brute Force protection

Session tracking
HTTP cookie protection (Enhanced)
Important BIG-IP APM may be required for applications with

very weak or vulnerable authentication mechanisms.
A3
Cross-site scripting
Attack signatures
Parameter meta characters (Comprehensive)
Parameter value length restrictions
Parameter type definitions (such as integer)
104
Vulnerability
A4
Insecure direct object

reference
BIG-IP ASM Controls

File types (Fundamental)
URL (Enhanced)
URL flows (Comprehensive)
Attack signatures (Directory traversal)
A5
Security misconfiguration
Attack signatures URL (Enhanced)
A6
Sensitive data exposure
Data Guard
A7
Missing function level access

control
Session tracking
File types (Fundamental) URL (Enhanced)
A8
Cross-site request forgery

(CSRF)
CSRF protection (Comprehensive)
A9
Using components with

known vulnerabilities
Attack signatures
Unvalidated redirects and

forwards
Redirection protection
A10
Vulnerability scanner integration
Location header whitelisting URL (Enhanced)


A commonly requested compliance assistance for the BIG-IP ASM system is associated with the Payment Card Industry Data
Security Standard (PCI DSS). WAFs are specifically referenced, in section 6.6 of the PCI DSS 1.1 (Sept., 2006), as one control
mechanism that an organization can implement to verify whether Internet-facing web applications are placing cardholder
information at risk.
The current version of the PCI DSS 3.1 (this link sends you to an external site) lists WAFs as mechanisms which organizations can
use to satisfy section requirements. You should become familiar with the entire DSS; specifically, section 6.5 describes the
application vulnerabilities that developers should take particular care to guard their applications against.
The following table lists requirements and BIG-IP ASM controls that you may find useful when pursuing PCI DSS compliance.
Where applicable, the Policy Type that will automatically include the mechanism is listed in parentheses. This table is similar to
the OWASP Top 10 list. You can see OWASP resources and related materials to improve the security of web applications when
pursuing PCI DSS compliance.
105
Table 5.2 PCIDSS compliance

PCI DSS Requirements
6.5.1
Description
Injection flaws
BIG-IP ASM Controls

Attack signatures
Meta character restrictions (Enhanced or Comprehensive)
Parameter length restrictions
6.5.2
Buffer overflows
Attack signatures
Length restrictions (Fundamental or Comprehensive)
6.5.3
Insecure cryptographic storage
Not applicable
6.5.4*
Insecure communications
Implement an http to https redirect iRule to require

encryption of all traffic and use rewrite profile if needed to
rewrite explicit HTTP references.
Implement server-side re-encryption via the Server SSL
profile.
Configure the BIG-IP ASM system to enforce URL flows
to prohibit HTTP requests (Comprehensive).
6.5.5
Improper error handling
Allowed Response Codes

Attack signatures (Response checking required)
6.5.6
High Risk vulnerabilities (as

defined by the organization
under 6.1)
BIG-IP ASM controls may be applicable depending on

the specific vulnerability.
6.5.7
Cross-site Scripting
Attack Signatures Parameter meta characters

(Comprehensive)
Parameter length restrictions
6.5.8
Improper Access Control
Session Tracking
Attack signatures (Forceful browsing)
File types (Fundamental)
URL (Enhanced)
6.5.9
Cross-site Request Forgery
CSRF Protection (Comprehensive)
* Specific requirements regarding SSL/TLS are new in PCI DSS 3.1. Specifically, the PCI DSS prohibits the use of SSL and TLS
version 1.0. For more information, see SSL Traffic Management in BIG-IP System: SSL Administration.
106
Additional regulatory compliance considerations

The following table lists additional PCI DDS considerations and F5 recommendations.
Table 5.3 Additional Payment Card Industry DDS requirements
Consideration
Logging. By default, the BIG-IP ASM system may log
cardholder data. This may contribute to data leakage.
Recommendation
Define all parameters that may include cardholder
data as Sensitive to prevent the values from being
logged. For more information, see Adding Entities to a
Security Policy in BIG-IP Application Security Manager:

Implementations.
RFC compliance. The PCI DSS does not mandate that
applications must comply with Requests for Comments
(RFC). However, non-compliant applications are vulnerable to
more threats.
Configure RFC compliance to minimize vulnerabilities.
Cardholder data leakage. The PCI DSS requires that

organizations ensure that cardholder data, such as social
security and credit card numbers, not be exposed in web
applications.
Use Data Guard.
Evasion techniques. The BIG-IP ASM system normalizes

inputs and blocks requests using common evasion
techniques. Make sure that evasion techniques are enforced.
Also make sure that when a technique is allowed to
enable application functionality that it does not expose the
application to additional risk.
Complete an evasion techniques policy audit
For more information, see Protecting Sensitive Data with
Data Guard in BIG-IP Application Security Manager:

Implementations.
For more information, Configuring Security Policy
Blocking in BIG-IP Application Security Management:

Implementations.
PCI report
The BIG-IP ASM system includes a PCI report that you can run to help assess whether a given security policy is providing
adequate controls for an application. Compliance is defined as properly securing the application. The PCI report is a useful data
point, but must be augmented by testing the application with web application vulnerability scanners, manual testing of suspected
sections of an application, and consultation with your organizations PCI auditors.

Among other reasons, the Health Information Portability and Accountability Act (HIPAA) was mandated to control the ways in
which security and privacy of protected health information (PHI) must be ensured by regulated organizations. HIPAA is a broad
and non-specific regulatory regime, and security policy authorities and security administrators are given a wide margin to
determine how to implement the requirements. While WAFs are not explicitly referenced, web applications are important vectors
for possible exposure of PHI and it is important to properly protect them. Additionally, there are specific requirements that a
BIG-IP ASM administrator must comply with.
107
HIPAA is primarily focused on:

Preventing accidental PHI exposure.
Ensuring that PHI is only accessed by authorized individuals.
Auditing and accounting all access to PHI and the systems that manage PHI.
Ensuring that PHI is properly encrypted at all times, both during transmission and at rest.
Disclosing any breach that compromises PHI in an accurate, complete, and timely manner.
The following table lists the requirements and BIG-IP ASM controls that you may find useful when pursuing HIPAA compliance.
Where applicable, the Policy Learning type level that will automatically include the mechanism is listed in parentheses.
Table 5.4 HIPPA compliance
Requirement
PHI Encryption. Network communications that

may include PHI must be encrypted at all times.
BIG-IP ASM Controls
Implement an http_to_https iRule to require

encryption of all traffic.
Implement server side re-encryption via serverssl
profile.
Configure the BIG-IP ASM system to enforce
URL Flows to prohibit HTTP requests (Complete).
Ensure strong encryption.
Data Leakage.
Data Guard may be customized to block or mask

requests including PHI if the administrator identifies
leakage in a web application.
PHI and PHI keywords are organization-specific.
You are encouraged to implement Data Loss
Prevention technologies to best protect PHI.
Logging. By default, BIG=-IP ASM may

incorrectly log PHI data which could lead to data
leakage.
Define all parameters that may include cardholder

data as Sensitive to prevent the values from being
logged.
108
Requirement
BIG-IP ASM Controls
Auditing. HIPAA is specifically concerned with

who accessed what, when, and how. This
includes comprehensive logging of all policy
changes and configuration changes to security
devices in the environment.
BIG-IP Audit Logging BIG-IP ASM Change

Logging Session Tracking

National Institute of Standards and Technology (NIST) does not require WAFs to specifically address the requirements stated in
the following documents, but you can use the BIG-IP ASM system to mitigate some of the concerns and requirements in them.
(Links send you to external sites.)
NIST Information Technology Laboratory

Guidelines on Securing Public Web Servers
Another part of NIST regulations requires that your BIG-IP system is securely hardened. For more information, see the NIST
Special Publication 800-53 in DevCentral.

The following table lists the requirements and BIG-IP ASM controls that you may find useful when pursuing NIST compliance.
Where applicable, the Policy Learning type level that will automatically include the mechanism is listed in parentheses.
Table 5.5 NIST compliance
Consideration
BIG-IP ASM Controls
Protocol Compliance
On the Policy Settings page, enable HTTP protocol compliance checks to allow
the BIG-IP ASM system to enforce proper usage of the HTTP protocol, limiting
automated and other non-browser clients from accessing the web application.
Evasion Techniques
On the Policy Settings page, enable evasion techniques to allow the BIG-IP
ASM system to find attempts to circumvent scanning and matching mechanisms,
enhancing the BIG-IP ASM system capabilities in enforcing security on the
application.
Login Enforcement
and Session Tracking
Configure the login page(s) for the application.

Enable Session Tracking and Login Enforcement. This allows the BIG-IP ASM
system to control which parts of the application are accessible only after a user
successfully logs in.
109
Consideration
BIG-IP ASM Controls
Brute Force
Protection
After the login pages are configured, add Brute Force Protection to your policy to
make sure that authenticated users are not using brute-forced credentials.
Attack Signatures
Attack signatures are enabled by default. The policy finds and enforces controls
for attempts to access predictable resources, such as active content libraries and
administrative folders.
File Types, URLs, and

Parameters
Enable Policy Builder to learn and populate a security policy, inspect traffic (requests
and responses), and build the application tree. This enables the BIG-IP ASM system
to enforce the policy and block access to URLs not specifically added and allowed
during the policy-building process.
You can choose to populate your policy with these application elements either
automatically or manually.
110

Yes
No

Yes
No

Yes
No

Send
COMMON DEPLOYMENT TOPOLOGIES

Common Deployment Topologies

The BIG-IP ASM system supports a variety of deployment topologies to secure applications, while it properly accommodates
unique network requirements, protected applications, and operational requirements.
This chapter provides an overview of the available the BIG-IP ASM system platforms and several common topology options,
including considerations for each. Specific and detailed configuration instructions are outside the scope of this document, but
may be found in articles and manuals on AskF5 and by searching DevCentral.

BIG-IP ASM is available on physical and virtual platforms, including the following:
BIG-IP hardware appliances
BIG-IP Virtual Edition
BIG-IP VIPRION
Platform choice determines the availability of topologies and scaling options. There are several factors to consider when you are
deciding on the appropriate platform, include the following:
SSL/TLS encryption requirements
Rate of environment growth.
Number of applications
Policy-building methods
Deployment environment (traditional data center, cloud, or private or public hybrid cloud)
BIG-IP ASM can be licensed as follows:
As a standalone BIG-IP ASM-only platform.
As part of the "Best" bundle of the Simplified Good/Better/Best licensing model or as an add-on license to BIG-IP LTM.
For more information, see the F5.com Simplified Licensing page.
Hardware appliances
The BIG-IP ASM system is commonly deployed with Device Service Clustering, as a redundant system. However, other
deployment configurations are available. For more information, see BIG-IP Device Service Clustering: Administration.
112

Hardware sizing
The BIG-IP ASM system performs best on hardware devices that are properly sized for the protected applications, and that have
the following:
Cryptographic hardware for offloading SSL/TLS computation
Hardware compression for offloading http compression computations
Solid-state drives for superior local I/O
Enough available RAM, particularly when using traffic learning on multiple applications
Enough CPU resources
Important RAM and CPU sizing recommendations for web application
firewalls vary widely by number and type of application, security policy
settings, and network conditions. Consult your F5 account team for
assistance in identifying the properly sized appliance for your security
requirements.
Upgrade hardware
Within BIG-IP hardware appliance series, each appliance is available in two models, which differ in CPU, SSL capacity, and other
characteristics:
Base model (n0n0)
Scale-Up model (n2n0)
Using a software license, you can upgrade most BIG-IP hardware appliances from a base appliance to a scale-up model in that
series. For most appliance series, you can purchase the base model and later increase performance by purchasing the scale-up
model. For example, if you purchased a 5050, using a software license key you can upgrade that model to a 5250, which nearly
doubles the capacity of the platform.
For more information, see the F5 Deployment Options page.
F5 FIPS models
Some F5 hardware appliances are available in a FIPS model for organizations storing their SSL/TLS private keys in a certified
Hardware Security Module (HSM). F5 FIPS models offer FIPS 140-2 level 2 compliance and also an interface to network HSMs
from Thales and Safenet.
For more information, see BIG-IP Platform: FIPS Administration.
113

vCMP support
Some hardware appliances support F5 vCMP virtualization technology to allow multiple virtual BIG-IP instances on a single
platform. A vCMP guest instance functions identically to a hardware appliance for the topologies described, as long as adequate
resources are assigned to the guest instance.
For more information, see vCMP for Appliance Models: Administration.
BIG-IP ASM Virtual Edition

BIG-IP ASM is available as a virtual appliance, either as a standalone BIG-IP ASM-only appliance or as part of the Best bundle
(for information on licensing, see F5.com Simplified Licensing page.
The BIG-IP ASM system can be deployed in cloud environments or as a virtual appliance on a variety of hypervisors. (To find
supported hypervisor types and versions, see the Virtual Edition documentation for your version.)
Reasons to choose a virtual appliance include the following:
To deploy the BIG-IP ASM system in a cloud environment.
To reduce acquisition cost.
You do not expect high volumes of SSL/TLS traffic in your environment.
Your environment requires rapid deployment, high levels of instantiation, or mobile deployment.
Capacity concerns
Most applications protected by the BIG-IP ASM system are encrypted with SSL/TLS. F5 recommends that you carefully consider
capacity.
A virtual edition is licensed to perform up to 500 SSL TPS for 2048-bit keys per vCPU allocated to the virtual appliance. Actual
TPS varies depending on the type and speed of the CPUs.
Depending on your license, you can allocate up to eight vCPUs. Applications that require high volumes of SSL/TLS traffic may
require either cryptographic offload (hybrid topology for example) or scaling the Virtual Edition appliances using a pool topology
or clustering.
Additionally, each Virtual Edition appliance is available in a variety of throughput levels, from 25Mb/sec to10Gb/sec, depending on
hypervisor. You can easily upgrade these throughput levels. When allocating disk space, CPU, and RAM, you can increase the
resources, as available, and increase the capacity and performance of each BIG-IP ASM virtual appliance.
For more information, see the AskF5 article SOL14810: Overview of BIG-IP VE license and throughput limits and BIG-IP Virtual
Edition Datasheet.
114

VIPRION
VIPRION is an F5 scalable chassis and blade platform. The platform presents multiple blades as a single logical device, to scale
rapidly and without disruption through the installation of additional blades. Since flow on any blade can be processed on the
computing resources for that blade or any other blade, the design provides robust processing power for a BIG-IP ASM
deployment.
The VIPRION platform is a frequent choice to protect high performance and high capacity applications, or to protect a large
number of applications.
vCMP support
With an optional, additional license, VIPRION supports F5 vCMP virtualization technology to allow multiple BIG-IP instances on a
single platform. In examples provided in this chapter, a vCMP guest instance can function identically to a hardware appliance for
the topologies described, as long as adequate resources are assigned to the guest instance.
Sizing
The BIG-IP ASM system performs best on VIPRION systems offering the following:
Cryptographic hardware for offloading SSL/TLS computation
Hardware compression for offloading http compression computations.
Solid-state drives for superior local I/O
Enough available RAM, particularly when using traffic learning on multiple applications
Enough CPU resources
Important RAM and CPU sizing recommendations for web application
firewalls vary widely by number and type of application, security policy
settings, and network conditions. Consult your F5 account team for
assistance in identifying the properly sized VIPRION for your security
requirements.

The three types of topology are single-tiered, multi-tiered, and hybrid.
Single-tiered is the most common topology. It involves deploying the BIG-IP ASM system in a simple active-standby
device pair, with protected application traffic directed to the active unit.
Multi-tiered involves deploying multiple BIG-IP ASM appliances in parallel with traffic steered to BIG-IP ASM devices
through BIG-IP LTM appliances.
115

Hybrid involves deploying BIG-IP ASM VE in a distributed topology, combined with VIPRION or hardware appliances,
performing traffic distribution and hardware-based cryptographic and compression offload.
Important If in order to meet specific business goals you need to deploy an
advanced topology for an atypical or complex application delivery
environment, F5 strongly encourages you to consult your F5 account team.
You can also get architectural and implementation assistance from F5
Professional Services or an F5 Guardian Partner.
Modes
You can deploy the BIG-IP ASM system in either routed mode (with or without SNAT) or in a one-armed mode (with SNAT).
You can configure both modes at the same time on a single BIG-IP system, on an app-by-app basis.
You can use both modes with single-tiered or multi-tiered topologies.
Note Requests and responses must go through the BIG-IP system. This
means that if you do not use NAT on the source IP address of the client, the
default gateway of the server needs to be the BIG-IP system. If you use
SNAT for all traffic from the client to an IP address of the BIG-IP system, all
responses will be sent back to the IP. To keep track of the original client IP
address, you can enable the X-Forwarded-For feature of the HTTP profile.
This adds the client IP address to the HTTP header that was sent to the web
server.
Routed mode
In route mode, the BIG-IP ASM system is in the routing path of the web servers, and all traffic to the server flows through the
system.
116

Figure 6.1 BIG-IP ASM routed mode deployment
Servers detect the actual client IP address in the IP header for security and logging purposes. Since all communication
traverses the BIG-IP system, there are no alternate, unprotected routes to the protected applications.
The BIG-IP system must be configured to allow administrative and non-application traffic.
Response traffic must be routed through the BIG-IP system, you usually accomplish this by setting the default gateway of
the web server to the floating self-IP of the BIG-IP system.
One-armed mode
In one-armed mode, only application traffic flows through the BIG-IP ASM system, and the server-side connection uses a SNAT.
The BIG-IP ASM appliance is logically in line with the web application traffic flow, but not physically in line with all traffic to and
from the web servers.
117

Note Requests and responses must go through the BIG-IP system. This
means that if you do not use NAT on the source IP address of the client, the
default gateway of the server needs to be the BIG-IP system. If you do use
SNAT for all traffic from the client to an IP address of the BIG-IP system, all
responses will be sent back to the IP. To keep track of the original client IP
address, you can enable the X-Forwarded-For feature of the HTTP profile.
This adds the client IP address to the HTTP header that was sent to the web
server.
Figure 6.2 BIG-IP ASM single-arm deployment
No changes to routing is required on the servers.

Only application traffic is sent through the BIG-IP system, which reduces traffic traversing the device.
Servers detect the IP address of the BIG-IP system in the TCP/IP header, which may complicate logging.
118

There is more than one path to the protected application. You need additional security controls such as firewalls to ensure
that malicious users do not access the application.
Tip If you expect a large number of concurrent connections, use a SNAT
Pool instead of SNAT Automap to prevent port exhaustion on the BIG-IP
system. For more information, see the AskF5 article SOL7820: Overview of
SNAT features.
Single-tiered topology
Combining BIG-IP LTM and BIG-IP ASM on a single BIG-IP platform has several advantages from an architectural perspective,
such as:
Simplified traffic flow.
Centralized administration on one device.
Encryption/decryption of traffic (SSL) on one device.
Depending on project requirements, you may not need BIG-IP LTM features. In this case, you can deploy the BIG-IP ASM system
only. (This is unlikely. Most will need BIG-IP LTM.)
Most deployments implement a redundant system configuration to ensure device high-availability.
Multi-tiered topology
BIG-IP LTM load balances to multiple BIG-IP systems. Traffic terminates on the BIG-IP LTM where the BIG-IP ASM devices are
configured in a pool.
You can horizontally scale the BIG-IP ASM devices.
You do not have to change licensing or the virtual server profile configuration on the load balancer.
You can add a BIG-IP ASM to or remove a BIG-IP ASM system r from the pool without changing the network
infrastructure.
BIG-IP ASM and BIG-IP LTM software versions do not need to match.
You can use the BIG-IP VE ASM to alleviate WAF processing, which is CPU-intensive.
You can deploy BIG-IP ASM systems in an N+1 redundant system configuration.
You have to manage more devices.
BIG-IP LTM uses a virtual server with a pool assigned. The pool members are virtual servers of the back-end BIG-IP ASM
systems.
119

The system uses cookie persistence (Cookie insert) on the front-end BIG-IP LTM system. This means SSL needs to be
terminated on the front-end BIG-IP LTM.
The system uses only L7 monitors on the front-end because L4 or ICMP monitors check only the state of the back-end
BIG-IP ASM virtual servers and not the real application.
Use sync-only device-groups on BIG-IP ASM stand-alone systems to ensure that the BIG-IP ASM policy is synchronized
among all back-end BIG-IP ASM members.
Configured thresholds are individual, per BIG-IP ASM pool member.
BIG-IP ASM systems are behind BIG-IP LTM, so statistics on the BIG-IP ASM system are individual, per stand-alone instance.
The same is true for BIG-IP ASM event logs; therefore F5 recommends that you use a central logging system if you need a
centralized view of all event log data.
On BIG-IP ASM systems, Auto Last Hop should be disabled on a per virtual server basis. Otherwise Mac Masquerade
needs to be configured on BIG-IP LTM to ensure seamless failover.
Hybrid Topology with Virtual Edition

Other than some hardware offload considerations, such as SSL/TLS, BIG-IP ASM scaling is based on the available CPU and
RAM, as well as the I/O capacity of the platform. Therefore, you may deploy the BIG-IP ASM system on a pool of VE instances,
with a hardware appliance or VIPRION directing the traffic.
In this configuration, you can size the appropriate hardware appliance for L7 traffic management while scaling up capacity
requirements for the BIG-IP ASM system by adding resources to the virtual appliances, increasing the number of virtual
appliances, or by doing both. Doing so allows a flexible and efficient right-sizing of capacity.
The hybrid topology allows organizations with a robust and rapidly expanding virtual environment to use commodity computing
resources and to rapidly deploy new BIG-IP ASM instances that do not need to be shipped or physically installed after purchase.
Virtual Edition licensing pools and other volume and on-demand purchasing and licensing options allow you to simply deploy
another instance from a pool of pre-purchased licenses on demand.

Rapidly deploy a new BIG-IP ASM instances on demand.
Add and remove commodity computing resources on demand.

Use commodity computing resources for computing-constrained tasks while using hardware acceleration for application
delivery tasks.
Provide hardware crypto offload.
Use BIG-IP LTM to direct traffic directly to the pools.
Use hardware DDoS L3/L4 capabilities on physical devices, but scale L7 DDoS capabilities on commodity computing.
120

Requires more complex deployment than a simple redundant system.

Requires management of more than one system.
Key management requires more operational overhead when re-encryption is required.
If virtual BIG-IP ASM systems are not also licensed for BIG-IP LTM, traffic must traverse BIG-IP LTM twice (or to another
tier of BIG-IP LTM) for distribution to the web server pools.
SSL offload on hardware reduces VE load, but sends traffic unencrypted to the VE and to the servers. This does not apply
to all applications in all environments. Using OneConnect greatly reduces TCP overhead, improves traffic distribution, and
reduces impact of the topology's added built-in network latency.
SSL offload with re-encryption performs much better on VE when you use ECC ciphers and certificates exclusively for the
back-end encryption, all the way through to the web servers.
If you are offloading or bridging SSL at an external BIG-IP LTM, F5 recommends that you enable an HTTP compression
profile to perform hardware compression on the hardware model you choose to offload this workload at the outer tier. This
will improve the overall performance of BIG-IP ASM VEs.
If VE appliances do not load balance to the web servers, traffic between BIG-IP LTM and BIG-IP ASM VE requires you to
use SNAT and/or Auto Last Hop. If the web servers need to detect the original client IP address in the TCP/IP header,
consider a different option.
You can "re-SNAT" to the original client IP from a header. This requires you to enable X-Forwarded-For on the external
BIG-IP LTM virtual server, enable Trust XFF in BIG-IP ASM policies, and set up an iRule on the load balancing BIG-IP LTM
virtual server to use SNAT to return traffic to the original client IP address.
With additional licensing, VE can perform crypto offload to a hardware appliance, a VIPRION system, or a third-party
network HSM platform.
Note The Crypto offload feature is outside the scope of this document. For
more information, see Implementing External Cryptographic Server Offload
with BIG-IP systems.
121

Yes
No

Yes
No

Yes
No

Send
COMMON MANAGEMENT TASKS

Guidelines
Common Management Tasks

This chapter contains guidelines for common tasks involved in managing your BIG-IP ASM system.
You can deploy the BIG-IP ASM system with the following configuration types:
Stand-alone
High availability (HA) is not available.
Redundant system (Sync-Failover device group)
Multiple BIG-IP devices share the same BIG-IP version and configuration.
Redundant system (Sync-only device group)
Multiple BIG-IP devices share a configuration, particularly specific application security policies.
Guidelines
Redundant systems guidelines
A BIG-IP system can be a member of only one device group.
All BIG-IP systems in a device group must use the same BIG-IP ASM version, including hotfix updates.
BIG-IP systems in the device group synchronize application security configuration data and security policies, providing
consistent enforcement on all the devices. However, event logs, reporting, and learning suggestions are not synchronized.
Policy Builder can run on only one system per security policy. When you set up Policy Builder on one member of a device
group, the policy is built on that BIG-IP system and then automatically updated on the other systems in the device group.
The BIG-IP ASM system considers one VIPRION platform (with multiple blades) as one device. You need add only the
master blade to the device trust and group.
You cannot use connection mirroring on virtual servers that have a BIG-IP ASM policy attached.
You must have consistent system times across all units using network time protocol (NTP).
For BIG-IP systems in a group, you should enable ports 22 and 443 for communication among self IPs and ports 1026
UDP and TCP for syncing between devices. Make sure to configure the Port Lockdown setting and use a self IP address
rather than the management IP address for configuration synchronization (ConfigSync).
We also need ports 1026 UDP and TCP for syncing between devices. See AskF5 article SOL13250:Overview of port
lockdown behavior (10.x - 11.x).

123

Update geolocation
When troubleshooting ConfigSync issues on a redundant system, review the /var/log/ltm file.
For more information, see Synchronizing Application Security Configurations Across LANs (11.x) or Synchronizing Application
Security Configurations Across LANs in BIG-IP Application Security Manager: Implementations.
Attack signatures guidelines

BIG-IP ASM attack signatures are an evolving set of protections that must be kept up-to-date to provide the best available
protection against new and emerging threats and to ensure minimal false positives.
F5 publishes signature update files on a regular basis. You must establish a process to keep attack signatures updated and
manage the update process within the policies.
The easiest way to update attack signatures is using automatic delivery mode through scheduled or manual updates. However, for
air-gapped systems with no access to the Internet (either direct or via a proxy), use the manual delivery mode. Manual delivery
mode allows you to download the update file manually from F5 Downloads and then upload that file using the BIG-IP ASM
Configuration utility.
For more information, see Working with Attack Signatures in BIG-IP Application Security Manager: Implementations (BIG-IP 11.6)
or Updating signatures manually in BIG-IP Application Security Manager: Custom Signature Reference (BIG-IP 12.0). Also see
AskF5 article: SOL8217: Updating the BIG-IP ASM attack signatures.
Signature staging guidelines

All new signatures are placed into staging regardless of the place-updated signatures in the staging settings.
If you update signatures to add protection or mitigation for a specific, newly identified vulnerability, after updating, decide whether
the new signature will be transitioned immediately into Enforced or if the Staging period will be allowed to proceed as defined in
staging settings.
Important If a signature is triggered on a request while in staging, the
request will not be blocked.
Update geolocation
The BIG-IP ASM system can protect against attacks based on the geolocation of the source IP during a request. Geolocation data
is used to control the accessibility of requests in the Geolocation Enforcement page and to detect suspicious L7 denial-ofservice (DoS) attacks from specific geolocations. Geolocation data changes regularly, so F5 releases a monthly download based
on collected data.
You must manually update geolocation information using the TMSH utility on your BIG-IP system.
For more information, see AskF5 article: SOL11176: Downloading and installing updates to the IP geolocation database.
124

Remove only the /shared/tmp/GeoIP.old/ path if the installation of all four RPM packages is successful, and you are able to
verify proper functionality by querying an IP address using the geoip_lookup tool.
Important F5 strongly recommends performing the md5sum validation
whenever you download F5 data over the Internet, particularly data to use on
your BIG-IP devices. Without this validation check, compromised releases or
corrupt archives can corrupt your configuration or otherwise cause adverse
effects to your BIG-IP devices.

The IP intelligence database is an F5 subscription-based database which allows BIG-IP systems to recognize IP addresses,
including known botnets, anonymous proxies, and malicious actors.
In the BIG-IP ASM system, the IP intelligence database allows you to:
Block a specific category of IP addresses.
Log and report on the IP intelligence categories.
Provide additional details for BIG-IP ASM scoring functionality to help better understand if a request is likely an attack (a
score of 4-5) or a false positive (a score of 1-2).
Subscribe to and configure updates

The IP intelligence database is an F5 subscription-based service that requires you to purchase an add-on license (1-year or
3-year options are available). Some functionality is available without the license through the Configuration utility. However,
without the license, the database cannot be downloaded and automatic categorization is not available. You can purchase a
license through the F5 sales team,
The IP intelligence database is updated very frequently, so the default minimum download interval is five minutes.
Note The IP intelligence database is very large and can take a long time to
download for the first time, depending on your connection. Later updates are
incremental and thus quicker to download and apply.
You can update the IP intelligence database using a direct IP connection or through an intermediate proxy.
Important DNS lookups on the BIG-IP system must first be configured for
the database to successfully download.
For more information, see Enabling IP Address Intelligence (BIG-IP 11.6) or Setting Up IP Address Intelligence Blocking (BIG-IP
125

12.0) and AskF5 article: SOL13875: Managing IP reputations and the IP Address Intelligence database.
Verify updates
Once you've downloaded and installed updates to the IP intelligence database, you should verify the installation by checking the
last time an update was received.
To display date and time of updates in the Configuration utility
1. Navigate to Security >> Application Security > IP Address > IP Address Intelligence.
2. Click Intelligence last updated.
To display date and time of updates using the TMSH utility at the command line

Type the following command:
tmsh show sys iprep-status

For more information, see AskF5 articles: SOL13776: Determining the IP intelligence subscription expiration date and SOL13653:
The IP Intelligence Service database cannot be updated.
Check IP address reputation

You can check the reputation of a specific IP address using the IP intelligence database.
To check reputation of a specific IP address at the command line

iprep _ lookup <IP address>

Output will appear similar to the following example:
iprep _ lookup 1.1.1.1 opening database in /var/IpRep/F5IpRep.dat size of

IP reputation database = 4163298 iprep threats list for ip = 1.1.1.1 is:
bit 4 Scanners bit 5 Denial of Service
Add IP address to IP Address Whitelist
You can eliminate false positives by adding specific IP addresses to the IP Address Whitelist.
To add an address to the IP Address Whitelist in the Configuration utility
1. Navigate to Security >> Application Security > IP Addresses > IP Address Intelligence.
2. In the IP Address Whitelist box, type the IP address.
3. Click Save.
126

For more information, see Setting Up IP Address Intelligence Blocking in BIG-IP Application Security Manager: Implementations.
Logs
IP intelligence functionality on the BIG-IP system is performed by the iprepd process, which logs to the /var/log/iprepd/
iprepd.log file.

F5 strongly recommends performing regularly scheduled backups of your BIG-IP system. At a minimum, backups must be
performed before and after any major change to the system, such as a configuration change or an upgrade.
You can use the Configuration utility to trigger backups, or you can use a central management system such as BIG-IQ or
Enterprise Manager. Only the configuration information is backed up.
Event logs, reporting, and learning suggestions are not backed up and cannot be saved from the local system. For this reason,
these items are also not synchronized between devices or blades in a cluster.
Tip To store event logs across upgrades and configuration restore
operations, F5 recommends using remote logging and sending the log data
to an external syslog server or SIEM for storage. For more information, see
BIG-IP ASM Event Logging .
Restore from a backup

Before restoring a BIG-IP system from a backup, you should:
Make sure you have a valid BIG-IP system license for that system.
Provision BIG-IP ASM on the system.
For more information, see AskF5 article: SOL13945: The BIG-IP ASM MySQL database is not installed completely if the BIG-IP
ASM is not provisioned when the UCS is loaded.

To successfully install a user configuration set (UCS) archive file on a BIG-IP system, perform one of the following actions:
Restore the UCS archive to the same system from which it was saved.
Have the license associated with the serial number of a new system. To do so, contact F5 Technical Support.
Note F5 Technical Support will associate a license file with a new serial
number onlyon an as-needed basis, in the event of a Return Materials
Authorization (RMA).
Relicense the BIG-IP system after restoring the UCS archive.
127

Save the license file prior to restoring the configuration from another system, and then copy the license file back.
Install the UCS archive by using the tmsh utility no-license option.
To install UCS by using TMSH utility no-license option

Type the following command syntax:
tmsh load sys ucs [ucs file name] no-license

For more information, see AskF5 articles: SOL13132: Backing up and restoring BIG-IP configuration files (11.x - 12.x) and
SOL12880: Configuring a replacement BIG-IP device after a Return Materials Authorization.
128

Yes
No

Yes
No

Yes
No

Send
TROUBLESHOOT BIG-IP ASM

Use platform logs
Troubleshoot BIG-IP ASM

Use platform logs
When troubleshooting your BIG-IP system, you should know the locations of the different log files and understand their contents.
The following table describes the contents of each platform log related to the BIG-IP ASM system.
Table 8.1 Platform log contents
Log
Description
/var/log/ltm
Contains general BIG-IP LTM log entries, such as availability of pool members, high
availability, and config-sys entries.
/var/log/asm
Contains critical messages from processes that the BIG-IP ASM system uses (mysql,
policy building engine, enforcer). Each process has its own log file under /var/log/ts
(see log, following).
/var/log/audit
Contains audit trails for BIG-IP user activities such as failed login attempts and certain
security events involving HTTPS, SSH, or other configuration changes.
/var/log/ts/
Contains information about various BIG-IP ASM system daemons and policy building.
/var/log/pktfiler
Contains results from implementation of packet filters and packet filter rules.
/var/log/dosl7
Contains BIG-IP ASM system DDoS event information such as attack started/stopped
and bot signature update status.
/var/log/iprepd/
Contains entries for the IP intelligence service updates.
iprepd.log
/var/log/icrd
Contains entries for iControl API calls, their results, and failures.
/var/log/
REST API Java framework used by BIG-IP and BIG-IQ to communicate writing logs.
Log entries include communication attempts and failures, such as SSH handshake
failures, certification, and authentication failures, and time skews.
restjavad.0.log
/var/log/tmm[0]
Contains traffic events, such as unexpected resets, DDoS drops, and other events.
Typically very large. File should be analyzed only with F5 support assistance.
You can configure the logging level for most platform logs at System\Logs\Configuration\Options.
130


There are several ways to check if your BIG-IP ASM system is up and running:
Check if BIG-IP daemons are running.

Check logs for error messages and illegal requests.
Check for TS cookie in header.

Upload a qkview file to BIG-IP iHealth.
Check if BIG-IP daemons are running

To check if BIG-IP daemons are running, using the TMSH utility
1. Type the following commands
tmsh show sys service asm

tmsh show sys service mysql
2. Make sure that all daemons are running.
For detailed information on core BIG-IP ASM services, and the impact to the BIG-IP ASM system operation if the service is not
running, see the AskF5 article SOL14020: BIG-IP ASM daemons (11.x).
Check logs for error messages and illegal requests

1. Check for error messages in the following logs:
/var/log/ltm
/var/log/asm
/var/log/dosl7/dosl7d.log
/var/log/mysql.out
2. Check the request log for illegal requests.
For more information, see Use platform logs.
Check for TS cookie in header

If the security policy is configured on a virtual server, you will see the TS cookie in place in the HTTP response from the BIG-IP
ASM system. In addition, the server-header of the response is removed. Both happen in blocking and transparent mode.
HTTP/1.1 200 OK
Date: Tue, 17 Nov 2015 13:01:53 GMT
Last
Modified: Mon, 21 Apr 2014 07:13:20 GMT ETag: "970c
178
4f7883bf94780"
131

Bypass BIG-IP ASM
Accept
Ranges: bytes Content
Length: 376
Keep
Alive: timeout=300, max=500 Connection: Keep
Alive
ContentType: text/html charset=UTF8 SetCookie:
S01425764=01ae97ff1e19f24a9b73757578683232de31fec9e054b6f04b167d6a7d88f4f7333871255d
Path=/
<html>
...
...
</html>
For more information, see the AskF5 article: SOL6850: Overview of BIG-IP ASM cookies.
Upload a qkview file to iHealth

iHealth is freely available to customers who run BIG-IP 10.x and later, or Enterprise Manager 2.x and later. iHealth enables you to
verify operation of your BIG-IP system and ensures that your hardware and software function at peak efficiency by providing
information covering your hardware, software, licensing, configuration, best practices, and known issues.
iHealth is a hosted application that parses a qkview file. The qkview provides a running snapshot of your BIG-IP system with
up-to-the-minute configuration and diagnostic information. You can download a qkview from your BIG-IP system and then upload
the file to the iHealth system.
For more information, see iHealth in the F5 BIG-IP TMOS: Operations Guide.
Bypass BIG-IP ASM

If the BIG-IP ASM system service has insufficient resources or is down, you can allow web application traffic to bypass it.
Starting in BIG-IP ASM 10.2.3, you can configure the following system variables using the following Configuration utility
commands:
bypass_upon_load
bypass_upon_asm_down
For more information, see SOL15093: The BIG-IP ASM system bypass_upon_load and bypass_upon_asm_down variables
should not be enabled.

If you enable the bypass_upon_load variable (set the value to 1), web application traffic bypasses the BIG-IP ASM system when
there are insufficient resources for BIG-IP ASM service.
132

If you enable the bypass_upon_asm_down variable (set the value to 1), web application traffic bypasses the BIG-IP ASM system
when any of the following conditions occur:
BIG-IP ASM service is stopped.
BIG-IP ASM service is restarted; traffic bypasses the BIG-IP ASM system from the time the BIG-IP ASM service is down
until the service resumes processing.
BIG-IP ASM service performs a core dump; traffic bypasses the BIG-IP ASM system until the BIG-IP ASM service resumes
processing.
If you enable either or both of the system variables, all web application traffic that is protected by BIG-IP ASM security policies is
no longer directed through the BIG-IP ASM system for security checks when BIG-IP ASM service experiences the previouslydescribed conditions; traffic is forwarded directly to the origin web servers. As a result, the web application may be at risk of
security threats and false positives.
Caution F5 recommends that you enable these system variables with careful
consideration to the security impact on your application environment.

In rare cases, you may need to review an entire HTTP transaction to determine the reason the expected response is not returned
to the client.
The following flowchart shows the steps you can follow to decide whether the BIG-IP ASM system is processing an HTTP
response correctly:
133

Figure 8.1 Troubleshooting flow chart for unexpected HTTP responses
134

1
Application is broken.
Page is blank.
Response is blocked.
Finding
Connection is reset.
Action
Find out if the BIG-IP ASM system is causing the problem.
Question
Does the request trigger the BIG-IP ASM blocking response page on the HTTP client?
Request is blocked by BIG-IP ASM security policy.
YES
Go to step 8.
NO
Go to step 2.
2
Application is broken.
Page is blank.
Response is blocked.
Connection is reset.
Finding
BIG-IP ASM blocking response page is not displayed on HTTP client.

Enable Log All Requests in event log on virtual server running the BIG-IP ASM system (see to
BIG-IP ASM Event Logging ).
Try to match the HTTP request in question with the event log. (See Capture HTTP request/
Action
Question
response.)
Can you find the HTTP request page?
HTTP request did not arrive at the BIG-IP ASM system.
NO
Go to step 3.
YES
Go to step 4.
3
Finding
HTTP request does not arrive at the BIG-IP ASM system.
135

The BIG-IP ASM system is not the problem.

To continue investigating, run tcpdump on the virtual server running the BIG-IP ASM system to
see if the HTTP request reaches the BIG-IP.
Use the following syntax at the command line:
Action
tcpdump I 0.0:nnn s 0 w /var/tmp/asm _ client.cap

host <virtual server IP address> and port <virtual
server port>
4
Finding
Matched HTTP request appears in the BIG-IP ASM event log.
Action
Review the logged request by selecting the HTTP request in the event log.
Question
NO
Does the request log show that the request was blocked?
Go to step 5.
Request blocked by BIG-IP ASM security policy.
YES
Go to step 8.
5
HTTP request appears in BIG-IP ASM request log.
Finding
HTTP request not blocked by the BIG-IP ASM system.

Do one of the following:
Remove BIG-IP ASM security policy from virtual server.
Disable the BIG-IP ASM system for a specific IP address URL using an iRule or local traffic
policy.
Actions
Question
NO
For iRule examples, see Wiki: iRules API on DevCentral (login required).
Does the issue continue after the removal of BIG-IP ASM security policy?
Go to step 7.
YES
Go to step 6.
6
Finding
136

Monitor performance
Action
Continue troubleshooting to find out if BIG-IP LTM is the problem.
7
The BIG-IP ASM system is the problem.
Finding
Request is not blocked by the BIG-IP ASM system in a security policy.

Run tcpdump on client side and server side connections.
tcpdump I 0.0:nnn s w /var/tmp/asm _ clientserver.

cap \(host <virtual server IP address> and port
<virtual server port>\) or \(host <pool member IP
address> and port <pool member port>
Action
Contact F5 support. See F5 technical support resources.
8
Finding
Request is blocked by the BIG-IP ASM system. Possible false-positive violation.
Action
Tune your BIG-IP ASM security policy. See Policy Tuning and Enhancement.
Monitor performance
Performance can be monitored in several ways. You can use performance graphs, iHealth, or the top command.
Performance graphs
The BIG-IP system provides performance graphs in the Configuration utility. Navigate to Statistics >> Performance.
137

Monitor performance
Figure 8.2 Performance graphs in the Configuration
utility
The graphs show historical running performance data for up to one month. In BIG-IP 12.0 and later, the BIG-IP system also
provides real-time dashboard style performance analytics. Navigate to Statistics >> Analytics : ASM Resources.
138

Monitor performance
Figure 8.2 Memory utilization graphs in the Configuration
utility
These graphs include CPU Utilization, Memory Utilization, and Bypass Information.
Regularly check these graph to monitor the overall health and capacity of the BIG-IP system. They can show early signs of
potential issues, allowing you to act on problems before they occur.
iHealth
iHealth provides an alternative for viewing RRD based performance graphs, and it is easy to compare performance data between
different BIG-IP ASM systems, and snapshots of different time periods. iHealth provides heuristic diagnostics based on log
messages and statistical data to help a customer identify performance issues.
139

Monitor CPU usage
For more information, see iHealth in F5 BIG-IP TMOS: Operations Guide.
top command
Table of processes (top) is a Linux/Unix CLI tool for process reporting, and is used for troubleshooting CPU and memory
performance issues on the BIG-IP ASM system.
You can start top in interactive mode and watch the performance data change.
Monitor CPU usage

F5 recommends that you regularly check the CPU usage of the BIG-IP ASM system.
Normal CPU usage at the peak of any CPU/thread on the system should not exceed 75 percent under normal traffic volume.
However, some administrative processes, such as those related to learning, may cause higher loads on the last CPU core. This is
not generally a problem on most platforms that use process scheduling and process separation across CPU cores.
Note For BIG-IP 11.5.0 and later, on systems with a CPU using HyperThreading Technology, tmm runs on half of the cores/threads on the system.
For more information, see the AskF5 article: SOL15003: Data plane and
control plane tasks use separate logical cores when the BIG-IP system CPU
uses Hyper-Threading Technology.
If CPU usage is too high, you need to identify the process that is causing the problem. Use the performance graph to view CPU
usage per core/thread and see whether CPU over-use occurs on multiple cores/threads or just one.
Some important BIG-IP ASM-related processes such as tmm or bd are multi-threaded and tend to spread their threads across
all even-numbered CPU cores. If you find excessive CPU usage on all even-numbered cores, these multi-threaded processes are
likely the problem.
The top command provides dynamic CPU usage by each process; using this command, you can display additional threads and
cores information.
To display additional threads and cores using the top command
1. Remove the current /root/.toprc file.
2. Run the top command in interactive mode.
3. To get the command to show threads, type H.
4. To get the command to show individual cores, type 1 .
5. Type f
140

Monitor CPU usage
6. Type j.
7. To add Last used cpu as a column, press Enter. .
The system displays the following output:
top 02:18:26 up 2 days, 18:36, 1 user, load average: 0.13, 0.23, 0.19
Tasks: 659 total, 1 running, 656 sleeping, 0 stopped, 2 zombie
Cpu0 : 9.1%us, 2.0%sy, 4.0%ni, 84.8%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16528548k total, 14496992k used, 2031556k free, 569104k buffers
Swap: 1048572k total, 0k used, 1048572k free, 2747692k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ RUSER P DATA COMMAND
20273 root 20 0 2038m 66m 26m S 8.7 0.4 20:31.20 root 1 338m avrd
17088 root RT 0 8915m 127m 101m S 8.7 0.8 330:27.58 root 0 206m tmm.0
7417 root 20 0 26776 20m 12m S 5.2 0.1 123:34.95 root 4 4140 csyncd
23050 root 20 0 3060 1384 792 R 5.2 0.0 0:00.06 root 6 828 top
5907 root 20 0 159m 118m 32m S 3.5 0.7 91:54.95 root 5 84m mcpd
17 root 20 0 0 0 0 S 1.7 0.0 11:10.78 root 3 0
ksoftirqd/3
5044 root 20 0 39332 21m 13m S 1.7 0.1 0:05.33 root 1 4268 eventd
5652 root 20 0 28480 27m 19m S 1.7 0.2 6:34.82 root 5 4184 clusterd
9214 root 20 0 2220 884 744 S 1.7 0.0 50:28.49 root 0 248 LCDd
1 root 20 0 2904 1368 1164 S 0.0 0.0 0:00.91 root 3 260 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 root 6 0 kthreadd
141

3 root RT 0 0 0 0 S 0.0 0.0 0:00.05 root 0 0 migration/0

To see utilization data for each virtual server CPU
1. Navigate to Statistics >> Module Statistics: Local Traffic >> Virtual servers.
2. See the data in the CPU Utilization Avg. and ASM CPU Utilization Avg. columns.

Monitor the memory usage to establish a baseline that is specific to your BIG-IP system and your network traffic.
Memory considerations when using CLI tools

TMM has a fixed memory size, which the system allocates when you start the system. When you use the top command, the
system output appears as a large VIRT memory allocation.
For performance reasons, the BIG-IP ASM traffic processing daemon, bd, does not release memory back to the operating
system.
Typical bd process is as follows:
1. You start the system.
2. The bd process immediately loads the configuration and allocates initial buffers.
This process uses a small amount of resident memory.
3. If not memory is available, the bd process sends a request to the system to allocate new memory for a fresh buffer.
4. The bd process retains this memory to use for a future request.
5. On the first day in production, bd memory increases and peaks as traffic throughput increases.
6. On subsequent days, bd memory stabilizes, unless peak throughput increases.
If bd memory continues to increase linearly, you should investigate.
The following graphs show typical BIG-IP ASM system memory use over time with respect to traffic.
142

Figure 8.4 BIG-IP ASM memory use over time with respect to traffic
To identify a potential memory leak in a BIG-IP ASM process, use the top command to collect continuous snapshots for a
particular interval, and monitor a process's memory use.
To use the top command to monitor memory

top b n <number of snapshots> -d <interval of snapshots in seconds> >

/var/tmp/top _ output.txt
For example the following example will capture 60 iterations at 10 second intervals and log the output to /var/tmp/top_output.
txt.
top b n 60 d 10 > /var/tmp/top _ output.txt

Using these settings, the capture will take 10 minutes (60 x 10 seconds).
143

Yes
No

Yes
No

Yes
No

Send
OPTIMIZE THE SUPPORT EXPERIENCE

Optimize the support experience

F5 technical support commitment
F5 strives to continuously improve its support service and create closer customer relationships. Designed to provide assistance
with specific break-fix issues and ongoing maintenance of F5 products, F5 professional support services are consistently
high-quality. This means:
F5 network support engineers conduct themselves professionally at all times.
F5 is committed to providing the best customer experience possible.
Customers are treated with respect and given every consideration possible.
F5 aims to provide resolutions the first time, every time.
Manager escalation is always available for unresolved or site down issues.
Some technical support issues arise from configuration errors, either within the BIG-IP system or with other devices in the
network. In other cases, a misunderstanding of BIG-IP capabilities can lead to support questions and issues. Although F5 does
everything possible to prevent defects in BIG-IP hardware and software, these issues may still arise periodically. Regardless of
the root cause of a problem, the goal is to resolve any issues quickly.
F5 technical support offerings

A variety of technical support offerings are available to provide the right level of support for any organization.
The F5 Standard and Premium support offerings include remote assistance from F5 Network Support Engineers, both online and
over the phone.
Premium Plus customers receive priority status at F5, with fast, easy access to a dedicated team of senior-level, F5-certified
Network Support Engineers and a Service Delivery Manager.
To learn more, see F5 Support Offerings or send an email to services@f5.com.
Take advantage of the full range of F5 Consulting Services to help you design, customize, and implement a solution that is right
for your IT infrastructure and supports your business goals.
F5 Professional Services (f5.com/support/professional-services) provides information about a wide range of F5 Professional

Services offerings and Professional Services Partners. You can use our online forms to request Consulting On Demand for
custom, shorter scope consulting engagements, or iRules OnDemand to get fast access to iRules scripts tailored to your specific
needs.
145

F5 certification
You can request specific support services by using either of the following forms:
Consulting Request Form (f5.com/support/professional-services/consulting-request-form)
iRules Consulting Request Form (f5.com/support/professional-services/irules-consulting-request-form).
GUARDIAN Professional Services Partners

F5 GUARDIAN Professional Services Partners are authorized as Installation Providers and are available to assist you. F5
GUARDIAN Professional Service Partners are selected because they have the skills and experience required to ensure successful
implementations of F5 BIG- IP Local Traffic Manager (LTM) and BIG-IP DNS.
See F5 Support Offerings for a complete list of partners.
F5 certification
F5 Certified! exams test the skills and knowledge necessary to be successful when working with todays application delivery
challenges. Our technically relevant and appropriate exams deliver consistently reproducible results that guarantee excellence in
those that achieve certification.
Certification levels
The F5 certification program is progressive with the four levels Administrator, Specialist, Expert, and Professional building on
the skills and knowledge demonstrated on previous exams.
C1 F5 Certified BIG-IP Administrator (F5-CA)
The starting point for all certifications; a certified BIG-IP administrator has basic network and application knowledge to be
successful in application delivery.
C2 F5 Certified Technology Specialists (F5-CTS)
The Technology Specialist certification assures employers that candidates are fully qualified to design, implement, and maintain a
specific product and its advanced features.
C3 F5 Certified Solution Expert (F5-CSE)
The Solution Expert certification focuses on how F5 technologies combine with industry technology to create real-world business
solutions.
C4 F5 Certified Application Delivery Engineer (F5-CADE)
The Application Delivery Engineer certification exam and requirements are still under development.
C5 F5 Certified Application Delivery Architect (F5-CADA)
The Application Delivery Architect certification exam and requirements are still under development.
146

Certificate expiration
F5 certifications are valid for two (2) years. Three months before the expiration date, the certificate holder becomes eligible for
recertification and can register for the necessary exam. Only the last exam in the highest level certification achieved needs to be
retaken.
Certification beta program

F5 uses Beta exams to maintain the relevancy and accuracy of all exams after production. Beta exams are open to all and
provide candidates an opportunity to have an impact on the F5 Certified program. While Beta exams are twice as long, they cost
less than regular exams and give candidates the chance to leave feedback. Beta exams are critical to our exam development
process and improve the F5 Certified program.
Get involved
There are a several ways to get involved with the F5 certification beta program:
Beta participation. Interested in taking our Beta exams? Send an email to F5Certification@f5.com to learn more.
Exam development. Send an email to F5Certification@f5.com if youre interested in helping us create our F5 Certified!
exams.
LinkedIn community. Join us on LinkedIn (this link sends you to an external site) for answers to frequently asked questions,
community developed resources, and more.
Visit the F5 Credential Management System (certification.f5.com) for information or to register.

Before you open a support case, F5 recommends you review self-help materials. For BIG-IP ASM, this includes this guide, BIG-IP
Application Security Manager: Implementation, and the following:

AskF5 Knowledge Base
Downloads
Security updates
BIG-IP iHealth
TechNews
RSS Feeds
DevCentral
147

AskF5
AskF5 (support.f5.com) provides thousands of articles to help you manage your F5 products more effectively, and should be the
first resource you choose when you need support. Step-by-step instructions, downloads, and links to additional resources give
you the means to solve known issues quickly and without delay, and to address potential issues before they become reality.
Whether you want to search the knowledge base to research an issue, or you need the most recent news on your F5 products,
AskF5 is your source for:
Product manuals, operations guides, and release notes

F5 announcements
General articles
Known issues
Security advisories
Recommended practices
Troubleshooting tips
How-to documents
Changes in behavior
Diagnostic and firmware upgrades
Hotfix information
Product life cycle information
Downloads
Downloads are available from the F5 website. It is highly recommended that your F5 software is kept up-to-date, including
hotfixes, Security updates, OPSWAT updates, BIG-IP ASM signature files, and geolocation database updates. All software
downloads are available from F5 Downloads (downloads.f5.com).
Security updates
You can receive timely security updates and BIG-IP Application Security Manager (BIG-IP ASM) attack signature updates from
F5. When remote vulnerabilities are discovered, F5 implements, tests, and releases security hotfixes for any vulnerable supported
version, and sends an email alert to the F5 Security mailing list. F5 encourages customers with an active support account to
subscribe to this list. For more information, see AskF5 article: SOL4602: Overview of the F5 security vulnerability response policy.
148

iHealth
iHealth is among the most important preventative tools to verify the proper operation of your BIG-IP system. This diagnostic
viewer ensures that hardware and software are functioning at peak efficiency, and helps detect and address issues that may
potentially affect F5 systems. iHealth is not integrated within the BIG-IP system. This tool is hosted by F5 at f5.com/support/tools/
iHealth and can be accessed with any web browser.

F5 recommends you generate an iHealth qkview file on the BIG-IP system and upload it to iHealth on a weekly basis in order to
benefit from the many regularly occurring diagnostic updates. Uploading qkview files to iHealth also provides F5 technical
support with access to your qkview files if you open a support case.
By reviewing iHealth output, many of the issues commonly experienced by customers can be resolved without the need for
opening a support case with F5.
For more information on running iHealth diagnostics, see iHealth in the TMOS Operations Guide.
TechNews
AskF5 provides two TechNews email publications to help keep administrators up-to-date on various F5 updates and other
offerings:
TechNews Weekly eNewsletters. Up-to-date information about product and hotfix releases, new and updated articles, and new
feature notices.
TechNews Notifications. Do you want to get release information, but not a weekly eNewsletter? Sign up to get an HTML
notification email any time F5 releases a product or hotfix.
Security Alerts. Receive timely Security updates and BIG-IP ASM attack signature updates from F5.
To sign up for the TechNews mailing lists, go to the AskF5 Publication Preference Center. Enter your email address and select the
publications you want to receive, and click Submit.
AskF5 recent additions and updates

You can subscribe to F5 RSS feeds to stay informed about new documents pertaining to your installed products or products of
interest. The AskF5 Recent Additions and Updates page provides an overview of all the documents recently added to the
knowledge base.
The Recent Additions and Updates list is also published over RSS. You can configure feeds that pertain to specific products,
product versions, and/or document sets. You can also aggregate multiple feeds into your RSS Reader to display one unified list of
all selected documents.
To generate an RSS feed, see AskF5 article: SOL9957: Creating a custom RSS feed to view new and updated documents.
149

DevCentral
DevCentral (devcentral.f5.com) is an online forum of F5 employees and customers that provides technical documentation,
discussion forums, blogs, and media, related to application delivery networking. DevCentral is a resource for education and
advice on F5 technologies, and is especially helpful for iRules and iApps developers. Access to DevCentral is free, but registration
is required. As a DevCentral member, you can:
Ask forum questions.
Rate and comment on content.
Contribute to wikis.
Download lab projects.
Join community interest groups.
Solve problems and search for information.
Attend online community events.
View educational videos.

F5 Global Training Services provides traditional classroom learning opportunities, live-online training, and free, self-paced online
courses to help you get the most out of your investment.
In-person courses
F5 courses are available in multiple training facilities across five continents. Each course combines instructor presentations,
classroom discussions, and interactive labs. The hands-on learning environment helps provide a fast track to accomplishing your
goals.
Virtual instructor-led training

Remote online courses mirror classroom training. Participants watch the remote instructors live lecture online, participate in
discussions, and perform lab exercises using remote desktop control.
Free online training

You can use the self-paced Getting Started series of free, web-based courses to learn how to deploy F5 solutions to address
your most common application delivery problems. For more information, see f5.com/education.
F5 Training Programs and Education (f5.com/education/training) provides links to course schedules, pricing, and registration
details. This page also has information about alternative training solutions such as virtual and web-based training for those who
150

Engage Support
cannot attend training in person. You can also find out more about the F5 Professional Certification or a non-accredited
Application Delivery Networking Certificate through F5.
Engage Support
F5 Technical Support is designed to provide support for specific break-fix issues for customers with active support contracts. For
more information about F5 scope of support, see Support Policies.
Options for assistance

You can contact F5 Support in two ways:
Online: You can open a support case at the F5 WebSupport Portal. Click Register for an Account to access to the
WebSupport Portal.
By phone: Phone numbers are provided in the General contact numbers section below. It is strongly recommended that
you contact F5 by phone if you have a Sev1 or Sev2 case, as defined in Open a support case .
F5 technical support resources

F5 support resources are available 24 hours a day, seven days a week, and are distributed around the globe in multiple support
centers. Live technical support is provided by our professional Network Support Engineers. Hours of availability may vary
depending on the service contract with F5.
Contact numbers
Standard, Premium, and Premium Plus Support customers can open and manage cases by calling one of the contact numbers
listed below.
North America
North America: (888) 882-7535 or (206) 272-6500
Traffix Support Only: (855) 849-5673 or (206) 272-5774
Outside North America

Outside North America, Universal Toll-Free: (800) 11 ASK 4 F5 or (800 11275 435)
Additional contact numbers by country
Australia: 1800 784 977
China: 010 5923 4123
Egypt: 0800-000-0537
151

Engage Support
Greece: 00-800-11275435
Hong Kong: 001-800-11275435
India: 000-800-650-1448; 000-800-650-0356 (Bharti Air users)
Indonesia: 001-803-657-904
Israel: 972-37630516
Japan: 81-3-5114-3260 or 0066-33-812670
Malaysia: 1-800-814994
New Zealand: 0800-44-9151
Philippines: 1-800-1-114-2564
Saudi Arabia: 800-844-7835
Singapore: 6411-1800
South Africa: 080-09-88889
South Korea: 002-800-11275435
Taiwan: 00-800-11275435
Thailand: 001-800-12-0666763
United Arab Emirates: 8000-3570-2437 United Kingdom: 44-(0)8707-744-655
Vietnam: 120-11585
Open a support case

F5 provides several resources to help find solutions to problems. Before opening a support case with F5 technical support, check
to see if the issue you are encountering is already documented.
Before opening a support case with F5, you should consult the following resources:
Deployment guides and white papers provide information about specific deployment configurations.
AskF5 Knowledge Base provides many articles including known issues, how-to guides, security advisories, release notes,
and general information about products. Many of the issues customers encounter are already documented on AskF5.

iHealth enables customers to upload qkview configuration snapshots in order to verify operation of any BIG-IP system.
152

Engage Support
Gather information to open a support case

If your issue cannot be solved using the resources listed, and you need to open a support case, you must first gather several
pieces of important information about your issue. Providing full and accurate information helps speed the path to resolution. The
required information for the majority of situations is summarized below:
The serial number or base registration key of the specific BIG-IP system requiring support. For more information, see
AskF5 article: SOL917: Finding the serial number or registration key of your F5 device.
A full description of the issue: A clear problem statement is the best tool in helping to troubleshoot issues. Your description
should include as much of the following information as you can provide.
Occurrences and changes: The date and times of initial and subsequent recurrences. Did this issue arise at
implementation or later? Were there any changes or updates made to the BIG-IP system prior to the issue arising? If so,
what were they?
Symptoms: Ensuring your list of symptoms is as detailed as possible will give more information for support personnel to
correlate with.
Scope of the problem: Note whether the problem is system-wide or limited to a particular configuration feature, service, or
element (such as VLAN, interface, application service, virtual server, pool, and others).
BIG-IP component: The feature, configuration element, or service being used when the problem occurred (such as
Session Tracking, Signatures, DoS/DDoS protection, Policy Builder, or others).
Steps to reproduce: The steps to reproduce the problem as accurately and in as much detail as possible. Include
expected behavior (what should happen) as well as actual behavior (what does happen).
Errors: Complete text of any error messages produced.
Environment: Current usage of the system. (Is this unit in production? If so, is there currently a workaround in place?)
Browsers: Types and versions, if applicable.
Changes: System changes made immediately prior to the problems first occurrence. This may include upgrades,
hardware changes, network maintenance, and other changes. Have any changes been made to resolve the problem? If
so, what were they?
Issue Severity: A description of the impact the issue is having on your site or Case severity

Severity 1: Software or hardware conditions on your F5 device are preventing the execution of critical business
activities. The device will not power up or is not passing traffic.
Severity 2: Software or hardware conditions on your F5 device are preventing or significantly impairing high-level
commerce or business activities.
153

Engage Support
Severity 3: Software or hardware conditions on your F5 device are creating degradation of service or functionality in
normal business or commerce activities.
Severity 4: Questions regarding configurations (how to), troubleshooting non-critical issues, or requests for product
functionality that are not part of the current product feature set.
Contact and availability information including alternate contacts authorized to work on the problem with F5 Technical
Support. When there are more personnel available to work with F5 Technical Support, the resolution of your issue may be
expedited.
Remote access information, if possible.
A qkview file obtained while problem symptoms are manifesting. A qkview file of the system before the occurrence is also
useful. F5 recommends archiving qkview files regularly. For more information, see iHealth in the TMOS Operations Guide.
Product-specific information: Software versions and types of equipment in use.
Platform and system. Version and provisioned software modules of the affected system.
To locate platform and system information using TMSH at the command line

tmsh show /sys hardware

<SNIP some of the output>

Platform
Name
BIG-IP 3900
BIOS Revision
F5 Platform: C106 OBJ-0314-03 BIOS (build: 010)
Date: 01/10/16
Base MAC

00:01:d7:be:bf:80
System Information

Type C106
Chassis Serial f5-jspv-lzxw
Level 200/400
Part 200-0322-02 REV C
Switchboard Serial
Switchboard Part Revision
Host Board Serial
Host Board Part Revision
154

Engage Support
To copy software version and build number information at the command line
1. Type the following command:
cat /VERSION
Product:
BIG-IP
Version:
11.6.0
Build:
0.0.401
Sequence:
11.6.0.0.0.401.0
BaseBuild:
0.0.401
Edition:
Final
Date:
Mon Jan 12 21:08:03 PDT 2016
Built:
140811210803
Changelist:
1255500
JobID:
386543
2. Highlight and copy the output information and include it with your support case.
To copy provisioned module information at the command line
1. Type the following command:
tmsh list /sys provision

sys provision afm { }

sys provision am { }
sys provision apm { }
sys provision asm {
level nominal
}
sys provision asm { }
sys provision avr { }
sys provision fps { }
sys provision gtm { }
sys provision lc { }
sys provision ltm {
level nominal
}
155

sys provision pem { }

sys provision swg { }
2. Highlight and copy the output information and include it with your support case.
Open a case using WebSupport Portal

If you cannot find the answer to your problem using the resources listed above, you can open a support case online, using the F5
WebSupport Portal (websupport.f5.com).

Use of the WebSupport Portal requires a current support contract and registration on the F5 website (login.f5.com).
Once registered, youll receive an email within 24 hours letting you know your account has been enabled with WebSupport Portal
access.
To register for WebSupport Portal access
1. Navigate to F5 WebSupport Portal.
2. Click Register for an Account.
3. Enter your email address.
4. Complete the Contact information portion of the page and then select I have a support contract and
need access to WebSupport.
5. Enter your serial number or registration key (optional).
After you logging you can open a support case.

Once the information is assembled and appropriate documentation gathered, transfer it to F5 technical support following the
steps in Share diagnostic files with F5 technical support For more information, see AskF5 article: SOL2486: Providing files to F5
Technical Support.
Share diagnostic files with F5 technical support

F5 technical support may require diagnostic files to help resolve technical support issues. Upload files to F5 using one of the
following two methods:
Upload qkview diagnostic files to iHealth.
Upload/download files using dropbox.f5.com.
156

Upload qkview diagnostic files to iHealth

The preferred method for providing a qkview diagnostic file to F5 Support is to upload the file to the iHealth website. iHealth
allows you to quickly diagnose the health and proper operation of your BIG-IP system. For more information about using iHealth,
see iHealth in the TMOS Operations Guide.
Upload/download files using dropbox.f5.com

The dropbox.f5.com site is a widely available file repository for exchanging incoming and outgoing diagnostic files with the F5
Technical Support team. The dropbox.f5.com site supports HTTP, FTP, and SFTP for transferring files to F5, and FTP and SFTP
for retrieving files from F5.
User name and password

Access to the dropbox.f5.com site is associated with an open support ticket number with syntax CXXXXXX or 1-########. The
user name provided to the dropbox.f5.com site is the ticket number, and the password provided is an email address of a user
associated with the ticket.
For example, if joeuser@example.com has opened ticket C123456, he would log in to the dropbox.f5.com site using the following
information:

Username: C123456
Password: joeuser@example.com
If joeuser@example.com has opened ticket 1-12345678, he would log in to the dropbox.f5.com site using the following
information:

Username: 1-12345678
Password: joeuser@example.com
For more information regarding uploading and downloading files using dropbox.f5.com, see AskF5 article: SOL2486: Providing
files to F5 Technical Support.

This section discusses BIG-IP ASM data you may need to gather for your support case, as well as tools to collect that data.
Important F5 Technical Support is the single point of contact for security vulnerability questions. For more information, see AskF5
article: SOL4602: Overview of the F5 security vulnerability response policy.
Use asmqkview utility

F5 Technical Support requires asmqkview output in all BIG-IP ASM related cases.
The asmqkview script automatically collects configuration and diagnostic information from BIG-IP ASM systems. The output
includes all data collected in qkview files and other data for BIG-IP ASM systems in a single file, which you can then provide to
157

F5 Technical Support to aid in troubleshooting.

To run asmqkview in BIG-IP 11.6.0

asmqkview -s0 --add-proxy-log output: /var/tmp/<hostname>.qkview

To run asmqkview in BIG-IP 12.0.0

qkview -s0 -o asm-request-log output: /var/tmp/<hostname>.qkview

For more information, see AskF5 article: SOL6824: Overview of the asmqkview script.
Export security policy

You may be asked to provide an exported version of your security policy for F5 Technical Support to review.
You can export a security policy and save it in a file. The exported security policy can be used as backup, or you can import it
onto another system.
To export a security policy using the Configuration utility
1. Navigate to Security >> Application Security : Security Policies.
The Active Policies page opens.
2. In the Active Security Policies list, select the security policy that you want to export, then click Export.
Note You can also export security policies from the Inactive Policies list using the same method.
The Select Export Method pop-up page opens.
3. Select an export method.

To save the security policy as an XML file, select Export security policy in XML format. To reduce the size
of the XML file, select the Compact format check box.
To save the security policy as a policy archive file (.plc file), select Binary export of the security policy.
If the security policy integrates with a vulnerability assessment tool, select the Include Vulnerability
Assessment configuration and data check box.
4. Click Export.
The system exports the security policy in the format you specified.
158

For more information, see Importing and Exporting Security Policies in BIG-IP Application Security Manager: Implementations.
Capture HTTP request/response

You may be asked to provide an overview of the HTTP request/response from the client side. This can help F5 Technical Support
understand the problem and provide a baseline for reproduction of the issue in the lab.
F5 recommends using one of the following tools to collect the data:
HttpWatch (save as HWL)
Fiddler (save as SAZ)
Chrome (save as cURL)
Important HttpWatch and Fiddler are commercial software and a license is
required.
Example
In the following example, a Chrome browser is used to save a single HTTP request into a cURL command and the entire
transaction into an .har archive file.
1. Navigate to View > Developer > Developer tools > Network tab.
2. Refresh the page.
3. Locate the HTTP request in question.
4. Copy as cURL.
5. Send the content in clipboard to F5.
6. Save as HAR file.
7. Navigate to View > Developer > Developer tools > Network tab.
8. Refresh the page.
9. Save with HAR with content.
10. Send the output to F5 Technical Support.
159

Important Information leakage may occur when capturing sensitive

application transactions on production traffic.
Use tcpdump utility

You can use tcpdump to capture client-side and server-side traffic of HTTP request/response to help F5 reproduce and
troubleshoot your issue.
To capture traffic using tcpdump

tcpdump -i 0.0:nnn -s0 -w /var/tmp/asm _ traffic _ catpure.cap host

<Virtual server IP address> or host <Pool member IP address or Host more
pool member IP address> -vvv
Important Information leakage may occur when capturing sensitive application transactions on production traffic.
For more information, see the following AskF5 articles:
SOL411: Overview of packet tracing with the tcpdump utility
SOL6546: Recommended methods and limitations for running tcpdump on a BIG-IP system
SOL7227: Considerations when using the tcpdump utility with tagged VLAN traffic
SOL13637: Capturing internal TMM information with tcpdump
SOL2289: Using advanced tcpdump filters
Save UCS file

You may be asked to supply a user configuration set (UCS) file so that F5 Technical Support can load your configuration to
reproduce your issue in the lab.
To save a UCS file using TMSH at the command line

tmsh save sys ucs asm _ support

Output is logged to the /var/local/ucs/asm_support.ucs file.
For more information, see AskF5 article: SOL4423: Overview of UCS archives.
160

Important A typical UCS archive contains user accounts, passwords,

critical system files, and SSL private keys. However, you can explicitly exclude
SSL private keys from a UCS archive during the backup process. If your UCS
archive contains SSL private keys, you must store backup UCS archives in an
environment that is as secure as where you store your private keys.
161

Yes
No

Yes
No

Yes
No

Send
APPENDIX
Appendix
BIG-IP AAM dynamic caching integration
You can deploy both the BIG-IP ASM system and F5 BIG-IP Application Acceleration Manager (AAM) for a single web
application.
Considerations
The BIG-IP ASM system overrides the eligibility for caching entities that it inspects in the following instances:
Policy Builder is running and the policy is unstable.
A violation or learning suggestion is generated.
Frame cookies are either created or removed due to an issue such as dynamic parameter extraction.
The system processes a request triggering policy tightening suggestions (file types, URLs, or parameters).
The system processes requests for pages that have extractions configured (including pages with dynamic sessions).
The system processes requests for pages that are within a Flow Access (including URLs embedded in the cookie and
logout URLs).
Applying a BIG-IP ASM security policy invalidates the BIG-IP AAM cache.
The Policy Builder periodically applies a policy that invalidates the BIG-IP AAM cache. Use BIG-IP AAM only after automatic
learning is complete and disabled. When protecting websites where performance improvements are critical, you can also choose
a policy type (such as the rapid deployment policy template) that does not require continuous learning.
For more information, see AskF5 article SOL16565: Configuring a Web Acceleration profile for use with a BIG-IP ASM-enabled
virtual server (11.4.0 and later).
Integrated BIG-IP APM session tracking and event logging

The BIG-IP ASM system integrates with BIG-IP APM to provide combined session tracking and event logging. This allows you to
configure your security policy to capture user names from the BIG-IP APM login process. It also allows you to see application
security violations that are associated with a user session.
For more information, see Tracking User Sessions in BIG-IP Application Security Manager: Implementations.

The Multiple Decoding: Passes option for evasion techniques allows you to configure the number of encoding passes that the
system should use to decode multiple encoded characters. The decoding passes are performed on URI and parameter input.
You can locate the Multiple Decoding option by navigating to Policy > Blocking > Evasion Techniques.
163
APPENDIX
Note As part of the normalization process that BIGIP ASM uses, multiple decoding is performed whether or not the blocking
properties are enabled. You can enable blocking properties to alarm or block an evasion technique when one is detected.
You can configure the Multiple Decoding option to perform two to five passes.
The number of specified decoding passes determines how the system responds. It either flags the results as an evasion
technique, triggers an attack signature, or both.
When the blocking properties are not set for Multiple Decoding, the ability to identify signatures is reduced to the number of
encoded passes.
The following table shows the actions the BIG-IP ASM system takes on each of the decoding passes:
Table A.1 Decoding pass actions
Decoding Pass(es)
Behavior
2 to 3
Triggers an evasion technique but will not trigger an attack signature if one exists
Triggers an evasion technique and an attack signature if one exists
Triggers an attack signature if one exists, but does not trigger an evasion technique
For example, Multiple Decoding set to perform 3 decoding passes converts the following a%252fb string to a/b after the
second pass. On the third decoding pass, the system responds with the appropriate alarm or block action you have configured.

On first pass, the system looks at the hexadecimal %252f.
In ASCII, 25 translates to %, so the first pass decoding result is %2f.

On second pass the system decodes 2f to / in ASCII
The two decoding passes of a %252fb result in a/b

On third pass, the system takes action. The encoding attempt of the characters a/b results in action specified
by the Learn, Alarm, and Block settings of the Evasion Technique Detected category on the Blocking
Policy page.
For example, take the following string:
/nameandcolor.asp? aaa=%2525253cSCRIPT%2525253e
Using the previous string as an example within a URI, the string translates from hexadecimal to ASCII is as follows:
164
APPENDIX
Table A.2 Hexadecimal to ASCII translation

Hexadecimal
ASCII
25
3C
<
3e
>
The following table shows the decoding results for this URI string, based on the number of passes configured:
Table A.3 Decoding passes and results
Passes
2 to 3
Result
First decoding pass results in 25253c and 25253e.
Second decoding pass results in 253c and 253e.
Third decoding pass results in < and >.
System triggers an evasion technique and responds with the appropriate action.
The number of configured passes is not high enough for the system to check /nameandcolor.
asp?aaa=<SCRIPT> against the list of known attack signatures, which could possibly trigger an attack
signature.
Fourth decoding pass results in the system checking the fully decoded results against the known attack
signatures.
The system triggers both an evasion technique and an attack signature.
Fifth decoding pass results in the system triggering on the detected matching attack signature.
No evasion technique violation is reported.
Note A higher number of decoding passes impacts system performance. F5

recommends that you set blocking properties when you use the lower
settings (two to three passes).
165
APPENDIX

Term
Add All Entities
Definition
Add All Entities creates an explicit object in a security policy for each entity, such as file
type, parameter, or URL. Supports different attributes for each entity. Replaces Tightening
in previous versions.
Alarm
If selected, the BIG-IP ASM system records requests that trigger the violation in the Charts
screen, the system log (/var/log/asm), and possibly in local or remote logs (depending on
the settings of the logging profile).
Attack signature
Textual patterns which can be applied to HTTP requests and/or responses by BIG-IP ASM to
determine if traffic is malicious.
For example, the string <script> inside an HTTP request will trigger an attack signature
violation.
Attack signature set
A collection of attack signatures designed for a specific purpose (such as bot detection or
Apache).
Block
To prevent a request from reaching a protected web application.
Block
If selected (and enforcement mode is set to Blocking), the BIG-IP ASM system blocks
requests that trigger the violation.
Blocking response page
A blocking response page can be displayed to a client when a request from that client has
been blocked.
Also called blocking page and response page.
Bot
A software application, tool, or agent that runs automated tasks over the Internet. Can be
either malicious or benign.
Comprehensive policy
type
The Comprehensive policy type provides the most granular definitions, includes all security
features, and is suited for advanced users or customers with extreme security needs.
This policy type includes all elements in the Enhanced policy type, and adds URLs and
meta characters, parameters (meta characters and URLs), and dynamic parameters (using
statistics). This security policy typically takes longer to deploy.
Content profile
Configurable file which you can add to a security policy to allow BIG-IP ASM to understand
and parse specific content formats, such as JSON or XML.
166
APPENDIX
Term
Denial of Service (DoS)/
Distributed Denial of
Service (DDoS)
Definition
Denial of Service (DoS)/ Distributed Denial of Service (DDoS) An attack intended to
disrupt a network by consuming excessive bandwidth or cause a machine to stop servicing
requests by overloading it. Legitimate users are consequently denied service. In BIG-IP
ASM, DoS refers to layer7 DoS attacks (L7 DoS).
A Distributed Denial of Service (DDoS) is a DoS attack executed by multiple attackers. In
BIG-IP ASM, DDoS is often generically called DoS.
Enforce
To remove an entity or attack signature from staging.
Enforced
Indicates that the relevant object has been removed from staging. If a relevant violation
occurs, the request can be blocked (if the overall policy is in blocking mode.) See
enforcement mode.
Enforcement mode
Security policies can be in one of two enforcement modes:

Transparent mode
In transparent mode, blocking is disabled for the security policy, and you cannot set
the violations to block on the Blocking screen. Traffic is not blocked even if a violation is
triggered. You can use this mode and staging when you first put a security policy into
effect to make sure that no false positives occur that would stop legitimate traffic.
Blocking mode
In blocking mode, blocking is enabled for the security policy, and you can enable or
disable the Block flag for individual violations.
Traffic is blocked when a violation occurs if the following conditions are met: you
configure the system to block that type of violation, the staging period is over, you
removed all entities (explicit and wildcard) whose staging period is over from staging,
and deleted wildcard entities with tightening (whose tightening period is over) from the
security policy. You can use this mode when you are ready to enforce the security policy.
You can change the enforcement mode for a security policy on the Policy Properties
screen or the Policy Blocking Settings screen.
Enforcement readiness
period
For each security policy, you can configure the number of days used as the enforcement
readiness period, also called staging. Security policy entities and attack signatures remain
in staging for this period of time before the system suggests that you enforce them. Staging
allows you to test security policy entities and attack signatures for false positives without
enforcing them. The default value of 7 days works for most situations so you typically do not
need to change it.
167
APPENDIX
Term
Definition
Enhanced policy type
The Enhanced policy type provides additional granularity and security features suited for
customers with higher (and, typically, specific) security needs. This policy type includes all
elements in the Fundamental policy type, and also includes parameters and lengths (global
level), cookies, and methods.
Entities
The elements of a security policy, such as HTTP methods, as well as file types, URLs, and/or
parameters, which have attributes such as byte length. Also refers to elements of a security
policy for which enforcement can be turned on or off, such as an attack signature.
Explicit entities learning
The Explicit Entities Learning scheme provides you with three tools for instructing BIG-IP
ASM what to learn and how to learn it.
Three learning modes apply to the four main entity types that have attributes: URLs,
Parameters, File Types, and Redirection Domains.
The modes are Add All Entities, Never (Wildcard Only) and Selective.
False positive
An instance when BIG-IP ASM treats a legitimate request as a violation.
File types
Examples of file types are .php, .asp, .gif, and .txt. They are the extensions for many objects
that make up a web application. File types are one type of entity a BIG-IP ASM policy
contains.
Fundamental policy
type
The Fundamental policy type provides granularity sufficient for most organizations creating a
generalized security policy that is easy to maintain. This policy type includes HTTP protocol
compliance, evasion techniques, file types and lengths, attack signatures, and the request
length exceeds predefined buffer size violation. This is the default setting.
Ignore/Ignore
Suggestion
The action of instructing BIG-IP ASM to no longer create learning suggestions for a specific
violation or entity.
Illegal request
A request which violates a security policy.
Learn
The action of allowing violations or entities such as file types, URLs, and parameters to the
security policy. Entities which have been learned can be either enforced or staged.
Learn
If selected, the BIG-IP ASM system generates learning suggestions for requests that trigger
the violation.
Learning
The iterative process BIG-IP ASM uses to adapt a policy in order to ultimately prevent false
positive violations and accurately profile legitimate interactions with the application. Also
called Policy Building.
Learning score
A value from 1 to 100, that determines the confidence level of a suggestion, before it is
accepted into the policy. Once a suggestion reaches a score of 100%, it can be safely added
to the policy.
168
APPENDIX
Term
Learning mode
Definition
Learning mode is a setting indicating how learning suggestions are processed by the BIG-IP
ASM system.
The learning process makes a security policy more accurate by verifying how it complies with
traffic requests. If the learning process finds discrepancies between the security policy and
the traffic requests, it translates the discrepancies into a learning suggestion for modifying
the security policy.
Automatic: Learning suggestions will be accepted when the Learning Score reaches 100%.
Manual: You must manually accept learning suggestions.
Disabled: Automatic policy is not running and no suggestions are being created.
Learning suggestion
The BIG-IP ASM system generates learning suggestions for requests that cause violations
and do not pass the security policy checks.
You can examine the requests that cause learning suggestions, and then use the
suggestions to refine the security policy. In some cases, learning suggestions may contain
recommendations to relax the security policy.
When dealing with learning suggestions, make sure to relax the policy only where false
positives occurred, and not in cases where a real attack caused a violation.
Legal request
A request which has not violated the security policy, or a request which involves an entity
that is in staging.
Local traffic policies
Local Traffic Policies allow you to direct HTTP traffic based on rules, such as the presence of
a specific URI, and to take action on that traffic based on the rule, such as sending a request
to a specific security policy. Also called Central Policy Management or CPM.
Loosening
The process of adapting a security policy to allow specific entities such as file types, URLs,
and parameters. The term also applies to attack signatures, which can be either manually or
automatically disabled--effectively removing the signature from triggering any violations.
Modular blocking
Modular blocking is the process of gradually changing a security policys mode from
transparent to full blocking mode.
Never (Wildcard Only)
This learning mode is based on a wildcard representation of file types, parameters, cookies,
URLs, and redirection domains. The wildcard, indicated by an asterisk (*) is never removed
from the policy by BIG-IP ASM if the policy is configured in this mode.
Parameters
Parameters consist of name=value pairs, such as OrderID=10. The parameters appear in

the query string and/or POST data of an HTTP request. Consequently, they are of particular
interest to BIG-IP ASM because they represent inputs to the web application.
Policy Builder
The BIG-IP ASM automatic policy building tool. Also called Real Traffic Policy Builder (BIGIP 11.6) and Automatic Policy Builder (BIG-IP 12.0).
Policy Diff
The Policy Diff tool allows you to easily view differences between two security policies, and
to merge configured elements (such as URLs and Login Pages) from one security policy to
another.
169
APPENDIX
Term
Definition
Policy Merge
BIG-IP ASM policy merge option combines two security policies. In the merge process, the
system compares, and then merges, specific features from one security policy to another.
Rapid deployment
policy
The rapid deployment security policy provides security features that minimize the number
of false positive alarms and reduce the complexity and length of the deployment period. By
default, the Rapid Deployment security policy includes the following security checks:

Performs HTTP compliance checks
Stops information leakage
Prevents illegal HTTP methods from being used in a request
Checks response codes
Enforces cookie RFC compliance
Applies attack signatures to requests and responses
Selective learning
In selective learning mode, the BIG-IP ASM system only creates suggestions for adding
new policy entities if they have different attributes from the wildcard (for example, a violation
created because a parameter had a value length of 70, when the wildcard was set with an
allowed value length of 25).
Staging
Staging means that the system applies policy attack signatures to web application traffic, but
does not apply the blocking policy action to requests that trigger those attack signatures.
The default staging period is seven days.
Whenever you add or change signatures in assigned sets, those are also put into staging.
You also have the option of putting updated signatures in staging.
Tightening
The process of enforcing entity lists such as file types, parameters, and URLs (removing
the wildcard), and enforcing those attack signatures which were not triggered during the
enforcement readiness period.
TPS/RPS
Transactions per second (TPS)/Requests per second (RPS). In BIG-IP ASM, these terms are
used interchangeably.
Tuning
Making automatic or manual changes to an existing security policy to reduce false positives
and increase the policys security level.
URI/URL
The Uniform Resource Identifier (URI) specifies the name of a web object in a request. A
Uniform Resource Locator (URL) specifies the location of an object on the Internet. For
example, in this web address http://www.siterequest.com/index.html, index.html is
the URI and http://www.siterequest.com/index.html is the URL.
In BIG-IP ASM, the terms URI and URL are used interchangeably.
170
APPENDIX
Term
Violation
Definition
Violations occur when some aspect of a request or response does not comply with the
security policy. You can configure the blocking settings for any violation in a security policy.
When a violation occurs, the system can learn, alarm, or block a request (blocking is only
available when the enforcement mode is set to blocking).
Violation names displayed in the Violation List are the names used as reference in the iRule
ASM::custom_violation command and the ASM::violation name command. The violation
name is also used in API, iControl, and TMAPI code.
You can also create user-defined violations if you need them on your system.
171

Yes
No

Yes
No

Yes
No

Send
APPENDIX
Resource Materials
Resource Materials
BIG-IP ASM product documentation
BIG-IP ASM product documentation provides step-by-step instructions for how to create a security policy and add available
protections.
BIG-IP ASM documentation for 11.6.
BIG-IP ASM documentation for 12.0.
AskF5 articles
The following articles contain information you may find useful.
For information about
Opening a support case
See this article
SOL6825: Information required when opening a support case for

BIG-IP ASM
Updating BIG-IP ASM attack signatures
SOL8217: Updating the BIG-IP ASM attack signatures
Understanding BIG-IP ASM cookies
SOL6850: Overview of BIG-IP ASM cookies
Using local traffic policies
SOL15085 Overview of the Local Traffic Policies feature
Configuring the language encoding
SOL6335 Overview of encoding language settings for BIG-IP ASM
Sending SNMP traps to communicate a blocked

request and violation
SOL7738 Configuring the BIG-IP ASM system to send SNMP traps
Redirecting response page to an external server
SOL7825: Redirecting a blocking response support ID to an
to communicate a blocked request and request violation
external error page

Working with evasion technique violations
SOL7929: Working with Evasion technique detected violations
Using the wildcard entity in the BIG-IP ASM system
SOL8623: Using the wildcard entity in BIG-IP ASM
Understanding the BIG-IP ASM system and caching
SOL14880: BIG-IP ASM may prevent object caching
Understanding the BIG-IP ASM system cookies
SOL6850: Overview of BIG-IP ASM cookies
173
APPENDIX
Resource Materials
For information about

BIG-IP ASM daemons
See this article
SOL14020: BIG-IP ASM daemons (11.x)
174
LEGAL NOTICES
Resource Materials
Legal Notices
Publication date
This document was published July 2016. Publication Number: BIG-IP ASMOps 01_1.
Copyright
Copyright 2013-2016, F5 Networks, Inc. All rights reserved.
F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5 assumes no responsibility for
the use of this information, nor any infringement of patents or other rights of third parties which may result from its use. No
license is granted by implication or otherwise under any patent, copyright, or other intellectual property right of F5 except as
specifically described by applicable user licenses. F5 reserves the right to change specifications at any time without notice.
Trademarks
AAM, Access Policy Manager, Advanced Client Authentication, Advanced Firewall Manager, Advanced Routing, AFM, APM,
Application Acceleration Manager, Application Security Manager, ARX, AskF5, ASM, BIG-IP, BIG-IQ, Cloud Extender,
CloudFucious, Cloud Manager, Clustered Multiprocessing, CMP, COHESION, Data Manager, DevCentral, DevCentral [DESIGN],
DNS Express, DSC, DSI, Edge Client, Edge Gateway, EdgePortal, ELEVATE, EM, Enterprise Manager, ENGAGE, F5, F5[DESIGN],
F5 Certified [DESIGN], F5 Networks, F5SalesXchange [DESIGN], F5Synthesis, f5Synthesis, F5Synthesis[DESIGN], F5
TechXchange [DESIGN], Fast Application Proxy, Fast Cache, FirePass, Global Traffic Manager, GTM, GUARDIAN, iApps, IBR,
Intelligent Browser Referencing, Intelligent Compression, IPv6 Gateway, iControl, iHealth, iQuery, iRules, iRules OnDemand,
iSession, L7 RateShaping, LC, Link Controller, Local Traffic Manager, LTM, LineRate, LineRate Systems [DESIGN], LROS, LTM,
Message Security Manager, MSM, OneConnect, Packet Velocity, PEM, Policy Enforcement Manager, Protocol Security Manager,
PSM, Real Traffic Policy Builder, SalesXchange, ScaleN, Signalling Delivery Controller, SDC, SSL Acceleration, software
designed applications services, SDAC (except in Japan), StrongBox,
SuperVIP, SYN Check, TCP Express, TDR, TechXchange, TMOS, TotALL, Traffic Management Operating System, Traffix
Systems, Traffix Systems (DESIGN), Transparent Data Reduction, UNITY, VAULT, vCMP, VE F5 [DESIGN], Versafe, Versafe
[DESIGN], VIPRION, Virtual Clustered Multiprocessing, WebSafe, Silverline, and ZoneRunner, are trademarks or service marks of
F5 Networks, Inc., in the U.S. and other countries, and may not be used without express written consent.
All other product and company names herein may be trademarks of their respective owners.
175
LEGAL NOTICES
Notice
Patents
This product may be protected by one or more patents. See the F5 Patents page (f5.com/about/guidelines-policies/patents).
Notice
THE SOFTWARE, SCRIPTING, AND COMMAND EXAMPLES ARE PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE, SCRIPTING AND COMMAND EXAMPLES, OR THE
USE OR OTHER DEALINGS WITH THE SOFTWARE, SCRIPTING, AND COMMAND EXAMPLES.
176

f5 Asm Operations Guide

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

f5 Asm Operations Guide

Încărcat de

Drepturi de autor:

Formate disponibile

BIG-IP Application Security Manager

A Web Application Firewall that

A message from Julian Eames,

Before using this guide

Common terms and concepts

Limits of this guide

Feedback and notifications

BIG-IP ASM security policy life cycle

Policy tuning details

Additional security checks

Tips and guidelines

Protect multiple applications using Automatic Policy Builder with a QA environment

Protect multiple applications using Automatic Policy Builder, no QA environment

Protect multiple applications with generic policy using manual learning

Protect applications with policy automatically built in non-production environment

Protect an application from DoS/DDoS attacks

Protect an application from web robots

BIG-IP ASM API/Web Services Protection

Web API Use Cases

RESTful API services

BIG-IP ASM Event Logging

Log display formats

Policy Tuning and Enhancement

BIG-IP ASM 12.0 Policy Builder updates

Manual learning and policy building

Attack signature tuning

Transition enforcement mode from Transparent to Blocking

Session tracking and login pages

Compare and merge policies

Regulatory compliance of WAFs

Open Web Application Security Project Top 10

Payment Card Industry Data Security Standard 3.1

Health Information Portability and Accountability Act

National Institute of Standards and Technology

Common Deployment Topologies

Platforms and licenses

Common topology options

Common Management Tasks

Maintain IP intelligence database

Back up your BIG-IP configuration information

Troubleshoot BIG-IP ASM

Use platform logs

Check BIG-IP ASM system health

Bypass BIG-IP ASM

Handle unexpected HTTP responses

Monitor CPU usage

Troubleshoot memory usage

Optimize the support experience

F5 technical support offerings

GUARDIAN Professional Services Partners

Review self-help options

F5 Global Training Services

Send information to Support

Collect BIG-IP ASM data

Use multiple decoding passes with evasion technique

BIG-IP ASM terminology

ABOUT THIS GUIDE

About this guide

Before using this guide

(support.f5.com) for platform guide to find the appropriate guide.

BIG-IP TMOS: Operations Guide.

Common terms and concepts

ABOUT THIS GUIDE

HTTP request components

If not, what information should be included that is not?

If yes, please describe the error:

If yes, please describe the error: