23-Jun-2022 05:00 - edited 22-May-2023 06:31
This is an extension of the already published article AI/ML detection of Malicious Users using F5 Distributed Cloud WAAP – Part I an introductory article which highlights the configurations available for detecting and mitigating malicious user activity and includes a demonstration focused on detecting and mitigating malicious clients based on WAF security events.
In part II of this series of articles, we will demonstrate a few more scenarios covering insights of malicious user detection and mitigation feature of F5 Distributed Cloud platform.
In this demonstration, we will set the threshold limit for failed login attempts in the app settings configuration to mark any subsequent requests as a malicious user event and apply mitigation rules to restrict access, as well as we will detect the clients based on various user identifier types provided by the F5 Distributed cloud console.
Step1:
Enable malicious user detection using Multi Load Balancer ML config as mentioned in the document.
Step2:
Add malicious user mitigation rule to the LB
Step3:
Go to Home->WAAP->Manage->AI&ML->App Settings, click ‘Add App Setting’.
Step4:
Enter a name and click on 'Add Item' to go to the ‘AppType’ settings section. Click ‘Add item’.
Step5:
Click on the ‘Select Item’ drop-down and select the app type configured in the LB while executing Step1.
Step6:
Click ‘Configure’ ‘Malicious User Detection’, tune the settings as per your need. For the demonstration purpose we are setting the threshold value for Failed Login Activity to 5.
Step7:
Apply and add the configurations and then click ‘Save and Exit’ to create the app settings object.
Note: Identifying users uniquely on the Internet is a critical task because it aids in the creation of a perception by learning from the activities they perform on the application.
Step8:
Go to Home->WAAP->Manage->Shared Objects->User Identifications, click ‘Add User Identification’
Step9:
Generate requests more than the configured threshold limit for failed login attempts in your application; it should return response code as 401.
Available User Identifier Types:
By default, the user identifier type is set to ‘Client IP Address’. As in the previous article, we have already seen IP address as a client identifier. In this demo, we will set other options available, follow the steps mentioned above to generate failed login events and verify that the users are getting detected based on the configured user identification policy.
Below are the screenshots for configured user identification rules and UI dashboards displaying the results of associated configurations:
In this article, we demonstrated how simple it is to configure your LB to respond to multiple unauthorised access attempts by detecting them using various client identification type options and mitigating them automatically at the same time with a very low risk of false positives.