Sophos Firewall WAF: Webserver veilig publiceren

Met Web Server Protection of Web Application Firewall (WAF) publiceert men interne of cloudgebaseerde webapplicaties via de Sophos Firewall. De firewall fungeert als 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.

Voor de bredere hardening-context past de hub Sophos Firewall Hardening: best practices voor een veilige configuratie.

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.

Beslissing vóór publicatie

Wanneer WAF in plaats van DNAT zinvol is

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

• DNAT past voor niet-HTTP-diensten, eenvoudige poortdoorschakelingen en speciale protocollen. De firewall vertaalt en staat dan primair traffic toe.
• WAF / Web Server Protection past voor HTTP- en HTTPS-toepassingen wanneer hostnaam, certificaat, paden, beschermingsprofielen, authenticatie of landregels relevant zijn.
• Reverse Proxy of ZTNA past voor complexe webplatforms, identiteitsintegratie en privétoepassingen wanneer toegang sterk gecontroleerd of helemaal niet openbaar moet zijn.

Als alleen snel een interne webserver via poortdoorschakeling toegankelijk moet worden gemaakt, helpt de handleiding Server publiceren via DNAT op Sophos Firewall. Voor openbare webapplicaties moet men eerst WAF beoordelen.

⚠️ 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:

• Openbare website of eenvoudige HTTPS-toepassing: WAF is meestal het passende startpunt. DNS, certificaat, hostnaam, beschermingsprofiel, logging en backend-bereikbaarheid moeten worden getest.
• Klantenportaal, partnerportaal of beheerdersinterface: WAF met bronbeperking en optioneel MFA kan zinvol zijn. Vooraf moet worden nagegaan of WAF-MFA, landregels of vaste bronnetwerken mogelijk zijn.
• Pure TCP- of UDP-dienst: DNAT is meestal passender. Firewallregel, NAT-regel, doelserver, retourroute en logging moeten gezamenlijk worden gecontroleerd.
• Webapplicatie met WebDAV of speciaal protocol: WAF niet automatisch gebruiken. Ondersteunde functies, clientgedrag en alternatieve publicatie testen.
• Applicatie alleen voor interne gebruikers: VPN, ZTNA of sterk beperkte WAF controleren. Openbare bereikbaarheid moet kritisch worden beoordeeld.

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.

Planning en vereisten

Vereisten

Voor de eerste WAF-regel moet men 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.

Daarnaast heeft de firewall een webserver-object nodig onder Web server > Web servers. Daar wordt de interne of externe doelserver beschreven met host, protocol en poort. De host is een IP- of FQDN-hostobject. Voor backends zijn HTTP of HTTPS mogelijk; standaardpoorten zijn 80 en 443. Als de backend-webserver lange antwoorden levert of keep-alive nodig heeft, moeten Keep alive en Timeout bewust worden gecontroleerd in plaats van toevallig overgenomen.

De backend-Timeout kan tussen 1 en 65,535 seconden liggen; standaard is 300 seconden. Na het verstrijken stuurt de WAF de client 502. Disable backend connection pooling forceert voor elke toegang een nieuwe backendverbinding en kan de prestaties verlagen. Gebruik deze optie daarom alleen voor gerichte foutanalyse en zet ze daarna terug naar de gedocumenteerde uitgangswaarde.

Daarnaast moet men de grenzen van Web Server Protection vroeg meenemen. Sophos noemt onder meer een limiet van 60 WAF-regels per firewall. Dat is voor veel omgevingen voldoende, maar kan bij veel klantenportalen, tenants, testsystemen of gescheiden hostnamen sneller relevant worden dan verwacht. Dan moet men niet blind extra losse regels bouwen, maar naamconcept, paden, virtuele webservers en alternatieve publicatieroutes controleren.

SFOS 22 ondersteunt geen WAF-regels via IPv6. Een applicatie mag daarom met deze functie niet als IPv6-publicatie worden gepland; het overzicht IPv6-ondersteuning en beperkingen in Sophos Firewall met SFOS 22 onderscheidt WAF van de ondersteunde IPv6-regel- en beveiligingsfuncties. Ook de Exchange-sjablonen zijn geen vrijbrief voor moderne Exchange-omgevingen: Sophos documenteert dat WAF-regels momenteel geen Exchange-versies na 2013 ondersteunen.

