WAF false positives: targeted exclusions

Back to the Web Application Firewall section

A WAF rule sometimes blocks your own visitors.
A contact form, a ticket description or a search box can hold text that looks like an attack to the OWASP rules.
The usual reaction is to write whitelist rules by hand.
When that does not work, the administrator disables the WAF for the whole site, and the site loses all its protection.

The False positives page handles this case.
Artica reads the WAF events of the last 7 days and looks for a rule that blocks only legitimate visitors on one path of a site.
When it finds one, it proposes an exclusion limited to that rule, that path, that site and, when it is known, that form field.
Nothing is applied until you click Apply exclusion and confirm.

Benefits

• You keep the WAF on.
  The exclusion removes one rule from one field of one page, and every other rule keeps protecting the site.
• You do not need to read audit logs or write ModSecurity syntax.
  Artica writes the directive and shows it before you apply it.
• Each proposal comes with its evidence: how many clean IP addresses were blocked, which internet providers they came from, how many requests were refused.
• Attackers are left out of the evidence.
  An IP address that is banned, listed by Spamhaus, hosted in a data center or flagged by IPQualityScore never counts as a legitimate visitor.
• The exclusion is reversible.
  One click removes it and the rules block those requests again.
• A rejected proposal stays rejected.
  Artica does not show it again on the next analysis.

How Artica detects a false positive

The reverse-proxy daemon runs the analysis every hour.
You can also start it with the Analyze now button.

The analysis groups the WAF events of the last 7 days by site, exact path and field.
A field is the part of the request the rule inspected, for example ARGS:description for a form field named description.
When the WAF event names no field, the group covers the whole path.

Each client IP address of a group is then classified.
An IP address is clean when all of the following are true:

• It is not in a ban list of the appliance (dangerous paths, ASN flood, CrowdSec, and the DecisionIP lists for active attacks, anonymous relays, unethical bots and honeypots).
• It is not in the Spamhaus DROP list, when this list is installed.
• Its network (AS number) is not a hosting provider, a cloud or a VPS provider.
• IPQualityScore does not flag it, when IPQualityScore is configured.
  A fraud score above 70, a proxy, a VPN, Tor or a data center connection makes it suspicious.

An IP address that matches one of these lists is suspicious.
An IP address that cannot be checked, for example a private address with no AS number, is unverified and counts on neither side.
For IPv6, all the addresses of one /56 network count as one visitor.

Artica creates a proposal when a group reaches these three conditions over the 7 days:

1. At least 5 different clean IP addresses.
2. No suspicious IP address at all.
3. At least one request really refused by the WAF.

A group gives one proposal, even when several rules fire on the same field.
The proposal then lists every rule involved.

Requirements

• The Web Application Firewall is installed and enabled on the site.
• The default action of the site is Alert and Deny.
  A site in detection mode refuses nothing, so it never gets a proposal.
• WAF events are stored in the statistics database (PostgreSQL).
• The GeoIP databases are updated, so that Artica can find the AS number of an IP address.
  Without them, every IP address stays unverified and the page shows a warning.
• Your account has the Web Security privilege to apply, reject or remove a proposal.

Open the page

There are two ways to reach it.

• In the left menu, open Web Firewall and click False positives.
  The page lists the proposals of all sites.
• Open the WAF settings of a site and click the False positives line.
  The page opens filtered on that site.

The header shows three counters.
Pending proposals and Applied exclusions count the proposals in each state.
Sites to review counts the sites that have at least one pending proposal.

Under the counters, Artica shows the time of the last analysis and how many groups and IP addresses it checked.
Use Pending, Applied and Rejected to switch lists, and the Site selector to filter on one site.

Read a proposal

In this example, two rules block the description field of the /support/ticket page on the site articatech.main.
The card shows:

• The path and the field.
• Each rule with its message and the number of times it fired.
• The evidence: 5 clean IP addresses, 0 suspicious, 1 unverified, 10 hits in 7 days, 10 requests blocked.
• The internet providers of the clean visitors.
  Here they are home ISPs, which is what you expect from real customers.
• The exact directives Artica will add, and the path they apply to.

