Why IP Blocking Isn’t Always the Best Answer

IP reputation is an important security signal, but modern infrastructure makes IP-based decisions increasingly complicated.

Attackers frequently operate from legitimate cloud environments, including infrastructure belonging to major providers such as AWS and Microsoft. An IP can generate clearly malicious traffic while still belonging to infrastructure that may also serve legitimate users.

In these cases, permanently greylisting or blacklisting the IP isn’t always the right solution.

The IP itself isn’t necessarily the problem. The request is.

This is where JA4H fingerprinting gives us another layer of information.

Blocking the Request, Not the IP

JA4H creates fingerprints based on characteristics of HTTP requests. This allows us to recognize request patterns associated with clients we’ve previously identified as malicious or highly suspicious.

With our latest WAF Pro development, we can use this information very early in the Caddy request-processing pipeline.

For HTTPS traffic, once the TLS connection has been established and the HTTP request is available for fingerprinting, BitNinja can evaluate its JA4H fingerprint.

If it matches a fingerprint we have identified as malicious, the request can be rejected before reaching the protected backend application.

Instead of blocking an entire IP address, we can make a much more granular decision:

Bad fingerprint → Block the matching request.

This is particularly valuable when malicious traffic originates from shared cloud infrastructure that we don’t want to broadly blacklist.

4 Million+ Requests Blocked with Just Five Fingerprints

We’re starting conservatively.

The first rollout monitors only five selected JA4H fingerprints associated with traffic we already had strong reasons to consider malicious.

Even with this deliberately small initial set, the impact was immediate.

More than 4 million matching requests were blocked in less than 24 hours.

This is especially interesting because some of this activity comes from cloud infrastructure that is difficult to handle through IP reputation alone.

JA4H allows us to be much more precise: rather than treating an entire source network as malicious, we can target the request patterns associated with unwanted activity.

Can JA4H Help Against DDoS Attacks?

Yes, for certain types of attacks.

JA4H operates at the HTTP layer, so the attacker needs to progress far enough through the connection to send an HTTP request.

That makes this approach useful against certain HTTP and application-layer DDoS attacks , including attacks where clients successfully establish TLS connections before flooding the server with requests.

By identifying known malicious fingerprints early, those requests can be rejected before unnecessary backend processing takes place.

However, this is not a replacement for network-layer DDoS protection .

For example, JA4H cannot stop a SYN flood , because a SYN flood attacks the TCP connection establishment process before an HTTP request and therefore a JA4H fingerprint exists.

Another Layer of WAF Protection

It provides an additional security signal that helps BitNinja identify and block malicious requests earlier.

Known malicious fingerprints can potentially be rejected quickly, while other requests continue through the normal WAF analysis pipeline.

This gives us another layer for making server protection more targeted and efficient: identify earlier, block more precisely, and avoid unnecessarily blocking legitimate infrastructure.

What Else Is New in BitNinja 3.16.14?

The BitNinja Linux Agent 3.16.14 Frequent Beta release also includes several additional improvements.

WAF Pro receives fixes for backend server detection and dependency handling for functionality relying on the WAF3 package.

ProcessAnalysis includes fixes aimed at improving the reliability and stability of process analysis.

We’ve also updated the uninstall workflow to handle configurations and modules more consistently when BitNinja is removed.

What’s Next?

The current JA4H rollout is intentionally limited to a small number of fingerprints while we evaluate effectiveness and false positives in real-world environments.

But the early numbers already demonstrate the potential.

Five fingerprints. Less than 24 hours. More than 4 million requests blocked.

IP reputation remains an important part of server security. But sometimes the better security decision isn’t to block where the traffic came from.

It’s to identify and stop the malicious request itself.