AI/ML detection of Malicious Users using F5 Distributed Cloud WAAP – Part I

Introduction

As people embraced the Internet as a part of their daily lives, businesses all over the world discovered an easier way to reach a large customer base that is not restricted by geographical boundaries.

While that is important, it has also provided an open platform for malicious users to look for potential security loopholes in order to break into the system and cause severe damages.

As a result, safeguarding business applications from such malicious user events becomes extremely critical.

"Nature is a mutable cloud, which is always and never the same." - Ralph Waldo Emerson

We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts.

F5 Distributed Cloud WAAP (Web App & API Protection) offers an AI/ML-based solution for monitoring such security events as well as the means to mitigate them.

In this series of articles, we will demonstrate enabling, configuring, monitoring, and mitigating malicious users using F5 Distributed Cloud console.

Configuration

There are two ways to enable malicious user detection:

Using Single Load Balancer ML configuration.
Using Multi Load Balancer ML configuration.

Using Single Load Balancer ML Configuration:

In this mechanism, detection is enabled as part of the load balancer configuration and is only applicable to the load balancer on which it is configured.

Using Multi Load Balancer ML Configuration:

In this mechanism, detection is enabled as part of the app type configuration and is valid for all LBs configured with the same app type label.

In both of the mentioned ways, detection is dependent on the ML configuration derived from the app settings object, with the difference that in single load balancer ML config values are not configurable and are set to default, whereas in multi load balancer ML config values can be configured according to the need.

Once malicious user events have been identified, the next stage is to prioritize mitigation. The following are two ways of mitigating detected malicious user events:

Using Load Balancer Security Monitoring.
Using Load Balancer Advanced Security Configuration.

Using Load Balancer Security Monitoring

This is a manual way of configuring mitigation in which malicious user IPs are added to the allow/deny list.

Using Load Balancer Advanced Security Configuration

This is an automatic way of enabling mitigation in which the platform will apply the corresponding configured mitigation action for the specific threat levels.

The default identifier configured for addressing malicious user events is the client IP address but in the ever-evolving world of attacks spoofing identity is not a difficult task to perform and to uniquely identify a user we should have a set of other identification mechanisms, keeping that in mind F5 Distributed Cloud console also provides you with the option to configure other parameters of identification like cookie name, header name, query parameter, ASN, TLS Fingerprint and combination of IP-header name & IP-TLS Fingerprint.

Follow the documentation for step-by-step configuration instructions

Demonstration (Using Single Load Balancer ML Configuration)

In this demonstration we will enable malicious user detection, configure a WAF policy with enforcement mode as monitoring, configure malicious user mitigation actions for medium and high threat levels and at the end monitor the XC logs for malicious user activity.

Step1: Enable malicious user detection using Single Load Balancer ML config as mentioned in the document.

Step2: Create an App Firewall policy.

Select WAAP service from the home page then go to Manage->App Firewall and click on 'Add App Firewall'.
Add name and customize the fields as needed, Save & Exit.

Step3: Configure mitigation actions.

Go to WAAP->Manage->Shared Objects->Malicious User Mitigation and click on Add Malicious User Mitigation.
Add a name, set threat level and associated actions accordingly. Add Item, Save & Exit.

Step4: Attach the WAF policy and add the malicious user mitigation settings to the LB.

From the Console homepage, Go to Load Balancers->Manage->Load Balancers->HTTP Load Balancers, select ‘Manage Configuration’ as an ‘Action’ to your LB and click ‘Edit Configuration’.

Scroll down to Web Application Firewall (WAF), enable it and set the waf policy created in Step 2, Save & Exit.

Scroll down to 'Common Security Controls' enable 'Malicious User Mitigation And Challenges', set 'Malicious User Mitigation Settings' as ‘custom’ and add the mitigation rule created in Step 3, Apply the changes. (Note: Here we have provided the flexibility to configure custom malicious user mitigation setting. However, users can also select default, which is a recommended setting).

Step5: Generate XSS attack (20+ requests in a minute) e.g., https://<domain>?a=<script>

Step6: Monitor the malicious user activity.

Go to WAAP -> Overview -> Dashboards->Security Dashboard, scroll down and select your LB.
Select Malicious Users tab.

On top of the above dashboard, F5 XC console also provides a seperate malicious users dashboard which shows a global view of potential malicious users interacting with the application load balancers in a specific namespace giving a better visibility and greater context about the malicious traffic and ease the process of tracking and mitigating possible attacks with quick assessment. Below are a few screenshots of the same.

To view this dashboard navigate to Home -> Web App & API Protection -> Overview -> Threat Insights -> Malicious Users

As you can see from the demonstration, even though the waf policy is set to monitoring mode, in the background, malicious user activity is continued to be tracked and the threat level kept increasing with the number of attacks being performed, and once the threat level reached ‘High’, configured mitigation action got triggered. (Note: Based on malicious user mitigation settings different threat levels will have different mitigation actions, for example: in default settings for low threat level, JavaScript Challenge will be applied, for medium threat level, Captcha Challenge will be applied and for high threat level, users will be temporarily blocked).

In this scenario, Customers can block attackers in real-time with very low risk of False Positives, as actions are taken based on observed user behavior over time.

Conclusion

In this article, we discussed how to enable malicious user detection and mitigation and how you can block attackers with a very low risk of False Positives. In future articles, we will discuss other scenarios. So please stay tuned.