WAF and intrusion detection

The firewall decides whether a connection is allowed. The WAF / IDS looks at the traffic that was allowed and asks a different question: does this look like an attack?

It matches traffic against signatures for known attack patterns — SQL injection, command injection, path traversal, scanners, malware and command-and-control traffic, and reconnaissance.

We maintain the rule signatures. Choosing and updating those is our job, not something you should have to research. What you control is how you’re told about matches, and which of your addresses are watched.

Alert-only vs blocking

The Active protections card shows which mode you’re in.

Alert-only detects and records matches but lets traffic through. Nothing legitimate can break. This is where new setups should start.

Blocking drops traffic that matches. Stronger protection, with a real trade-off: a signature that matches something your application legitimately does will break that feature, and the symptom is a request that mysteriously fails.

The sensible path is to run alert-only long enough to see what your normal traffic actually triggers, review those alerts, then switch to blocking with confidence. Ask us via Support when you want to change mode.

Caution

If a service worked and then started failing in an odd, partial way — one form submission, one API call, one admin page — check your recent alerts before anything else. In blocking mode a false positive looks exactly like an application bug.

Tune your alerts

On the Alert preferences card you choose how you want to hear about matches and which of your IP addresses are monitored.

Two things worth getting right:

Don’t monitor addresses you don’t care about. A staging box that gets scanned all day will bury the alert that mattered.

Match the channel to the severity you’ll act on. Anything routed somewhere you check constantly should be reserved for things you’d genuinely get up for. An alert stream nobody reads is worse than no alert stream, because it looks like coverage.

Reading recent alerts

The Recent alerts card lists what matched, grouped by the kind of attack. Ask three questions:

1. Was it blocked or only recorded? In alert-only mode everything is recorded, which is not the same as stopped.
2. Is the target something you actually run? WordPress exploit attempts against a server with no WordPress on it are noise. The same signature against your actual site is not.
3. Did it repeat? One probe from one address is background. Sustained, varied attempts on one service is someone working on you.

Volume alone isn’t the signal. Every public address is scanned constantly, so a busy list is expected.

What it can and can’t see

This is the important limitation, and it’s better to know it up front than to assume more protection than you have.

Encrypted traffic limits inspection. HTTPS traffic passing straight through to your server is encrypted end to end, so the WAF cannot read the request inside it — it sees a connection, not a SQL injection attempt in the body. Signature matching works fully on unencrypted traffic; on encrypted traffic, inspection is limited to what’s visible from the outside.

The practical consequence: the WAF is a layer, not a substitute. It doesn’t replace patching your application, keeping dependencies current, using strong authentication, or restricting administrative ports to addresses you control.

It doesn’t see private traffic. Server-to-server traffic on your private network doesn’t pass the edge, so it isn’t inspected.

It won’t fix a vulnerable application. A signature can catch a known attack shape. It cannot know that your own code trusts input it shouldn’t.