Sophos Firewall WAF: Publicera webbtjänster säkert

Med Web Server Protection eller Web Application Firewall (WAF) publicerar man interna eller molnbaserade webbapplikationer via Sophos Firewall. Brandväggen fungerar som en omvänd proxy: Klienter ansluter till brandväggens offentliga adress, brandväggen granskar HTTP- eller HTTPS-trafik och vidarebefordrar förfrågan till den skyddade webbservern.

För det bredare hardening-sammanhanget passar hubben Sophos Firewall Hardening: best practices för säker konfiguration.

En WAF-regel ersätter inte automatiskt säker applikationsutveckling, patchning, stark autentisering eller serverhärdning. Jämfört med en enkel portvidarebefordran minskar den dock attackytan avsevärt, eftersom HTTP(S)-trafik kan granskas, begränsas och loggas mer riktat.

WAF är dock inte automatiskt rätt svar för varje publicering. Avgörande är om applikationen verkligen fungerar korrekt över HTTP eller HTTPS, om brandväggen ska utvärdera värdnamn och sökvägar och om det extra omvända proxy-lagret passar applikationen.

Beslut före publicering

När WAF är mer lämpligt än DNAT

För enkla TCP- eller UDP-tjänster använder man fortfarande NAT och brandväggsregler. För webbapplikationer är WAF ofta det bättre valet.

• DNAT passar för icke-HTTP-tjänster, enkla portvidarebefordringar och specialprotokoll. Firewallen översätter och tillåter då primärt trafiken.
• WAF / Web Server Protection passar för HTTP- och HTTPS-applikationer när hostname, certifikat, sökvägar, skyddsprofiler, autentisering eller landsregler är relevanta.
• Reverse Proxy eller ZTNA passar för komplexa webbplattformar, identitetsintegration och privata applikationer när åtkomst ska kontrolleras starkt eller inte vara offentlig alls.

Om man snabbt vill göra en intern webbserver tillgänglig via portvidarebefordran, hjälper guiden Publicera server via DNAT på Sophos Firewall. För offentliga webbapplikationer bör man först överväga WAF.

⚠️ WebDAV stöds inte av Sophos WAF. Applikationer som Nextcloud bör därför inte publiceras blint via WAF, utan planeras med lämpliga brandväggs- och NAT-regler eller en annan publiceringsarkitektur.

Beslut: WAF, DNAT eller privat åtkomst

Den viktigaste frågan är inte hur snabbt en publicering kan byggas, utan om den senare kan drivas säkert, testas och återställas. Denna klassificering hjälper innan den tekniska implementeringen:

• Offentlig webbplats eller enkel HTTPS-applikation: WAF är oftast rätt startpunkt. DNS, certifikat, hostname, skyddsprofil, loggning och backend-tillgänglighet måste testas.
• Kundportal, partnerportal eller admin-gränssnitt: WAF med källbegränsning och valfritt MFA kan vara meningsfullt. Först bör man klargöra om WAF-MFA, landsregler eller fasta källnät är möjliga.
• Ren TCP- eller UDP-tjänst: DNAT är oftast mer passande. Firewall Rule, NAT-regel, målserver, returväg och loggning måste kontrolleras tillsammans.
• Webbapplikation med WebDAV eller specialprotokoll: Använd inte automatiskt WAF. Testa stödda funktioner, klientbeteende och alternativ publicering.
• Applikation endast för interna användare: Kontrollera VPN, ZTNA eller starkt begränsad WAF. Offentlig tillgänglighet bör ifrågasättas kritiskt.

För privata applikationer är en globalt tillgänglig WAF-regel ofta för mycket attackyta. Om endast ett fåtal personer behöver åtkomst är fasta källnät, VPN, ZTNA eller en annan privat åtkomstarkitektur ofta renare än en offentlig webbpublicering.

Planering och förutsättningar

Förutsättningar

Innan den första WAF-regeln bör man klargöra dessa punkter:

