Service 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®Detection 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)Detection of Malicious Users using F5 Distributed Cloud WAAP – Part II
Introduction This is an extension of the already published article Detection of Malicious Users using F5 Distributed Cloud WAAP – Part I an introductory article which highlights the configurations available for detecting and mitigating malicious user activity and includes a demonstration focused on detecting and mitigating malicious clients based on WAF security events. In part II of this series of articles, we will demonstrate a few more scenarios covering insights of malicious user detection and mitigation feature of F5 Distributed Cloud platform. Demonstration (Using Multi Load Balancer ML Configuration) In this demonstration, we will set the threshold limit for failed login attempts in the app settings configuration to mark any subsequent requests as a malicious user event and apply mitigation rules to restrict access, as well as we will detect the clients based on various user identifier types provided by the F5 Distributed cloud console. Step1: Enable malicious user detection using Multi Load Balancer ML config as mentioned in the document. Step2: Add malicious user mitigation rule to the LB In ‘Common Security Controls’, enable ‘Malicious User Mitigation And Challenges’, set 'Malicious User Mitigation Settings' as ‘Custom’, if the rule is already created select and apply the custom mitigation rule, Save & Exit or click on 'Add Item', add a name, set the rules (threat level and associated actions) accordingly, click continue, apply, Save & Exit. (Note: You can also configure the 'Default' malicious user mitigation settings, which has already defined mitigation rules and is a recommended setting). Step3: Go to Home->WAAP->Manage->AI&ML->App Settings, click ‘Add App Setting’. Step4: Enter a name and click on 'Add Item' to go to the ‘AppType’ settings section. Click ‘Add item’. Step5: Click on the ‘Select Item’ drop-down and select the app type configured in the LB while executing Step1. Step6: Click ‘Configure’ ‘Malicious User Detection’, tune the settings as per your need. For the demonstration purpose we are setting the threshold value for Failed Login Activity to 5. Step7: Apply and add the configurations and then click ‘Save and Exit’ to create the app settings object. Note: Identifying users uniquely on the Internet is a critical task because it aids in the creation of a perception by learning from the activities they perform on the application. Step8: Go to Home->WAAP->Manage->Shared Objects->User Identifications, click ‘Add User Identification’ Add a name, click ‘Configure’ on ‘User Identification Rules’, click ‘Add Item’ Set and apply the user identifier type and add the created user identification policy to the LB. Step9: Generate requests more than the configured threshold limit for failed login attempts in your application; it should return response code as 401. Available User Identifier Types: By default, the user identifier type is set to ‘Client IP Address’. As in the previous article, we have already seen IP address as a client identifier. In this demo, we will set other options available, follow the steps mentioned above to generate failed login events and verify that the users are getting detected based on the configured user identification policy. Below are the screenshots for configured user identification rules and UI dashboards displaying the results of associated configurations: Query Parameter Key HTTP Header Name Cookie Name Client Autonomous System TLS Fingerprint Client IP and HTTP Header Name Client IP and TLS Fingerprint Conclusion In this article, we demonstrated how simple it is to configure your LB to respond to multiple unauthorised access attempts by detecting them using various client identification type options and mitigating them automatically at the same time with a very low risk of false positives. For further information or to get started F5 Distributed Cloud Platform (Link) F5 Distributed Cloud WAAP Services (Link)F5 BIG-IP SSL Orchestrator and ReversingLabs Integration Guide
Introduction F5 BIG-IP SSL Orchestrator centralizes & manages decryption of SSL/TLS traffic. This enables security and monitoring tools to view the decrypted content and analyze it for threats and other anomalies. SSL Orchestrator removes the burden of decrypting content from your security tools, so they perform better and are more scalable. An integrated F5 and ReversingLabs Spectra Detect ICAP Server solution provides an enterprise-class malware detection and analysis platform while eliminating the blind spots introduced by SSL/TLS-encrypted content as follows: Delivers unmatched speed and scalability Broad Threat and file coverage Industry-leading object size unpacking and analysis Flexible deployment using AMI, OVA, or Kubernetes End-to-End Yara Rule Workflow Seamless secure sandbox connection to Spectra Analyze Deep Cloud Analysis and enrichment reports ReversingLabs Spectra Detect ICAP Server provides comprehensive, enterprise-wide visibility into malicious files and objects, enabling the identification of threats wherever they reside. High-volume, high-speed file unpacking, inspection, and definitive threat classification empower security operations teams with real-time, context-rich intelligence to drive faster and more effective threat detection and response, along with more powerful and precise hunting, so that dangerous malware can no longer hide and dwell within the organization. Demo Video Deployment Prerequisites This guide was tested with the following software versions: F5 BIG-IP version 17.5 SSL Orchestrator version 12.1.5 ReversingLabs Spectra Detect version 5.5.1-24 ReversingLabs Hub version 5.5.1 ReversingLabs Worker version 5.5.1 This article assumes you have SSL Orchestrator configured with a Topology and Service Chain. ReversingLabs Configuration The Spectra Detect Manager, Worker and Hub nodes should be deployed and working. The Hub and Worker need to be members of the same Configuration Group. The Dashboard should look like the following: NOTE: Proceed to the section on “Add the Connector” if the Worker and Hub are already in the same Configuration Group. If they are not in the same Configuration Group you can resolve this from the Central Configuration screen by clicking Add New Group. Give it a name, Hub-Group in this example. Set the Group Type to Hub Group by clicking the down arrow on the right. Set the Primary Host by clicking the down arrow on the right. Enter 1 for the Router ID. Click Add at the bottom Click Confirm Set the Configuration Group to Hub Group Under Appliances select All then Save Click Save and Apply The Hub and the Worker should now be visible Add the ICAP Connector Go back to the Dashboard Click on the Hub appliance On the right select Actions then Connectors Select ICAP Server on the left and then click Enable Connector Optionally configure Max File Size and other settings on this page Specify the REQMOD Block Page URL NOTE: Replace 172.16.60 202 with the IP address of your Spectra Detect Manager Disable the Use TLS option. The port should default to 1344 Click Start Connector Click Yes Back on the Dashboard click the green arrow next to Integrations It should look like the following: NOTE: you can come back later and configure the ICAP Server TLS option SSL Orchestrator Configuration From the SSL Orchestrator Configuration screen select the Services tab then click Add Select the ICAP tab then double click on the Generic ICAP Service Give it a name, RL_SpectraDetect in this example Click the Add button for ICAP Devices Enter the IP address of your ReversingLabs Hub, 172.16.60.201 in this example Click Done Set the Request and Response Modification URI to “spectraconnector” Scroll down then click Save & Next From the Services Chain List screen click on the name of your Service Chain, ServiceChain1 in this example Select the RL_SpectraDetect Service and click the right arrow to move it to the right. It should look like the following Click Save Click OK Click Save & Next Click Deploy Click OK Afterwards it should look like this: Test the Solution Access the internet from a client computer that connects through BIG-IP SSL Orchestrator. Note that the connection to www.f5.com is secure and the certificate has been verified by f5labs.com instead of Entrust, Inc. This indicates that SSL Orchestrator is decrypting and encrypting the connection. Next I will connect to the eicar.org web site which hosts a test virus. I’ll attempt to download the EICAR.TXT file. The test virus is successfully blocked by ReversingLabs! The Analytics Dashboard on the Spectra Detect Manager shows more details about the files processed. Conclusion F5 BIG-IP SSL Orchestrator is a great solution for managing encrypted traffic. Traffic can be selectively steered to one or more security solutions to check for threats. ReversingLabs Spectra Detect works in tandem with SSO Orchestrator to protect Enterprise networks from malicious threats. Related Content Introduction to BIG-IP SSL Orchestrator Integrating Security Solutions with F5 BIG-IP SSL Orchestrator F5 BIG-IP Zero Trust with BIG-IP SSL Orchestrator
BIG-IP Next Edge Firewall CNF for Edge workloads
Introduction The CNF architecture aligns with cloud-native principles by enabling horizontal scaling, ensuring that applications can expand seamlessly without compromising performance. It preserves the deterministic reliability essential for telecom environments, balancing scalability with the stringent demands of real-time processing. More background information about what value CNF brings to the environment, https://community.f5.com/kb/technicalarticles/from-virtual-to-cloud-native-infrastructure-evolution/342364 Telecom service providers make use of CNFs for performance optimization, Enable efficient and secure processing of N6-LAN traffic at the edge to meet the stringent requirements of 5G networks. Optimize AI-RAN deployments with dynamic scaling and enhanced security, ensuring that AI workloads are processed efficiently and securely at the edge, improving overall network performance. Deploy advanced AI applications at the edge with the confidence of carrier-grade security and traffic management, ensuring real-time processing and analytics for a variety of edge use cases. CNF Firewall Implementation Overview Let’s start with understanding how different CRs are enabled within a CNF implementation this allows CNF to achieve more optimized performance, Capex and Opex. The traditional way of inserting services to the Kubernetes is as below, Moving to a consolidated Dataplane approach saved 60% of the Kubernetes environment’s performance The F5BigFwPolicy Custom Resource (CR) applies industry-standard firewall rules to the Traffic Management Microkernel (TMM), ensuring that only connections initiated by trusted clients will be accepted. When a new F5BigFwPolicy CR configuration is applied, the firewall rules are first sent to the Application Firewall Management (AFM) Pod, where they are compiled into Binary Large Objects (BLOBs) to enhance processing performance. Once the firewall BLOB is compiled, it is sent to the TMM Proxy Pod, which begins inspecting and filtering network packets based on the defined rules. Enabling AFM within BIG-IP Controller Let’s explore how we can enable and configure CNF Firewall. Below is an overview of the steps needed to set up the environment up until the CNF CRs installations [Enabling the AFM] Enabling AFM CR within BIG-IP Controller definition global: afm: enabled: true pccd: enabled: true f5-afm: enabled: true cert-orchestrator: enabled: true afm: pccd: enabled: true image: repository: "local.registry.com" [Configuration] Example for Firewall policy settings apiVersion: "k8s.f5net.com/v1" kind: F5BigFwPolicy metadata: name: "cnf-fw-policy" namespace: "cnf-gateway" spec: rule: - name: allow-10-20-http action: "accept" logging: true servicePolicy: "service-policy1" ipProtocol: tcp source: addresses: - "2002::10:20:0:0/96" zones: - "zone1" - "zone2" destination: ports: - "80" zones: - "zone3" - "zone4" - name: allow-10-30-ftp action: "accept" logging: true ipProtocol: tcp source: addresses: - "2002::10:30:0:0/96" zones: - "zone1" - "zone2" destination: ports: - "20" - "21" zones: - "zone3" - "zone4" - name: allow-us-traffic action: "accept" logging: true source: geos: - "US:California" destination: geos: - "MX:Baja California" - "MX:Chihuahua" - name: drop-all action: "drop" logging: true ipProtocol: any source: addresses: - "::0/0" - "0.0.0.0/0" [Logging & Monitoring] CNF firewall settings allow not only local logging but also to use HSL logging to external logging destinations. apiVersion: "k8s.f5net.com/v1" kind: F5BigLogProfile metadata: name: "cnf-log-profile" namespace: "cnf-gateway" spec: name: "cnf-logs" firewall: enabled: true network: publisher: "cnf-hsl-pub" events: aclMatchAccept: true aclMatchDrop: true tcpEvents: true translationFields: true Verifying the CNF firewall settings can be done through the sidecar container kubectl exec -it deploy/f5-tmm -c debug -n cnf-gateway – bash tmctl -d blade fw_rule_stat context_type context_name ------------ ------------------------------------------ virtual cnf-gateway-cnf-fw-policy-SecureContext_vs rule_name micro_rules counter last_hit_time action ------------------------------------ ----------- ------- ------------- ------ allow-10-20-http-firewallpolicyrule 1 2 1638572860 2 allow-10-30-ftp-firewallpolicyrule 1 5 1638573270 2 Conclusion To conclude our article, we showed how CNFs with consolidated data planes help with optimizing CNF deployments. In this article we went through the overview of BIG-IP Next Edge Firewall CNF implementation, sample configuration and monitoring capabilities. More use cases to cover different use cases to be following. Related content F5BigFwPolicy BIG-IP Next Cloud-Native Network Functions (CNFs) CNF HomeLeverage F5 BIG-IP APM and Azure AD Conditional Access Easy button
Integrating F5 BIG-IP APM’s Identity Aware Proxy (IAP) with Microsoft EntraID (Previously called AzureAD) Conditional Access enables fine-grained, adaptable, zero trust access to any application, regardless of location and authentication method, with continuous monitoring and verification.
Zero Trust building blocks - Leverage Microsoft Intune endpoint Compliance with F5 BIG-IP APM Access
Use case summary Let's walk through a real life scenario, we have company A that's building its Zero Trust strategy and of course it will be great to make use of existing solutions to reach our target. Microsoft Intune introduces a great source of intelligence and compliance enforcement for endpoints, combined with F5 BIG-IP Access Policy Manager (APM) integrated with Microsoft EntraID (previously called AzureAD) this extends the enforcement to the endpoints accessing Company A resources whether it's a SAAS or locally hosted. Below is the flow of some use cases that leverage how F5 BIG-IP APM and Microsoft Intune pave the way to achieve Zero Trust strategy. We've an endpoint Managed by Microsoft Intune. Microsoft Intune contains device compliance policy to determine the conditions at which the machine to be considered compliant and the configuration profile determine the configurations for specific applications in our case (F5 Access VPN). We have the following use cases, User tries to access web application through F5 BIG-IP APM, BIG-IP is already integrated with Microsoft Intune and Microsoft EntraID (previously called AzureAD). F5 BIG-IP APM acts as SP, that directs user request to Microsoft EntraID (previously called AzureAD) for authentication and compliance check. If the user successfully authenticate and pass compliance policy, user will be redirected back to the application with SAML assertion response otherwise the user will be denied to acces. A demo was created by our awesome Access guru Matt_Dierick User tries to use SSL VPN to access corporate resources, User click on F5 Access VPN connection pushed to the endpoint via configuration profile at Microsoft Intune. User selects the proper authentication method (Username&Password, Smart Card or Certificate based Authentication). Once user successfully authenticate and pass compliance check, a temporary certificate is pushed to the machine. The temporary certificate is used to authenticate with F5 BIG-IP APM and then the user is granted access to SSL VPN connection. A demo was created for this use case as well by our awesome Access guru Matt_Dierick , as Microsoft Intune portal got updated, we may now perform the endpoint management related tasks through endpoint.microsoft.com portal instead of portal.azure.com, make sure to follow Microsoft documentations for any new updates. Conclusion In conclusion to the highlighted use cases, we can see that we can make use of existing solutions and extend their capabilities with the ease of integration to acheive our organization Zero Trust strategy. F5 BIG-IP in general allows the organization to decouple client side connection from server side, which simplifies further services integration to boost organization security posture. F5 BIG-IP APM allows us to integrate with different parties to extend their capabilties whether they endpoint compliance, risk factor or IDaaS to use such insights for securing application or network access. In addition to corporate related secure access, if we have customers accessing applications and need integration with Google or other Open ID Connect (OIDC) provider, you can make use of F5 BIG-IP APM OIDC integration to that 3rd party for customers' access. Additional resources Configuring Access Policy Manager for MDM applications BIG-IP Access Policy Manager: Third-Party Integration OAuth and OpenID Connect - Made easy with Access Guided Configurations templatesExtend visibility - BIG-IP joins forces with CrowdStrike
Introduction The traditional focus in cybersecurity has prioritized endpoints like laptops and mobiles with EDR, as they are key entry points for intrusions. Modern threats target the full network infrastructure, like routers, ADCs, firewalls, servers, VMs, and cloud instances, as interconnected endpoints. All network software is a potential target in today’s sprawling attack surface. Summarizing some of those blind points below, Servers, including hardware, VMs, and cloud instances: Often under-monitored, rapid spin-up creates ephemeral risks for exfiltration and lateral movement. Network appliances: Enable traffic redirection, data sniffing, or backdoors, if compromised. Application delivery components: Vulnerable to session hijacking, code injection, or DDoS, due to high-traffic processing. Falcon sensor integration In this section, we go through download and installation steps, and observe how the solution works with detecting/blocking malicious packages. For more information, follow our KB articles, https://my.f5.com/manage/s/article/K000157015 Related content K000157015: Getting Started with Falcon sensor for BIG-IP K000156881: Install Falcon sensor for BIG-IP on the BIG-IP system K000157014: F5 Support for Falcon for BIG-IP https://www.f5.com/partners/technology-alliances/crowdstrike
