Applies To:
Show VersionsBIG-IP ASM
- 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
About anti-bot mobile application SDK
You can configure the BIG-IP® system to detect traffic coming from known mobile applications and determine which of the requests to allow to continue to your server application. The ability to distinguish mobile application traffic from browser traffic is important because mobile applications do not usually run JavaScript code coming from the server. Therefore, responding with JavaScript-based challenges, such as Client Side Integrity and CAPTCHA, breaks the application. You can configure the anti-bot mobile application SDK so the system does not respond to mobile application traffic with those challenges (as it does to browser clients), but rather tests them for human activity.
Attackers can easily generate traffic that mimics the behavior of a mobile app by setting the User-Agent string and sending HTTP requests that are similar to those sent by authentic applications. Attackers might even log in as a valid registered user in those cases, and perform automated tasks, such as content scraping and other web attacks, from their attacked HTTP client tool.
You can reliably detect traffic from your mobile applications by using the Anti-Bot Mobile Application SDK. The SDK authenticates your application with BIG-IP® system security, something that tools emulating mobile applications cannot do. See the ASM Anti-Bot Mobile Application SDK for details on how to build your mobile application. See this Appdome article for details on integrating apps with the F5 Anti-Bot Mobile SDK.
Importing Android mobile application publisher certificates
You identify Android mobile applications by the certificate used to sign them. We do not trust the name of the application as this name can be spoofed if the application was not installed from the Google Play store. If you want to detect mobile applications running on Android devices, you first have to upload the certificates of their publishers, the signing parties.
Configuring a DoS profile to detect mobile applications
The mobile application user does not see a CAPTCHA challenge and the mobile application is not presented with the Client Side Integrity challenge. Client-Side Integrity and CAPTCHA challenges used in other features such as DoS mitigation, Web Scraping prevention and Brute Force attack prevention will not be applied to mobile app traffic in order not to break them. However, to strengthen the security in those features with mobile application clients, you can use a challenge for human behavior as a replacement for those challenges. Use this challenge if most of the requests sent by your mobile applications are preceded with some human interaction, typically tapping the screen. This is especially important for the login operation monitored by the Brute Force protection feature. It checks that the request was indeed triggered by a human and not generated automatically. However, if your mobile application might log in automatically without user intervention, you should disable this option and select the Always passed option.
Mobile application traffic
Mobile application requests are logged in Bot Defense logs, and also in the Application (ASM) request log if an ASM® policy is configured. A typical use case for logs is troubleshooting requests that were accidentally blocked or passed. In Bot Defense request logs, you can see the action taken for that request, and also see the attributes of the mobile applications such as the application display name, version, or whether it was from a jailbroken or rooted device. This way you can track the reason for blocking an application. For example, if the request was blocked because it did not match any of the allowed application package names or publishers, you see the actual application's display name and the reason, Mobile application does not match profile criteria.
Setting up mobile application request logs
An interesting use case is to track requests that were blocked because no human behavior was found in Web Scraping or Brute Force features, although the Challenge for Human Behavior option was selected when client side challenges were required. Once you realize that the request was blocked in the ASM® Application log, you can look for the matching entry of the same request in the Bot Defense log. You can do this by searching the same Support ID in that log. Observe the Human Behavior Indication attribute in the log: if it was not Human Detected, then the request was blocked because no tap screen event was recorded prior to the request.
Viewing mobile application traffic statistics charts
You can get important insights about the traffic accessing your server applications, and specifically traffic coming from mobile applications, by looking at the DoS analysis HTTP traffic charts. You can see the composition of the HTTP traffic to your application by looking at the Client Types chart. You can see how much of the traffic came from mobile applications, from browsers, and from bots, at any time on the selected time period. You can also narrow the chart to certain applications by selecting a specific virtual server, OS name, and jailbreak status on the dimension inspector.