• Offentligt DNS-namn, till exempel portal.example.com
• Offentlig IP-adress eller alias på WAN-gränssnittet
• Certifikat för det publicerade värdnamnet
• Intern IP-adress eller FQDN för webbservern
• Intern målport för webbservern
• Beslut om HTTP ska omdirigeras till HTTPS
• Tillåtna källnät, länder eller användargrupper
• Lämplig skyddsprofil och valfri IPS-policy
• Aktiverad loggning för senare analys
• Extern teståtkomst utanför det egna LAN

Det offentliga DNS-namnet måste peka på den adress som används som Hosted address i WAF-regeln. Vid HTTPS måste certifikatet matcha det publicerade värdnamnet.

Dessutom behöver brandväggen ett web server-objekt under Web server > Web servers. Där beskrivs den interna eller externa målservern med host, protokoll och port. Host är ett IP- eller FQDN-hostobjekt. För backends är HTTP eller HTTPS möjliga; standardportarna är 80 och 443. Om backend-webbservern levererar långa svar eller behöver keep-alive bör Keep alive och Timeout kontrolleras medvetet i stället för att bara ärvas.

Dessutom bör man ta hänsyn till Web Server Protection-gränser tidigt. Sophos anger bland annat en gräns på 60 WAF-regler per Firewall. Det räcker för många miljöer, men kan bli relevant snabbare än väntat vid många kundportaler, tenants, testsystem eller separata hostnames. Då bör man inte blint skapa fler enskilda regler, utan kontrollera namngivningskoncept, sökvägar, virtuella webbservrar och alternativa publiceringsvägar.

WAF-regler är dessutom inriktade på IPv4-publiceringar. Om en applikation måste publiceras via IPv6 krävs en separat designkontroll. Även Exchange-mallarna är ingen fribiljett för moderna Exchange-miljöer: Sophos dokumenterar att WAF-regler för närvarande inte stöder Exchange-versioner efter 2013.

Planera WAF-publicering innan konfiguration

En WAF-regel bör inte planeras först i gränssnittet. Det måste vara klart i förväg om Sophos Firewall bara ska publicera eller om den också ska hantera autentisering, skyddsprofiler, landsregler och loggning.

Dessa frågor är viktiga innan en produktiv publicering:

• Är det verkligen en HTTP- eller HTTPS-applikation? För andra protokoll är DNAT oftast mer lämpligt.
• Måste applikationen vara offentligt tillgänglig? Privata adminportaler passar ofta bättre med VPN, ZTNA eller begränsade källnät.
• Vilket hostname och vilket certifikat används? DNS, SNI, certifikat och WAF-domäner måste matcha.
• Hur många publiceringar planeras? WAF-regellimit och senare hanterbarhet påverkar designen.
• Ska firewallen autentisera användare? För portaler kan WAF-MFA vara meningsfullt.
• Vilka skyddsprofiler är aktiva? För breda undantag försvagar WAF, för hårda profiler kan bryta applikationer.
• Hur loggas och testas det? Log Viewer, reverseproxy.log och backend-loggar måste vara kända innan Go-live.

För certifikat bör man tidigt klargöra om ett befintligt certifikat importeras, om brandväggen själv ska skapa och förnya ett Let’s-Encrypt-certifikat eller om ett externt genererat certifikat behövs. För wildcard-certifikat finns en separat guide: Skapa Let’s Encrypt wildcard-certifikat.

Konfigurera WAF-regel

Grundstruktur för en WAF-regel

En WAF-publicering består av flera komponenter:

• Hosted address: Offentlig IP-adress eller alias där klienter når applikationen.
• Listening port: Offentlig port, oftast 80 eller 443.
• Domains: Hostnames som ska matcha WAF-regeln.
• HTTPS certificate: Certifikat för det publicerade hostnamnet.
• Web server: tidigare skapat web server-objekt med host, protokoll, port och anslutningsinställningar.
• Allowed client networks: Källnät som får åtkomst.
• Blocked client networks / countries: Källor eller länder som blockeras.
• Protection policy: WAF-skydd mot typiska webbattacker.
• Authentication: Valfri förhandsautentisering via firewallen.