De vooraf geconfigureerde templates komen uit een ouder Microsoft-applicatielandschap: Exchange Autodiscover, Outlook Anywhere en Exchange General stoppen bij deze Exchange 2013-grens; de overige Sophos-handleidingen noemen Microsoft Lync, Remote Desktop Gateway of RD Web 2008/R2 en SharePoint 2010/2013. Ze vormen daarom geen actuele basis voor Microsoft 365, moderne Exchange-versies, Teams of huidige RDS-implementaties. Vergelijk vóór gebruik de daadwerkelijk benodigde paden, authenticatiemethoden en beveiligingspolicies met de actuele Microsoft-architectuur; laat voor een moderne applicatie Preconfigured template bij twijfel op None staan.

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:

• Is het echt een HTTP- of HTTPS-toepassing? Voor andere protocollen is DNAT meestal passender.
• Moet de applicatie openbaar toegankelijk zijn? Privébeheerportalen passen vaak beter bij VPN, ZTNA of beperkte bronnetwerken.
• Welke hostnaam en welk certificaat worden gebruikt? DNS, SNI, certificaat en WAF-domeinen moeten overeenkomen.
• Hoeveel publicaties zijn gepland? Het WAF-regellimiet en de latere bedienbaarheid beïnvloeden het ontwerp.
• Moet de firewall gebruikers authenticeren? Voor portalen kan WAF-MFA zinvol zijn.
• Welke beschermingsprofielen zijn actief? Te brede uitzonderingen verzwakken de WAF, te strenge profielen kunnen applicaties breken.
• Hoe wordt er gelogd en getest? Log Viewer, reverseproxy.log en backend-logs moeten vóór de livegang bekend zijn.

Voor certificaten moet vroegtijdig worden verduidelijkt of een bestaand certificaat met privésleutel en CA-keten 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.

WAF-regel configureren

Basisstructuur van een WAF-regel

Een WAF-publicatie bestaat uit meerdere bouwstenen:

• Hosted address: openbaar IP-adres of alias waarop clients de applicatie bereiken.
• Listening port: openbare poort, meestal 80 of 443.
• Domains: hostnamen die bij de WAF-regel moeten passen.
• HTTPS certificate: certificaat voor de gepubliceerde hostnaam.
• Web server: vooraf aangemaakt webserver-object met host, protocol, poort en verbindingsinstellingen.
• Allowed client networks: bronnetwerken die toegang mogen hebben.
• Blocked client networks / countries: bronnen of landen die worden geblokkeerd.
• Protection policy: WAF-bescherming tegen typische webaanvallen.
• Authentication: optionele voorafgaande aanmelding via de firewall.

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

Belangrijk: een WAF-regel is geen normale firewallregel met NAT erachter. Er ontstaat een Reverse-Proxy-publicatie. Daarom moeten Hosted address, Listening port, Domains, certificaat, Protected server en Allowed client networks samenpassen. Als een van deze velden niet klopt, lijkt de fout vaak op een certificaat-, DNS- of backendprobleem.

WAF-regel maken

Het menupad is:

Rules and policies > Firewall

Stappen:

De volgende genummerde procedure met Protected servers geldt alleen voor SFOS 22 en blijft voor deze versie ongewijzigd. WAF-regels ondersteunen alleen IPv4. De regelactie Protect with web server protection is niet gelijk aan de pad-specifieke Action > Protect onder Traffic routing in SFOS 23; voor SFOS 23 geldt de afzonderlijke handleiding direct na deze procedure.

