Mitigating OWASP Web Application Insecure Design using F5 BIG-IP Advanced WAF
This article provides OWASP Top 10 Insecure Design caused due to improper planning, logic in the application. These risks allows Web crawlers, automated bots etc. to cause web scraping attack. This article also provides mitigation steps by F5 BIG-IP using Advanced WAF protection.Displaying Application Study Tool (AST) Dashboards in Your Own Grafana Instance
The Application Study Tool (AST) has its own Prometheus and Grafana instances. These instances run as containers and are designed to coexist with other Prometheus and Grafana instances in your environment, even on the same host. However, during demos and discussions with customers, many have expressed the desire to use their existing Grafana instance to display AST dashboards. Although it may not be obvious to new Grafana users, this process is straightforward. This blog will walk you through launching a second generic Grafana container instance, connecting it to the AST instance of Prometheus (the data source), importing a dashboard from the AST instance of Grafana, and displaying it in the new Grafana instance. If you already have a non-AST instance of Grafana running in your environment, the steps to launch a second Grafana container are optional. However, you may want to run it in order to test the import functionality and make your own customizations before importing it again into your “production” Grafana instance. Here is an example of a dashboard folder in a non-AST Grafana instance after importing three dashboards from AST: Launch a Second (Generic) Grafana Container If you already have a Grafana instance, you may skip this step. However, if you don’t, or you would like to use a “sandbox” for testing customizations before importing the dashboard into your “production“ Grafana instance, you can use the following steps to launch a new Grafana container. The following assumptions are made for the steps that follow: You are using Docker as your container runtime. (If you are using Podman, simply substitute “podman” for “docker” in each of the following commands. Other container runtimes may also work for this exercise, but I have not tested them.) You have sufficient privileges to run containers. If you don’t, you may need to run these commands with “sudo”. If that fails due to permissions errors, you will need to request the necessary privileges from your Linux administrator. We want to run Grafana version 11.5.2. Any recent version should work. However, this is the latest version as of the writing of this blog. The IP address of the host where you are running these containers is 192.168.0.15. Yours will likely be different. Use your own host’s IP when you run “curl” inside the grafana2 container. In my testing, I used MacOS. This will also work on any current Linux distribution and should work on Windows. First, launch the Grafana container. I set this new instance of Grafana to listen on port 3002 (the default for Grafana is 3000) to avoid conflicts with the AST instance, if they are running on the same host. $ docker run -d --name=grafana2 -p 3002:3000 grafana/grafana:11.5.2 Next, exec into the container to ensure it can connect to the AST instance of Prometheus. You can instead check connectivity from the Grafana UI, but the below method is a good way to troubleshoot any connectivity errors you may encounter. $ docker exec -it grafana2 bash You are now running a Bash shell inside the new Grafana container. Run a curl command to confirm the new Grafana container can reach the Prometheus application, which listens on port 9090, by default. (The IP address, 192.168.0.15, is used as an example. Use your own host's IP address here.) 5d3e8256af3d:/usr/share/grafana$ curl 192.168.0.15:9090 <a href="/graph">Found</a>. Now, it is time to test the new Grafana instance. Open a web browser and navigate to the host where this new Grafana container is running, at port 3002. If you are running on your local machine, it will be http://localhost:3002/. The default credentials are admin/admin. When first logging in, Grafana will prompt you to change the password. You may choose to change it now or click “skip” to leave it as is. Now you can export one of the dashboards from AST and import it into this instance. Export a Dashboard from AST Now that you have launched a second instance of Grafana (or you are running your own non-AST instance), it is time to import a dashboard from AST. You can import just one dashboard of your choosing (i.e., BigIP - Device Device >> Virtual Servers), or several (or even all) dashboards from AST. For this example, we will only import one dashboard, BigIP - Device Device >> Virtual Servers. If you wish to import other dashboards, the steps are the same. Navigate to the dashboard you would like to import into your Grafana instance. For the example used here, navigate to Dashboards >> BigIP – Device >> Device Virtual Servers. Click the blue "Share" button near the upper-right corner. In the pop-up box, click the Export tab. Click the blue "Save to file" button to download the JSON file representing the dashboard. Two notes: If you wish to use your own non-AST instance of Prometheus, you will need to move the slider for “Export for sharing externally” (available in the Share pop-up box, under the Export tab) to the right to enable it. This will allow you to select your own Prometheus instance as the data source when importing the dashboard into the alternate Grafana instance. The default JSON for these dashboards is also available in “dashboards” folder of the repo: https://github.com/f5devcentral/application-study-tool/tree/main/services/grafana/provisioning/dashboards. This version has the “Export for sharing externally” option enabled, so you will need to select the desired Prometheus data source – either your own or the AST instance – when importing the dashboard into the alternate Grafana instance. Import the Dashboard into the New (or Existing) Grafana Instance If you have just launched a new, generic Grafana container using the instructions in the above section, Launch a Second (Generic) Grafana Container, you can now launch the UI from a web browser by navigating to http://localhost:3002/ (assuming you are running on your local machine). The default login credentials are admin/admin. If this is just a temporary test instance, you may click “skip” when prompted to “Update your password”. (For a production instance or any instance that will be used more than just briefly, we recommend changing this to a stronger password.) If you are using an existing Grafana instance, navigate to it and log in. Connect the New Grafana Instance to the AST Prometheus Instance From this non-AST Grafana instance, verify the Prometheus data source is reachable from Grafana, and then connect to it by following these steps: In the menu bar on the left, click Connections >> Data sources. If this is a new instance of Grafana, the “Add data source” button will appear in the middle of the screen. If this is an existing instance with pre-existing data sources, the button will be in the upper-right corner of the screen and will say “Add new data source”. Click on it. Select Prometheus from the list of data sources. You may have to scroll down or enter “prometheus” in the search bar. Fill in a name (for example, “ast-prometheus”), and the URL to connect to the Prometheus instance. In my case, it was my host's private IP address, 192.168.0.15, and the port Prometheus is listening on (9090 by default): http://192.168.0.15:9090. Set the “Interval behaviour >> Scrape interval” to be the same as the value used for the collection_interval setting in your AST configuration. If you did not explicitly change it when configuring AST, it will be the default value of 60s. Click the blue "Save & test" button and ensure you get the message, “Successfully queried the Prometheus API” at the bottom of the screen. Import the Dashboard into the New Grafana Instance Click on “Dashboards” in the menu on the left. Click the blue “New” button in the upper-right and, from the drop-down, select "Import". Click on "Upload dashboard JSON file" and upload the JSON file you previously exported from the original AST dashboard. Give it a name (under Name). Under the Prometheus drop-down, select your Prometheus data source. (In the example above, it is called "ast-prometheus". If you accept the default name, it will just be “prometheus”.) Click Import. Voilà! You are now taken to the newly imported Grafana dashboard. Conclusion The Application Study Tool offers excellent observability for F5 BIG-IP systems and the traffic they handle. If you have your own Grafana instance with your own set of dashboards, there is no need to manage two separate instances. You can combine the two so you have all your dashboards in one place. The flexibility of Grafana also allows it to be highly customizable, so you can modify any of the out-of-the-box dashboards AST provides and even create your own. If you have gotten value from customizing some of the default AST dashboards, feel free to post what you did below, as many of our readers will find this valuable.Maintaining BIG-IP's Golden Compliance Configuration in Financial Services
For financial services organizations, demonstrating compliance is not just about satisfying auditors; it's about safeguarding trust in every transaction. By applying the strategies outlined in this article, teams can minimize configuration drift, maintain golden state readiness, and respond effectively to audits—even in high-pressure environments.Enhancing BIG-IP with F5 Distributed Cloud: Automated Service Discovery for Scalable Application Delivery and Security
The F5 Distributed Cloud Services (XC) feature called BIG-IP Service Discovery makes it easier to deliver and protect distributed applications on BIG-IP virtual servers. It does this by automatically finding them in an existing BIG-IP TMOS setup. Augmenting BIG-IP with F5 Distributed Cloud streamlines operations and maximizes efficiency. This makes it easier to change your network settings without having to do it yourself. It also makes it easier to manage global traffic, without having to worry about managing hardware across regions. Ensure application uptime with real-time health monitoring and automated service registration for seamless handling of ephemeral applications. Additionally, this accelerates deployment in new environments with high-speed discovery and one-click policy deployment. Simplify, scale, and secure your applications effortlessly with F5 Distributed Cloud Value delivered to BIG-IP deployments Service discovery unlocks the full potential of your BIG-IP deployments by extending them with F5 Distributed Cloud’s SaaS services. Customers gain centralized observability across multiple BIG-IP instances via the F5 Distributed Cloud Console, ensuring seamless visibility and control. It strengthens application security with advanced services like API Discovery and XC WAF while shifting the security perimeter to the F5 Global Network for superior defense against large-scale attacks. It also enables secure partner access with ease and simplifies application migration to public clouds to optimize BIG-IP resources. Technical details The feature requires the deployment of an F5 Distributed Cloud CE with reachability to the BIG-IP management and data interfaces. In the case of the F5 rSeries, the CE and BIG-IP can be deployed on the same hardware. See the reference architecture for details. For other BIG-IP hardware and virtual deployments, the CE can be deployed on any supported platform like VMWare, KVM, or bare-metal servers. The diagram below provides an overview of the solution in action: With the XC CE Site, you can securely access internal resources without exposing them to the internet, providing enhanced control and security. Once the XC Site is set up, configuring BIG-IP Service Discovery becomes straightforward. Before starting to configure Service Discovery, decide where the configuration will be. If BIG-IP is a dedicated resource managed by a single team, configure the Service Discovery object within the specific App Connect Namespace to ensure all resources are discovered in one namespace. This setup keeps the deployment isolated for use by a single team. Alternatively, for shared BIG-IP resources managed by different teams, configure the Service Discovery object in the Shared Configurations workspace. To begin with, create a new BIG-IP Service Discovery object from the XC Cloud portal. Then enter the BIG-IP Management IP and Username and click on Configure to add the Admin Password. This establishes communication between F5 XC Cloud and the BIG-IP deployment. In the Virtual Server Filter, you can fine-tune the discovery process by filtering Virtual Servers based on Name, Description, or Port Range. For instance, in this example: Name: Apply a regex filter using ^*app* to identify Virtual Servers containing the word "app" in their names. Port Range: Set the range to 8080-8090 to include only Virtual Servers operating within that specific port range. This flexible filtering mechanism allows you to target specific services for discovery, streamlining the load balancer configuration process. After applying the configuration, the Discovered Virtual Servers will appear in the interface. Keep in mind that it may take a few minutes for the system to load and display the Virtual Servers. Once they are listed, you can click on any of the discovered services to view detailed information After the Virtual Servers are discovered, it becomes possible to create an HTTP Load Balancer in just a few clicks. Simply provide a name, domain name, and SSL details, and the HTTP Load Balancer will be created and configured automatically. While the initial setup is quick and straightforward, you can further customize it later by adding advanced features such as enhanced security, high availability (HA), or a DMZ configuration to meet specific operational requirements. With HA, you will need to deploy an additional rSeries device with the same configuration to ensure redundancy and continuous availability. For a DMZ setup, a second data center is required to segregate external and internal traffic for added security. Once these components are in place, you can update the Origin Pool of the HTTP Load Balancer to include the new resources, ensuring a robust and scalable load balancing solution. The diagram below illustrates this configuration, showing how HA and DMZ work together with the HTTP Load Balancer to enhance reliability and security. Conclusion In this article, we walk through configuring BIG-IP Service Discovery to automatically discover Virtual Servers and create an HTTP Load Balancer to expose applications to the internet. Beyond the basic setup, we also implemented High Availability by adding a second rSeries device and introduced a DMZ deployment by including a second data center, ensuring a more resilient and secure architecture. More details on this feature and its configuration options are available in this technical documentation. Or you can view a demonstration of the feature and related use cases in this Teachable Course. With F5’s rSeries devices, you get the performance and scalability required to handle modern multi-cloud environments, while F5 Distributed Cloud simplifies management by providing centralized visibility and control. Elevate security, streamline operations, and future-proof your BIG-IP applications with F5 Distributed Cloud.How I did it - “Delivering Kasm Workspaces three ways”
Securing modern, containerized platforms like Kasm Workspaces requires a robust and multi-faceted approach to ensure performance, reliability, and data protection. In this edition of "How I did it" we'll see how F5 technologies can enhance the security and scalability of Kasm Workspaces deployments.
