miércoles, 8 de octubre de 2014

LTM specialist 301a - section 1

1.   Architect an Application

1.1.  Given an expected traffic volume, determine the appropriate SNAT configuration.

Example: Explain when SNAT is required
Example: Describe the benefit of using SNAT pools



Note: 
  • Standard SNAT
  • Intelligent SNAT (within an iRule)
  • SNAT pool assigned as a virtual server resource

Note: When you create local traffic objects that process network traffic on the BIG-IP system, such as virtual servers, NATs, and SNATs, the BIG-IP system creates appropriate listeners for the objects that you define. 







Inside TMM the order of operation is:

1. Existing connection in connection table


2. Packet filter rule

3. More Specific Destination Traffic Listener (VS/NAT)

Profile assignement happens here. Profiles determine how the connection is going to be processed.

Traffic is sent to other feature modules here.

When several virtual servers can process a connection; the following values determine priority in the order they are presented:
  • Destination address
  • Source address
  • Service port

4. More Specific Source Traffic Listener (SNAT/NAT)

** NAT
The BIG-IP system does not track NAT connections. Therefore, the public IP address that you define in a NAT cannot be the same address as a virtual address or SNAT address.

5. Self-IP

6. Drop



When a connection matches both a source and a destination listener object, the BIG-IP LTM system places a higher precedence on the destination listener object. However NAT can be performed for VS processed connection. (SNAT is set to none by default inside Virtual Configuration)

SOL9039: A virtual server with a SNAT pool takes precedence over matching the NAT

SOL9038 The order of precedence for local traffic object listeners


The BIG-IP system creates destination listener for Local traffic Objects (like VS). 

The BIG-IP system creates source listener for Local Traffic Objects (like SNATs)
( When a connection matches multiple source listener objects, the BIG-IP LTM system places a higher precedence on the more specific object, and a SNAT takes precedence over a NAT.)

The BIG-IP system creates a source and destination listener for NATs
(When a connection matches both a source and a destination listener object, the BIG-IP LTM system places a higher precedence on the destination listener object.)


 

Since 9.4 when the TM.ContinueMatching db variable is set to true, the BIG-IP system checks if another virtual server is available to handle a request if the higher precedence virtual server is disabled.

1.2.  Given a scenario, determine the minimum profiles for an application.

Example: Explain security options available for the application
Example: Explain how to use LTM as a service proxy
Example: Describe how a given service is deployed on an LTM

- Proxies Overview

F5 as Full Proxy. TMOS and F5′s implements so-called 'full proxy' architecture. Standard Virtual Server.

A full-proxy maintains two separate session tables – one on the client-side, one on the server-side. Can intercept, inspect, transform and direct packets bi-directionally. 
  1. TCP buffer
  2. SOL3422: Content Spooling
  3. TCP express
  4. SCTP introduction
  5. TCP request queue
F5 as Half proxy. (DSR and delayed binding)
  1. Disadvantages of dsr direct server return
  2. Npath routing
  3. SOL13403: L3 Npath routing

Objective: Configuring BIG-IP Local Traffic Manager v11: Profiles module


- SOL14163: Virtual Server Types and features

Next table shows the different Virtual Server type.

Virtual server typeDescription of virtual server type
StandardA Standard virtual server directs client traffic to a load balancing pool and is the most basic type of virtual server. It is a general purpose virtual server that does everything not expressly provided by the other type of virtual servers.
Forwarding (Layer 2)A Forwarding (Layer 2) virtual server typically shares the same IP address as a node in an associated VLAN. A Forwarding (Layer 2) virtual server is used in conjunction with a VLAN group.
Forwarding (IP)A Forwarding (IP) virtual server forwards packets directly to the destination IP address specified in the client request. A Forwarding (IP) virtual server has no pool members to load balance.
Performance (Layer 4)A Performance (Layer 4) virtual server has a FastL4 profile associated with it. A Performance (Layer 4) virtual server increases the speed at which the virtual server processes packets. 
Performance (HTTP)A Performance (HTTP) virtual server has a FastHTTP profile associated with it. The Performance (HTTP) virtual server and related profile increase the speed at which the virtual server processes HTTP requests. This is accomplished by combining features from the TCP, HTTP, and OneConnect profiles into a single profile that is optimized for network performance. The Performance HTTP virtual server processes connections on a packet-by-packet basis and buffers only enough data to parse packet headers.
StatelessA Stateless virtual server improves the performance of UDP traffic in specific scenarios.
RejectA Reject virtual server rejects any traffic destined for the virtual server IP address.
DHCP RelayA DHCP Relay virtual server relays DHCP client requests for an IP address to one or more DHCP servers, and provides DHCP server responses with an available IP address for the client. (11.1.0 and later)
InternalAn Internal virtual server enables usage of ICAP servers to modify HTTP requests and responses by creating and applying an ICAP profile and adding Request Adapt or Response Adapt profiles to the virtual server. (11.3.0 and later)