1. Selecteer IPv4.
2. Open Add firewall rule.
3. Kies New firewall rule.
4. Geef een duidelijke regelnaam.
5. Stel Rule position bewust in, vooral als er al algemenere WAF-regels of oude publicaties bestaan.
6. Kies bij Action de optie Protect with web server protection.
7. Laat Preconfigured template op None als er geen speciale sjabloon nodig is.
8. Definieer onder Hosted server details het openbare adres, de luisterpoort, HTTPS, certificaat en domeinen.
9. Selecteer onder Protected servers het passende webserver-object of maak dit eerst aan onder Web server > Web servers.
10. Stel Allowed client networks bewust in. Voor openbare websites kan Any IPv4 nodig zijn; voor portalen is een beperking meestal beter.
11. Stel indien nodig Blocked client networks of Blocked countries in.
12. Controleer onder de geavanceerde beleidsregels bewust Protection, Intrusion prevention en Traffic shaping.
13. Sla de regel op en test extern.

SFOS 23: Paden publiceren onder Traffic routing

1. Maak of bewerk onder Rules and policies > Firewall een IPv4-regel. Kies als regelactie Action nog steeds Protect with web server protection en configureer het openbare adres, de poort, het HTTPS-certificaat en de domeinen passend. Een nieuwe regel bevat standaard / met Block: zonder aanvullende routingconfiguratie worden verzoeken afgewezen, niet gepubliceerd.
2. Bewerk of voeg onder Traffic routing met Edit of Add new path het specifiek bedoelde pad toe. Kies bij Action expliciet Protect en wijs de benodigde backend-objecten uit Web server > Web servers toe. Een sjabloon maakt wel paden met Protect aan, maar vereist nog steeds de backend-toewijzing.
3. Wijs voor elk beschermd pad het bedoelde authenticatiebeleid toe in het veld Authentication en stel Allowed client networks bewust in; laat dit niet leeg. Controleer Blocked client networks, Blocked countries en Block IP addresses of unknown country-origin gericht; houd bij onbekende landenherkomst ook rekening met het risico van een eigen lockout.
4. Als alleen bepaalde paden moeten worden gepubliceerd, behoud / dan bewust met Block als opvangroute. Zet / alleen op Protect als de volledige applicatie moet worden gepubliceerd; controleer expliciet de backend, authenticatie, toegangsbeperkingen en de applicatiedelen die daardoor bereikbaar worden. Langere, specifiekere paden worden eerst geëvalueerd, niet de tabelvolgorde.
5. Maak onderscheid tussen de acties: Block wijst verzoeken voor het gekozen pad af en stuurt ze niet door naar de backend. Protect past de beschermingspolicy van de regel en de geconfigureerde authenticatie- en toegangsinstellingen toe. Redirect stuurt de client een omleiding naar het geconfigureerde doel, in plaats van een backend te publiceren. Passthrough maakt een tunnel naar de backend zonder WAF-inspectie en zonder toepassing van de beschermingspolicy. Protection geldt alleen voor paden met Protect.
6. Test na het opslaan extern een bedoeld toegestaan pad, een bewust geblokkeerd pad en een pad zonder specifieke overeenkomst. Controleer, indien gebruikt, ook Redirect en Passthrough afzonderlijk. Correleer het clientresultaat, Log Viewer, reverseproxy.log en backend-logs aan de hand van hetzelfde verzoek en hetzelfde tijdstip.

Bestaande regels na de upgrade: Volgens de Sophos-documentatie worden bestaande WAF-regels bij de upgrade naar SFOS 23 automatisch omgezet naar Protect; bestaande pad-specifieke routes blijven behouden. Dit verschilt van de standaardinstelling / met Block bij nieuwe regels en van de oudere SFOS 18-migratie van ModSecurity Protection Policies. Controleer na de upgrade toch voor elk pad de actie, backend, authenticatie, toegangsbeperkingen en daadwerkelijke route en voer een externe acceptatietest uit; automatische migratie vervangt geen acceptatie.

Duiding van de handleiding: De Sophos-handleiding over het beschermen van een webserver tegen aanvallen gebruikt nog steeds de procedure met Protected servers en noemt IPv4 or IPv6, hoewel de WAF-regelreferentie WAF tot IPv4 beperkt. Deze handleiding is daarom geen volledige SFOS 23-routinghandleiding. Voor de actuele configuratie gelden IPv4 en de expliciete padacties hierboven.

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.

