Hitting the Easy Button: Securing the Remote Desktop on F5 BIG-IP APM
Being able to provide the most effective remote access solution is critical, especially in these turbulent times. In this article printed with permission from authors Lucas Thompson & Michael Waechter, we're going to talk about Remote Desktop Web Access. Solution Brief In short, it enables end-users to access their Remote Desktop applications through the F5 APM Webtop. The benefits of utilizing Remote Desktop Web Access over a desktop can be many. With the only requirement being a compatible web browser, Microsoft RDP application (comes installed with all modern versions of Windows), and a backend server hosting the applications… the solution speaks for itself. When the Full Webtop is displayed, APM will fetch a list of RemoteApps available on the target Terminal Server via HTTPS (using the Server SSL profile on the APM virtual server) and the associated icons. They will then be presented to the end user. The connection is done over HTTPS to the APM, and APM uses RDP (port 3389) to the Terminal Server. In the classic Terminal Server Desktop use case, the user is assigned a ‘native’ type RDP resource. This icon is presented to the user on a Full Webtop. Access is made by selecting the icon. A .RDP file is downloaded to the end user client PC, and the browser will activate the OS’s native RDP client to proceed with the connection. The connection is done over HTTPS to the APM, and APM uses RDP (port 3389) to the Terminal Server. Not only is the client setup simple, but the administration part of the equation is equally as easy to enable. I’m running version 14.1 (LTS) and here are a few screenshots of the setup. To enable the solution, let’s click on Access -> Connectivity/VPN Go ahead and choose VDI/RDP -> Remote Desktops Add the relative information. (Note: It’s always best to have the host name be a FQDN, and add this as a LTM node for health monitoring.) Technical Workflow The user clicks a resource icon on the Full Webtop, an RDP file is downloaded and then executed by the TS client on the user’s PC. The RemoteApp use case has a few differences versus targeting a desktop, or terminal server directly. In this case APM Will: Obtain a list of the RD feeds. The list of RDP App Resources will be derived from the RemoteApp feed. The list of icons will be delivered to the end user’s browser. The end user’s browser will request the icon pictures via a proxy mechanism in the VDI module. Because the RemoteApp feed comes through HTTPS and IIS on the Terminal Server, we have to make sure that: BIG-IP data plane can route to the Terminal Server. BIG-IP can create a HTTPS connection to Terminal Server. Terminal Server is rendering the page correctly. When you browse to it (https://terminalserver/rdweb/) you should see something like this: 2008: 2012: Authenticate with the same credentials that the test user uses in APM, and you should see an App Feed or desktop feed: Solution FAQ What kind of licenses are used for RDP access? APM has two license types: CCU and Access Session. Access Sessions are used for each established session ID. CCU are used for Network VPNs and other things that require more advanced features. Native Mode RDP does NOT use a CCU (connectivity) license. Only a single Access Session license will be consumed by a connecting user. What RDP options are supported? All of them. They’re basically echoed back to the client in the .RDP file. Put your desired parameter into the Custom Parameters area. It’s OK to use session variables in %{session.variable} format as well. RDP Custom Parameters configuration Lists of the RDP options have been compiled by 3rd parties, including the one at https://www.donkz.nl/overview-rdp-file-settings/ which is quite comprehensive. Please note that the following options are reserved for APM RDG use. If you attempt to apply these custom parameters, they will be ignored and/or overwritten by APM: Gatewayusagemethod Gatewayprofileusagemethod Gatewayhostname Gatewaycredentialssource Gatewayaccesstoken authentication level full address server port enablecredsspsupport signscope signature prompt for credentials on client domain username alternate full address gatewaybrokeringtype RDP Window Title The maximized window title for MSTSC inherits the target device name (not the RD gateway host). The medium-sized window title for MSTSC inherits the RDP filename (which is always “launch” -- see RFE 610244). One interesting thing that is possible is to internally-redirect the RDP session so that the client THINKS its connecting to one site, but then re-assign the remote host variable to a different site during the RAP access policy execution. RemoteApps It’s possible to create a lot of apps by using a PowerShell script on a RemoteApp-enabled terminal server. Client Requirements Microsoft Remote Desktop Client is supported for both Windows and Mac. Because the protocol used utilizes the Remote Desktop Gateway functionality, only newer RDP clients work. Legacy clients will likely not be able to create connections. iOS/Android The latest iOS / Android App Store RDP clients from Microsoft are supported. There might be some version conflicts, but for the most part the latest and greatest will work Reconnections / Disruptions Reconnections work the same as normal RDP If the user disconnects and reconnects, the session will be resumed. The client instructs the RD Gateway (APM) to again establish the session. The Remote Desktop session will be resumed also, the same way as with normal RDP. If the session is deleted or timed out or otherwise destroyed, the connection will stop, RDP will try to reconnect, but it will fail, and you will see this message from the MSTSC client.Using F5 NGINX Plus as the Ingress Controller within Nutanix Kubernetes Platform (NKP)
Managing incoming traffic is a critical component of running applications efficiently within Kubernetes clusters. As organizations continue to deploy a growing number of microservices, the need for robust, flexible, and intelligent traffic management solutions becomes more apparent. In this article, we provide an overview of how F5 NGINX Plus, when used as the ingress controller in the Nutanix Kubernetes Platform (NKP), offers a comprehensive approach to traffic optimization, application reliability, and security.Fine-Tuning F5 NGINX WAF Policy with Policy Lifecycle Manager and Security Dashboard
Introduction Traditional WAF management often relies on manual, error-prone editing of JSON or configuration files, resulting in inconsistent security policies across distributed applications. F5 NGINX One Console and NGINX Instance Manager address this by providing intuitive Graphical User Interfaces (GUIs) that replace complex text editors with visual controls. This visual approach empowers SecOps teams to manage security at all three distinct levels precisely: Broad Protection: Rapidly enabling or disabling entire signature sets to cover fast but broad categories of attacks. Targeted Tuning: Fine-tuning security by enabling or disabling signatures for a specific attack type. Granular Control: Defining precise actions for specific user-defined URLs, cookies, or parameters, ensuring that security does not break legitimate application functionality. Centralized Policy Management (F5 NGINX One Console) This video illustrates the shift from manually managing isolated NGINX WAF configurations to a unified, automated approach. With NGINX One Console, you can establish a robust "Golden Policy" and enforce it consistently across development, staging, and production environments from a single SaaS interface. The platform simplifies complex security tasks through a visual JSON editor that makes advanced protection accessible to the entire team, not just deep experts. It also prioritizes operational safety; the "Diff View" allows you to validate changes against the active configuration side-by-side before going live. This enables a smooth workflow where policies are tested in "Transparent Mode" and seamlessly toggled to "Blocking Mode" once validated, ensuring security measures never slow down your release cycles. Operational Visibility & Tuning (F5 NGINX Instance Manager) This video highlights how NGINX Instance Manager transforms troubleshooting from a tedious log-hunting exercise into a rapid, visual investigation. When a user is blocked, support teams can simply paste a Support ID into the dashboard to instantly locate the exact log entry, eliminating the need to grep through text files on individual servers. The console’s new features allow for surgical precision rather than blunt force; instead of turning off entire security signatures, you can create granular exceptions for specific patterns—like a semicolon in a URL—while keeping the rest of your security wall intact. Combined with visual dashboards that track threat campaigns and signature status, this tool drastically reduces Mean-Time-To-Resolution (MTTR) and ensures security controls don’t degrade the application experience. Conclusion The F5 NGINX One Console and F5 NGINX Instance Manager go beyond simplifying workflows—they unlock the full potential of your security stack. With a clear, visual interface, they enable you to manage and resolve the entire range of WAF capabilities easily. These tools make advanced security manageable by allowing you to create and fine-tune policies with precision, whether adjusting broad signature sets or defining rules for specific URLs and parameters. By streamlining these tasks, they enable you to handle complex operations that were once roadblocks, providing a smooth, effective way to keep your applications secure. Resources Devcentral Article: https://community.f5.com/kb/technicalarticles/introducing-f5-waf-for-nginx-with-intuitive-gui-in-nginx-one-console-and-nginx-i/343836 NGINX One Documentation: https://docs.nginx.com/nginx-one-console/waf-integration/overview/ NGINX Instance Manager Documentation: https://docs.nginx.com/nginx-instance-manager/waf-integration/overview/
Issue with TLS Version 1.1 Deprecated Protocol
My vuln scanner is popping hot for an issue on only one of my tenants. The issue describes the following. " Enable support for TLS 1.2 and/or 1.3, and disable support for TLS 1.1. - TLSv1.1 is enabled and the server supports at least one cipher. " I've read a few articles on where to disable this ins BIG-IP and from what I can gather I don't see where I have TLS 1.1 enabled on this guest or the handful of services I run on it. This issue is still showing on my vulnerability report as of this passed Wednesday so its clear I'm missing something. Any suggestions?Introducing F5 AI Red Team
F5 AI Red Team simulates adversarial attacks such as prompt injection and jailbreaks at unprecedented speed and scale, allowing for continuous assessment throughout the application lifecycle, providing insights into threats and integrating with F5 AI Guardrails to convert these insights into security policies.
Runtime API Security: From Visibility to Enforced Protection
This article examines how runtime visibility and enforcement address API security failures that emerge only after deployment. It shows how observing live traffic enables evidence-based risk prioritization, exposes active exploitation, and supports targeted controls such as schema enforcement and scoped protection rules. The focus is on reducing real-world attack impact by aligning specifications, behavior, and enforcement, and integrating runtime protection as a feedback mechanism within a broader API security strategy.
Service discovery is not happening in AS3
We are having AS3 running in our F5 BIGIP and we are facing an issue with the service discovery. The pool members are unable to Autodiscover the new ip and port when the application containers are restarted. --> I can be able to see the auto discovery is happening in CLI (meaning after the application container is restarted, I can see the new Ip, and port is reflecting in the CLI. I am checking this using the command curl -vk http://<consul IP>/<endpoint URI> | jq .) and that auto discovery is not happing in GUI. As the pool members are not auto discovered and not attach to the pool, the pool is showing down and the users are getting impacted. --> I have reinstalled the AS3 in our F5 and the issue remains same. Currently the AS3 version we are running on 3.47 --> I can be able to see the declaration in the GUI (https://<BIG-IP>/mgmt/shared/appsvcs/declare) --> Service discovery is enabled in our F5. (https://<BIG-IP>/mgmt/shared/appsvcs/settings) --> We have tried by increasing the memory of 1GB to REST API interface, but the issue still remains same. We have increased the memory to 1Gb for the below list sys db provision.extramb list sys db provision.restjavad.extramb list sys db provision.tomcat.extramb --> Currently our F5 LTM is running on version 16.1.5 and we have tried upgrading to version 17.1.2.1 to check if this issue can bel resolved or not but after upgrading the complete AS3 services are down (the service discovery did not happen and because of that I see all the virtual servers are in down state). --> We are having Active -Standby setup, we have tried by failover but the issue still remains same. --> We have tried restarting the below bigstart restart restjavad restnoded bigstart restart restjavad restnoded httpd tomcat Could someone please help here to overcome this issue. This issue has been running from past 30 days, and we don't have any solution from F5 TAC. Regards, Bharath Kumarv11: RDP Access via BIG-IP APM - Part 1
I wrote an article several months back on auto-launching Remote Desktop sessions with APM. With the introduction of BIG-IP APM v11, there is a new built-in capability to support a full webtop. This means that server, desktop, or other resources can be placed on the webtop for users to select once logging in. In this first example, I’ll set up a static internal resource for users to connect to after logging in. Create the Webtop After logging in to the BIG-IP, open up the Access Policy tab and select Webtops->Webtop List and then click Create (or you can hit the “+” circled to the right of the Webtop List.) Give the Webtop a meaningful name and the type needs to be Full as show in Figure 1. Create the RDP Resource Still in the Access Policy tab, click Application Access->Remote Desktops->Remote Desktops and then click Create. There are a number of fields here, but for this example the only ones that need to be set are the Type (RDP), the Destination (Server or Desktop hostname or IP), and Auto Logon (Enable). When Auto Logon is selected, the username, password, and domain source variable fields are shown. I accepted the defaults. Create the Access Policy Now that the two custom objects for the RDP Webtop are created, I’ll create the access policy (and virtuals) with the Network Access Setup Wizard for Remote Access under the Wizards tab. I create all my access policies this way, the wizard is very thorough and eliminates my tendency to overlook an object or misconfigure one, not to mention the time savings. In the first screen, I disabled AV checks (though in production I wouldn’t recommend this) as shown in Figure 3 below. Next I create a new authentication resource (you can select existing if this is not a new installation), utilizing my test active directory server. Next I configure the lease pool. It’s just me in my test lab, so I only create a single client address, but you’ll likely need to choose the IP address range. The next step is for network access configuration. Corporate policies will dictate whether all traffic is forced through the tunnel or if split-tunneling is appropriate. For this example, I stuck with forcing all traffic through the tunnel to minimize the necessary configuration to show the features. I only have one name server, my ad01 directory server, so I enter that and leave the rest blank. Next I’ll enter the VIP address and leave the http->https redirect virtual enabled. At this point, I review the configuration and click next. If there are any errors, you can return to previous steps in the wizard and make corrections. Before clicking Finished in the next screen, I need to edit the access policy. Once in the policy editor, click on the Logon Page object and set Field 3 from none to text and use domain as the post and session variable name. Then below in the Logon Page Input Field #3 text box, enter Domain. Next, click on the Resource Assign object and then click Add/Delete in the expression. I need to replace the webtop the network access wizard created and I need to select the RDP Resource I created. Close out the policy and then click Finished in the Setup Summary screen. For my configuration I need to snat the traffic, so I enabled snat-automap on the virtual created by the wizard. Because I made changes to the policy, I need to re-apply it, so in the Access Policy tab I clicked on Access Profiles and then selected my profile and clicked Apply Access Policy. That completes the configuration steps. Now it’s time to test. Testing the Configuration First I open a browser and navigate to my vip, https://10.10.20.30. After login, my RDP resource is shown on my Webtop, along with my network access. After clicking the rdptest icon, I am logged in automatically to my server. It seems like a lot of steps, but I configured this in less than five minutes, which is far more efficient and far less error-prone than the previous solution. The video below shares the same steps covered here in screen captures. BIG-IP APM RDP Webtop Conclusion This solution introduces a full Webtop environment for BIG-IP APM in version 11, which I took advantage of for statically configuring RDP resources for clients. In part 2, I’ll introduce a dynamic option for the RDP resource.