Sophos skapar WAF-regler i brandväggsreglernas område. Åtgärden heter Protect with web server protection.

Viktigt: En WAF-regel är inte en vanlig Firewall Rule med NAT bakom. Den skapar en Reverse-Proxy-publicering. Därför måste Hosted address, Listening port, Domains, certifikat, Protected server och Allowed client networks passa ihop. Om ett av dessa fält inte passar ser felet ofta ut som ett certifikats-, DNS- eller backendproblem.

Skapa WAF-regel

Menypath är:

Rules and policies > Firewall rules

Förfarande:

1. Välj IPv4.
2. Öppna Add firewall rule.
3. Välj New firewall rule.
4. Ge ett beskrivande regelnamn.
5. Sätt Rule position medvetet, särskilt om mer generella WAF-regler eller gamla publiceringar redan finns.
6. Välj alternativet Protect with web server protection under Action.
7. Om ingen speciell mall behövs, lämna Preconfigured template på None.
8. Aktivera Log firewall traffic om regeln ska vara spårbar i Log Viewer och rapporter.
9. Under Hosted server details definiera den offentliga adressen, lyssningsporten, HTTPS, certifikat och domäner.
10. Under Protected servers välj rätt web server-objekt eller skapa det först under Web server > Web servers.
11. Sätt medvetet Allowed client networks. För offentliga webbplatser kan Any IPv4 behövas; för portaler är en begränsning oftast bättre.
12. Vid behov sätt Blocked client networks eller Blocked countries.
13. Kontrollera skyddsprofil, IPS och avancerade alternativ.
14. Spara regeln och testa externt.

När regeln sparas startar Sophos om Web Server Protection-reglerna. Befintliga live-anslutningar via dessa regler kan avbrytas. Ändringar av produktiva WAF-regler bör därför göras under ett underhållsfönster eller åtminstone medvetet.

Om Allowed client networks lämnas tomt fungerar WAF-regeln inte korrekt; webbläsaren kan då få 400 Bad Request. För en offentlig applikation är Any IPv4 visserligen möjligt, men inte automatiskt rätt. För adminportaler, partnerportaler eller interna verktyg bör man först kontrollera fasta källnät, landsbegränsning, WAF-MFA, VPN eller ZTNA.

Portkonflikter bör klargöras innan regeln sparas. Beroende på Hosted address kan WAF använda samma port som SSL VPN, men inte samma port som User Portal. Om WebAdmin, VPN Portal, User Portal eller en gammal DNAT-publicering redan lyssnar på en offentlig IP måste tilldelningen vara entydig. Annars ser felet senare ut som ett WAF-problem trots att en annan funktion svarar.

Go-live och acceptans

Planera Go-live och rollback

En WAF-publicering bör inte betraktas som avslutad direkt vid sparandet av regeln. Avgörande är om DNS, certifikat, Hosted address, backend, skyddsprofil och loggning fungerar tillsammans. Särskilt vid befintliga portvidarebefordringar bör man behandla bytet som en liten publicering.

Innan Go-live kontrollera:

• Dokumentera aktuell brandväggskonfiguration eller åtminstone de berörda regel- och certifikatinställningarna.
• Identifiera tidigare DNAT- eller brandväggsregler som påverkar samma port, offentliga IP eller värdnamn.
• Inaktivera gamla DNAT-regler eller dokumentera tydligt varför de inte konkurrerar med WAF-regeln.
• Minska DNS-TTL innan en övergång om det offentliga värdnamnet byter från en gammal publicering till WAF.
• Tillhandahåll extern teståtkomst, testa inte bara från det interna LAN.
• Definiera testfall: Startsida, inloggning, uppladdning, nedladdning, API-sökväg, WebSocket, utloggning och felmeddelande.
• Fastställ förväntade loggplatser: Log Viewer, reverseproxy.log, backend-access-log och backend-error-log.
• Fastställ rollback-kriterium, till exempel inloggning inte möjlig, backend inte tillgänglig, fel certifikat, hög felfrekvens eller kritiska applikationsdelar defekta.

