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 op servers met nginx + Apache, met alleen Apache, met alleen nginx en met LiteSpeed Enterprise. Op een server met OpenLiteSpeed zegt de pagina dat en biedt hij niets. In Een server beheren zie je welke webserver een machine draait.

Onder de pagina zit één regelset (OWASP Core Rule Set) en een van drie motoren:

Welke motor een server gebruikt staat op de pagina, onder de ladder. De bediening is voor alle drie gelijk. Zet je de firewall op een Apache-server voor het eerst aan, dan installeert de server de motor en start Apache één keer opnieuw; daarna gaat elke wijziging zonder herstart. Op een server met alleen nginx gaat ook het eerste aanzetten zonder herstart.

Op een server met alleen nginx hoort de motor bij precies de nginx-versie die de server draait. Een nginx-update naar een versie waar nog geen motor voor is, wordt geweigerd zolang de firewall aanstaat — de server houdt dan de nginx die zijn firewall kan laden, in plaats van een nginx die niet meer start.

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 (LiteSpeed). 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 (LiteSpeed). Ze vragen om iets dat de engine niet heeft. De pagina noemt hun nummers.
• Wat nginx zelf beantwoordt, komt niet langs de regels (nginx + Apache): certificaatcontroles, de doorverwijzing van een aliasnaam, de pagina van een opgeschorte website, en webmail en phpMyAdmin.
• Wat nginx zonder de regels beantwoordt (alleen nginx): de doorverwijzing van een aliasnaam, aanvragen voor een naam die geen website op de server draagt, en webmail en phpMyAdmin.
• ModSecurity 3 geeft een paar valse treffers op XML (alleen nginx). Elke aanval uit de testset van de regelset wordt gevangen, maar een handvol gewone XML-berichten kan een Java-regel laten afgaan die op Apache stil blijft. Stuurt een website zelf XML en gebeurt dat, dan zet je die ene regel voor die website uit zoals hierboven.
• Een heel grote aanvraag wordt maar deels gelezen (Apache en alleen nginx). Boven 128 MiB — meestal een upload — wordt het begin gecontroleerd en gaat de rest ongelezen door. Een aanvraag die de motor helemaal niet kan lezen, wordt in de stand Blokkeren geweigerd.
• 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. 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.

Op een Apache-server worden de sessiecookie en het wachtwoord van een beveiligde map in dat bestand vervangen door sterretjes. Op LiteSpeed en op een server met alleen nginx kan dat niet: daar staan ze er leesbaar in, en 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

Op een Apache-server blijft het motorpakket (corecp-modsecurity2) staan als je de firewall uitzet. Verwijderen kan pas als de firewall uit is; zolang hij aanstaat weigert het pakket, zodat Apache niet zonder motor opnieuw start. Op een server met alleen nginx geldt hetzelfde voor corecp-nginx-modsecurity.

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