sol13675: Stateless Virtual Server
sol4362: L2 Forwarding VS
sol7595: Forwarding VS

5 main sections appear to fullfill  when creating the virtual server:

- General Properties (IP/mask,type, Soion (Source Address)
- Configuration (Protocol profiles, Service Profiles, Other Profiles, Authentication, SSL, Connection and connection rate limit, SNAT, Lasthop pool, address translation; rate class)
- Content rewrite (irules for URI rewriting, html content)
- Acceleration (HTTP compression, Webacceleration, SPDY, One Connect, Rate Class)
- Resources (pool, persistence, fallback, irule) 


Next tables show some of features that can be enabled per Virtual Server type.
  • (1) Only TCP protocol profiles are available
  • (2) Only UDP protocol profiles are available
  • (3) Only FastL4 protocol profiles are available
  • (4) Only FastHTTP protocol profiles are available
  • (5) These profiles are related and only one can be selected at a time
  • (6) TCP and SCTP profiles are available

Standard

Standard virtual serverTCPUDPSCTP
Configuration Basic / Advanced
Protocol (Client)Y(1)Y(2)Y(6)
Protocol (Server)Y(1)Y(2)Y(6)
OneConnectYNN
NTLM Conn PoolYNN
HTTPY(5)NN
HTTP CompressionYNN
Web AccelerationYNN
SPDYYNN
FTPY(5)NN
SSL (client)YYN
SSL (server)YYN
AuthenticationYYN
StreamYNN
XMLYNN
RTSPYNN
SMTPYYY
DNSYYN
DiameterYNY
Request AdaptYYY
Response AdaptYYY
RADIUSYYN
SIPYYY
StatisticsYYY
VLAN and Tunnel TrafficYYY
Rate ClassYYY
Bandwidth ControllerYYY
Traffic ClassYYY
Connection LimitYYY
Connection Rate LimitYYY
Connection Rate Limit ModeYYY
Connection MirroringYYY
Source Address TranslationYYY
Port TranslationYYY
Source PortYYY
Address TranslationYYY
Clone Pool (Client)YYY
Clone Pool (Server)YYY
Last Hop PoolYYY
Auto Last HopYYY
AnalyticsYYY
NAT64YYY
Request LoggingYYN
VS ScoreYYY
Resources
iRulesYYY
HTTP ClassYNN
Default PoolYYY
Default PersistenceYYY
Fallback PersistenceYYY

Forwarding (Layer 2)

Forwarding (Layer 2)TCPUDPAllOther
Configuration Basic / Advanced
Protocol (Client)Y(3)Y(3)Y(3)Y(3)
StatisticsYYYY
VLAN and Tunnel TrafficYYYY
Source Address TranslationYYYY
Rate ClassYYYY
Bandwidth ControllerYYYY
Traffic ClassYYYY
Connection LimitYYYY
Connection Rate LimitYYYY
Connection Rate Limit ModeYYYY
Connection MirroringYYYY
Source PortYYYY
Clone Pool (Client)YYYY
Clone Pool (Server)YYYY
Auto Last HopYYYY
Auto Last Hop PoolYYYY
AnalyticsYYYY
NAT64YYYY
VS ScoreYYYY
Resources
iRulesYYYY
Default PoolNNNN
Default Persistence ProfileNNNN
Fallback Persistence ProfileNNNN

Forwarding IP

Forwarding IP virtual serverTCPUDPAllOther
Configuration Basic / Advanced
Protocol (Client)Y(3)Y(3)Y(3)Y(3)
StatisticsYYYY
VLAN and Tunnel TrafficYYYY
Source Address TranslationYYYY
Rate ClassYYYY
Bandwidth ControllerYYYY
Traffic ClassYYYY
Connection LimitYYYY
Connection Rate LimitYYYY
Connection Rate Limit ModeYYYY
Connection MirroringYYYY
Source PortYYYY
Clone Pool (Client)YYYY
Clone Pool (Server)YYYY
Auto Last HopYYYY
Auto Last Hop PoolYYYY
AnalyticsYYYY
NAT64YYYY
VS ScoreYYYY

Performance HTTP

Performance HTTP virtual serverTCP
Configuration Basic / Advanced
Protocol (Client)Y(4)
StatisticsY
VLAN and Tunnel TrafficY
Source Address TranslationY
Rate ClassY
Bandwidth ControllerY
Traffic ClassY
Connection Rate LimitY
Connection Rate Limit ModeY
Source PortY
Clone Pool (Client)Y
Clone Pool (Server)Y
Auto Last HopY
Auto Last Hop PoolY
AnalyticsY
NAT64Y
VS ScoreY
Resources
iRulesY
Default PoolY
Default Persistence ProfileY

Performance (Layer 4)

Performance (Layer 4) virtual serverTCPUDPAllOther
Configuration Basic / Advanced
Protocol (Client)Y(3)Y(3)Y(3)Y(3)
StatisticsYYYY
VLAN and Tunnel TrafficYYYY
Source Address TranslationYYYY
Rate ClassYYYY
Bandwidth ControllerYYYY
Traffic ClassYYYY
Connection LimitYYYY
Connection Rate LimitYYYY
Connection Rate Limit ModeYYYY
Connection MirroringYYYY
Source PortYYYY
Clone Pool (Client)YYYY
Clone Pool (Server)YYYY
Auto Last HopYYYY
Auto Last Hop PoolYYYY
AnalyticsYYYY
NAT64YYYY
VS ScoreYYYY
Resources
iRulesYYYY
Default PoolYYYY
Default Persistence ProfileYYYY
Fallback Persistence ProfileYYYY

Stateless

Stateless virtual serverTCPUDPAllOther
Configuration Basic / Advanced
StatisticsNYNN
VLAN and Tunnel TrafficNYNN
Source Address TranslationNYNN
Connection LimitNYNN
Connection Rate LimitNYNN
Connection Rate Limit ModeNYNN
Port TranslationNNNN
Auto Last HopNYNN
Auto Last Hop PoolNYNN
AnalyticsNYNN
NAT64NYNN
VS ScoreNYNN
Resources
Default PoolNYNN

Reject

Reject virtual serverTCPUDPAllOther
Configuration Basic / Advanced
StatisticsYYYY
VLAN and Tunnel TrafficYYYY
Traffic ClassYYYY
Connection Rate LimitYYYY
Connection Rate Limit ModeYYYY
Source PortYYYY
Auto Last HopYYYY
AnalyticsYYYY
NAT64YYYY
VS ScoreYYYY

DHCP Relay

DHCP Relay virtual server (11.1.0 and later)TCPUDPAllOther
Configuration Basic / Advanced
StatisticsYYYY
VLAN and Tunnel TrafficYYYY
Connection Rate LimitYYYY
Connection Rate Limit ModeYYYY
VS ScoreYYYY
Resources
Default PoolYYYY

Internal

Internal virtual server (11.3.0 and later)TCP
Configuration Basic / Advanced
Protocol Profile (Client)Y
Protocol Profile (Server)Y
One ConnectY
SSL (Server)Y
ICAPY
StatisticsY
VLAN and Tunnel TrafficY
Source Address TranslationY
Resources
Default PoolY




Objective: HTTP service.


- HTTP profiles
- SOL4707: Choosing appropriate profiles for HTTP traffic

Summary:

Three profiles can be used to manage HTTP:

HTTP compression
HTTP
Web Accelaration


HTTP profiles allow us to manage:

- Chunking: sol5379: Chuncking Overview (Defaul selective)
- One Connect Transformations: When a OneConnect profile is enabled for an HTTP virtual server, and an HTTP client sends multiple requests within a single connection, the BIG-IP system is able to process each HTTP request individually. The BIG-IP system sends the HTTP requests to different destination servers as determined by the load balancing method. When the OneConnect Transformations setting is enabled in the HTTP profile, the BIG-IP system transforms Connection: close headers in HTTP/1.0 client-side requests to X-Cnection: close headers on the server side. This allows the BIG-IP system to make client requests containing the Connection: close header such as HTTP/1.0 requests, eligible for connection reuse. (Defaul enabled)
- HTTP pipelining: HTTP pipelining is a feature of HTTP 1.1 that's allows multiple requests to be sent via single connection without waiting for each response.OneConnect does not support Pipelining as each request must be initiated after the response from the previous requests have been received.  (Defaul enabled)
- X-forwarded-headed: When using connection pooling, which allows clients to make use of existing server-side connections, you can insert the XForwarded For header into a request. 
- Proxy Via header: The Via header, configured in an HTTP profile, provides information about each intermediate router that forwards a message. Intermediate routers between a client and an origin web server use the Via header to indicate intermediate protocols and recipients.
- Protocol Security: if PSM module is provisioned.


When HTTP profile is selected we can configure  HTTP Compression profiles or Web Acceleration/Cache profiles.

Next graph summarizes criteria used to select the virtual server type when processing HTTP traffic.

TCP+HTTP
FastHTTP
FastL4
Pros
IPv6 support

TCPexpress and content spooling features reduce server load

Full OneConnect functionality (including
HTTP 1.0 transformations)

Layer 7 persistence (cookie, hash, universal, and iRule)

Full HTTP iRules logic

Cache and Web Acceleration features

HTTP Compression

HTTP pipelining

Virtual Server
Authentication

Redirect Rewriting

SPDY protocol support
subset of OneConnect features to reduce the number of conns to the backend HTTP servers.





Accelerates packet processing
Cons
More CPU-intensive

Memory utilization if:

Cache / Web Acceleration

Compression

TCP offloading/content spooling (when either the client-side or the server-side of the connection is slower than the other.

Requires client source address translation

Not compatible with persistence until version 10.0.0

Limited iRules support L4 and are limited to a subset of HTTP header operations, and pool/pool member selection

No compression

No virtual server authentication

No support for HTTP pipelining

No TCP optimizations

No IPv6 support

No HTTP optimizations

No TCP optimizations for server offloading

SNAT/SNAT pools demote PVA acceleration setting level to Assisted

iRules limited to L4 events, such as CLIENT_ACCEPTED and SERVER_CONNECTED

No OneConnect

Limited persistence options.

No compression

No Virtual Server Authentication

No support for HTTP pipelining

**IPv6 TCP or UDP not accelerated


Objective: Security Options Available.


Next graph shows the F5 modules available to protect the application at different layers.



best_practices_f5_ddos_protection.pdf


Protection at tier 1 (Network Attacks): 

Advanced Firewall Module enrich the basic protection which gives LTM.

LTM protections:

SYN floods are mitigated with SYN cookiesCertain BIG-IP platforms can perform hardware/software SYN cookie protection, while other platforms perform software-only SYN cookie protection. When the SYN Check Activation Threshold value is reached  for a virtual server, the BIG-IP system responds to SYN requests by sending the SYN+ACK response back to the client that contains an encoded secret. The system then discards the SYN queue entry and waits for the ACK from the client. The SYN Check Activation Threshold indicates the number of new or untrusted TCP connections (those that have not yet completed the three-way TCP handshake) that can be initiated before the BIG-IP system activates the SYN Cookie authentication method for subsequent TCP connections. The default SYN Check Activation Threshold is 16,384 connections. A log is sent to /var/log/ltm when syn cookies is activated.

The following profile allow syn cookies:


  • TCP: Hardware SYN cookie protection is enabled by default in the TCP profile. If the platform does not support hardware SYN cookie protection, or hardware SYN cookie protection is disabled in the profile, the system uses software SYN cookie protection.
  • FastL4: Hardware SYN cookie protection is enabled by default in the FastL4 profile. If the platform does not support hardware SYN cookie protection, or hardware SYN cookie protection is disabled in the profile, the system uses software SYN cookie protection.
  • FastHTTP: Hardware SYN cookie protection is disabled in the FastHTTP profile, and the system uses software SYN cookie protection by default.

The receiving Traffic Management Microkernel (TMM) instance determines whether to enable hardware or software SYN cookie protection as follows:
  • If the platform contains the high speed bus (HSBe2) chip, and hardware SYN cookie protection is enabled in the profile, the TMM notifies the HSB chip and other TMM instances in the cluster to enable hardware SYN cookie protection. The HSB chip and receiving TMM instance will then program HSB hardware for hardware SYN cookie generation and validation for the virtual server or self IP address, and synchronize the status to all TMM instances in the cluster.
  • For TCP and FastHTTP profiles, if the platform does not contain the HSB chip or hardware SYN cookie protection is disabled in the profile, the TMM notifies other TMM instances in the cluster to enable software SYN cookie protection.
  • For FastL4 profiles, if the platform does not contain the HSB chip or hardware SYN cookie protection is disabled, SYN cookie protection is not available for the virtual server unless the software SYN cookie protection option is specifically enabled.

Against TCP 3way handshake flood and zero window attacks, there are the features deferred-accept/zero-window-timeout  enabled in TCP profile; the system defers allocation of the connection chain context until the system has received the payload from the client. This option is useful for dealing with 3-way handshake denial-of-service (DOS) attacks. T

The Maximum Segment Retransmissions setting specifies the maximum number of data segment retransmissions that the BIG-IP system allows. The default is eight retransmissions. When the system exceeds the default number of retransmissions, the Traffic Management Microkernel (TMM) resets the TCP connection to avoid resource starvation during a potential DoS attack. The Maximum Syn Retransmissions setting specifies the maximum number of times that the BIG-IP system retransmits a SYN packet when it does not receive a corresponding SYN-ACK. The default is four retransmissions.




The TM.MaxRejectRate system variable can reduce the effects of a denial of service attack by 
allowing you to limit the number of TCP RSTs or ICMP unreachable packets that the BIG-IP system 
sends in response to incoming connections that cannot be matched with virtual server connections. The default value for the TM.MaxRejectRate system variable is 250 TCP RSTs or 250 ICMP unreachable packets per second.

In the event that the BIG-IP connection table does become full, connections will be “reaped” 
according to the adaptive reaping low-water and high-water settings. These can be adjusted 
downward from the default values of 85 and 95 in order to begin mitigating a “spiky” DDoS faster, 
and thus reducing the window during which the initial attack will load the servers.

TM.RejectUnmatched BigDB variable is set to true, and the BIG-IP system sends a TCP RST packet in response to a non-SYN packet that matches a virtual server address and port or self IP address and port, but does not match an established connection


Modifying idle timeout in profiles, would alleviate connection floods; next values are the defaults:

 FastL4, FastHTTP, TCP, SCTP:  300sec
 UDP 60 sec
 OneConnect  Idle Timeout Overrides protocol profile.  
 SNAT


In addition a fair CMP-hash would improve distribution of cores load (packet-flow-in-f5 ). Since 11.5 a new DAG Round Robin prevents stateless traffic from overloading a few TMM instances, instead load balancing the traffic among TMMs evenly rather than using a static hash. Stateless traffic in this case includes non-IP Layer 2 traffic, ICMP, some UDP protocols, and others. DAG Round Robin is particularly useful for firewall and Domain Name System (DNS) traffic, and can help prevent certain types of DDoS attacks, such as an ICMP DDoS attack that can overload the system by sending the same packets repeatedly to a specific subset of TMMs.

Configuring a connection limit or a connection rate limit for a virtual server, pool member, or node prevents an excessive number of connection requests during events such as a Denial of Service (DoS) attack or a planned, high-demand traffic event. In this way, you can manage the total number of connections to a virtual server, pool member, or node, as well as the rate at which connections are made. When you specify a connection rate limit, the system controls the number of allowed new connections per second, thus providing a manageable increase in connections without compromising availability. connection rate limit can be applied per virtual object, per
source address, per destination address, or some combination thereof.


It is possible to enforce a throughput restriction on incoming traffic thru a Virtual Server. Two choices are possible to rate limitting the througput (Acceleration label), bandwidth controllers (since 11.3) and rate class. Bandwidth controller are the updated version of rate shaping on the BIG-IP system. These features are mutually exclusive. Bandwidth controllers include distributed control, subscriber fairness, and support for a maximum rate of 320 Gbps. Rate shaping is hierarchical and supports minimum bandwidth (committed information rate), priority, and flow fairness. 


Rate Class:

A rate class defines the throughput limitations and packet scheduling method that you want the BIG-IP® system to apply to all traffic that the rate class handles. You assign rate classes to virtual servers and packet filter rules, as well as through iRules®.
If the same traffic is subject to rate classes that you have assigned from more than one location, the BIG-IP system applies the last-assigned rate class only. The BIG-IP system applies rate classes in the following order:
  • The first rate class that the BIG-IP system assigns is from the last packet filter rule that matched the traffic and specified a rate class.
  • The next rate class that the BIG-IP system assigns is from the virtual server; if the virtual server specifies a rate class, the rate class overrides any rate class that the packet filter selects.
  • The last rate class assigned is from the iRule; if the iRule specifies a rate class, this rate class overrides any previously-selected rate class.

In a rate class, it is possible to define:

- base rate

- ceiling rate

- burst size

- Parent class: child rate class can borrow unused bandwidth from the ceiling of the parent class.

- Shaping policy: 

Drop: 

            - fred: Specifies that the system uses Flow-based Random Early Detection to
                 decide whether to drop packets based on the aggressiveness of each
                 flow.

            - red:  Specifies that the system uses Random Early Detection to determine
                 whether to drop packets to maintain the average queue length within
                 the specified range.

            - tail: (default) Specifies that the system drops all incoming packets when the queue
                 is full.

queue:

            - pfifo: The Priority FIFO queuing method queues all traffic under a set of
                 five sub-queues based on the Type of Service (TOS) field of the
                 traffic.  Four possible TOS values (Minimum delay, Maximum throughput, Maximum                      reliability, and Minimum cost). The fifth sub-queue represents traffic with no TOS
                 value. The Priority FIFO method processes these five sub-queues in
                 a way that preserves the meaning of the TOS value as much as possi-
                 ble. 

            - sfq: (default)  Stochastic Fair Queuing is a queuing method that further queues
                 packets under a set of many FIFO sub-queues. Selecting a specific
                 sub-queue is based on a hash of the flow address information. SFQ
                 dequeues packets from the set of sub-queues in a Round Robin fash-
                 ion. The overall effect is that fairness of dequeuing is achieved,
                 because packets from one flow cannot occupy the queues at the
                 exclusion of those of another flow.


Bandwith Controllers:

static bandwidth control policy controls the aggregate rate for a group of applications or a network path. It enforces the total amount of bandwidth available to all the connections going through this static policy.

Dynamic bandwidth control policy restrict bandwidth usage per subscriber or group of subscribers, per application, per network egress link, or any combination of these. A dynamic bandwidth control policy provides fairness on traffic flows, according to configurable parameters, within an upper bandwidth limit. The BIG-IP system activates the dynamic bandwidth control policy for each user only when the user participates. When you create a dynamic bandwidth control policy, it acts as a policy in waiting, until the system detects egress traffic that matches the traffic you want to control and creates an instance of the policy. At that moment, the system applies the bandwidth control policy limits, as specified. 



Finally, you could configure iRules that block or limit the number of requests that match a specific profile to filter out a specific connection-based DoS attack. If you can profile the requests that result from a particular DoS attack, then you can write an iRule that discards requests based on those specific criteria, such as source IP address or request pattern.




AFM protections:

The Advance Firewall Module enrich the DOS protection features available for basic LTM.

It allows the device to work as a complete Network Firewall (ADC/firewall mode) with security rules (policies|inline rules). 

Next graph shows the sequential processing of rules.




In addition we can configure an unique or general DoS/DDoS profile per Listener.


ASM protections:

ASM would protect against advanced L7 attacks.

ASM Features & Specs

- automatic policy building (staging)

- violations (learn, alarm, block)  

- Attack signatures 

- web scrapping|CSRF|Cloaking|Check request|response formats 


· Cross-site request forgery: Attack a site Trust Relationship with an user. Authenticated user launch a forgery action executed by another Web application in the Trust site. 

#When the CSRF Protection feature is enabled, F5 inserts custom JavaScript into the response pages of a protected web application The inserted JavaScript appends the CSRF token to the query string when a link is clicked. For an HTML form, the inserted JavaScript appends the CSRF token as a hidden form variable.

· Cross-site scripting: Cross-site scripting (XSS or CSS) is a Web application attack used to gain access to private information by delivering malicious code to end-users via trusted Web sites. 
XSS enables attackers to inject client-side script into Web pages viewed by other users. 
Typically, this type of attack is successful due to a Web application's lack of user input validation, allowing users to supply application code in HTML forms instead of normal text strings, for example.

· Layer 7 DDoS: Anomalies (Web Scrapping)

· SQL injection

· Parameter and HPP tampering

· Session highjacking

· Cookie manipulation

· Forceful browsing

· XML bombs/DoS

Slowloris, Slow Post, 

HashDos, GET Floods



The ASM will always inject the TS* cookie. This allows the ASM to track information about individual clients such as their IP address. When a TS* cookie becomes associated with another client from a different IP address then it will suspect a cookie hijacking has taken place.

if blocking <%TS.request.ID()%> is displayed to customer and info about violation can be seen in Security > Application Security > Reporting > Request (session tracking must be enabled)


While all the process is mostly hidden to operatior. The ASM policy application follows the next steps.


1. ASM policy
tmsh list asm policy TestVS all-properties one-line
asm policy TestVS { active app-service none blocking-mode disabled description none encoding utf-8 partition Common policy-builder disabled policy-template none virtual-servers { TestVS } }


2. LTM Policy to associate ASM policy
ltm policy asm_auto_l7_policy__TestVS { controls { asm } requires { http } rules { default { actions { 1 { asm enable policy /Common/TestVS } } ordinal 1 } } strategy first-match }



3. Apply LTM policy to Virtual Server 
ltm virtual TestVS { destination 2.2.2.2:http ip-protocol tcp mask 255.255.255.255 policies { asm_auto_l7_policy__TestVS } profiles { tcp { } html { } http { } httpcompression { } rewrite-uri-translation { } webacceleration { } websecurity { } } security-log-profiles { "Log illegal requests" } source 0.0.0.0/0 vs-index 340 }



1.03  Given an application configuration, determine which functions can be offloaded to the LTM device.
Example: Explain how to offload HTTP servers for SSL compression and caching

SOL14783: Overview of the Client SSL profile
SOL13385: ProxySSL
SOL13163: Supported SSL ciphers
Overview Forward Proxy SSL
SOL14806: Overview Server SSL profile
Application Delivery Optimization
Intelligent compression in F5
Intelligent Caching
CDN offload
WebAccelerator Overview
Webaccelerator Deployment
Application Acceleration Manager (WOM + Webaccelerator)

1.04  Given an iRule functionality, determine the profiles and configuration options necessary to implement the iRule.

Example: Explain how to create an HTTP configuration to handle an HTTP server error

- Configuring BIG-IP Local Traffic Manager v11: iRules module  (F5 University )
- Configuring BIG-IP Local Traffic Manager v11: Profiles module
- iRules.HTTP_RESPONSE
- iRules Commands

1.05  Given an application configuration, determine the appropriate profile and persistence options.


Example: Explain how to create an HTTP configuration for mobile clients
Example: Explain how to create an HTTP configuration to optimize WAN connectivity
Example: Determine when connection mirroring is required

- Configuring BIG-IP Local Traffic Manager v11: Profiles module








Cookie persistence







Cookie persistence uses an HTTP cookie stored on a client’s computer to allow the client to reconnect to the same server previously visited at a web site.









Destination address affinity persistence







Also known as sticky persistence, destination address affinity persistence supports TCP and UDP protocols, and directs session requests to the same server based solely on the destination IP address of a packet.









Hash persistence


Hash persistence allows you to create a persistence hash based on an existing iRule.









Microsoft Remote Desktop Protocol persistence







Microsoft Remote Desktop Protocol (MSRDP) persistence tracks sessions between clients and servers running the Microsoft Remote Desktop Protocol (RDP) service.









SIP persistence







SIP persistence is a type of persistence used for servers that receive Session Initiation Protocol (SIP) messages sent through UDP, SCTP, or TCP.








Source address affinity persistence


Also known as simple persistence, source address affinity persistence supports TCP and UDP protocols, and directs session requests to the same server based solely on the source IP address of a packet.








SSL persistence


SSL persistence is a type of persistence that tracks non-terminated SSL sessions, using the SSL session ID. Even when the client’s IP address changes, Local Traffic Manager still recognizes the connection as being persistent based on the session ID. Note that the term non-terminated SSL sessions refers to sessions in which Local Traffic Manager does not perform the tasks of SSL certificate authentication and encryption/re-encryption.

- Configuring BIG-IP Local Traffic Manager v11: Persistence module
- SOL4707: Choosing appropriate profiles for HTTP traffic
- SOL13478: Overview of Connection and Persistence Mirroring (11.x)
Note: Only FastL4 and SNAT connections are re-mirrored after failback.
Note: Viprions does not support intra-cluster mirroring for Layer 7 (non-FastL4) virtual servers. 
- SOL8024 - Overview of the FastHTTP profile

FastHTTP / HTTP profile comparison

The FastHTTP profile is optimized for performance under ideal traffic conditions. However, the HTTP profile is recommended when load-balancing Internet-based traffic. 
FastHTTP profileHTTP profile
Designed for limited traffic conditions
(ideal)
Designed for all traffic conditions
Packet-by-packetFull proxy
Limited features
(SNAT, Oneconnect, no mirror)
Full featured
Packet-basedStream-based
Single TCP connectionTwo separate TCP connections
Limited error-handlingRobust error-handling



- SOL7208 - Overview of the OneConnect profile
Note:The OneConnect profile may be used with any TCP protocol, but only when applied to virtual servers that process simple request/response protocols where transaction boundaries are explicitly obvious, such as those in which each request and each response is contained within a single packet.
- SOL7280 - Overview of the HTTP class profile
Note: HTTP class profiles are processed in the order in which they are applied to the virtual server, and the first matching HTTP class profile applied to the virtual server is used: An HTTP class profile located farther down the list will not be used even if it results in a more specific match.
Note: Actions: none, send to pool, send to another resource (ASM|WebAccelerator) 
Note: Beginning in BIG-IP WebAccelerator 11.0.0, web acceleration is enabled through the Web Acceleration profile.
Note: Starting in BIG-IP 11.4.0, the Local Traffic Policies feature provides a way to classify traffic based on a list of matching rules, and then to run specific actions, such as, directing all HTTP traffic to the BIG-IP ASM system for security checks based on the configured security policy, redirecting traffic received on an HTTP virtual server to an HTTPS virtual server, sending traffic to a load balancing pool based on header data, or refining the types of traffic to be collected for statistical analysis in BIG-IP Analytics, etc.
- SOL15085: LTM policies

Local traffic policy matching Requires profile settings

This table summarizes the profile settings that are required for local traffic policy matching.
REQUIRES SETTINGDESCRIPTION
httpSpecifies that the policy matching requires an HTTP profile.
sslSpecifies that the policy matching requires a Client SSL profile.
tcpSpecifies that the policy matching requires a TCP profile.

Local traffic policy matching Controls settings

This table summarizes the controls settings that are required for local traffic policy matching.
CONTROLS SETTINGDESCRIPTION
accelerationProvides controls associated with acceleration functionality.
cachingProvides controls associated with caching functionality.
classificationProvides controls associated with classification.
compressionProvides controls associated with HTTP compression.
forwardingProvides controls associated with forwarding functionality.
request-adaptationProvides controls associated with request-adaptation functionality.
response-adaptationProvides controls associated with response-adaptation functionality.
server-sslProvides controls associated with server-ssl functionality.

rules inside policy match defined conditions and start specific actions.


About conditions for local traffic policy matching

The conditions for a local traffic policy rule define the necessary criteria that must be met in order for the rule's actions to be applied. For example, a policy might include the following conditions, which, when met by a request, would allow the rule's specified actions to be applied.
CONDITIONSETTING
Operandhttp-host
Eventrequest
Selectorall
Conditionequals
Valueswww.siterequest.com


Local traffic policy matching Conditions operands

This table summarizes the operands for each condition used in policy matching.
OPERANDTYPEVALID EVENTSSELECTORS AND PARAMETERSDESCRIPTION
client-sslstring/number
  • request
  • response

  • cipher
  • cipher-bits
  • protocol
Requires a Client SSL profile for policy matching.
http-basic-authstring
  • request

  • password
  • username
Returns <username>: <password> or parts of it.
http-cookiestring
  • request

  • all
    • name
Returns the value of a particular cookie or cookie attribute.
http-headerstring
  • request
  • response

  • all
    • name (required)
Returns the value of a particular header.
http-hoststring/number
  • request

  • all
  • host
  • port
Provides all or part of the HTTP Host header.
http-methodstring
  • request

  • all
Provides the HTTP method.
http-refererstring/number
  • request

  • all
  • extension
  • host
  • path
  • path-segment
    • index (required)
  • port
  • query-parameter
    • name (required)
  • query-string
  • scheme
  • unnamed-query- parameter
    • index (required)
Provides all or part of the HTTP Referer header.
http-set-cookiestring
  • response

  • domain
    • name (required)
  • expiry
    • name (required)
  • path
    • name (required)
  • value
    • name (required)
  • version
    • name (required)
Sets the selected setting of a particular cookie or cookie attribute.
http-statusstring/number
  • response

  • all
  • code
  • text
Returns the HTTP status line or part of it.
http-uristring/number
  • request

  • all
  • extension
  • host
  • path
  • path-segment
    • index (required)
  • port
  • query-parameter
    • name (required)
  • query-string
  • scheme
  • unnamed-query- parameter
    • index (required)
Provides all or part of the request URI.
http-versionstring/number
  • request
  • response

  • response
    • all
    • major
    • minor
    • protocol
Provides HTTP/1.1 a number.
tcpnumber
  • request
  • response

  • mss
    • internal true
  • port
    • internal true
    • local true
  • route-domain
    • internal true
  • rtt
    • internal true
  • vlan
    • internal true
  • vlan-id
    • internal true
Requires a TCP profile for policy matching.

About actions for a local traffic policy rule

The actions for a local traffic policy rule determine how traffic is handled. For example, actions for a rule could include the following ways of handling traffic.

  • Blocking traffic
  • Rewriting a URL
  • Logging traffic
  • Adding a specific header
  • Redirecting traffic to a different pool member
  • Selecting a specific Web Application policy
  • Selecting an ASM policy

Local traffic policy matching Actions operands

This table summarizes the actions associated with the conditions of the rule used in policy matching.
TARGETTYPEVALID EVENTSACTION
accelerationstring/number
  • request

  • disable
  • enable
cachestring
  • request
  • response

  • disable
  • enable
    • pin true
compressstring
  • request
  • response

  • disable
  • enable
decompressstring
  • request
  • response

  • disable
  • enable
forwardstring
  • request

  • reset
  • select
    • clone-pool
    • member
    • nexthop
    • node
    • pool
    • rateclass
    • snat
    • snatpool
    • vlan
    • vlan-id
http-cookiestring
  • request

  • insert
    • name (required)
    • value (required)
  • remove
    • name (required)
http-headerstring/number
  • request
  • response

  • insert
    • name (required)
    • value (required)
  • remove
    • name (required)
  • replace
    • name (required)
    • value (required)
http-hoststring
  • request

  • replace
    • value
http-refererstring
  • request

  • insert
    • value (required)
  • remove
  • replace
    • value
http-replystring
  • request
  • response

  • redirect
    • location (required)
http-set-cookiestring/number
  • response

  • insert
    • name (required)
    • domain
    • path
    • value (required)
  • remove
    • name (required)
http-uristring/number
  • response

  • replace
    • path
    • query-string
    • value
logstring/number
  • request
  • response

  • write
    • message (required)
pemstring/number
  • request
  • response

  • classify
    • application
    • category
    • defer
    • protocol
request-adaptstring/number
  • request
  • response

  • disable
  • enable
response-adaptstring/number
  • request
  • response

  • disable
  • enable
server-sslstring/number
  • request

  • disable
  • enable
tclstring/number
  • request
  • response

  • set-variable
    • name (required)
    • expression (required)
tcp-naglestring/number
  • request

  • disable
  • enable
asm                        string
  • request

  • disable
  • enable

- SOL7392: UIE persistence