Vid bytet bör endast en publicering vara aktiv åt gången. Om en gammal DNAT-regel och en ny WAF-regel använder samma offentliga IP och port är beteendet svårt att förstå. Innan den produktiva omkopplingen bör det vara klart vilken regel som faktiskt hanterar trafiken.

En enkel rollback består ofta i att inaktivera den nya WAF-regeln och återaktivera den tidigare publiceringen. Om DNS dessutom har ändrats måste DNS-TTL beaktas. Vid certifikats- eller värdnamnsproblem är en rollback via DNS ensam ofta för långsam; i sådana fall bör den gamla regeln kunna aktiveras igen på samma Hosted address eller en alternativ åtkomst vara tillgänglig.

Efter Go-live bör de första åtkomsterna övervakas aktivt. Viktigt är inte bara framgångsrika HTTP-statuskoder, utan även WAF-blockeringar, backend-fel, oväntade omdirigeringar, sessionsproblem och saknade klient-IP-informationer i backend-loggarna.

Godkänningstest efter Go-live

Ett WAF-test är först komplett när samma förfrågan kan spåras från tre perspektiv: klient, brandvägg och backend. Detta gör det lättare att snabbt identifiera om ett problem ligger i DNS, certifikat, WAF-matchning, skyddsprofil eller applikation.

• Extern klient: Kontrollera DNS-upplösning, certifikat, HTTP-status, login och viktiga sökvägar. Applikationen bör öppna via det offentliga hostnamnet utan certifikatsvarning.
• Sophos Firewall: Kontrollera Log Viewer, WAF-regel, reverseproxy.log och blockerade signaturer. Rätt WAF-regel bör hantera åtkomsten och loggar bör visa tillåtna eller motiverat blockerade requests.
• Backend-webbserver: Kontrollera Access-log, Error-log, applikationssession och X-Forwarded-For. Requesten bör nå rätt vHost eller sökväg, och klient-IP-logiken måste förstås.

För produktiva applikationer bör man testa minst dessa fall:

• Åtkomst via rätt värdnamn och via en icke-matchande domän.
• Inloggning med giltig och ogiltig användare, om applikationen eller WAF autentiserar.
• Uppladdning, nedladdning, API- eller WebSocket-funktion, om applikationen använder sådana funktioner.
• Åtkomst från tillåten källa och, om möjligt, från en medvetet icke-tillåten källa.
• Beteende hos en känd ofarlig WAF-testförfrågan, så att loggning och blockväg är synliga.

Om applikationen efter Go-live verkar fungera men inga passande loggar är synliga, är testet ännu inte avslutat. Då kan det vara så att en annan publicering matchar, loggning saknas eller åtkomsten inte går via den förväntade vägen.

Säkra skydd och åtkomst

Certifikat och värdnamn

För HTTPS måste WAF-regeln använda ett certifikat som matchar det offentliga värdnamnet. Certifikatet importeras eller skapas under Certificates > Certificates och väljs sedan i WAF-regeln.

Viktiga punkter:

• DNS-namnet måste matcha certifikatet.
• Det valda HTTPS-certifikatet kan fylla i domänlistan i WAF-regeln automatiskt eller skriva över befintliga domänposter.
• Vid flera värdnamn på samma IP använder brandväggen SNI.
• Wildcard-certifikat är möjliga men bör dokumenteras noggrant.
• Wildcard-domäner används först efter mer specifika domänregler.
• Understreck i den vänstra domänetiketten är inte ett rent DNS-namn och bör undvikas för WAF-domäner.
• Backend kan använda ett annat internt namn om Host Header och applikationen kan hantera det.
• Vid problem med absoluta länkar kan Rewrite HTML bli relevant.

