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.

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.

WAF-regels zijn bovendien gericht op IPv4-publicaties. Als een applicatie verplicht via IPv6 gepubliceerd moet worden, moet het ontwerp apart worden beoordeeld. Ook de Exchange-sjablonen zijn geen vrijbrief voor moderne Exchange-omgevingen: Sophos documenteert dat WAF-regels momenteel geen Exchange-versies na 2013 ondersteunen.

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 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 rules

Stappen:

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. Activeer Log firewall traffic als de regel in Log Viewer en rapporten traceerbaar moet zijn.
9. Definieer onder Hosted server details het openbare adres, de luisterpoort, HTTPS, certificaat en domeinen.
10. Selecteer onder Protected servers het passende webserver-object of maak dit eerst aan onder Web server > Web servers.
11. Stel bewust Allowed client networks in. Voor openbare websites kan Any IPv4 nodig zijn; voor portalen is een beperking meestal beter.
12. Stel indien nodig Blocked client networks of Blocked countries in.
13. Controleer beschermingsprofiel, IPS en geavanceerde opties.
14. 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.

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. Afhankelijk van de Hosted address kan WAF dezelfde poort als SSL VPN gebruiken, maar niet dezelfde poort als User Portal. Als WebAdmin, VPN Portal, User Portal of een oude DNAT-publicatie al op een publieke IP luistert, moet de toewijzing eenduidig zijn. Anders lijkt de fout later op een WAF-probleem, terwijl een andere functie antwoordt.

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.

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.

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.

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.

Men moet er rekening mee houden dat de firewall paden niet eenvoudig op basis van tabelvolgorde beoordeelt. Sophos prioriteert langere en daarmee specifiekere paden. Specifieke paden moeten daarom 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.

Het standaardpad / moet bewust ingesteld blijven. Als het wordt verwijderd, worden niet-passende paden niet naar een standaardserver doorgestuurd, maar met 404 Not Found geweigerd. Dat kan gewenst zijn, maar lijkt bij storingen snel op een backendprobleem.

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.

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 de gedocumenteerde uitweg.

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

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