401 v2





Threat Modelling

READ !!! https://f5.com/Portals/1/Premium/Architectures/RA-DDoS-Playbook-Recommended-Practices.pdf



  1. Get a good hold on Silver line. Deployment mode, etc. When to use which mode, pros and cons etc.

  2. DDoS concepts are tested extensively, w.r.t AFM, ASM and device DDoS

  3. Understanding Kerberos and NTLM authentication and related security flaws while understanding how APM can help

  4. SAML use cases

  5. Read customer success stories on f5.com - https://www.f5.com/customer-stories

  6. Read all reference architecture guides on F5 - https://www.f5.com/services/resources/deployment-guides

  7. Finally be prepared to reading lengthy problem descriptions

  8. For Threat modeling, I study the STRIDE/DREAD model of Microsoft. Also the Owasp docs on the same subjects

  9. For design, I study the roles on each components and security features, customer stories on F5 website, light board..

  10. For operation, diagnosis notes on askf5 and lot of labs

  11. For incident response, study all reference guide (DDOS...) and be able to determine the right solution for a case.

  12. And practice always, read what you can to be sure to understand well the solutions (Maybe too much...)

  13. websafe, Silverline, WAF and knowing when to use it


Security terminology

What is a Threat in security terminology

-A threat refers to a new or newly discovered incident that has the potential to harm a system or your company overall. Anything that can exploit a vulnerability and gain unwanted access to an asset. These are the things that are being protected against.

What is a Vulnerability in security terminology

-A vulnerability refers to a known weakness of an asset (resource) that can be exploited by one or more attackers. In other words, it is a known issue that allows an attack to succeed.

What is a Risk in security terminology

-The potential for loss, damage or destruction of an asset as a result of a threat exploiting a vulnerability.

Usability over risk means doing something knowing that a threat may use a vulnerability to access an asset.

Usability over threat means knowing a threat is present using a vulnerability to access an asset.

Usability over vulnerability means knowing a vulnerability is present.


Common Vulnerabilities & Exposures (CVE)

TLS / SSL vulnerability aka the "Bar Mitzvah" issue.

K16864: SSL/TLS RC4 vulnerability CVE-2015-2808



configure SSL profile !RC4


TLS / SSL vulnerability aka BEAST exploit



configure SSL profile 'DEFAULT:!SSLv3:!RC4'



TLS / SSL vulnerability aka a ROBOT attack.


Robot Vulnerability (CVE-2017-6168) Remediation




configure SSL profile !RSA


Common Vulnerability Scoring System (CVSS)

CVSS is an open framework for communicating the characteristics and severity of software vulnerabilities. Learn how a vulnerability gets scored by using the Base, Temporal, and Environmental metric groups.

Common Vulnerability Scoring System v3.1: Examples




SSLO logs content into two main files;


For normal logging, error logging, connections, and other normal BIG-IP logging.


For policy decisions. Most useful when troubleshooting problems with chains and services.

Device logs

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)

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[17605]: 01580005:5: /Common/APM-HTTP-TEST:Common:95fd323f: discard ACL: /Common/block-lab-SSH:0 packet: http://zoltan.home/login. html tcp ->

secure: 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))



Testing tools

Docker Test SAML IDP

F5 Access Policy Manager and Okta: Multi-Factor Authentication and Single Sign-On

https://developer.okta.com/ ??? setup ??? https://support.google.com/a/answer/6349809?hl=en&ref_topic=6348126

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

APM ADFS proxy (Microsoft Active Directory Federation Services)

https://www.youtube.com/watch?v=Awf6LVMVtH0 - ADFS Proxy on F5 BIG-IP

https://www.youtube.com/watch?v=b1JtV-eV138 - Microsoft ADFS Web Application Proxy Using F5 BIG-IP


https://www.youtube.com/watch?v=Jz-McWn1AFE - Getting started with SSL VPN on BIG-IP APM

Kerberos / domain delegation


HTTP 401 response - Kerberos negotiation

https://www.youtube.com/watch?v=CuROO2Qpllg - Using the F5 BIG-IP to provide Kerberos authentication with end-user logons

https://youtu.be/UGWP4ewxcTA - Kerberos Delegation and Protocol Transition (good)

https://youtu.be/u7MQoSN19O4 - Basic Kerberos Authentication

