Web application firewall

1. Settings, WAF rule set, choose the long term support track and press Install it now. Check every node got it.
2. Open one site, WAF tab, set the mode to Watching, refuse nothing. Apply.
3. Leave it a week and look at what fired.
4. Run a learning session against a proper test pass and save a profile.
5. Apply the profile and stay in watching mode for a few more days.
6. Move to Block known malicious. Watch for a week.
7. Only then consider full enforcement, one strictness step at a time.

Going straight to blocking on a live site is how people conclude that WAFs do not work.

Settings, WAF rule set. Choose a track, save the page first, then press Install it now. It goes to every node, because a node without the rules refuses the whole configuration and the apply is turned away.

Having the rules on a node does not switch anything on. A site is only checked once its own WAF setting is turned on, and that starts in watching mode.

A new rule can start refusing something your own application does, on a site already in blocking mode. That is the whole trade off.

1. Open the site, WAF tab, Learning session.
2. Put in the addresses your testers will come from. An office, a VPN, a build runner, somebody's laptop.
3. Name the round, such as "checkout regression, August release".
4. Press Start watching.
5. Exercise the application properly. Click everything, upload something, use the search, post text with quotes in it.
6. Press Stop watching, look at what fired, tick what is your application rather than an attack, and save it as a profile.

Because the internet does not stop while you test. Without a filter the session would collect every scanner and every genuine probe that arrived during the window, and you would end up excusing rules on the strength of somebody else's attack.

Do not raise the strictness or turn the rule off globally. Run a learning session, reproduce the action, and tick that specific rule on that specific path as an exclusion. It stops that one rule firing on that one path and changes nothing else.

Paths that hold an id are collapsed to a star automatically, so /user/*/profile covers the account created tomorrow.

Check them before saving. A star in the wrong place allows more than you meant. A missing one refuses everything created after today, and that failure only shows up when a new record is made, which could be weeks later.

Save the exclusions as a profile, then set each site to that profile. Editing it changes every site using it at the next apply, which is the point of having them. Every profile card lists the sites relying on it.

Separate from the attack rules. Off means the rules decide on their own and anything they do not recognize reaches your application, which is how nearly every WAF works and is the right default.

The stricter settings only allow paths your testers actually reached. Only sane for an application whose surface is genuinely fixed, and it will refuse anything you forgot to test.

A 403. If the site has an error page template covering 403, they see your page rather than the bare nginx one, which is worth setting up before you start blocking.

Inspecting every request is not free. Expect a measurable increase in processor use and a small amount of added latency. On the fleet the numbers on this site came from, the load balancers ran at around 8% of sixteen cores under 2,000 requests a second, so there is plenty of headroom. Measure your own rather than trusting that.

The rules have not been installed yet. Settings, WAF rule set, save the page, then Install it now. It takes a few seconds. Until then the WAF cannot be applied, and the site page says so rather than letting you configure something that would fail.

Open the site, WAF tab, set the mode to Off, and apply. Nothing is checked for that site and requests reach your backend exactly as they did before. The rules stay installed on the nodes and other sites are unaffected.