Firewall vs WAF: what each one sees and stops

What a stateful firewall decides

A Layer 3/4 firewall tracks connections and judges each new one on its addresses, its port and the state of the flow it belongs to. Cisco Firepower, OPNsense and netfilter all do this well: a port that no rule opens is closed, a reply is allowed only for a connection the inside started, and management ports answer only to the ranges that are allow-listed. Its view stops at the transport layer. With TLS in the path it cannot see inside the payload at all unless it terminates the session, and even in the clear it has no concept of a URL, a header, a response status or a login.

What a WAF adds

A web application firewall reads the HTTP transaction after TLS termination, which in practice means it lives in or beside the reverse proxy. It adds three kinds of control the firewall cannot express. Signature rules, such as ModSecurity with the OWASP Core Rule Set, match injection, traversal and known exploit payloads in the request. Behavioural rules count per client and per path: requests per minute on the login route, failed-login responses per address, bot signals in headers and timing. Positive rules state what a path accepts, such as which methods, which content types and what body size, and refuse the rest.

A WAF is not a substitute for the firewall. It sees only the traffic that reaches it, and it knows nothing about SSH, database ports or the management plane.

Where login abuse becomes visible

A failed login is a fact in the response. The application answers a POST to the login path with a status or a redirect that distinguishes failure from success, and the proxy writes that into its access log on every attempt. Counting failures per client per minute is one line of awk over that log, and it is the signal a packet filter has no way to see.

The control has to be keyed on the client, not the account. Account lockout on its own stops attempts against one username and locks out its owner, while the bot moves to the next name on its list. A per-client rate limit on the login route does what the lockout cannot:

# nginx: at most 5 login attempts a minute per client, small burst allowed
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /login {
    limit_req zone=login burst=5 nodelay;
    proxy_pass http://app;
}

HAProxy expresses the same idea with a stick table keyed on source address, and a WAF rule set can count the failed-login response code directly.

How the two fit together

The order is firewall, then TLS termination and the proxy with its WAF rules, then the application. Detection belongs at Layer 7, because that is where the evidence is. Enforcement can be either layer. The proxy can answer the offending client with a 429 or a 403 on its next request, which is enough for most abuse. For a client that keeps coming, the proxy can push the address into the packet filter's dynamic table for a set period, which also drops that client's other connections and costs the firewall nothing per packet.

Two design points come before arming that feedback loop. The operator's management and monitoring ranges go on the allow-list first, so a test or a typo cannot lock out the people who run the platform. And shared addresses are real: an office NAT or a carrier-grade NAT puts many people behind one address, so blocks carry a short expiry and a documented way to lift them. The whole chain is then tested from a host outside the network, as an attacker would meet it, before anyone relies on it.

What neither of them sees

A correct password. Credential stuffing with a leaked, valid password looks like a successful login to every layer. That gap is closed by multi-factor authentication on the account and by allow-listing the administrative paths at the firewall, so that a valid credential is useless from an address that is not yours.