https://youtu.be/NDFJ7m8iaPA - Kerberos Authentication on BIG-IP APM

Key Distribution Center (KDC)

*Kerberos only requires that you have a username and a domain

*APM credentials (session.logon.last) Username and Password

KDC - Key Distribution Centre (AD server)

  • Authentication service (AS)

  • Ticket Granting Service (TGS)

SPN = Service principle name

SVC/principle @ realm = (HTTP/ www.example.com @ example.com) (HOST/ myserver.example.com @ example.com)

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.

Kerberos Constrained Delegation Pre-requisites

  • DNS Reverse Lookup Zones with appropriate A and PTR record(s)

  • All of the Active Directory domains involved in Kerberos Delegated authentication must be at a Microsoft Windows Server 2003 Functional Level or higher

  • Reliable time source to be used by Active Directory and the BIG-IP

**************Kerberos only requires that you have a username and a domain

Ex. Account Name: host/apm-svc.siterequest.com

Based on my testing, if the account name is not provided in SPN format the following error will be generated in the APM logs.

Kerberos: can't get TGT for apm-svc.siterequest.com@SITEREQUEST.COM - Client 'apm-svc.siterequest.com@SITEREQUEST.COM' not found in Kerberos database (-1765328378)


One of the most common issues of KCD is the use of incorrect reverse lookup records or no reverse lookup record created at all. Using Microsoft documentation, I found the clearest documentation that I could on this subject.

“Determine whether you are connecting to the Web site by using the actual NetBIOS name of the server or by using an alias name, such as a DNS name (for example, www.microsoft.com). If you are accessing the Web server by using a name other than the actual name of the server, a new Service Principal Name (SPN) must have been registered by using the SetSPN tool. Because the Active Directory directory service does not know this service name, the ticket-granting service (TGS) does not give you a ticket to authenticate the user. This behavior forces the client to use the next available authentication method, which is NTLM, to renegotiate. If the Web server is responding to a DNS name of www.microsoft.com but the server is named webserver1.development.microsoft.com, you must register www.microsoft.com in Active Directory on the server that is running IIS. To do this, you must run the SetSPN tool on the server that is running IIS.”

NTP issue - error log

Kerberos: can't get TGT for host/apm-svc.siterequest.com@SITEREQUEST.COM - Clock skew too great (-1765328347)


https://www.youtube.com/watch?v=5N242XcKAsM - Kerberos Authentication Explained | A deep dive


OCSP - Online Certificate Status Protocol

OCSP (Online Certificate Status Protocol) removes many of the disadvantages of CRL by allowing the client to check the certificate status for a single certificate.

CRLDP Certificate Revocation List Distribution Point (CRLDP)

CRL (Certificate Revocation Lists) contains a list of certificate serial numbers that have been revoked by the CA. The client then checks the serial number from the certificate against the serial numbers within the list.


The first type of CRLDP is Lightweight Directory Access Protocol (LDAP). This is superficially similar to the directory approach. The distinction is clarified here:

With directory based access, which is still likely to use the LDAP protocol, only the name of the directory entry is specified. This means that the RP can use a local directory server, which gives efficient high performance access. To achieve this, the local directory server needs to be connected to other directory servers participating in the PKI.

With an LDAP CRLDP, the LDAP server is explicitly specified. This means that all RPs need to connect to the same LDAP server. In some environments this works well, but it can lead to scaling problems or performance issues when the RP is not close to the LDAP server. This can be mitigated to some extent by use of multiple LDAP CRLDP values.

A key benefit of LDAP CRLDP is that most CAs support LDAP CRL publishing, so this integrates cleanly.


The second type of CRLDP is HTTP. Essentially, this is using a Web server to publish CRL information. Superficially, this seems similar to use of LDAP, but uses a more general protocol. It has a number of functional advantages over LDAP:

Operational experience suggests that timeouts work better, which is important when network access is poor.

HTTP works better than LDAP when Firewalls and other network boundaries are involved.

In large scale deployments HTTP can feed into Content Distribution Networks (CDNs). This gives effective wide area replication of the data and mitigates the issues of central access.


The LDAP and HTTP CRLDP mechanisms both work by sharing CRL information. There are two key problems with this:

