Security Best Practices for BIG-IP & BIG-IQ systems

This isn’t going to be an exhaustive list of steps you should take to secure a BIG-IP environment, but some colleagues and I worked on this list a little while ago and I wanted to finally get it out there for everyone to consume.

There’s a wealth of information outside of this on AskF5 with specific steps to take to configure specific pieces of functionality, and it’s hard to link to them all here because often they are version specific where functionality has changed or been enhanced across major releases, so I’ll leave looking up those steps as an exercise for the reader should you find steps here you want to undertake.

You’ll occasionally see us refer to the “control-plane” and “data-plane” in F5 documentation; the “control-plane” encompasses all the ways you can manage a device or installation – the Web UI (TMUI), iControl REST, iControl SOAP, SSH etc., they all count but also big3d, bigd and other daemons relevant to the management of the system. The “data-plane” encompasses every construct that passes user traffic like Virtual Servers, NATs, SNATs and so on, basically everything other than the control-plane. From here on in, those are the constructs I’ll be referring to.

Step 1: Minimize access to the control-plane

This is good practice for any system, but especially those which might sit in a privileged position in your network such as the BIG-IP (or edge firewalls and so on). It’s essential to keep the control-plane off the internet (with few exceptions such as big3d communications between BIG-IP DNS and BIG-IP LTM devices which may often traverse the internet); ideally though, you want to restrict access to only authorized IT staff.

It's also good practice to control access to any control-plane services (SSH, HTTP, SNMP etc.) so that traffic is only allowed to travel to and from hosts you expect.

Wherever possible, it’s best to use a management DMZ to control access, but you should also think about how to restrict lateral movement within the DMZ using microsegmentation or on-device controls, and the on-device controls were significantly enhanced in 14.1 to provide a robust management interface firewall.

Access to a management DMZ should be through a jump box or VPN with 2FA enabled. Jump boxes provide a dedicated environment which can be secured and provides meaningful protection against XSS and CSRF attacks since administrators will be using the jump box only to administer the device and perform general purpose browsing and other office related tasks on their own hosts. Even without this infrastructure, it is better to administer your BIG-IP using a local Virtual Machine or, at the very least, a dedicated browser, to offer protection against phishing delivered XSS & CSRF attacks.

Of course, we understand that the network design changes required for a management DMZ won’t happen overnight, but the on-device management interface firewall can at least be implemented independently, as can mandating a more secure environment to perform administrative tasks within.

 

Step 2: BIG-IP Management and Self IPs

Firstly, make sure that all Self IPs are configured with “Lockdown None” to ensure that no control-plane services are exposed, unless you specifically need to expose a service such as big3d (port 4353) where you should be sure to expose only the ports you require. On your dedicated management VLAN and non-routable HA VLANs you can use “Allow Default”, though consider allowing only specific ports where possible.

Out-of-band management over a dedicated interface or VLAN is strongly recommended. You can achieve this using either the dedicated management interface on hardware platforms, or a dedicated management VLAN on the production interfaces where preferred or where a dedicated management interface is unavailable (e.g., a single-NIC cloud deployment).

 

Step 3: Hardening the BIG-IP

Where possible you should consider storing secrets in a Hardware Security Module – onboard FIPS HSM or NetHSM offer an extremely high level of security for SSL Keys and for those not wishing to go to a hardware HSM system, the built-in SecureVault functionality makes recovery of SSL keys more difficult for any unauthorized user who might gain access to the BIG-IP’s control plane. For more information on SecureVault, F5 has a knowledge base article available: K73034260

Reduce your attack surface wherever possible by provisioning additional modules as you need them, rather than up-front; this may also help to reduce the number of Security Advisories that are applicable to your systems.

Consider using AAA such as RADIUS, TACACS or LDAP for authentication to the BIG-IP control-plane rather than locally configured accounts, as this will immediately bring all accounts with access to the BIG-IP under the control of your pre-existing enterprise account security practices. Remember that, regardless of remote authentication, the root and admin passwords are still available for fallback local authentication, so be sure to configure strong passwords and ensure they are stored securely.

