Manual Chapter : Working with Anti-Bot Mobile Application SDK

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
Manual Chapter

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.

Note: This feature detects only mobile applications running with the ASM® Anti-Bot Mobile Application 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.

  1. Locate and open the .apk application file with an archive extractor.
  2. Extract the META-INF/APPDOME.RSA file.
  3. In the directory where you extracted the .RSA file, install the OpenSSL package (version 1.0 or later), if not already installed.
  4. Run the following commands:
    1. openssl pkcs7 -print_certs -inform der -in CERT.RSA -out cert.crt
    2. openssl x509 -inform pem -in /tmp/cert.crt -outform der -out /tmp/cert.der
  5. On the Main tab, click System > Certificate Management > Traffic Certificate Management > SSL Certificate List > Import .
    The Import SSL Certificates and Keys screen opens.
  6. For Import Type, select Certificate and enter the certificate name.
  7. Select the Certificate Source, and either upload or copy and paste the cert.der certificate file.
  8. Click Import.

Configuring a DoS profile to detect mobile applications

Before configuring your DoS profile, you must have first uploaded the publisher certificates that you will use in the DoS profile.
You can use an existing DoS profile or create a new one for use with your mobile application detection.

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.

  1. On the Main tab, click Security > DoS Protection > DoS Profiles .
    The DoS Profiles screen opens, where you can create a new profile (step 2) or use an existing profile (step 3).
  2. To create a new DoS profile:
    1. Click Create.
      The New DoS Profile screen opens.
    2. Type a Name and Description.
    3. Click Finished.
      The DoS Profiles screen opens.
    4. Click the name of the profile you just created, and go to step 4.
  3. To use an existing profile, click the name of the DoS profile you want to use.
    The Properties screen opens.
  4. Click Application Security.
  5. On the left, click Mobile Applications.
  6. In the Mobile Applications area, click Edit and then select Enabled.
  7. iOS: Click Edit in the iOS section if your mobile applications run on iOS devices.
    1. Enter the mobile application package names individually that you allow access to your server application and click Add.
      Mobile applications are identified by their package names (also known as Bundle IDs), for example, com.f5.app1.
    2. Alternately, if you want to detect authentic mobile application traffic without checking which application sent the request, select Allow Any Package Name.
    3. Select Allow Jailbroken Devices to allow requests from jailbroken devices. This is not recommended because it allows unchecked applications with spoofed identities in the system.
  8. Android: Click Edit in the Android section if your mobile applications run on Android devices.
    1. Assign the mobile application publisher certificates that are allowed access to your server application by moving them to the Assigned publisher certificate list . The uploaded certificate names appear in the Available publisher certificate list but not all certificates on the list belong to mobile application publishers.
    2. Alternately, if you want to detect authentic mobile application traffic without checking which application sent the request, select Allow Any Publisher.
    3. Select Allow Rooted Devices to allow requests from rooted devices. This is not recommended because rooted devices can allow attackers to hijack sessions of mobile applications for a limited time. .
  9. ,To specify advanced options, for Advanced, click Edit.
    1. If your mobile application is in testing phase you can select Allow Emulators.
      Use this option with care because emulators can be abused to create automated attacks on your server application.
    2. If you want to specify the action to take when a CAPTCHA or Client Side Integrity challenge needs to be presented, select an option from the list:
    Option Description
    Always passed The traffic is passed without incident.
    Challenged for human behavior The SDK checks for human interactions with the screen in the last few seconds. If none are detected, the traffic is blocked.
  10. Click Update to update the profile.
  11. On the Main tab, click Local Traffic > Virtual Servers > Virtual Server List .
  12. Click the name of the virtual server to attach the DoS profile to.
    The Policy Settings screen opens.
  13. In Log Profile, add the DoS profile to Selected.
  14. Click Update to update the profile.

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

You can monitor the traffic coming from mobile applications that use the mobile application SDK in the logs and in the charts.
  1. On the Main tab, click Security > Event Logs > Logging Profiles .
  2. Select the name of an existing profile and go to step 4, or click Create to create a new profile.
  3. If you create a new profile, on the Create New Logging Profile screen:
    1. Enter a Profile Name and optional Description.
    2. Click Finished.
    3. On the Logging Profiles screen, click the name of the profile you created.
  4. On the Edit Logging Profile screen, enable Bot Defense.
    The screen displays the Bot Defense area.
  5. Enable Local Publisher.
  6. Optional: Select a Remote Publisher for your remote logging system such as Splunk.
  7. Enable the types of requests to see in the logs, most typically Log Illegal Requests.
  8. Click Update to save the logging profile properties.
  9. On the Main tab, click Local Traffic > Virtual Servers > Virtual Server List .
  10. Select the virtual serve to attach the login profile to.
    The Policy Settings screen opens.
  11. In Log Profile, add the DoS profile to Selected.
  12. Click Update to update the profile.
  13. Run mobile application traffic to generate logs.
  14. On the Main tab, click Security > Event Logs > Bot Defense .

    Mobile application requests have Client Type set as Mobile Application. Scroll very far to the right to see the Client Type column. You can filter the requests by this criterion.

  15. If you deploy an ASM policy for your application, on the Main tab, click Security > Event Logs > Application > Requests .

    Just as in the Bot Defense log, requests coming from mobile applications can be filtered by their Client Type.

    The same request logged in both Bot Defense and Applications Requests logs will have the same Support ID, so its records can be correlated.

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.

  1. On the Main tab, click Security > Reporting > DoS > Analysis .
  2. At the top of the far right pane, in the Dimension Inspector, select HTTP and use the scroll bar to scroll down to and click Client Types.
  3. Select the mobile application traffic to display its chart.
  4. You can further narrow the results by selecting specific attributes of mobile application traffic in the Dimension Inspector.
    For example, you can filter traffic coming from Android rooted devices in the Dimension Inspector by selecting: Client Type = Mobile Application, OS Name = Android and Jailbreak = True.