Als Allowed client networks leeg blijft, werkt de WAF-regel niet correct; de browser kan dan een 400 Bad Request krijgen. Voor een openbare applicatie is Any IPv4 wel mogelijk, maar niet automatisch juist. Voor beheerportalen, partnerportalen of interne tools moet men eerst vaste bronnetwerken, landenbeperking, WAF-MFA, VPN of ZTNA beoordelen.

Poortconflicten moeten vóór het opslaan worden opgehelderd. WebAdmin en User Portal hebben elk een unieke poort nodig. WAF en VPN Portal gebruiken beide TCP; als ze dezelfde poort gebruiken, moeten hun Hosted address of WAN-IP-adressen daarom verschillen. WAF kan van SSL VPN verschillen door het WAN-IP-adres, de poort of het protocol, omdat SSL VPN TCP of UDP ondersteunt. Alleen een andere FQDN- of SNI-naam is niet voldoende om deze listeners van elkaar te scheiden. Als een andere dienst of een oude DNAT-publicatie al op een publiek IP-adres luistert, moet de toewijzing vóór de ingebruikname per IP-adres, poort en protocol worden getest.

Go-live en acceptatie

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 men 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 herkent men sneller of een probleem bij DNS, certificaat, WAF-matching, beschermingsprofiel of applicatie ligt.

• Externe client: DNS-resolutie, certificaat, HTTP-status, login en belangrijke paden controleren. De applicatie moet via de openbare hostnaam zonder certificaatwaarschuwing openen.
• Sophos Firewall: Log Viewer, WAF-regel, reverseproxy.log en geblokkeerde signatures controleren. De juiste WAF-regel moet de toegang verwerken en logs moeten toegestane of gerechtvaardigd geblokkeerde requests tonen.
• Backend-webserver: toegangslog, foutenlog, applicatiesessie en X-Forwarded-For controleren. Het request moet de juiste vHost of het juiste pad bereiken en de client-IP-logica moet duidelijk zijn.

Voor productieve applicaties moeten ten minste deze gevallen worden getest:

• 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.

Bescherming en toegang beveiligen

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.
• Het geselecteerde HTTPS-certificaat kan de domeinlijst in de WAF-regel automatisch vullen of bestaande domeinvermeldingen overschrijven.
• Bij meerdere hostnamen op hetzelfde IP gebruikt de firewall SNI.
• Wildcard-certificaten zijn mogelijk, maar moeten goed worden gedocumenteerd.
• Wildcard-domeinen worden pas gebruikt na specifiekere domeinregels.
• Underscores in het linker domeinlabel zijn geen nette DNS-naam en moeten voor WAF-domeinen worden vermeden.
• 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.

De Domains in de WAF-regel moeten daarom exact passen bij DNS en certificaat. Wildcards kunnen nuttig zijn, maar mogen geen vervanging zijn voor een schoon publicatieconcept. Als meerdere applicaties onder vergelijkbare hostnamen draaien, is duidelijke regel- en certificaatdocumentatie nodig; anders wordt later moeilijk te achterhalen welke WAF-regel werkelijk matcht. Een test met een bewust niet-passend subdomein is zinvol: dan ziet men of de specifieke regel, een wildcard-regel of geen passende virtuele webserver antwoordt.

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 vroegtijdig worden gecontroleerd 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 kan de toegang worden beperkt.

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 men niet alleen de WAF-regel zelf bekijken. 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 worden gecontroleerd:

• 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 de treffer zichtbaar is en hoe men schoon beslist: echte aanval, vals alarm of verkeerd gepubliceerde applicatie.

Beschermingsprofielen en uitzonderingen

Een WAF-regel moet niet alleen publiceren, maar ook beschermen. Hiervoor gebruikt men 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

