Sophos Firewall WAF: Webserver veilig publiceren

Met Web Server Protection of Web Application Firewall (WAF) publiceer je interne of cloudgebaseerde webapplicaties via de Sophos Firewall. De firewall fungeert als een reverse proxy: clients verbinden zich met het openbare adres van de firewall, de firewall controleert HTTP- of HTTPS-verkeer en stuurt het verzoek door naar de beveiligde webserver.

Een WAF-regel vervangt niet automatisch veilige applicatieontwikkeling, patching, sterke authenticatie of serverhardening. In vergelijking met eenvoudige poortdoorschakeling vermindert het echter aanzienlijk de aanvalsoppervlakte, omdat HTTP(S)-verkeer gerichter kan worden gecontroleerd, beperkt en gelogd.

WAF is echter niet automatisch de juiste oplossing voor elke publicatie. Het is cruciaal of de applicatie daadwerkelijk goed functioneert via HTTP of HTTPS, of de firewall hostnamen en paden moet evalueren en of de extra reverse proxy-laag bij de applicatie past.

Wanneer WAF in plaats van DNAT zinvol is

Voor eenvoudige TCP- of UDP-diensten gebruik je nog steeds NAT en firewallregels. Voor webapplicaties is WAF vaak de betere keuze.

Als je alleen snel een interne webserver via poortdoorschakeling toegankelijk wilt maken, helpt de handleiding Server publiceren via DNAT op Sophos Firewall. Voor openbare webapplicaties moet je eerst WAF overwegen.

⚠️ WebDAV wordt niet ondersteund door Sophos WAF. Applicaties zoals Nextcloud moeten daarom niet blindelings via WAF worden gepubliceerd, maar via passende firewall- en NAT-regels of een andere publicatiearchitectuur worden gepland.

Beslissing: WAF, DNAT of privétoegang

De belangrijkste vraag is niet hoe snel een publicatie is gebouwd, maar of deze later veilig kan worden beheerd, getest en teruggedraaid. Deze indeling helpt vóór de technische implementatie:

Voor privétoepassingen is een wereldwijd bereikbare WAF-regel vaak te veel aanvalsoppervlakte. Als slechts enkele personen toegang nodig hebben, zijn vaste bronnetwerken, VPN, ZTNA of een andere privétoegangsarchitectuur vaak schoner dan een openbare webpublicatie.

Vereisten

Voor de eerste WAF-regel moet je deze punten verduidelijken:

• Openbare DNS-naam, bijvoorbeeld portal.example.com
• Openbaar IP-adres of alias op de WAN-interface
• Certificaat voor de gepubliceerde hostnaam
• Intern IP-adres of FQDN van de webserver
• Interne doelpoort van de webserver
• Beslissing of HTTP naar HTTPS wordt omgeleid
• Toegestane bronnetwerken, landen of gebruikersgroepen
• Passend beschermingsprofiel en optioneel IPS-beleid
• Geactiveerde logging voor latere analyse
• Externe testtoegang buiten het eigen LAN

De openbare DNS-naam moet wijzen naar het adres dat in de WAF-regel als Hosted address wordt gebruikt. Bij HTTPS moet het certificaat overeenkomen met de gepubliceerde hostnaam.

WAF-publicatie plannen vóór configuratie

Een WAF-regel moet niet pas in de interface worden gepland. Van tevoren moet duidelijk zijn of de Sophos Firewall alleen moet publiceren of dat deze ook authenticatie, beschermingsprofielen, landregels en logging moet overnemen.

Deze vragen zijn belangrijk vóór een productieve publicatie:

Voor certificaten moet je vroegtijdig verduidelijken of een bestaand certificaat wordt geïmporteerd, of de firewall zelf een Let’s-Encrypt-certificaat aanmaakt en vernieuwt of dat een extern gegenereerd certificaat nodig is. Voor wildcard-certificaten is er een aparte handleiding: Let’s Encrypt Wildcard Certificaat aanmaken.

Basisstructuur van een WAF-regel

Een WAF-publicatie bestaat uit meerdere bouwstenen:

Sophos maakt WAF-regels in het gedeelte van de firewallregels. De actie heet Protect with web server protection.

WAF-regel maken

Het menupad is:

Rules and policies > Firewall rules

Stappen:

1. Selecteer IPv4.
2. Open Add firewall rule.
3. Kies New firewall rule.
4. Geef een duidelijke regelnaam.
5. Kies bij Action de optie Protect with web server protection.
6. Laat Preconfigured template op None als er geen speciale sjabloon nodig is.
7. Definieer onder Hosted server details het openbare adres, de luisterpoort, HTTPS, certificaat en domeinen.
8. Selecteer of maak de interne webserver onder Protected servers.
9. Stel bewust Allowed client networks in. Voor openbare websites kan Any IPv4 nodig zijn, voor portalen is een beperking meestal beter.
10. Stel indien nodig Blocked client networks of Blocked countries in.
11. Controleer beschermingsprofiel, IPS en geavanceerde opties.
12. Sla de regel op en test extern.

Wanneer de regel wordt opgeslagen, start Sophos de Web Server Protection-regels opnieuw. Bestaande liveverbindingen via deze regels kunnen daardoor worden onderbroken. Wijzigingen aan productieve WAF-regels moeten daarom in een onderhoudsvenster of op zijn minst bewust worden uitgevoerd.

Go-live en rollback plannen

Een WAF-publicatie moet niet als voltooid worden beschouwd zodra de regel is opgeslagen. Het is cruciaal of DNS, certificaat, Hosted address, backend, beschermingsprofiel en logging samen functioneren. Vooral bij bestaande poortdoorschakelingen moet je de overgang als een kleine publicatie behandelen.

Voor de go-live controleren:

• Documenteer de huidige firewallconfiguratie of op zijn minst de betrokken regel- en certificaatinstellingen.
• Identificeer eerdere DNAT- of firewallregels die dezelfde poort, hetzelfde openbare IP of dezelfde hostnaam betreffen.
• Deactiveer oude DNAT-regels of documenteer duidelijk waarom ze niet concurreren met de WAF-regel.
• Verlaag de DNS-TTL vóór een overgang als de openbare hostnaam van een oude publicatie naar de WAF verandert.
• Zorg voor externe testtoegang, test niet alleen vanuit het interne LAN.
• Definieer testgevallen: startpagina, inloggen, uploaden, downloaden, API-pad, WebSocket, uitloggen en foutmelding.
• Stel verwachte loglocaties vast: Log Viewer, reverseproxy.log, backend-toegangslog en backend-foutenlog.
• Stel rollback-criteria vast, bijvoorbeeld inloggen niet mogelijk, backend niet bereikbaar, verkeerd certificaat, hoge foutmarge of kritieke applicatiedelen defect.

Bij de overgang moet telkens slechts één publicatie actief zijn. Als een oude DNAT-regel en een nieuwe WAF-regel hetzelfde openbare IP en dezelfde poort gebruiken, is het gedrag moeilijk te begrijpen. Voor de productieve omschakeling moet duidelijk zijn welke regel het verkeer daadwerkelijk verwerkt.

Een eenvoudige rollback bestaat vaak uit het deactiveren van de nieuwe WAF-regel en het opnieuw activeren van de vorige publicatie. Als daarnaast DNS is gewijzigd, moet rekening worden gehouden met de DNS-TTL. Bij certificaat- of hostnaamproblemen is een rollback via DNS alleen vaak te traag; in dergelijke gevallen moet de oude regel op hetzelfde Hosted address weer kunnen worden geactiveerd of moet er een alternatieve toegang beschikbaar zijn.

Na de go-live moeten de eerste toegangen actief worden bewaakt. Belangrijk zijn niet alleen succesvolle HTTP-statuscodes, maar ook WAF-blokkeringen, backend-fouten, onverwachte omleidingen, sessieproblemen en ontbrekende client-IP-informatie in de backend-logs.

Acceptatietest na de go-live

Een WAF-test is pas compleet als hetzelfde verzoek vanuit drie perspectieven kan worden nagevolgd: client, firewall en backend. Hierdoor kun je sneller herkennen of een probleem bij DNS, certificaat, WAF-matching, beschermingsprofiel of applicatie ligt.

Voor productieve applicaties moet je ten minste deze gevallen testen:

• Oproep via de juiste hostnaam en via een niet-passend domein.
• Inloggen met een geldige en ongeldige gebruiker, als de applicatie of WAF authenticatie uitvoert.
• Upload, download, API- of WebSocket-functie, als de applicatie dergelijke functies gebruikt.
• Toegang vanuit een toegestane bron en, indien mogelijk, vanuit een bewust niet-toegestane bron.
• Gedrag van een bekende onschadelijke WAF-testaanvraag, zodat logging en blokkeerpad zichtbaar zijn.

Als de applicatie na de go-live ogenschijnlijk werkt, maar er geen passende logs zichtbaar zijn, is de test nog niet voltooid. Dan kan het zijn dat een andere publicatie overeenkomt, logging ontbreekt of de toegang niet via het verwachte pad verloopt.

