Security Best Practices for F5 Products

My colleagues previously wrote this article as a security best practice guidance for BIG-IP and BIG-IQ. This is an updated overview of key recommendations and not an exhaustive list of steps for securing an F5 product. I’ve also included updates to keep it relevant including newly published product hardening guides. These include: K53108777: Hardening your F5 system and K45321906: Harden your BIG-IQ system along with the two newly published K000156803: Hardening NGINX and NGINX Plus and K000156807: Secure the AOM subsystem. Regarding BIG-IP, the F5 SIRT team recently collaborated with the F5 iHealth team to create new diagnostic heuristics that align with these hardening best practices. These heuristics are now included in the Security tab of QKViews under a new "Security Best Practices" panel. You can also filter the alerts in the Diagnostics tab to show "Security_best_practices". Beyond these resources, there is extensive documentation available on MyF5 detailing specific steps for configuring functionality, though many are version-specific due to changes and enhancements across major releases. The most relevant links for configuration can usually be found within the hardening guides listed above. Additionally, F5 documentation occasionally refers to the "control-plane" and "data-plane." The control-plane includes all methods for managing a device or installation, such as the Web UI (TMUI), iControl REST, iControl SOAP, SSH, and related daemons like big3d and bigd. The data-plane, on the other hand, refers to all constructs that handle user traffic, such as Virtual Servers, NATs, SNATs, and other similar components. Going forward, references in this context will pertain to these constructs. 

Step 1: Minimize access to the control-plane

It is crucial to implement sound security practices for any system, especially those in privileged network positions like BIG-IP or edge firewalls. One fundamental principle is keeping the control-plane off the internet whenever possible, with limited exceptions such as big3d communications between BIG-IP DNS and BIG-IP LTM devices that may traverse the internet. Ideally, access to the control-plane should be restricted solely to authorized IT staff. Measures should be taken to control access to control-plane services (such as SSH, HTTP, and SNMP) to ensure traffic only comes from expected hosts, as outlined in K13092: Overview of securing access to the BIG-IP system and 10 Settings to Lock Down Your BIG-IP. Adding pre-login and post-login banners is another effective security step, as they can help enforce security policies—such as informing users that activities are logged—or notify users of system updates like scheduled maintenance. Guidance for configuring banners can be found in K6068: Configuring a pre-login or post-login message banner for the BIG-IP or Enterprise Manager system and K71515276: Configuring a pre-login or post-login message banner for the BIG-IQ system. 

Ideally, control-plane access should be managed via a management DMZ, and additional restrictions on lateral movement within the DMZ can be enforced through micro-segmentation or the use of on-device controls. For BIG-IP, these on-device controls were notably enhanced in version 14.1 and above with a robust management interface firewall. Access to the management DMZ itself should be through a jump box or VPN with 2FA enabled. Jump boxes provide a dedicated and secure environment for administrative tasks, offering substantial protection against attacks like XSS and CSRF, because administrators will use them solely for device administration rather than general browsing or other activities. In the absence of this infrastructure, using a local virtual machine or dedicated browser for administrative duties is still recommended to mitigate risks from phishing-delivered XSS and CSRF attacks. While changes to network design to accommodate a management DMZ may take time, the on-device management interface firewall can be implemented independently, along with a mandate for more secure administrative environments. 

Several articles provide guidance for minimizing access to the control-plane, including K5380: Specify allowable IP ranges for SSH access, K11719: Mitigating risk from SSH brute-force login attacks, K13309: Restricting access to the Configuration utility by source IP address (11.x–17.x), K9908: Configure an automatic logout for idle sessions, and K75211108: Configure automatic logout for idle sessions on the BIG-IQ system. Furthermore, articles like K80425458: Modifying the list of ciphers and MAC and key exchange algorithms used by the SSH service on BIG-IP or BIG-IQ systems, K92748202: Restrict access to the BIG-IQ management interface using network firewall rules, and K31401771: Restricting access to the BIG-IQ or F5 iWorkflow user interface by source IP address provide additional strategies for securing critical management interfaces. 

 

Step 2: BIG-IP Management and Self IPs

To enhance security, ensure that all Self IPs are set to "Lockdown None" to prevent the exposure of control-plane services unless explicitly required. If a service such as big3d (port 4353) needs to be exposed, carefully restrict access to only the specific ports required. For dedicated management VLANs and non-routable HA VLANs, the "Allow Default" setting can be used, though it is recommended to allow only specific ports whenever possible for tighter access control. Relevant guidance can be found in K17333: Overview of port lockdown behavior (12.x–17.x), K39403510: Managing the port lockdown configuration on the BIG-IQ system, and K15612: Connectivity requirements for the BIG-IQ system. Out-of-band management via a dedicated interface or VLAN is strongly recommended for optimal security. This can be implemented using the hardware platform’s dedicated management interface or a dedicated management VLAN on production interfaces when a dedicated management interface is unavailable, such as in single-NIC cloud deployments. 

 

