F5 Distributed Cloud Bot Defense (Overview and Demo)
What is Distributed Cloud Bot Defense? Distributed Cloud Bot Defense protects your web properties from automated attacks by identifying and mitigating malicious bots. Bot Defense uses JavaScript and API calls to collect telemetry and mitigate malicious users within the context of the Distributed Cloud global network. Bot Defense can easily be integrated into existing applications in a number of ways. For applications already routing traffic through Distributed Cloud Mesh Service, Bot Defense is natively integrated into your Distributed Cloud Mesh HTTP load balancers. This integration allows you to configure the Bot Defense service through the HTTP load balancer's configuration in the Distributed Cloud Console. For other applications, connectors are available for several common insertion points that likely already exist in modern application architectures. Once Bot Defense is enabled and configured, you can view and filter traffic and transaction statistics on the Bot Defense dashboard in Distributed Cloud Console to see which users are malicious and how they’re being mitigated. F5 Distributed Cloud Bot Defense is an advanced add-on security feature included in the first launch of the F5 Web Application and API Protection (WAAP) service with seamless integration to protectyour web apps and APIs from a wide variety of attacks in real-time. High Level Distributed Cloud Security Architecture Bot Defense Demo: In this technical demonstration video we will walk through F5 Distributed Cloud Bot Defense, showing you how quick and easy it is to configure, the insights and visibility you have while demonstrating a couple of real attacks with Selenium and Python browser automation. "Nature is a mutable cloud, which is always and never the same." - Ralph Waldo Emerson We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts. Hope you enjoyed this Distributed Cloud Bot Defense Overview and Demo. If there are any comments or questions please feel free to reach us in the comments section. Thanks! Related Resources: Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) Protecting Your Web Applications Against Critical OWASP Automated Threats Making Mobile SDK Integration Ridiculously Easy with F5 XC Mobile SDK Integrator JavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo) Bots, Fraud, and the OWASP Automated Threats Project (Overview) Protecting Your Native Mobile Apps with F5 XC Mobile App Shield Enabling F5 Distributed Cloud Client-Side Defense in BIG-IP 17.1 Bot Defense for Mobile Apps in XC WAAP Part 1: The Bot Defense Mobile SDK F5 Distributed Cloud WAAP Distributed Cloud Services Overview Enable and Configure Bot Defense - F5 Distributed Cloud ServiceOWASP Automated Threats - CAPTCHA Defeat (OAT-009)
Introduction: In this OWASP Automated Threat Article we'll be highlighting OAT-009 CAPTCHA Defeat with some basic threat information as well as a recorded demo to dive into the concepts deeper. In our demo we'll show how CAPTCHA Defeat works with Automation Tools to allow attackers to accomplish their objectives despite the presence of CAPTCHA's intended purpose of preventing unwanted automation. We'll wrap it up by highlighting F5 Bot Defense to show how we solve this problem for our customers. CAPTCHA Defeat Description: Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) challenges are used to distinguish normal users from bots. Automation is used in an attempt to analyse and determine the answer to visual and/or aural CAPTCHA tests and related puzzles. Apart from conventional visual and aural CAPTCHA, puzzle solving mini games or arithmetical exercises are sometimes used. Some of these may include context-specific challenges. The process that determines the answer may utilise tools to perform optical character recognition, or matching against a prepared database of pre-generated images, or using other machine reading, or human farms. OWASP Automated Threat (OAT) Identity Number OAT-009 Threat Event Name CAPTCHA Defeat Summary Defining Characteristics Solve anti-automation tests. OAT-009 Attack Demographics: Sectors Targeted Parties Affected Data Commonly Misused Other Names and Examples Possible Symptoms Education Application Owners Authentication Credentials Breaking CAPTCHA High CAPTCHA solving success rate on fraudulent accounts Entertainment CAPTCHA breaker Suspiciously fast or fixed CAPTCHA solving times Financial CAPTCHA breaking Government CAPTCHA bypass Retail CAPTCHA decoding Social Networking CAPTCHA solver CAPTCHA solving Puzzle solving CAPTCHA Defeat Demo: In this demo we will be showing how it’s possible to leverage real human click farms via CAPTCHA solving services like 2CAPTCHA to bypass reCAPTCHA. We'll then have a look at the same attack with F5 Distributed Cloud Bot Defense protecting the application. In Conclusion: CAPTCHAs are only a speed bump for motivated attackers while introducing considerable friction for legitimate customers. Today, we’re at a point where bots solve CAPTCHAs more quickly and easily than most humans. Check out our additional resource links below to learn more. OWASP Links OWASP Automated Threats to Web Applications Home Page OWASP Automated Threats Identification Chart OWASP Automated Threats to Web Applications Handbook F5 Related Content Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) F5 Bot Defense Solutions F5 Labs "I Was a Human CATPCHA Solver" The OWASP Automated Threats Project How Attacks Evolve From Bots to Fraud Part: 1 How Attacks Evolve From Bots to Fraud Part: 2 F5 Distributed Cloud Bot Defense F5 Labs 2021 Credential Stuffing ReportJavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo)
JavaScript Supply Chain Attacks are on the Rise With a firewall, a WAF, bot defense, and a SIEM, you control and monitor web traffic entering the data center. Criminals have adapted their strategies to attack your customers in the browser. New web architectures involving dozens of third-party JavaScript files make this new attack surface even more vulnerable. Increasing Web Page Complexity Enterprises cannot keep track of all the scripts and changes that go on in their website and attackers are exploiting this lack of surveillance to introduce malicious code into the supply chain that their web page relies on. Most use 3rd party libraries (eg. Marketing Scripts) Most 3rd party libraries themeselves depend on another set of 3rd party libraries (eg. jQuery.js) Final page loads on end user's browser can easily contain scripts from 20-30 different organizations Magecart, Formjacking, and E-skimming These attacks occur when a threat actor injects one or many malicious scripts into a legitimate page or code repo to create a software supply chain man-in-the-browser attack (SC-MITB). The attacker can then run keyloggers and any other JavaScript based attacks on the end-users browser stealing any credit card data, username and password combinations etc... which will be sent to the attackers command and control server as pictured below. What is Distributed Cloud Client-Side Defense? F5® Distributed Cloud Client-Side Defense (CSD) provides a multi-phase protection system that protects web applications against Magecart-style and other malicious JavaScript attacks. This multi-phase protection system includes detection, alerting, and mitigation. Detection. A continuously evolving signal set allows CSD to understand when scripts on web pages exhibit signs of exfiltration. CSD detects network requests made by malicious scripts that attempt to exfiltrate PII data. Alerting. CSD generates timely alerts on the behavior of malicious scripts, provided by a continuously improving Analysis Engine. The Analysis Engine contains a machine learning component for accurate and informative analysis and provides details on the behavior of malicious script to help troubleshoot and identify the root cause. Mitigation. CSD detects threats in real-time and provides enforcement with one-click mitigation. CSD leverages the same obfuscation and signal technology as F5® Distributed Cloud Bot Defense, delivering unparalleled efficacy. High Level Distributed Cloud Client-Side Defense Architecture Client-Side Defense Demo: Learn about the risks of JavaScript supply-chain attacks (aka Magecart), the costs of Formjacking and PII Harvesting, and how to detect and mitigate this threat vector. Regain security control of your apps with F5’s Distributed Cloud Client-Side Defense. Related Resources Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) F5 Client-Side Defense Product Page Client-Side Defense DocumentationBots, Fraud, and the OWASP Automated Threats Project (Overview)
Introduction Many of us have heard of OWASP in the context of the OWASP Top 10. In this article series we will take a look at another very important threat classification list called the OWASP Automated Threats (OAT) Project and provide a foundational overview. The terms Malicious Bot and Automated Threat can be used interchangeably throughout. In future articles we'll dive deeper into individual key threats called OATs and demonstrate how these attacks work and how to defend against them. Why should we care about the OWASP Automated Threats Project? Web security is no longer constrained to inadvertent vulnerabilities and attackers are abusing inherent functionality to conduct Automated and Manual Fraud. Existing technologies are not capable of detecting advancedautomated abuse, fraud teams can’t keep up with new fraud mechanisms,while web users are increasingly adverse to encountering Authentication Friction created by legacy or traditional bot defenses like CAPTCHAs. From its original release in 2015, the OWASP Automated Threat Handbook has now become a de facto industry standard in classifying Bots and better understanding all aspects of Malicious Web Automation. What OATs Are Not - Not another vulnerability list - Not an OWASP Top N List - Not threat modelling - Not attack trees - Not non web - Not non application What Are OATs (aka Malicous Bots)? In order to quantify these threats, it is necessary to be able to name them. OAT stands for OWASP Automated Threat and there are currently 21 attack vectors defined. Currently OAT codes 001 to 021 are used. Within each OAT the Threat definition contains a description, the sectors targeted, parties affected, the data commonly misused, and external cross mappings to other lists like CAPEC Category, possible symptoms, suggested countermeasures, etc... Here is the Full List of OATs ordered by ascending name: Identifier OAT Name Summary Defining Characteristics OAT-020 Account Aggregation Use by an intermediary application that collects together multiple accounts and interacts on their behalf OAT-019 Account Creation Create multiple accounts for subsequent misuse OAT-003 Ad Fraud False clicks and fraudulent display of web-placed advertisements OAT-009 CAPTCHA Defeat Solve anti-automation tests OAT-010 Card Cracking Identify missing start/expiry dates and security codes for stolen payment card data by trying different values OAT-001 Carding Multiple payment authorisation attempts used to verify the validity of bulk stolen payment card data OAT-012 Cashing Out Buy goods or obtain cash utilising validated stolen payment card or other user account data OAT-007 Credential Cracking Identify valid login credentials by trying different values for usernames and/or passwords OAT-008 Credential Stuffing Mass log in attempts used to verify the validity of stolen username/password pairs OAT-021 Denial of Inventory Deplete goods or services stock without ever completing the purchase or committing to the transaction OAT-015 Denial of Service Target resources of the application and database servers, or individual user accounts, to achieve denial of service (DoS) OAT-006 Expediting Perform actions to hasten progress of usually slow, tedious or time-consuming actions OAT-004 Fingerprinting Elicit information about the supporting software and framework types and versions OAT-018 Footprinting Probe and explore application to identify its constituents and properties OAT-005 Scalping Obtain limited-availability and/or preferred goods/services by unfair methods OAT-011 Scraping Collect application content and/or other data for use elsewhere OAT-016 Skewing Repeated link clicks, page requests or form submissions intended to alter some metric OAT-013 Sniping Last minute bid or offer for goods or services OAT-017 Spamming Malicious or questionable information addition that appears in public or private content, databases or user messages OAT-002 Token Cracking Mass enumeration of coupon numbers, voucher codes, discount tokens, etc OAT-014 Vulnerability Scanning Crawl and fuzz application to identify weaknesses and possible vulnerabilities Automated Threats Breakdown By Industry Within each OAT definition there is a section for the Sectors Targeted for that particular attack vector. For example, a Carding Attack would be seen on ecommerce and retail type of sites with payment card processing. Here they would be able to validate a list of stolen credit card numbers to identify the working ones from non working. Example: OAT-001 Carding Attack example highlighting "Sectors Targeted" for this type of attack. This exists for each attack definition. OWASP Defined Countermeasures Countermeasure Classes: The technology and vendor agnostic countermeasure classes attempt to group together the types of design, development and operational controls identified from research that are being used to partially or fully mitigate the likelihood and/or impact of automated threats to web applications. In all applications, builder-defender collaboration is key in controlling and mitigating automated threats – the best protected applications do not rely solely upon standalone external operational protections, but also have integrated protection built into the design. Similarly to other types of application security threat, it is important to build consideration of automated threats into multiple phases of a secure software development lifecycle (S-SDLC). 14 Countermeasure Classes: Value Authentication Requirements Rate Testing Monitoring Capacity Instrumentation Obfuscation Contract Fingerprinting Response Reputation Sharing Countermeasure Controls Countermeasures are controls that attempt to mitigate the identified automated threats in three ways: Prevent - Controls to reduce the susceptibility to automated threats Detect - Controls to identify whether a user is an automated process rather than a human, and/or to identify if an automated attack is occurring, or occurred in the past Recover - Controls to assist response to incidents caused by automated threats, including to mitigate the impact of the attack, and to to assist return of the application to its normal state. Cross References Other Threat Mappings Each OAT Threat is cross referenced with other external threat lists to provide and understanding of how this OAT Handbook can be integrated with other works. Example, OAT Threat below shows the cross referenced CAPEC, CWE, and WASC Threat ID's You can find links to each of the external classification models below: Mitre CAPEC - best full and/or partial match CAPEC category IDs and/or attack pattern IDs WASC Threat Classification - best match to threat IDs Mitre Common Weakness Enumeration - closely related base, class & variant weakness IDs Matching pages defining terms classified as Attacks on the OWASP wiki Youtube Conclusion In conclusion, the OWASP Automated Threat Handbook has now become a de facto industry standard in classifying and better understanding all aspects of malicious web automation. We can use this handbook to build secure software development lifecycles around our web properties and implement the appropriate countermeasure to prevent unwanted automation against them. OWASP Links OWASP Automated Threats to Web Applications Home Page OWASP Automated Threats Identification Chart OWASP Automated Threats to Web Applications Handbook F5 Related Content Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) How Attacks Evolve From Bots to Fraud Part: 1 How Attacks Evolve From Bots to Fraud Part: 2 F5 Distributed Cloud Bot Defense F5 Labs 2021 Credential Stuffing Report
F5 Distributed Cloud Bot Defense Protecting AWS CloudFront Distributions
In this article, I will show you how to easily protect your AWS CloudFront distributions with F5 Distributed Cloud (XC) Bot Defense. We will take advantage of AWS Lambda@Edge and the AWS Serverless Application Repository (SAR) to integrate with the F5 XC Bot Defense API. Amazon CloudFront is a content delivery network (CDN) operated by Amazon Web Services. Content delivery networks provide a globally-distributed network of proxy servers that cache content, such as web videos or other bulky media, more locally to consumers, thus improving access speed for downloading the content. F5's Distributed Cloud Bot Defense combined with Amazon's CloudFront to protect your vital applications from malicious traffic is an effective and robust solution. General Overview of Architecture Create a new Bot Defense application for AWS CloudFront Log in to your F5 Distributed Cloud Console Go to the Dashboard page of XC console and click Bot Defense Verify you are in the correct Namespace. Click Add Application at the top-left of the page. Add a Name for the Application, and a Description. Select a region (US, EMEA, or APJC). For Connector Type, select AWS CloudFront. Once AWS CloudFront is selected, options appear to configure AWS reference details. Add AWS Reference Information Enter your AWS 12-digit Account Number. Specify your AWS Configuration and add your CloudFront distribution; a Distribution ID and/or a Distribution Tag. You can add one or more distributions. This information is needed to associate your newly created protected application to your AWS distribution(s). Add Protected Endpoints Click Configure to define your protected endpoints. Click Add Item Enter a name and a description to the specific endpoint. Specify the Domain Matcher. You can choose any domain or specify a specific host value. Specify the Path to the endpoint (such as /login). Choose the HTTP Methods for which request will be analyzed by Bot Defense. Multiple methods can be selected. Select the Client type that will access this endpoint (Web Client). Select the Mitigation action to be taken for this endpoint: Continue (request continues to origin) Redirect. Provide the appropriate Status Code and URI Block. Provide the Status Code, Content Type, and Response message When done configuring the endpoint, click Apply. To continue, click Apply at the bottom of the page. Define Continue Global Mitigation Action The Header Name for Continue Mitigation Action field is the header that is added to the request when the Continue mitigation action is selected and Add A Header was selected in the endpoint mitigation configuration screen. Define Web Client JavaScript Insertion Settings JS Location - Choose the location where to insert the JS in the code: Just After <head> tag. Just After </title> tag. Right Before <script> tag. Under Java Script Insertions. Select Configure. owing Javascript insertion menu Click Add Item Add the Web Client JavaScript Path. You should select paths to HTML pages that end users are likely to visit before they browse to any protected endpoint. Click Apply Click Save & Exit to save your protected application configuration. Download Config File and AWS Installer Tool In the Actions column of the table, click the 3 ellipses (…) on your application. Download both the Config File and the AWS Installer. Log in to your AWS Console Login to AWS Console home page. Select AWS Region Northern Virginia (US-EAST-1). Use the search to find Serverless Application Repository and click it Click Available Applications and search with "F5" Click the F5BotDefense tile This will take you to the Lambda page. Here you will be creating and deploying a Lambda Function Click Deploy to install the F5 Connector for CloudFront Deploying the F5 Connector creates a new Lambda Application in your AWS Account. AWS sets the name of the new Lambda Application to start with serverlessrepo-. The deployment can take some time. It is complete when you see the serverlessrepo-F5BotDefense-*of type Lambda Function. You can click on the nameto review contents of the installed Lambda Function. n details Switch to AWS CloudShell Configuration of the F5 Connector in AWS is best done via the F5 CLI tool. It is recommended to use the AWS CloudShell in us-east-1 region to avoid any issues. After starting AWS CloudShell, click Actions and Upload file. Upload the files you downloaded from the F5 XC Console, config.json and f5tool. (Only one file at a time can be uploaded) Run bash f5tool --install <config.json>. Installation can take up to 5 minutes. Note: Copy pasting the command may not work and so type it manually. The installation tool saves the previous configuration of each CloudFront Distribution in a file. You can use the F5 tool to restore a saved Distribution config (thus removing F5 Bot Defense). Note: Your F5 XC Bot Defense configuration, such as protected endpoints, is sensitive security info and is stored in AWS Secrets Manager. You should delete config.json after CLI installation. Validate CloudFront Distribution Functions Navigate to CloudFront > Distributions and select the distribution you are protecting. Then go to Behaviors Here under Behaviors are where you specify which request/response is forwarded to the Lambda@Edge Function to process with F5 XC Bot Defense. F5 XC Bot Defense requires us to leverage Viewer Request and Origin Request events. These events need to be available for user to use (IE they have not assigned other Functions) The AWS Installer tool that we downloaded from Distributed Cloud Console and ran in the AWS CloudShell configured this for us. AWS CloudWatch AWS CloudWatch contains logs for Lambda function deployed by F5BotDefense serverless application. The Log group name starts with /aws/lambda/us-east-1.serverlessrepo-F5BotDefense-F5BotDefense-*. The logs of lambda function can be found in the region closest to the location where the function executed. For troubleshooting, look for error messages contained in the links under Log steams. View Bot Traffic Now let’s return to F5 XC Console and show the monitoring page. Log in to your F5 Distributed Cloud Console Go to the Dashboard page of XC console and click Bot Defense. Make sure you are in the correct Namespace Under Overview click Monitor Here you can monitor and respond to events that are identified as Bot traffic. Conclusion That is all that is required to deploy F5 XC Bot Defense to protect your AWS Cloud Front distributions from mailicious bots protecting yourself from fraud and abuse. Related Articles: An overview of F5 Distributed Cloud Bot Defense How to easily protect your BIG-IP applications using F5's Distributed Cloud Bot Defense with iApps How to easily protect your BIG-IP applications using F5's Distributed Cloud Bot Defense, natively Related Video: Get Started: F5 Distributed Cloud Services F5 Distributed Cloud Bot Defense Brightboard Lesson
How to quickly protect your Cloudflare CDN with F5 Distributed Cloud Bot Defense
Introduction F5 Distributed Cloud (XC) Bot Defense can now be easily integrated into the Cloudflare CDN. The connector instantly integrates with XC Bot Defense to help customers improve their bottom line by eliminating automated bot traffic. XC Bot Defense has the highest long-term efficacy by combining machine learning with human domain experience to ensure sustained near-zero false positives. In this article, I will outline the steps to start and take advantage of F5 Bot Defense. Prerequisites: An Account on F5 Distributed Cloud Services. A Cloudflare CDN is delivering your applications. F5 Distributed Cloud Steps: Log In: Select the Bot Defense Tile Scroll down Selecting Manage > Applications Click Add Application Provide Name, Label and a Description Select the Application Region (US for my demo) Select the Connector Type - Cloudflare (Previous articles covered BIG-IP, CloudFront and Custom) Select Configureonce Cloudflare is selected as the Connector Type Select Configure under Protected Endpoints On the Protected Endpoints page click Add Item Give the Protected Endpoint a Name and Description Under Domain Matcher you have the option of Any Domain which will match all domains or you can specify the Domain you are protecting. I am using Any Domain Next indicate the Path you are protecting; Entry Points and/or Login pages as examples. Query Strings HTTP Methods - Depending on what you are protecting. (GET, POST, PUT) Select the Client Type (Web Client, Mobile Client or Web and Mobile) again depending on your application. Here I will Select Web Client Next you will select the Mitigation action. (Continue, Redirect or Block) - I am selecting Block Block gives you the ability to indicate Status, Content Type and the displayed Body. Click Apply This screen shows the Protected Endpoint now configured. Next we will Specify the Java Script Insertion Rules Click Configure The Web Client Java Script Path and name can be configured here. The Java Script Location is where the Java Script is inserted on your Web Application. Under Java Script Insertion Paths Click Add Item - We will specify where to insert the JS. You could also configure JS Exclude Paths. Give this a Name and Description Domain Matcher just as before, can be Any Domain or you can Specify a Domain. And finally, the Path (Prefix, Path or Glob) Supply the path to insert the JS. Click Apply We now have configured the Web Client JS settings. If we were configuring mobile application protection we would enable Mobile SDK Trusted Client Rules we could specify an IP Prefix and/or HTTP Headers. Click Apply Click Save and Exit This takes us back to our main Applications page. Click the three ellipsis to the right. Download both the Config file and Worker file to a known location. We will use these files in the Cloudflare UI. That is all the configuration needed in F5 Distributed Cloud Console. We will return to monitor our Application after configuring Cloudflare. Cloudflare Steps: Log In: Navigate down to Workers From this page, you would either select an existing Service if one existed or Create a Service. I am showing how to Create a Service. Click Create a Service Cloudeflare assigns a name. Select HTTP handler Then Create Service Click on your newly created Service Click Quick Edit Notice on the left the code would deploy a worker that returns "Hello World" But we need to assign the worker to a Website. Return to the main menu and select Websites. We have a Website already configured. Select the preconfigured Website. We could Add a Site if one was not already configured. This will take you to the Website Summary Page. Select Workers Routes on the Left Pane Then Click Add Route Cloudflare shows the Website Route but it is greyed out. Type the Route. Select the Service you created in the last steps. Select the Environment Click Save This will return you to the Workers Routes page. It will show the Service was added to the HTTP Routes. Next we need to test and verify the Worker is returning what we are expecting. Remember above, it should return "Hello World" Navigate in a browser to your website. In this case https://sales.xcbotsdemo.com/ You should get the following return. This shows our website and worker are working as expected. Now we will configure our Worker to protect the actual website with F5 Distributed Cloud Bot Defense. Navigate back to your Worker and Select Quick Edit. Here we will use the files we downloaded from F5 Distributed Cloud Console. The Worker file is the .js file you downloaded. The Config file is the .json file you downloaded Open both files in the editor of your choice Copy the entire contents of the Worker file and replace the contents in the left hand pane Copy the entire contents of the Config file and replace the contents in the left hand pane under XC Configuartion -- "_CONFIG_" Click Save and Deploy at the bottom. You will recieve a succesful message if the Worker depoys suceesfully. If not it returns an error. Now is the time to prove all the prior work. Navigate back to https://sales.xcbotsdemo.com/ If you have configured everything correcty, you should get your website to return as below. Now I genertated traffic via human browser clicks and then automated commmands that would mimic bot traffic. I show the results in the F5 Distributed Cloud Bot Defense Overview page. Technical Demo: Brightboard Video Conclusion: As you can see, F5 Distributed Cloud Bot Defense protected your Cloudflare hosted application from automated threats. It allowed normal human browsing but identified and mitigated actions you specified as malicious bots. Related Links: https://www.f5.com/cloud https://www.f5.com/cloud/products/bot-defenseAutomation of F5 Distributed Cloud Platform Client-Side Defense feature - Part I
Objective: The purpose of this article is to automate F5 Distributed Cloud Platform Client-Side Defense feature (F5 XC CSD) detection of malicious 3rd party domains and integrating code in GitHub. This article shows how we can use the Github available Actions workflow to provide the flexibility of updating existing infrastructure after every change using CI/CD event triggers. In this article we showed a small use case of CI/CD deployment using GitHub Actions, Terraform and Python developed in a generic way where users can bring up the complete setup within a few clicks. For more details about this feature please refer: https://community.f5.com/t5/technical-articles/javascript-supply-chains-magecart-and-f5-xc-client-side-defense/ta-p/296612 Overview: Client-Side Defense (CSD) feature provides a web application protection solution against Magecart style and similar malicious JavaScript attacks. This solution supports below features: Detection: A continuously evolving signal set allows CSD to understand when scripts on web pages exhibit signs of exfiltration. CSD detects network requests made by malicious scripts that attempt to exfiltrate PII data. Alerting: CSD generates timely alerts on the behavior of malicious scripts, provided by a continuously improving Analysis Engine. Mitigation: CSD detects threats in real-time and provides enforcement with one-click mitigation. Automation Design: As part of this automation, we are deploying a demo application in AWS and NGINX web service which hosts a simple web login page. The demo application has a malicious 3rd party Java script which captures the provided username and passwords during the login and sends these details to a malicious control server which keeps recording these credentials. Once the demo app is deployed, we are then configuring the origin pool and load balancer in F5 XC and generating web login traffic using Selenium script. Once traffic is logged in F5 XC platform, CSD feature will detect malicious domain network and will display domain in client-Side defense dashboard. After researching the 3rd party domain details customers can either approve or mitigate these network requests. Above workflow is integrated using GitHub Actions file which ensures dynamic deployment of the demo app and F5 XC load balancer which can be exposed using public domain name. Note: Currently this repo code covers automation till CSD malicious domain detection only and will cover mitigation part in the upcoming article of this series. Code is available here. Deployment steps: Security users can simply clone repo, update variables.tf as per their infra and run workflow which will bring entire infrastructure in few mins. They can login to the F5 XC console and explore the functionality of Client-Side Defense in an interactive way. Users can use this as a plugin to demonstrate CSD feature. Conclusion: This article demonstrated how we can leverage the power of CI/CD to create or upgrade our existing infrastructure and maintain the testing scope of Client Side Defense feature. For further information check the links below: F5 Distributed Cloud Platform (Link) F5 Distributed Cloud Client-Side Defense Overview (Link) F5 Distributed Cloud Client-Side Defense Docs (Link)Protect Your Adobe Commerce Site with F5 Distributed Cloud Services (Part 2)
In Part 1, I was able to show how to quickly and easily it is to configure Bot Defense to protect your Adobe Commerce site with F5 Distributed Cloud (F5 XC) Services. In this article, I will expand on that offering and show you how to configure both Account Protection and Authentication Intelligence, again leveraging F5 XC Services. As a refresher the following services are provided: Distributed Cloud Bot Defense blocks up to 99% of malicious bots and other automated attacksat the origin. Distributed Cloud Account Protection leverages a real-time, closed-loop AI fraud engine designed to predict and mitigaterisky or malicious transactions. Distributed Cloud Authentication Intelligence model’s good user behavior to ensure safe user journeys and reduces unnecessary friction (e.g., MFA, CAPTCHA). Note: This article assumes you have both a F5 Distributed Cloud Services account and an Adobe Commerce Account. Log in to the F5 Distributed Cloud Console. You will notice Account Protection and Authentication Intelligence as available solutions. In order to enable them you will click the respective tiles to enable for your tenant. This Screenshot shows the example welcome Screen for Authentication Intelligence. Here you can explore and find Datasheets, Whitepapers, Technical Documentation or Schedule a session with the Customer Success Team. Additionally, if you click “Learn How JS Injection Works” the fly out will tell you where to put you JS and give you the JS tag that is needed for the service to integrate with F5 XC. You will take this information over to Adobe Commerce, working with the F5 Team and configure the service. Next Switch to Adobe Commerce and Login. This will take you to Your Dashboard. Navigate down the Left Pane and Select Stores. Click Configuration. Navigate down the Configuration page to F5 Distributed Cloud Services. In the previous article we chose Bot Defense and configured that appropriately. Here we will select Account Protection and/or Authentication Intelligence for this article. This image shows Account Protection. At the very top and most importantly you need to enable the Service. This will expose all the other settings we will configure. API Hostname Script Tag JS Path Customer ID Cookie name Decryption key Protected Endpoints Both services have almost the same configuration items. Here is Authenticaion Intelligence. At the very top and most importantly you need to enable the Service. This will expose all the other settings we will configure. API Hostname Script Tag JS Path Customer ID Cookie name Decryption key These settings will be suppled by the F5 Customer Success Team when you implment the service. We recommend to inject into all Login, Logout, and Checkout/Transfer flow pages Those are all the steps that are necessary to easily and quickly set up Account Protection and Authentication Intelligence in the F5 Distributed Cloud. After your service is configured you will monitor from the F5 Distributed Cloud Console. I am including several images to give you a sample of the data you will see and have available to you. Related Articles: F5 Distributed Cloud Bot Defense Overview How to easily protect your BIG-IP applications using F5's Distributed Cloud Bot Defense with iApps How to easily protect your BIG-IP applications using F5's Distributed Cloud Bot Defense, natively F5 Distributed Cloud ServicesProtect your Mobile Applications with F5 Distributed Cloud Bot Defense
Introduction The newly released F5 Distributed Cloud (F5XC) Bot Defense iApp v.3.0.3 Connector for BIG-IP supports the following enhancements: Enables Mobile SDK support:Customers can now configure endpoints for web, mobile, or both. Independent SNAT configuration: Customers can configure SNAT for access to F5 Security API separately from SNAT for their protected virtual servers. Syslog improvements:Log messages are now distinguished by syslog severity level and can be associated with a specific transaction.Detailed per-transaction log messages are available if desired. SIEM logging:Users can send log messages to an external logserver/SIEM by using BIG-IP’s High Speed Logging (HSL) feature.(This applies to data generated on the BIG-IPand not to data from F5 Cloud dashboards.) Many additional performance and functional improvements. In this article, I will show you how to protect an Application with the new iApp and how to enable Moblie SDK. Getting Started First login to F5 Distributed Cloud console. Click on the Bot Defense Tile Make sure you are working in the correct Namespace. Click Add Application Give your protected application a Name, Labels and Description. Select your Application Region and F5 BIG-IP iApp as the Connector Type. Click Save and Exit Next, we will download the iApp template created for this application and save it in an accessible location to be installed on your BIG-IP. Now we will import the template, create the Application Service on the BIG-IP and configure the iApp. Log in to your BIG-IP. Navigate to iApps, Templates, Click Templates. Next Click Import. Navigate to the template file you downloaded from F5XC Console. And click Upload Next navigate to Application Services, and click Applications, click Create Give your application a Name and select the template you just uploaded. This will display the iApp page where we will configure all the options to protect your mobile applications. I have covered web applications in previous articles that I will link to at the end. You can select Advanced at the top of the page to see the complete list of options. You must change Mobile SDK options tab shown at the bottom of the image to Yes, to see the correct Security Endpoints. First, again you will be prompted that you need a F5XC Security Mobile SDK Subscription. You will supply what headers are expected from your mobile SDK and Enter the Mobile SDK Reload Header Name supplied by F5. This is used for signaling between the Mobile SDK and the F5XC Security service. Moving to the next section you will cover how the BIG-IP will handle the JS Injections, the URL and/or path and where on the page to inject. The next section has the newly added features for the iApp version 3.0.3. You'll notice at the bottom, you configure what URLs to be routed to the F5XC console. The options are Web, MSDK or Both. I give more details below the image of how to set this up and what to consider when designing your protected endpoints. When Mobile-SDK support is enabled, there are three types of protected endpoints: Web MSDK Both Endpoints marked Bothcan be accessed by either web or MSDK clients. When a client request reaches a Both endpoint, the F5XC Bot Defense iApp assumes the request comes from a web client unless the request includes a Mobile Request ID value shown in the red box above. There are two types of Mobile Request ID’s: Special request headers Special string values embedded in a request body (typically a POST request) To recognize Mobile SDK requests by headers, enter regular expressions to recognize the names and acceptable values of those headers. To recognize Mobile SDK requests by one or more keywords embedded in request-bodies, enter a suitable regular expression, using alternation to recognize different keywords if necessary. Beware of partial matches; use regex operators like ^ and $ and [^\w] as needed. The Actions available for protected endpoints also differ between Web type and MSDK type endpoints. Requests from MSDK clients may be Continued or Blocked but cannot be Redirected or Dropped. Whenever the Action configured for an MSDK request is Redirect or Drop, it is silently converted to Block whenever it is applied to a request from an MSDK client. The host and path are determined by your application. Finally, I want to point out a few features under Advanced Features that were highlighted in the opening of this article. Previous versions of the Bot Defense iApp “borrowed” the SNAT configuration they needed to connect to the F5XC Security Service API server(s) from the virtual-server to which Bot Defense protection was attached. That approach was not optimal, so starting with iApp v3.0.3, a distinct SNAT configuration must be selected. The default option is SNAT Automap: If configured to do so, iApp v3.0.3 will log an informative message about each transaction (a transaction is a distinct client HTTP request). Transaction logging does not directly incur a performance penalty but sending transaction logs to the local control-plane syslogd will incur a large performance penalty. If you want to log transactions, you should enable HSL (High-Speed Logging) to an external log server: Many log servers prefer messages in structured (JSON) format, which you may choose in the iApp. To include some HTTP request headers in transaction log messages (for example, headers which identify site users) specify a regex to match those headers’ names. Make sure you click Finished and you will have deployed your protected application. Closing: I wanted to highlight the changes F5 has made and show how easily you can deploy the iApp and take advantage of all the new features. That is all that you need to configure, to take advantage of F5’s Distributed Cloud Security Service. Note: If you are upgrading from an earlier version of the iApp (for example, iApp v.3.0.2 or v.3.0.1), you need take these steps to avoid possible errors: Prior to installing the v3.0.3 template: Reconfigurethe current Application Service (iApp instance). SetClean Before DeletiontoYes. SelectFinished. Install the v3.0.3 template. Be sure to select theOverwrite existing templatecheckboxbefore uploading the new template. Reconfigurethe current Application Service: SetClean Before DeletiontoNo. Check and update configuration as needed. SelectFinished. "Nature is a mutable cloud, which is always and never the same." - Ralph Waldo Emerson We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts. Related Articles: F5 Distributed Cloud Bot Defense Overview: https://community.f5.com/t5/technical-articles/f5-distributed-cloud-bot-defense-overview-and-demo/ta-p/292187 How to easily protect your BIG-IP applications using F5's Distributed Cloud Bot Defense with iApps: https://community.f5.com/t5/technical-articles/how-to-easily-protect-your-big-ip-applications-using-f5-s/ta-p/295578 How to easily protect your BIG-IP applications using F5's Distributed Cloud Bot Defense, natively: https://community.f5.com/t5/technical-articles/how-to-easily-protect-your-big-ip-applications-using-f5-s/ta-p/295590 Get Started: F5 Distributed Cloud Services: https://www.f5.com/cloud F5 Distributed Cloud Bot Defense: https://www.f5.com/cloud/products/bot-defenseProtect Your Adobe Commerce Site with F5 Distributed Cloud Services
Now you can use F5 Distributed Cloud Services to protect your Adobe Commerce site against malicious bots, seamlessly authenticate users, and stop online fraud – enabling you to fully maximize your Adobe Commerce investment F5 Distributed Cloud Bot Defense blocks up to 99% of malicious bots and other automated attacksat the origin. F5 Distributed Cloud Account Protection leverages a real-time, closed-loop AI fraud engine designed to predict and mitigaterisky or malicious transactions. F5 Distributed Cloud Authentication Intelligencemodel’s good user behavior to ensure safe user journeys and reduces unnecessary friction (e.g., MFA, CAPTCHA). In this article I will show you how to easily setup and configure the bot defense solution as the setup and steps are nearly identical and would be duplicative. Note: This article assumes you have both a F5 Distributed Cloud Services account and an Adobe Commerce Account. Log in to F5’s Distributed Cloud Console Click the Bot Defense tile Make sure you are in the correct Namespace. (Tenant’s configuration objects are grouped under namespaces. Namespaces can be thought of as administrative domains.) Click Add Application Give your application a Name, Labels, and a Description. Select the appropriate Application Region. Next Choose the Connector type as Custom Click Save and Exit This takes you back to the Manage Applications Page. Verify your Application has been deployed. App Name, Connector Type App ID and the Region are Correct. Here you will click on the ellipsis under Actions and copy out the following information: Copy App ID Copy Tenant ID Copy API Key Copy Web API Hostname Copy Telemetry Header Prefix This will be the information we will need to supply to the Adobe Commerce site to protect your application. Next Switch to Adobe Commerce and Login. This will take you to Your Dashboard. Navigate down the Left Pane and Select Stores. Click Configuration. Navigate down the Configuration page to F5 Distributed Cloud Services. Here we will select Distributed Cloud Bot Defense for this article. You could just as easily Select Account Protection and/or Authentication Intelligence. I'll cover the others in a follow-on article. Here you configure the settings that will set all the parameters needed to integrate with F5 Distributed Cloud. (F5XC) At the very top and most important you need to enable the Service. This will expose all the other settings we will configure. Now transfer all the key elements you copied out from the F5XC console: Copy App ID Copy Tenant ID Copy API Key Copy Web API Hostname Copy Telemetry Header Prefix This information is the base that allows your application to talk to and establish a connection to theF5 Distributed Cloud Console. This is enough to get connected. Now you would configure the protection you require. In the sections JS Insertion settings, Login Protection Settings, Protected Endpoints and Web Scraping Settings you will supply names, paths, methods and mitigations to protect your applications from the malicious bots. All the detailed information and each setting is too much to cover for this introductory article, but I hope this helps you get started. This shows just how easily and quickly you can set this up. Detailed guides will be available to explain each setting. Although not covered here both Account Protection and Authentication Intelligence are enabled the same way. Enable the Service in the UI and supply API hostnames and a few details copied from Distributed Cloud Console. Related Articles: F5 Distributed Cloud Bot Defense Overview How to easily protect your BIG-IP applications using F5's Distributed Cloud Bot Defense with iApps How to easily protect your BIG-IP applications using F5's Distributed Cloud Bot Defense, natively F5 Distributed Cloud Services
