Our WAF is flagging our own health checks as attacks. How to fix?

That's a frustrating but classic case of a WAF's behavioral analysis going a bit overboard. When they mentioned the static, repetitive nature being a trigger, that immediately makes sense to me - some of those heuristics are looking for automated attack tools that blast the same request over and over.

One thing you could try, if the WAF allows it, is to add a bit of harmless variation to your health checks. Maybe append a random but innocuous query parameter like `?ts=` with a timestamp, or rotate between a couple of common, legitimate-looking User-Agent strings from a small pool. It tricks the pattern-matching without changing the function.

Also, for the internal monitoring subnet, have you looked into creating a specific WAF rule that just whitelists those source IPs for those specific paths? Most cloud WAFs should let you set an allow rule that bypasses all other inspection for a trusted source and URI combination. It feels a bit brute-force, but it's reliable.

Oh, that sounds so frustrating! I'm just getting into some basic system monitoring for my team's projects and this is a scenario I wouldn't have even thought about. You'd think your own health checks would be safe, right?

When the vendor said the static, repetitive nature could be the trigger, does that mean the WAF is basically seeing the exact same request from the same IP every, say, 30 seconds and flagging it as a bot attack? That seems like a big oversight on their part for a feature meant for automated checks.

Is there a way in that WAF's rules to lower the sensitivity or turn off specific signatures just for those health check endpoints? That seems like it should be the first fix, before having to change the checks themselves. Forgive the basic question, but is that usually a straightforward setting change, or does it get really complicated with these cloud WAFs?

You've hit on the classic tension between static rule-based detection and legitimate automation. The vendor's mention of the static, repetitive nature and the specific order of headers is the key. Many WAF engines build a baseline profile, and a perfectly identical request from a single IP at fixed intervals fits the pattern of a basic scanning tool.

Instead of modifying the health checks themselves as a first step, I'd recommend a layered configuration approach within the WAF. First, create an explicit allow rule for your monitoring subnet IP range targeting the exact paths (`/api/health`, `/status`). This should be your primary, most secure fix as it uses positive security modeling.

However, also inspect the specific triggered signatures. For rules like "Generic SQL Injection" that are likely inspecting query strings, your request has none, so this is a false positive pattern match on the URI path itself. You can often create a rule exclusion for that specific signature ID only for those paths. This is more surgical than disabling the signature entirely. Combining the IP/path allowlist with targeted signature exclusions for those endpoints typically resolves it without altering your monitoring system's logic.

Yep, the layered config approach is the right call. The IP/path allowlist is your solid foundation.

But a quick caveat on the signature exclusions: be really careful you're only excluding the rule ID for *exact* paths, not a broader pattern. I've seen teams accidentally create a rule exclusion for `/api/*` when they only meant `/api/health`, and that opened up a real blind spot.

Also, check if your WAF has a "learning" or baseline-building mode. Sometimes you can put it in that mode for a short period while the health checks run, so it accepts that pattern as normal traffic for those specific sources. It can be a faster fix than manual rule crafting.

That's an excellent point about the learning mode. It's often called "policy tuning" or "baseline generation" in enterprise WAFs. While it can be a faster initial fix, I've found it introduces a different risk if not handled precisely. The system often learns from all traffic during that window, not just the health checks. If you're running it during a period of low activity, you might inadvertently teach it that an *absence* of certain attack patterns is normal, which can lower detection sensitivity broadly.

A more surgical approach is to use that mode, but combine it with a pre-configured scope. If the WAF supports it, you should restrict the learning phase to traffic *only* from your monitoring subnet and *only* to the designated health endpoints. This creates a tight baseline for that specific traffic pattern without polluting the general security profile.

Your caveat on path exclusions is critical. A common pitfall I've seen is regex over-matching. Excluding `/api/health` might seem safe, but if the rule engine uses a simple prefix match, an exclusion for `/api/health` could also apply to `/api/healthcheck/admin` unless the rule syntax explicitly anchors the end of the string. Always verify the match logic with a test outside the exclusion list first.

That's a good point about adding variation, and I've heard of that trick. But doesn't that feel like working around the problem instead of fixing it? You're changing your legitimate monitoring traffic to look "less automated" for a security tool.

I'm still learning WAF configs, but I'd be worried that approach could mask a real issue later. If the health check script gets modified to actually send a bad parameter by accident, the WAF might not catch it because it's already used to seeing random junk on that endpoint from the trusted IP. The IP/path allowlist seems like the cleaner solution to me, even if it is a bit brute-force.

Yeah, that's a classic pain point. When the vendor mentions the static, repetitive nature, it's often because the request pattern looks exactly like a basic vulnerability scanner hammering an endpoint. The lack of referrer and a simple, unchanging User-Agent string just reinforces that signature.

I think the cleanest first step is that IP/path allowlist, as others have mentioned. But given they flagged things like "Generic SQL Injection" on a simple GET, you should also check if the WAF is misreading the static path string itself as an attack pattern. Sometimes the literal `/api/health` string can trip a naive regex if it's looking for things like `'` or `;`. Getting a look at the raw log from the WAF's perspective, not just your app logs, might show you what specific part of the request it's latching onto. That can make your rule tuning a lot more precise.

That's a great point about the raw WAF logs. I've seen similar things happen in my email security tools where a perfectly normal subject line gets flagged because it contains a word like "invoice" that some old regex pattern associates with phishing.

If the WAF is looking at the literal path string, could a health check endpoint like `/status` also trip something if a rule is naively looking for the substring `us` or `stat`? That seems overly broad, but I guess it's possible.

It absolutely could. I've seen WAF regexes so lazy they'd flag the word "select" in any context, even as part of a larger string like "selection". If you have a path like `/status`, some ancient rule looking for `stat` (thinking it's "STAT" from an old FTP attack) might fire. Always demand the exact signature details from the WAF logs. Never assume the vendor's rule descriptions are accurate.

You're right about demanding the raw signature details. The WAF console's simplified "Generic SQL Injection" label is often useless. I've had to parse the underlying ModSecurity-style rule logs to find it was flagging on something like a harmless integer in a query string because a poorly written regex matched `0 OR 1`.

Even with the logs, you sometimes find the rule logic is proprietary and opaque. That's when you have to shift from diagnosis to mitigation: a precise IP/path allowlist becomes the only reliable bypass for a broken detection engine.