De firewall vóór je websites

Een server heeft twee firewalls, en die doen verschillend werk. Die uit De firewall van een server bepaalt welke adressen de machine überhaupt mogen bereiken. Deze bepaalt welke aanvragen een website mogen bereiken: hij leest de adresbalk, het formulier dat iemand verstuurde en de headers die erbij zaten, en weigert wat op een aanval lijkt.

Op een nieuwe server staat hij uit. Er verandert niets aan tot je hem aanzet.

Hij draait alleen op LiteSpeed Enterprise-servers. Op elke andere webserver zegt de pagina dat en biedt hij niets — de regelset heeft de engine nodig die die editie meebrengt. In Een server beheren zie je welke een machine draait.

De pagina openen

Servers → je server → Firewall voor websites. Je moet serverbeheerder zijn.

Begin bij "Meekijken", niet bij "Blokkeren"

Bovenaan de pagina staan drie standen, en het is een ladder en geen schakelaar:

Zet een server eerst op Meekijken en laat hem daar een paar dagen staan. De lijst verderop de pagina vult zich dan met alles wat de regels zouden hebben geweigerd, en je kunt die lezen voordat er één klant last van heeft. Ga pas naar Blokkeren als er niets legitiems meer tussen staat.

Dat is geen formaliteit. Een regelset waar niemand naar gekeken heeft weigert vroeg of laat iets dat een klant nodig heeft, en op die dag zet iemand het hele ding uit.

Als er iets legitiems geweigerd wordt

Elke regel in Wat de regels vingen toont welke regels afgingen, als nummers. Die nummers zijn knoppen.

1. Zoek de treffer op. Het websitefilter staat boven de lijst, en de schakelaar Alleen geweigerd verbergt alles wat alleen genoteerd is.
2. Lees de aanvraag eronder — het adres, en wat de regel zelf zegt te hebben gezien.
3. Is het een legitieme aanvraag, druk dan op het regelnummer. Het paneel vraagt om bevestiging en zegt wat je opgeeft: die regel gaat niet meer af op die ene website, en blijft overal elders gewoon werken.

Terugdraaien doe je in de tabel Websites onderaan: elke regel die je hebt uitgezet staat onder zijn site, en drukken zet hem weer aan.

Eerst een zachtere stap. Struikelt één site over van alles, dan is Weigeren vanaf score verhogen vriendelijker dan regels uitzetten. De regels tellen punten op; de score is waar het totaal een weigering wordt. Van 5 naar 10 houdt elke regel aan het werk en vergeeft de bijna-treffers.

Eén website zachter zetten

In de tabel Websites zet je elke site apart. Een site mag lager staan dan de server — uit, of alleen meekijken terwijl de server blokkeert — en nooit hoger. Zet je een site op Blokkeren terwijl de server alleen meekijkt, dan legt het paneel vast wat je vroeg, toont Vroeg om meer, en blijft de site meekijken tot je de server verhoogt.

Dat is met opzet: de stand van de server is wat jij hebt afgesproken te dragen, en één website beslist niet dat de hele machine aanvragen gaat weigeren.

Wat deze firewall niet ziet

De pagina heeft een sectie die dat zegt, en die is het lezen waard voordat je op de rest vertrouwt:

• Een pagina uit de websitecache wordt nooit beoordeeld. De cache antwoordt voordat de firewall kijkt. CoreCP houdt de WordPress-inlog- en beheerpagina's voor je uit de cache zolang de firewall aanstaat, maar een gecachete pagina is een pagina die de regels niet gelezen hebben.
• Een paar regels draaien niet op deze webserver. Ze vragen om iets dat de engine niet heeft. De pagina noemt hun nummers.
• De WordPress-editor heeft een kleine uitzondering. Zonder die uitzondering loopt het opslaan van een gewoon bericht — met een link, een apostrof en een codevoorbeeld erin — vast op de regels en werkt de editor niet meer. Hij zet vijf met naam genoemde regels uit, op WordPress' eigen editor- en instellingenpagina's, voor een aanvraag die een WordPress-inlogcookie meedraagt. Alle andere regels blijven gelden. Draaien je servers geen WordPress, dan kun je hem in diezelfde sectie uitzetten.
• Webmail en phpMyAdmin worden helemaal niet beoordeeld. phpMyAdmin is er nu juist om SQL te versturen, en dat is precies waar de regels naar kijken.

Wat er van een aanvraag wordt vastgelegd

Gaat er een regel af, dan legt de server de aanvraag vast die hem raakte — het adres, de methode, en de headers die de bezoeker meestuurde. Daar zit de sessiecookie van de bezoeker bij, en bij een map met wachtwoordbeveiliging het wachtwoord zelf. Het bestand is alleen door root op de server te lezen, het paneel toont nooit een header, en alleen aanvragen die een regel raakten worden vastgelegd; het wordt veertien dagen bewaard. De webserver biedt geen manier om die headers weg te laten, dus dit staat er in plaats van dat het opgelost is.

Wat je klanten zien

Van deze pagina niets. Het is een serverpagina, en hij toont elke huurder op die machine tegelijk.

De treffers van hun eigen site staan in hun eigen logboekviewer, onder Logboeken → Firewall-treffers — zie Logboeken bekijken. Ze zien hun eigen websites en die van niemand anders.

Vanaf de opdrachtregel

corectl waf status                                  # waar deze machine op staat
corectl waf set --mode detect                       # ga meekijken
corectl waf hits --limit 20                         # wat de regels vingen
corectl waf hits --domain shop.example.com          # van één website
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                          # en alles wat hij schreef wordt weggehaald

Zie ook

• De firewall van een server — de andere, voor adressen en poorten
• Logboeken bekijken — waar een klant zijn eigen treffers leest
• Besmette bestanden en websitecache — de scanner die naar bestanden kijkt in plaats van naar aanvragen