F5 BIGIP ASM Presentation

Instructor
Manoj Verma | CCIE 43923

Highly experienced (19 Years Exp.)
Senior Technical Instructor and
Network/ Security Consultant
Vendors & Technologies:

F5,Palo Alto,Checkpoint,Cisco,Fortigate,AWS
Cloud,Microsoft Azure (MCT in year 2002),BGP/MPLS,QOS,
SD WAN ,VMware etc.…….
Nettech | A passion to see you at the top www.nettechcloud.com

F5 BIGIP ASM (WAF) – Application Security Manager
COURSE OVERVIEW:
 In this course, you will learn how to deploy, tune, and
operate BIG-IP Application Security Manager (ASM) to
protect your web applications from HTTP-based attacks.
 The course includes lecture, hands-on labs, and discussion
about different ASM components for detecting and
mitigating threats from multiple attack vectors such web
scraping, Layer 7 Denial of Service, brute force, bots, code
injection, and zero day.

Course Topics
Module 1 - Setting up BIGIP System
Module 2 - Traffic Processing with BIG-IP
Module 3 - Web Application Concepts
Module 4 - Common Web Application Vulnerabilities
Module 5 - Security Policy Deployment
Module 6 - Policy Tuning and Violations
Module 7 - Attack Signatures
Module 8 - Positive Security Policy Building
Module 9 - Cookies and Other Headers

Course Topics
Module 10 - User Roles and Policy Modification
Module 11 - Reporting and Logging
Module 12 - Advanced Parameter Handling
Module 13 - Using Application-Ready Templates
Module 14 - Automatic Policy Building
Module 15 - Web Application Vulnerability Scanner Integration
Module 16 - Layered Policies
Module 17 - Login Enforcement, and Session Tracking
Module 18 - Brute Force and web scraping
Module 19 - Layer 7 DoS Mitigation and Advanced Bot Protection

ASM Lab Topology
Client -Desktop/Laptop
IP : 192.168.0.X/24 http://192.168.0.201
Self IP : 192.168.0.200/24
1.2 External
Management IP
172.16.1.1/24 F5 BIP-IP [LTM & ASM]
1.1 Internal
Self IP : 10.128.1.1/24
MY SQL
PHP
Linux/Unix PHPauction2.1
Apache/Tomcat IP: 10.128.1.150/24

MODULE 1 : SETTING UP THE BIGIP SYSTEM
Agenda :
• Packet Based Design Vs Full Proxy Architecture
• What’s Inside a BIG IP SYSTEM
• BIG-IP Platforms
• What’s outside a Hardware BIG IP SYSTEM
• Initial BIG-IP setup
• Licensing, Provisioning and Network Configuration
Packet based Vs. Full Proxy Architecture
Packet based design:

A Network device with a packet based ( or packet-
by-packet) design is located in the middle of
communication streams, but is not an endpoint for
those communications. For example, routers
change layer 2 information, but then just pass
traffic along

Packet based Design

Full Proxy Architecture
Full proxy Architecture:
 The system is placed in the network between the clients

and the servers. Incoming requests are handled by the
BIG-IP, which interacts on behalf of the client with the
desired server or service on the server.
 A full proxy maintains two separate layer 4 connections
– one on the client side, one on the server-side

Full Proxy Architecture

What’s Inside a BIG IP SYSTEM?
The internal architecture of a BIG-IP system is separated

into two functional areas:
 One that is responsible for operational management

 And another that is primarily responsible for traffic
management but also handles certain aspects of BIG-IP
operation.

What’s Inside a BIG IP SYSTEM?

Operational and Traffic Management
1. Operational management or administration

The operational management side of the BIG-IP system does
not manage traffic; it provides administrative functionality
through the Linux shell (bash), TMOS shell (TMSH) and GUI
interface
2. Traffic Management
Traffic flowing through a BIG-IP system passes through TMOS,
to provide traffic management functions. These functions
include:

Traffic Management
BIG-IP Local Traffic Manager (LTM)- LTM is a local area

application traffic management solution: provides intelligent
traffic management as well as advanced application security,
acceleration , and optimization
BIG-IP DNS (GTM) –Intelligent and Accelerated DNS resolution:

Directs users to the best-performing data center
BIG-IP Access Policy Manager (APM) - Access Control:
Integrates and unifies secure user access to applications.

Traffic Management
BIG-IP Application Security manager (ASM) - Application security:

ASM provides comprehensive security for IP-based applications
and services, protecting them against known and unknown
external threats at the network and application layers.
BIG-IP Advanced Firewall Manager (AFM) - Network firewall:

Protects apps from even the most aggressive volumetric DDOS
attack.
Etc.

BIG-IP Platforms
Virtual Edition:
Different situations call for the BIG-IP Virtual Edition and the
physical BIG-IP hardware. F5 BIG-IP virtual editions (VEs) are
virtual application delivery controllers (vADCs) that can be
deployed on all leading hypervisors and cloud platforms running
on commodity servers. It also provides flexible and quick
deployment options and failure isolation.

BIG-IP Platforms
Hardware:
 Physical hardware provides a number of important
benefits and is necessary in many situations. F5 hardware
is purposefully built to provide high performance for
application delivery.
 BIG-IP physical device can run all BIG-IP modules and
perform hardware SSL offload and compression

What’s outside a Hardware BIG IP SYSTEM?
MGMT: Management
interface with the default
IP address 192.168.1.245
CONSOLE: Console port is
used to connect serial
console cable for CLI access
FAILOVER: Failover serial
port is used to connect
redundant F5-BIG IP
system
USB: USB port is used to connect external
DVD or flash drive for installing
upgrades and system recovery

Licensing, Provisioning, and the Setup utility
BIGIP Setup Utility

 Accessing the BIGIP system
 Licensing
 Provisioning
 BIGIP Platform properties -
 Standard Network Configuration
IP addresses
VLAN Interfaces
NTP servers
DNS settings

Accessing the BIGIP system
Configuring the Management Interface

One of the first steps in setting up BIGIP system is to configure the
management interface. The management interface is used by the
BIGIP system to perform management functions, and is intended for
administrative traffic only. -
 There are several ways to access the BIGIP system to configure
management Interface
 Using LCD panel and control Buttons
 Using Management port – Via Network Cable (HTTPS/SSH)
 Using a serial cable – Via Console port (CLI access)

Accessing the BIGIP system
LOGIN [CLI]
root/default
Connect via default IP
Network address
Serial console cable https://192.168.1.245
cable
- LOGIN
Mgmt port
admin/admin
Console Port LCD Panel and Controls

Licensing
The Licensing process consists of five basic steps
1. Finding Base registration Key
2. Generating the dossier on the BIGIP system . DOSSIER
contains encrypted information that identifies platform to
the F5 Licensing server. Dossier
- also includes the registration
key.
3. Sending the dossier to the F5 License server at
https://activate.f5.com [Manual Licensing]
4. Generating License and sending back to the BIGIP system
5. Installing License on the BIGIP system

Provisioning Modules and Resources
The process of allocating CPU, memory and disk space to licensed software modules
is called provisioning.
(License determines what software modules the BIGIP system will support.)
 Provisioning Management Module
Small, Medium and Large – Configuration utility
 Provisioning Levels
Dedicated : Dedicated setting specifies that- this is only active module
Nominal : Nominal gives the module its minimum functional resources and distributes
additional resources to the module only if they are available after all other
provisioned modules are enabled.
Minimum : Minimum setting allocates the least amount of resources required for the
module to be enabled. No additional resources are ever allocated to the
module during operation.

BIGIP Platform Properties
After licensing and provisioning, the setup utility provides