CRLs can get large. This is not an issue for a server that is checking lots of certificates. However, where the RP is an end user checking the occasional certificate, retrieving the CRL can cause performance problems, particularly if the client is connected over a constrained link.

CRLs contain "next update" information, which enables an RP to detect if a CRL is out of date (and so a new CRL needs to be retrieved). The difficulty with this is that most RPs will use the cached CRL until "next update" time. Certificates are often revoked for reasons where quick response to the revocation is highly desirable.

OCSP (Online Certificate Status Protocol) was designed to address this, by providing a client/server protocol that enables an RP to check the status of a certificate. An OCSP server is indicated by a special certificate extension.

API security ?



ASM Application Language

The BIG-IP ASM Application Language setting specifies the default character encoding set for the web application. The language encoding determines how the security policy processes the character sets. The default language encoding determines the default character sets for headers, objects, parameter names, and parameter values.

When you create a new security policy for the BIG-IP ASM system, you must specify the character encoding method used by the web application in order to apply the correct character set.

The character encoding method is a key characteristic of the security policy, and cannot be changed. Additionally, policies cannot be imported to replace a policy that uses a different encoding language.

There are several ways to determine the character encoding method used by a web application:

You can view the site in a web browser and obtain the character encoding method from the web browser. Refer to the documentation for your web browser for information about viewing the character encoding method.

You can perform a packet trace and view the Content-Type HTTP header.

You can ask the administrator of the web application how the application is configured.

You can use the following website to validate the current encoding designated by the site:


ASM must know the character set so it can evaluate requests based on the correct encoding. It checks if the byte sequence is correct for the specified application language. Attack signatures are useless if the application language is incorrect and learning suggestions would be meaningless.

K7921: Error Message: Failed to convert character

  • To work around this issue, you can allow a Failed to convert character string to pass the BIG-IP ASM system.







01. Threat Analysis

02. Architect Solutions

03. Operation and Implementation

04. Security Response





Understanding CSRF, the video tutorial edition




Threat Modeling


  • Damage (potential)

  • Reproducability

  • Exploitability

  • Affected users

  • Discoverability

Secure Development Lifecycle



  • threat modeling



  • Code Review



  • Code Review


  • Pen Testing

  1. What are we building ?

  2. What can go wrong ?

  3. What are we going to do about it ?

  4. Did we do a good enough job ?

1.Scope -> 2. Draw -> 3. Analyse -> 4. Mitigate -> 5. Document

Step 1. Scope: Feature / Module (start small ) or Subsystem / Service or Entire Product

  • Entities: User / Admin / Attacker

  • Attack Surface: Accept network packets ? Network Protocols ? Web Interface? Administration ? System daemon ? CLI ?

SAMPLE: As there is no authentication the form is pushed outside the trust boundary


Example Threat Model Diagram


  • Spoofing Identity

  • Tampering with data

  • Repudiation, Deniability

  • Information Disclosure

  • Denial of service

  • Elevation of privilege


https://owasp.org/www-community/Application_Threat_Modeling - OWASP Application Threat Modeling

https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html - OWASP Threat Modeling Cheat Sheet

https://www.youtube.com/watch?v=Fmp9UFjPiJs - Threat Modeling: uncover vulnerabilities without looking at code (Good)

https://www.youtube.com/watch?v=KGy_KCRUGd4 - APPSEC Cali 2018 - Threat Modeling Toolkit


The Four Categories of DDoS

  1. 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 (Layer7)

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)

  • Keep-Dead

  • Slow POST (R-U-Dead-Yet, Tor Hammer, Nuclear DDoSer, Slowhttptest)

  • HashDoS

  • 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 Flood

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.

NXDomain Flood

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

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

SYN Flood

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 Flood

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.

Memcached Amplification (Example John outlines the details of the DDoS attack that targeted the popular GitHub website.)

*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

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!!!


The F5 DDoS Protection Reference Architecture


Mitigating DDoS attacks with F5

Real Attack Stories: Financial Botnet


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

  • CAPTCHA Request-throttling

  • 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


MID-TO-LARGE ENTERPRISES BIG-IP i5000 / i7000 / i10000 series


Cross Site Request Forgery (CSRF)

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!! ...Look for the auth cookie in the request!