Onder Web server > General settings staan aanvullende globale instellingen voor Web Server Protection, waaronder TLS-versiebeheer en bescherming tegen langzame HTTP-DoS-patronen. Deze instellingen gelden niet alleen voor één regel. Wijzigingen moeten daarom bewust worden gepland en met bestaande WAF-publicaties worden afgestemd.

SFOS 23: Worker-profiel gericht aanpassen

Onder Web server > General settings > Worker customization berekent de firewall de standaardwaarden op basis van de beschikbare CPU- en RAM-resources; deze zijn geschikt voor de meeste installaties. Hogere waarden kunnen de WAF-prestaties en systeemresources negatief beïnvloeden. Activeer Use custom worker profile daarom alleen nadat de noodzaak is gecontroleerd en de gevolgen zijn beoordeeld. Documenteer vooraf de huidige waarden en of het profiel berekend of aangepast is, maak een configuratieback-up en plan een onderhoudsvenster en een rollback naar precies die eerdere toestand. Deze aanpassing is geen wijziging van Maximum sessions.

• Start servers: Aantal worker-processen dat bij het starten van de webserver wordt gestart.
• Server limit: Maximumaantal worker-processen dat gelijktijdig kan worden uitgevoerd.
• Minimum spare threads: Minimumaantal inactieve threads dat beschikbaar wordt gehouden voor nieuwe verzoeken.
• Maximum spare threads: Maximumaantal inactieve threads voordat overtollige threads worden verwijderd.
• Threads per child: Maximumaantal worker-threads per worker-proces.
• Asynchronous request worker factor: Regelt de schaling van worker-processen voor asynchrone verbindingen en verzoeken.

Bij formuliergebaseerde reverse-proxyauthenticatie begrenst het globale veld Maximum sessions de gelijktijdige gebruikerssessies van alle WAF-regels die deze authenticatiemethode gebruiken. De standaardwaarde is 25,000; het toegestane bereik loopt van 100 tot 100,000. Zodra de limiet is bereikt, sluit de firewall oude of verlopen sessies om nieuwe toe te laten. Dit is dus geen capaciteit per regel: stem de waarde af op gelijktijdige aanmeldingen van de betrokken toepassingen en controleer na een wijziging aanmelden, afmelden en sessiewisseling.

Bij Slow HTTP protection is Soft limit de aanvankelijke timeout voor het ontvangen van de requestheader. Hard limit bepaalt de absolute bovengrens. Extension rate legt vast hoeveel extra ontvangen bytes het soft limit met één seconde verlengen. Test deze drie waarden samen en met werkelijk trage clients; één te ruime waarde kan de bescherming onnodig verzwakken.

Beperk uitzonderingen bij Slow HTTP protection tot het kleinst noodzakelijke IP-adres of netwerk. Sophos ondersteunt hier IP- en netwerkhostobjecten, maar geen IP-bereiken of hostlijsten. De Minimum TLS version is eveneens globaal; test oudere clients en alle gepubliceerde applicaties via een echte externe verbinding voordat deze instelling wordt aangescherpt.

Als globale TLS-instellingen biedt SFOS onder meer TLS v1.2 (wide compatibility), TLS v1.2 (strict) en TLS v1.3. Wijzig Custom protocol configuration en Custom cipher configuration alleen met gedocumenteerde en geteste OpenSSL-waarden; cipher suites voor TLS 1.3 worden afzonderlijk beheerd. Ongeldige waarden kunnen voorkomen dat de door SFOS beheerde Apache-service en daarmee Web Server Protection starten. Het wijzigingsplan moet daarom de vorige waarden, een configuratieback-up, een onderhoudsvenster en alternatieve beheerstoegang bevatten. Test daarna alle WAF-publicaties en controleer reverseproxy.log; als de service niet start, herstel dan de laatste aangepaste waarden in plaats van meer varianten in productie te proberen.

Bij Protection Policies is de modus belangrijk. Reject blokkeert en genereert zichtbare Log Viewer-events voor WAF-regels. Monitor logt alleen, maar deze WAF-meldingen verschijnen niet noodzakelijk in Log Viewer; dan moet reverseproxy.log worden gecontroleerd. Voor een pilot kan Monitor zinvol zijn, maar voor productieve bescherming moet duidelijk zijn of aanvallen alleen worden bekeken of echt worden geweigerd.