for quickly defining (or changing) certain BIGIP platform
properties.
 Management IP address, netmask and IP address of
default route -
 Hostname and time zone
 Passwords for both root and admin
 Controlling SSH access

Standard Network Configuration
 Network configuration wizard requires to assign self and floating IP

addresses for VLAN internal and external
VLAN: A virtual VLAN is way of logically partitioning a physical
network so that distinct broadcast domains are created.
-
 A self IP address is an IP address/netmask combination on the BIGIP
system that is associated with a VLAN
 VLAN Tag IDs can be manually defined for each VLAN , although F5
recommendation is to let the system retain the default Value, auto.

MODULE 2 : Traffic Processing with BIG-IP
Agenda :
• Identifying BIG-IP Traffic Processing Objects
• Overview of Network Packet Flow
• Understanding Profiles
• Overview of Local Traffic Policies
• Visualizing the HTTP Request Flow

Identifying BIG-IP Traffic Processing Objects
Node:
• A node is a Logical configuration object on BIG-IP that
identifies the IP address of a physical device on the network.
• A single node may logically represent multiple members
• Nodes are typically not defined directly. Rather as a pool
member is defined , its associated node object is automatically
created, if necessary.
• A node definition on the BIG-IP system consists of an IP
address only.

Pool Member:
• Pool members are conceptually the actual application services
used to process client traffic, and are defined as configuration
objects on the BIG-IP system.
• A pool member includes both an IP address and service port
for example 172.16.1.1:80
• The same IP:Port combination can be defined in multiple load
balancing pools, but each is treated as a separate and distinct
pool member within the BIG-IP system.

Pool:
• A pool is a logical set of pool members that are grouped
together to receive and process a certain type of traffic
• With a few exceptions, all the members of a given pool
typically host the same content.
• LTM uses the load balancing method, along with other
criteria to determine which pool member to direct network
traffic to.

Virtual Servers:
• As a default deny device, the BIG-IP system will not process
traffic unless it is told to specifically listen for traffic.
A virtual server is one such listener
• Client traffic is directed to the virtual server on the BIG-IP
system; BIG-IP system then directs traffic to the pool member
• Virtual servers also include many other properties that give it
to the intelligence it needs to process the traffic that it
receives.
Understanding Network Packet Flow
 When a client connection arrives on the BIG-IP system, its

destination is a virtual server address and port. The BIG-IP
system further processes the request based on the virtual
server’s configuration and sends it to a different final
destination – a pool member. This translation process is
transparent to the client.
 By default, destination IP address and Port address translation
is enabled per virtual server basis.

Understanding Profiles
 Profiles are powerful configuration tools that provide an easy

way for you to define traffic policies and then apply those
policies across many virtual server, effecting change in traffic
settings more efficiently.
 Most importantly though, profiles are a configuration tool that
you can use to
-Affect the behaviour of certain types of network traffic
-Help increase performance and throughput on the network
-offload work from internal application servers

Understanding Profiles
Why an HTTP profile is required for ASM:
As a Layer 7 web application firewall, ASM must be able to

process HTTP Traffic. Therefore, an HTTP profile is required
on any virtual server for which you want to enable ASM,

Overview of Local Traffic Policies
 Local Traffic policies provide another mechanism for

customizing application delivery through a BIG-IP system.
 Local traffic policies offer a subset of the functionality available
via iRules, without having to know the Tcl
 As with an iRule , a local traffic policy is assigned to a virtual
server to direct traffic accordingly.
 You can use Local traffic policies to do all sorts of things that
were previously only possible using an iRule

How Local Traffic Policies Work
Virtual Server
HTTP Profile
Layer 7 Local Traffic Policy

Host Name | IP address | URI path | Headers | cookies
Security Policy A
Security Policy B
Security Policy C

How Local Traffic Policies Work
 A default local traffic policy can be created automatically, by

enabling application security on a virtual server. This default
policy is referred to as a Layer 7 local traffic policy, and
continues a default rule which forwards all traffic to a single
application security policy selected by the administrator.
 Once you assign a local policy to a virtual server, its rules are
now conditionally applied against all traffic passing through
that virtual server.

The HTTP Request Flow
Virtual Server Request
Default Pool
Yes
Default No Matches Yes
ASM Policy
Pool? Layer 7
No Policy ?
Request ASM
Dropped enabled ?
Yes
No
Valid
Violation Request ? Default Pool
No Yes

MODULE 3: Web Application Concepts
Agenda :
• Overview of Web Application Request Processing
• Web Application Firewall: Layer 7 Protection
• ASM Layer 7 Security Checks
• Overview of Web Communication Elements
• Overview of the HTTP Request Structure
• Examining HTTP Responses
• How ASM Parses File Types, URLs, and Parameters
• Using the Fiddler HTTP Proxy

Overview of Web Application Request Processing
Most commercial web applications consist of at

least three main components:
1. Web Server
2. Application server
3. Database Server

Multi-level interaction between user and database.

 A client interacts with the web server by sending HTTP requests
and then waiting for a response. The web server will frequently
need to interact with other services, such as application servers to
generate the HTTP response. In addition, the application server may
in turn have to query a database to be able to create its response.
This entire process is the web application.
 While a browser is the most common client, other tools such as

cURL,Burp Suite and WebScarab can also communicate with the
web application.

Web Applications are vulnerable even with SSL
 When an organization deploys a web application, it invites the

world to send HTTP requests to the application. Many attacks
buried in these requests sail past firewalls, filters, platform
hardening and intrusion detection systems without notice
because they are inside legal HTTP requests.
 Each part of the web application can potentially be vulnerable

to attacks.

Layer 7 Protection with WAFs
Web Application Firewalls:

While traditional network firewalls work at layer 3 and 4 of OSI
model, WAFs work at the application layer (Layer7)
Why Deploy a WAF ?
• Do you perform a Vulnerability assessment of your web
application ? If yes, how much time does it take to fix
vulnerabilities ?
• Would you like to control web application security without
involving the development team ?

Layer 7 Protection with WAFs
• How is your organization securing inbound traffic after passing

through network firewalls and IPS/IDS devices ?
• Do you have a requirement to be a Payment Card Industry (PCI)
Compliant?
• How aware are you of bots and other automated tools that are
crawling your site?
• Are you aware of the OWASP top 10 ? Do you need to protect
against web application vulnerabilities?

Overview of Web Communication Elements
What happens when you click on a web page ?

1. DNS Resolves the domain name to an IP address
2. TCP/IP carries the request/response data
3. The response data consists of HTTP,HTML and other page
information
4. HTTP Provides the framework for the browsers to construct
the request
5. HTML describes the page layout and content

Parsing URLs
The URL(Uniform Resource Locator) has two main Components:

1. Protocol identifier – Indicates the protocol to be used
2. Resource name – the complete address to the resource
Consider the following URL:
http://support.f5.com/kb/en-
us/search.html?product=asm&searchType=basics&query=protocol&productVers
ion=all&documentsType=all
Protocol identifier : HTTP

Resource name : support.com/kb/en-us/………………all&documentsType=all

Parsing URLs
The Resource Name is broken into following elements:

Hostname : support.f5.com
File name : /kb/en-us
Request Object(URI-Uniform Resource Identifier): search.html
Query string: The query string is separated from the hostname/
filename by a question mark ? and typically
composed of series of parameter-value pairs.
product=asm&searchType=basics&query=protocol&productVe
rsion=all&documentsType=all

Overview of the HTTP Request Structure
An HTTP request has the following structure:
1. Request Line – Consists of the method used for the request,

the URI being requested and the HTTP Version
2. Headers – Headers are name/value pairs that appear in both
request and response messages after the first line.
3. Message Body (optional) – Parameters specified via POST
method.