Om flera virtuella webbservrar körs över samma IP och port, avgör brandväggen vid HTTPS baserat på SNI och värdnamn vilken WAF-regel som passar.

Domains i WAF-regeln bör därför matcha DNS och certifikat exakt. Wildcards kan vara hjälpsamma, men bör inte ersätta ett rent publiceringskoncept. Om flera applikationer körs under liknande hostnames behövs tydlig regel- och certifikatsdokumentation, annars blir det senare svårt att förstå vilken WAF-regel som faktiskt matchar. Ett test med en medvetet icke-matchande subdomän är användbart: då ser man om den specifika regeln, en wildcard-regel eller ingen matchande virtuell webbserver svarar.

Planera klient-IP och backend-loggar

Vid WAF-publiceringar ser den interna webbservern ofta inte den verkliga klient-IP:n som direkt källadress. Sophos Firewall fungerar som en omvänd proxy och bygger själv upp anslutningen till backend. För applikationen och webbserverloggarna kan därför först brandväggens adress vara synlig.

Om applikationen eller backend behöver den ursprungliga klient-IP:n bör man tidigt kontrollera om X-Forwarded-For eller en jämförbar header utvärderas. Detta är viktigt för:

• Applikationsloggar och säkerhetsutvärdering
• Hastighetsbegränsningar eller inloggningsskydd på applikationsnivå
• Felsökning med användar- eller käll-IP-referens
• SIEM- eller övervakningskorrelation
• Forensisk utvärdering efter en incident

Viktigt är förtroendegränsen: Ett backend bör endast behandla sådana headers som betrodda om förfrågan verkligen kommer från Sophos Firewall eller en definierad omvänd proxy. Offentliga klienter bör inte kunna sätta X-Forwarded-For direkt som säkerhetsbevis. I praktiken bör webbservern därför endast lita på brandväggens IP och ignorera eller skriva över headers från andra källor.

För felsökning innebär detta: Log Viewer, reverseproxy.log och backend-logg måste täcka samma testtidpunkt. Om endast brandväggens IP är synlig i backend är det inte automatiskt ett WAF-fel, utan ofta normalt omvänd proxy-beteende.

Begränsa klientåtkomst

Inte varje webbapplikation behöver vara globalt tillgänglig. Redan i WAF-regeln kan man begränsa åtkomsten.

Lämpliga begränsningar:

• Tillåt endast kända käll-IP-adresser eller partnernät.
• Blockera onödiga länder.
• Blockera IP-adresser från okända länder endast om risken för egen avstängning har granskats.
• För portaler använd dessutom WAF-MFA eller förhandsautentisering.
• Blockera kända skadliga källor via Threat Feeds.

För lands- och dåliga IP-blockering hjälper Sophos Firewall: Blockera länder och skadliga IPs. För dynamiska hotlistor är Sophos Firewall Threat Feeds relevant.

Planera Threat Feeds och Active Threat Response

Vid offentligt tillgängliga webbapplikationer bör man inte bara betrakta WAF-regeln själv. Sedan SFOS 22 är Threat Feeds också mer relevanta för inkommande, vidarebefordrad trafik som WAF- och DNAT-publiceringar. Brandväggen kan matcha sådana träffar med MDR Threat Feeds, NDR Essentials och Third-Party Threat Feeds.

För administratörer innebär detta: WAF är publiceringslagret, Threat Feeds och Active Threat Response kan blockera eller synliggöra ytterligare kända skadliga källor. Detta ersätter dock inte patchhantering, ren autentisering och applikationshärdning.

Praktiskt bör man kontrollera:

• Är Active Threat Response meningsfullt konfigurerad i miljön?
• Används relevanta Threat Feeds och granskas regelbundet?
• Är WAF-händelser, Active-Threat-Response-loggar och backend-loggar synliga i drift?
• Finns det en process för falska positiva, tillåtelselistor och nödfriheter?
• Är det klart vem som reagerar på träffar och om det bara loggas eller blockeras aktivt?

