In this article, I will show you how to easily deploy your Palo Alto firewall in a Security Services VPC using F5 Distributed Cloud (XC) Security Service Insertion.
Security service insertion from F5 Distributed Cloud Network Connect simplifies the deployment and operation of Palo Alto NGFW security services across hybrid and multi-cloud environments.
Deploying security software in the public cloud—especially in multiple public clouds—is more complicated than deploying it in private cloud and on-premises because the virtualized infrastructure is explicitly designed to operate as multiple independent instances, easily leading to instance sprawl and policy skew. SecOps and NetOps teams are struggling to install, configure, and maintain security solutions that work consistently.
Key Benefits
Enhanced Firewall Policy is an intent-based network policy supported on the Distributed Cloud Platform. Just like Network Policy, an Enhanced firewall policy can be applied at the site level, and it can use flexible and dynamically abstracted data to make decisions. For example, the tags or labels belonging to a source or destination VPC on a deployed site can be used to allow, deny, or steer traffic.
Using the new Enhanced Firewall policy object, network admins can steer the traffic to an external service.
Use Cases
I am listing six different use cases that can easily be configured in the XC Console to enable traffic steering with our newly released Enhanced firewall policies. This article will highlight the (1) East-West and (4) North-South scenarios below.
In addition, different types of traffic can be individually steered to the PAN Firewall, potentially offloading the firewall from having to inspect traffic that can be blocked by Distributed Cloud.
The following prerequisites apply:
The steps below are what is required to set up Service Insertion. I will not cover every step, as I will assume most have some experience with VPCs and some related cloud concepts. I will highlight where Distributed Cloud simplifies building this environment and changing traffic policies.
F5 Distributed Cloud Console
Log In:
Select Multi-Cloud Network Connect:
Navigate to Manage > Site Management > AWS TGW Sites
Click Add AWS TGW Site or Select a TGW Site that has already been built for your organization.
Note: At any time, you need additional information, click the Tech Docs link.
On this initial page, you need to supply the Metadata Name, Label, and Description. I will cover each additional section in detailed Screenshots.
Click on Configure under AWS Resources:
AWS Resources:
Region and Services VPC:
Transit Gateway
Site Node Parameters
Click Add Item
You are returned to the previous screen.
Enter the Public SSH Key that you will use to access your AWS instances.
Associate Spoke VPCs
Now configure your Spoke VPC’s
Click Configure.
Supply the appropriate VPC ID you are connecting with labels.
Click Apply and continue adding additional VPC’s if needed.
Click Apply again as needed.
Site Network and Security
Under Site Network and Security, you will have to select Configure under both areas, but the settings are all correct. Click Apply
Direct Connect
Software Version
Advanced
Click Save and Exit
You have now successfully set up all the requirements to have a functioning TGW site. This uses Enhanced Firewall Policies with the attached VPCs to steer and secure traffic to your Palo Alto NGFW.
Add an External Service
Navigate in Multi-Cloud Network Connect > Manage > External Services
Click Add External Service
Supply a Name, Label and Description
Under AZ Nodes, Select Add Item
Give the Service Node a Name, the AWS AZ Name, and the Subnet for Management Interface
Note: Click here for information about AWS Availability Zones, the name choices are unique to your AWS Subscription. The subnet and CIDR block for the management interface can be autogenerated by Distributed Cloud, it can be created manually at this step in the process, or you can use an existing subnet. This step determines the IP address that the firewall uses for its lifespan.
Click > Apply
You will be returned to the previous screen.
If you are integrating Panorama, you would do that here. We are not covering that in this article.
Select the PA Version. (At the time of this article's publishing only 11.0.0 is available)
Click Apply
Depending on the configuration, you will either enable or disable HTTPS Management of the firewall, choose the domain name suffix to complete the URL that will be used to access the firewall, and whether the firewall will be available publicly on the Internet or through select locations and networks connected by Distributed Cloud.
Click Save and Exit
Distributed Cloud now deploys the Palo Alto Firewall instance(s) and builds the Geneve tunnels.
Configure Enhanced Firewall Policy
This brings us to the final configuration and most powerful feature of Service Insertion. You can manipulate traffic going to the external service in 6 key use case scenarios by making simple changes to F5 XC enhanced firewall policy and reordering rules
Here are 5 different policies that were built. Let’s look at one policy and then see how to change it to manipulate traffic. Note that the Enhanced Firewall Policy only controls what traffic goes to the external service, it doesn’t control what happens to the traffic on the external service itself.
To see the flexibility provided for building policies, notice the firewall option to set up and control traffic.
Select Custom Enhanced Firewall Policy Rule Selection
Click Configure
In the following screenshots, I will Show all the items in the Source Traffic Filter, the Destination Traffic Filter, the Type of Traffic to Match, and the Action. This rule sends all traffic to the external service in one direction. Because the firewall is stateful and the connection path is symmetric, a corresponding rule to redirect traffic in the reverse direction is not needed.
Source Traffic Filter: All Sources
Destination Traffic Filter: All Destinations
Types of Traffic to Match: Match All Traffic
Action: Insert an External Service
Source Traffic Filter
Destination Traffic Filter
Types of Traffic to Match
Action
Here is where the Distributed Cloud magic happens.
Select Insert an External Service. We will select the Palo Alto External Service you created previously.
A final and optional step could be to add keys/labels to further restrict the selection criteria for routing and controlling traffic. For example, if the origin site routes traffic for multiple VPC’s, each VPC having its own unique key value, then entering a key here further restricts which VPC the rule applies to, i.e. prod, staging, or dev.
You now have completed all the steps to integrate your Palo Alto Firewall into F5 Distributed Cloud Network Connect. This enables you to route traffic through or around your Firewall based on the architecture and design of your network. Based on these simple steps, you have granular control over all your traffic and how you handle your traffic across multiple clouds.
F5 Distributed Cloud Network Connect
F5 Distributed Cloud Security Service Insertion With BIG-IP Advanced WAF
This article serves as an update to a previous post, reflecting the latest information and updates in the "OpenShift Anywhere with F5 Distributed Cloud" video series.
Creating and managing an OpenShift environment can be complex. To help customers reduce this complexity and focus on their applications, Red Hat has partnered with key cloud providers to offer fully managed container environment services such as Red Hat OpenShift Service on AWS (ROSA) and Azure Red Hat OpenShift (ARO).
In previous blogs, we covered how F5 technologies (BIG-IP Container Ingress Service (CIS) and NGINX Ingress Controller) can be integrated into ROSA and ARO service offerings:
Now, let's delve into F5 Distributed Cloud Platform, a SaaS-based solution for multi-cloud OpenShift services, and explore its ability to address two main challenges: connecting and securing applications for Multi-Cloud OpenShift clusters.
Multi-cloud OpenShift clusters present several challenges when it comes to connecting applications:
By utilizing F5 Distributed Cloud Mesh as an ingress and egress gateway for OpenShift, we can discover services and make OpenShift services available in any location, whether it's Public Clouds, Private Clouds, or the edge. This approach helps overcome the challenges of connecting apps in multi-cloud OpenShift clusters.
Multi-cloud adoption presents a couple of challenges when it comes to securing applications:
F5 Distributed Cloud Platform is designed to secure multiple OpenShift clusters by providing features such as:
This approach results in unified Multi-Cloud Networking with consistent networking policies, application security, and network security. By reducing complexity and offering common standards for IT professionals to manage, F5 Distributed Cloud Services effectively addresses the security challenges associated with multi-cloud OpenShift clusters.
F5 Distributed Cloud WAAP delivers a SaaS-based solution for app security, covering each application attack surface, including WAF, Bot and fraud mitigation, application-based DoS mitigation, and API protection. This ensures a comprehensive and unified security policy across your multi-cloud OpenShift environment.
To help users explore and embrace this new Distributed Cloud model for multi-cloud OpenShift services, we have created a series of how-to videos called "OpenShift Anywhere with F5 Distributed Cloud." The series includes the following episodes:
These videos demonstrate the ease and power of F5 Distributed Cloud in deploying, managing, and enforcing security policies across distributed workloads for multi-cloud OpenShift clusters. They provide a comprehensive guide to implementing F5 Distributed Cloud Services for both connecting and securing applications in your multi-cloud OpenShift environment, effectively overcoming the challenges presented by multi-cloud adoption.
In addition to the initial episodes of the "OpenShift Anywhere with F5 Distributed Cloud" video series, we are continuously working on creating more informative and practical content to help users further explore and embrace the Distributed Cloud model for multi-cloud OpenShift services.
Stay tuned for upcoming videos that will cover advanced topics, best practices, and real-world use cases to ensure you get the most out of F5 Distributed Cloud Platform in your multi-cloud OpenShift environment.
Hi Floks,
I would like to automate the backup (and restore if needed!) of my XC configurations via the API.
What is the best way, can I save all the configurations at once, should I save the namespaces completely, one by one or should I save each object of a namespace (pool, healthcheck, HTTP LB, App FW...)? Or maybe it's doable per service? In short, what is the smartest way to make a complete backup of the confs?
Thanks.
In this article, we'll show you how customers can now utilize F5's industry leading Distributed Cloud Account Protection and Authentication Intelligence Services with Forgerock's Customer Identity and Access Management Platform, bringing immediate security action and protecting their digital businesses against fraud.
F5 Distributed Cloud Authentication Intelligence and Account Protection can now be easily integrated into the ForgeRock customer identity & access management (CIAM) platform. The ForgeRock connector instantly integrates with Distributed Cloud to enable Authentication and Account Protection to stop targeted, human-driven fraud with adaptive, real-time detection of fraudulent activity across the entire user journey. The ForgeRock connector adds no additional friction to help to drive a strong customer experience that improves the bottom line.
There are many benefits that customers can gain by deploying F5’s Distributed Cloud Fraud Solutions with the Forgerock Connector Integration. They can Slash fraud and abuse, increase top-line revenue, remove friction for good users and maximize app security against manual fraud. To learn more please visit F5.com/ForgeRock or contact ForgeRock@F5.com.
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.
That is all the configuration needed in F5 Distributed Cloud Console. We will return to monitor our Application after configuring Cloudflare.
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.
But we need to assign the worker to a Website. Return to the main menu and select Websites.
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"
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.
Here we will use the files we downloaded from F5 Distributed Cloud Console.
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.
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.
Application Programming Interface (APIs) holds a prominent place in this emerging technology world. API users have increased exponentially and so are the attacks. Improper design, internal testing APIs exposure, PII leakage, lack of API authentication, lack of rate limiting, and improper logging are some of the commonly observed reasons for the API attacks. OWASP API Security article provides detailed explanation on Top 10 API vulnerabilities.
Insufficient logging and monitoring are observed as some of the common reasons in majority of the attacks. Having an improper logging system will make it difficult for an organization to analyse and identify the issues, unusual activities and breaches as it needs a lot of time and human efforts in troubleshooting. The impact will be huge and can be worse if the logs cannot provide sufficient data or the attack is not identified in the early stage. F5 Distributed Cloud (XC) provides efficient logging and monitoring solutions to overcome these difficulties. This article explains more about the logging capabilities of F5 Distributed Cloud.
F5 Distributed Cloud Platform (F5 XC) not only provides API protection features like Rate limiting, API Discovery, PII safeguard and Bot Defence but also provides Performance and Security monitoring GUI dashboards to monitor the logs in a convenient and user-friendly manner.
F5 XC continuously monitors and actively collects all the data related to load balancer like Request rate, throughput, latency, security events, requests, alerts, API Discovery, top attacked API endpoints, location from where the request is being generated, bot attacks, malicious users and presents it in a very organised manner which helps to monitor the data with ease. F5 XC centralized log management provides a flexible approach to monitor the dashboards continuously, correlate security events and analyse them. Filtration of data using timestamps and different key values helps to monitor the data more accurately.
With F5 XC Security Monitoring, the administrator can:
F5 XC centralized monitoring dashboard displays security events classification, source IP, country and other details.
F5 XC dashboard also displays Top attack details based on different classifications.
Different security events that were generated.
A security event contains all the necessary details to identify the event occurrence..
F5 XC detects and displays malicious user and activity.
Discovered API endpoints.
F5 XC generates alerts when something unexpected has occurred.
Routine monitoring of security events, alerts and requests data can help the admin to notice the abnormal actions happening if any and can immediately take protection measures.
With F5 XC Performance Monitoring, the administrator can:
Performance monitoring dashboard provides Application metrics such as Healthscore, Throughput, Latency, Requests details.
This picture provides pictorial overview of traffic flow from source site to origin server.
Overall incoming requests can be monitored, and they get classified according to the response code.
Request provides all the details such as response codes, source details.
Global log receiver feature of F5 XC helps in sending the tenant logs from F5 Distributed Cloud Regional Edge (RE) Sites to an external log collection system such as Amazon S3, Splunk, Azure Blob Storage and many more. The request(access) logs, security events, and audit logs for all HTTP Load Balancers and sites can be preserved in the external log collection systems. Please refer Global log receiver document for more details.
Insufficient logging and improper monitoring are the reasons organisations fail to deal with the security breaches. F5 XC helps to overcome these challenges by providing efficient logging and monitoring solutions which helps organizations to identify abnormal events, malicious requests well in advance and remediate security weakness faster. F5 XC has gained a remarkable attention due to their centralized visibility dashboards and monitoring solutions.
For those of you following along with the F5 Hybrid Security Architectures series, welcome back! If this is your first foray into the series and would like some background, have a look at the intro article. This series is using the F5 Hybrid Security Architectures GitHub repo and CI/CD platform to deploy F5 based hybrid security solutions based on DevSecOps principles. This repo is a community supported effort to provide not only a demo and workshop, but also a stepping stone for utilizing these practices in your own F5 deployments. If you find any bugs or have any enhancement requests, open an issue, or better yet contribute!
Here in our fourth example solution, we will be using Terraform to deploy an application server running the OWASP Juice Shop application serviced by a F5 BIG-IP Advanced WAF Virtual Edition. We will supplement this with F5 Distributed Cloud Web App and API Protection to provide BOT and DDoS Defense at the Edge. Everything will be tied together using GitHub Actions for CI/CD and Terraform Cloud to maintain state.
Distributed Cloud WAAP: Available for SaaS-based deployments in a distributed environment that reduces operational overhead with an optional fully managed service.
BIG-IP Advanced WAF: Available for on-premises / data center and public or private cloud (virtual edition) deployment, for robust, high-performance web application and API security with granular, self-managed controls.
The F5 Distributed Cloud Bot Defense is an advanced security add-on included with the F5 Web Application and API Protection (WAAP) service, providing seamless integration for real-time safeguarding of your web applications and APIs against a diverse range of attacks. This feature enables enterprises to benefit from advanced bot defense and sophisticated security monitoring to eliminate malicious traffic targeting user accounts, content scraping, and ad fraud.
F5 Distributed Cloud WAAP safeguards applications from volumetric L3-L7 DDoS attacks at the network edge, allowing the app to remain globally accessible while avoiding disruption to genuine customers. Additionally, the Distributed Cloud WAAP furnishes insights into both past and ongoing attacks that have been mitigated, empowering proactive measures to thwart malicious individuals.
Workspaces: Create a workspace for each asset in the workflow chosen
Workflow | Workspaces |
xcbot-bigip | infra, bigip, juiceshop, xc |
Workspace Sharing: Under the settings for each Workspace, set the Remote state sharing to share with each Workspace created.
Your Terraform Cloud console should resemble the following:
Variable Set: Create a Variable Set with the following values.
IMPORTANT: Ensure sensitive values are appropriately marked.
Your Variable Set should resemble the following:
Fork and Clone Repo: F5 Hybrid Security Architectures
Actions Secrets: Create the following GitHub Actions secrets in your forked repo
Your GitHub Actions Secrets should resemble the following:
Step 1: Check out a branch for the deploy workflow using the following naming convention
Step 2: Rename infra/terraform.tfvars.examples to infra/terraform.tfvars and add the following data
project_prefix = "Your project identifier"
resource_owner = "You"
aws_region = "Your AWS region" ex: us-west-1
azs = "Your AWS availability zones" ex: ["us-west-1a", "us-west-1b"]
Step 3: Rename bigip/terraform.tfvars.examples to bigip/terraform.tfvars and add the following data
f5_ami_search_name = "F5 BIGIP-16.1.3* PAYG-Adv WAF Plus 25Mbps*"
aws_secretmanager_auth = false
create_awaf_config = true
awaf_config_payload = "awaf-config.json"
Step 4: Rename xc/terraform.tfvars.examples to xc/terraform.tfvars, add the XC tenant data, and set the WAF, Bot, and DDoS feature flags to `true`.
#XC Tenant and Namespace
api_url = "https://<YOUR TENANT>.console.ves.volterra.io/api"
xc_namespace = "Your XC Namespace"
app_domain = "Your APP FQDN"
#XC WAF
xc_waf_blocking = true
#XC Bot Defense
xc_bot_def = true
#XC DDoS
xc_ddos_pro = true
Step 5: Git Add and Commit your changes
Step 6: Push your deploy branch to the forked repo
Step 7: Back in GitHub, navigate to the Actions tab of your forked repo and monitor your build
Step 8: Once the pipeline completes, verify your assets were deployed to AWS and F5 XC
Note: Check the terraform outputs of the bigip job for the randomly generated password for BIG-IP GUI access
F5 BIG-IP Terraform Outputs:
Step 9: Verify your app is available by navigating to the app domain FQDN you provided in the setup.
Note: The autocert process takes time. It may be 5 to 10 minutes before Let's Encrypt has provided the cert
F5 XC Terraform Outputs:
Step 1: From your deploy branch, check out a new branch for the destroy workflow using the following naming convention
Step 2: Push your destroy branch to the forked repo
Step 3: Back in GitHub, navigate to the Actions tab of your forked repo and monitor your workflow
Step 4: Once the pipeline completes, verify your assets were destroyed in AWS and F5 XC
In this article we have shown how to utilize the F5 Hybrid Security Architectures GitHub repo and CI/CD pipeline to deploy a tiered security architecture utilizing F5 XC WAF and BIG-IP Advanced WAF to protect a test web application. We applied advanced BOT and DDoS protection at the Edge and traditional Application Security next to our application. While the code and security policies deployed are generic and not inclusive of all use-cases, they can be used as a steppingstone for deploying F5 based hybrid architectures in your own environments.
As workloads are increasingly being deployed in various environments and application architectures, it has become vital for organizations to safeguard their critical applications, regardless of their deployment or architecture. It is equally essential to deploy these protections swiftly and flexibly, just like the applications they are protecting. By utilizing the F5 WAF portfolio in conjunction with DevSecOps principles, organizations can deploy and maintain industry-leading security without affecting the time-to-value of their applications. Edge and Shift Left principles can coexist to offer a more efficient security solution.
F5 Hybrid Security Architectures (Intro - One WAF Engine, Total Flexibility)
F5 Hybrid Security Architectures (Part 1 - F5's Distributed Cloud WAF and BIG-IP Advanced WAF)
F5 Hybrid Security Architectures (Part 2 - F5's Distributed Cloud WAF and NGINX App Protect WAF)
F5 Hybrid Security Architectures (Part 3 - F5 XC API Protection and NGINX Ingress Controller)
F5 Hybrid Security Architectures (Part 4 - F5 XC BOT and DDoS Defense and BIG-IP Advanced WAF)
For further information or to get started:
An Application Programming Interface (API) is a component that enables communication between two different systems by following certain rules. It also adds a layer of abstraction between the two systems where the requester does not know how the other system has derived the result and responded back.
Over the past few years, developers have started relying more on APIs as it helps them to meet the needs of today’s rapid application deployment model.
As the APIs started getting a wider acceptance it is highly critical to safeguard them by thoroughly testing their behavior and following best security practices.
The OWASP API Security project aims to help the organizations by providing a guide with a list of the latest top 10 most critical API vulnerabilities and steps to mitigate them.
As part of updating the old OWASP API Security risk categories of 2019, recently OWASP API Security Top 10 2023 RC is being released.
API1:2023 Broken Object Level Authorization
Broken Object Level Authorization (BOLA) is a vulnerability that occurs when there is a failure in validation of user’s permissions to perform a specific task over an object which may eventually lead to leakage, updation or destruction of data.
To prevent this vulnerability, proper authorization mechanism should be followed, proper checks should be made to validate user’s action on a certain record and security tests should be performed before deploying any production grade changes.
API2:2023 Broken Authentication
Broken Authentication is a critical vulnerability that occurs when application’s authentication endpoints fail to detect attackers impersonating someone else’s identity and allow partial or full control over the account.
To prevent this vulnerability, observability and understanding of all possible authentication API endpoints is needed, re-authentication should be performed for any confidential changes, multi-factor authentication, captcha-challenge and effective security solutions should be applied to detect & mitigate credential stuffing, dictionary and brute force type of attacks.
API3:2023 Broken Object Property Level Authorization
Broken Object Property Level Authorization is one of the new risk categories of OWASP API Security Top 10 2023 RC. This vulnerability occurs when a user is allowed to access an object’s property without validating his access permissions.
Excessive Data Exposure and Mass Assignment which were in OWASP APISec 2019 are now part of this new vulnerability.
To prevent this vulnerability, access privileges of users requesting for a specific object's property should be scrutinized before exposure by the API endpoints. Use of generic methods & automatically binding client inputs to internal objects or code variables should be avoided and schema-based validation should be enforced.
API4:2023 Unrestricted Resource Consumption
Unrestricted Resource Consumption vulnerability occurs when the system’s resources are being unnecessarily consumed which could eventually lead to degradation of services and performance latency issues. Although the name has changed, the vulnerability is still the same as that of Lack of Resources & Rate Limiting.
To prevent this vulnerability, rate-limiting, maximum size for input payload/parameters and server-side validations of requests should be enforced.
API5:2023 Broken Function Level Authorization
Broken Function Level Authorization occurs when vulnerable API endpoints allow normal users to perform administrative actions or user from one group is allowed to access a function specific to users of another group.
To prevent this vulnerability, access control policies and administrative authorization checks based on user’s group/roles should be implemented.
API6:2023 Server-Side Request Forgery
After finding a place in OWASP’s Top 10 web application vulnerabilities of 2021, SSRF has now been included in OWASP API Security Top 10 2023 RC list as well, showing the severity of this vulnerability.
Server-Side Request Forgery (SSRF) vulnerability occurs when an API fetches an internal server resource without validating the URL from the user. Attackers exploit this vulnerability by manipulating the URL, which in turn helps them to retrieve sensitive data from the internal servers.
To overcome this vulnerability, Input data validations should be implemented to ensure that the client supplied input data obeys the expected format. Allow lists should be maintained so that only trusted requests/calls will be processed, and HTTP redirections should be disabled.
API7:2023 Security Misconfiguration
Security Misconfiguration is a vulnerability that may arise when security best practices are overlooked. Unwanted exposure of debug logs, unnecessary enabled HTTP Verbs, unapplied latest security patches, missing repeatable security hardening process, improper implementation of CORS policy etc. are a few examples of security misconfiguration.
To prevent this vulnerability, systems and entire API stack should be maintained up to date without missing any security patches. Continuous security hardening and configurations tracking process should be carried out. Make sure all API communications take place over a secure channel (TLS) and all servers in HTTP server chain process incoming requests. Cross-Origin Resource Sharing (CORS) policy should be set up properly. Unnecessary HTTP verbs should be disabled.
API8:2023 Lack of Protection from Automated Threats
Lack of Protection from Automated Threats is also a new addition to the list of API vulnerabilities as now-a-days, APIs are easily becoming victims of automated attacks. By keeping automation to work, attackers can smartly use multiple IP addresses and Geo locations to bypass traditional protection mechanisms like rate limiting.
APIs inefficiency in detecting automated attacks may cause serious harm for businesses as it can adversely impact the services for real users as well.
To overcome this vulnerability, enterprises need to have a platform to identify whether the request is from a real user or an automated tool. Captcha and device fingerprinting also help to mitigate the attack.
For more details on automated threats, you can visit OWASP Automated Threats to Web Applications
API9:2023 Improper Inventory Management
Improper Inventory Management vulnerability occurs when organizations don’t have much clarity on their own APIs as well as third-party APIs that they use and lack proper documentation.
Unawareness with regards to current API version, environment, access control policies, data shared with the third-party etc. can lead to serious business repercussions.
Clear understanding and proper documentation are the key to overcome this vulnerability. All the details related to API hosts, API environment, Network access, API version, Integrated services, redirections, rate limiting, CORS policy should be documented correctly and maintained up to date. Documenting every minor detail is advisable and authorized access should be given to these documents. Exposed API versions should be secured along with the production version. A risk analysis is recommended whenever newer versions of APIs are available.
API10:2023 Unsafe Consumption of APIs
Unsafe Consumption of APIs is again a newly added vulnerability which occurs when developers tend to apply very little or no sanitization on the data received from third-party APIs.
To overcome this, we should make sure that API interactions take place over an encrypted channel. API data evaluation and sanitization should be carried out before using the data further. Precautionary actions should be taken to avoid unnecessary redirections by using Allow lists.
F5 Distributed Cloud (F5 XC) has a wide range of solutions for deploying, managing and securing application deployments in different environments.
XC WAAP is a F5 SaaS offering. The 4 key components of WAAP are Web Application Firewall, API Security, Bot Defense, DDoS Mitigation. All these solutions are powered on top of the XC platform. In addition to WAAP, F5 XC has other solutions to offer such as Fraud and Abuse, AIP, CDN, MCN, DNS and so on.
API security in XC WAAP simplifies operations with automated discovery of API transactions using AI/ML Engine along with insights of performance. It also provides API protection features like Rate Limiting, PII safeguard along with comprehensive security monitoring GUI dashboard. API security provides feasibility to import the inventory file in the form of swagger which helps to know exactly what endpoints, methods and payloads are valid, and this tightens security against abuse.
F5 XC management console helps the customers to leverage the benefit of monitoring, managing, and maintaining their application’s traffic from a single place irrespective of its platform on which it is hosted, it could be multi-cloud, on prem or edge.
This is an initial article covering the overview of proposed most critical API vulnerabilities from OWASP API Security community for 2023.
More articles covering detailed insight of each vulnerability and their mitigation steps using F5 XC platform will follow this article in coming days.
Meanwhile, you can refer to overview article for OWASP API Security Top 10 2019 which contains link to detailed articles covering API vulnerabilities of 2019 and how F5 XC can help to mitigate them.
What if I told you F5 is making F5 Distributed Cloud Services even easier to consume?
Do you want to step up and accelerate your security initiatives?
F5 Distributed Cloud Services are SaaS-based security, networking, and application management solutions that enable our customers to deploy, secure, and operate their applications in cloud-native environments wherever needed: data center, hybrid- or multi-cloud, or the network and enterprise edge.
But what if you don’t have the resources and/or manpower to manage the SaaS Service yourself? Or you want F5’s World-Class Team to setup and manage some or all these services for you?
F5 now offers four managed services for you to take advantage of to protect your infrastructure and applications.
I’ll take a quick look into each service, and then give you all the information you need to get started consuming these services.
F5 Distributed Cloud DDoS Mitigation leverages a globally secured network with Regional Edges (RE), hosted in scrubbing data centers, interconnected across a dedicated, multi-terabit, redundant, private backbone, operated by Tier 1 Carriers. Our highly available, global scrubbing centers and network reduce the risk of a single scrubbing center from being overwhelmed by intercepting traffic closer to the source of the origin of the DDoS attacks. The current list of scrubbing centers and operational status is available at F5 Distributed Cloud Status
F5 Distributed Cloud Web Application Firewall (WAF) is a SaaS delivered managed service that detects and mitigates general, automated, and application-specific security threats. The managed WAF service protects organizations’ internet facing web applications and data, and enforces compliance with industry security standards, such as PCI DSS. Managed WAF includes WAF, API and signature-based Bot. The service is supported by highly specialized, application security experts in the global F5 Security Operation Center (SOC) which is staffed 24/7. The managed WAF service is delivered via our global network with 23 Regional Edges (RE) in 22 metro markets.
Bot Defense protects your Internet Applications from automated attacks by identifying and mitigating malicious bots.
On the client, Bot Defense uses JavaScript or native Mobile SDK to collect telemetry. This telemetry is then attached in the form of HTTP headers or included in the POST body to the protected requests.
On the server, protected requests are configured to be examined by the Bot Defense solution before being permitted to reach the customer’s application.
Once Bot Defense is enabled and configured, you can view and filter traffic and transaction statistics with the Bot Defense Dashboard in Distributed Cloud Console to see which users are malicious and how they’re being mitigated.
App Infrastructure Protection (AIP) provides runtime infrastructure visibility across the host, container, and cloud control plane to monitor for, detect, and respond to security incidents. The AIP Cloud Security Platform offers a single source for security observability across your cloud infrastructure stack. Simply integrate your cloud environment with AIP and deploy a lightweight agent onto your servers and you’ll get instant visibility into any anomalous, risky, or non-compliant activity. The AIP Cloud Security Platform is completely customizable to your environment, so you can tailor it to your risk and compliance requirements. The agent supports linux, windows, and AWS Fargate (serverless) workloads.
Combining rules and machine learning to detect threats in real time across the entire infrastructure stack – cloud provider APIs, virtual machine instances, containers, and Kubernetes – AIP uses behavioral analysis to identify insider threats, external threats, and data loss risk for modern applications.
People oftentimes delay or do not implement solutions they know they need, either due to lack of resources and/or experience. F5 now makes is easy to protect your infrastructure with managed services.
Try these Simulators Bot Defense or DDoS to easily get started, and contact your Account Team, or Click Here to submit a request to get started with F5 Distributed Cloud Managed Services.
https://www.f5.com/cloud/products/managed-services#
F5 Distributed Cloud DDoS Mitigation – Managed Service
F5 Distributed Cloud WAF – Managed Service
F5 Distributed Cloud Bot Defense – Managed Service
F5 Distributed Cloud Advanced Infrastructure Protection (AIP) – Managed Service
F5 Distributed Cloud – F5 XC for short – has a robust alerting mechanism with a wide range of different alert types. Most alerts are generated because something unexpected has occurred, but alerts are also generated for what is considered normal activity.
As an example, when a new user is created in F5 XC to provide access to the console, an alert is generated, and the same thing happens when a user is updated or deleted.
Examples of alerts that are generated when something unexpected happens range from F5 XC login failures to an excessive number of web application firewall attacks to a pod in the virtual Kubernetes layer (vk8s) of F5 XC crash looping and everything in-between.
F5 XC alerts are categorized by severity in to minor, major and critical. Alerts are also named, and a few examples are WAFTooManyAttacks, UserCreated and SiteCertificateExpiration
Additionally, alerts are also divided into groups such as security, infrastructure, user access management and others. As examples, the alerts WAFTooManyAttacks and MaliciousUserDetected are both in the security alert group and SiteCertificateExpiration is part of the infrastructure alert group.
While F5 XC has a robust alerting mechanism, users must either view them in the alerts dashboard of the console or make API calls to retrieve the alerts.
Instead of having to periodically check the alerts dashboard or make API calls, F5 XC provides a mechanism to send alert notifications to an external system – which is called an alert receiver. The alert receivers supported are Email, Slack, OpsGenie, SMS and PagerDuty. By configuring one or more of these receivers, customers can integrate F5 XC alerts with alerts from other systems in their environment.
The following walkthrough video steps through the process of configuring F5 XC to send alert notifications to PagerDuty. The video covers the steps in detail; the process is fairly straightforward.
By configuring F5 XC to send alert notifications, customers that use PagerDuty can include these alerts as part of their escalation policies and workflows, allowing them to consolidate F5 XC alerts along with those generated by other systems in their environment.
Check it Out
This video provides a step-by-step walkthrough of how to configure F5 Distributed Cloud to send alert notifications to PagerDuty
Additional Links
F5 Distributed Cloud (XC) Services
F5 XC PagerDuty Alert Receiver Configuration
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).
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.
When you select a Namespace that has been configured with Protected Applications you will see this page.
Scroll down to Manage
The Protected Application page is presented.
Enter:
Scroll to the bottom and Click Save and Exit
That will take you back to the Protected Applications Page.
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.
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.
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.
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
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.
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.
This Learning Path article will serve as your guide to content that will build your skills in Multi-Cloud Networking. The content is organized starting with Foundational Topics to get you familiar with concepts. This is followed by content that will help you with Basic Configuration. After that, there is content listed for specific Use Case Configurations.
This Learning Path is a living document and will be updated as new content is developed.
What is Multi-Cloud Networking?
What is Multi-Cloud Networking - Brightboard Lesson
F5 Distributed Cloud Multi Cloud App Demo - Video
Experience F5 Distributed Cloud with Multi-Cloud Sites and Distributed Apps
Demo Guide & Video Series for F5 Distributed Cloud Network Connect (Multi-Cloud Networking)
Build It Live! - Multi-Cloud Networking Live Streams
Building an F5 Distributed Cloud Customer Edge, from Hawaii! - Video
Multi-Cloud Networking Demo Guide - Github Repo
Using F5 Distributed Cloud private connectivity orchestration for secure multi-cloud infrastructure
Using F5 Distributed Cloud Service Transit to route & secure private cloud environments
When using F5 Distributed Cloud Platform, never deal with Site to Site IP conflicts again!
Using F5 Distributed Cloud private connectivity orchestration for secure multi-cloud infrastructure
Governance and Automation - Distributed Apps for Hybrid Cloud Architecture
Protect an application spread across several locations with F5 XC WAAP and Multi-Cloud Networking
In the early 90’s, applications were in dormant phase and JavaScript & XML were dominating this technology. But in 1999, the first web application was introduced after the release of the Java language in 1995. Later with the adoption of new languages like Ajax, HTML, Node, Angular, SQL, Go, Python, etc. and availability of web application frameworks have boosted application development, deployment, and release to production. With the evolving software technologies, modern web applications are becoming more and more innovative, providing users with a grand new experience and ridiculously ease of interface. With these leading-edge technologies, novel exploit surfaces are also exposed which made them a primary target for intruders/hackers. Application safeguarding against all these common exploits is a necessary step in protecting backend application data. Open Worldwide Application Security Project (OWASP) is one of those security practices which protects application with above issues. This article is the first part of the series and covers OWASP evolution, its importance and overview of top 10 categories.
Before diving into OWASP Web Application Security Top 10, let’s time travel to era of 1990’s and try to identify challenges the application customers, developers and users were facing. Below are some of them:
After running into the above concerns, people across the globe have come together in 2001 and formed an international open-source community OWASP. It’s a non-profit foundation which has people from different backgrounds like developers, evangelist, security experts, etc. The main agenda for this community is to solve application related issues by providing:
With the rapid increase of cyber-attacks and because of dynamic report updates, OWASP gained immense popularity and is considered as one of the top security aspects which application companies are following to protect their modern applications against known security issues.
Periodically they release their Top 10 vulnerabilities report and below are the latest Top 10 - 2021 categories with their summary:
Access controls enforce policy such that users cannot act outside of their intended permissions. Also called authorization, it allows or denies access to your application's features and resources. Misuse of access control enables unauthorized access to sensitive information, privilege escalation and illegal file executions.
Check this article on protection against broken access vulnerabilities
In 2017 OWASP top 10 report, this attack was known as Sensitive Data Exposure, which focuses on failures related to cryptography leading to exposure of sensitive data.
Check this article on cryptographic failures
An application is vulnerable to injection if user data and schema is not validated by the application. Some of the common injections are XSS, SQL, NoSQL, OS command, Object Relational Mapping (ORM), etc., causing data breaches and loss of revenue.
Check this article on safeguarding against injection exploits
During the development cycle, some phases might be reduced in scope which leads to some of the vulnerabilities. Insecure Design represents the weaknesses i.e., lack of security controls which are not tracked in other categories throughout the development cycle.
Check this article on design flaws and mitigation
This occurs when security best practices are overlooked allowing attackers to get into the system utilizing the loopholes. XML External Entities (XXE), which was previously a Top 10 category, is now a part of security misconfiguration.
Check this article on protection against misconfiguration vulnerabilities
Applications used in enterprises are prone to threats such as code injection, buffer overflow, command injection and cross-site scripting from unsupported, out of date open-source components and known exploited vulnerabilities. Utilizing components with security issues makes the application itself vulnerable. Intruders will take use of this defects and exploit the deprecated packages thereby gaining access to backend applications.
Check this article on finding outdated components
Confirmation of the user's identity, authentication, authorization and session management is critical to protect applications against authentication-related attacks. Apps without valid authorization, use of default credentials and unable to detect bot traffic are some of the scenarios in this category.
Check this article on identifying and protection against bots
Software and data integrity failures occurs when updates are pushed to the deployment pipeline without verifying its integrity. Insecure Deserialization, which was a separate category in OWASP 2017, has now become a part of this larger category set.
Check this article on software failures protection
As a best recommendation, we shall always log all incoming request details and monitor application for fraudulent transactions, invalid logins, etc. to identify if there are any attacks or breaches. Applications without logging capabilities provide opportunities to the attackers to exploit the application and may lead to many security concerns. Without logging and monitoring we won’t be able to validate the application traffic and can’t identify the source of the breach.
Check this article for identifying logging issues
Server-Side Request Forgery (SSRF) attack is a technique which allows intruders to manipulate the server-side application vulnerability and make a malicious request to the internal-only resources. Attacker exploits this flaw by modifying/crafting a URL which forces the server to retrieve and disclose sensitive information.
Check this article which focusses on SSRF mitigation
NOTE: This is an overview article of this OWASP series, check the below links to prevent these vulnerabilities using F5 Distributed Cloud Platform.
OWASP Web Application Security Series:
It wasn't too long ago that we saw Next Generation FireWall (NGFW) companies telling potential buyers that a Web Application Firewall (WAF) was unnecessary if you had a NGFW. These days, thankfully, most security professionals are educated enough to understand that a WAF - and really, WAAP today - is a critical component of a modern application infrastructure for just about any organization that needs to expose an application for consumption - whether external or internal.
So, what is WAAP? It is an evolution of the WAF, conceptually and it stands for Web Application & API Protection (WAAP). It is similar to WAF in that the primary focus is to defend against layer 7 attacks - slowloris, brute force, L7 DOS, etc. - and also to provide protocol enforcement at layer 4. Another similarity is that both WAF and WAAP focus on the OWASP Top 10 as a framework for development. The glaring difference between the two is the necessitated inclusion of the OWASP Top 10 for APIs, as it is estimated that some 80% of the internet's traffic is now API related. WAAP has an understood bot defense component, as well. In the days of WAF, this was not as prevalent, but I think we all know that bot traffic is nothing short of explosive these days.
The challenges that WAAP looks to resolve are a bit different than WAF, as you can imagine. One of the first issues is API awareness. With virtualization, we learned some lessons around sprawl. We see similar behaviors in cloud adoption today, as so many companies have found with their bottom-line cloud spending. So often, an API is developed and used and replaced, then left open and forgotten... a gaping risk for the foreseeable future.
Another challenge is business logic. With traditional data center firewalls, we protected the ip and port, but the business logic was always enforced on the application, itself. Firewalling an application is quite a bit different, as the minutia of how the application applies limits to defend the business become an enforcement point, rather than an irrelevant data point. Put more simply, we must defend those pieces of the application that are able to impact the overall business. APIs have glaringly been a way to manipulate business logic in ways that can really impact a business or brand. If we think about the rash of reseller bots in the past few years and what that has meant for concertgoers, comic-nerds and shoe-heads, alike, we see this damage in the headlines.
Then, there's the big one (heh)... volumetric attacks. This is a problem in SO many ways. Not only does it have the potential to diminish valuable system and network resources, but it is also the most common way to 'provide air cover' for some of the more intelligent application-level attacks. It does this by making system and network logs almost unreadable by security response engineers during an attack.
Lastly - and this is a big one - is security management. With more complex infrastructures and cloud resources to account for, our computing environments have become SO much more diverse. Mature organizations will have a mixture of monolithic and modern applications running. Not only do we need to be cognizant of our virtual infrastructures, but also our more modern containering environments. How many clouds? Does it feel like all of them? Learning the ins and outs of security tools in all of those different application environments is nearly impossible for existing staff and spending on expertise in personnel is... difficult? At best.
These challenges are tremendous, but WAAP, as a solution, provides tremendous 'bang for the buck' ratios for the types of attacks we see on the open internet today. Firstly, WAAP provides an awareness of applications and APIs. We need to custom tailor our solutions around what web server is being used, what database the application relies on, what functions an API endpoint might expose and so much more. With regards to APIs, we also need to have a way to discover APIs in our environments. All of this understanding allows for granular control and constraint of each application we secure.
Another solution is the concept of a managed ruleset and policy layering for our applications. With the aforementioned sprawl that is inherent with modern, distributed applications and even with monolithic applications that span many environments, we see a common theme, with regards to management: Division of responsibility is a brilliant way to overcome. With the ability to layer policies at various points in the journey of a packet within our environments, we can have an individual or team manage global policies, while another group of people divide microservice-specific responsibilities and even another could manage geographical security needs. Layers... through the application.
As a final thought, there are some specific advantages with the F5 Distributed Cloud WAAP offering. You get a high-speed fabric for application ingress that is unattainable by most organizations, out of the box. The platform is completely managed, so worries about global availability and infrastructure uptimes can be a thing of the past. You just need to worry about administering the security of it... which can also be managed by F5. Finally, a unified platform for application visibility is a very powerful benefit. Having the flex to use bot defense or DoS protection or endpoint-specific defenses based on the client to application traffic flows as they happen is an amazing power to be given, as a front-line security practitioner or even as a CISO. You can watch our journey to put it to community use here on our 'Build It Live' live stream:
https://youtube.com/playlist?list=PLyqga7AXMtPMdKtr9vGnW1ORibl2PNe5l
When Gartner announced their decision to throw in the towel on the WAF magic quadrant and focus, more conceptually, on WAAP, I must admit... I was skeptical of the need for change at first. Years later, I completely get it. As we witness more and more applications rising up and out of the data center, I get it. As we witness applications that are really made up of hundreds of other tiny applications begin to dominate the technology landscape on the open internet, I get it. APIs and cloud present completely different challenges to and solutions for all of our security professionals - our front-line security operations people all the way up to the CISO. WAAP is the logical evolution of WAF, as a concept, which can help us meet the majority of our modern data security challenges with a real solution.
In the introductory article and subsequent series (overview) we have demonstrated how F5 Distributed Cloud Web App and API Protection (WAAP) has prevented OWASP Top 10 API Security risk categories of 2019 with demonstration. This article is the continuation of this series, demonstrating how to mitigate Improper Assets Management vulnerabilities using F5 Distributed Cloud Platform.
A vulnerability that appears when multiple services are left over to an old API version, unprotected, giving access to the attackers to get the sensitive information from the application database.
Modern applications require fast iteration through the development cycle and sometime old artifacts, such as APIs, are not properly phased out. For example, while the new API (app.service.com/v2) is created, the old API (app.service.com/v1/admin) is deprecated but still available and unprotected by a WAF, provides access to the attacker to get sensitive information of database.
In this demonstration, we will see how F5 XC helps to patch the above vulnerability and protect the overlooked, unprotected older versions of APIs (Application Programming Interfaces) from the attackers.
Here is the procedure to configure API Protection rules in the load balancer and associate the LB (Load Balancer) to the origin pool (backend application – app.service.com).
As you can see from the demonstration, the F5 Distributed Cloud WAAP has successfully able to detect and mitigate the vulnerabilities on API endpoints using API protection rules.
For further information click the links below:
Subject | Author | Posted |
---|---|---|
24-May-2023 01:13 | ||
24-May-2023 01:11 | ||
16-May-2023 06:22 | ||
16-May-2023 05:57 | ||
16-May-2023 02:25 |
An open group to foster discourse around the integration of security, networking, and application management services across public/private cloud and network edge compute services.
User |
---|
Michael_Allen
![]() F5 Employee
|
Sanjay_Shitole
![]() F5 Employee
|
AlsDevC
![]() Altocumulus
|
Kevin_Davies
![]() MVP
|
Michael_Saleem
![]() Cirrocumulus
|