eBPF is a revolutionary technology with origins in the Linux kernel that can run sandboxed programs in a privileged context such as the operating system kernel. It is used to safely and efficiently extend the kernel's capabilities without requiring changes to the kernel source code or loading kernel modules.

What is fail2ban?

Fail2ban is an intrusion prevention software framework that guards against brute-force attacks by monitoring system log files for suspicious activity and automatically banning malicious IP addresses. It works by parsing log files for patterns, such as excessive failed login attempts, and then updating firewall rules to block the source IP address for a set period of time or indefinitely.

What is the problem?

Fail2Ban faces two key challenges. First, if there’s a lack of synchronization between nodes, each server must independently detect and respond to malicious activity, which makes centralized management difficult. Second, Fail2Ban relies on iptables by default, and iptables itself comes with scalability and performance limitations.

What is the difference between eBPF and iptables?

The solution

Moat — our agents are running on every node and integrated with kernel-level eBPF. If you ban an IP Address or CIDR, ASN, that’s synced across every node, and if you unban it, that’s synced too. Our config is refreshing every 10 seconds.

Moat

You can find our integration on GitHub.

Integration

I wrote this article to demonstrate the power of SSL fingerprinting in security. Our product, Arxignis, is actively using this technology for security purposes.

Most people reading this article have likely seen this technology. The SSL heartens everybody; however, not everybody knows how SSL works.

How does SSL work?

This diagram illustrates how the TCP protocol and SSL work. I don’t want to start from the ground. The most important part here for us is the client's hello. This is the moment when we get more information about our SSL client. Client Hello, help us to understand who is sitting on the other side. Possibly a bad actor or just a simple customer.

Where can we collect this information?

We can obtain the JA3 and JA4/JA4+ client hash only when SSL termination occurs. Therefore, if you are using a CDN or service provider, they must collect this data on your behalf. Some providers are requesting additional compensation for this information. We can collect this information ONLY here.

SSL fingerprinting history

The original idea came from Lee Brotherston. JA3 hash original coming from Salesforce Labs from 2017. The author of this technology is John Althouse, who has written a detailed article on the subject. He left Salesforce and founded a new company named Fox IO. Fox IO developed an improved hashing technology, known as JA4/JA4+.

JA3 vs JA4+

JA3

JA3 creates a fingerprint by serializing (in a fixed order) the decimal values of several TLS ClientHello fields and hashing that string with MD5:

JA3 = MD5(TLSVersion, CipherSuites, Extensions, SupportedGroups, ECPointFormats)

The result is a 32-character hash, known as the JA3 fingerprint. Because different clients (e.g., Chrome on Windows, a Python requests script, or malware) implement TLS differently, they produce distinct JA3 hashes. Security systems leverage this to spot and block suspicious clients, since malware often presents a different—and more static—JA3 than typical browsers.

Limitations of JA3

• Low visibility into differences: Everything is folded into one MD5 value, so you can’t tell why two fingerprints differ without inspecting the raw fields.

• Cipher-suite order randomness: Some legitimate software (notably many Go-based apps) shuffles cipher-suite order, yielding a new JA3 on each connection and complicating tracking.

• No app-layer context: JA3 only covers the TLS handshake and excludes application-level details, such as the HTTP User-Agent.

JA4/JA4+

JA4 is a family of TLS fingerprints from the creators of JA3 that addresses JA3’s blind spots. It’s not a single value but several related ones that add context and resist evasion: JA4 (client), JA4S (server), and JA4X (certificate). Below, we focus on the client-side JA4.

The JA4 fingerprint is a string with three sections, separated by underscores:

JA4 = ProtocolAndVersion _ CipherCount + CipherHash _ ExtensionCount + ExtensionHash + SignatureAlgs

1) Protocol & TLS version

• t = TLS 1.2 or below, q = TLS 1.3

• Followed by the version: e.g., t12, q13.

2) Cipher suites (sorted)

• The number of offered ciphers.

• An underscore.

• A 5-character “fuzzy” hash of the sorted cipher list.

Sorting neutralizes libraries (like many Go clients) that randomize cipher order—so the same client yields a stable JA4.

3) Extensions & signature algorithms

• The number of extensions.

• An underscore.

• A 5-character “fuzzy” hash of the sorted extensions.

• An underscore.

• The signature algorithms.

Example (Chrome-like):

t13_17_15ae45e35b_13_22a2da45a2_0017

You can read this at a glance as a TLS 1.3 client with 17 ciphers and 13 extensions.

JA4+ (adds application context)

JA4+ enriches the network fingerprint with HTTP-layer details, such as:

• HTTP method (GET, POST)

• HTTP version (h1, h2)

• User-Agent

• Accept-Language

By tying TLS behavior to concrete application signals, JA4+ makes it significantly harder for malware to mimic a real browser convincingly.

What problem does this information address?

We have to go back a little bit in time. We have a billion devices around the world, each with an IP address, internal or external. The biggest problem with the world IPv4 pools is that they are deficient. You can imagine that every mobile device connecting to the internet has a public IP address, and this is just one piece of the puzzle.

The result is that we don’t have enough IPv4 addresses, but we do have IPv6 addresses; however, their adoption is not as rapid as ISPs and providers would like it to be. For example, GitHub is not available on IPv6. Crazy right? Lots of other services are also not available on IPv6. ISPs have to find a solution.

What is the ISP solution?

CGNAT

They start to use multiple NAT technologies to solve this problem—for example, CGNAT. The devices use a private IP address, but they transform their side to IPv4 public and connect to the host.

464xlat

464XLAT is an IPv4/IPv6 transition mechanism that enables IPv4-only applications or devices to work over IPv6-only access networks by utilizing a stateless customer-side translator (CLAT) to convert IPv4 addresses into IPv6 and a provider-side stateful NAT64 (PLAT) to access the IPv4 Internet. It’s widely used in mobile networks (LTE/5G, Android) to provide legacy IPv4 service without requiring IPv4 on the access link.

Result

On the server-side, we see one IP address, but that can encompass a large number of devices.

IPs have lost their uniqueness.

We can’t block all attacker IP addresses because it could easily kill our business. If you look at the picture below, you can see multiple clients have the same IP address.

For example, if we have an e-commerce webshop and we block a big ISP CGNAT IP address, we can easily block hundreds of potential customers. The attackers can easily exploit this vulnerability because they often operate from this pool; you are at a disadvantage here. Of course, you block the temporary use of CAPTCHA, but the problem is that you punish your innocent customers. Yeah, you can’t use CAPTCHA for API calls.

How can we identify?

Now we have context about the technology and reasons.

JA4 fingerprints are driven by the TLS stack’s implementation details—cipher-suite preferences, extension ordering, ALPN lists—not just the application itself. For example:

• Chrome (BoringSSL) will yield a different JA4 than a Python bot using requests (typically OpenSSL).

• Malware with embedded or outdated TLS stacks often produces rare JA4s that are easily identifiable.

• Even bots that rotate IPs or spoof User-Agents frequently keep a stable JA4, making them traceable across multiple requests.

In what ways can we use these findings?

Threat detection

• Treat the JA4/TLS fingerprint as the client identity key.

• Link activity across IP churn and UA spoofing.

• Use similarity matching (e.g., distance on cipher/extension order, ALPN sets) to catch “nearby” variants.

• Flag outliers: rare or outdated stacks are high-risk.

• Fuse with request shape (method/path/header order), velocity, and reputation.

• Outcomes: tag → raise score → challenge → block.

WAF

• Feed the fingerprint and related features into a risk score:

  • score = w1*rarity + w2*bad_reputation + w3*behavior_anomaly + w4*path_sensitivity

• Action matrix: allow (<T1) → throttle/challenge (T1–T2) → block (>T2).

• Maintain allow/deny clusters (known-good browsers vs. bot toolkits).

• Keep static edge signatures for known exploits/CVEs for immediate drops.

• Log reason codes (fingerprint, rule hit, score) for auditability.

Rate-limit

• Prefer entity limits over IP limits: bucket per TLS fingerprint (JA4).

• Reduces collateral damage behind NAT/CGNAT and shared proxies.

• Separate pools for sensitive endpoints; cap bursts and in-flight concurrency.

• If fingerprints rotate, compose the key (JA4 + header order + cookie/session) before throttling. No single indicator stops everything. Utilize TLS fingerprints in conjunction with other data to construct a more intelligent and resilient defense.

Service provider support

https://docs.aws.amazon.com/waf/latest/APIReference/API_JA4Fingerprint.html

https://cloud.google.com/load-balancing/docs/https/custom-headers#variables

https://developers.cloudflare.com/bots/additional-configurations/ja3-ja4-fingerprint/

https://ngrok.com/docs/traffic-policy/variables/connection/#conntlsja4_fingerprint

https://github.com/arxignis/nginx

Arxignis

We are building multi-layer services because the best result is similar to an onion.

Arxignis architecture

If you have any questions, please join our Discord community.

Author: David Papp

LinkedIn: https://www.linkedin.com/in/davpapp/