Overview of MITRE ATT&CK Tactic: TA0040 - Impact
This article focuses on the Impact Tactic, and the techniques adversaries use to manipulate, disrupt or damage the systems and data as they reach the final stage of an attack. This is one of the critical tactics, as it highlights the adverse effects attackers can cause, including exploitation, operational disruption, data destruction, or financial gainForwarding Logs to SIEM Tools via HTTP Proxy for F5 Distributed Cloud Global Log Receiver
Purpose This guide provides a solution for forwarding logs to SIEM tools that support syslog but lack HTTP/HTTPS ingestion capabilities. It covers the deployment and tuning of an HTTP Proxy log receiver configured to work with F5 Distributed Cloud (XC) Global Log Receiver settings. Audience: This guide is intended for technical professionals, including SecOps teams and Solution Architects, who are responsible for integrating SIEM tools with F5 XC Global Log Receiver. Readers should have a solid understanding of HTTP communication (methods, request body, reverse proxy), syslog, and data center network architecture. Familiarity with F5 XC concepts such as namespaces, log types, events, and XC-GLR is also required. Introduction: Problem Statement: SIEM tools often support syslog ingestion but lack HTTP/HTTPS log reception capabilities. Objective: Explain how to deploy and configure an HTTP Proxy to forward logs to F5 Distributed Cloud Global Log Receiver. Solution Overview: Architecture Diagram and workflow: Configuration Steps: Configure Global Log Receiver in F5 Distributed Cloud Console Navigate to: Home → Shared Configuration → Global Log Receiver Create or edit the Global Log Receiver settings for HTTP receiver Ensure the Global Log Receiver batch size is based on the payload size expected from F5 NGINX. Example configuration snap: Set Up NGINX as an HTTP Log Receiver Install NGINX on your designated server. Configure log_format Configure NGINX to accept HTTP POST requests only and forward access logs to syslog Example configuration snippet: log_format custom_log_format_1 escape=json $request_body; # Example: include request body only server { listen 443 ssl; server_name <logreceiver_server_name>; ssl_certificate /etc/ssl/<logreceiver_server_cert>; ssl_certificate_key /etc/ssl/<logreceiver_server_key>; # Other SSL/TLS configurations (e.g., protocols, ciphers) ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; client_body_in_single_buffer on; # The directive is recommended when using the $request_body variable, to save the number of copy operations involved client_body_in_file_only off; #default client_max_body_size 32M; # based on tuning gzip on; location /log_endpoint { # Allow only POST requests for sending log data limit_except POST { deny all; } # Configure access_log to write incoming data to a file # access_log /var/log/nginx/log_receiver.log custom_log_format_1; access_log syslog:server=127.0.0.1:514,facility=local7,tag=nginx,severity=info custom_log_format_1; proxy_pass http://localhost:8091/; # This dummy Internal server required to collect request_body variable. } } # dummy internal server to respond back 200 ok server { listen 8091; server_name localhost; location / { return 200 "Log received successfully."; } } Set Up rsyslog server Install/configure rsyslog on your designated server. Configure 60-nginx.conf file in /etc/rsyslog.d/ directory Sample 60-nginx.conf file #nginx.* @@127.0.0.1:514 :syslogtag, isequal, "[nginx]" /var/log/nginx-syslog/nginx-access-log.log References: F5 Distributed Cloud Global log receiver supports many log receivers natively: F5 Distributed Cloud Technical Knowledge page on "Configure Global Log receiver" Prerequisites: An external log collection system reachable publicly. The following IP address ranges are required to be added to your firewall's allowlist: 193.16.236.64/29 185.160.8.152/29Service Extensions with SSL Orchestrator: Advanced Blocking Pages
Introduction Service Extensions are a new programmable capability in F5 BIG-IP SSL Orchestrator (as of F5 BIG-IP 17.0) that allow for customizable behaviors on decrypted HTTP traffic directly from within the Service Chain. In this article you will learn how to download, install, and configure the policy that enables the “Advanced Blocking Pages” Service Extension. Demo Video What are Advanced Blocking Pages? Advanced Blocking Pages allow for easy customization of the block page as well as flexible policy options to trigger specific block pages. This Service Extension creates a Service that will return a block page when placed into a Service Chain. It can also apply the iRule logic to dynamically inject the contents of a blocking page. Deployment Prerequisites F5 BIG-IP version 17.1.x SSL Orchestrator version 11.1+ This article assumes you have an SSL Orchestrator configured with a Topology and Service Chain. Advanced Blocking Pages Service Extension Installation The information below is from the GitHub repository for the Advanced Blocking Pages Service Extension (click here for a direct link). It includes an installer to create all the necessary objects. Download the installer: curl -sk https://raw.githubusercontent.com/f5devcentral/sslo-service-extensions/refs/heads/main/advanced-blocking-pages/advanced-blocking-pages-installer.sh -o advanced-blocking-pages-installer.sh CLI output: Make the script executable: chmod +x advanced-blocking-pages-installer.sh CLI output: Export the BIG-IP username and password: export BIGUSER='admin:password' CLI output: Note: replace “password” with your actual BIG-IP admin password Run the script to create all the SaaS Tenant Isolation objects: ./advanced-blocking-pages-installer.sh CLI output: The installer creates a new Inspection Service named "ssloS_F5_Advanced-Blocking-Pages". Add this Inspection Service to any Service Chain that can receive decrypted HTTP traffic. Service Extension Services will only trigger on decrypted HTTP, so can be inserted into Service Chains that may also see TLS bypass traffic (not decrypted). SSL Orchestrator will simply bypass this Service for anything that is not decrypted HTTP. After following the steps above, the SSL Orchestrator screen should look like this: Customizing Functionality To customize the functionality of the Blocking Pages we’ll start by editing an iRule. Navigate to Local Traffic > iRules > iRule List Click on the iRule named “advanced-blocking-pages-rule” (you may need to expand the iRule List) To enable the Advanced Blocking Pages, set the value for “GLOBAL_BLOCK” from 0 to 1. Click Update. NOTE: We’ll go over the other customization options later in this article. Move the Advanced-Blocking-Pages Service to a Service Chain Go to the SSL Orchestrator Configuration screen Click Service Chains then Add NOTE: For testing purposes, it is recommended to create a new Service Chain and add the Advanced-Blocking-Page Service to it Give it a name, “AdvancedBlocking” in this example. Select the ssloS_F5_Advanced-Blocking-Pages Service and click the arrow to move it to the right Click Deploy Click OK Edit the Security Policy From the Configuration screen, select Security Policies then click the policy you want to edit, “L3_Outbound” in this example. Click Add to add a Rule Give the Rule a name, “BlockThreats” in this example Configure the Rule Conditions by selecting Category Lookup (All) Select the Categories you wish to Block by clicking in the “Click to select” field Select all Malware-related categories These are all the Malware-related categories: Advanced Malware Command and Control Advanced Malware Payloads Malicious Embedded Link Malicious Embedded iFrame Malicious Web Sites Mobile Malware You may want to consider adding the following Categories, too: Spyware and Adware Suspicious NOTE: For testing purposes, it would be safer to add a category like “Alcohol and Tobacco” to the above rule in order to test its efficacy. Set the Action to Allow (this is counterintuitive) Set the SSL Proxy Action to Intercept Set the Service Chain to the one created previously, “AdvancedBlocking” Click OK The Security Policy should look like this: Click Deploy Click Deploy Click OK Test the Advanced Blocking Page Assuming you have added the “Alcohol and Tobacco” Category to the Security Policy, go to a client computer and test it now. An attempt to view the Products page on www.marlboro.com results in the following: Note: remember to remove the “Alcohol and Tobacco” category from the Security Policy. Customizing the Blocking Page First, you need an html file to use as the custom Blocking Page. You can use a sample file from the GitHub repository. Expand the folder “blocking-page-samples” and click “blocking-page-sample1.html”. Click the Download button on the right. To Customize the Blocking Page, go to System > File Management > iFile List > Import Choose the Blocking Page sample file in your Downloads folder. Choose Overwrite Existing, then click Import. Test the Blocking Page again and it should look like the following: Injecting Dynamic Messages To inject a dynamic message in the block page, edit the “advanced-blocking-pages-rule” iRule. Find “set static::GLOBAL_BLOCK_MESSAGE” in the iRule and replace all the text within the quotation marks: Click Update when done Test the Blocking Page again and it should look like the following: Handling Server-Side Certificate Errors SSL Orchestrator can also be customized to handle different server-side certificate validation errors. To configure this, start by editing the SSL Configuration. Click the Edit icon Click Show Advanced Settings Near the bottom, set Expire Certificate Response and Untrusted Certificate Authority from Drop to Mask. Click Save & Next when done. The Mask option tells SSL Orchestrator to send a good/valid certificate to the client when these certificate errors occur. This allows a custom blocking page to be presented to the client. Click OK Click Deploy Click OK Next, edit the Interception Rule for this Topology Click the Edit icon In the Resources section near the bottom, move the “ssl-tls-verify-rule” from Available to Selected. Click Save & Next Click Deploy Click OK NOTE: The blocking page iRule (when GLOBAL_BLOCK is 0) will read this context array variable and trigger the blocking page if the certificate verification code is not ‘ok’. It also injects the verification code string into the page. You can test this using the site, https://badssl.com Under Certificate, try “expired” and “self-signed” Example of Expired Certificate: Example of Self-Signed Certificate: Handling Custom Blocking Page Triggers The included iRule is intentionally sparse to include the two primary blocking page use cases (global blocking and server-side certificate validation errors): when HTTP_REQUEST { if { $static::GLOBAL_BLOCK } { call GEN_BLOCK_PAGE ${static::GLOBAL_BLOCK_MESSAGE} event disable all } else { sharedvar ctx if { ( [info exists ctx(tlsverify)] ) and ( $ctx(tlsverify) ne "ok" ) } { call GEN_BLOCK_PAGE "This request has been blocked due to a server side TLS issue: <br /></br>[string toupper $ctx(tlsverify)]" event disable all } } } To customize this for additional triggers, add iRule logic inside the “else” block as required: if { some-condition } { call GEN_BLOCK_PAGE "message to send into blocking page `receive_msg` variable" event disable all } Conclusion SSL Orchestrator Advanced Blocking Pages allow for easy customization of the block page as well as flexible policy options to trigger specific block pages. Related Content Service Extensions with SSL Orchestrator SaaS Tenant Isolation Service Extensions with SSL Orchestrator User Coaching of AI Related Content SSL Orchestrator Service Extensions: DoH Guardian Office 365 Tenant Restrictions Introduction to BIG-IP SSL Orchestrator Integrating Security Solutions with F5 BIG-IP SSL Orchestrator
Overview of MITRE ATT&CK Tactic - TA0010 Exfiltration
Introduction In current times of cyber vulnerabilities, data theft is the ultimate objective with which attackers monetize their presence within a victim network. Once valuable information is identified and collected, the attackers can package sensitive data, bypass perimeter defences, and finalize the breach. Exfiltration (MITRE ATT&CK Tactic TA0010) represents a critical stage of the adversary lifecycle, where the adversaries focus on extracting data from the systems under their control. There are multiple ways to achieve this, either by using encryption and compression to avoid detection or utilizing the command-and-control channel to blend in with normal network traffic. To avoid this data loss, it is important for defenders to understand how data is transferred from any system in the network and the various transmission limits imposed to maintain stealth. This article walks through the most common Exfiltration techniques and how F5 solutions provide strong defense against them. T1020 - Automated Exfiltration To exfiltrate the data, adversaries may use automated processing after gathering the sensitive data during collection. T1020.001 – Traffic Duplication Traffic mirroring is a native feature for some devices for traffic analysis, which can be used by adversaries to automate data exfiltration. T1030 – Data Transfer Size Limits Exfiltration of the data in limited-size packets instead of whole files to avoid network data transfer threshold alerts. T1048 – Exfiltration over Alternative Protocol Stealing of data over a different protocol or channel other than the command-and-control channel created by the adversary. T1048.001 – Exfiltration Over Symmetric Encrypted Non-C2 Protocol Symmetric Encryption uses shared or the same keys/secrets on all the channels, which requires an exchange of the value used to encrypt and decrypt the data. This symmetric encryption leads to the implementation of Symmetric Cryptographic Algorithms, like RC4, AES, baked into the protocols, resulting in multiple layers of encryption. T1048.002 – Exfiltration Over Asymmetric Encrypted Non-C2 Protocol Asymmetric encryption algorithms or public-key cryptography require a pair of cryptographic keys that can encrypt/decrypt data from the corresponding keys on each end of the channel. T1048.003 – Exfiltration Over Unencrypted Non-C2 Protocol Instead of encryption, adversaries may obfuscate the routine channel without encryption within network protocols either by custom or publicly available encoding/compression algorithms (base64, hex-code) and embedding the data. T1041 – Exfiltration Over C2 Channel Adversaries can also steal the data over command-and-control channels and encode the data into normal communications. T1011 – Exfiltration Over Other Network Medium Exfiltration can also occur through a wired Internet connection, for example, a WiFi connection, modem, cellular data connection or Bluetooth. T1011.001 – Exfiltration Over Bluetooth Bluetooth can also be used to exfiltrate the data instead of a command-and-control channel in case the command-and-control channel is a wired Internet connection. T1052 – Exfiltration Over Physical Medium Under circumstances, such as an air-gapped network compromise, exfiltration occurs through a physical medium. Adversaries can exfiltrate data using a physical medium, for example, say a removable drive. Some examples of such media include external hard drives, USB drives, cellular phones, or MP3 players. T1052.001 – Exfiltration Over USB One such circumstance is where the adversary may attempt to exfiltrate data over a USB connected physical device, which can be used as the final exfiltration point or to hop between other disconnected systems. T1567 – Exfiltration Over Web Services Adversaries may use legitimate external Web Service to exfiltrate the data instead of their command-and-control channel. T1567.001 – Exfiltration to Code Repository To exfiltrate the data to a code repository, rather than adversary’s command-and-control channel. These code repositories are accessible via an API over HTTPS. T1567.002 – Exfiltration to Cloud Storage To exfiltrate the data to a cloud storage, rather than their primary command-and-control channel. These cloud storage services allow storage, editing and retrieval of the exfiltrated data. T1567.003 – Exfiltration to Text Storage Sites To exfiltrate the data to a text storage site, rather than their primary command-and-control. These text storage sites, like pastebin[.]com, are used by developers to share code. T1567.004 – Exfiltration Over Webhook Adversaries also exfiltrate the data to a webhook endpoint, which are simple mechanisms for allowing a server to push data over HTTP/S to a client. The creation of webhooks is supported by many public services, such as Discord and Slack, that can be used by other services, like GitHub, Jira, or Trello. T1029 – Scheduled Transfer To exfiltrate the data, the adversaries may schedule data exfiltration only at certain times of the day or at certain intervals, blending the traffic patterns with general activity. T1537 – Transfer Data to Cloud Account Many a times, exfiltration of data can also be through transferring the data through sharing/syncing and creating backups of cloud environment to another cloud account under adversary control on the same service. How F5 Can Help F5 offers a comprehensive suite of security solutions designed to safeguard applications and APIs across diverse environments, including cloud, edge, on-premises, and hybrid platforms. These solutions enable robust risk management to effectively mitigate and protect against MITRE ATT&CK Exfiltration threats, delivering advanced functionalities such as: Web Application Firewall (WAF): Available across all F5 products, the WAF is a flexible, multi-layered security solution that protects web applications from a wide range of threats. It delivers consistent defense, whether applications are deployed on-premises, in the cloud, or in hybrid environments. HTTPS Encryption: F5 provides robust HTTPS encryption to secure sensitive data in transit, ensuring protected communication between users and applications by preventing unauthorized access or data interception. Protecting sensitive data with Data Guard: F5's WAF Data Guard feature prevents sensitive data leakage by detecting and blocking exposure of confidential information, such as credit card numbers and PII. It uses predefined patterns and customizable policies to identify transmissions of sensitive data in application responses or inputs. This proactive mechanism secures applications against data theft and ensures compliance with regulatory standards. For more information, please contact your local F5 sales team. Conclusion Adversaries Exfiltration of data often aims to steal sensitive information by packaging it to evade detection, using methods such as compression or encryption. They may transfer the data through command-and-control channels or alternate paths while applying stealth techniques like transmission size limitations. To defend against these threats, F5 provides a layered approach with its advanced offerings. The Web Application Firewall (WAF) identifies and neutralizes malicious traffic aimed at exploiting application vulnerabilities. HTTPS encryption ensures secure data transmission, preventing unauthorized interception during the attack. Meanwhile, a data guard policy set helps detect and block exposure of confidential information, such as credit card numbers and PII. Together, these F5 solutions effectively counteract data exfiltration attempts and safeguard critical assets. Reference links MITRE | ATT&CK Tactic 10 – Exfiltration MITRE ATT&CK: What It Is, how it Works, Who Uses It and Why | F5 Labs MITRE ATT&CK®The End of ClientAuth EKU…Oh Mercy…What to do?
If you’ve spent any time recently monitoring the cryptography and/or public key infrastructure (PKI) spaces…beyond that ever-present “post-quantum” thing, you may have read that starting in May of 2026, Google Chrome Root Program Policy will start requiring public certificate authorities (CAs) to stop issuing certificates with the Client Authentication Extended Key Usage (ClientAuth EKU) extension. While removing ClientAuth EKU from TLS server certificates correctly reduces the scope of these certificates, some internal client certificate authenticated TLS machine-to-machine and API workloads could fail when new/renewed certificates are received from a public CA. Read more here for details and options.What's new in BIG-IP v21.0?
Introduction In November of 2025 F5 released the latest version of BIG-IP software, v21.0. This release is packed with fixes and new features that enhance the F5 Application Delivery and Security Platform (ADSP). These changes complement the Delivery, Security and Deployment aspects of the ADSP. New SSL Orchestrator Features SNI Preservation SNI (Server Name Indication) Preservation is now supported for Inbound Gateway Mode. This preserves the client’s original SNI information as traffic passes through the reverse proxy, allowing backend TLS servers to access and use this information. This enables accurate application routing and supports security workflows like threat detection and compliance enforcement. Previous software versions required custom iRules to enable this functionality. Note: SNI preservation is enabled by default. However, if you have existing Inbound Gateway Topologies, you must redeploy them for the change to take effect. iRule Control for Service Entry and Return Previously, iRules were only available on the entry (ingress) side, limiting customization to traffic entering the Inspection Service. iRule control is now extended to the return-side traffic of Inspection Services. You can now apply iRules on both sides of an Inspection Service (L2, L3, HTTP). This enhancement provides full control over traffic entering and leaving the Inspection Service, enabling more flexible, powerful, and fine-grained traffic handling. The Services page will now include configuration for iRules on service entry and iRules on service return. A typical use-case for this feature is what we call Header Enrichment. In this case, iRules are used to add headers to the payload before sending it to the Inspection Service. The headers could contain the authenticated username/group membership of the person who initiated the connection. This information can be useful for Inspection Services for either logging, policy enforcement, or both. The benefit of this feature is that the authenticated username/group membership header can be removed from the payload on egress, preventing it from being leaked to origin servers. New Access Policy Manager (APM) Features Expanded Exclusion Support for Locked Client Mode Previously, APM-locked client mode allowed a maximum of 10 exclusions, preventing administrators from adding more than 10 destinations. This limitation has now been removed, and the exclusion list can contain more than 10 entries. OAuth Authorization Server Max Claims Data Support The max claim data size is set to 8kb by default, but a large claim size can lead to excessive memory consumption. You must allocate the right amount of memory dynamically as required based on claims configuration. New Features in BIG-IP v21.0.0 Control Plane Performance and Scalability Improvements The BIG-IP 21.0.0 release introduces significant improvements to the BIG-IP control plane, including better scalability and support for large-scale configurations (up to 1 million objects). This includes MCPD efficiency enhancements and eXtremeDB scale improvements. AI Data Delivery Optimize performance and simplify configuration with new S3 data storage integrations. Use cases include secure ingestion for fine-tuning and batch inference, high-throughput retrieval for RAG and embeddings generation, policy-driven model artifact distribution with observability, and controlled egress with consistent security and compliance. F5 BIG-IP optimizes and secures S3 data ingress and egress for AI workloads. Model Context Protocol (MCP) support for AI traffic Accelerate and scale AI workloads with support for MCP that enables seamless communication between AI models, applications, and data sources. This enhances performance, secures connections, and streamlines deployment for AI workloads. F5 BIG-IP optimizes and secures S3 data ingress and egress for AI workloads. Migrating BIG-IP from Entrust to Alternative Certificate Authorities Entrust is soon to be delisted as a certificate authority by many major browsers. Following a variety of compliance failures with industry standards in recent years, browsers like Google Chrome and Mozilla made their distrust for Entrust certificates public last year. As such, Entrust certificates issued on or after November 12, 2024, are deemed insecure by most browsers. Conclusion Upgrade your BIG-IP to version 21.0 today to take advantage of these fixes and new features that enhance the F5 Application Delivery and Security Platform (ADSP). These changes complement the Delivery, Security and Deployment aspects of the ADSP. Related Content SSL Orchestrator Release Notes BIG-IP Release Notes BLOG F5 BIG-IP v21.0: Control plane, AI data delivery and security enhancements Press Release F5 launches BIG-IP v21.0 Introduction to BIG-IP SSL OrchestratorDistributed Cloud for App Delivery & Security for Hybrid Environments
As enterprises modernize and expand their digital services, they increasingly deploy multiple instances of the same applications across diverse infrastructure environments—such as VMware, OpenShift, and Nutanix—to support distributed teams, regional data sovereignty, redundancy, or environment-specific compliance needs. These application instances often integrate into service chains that span across clouds and data centers, introducing both scale and operational complexity. F5 Distributed Cloud provides a unified solution for secure, consistent application delivery and security across hybrid and multi-cloud environments. It enables organizations to add workloads seamlessly—whether for scaling, redundancy, or localization—without sacrificing visibility, security, or performance.BIG-IP for Scalable App Delivery & Security in Hybrid Environments
Scope: As enterprises deploy multiple instances of the same applications across diverse infrastructure platforms such as VMware, OpenShift, Nutanix, and public cloud environments and across geographically distributed locations to support redundancy and facilitate seamless migration, they face increasing challenges in ensuring consistent performance, centralized security, and operational visibility. The complexity of managing distributed application traffic, enforcing uniform security policies, and maintaining high availability across hybrid environments introduces significant operational overhead and risk, hindering agility and scalability. F5 BIG-IP Application Delivery and Security address this challenge by providing a unified, policy-driven approach to manage secure workloads across hybrid multi-cloud environments. It can be used to scale up application services on existing infrastructure or with new business models. Introduction: This article highlights how F5 BIG-IP deploys identical application workloads across multiple environments. This ensur high availability, seamless traffic management, and consistent performance. By supporting smooth workload transitions and zero-downtime deployments, F5 helps organizations maintain reliable, secure, and scalable applications. From a business perspective, it enhances operational agility, supports growing traffic demands, reduces risk during updates, and ultimately delivers a reliable, secure, and high-performance application experience that meets customer expectations and drives growth. This use case covers a typical enterprise setup with the following environments: VMware (On-Premises) Nutanix (On-Premises) Google Cloud Platform (GCP) Architecture: As illustrated in the diagram, when new application workloads are provisioned across environments such as AWS, GCP, VMware (on-prem), Nutanix (on-prem & VMware) BIG-IP ensures seamless integration with existing services. Platforms Supported Environments VMware On-Prem, GCP, Azure Nutanix On-Prem, AWS, Azure This article outlines the deployment in VMware platform. For deployment in other platforms like Nutanix and GCP, refer the detailed guide below. F5 Scalable Enterprise Workload Deployments Complete Guide Scalable Enterprise Workload Deployment Across Hybrid Environments Enterprise applications are deployed smoothly across multiple environments to address diverse customer needs. With F5’s advanced Application Delivery and Security features, organizations can ensure consistent performance, high availability, and robust protection across all deployment platforms. F5 provides a unified and secure application experience across cloud, on-premises, and virtualized environments. Workload Distribution Across Environments Workloads are distributed across the following environments: VMware: App A & App B OpenShift: App B Nutanix: App B & App C → VMware: Add App C → OpenShift: Add App A & App C → Nutanix: Add App A Applications being used: A → Juice Shop (Vulnerable web app for security testing) B → DVWA (Damn Vulnerable Web Application) C → Mutillidae Initial Infrastructure: & B, Nutanix: App B &C, GCP: App B. VMware: In the VMware on-premises environment, Applications A and B are deployed and connected to two separate load balancers. This forms the existing infrastructure. These applications are actively serving user traffic with delivery and security managed by BIG-IP. Web Application Firewall (WAF) is enabled, which will prevent any malicious threats. The corresponding logs can be found under BIG-IP > Security > Event Logs Note: This initial deployment infrastructure has also been implemented on Nutanix and GCP. For the full details, please consult the complete guide here Adding additional workloads: To demonstrate BIG-IP’s ability to support evolving enterprise demands, we will introduce new workloads across all environments. This will validate its seamless integration, consistent security enforcement, and support for continuous delivery across hybrid infrastructures. VMware: Let us add additional application-3 (mutillidae) to the VMware on-premises environment. Try to access the application through BIG-IP virtual server. Apply the WAF policy to the newly created virtual server, then verify the same by simulating malicious attacks. Nutanix: The use case described for VMware is equally applicable and supported when deploying BIG-IP on Nutanix Bare Metal as well as Nutanix on VMware. For demonstration purposes, the Nutanix Community Edition hypervisor is booted as a virtual machine within VMware. Inside this hypervisor, a new virtual machine is created and provisioned using the BIG-IP image downloaded from the F5 Downloads portal. Once the BIG-IP instance is online, an additional VM hosting the application workload is deployed. This application VM is then associated with a BIG-IP virtual server, ensuring that the application remains isolated and protected from direct external exposure. GCP (Google Cloud Platform): The use case discussed above for VMware is also applicable and supported when deploying BIG-IP on public cloud platforms such as Azure, AWS, and GCP. For demonstration purposes, GCP is selected as the cloud environment for deploying BIG-IP. Within the same project where the BIG-IP instance is provisioned, an additional virtual machine hosting application workloads is deployed and associated with the BIG-IP virtual server. This setup ensures that the application workloads remain protected behind BIG-IP, preventing direct external exposure. Key Resources: Please refer to the detailed guide below, which outlines the deployment of Nutanix on VMware and GCP, and demonstrates how BIG-IP delivers consistent security, traffic management, and application delivery across hybrid environments. F5 Scalable Enterprise Workload Deployments Complete Guide Conclusion: This demonstration clearly illustrates that BIG-IP’s Application Delivery and Security capabilities offer a robust, scalable, and consistent solution across both multi-cloud and on-premises environments. By deploying BIG-IP across diverse platforms, organizations can achieve uniform application security, while maintaining reliable connectivity, strong encryption, and comprehensive protection for both modern and legacy workloads. This unified approach allows businesses to seamlessly scale infrastructure and address evolving user demands without sacrificing performance, availability, or security. With BIG-IP, enterprises can confidently deliver applications with resilience and speed, while maintaining centralized control and policy enforcement across heterogeneous environments. Ultimately, BIG-IP empowers organizations to simplify operations, standardize security, and accelerate digital transformation across any environment. References: F5 Application Delivery and Security Platform BIG-IP Data Sheet F5 Hybrid Security Architectures: One WAF Engine, Total Flexibility Distributed Cloud (XC) Github Repo BIG-IP Github RepoDetection of Malicious Users using F5 Distributed Cloud WAAP – Part III
Introduction We have already discussed the advantages that the F5 Distributed cloud’s solution for malicious users’ brings to the table as well as how simple it is to configure and monitor those events using an interactive UI dashboard of F5 Distributed Cloud Console. Below are the links for parts 1 and 2 of this article: Detection of Malicious Users using F5 Distributed Cloud WAAP – Part I Detection of Malicious Users using F5 Distributed Cloud WAAP – Part II In this article, we will go over a few more test scenarios covering the detection and mitigation of malicious user events. Demonstration (using Multi Load Balancer ML config) Scenario 1: In this scenario, we will monitor and mitigate detected malicious users for forbidden access attempts. Step1: Enable malicious user detection using Multi Load Balancer ML config as mentioned in the document. Step2: Configure a policy that prevents users from accessing a specific path. From the Console homepage, click Web App & API Protection. Click Manage -> Service Policies -> Service Policies. Click 'Add service policy,' give it a name, and set the rules as needed. Here, we are prohibiting access to the path '/delete,' as illustrated in the screenshot below. As a result, users will be unable to access the endpoint "https://<domain>/delete". Go to Home -> Web App & API Protection -> Manage -> Load Balancers -> HTTP Load Balancers, and add the created service policy to the LB Step3: Configure app setting object to detect malicious user activity based on forbidden access requests Go to Home->WAAP->Manage->AI&ML->App Settings, click ‘Add App Setting’. Enter a name and go to ‘AppType’ Settings section. Click ‘Add item’. Click on the ‘App Type’ drop-down and select the app type configured in the LB while executing Step1. Click ‘Configure’ in ‘Malicious User Detection’, tune the settings as per your need. Here, we have set the threshold limit for forbidden access requests to 10, beyond which the system will flag the user as malicious. Apply and add the configurations and then click ‘Save and Exit’ to create the app settings object. Step4: Configure automatic mitigation for malicious users Go to your LB and click ‘Edit Configuration’ Scroll down to ‘Common Security Controls’ section Enable 'Malicious User Mitigation And Challenges'. Set the ‘Malicious User Mitigation Settings’ as ‘Default’. click Save & Exit. Step5: Generate requests (more than the configured threshold value in Step3) to forbidden path (https://<domain>/delete). Note: Here generating requests indicates attempts of an attacker to bypass 403 forbidden error response. For example, trying different HTTP request methods, manipulating endpoint by appending sequences to it like {%2e}, {%2f}, {%5c} or by applying some other technique manually or through script. Step6: Go to Home->Web App & API Protection->Overview->Dashboards->Security Dashboard, select your LB and switch to Malicious Users tab, monitor the activity. Note: You can also use manual configuration for mitigation if automatic mitigation is not applied by simply clicking on ‘Block User’ on the top right side and adding detected malicious user's IP address to the deny list. Scenario 2: In this scenario, we will set the configuration to detect malicious users based on requests from potentially High-Risk IPs and block them by configuring default automatic mitigation action. Step1: Enable malicious user detection using Multi Load Balancer ML config as mentioned in the document. Step2: In app settings object configuration, make sure 'IP Reputation' is enabled (follow points in Step3 from Scenario1). Apply, Save & Exit. Step3: Follow Step4 in Scenario 1 to enable default automatic malicious user mitigation action . Step4: Generate 20+ requests in a minute from Tor browser. At the end follow Step6 from Scenario1 to monitor the malicious user activity Note: Tor is a free and open-source software developed to hide its user’s identity and activities over the Internet and make them anonymous. Conclusion This brings us to the end of this article series. We have seen how F5 Distributed Cloud WAAP’s security solution for malicious users aids in the identification and mitigation of suspicious activities. Alert fatigue, long investigation times, missed attacks, and false positives are all common issues for security teams. However, by utilizing malicious user detection, security teams can effectively filter out noise and identify actual risks and threats without the need for manual intervention. Suspicious actions such as Forbidden access attempts, login failures, and so on create a timeline of events that suggests the possibility of malicious user activity. Users who exhibit such behavior can be blocked manually or automatically based on their threat levels, and exceptions can be made using allow lists.Detection of Malicious Users using F5 Distributed Cloud WAAP – Part I
Introduction As people embraced the Internet as a part of their daily lives, businesses all over the world discovered an easier way to reach a large customer base that is not restricted by geographical boundaries. While that is important, it has also provided an open platform for malicious users to look for potential security loopholes in order to break into the system and cause severe damages. As a result, safeguarding business applications from such malicious user events becomes extremely critical. F5 Distributed Cloud WAAP (Web App & API Protection) offers a solution for monitoring such security events as well as the means to mitigate them. In this series of articles, we will demonstrate enabling, configuring, monitoring, and mitigating malicious users using F5 Distributed Cloud console. Configuration There are two ways to enable malicious user detection: Using Single Load Balancer ML configuration. Using Multi Load Balancer ML configuration. Using Single Load Balancer ML Configuration: In this mechanism, detection is enabled as part of the load balancer configuration and is only applicable to the load balancer on which it is configured. Using Multi Load Balancer ML Configuration: In this mechanism, detection is enabled as part of the app type configuration and is valid for all LBs configured with the same app type label. In both of the mentioned ways, detection is dependent on the ML configuration derived from the app settings object, with the difference that in single load balancer ML config values are not configurable and are set to default, whereas in multi load balancer ML config values can be configured according to the need. Once malicious user events have been identified, the next stage is to prioritize mitigation. The following are two ways of mitigating detected malicious user events: Using Load Balancer Security Monitoring. Using Load Balancer Advanced Security Configuration. Using Load Balancer Security Monitoring This is a manual way of configuring mitigation in which malicious user IPs are added to the allow/deny list. Using Load Balancer Advanced Security Configuration This is an automatic way of enabling mitigation in which the platform will apply the corresponding configured mitigation action for the specific threat levels. The default identifier configured for addressing malicious user events is the client IP address but in the ever-evolving world of attacks spoofing identity is not a difficult task to perform and to uniquely identify a user we should have a set of other identification mechanisms, keeping that in mind F5 Distributed Cloud console also provides you with the option to configure other parameters of identification like cookie name, header name, query parameter, ASN, TLS Fingerprint and combination of IP-header name & IP-TLS Fingerprint. Follow the documentation for step-by-step configuration instructions Demonstration (Using Single Load Balancer ML Configuration) In this demonstration we will enable malicious user detection, configure a WAF policy with enforcement mode as monitoring, configure malicious user mitigation actions for medium and high threat levels and at the end monitor the XC logs for malicious user activity. Step1: Enable malicious user detection using Single Load Balancer ML config as mentioned in the document. Step2: Create an App Firewall policy. Select WAAP service from the home page then go to Manage->App Firewall and click on 'Add App Firewall'. Add name and customize the fields as needed, Save & Exit. Step3: Configure mitigation actions. Go to WAAP->Manage->Shared Objects->Malicious User Mitigation and click on Add Malicious User Mitigation. Add a name, set threat level and associated actions accordingly. Add Item, Save & Exit. Step4: Attach the WAF policy and add the malicious user mitigation settings to the LB. From the Console homepage, Go to Load Balancers->Manage->Load Balancers->HTTP Load Balancers, select ‘Manage Configuration’ as an ‘Action’ to your LB and click ‘Edit Configuration’. Scroll down to Web Application Firewall (WAF), enable it and set the waf policy created in Step 2, Save & Exit. Scroll down to 'Common Security Controls' enable 'Malicious User Mitigation And Challenges', set 'Malicious User Mitigation Settings' as ‘custom’ and add the mitigation rule created in Step 3, Apply the changes. (Note: Here we have provided the flexibility to configure custom malicious user mitigation setting. However, users can also select default, which is a recommended setting). Step5: Generate XSS attack (20+ requests in a minute) e.g., https://<domain>?a=<script> Step6: Monitor the malicious user activity. Go to WAAP -> Overview -> Dashboards->Security Dashboard, scroll down and select your LB. Select Malicious Users tab. On top of the above dashboard, F5 XC console also provides a seperate malicious users dashboard which shows a global view of potential malicious users interacting with the application load balancers in a specific namespace giving a better visibility and greater context about the malicious traffic and ease the process of tracking and mitigating possible attacks with quick assessment. Below are a few screenshots of the same. To view this dashboard navigate to Home -> Web App & API Protection -> Overview -> Threat Insights -> Malicious Users As you can see from the demonstration, even though the waf policy is set to monitoring mode, in the background, malicious user activity is continued to be tracked and the threat level kept increasing with the number of attacks being performed, and once the threat level reached ‘High’, configured mitigation action got triggered. (Note: Based on malicious user mitigation settings different threat levels will have different mitigation actions, for example: in default settings for low threat level, JavaScript Challenge will be applied, for medium threat level, Captcha Challenge will be applied and for high threat level, users will be temporarily blocked). In this scenario, Customers can block attackers in real-time with very low risk of False Positives, as actions are taken based on observed user behavior over time. Conclusion In this article, we discussed how to enable malicious user detection and mitigation and how you can block attackers with a very low risk of False Positives. In future articles, we will discuss other scenarios. So please stay tuned. For further information or to get started: F5 Distributed Cloud Platform (Link) F5 Distributed Cloud WAAP Services (Link)