Särskilt vid kundportaler, admin-gränssnitt eller partneråtkomster bör denna kontroll ske före Go-live. Om en feed senare blockerar produktiv trafik måste driften veta var man ser träffen och hur man beslutar korrekt: verklig attack, falskt alarm eller felaktigt publicerad applikation.

Skyddsprofiler och undantag

En WAF-regel bör inte bara publicera utan också skydda. För detta använder man skyddspolicyer, valfria IPS-policyer och undantag.

Typiska skyddsområden:

• Cookiemanipulation
• URL-härdning
• Formulärhärdning
• Cross-Site Scripting
• Applikationsattacker
• Antiviruskontroll
• Klienter med dåligt rykte

Under Web server > General settings finns ytterligare globala inställningar för Web Server Protection, bland annat TLS-versionsstyrning och skydd mot långsamma HTTP-DoS-mönster. Dessa inställningar gäller inte bara en enskild regel. Ändringar bör därför planeras medvetet och samordnas med befintliga WAF-publiceringar.

För Protection Policies är läget viktigt. Reject blockerar och skapar synliga Log Viewer-händelser för WAF-regler. Monitor loggar bara, men dessa WAF-meddelanden visas inte nödvändigtvis i Log Viewer; då måste reverseproxy.log kontrolleras. Monitor kan vara användbart i en pilot, men för produktivt skydd måste det vara tydligt om attacker bara observeras eller faktiskt avvisas.

IPS i en WAF-regel bör bedömas separat. Sophos använder IPS för WAF endast när kommunikationen mellan brandvägg och web server sker via HTTP. Om backend är ansluten via HTTPS ska man alltså inte automatiskt förvänta sig att en vald IPS-policy har samma effekt.

Undantag bör sättas snävt. Om en applikation inte fungerar på grund av en enskild sökväg eller en viss källa bör man inte stänga av hela skyddsprofilen. Bättre är ett riktat undantag med sökväg, källa och tydlig motivering.

⚠️ Varje undantag minskar skyddseffekten. Sökväg, källa, anledning, datum och granskningstidpunkt bör dokumenteras så att tillfälliga lösningar inte blir permanenta.

Sökvägsspecifik routing, WebSocket och lastbalansering

WAF kan vidarebefordra förfrågningar beroende på sökväg till olika backend-servrar. Detta är användbart när en applikation har flera komponenter eller ett enda värdnamn ska fördelas på flera interna tjänster.

Exempel:

• /api/ går till en API-server.
• /shop/ går till ett shop-system.
• / går till standard-webbservern.

Man bör dock notera att brandväggen inte enkelt utvärderar sökvägar efter tabellordning. Sophos prioriterar längre och därmed mer specifika sökvägar. Specifika sökvägar måste därför planeras och testas noggrant. Om WebSocket behövs kan WebSocket passthrough aktiveras. WebSocket-trafik vidarebefordras då utan samma WAF-granskning eftersom protokollet inte kan granskas på samma sätt som vanlig HTTP-trafik.

Standardvägen / bör medvetet vara kvar. Om den tas bort vidarebefordras icke-matchande sökvägar inte till en standardserver, utan avvisas med 404 Not Found. Det kan vara avsiktligt, men vid fel ser det snabbt ut som ett backendproblem.

Vid flera backend-servrar är Sticky Sessions eller Hot-standby möjliga. Detta hjälper vid enkla hög tillgänglighets- eller lastbalanseringsfall, men ersätter inte ett fullständigt applikationslastbalanseringskoncept.

Om den skyddade webbservern inte finns i firewallens lokala nät bör routing och SD-WAN kontrolleras särskilt medvetet. För backends via platsförbindelser, MPLS eller route-based IPsec kan en passande SD-WAN Route behövas så att firewallen når Protected Server tillförlitligt och returvägen stämmer. Vid route-based IPsec är dessutom viktigt: WAF via route-based IPsec med Traffic Selectors för subnät stöds inte av Sophos; Any-to-Any-anslutningar är den dokumenterade utvägen.

