F5 Distributed Cloud: Denylisting/Allowlisting
Introduction
Advancement in technology brings lot of challenges to security and demands designing strategies to prevent security breaches by either restricting or limiting share of resources.
Allowlisting and Denylisting are two such security strategies that prevents unauthorized access and helps in maintaining confidentiality of the system.
What is Denylisting?
Denylisting is a security strategy which involves defining some set of rules that denies access of application/network to suspected entities identified as a possible threat to the system.
Generally, this type of strategy is being adopted by the administrators in case of default allow that means allowing access to all except those specified in deny list.
For example, now-a-days e-commerce sites want more public reachability in such case denylisting can be applied as one of the possible solutions by identifying and blocking suspected malicious sources and allowing access for the rest.
Drawback: Even though denylisting is an easily deployable technique and works well with the known threats, it may sometimes be inefficient in case of unknown threats.
What is Allowlisting?
Allowlisting serves the same objective as that of denylisting by providing totally opposite solution. Here, instead of blocking access to the threats, only trusted/valid entities are allowed, and rest all are blocked.
This type of strategy is strict as compared to denylisting and is used in case of default deny that means blocking access to all and allowing only the known and trusted sources.
For example, company specific applications/networks/devices should only be accessible by its employees and not by any outsiders, in such scenarios allowlisting strategy can be applied as a possible solution.
Drawback: Since this strategy is stricter it offers more security, but its deployment is complicated especially in complex environments.
Demonstration
To carry out testing activities we've followed article: API Discovery and Auto Generation of Swagger Schema for our infra creation and application deployment.
Below are few sample scenarios for testing denylisting and allowlisting feature:
(Note: Testing is done on ‘Software Version: crt-20220217-1449’)
Scenario 1:
In this scenario, we will allow the clients to access the application based on their geographical location using our service policy.
Expected Result: Only clients from allowed geolocation should be able to access the application.
Steps to follow once infra is created and application is deployed:
Step 1: Go to Home -> Web App & API Protection and select your namespace.
Step 2: Go to Home -> Web App & API Protection -> Manage -> Service Policies -> Service Policies and click Add service policy.
Step 3: Enter a name for the new service policy, in ‘Server Selection’ field choose any one of the options as per need, we chose ‘Any Sever’ which is a default option.
Step 4: Create Service Policy Rule, since here we are testing the allowlist feature using geographical location, we did the configurations as shown in Figure1, Save & Exit.
Step 5: Go to Home -> Web App & API Protection -> Manage -> Load Balancers -> HTTP Load Balancers and to your LB select Action as Manage Configuration.
Step 6: Click Edit Configuration and in ‘Security Configuration’ section select option ‘Apply Specified Service Policies’ for ‘Service Policies’ field, Click Configure.
Step 7: Apply newly created Service Policy to the Load Balancer as shown in Figure2, Save & Exit.
Figure1 - Service policy creation
Figure2 - Attaching service policy to the load balancer
Actual Result: As we can see in Figure3 and Figure4, only traffic from client in allowed geographical location is able to access the application. We can conclude that we are able to successfully achieve the Allowlisting behavior.
Figure3 - Accessing application from allowed geolocation
Figure4 - Accessing application from different geolocation
Scenario 2:
In this scenario, we will deny access of application to the clients based on BGP ASN (Autonomous System Number) using our service policy.
Expected Result: Clients from blocked ASN should not be able to access the application.
Steps to follow:
Step 1: Repeat Steps 1 to 3 from Scenario 1.
Step 2: Create Service Policy Rule, since here we are testing denylist feature using ASN, we did the configurations as shown in Figure5 and Figure6.
Step 3: Repeat Steps 5 and 6 from Scenario 1.
Step 4: Apply newly created Service Policy to the Load Balancer as shown in Figure7, Save & Exit.
Figure5 - Adding ASN
Figure6 - Service Policy Rule for blocking clients using ASN
Figure7 - Attaching service policy to the LB
Actual Result: As we can see in Figure8 and Figure9, traffic from client having blocked ASN is not allowed to access the application and hence, we can conclude that we are able to successfully achieve the denylisting behavior.
Figure8 - Accessing application through client having blocked ASN
Figure9 - JSON log for the request
Scenario 3:
In this Scenario we will follow a hybrid approach (i.e., incorporating both Allowlisting and Denylisting strategies). We will first allow the clients based on geolocation and among those allowed clients we will then block a client based on IPv4 prefix.
Expected Result: Blocked client should not be able to access the application.
Steps to follow:
Step1: Follow Scenario 1 to achieve allowlisting behavior.
Step2: Go to Home -> Web App & API Protection -> Manage -> Load Balancers -> HTTP Load Balancers and to your LB select Action as Manage Configuration.
Step3: Click Edit Configuration and in ‘Security Configuration’ section toggle ‘Show Advanced Fields’ button.
Step4: In ‘Client Blocking Rules’ click Configure.
Step5: Click Add Item and fill up the entries as shown in Figure10.
Figure10 - Applying client blocking rule to the load balancer
Actual Result: As we can see in Figure11 and Figure12, blocked client is not allowed to access the application even though it falls in the same allowed geographical location. Hence, we can conclude that we are able to achieve the benefits of both denylisting and allowlisting security strategies.
Figure11 - Accessing application from blocked client
Figure12 – Accessing application from unblocked client
Scenario 4:
In this scenario we will restrict a client to access the application based on its ‘TLS Fingerprint Value’.
Expected Result: Blocked client should not be able to access the application.
Steps to follow:
Step1: Repeat Steps 1 to 3 from Scenario 1.
Step 2: Create Service Policy Rule, since here we are testing Deny list feature using ‘TLS Fingerprint Value’ we did the configuration as shown in Figure13.
Step 3: Repeat Steps 5 and 6 from Scenario 1.
Step 4: Apply newly created Service Policy to the Load Balancer as shown in Figure14, Save & Exit.
Figure13 - Service Policy Rule for blocking client using TLS Fingerprint Value
Figure14 - Attaching service policy to the LB
Actual Result: As we can see in Figure15, the client having blocked TLS fingerprint value has been denied access with response code as 403. We can conclude that we are successfully able to achieve the desired behavior.
Figure15 - Security Events JSON log
Conclusion
As attackers and their attack methodologies evolve you cannot simply depend upon one security strategy to protect entire application. We need to have a hybrid environment of security features to protect the application.
Keeping that in mind ideally ‘Denylisting and Allowlisting’ applied together can serve the purpose of better protecting the end applications.
So, to achieve the listed behaviors ‘F5 Distributed Cloud Console’ provide below options, Denylisting/Allowlisting clients through:
- IPv4 prefixes
- ASN
- Geo location
- TLS fingerprint