Het Common threat filter werkt met vier Filtering Strengths. Level 1 is het tolerantst en wordt niet gelogd; vanaf Level 2 staan treffers in /log/reverseproxy.log, terwijl ook het risico op false positives stijgt. Sla individuele regels alleen over aan de hand van de in het log aangetoonde Rule ID onder Skip filter rules. Een volledige categorie of een hoger level globaal uitschakelen vervangt deze analyse niet.

Static URL hardening is hoofdlettergevoelig, accepteert geen wildcards en helpt niet bij URL’s die dynamisch door JavaScript worden gemaakt. Form hardening vergelijkt de formulierstructuur en ondersteunt formulieren tot 8,000 bytes. Als binaire inhoud ten onrechte als HTML of XML wordt geleverd, kunnen beide functies die inhoud beschadigen; corrigeer daarom eerst het Content-Type van de backend in plaats van de beveiligingsfunctie breed uit te schakelen.

Bij de antivirusscan geldt een groottelimiet voor het totale uploadvolume van een request, niet voor elk afzonderlijk bestand. De extra Request size limit voor de HTTP-body loopt van 1 tot 1,024 MB en staat standaard op 10 MB. HTTP Strict Transport Security voegt de HSTS-header alleen toe wanneer de WAF-regel Redirect HTTP gebruikt; MIME-type sniffing protection zet X-Content-Type-Options: nosniff. Test uploads, downloads en headers daarom met de echte applicatie.

IPS in een WAF-regel moet apart worden beoordeeld. Sophos past IPS voor WAF alleen toe wanneer de communicatie tussen firewall en webserver via HTTP loopt. Als de backend via HTTPS is aangesloten, mag men dus niet automatisch verwachten dat een geselecteerde IPS-policy hetzelfde effect heeft.

Uitzonderingen moeten nauw worden ingesteld. Als een applicatie vanwege een enkel pad of een bepaalde bron niet werkt, moet niet het hele beschermingsprofiel worden uitgeschakeld. 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.

Gemigreerde Protection Policies opnieuw valideren

Sinds SFOS 18 gebruikt Web Server Protection het OWASP ModSecurity Core Rule Set 3.0. Bij de migratie van oudere Protection Policies zijn eerdere categorieën samengevoegd, Rule IDs opnieuw toegewezen en Filtering Strengths ingevoerd. Als één van de samengevoegde categorieën eerder actief was, kan de nieuwe gezamenlijke categorie daarom actief zijn, ook wanneer een ander deel eerder uitgeschakeld was.

Na zo’n upgrade volstaat het niet om alleen de naam van de policy te vergelijken. Controleer de actieve categorieën, uitzonderingen en Filtering Strengths aan de hand van de vorige documentatie. Voer daarna gecontroleerde positieve en negatieve tests met echt applicatieverkeer uit en controleer Log Viewer en reverseproxy.log. De gemigreerde policy is pas gevalideerd wanneer legitieme requests blijven werken en de verwachte testaanvallen worden gedetecteerd.

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.

De firewall beoordeelt paden niet op basis van de tabelvolgorde, maar geeft langere en daarmee specifiekere paden voorrang op de opvangroute. Deze toewijzing moet gericht worden getest. Alleen voor SFOS 22: Voor het benodigde websitepad kan het selectievakje WebSocket passthrough worden geactiveerd; WebSocket-verkeer wordt daarbij zonder WAF-bescherming doorgestuurd, omdat WebSocket-gegevens niet zoals normaal HTTP-verkeer kunnen worden gecontroleerd. Voor SFOS 23: Configureer onder Traffic routing uitsluitend het benodigde WebSocket-pad met Action > Passthrough en de bedoelde backend. Deze tunnel werkt zonder WAF-inspectie en zonder beschermingspolicy; de overige applicatiepaden blijven op Protect staan. Zet nooit het volledige portaal als workaround op Passthrough. Test verbindingsupgrade, gegevensoverdracht en opnieuw verbinden afzonderlijk. Hieruit kan geen uitspraak over MFA-afdwinging bij Passthrough worden afgeleid; stem bij vereiste authenticatie de verantwoordelijkheid af met de verantwoordelijke voor authenticatie.