Drift och felsökning

Vanliga fel

• Offentligt DNS-namn pekar på fel IP: WAF-regeln nås aldrig.
• Certifikat matchar inte hostnamnet: Webbläsare visar certifikatsfel eller SNI-matchning passar inte.
• Fel Hosted address vald: Firewallen matchar en annan regel eller ingen WAF-trafik.
• Allowed client networks tom: Regeln fungerar inte som förväntat.
• WAF-regellimit inte beaktat: Fler publiceringar kan inte längre avbildas rent.
• Exchange-version efter 2013 planerad med WAF-template: Mallen passar inte till den stödda WAF-gränsen.
• Portkonflikt med User Portal, VPN Portal eller annan tjänst: Applikationen är inte tillgänglig eller en firewalltjänst svarar.
• Backend är inte tillgänglig internt: Externa klienter får fel, även om DNS och certifikat stämmer.
• Backend-timeout felaktigt inställd: Långa svar slutar med fel även om applikationen i grunden är tillgänglig.
• Backend ligger över VPN eller SD-WAN utan passande route: WAF-regeln matchar, men Protected Server nås inte tillförlitligt.
• Route-based IPsec med Traffic Selectors till backend: WAF över denna väg stöds inte.
• WAF-undantag satt för brett: Skyddseffekten minskar onödigt.
• WebDAV-applikation publicerad via WAF: Applikationen fungerar inte tillförlitligt eller stöds inte.
• Regeländring utan underhållsfönster: Befintliga anslutningar kan avbrytas vid omstart av WAF-reglerna.
• Gammal DNAT-regel och ny WAF-regel konkurrerar: Det är oklart vilken publicering som hanterar trafiken.

Felsökning

Om en WAF-publicering inte fungerar bör man systematiskt kontrollera:

1. Pekar det offentliga DNS-namnet på rätt offentlig IP?
2. Är rätt Hosted address vald i WAF-regeln?
3. Är lyssningsporten ledig och inte upptagen av WebAdmin, User Portal, VPN Portal eller en annan publicering?
4. Matchar certifikatet det anropade värdnamnet?
5. Är den interna webbservern tillgänglig från brandväggen?
6. Är Allowed client networks, Blocked client networks och Blocked countries korrekt satta?
7. Ligger Protected Server över en route, SD-WAN Route eller VPN-förbindelse som verkligen passar ur firewallens perspektiv?
8. Finns det en mer allmän WAF-regel som matchar tidigare?
9. Visas åtkomsten i Log Viewer som tillåten, blockerad eller bortkastad?
10. Finns det ledtrådar i /log/reverseproxy.log?
11. Är Protection Policy satt till Monitor eller Reject?
12. Passar timeout för web server-objektet applikationen?

För den första analysen är Log Viewer användbar. För djupare felsökning hjälper Web Server Protection-loggarna på brandväggen. En översikt över loggfiler och tjänster finns i Sophos Firewall Troubleshooting: Services och Logs.

Checklista för produktiva WAF-regler

• Regelnamn beskriver applikation, värdnamn och miljö.
• Ansvarig person eller systemägare är dokumenterad.
• DNS, certifikat och Hosted address är kontrollerade.
• Backend-tillgänglighet har testats från brandväggen.
• Tidigare publicering och rollback är dokumenterade.
• Gamla DNAT- eller brandväggsregler konkurrerar inte med WAF-regeln.
• Externa Go-live-tester är definierade.
• Åtkomst är begränsad till nödvändiga källor eller länder.
• Threat Feeds och Active Threat Response har utvärderats för offentliga applikationer.
• Loggning är aktiv.
• Skyddsprofil är inte onödigt inaktiverad.
• Undantag är snäva, motiverade och tidsbegränsade.
• Ändring har testats externt.
• Utgångsdatum eller granskningstidpunkt är dokumenterad.

Vanliga frågor