When blocking the IP is not enough

A banned address is a satisfying little victory. Unfortunately, an address is not a person, and a determined visitor may arrive with a rather full wardrobe of them. The useful question is what the application can recognize when the costume changes.

A common approach to protecting a website is straightforward: if one IP address sends too many requests, block it.

That works—until the traffic stops coming from one IP address.

Modern web applications can face traffic distributed across VPNs, proxies, cloud infrastructure, compromised devices, and other networks. Ten thousand suspicious requests arriving from one address are easy to recognize. Ten thousand requests arriving from a thousand addresses can look very different.

That distinction matters because effective application security is increasingly about recognizing behavior, not simply maintaining a list of bad addresses.

The Limits of Basic Rate Limiting

Imagine a customer portal that allows 100 login attempts from an IP address before a security control intervenes.

An attacker sending thousands of requests from a single address quickly crosses that threshold.

Now change the scenario.

Instead of one address sending 10,000 requests, 1,000 addresses each send 10.

No individual address comes close to the limit, but the application still receives 10,000 requests.

This is why IP-based rate limiting should be considered one layer of protection rather than the entire defense.

Look at the Request From More Than One Direction

Modern web application firewalls can evaluate considerably more than source IP.

For an application protected by AWS WAF, for example, rate-based controls can aggregate traffic using characteristics including IP address, autonomous system number (ASN), HTTP method, URI path, cookies, query arguments, labels, and TLS client fingerprints such as JA3 and JA4. [1]

That creates opportunities to identify patterns that would otherwise disappear when an attacker changes addresses.

A login endpoint might therefore be protected at several levels:

Per-IP behavior: Is one source generating an abnormal number of requests?

Network behavior: Are many addresses from the same network producing similar traffic?

Endpoint behavior: Is /login suddenly receiving dramatically more traffic than normal?

Client characteristics: Do supposedly unrelated sources exhibit the same recognizable client characteristics?

But there is another layer that a firewall cannot completely understand: the business meaning of the request.

The Application Knows Things the Firewall Doesn't

Consider two scenarios.

In the first, 500 IP addresses repeatedly attempt to authenticate against one customer account.

In the second, those same addresses each attempt to authenticate against hundreds of different accounts.

Network traffic might look similar. From the application's perspective, they represent very different events.

That creates an important distinction between edge security and application security.

The edge can answer questions such as:

How much traffic is reaching this endpoint, and what characteristics does it have?

The application can answer:

What is happening to this customer account?

Good security monitoring connects the two.

An application might recognize that an account normally experiences one or two failed authentications in a day but has suddenly received attempts from dozens of different sources. Conversely, it might recognize a large increase in failed authentications across the entire customer population.

Neither situation is adequately described by simply asking whether an individual IP address exceeded a threshold.

What About the Logs?

More logging is not automatically better security.

If every unwanted request reaches the application, executes PHP, touches a database, and generates several verbose log entries, abusive traffic can consume application resources while simultaneously increasing log ingestion and storage.

The better objective is to reject obviously unwanted traffic as cheaply and as early as practical while preserving enough information to understand what happened.

A typical architecture might look like:

Internet → CDN/edge → Web Application Firewall → Load Balancer → Application → Security Events → Detection → Alert

Traffic that can confidently be rejected near the edge should not unnecessarily consume application resources.

Requests that require application context can proceed farther into the system, where authentication, authorization, and business-specific controls can make better decisions.

Logs should then capture useful security events without storing passwords, session tokens, API credentials, or other secrets.

Automation Requires Configuration

A Web Application Firewall can automatically enforce rate limits, challenges, and blocking decisions after appropriate rules are configured.

The important phrase is after appropriate rules are configured.

There is no universal number of requests that constitutes an attack.

Ten requests per second could be extraordinary for one administrative portal and completely ordinary for a busy API. An authentication endpoint has different expected behavior from an image server. A business application used by 30 employees has a different baseline from an e-commerce platform serving thousands of customers.

Security controls therefore need to reflect the application they protect.

The process should be:

Measure → Establish normal behavior → Define controls → Simulate abnormal behavior → Observe → Tune → Retest

That last part is frequently overlooked.

A security control existing in a configuration screen does not prove that it works as intended.

Test the Entire Chain

When evaluating a client system, the useful question isn't merely:

“Do you have a WAF?”

Better questions are:

• Does abnormal traffic trigger the expected control?
• How much unwanted traffic reaches the application before intervention?
• Does legitimate traffic continue working?
• Are meaningful security events retained?
• Does suspicious application behavior create a detection?
• Does that detection reach somebody responsible for acting on it?
• Can the same controlled test be repeated after remediation?

That turns security from a collection of installed products into a set of verifiable controls.

And that distinction matters.

A firewall can be enabled.

Logging can be enabled.

Monitoring can be enabled.

The more valuable question is whether the organization can demonstrate what happens when something actually goes wrong.

At Zyel, that is the standard we increasingly prefer for business-critical systems: don't simply confirm that a security control exists. Test what it does, measure the result, and verify the complete path from suspicious activity to response.