Managing DMZ app servers behind the BigIP
Hey all, I'm just curious how some of you have designed your networks to load balance and secure your public apps, but still manage them with internal resources and tools (software, patching, security scans, etc.). Here's the scenario. BigIP has a switch hanging off of it, isolated DMZ environment, no other connection. Any web apps we're publishing we plug into that switch, build a virtual server, and we're off and running. Any resources the app server needs internally like DNS, directory services, etc. that it can initiate itself, it routes through the BigIP which has an internal network interface and a route built in for that comm. One of the issues is any connection initiated from the internal network cannot reach that app server unless we build a virtual server for each service (RDP, monitoring and patching which has multiple ports, security scans even more ports). That can;t be the right way to do it. I personally think we should have a seperate DMZ switch hanging off the firewall with a different interface on the app server dedicated to those management functions. It's much easier for me to write one rule in the FW for that access than create multiple VIPS for each server/service for management functions. Our BigIP is sitting along side our fw's today so any connections sourcing from the outside bypass those. I am toying with the idea of placing the BigIP behind the fw's once they;re replaced with more robust appliances but that has not happened yet. Just curious all, I appreciate the feedback. -GR
LTM - DMZ Routing
We have 2 VLANs setup for a specific partition on our LTM. One is for their production servers, the other is intended to act as a DMZ as there is a particular server that needs a lot of ports opened to it from the Internet. To reduce the security risk of opening so many ports to the production network, another VLAN was created for this server to sit on. However, this server still needs to access select devices on their production network, but only using 1 port. How can I allow communication from the server in the DMZ to specific devices on their production network? Is setting up Layer 4 virtual servers the only to acheive this without completely opening the communication between the two VLANs? Is there a way that I can allow communication between the 2 networks, but restrict what devices it has access to without creating a virtual server for every device this server needs to communicate with on the production network? Any assistance is appreciated. Thank you.Direction on how to connect LTM VE between internet and web server
I am interested in connecting a Big-IP LTM VE to the outside. Place web servers in the DMZ. Traffic from the outside hit F5 and traffic to pool of web servers will pass through a Firepower / Firewall. What I am not sure about is if I assign an interface on the LTM a public address and assign that address to mywebservers.org, when traffic hits that interface on the LTM how is it forwarded to the pool? Can I create a VIP for a self-ip address? The LTM is used internally. I SNAT, automap. Thanks in advance for any support. JohnA Guide to F5 Volumetric (Routed) DDoS Protection in F5 Distributed Cloud
Introduction F5 Volumetric (Routed) DDoS protection is a service in F5 Distributed Cloud (F5 XC) available for standard deployment and emergency use. F5 has over 100 engineers in its incident response team and 24/7 dedicated SOC analysts in 3 security operations centers around the world. This means F5 can help with the quick detection, mitigation, and resolution of Layer3-4 routed DDoS attacks. F5 Volumetric DDoS Protection stands out for several key reasons, especially for enterprises needing fully managed, hybrid, and multicloud-based DDoS mitigation with human-led and AI-assisted support. Here’s some of the ways Volumetric DDoS protection with F5 stands out: Fully Managed 24/7 Security Operations Center (SOC) F5’s SOC continuously monitors traffic for DDoS attacks in real time. Unlike purely automated solutions, human analysts intervene to fine-tune attack mitigation. The SOC provides expert-led response to mitigate complex or evolving threats. Hybrid Deployment Flexibility Cloud-based, always-on, or on-demand models for different use cases. Integrates with on-prem F5 BIG-IP solutions for a hybrid defense strategy. Helps reduce false positives by fine-tuning security policies. Advanced Attack Detection & AI-driven Mitigation Uses behavioral analytics to differentiate between legitimate traffic and attacks. Mitigates volumetric, application-layer, and multi-vector attacks. AI-assisted rules dynamically adapt to new attack patterns. Large-Scale Scrubbing Capacity Global scrubbing centers prevent volumetric DDoS attacks from overwhelming networks. Reduces the risk of downtime by filtering malicious traffic before it reaches critical infrastructure. F5 blocks volumetric DDoS attacks by denying offending /24 prefixes (via BGP) the ability to route to the Distributed Cloud scrubbing centers. (reference DevCentral) API-Driven and Customizable Security Policies Offers API integration for automated DDoS mitigation and security orchestration. Supports custom policies to protect specific applications from targeted attacks. Enterprise-Grade Support & Compliance Designed for large enterprises, financial institutions, and high-security industries. Meets compliance standards such as PCI DSS, GDPR, and SOC 2. Backed by F5’s global threat intelligence network. Logging & Observability Recently introduced is the capability to observe security events using external handlers via the Global Log Receiver (GLR) service. Organizations can use AWS S3 buckets, HTTP(s) servers, Datadog, Splunk, AWS CloudWatch, Azure Event Hubs and Blog Storage, Google Cloud Platform (GCP), Kafka Receiver, NewRelic, IBM QRadar, and SumoLogic, to store Distributed Cloud events. Then, they can use any platform to watch DDoS and other security events. If you’re curious how Distributed Cloud events look using ELK (Elasticsearch, Logstash, and Kibana), including how to set it up, see this related article in DevCentral. To configure Distributed Cloud to send events from Global Log Receiver, log in to the Distributed Cloud console and navigate to Shared Configuration > Manage > Global Log Receiver. Add a new item, and ensure the following: Log Type: Security Events Log Message Selection: Select logs from all namespaces For this example, I use Distributed Cloud App Connect to securely deliver events to an instance of ELK Stack running on AWS. To deliver the events locally with internal networking between Distributed Cloud and ELK Stack, I use a Customer Edge (CE) appliance, also in AWS. Having the CE deployed locally provides a secure endpoint with only local routing in the AWS VPC. ➡️ See the following documentation for how to deploy a CE in AWS. Next is to use App Connect with an HTTP Load Balancer. In this case, the origin pool is my ELK Stack receiver, and I’ve configured ELK to receive events over HTTP. Because I’ve configured the HTTP Load Balancer to be publicly available on the Internet to accept traffic from the Global Log Receiver, a Service Policy has been configured to restrict access to specific IP ranges. Although not shown, only traffic from the F5 Global Log Receiver designated IP ranges is allowed to access this load balancer. ➡️ See the following Allowlist reference documentation to learn which IP addresses to allow. To receive and process events in ELK, I’ve configured the following for logstash: root@3c99db3fa334:/etc/logstash/conf.d# cat 50-f5xc-logs.conf input { http { port => 8080 } } filter { json { source => "message" } } output { elasticsearch { hosts => ["localhost"] index => "f5xc-logs-%{+YYY.MM.dd}" } } In the ELK console, new messages are visible under Analytics > Discover. With messages arriving from GLR, we can now see many of the fields becoming searchable in the “message_parsed” hierarchy. Volumetric (Routed) DDoS events appear in the field “sec_event_type” with value “routed_ddos_sec_event”. The following alert and mitigation messages may be classified and searched as follows: New ongoing alert msg = “alert created” no “alert_ended_at” field present New and already completed alert msg = “alert created” alert_ended_at field present Completed ongoing alert msg = “alert completed” alert_started_at field present alert_ended_at field present New ongoing mitigation msg = “mitigation created” mitigation_ongoing = true no “mitigation_stop_time” field present New and already-completed mitigation msg = “mitigation created and completed” mitigation_ongoing = false migitation_stop_time field present Completed mitigation msg = “mitigation completed” mitigation_ongoing = false “mitigation_stop_time” field present Putting it all together in ELK, it’s easy to visualize each routed_ddos_sec_event with a filtered dashboard. Using the pie visual below allows security admins to decide what type of attacks have happened and whether any are still occurring. The dashboard visual can be added to other existing security dashboards in Kibana to provide a complete and robust overview of your security posture. Demo The following video further illustrates the capabilities of Volumetric (Routed) DDoS protection in Distributed Cloud. In it, I walk through the different ways protection can be activated and what some of the mitigation events and alerts look like in the console. 🎥 YouTube: https://youtu.be/jYiqog_tz2I Conclusion F5 Volumteric (Routed) DDoS protection combines integrated services to provide core-protect, auto-mitigation, security-analyst-initiated mitigations, and advanced deep packet inspection and filtering to provide the best protection available for Layer-3 and Layer-4 routed networking. Adding routed DDoS to networks is a simple onboarding process. F5 also provides emergency DDoS mitigation for customers who are actively being attacked. Observing DDoS attacks is not only available in the Distributed Cloud console but is also available directly in your monitoring platform of choice when using Global Log Receiver. Additional Resources 🎥 YouTube: Tour of Routed (Layer3 & Layer4) DDoS Protection in F5 Distributed Cloud How I did it - "Remote Logging with the F5 XC Global Log Receiver and Elastic" Deploy Secure Mesh Site v2 in AWS (ClickOps) Firewall and Proxy Server Allowlist Reference How To: Configure Global Log Receiver
Guidance setting up a DMZ proxy for Citrix ShareFile
I am looking into setting up our F5 as the DMZ proxy for Citrix ShareFile. I have seen some discussions about some setting it up as an SAML IdP, (with issues with SLO). Is an IdP necessary as part of the proxy for ShareFile? Does anyone else have experience using F5 APM with ShareFile or can point to some F5 documentation for this? Thanks in advance for your help,Scale Your DMZ with F5 Distributed Cloud Services
Modern DMZ Challenges The task of securing and optimizing DMZ (Demilitarized Zone) environments is becoming increasingly complex. A traditional DMZ is a physical or logical subnetwork that contains and exposes an organization’s external-facing services to an untrusted network, typically the internet. It serves as a buffer zone between the secure internal network and external networks, providing an additional layer of security to ensure that potentially malicious traffic does not reach critical internal systems directly. To make data center applications accessible on the internet, IT teams traditionally handle several DMZ-related networking operations, including: NAT (Network Address Translation): Converting public IP addresses to private server IPs. DNS Resolution: Ensuring domain names resolve to the correct IP addresses. Load Balancing: Distributes incoming application traffic across multiple servers to ensure reliability, optimal resource utilization, and high availability Security Operations: Deploying protections such as Web Application Firewalls (WAF) and Distributed Denial of Service (DDoS) mitigation. With modern microservices-based and API-rich applications handling these DMZ operations at the App Services tier (see highlighted in blue below) or on a per-application basis adds complexity, resulting in some additional challenges impacting app delivery, such as: Management and “stitching” of multiple app DMZ environments at scale Standardized, consistent policy across overall data center deployments Handling unwanted traffic (bad actors and bots) at the global services tier The end result is that modern DMZ requirements need to keep pace with modern microservices-based API-heavy app architectures. Without uniform security or visibility when managing multiple sites across several datacenters or clouds, organizations struggle to maintain visibility and enforce security at scale. Scalable DMZ Solution F5 Distributed Cloud (XC) Services address the modern DMZ challenges by centralizing networking and security functions at the network edge. This includes volumetric DDoS protection, API protection, and Bot mitigation as part of WAF configurations at the network edge. All of this is enabled through the configuration and operation of a Customer Edge (CE) in various on-premises environments, such as VMWare, OpenShift, Nutanix, or F5’s own rSeries appliances. This results in a “separation of duties” for the App Services Tier and Global Services Tier as follows: (1) Global Services Tier Keeps unwanted traffic off your infrastructure Broad-spectrum volumetric DDoS mitigation (L3/L) Anti-abuse, including bot/fraud detection and mitigation Ease of securely exposing applications to the public internet by simplifying or eliminating manual handling of routing and other networking tasks Simplifying workflows for pushing out App DMZ toward the network edge Standard company app security policy / policies used by all apps (2) App Services Tier Retains important / integrated security controls and policy, including automation and CI/CD pipelines at your app Workload-specific security policy definitions and enforcement Closest to the application and Line of Business / security teams managing specific app services Building a Scalable DMZ The configuration described below follows the detailed guide in the F5 Devcentral GitHub repo, which provides steps for creating a secure DMZ environment for a sample application (also included in the GitHub repo) using the F5 rSeries hardware platform. ➡️ See here for a reference architecture with details about which F5 rSeries platforms run the F5 XC Customer Edge (CE) The setup includes two Data Centers, each having an origin pool that connects to the XC site installed in F5 rSeries. The XC site is connected to the BIG-IP, where a Virtual Server is configured. The included sample app is located inside the Virtual Server Pool of the BIG-IP appliance, and is protected by Web Application Firewall (WAF), DDoS Protection, and Bot Protection; it also leverages the API Discovery feature of the XC platform. The steps include the following: Configuring the BIG-IP on F5 rSeries; Configuring of the Customer Edge (CE) Sites on F5 rSeries; Demo application deployment in the Data Center; Configuring the XC Cloud Secure Mesh Site and combining them into a single Virtual Site; Exposing the application to the Internet using the HTTP Load Balancer; Protecting the application with a Web Application Firewall (WAF), DDoS Protection, Bot Protection, and API Discovery; Upgrading the solution with a second Data Center and configuring the HTTP Load Balancer for a complete DMZ configuration. The end result is a modern topology for flexible and scalable networking connectivity, enhanced performance, and protection captured in the following diagram: At the core of this solution is the Customer Edge (CE), which allows organizations to establish Secure Mesh Sites in various environments. By integrating CE with F5 XC, organizations can create a Virtual Site, simplifying access management while allowing for future scalability. Once the Secure Mesh Site is established, application traffic can be exposed and optimized using an HTTP Load Balancer within F5 XC. This enables efficient routing, automated certificate management, and secure connectivity to backend application services. For organizations requiring failover and redundancy, additional Secure Mesh Sites and Virtual Sites can be configured across multiple data centers. This ensures that applications remain accessible even if one data center experiences downtime, improving resilience and disaster recovery capabilities. Solution Demo Conclusion: A Modern Approach to Scaling DMZ By leveraging F5 Distributed Cloud Services, organizations can transition from traditional, fragmented DMZ architectures to a more scalable, cloud-integrated security model. Centralizing networking and security functions at the edge prevents unwanted traffic from reaching core infrastructure, ensures policy consistency across deployments, and simplifies multi-cloud networking. For organizations looking to implement this model in their own environments, the F5 DevCentral GitHub repository provides a detailed Workflow Guide covering the step-by-step setup process. This guide offers a structured approach to configuring Secure Mesh Sites, deploying CEs, and integrating application security services, enabling teams to modernize their DMZ architecture with confidence. As security and networking challenges evolve, adopting a scalable, edge-based DMZ strategy ensures greater efficiency, stronger security, and seamless application delivery across hybrid multi-cloud environments. Additional Resources F5 Distributed Cloud Customer Edge on F5 rSeries – Reference Architecture GitHub: Extending App DMZ to Global Service Tier with F5 rSeries and Distributed Cloud Services - Workflow Guide GitHub: DMZ Setup with F5 Distributed Cloud (VMware-specific) - Workflow Guide F5 Solutions: Secure Multi-Cloud Networking F5 Solutions: Application and Network Performance Learn about the future of Application Delivery at F5
