WAF (Firewall)

A WAF (Web Application Firewall) inspects each request before it reaches your website and refuses the ones that look like attacks — SQL injection, cross-site scripting, path traversal, command injection and the rest of the usual list.

nsin’s WAF is managed: it ships with the OWASP Core Rule Set, and nsin keeps the rules up to date. You don’t write attack signatures — you decide where the WAF applies and how strict it should be.

Note

The WAF blocks attacks. To keep out traffic that isn’t an attack — a whole country, a path you don’t want public — use a block rule. To limit how often someone can knock, use rate limiting.

Turn it on

1. Go to Rules → Add Rule → WAF.
2. Leave the paths as everything, or narrow it to a section of your site.
3. Set the strictness and sensitivity (below).
4. Save it in dry run first — see below.

Strictness and sensitivity

Two settings decide what gets blocked:

• Strictness (paranoia level, 1–4). How many checks run. Level 1 catches clear attacks with very few false positives. Higher levels catch subtler ones and flag more legitimate requests. Most sites should stay at 1 or 2.
• Sensitivity (threshold). Requests build up a score as they trip checks; when the score reaches this number the request is blocked. A lower number is stricter.

There’s also a body inspection limit — how much of a request’s body is examined, in kilobytes. Large uploads are only checked up to that point, which keeps big file uploads fast. Setting it to zero skips body inspection entirely.

Always start in dry run

A WAF rule can run in dry run: it evaluates every request and records what it would have blocked, but lets everything through.

1. Create the rule in dry run.
2. Leave it for a day or two of normal traffic.
3. Open Monitoring → WAF log and look at what it caught.
4. If real traffic is in there, tune it (below). Otherwise switch to enforce.

This is the single most important habit with a WAF. Going straight to enforce on a busy site is how you break your own checkout page.

Removing false positives

Sometimes a legitimate request looks like an attack — a CMS editor posting HTML, a form that legitimately contains SQL-ish text. The WAF log shows which check matched, by its rule id.

You have three ways out, from most to least surgical:

1. Exclude that rule id on the WAF rule. Everything else keeps working.
2. Narrow the paths so the WAF doesn’t cover that endpoint.
3. Lower the strictness for the whole rule.

Prefer the first. Turning the WAF off across your admin area because of one false positive removes protection exactly where you need it most.

Combining rules

A common, effective layout:

1. A WAF rule over the whole site at strictness 1.
2. A stricter WAF rule scoped to /admin/* or your API.
3. Rate limiting on /login.
4. Block rules for paths you never serve (/wp-login.php on a site that isn’t WordPress).

Common questions

Real visitors are being blocked. Find the request in the WAF log, note the rule id that matched, and exclude that id. If several ids for the same feature are firing, narrow the path instead.

Does the WAF slow my site down? Inspection happens at the edge in a few milliseconds. The body inspection limit is what keeps large uploads from being affected.

Do I still need the WAF if I have a firewall on my server? The WAF stops attacks before they use your server’s bandwidth and CPU. It complements what you run yourself rather than replacing it.

Blocked visitors see nsin’s page. You can replace it with your own — see Custom Error Pages.