Step 3: Hardening the BIG-IP

To improve security, consider using a Hardware Security Module (HSM) for storing sensitive information such as SSL keys. Options like an onboard FIPS HSM or NetHSM offer a high level of protection, while the built-in SecureVault functionality can provide additional security by making SSL key recovery more difficult for unauthorized users who gain access to the BIG-IP’s control plane. For more details about SecureVault, F5 offers a knowledge base article: K73034260: Overview of the BIG-IP system Secure Vault feature. Additionally, reduce your attack surface by provisioning modules only as needed instead of upfront, which can also decrease the frequency of applicable Security Advisories. For further access restriction, appliance mode is another option designed to limit BIG-IP administrative access, making it behave more like a typical network appliance rather than a multi-user UNIX device (K12815: Overview of Appliance mode). 

For authentication, the BIG-IP control-plane should integrate with enterprise-grade AAA solutions such as RADIUS, TACACS+, or LDAP, as these bring administrative accounts under pre-existing enterprise security practices. However, note that root and admin passwords are available as fallback authentication, so these should be configured with strong, secure passwords. Guidance for setting up AAA solutions can be found in articles such as K8811: Configuring TACACS+ authentication for BIG-IP administrative users, K11072: Configuring LDAP remote authentication for Active Directory, K17403: Configuring RADIUS authentication for administrative users, and corresponding BIG-IQ articles like K31586420: Configuring the BIG-IQ system to use TACACS+ based authentication and authorization, K00153876: Enabling LDAP remote authentication for Advanced Shell access to the BIG-IQ system, and K51458353: Configuring the BIG-IQ system to use RADIUS authentication. 

If remote authentication is not being used, it is essential to enforce a strong password policy for local accounts on the BIG-IP or BIG-IQ systems. Several articles on MyF5 provide detailed instructions for locking down authentication on F5 devices, including K15497: Configuring a secure password policy for the BIG-IP system, K13121: Changing system maintenance account passwords, K4139: Configuring the BIG-IP system to enforce the use of strict passwords, K32203233: The root and admin accounts are now subject to the enforcement restrictions of the secure password policy, K12173: Overview of BIG-IP administrative access controls, and K49507549: Configuring a secure password policy for the BIG-IQ system. 

For systems running BIG-IP 15.0.0 or later, remote APM authentication can be used to manage control-plane access while also implementing two-factor or multi-factor authentication (2FA/MFA) using the APM system. For further details, see https://techdocs.f5.com/en-us/bigip-15-0-0/big-ip-local-traffic-manager-implementations/implementing-apm-system-authentication.html . 

 

Step 4: Monitoring

To maintain comprehensive security and monitoring, it is recommended to configure off-box syslog, ideally directed to a SIEM, to ensure you have a reliable and immutable record of events such as configuration changes, potential indicators of compromise, and system issues. Alerts based on these logs can be set up to monitor critical events in real-time. Additionally, consider utilizing SNMP traps and polling to keep track of system performance and load while monitoring for potential attack indicators against the data-plane, such as denial of service (DoS) attacks. Regularly uploading qkviews to iHealth is another beneficial practice—unless restricted by enterprise security policies—as iHealth’s built-in heuristics can identify potential device misconfigurations, vulnerabilities specific to your version, hardware, or configuration, and any indicators of compromise within your system. This process can be automated via BIG-IQ, which also has the capability to automate regular configuration snapshots. For enhanced awareness of system access, refer to resources such as K13426: Monitoring login attempts (11.x–17.x) and K08662997: Monitoring login attempts on the BIG-IQ system. 

 

Step 5: Maintaining

It is highly recommended to run a recent software release, ideally within the last two LTS (Long-Term Support) branches, as F5 continuously enhances functionality to address new attack vectors and ensure rapid adoption of security fixes. While some customers opt for engineering hotfixes to resolve specific issues, it is advised to migrate back to a mainline branch as soon as the necessary fixes are incorporated to minimize time-to-patch for newly discovered defects or vulnerabilities. Useful references include K9957: Creating a custom RSS feed to view new and updated documents, K2200: Most recent versions of F5 software, K9502: BIG-IP hotfix and point release matrix, and K15113: BIG-IQ hotfix and point release matrix. To stay informed about significant vulnerabilities, customers should subscribe to the F5 Security mailing list to receive alerts for critical vulnerabilities, including Quarterly Security Notifications (QSNs) and out-of-band notifications for high-impact third-party vulnerabilities. For more information about the QSN process and scheduling, consult K67091411: Guidance for Quarterly Security Notifications and K9970: Subscribe to email notifications regarding F5 products and security announcements. 

