Because of the iControl REST Vulnerability, we want to block all HTTPS traffic to F5 loadbalancers, except for whitelisted API servers and whitelisted management servers.
Running: BIG-IP 14.1.4.6 Build 0.0.8 Point Release 6.
Q1: Please confirm that there is no implicit deny as last rule; all traffic not specifically dropped/blocked, is permitted. Q2: Please advise about the relationship/overlap/overruling between the security firewall rules and the HTTPD rules. When the firewall rules on https traffic blocks traffic, the http-daemon allows all. Q3: Is the example the correct way to block all API-call traffic to F5 loadbalancers, except for whitelisted API servers and whitelisted management servers? So 1 HTTPS rule permitting the white-listed sources + 1 HTTPS rule blocking all others.
when we use firewall rule for BIG-IP management, will that overrule the sys HTTPD configuration? If so, is it then better to use firewall rule for BIG-IP management in stead off sys HTTPD?
I have documentation to help answer a few of these.
Q1: "Note: The system does not create the aforementioned deny-all rule automatically, you must explicitly create the deny-all rule as the Last in the rule list for it to block access from non-allowed sources. When configuring a deny-all rule, ensure you have a rule that allows access from your client system and appears before the deny-all rule in the rule list. Otherwise, you may lose access to the management interface on the BIG-IP system." (source)
Q2: Security firewall rules will cover any ip ranges and services listed in the rules. SSHD and HTTPD allow lists apply only to that service. I suggest reviewing this article if you haven't already: K13092: Overview of securing access to the BIG-IP system
Thanks for your answer, very interesting!! However my question now is, when we use firewall rule for BIG-IP management, will that overrule the sys HTTPD configuration? If so, is it then better to use firewall rule for BIG-IP management in stead off sys HTTPD?
Make a quick edit to your post to tag @G-Rob to make sure he saw your follow-up. 🙂 In the future, you can do this yourself by typing @ before their username, and a dropdown should automatically pop up for you to click on .
Technically, restricting source IP addresses in either configuration is enough to block the service. The hierarchy of processing for management traffic would put the firewall rules enforcement before the sshd/httpd allow lists, which provides protection lower in the network stack than the daemon allow lists. So I wouldn't say that either configuration overrules the other, as a specific permit in one and a specific deny in the other will result in a failed connection. I would certainly recommend using the network firewall rules to limit management access. Adding those same IPs to the daemon allow lists would offer another layer of security.