Read the evidence before you apply.
Five visitors coming from home ISPs and filling the same form field is a strong sign of a false positive.
If the field should never hold code or SQL, the rule may be doing its job, and you should reject the proposal.

Check the blocked requests

Click Show requests to see the requests of this path that triggered these rules.

The list comes from the current access log of the site.
It shows every request of the path that triggered one of the rules, whatever field was involved.
Older events that left the current log are not listed, even though they still count in the evidence.

Apply the exclusion

Click Apply exclusion.
Artica asks for a confirmation and repeats what will change.

After you confirm, Artica writes one whitelist entry per rule and rebuilds the WAF rules of the site.
Each entry is limited in four ways:

• The rule: only the listed rule IDs.
• The field: the rule stops inspecting this field only.
  Other fields of the same form are still inspected.
• The path: the exact path, compared character by character.
  /support/ticket does not cover /support/ticket/2.
• The site: the host names of the site, on any port.

The directive looks like this:

ctl:ruleRemoveTargetById=942100;ARGS:description

On our test appliance, after the exclusion, the same request on the description field reached the web server.
The same text in another field of /support/ticket was still refused with HTTP 405.

If an analysis changed the list of rules while you were reading the proposal, the page refuses to apply it and asks you to reload.

Applied exclusions

The Applied list shows who applied each proposal and when.

Click Remove exclusion to delete it.
The rules block those requests again as soon as the WAF rules are rebuilt.

The exclusions also appear in Web Firewall > Whitelists, with the exact path and Artica labels.
They are read only on that page.
Remove them from the False positives page, so that the proposal and the whitelist stay in step.

Reject a proposal

Click Reject when the rule is right to block these requests.
The proposal moves to the Rejected list and does not come back by itself.
Click Restore in that list if you change your mind.

Artica also withdraws a pending proposal on its own when a suspicious IP address shows up on the same site, path and field.
A withdrawn proposal can come back only when that suspicious event is more than 7 days old.

Hosting providers

Visitors from data centers, cloud and VPS providers never count as legitimate users.
Artica ships a built-in list of 20 networks, such as OVH, Hetzner Online, Amazon AWS, Microsoft Azure, DigitalOcean and Scaleway.
Click Hosting providers in the header to see it.

• Click Add a hosting provider and type an AS number, for example 16276 or AS16276.
• Click the icon at the end of a line to stop treating a network as a hosting provider.
  Do this only for a network whose visitors are real users, for example your company network hosted in a data center.
• A built-in network you removed is listed apart, and you can reset it.

Notifications

When an analysis creates a new proposal, Artica adds an event to the Web Console notifications.
The event reads WAF: N new false-positive proposal(s) and lists each site, path and field.

Artica AI

Artica AI can list the proposals and their evidence.
It can also apply or reject a proposal, but only after an administrator approves the action.
It never applies an exclusion on its own.

Limitations

• VPN exits are not detected yet, unless IPQualityScore is configured.
  Without it, a visitor behind a home VPN service counts as clean if the VPN network is not in the hosting list.
• Sites in detection mode never get a proposal, because their rules refuse nothing.
• The analysis only sees events of the last 7 days.
  A rule that fires once a month will not reach the threshold.
• An analysis checks at most 5,000 IP addresses.
  Groups that do not fit are checked on the next run.
  A single group with more than 5,000 IP addresses is never checked.
• Paths that contain a space, a percent sign, a quote or a backslash are skipped, because the exclusion compares the path exactly.
• The site is identified by the Host header of the request.
• The requests blocked counter relies on the HTTP 405 or 403 status recorded in the WAF report.
  If the web server behind the proxy answers 405 or 403 itself, the request is counted as blocked.
  This counter does not change the decision.
• Show requests reads only the current access log of the site.
• A proposal cannot be deleted.
  It stays in the Rejected list.

Troubleshooting

REST API

The reverse-proxy daemon exposes these routes on its Unix socket /run/reverse-proxy.sock.

Example:

curl -s --unix-socket /run/reverse-proxy.sock http://localhost/waf/fp/proposals?state=pending

Related pages

• Activate the WAF engine on your websites
• Disable rules using threats events
• Display all whitelisted rules