Additionally, reporting software issues—whether security-related or not—ensures the continuous improvement of F5 software. Any issues reported to F5 allow developers to address them promptly, facilitating early fixes. Resources such as K4602: Overview of the F5 security vulnerability response policy and K4918: Overview of the F5 critical issue hotfix policy provide more insights into how F5 handles reported vulnerabilities. Regular backups of your devices are another critical aspect of maintaining security and stability. Backups ensure you have a reliable, uncompromised configuration to restore in case a device needs reimaging. BIG-IQ can assist in automating this process, but it is crucial to thoroughly test and validate backup scripts to ensure they capture valid data and do not unintentionally delete necessary files during backup rotation. 

 

Step 6: Recovery

Although compromise is relatively uncommon, adhering to the outlined security steps and best practices can significantly reduce the likelihood of it occurring. However, preparation is critical to ensuring a successful recovery should a compromise take place. Since recovery efforts often involve multiple departments within an organization, having a documented recovery plan is essential. At a minimum, the plan should address key areas such as how to isolate the compromised device. For example, if a device pair is compromised, should a potentially compromised box remain online and serve customers despite serious implications like PCI or GDPR noncompliance? Does your application delivery design allow you to continue serving customers after losing a device pair, or should you activate Disaster Recovery? The plan should also define when and how devices can be reintroduced into service. If company policy requires devices to be held for forensic analysis, ensure you have spare devices available to maintain uninterrupted service. Include steps for reimaging devices from scratch and recovering configurations from backups, as well as revoking and replacing potentially compromised SSL keys. Additionally, consider other secrets that might need to be replaced, such as RADIUS, TACACS, or SNMP credentials. Although this level of preparation may seem burdensome, having these discussions in advance is far easier than making critical, service-impacting decisions under pressure. Moreover, your recovery plan should not be limited to only your F5 systems but should account for broader infrastructure. For additional guidance, refer to K11438344: Considerations and guidance when you suspect a security compromise on a BIG-IP system. 

 

Step 7: Secure Against Brute Force and Application Attacks

Protecting your F5 system is only part of securing your network; it is equally important to protect the applications and application servers that sit behind it. F5 systems can be configured in numerous ways to provide protection not only for the system itself but also for your applications. Starting at the lower layers, protections can be implemented using TCP profiles or by adding additional modules like F5’s Advanced Firewall Manager (AFM). AFM is a high-performance, stateful, full-proxy network firewall designed to safeguard data centers from incoming threats. It supports widely used protocols such as HTTP/S, SMTP, DNS, SIP, and FTP. For further guidance, consult resources such as K25301105: Mitigate HTTP SLOWRead attacks, K37718515: Investigating BIG-IP AFM attack vector logs and tuning the DoS Vector Attack Type, and K41305885: BIG-IP AFM DoS vectors. 

At higher layers, HTTP applications can be protected using a Web Application Firewall (WAF). F5 offers several WAF solutions, including Distributed Cloud, NGINX App Protect WAF, and Advanced WAF/ASM. With the increasing complexity of web applications, adding a WAF has become essential. A WAF provides significant mitigation capabilities and can be configured to protect against emerging attacks, offering robust defenses against threats such as authentication attacks and brute-force attempts. For additional information, refer to K07359270: Succeeding with application security, K15405450: Overview of web scraping detection, K18650749: Configuring brute force attack protection (13.1.0 and later), and K14199: Determining if the BIG-IP ASM system has detected and prevented a Slow HTTP POST DDoS attack. Implementing these layers of protection ensures comprehensive security for both your F5 systems and the applications they support. 

Summary

As noted earlier, this list is not exhaustive and should be considered within the context of your organization's existing guidelines for securing, monitoring, and maintaining systems, as well as any disaster recovery plans in place. While the technical details may evolve over time as F5’s product offerings expand—whether with BIG-IP or the NGINX suite—the overarching principles of system security will largely remain constant. To assist with these efforts, there is a wealth of documentation available on MyF5 that outlines specific technical steps, additional resources, and best practices for securing systems. A few key references include K67091411: Guidance for Quarterly Security Notifications, K9970: Subscribing to email notifications regarding F5 products, K27404821: Using F5 iHealth to diagnose vulnerabilities, K11438344: Considerations and guidance when you suspect a security compromise on a BIG-IP system, K53108777: Hardening your F5 system, K45321906: Harden your BIG-IQ system, and K000156803: Hardening NGINX and NGINX Plus.