https://www.youtube.com/watch?v=1QZfes9q1LI - F5 Configuring CSRF protection

https://youtu.be/5joX1skQtVE - What is a CSRF? | OWASP Top 10 2013

https://youtu.be/eWEgUcHPle0 - Cross-Site Request Forgery Attack

https://www.youtube.com/watch?v=hW2ONyxAySY - Understanding CSRF, the video tutorial edition (Good)

Open Web Application Security Project OWASP TOP TEN


Almost any source of data can be an injection vector, environment variables, parameters, external and internal web services, and all types of users. Injection flaws occur when an attacker can send hostile data to an interpreter.

Injection flaws are very prevalent, particularly in legacy code. Injection vulnerabilities are often found in SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries. Injection flaws are easy to discover when examining code. Scanners and fuzzers can help attackers find injection flaws.

Injection can result in data loss, corruption, or disclosure to unauthorized parties, loss of accountability, or denial of access. Injection can sometimes lead to complete host takeover. The business impact depends on the needs of the application and data.

***injection attack is attacking the server

*SQL injection


Ref and Example;

https://www.youtube.com/watch?v=9CnpHT5Nn8c - OWASP Top 10: A1 Injection

https://youtu.be/Znywg57m2iM - What is Injection? | OWASP Top 10 2017 | Video by Detectify

https://youtu.be/rWHvp7rUka8 - OWASP Top 10: Injection Attacks Dev Central

https://youtu.be/-tF-ZkzdThI - The OWASP Top Ten Proactive Controls - Jim Manico *V.Good

https://www.youtube.com/watch?v=CCIO3GOaFe0 - OWASP Top Ten(s) to the OWASP ASVS - Jim Manico


https://portswigger.net/web-security/os-command-injection - Command Injection / Shell Command

https://www.youtube.com/watch?v=fV0qsqcScI4 - XPath Injection

Command Injection

cmd1||cmd2 : Command 2 will only be executed if command 1 execution fails.


A2:2017-Broken Authentication

Attackers have access to hundreds of millions of valid username and password combinations for credential stuffing, default administrative account lists, automated brute force, and dictionary attack tools. Session management attacks are well understood, particularly in relation to unexpired session tokens.


*broken access / authentication - cookie tampering

A3:2017-Sensitive Data Exposure

Rather than directly attacking crypto, attackers steal keys, execute man-in-the-middle attacks, or steal clear text data off the server, while in transit, or from the user’s client, e.g. browser. A manual attack is generally required. Previously retrieved password databases could be brute forced by Graphics Processing Units (GPUs)

Example Attack Scenarios

Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption. However, this data is automatically decrypted when retrieved, allowing a SQL injection flaw to retrieve credit card numbers in clear text.

Scenario #2: A site doesn’t use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g. at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user’s session cookie. The attacker then replays this cookie and hijacks the user’s (authenticated) session, accessing or modifying the user’s private data. Instead of the above they could alter all transported data, e.g. the recipient of a money transfer.

Scenario #3: The password database uses unsalted or simple hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted.


A4:2017-XML External Entities (XXE)

Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations.

Applications and in particular XML-based web services or downstream integrations might be vulnerable to attack if:

* The application accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor.

* Any of the XML processors in the application or SOAP based web services has document type definitions (DTDs) enabled. As the exact mechanism for disabling DTD processing varies by processor, it is good practice to consult a reference such as the OWASP Cheat Sheet ‘XXE Prevention’.

* If the application uses SAML for identity processing within federated security or single sign on (SSO) purposes. SAML uses XML for identity assertions, and may be vulnerable.

* If the application uses SOAP prior to version 1.2, it is likely susceptible to XXE attacks if XML entities are being passed to the SOAP framework.

Being vulnerable to XXE attacks likely means that the application is vulnerable to denial of service attacks including the Billion Laughs attack

Scenario #1: The attacker attempts to extract data from the server:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [


<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>


Scenario #2: An attacker probes the server’s private network by changing the above ENTITY line to:

<!ENTITY xxe SYSTEM "" >]>

Scenario #3: An attacker attempts a denial-of-service attack by including a potentially endless file:

<!ENTITY xxe SYSTEM "file:///dev/random" >]>


A5:2017-Broken Access Control