Certificaten en hostnamen

Voor HTTPS moet de WAF-regel een certificaat gebruiken dat overeenkomt met de openbare hostnaam. Het certificaat wordt geïmporteerd of aangemaakt onder Certificates > Certificates en vervolgens geselecteerd in de WAF-regel.

Belangrijke punten:

• De DNS-naam moet overeenkomen met het certificaat.
• Bij meerdere hostnamen op hetzelfde IP gebruikt de firewall SNI.
• Wildcard-certificaten zijn mogelijk, maar moeten goed worden gedocumenteerd.
• De backend kan een andere interne naam gebruiken, mits Host Header en applicatie daarmee kunnen omgaan.
• Bij problemen met absolute links kan Rewrite HTML relevant worden.

Als meerdere virtuele webservers via hetzelfde IP en dezelfde poort draaien, beslist de firewall bij HTTPS op basis van SNI en hostnaam welke WAF-regel past.

Client-IP en backend-logs plannen

Bij WAF-publicaties ziet de interne webserver vaak niet het echte client-IP als directe bronadres. De Sophos Firewall werkt als een reverse proxy en bouwt zelf de verbinding met de backend op. Voor de applicatie en de webserver-logs kan daarom eerst het firewall-adres zichtbaar zijn.

Als de applicatie of de backend het oorspronkelijke client-IP nodig heeft, moet je vroegtijdig controleren of X-Forwarded-For of een vergelijkbare header wordt geëvalueerd. Dit is belangrijk voor:

• Applicatielogs en beveiligingsevaluatie
• Rate limits of inlogbeveiliging op applicatieniveau
• Foutanalyse met gebruikers- of bron-IP-referentie
• SIEM- of monitoringcorrelatie
• Forensische evaluatie na een incident

Belangrijk is de vertrouwensgrens: een backend moet dergelijke headers alleen als betrouwbaar beschouwen als het verzoek echt van de Sophos Firewall of een gedefinieerde reverse proxy komt. Openbare clients mogen X-Forwarded-For niet direct als beveiligingsbewijs kunnen instellen. In de praktijk moet de webserver daarom alleen de firewall-IP vertrouwen en headers uit andere bronnen negeren of overschrijven.

Voor troubleshooting betekent dit: Log Viewer, reverseproxy.log en backend-log moeten dezelfde testtijd dekken. Als in de backend alleen de firewall-IP zichtbaar is, is dat niet automatisch een WAF-fout, maar vaak normaal reverse proxy-gedrag.

Clienttoegang beperken

Niet elke webapplicatie hoeft wereldwijd bereikbaar te zijn. Al in de WAF-regel kun je de toegang beperken.

Zinvolle beperkingen:

• Alleen bekende bron-IP-adressen of partnernetwerken toestaan.
• Niet benodigde landen blokkeren.
• IP-adressen van onbekende landenherkomst alleen blokkeren als het risico van een eigen lockout is beoordeeld.
• Voor portalen daarnaast WAF-MFA of voorafgaande authenticatie gebruiken.
• Bekende kwaadaardige bronnen via Threat Feeds blokkeren.

Voor landen- en slechte IP-blokkering helpt Sophos Firewall: Landen en kwaadaardige IP’s blokkeren. Voor dynamische dreigingslijsten is Sophos Firewall Threat Feeds relevant.

Threat Feeds en Active Threat Response inplannen

Bij openbaar toegankelijke webapplicaties moet je niet alleen de WAF-regel zelf beschouwen. Sinds SFOS 22 worden Threat Feeds ook voor inkomend, doorgestuurd verkeer zoals WAF- en DNAT-publicaties relevanter. De firewall kan dergelijke treffers met MDR Threat Feeds, NDR Essentials en Third-Party Threat Feeds vergelijken.

Voor beheerders betekent dit: WAF is de publicatielaag, Threat Feeds en Active Threat Response kunnen extra bekende kwaadaardige bronnen blokkeren of zichtbaar maken. Dit vervangt echter geen patchbeheer, geen schone authenticatie en geen applicatiehardening.

Praktisch moet je controleren:

• Is Active Threat Response in de omgeving zinvol geconfigureerd?
• Worden relevante Threat Feeds ingezet en regelmatig gecontroleerd?
• Zijn WAF-events, Active-Threat-Response-logs en backend-logs in bedrijf zichtbaar?
• Is er een proces voor false positives, allowlisting en noodtoestemmingen?
• Is het duidelijk wie op treffers reageert en of alleen wordt gelogd of actief wordt geblokkeerd?