If you are using BIG-IP 15.0.0 or later you can also use a remote APM system to manage the authentication for the control-plane and implement 2FA/MFA using the APM system: https://techdocs.f5.com/en-us/bigip-15-0-0/big-ip-local-traffic-manager-implementations/implementing-apm-system-authentication.html

 

Step 4: Monitoring

You should configure off-box syslog (ideally to a SIEM) so that you have a reliable, immutable, record of configuration changes, potential indicators of compromise, system issues etc., and configure alerts based on those. You can also consider using SNMP traps and polling to monitor system performance and load, and to watch for potential indicators of attack against the data-plane (such as denial of service attacks).

Consider regularly uploading qkviews to iHealth, unless doing so is prohibited by your enterprise security policies, as the built in heuristics will warn you about potential device misconfigurations, security vulnerabilities impacting your specific version, hardware and/or configuration and any indicators of compromise found on your system. You can automate this step using BIG-IQ, which can also be used to automate taking regular configuration snapshots.

 

Step 5: Maintaining

You really want to be running a recent software release, ideally within the last 2 LTS branches as F5 continuously improves functionality to address new attacks, and to ensure you are consuming security fixes quickly.

Some customers prefer to use engineering hotfixes to address known issues, and we would suggest looking to move back to a mainline branch as soon as the fixes you require are available there, because this will ensure you have the minimum time-to-patch when new defects or vulnerabilities are uncovered in the product.

Speaking of vulnerabilities – make sure you are signed up to the F5 Security mailing list to get alerts for significant vulnerabilities; both when Quarterly Security Notifications (QSNs) occur and should high-impact third party vulnerabilities require out of band notifications. For more information on F5s QSN approach, and the dates of past and future QSNs, see K67091411

I mentioned this earlier under Monitoring, but ensure you are taking regular backups of your devices so that you have a known-good, uncompromised configuration to work with should the worst happen, and a device needs reimaging. As noted earlier, BIG-IQ can help automate this task although, as always, be cautious and ensure you test and validate your backup scripts to make sure that you are gathering valid backups and the script(s) are not accidentally erasing anything when rotating old backups out.

 

Step 6: Recovery

Compromise is relatively uncommon, and if you take the steps outlined above to secure your environment and adhere to security best practices, it is unlikely to happen to you. That said, before anything else, preparation is the key to success and given that recovery efforts often involve several departments within an organization, make sure you have worked through a documented recovery plan. At a minimum, we’d suggest covering:

• How you would isolate the compromised device (If a pair is compromised, should you keep a compromised box running and serving customers with potentially serious PCI/GDPR implications, does your application delivery design allow you to keep serving customers after the loss of a device pair, should you invoke Disaster Recovery?)
• When can you reintroduce devices into service – does your company policy require that devices are held for forensic analysis? If so, do you have spare devices you can use the maintain service for your customers?
• How you would reimage the devices from scratch and recover from backups
• How you would revoke and replace SSL keys on the device which may have been compromised
• What other secrets might need to be replaced (RADIUS, TACACS, SNMP?)

This sounds onerous, but it’s so much easier to have this conversation before you’ve got to make critical service impacting decisions. And of course, the scope shouldn’t be limited to just your F5 estate!

 

Summary

As I said at the outset, this list is far from exhaustive and needs to be read in the context of whatever existing guidelines your organisation has for securing, monitoring and maintaining systems as well as any existing disaster recovery plans. It’s also worth saying that while the technical specifics will change as F5s product offerings evolve with BIG-IP Next or the NGINX suite of products, but the general principles will remain largely the same.

There is a wealth of documentation on AskF5 around securing systems with specific, technical steps you can follow, additional resources and so on, and I’ll link to just a few of those here:

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