401 Study Notes
Get a good hold on Silver line. Deployment mode, etc. When to use which mode, pros and cons etc.
DDoS concepts are tested extensively, w.r.t AFM, ASM and device DDoS
Understanding Kerberos and NTLM authentication and related security flaws while understanding how APM can help
SAML use cases
Read customer success stories on f5.com - https://www.f5.com/customer-stories
Read all reference architecture guides on F5 - https://www.f5.com/services/resources/deployment-guides
Finally be prepared to reading lengthy problem descriptions
For Threat modeling, I study the STRIDE/DREAD model of Microsoft. Also the Owasp docs on the same subjects
For design, I study the roles on each components and security features, customer stories on F5 website, light board..
For operation, diagnosis notes on askf5 and lot of labs
For incident response, study all reference guide (DDOS...) and be able to determine the right solution for a case.
And practice always, read what you can to be sure to understand well the solutions (Maybe too much...)
websafe, Silverline, WAF and knowing when to use it
Exam 401–Security Solutions Summary
Successful completion of this exam acknowledges the skills and understanding to discover business requirements regarding security and articulate technical requirements driven by the business. Candidates can also apply F5 solutions to meet technical requirements for a security solution and articulate the value of the solution. This exam is based on version 13.1.
Summary description of the MQC
The MQC has experience designing, maintaining, and troubleshooting using F5 technology to solve security problems. The MQC can define security requirements based on technical and business needs, apply and modify security architectures utilizing F5 technology, and articulate the value of the solution. The MQC will also have experience in identifying, analyzing, and mitigating security incidents leveraging F5 technology as appropriate.
The MQC can do the following without assistance:
Identify security threats and interpret their potential business impact
Design solutions to mitigate security threats
Analyze anomalous data to recognize security incidents
Perform multi-module troubleshooting, possibly leveraging third-party tools
Architect technical solutions to meet given business requirements
BIG-IP Traffic Processing Order
The packet is first evaluated by the Packet Filter The next is FLOW_INIT, then by AFM, then by LTM , then by APM. And at last ASM processes the traffic, then hands the traffic back to LTM to finish up with. ASM sits off to the side and either tells LTM to proceed or hands out a block page.
ePVA embedded Packet Velocity Acceleration chip.
*L2-L4 Dos vectors / IP intelligence / HW Acceleration ---> L2 / Stateless packet filter/ Flow lookups ---> L3
Packet Filter IP intelligence --> L2-L4 Dos vectors --> Listener / Lookup -->
Flow_INIT (This event is triggered (once for TCP and unique UDP/IP flows) after packet filters, but before any AFM and TMM work occurs.)
AFM (Global (IPI - Network Firewall) / Route Domains (IPI - Network Firewall) / VIP (IPI - Network Firewall) )
Local Logging Directories
Type Description Log file
audit: The audit event messages are messages that the BIG- /var/log/audit IP system logs as a result of changes to the BIG-IP system configuration. Logging audit events is optional. (shows successful logins and actions taken once logged in)
boot: The boot messages contain information that is logged /var/log/boot.log when the system boots.
cron: When the cron daemon starts a cron job, the daemon /var/log/cron logs the information about the cron job in this file.
daemon: The daemon messages are logged by various daemons /var/log/daemon.log that run on the system.
dmesg: The dmesg messages contain kernel ring buffer /var/log/dmesg information that pertains to the hardware devices that the kernel detects during the boot process.
GSLB: The GSLB messages pertain to global traffic /var/log/gtm management events.
httpd: The httpd messages contain the Apache Web server /var/log/httpd/httpd_errors error log.
kernel: The kernel messages are logged by the Linux kernel. /var/log/kern.log
local traffic: The local traffic messages pertain specifically to the /var/log/ltm BIG-IP local traffic management events.
mail: The mail messages contain the log information from the /var/log/maillog mail server that is running on the system.
packet filter: The packet filter messages are those that result from /var/log/pktfilter the use of packet filters and packet-filter rules.
*pktfilter - message from the packet filter or APM ACLs
(example Aug 3 15:13:58 ltm2 notice tmm1: 01580005:5: /Common/APM-HTTP-TEST:Common:95fd323f: discard ACL: /Common/block-lab-SSH:0 packet: http://zoltan.home/login. html tcp 192.168.50.20:7321 -> 192.168.100.125:8385)
security: The secure log messages contain information related to /var/log/secure authentication and authorisation privileges.
* (shows logins and can alert for remote logins/failed logs in (i.e. Brute Force))
system: The system event messages are based on global Linux /var/log/messages events, and are not specific to BIG-IP local traffic management events.
TMM: The TMM log messages are those that pertain to Traffic /var/log/tmm Management Microkernel events.
user: The user log messages contain information about all /var/log/user.log user level logs.
webui: The webui log messages display errors and exception /var/log/webui.log details that pertain to the Configuration utility.
Example of a failed NTP peer server query
# ntpq -np
remote refid st t when poll reach delay offset jitter
172.28.4.133 .INIT. 16 u - 64 0 0.000 0.000 0000.00
Note: An st (stratum) of 16 means that the destination NTP server is unreachable or is not considered a viable candidate.
Example of a successful NTP preferred peer server query
If the local ntpd process communicates or attempts to communicate with a declared preferred NTP peer server, the output from the ntpq command appears similar to the following example:
# ntpq -np
remote refid st t when poll reach delay offset jitter
*172.28.4.133 10.10.10.251 4 u 482 1024 377 0.815 -10.010 0.345
+172.28.4.134 10.10.10.252 6 u 482 1024 179 0.215 -1.010 0.545
In the previous example, 172.28.4.133 is the preferred server, or current time source, and is designated by the * symbol. Any remaining servers available for use are indicated by the + symbol. When initially configured, NTPd can take up to a few minutes to calculate and designate the current preferred time source.
Note: Pay attention to the first character for remote. A successful query that has a space as the first character is not used to synchronize time on the device. Although the response may appear successful, the space indicates that it is not acceptable for use.
NTP output details
prefix to the remote field
An asterisk (*) character indicates that the peer is declared the system peer and lends its variables to the system variables.
A plus sign (+) indicates that the peer is a survivor and a candidate for the combining algorithm.
A space, x, period (.), dash (-), or hash (#) character indicates that this peer is not being used for synchronization because it either does not meet the requirements, is unreachable, or is not needed.
remote The address of the remote peer.
The reference ID identifying the server or reference clock with which the remote peer synchronizes. The interpretation depends on the value of the stratum field (explained in the st definition). For stratum 0 (unspecified or invalid), the refid is an ASCII value used for debugging. Example: INIT or STEP. For stratum 1 (reference clock), the refid is an ASCII value used to specify the type of external clock source. Example: NIST refers to NIST telephone modem. For strata 2 through 15, the refid is the address of the next lower stratum server used for synchronization.
The stratum of the remote peer. Primary servers (servers with an external reference clock such as GPS) are assigned stratum 1. A secondary NTP server which synchronizes with a stratum 1 server is assigned stratum 2. A secondary NTP server which synchronizes with a stratum 2 server is assigned stratum 3. Stratum 16, referred to as MAXSTRAT, is customarily mapped to stratum value 0 and therefore indicates that it is unsynchronized. Strata 17 through 255 are reserved.
The type of peer: local, unicast, multicast, or broadcast.
The time since the last response to a poll was received (in seconds).
The polling interval (in seconds). This value starts low (example: 64) and, over time, if no changes are detected, this polling value increases incrementally to the configured max polling value (example: 1024).
The reachability register. The octal shift register records results of the last eight poll attempts.
The current estimated delay, which is the transit time between these peers in milliseconds.
The current estimated offset, which is the time difference between these peers in milliseconds.
The current estimated dispersion, which is the variation in delay between these peers in milliseconds.
Service options are Always On or Always Available
Always Available is a On-Demand Mode and is most commonly used with proxy mode, where F5 can re-route traffic through the Silverline service when the customer has come under attack
Always On, speaks for itself, always goes through Silverline
Proxy Mode -
This is setup by using a new IP via the F5 Silverline cloud. Basically proxed in the cloud via F5 BigIP (AFM/ASM)in the cloud, only allow your data centre to accept traffic from Silverline IPs.
Routed mode - (client must have a /24 to use this mode!)
BGP advertises IPs from the F5 silver cloud for the customer services and then GRE tunnels backend to the customer data centre. Return traffic goes directly back to the client and NOT through Silverline
Layer 3/4 DDos
Attacks best mitigated by Silverline - Volumetric floods, Amplification and protocol whitelisting (options are Any, TCP, UDP, ICMP, or IGMP.)
Layer 7 DDoS
Silverline DDoS Protection safeguards against a wide variety of attacks, including those
DDoS attack protection
Protocol anomaly detection
L3–L4 DDoS protection
SYN flood, TCP flood, ICMP flood, UDP flood,known signature attacks, Teardrop, Smurf, Ping of Death, Mixed Flood, Reflected ICMP
L7 DDoS protection
NTP, HTTP Flood, Slowloris
DNS traffic protection
DNS flood, DNS reflection attacks, DNS, amplification attacks
Protected Internet services
Internet services All, including: HTTP/HTTPS/SFTP/SNMP//SMTP/POP-3/CHARGEN/MIME/DNS/IMAP
Silverline and ASM can ensure PCI (Payment Card Industry)/DSS (Data Security Standard) compliance.
https://www.youtube.com/watch?v=zL39yiaBS2Y - F5 Silverline Proxy and Routed Modes
DDoS Reference Architecture use cases
Large financial service institution (FSI) Data Center (2 teir)
Cloud Scrubbing (Silverline) Always Available Subscription
On Prem AFM / LTM / IPI **VIPRION Chassis (Pair) and GTM **Mid-Range BIG-IP Appliance (Pair)
On Prem LTM / ASM **Mid-Range BIG-IP Appliance
*Network HSM at both on prem tiers
Enterprise Data Centre (2 teir)
Cloud Scrubbing (Silverline) Ready Defense Subscription
On prem AFM / LTM / GTM / IPI **VIPRION Chassis (Pair) or High-End BIG-IP Appliance (Pair)
*** CUSTOMER NEXT-GEN FIREWALL*** user leverage outbound connection
On Prem LTM / ASM **Mid-Range BIG-IP Appliance
SMB data centre (1 Teir)
Cloud Scrubbing (Silverline) Ready Defense Subscription
On prem AFM / LTM / GTM / ASM / IPI **Mid- to High-End BIG-IP Appliance Pair
*** CUSTOMER NEXT-GEN FIREWALL*** user leverage outbound connection
The Four Categories of DDoS
Volumetric—Flood-based attacks that can be at layer 3/4 or 7.
Attacks that consume all available bandwidth across the network link that connects an application to the Internet or other networks.
Mitigation - Cloud-Based Scrubbing Service / Web Application Firewall.
2. Asymmetric—Attacks designed to invoke timeouts or session-state changes. Layer 7
Attacks that mimic legitimate application requests but attempt to overload web server resources such as CPU or memory.
Mitigation - Web Application Firewall
3. Computational—Attacks designed to consume CPU and memory. Layer 3/4
Attacks that attempt to exhaust infrastructure resources, such as firewall state tables, leading to crashing or degraded performance.
Mitigation - Application Delivery Controller (LTM) / Network Firewall (AFM)
4. Vulnerability-based—Attacks that exploit software vulnerabilities / weaknesses. Layer 3/4, 7
Mitigation - IP Reputation Database (IPI)/ Intrusion Prevention/Detection Systems (IDS/IPS) (ASM)/ Application Delivery Controller (LTM)
Application Services DDoS Attacks
HTTP Flood (Layer7)
In an HTTP flood, the attacker exploits seemingly legitimate HTTP GET or POST requests to attack a web server or application. These attacks typically consume less bandwidth than others but focus on triggering complex server-side processing to bring down the targeted site or app. HTTP floods can sometimes trigger responses from web servers that can turn it into a pipe-saturating volumetric attack.
Heavy URL (Layer7)
During the reconnaissance phase, an attacker will map out the most computationally expensive URLs on a site or application, also known as heavy URLs. Heavy URLs include any URL causing greater server load upon request. The initial HTTP request is relatively small but can take a long time to complete or yield large response sizes. These requests can require the server to load multiple large files or run resource-intensive database queries.
Slowloris works by opening multiple connections to a web server and sending HTTP requests, none of which are ever completed. Periodically, the attacker sends subsequent HTTP headers for each request, but never actually completes the request. Ultimately, the target server’s maximum concurrent connection pool is filled and legitimate connections are denied.
Slow Post (Layer7)
An attacker begins by sending a legitimate HTTP POST request to a web server, in which the header specifies the exact size of the message body that will follow. However, that message body is then sent at an extremely slow rate. Because the message is technically correct and complete, the targeted server attempts to follow all specified rules. If an attacker establishes enough of these POST attacks simultaneously, they consume server resources to the extent legitimate requests are denied.
Access DDoS Attacks
Brute-Force Login Attack (Layer7)
An attacker tries multiple username and password combinations, often using a dictionary of words or commonly used passwords to gain unauthorized access to an application or website. A common mitigation is to temporarily lock out user accounts with multiple failed login attempts. However, this can result in a denial of service for those affected accounts.
TLS DDoS Attacks (LTM ADC)
SSL Renegotiation (Layer 7)
This attack takes advantage of an asymmetric workload by requesting a secure connection, and then continuously renegotiating it. This requires a lot of CPU power from the server and can slow current or new connections or even take down the server.
SSL Flood (Layer 7)
Attackers send numerous TLS/SSL connection requests with the client never closing the connection. Once the concurrent connection limit is reached, the TLS termination point stops processing traffic, including legitimate requests.
SSL Squeeze (Layer 7)
A variant of an SSL renegotiation attack, the squeeze attack continuously attempts to renegotiate the connection handshake, forcing the server to decrypt “junk” requests. Typical renegotiation attacks multiplex SSL handshakes, which can be mitigated by disabling renegotiation on the server. However, SSL squeeze opens new TCP connections for each request, eventually consuming I/O.
Common Application Attacks
Mitigation BIG IP LTM + iRule OR BIG-IP ASM
Slowloris (Nuclear DDoSer, Slowhttptest)
Slow POST (R-U-Dead-Yet, Tor Hammer, Nuclear DDoSer, Slowhttptest)
Apache Killer (Slowhttptest)
HTTP GET Flood, Recursive GET Flood (Web Scraping)Dirt Jumper (HTTP Flood)
Mitigation BIG-IP ASM
exploits SQLi / OWASP Top 10 vulnerability as entry
XML Bomb (DTD Attack), XML External Entity DoS
DNS DDoS Attacks
DNS servers rely on the UDP protocol for name resolution, which (unlike TCP queries) is connection-less. Because confirmation that UDP packets have been received isn’t required, spoofing is easily accomplished. This scripted botnet attack attempts to overwhelm server resources, ultimately affecting the DNS servers’ ability to direct legitimate requests. The attack can consist of valid UDP traffic from multiple sources or randomized packet data. This helps this attack type evade basic DDoS protection techniques like IP filtering.
A variant of the DNS flood, an attacker floods the DNS server with requests for invalid or nonexistent records. Then, the DNS server spends its resources looking for something that doesn't exist instead of serving legitimate requests. The result is that the cache on the DNS server gets filled with bad requests and clients can't find the servers they’re looking for.
DNS amplification is a type of reflection attack that manipulates vulnerable internet facing DNS servers, causing them to flood an internet resource with an influx of large UDP packets. An attacker-controlled botnet is scripted to send small, but specially formed, DNS queries to any publicly available DNS resolver. This elicits a disproportionate response from the DNS resolver. The packet headers also include a spoofed IP address, the IP address of the DDoS target. Upon receiving the query, the open DNS resolvers provide an extremely large response to the target of the attack, which eventually consumes the bandwidth of the internet resource.
Network DDoS Attacks
Every client-server conversation begins with a standard three-way handshake. The client sends a SYN packet, the server responds with a SYN-ACK, and the TCP connection is established with a final client ACK. In a SYN flood attack the client sends massive numbers of SYN requests, and never responds to the SYN-ACK messages from the server. This leaves the server with open connections waiting for responses from the client. Each of these half-open connections is tracked in the TCP connection table, eventually filling the table and blocking additional connection attempts, legitimate or otherwise.
UDP is a standard communication protocol across IP networks. Because UDP packets are stateless, they require less error checking and validation in contrast to TCP. A UDP flood attack attempts to overload a server with requests by saturating the connection tables on every accessible server port. Filling the connection table with these requests prevents legitimate requests from being processed.
*Memcache issue is that it dos not have any way of authenticating
An amplification attack is a type of reflection attack that takes advantage of the ability to send small spoofed packets to services that, as part of their normal operation, will reply back to the target with a much larger response.
Memcached is a database caching system for speeding up websites and networks. Attackers can spoof requests to a vulnerable internet-facing memcached server, which then floods a target with traffic, potentially overwhelming their resources. While the target’s infrastructure is overloaded, new requests can’t be processed and regular traffic can’t access the Internet resource, resulting in denial-of-service.
Other types of amplification attacks include NTP, SSDP, SNMPv2, CharGEN, QOTD, and more.
IP fragmentation is a process established by design of the IP protocol that breaks packets or datagrams into smaller fragments, so they can pass through network links that have a smaller maximum transmission unit (MTU) limit. The host or stateful security devices receiving the fragments reassembles them into the original datagram. The packets’ or datagrams’ IP header tells the receiver how to reassemble the datagram.
These attacks come in various forms, but all variations attempt to use fragmentation to overwhelm the target server or network node.
#note # Amplification Example - request 100mb , response maybe 10 times that!!!
syn, syn, syn ,syn attack (mitigate computational attacks such as SYN floods with On-Premises Network Defence)
get index.asp multiple times attack (Mitigating GET floods / Asymmetric DDoS with ASM On-Premises Application Defence.
Mitigations strategies for GET floods include:
The login-wall defense
DDoS protection profiles
Real browser enforcement
iRules Custom iRules
Application Delivery Controllers (ADCs) provide strategic points of control in the network. When chosen, provisioned, and controlled properly, they can significantly strengthen a DDoS defense. For example, the full-proxy nature of the F5 ADC reduces computational and vulnerability-based threats by validating common protocols such as HTTP and DNS. For these reasons, F5 recommends a full-proxy ADC.
Big-IP TCP / SSL sizing
Platform Series TCP Connection Table Size SSL Connection Table Size
VIPRION Chassis 12–144 million 1–32 million
High-End Appliances 24–36 million 2.5–7 million
Mid-Range Appliances 24 million 4 million
Low-Range Appliances 6 million 0.7–2.4 million
Virtual Edition 3 million 0.7 million
SMALL-TO-MEDIUM ENTERPRISES BIG-IP i2000 / i4000 series
MID-TO-LARGE ENTERPRISES BIG-IP i5000 / i7000 / i10000 series
LARGE ENTERPRISES AND SERVICE PROVIDERS BIG-IP i11000 / i15000 series
DNS / GTM
Static load balancing methods
Drop packet - GTM drops packet
Fallback IP - GTM returns the IP
Global Availability - Sent to first available pool
None - skip that method
Ratio - Round Robin in pool based on the configured ratio
Return to DNS - Send to BIND
Static Persist - Mask-base persistence
Dynamic load balancing methods
Completion Rate - VS with lowest failures
CPU - VS with lowest CPU usage
Hops - VS with lowest hops from client
Kbs - VS with lowest Kbs in responses
Least Connections - VS with least connections
Packet Rate - VS with least packet rate
Quality of Service - lowest performance metrics
Round Trip Time - from VS to client
Virtual Server Score - VS based on configured ranking
Virtual Server Capacity - Sent to pool with most free VS in it
Chain of trust ............
requesting a DNSSEC singed DNS domain with the DO-Flag set (DNSSEC OK) should return an answer including the AD-Flag (Authenticated answer) set in the header
flags: qr rd ra ad; (Authenticated answer)
QR: 0=Query, 1=response
AA: Authoritative Answer (set by the server)
TC: message is TrunCated (set by the server)
RD: Recursion Desired (set by the client and copied to the response)
RA: Recursion Available (set by the server)
AD: Authenticated Data, DNSSEC flag (set by the server)
CD: Checking Disabled, DNSSEC flag (set by the client, copied to the response)
RCODE, 4-bits: 0000=NOERROR.
trying to resolve a domain that has DNSSEC issues should only return a SERVFAIL returncode without any DNS data
non-DNSSEC domains are resolved normally
DXDOMAIN - Domain doesn't exist
Access Policy Manager® (APM®) provides an alternative to a form-based login authentication method. This alternative method uses a browser login box that is triggered by an HTTP 401 response to collect credentials. A SPNEGO/Kerberos or basic authentication challenge can generate a HTTP 401 response.
This option is useful when a user is already logged in to the local domain and you want to avoid submitting an APM HTTP form for collecting user credentials. The browser automatically submits credentials to the server and bypasses the login box to collect the credentials again.
Note: Because SPNEGO/Kerberos is a request-based authentication feature, the authentication process is different from other authentication methods, which run at session creation time. SPNEGO/Kerberos authentication can occur at any time during the session.
KDC - Key Distribution Centre (AD server)
Authentication service (AS)
Ticket Granting Service (TGS)
SPN = Service principle name
Kerberos Delegation and Protocol Transition (*Server Side)
*Kerberos only requires that you have a username and a domain
*APM credentials (session.logon.last) Username and Password
When troubleshooting, you need to have an understanding of the following sequence of events in the Kerberos end-user logon authentication process.
The client connects to the BIG-IP virtual server and receives an HTTP 401 or HTTP 407 authentication response from the BIG-IP APM system.
In an AS_REQ/AS_REP request, the client obtains the Kerberos ticket-granting ticket (TGT) from the KDC.
In a TGS_REQ/TGS_REP request, the client presents the TGT to the KDC and obtains the Kerberos service ticket to the appropriate service in response.
The client responds to the earlier response from the BIG-IP APM in step 1 by presenting the Kerberos service ticket in an AP_REQ request to the BIG-IP APM system.
The BIG-IP APM system authenticates the client service ticket using the keytab file.
When Kerberos authentication is successful, the BIG-IP APM system sends an AP_REP reply and the client is able to access the service.
To retrieve user credentials for end-user logon, you can use basic authentication or SPEGNO/Kerberos methods or both.
Use this method to retrieve user credentials (user name and password) from a browser. You can think of this method as a replacement for form-based authentication used by the standard login screen. If you use basic authentication, the system populates the user name and password session variables, which can then be used by any other authentication actions, such as Active Directory or RADIUS.
Use this method to retrieve user credentials through SPNEGO/Kerberos authentication header. With the Kerberos method, the client system must first join a domain and a Kerberos action must follow. The Kerberos action does not run immediately; it runs only when clients request SPNEGO/Kerberos authentication. By default, Kerberos authentication runs not only on the first request, but also on subsequent requests where authentication is needed, such as for new connections. Access Policy Manager® ( APM®) validates the request by confirming that a valid ticket is present.
A keytab is a file containing pairs of Kerberos principals and encrypted keys (which are derived from the Kerberos password). You can use a keytab file to authenticate to various remote systems using Kerberos without entering a password
APM Access Policies
Network Access - A SSL VPN tunnel from client (with client software) to BIG-IP. This consumes a CAL.
Portal Access - provides access to web services. Clientless VPN but requires ? components ?. This consumes a CAL.
Web Application Access -APM+LTM where APM just does identity and access management. Doesn't require client software and doesn't consume a CAL.
Secure - If you are configuring an application access control scenario where you are using an HTTPS virtual server to authenticate the user, and then sending the user to an existing HTTP virtual server to use applications, clear this check box.
HTTP only - This flag is for use only with an LTM-APM access profile type. Use the HttpOnly flag when generating a cookie to help mitigate the risk of a client-side script accessing the protected cookie, if the browser supports HttpOnly.
ERROR: query with ‘(sAMAccountName=student)’ failed in ldap_sasl_interactive_bind_s(): Local error, SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot find KDC for requested realm) (-2)
Test done: total tests: 1, success=0, failure=1
The cause of this is typically failed DNS resolution
By default, MRHSession and LastMRH_Session are inserted by APM with the Secure flag, meaning no connection on HTTP will be allowed.
Logging - ECA Specifies the log level for events related to NTLM authentication for Microsoft Exchange clients
Using VCMP allows the flexability on seperations that virtuals provide but also allows utilisation of the hardware for things like TLS acceleration
SSL Orchestrator (SSLO)
Dynamic service chaining ! through classification.
IP Intelligence IPI
IP Intelligence identifies IP addresses, compares them to the global IP Intelligence database, and allows or blocks connections based on current known risks. IPI can be used along with LTM, AFM and ASM and updates the IPI database every 5 mins.
Ensure IP threat protection
Deliver contextual awareness and analysis to block threats from a dynamic set of high-risk IP addresses.
Improve visibility into threats frommultiple sources
Detect malicious activity and IP addresseswith help from a global threat-sensor network and IP intelligence database.
Enable granular threat reporting and automated blocking
Reveal communication with malicious IP addresses to create more effective security policies.
Optimize protection with real-time updates
Automatically refresh the threat database as often as every five minutes
The IP Intelligence service identifies and blocks IP addresses associated with a variety of threat sources, including:
Windows exploits: Includes active IP addresses offering or distributing malware, shell code, rootkits, worms, or viruses. Web attacks: Includes cross-site scripting, iFrame injection, SQL injection, cross domain injection, or domain password brute force.
Botnets: Includes botnet command and control channels and infected zombie machines controlled by the bot master.
Scanners: Includes all reconnaissance, such as probes, host scan, domain scan, and password brute force.
Denial of service: Includes DoS, DDoS, anomalous SYN flood, and anomalous traffic detection.
Reputation: When enabled, denies access to IP addresses currently known to be infected with malware or to contact malware distribution points.
Phishing: Includes IP addresses hosting phishing sites or other kinds of fraud activities, such as click fraud or gaming fraud.
Proxy: Includes IP addresses providing proxy and anonymization services, as well as The Onion Router (TOR) anonymizer addresses.
IPI blocks four main attacks at the edge - Phishing, Anonymous Attackers, Botnet and Scanners.
Using IPI with ASM - It acts like an entity and can be alarmed, blocked excluded and learned against.
IPI helps with DoS mitigation by allowing blocking against IPs which originate the attacks.
IPI can also block egress traffic like infected PC's that call home to Botnet C&C node on IPI known address.
Use IPI with AFM, ASM or irules
lookup IPI database iprep_lookup 220.127.116.11
Identity Provider (IDP) - Authenticates and authorises user and creates security assertion
creates a SAML assertion (XML) with details when you have authenticated.
Service Provider (SP) - Receives and validates an assertion from IdP and provides access to requested application
OpenID Connect is used for authentication
UserInfo endpoint for getting more user information
Standard set of scopes
OAuth 2.0 is used for authorisation
ASM DoS Protections
CAPTCHA - CAPTCHA is issued
Request Blocking - Blocks requests when protection is active
ASM XML profile helps prevent illegal usage of XML parameters by client by enforcing limits defined by the application.
User and Session tracking - ASM can track via login pages and APM via usernames for sessions. Various alerts, limits and thresholds can be configured on them with a variety of variables like IP, number of sessions etc.
Common types of application (L7) DoS attacks the ASM can block
HTTP GET and page flood attacks.
HTTP GET asks for all resources like images and scripts while page flood requests for specific URLs over and over.
Advanced Web Application Firewall (WAF)
Proactive Bot Defence (PBD) - e.g. user is acting like a bot and will be limited / blocked
Brute Force Protection
Malware and fraud detection
application layer encryption (real-time) (key log protection )
Behavioural DDoS (layer 7 DDoS) (Unlimited)
Upstream Signalling (redirect traffic to Silverline)
Credential Stuffing (have I been pwned / stolen credentials)
Threat Campaigns (Also needs threat campaign subscription, little to no false positives )
Layer 7 DoS Bot Protection
Layer 7 DoS Bot Protection TPS
Layer 7 Bot defence is enabled by creating a ASM DoS profile, enabling application security then enabling TPS-based Detection by changing the mode to blocking. this can be trigger by a number of factors, for example soure IP, devie, ID, geo-loation, etc , plus thresholds.
Suspicious Web Browsers
Suspicious Web Browsers will also be blocked if the above profile is enabled as "block requests from suspicious browsers" is enabled by default.
FPS is WebSafe Fraud Protection Service
Websafe uses HTML and the Document Object Model (DOM)
Websafe detection and protection
Application layer encryption
Automated transaction protection
Dynamic Application Security Testing is a suite of tools that is given an site or URL as input and performs a series of scans, probes and and attacks to determine the vulnerability of the target. ASM blocks most of this activity.
Positive security - Defines what is allowed and everything else is rejected."Default Deny"
Negative security - Defines what isn't allowed and everything else is accepted."Default Accept"
Payment Card Industry Data Security Standard PCI-DSS
The PCI Compliance Report lists each security measure required to comply with PCI-DSS 3.0, and indicates which measures are relevant, or not relevant, to the Application Security Manager. For security measures that are relevant to the Application Security Manager, the report indicates whether this Application Security Manager appliance complies with PCI-DSS 3.0. For security measures that are not relevant to the Application Security Manager, the report explains what action you must take to make this Application Security Manager appliance comply with PCI-DSS 3.0.
Build and maintain a secure network
Install and maintain a firewall configuration to protect cardholder data
Do not use vendor-supplied defaults for system passwords and other security parameters
Protect cardholder data
Protect stored cardholder data
Encrypt transmission of cardholder data across open, public networks
Maintain a vulnerability management program
Use and regularly update anti-virus software
Develop and maintain secure systems and applications
Implement strong access control measures
Restrict access to cardholder data by business need-to-know
Assign a unique ID to each person with computer access
Restrict physical access to cardholder data
Regularly monitor and test networks
Track and monitor all access to network resources and cardholder data
Regularly test security systems and processes
Maintain an information security policy
Maintain a policy that addresses information security
The previous versions are no longer considered safe for data transmission compared to the encryption security provided by TLS 1.3 and even TLS 1.2.
The Payment Card Industry Security Standards Council’s (PCI) final deadline for TLS 1.0 was in March 2018. Moreover, the PCI Data Security Standard (PCI DSS) mandates that users disable the utilization of all SSL/TLS 1.0 applications by no later than June 30, 2018. Although PCI will still accept TLS 1.1, users are strongly encouraged to adopt the utilization of newer versions of TLS protocol.
Compared to TLS 1.2, TLS 1.3 offers improved speed. The faster speed for encrypted connections stems from features such as Zero Round Trip Time (0-RTT) and TLS false start. In the past, TLS 1.2 required two round-trips to finish a TLS handshake. In contrast, TLS 1.3 only needs to complete one round-trip. This reduces encryption latency by one-half. With this feature, users will be able to browse websites faster and with greater security.
Compared to TLS 1.2, which webmasters and system administrators struggled to consistently configure properly and thus made connections to websites vulnerable to attacks such as the RC4 and BEAST exploits, TLS 1.3 has removed the deprecated features that caused these issues, including SHA-1, RC4, DES and AES-CBC, among others. With this streamlined approach, Web developers and administrators are now less susceptible to misconfiguring protocols, thus making websites safer for users in terms of confidentiality and integrity as well as reducing the risk of cyberattacks.
Federal Information Processing Standard
Ensure computer security and interoperability , such as ANSI / IEEE / ISO
HTTP Strict Transport Security (HSTS)
This can be set in the HTTP profile
HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should interact with it using only secure HTTPS connections, and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797.
Session Cookie Hijacking Protection
The ASM Feature cookie name is constructed with eight hexadecimal characters and three decimal characters (TSxxxxxxxxd). The d in the name represents the type of feature being triggered in the BIG-IP ASM policy.
The ASM Proactive cookie format varies depending on the BIG-IP ASM enabled feature. The structure is as follows:
The ASM Proactive cookies related to client-side challenges begin with the TSPD_101 prefix by default.
The ASM Proactive cookies related to cross-domain flow begin with the TSPD prefix by default.
The ASM Feature cookies are set for client requests when one or more BIG-IP ASM features are activated or enabled, such as the following policy features:
Login/Logout page enforcement
If an attack can get a valid username then he can easily preform Brute force attacks until he gets a valid login. ASM can protect against this by using , Sessions and login pages, creating a login page, with URL, username and password field along with the unsuccessful login string and the HTTP response code. The login names will now be logged along with the login result. Now that these details are logged, the anomaly detection -> brute force configuration needs added to the policy with the appropriate values set.
Cookie Modification (session hijacking)
An attack could hijack a user session and modify the cookies. ASM can protect against that by learning and enforcing in " headers then cookie list"
Proactictive Bot defence
Attack like HTTP get login.asp hundreds of times is a layer 7 DDoS attack, this can be mitigated by ASM Proactive Bot Defense
Cross Site Scripting Attacks
Generally cross site scripting attacks are performs by the attacker entering scripts into user input fields. This can be easily protected by ASM using a basic signature based ASM policy.
Generally cross SQL injection attacks are performs by the attacker entering scripts into user input fields that query the SQL database backend and expose sensitive information. This can be easily protected by ASM using a basic signature based ASM policy.
This feature allows you to configure response scrubbing for sensitive user information, such as credit card numbers or social security numbers.This pervents information leakage and is need for PCI (Payment Card Industry) compliance. The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle branded credit cards from the major card schemes.
The PCI Standard is mandated by the card brands but administered by the Payment Card Industry Security Standards Council. The standard was created to increase controls around cardholder data to reduce credit card fraud.
This basicly just needs enabled by checking the datagaurd checkbox in the ASM profile, if the license permits.
File Type Enforcement
Forceful browsing is used to gain access to restricted pages of sensitive pages by accessing the URL directly.
File type enforcement can mitigate forceful browsing. ASM can limit file types by creating a file type whitelist. (Allways not *) (Learn then enforce) further learning can be enabled)
Protect against malicious user input, with allowed URL configured, parameters can be enforced.(Allways not *) (Learn then enforce )
data type and length
Protect against man in the middle attacks. This is done by creating dynamic parameter values in the ASM policy.
CSRF Protection (Cross-site request forgery)
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. This can be protected by enabling an ASM policy the CSRF checkbox enabled on the CSRF page. By default this enables protection for all URLs, this can be edited to just protect the URLs that need this protection.
Web scraping, web harvesting, or web data extraction is data scraping used for extracting data from websites. ASM can protect against this by using anomaly detection and web scrapping and enable bot detection to alarm and block.
Login Page Enforcement (forceful browsing)
An Attacker may try to bypass the login page of a web application. ASM security policy can prevent this by using the, Sessions and login pages, creating a login page, with URL, username and password field along with the unsuccessful login string and the HTTP response code, then configure the login enforcement page with authenticated URLs. These URLs with now only be available if the user has successful authenticated. Any force browsing attempt will be blocked.
The secure flag restricts the cookie to only being sent over HTTPS so it is secure.
AFM is a layer 4 stateful full proxy
AFM Network Firewall is considered to be default allow, also known as Application Delivery Controller (ADC) mode. This mode allows access to all traffic processing objects and requires one or more firewall rules to block access.
AFM match order -
AFM excels at preventing TCP, UDP, DNS, HTTP and floods with attack characteristics defined (similar to ASM attack signatures).
DNS server to resolve FQDN
Public and private keys from Google
Input parameters for the two words
Secret, Site Key, Verification URL, Challenge URL, Noscript URL
BIG-IP Local Traffic Manager
Software services - · Advanced routing (BGP, RIP, OSPF, ISIS, BFD)
BIG-IP Advanced Firewall Manager
BIG-IP Application Security Manager
BIG-IP Access Policy Manager
Negotiation phase handshake examples
In the following example, the client offered protocol TLSv1.2 (version 3.3) and the server downgraded the protocol to TLSv1.0 (version 3.1). The server also chose the preferred cipher from the client's list:
1 1 0.0003 (0.0003) C>SV3.3(79) Handshake
1 2 0.0008 (0.0005) S>CV3.1(74) Handshake
In the following examples, the client and server fail to agree on the SSL protocol version in the first example, and the SSL cipher in the second example.
Example 1: The client and server unsuccessfully negotiate the protocol. The server does not support protocol version below TLS1 (version 3.1) and the client does not support protocol versions above SSLv3 (version 3.0):
1 1 0.0012 (0.0012) C>SV3.0(47) Handshake
1 2 0.0013 (0.0000) S>CV0.0(2) Alert
Example 2: The client and server unsuccessfully negotiate a cipher; the server does not support any of the client's ciphers. This is a common failure:
1 1 0.0012 (0.0012) C>SV3.1(58) Handshake
1 2 0.0013 (0.0000) S>CV3.2(2) Alert
-Version 3.0 = SSLv3,
-Version 3.1 = TLS 1.0
-Version 3.2 = TLS 1.1
-Version 3.3 = TLS 1.2
## No SSL Profile
The client will open a connection to the virtual on port 443, a TCP
connection will be established, and the client will send a ‘ClientHello’. Normally the server would then respond
with ServerHello, but in this case there is no response and after some period of time (5 minutes is the default
timeout for the browser) the connection is closed.
New TCP connection #1: 10.0.0.10(46226) <-> 10.0.0.20(443)
1 1 0.0011 (0.0011) C>SV3.1(84) Handshake
4c b6 3b 84 24 d7 93 7f 4b 09 fa f1 40 4f 04 6e
af f7 92 e1 3b a7 3a c2 70 1d 34 dc 9d e5 1b c8
[a number of other cipher suites]
Unknown value 0xff
1 299.9883 (299.9871) C>S TCP FIN ***** client closes the connection
1 299.9883 (0.0000) S>C TCP FIN
##No Cipher agreed
This is a common scenario when really old browsers try to connect to servers with modern cipher suites. We
have purposely configured our SSL profile to only accept one cipher suite (TLS_RSA_WITH_AES_256_CBC_
SHA in this case). When we try connect to the virtual using a 128-bit key, the connection is immediately closed
with no ServerHello from the virtual server. The differentiator here, while small, is the quick closure of the
connection and the ‘TCP FIN’ that arises from the server. This is unlike the behavior of the missing SSL profile,
because the server initiates the connection teardown and there is no connection timeout. The differences,
while subtle, hint at the details of the problem:
New TCP connection #1: 10.0.0.10(49342) <-> 10.0.0.20(443)
1 1 0.0010 (0.0010) C>SV3.1(48) Handshake
4c b7 41 87 e3 74 88 ac 89 e7 39 2d 8c 27 0d c0
6e 27 da ea 9f 57 7c ef 24 ed 21 df a6 26 20 83
Unknown value 0xff
1 0.0011 (0.0000) S>C TCP FIN **** server closes connection
1 0.0022 (0.0011) C>S TCP FIN
C > S * TCP FIN CLIENT CLIENT CLOSES CONNECTION (No SSL)
S > C * TCP FIN CLIENT CLIENT CLOSES CONNECTION (No Cipher agreed)
when Server does not allow any ciphersuite in ClientHello or does not allow SSL/TLS versions in ClientHello the Server denies connection and sends Fatal Alert to Client
tcpdump SSL ?? Bad MAC maybe "million question" attack
A plausible cause would be the following: the client is using a purported server public key which does not match the actual server private key.
Normally, the client will extract the server public key from the server certificate, which the server sends to the client during the handshake.
The server also owns a private key, which is mathematically linked with the public key. If the server is configured to use the wrong file,
then you could obtain the symptoms you observe.
Proxy SSL (Bulk decrypt/encrypt) (needs to be RSA)
Client handshakes directly with the Server
All further communication is done by the F5 (Client and Server SSL profiles need configured with the server KEY and CERT)
Set an http profile up with;
Set the Fallback Host:
Fallback on Error Codes:
Response Headers Allowed: Content-Type Set-Cookie Location
Insert XForwarded For: Enabled
A client request may be redirected from the HTTPS protocol to the HTTP protocol, which is a non-secure channel. If you want to ensure that the request remains on a secure channel, you can configure the BIG-IP system to rewrite the redirection so that it is redirected back to the HTTPS protocol. To enable the BIG-IP system to rewrite HTTP redirections, you use the Rewrite Redirections setting to specify the way that you want the system to handle URIs during the rewrite.
You can configure the HTTP profile so that the BIG-IP system encrypts HTTP cookies before sending them to the client system. The system can encrypt BIG-IP persistence cookies, as well as cookies that are embed in the response from the server. You can also configure the BIG-IP system to encrypt cookies to keep information private if the cookie contains sensitive information about the web application. When cookie encryption is enabled, the BIG-IP system extracts the unencrypted cookie from the server response, encrypts it using a 192-bit AES cipher, and then encodes it using the Base64 encoding scheme. The BIG-IP LTM system then embeds the encrypted cookie into the HTTP response to the client. On subsequent requests, when the client presents the encrypted cookie to the BIG-IP system, the system removes the cookie, decodes it using the Base64 encoding scheme, and decrypts it. The BIG-IP system then re-embeds the decrypted cookie in the HTTP request to the server.
An L7 DoS profile, the Accept XFF option allows the BIG-IP system to take action based on IP addresses from the X-Forwarded-For header that match, for example, an Access List.
HTTP Profile setting
Secure Web Gateway filters outbound traffic based on URL categorisation and scans packets for malicious content (malware inspection).
F5 DC Agent is a Windows app that attempts to identify users based on their Windows logon domain and informs SWG.
The IF MAP server resides on thew BigIP and contains the maps of usernames to IPs
URLF is URL Filtering
Internet Content Adaptation Protocol
REQMOD Can be used to ask ICAP Server to modify Requests
RESPMOD Can be used to ask ICAP Server to modify Response
100 Continue after ICAP Preview, Client is still sending the request to the ICAP Server, and client should send any requests that is queued.
204 No modifications needed.
400 Bad request
404 ICAP Server not found
405 Method not allowed for service (e.g., RESPMOD requested for service that supports only REQMOD).
408 Request timeout. ICAP server gave up waiting for a request from an ICAP client.
500 Server error. Error on the ICAP server, such as “out of disk space”.
501 Method not implemented. This response is illegal for an OPTIONS request since implementation of OPTIONS is mandatory.
502 Bad Gateway. This is an ICAP proxy and proxying produced an error.
503 Service overloaded. The ICAP server has exceeded a maximum connection limit associated with this service; the ICAP client should not exceed this limit in the future.
505 ICAP version not supported by server.
Web Application Testing / Security / Auditing Tools
HTTP watch - Capturing HTTP data from client to server from the client before it is encrypted and after it is decrypted like Fiddler.
Fiddler - Captures HTTP/HTTPS traffic to review like HTTPWatch
Cain and Able - Network password sniffing and Microsoft password recovery, it can generate a DoS attack with the amount of fake packets it generates.
THC Hydra - Login cracker for passwords like John the Ripper but online. Performs brute force guessing so it generates a Brute Force Attack.
John the Ripper - Password cracker for passwords like THC Hydra but offline. Also generates a Brute Force Attack in its cracking attempts.
OWASP ZAP/Zed Attack Proxy - DAST/Web Application Security Scanner that does scanning and vulnerability testing like Burp Suite. Also able to proxy and manipulate proxied traffic.
Burp Suite - Java-based DAST/Web Application Security Scanner like Zed Attack Proxy.
W3af - Web application security scanner.
HTTrack - Web crawler/web scraper
CIA Confidentiality, Integrity, Availability.
Confidentiality is the set of rules to limit access to information
Integrity means the information is trustworthy
Availability is guarantee the information accessibly by authorised persons.
Vulnerability - A weakness or gap in security protection which can be exploited by a threat.
Risk - The potential for loss, damage or destruction of an asset as a result of a threat exploiting a vulnerability.
OWASP Top Ten - Open Web Application Security Project's ten most critical web application security flaws.
Remotely-Triggered Black Hole (RTBH) routing is an interesting application of BGP as a security tool within service provider networks.
Case study 1: An organisation has following Challenges:
High volumes of SSL traffic during online promotions -LTM
Securing service availability in heavy traffic - LTM
Protecting against web vulnerabilities and DDoS attack - ASM / Silverline /AFM / GTM/ IPI
Answer the following questions based on above case study.
Which modules of F5 can help customer to overcome the described challenges? LTM ASM AFM / Silverline
Which DDoS feature can help customer to mitigate the attack?
Would you advise Web Scrapping or bot defense? Bot Defense
Can Websafe be helpful? If yes, which features of Websafe you can incorporate? Yes , Application layer encryption, Malware detection, Automated transaction protection
Case study 2: An organization has following challenges:
Limited rack space for moving into private cloud - VE's / VCMP
Authentication for email system on Office 365 - APM
Replace old authentication and SSL VPN systems - APM
Answer the following questions based on above case study.
Which modules of F5 are suitable for the requirement? APM / LTM
Which platform do you recommend to customer considering limited rack space? VE's / VCMP
Which multi-factor authentication can be helpful for secure web application access? ???? token / Push /
How would you design your VPE for this requirement in APM?
Which multi factor auth would you suggest?
Case study 3: An organization has following challenges:
Deliver fast, quality services for customers
Ensure high application availability - LTM
Adapt to support new applications and business growth
Answer the following questions based on above case study.
Which modules of F5 can help to resolve all the challenges? LTM / ASM
How can you ensure highest possible uptime and low latency to the users while accessing real time applications? LTM / AFM / ASM
How can you ensure high availability and low latency of the application for the users coming from different geo locations? GTM / Anycast
Case study 4: An organization has following challenges:
Customer demand for faster services
Firewall bottlenecks in the current system
Continued support for multihoming and ISP line redundancy
Need for enhanced security
Answer the following questions based on above case study.
Which module of modules of F5 can help to resolve all the challenges? ASM / LTM / GTM
CGNET or PEM can be helpful? Yes? How? No? which other features can accommodate all the needs?
For enhanced security, what additional features can be leveraged? Silverline
Case study 5: An organization has following challenges:
Ensure constant security, reliability and data integrity, with attention to those transmitted to suppliers and customers and published externally through web services (such as portals for the PA)
Reduce costs and rationalize the management of resources
Enhance the performance of a growing number of services, eliminating potential downtime or operational delays.
Answer the following questions based on above case study.
Which module of modules of F5 can help to resolve all the challenges? APM / LTM / AFM / Silverline
Which features of APM can be useful? Yes Can you use SSL VPN? Yes Portal access with/without rewrite? With
How would you advise on AAA? AD
Case study 6: An organization has following challenges:
Downtime caused by DDoS activity
Limited in-house cloud security expertise
Inadequate visibility into attacks
Answer the following questions based on above case study.
Which services or modules would you advise to address listed challenges? Silverline
Which DDoS solutions offered by F5 can be useful to mitigate the attack as described in the case study? Silverline
Would you advise customer to use Session tracking in ASM? no
Can Silverline DDoS defense be helpful to mitigate the attack? yes