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 servers with nginx + Apache, with Apache alone, and with LiteSpeed Enterprise. On a server with nginx alone or with OpenLiteSpeed the page says so and offers nothing. See Managing a server for how to see which web server a machine runs.

Under the page is one rule set (the OWASP Core Rule Set) and one of two engines:

The page names the engine a server uses, under the ladder. The controls are the same for both. The first time you switch the firewall on for an Apache server, the server installs the engine and restarts Apache once; every change after that happens without a restart.

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 (LiteSpeed). 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 (LiteSpeed). They ask for something its engine does not have. The page lists their numbers.
• What nginx answers itself never reaches the rules (nginx + Apache): certificate challenges, the redirect of an alias name, the page of a suspended website, and webmail and phpMyAdmin.
• A very large request is read only in part (Apache). Above 128 MiB — usually an upload — the beginning is examined and the rest passes unread. A request the engine cannot read at all is refused on Block.
• 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. 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.

On an Apache server the session cookie and the password of a protected folder are replaced by asterisks in that file. LiteSpeed cannot do that: there they are in it in the clear, and 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

On an Apache server the engine package (corecp-modsecurity2) stays when you switch the firewall off. It can be removed only once the firewall is off; while it is on the package refuses, so Apache never restarts without its engine.

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