Vooral bij klantenportalen, beheerdersinterfaces of partnertoegangen moet deze controle vóór de go-live plaatsvinden. Als een feed later productief verkeer blokkeert, moet de operatie weten waar je de treffer ziet en hoe je schoon beslist: echte aanval, vals alarm of verkeerd gepubliceerde applicatie.

Beschermingsprofielen en uitzonderingen

Een WAF-regel moet niet alleen publiceren, maar ook beschermen. Hiervoor gebruik je Protection Policies, optionele IPS-policies en uitzonderingen.

Typische beschermingsgebieden:

• Cookie manipulatie
• URL Hardening
• Form Hardening
• Cross-Site Scripting
• Applicatie-aanvallen
• Antivirus-controle
• Clients met slechte reputatie

Uitzonderingen moeten nauw worden ingesteld. Als een applicatie vanwege een enkel pad of een bepaalde bron niet werkt, moet je niet het hele beschermingsprofiel uitschakelen. Beter is een gerichte uitzondering met pad, bron en duidelijke reden.

⚠️ Elke uitzondering vermindert de beschermingswerking. Pad, bron, reden, datum en herzieningstermijn moeten worden gedocumenteerd, zodat tijdelijke workarounds niet permanent blijven bestaan.

Pad-specifieke routering, WebSocket en Load Balancing

WAF kan verzoeken afhankelijk van het pad naar verschillende backend-servers doorsturen. Dit is nuttig als een applicatie meerdere componenten heeft of een enkele hostnaam over meerdere interne diensten moet worden verdeeld.

Voorbeelden:

• /api/ gaat naar een API-server.
• /shop/ gaat naar een shopsysteem.
• / gaat naar de standaardwebserver.

Je moet er rekening mee houden dat de firewall paden niet eenvoudig op basis van tabelvolgorde beoordeelt. Specifieke paden moeten goed worden gepland en getest. Als WebSocket nodig is, kan WebSocket passthrough worden geactiveerd. WebSocket-verkeer wordt dan zonder dezelfde WAF-controle doorgestuurd, omdat het protocol niet op dezelfde manier kan worden gecontroleerd als normaal HTTP-verkeer.

Bij meerdere backend-servers zijn Sticky Sessions of Hot-standby mogelijk. Dit helpt bij eenvoudige hoogbeschikbaarheids- of lastverdelingsgevallen, maar vervangt geen volledig applicatie-load-balancingconcept.

Typische fouten

Troubleshooting

Als een WAF-publicatie niet werkt, moet je systematisch controleren:

1. Wijst de openbare DNS-naam naar het juiste openbare IP?
2. Is het juiste Hosted address in de WAF-regel geselecteerd?
3. Is de luisterpoort vrij en niet bezet door WebAdmin, User Portal, VPN Portal of een andere publicatie?
4. Komt het certificaat overeen met de opgeroepen hostnaam?
5. Is de interne webserver vanaf de firewall bereikbaar?
6. Zijn Allowed client networks, Blocked client networks en Blocked countries correct ingesteld?
7. Is er een algemenere WAF-regel die eerder matched?
8. Wordt de toegang in de Log Viewer als toegestaan, geblokkeerd of verworpen weergegeven?
9. Zijn er aanwijzingen in /log/reverseproxy.log?

Voor de eerste analyse is de Log Viewer nuttig. Voor diepere troubleshooting helpen de Web Server Protection Logs op de firewall. Een overzicht van logbestanden en diensten staat in Sophos Firewall Troubleshooting: Services en Logs.

Checklist voor productieve WAF-regels

• Regelnaam beschrijft applicatie, hostnaam en omgeving.
• Verantwoordelijke persoon of systeembeheerder is gedocumenteerd.
• DNS, certificaat en Hosted address zijn gecontroleerd.
• Backend-bereikbaarheid is vanaf de firewall getest.
• Eerdere publicatie en rollback zijn gedocumenteerd.
• Oude DNAT- of firewallregels concurreren niet met de WAF-regel.
• Externe go-live-tests zijn gedefinieerd.
• Toegang is beperkt tot noodzakelijke bronnen of landen.
• Threat Feeds en Active Threat Response zijn voor openbare applicaties geëvalueerd.
• Logging is actief.
• Beschermingsprofiel is niet onnodig gedeactiveerd.
• Uitzonderingen zijn nauw, gerechtvaardigd en tijdelijk.
• Wijziging is extern getest.
• Vervaldatum of herzieningstermijn is gedocumenteerd.

Veelgestelde vragen