Overview of the HTTP Request Structure
Uniform Resource Identifier (URI):
URI can be represented in absolute form or relative to some

known base URI, depending upon the context of their use.
Absolute URI – http://www.f5.com
Relative URI – /relative/URI/with/absolute/path/resource.txt
(Absolute URI always begin with a scheme name followed by a colon)
The URL typically includes the path and file name desired by the
client, but may only be a single slash / (index.html)

Overview of the HTTP Request Methods
HTTP Request Methods:

1. GET – Retrieves whatever information is identified by the
request-URI
2. HEAD – Asks for the response that is identical to the to a GET
request, but without the response body
3. POST – The post method is used to send data to a web
application
4. PUT – Allows a client to upload new files on web server

Overview of the HTTP Request Methods
5. DELETE – This method allows a client to delete a file on the web

server.
6. CONNECT – This method could allow a client to use the web
server as a proxy
7. TRACE – This method simply echoes back to the client whatever
string has been sent to the server, and is used mainly for
debugging purposes.
8. OPTIONS - The OPTIONS method is used by the client to find out
the HTTP methods and other options supported by a web server

Comparing POST with GET
GET request considerations:

 GET Requests can be cached , No issue if page is
refreshed from cache
 GET Requests remain in the browser history
 GET Requests can be bookmarked
 GET Requests have length restrictions[2048 Characters]
 GET Requests should be used only to retrieve data

Comparing POST with GET
POST Request Considerations:

 POST requests are never cached, Data will be
resubmitted if page is refreshed or Backed
 POST requests do not remain in the browser history
 POST requests can not be bookmarked
 POST requests have no restrictions on data length

Examining HTTP Responses
HTTP Responses are generally composed of three sections

 HTTP Version and Response code
 Response header
 Body of the Response
HTTP Response status Codes:
100 - Informational (Not supported by HTTP 1.0)
200 - Successful to some degree
300 - Redirection needed
400 - Error seems to be in the client
500 - Error seems to be in the server

Examining HTTP Responses
HTTP Response Header
Response headers provide information about the payload of the
HTTP message
Content-type: text/html (Data Type )
Content-length: Length of the body
Expires: Time after which resource may no longer be valid
Last Modified: Date and time of last changed to the entity body
Content Encoding: gzip (Format of a compressed resource)
Message Body (optional)

