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
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.)
( 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.)
(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.
F5 as Half proxy. (DSR and delayed binding)
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 type | Description of virtual server type |
| Standard | A 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. |
| Stateless | A Stateless virtual server improves the performance of UDP traffic in specific scenarios. |
| Reject | A Reject virtual server rejects any traffic destined for the virtual server IP address. |
| DHCP Relay | A 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) |
| Internal | An 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 server | TCP | UDP | SCTP | ||
| Configuration Basic / Advanced | |||||
| Protocol (Client) | Y(1) | Y(2) | Y(6) | ||
| Protocol (Server) | Y(1) | Y(2) | Y(6) | ||
| OneConnect | Y | N | N | ||
| NTLM Conn Pool | Y | N | N | ||
| HTTP | Y(5) | N | N | ||
| HTTP Compression | Y | N | N | ||
| Web Acceleration | Y | N | N | ||
| SPDY | Y | N | N | ||
| FTP | Y(5) | N | N | ||
| SSL (client) | Y | Y | N | ||
| SSL (server) | Y | Y | N | ||
| Authentication | Y | Y | N | ||
| Stream | Y | N | N | ||
| XML | Y | N | N | ||
| RTSP | Y | N | N | ||
| SMTP | Y | Y | Y | ||
| DNS | Y | Y | N | ||
| Diameter | Y | N | Y | ||
| Request Adapt | Y | Y | Y | ||
| Response Adapt | Y | Y | Y | ||
| RADIUS | Y | Y | N | ||
| SIP | Y | Y | Y | ||
| Statistics | Y | Y | Y | ||
| VLAN and Tunnel Traffic | Y | Y | Y | ||
| Rate Class | Y | Y | Y | ||
| Bandwidth Controller | Y | Y | Y | ||
| Traffic Class | Y | Y | Y | ||
| Connection Limit | Y | Y | Y | ||
| Connection Rate Limit | Y | Y | Y | ||
| Connection Rate Limit Mode | Y | Y | Y | ||
| Connection Mirroring | Y | Y | Y | ||
| Source Address Translation | Y | Y | Y | ||
| Port Translation | Y | Y | Y | ||
| Source Port | Y | Y | Y | ||
| Address Translation | Y | Y | Y | ||
| Clone Pool (Client) | Y | Y | Y | ||
| Clone Pool (Server) | Y | Y | Y | ||
| Last Hop Pool | Y | Y | Y | ||
| Auto Last Hop | Y | Y | Y | ||
| Analytics | Y | Y | Y | ||
| NAT64 | Y | Y | Y | ||
| Request Logging | Y | Y | N | ||
| VS Score | Y | Y | Y | ||
| Resources | |||||
| iRules | Y | Y | Y | ||
| HTTP Class | Y | N | N | ||
| Default Pool | Y | Y | Y | ||
| Default Persistence | Y | Y | Y | ||
| Fallback Persistence | Y | Y | Y | ||
Forwarding (Layer 2)
| Forwarding (Layer 2) | TCP | UDP | All | Other |
| Configuration Basic / Advanced | ||||
| Protocol (Client) | Y(3) | Y(3) | Y(3) | Y(3) |
| Statistics | Y | Y | Y | Y |
| VLAN and Tunnel Traffic | Y | Y | Y | Y |
| Source Address Translation | Y | Y | Y | Y |
| Rate Class | Y | Y | Y | Y |
| Bandwidth Controller | Y | Y | Y | Y |
| Traffic Class | Y | Y | Y | Y |
| Connection Limit | Y | Y | Y | Y |
| Connection Rate Limit | Y | Y | Y | Y |
| Connection Rate Limit Mode | Y | Y | Y | Y |
| Connection Mirroring | Y | Y | Y | Y |
| Source Port | Y | Y | Y | Y |
| Clone Pool (Client) | Y | Y | Y | Y |
| Clone Pool (Server) | Y | Y | Y | Y |
| Auto Last Hop | Y | Y | Y | Y |
| Auto Last Hop Pool | Y | Y | Y | Y |
| Analytics | Y | Y | Y | Y |
| NAT64 | Y | Y | Y | Y |
| VS Score | Y | Y | Y | Y |
| Resources | ||||
| iRules | Y | Y | Y | Y |
| Default Pool | N | N | N | N |
| Default Persistence Profile | N | N | N | N |
| Fallback Persistence Profile | N | N | N | N |
Forwarding IP
| Forwarding IP virtual server | TCP | UDP | All | Other |
| Configuration Basic / Advanced | ||||
| Protocol (Client) | Y(3) | Y(3) | Y(3) | Y(3) |
| Statistics | Y | Y | Y | Y |
| VLAN and Tunnel Traffic | Y | Y | Y | Y |
| Source Address Translation | Y | Y | Y | Y |
| Rate Class | Y | Y | Y | Y |
| Bandwidth Controller | Y | Y | Y | Y |
| Traffic Class | Y | Y | Y | Y |
| Connection Limit | Y | Y | Y | Y |
| Connection Rate Limit | Y | Y | Y | Y |
| Connection Rate Limit Mode | Y | Y | Y | Y |
| Connection Mirroring | Y | Y | Y | Y |
| Source Port | Y | Y | Y | Y |
| Clone Pool (Client) | Y | Y | Y | Y |
| Clone Pool (Server) | Y | Y | Y | Y |
| Auto Last Hop | Y | Y | Y | Y |
| Auto Last Hop Pool | Y | Y | Y | Y |
| Analytics | Y | Y | Y | Y |
| NAT64 | Y | Y | Y | Y |
| VS Score | Y | Y | Y | Y |
Performance HTTP
| Performance HTTP virtual server | TCP | |||
| Configuration Basic / Advanced | ||||
| Protocol (Client) | Y(4) | |||
| Statistics | Y | |||
| VLAN and Tunnel Traffic | Y | |||
| Source Address Translation | Y | |||
| Rate Class | Y | |||
| Bandwidth Controller | Y | |||
| Traffic Class | Y | |||
| Connection Rate Limit | Y | |||
| Connection Rate Limit Mode | Y | |||
| Source Port | Y | |||
| Clone Pool (Client) | Y | |||
| Clone Pool (Server) | Y | |||
| Auto Last Hop | Y | |||
| Auto Last Hop Pool | Y | |||
| Analytics | Y | |||
| NAT64 | Y | |||
| VS Score | Y | |||
| Resources | ||||
| iRules | Y | |||
| Default Pool | Y | |||
| Default Persistence Profile | Y | |||
Performance (Layer 4)
| Performance (Layer 4) virtual server | TCP | UDP | All | Other |
| Configuration Basic / Advanced | ||||
| Protocol (Client) | Y(3) | Y(3) | Y(3) | Y(3) |
| Statistics | Y | Y | Y | Y |
| VLAN and Tunnel Traffic | Y | Y | Y | Y |
| Source Address Translation | Y | Y | Y | Y |
| Rate Class | Y | Y | Y | Y |
| Bandwidth Controller | Y | Y | Y | Y |
| Traffic Class | Y | Y | Y | Y |
| Connection Limit | Y | Y | Y | Y |
| Connection Rate Limit | Y | Y | Y | Y |
| Connection Rate Limit Mode | Y | Y | Y | Y |
| Connection Mirroring | Y | Y | Y | Y |
| Source Port | Y | Y | Y | Y |
| Clone Pool (Client) | Y | Y | Y | Y |
| Clone Pool (Server) | Y | Y | Y | Y |
| Auto Last Hop | Y | Y | Y | Y |
| Auto Last Hop Pool | Y | Y | Y | Y |
| Analytics | Y | Y | Y | Y |
| NAT64 | Y | Y | Y | Y |
| VS Score | Y | Y | Y | Y |
| Resources | ||||
| iRules | Y | Y | Y | Y |
| Default Pool | Y | Y | Y | Y |
| Default Persistence Profile | Y | Y | Y | Y |
| Fallback Persistence Profile | Y | Y | Y | Y |
Stateless
| Stateless virtual server | TCP | UDP | All | Other |
| Configuration Basic / Advanced | ||||
| Statistics | N | Y | N | N |
| VLAN and Tunnel Traffic | N | Y | N | N |
| Source Address Translation | N | Y | N | N |
| Connection Limit | N | Y | N | N |
| Connection Rate Limit | N | Y | N | N |
| Connection Rate Limit Mode | N | Y | N | N |
| Port Translation | N | N | N | N |
| Auto Last Hop | N | Y | N | N |
| Auto Last Hop Pool | N | Y | N | N |
| Analytics | N | Y | N | N |
| NAT64 | N | Y | N | N |
| VS Score | N | Y | N | N |
| Resources | ||||
| Default Pool | N | Y | N | N |
Reject
| Reject virtual server | TCP | UDP | All | Other |
| Configuration Basic / Advanced | ||||
| Statistics | Y | Y | Y | Y |
| VLAN and Tunnel Traffic | Y | Y | Y | Y |
| Traffic Class | Y | Y | Y | Y |
| Connection Rate Limit | Y | Y | Y | Y |
| Connection Rate Limit Mode | Y | Y | Y | Y |
| Source Port | Y | Y | Y | Y |
| Auto Last Hop | Y | Y | Y | Y |
| Analytics | Y | Y | Y | Y |
| NAT64 | Y | Y | Y | Y |
| VS Score | Y | Y | Y | Y |
DHCP Relay
| DHCP Relay virtual server (11.1.0 and later) | TCP | UDP | All | Other |
| Configuration Basic / Advanced | ||||
| Statistics | Y | Y | Y | Y |
| VLAN and Tunnel Traffic | Y | Y | Y | Y |
| Connection Rate Limit | Y | Y | Y | Y |
| Connection Rate Limit Mode | Y | Y | Y | Y |
| VS Score | Y | Y | Y | Y |
| Resources | ||||
| Default Pool | Y | Y | Y | Y |
Internal
| Internal virtual server (11.3.0 and later) | TCP | |||
| Configuration Basic / Advanced | ||||
| Protocol Profile (Client) | Y | |||
| Protocol Profile (Server) | Y | |||
| One Connect | Y | |||
| SSL (Server) | Y | |||
| ICAP | Y | |||
| Statistics | Y | |||
| VLAN and Tunnel Traffic | Y | |||
| Source Address Translation | Y | |||
| Resources | ||||
| Default Pool | Y | |||
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 cookies. Certain 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.
- 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:
A 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 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.
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 allows you to create a persistence hash based on an existing iRule.
Microsoft Remote Desktop Protocol (MSRDP) persistence tracks sessions between clients and servers running the Microsoft Remote Desktop Protocol (RDP) service.
SIP persistence is a type of persistence used for servers that receive Session Initiation Protocol (SIP) messages sent through UDP, SCTP, or TCP.
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 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.
|
- 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 SETTING | DESCRIPTION |
|---|---|
| http | Specifies that the policy matching requires an HTTP profile. |
| ssl | Specifies that the policy matching requires a Client SSL profile. |
| tcp | Specifies 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 SETTING | DESCRIPTION |
|---|---|
| acceleration | Provides controls associated with acceleration functionality. |
| caching | Provides controls associated with caching functionality. |
| classification | Provides controls associated with classification. |
| compression | Provides controls associated with HTTP compression. |
| forwarding | Provides controls associated with forwarding functionality. |
| request-adaptation | Provides controls associated with request-adaptation functionality. |
| response-adaptation | Provides controls associated with response-adaptation functionality. |
| server-ssl | Provides 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.
| CONDITION | SETTING |
|---|---|
| Operand | http-host |
| Event | request |
| Selector | all |
| Condition | equals |
| Values | www.siterequest.com |
Local traffic policy matching Conditions operands
This table summarizes the operands for each condition used in 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.
| asm | string |
|
|
- SOL7392: UIE persistence
