Identify and Block Malicious Traffic Using JA3/JA4 Fingerprints

Knowledge Articles
1

Overview

Auth0 Attack Protection features help mitigate malicious attempts to access your application by throttling traffic from specific IPs, displaying a CAPTCHA, requiring MFA, or blocking login attempts for specific end-user accounts.

While these features can help mitigate unauthorized system access, malicious traffic may consume rate limits unnecessarily or increase the volume of tenant logs. Such an increase can impact costs in upstream systems that receive and process those logs.

Network-level blocking of the attempts detected by attack protection features may complement the tenant’s overall protection and mitigate the impact on rate limits or systems processing tenant logs.

Applies To

  • Attack Protection
  • Tenant Access Control

Cause

Sophisticated attack actors may be able to use multiple IPs across a wide variety of geographies as the source of malicious traffic, avoiding more traditional blocking of traffic based on individual IP addresses or IP address ranges.

Solution

If the investigation into a potential attack concludes that the attacker uses multiple IP addresses concurrently or rotates from one IP address to another when a specific IP address is blocked explicitly, blocking of malicious traffic based on JA3/JA4 fingerprints is an available alternative.

JA3 and JA4 are methods for creating fingerprints of clients who initiate secure connections using TLS/SSL. They help identify applications, even if they are spoofing their identity or changing their IP address.

The attack protection playbooks provide steps for identifying bot traffic and investigating potential attacks using tenant logs. A JA3/JA4 fingerprint is available in supported scenarios within specific tenant log types.

More specifically, a ja3 and a ja4 field would be available within the security_context object. Use the auth0-log-schemas repository to confirm which specific tenant log types may have this information available.

Alternatively to tenant logs, and in a similar fashion, JA3/JA4 fingerprints for the ongoing transaction may also be available within the event object of the following action triggers:

Remember that the fields are optional and may be absent. Also, JA3/JA4 are fingerprints of the client’s TLS handshake, so they are mostly relevant in tenants where Auth0 acts as the network edge for public traffic. For example, in a tenant using a self-managed certificate custom domain, JA3/JA4 fingerprints for requests performed through the custom domain would reflect the fingerprint of the reverse proxy used in implementing this type of custom domain and, as such, would not be helpful for network-blocking.

Once the JA3/JA4 fingerprints associated with a potential attack are determined, using either tenant logs or extensibility, create a tenant access control list rule that uses a match condition on the applicable ja3_fingerprints or ja4_fingerprints. For example, the following rule configuration illustrates how to configure a rule using the Management API endpoint (Create Access Control List) that blocks authentication-related traffic associated with a specific JA4 fingerprint:

{
  "description": "Block authentication traffic from malicious JA4",
  "active": true,
  "priority": 1,
  "rule": {
    "action": {
      "block": true
    },
    "match": {
      "ja4_fingerprints": ["t13d201100_2b729b4bf6f3_9e7b989ebec8"]
    },
    "scope": "authentication"
  }
}