F5 Logo MyF5
Search
  1. MyF5 Home
  2. BIG-IP Application Security Manager: Implementations
  3. Working with Anti-Bot Mobile Application SDK
Manual Chapter : Working with Anti-Bot Mobile Application SDK

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 17.1.2, 17.1.1, 17.1.0, 17.0.0
Manual Chapter

Working with Anti-Bot Mobile Application SDK

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.
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 publisher, the signing party. This certificate to used for repackaging detection.
  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 Bot Defense profile to detect mobile applications

Before configuring your Bot Defense profile, you must have first uploaded the publisher certificates that you will use in the Bot Defense profile.
You can use an existing Bot Defense 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 Bot Defense mitigation, Web Scraping prevention and Brute Force attack prevention will
not
be applied to mobile app traffic in order not to block the application when they inevitably fail. 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.
When licensed, mobile application protection is enabled by default when creating a Bot Defense profile. The mobile application default settings are:
  • iOS Application Packages
    : Allow Any
  • iPhone Jailbroken Devices
    : Disallowed
  • Android Application Publishers
    : Allow Any
  • Android Rooted Devices
    : Disallowed
  • Debugger Enabled Devices
    : Disallowed
  • CAPTCHAT Substitute for Mobile Applications
    : No Challenge
  • Emulators
    : Disallowed
  1. On the Main tab, click
    Security
    Bot Defense
    Bot Defense Profiles
    .
    The Bot Defense Profiles screen opens, where you can create a new profile (step 2) or use an existing profile (step 3).
  2. To create a new Bot Defense profile:
    1. Click
      Create
      .
      The Create New Bot Profile screen opens.
    2. Type a
      Name
       and
      Description
      .
    3. Click
      Save
      .
      The Bot Defense 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 Bot Defense profile you want to use.
    The Bot Profile Properties screen opens.
  4. On the left, click
    Mobile Applications
    .
  5. In the Mobile Applications area, click
    On
     if it is not already on.
  6. iOS Application Packages
    :
    1. Allow Any
      : If you want to detect authentic mobile application traffic without checking which application sent the request.
    2. Custom
      : 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
      .
  7. iPhone Jailbroken Devices
    : Click
    Allowed
     to allow requests from jailbroken devices. This is
    not
     recommended because it allows unchecked applications with spoofed identities in the system.
  8. Android Application Publisher
    :
    1. Allow Any
      : If you want to detect authentic mobile application traffic without checking which application sent the request.
    2. Custom
      : 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.
  9. Android Rooted Devices
    :
    1. Disallowed
      : Prohibits requests from rooted devices. This is the recommended setting.
    2. Allowed
      : Allows requests from rooted devices. This is
      not
       recommended because rooted devices can allow attackers to hijack sessions of mobile applications for a limited time.
  10. Debugger Enabled Devices
    :
    1. Disallowed
      : Prohibits traffic that passes through an external debugger.
    2. Allowed
      : Allows traffic from devices where the mobile application is attached to an external debugger. Debuggers may tamper with the functionality of the SDK and present a risk.
  11. CAPTCHA Substitute for Mobile Applications
    :
    1. No Challenge
      : The traffic is passed without incident.
    2. Human Behavior Challenge
      : When a CAPTCHA or Client Side Integrity challenge needs to be presented, the SDK checks for human interactions with the screen in the last few seconds. If none are detected, the traffic is blocked.
  12. Emulators
    :
    1. Disallowed
      : If your mobile application is in production.
    2. Allowed
      : If your mobile application is in testing phase.
      Use this option with care because emulators can be abused to create automated attacks on your server application.
  13. Allowed Application Signatures
    : This option is for working with mobile applications which were not built with the Anti-Bot Mobile SDK. This relies on analyzing the User-Agent header field only, which can be easily spoofed, and should be used with care. Select one or more applications from the list to allow or select
    Create Signature
     to create a new application signature.
  14. Click
    Save
     to save the profile configuration.
  15. On the Main tab, click
    Local Traffic
    Virtual Servers
    Virtual Server List
    .
  16. Click the name of the virtual server to attach the Bot Defense profile to.
  17. Select
    Security
    Policies
    from the virtual server submenu.
    The Policy Settings screen opens.
  18. In the
    Bot Defense Profile
    , select Enabled and select the desired Bot Defense Profile from the list.
  19. In
    Log Profile
    , add the local Bot Defense profile to
    Selected
    .
  20. 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.
  11. Select
    Security
    Policies
     from the virtual server submenu.
    The Policy Settings screen opens.
  12. In
    Log Profile
    , add the Bot Defense profile to
    Selected
    .
  13. Click
    Update
     to update the profile.
  14. Run mobile application traffic to generate logs.
  15. 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.
  16. 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 bot traffic statistics. You can see how much of the traffic came from mobile applications at any time in the selected time period. You can also narrow the chart to specific applications by selecting a specific virtual server.
  1. On the Main tab, click
    Security
    Event Log
    Bot Defense
    Bot Traffic
    .
    The Bot Traffic statistics screen opens with all virtual server traffic displayed by default.
  2. At the top of the Virtual Servers pane, select a specific virtual server whose traffic you want to investigate or leave all virtual server traffic statistics displayed.
  3. Select the traffic time period.
A doughnut graph displays the total amount of traffic with the percent of traffic by class, including the Mobile Application class.
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information