The firewall in front of your websites

A server has two firewalls, and they do different jobs. The one under The firewall of a server decides which addresses may reach the machine at all. This one decides which requests may reach a website: it reads the address bar, the form somebody posted and the headers they sent, and refuses the ones that look like an attack.

It is off on a new server. Nothing about it changes until you turn it on.

It runs on LiteSpeed Enterprise servers only. On any other web server the page says so and offers nothing — the rule set needs the engine that edition carries. See Managing a server for how to see which one a machine runs.

Open the page

Servers → your server → Website firewall. You need to be a server administrator.

Start on "Watch", not on "Block"

The top of the page has three settings, and they are a ladder rather than a switch:

Put a server on Watch first and leave it there for a few days. The list further down the page then fills with everything the rules would have refused, and you can read it before a single customer is affected. Move to Block once nothing legitimate is in that list.

That is not a formality. A rule set that has never been looked at will refuse something a customer needs, and the day it does is the day somebody switches the whole thing off.

When something legitimate gets refused

Every entry in What the rules caught shows which rules fired, as numbers. Those numbers are buttons.

1. Find the entry. The website filter is at the top of the list, and the Refused only switch hides everything that was merely recorded.
2. Read the request under it — the address, and the rule's own description of what it thought it saw.
3. If it is a legitimate request, press the rule number. The panel asks you to confirm, and tells you what you give up: that rule stops firing on that one website, and keeps working everywhere else.

To put it back, open the Websites table at the bottom: every rule you switched off is listed under its site, and pressing it there turns it back on.

A gentler step first. If one site trips the rules on all sorts of things, raising Refuse from score is kinder than switching rules off. The rules add up points; the score is where the total becomes a refusal. Going from 5 to 10 keeps every rule working and forgives the near misses.

Turning it down for one website

The Websites table sets each site on its own. A site may be set lower than the server — off, or watch-only while the server blocks — and never higher. If you set a site to Block on a server that is only watching, the panel records what you asked for, shows Asked for more, and the site keeps watching until you raise the server.

That is deliberate: the server's setting is what you agreed to carry, and one website may not decide that the whole machine starts refusing requests.

What this firewall does not see

The page has a section that says so, and it is worth reading before you rely on the rest:

• A page from the website cache is never examined. The cache answers before the firewall gets a look. CoreCP keeps the WordPress login and admin pages out of the cache for you while the firewall is on, but a cached page is a page the rules did not read.
• A few rules do not run on this web server. They ask for something its engine does not have. The page lists their numbers.
• The WordPress editor has a small exception. Without it, saving an ordinary post — one with a link, an apostrophe and a code sample in it — trips the rules and the editor stops working. It switches off five named rules, on WordPress' own editor and settings pages, for a request that carries a WordPress sign-in cookie. Every other rule still applies. You can switch it off in the same section if your servers run no WordPress.
• Webmail and phpMyAdmin are not examined at all. phpMyAdmin's whole job is to send SQL, which is exactly what the rules look for.

What is written down about a request

When a rule fires, the server records the request that tripped it — the address, the method, and the headers the visitor sent. Those headers include the visitor's session cookie, and on a password-protected folder the password itself. The file is readable only by root on the server, nothing in the panel ever shows a header, and only requests that tripped a rule are recorded at all; it is kept for fourteen days. The web server gives no way to leave those headers out, so this is stated rather than solved.

What your customers can see

Nothing on this page. It is a server page, and it shows every tenant on that machine at once.

Their own site's firewall hits are in their own log viewer, under Logs → Firewall hits — see Reading logs. They see their own websites and nobody else's.

From the command line

corectl waf status                                  # what this machine is set to
corectl waf set --mode detect                       # start watching
corectl waf hits --limit 20                         # what the rules caught
corectl waf hits --domain shop.example.com          # one website's
corectl waf rule exclude 942100 --domain shop.example.com
corectl waf rule include 942100 --domain shop.example.com
corectl waf domain set shop.example.com --mode detect
corectl waf set --mode block
corectl waf set --mode off                          # and everything it rendered is removed

See also

• The firewall of a server — the other one, for addresses and ports
• Reading logs — where a customer reads their own hits
• Infected files and the website cache — the scanner that looks at files rather than requests