Response payload (HTML, Images, Scripts, Video etc.

How ASM Parses File Types, URLs & Parameters
1. GET /search.php?name=student1&status=1 HTTP/1.1

2. Host: 172.16.200.10\r\n
3. Connection: keep-alive\r\n
4. User-Agent: Mozilla/5.0(windows NT6.1) \r\n
5. Accept: text/html,application/xhtml+xml,application/xml;q=0.9 \r\n
6. Referer: http://172.16.200.10/search.php?q=data \r\n
7. Accept-Encoding: gzip,deflate, \r\n
8. Accept-Language: en-GB,en=US,q=0.8,en;,q=0.6 \r\n
9. Accept-Cahrset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 \r\n

 How ASM Parses File Types, URLs & Parameters
 In Line 1 , ASM can verify HTTP compliance by verifying that the
method is allowed. In Lines 2 through 9 , ASM can check if every line
ends with \r\n and if each header is valid and includes a value.
 In Line 1 and 6, ASM can enforce valid file types
 Additionally in lines 1 and 6 , ASM can enforce a list of valid URLs
 In lines 1 and 6 , ASM can check for a list of valid parameter names
 For each parameter ASM can then enforce a maximum value length
allowable by the web application
 Finally before sending the HTTP request to the web application, ASM
can scan each parameter, the URI and headers for known attack
patterns
Fiddler HTTP Proxy Tool
 Fiddler allows you to inspect all HTTP traffic, and generally

“fiddle” with incoming or outgoing data
 Fiddler is helpful in two ways. First, requests are instantly
logged and displayed in summary. Second the inspector lets
you see details of what is happening with each request
 Fiddler can break any request and allow you to inspect and
modify the request before sending it along

MODULE 4 : Common Web Application Vulnerabilities
Agenda :
• Injection attacks
• Parameter Tampering
• Hidden Field Manipulation
• Forceful Browsing
• Cross site scripting

Common Exploits Against Web Applications
Injection attacks :
 OWASP defines injection attacks as untrusted data sent to an
interpreter (such as SQL,LDAP) as part of a command or query
 A very common type of injection is SQL injection
 Through an SQL injection, an attacker can input specifically
crafted SQL Commands with the intent of bypassing the login
process. This can only be possible if the inputs are not
sanitized, or properly prevented from reaching the back-end
system, and sent directly with SQL query to database.

Common
Common Exploits
Exploits Against
Against Web Web Applications
Applications
ASM mitigation
ASM protects the web application from injection attacks
by checking for allowed characters in parameter name
and value inputs, checking for malicious patterns in user
input parameters, and verifying query string and POST
data request lengths.

Parameter tampering
Parameter tampering can occur when a web application
exposes a reference to an internal object to the user.
Examples of internal objects are URLs, parameters, files,
directories, hidden fields.
ASM Mitigation
ASM checks for allowed characters in the parameter name and
value, checks for malicious patterns in user input parameters,
and verify query string and data request lengths.

Hidden Field Manipulation

 In many applications, hidden HTML form fields are used to
hold system passwords or merchandise pricing.
 A hidden field is a type of dynamic field that is placed in the
HTML form using a keyword “hidden”. For instance, in the form
where you input a credit card number to purchase a book,
there might be hidden fields that contain a book inventory
index and a price

ASM Mitigation
 ASM can protect against Hidden field Manipulation by
enforcing dynamic parameters (ensuring that the values
set by the server will not be changed on the client side)
 ASM also provides a whitelist for allowed URLs for a
specific applications.

Forceful browsing
 Forceful browsing refers to directly accessing a web page that
should not be available to unauthorized users, or a page to
which a link exists from an unauthorized hyperlink. In other
words, users can jump directly to parts of a web application
which they should not be able to access.
 Web applications that are not properly configured allow
malicious users to directly access URLs that could contain
sensitive information

ASM Mitigation
ASM can enforce allowed file types and URLs, and accurate
parameter values and login pages.
Cross-Site Scripting (XSS)

Cross-site scripting allows for the ability to make a user run the
hacker’s script while in the context of the attacked application.
ASM Mitigation
By enforcing XSS attack patterns

MODULE 5 : Security Policy Deployment
Agenda :
• Positive & Negative Security Models
• Deployment workflow
• Security Checks offered by Rapid Deployment
• Response Checks using Data Guard

Comparing Positive & Negative Security Models
Defining Negative Security:
 Negative security defines which interactions and inputs with a
web application are disallowed.
 Anything not explicitly disallowed is permitted
 A blacklist od IPs or the latest set of virus signatures on your
home computer are example of negative security.
 In ASM, attack signatures are an important part of negative
security. Attack signatures are rules and patterns that identify
attacks on a web application and its components.

Negative Security Models
Requests
RFC Compliance Evasion Attack Signatures

detection
Client
Server
Attack Data Guard

Signatures
Responses

Positive Security Models
Defining Positive Security:

 A positive security model explicitly defines what is allowed, and
rejects everything else. In a nutshell anything that does not
match the definition of acceptable behavior is unacceptable
 MAC address whitelists or IP address filters to control who is
allowed on network is example of positive security model
 With ASM policy, you can examine and control requests from
specific clients, allow only certain HTTP requests

Positive Security Models
Requests
Allowed File Allowed Allowed

Types URLs Parameters
Client
Server
Allowed HTTP
response Codes
Responses

The Deployment Wizard Workflow
1. Security Policy Name - User supplied name

2. Application Language – Every web application has an encoding
language that determines the character set that browsers use to
display the application. You must set the application language so
that ASM knows the acceptable character set for the application.
e.g. Charset= utf-8
3. Policy template - ASM provides application-ready templates
4. Enforcement Readiness Period – Trial period during which any
violations detected by ASM will not be blocked

The Deployment Wizard Workflow
5. Configure Attack Signatures – Administrators can assign

known attack signatures to protect operating system, web server
, database server, language and application vulnerabilities.
Although ASM provides generic attack signatures such as those
for detecting XSS and SQL injection.
Violations resulting from known attack signatures will not be
blocked until signatures are removed from staging.

Security Checks offered by Rapid Deployment
By default, the Rapid Deployment security policy includes the

following checks:
1. HTTP compliance checks:
• POST request with Content-length 0
• Header name with no header value
• Several Content-length headers
• No Host header in HTTP/1.1 request
2. Evasion technique detection:
Attackers attempt to encode attacks so that attack signatures

Security Checks offered by Rapid Deployment
And pattern matching systems cannot detect malicious code.

For Example: white space manipulation
3. Attack Signatures:
Attack signatures are rules and patterns that identify attacks
or classes of attacks on a web application and its components
-All attack signatures are in staging mode [Rapid deployment]
-Generic detection Signatures attack signatures are assigned
to the security policy

Response Checks using Data Guard
Data Guard is a feature used to prevent the release of sensitive

data in the response to an HTTP request. For example , if a web
server response contains a credit card number, US social security
number or a pattern defined with a regular expression that
matches certain criteria, ASM can enforce security in two ways.
 If the policy in in Blocking mode, and if the response contains
sensitive information, ASM will block response
 ASM will also mask the sensitive data by replacing it with a
string of asterisks ***********

MODULE 6 : Policy Tuning and Violations
Agenda :
• Defining False Positives
• How violations are categorized
• Violation Rating
• Enforcement settings & staging

Defining False Positives
 A false positive is an instance when ASM treats a

legitimate request as a violation
 False positives can effectively break the application
ASM is intended to protect and can negatively
influence the user experience with the application –
particularly if the security policy is configured to
block certain requests.

Defining False Positives
 ASM has a modular blocking capability, allowing a
combination of positives and negative security. This means
that you can configure handling certain violations such as
HTTP protocol compliance failure, independently from
violations which require more time to interpret. The idea is
that ASM can block some violations which are probably not
false positives from day one , while you to review other
violation that may reflect legitimate requests.

How Violations are categorized
 A violation is anything that is not in accordance with the

rules set forth in the security policy
 A violation can indicate a mismatch to an explicit security
policy definition , such as the allowable number of bytes
that can be entered into a web form or to something that
is not explicitly allowed, such as an HTTP request for an
executable file.

Violations Categories
 HTTP Compliance failed violations
 Attack signature violations
 Evasion technique detected violations
 File type violations
 URL violations
 Parameter violations
 Session and Login violations
 Cookie violations
 IP addresses/Geolocations violations

Violation Rating
 Each violation is rated on a severity scale
Rating Definition
0 Not rated = No violation
1 Most Likely a false positive
2 Looks like a false positive, requires examination
3 Needs further examination
4 Looks like a threat but requires examination
5 Request is most likely a threat

Enforcement settings & staging : Global policy Control
Enforcement Mode:
1. Transparent – ASM will log the request and send it to
the web application. Additionally , ASM will generate a
security violation that the ASM administrator can review
2. Blocking – The request can be blocked , ASM will still log
the request and a security violation will be generated.

Defining signature staging:

 Signature staging refers to attack signatures and is a trial
period (7 days is the system default) for allowing ASM to
build a list of false positives without harming traffic or the
user experience with the application.
 If an attack signature is in staging, requests which trigger
this signature will not be blocked, regardless of the policy’s
enforcement mode

Learning Mode : Automatic or Manual:

 Learning mode is one of the two methods for deciding when
and how to accept an entity into the security policy.
 A Learning suggestion can be managed manually (by the
administrator ) or automatically
Action offered by the Learning suggestion
1. Accept suggestion
2. Delete suggestion
3. Ignore suggestion

Learning and blocking settings
Learn : when the Learn checkbox is selected for a violation, and a
request triggers the violation, ASM generates learning
suggestions on the traffic learning screen
Alarm: when the Alarm checkbox is selected for a violation and a
request triggers the violation, ASM logs the request
Block: when the block checkbox is selected for a violation and
policy is in blocking mode, ASM will block the request which
caused the violation.

MODULE 7 : Attack Signatures
Agenda :
• Defining Attack signatures
• User Defined attack signatures
• Defining attack signature sets
• Attack Signatures and Staging

Defining Attack Signatures
 Attack signatures are rules and patterns that identify attacks

on a web application and its components
 Attack signatures are the basis for negative security Logic
within ASM because the rules and patterns in the signature
explicitly define what is disallowed
What attack Signatures inspect
uricontent – For requested URI
valuecontent – For query string,POST body, cookies
headercontent – For all the headers in the request
content – For the entire request

User Defined attack signatures
 User defined attack signature are those that the user creates
and adds to the attack signature pool
 Whenever creating signatures, several rules apply:
- They must adhere to the rule syntax defined by F5
- They are never updated by F5 Networks
- They are placed in staging mode whenever a user updates
any of the signature properties

Defining Attack signature sets
 An attack signature set is a grouping of individual attack
signatures. This way you can apply more than one attack
signature to a security policy.
 By Default there is generic attack signature set that is assigned
to a new security policies
 Individual signatures cannot be assigned directly to security
policies
 Signatures and signature sets are managed as global entities,
whereas the assignment of sets to the policy, their blocking
actions are attributes of a particular policy.
Updating Attack Signatures
 ASM has approximately 2,000 built-in attack signatures

 There is mechanism to update those attack signatures and
their default settings from an update file
 The update file can be downloaded and applied
automatically or can downloaded from f5 network
 If using the automatic method, BIG-IP uses its own self IP
address and default gateway when requesting attack
signatures

Understanding Attack Signatures and Staging
 Signature staging is enabled by default on new policies in order

to avoid false positive violations due to attack signature pattern
matching
 Attack signatures should remain in staging until they have been
sufficiently tested by the user
 If a staged attack signature is triggered, the offending request
will not be blocked even if the enforcement mode of the
security policy is Blocking
 Newly added signatures are always placed in staging, by default

MODULE 8 : Positive Security Building
Agenda :
• Security Policy Components
• Learning File Types, URLs, Parameters
• Choosing the Learning Scheme

Defining Security Policy Components
 Positive security means that only explicitly allowed HTTP

transactions between a client and the components of the
web application are permitted.
-Is the method allowed ?
-Is the file type allowed?
-Is the URL allowed?
-Are the parameters and parameter values allowed ?

Learning 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
 Each file type has configurable values which specify the
legitimate behavior and properties of each file type
 By creating a positive security definition for file types , you can
deny any requests for a resource with an undefined file type
Explicit – file types that are not wild card expressions such as .gif,.php
Wildcard – file type is a wildcard expression , indicated by a *
no_ext – No extension , no file types or the backslash (“/”)

Learning URLs
 URLs are specific objects in the protected web

application, such as /login.php and /sell.php
 ASM can learn URLs gradually and then you can
decide later if they should be added to a list of
allowed URLs
 When manually creating a URL , you have the option
of creating an Explicit or wildcard URL

Learning Parameters
 Parameters are an integral entity in any web application

 Parameters consist of “name=value” pairs , such as
OrderID=10
 Parameter appear in the query string and /or POST data
 When you define parameters in a security policy, you are
hardening the security for the web application because
you are protecting against tampering with parameter
names and values

Choosing the Learning Scheme
1. Learn Always - Choose this option if you would like to create a

comprehensive whitelist policy that includes all of the website
Parameters/URLs/File Types that match this wildcard.
2. Never (wild Card) – ASM will suggest changes to the attributes

only if the traffic shows different attributes values than the
ones specified by the administrator. When false positives occur
the system will suggest to relax the settings of the wildcard
Parameter.

Choosing the Learning Scheme
3. Selective – Selective mode will suggest the addition of explicit

entities to the policy if their attributes are higher (or different)
from attributes values specified in the wildcard. When false
positives occur, the system will add/suggest to add an explicit
Parameter/file types/URLs with relaxed settings that avoid the
false positive.
4. Compact - Choose this option if you would like to create a list of
the most commonly used parameters, while enforcing all other
parameters/file types/URLs with a wildcard rule.

MODULE 9 : Cookies and Other Headers
Agenda :
• ASM Cookies: What to Enforce
• Enforce integrity of domain cookies
• Defining Allowed and Enforced Cookies

ASM Cookies: What to Enforce
 ASM uses two primary types of proprietary cookies to prevent

various forms of cookie tampering, to enforce user sessions and
login pages, and to distinguish between human and non-human
clients for web scraping and proactive bot defense
1. Main SM (TS) Cookie
2. ASM Frame Cookie – Later on..
-Enforced flows (URL Navigation through application
-Extraction/protection of dynamic parameter data

Main ASM (TS) Cookie
 Validates domain cookies (set by application)

 Detects sessions expiration
 Enforce other ASM-proprietary cookie used for
-Brute force protection
-Login page enforcement
-Web scraping protection
-Cross-site Request Forgery protection
-Pro-active bot defense etc.

Enforce integrity of domain cookies
 Many web applications set cookies for user tracking, shopping

cart functionality and other reasons related to the user
experience. In many cases, a domain attribute is attached to
the set-cookie command in an HTTP response from the
application. Browsers then send the cookie back to the web
server for all requests which must comply with the defined
domain.
set-cookie:SMCHALLENGE=YES;path=/;domain=.nettechcloud.com;secure;HTTP only

Enforce integrity of domain cookies
 If the Set-cookie header is present, ASM will perform a hash on the
cookie and insert the hash value into its own TS cookie. Thus ASM
generates its own cookie in the response, specific to domain
nettechcloud.com – In addition to any possible different
domain/path combination presented in cookies set by the server
 If either the cookie set by application or the cookie inserted into
response by ASM is tampered with, a violation will be triggered.
ASM validates its own cookies by signing each one with MD5 digest
and enforcing matches between cookies using a proprietary
message key
Allowed Cookies
 The allowed attribute is used for cookies that ASM knows or
recognizes as cookies which can be modified externally. These
might be persistent cookies set by the application, single sign on
cookies, and other legitimately modified cookies. When ASM
receives a cookie which was set as “Allow” ASM will ignore it and
a violation will not be triggered.
 Allowed cookies can be of two types: Explicit and wildcard
 Explicit lets you input the cookie name exactly as it appears in the
request. Wildcard allows you to match and learn the pattern of
the expected cookie.

Enforced Cookies
 The Enforced attribute is used for cookies that ASM signs which
should not be modified on the client side.
 If a Cookie with the attribute “Enforced Cookie” is modified on
the client side, ASM will trigger the violation “Modified domain
Cookie”
 If ASM receives a cookie which wasn’t set with the Allowed or
Enforced attribute, it is an unknown cookie and therefore an
unwanted cookie, and will trigger a Modified Domain cookie
violation.

MODULE 10 : User Roles and Policy Modification
Agenda :
• Defining User Roles
• Administrative partitions
• Comparing Security policies
• Editing and Exporting Security Policies
• ASM Deployment Types

Defining User Roles
 User Roles are a means of controlling access to BIG-IP

system resources. You assign a user role to each user and
in doing so grant the user a set of permissions for
accessing BIG-IP system resources
 A user Role defines:
-The Resources a user can manage
-The Tasks a user can perform on those resources

ASM Specific user Roles
Application Security Administrator:
-Grants full access to security policies, statistics, logs
-Doesn’t have access to virtual servers and pools
-This role is available with ASM
Application Security Editor:
-Full Read/write access to security policies
-No access to attack signatures but has access to logs
Resource Administrator:
-Complete access to all objects, except access to user accounts
-Access to Security polices and logs
Administrative Partitions
 An administrative partition is a logical container for BIG-IP
system objects, such as virtual servers, pools, profiles and
monitors
 By putting objects into partitions, you can then allow or
disallow specific partition access for specific users
 Until you create other partitions on the system, all objects that
you create automatically reside in the common partition
 You can not move an object in Common partition to one of the
new partitions, instead you must delete the object from
common and recreate it in new partition
Administrative Partitions
The following configuration objects can exist in separate

partitions:
-User Accounts
-Virtual Servers
-Pools, Pool Members
-Nodes
-Custom Profiles and Monitors
-SSL keys and Certificates
-Application security policies

Comparing Security Policies
 Security Policy comparisons are done for auditing purposes, to

ensure similar functions between two polices , or to view the
differences between staging and production versions
Policy Diff Requirements:

-The two polices must be on the same BIG-IP system
-Polices must have the same language encoding
-Polices must have the same protocol configuration
-Polices must have same case sensitivity configuration

Editing and Exporting Security Policies
 You can export a security policy as a binary archive file or as a

readable XML file. This allows users to compose a security
policy in XML format and import into ASM
 You can also export existing security policies into XML format
and modify the file manually
 If you choose to export the security policy as an XML file , you
can choose between Regular and compact Format
Compact: ASM doesn’t export the staging state of attack
signatures (smaller XML File)

ASM Deployment Types
1. ASM standalone:
-is useful when load balancing is not essential
2. Multiple ASM devices behind a BIGIP-LTM
-Deploying multiple dedicated ASM devices behind LTM
delivers a higher performance level, allows to scale on demand
3. ASM In-Line with BIG-IP LTM
4. ASM module on BIG-IP LTM

MODULE 11 : Reporting and Logging
Agenda :
• Reporting
• Logging and Viewing Logs
• Logging profiles
-Default
- Custom

Reporting: Build Your own view
ASM provides two areas for reports –Overview & Reporting

Overview:
 ASM can display numerous graphical charts that illustrate the
distribution of security alerts.
 You can filter the data by security policy and time period, and
you can view illegal request based on different criteria such as
security policy, attack type, violation rating, URL,IP address,
Country, response code etc.

Reporting: Build Your own view
Reporting: Chart based on Filters

Charts display information about the requests that triggered
security policy violations. Charts can be filtered (viewed by ) using
the following criteria
• Applications
• Virtual servers
• Security policies
• Attack types
• Violations etc.

Logging
 ASM Logs all system and administrative events to syslog and

locally in /var/log/asm
File name: /var/log/asm
Archives: /var/log/asm.1.gz through /var/log/asm.8.gz
 ASM does not log security events, such as illegal file types to
syslog or locally in /var/log/asm. However for troubleshooting
purposes, there is an option to change an internal parameter
called send_content_events which enables security events in
the log.

Logging
Viewing Current Log Files via Command Line

To view the log files from the command line, use a plain text
viewer such as cat or more in conjunction with other tools. Use:
 The cat command to display the entire contents of a file
 The grep command to filter for specific entries
 The more command to display one page at a time
 The tail command to look at the end of a file
tail -f /var/log/asm

Logging profiles
 Logging profiles provide with a tool for filtering traffic through

a virtual server. When you configure a virtual server, you can
select a logging profile for that virtual server
 You can use one of the system supplied logging profiles or you
can create a custom logging profile
Creating New log profile:
Security >> Event Logs >> Logging profiles >> create

MODULE 12 : Advanced Parameter Handling
Agenda :
• Defining parameters types
• User-Input Parameters
• Defining static parameters
• Defining Dynamic Parameters
• Dynamic Parameter Extraction

Defining Parameter Types
 Parameters consist of all “name=value” pairs

 Parameters can appear in the query string and /or POST data
 Parameters can be vulnerable to tampering
User Input Parameters:

User input fields are free from data fields where the user input
data. Comment, name and phone number fields on an online
form are all examples of user-input parameters.

User-input parameters
For user-input parameters, you can configure ASM to verify

minimum and maximum values, minimum and maximum lengths
and valid meta characters
User-input Parameter value Types:

1. Alpha-numeric user-input parameter –can have letters,
integers and underscore character in it. For this data type you
can specify a maximum length.

2. Decimal User-input parameter-specifies that the parameter

value is in the decimal format. Values for this data type can
include numbers only along with decimals. For this data type you
can specify a maximum length and maximum value.
3. Email user input- specifies that the parameter value is in the
email address format. Value for this data type can include letters,
numbers, the meta character (@), the period (.) character and
the hyphen (-) character. For this data type you can specify only a
maximum length.

4. Integer user-input parameters- The integer data type specifies

that the parameter value is numeric and can include only whole
numbers. For this data type, you can specify a minimum value, a
maximum value and maximum length.
5. Phone user-input parameter – specifies that the parameter
value is in the phone number format
6.File upload data type-specifies there is no text limit for the
data . ASM can detect and block users from uploading binary
executable content in a parameter’s value

Defining static parameters
 Static parameters are those that have a known set of values.

 A list of country names, or a yes/no form field are both
examples of static parameters
 The most common input-formats are drop-down lists,
checkboxes, radio buttons, action buttons
 Static parameter values need to be defined explicitly by
adding each possible value to the parameter static values list

Defining Dynamic Parameters
 A dynamic parameter is a parameter in a request where the

set of allowed values (name/value pairs) this parameter can
have is subject to change, and usually dependent on a user
session. For example in a banking application the customer
account number could be a dynamic parameter.
 ASM can be configured to extract this unique value from web
page that is sent to the user and can subsequently verify that
the value sent in request for the parameter is legal or has not
been tampered with.

Dynamic Parameter Extraction
 The extraction defines the URL, or file type where ASM can
discover the parameter’s value in a server response. Once
ASM discovers the parameter’s value as set by the application.
ASM inserts an encoded copy into an ASM cookies which is
added to the response. If a user changes the parameter value
in a subsequent request ,ASM will generate an Illegal Dynamic
Parameter value violation, depending on the Learn, Alarm and
Block settings .

MODULE 13 : Using Application-Ready Templates
Agenda :
• Application Ready Templates
• Commonly used Templates

Application-Ready Templates
 ASM includes a set of templates for protecting many

branded applications such as Lotus Domino and MS
Exchange. These templates can greatly reduce the time
required to create a security policy because they contain
pre-populated elements that would otherwise have to be
configured manually , including application-specific file
types and parameters. The elements in each template have
been tested by F5 in collaboration with application Vendors

Commonly used Templates
1. Lotus Domino 6.5 (http/s)

2. OWA Exchange 2003,2007,2010 (http/s)
3. Oracle Applications 11i (http/s)
4. PeopleSoft Portal 9 (http/s)
5. SharePoint 2003,2007,2010 (http/s0
Etc…….

MODULE 14 : Automatic Policy Building
Agenda :
• Overview of Automatic Policy Building
• Choosing policy types
-Rapid, Fundamental and Comprehensive
• Trusted and Untrusted IP Addresses
• Learning speed
• Learning score
Overview of Automatic Policy Building
 Automatic policy building can develop a security policy based on

statistical analysis of production traffic , or safe traffic (such as
traffic generated in a quality assurance environment) over time.
 The process is referred to as “automatic” because ASM does the
work of accepting entities and attack signatures without requiring
human intervention.
 By allowing ASM to manage the policy building process
automatically the administrator can reduce chances of user errors
*Manual intervention is always permitted.

Choosing a Policy type
 Different policy types specify different sets of policy elements.

The Fundamental policy type includes the fewest number of
policy elements, and the Comprehensive type includes nearly all
policy elements.
1. 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

Rapid Deployment Policy
By default, the Rapid Deployment security policy includes the

following security checks:
• Performs HTTP compliance checks
• Checks for mandatory HTTP headers
• Stops information leakage
• Prevents illegal HTTP methods from being used in a request
• Checks response codes
• Enforces cookie RFC compliance
• Applies attack signatures

1. Rapid Deployment Policy
• Detects evasion technique

• Prevents access from disallowed geolocations
• Prevents access from disallowed users, sessions, and IP
addresses
• Checks whether request length exceeds defined buffer size
• Detects disallowed file upload content
• Checks for characters that failed to convert
• Looks for requests with modified ASM cookies

2. Fundamental
Fundamental Deployment security policy includes the following
security checks:
• Learn new File types and Lengths
• Learn New Parameters in selective mode at global level
• Checks whether request length exceeds defined buffer size
• Host names
• Learn New Redirection Domains

3. Comprehensive
Comprehensive Deployment security policy includes the

following security checks:
• Learn new File types and Lengths
• Learn new URLs + Meta characters , Classify request Contents
• Learn New Parameters + Lengths, at URL Level, Classify Value contents
• Parameter Meta characters

3. Comprehensive
• Request Length exceeds defined buffer size
• Host Names
• Learn new cookies
• Header length
• Learn New Redirection Domains
• Dynamic Parameters
• Track user Login sessions
• Brute force Login protection

Trusted and Untrusted IP Addresses
 If an IP address is designated as trusted, all requests arriving

from that IP address are considered safe, Legitimate and valid. In
many implementations, the trusted IP address comes from a
quality assurance environment or test lab network.
 Untrusted IP addresses are the opposite-those IP addresses
which are seen in real traffic.
 Building a security policy based on trusted traffic can save a
great deal of time compared to using untrusted traffic

Learning Speed
ASM will sample traffic in order to either make decisions
automatically, or to offer learning suggestions to the administrator
1. Fast: A fast speed will reduce the number of required samples in

order to make a decision. But the tradeoff is that incorrect suggestions
may be provided or incorrect elements may be added or enforced
2. Slow: Slow speed requires more samples per learning suggestion
but reduces the risk of inaccurate suggestions or other errors
3. Medium: This is the default setting and appropriate for most web
applications
Learning Score
 Each violation is assigned a percentage value which reflect

the progress of learning for each entity or item. This
percentage value is called the Learning Score.
 For each request, ASM tracks the originating IP address,
the time the HTTP session was opened, how many requests
have been made, any violation ratings that have been
assigned, and numerous proprietary rules of varying
tolerance.

MODULE 15 : Web Application Vulnerability Scanner Integration
Agenda :
• Overview
• Integrating ASM with Vulnerability Scanners
• Resolving Vulnerabilities

Overview
 Web applications scanners identify, classify and report on

potential security problems in the code of your web
application.
 According to OWASP, PHP is one of the most commonly used
server side programming languages , and millions of web
servers deploy PHP. PHP is open source. The core of PHP is
reasonably secure, but its plugins, libraries and third party
tools are often insecure.

Integrating ASM with Vulnerability Scanners
 ASM integrates with IBM AppScan , Trustwave App scanner

,Qualys,WhiteHat Sentinel,Quotium Seeker and HP WebInspect
 Generally, web application scanners comprise three main
components:
- A Crawler module
- An Attacker Module
- An Analysis Module
 The Crawler is given a list of URLs, retrieves the corresponding
pages and follows links and redirects to identify all the

Integrating ASM with Vulnerability Scanners
reachable pages in the application. In addition the crawler identifies

all the input points to the application, such as the parameters of GET
requests, the input fields of web forms and the controls for
uploading files.
 The Attacker Module analyzes the URLs discovered by the crawler
and their related inputs. Then for each vulnerabilities type that
the scanner tests for, the attacker module generates values that
reveal vulnerabilities. For example, the attacker module might
attempt to inject JavaScript when testing XSS vulnerabilities.

Resolving Vulnerabilities
ASM will present you with options for reviewing and resolving
vulnerabilities that the assessment tool has detected.
Vulnerabilities are categorized into the following types:
Resolvable(Automatically): ASM can apply actions to mitigate

the vulnerability without any administrative intervention(such
as turning on data Guard)

Resolving Vulnerabilities
Resolvable(Manually): The vulnerability can be

mitigated but some manual changes to the security
policy or to LTM objects may be required(such as
writing an iRule or creating certificate)
Not Resolvable: The vulnerability cannot be mitigated
by ASM

MODULE 16 : Layered Policies
Agenda :
• Overview of Layered Security Policies
• Parent and child security policy terminology
• Policy Section elements and settings
• Inheritance settings

Overview of Layered Security Policies
 Beginning in BIG-IP ASM 13.0.0, you can create a parent security

policy and have child security policies refer to it (layered policies)
 A parent security policy defines common Policy Section elements
and settings that provide baseline protection for your
environment and are inherited by all child policies attached to it
 You identify the elements and settings that can be modified in
child security policies and those that are mandatory and cannot
be modified.

Overview of Layered Security Policies
 For example, consider a scenario is which you discover a zero-

day exploit. Using a parent policy, you create the signatures
you need to mitigate the attack, and then add them to the
policy. Then, all the attached child security policies
automatically inherit the signature set in the parent policy, so
you don't have to manually add the new attack signatures to
multiple security policies.

Parent and child security policy terminology
A parent security policy:

 Is a virtual policy that does not process traffic and cannot be
assigned to a virtual server.
 Acts as a template for attached child security policies by sharing
the configuration of specific Policy Section elements and
settings.
A child security policy:
 Behaves as a standard security policy that can be assigned to a
virtual server.

Parent and child security policy terminology
 Inherits the Policy Section elements and settings of the parent

security policy, when attached to one.
 Generates traffic learning suggestions and request log entries,
when attached to a parent security policy.
 Can attach and detach from a parent security policy.
 Can only be modified when the parent security policy allows
updates to attached child security policies or the child policy is
detached from a parent policy's inheritance settings.

Policy Section elements and settings
Child security policies inherit the following Policy Section elements and
settings from the parent security policy to which they are attached:
• Attack signatures sets • IP addresses and geolocations

• Custom violations • Parameters
• Data Guard • Policy building process
• Evasion techniques • Server technologies
• File types • WebSocket protocol compliance
• General policy settings • HTTP protocol compliance failed
• Headers • Attack signatures
• HTTP protocol compliance • Evasion technique detected

Inheritance settings
The following Inheritance settings define how attached child
security policies inherit Policy Section elements and settings:
 None: Attached child security policies do not inherit parent
security policy elements and settings.
 Mandatory: Attached child security policies inherit parent
security policy elements and settings, which can only be
modified on the parent policy.
 Optional: Attached child security policies can accept or decline
to inherit parent security policy elements and settings.

MODULE 17 : Login Enforcement, and Session Tracking
Agenda :
• Defining a Login URL
• Defining Session Tracking
• Session Hijacking Mitigation
• Fingerprinting Overview
• Partial List of what ASM can fingerprint

Defining a Login URL
 Login pages provide a mechanism for preventing forceful
browsing to restricted parts of the web application.
 By defining a required URL (i.e. login page) the user must pass
through it in order to access a certain target URL
 The required URL has the following attributes:
- It specifies pages that can’t be accessed before the required
URL was accesses successfully.
- If the user passes through the revoke URL (i.e. logout page) , it
invalidates the required URL and the user must access the
required URL again before accessing the target object

Defining a Login URL
- Validation criterial ensure the user has successfully

authenticated and not only browsed the required URL, but
also has the correct response. To maintain information on
access to prerequisite URLs, ASM keeps information about the
prerequisites URL that was accesses successfully in the ASM
cookie. The cookie is a session cookie and includes an
expiration mechanism. If the cookie is expired, the prerequisite
URL has to be accessed again before the protected pages can
be reached by the user

Defining Session Tracking
 Session tracking can track a specific client/user via their
authenticated session.
 Tracking by an IP address can be challenging for a number of
reasons including but not limited to the common practice of NAT
 Suspicious sessions can be blocked temporarily or permanently
once specific limits are exceeded per unit of time, per users, or
per session
 Blocking is not the only option, ASM can selectively log all
requests from a session or IP address after violation thresholds
have been exceeded.
Session Hijacking Mitigation
Session hijacking occurs when an attacker is able to steal session

information from an authenticated user. Usually an application
stores the authenticated information inside a cookie. Therefore
if the attacker steals the cookie, access to the web site as an
authenticated user can be achieved. Session hijacking prevention
is now based on fingerprinting. ASM now holds incoming
requests, and returns a response that includes a JavaScript. ASM
then assigns the client a label, or Device ID based on the
information that the JavaScript collected.

Fingerprinting Overview
 Fingerprinting is a technique used by ASM to uniquely identify

different devices.
 The idea behind fingerprinting is to identify clients which are
sending traffic more accurately that by simply tracking their IP
addresses.
 Fingerprinting can track a device if it is changing its IP address
between switching between Wi-Fi and a local network
 Fingerprinting can also identify devices which are behind a
proxy and share the same source IP address

Partial List of what ASM can fingerprint
• Browser APIs: bitmap of JavaScript API support by the browser
• Results of executing various expressions by the browsers
• Capabilities of the browser
• Bitmap of fonts that are installed in the browser
• Screen Resolution and other screen parameters
• Various browser attributes such as platform, version etc.
• Time and time zone data
• Plugins installed in the browser
• ActiveX: Bitmap of ActiveX components installed in the browser
(only in IE)

MODULE 18 : Brute Force and Web scraping
Agenda :
• Defining Anomalies
• Mitigating Brute Force Attacks via Login Page
• Defining Session-Based Brute Force Protection
• Defining the Prevention Policy
• Mitigating Web Scraping
• Defining Geolocation and IP address Exceptions
Defining Anomalies
 Anomaly detection means detecting patterns in traffic that

reflect abnormal behavior, such as an increase in page load
times, server side latency, spikes in HTTP transaction rates,
an unusually high number of page requests and other
events which might indicate malicious or non-human
interaction with a web application.
 ASM groups two common web application threats under the
umbrella term anomalies.

Defining Anomalies
 One threat is the Brute Force attack, in which numerous

repeated attempts are made from one or more sources to
access data.
 The other threat is unauthorized data harvesting from a
web application by automated, external tools, sometimes
referred to as web scraping.

Mitigating Brute Force Attacks via Login Page
 Brute force attacks are attempts to break into secured areas of

a web application by trying exhaustive, systematic permutations
od code or username/password combinations to discover
legitimate authentication credentials. Malicious clients might
send high volumes of these combination to defeat security
mechanisms.
 ASM can be configured to define and then protect a login URL
the mitigation methods and the access validation criterial for
login responses.

Mitigating Brute Force Attacks via Login Page
 ASM will monitor traffic to detect excessive failures to

authenticate, monitor suspicious IP addresses and
detect other anomalies in a typical traffic pattern for the
login URL
 When ASM detects a brute force attack , it triggers the
Brute Force: Maximum login attempts are exceeded
violation, and applies the blocking settings in the security
policy.

Defining Session-Based Brute Force Protection
 Session-based protection counts the number of times a client

may attempt to log on, from the same browser with same
session, based on a session cookie, before ASM blocks the
request.
 Blocked clients can be allowed to log in again. ASM uses its own
cookie to track sessions. In ASM terms, a new session is a
request that does not contain an ASM TS Cookie, which means
that ASM cannot link the new request with a known, ongoing
client session.

Defining the Prevention Policy
The Prevention Policy specifies how ASM handles an attack.

There are four policy modes:
1. Source IP-Based Client Side Integrity Defense – determines

whether the client is a legal browser or an illegal script by sending
a JavaScript response to a suspicious IP address and then waiting
for a response. Legal browsers are able to respond , while illegal
scripts cannot.

2. URL-Based Client Side Integrity Defense – determines whether

the client is a legal browser or an illegal script by sending a
JavaScript response to a suspicious URL and then waiting for a
response. Legal URLs post expected data back to ASM , while
illegal scripts cannot.
3. Source IP-Based Rate Limiting – drops requests from the
suspicious IP address to the URL.
Rate Limiting: is based on defined thresholds. If ASM detects a number of failed
logins per second that exceeds the threshold, it will drop requests from the
offending IP

4. URL-Based Rate Limiting – limits the rate of all requests for a

URL according to the URL’s history interval, when ASM detects
that the URL is under attack.
Note: If both Client side Integrity Defense and Rate Limiting are
enabled then ASM firs attempts to use Client side Integrity
Defense.
Prevention Duration: Specifies for how long ASM performs attack

prevention against an attacker IP address or an attacked URL

Mitigating Web Scraping
 Web scraping is an automated, programmatic technique for

obtaining large amount of data from web sites.
 ASM can protect web applications from unwanted
information harvesting by employing several modes which
can work together or independently
1. Session opening Anomaly detection – Detects IP addresses
from which an abnormally high number of new sessions
are opened.

Mitigating Web Scraping
2. Bot Detection – Determines whether the web client is a

human
3. Session Transactions anomaly detection – Captures the
number of transactions per session and replies with
response Blocking page if the number of allowable
transactions is exceeded
4. Suspicious Clients – Collects browsers attributes to detect
malicious users.

Trusted Bots
Bots: Software application that runs automated tasks over the

internet. Some bots ae legitimate e.g. Googlebot used by google to
crawl the internet and index it for search
Trusted Bots :
googlebot – Google Search Engine
feoma – ASK (ask.com)
bingbot – Bing Search engine
Yahoo – Yahoo Search Engine
etc…….

Defining Geolocation Enforcement
 Geolocation enforcement allows you to configure which

countries may or may not access your web application by
mapping an IP address to its physical origin
Allowed and disallowed Geolocations
Anonymous Proxy: represents known servers that are acting as

proxies, allowing clients to mask their source IP address an
perform anonymous access to applications.

Configuring IP address Exceptions
 IP address Exceptions are frequently used by web

application developers and QA testers to run valid traffic
through ASM to help build correct policy entities and
attributes
 ASM provides a central locations for defining IP address
exceptions, or whitelists of IP addresses from which
requests are allowed.

MODULE 19 : Layer 7 DoS Mitigation and Advanced Bot Protection
Agenda :
• Defining Denial of Service Attacks
• DoS profile
• Defining Mitigation Methods
• Using Bot Signatures

Defining Denial of Service Attacks
 A denial of service attack is an attempt to make a computer

resource unavailable to its intended users
 The attacks can either be initiated from a single user (single IP
address) or from thousands of computers (distributed DoS
attack)
 ASM considers traffic to be a DoS attack based on calculations
for transaction rates on the client side (TPS-based) or latency
on the server side (Latency-based)

Defining Denial of Service Attacks
 TPS-based ratios are configurable. Latency-based ratios

are based on f5-proprietary predictive latency algorithms
and are not exposed in the configuration utility.
 Because most bot attacks are executed by automated
agents, ASM includes a proactive bot defense
technology to differentiate between legitimate clients
such as search engines and DoS or spam agents.

DoS profile
 Denial of Service attacks are handled by configuring a specific

profile for DoS, as part of the global BIG-IP security offering.
 ASM can be configured to mitigate DoS attacks based on
transactions per second (TPS).
 ASM detects DoS attacks from the client side using the following
calculation:
-Transaction rate history interval
-Transaction rate detection interval

Defining Mitigation Methods
1. Client-side Integrity Defense: Determines whether a client is a

legitimate browser or an illegal script by generating JavaScript
responses when suspicious IP addresses are requested.
Legitimate browsers can process JavaScript and respond
properly, whereas illegal scripts cannot. The default is
disabled.
2. CAPTCHA Challenge: ASM can be configured to generate and
then grade its own Completely Automated Public Turing Test
To Tell Computers and Humans Apart (CAPTCHA)

Using Bot Signatures
 Bot signature detection capability providers another

line of defense for known simple bots that can be easily
detected by their signatures.
 Bot signature classification mechanism is separate from
the ASM attack signature mechanism in that it allows
you to write your own custom signatures.
 Bot signatures are updated with the ASM signature
update

F5 BIGIP ASM Presentation

Uploaded by

Copyright:

Available Formats

F5 BIGIP ASM Presentation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

F5 BIGIP ASM Presentation

Uploaded by

Copyright:

Available Formats

Instructor

Manoj Verma | CCIE 43923

Vendors & Technologies:

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

Packet based design:

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

Full proxy Architecture:

 The system is placed in the network between the clients

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

The internal architecture of a BIG-IP system is separated

 One that is responsible for operational management

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

1. Operational management or administration

Nettech | A passion to see you at the top www.nettechcloud.com

BIG-IP Local Traffic Manager (LTM)- LTM is a local area

BIG-IP DNS (GTM) –Intelligent and Accelerated DNS resolution:

Nettech | A passion to see you at the top www.nettechcloud.com

BIG-IP Application Security manager (ASM) - Application security:

BIG-IP Advanced Firewall Manager (AFM) - Network firewall:

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

BIGIP Setup Utility

Nettech | A passion to see you at the top www.nettechcloud.com

Configuring the Management Interface

Nettech | A passion to see you at the top www.nettechcloud.com

Console Port LCD Panel and Controls

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

After licensing and provisioning, the setup utility provides

Nettech | A passion to see you at the top www.nettechcloud.com

 Network configuration wizard requires to assign self and floating IP

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com

 When a client connection arrives on the BIG-IP system, its

Nettech | A passion to see you at the top www.nettechcloud.com

 Profiles are powerful configuration tools that provide an easy

Nettech | A passion to see you at the top www.nettechcloud.com

Why an HTTP profile is required for ASM:

As a Layer 7 web application firewall, ASM must be able to

Nettech | A passion to see you at the top www.nettechcloud.com

 Local Traffic policies provide another mechanism for

Nettech | A passion to see you at the top www.nettechcloud.com

Layer 7 Local Traffic Policy

Nettech | A passion to see you at the top www.nettechcloud.com

 A default local traffic policy can be created automatically, by

Nettech | A passion to see you at the top www.nettechcloud.com

Nettech | A passion to see you at the top www.nettechcloud.com