Exploitation of access control is a core skill of attackers. SAST and DAST tools can detect the absence of access control but cannot verify if it is functional when it is present. Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks.

* Bypassing access control checks by modifying the URL, internal application state, or the HTML page, or simply using a custom API attack tool.

* Allowing the primary key to be changed to another’s users record, permitting viewing or editing someone else’s account.

* Elevation of privilege. Acting as a user without being logged in, or acting as an admin when logged in as a user.

* Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation.

* CORS misconfiguration allows unauthorized API access.

* Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user. Accessing API with missing access controls for POST, PUT and DELETE.

Scenario #1: The application uses unverified data in a SQL call that is accessing account information:

pstmt.setString(1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user’s account.


Scenario #2: An attacker simply force browses to target URLs. Admin rights are required for access to the admin page.



If an unauthenticated user can access either page, it’s a flaw. If a non-admin can access the admin page, this is a flaw.


broken access / authentication - cookie tampering

A6:2017-Security Misconfiguration

Attackers will often attempt to exploit unpatched flaws or access default accounts, unused pages, unprotected files and directories, etc to gain unauthorized access or knowledge of the system.

The application might be vulnerable if the application is:

* Missing appropriate security hardening across any part of the application stack, or improperly configured permissions on cloud services.

* Unnecessary features are enabled or installed (e.g. unnecessary ports, services, pages, accounts, or privileges).

* Default accounts and their passwords still enabled and unchanged.

* Error handling reveals stack traces or other overly informative error messages to users.

* For upgraded systems, latest security features are disabled or not configured securely.

* The security settings in the application servers, application frameworks (e.g. Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values.

* The server does not send security headers or directives or they are not set to secure values.

* The software is out of date or vulnerable (see A9:2017-Using Components with Known Vulnerabilities). Without a concerted, repeatable application security configuration process, systems are at a higher risk.

Scenario #1: The application server comes with sample applications that are not removed from the production server. These sample applications have known security flaws attackers use to compromise the server. If one of these applications is the admin console, and default accounts weren’t changed the attacker logs in with default passwords and takes over.

Scenario #2: Directory listing is not disabled on the server. An attacker discovers they can simply list directories. The attacker finds and downloads the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a serious access control flaw in the application.

Scenario #3: The application server’s configuration allows detailed error messages, e.g. stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws such as component versions that are known to be vulnerable.

Scenario #4: A cloud service provider has default sharing permissions open to the Internet by other CSP users. This allows sensitive data stored within cloud storage to be accessed.

A7:2017-Cross-Site Scripting (XSS)

Automated tools can detect and exploit all three forms of XSS, and there are freely available exploitation frameworks.

There are three forms of XSS, usually targeting users’ browsers:

* Reflected XSS: The application or API includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim’s browser. Typically the user will need to interact with some malicious link that points to an attacker-controlled page, such as malicious watering hole websites, advertisements, or similar.

* Stored XSS: The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered a high or critical risk.

* DOM XSS: JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application would not send attacker-controllable data to unsafe JavaScript APIs.

Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM node replacement or defacement (such as trojan login panels), attacks against the user’s browser such as malicious software downloads, key logging, and other client-side attacks.

Scenario #1: The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

(String) page += "<input name='creditcard' type='TEXT'

value='" + request.getParameter("CC") + "'>";

The attacker modifies the ‘CC’ parameter in the browser to:




This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.

Note: Attackers can use XSS to defeat any automated Cross-Site Request Forgery (CSRF) defense the application might employ.

***xxs cross site script attack is attack the user

example XML attacks

$HTMLCode = <![CDATA[<script>alert('XSS')</script>]]>

$HTMLCode = &lt;script>alert('XSS')&lt;/script>

A8:2017-Insecure Deserialization

Exploitation of deserialization is somewhat difficult, as off the shelf exploits rarely work without changes or tweaks to the underlying exploit code.

Applications and APIs will be vulnerable if they deserialize hostile or tampered objects supplied by an attacker. This can result in two primary types of attacks:

* Object and data structure related attacks where the attacker modifies application logic or achieves arbitrary remote code execution if there are classes available to the application that can change behavior during or after deserialization.

* Typical data tampering attacks such as access-control-related attacks where existing data structures are used but the content is changed.

Serialization may be used in applications for:

* Remote- and inter-process communication (RPC/IPC)

* Wire protocols, web services, message brokers!

* Caching/Persistence

* Databases, cache servers, file systems

* HTTP cookies, HTML form parameters, API authentication tokens

Scenario #1: A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing user state and passing it back and forth with each request. An attacker notices the “R00” Java object signature, and uses the Java Serial Killer tool to gain remote code execution on the application server.

Scenario #2: A PHP forum uses PHP object serialization to save a “super” cookie, containing the user’s user ID, role, password hash, and other state:



An attacker changes the serialized object to give themselves admin privileges:



A9:2017-Using Components with Known Vulnerabilities

While it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require concentrated effort to develop a custom exploit.

You are likely vulnerable:

* If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies.

* If software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.

* If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use.

* If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities.

* If software developers do not test the compatibility of updated, upgraded, or patched libraries.

* If you do not secure the components’ configurations (see A6:2017-Security Misconfiguration).

Scenario #1: Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g. coding error) or intentional (e.g. backdoor in component). Some example exploitable component vulnerabilities discovered are:

* CVE-2017-5638, a Struts 2 remote code execution vulnerability that enables execution of arbitrary code on the server, has been blamed for significant breaches.

* While internet of things (IoT) are frequently difficult or impossible to patch, the importance of patching them can be great (e.g. biomedical devices).

There are automated tools to help attackers find unpatched or misconfigured systems. For example, the Shodan IoT search engine can help you find devices that still suffer from Heartbleed vulnerability that was patched in April 2014.

There are automated tools to help attackers find unpatched or misconfigured systems. For example, the Shodan IoT search engine can help you find devices that still suffer from Heartbleed vulnerability that was patched in April 2014.

A10:2017-Insufficient Logging & Monitoring

Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident.

Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected.

Insufficient logging, detection, monitoring and active response occurs any time:

* Auditable events, such as logins, failed logins, and high-value transactions are not logged.

* Warnings and errors generate no, inadequate, or unclear log messages.

* Logs of applications and APIs are not monitored for suspicious activity.

* Logs are only stored locally.

* Appropriate alerting thresholds and response escalation processes are not in place or effective.

* Penetration testing and scans by DAST tools (such as OWASP ZAP) do not trigger alerts.

* The application is unable to detect, escalate, or alert for active attacks in real time or near real time.

You are vulnerable to information leakage if you make logging and alerting events visible to a user or an attacker (see A3:2017-Sensitive Data Exposure).

Scenario #1: An open source project forum software run by a small team was hacked using a flaw in its software. The attackers managed to wipe out the internal source code repository containing the next version, and all of the forum contents. Although source could be recovered, the lack of monitoring, logging or alerting led to a far worse breach. The forum software project is no longer active as a result of this issue.

Scenario #2: An attacker uses scans for users using a common password. They can take over all accounts using this password. For all other users, this scan leaves only one false login behind. After some days, this may be repeated with a different password.

Scenario #3: A major US retailer reportedly had an internal malware analysis sandbox analyzing attachments. The sandbox software had detected potentially unwanted software, but no one responded to this detection. The sandbox had been producing warnings for some time before the breach was detected due to fraudulent card transactions by an external bank.

Two good pages that give examples and interactive demos



Top 10 Web Application Security Risks


Injection. Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

Broken Authentication. Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

Sensitive Data Exposure. Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

XML External Entities (XXE). Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.

Broken Access Control. Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

Security Misconfiguration. Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

Cross-Site Scripting XSS. XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

Insecure Deserialization. Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

Using Components with Known Vulnerabilities. Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

Insufficient Logging & Monitoring. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.


Common Vulnerabilities and Exposures, often known simply as CVE

https://www.youtube.com/watch?v=qfpnJyTl1To - What is Common Vulnerabilities & Exposures (CVE)

https://youtu.be/rR63F_lfKf0 - What is Common Vulnerability Scoring System (CVSS)

ASM response codes

blocking response code is 200 OK* Security ›› Application Security : Policy : Response Pages

HTTP response code definition

100-199 Informational codes

200-299 Status codes

300-399 Redirect codes

400 Bad request

401 Unauthorized

404 Not found

407 Proxy Authentication Required

417 Expectation failed

503 Service unavailable


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

shown below.

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.


Silverline DDoS datasheet.pdf

F5 DDoS Animated Whiteboard

Free Silverline Training

https://www.youtube.com/watch?v=zL39yiaBS2Y - F5 Silverline Proxy and Routed Modes


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 -

  1. Global

  2. Route Domain

  3. Virtual Server

  4. Self IP

  5. default action

AFM excels at preventing TCP, UDP, DNS, HTTP and floods with attack characteristics defined (similar to ASM attack signatures).

https://www.youtube.com/watch?v=GGNVgNY_Mz8&feature=youtu.be - Dynamic AFM Policy Selection

BIG-IP AFM also helps to ensure clean pipes for inbound traffic. Using remotely triggered black hole filtering (RTBH), BIG-IP AFM stops attack traffic even before it leaves the ISP network realm. When activated, BIG-IP AFM automatically broadcasts malicious IPs to upstream routers to enforce blacklisting through participating ISP routers, ensuring that only good traffic is routed to the data center network and applications within. RTBH functionality leverages the BIG-IP AFM IP shun category blacklist that uniquely identifies and blocks malicious L3–L7 attack sources in hardware until feed lists are updated. BIG-IP AFM can also signal and redirect traffic to F5 Silverline for DDoS Protection service. Silverline’s DDoS defense can be either reactive or proactive hybrid DDoS defense—ensuring always-up services by rerouting attacks away from the data center for cloud-based mitigation.

BIG-IP AFM offers more granularity and visibility into traffic and DDoS attacks than most solutions,with detailed logging and reporting of attack detection and mitigation. It also delivers increased SYN cookie protections, per-server granular DDoS policies, IP reputation intelligence, and custom whitelist and blacklist support. BIG-IP AFM uses hardware-based DDoS mitigation that scales to prevent high-volume, targeted, network flood attacks—while allowing legitimate traffic to flow without compromising performance.

DNS Security

DNS servers are critical to any mobile or fixed line network operator. Security is paramount to

operations, as the DNS protocol serves as the basis for internet infrastructure mapping of the

web domains that subscribers access. BIG-IP® DNS delivers an intelligent and scalable DNS

infrastructure that gives mobile users faster access and service response. This makes it easy for

service providers to optimize, monetize, and secure their DNS infrastructures. F5 DNS provides

carrier-grade, high-performance LDNS caching and resolving, and is a hyper-scale authoritative

DNS solution that handle business growth and sudden demand spikes.

BIG-IP AFM shields the DNS infrastructure from malicious attacks designed to reduce DNS

and service performance, launched by infected subscribers from undesired DNS queries and

responses. F5’s intelligent protection of DNS services inspects and validates traffic adherence

to the DNS protocol while dropping invalid requests or refusing to accept unsolicited responses.

BIG-IP AFM is an ICSA Labs certified network firewall with DDoS threshold alerting that hyperscales across many devices using IP Anycast for DDoS absorption. It mitigates threats by blocking

access to malicious IP domains.

Google Captcha

  • 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

Silverline signalling AFM

Security ›› Options : External Redirection : Scrubbing Profile ›› scrubber-profile-default


Websafe / Mobilesafe

protecting the users - browser security - via java-script injection from the F5

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.

https://youtu.be/zys1z1peDkw - Introducing F5 DataSafe

FPS is WebSafe Fraud Protection Service

WebSafe & MobileSafe

Websafe uses HTML and the Document Object Model (DOM)

Websafe detection and protection

Phishing detection

Malware detection

Application layer encryption

Automated transaction protection

IP Intelligence IPI

IP-Intelligence datasheet

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

TLS 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.

Faster Speed

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.

Enhanced 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.

SSL Security

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

Redirect Rewrite

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.

Encrypt Cookies

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.

Accept XFF

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.

ref; https://clouddocs.f5.com/training/community/adc/html/class3/module5/lab5.html

https://youtu.be/ZM3tXhPV8v0 - What is a TLS Cipher Suite? (very good)

https://youtu.be/k_C2HcJbgMc - Strong vs. Weak TLS Ciphers

Key Exchange - ECDHE - uses PFS perfect forward secrecy (TLS1.3)

Auth - RSA

Cipher - AES GCM

HTTP Profile setting

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[1] 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,[2] and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797.