Alleen voor SFOS 22: Bij de procedure met Protected servers stuurt het standaardpad / verzoeken zonder specifiekere overeenkomst door naar de toegewezen standaardserver. Als deze standaardroute wordt verwijderd, wijst de firewall dergelijke verzoeken af met 404 Not Found. Voor SFOS 23: Verzoeken zonder specifiekere overeenkomst gebruiken de actie van /; bij nieuwe regels is dat standaard Block. Behoud deze opvangroute bewust als alleen afzonderlijke paden moeten worden gepubliceerd. Protect voor / is alleen zinvol als publicatie van de volledige applicatie is bedoeld en vereist een controle van de extra bereikbaarheid. Voor SFOS 23 wordt geen vaste 404-status gegarandeerd: het antwoord van Block wordt via Response code geconfigureerd.

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.

Externe WAF-backends via SD-WAN bereiken

Als de beschermde webserver niet in het lokale netwerk van de firewall staat, moeten routing en SD-WAN bijzonder bewust worden gecontroleerd. Voor backends via locatieverbindingen, MPLS of route-based IPsec kan een passende SD-WAN Route nodig zijn, zodat de firewall de Protected Server betrouwbaar bereikt en de terugweg klopt. Bij route-based IPsec is bovendien belangrijk: WAF over route-based IPsec met Traffic Selectors voor subnetten wordt door Sophos niet ondersteund; Any-to-Any-verbindingen zijn het gedocumenteerde alternatief.

Het door Sophos gedocumenteerde ontwerp begint met een werkende WAF-regel en een bereikbaar route-based tunnel. Maak onder Routing > Gateways voor het externe pad een gateway-object met het IP-adres van de peer, de geadresseerde XFRM-interface en een betrouwbare monitoringhost achter de peer. Pas daarna wordt onder Routing > SD-WAN routes de gerichte route voor WAF-proxyverkeer gemaakt:

1. Destination networks komt overeen met de publieke WAN-interface of Hosted address waarmee de client de WAF-regel bereikt.
2. Services bevat de externe Listening Port van de WAF-regel. Als deze afwijkt van de interne backendpoort, hoort hier uitdrukkelijk de externe poort te staan.
3. Onder Primary gateway wordt de eerder gemaakte XFRM-gateway gekozen.
4. Als meerdere publicaties dezelfde gateway gebruiken, kan dezelfde SD-WAN Route meerdere publieke WAN-adressen en Listening Ports bevatten. Voor verschillende gateways zijn afzonderlijke routes nodig.

De validatie scheidt vervolgens de lagen: de externe test moet de verwachte WAF-regel treffen; correleer in de Log Viewer de WAF-regel, reverse-proxyfouten en het tijdstip; op de firewall moeten XFRM-interface, gatewaymonitor en SD-WAN Route actief zijn; en de backendserver moet het verzoek ontvangen en via het bedoelde pad antwoorden. Alleen een groene tunnel bewijst noch de SD-WAN-match noch de bereikbaarheid van het backend.

Beheer en troubleshooting

Typische fouten

