OWASP 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 ReportF5 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 protect your 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 Service
Leverage BIG-IP 17.1 Distributed Cloud Services to Integrate F5 Distributed Cloud Bot Defense
Introduction: The F5 Distributed Cloud (XC) Bot Defense protects web and mobile properties from automated attacks by identifying and mitigating malicious bots. The Bot Defense uses JavaScript and API calls to collect telemetry and mitigate malicious users. The F5 Distributed Cloud (XC) Bot Defense is available in Standard and Enterprise service levels. In both the service levels the Bot Defense is available for traffic form web, web scarping, and mobile. The web scrapping is only applicable to web endpoints. This article will show you how to configure and use F5 Distributed Cloud Bot Defense (XC Bot Defense) on BIG-IP version 17.1 and above and monitor the solution on F5 Distributed Cloud Console (XC Console). Prerequisites: A valid XC Console account. If you don't have an account, visit Create a Distributed Cloud Console Account. An Organization plan. If you don't have an Organization plan, upgrade your plan. Getting Started: Log In to F5 XC Console: If XC Bot Defense isn't enabled, a Bot Defense landing page appears. Select Request Service to enable XC Bot Defense. If XC Bot Defense is enabled, you will see the tiles. Select Bot Defense. Verify you are in the correct Namespace. If your Namespace does not have any Protected Applications you will see the following page. Click Add Protected Application When you select a Namespace that has been configured with Protected Applications you will see this page. Scroll down to Manage Click Applications Click Add Application The Protected Application page is presented. Enter: Name Labels Description Select the Application Region - US in this example Connector Type - BIG-IP iApp for this demo. Cloudfront and Custom are other available connectors Scroll to the bottom and Click Save and Exit That will take you back to the Protected Applications Page. Verify your Application is listed with all the Metadata you supplied. Click the three ellipses to the right. Scroll down into the highlighted area and click and Copy App ID, Tenant ID and API Key Copy and save each value to a location where you can access it in the next steps. That completes the configuartion of F5 XC Console. Log In to your BIG-IP You will Notice in version 17.1 and above you will have a new selection along the left pane called Distributed Cloud Services. Expand and you will see all the latest integrations F5 provides. Application Traffic Insight Bot Defense Client-Side Defense Account Protection & Authentication Intelligence Cloud Services This article as stated before will focus on Bot Defense. Look for future articles that will focus on the other integrations. On the Main tab, Click Distributed Cloud Services > Bot Defense > Bot Profiles and Select Create This will bring up the General Properties page where you will enter required and optional information. Mandatory items have a Blue line on the edge. Supply a Name Application ID - From previous step Tenant ID - From previous step API Hostname - Web is filled in for you API Key - from previous step In the JS Injection Configuration section, the BIG-IP Handles JS Injectionsfield is checked by default, if you uncheck the field then follow the Note given in the Web UI. Protected Endpoint(s) - Web - Supply either the URI or IP of the Host Application along with the path and method you are protecting on the protected endpoint. In the following image, I have selected Advanced to show more detail of what is available. Again Mandatory fields have a blue indicator. Here the Protection Pool and SSL Profile. Click Finished when complete. One final step to complete the setup. Go to the Main tab, Local Traffic > Virtual Servers > Virtual Serves List Select the Virtual Server you are going to apply the Bot Defense profile to. Click on Distributed Cloud Services on the top banner Under Service Settings > Bot Defense set to Enable and then select the Bot Defense Profile you created in the above steps. The click Update. You have now sucessfully integrated BIG-IP Distributed Cloud Service on version 17.1 with F5 Distributed Coud Bot Defense. One final visual is the dashboard for F5 Distributed Cloud Bot Defense. This is where you will observe and monitor what bots and actions have been taken against bots and your protected applications. Conclusion: I hope you were able to benefit from this tutorial. I was able to show how quickly and easlity it is to configure F5 Dsitributed Cloud Bot Defense on BIG-IP v17.1 using the built in Distributed Cloud Services integration. Related Links: https://www.f5.com/cloud https://www.f5.com/cloud/products/bot-defense BIG-IP Bot Defense on 14.x-16.xEvolving Financial Services and how to protect against sophisticated cyber threats
In an era where cyber threats evolve as rapidly as digital innovation, financial institutions face unprecedented challenges. Balancing security, performance, and compliance is no longer optional—it’s critical to survival. F5 empowers financial organizations to modernize their operations, safeguard customer trust, and stay ahead of competitors through a robust suite of solutions designed to mitigate risks, optimize performance, and ensure regulatory compliance. This article (first in a series) provides an overview of how F5 addresses the pressing challenges of modern financial services, from securing APIs to neutralizing sophisticated DDoS attacks. Let’s explore how F5 enables you to deliver fast, reliable, and secure digital experiences—every time. What to expect? Here's what to expect in this article, Technical articles covering related F5 solutions. Overview about how F5 products are able to handle different aspects in Financial services, F5 BIG-IP F5 Distributed Cloud NGINX Mitigating Application Vulnerability Financial institutions are prime targets for cybercriminals. F5’s layered security approach ensures resilience against evolving threats. Protecting against OWASP Top 10 vulnerabilities (e.g., injection attacks, broken authentication) evolved from just mere web protection, to web, API, LLM. You can explore examples of solutions across BIG-IP Advanced WAF, F5 Distributed Cloud, and NGINX which actively blocks exploits while maintaining application performance through those articles, OWASP top 10 Series F5 Hybrid Security Architectures for DevSecOps: F5's Distributed Cloud WAF and BIG-IP Advanced WAF BIG-IP Advanced WAF. NGINX App Protect. Encrypted Traffic Inspection BIG-IP SSL Orchestrator (SSLO) enables organizations to decrypt and inspect encrypted traffic without compromising speed, ensuring threats hidden in SSL/TLS traffic are neutralized, this series or articles shows different integration use cases with BIG-IP SSLO. Implementing SSL Orchestrator - High Level Considerations | DevCentral Bot Mitigation Bot attacks lead to fraud, operational disruptions, and reputational damage by enabling account takeovers, credential stuffing, and synthetic fraud. These attacks increase infrastructure costs, cause service downtime through DDoS, and expose institutions to regulatory penalties. Mitigating such attacks starts at multiple levels, below we are listing some of the helpful items on how to combat Bot attacks. An overview of F5 Distributed Cloud Bot Defense Ridiculously Easy Bot Protection: How to Use BIG-IP APM to Streamline Bot Defense Implementation | DevCentral Securing APIs and Third-Party Integrations APIs drive innovation but introduce risks like data breaches and downtime. how we can tackle API security depends on the applications need to be protected, whether we rely on BIG-IP, F5 Distributed Cloud or NGINX, or the Hybrid integration of different components, This series is about API security, will be a great start Use of NGINX Controller to Authenticate API Calls | DevCentral And to understand more about WAAP, What is WAAP?Community Learning Path: Web Application and API Protection (WAAP) Preventing DDoS Attacks DDoS attacks can cause a lot of impact to the business, whether it’s immediate impact by preventing the business from serving its customer or non-immediate one by impacting business brand image and ability to secure their customers and their data. DDoS attack vectors may vary from targeting application, bandwidth, resources like CPU, Memory or critical protocols like DNS, TCP or UDP. You can explore some interesting use cases on F5 DDoS mitigation through the below, NGINX App Protect. F5 Distributed Cloud DDoS Mitigation Service. DDoS Mitigation with F5 Distributed Cloud How to get started with F5 Distributed Cloud Managed Services How to easily add DoS protection to your F5 Distributed Cloup applications BIG-IP Advanced Firewall Manager. Explanation of F5 DDoS threshold modes | DevCentral Concept of F5 Device DoS and DoS profiles | DevCentral IP-Intelligence and IP-Shunning | DevCentral BIG-IP Advanced WAF. F5 Hybrid Security Architectures for DevSecOps: F5's Distributed Cloud WAAP Bot and DDoS Defense and BIG-IP Advanced WAF F5 BIG-IP Advanced WAF - DOS profile configuration options. | DevCentral F5 Hybrid Security Architectures for DevSecOps: F5's Distributed Cloud WAF and BIG-IP Advanced WAF Conclusion In this introduction article, we went through an overview of F5 solutions in Financial Services, in the following articles, we will dig a bit deeper with each solution. F5 not only helps with security but with maximizing performance as well. Related Content Testing the security controls for a notional FDX Open Banking deployment Decoding PCI-DSS v4.0: F5's Ridiculously Easy Guide to Technical Compliance Banking and Financial Services Why Top Financial Services Companies Rely on F5 NGINX App Protect. F5 Distributed Cloud DDoS Mitigation Service. DDoS Mitigation with F5 Distributed Cloud How to get started with F5 Distributed Cloud Managed Services How to easily add DoS protection to your F5 Distributed Cloup applications BIG-IP Advanced Firewall Manager. Explanation of F5 DDoS threshold modes | DevCentral Concept of F5 Device DoS and DoS profiles | DevCentral IP-Intelligence and IP-Shunning | DevCentral BIG-IP Advanced WAF. F5 Hybrid Security Architectures for DevSecOps: F5's Distributed Cloud WAAP Bot and DDoS Defense and BIG-IP Advanced WAF F5 BIG-IP Advanced WAF - DOS profile configuration options. | DevCentral F5 Hybrid Security Architectures for DevSecOps: F5's Distributed Cloud WAF and BIG-IP Advanced WAF Overview of WAAP Incidents What is WAAP?BIG-IP BGP Routing Protocol Configuration And Use Cases
Is the F5 BIG-IP a router? Yes! No! Wait what? Can the BIG-IP run a routing protocol? Yes. But should it be deployed as a core router? An edge router? Stay tuned. We'll explore these questions and more through a series of common use cases using BGP on the BIG-IP... And oddly I just realized how close in typing BGP and BIG-IP are, so hopefully my editors will keep me honest. (squirrel!) In part one we will explore the routing components on the BIG-IP and some basic configuration details to help you understand what the appliance is capable of. Please pay special attention to some of the gotchas along the way. Can I Haz BGP? Ok. So your BIG-IP comes with ZebOS in order to provide routing functionality, but what happens when you turn it on? What do you need to do to get routing updates in to the BGP process? And well does my licensing cover it? Starting with the last question… tmsh show /sys license | grep "Routing Bundle" The above command will help you determine if you’re going to be able to proceed, or be stymied at the bridge like the Black Knight in the Holy Grail. Fear not! There are many licensing options that already come with the routing bundle. Enabling Routing First and foremost, the routing protocol configuration is tied to the route-domain. What’s a route-domain? I’m so glad you asked! Route-domains are separate Layer 3 route tables within the BIG-IP. There is a concept of parent and child route domains, so while they’re similar to another routing concept you may be familiar with; VRF’s, they’re no t quite the same but in many ways they are. Just think of them this way for now. For this context we will just say they are. Therefore, you can enable routing protocols on the individual route-domains. Each route-domain can have it’s own set of routing protocols. Or run no routing protocols at all. By default the BIG-IP starts with just route-domain 0. And well because most router guys live on the cli, we’ll walk through the configuration examples that way on the BIG-IP. tmsh modify net route-domain 0 routing-protocol add { BGP } So great! Now we’re off and running BGP. So the world know’s we’re here right? Nope. Considering what you want to advertise. The most common advertisements sourced from the BIG-IP are the IP addresses for virtual servers. Now why would I want to do that? I can just put the BIG-IP on a large subnet and it will respond to ARP requests and send gratuitous ARPs (GARP). So that I can reach the virtual servers just fine. <rant> Author's opinion here: I consider this one of the worst BIG-IP implementation methods. Why? Well for starters, what if you want to expand the number of virtual servers on the BIG-IP? Well then you need to re-IP the network interfaces of all the devices (routers, firewalls, servers) in order to expand the subnet mask. Yuck! Don't even talk to me about secondary subnets. Second: ARP floods! Too many times I see issues where the BIG-IP has to send a flood of GARPs; and well the infrastructure, in an attempt to protect its control plane, filters/rate limits the number of incoming requests it will accept. So engineers are left to try and troubleshoot the case of the missing GARPs Third: Sometimes you need to migrate applications to maybe another BIG-IP appliance as it grew to big for the existing infrastructure. Having it tied to this interface just leads to confusion. I'm sure there's some corner cases where this is the best route. But I would say it's probably in the minority. </rant> I can hear you all now… “So what do you propose kind sir?” See? I can hear you... Treat the virtual servers as loopback interfaces. Then they’re not tied to a specific interface. To move them you just need to start advertising the /32 from another spot (Yes. You could statically route it too. I hear you out there wanting to show your routing chops.) But also, the only GARPs are those from the self-ip's This allows you to statically route of course the entire /24 to the BIG-IP’s self IP address, but also you can use one of them fancy routing protocols to announce the routes either individually or through a summarization. Announcing Routes Hear ye hear ye! I want the world to know about my virtual servers. *ahem* So quick little tangent on BIG-IP nomenclature. The virtual server does not get announced in the routing protocol. “Well then what does?” Eery mind reading isn't it? Remember from BIG-IP 101, a virtual server is an IP address and port combination and well, routing protocols don’t do well with carrying the port across our network. So what BIG-IP object is solely an IP address construct? The virtual-address! “Wait what?” Yeah… It’s a menu item I often forget is there too. But here’s where you let the BIG-IP know you want to advertise the virtual-address associated with the virtual server. But… but… but… you can have multiple virtual servers tied to a single IP address (http/https/etc.) and that’s where the choices for when to advertise come in. tmsh modify ltm virtual-address 10.99.99.100 route-advertisement all There are four states a virtual address can be in: Unknown, Enabled, Disabled and Offline. When the virtual address is in Unknown or Enabled state, its route will be added to the kernel routing table. When the virtual address is in Disabled or Offline state, its route will be removed if present and will not be added if not already present. But the best part is, you can use this to only advertise the route when the virtual server and it’s associated pool members are all up and functioning. In simple terms we call this route health injection. Based on the health of the application we will conditionally announce the route in to the routing protocol. At this point, if you’d followed me this far you’re probably asking what controls those conditions. I’ll let the K article expand on the options a bit. https://my.f5.com/manage/s/article/K15923612 “So what does BGP have to do with popcorn?” Popcorn? Ohhhhhhhhhhh….. kernel! I see what you did there! I’m talking about the operating system kernel silly. So when a virtual-address is in an unknown or enabled state and it is healthy, the route gets put in the kernel routing table. But that doesn’t get it in to the BGP process. Here is how the kernel (are we getting hungry?) routes are represented in the routing table with a 'K' This is where the fun begins! You guessed it! Route redistribution? Route redistribution! And well to take a step back I guess we need to get you to the ZebOS interface. To enter the router configuration cli from the bash command line, simply type imish. In a multi-route-domain configuration you would need to supply the route-domain number but in this case since we’re just using the 0 default we’re good. It’s a very similar interface to many vendor’s router and switch configuration so many of you CCIE’s should feel right at home. It even still lets you do a write memory or wr mem without having to create an alias. Clearly dating myself here.. I’m not going to get in to the full BGP configuration at this point but the simplest way to get the kernel routes in to the BGP process is simply going under the BGP process and redisitrubting the kernel routes. BUT WAIT! Thar be dragons in that configuration! First landmine and a note about kernel routes. If you manually configure a static route on the BIG-IP via tmsh or the tmui those will show up also as kernel routes Why is that concerning? Well an example is where engineers configure a static default route on the BIG-IP via tmsh. And well, when you redistribute kernel routes and that default route is now being advertised into BGP. Congrats! AND the BIG-IP is NOT your default gateway hilarity ensues. And by hilarity I mean the type of laugh that comes out as you're updating your resume. The lesson here is ALWAYS when doing route redistribution always use a route filter to ensure only your intended routes or IP range make it in to the routing protocol. This goes for your neighbor statements too. In both directions! You should control what routes come in and leave the device. Another way to have some disasterous consequences with BIG-IP routing is through summarization. If you are doing summarization, keep in mind that BGP advertises based on reachability to the networks it wants to advertise. In this case, BGP is receiving it in the form of kernel routes from tmm. But those are /32 addresses and lots of them! And you want to advertise a /23 summary route. But the lone virtual-address that is configured for route advertisement; and the only one your BGP process knows about within that range has a monitor that fails. The summary route will be withdrawn leaving all the /23 stranded. Be sure to configure all your virtual-addresses within that range for advertisement. Next: BGP Behavior In High Availability ConfigurationsAppSec, Camels, Typhoons, and Backdoors
Welcome back to the F5 SIRT's weekly roundup of whatever news caught the editor's eye, and whatever else we feel like covering. It's our soapbox, and we're going to use it! This week MegaZone is once against at the keyboard, and we'll be covering news for the week of March 2-8, 2025.Mitigating Apache Camel Vulnerability CVE-2025–27636 with F5 Products
Recently Apache Camel has published a vulnerability CVE-2025-27636 (https://nvd.nist.gov/vuln/detail/CVE-2025-27636 ) As always, F5 is here to support customers and provide mitigation for this vulnerability. Apache Camel is a free tool that helps developers connect different systems and apps. It does this by using enterprise integration patterns (EIPs). Since it is widely used in enterprise environments, it becomes a tempting target for malicious actors.. To mitigate this vulnerability against your web application with F5 product, please follow below-mentioned steps. For F5 WAF products: Assign the signature 200016013 to the security policy which is part of signature update ASM-AttackSignatures_20250309_023422.im. Make sure your policy is in blocking mode and signature 200016013 is enforced. To know the status of policy Go to Security > Application Security > Security Policies > Policies List > Select the policy Under policy configuration, select General setting and look for Enforcement mode under learning and blocking. If the policy is not in blocking mode, you may change it by changing the enforcement mode to blocking. To apply the changes, save and apply the policy. To know the status of signature. Go to Security > Application Security > Security Policies > Policies List and then select the policy. Under policy configuration, select Attack Signatures, then click on filter and search for signature ID “200016013” Make sure the signature is not disabled or in staging state. If signature is not enforced, you may enforce it by selecting the signature and then by clicking on enforce button. For detail information - please check https://techdocs.f5.com/en-us/bigip-14-1-0/big-ip-asm-attack-and-bot-signatures-14-1-0/assigning-attack-signatures-to-security-policies.html To apply the changes save and apply the policy. Note: Signature updates are available at https://my.f5.com/manage/s/downloads To know how to update signatures https://my.f5.com/manage/s/article/K82512024 For BIG-IP Products (In case you don’t have F5 WAF products): To mitigate the CVE, apply the iRule available at https://my.f5.com/manage/s/article/K000150304A Very Chinese New Year
Happy New Year everyone! It's a new year, with new news, and the same old(er) MegaZone. This time we're looking at the news that I found worthy from the week of January 5-11, 2025. (Have you gotten used to typing 2025 yet?) I found it to be a fairly slow news week, and not much really grabbed my attention enough that I felt it was worth commenting on. That's not too unusual for the start of a new year, as there is often a bit of a post-holiday lull. Not that there was no news at all, it is never truly quiet in cybersecurity, just that most of it was run-of-the-mill stuff, IMHO. Oh, and as for the title of this 'issue', I know the Lunar New Year (aka Chinese New Year) isn't until January 29th, but I couldn't pass up the play on words given the topic below. And with that, let's dive in.Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation)
Introduction This guide, along with the provided scripts and sample app and services, is designed to help explore and demonstrate the use cases of the F5 Distributed Cloud (XC) Bot Defense in a variety of different cloud environments including AWS, Azure, GCP, and within the Distributed Cloud (XC) Regional Edge. XC Bot Defense Connector Strategy F5 Distributed Cloud Bot Defense meets you where you’re at when it comes to deployment flexibility. We make it ridiculously easy for you to deploy XC Bot Defense either in the cloud, on-prem, or as a hybrid configuration with pre-built connecters in leading application platforms and CDNs to make deployment easy and fast. Choose Your Path Within each deployment scenario, you can choose your path with the following options to deploy the specified Bot Defense environment using either the console deployment link or automation with terraform. Module 1 Deploy Bot Defense on Regional Edges with F5 Distributed Cloud Module 2 Deploy F5 XC Bot Defense for AWS Cloudfront with F5 Distributed Cloud Module 3 Deploy Bot Defense in Azure with BIG-IP Connector for F5 Distributed Cloud Module 4 Deploy Bot Defense in GCP Using BIG-IP Connector for F5 Distributed Cloud XC Bot Defense Scenarios The modules below lay out a framework for connecting and managing distributed app services for this scenario, with a focus on the three core use cases. MODULE 1: Deploy Bot Defense on Regional Edges with F5 Distributed Cloud In this scenario, we will be deploying our fictitious airline application into a Regional Edge location of our choosing via the VK8's service in XC. We'll walk through all of the required steps, provide the vk8's manifest file and front end this application with an XC HTTP Load Balancer. In addition, the HTTP Load Balancer will be used to front-end our application and enable our XC Bot Defense Service. Choose your path: Console Steps for XC Bot Defense on Regional Edges Automated Deployment of XC Bot Defense on Regional Edge via Terraform MODULE 2: Deploy F5 XC Bot Defense for AWS Cloudfront with F5 Distributed Cloud In this scenario, we will be deploying our fictitious application in AWS with the XC Bot Defense Connector for AWS Cloudfront Distributions. Choose your path: Console Steps to Deploy F5 XC Bot Defense for AWS Cloudfront Coming Soon*** Automated Deployment of XC Bot Defense for AWS Cloudfront MODULE 3: Deploy Bot Defense in Azure with BIG-IP Connector for F5 Distributed Cloud In this scenario, we will be deploying our fictitious application into Azure with the XC Bot Defense Connector for BIG-IP. Choose your path: Console Steps to Deploy F5 XC Bot Defense in Azure with BIG-IP Connector Automated Deployment of XC Bot Defense in Azure with BIG-IP Connector MODULE 4: Deploy Bot Defense in GCP Using BIG-IP Connector for F5 Distributed Cloud In this scenario, we will be deploying our fictitious application into GCP with the XC Bot Defense Connector for BIG-IP. Choose your path: Console Steps to Deploy F5 XC Bot Defense in GCP Using BIG-IP Connector Automated Deployment of XC Bot Defense in GCP with BIG-IP Connector For additional information, refer to these resources: Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) GitHub repository with the walk-through of the deployment steps & demo YouTube video series discussing the different aspects of this configuration DevCentral Learning Series: Edge Compute Get Started with F5 Distributed Cloud ServicesGiving Thanks for the Hackers, Crackers and Thieves
This holiday season, give you friendly neighborhood hacker (black or white hatted) and nice pat on the back. ‘Why?’ you may ask. ‘Aren’t they responsible for the nasty botnets, malware, SQL injections, stolen identities, government infiltration, Stuxnet, and all the malicious things you warn against in this very blog?’ Yes, but over the years it’s been the very same folks attempting to and successfully gaining access to systems to infect, steal, snoop and causing general havoc that have made security better. All the new variants of worms, viruses, trojans or the all encompassing ‘malware’ force security professionals to stay alert, review risks and come up with solutions to thwart such attacks. It is a great battle of wits in this game of chess that’s played out over the internet. Patch one hole, find another; lock one system, infiltrate another; fix one vulnerability, expose another. As an aside, I’m using the term ‘hacker’ to mean both the good and the bad. In the media, the term hacker has grown to mean someone with bad intentions who breaks into computers with malicious intent, but within the programming world, it’s also considered a compliment. A hacker is just someone with exceptional computer skills that can, essentially, make a system do what they want. Even the term ‘hack’ can be good and bad; a compliment or insult. If you ‘hack’ something with criminal intentions, then it is bad but if you come up with a clever way or a brilliant ‘hack’ to accomplish something, then you are praised. Both break the rules - either the law or the accepted way of doing something. Over the years, while software firms, financial institutions, retailers, travel outlets, ISPs and others would deny the fact that there might be something wrong or a vulnerability within their code, systems and infrastructure, it would be the ‘hacker’ that would prove to the world and force the manufacturer to both admit and fix the weak link. As the years have passed and the hackers are often proven right, companies now (to some extent) welcome the insight of how to make their products more secure. ‘Welcome’ might not be the most accurate term but there is less denial and more acceptance, with quicker fixes, patches and other remedies. They have also made the individual user more aware of the things that might harm their computers and compromise their identity. They have made the casual user more savvy to avoiding those pitfalls, tricks and methods to steal personal information. They have taught us to be more careful about the links we click, the things we publish on social media sites and how we navigate the internet. Imagine how open If you haven’t figured it out by now, there has always been the Great Battle between Good and Evil – those who want to help and those who want to hurt; those with good intentions and those with bad; those with kindness and those who are cruel. Granted, it is not as black and white as depicted and there are many, many grey areas when it comes to doing what is right. If the bad guys have, by their actions, forced providers to bestow better solutions and make us, as users, safer, then have at it! With anything, if you can pull whatever good out of a bad situation and learn from it, then you are living a fruitful life – and that, you should be thankful for. ps twitter: @psilvas