• Openbare DNS-naam wijst naar het verkeerde IP: de WAF-regel wordt nooit bereikt.
• Certificaat komt niet overeen met de hostnaam: browsers tonen certificaatfouten of SNI-matching komt niet overeen.
• Verkeerde Hosted address gekozen: de firewall matched een andere regel of geen WAF-verkeer.
• Allowed client networks leeg: de regel werkt niet zoals verwacht.
• WAF-regellimiet niet meegenomen: extra publicaties kunnen niet meer schoon worden afgebeeld.
• Exchange-versie na 2013 met WAF-template gepland: de template past niet bij de ondersteunde WAF-grens.
• Poortconflict met User Portal, VPN Portal of andere dienst: de applicatie is niet bereikbaar of een firewall-dienst reageert.
• Backend is intern niet bereikbaar: externe clients krijgen fouten, hoewel DNS en certificaat kloppen.
• Backend-timeout verkeerd ingesteld: lange antwoorden eindigen met fouten, hoewel de applicatie in principe bereikbaar is.
• Backend ligt via VPN of SD-WAN zonder passende route: de WAF-regel matched, maar de Protected Server wordt niet betrouwbaar bereikt.
• Route-based IPsec met Traffic Selectors naar de backend: WAF over dit pad wordt niet ondersteund.
• WAF-uitzondering te breed ingesteld: de beschermingswerking neemt onnodig af.
• WebDAV-applicatie via WAF gepubliceerd: de applicatie werkt niet betrouwbaar of wordt niet ondersteund.
• URL-pad bevat %2F: WAF antwoordt met 404 Not Found, hoewel de resource rechtstreeks op de backend bereikbaar is. %2F is de URL-gecodeerde vorm van een slash / en moet worden onderscheiden van een normale backend-404.
• Regelwijziging zonder onderhoudsvenster: bestaande verbindingen kunnen bij het herstarten van de WAF-regels worden verbroken.
• Oude DNAT-regel en nieuwe WAF-regel concurreren: het is onduidelijk welke publicatie het verkeer verwerkt.

Troubleshooting

Als een WAF-publicatie niet werkt, moet men 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. Ligt de Protected Server via een route, SD-WAN Route of VPN-verbinding die vanuit firewallperspectief echt klopt?
8. Is er een algemenere WAF-regel die eerder matched?
9. Wordt de toegang in de Log Viewer als toegestaan, geblokkeerd of verworpen weergegeven?
10. Zijn er aanwijzingen in /log/reverseproxy.log?
11. Staat de Protection Policy op Monitor of Reject?
12. Past de timeout van het webserver-object bij de applicatie?

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.

WAF antwoordt met 404 bij %2F in het pad

Een specifiek foutbeeld treedt op bij URL’s met een gecodeerde slash. Een verzoek zoals https://portal.example.com/api/files/project%2Freport.pdf kan via Sophos WAF 404 Not Found opleveren, hoewel de resource bij rechtstreekse toegang op de backend bestaat. Sophos houdt dit gedrag bij onder NC-159041 en noemt momenteel noch een specifieke getroffen of gecorrigeerde SFOS-versie, noch een ondersteunde workaround.

Om de oorzaak af te bakenen, moet hetzelfde verzoek via WAF en rechtstreeks op de backend worden vergeleken. De exacte URL en het testtijdstip zijn daarbij belangrijk:

1. Controleer of het pad werkelijk %2F bevat. Een normale slash / of een ontbrekend standaardpad is een ander foutbeeld.
2. Vergelijk het tijdstip in Log Viewer, /log/reverseproxy.log en het toegangslog van de webserver.
3. Als op de backend geen passende vermelding verschijnt, is het verzoek waarschijnlijk al vóór de webserver afgewezen. Met een rechtstreekse backendtest kan tegelijk worden bevestigd dat de resource zelf bestaat.

Een brede WAF-uitzondering verhelpt dit probleem niet gericht en zou de bescherming onnodig verminderen. Ook de door SFOS beheerde Apache-configuratie mag niet worden gewijzigd: de restrictieve behandeling van gecodeerde slashes helpt voorkomen dat pad- of toegangscontroles worden omzeild.

Het is het schoonst wanneer de applicatie of leverancier URL’s zonder gecodeerde slashes genereert. Als dat niet mogelijk is, moet een andere publicatiemethode zoals DNAT, een geschikte reverse proxy of privétoegang bewust worden afgewogen tegen het wegvallen van de WAF-bescherming. Voor niet-aanpasbare applicaties moet Sophos Support de concrete SFOS-build en use case beoordelen. De vormen project%2Freport.pdf en project/report.pdf zijn alleen een herkenningspatroon en zijn niet automatisch functioneel gelijkwaardig.

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