Sophos Firewall WAF: Publicera webbservrar 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 härdningssammanhanget 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.

PHP2Shell – lägesbild 24 oktober 2026: För CVE-2026-109618 och CVE-2026-109619 anger Sophos i rådgivningen från 22 oktober, version 4 inget specifikt skydd i Sophos Firewall WAF. Berörda PHP-miljöer på backend måste uppdateras; publicering via WAF ersätter inte denna uppdatering. IPS-signaturerna som har funnits sedan 22 oktober används för att upptäcka angreppsförsök. Kontrollera separat om en lämplig IPS-policy granskar den faktiska datavägen och vilken åtgärd den utför; IPS-guiden hjälper med detta. Att inget larm visas bevisar inte att rätt säkerhetsuppdatering är installerad.

Beslut före publicering

Innan man skapar en WAF-regel bör det vara klart om WAF, DNAT, VPN eller ZTNA passar applikationen. Detta beslut är viktigare än själva formuläret i brandväggen, eftersom det avgör attackyta, drift och felsökning.

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. Brandväggen översätter och tillåter då primärt trafiken.
WAF / Web Server Protection passar för HTTP- och HTTPS-applikationer när värdnamn, certifikat, sökvägar, skyddsprofiler, autentisering eller landsregler är relevanta.
Omvänd proxy eller ZTNA passar för komplexa webbplattformar, identitetsintegration och privata applikationer när åtkomsten ska kontrolleras strikt eller inte vara offentlig alls.

Om man bara vill göra en intern webbserver snabbt 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, värdnamn, 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. Brandväggsregel, 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 en bättre lösning än en offentlig webbpublicering.

Planering och förutsättningar

En stabil WAF-publicering kräver DNS, certifikat, backend-tillgänglighet, loggning och en återställningsplan. Dessa punkter bör vara fastställda före konfigurationen.

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 webbserverobjekt under Web server > Web servers. Där beskrivs den interna eller externa målservern med värd, protokoll och port. Värden är ett IP- eller FQDN-värdobjekt. 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 övertas utan eftertanke.

Backendens Timeout kan ligga mellan 1 och 65,535 sekunder; standardvärdet är 300 sekunder. När tiden löper ut skickar WAF 502 till klienten. Disable backend connection pooling tvingar fram en ny backendanslutning för varje åtkomst och kan sänka prestandan. Använd därför alternativet endast för riktad felsökning och återställ sedan det dokumenterade tidigare tillståndet.

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 brandvägg. Det räcker för många miljöer, men kan bli relevant snabbare än väntat vid många kundportaler, klientorganisationer, testsystem eller separata värdnamn. Då bör man inte blint skapa fler enskilda regler, utan kontrollera namngivningskoncept, sökvägar, virtuella webbservrar och alternativa publiceringsvägar.

SFOS 22 stöder inte WAF-regler via IPv6. En applikation får därför inte planeras som IPv6-publicering med den här funktionen; översikten IPv6-stöd och begränsningar i Sophos Firewall med SFOS 22 skiljer WAF från de IPv6-regel- och skyddsfunktioner som stöds. Ä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.

De förkonfigurerade mallarna kommer från ett äldre Microsoft-applikationslandskap: Exchange Autodiscover, Outlook Anywhere och Exchange General slutar vid gränsen Exchange 2013; de övriga Sophos-guiderna nämner Microsoft Lync, Remote Desktop Gateway eller RD Web 2008/R2 samt SharePoint 2010/2013. De är därför ingen aktuell utgångspunkt för Microsoft 365, moderna Exchange-versioner, Teams eller dagens RDS-installationer. Jämför före användning de sökvägar, autentiseringsmetoder och skyddsprofiler som faktiskt behövs med den aktuella Microsoft-arkitekturen; lämna Preconfigured template på None vid tveksamhet för en modern applikation.

Skapa ett backend-objekt med ett tydligt exempel

Det offentliga namnet och backend-namnet fyller olika funktioner. I följande exempel öppnar användarna portal.example.com; brandväggen når servern via backend.example.com. Båda namnen är platshållare och måste ersättas med de egna DNS-namnen. Backend-namnet måste ur brandväggens perspektiv lösas till den faktiska servern, inte tillbaka till den egna offentliga WAF-adressen: Annars finns ingen fungerande väg till backend.

Skapa och spara ett objekt med namnet WAF_Backend_Portal och FQDN backend.example.com under Hosts and services > FQDN host > Add. Använd alternativt ett IP-värdobjekt för en fast backend-server. Enligt produktdokumentationen ger FQDN-värdar bredare serverkompatibilitet; DNS-upplösning och målserver måste ändå kontrolleras.
Skapa ett webbserverobjekt WAF_Portal_Server under Web server > Web servers > Add och välj backend-objektet under Host.
Ställ in Type och Port efter den faktiska backend-lyssnaren: i HTTPS-exemplet HTTPS och 443, för en HTTP-backend HTTP och exempelvis 80. Den externa lyssningsporten fastställs först i WAF-regeln och behöver inte vara identisk med backend-porten. För en HTTP-backend måste det okrypterade segmentet säkras medvetet; en HTTPS-frontend krypterar inte i sig detta segment.
Aktivera Keep alive endast om webbservern stöder återanvändning av anslutningar. Utvärdera först Timeout med standardvärdet 300 sekunder. Detta avser väntetiden på data till eller från backend, inte en generell maximal total varaktighet för varje förfrågan: Så länge data kommer in i tid kan ett svar ta längre tid. Vid 502 bör man därför kontrollera backend-loggar och uppehåll i dataöverföringen i stället för att omedelbart höja värdet.
Aktivera inte Disable backend connection pooling som en prestandaoptimering i normal drift. Spara objektet, kontrollera tilldelningen till WAF-regeln eller till Protect-sökvägen i SFOS 23 och kontrollera en representativ backend-åtkomst.

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 produktionspublicering:

Ä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 värdnamn och vilket certifikat används? DNS, SNI, certifikat och WAF-domäner måste matcha.
Hur många publiceringar planeras? WAF-regelgränsen och den senare hanterbarheten påverkar designen.
Ska brandväggen autentisera användare? För portaler kan WAF-MFA vara meningsfullt.
Vilka skyddsprofiler är aktiva? För breda undantag försvagar WAF, för strikta profiler kan få applikationer att sluta fungera.
Hur loggas och testas det? Log Viewer, reverseproxy.log och backend-loggar måste vara kända innan driftsättning.

För certifikat bör man tidigt klargöra om ett befintligt certifikat importeras med privat nyckel och CA-kedja, 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

Själva WAF-regeln består av offentlig adress, värdnamn, certifikat, målserver, tillåtna källor och skyddsprofil. Dessa fält bör ses som en helhet, inte som isolerade enskilda alternativ.

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: Värdnamn som ska matcha WAF-regeln.
HTTPS certificate: Certifikat för det publicerade värdnamnet.
Web server: Tidigare skapat webbserverobjekt med värd, 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 brandväggen.

Sophos skapar WAF-regler i området för brandväggsregler. Åtgärden heter Protect with web server protection.

Viktigt: En WAF-regel är inte en vanlig brandväggsregel med NAT bakom. Den skapar en publicering via omvänd proxy. 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

Menysökvägen är:

Rules and policies > Firewall

Förfarande:

Nya regler är aktiverade som standard. För en förberedd publicering som ännu inte har godkänts ska du därför uttryckligen kontrollera regelns status och låta regeln vara inaktiverad fram till planerad driftsättning. Rule position erbjuder Top eller Bottom; Rule group placerar regeln i en befintlig grupp eller i en grupp som skapats via Create new. Automatic använder den första matchande gruppen utifrån regeltyp och käll-/målzoner. Gruppering är ett administrativt hjälpmedel, inte en ersättning för åtkomstkontroll.

Följande numrerade förfarande med Protected servers gäller endast för SFOS 22 och förblir oförändrat för den versionen. WAF-regler stöder endast IPv4. Den yttre regelåtgärden Protect with web server protection är inte samma sak som den sökvägsspecifika Action > Protect under Traffic routing i SFOS 23; för SFOS 23 gäller den separata instruktionen direkt efter detta förfarande.

Välj IPv4.
Öppna Add firewall rule.
Välj New firewall rule.
Ge regeln ett beskrivande namn.
Ställ in Rule position medvetet, särskilt om mer generella WAF-regler eller gamla publiceringar redan finns.
Välj alternativet Protect with web server protection under Action.
Om ingen särskild mall behövs, lämna Preconfigured template på None.
Under Hosted server details definierar du den offentliga adressen, lyssningsporten, HTTPS, certifikat och domäner.
Under Protected servers väljer du rätt webbserverobjekt eller skapar det först under Web server > Web servers.
Ställ in Allowed client networks medvetet. För offentliga webbplatser kan Any IPv4 behövas; för portaler är en begränsning oftast bättre.
Ställ vid behov in Blocked client networks eller Blocked countries.
Granska medvetet Protection, Intrusion prevention och Traffic shaping under de avancerade policyerna.
Spara regeln och testa externt.

SFOS 23: Publicera sökvägar under Traffic routing

Skapa eller redigera en IPv4-regel under Rules and policies > Firewall. Välj fortfarande Protect with web server protection som yttre Action och konfigurera offentlig adress, port, HTTPS-certifikat och domäner så att de passar. En ny regel innehåller som standard / med Block: Utan ytterligare routingkonfiguration avvisas förfrågningar i stället för att publiceras.
Redigera eller lägg till den specifika avsedda sökvägen under Traffic routing med Edit eller Add new path. Välj uttryckligen Protect under Action och tilldela de backend-objekt som behövs från Web server > Web servers. En mall skapar visserligen sökvägar med Protect, men backend-objekten måste fortfarande tilldelas.
Tilldela den avsedda autentiseringspolicyn i fältet Authentication för varje skyddad sökväg och ställ in Allowed client networks medvetet; lämna inte fältet tomt. Granska Blocked client networks, Blocked countries och Block IP addresses of unknown country-origin noggrant; vid okänt ursprungsland måste även risken att låsa ute sig själv beaktas.
Om endast vissa sökvägar ska publiceras, behåll medvetet / med Block som uppsamlingsroute. Sätt endast / till Protect om hela applikationen ska publiceras; kontrollera uttryckligen backend, autentisering, åtkomstbegränsningar och vilka applikationsdelar som därmed blir tillgängliga. Längre, mer specifika sökvägar utvärderas först, inte tabellordningen.
Skilj mellan åtgärderna: Block avvisar förfrågningar för den valda sökvägen och vidarebefordrar dem inte till backend. Protect tillämpar regelns skyddspolicy samt de konfigurerade autentiserings- och åtkomstinställningarna. Redirect skickar en omdirigering till klienten till det konfigurerade målet i stället för att publicera en backend. Passthrough skapar en tunnel till backend utan WAF-granskning och utan att tillämpa skyddspolicyn. Protection gäller endast för sökvägar med Protect.
Efter att du sparat, testa externt en avsedd tillåten sökväg, en avsiktligt blockerad sökväg och en sökväg utan specifik matchning. Om Redirect och Passthrough används, testa även dessa separat. Korrelera klientresultat, Log Viewer, reverseproxy.log och backend-loggar utifrån samma förfrågan och samma tidpunkt.

Standardsökvägen kan redigeras, klonas eller tas bort. En klon övertar inget verksamhetsmässigt godkännande: kontrollera på nytt åtgärd, backend, autentisering och källor för den nya tilldelningen. Ta inte bort / av misstag om den utgör den avsiktligt blockerande uppsamlingsrouten.

Befintliga regler efter uppgraderingen: Enligt Sophos dokumentation ställs befintliga WAF-regler automatiskt om till Protect vid uppgradering till SFOS 23; befintliga sökvägsspecifika routes behålls. Detta skiljer sig från standardinställningen / med Block i nya regler och från den äldre SFOS 18-migreringen av ModSecurity Protection Policies. Kontrollera ändå åtgärd, backend, autentisering, åtkomstbegränsningar och faktisk route för varje sökväg efter uppgraderingen och genomför externa acceptanstester; den automatiska migreringen ersätter inte acceptanstester.

Hur tutorialen ska tolkas: Sophos tutorial om att skydda en webbserver mot attacker använder fortfarande förfarandet med Protected servers och anger IPv4 or IPv6, trots att WAF-regelreferensen begränsar WAF till IPv4. Tutorialen är därför inte en fullständig routinginstruktion för SFOS 23. För den aktuella konfigurationen gäller IPv4 och de uttryckliga sökvägsåtgärderna ovan.

När regeln sparas startar Sophos om Web Server Protection-reglerna. Befintliga aktiva anslutningar via dessa regler kan avbrytas. Ändringar av WAF-regler i produktion 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. WebAdmin och User Portal behöver var sin unik port. WAF och VPN Portal använder båda TCP; om de använder samma port måste deras Hosted address eller WAN-IP-adresser därför vara olika. WAF kan skiljas från SSL VPN genom WAN-IP-adress, port eller protokoll, eftersom SSL VPN stöder TCP eller UDP. Ett annat FQDN- eller SNI-namn räcker inte i sig för att separera dessa lyssnare. Om en annan tjänst eller en gammal DNAT-publicering redan lyssnar på en offentlig IP-adress måste tilldelningen testas per IP-adress, port och protokoll före driftsättning.

Standardporten för User Portal är 4443; portallyssnare och deras begränsningar beskrivs i portalöversikten.

SFOS 23: Ange konkreta svar för Block och Redirect

En routingåtgärd kan samla flera poster under Paths om alla behöver hanteras på samma sätt. Välj sökvägarna och åtgärden under Traffic routing > Add new path, fyll i de åtgärdsberoende fälten och spara sökvägsposten. Använd separata poster för olika backends, åtkomstregler eller omdirigeringsmål.

För Block bestämmer Response code svaret. Ett exempel är /admin/ med Forbidden (403), medan / behålls med Block som uppsamlingsroute. Det dokumenterade urvalet omfattar 400 till 417 samt 422, 423, 424 och 426. Välj koden efter det avsedda budskapet: 403 står för nekad åtkomst, 404 för innehåll som inte hittades. Att välja koden 401 konfigurerar ingen autentiseringspolicy; statuskoden i sig ger inget inloggningsskydd. Kontrollera vid acceptanstestet den konfigurerade statusen och att ingen motsvarande förfrågan når backend.

För Redirect ingår, förutom Paths och Action, fälten Response code, Protocol, Host, Path och Port i konfigurationen. Exempel: /old-portal/ med Temporary Redirection (307), Protocol HTTPS, en FQDN-host för portal.example.com, Path /portal/ och Port 443. Ersätt namn och sökvägar med dem som gäller för den egna målapplikationen. 307 betecknar en tillfällig omdirigering där förfrågningsmetoden behålls; det passar för ett kontrollerat pilotförsök om målet hanterar samma metod. Testa ändå webbläsare och API-klient separat, särskilt POST-förfrågningar. Målet /portal/ måste i sig vara tillgängligt och skyddat, exempelvis via en lämplig Protect-sökväg; en omdirigering i sig skapar ingen backend- eller åtkomstkonfiguration där.

Urvalet omfattar 300, 301, 302, 303, 304, 305, 307 och 308. Alla koder som erbjuds är inte vanliga omdirigeringar till en ny sida: 304 beskriver cachevalidering. 305 är föråldrad på grund av säkerhetsrisker och rekommenderas inte för offentliga applikationer. Använd 301 respektive 308 först när en permanent övergång är avsedd och ta hänsyn till klient- och cachebeteende vid en återgång. Målets standardportar är 80 för HTTP och 443 för HTTPS. Redirect utför ingen WAF-granskning och skickar inte förfrågan till en backend för denna route; kontrollera därför status och omdirigeringsmål på klienten och därefter målapplikationens skydd.

Anpassa Host Header, HTML och komprimering efter behov

Advanced settings i en WAF-regel hjälper vid specifika problem med omvänd proxy. Det är inte alternativ som generellt bör aktiveras allihop:

Pass host header vidarebefordrar den Host Header som klienten begärt till backend. Vid flera webbplatser på en server kan detta göra att rätt virtuell värd väljs. Konfigurera backendens vHost så att den matchar det publicerade namnet och kontrollera i accessloggen att ingen annan webbplats svarar.
Rewrite HTML anpassar länkar i returnerade sidor. Om exempelvis en absolut länk pekar på http://backend.example.com/ medan applikationen publiceras via det offentliga namnet kan en omskrivning behövas. Om de offentliga värdnamnen redan stämmer eller länkarna genomgående är relativa behövs den normalt inte. Bearbetningen gäller Content-Type-värdena text/* och *xml*; binära nedladdningar måste levereras med korrekt Content-Type, annars finns risk att innehållet skadas. Testa därefter offentliga länkar, nedladdningar och applikationsfunktioner separat.
Rewrite cookies skriver om cookies i de returnerade sidorna. Vid sessionsproblem ska du undersöka vilka cookies som faktiskt sätts samt inloggning och utloggning, i stället för att förväxla cookieomskrivning med Cookie signing: omskrivning och manipulationsskydd har olika uppgifter.
Disable compression support är ett riktat hjälpmedel vid felaktigt visade sidor eller Content-Encoding-fel. Brandväggen begär då okomprimerade data från backend och levererar dem okomprimerade oavsett vilken kodning som begärts. Dokumentera tidigare tillstånd, upprepa samma sidförfrågan och återställ alternativet om det inte löser felet.

Vissa portar är reserverade för systemtjänster även om den aktuella tjänsten inte används. Att ingen lyssnare använder porten innebär inte i sig att en sådan port är tillgänglig för WAF; översikten Reserverade portar i Sophos Firewall hjälper vid planeringen. Traffic shaping tilldelar publiceringen bandbredd och tidsberoende prioritering. Det är ett driftsbeslut, inte ett ytterligare applikationsskydd; kontrollera även uppladdningar och nedladdningar under representativ belastning när policyn är aktiverad.

Go-live och acceptans

Publiceringen är inte färdig när regeln har sparats. Först externa tester, relevanta loggar och en tydlig återställningsplan gör ändringen redo för produktion.

Planera Go-live och rollback

En WAF-publicering bör inte betraktas som avslutad direkt när regeln sparas. 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 mindre publicering.

Kontrollera före Go-live:

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-adress eller värdnamn.
Inaktivera gamla DNAT-regler eller dokumentera tydligt varför de inte konkurrerar med WAF-regeln.
Minska DNS-TTL före 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-accesslogg och backend-fellogg.
Fastställ kriterier för rollback, till exempel att inloggning inte är möjlig, backend inte är tillgänglig, certifikatet är fel, felfrekvensen är hög eller kritiska applikationsdelar inte fungerar.

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-adress och samma port är beteendet svårt att förstå. Innan omkopplingen i produktion 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 saknad klient-IP-information i backend-loggarna.

Acceptanstest 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, inloggning och viktiga sökvägar. Applikationen bör öppnas via det offentliga värdnamnet utan certifikatsvarning.
Sophos Firewall: Kontrollera Log Viewer, WAF-regel, reverseproxy.log och blockerade signaturer. Rätt WAF-regel bör hantera åtkomsten och loggarna bör visa tillåtna eller motiverat blockerade förfrågningar.
Backend-webbserver: Kontrollera accesslogg, fellogg, applikationssession och X-Forwarded-For. Förfrågan bör nå rätt vHost eller sökväg, och hanteringen av klient-IP måste vara klarlagd.

För produktionsapplikationer bör man testa minst dessa fall:

Åtkomst via rätt värdnamn och via en domän som inte matchar.
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 en tillåten källa och, om möjligt, från en medvetet otillåten källa.
Beteendet vid en känd ofarlig WAF-testförfrågan, så att loggningen och hur blockeringen sker blir 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

För offentliga webbapplikationer är WAF bara ett skyddslager. Certifikat, källbegränsningar, Threat Feeds, skyddsprofiler och backend-loggning måste planeras tillsammans.

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. *. är endast tillåtet i början, exempelvis *.example.com; flera wildcard-domäner i en regel är möjliga.
Understreck i den vänstra domänetiketten ger inte ett korrekt DNS-namn och bör undvikas för WAF-domäner.
Backend kan använda ett annat internt namn om Host-headern och applikationen kan hantera det.
Vid problem med absoluta länkar kan Rewrite HTML bli relevant.

Om flera virtuella webbservrar körs på samma IP och port, avgör brandväggen vid HTTPS utifrån 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 välstrukturerat publiceringskoncept. Om flera applikationer körs under liknande värdnamn 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 avsiktligt icke-matchande subdomän är användbart: då ser man om den specifika regeln, en wildcard-regel eller ingen matchande virtuell webbserver svarar.

Certifikatobjektets namn får endast innehålla alfanumeriska tecken ur teckenuppsättningen US-ASCII; det är inte samma sak som DNS-namnet i certifikatet. Kontrollera de automatiskt införda posterna i Domains efter valet och redigera, komplettera eller ta bort dem vid behov. HTTPS gör lyssnaren tillgänglig via HTTPS, inte även via HTTP. Redirect HTTP omdirigerar separat åtkomst från port 80 till port 443; planera därför även dessa lyssnare och eventuella portkonflikter.

Vid ett subdomännamn som inte matchar behöver ingen grafisk blockeringssida visas. Dokumentationen visar exempelvis 403 vid åtkomst via en annan subdomän. Kontrollera därför HTTP-status och reverseproxy.log, inte bara hur webbläsarsidan ser ut.

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 brandväggens adress vara den som först syns.

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äkerhetsanalys
Hastighetsbegränsningar eller inloggningsskydd på applikationsnivå
Felsökning med koppling till användare eller käll-IP
SIEM- eller övervakningskorrelation
Forensisk analys efter en incident

Förtroendegränsen är viktig: en 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 får inte kunna ange 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-loggen 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 beteende för en omvänd proxy.

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 länder som inte behövs.
Blockera IP-adresser med okänt ursprungsland endast om risken att låsa ute sig själv har granskats.
Använd dessutom WAF-MFA eller förhandsautentisering för portaler.
Blockera kända skadliga källor via Threat Feeds.

För landsblockering och blockering av skadliga IP-adresser 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 själva WAF-regeln. Sedan SFOS 22 är Threat Feeds också mer relevanta för inkommande, vidarebefordrad trafik som WAF- och DNAT-publiceringar. Brandväggen kan jämföra 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, medan Threat Feeds och Active Threat Response kan blockera eller synliggöra ytterligare kända skadliga källor. Detta ersätter dock inte patchhantering, korrekt autentisering eller applikationshärdning.

I praktiken bör man kontrollera:

Är Active Threat Response ändamålsenligt konfigurerat i miljön?
Används relevanta Threat Feeds och granskas de 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 tillfälliga tillstånd i nödsituationer?
Är det klart vem som reagerar på träffar och om trafiken bara loggas eller blockeras aktivt?

Särskilt vid kundportaler, admin-gränssnitt eller partneråtkomst bör denna kontroll ske före Go-live. Om en feed senare blockerar produktionstrafik måste driftorganisationen veta var träffen syns och hur man gör en korrekt bedömning: 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.

SFOS 23: Anpassa worker-profilen medvetet

Under Web server > General settings > Worker customization beräknar brandväggen standardvärdena utifrån tillgängliga CPU- och RAM-resurser; de passar för de flesta installationer. Högre värden kan påverka WAF-prestanda och systemresurser negativt. Aktivera därför Use custom worker profile endast efter att behovet har verifierats och konsekvenserna bedömts. Dokumentera först de tidigare värdena och om profilen är beräknad eller anpassad, skapa en konfigurationsbackup och planera ett underhållsfönster samt rollback till exakt detta tidigare tillstånd. Denna anpassning ändrar inte Maximum sessions.

Start servers: Antal worker-processer som startas när webbservern startar.
Server limit: Maximalt antal worker-processer som kan köras samtidigt.
Minimum spare threads: Minsta antal inaktiva trådar som hålls tillgängliga för nya förfrågningar.
Maximum spare threads: Högsta antal inaktiva trådar innan överflödiga trådar tas bort.
Threads per child: Maximalt antal worker-trådar per worker-process.
Asynchronous request worker factor: Styr skalningen av worker-processer för asynkrona anslutningar och förfrågningar.

Vid formulärbaserad reverse proxy-autentisering begränsar det globala fältet Maximum sessions de samtidiga användarsessionerna i alla WAF-regler som använder denna autentiseringsmetod. Standardvärdet är 25,000 och det tillåtna intervallet är 100 till 100,000. När gränsen nås stänger brandväggen gamla eller utgångna sessioner för att släppa in nya. Värdet är alltså inte en kapacitet per regel; dimensionera det efter samtidiga inloggningar i de berörda applikationerna och kontrollera inloggning, utloggning och sessionsbyte efter en ändring.

För Slow HTTP protection anger Soft limit det initiala tidsfönstret för att ta emot request-headern. Hard limit sätter den absoluta övre gränsen. Extension rate bestämmer hur många ytterligare mottagna byte som förlänger soft limit med en sekund. Dessa tre värden bör testas tillsammans och med verkligt långsamma klienter; ett enda alltför generöst värde kan försvaga skyddet i onödan.

För Slow HTTP protection bör undantag begränsas till den minsta nödvändiga IP-adressen eller det minsta nödvändiga nätverket. Sophos stöder här IP- och nätverkshostobjekt, men inte IP-intervall eller hostlistor. Minimum TLS version gäller också globalt; innan den skärps måste äldre klienter och alla publicerade applikationer kontrolleras med ett verkligt externt test.

Som globala TLS-inställningar erbjuder SFOS bland annat TLS v1.2 (wide compatibility), TLS v1.2 (strict) och TLS v1.3. Custom protocol configuration och Custom cipher configuration bör endast ändras med dokumenterade, testade OpenSSL-värden; cipher suites för TLS 1.3 hanteras separat. Ogiltiga värden kan hindra den SFOS-hanterade Apache-tjänsten och därmed Web Server Protection från att starta. Tidigare värden, en konfigurationsbackup, ett underhållsfönster och alternativ administrativ åtkomst hör därför till ändringsplanen. Därefter måste alla WAF-publiceringar och reverseproxy.log kontrolleras; om tjänsten inte startar återställs de senaste anpassade värdena i stället för att fler varianter provas i produktion.

För skyddspolicyer är läget viktigt. Reject blockerar och skapar synliga händelser i Log Viewer 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 skydd i produktion bör det vara tydligt om attacker bara observeras eller faktiskt avvisas.

Common threat filter arbetar med fyra Filtering Strengths. Level 1 är mest tolerant och loggas inte; från Level 2 visas träffar i /log/reverseproxy.log, samtidigt som risken för falska positiva ökar. Enskilda regler undantas endast utifrån det Rule ID som har belagts i loggen under Skip filter rules. Att generellt stänga av en hel kategori eller en högre nivå är ingen bra ersättning för denna analys.

Static URL hardening är skiftlägeskänsligt, accepterar inga wildcards och hjälper inte för URL:er som skapas dynamiskt av JavaScript. Form hardening jämför formulärstrukturen och stöder formulär upp till 8,000 byte. Om binärt innehåll felaktigt levereras som HTML eller XML kan båda funktionerna skada innehållet; korrigera därför först backendens Content-Type i stället för att stänga av skyddet brett.

Vid antivirusskanning gäller en storleksgräns för den totala uppladdningsvolymen i en förfrågan, inte för varje enskild fil. Den extra Request size limit för HTTP-body sträcker sig från 1 till 1,024 MB och har standardvärdet 10 MB. HTTP Strict Transport Security lägger endast till HSTS-headern när WAF-regeln använder Redirect HTTP; MIME-type sniffing protection sätter X-Content-Type-Options: nosniff. Uppladdning, nedladdning och headers måste därför kontrolleras med den verkliga applikationen.

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

Skapa en Protection Policy och förstå skyddseffekten

Ange ett beskrivande namn under Web server > Protection policies > Add, exempelvis WAF_Portal_Protection, konfigurera de skyddsfunktioner som behövs och välj Save. Välj därefter policyn i fältet Protection i WAF-regeln; i SFOS 23 gäller den endast för Protect-sökvägar. En befintlig standardpolicy, exempelvis för Exchange Autodiscover, bör endast användas för det användningsfall den är avsedd för.

För en pilot med den egna applikationen ska man först göra ett tydligt val mellan Monitor och Reject. Monitor blockerar inte och visar inte de berörda WAF-meddelandena i Log Viewer; för detta behövs reverseproxy.log. Den bättre synligheten med Reject får inte förväxlas med att applikationskompatibiliteten redan har testats. Pass Outlook anywhere låter externa Outlook-klienter kringgå webbserverskyddet för Exchange-åtkomst. Alternativet är ingen allmän kompatibilitetslösning för moderna portaler och ska vara avstängt om det inte finns ett motiverat användningsfall med äldre teknik.

Cookie signing kompletterar en cookie som servern sätter med en andra cookie med ett hashvärde baserat på namn, värde och en hemlighet som endast brandväggen känner till. Om klienten inte skickar det matchande paret förkastas cookien. Detta skyddar mot manipulation, men ersätter varken säkra applikationssessioner eller korrekt cookie-konfiguration på backend. Testa inloggning, varukorg och andra cookie-beroende flöden efter aktivering.

Med Static URL hardening signerar brandväggen statiska länkar och bedömer utifrån serversvaret vilka efterföljande länkar som är tillåtna. Entry URLs definierar ingångs-URL:er som får vara tillgängliga utan hardening-signatur; för en enkel webbplats kan / vara ingången. Denna lista är ingen allmän routinglista. Var uppmärksam på stora och små bokstäver och ange inga wildcards. Applikationer med JavaScript-genererade URL:er eller legitima djuplänkar kräver en separat granskning. Form hardening signerar den ursprungliga formulärstrukturen och avvisar manipulerade formulär. Den befintliga gränsen på 8,000 byte och korrekt HTML-/XML-Content-Type är fortfarande avgörande.

Det dokumenterade enkla exemplet på attackskydd använder Reject, Static URL hardening med ingången /, Form hardening, Antivirus, Block clients with bad reputation och Common threat filter. Cookie signing, Pass Outlook anywhere och Skip remote lookups for clients with bad reputation är avstängda där. Detta är en testprofil för just det flödet, ingen universell rekommendation och inget belägg för att standardinställningarna passar varje applikation. För en modern portal ska varje sådant alternativ bedömas utifrån den verkliga applikationstrafiken. Inte heller Basic with passthrough, som nämns där, är en MFA-rekommendation; klientläge, vidarebefordran av inloggningsuppgifter och mallar förklaras i den länkade artikeln om WAF-autentisering och MFA.

Konfigurera antivirus och ryktesbedömning medvetet

För Antivirus avgör Mode om en eller två skanningsmotorer används; vid skanning med en enda motor ska motorn väljas. Direction anger uppladdning, nedladdning eller båda riktningarna. Block unscannable content blockerar exempelvis krypterade eller skadade filer som inte kan kontrolleras. Detta stärker genomdrivandet av skyddet men kan påverka legitima krypterade dokument; fastställ därför tillåtna verksamhetsflöden och supportväg i förväg.

Limit scan size begränsar den volym som ska skannas; 0 eller ett tomt fält innebär ingen storleksgräns för skanningen. Exempel: Med en skanningsgräns på 50 MB och filer på 45, 5 och 10 MB i en uppladdning skannas inte den sista filen. En lyckad uppladdning bevisar därför inte att varje ingående fil har kontrollerats. Denna skanningsgräns ska skiljas från Request size limit för hela HTTP-body: En högre body-gräns gör inte automatiskt att mer innehåll kan skannas. Välj gränser utifrån de uppladdningar som faktiskt behövs, resurser och säkerhetskrav, och kontrollera uppladdningar med flera filer samt innehåll som inte kan skannas i en godkänd testmiljö.

Block clients with bad reputation använder RBL- och GeoIP-information: Sophos SXL för RBL:er och MaxMind för GeoIP. Även blockeringar för klassificeringarna A1 (anonyma proxyservrar respektive VPN-tjänster) och A2 (satellit-ISP) är dokumenterade. Detta kan påverka legitim partneråtkomst. Skip remote lookups for clients with bad reputation kan förbättra prestandan, men förändrar bedömningen via fjärruppslagningar; aktivera inte alternativet obemärkt och likställ det inte med en tillåtelselista för källor.

Bedöm Common threat filter utifrån kategorier och styrka

Kategorierna besvarar olika frågor och ska väljas medvetet för applikationen:

Application attacks: Identifierar bland annat otillåtna sökvägsåtkomster och typiska försök att köra kommandon, även efter ett möjligt intrång.
SQL injection attacks: Kontrollerar förfrågningsargument för inbäddade SQL-kommandon och escape-tecken.
XSS attacks: Kontrollerar indata för inbäddade skripttaggar och kod.
Protocol enforcement: Kontrollerar protokollöverensstämmelse, typiska headers som Host och User-Agent, argumentgränser och tillåten HTTP-användning. En ovanlig legitim klient kan därför också ge utslag.
Scanner detection: Identifierar typiska bot-, crawler- och skanningsmönster; önskad åtkomst från sökmotorer eller övervakningssystem måste ändå testas.
Data leakage: Förhindrar att känslig information når klienten, exempelvis via serverfelmeddelanden. När Application attacks eller SQL injection attacks är aktivt bör även denna kategori granskas, eftersom detekteringsområdena överlappar varandra.

Filter strength har som standard Level 1 och ger minst antal falska positiva. Level 2 lägger exempelvis till reguljära uttryck för SQL-/XSS-injektion och ytterligare nyckelord för kodinjektion; Level 3 lägger till regler, nyckelordslistor och gränser för specialtecken; Level 4 begränsar specialtecken ännu mer och kräver särskilt grundliga tester av falska positiva före driftsättning. De tidigare beskrivna loggningsbegränsningarna gäller fortfarande: Level 1 loggas inte, medan Level 2 och högre visas i /log/reverseproxy.log. Betrakta inte en högre styrka som säker och godkänd enbart för att startsidan öppnas.

Kontrollera HSTS och MIME-skydd innan de aktiveras

Med HTTP Strict Transport Security och aktiverat Redirect HTTP lägger brandväggen till denna header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

31536000 motsvarar ett år. Detta påverkar inte bara den testade ingången: includeSubDomains omfattar subdomäner, och webbläsare kan lagra instruktionen. Före aktivering måste HTTPS, certifikat och alla berörda subdomäner fungera varaktigt; att senare avmarkera kryssrutan ger ingen omedelbar återställning av instruktioner som webbläsarna redan har lagrat. Enbart preload i headern bevisar inte att webbplatsen har tagits upp i en webbläsares preload-lista. MIME-type sniffing protection lägger till X-Content-Type-Options: nosniff; korrigera därför felaktiga MIME-typer på backend i stället för att generellt ta bort headern. Kontrollera båda headers på den externa klienten.

Skapa undantag som är så snäva som möjligt

Ange Paths, Sources, Operation och de specifika kontroller som ska hoppas över under Add new exception. Undantagssökvägar är skiftlägeskänsliga och tillåter wildcards, exempelvis /products/*/images/*. Detta skiljer dem från Entry URLs i Static URL Hardening Policy, där wildcards inte tillåts. För Operation är den booleska kopplingen avgörande: En sökväg och en källa tillsammans ger en snävare matchning än en sökväg eller en källa. Kontrollera den önskade skärningen innan du sparar, så att en partnerkälla inte av misstag undantas från skyddet för alla sökvägar.

För Sources i ett undantag är IP-adresser, intervall, listor och nätverk dokumenterade. Detta får inte överföras till andra fält: För Path-specific routing i SFOS 22 samt för Passthrough-fälten Allowed client networks och Blocked client networks i SFOS 23 är endast hosttyperna IP och Network dokumenterade, inte IP ranges eller IP lists. Använd enskilda IP- eller nätverksobjekt där för en förutsägbar åtkomstbegränsning.

Alternativen i ett undantag hoppar bland annat över Cookie signing, Static URL hardening, Form hardening, Antivirus, Block clients with bad reputation och valda Common-Threat-kategorier. Två alternativ kräver extra försiktighet:

Never change HTML during static URL hardening or form hardening förhindrar omskrivning av HTML-sidan, exempelvis när applikationen är beroende av oförändrade länkar. Detta innebär inte automatiskt att osignerade länkar accepteras; ett riktat hardening-undantag kan behövas för detta.
Accept unhardened form data accepterar formulärdata utan hardening-signatur. Ett Form hardening-undantag ensamt gör inte det. Denna ytterligare tillåtelse tar bort ännu en kontroll och är endast lämplig för ett exakt avgränsat och motiverat flöde.

Spara först den legitima förfrågan som misslyckas, tidpunkten och det belagda Rule ID:t. Upprepa därefter samma förfrågan och gör en kontroll med en källa respektive en sökväg som inte omfattas av undantaget. Undantaget är ändamålsenligt avgränsat först när det nödvändiga flödet fungerar och det övriga skyddet bevaras; vid tveksamhet ska ett enskilt belagt Rule ID undantas under Skip filter rules i stället för ett helt skyddsområde.

Validera migrerade Protection Policies på nytt

Sedan SFOS 18 använder Web Server Protection OWASP ModSecurity Core Rule Set 3.0. Vid migreringen av äldre Protection Policies slogs tidigare kategorier samman, regel-ID:n mappades om och Filtering Strengths infördes. Om en av de sammanslagna kategorierna tidigare var aktiv kan den nya gemensamma kategorin därför vara aktiv även om en annan del tidigare var avstängd.

Efter en sådan uppgradering räcker det inte att bara jämföra policyns namn. Aktiverade kategorier, undantag och Filtering Strengths måste kontrolleras mot den tidigare dokumentationen. Därefter följer kontrollerade positiva och negativa tester med verklig applikationstrafik samt kontroll av Log Viewer och reverseproxy.log. Först när legitima förfrågningar fortfarande fungerar och de förväntade testattackerna identifieras är den migrerade policyn godkänd.

För den äldre SFOS-18-migreringen är följande mappningar viktiga: Protocol violations, Protocol anomalies, Request limits och HTTP policy blev Protocol enforcement; Generic attacks och Tight security blev Application attacks; Bad robots blev Scanner detection; Outbound blev Data leakage. Rigid filtering migreras till Level 1 och måste medvetet bedömas på nytt. Kategorin Trojans togs bort; antivirus tar över motsvarande skydd. Redan undantagna regler som har mappats till ett nytt Rule ID förblir undantagna, medan ID:n som inte har mappats, som har tagits bort eller som har slagits samman till en ny regel tas bort från Skip-listan. Kopiera därför inte den gamla undantagslistan utan granskning, utan jämför den med den aktuella policyn och aktuella loggar.

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.

Brandväggen utvärderar inte sökvägar efter tabellordning, utan prioriterar längre och därmed mer specifika sökvägar före uppsamlingsrouten. Denna matchning måste testas riktat. Endast för SFOS 22: För den webbplatssökväg som behövs kan kryssrutan WebSocket passthrough aktiveras; WebSocket-trafik vidarebefordras då utan WAF-skydd, eftersom WebSocket-data inte kan granskas som vanlig HTTP-trafik. För SFOS 23: Konfigurera endast den WebSocket-sökväg som behövs under Traffic routing med Action > Passthrough och avsedd backend. Denna tunnel arbetar utan WAF-granskning och utan skyddspolicy; övriga applikationssökvägar behåller Protect. Ställ aldrig om hela portalen till Passthrough som workaround. Testa anslutningsuppgradering, dataöverföring och återanslutning separat. Detta ger inget underlag för slutsatser om MFA upprätthålls vid Passthrough; om autentisering krävs, klargör ansvaret med den autentiseringsansvariga.

Endast för SFOS 22: Vid förfarandet med Protected servers vidarebefordrar standardsökvägen / förfrågningar utan mer specifik matchning till den tilldelade standardservern. Om denna standardroute tas bort avvisar brandväggen sådana förfrågningar med 404 Not Found. För SFOS 23: Förfrågningar utan mer specifik matchning använder åtgärden för /; i nya regler är den som standard Block. Behåll denna uppsamlingsroute medvetet om endast enskilda sökvägar ska publiceras. Protect för / är endast lämpligt om hela applikationen avsiktligt ska publiceras och kräver en kontroll av vad som därmed blir ytterligare tillgängligt. För SFOS 23 garanteras ingen fast 404-status: Svaret från Block konfigureras via Response code.

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.

Utan ytterligare bindning fördelas förfrågningarna mellan de valda webbservrarna när flera har valts. Sticky session cookie binder webbläsaren till en backend-server; om den servern slutar fungera uppdateras cookien och sessionen flyttas till en annan server. Detta garanterar inte att applikationens tillstånd överförs: En varukorg kan exempelvis behöva en gemensam sessionslagring.

Hot-standby mode skickar först alla förfrågningar till den första valda servern och använder de övriga som reservservrar. När huvudservern åter är tillgänglig flyttas sessionerna normalt tillbaka; med Sticky session cookie aktiverat stannar den befintliga sessionen på reservservern. Genomför därför separata acceptanstester för primärservern, reservservrarnas ordning, avbrott, återgång och ett inloggnings- eller varukorgsflöde som faktiskt bevarar tillstånd.

Fältet Authentication finns även med i SFOS 23-tabellen för Passthrough, medan funktionsöversikten kopplar autentisering till Protect. Denna motsägelse i dokumentationen ska inte lösas genom antaganden. Om WAF-MFA krävs ska den skyddade delen bygga på Protect och en uttrycklig policy; avgränsningen och testerna beskrivs i WAF-autentisering med MFA.

Nå fjärranslutna WAF-backends via SD-WAN

Om den skyddade webbservern inte finns i brandväggens lokala nät bör routing och SD-WAN kontrolleras särskilt noggrant. För backends via platsförbindelser, MPLS eller route-based IPsec kan en passande SD-WAN Route behövas så att brandväggen 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 det dokumenterade alternativet.

Designen som Sophos dokumenterar börjar med en fungerande WAF-regel och en nåbar route-based tunnel. Under Routing > Gateways skapas ett gateway-objekt för fjärrvägen med peer-enhetens IP-adress, det adresserade XFRM-gränssnittet och en tillförlitlig övervakningshost bakom peer-enheten. Först därefter skapas den riktade vägen för WAF-proxytrafik under Routing > SD-WAN routes:

Skapa och spara gatewayen under Routing > Gateways > IPv4 gateway > Add. I exemplet heter den gw6 och använder Gateway IP 10.12.13.2 och Interface xfrm1-10.12.13.1. Använd en host bakom gatewayen som svarar tillförlitligt under Monitoring condition; det dokumenterade exemplet använder 10.12.13.2. Ersätt dessa privata adresser och gränssnittet med den faktiska tunneladresseringen och en lämplig övervakningshost.
Välj IPv4 och Add under Routing > SD-WAN routes, exempelvis med namnet SD-WAN_WAF_Portal. Ta bort Any från Destination networks och välj det offentliga WAN-gränssnitt eller den Hosted address genom vilken klienten når WAF-regeln; i exemplet #Port1. För denna dokumenterade WAF-route är det alltså inte bara den privata backend-IP-adressen som ska anges.
Ta bort Any från Services och välj WAF-regelns externa Listening Port, i exemplet TCP 8080. Om den skiljer sig från den interna backendporten ska den externa porten uttryckligen användas här. Den port som avviker från standardporten måste även beaktas vid det externa testanropet.
Välj Primary and Backup gateways under Link selection settings och ange den tidigare skapade XFRM-gatewayen gw6 i Primary gateway. Spara routen. Om flera publiceringar använder samma gateway kan samma SD-WAN Route innehålla flera offentliga WAN-adresser och Listening Ports. Olika gateways kräver separata routes.

SD-WAN-förfarandet hänvisar till en instruktion för route-based VPN med Traffic Selectors; WAF-regelreferensen utesluter dock uttryckligen subnätsbaserade Traffic Selectors. Planera därför en Any-to-Any-anslutning för detta WAF-användningsfall och tolka inte den hänvisade instruktionens rubrik som ett klartecken för konfigurationer med subnätsselektorer.

Acceptanstesterna skiljer sedan på lagren: Det externa anropet måste träffa den förväntade WAF-regeln; korrelera WAF-regel, reverse proxy-fel och tidpunkt i Log Viewer; XFRM-gränssnitt, gatewayövervakning och SD-WAN Route måste vara aktiva på brandväggen; och backendservern måste ta emot förfrågan och svara via den avsedda vägen. En grön tunnel bevisar varken SD-WAN-matchning eller att backendservern går att nå.

Drift och felsökning

I drift är det viktigt att publiceringen förblir spårbar: vilken regel som matchar, vilka loggar som är relevanta, vilka undantag som finns och hur man går till väga vid störningar.

Vanliga fel

Offentligt DNS-namn pekar på fel IP: WAF-regeln nås aldrig.
Certifikatet matchar inte värdnamnet: Webbläsare visar certifikatsfel eller SNI-matchningen stämmer inte.
Fel Hosted address vald: Brandväggen matchar en annan regel eller ingen WAF-trafik.
Allowed client networks tomt: Regeln fungerar inte som förväntat.
WAF-regelgränsen har inte beaktats: Ytterligare publiceringar kan inte längre hanteras på ett tydligt och korrekt sätt.
Exchange-version efter 2013 planerad med WAF-mall: Mallen passar inte inom den stödda WAF-gränsen.
Portkonflikt med User Portal, VPN Portal eller annan tjänst: Applikationen är inte tillgänglig eller en brandväggstjä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 nås via 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 via denna väg stöds inte.
WAF-undantaget är för brett: Skyddseffekten minskar onödigt.
WebDAV-applikation publicerad via WAF: Applikationen fungerar inte tillförlitligt eller stöds inte.
URL-sökvägen innehåller %2F: WAF svarar med 404 Not Found, trots att resursen är direkt tillgänglig på backendservern. %2F är den URL-kodade formen av ett snedstreck / och måste skiljas från ett vanligt 404-fel från backendservern.
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:

Pekar det offentliga DNS-namnet på rätt offentlig IP?
Är rätt Hosted address vald i WAF-regeln?
Är lyssningsporten ledig och inte upptagen av WebAdmin, User Portal, VPN Portal eller en annan publicering?
Matchar certifikatet det anropade värdnamnet?
Är den interna webbservern tillgänglig från brandväggen?
Är Allowed client networks, Blocked client networks och Blocked countries korrekt inställda?
Nås Protected Server via en route, SD-WAN Route eller VPN-förbindelse som verkligen passar ur brandväggens perspektiv?
Finns det en mer generell WAF-regel som matchar tidigare?
Visas åtkomsten i Log Viewer som tillåten, blockerad eller bortkastad?
Finns det ledtrådar i /log/reverseproxy.log?
Är Protection Policy satt till Monitor eller Reject?
Passar timeouten för webbserverobjektet 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.

WAF svarar med 404 när sökvägen innehåller `%2F`

Ett särskilt fel uppstår med URL:er som innehåller ett kodat snedstreck. Ett anrop som https://portal.example.com/api/files/project%2Freport.pdf kan via Sophos WAF returnera 404 Not Found, trots att resursen finns vid direkt åtkomst till backendservern. Sophos spårar detta beteende under NC-159041 och anger för närvarande varken en viss berörd eller korrigerad SFOS-version eller en stödd workaround.

För att avgränsa orsaken bör samma anrop jämföras under kontrollerade former via WAF och direkt mot backendservern. Den exakta URL:en och testtidpunkten är viktiga:

Kontrollera om sökvägen faktiskt innehåller %2F. Ett vanligt snedstreck / eller en saknad standardsökväg är ett annat fel.
Jämför tidpunkten i Log Viewer, /log/reverseproxy.log och webbserverns accesslogg.
Om ingen motsvarande post visas på backendservern avvisades anropet sannolikt före webbservern. Med ett direkt backendtest kan man samtidigt utesluta att själva resursen saknas.

Ett brett WAF-undantag löser inte detta problem specifikt och skulle i onödan försvaga skyddet. Den Apache-konfiguration som hanteras av SFOS bör inte heller ändras: Den restriktiva hanteringen av kodade snedstreck hjälper till att förhindra att sökvägs- eller åtkomstkontroller kringgås.

Den renaste lösningen är att applikationen eller leverantören genererar URL:er utan kodade snedstreck. Om det inte är möjligt måste en annan publiceringsmetod, till exempel DNAT, en lämplig omvänd proxy eller privat åtkomst, medvetet vägas mot att WAF-skyddet försvinner. För applikationer som inte kan ändras bör Sophos Support kontrollera den specifika SFOS-builden och användningsfallet. Former som project%2Freport.pdf och project/report.pdf är endast ett diagnostiskt mönster och är inte automatiskt funktionellt likvärdiga.

Checklista för produktiva WAF-regler

Regelnamnet 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.
Skyddsprofilen är inte onödigt inaktiverad.
Undantag är snäva, motiverade och tidsbegränsade.
Ändringen har testats externt.
Utgångsdatum eller granskningstidpunkt är dokumenterad.

Klassificera WAF-objekt via XML API

För automatisering hör publicering, backend och skyddspolicy ihop, men de förblir separata objekt. FirewallRule med PolicyType HTTPBased innehåller HTTPBasedPolicy; RealServers beskriver backend-webbservern och ProtocolSecurity skyddspolicyn. WAF-regeln refererar till dessa objekt, den ersätter inte deras konfiguration. Åtkomst, TLS-verifiering, hemligheter, explicita skrivoperationer och tolkning av XML-status förklaras i Begränsa åtkomsten till XML API säkert.

Följande mappningar förklarar referenserna för SFOS 22/23, men är inte körbara mallar för förfrågningar. Före varje skrivning ska API help för den installerade builden jämföras med det befintliga objektet, en säkerhetskopia och en återställningsväg förberedas och en ofarlig läsfråga kontrolleras först. Skriv inte om syntax, enhet eller åtgärdsmappning är oklar, utan låt supporten reda ut detta. Det gäller särskilt efter ett versionsbyte.

Blanda inte ihop publicering och åtkomstvägar

Name identifierar FirewallRule; referensen tillåter högst 60 tecken, inga kommatecken och UTF-8. Position är obligatoriskt och anger Bottom, Top, After eller Before; för de två sista varianterna måste även den namngivna referensregeln anges. För Status anger tabellen standardvärdet ON och skrivvärdena Disable och Enable: att utelämna fältet är inte ett säkert sätt att förbereda en inaktiverad publicering. Enligt tabellen är standardvärdet för LogTraffic Disable; kontrollera loggningen uttryckligen. IPFamily erbjuder även IPv6 i det gemensamma FirewallRule-kontraktet, men HTTPBasedPolicy är uttryckligen begränsat till IPv4. Nätverks- och användarregler behandlas under Brandväggsregler och ska inte tas över som WAF-payload.

I WAF-delen motsvarar HostedAddress, ListenPort, HTTPS, HTTPSCertificate och Domains/Domain den publika lyssnaren. Tabellen anger HostedAddress, ListenPort, HTTPS och Domains som obligatoriska fält. ListenPort är ett heltal från 1 till 65535; dokumenterade värden är 80 när HTTPS är avstängt och 443 när HTTPS är aktiverat. Detta är inte backend-porten. RedirectHTTP är den separata HTTP-omdirigeringen. Kontrollera det publika namnet, certifikatet och lyssnaren tillsammans efter varje ändring.

Sökvägsmappningar finns under HTTPBasedPolicy/AccessPaths/AccessPath. Där refererar backend till webbserverobjekten; allowed_networks, denied_networks, blocked_countries och block_unknown_country beskriver klientåtkomsten. stickysession_status och hot_standby hör till sessionsbindningen och valet av backend. En refererad autentiseringspolicy förklaras i artikeln om WAF-autentisering; ett fält som finns garanterar inte MFA-tillämpning för varje åtgärd.

Versionsskillnad: Tabellen för SFOS 22 beskriver path som en enskild sträng och backend som en obligatorisk array. I SFOS 23 är path en array med flera värden, medan backend anges som valfritt. Enligt tabellen är sökvägsvärdena begränsade till 63 tecken och får inte innehålla kommatecken. Valfritt betyder här inte att en Protect- eller Passthrough-sökväg kan publiceras på ett meningsfullt sätt utan tilldelad backend: det aktuella användargränssnittet kräver val av backend för dessa åtgärder, medan Block och Redirect inte publicerar någon backend.

SFOS 23 lägger till action med liten begynnelsebokstav och de tillåtna värdena 0, 1, 2, 3, samt response_code, redirect_protocol, redirect_host, redirect_port och redirect_path. Referensen kopplar inte de fyra talen till åtgärderna i användargränssnittet. Skapa ingen mappning utifrån ordningsföljd eller antaganden; en bekräftad mappning för den installerade builden är en förutsättning för varje automatiserad ändring. Action med stor begynnelsebokstav och värdena Accept, Drop, Reject finns i exemplet under UserPolicy respektive NetworkPolicy, inte i WAF-blocket. Det ersätter varken den yttre WAF-åtgärden i användargränssnittet eller AccessPath/action. För redirect_protocol anger tabellen ordagrant http och https, för redirect_port 1 till 65535 och för redirect_path högst 8192 tecken. response_code beskrivs där endast som ett heltal; valet i användargränssnittet ovan är fortsatt avgörande för den konkreta konfigurationen.

Inte heller exemplet bevisar schemat: det blandar path och Path, innehåller tomma referenser och platshållare och visar inte HTTPSCertificate och LogTraffic fullständigt i WAF-blocket. SFOS 22 visar fortfarande websocket_passthrough; SFOS 23 använder åtgärdsmodellen. Bekräfta därför stavning, nästling, nödvändiga fält och loggning i det build-specifika kontraktet i stället för att mekaniskt komplettera exemplet. ProtocolSecurity i WAF-blocket refererar till skyddspolicyn. De avancerade inställningarna PassHostHeader, RewriteHTML, RewriteCookies och CompressionSupport hör till de reverse proxy-anpassningar som förklaras ovan; jämka inte ihop motstridiga exempel- och tabellvärden till egna enum-värden.

Exemplet visar dessutom SourceNetworks/Network och ExceptionNetworks/Network, medan dess kommentar alternativt anger Authentication, AllowFrom, BlockFrom eller AccessPaths. Dra inga slutsatser om likvärdiga alias, tillåtna kombinationer eller prioritetsregler utifrån detta. För befintliga objekt med denna åtkomstrepresentation ska strukturen och effekten klarläggas i den installerade builden; om de förblir oklara ska ingen automatiserad skrivning göras.

För undantag finns ett separat block, Exceptions/Exception. Där kopplar path, source och op samman villkoren; tabellen anger ordagrant and, or, AND, OR för op. skipcookie, skipurl, skipform, skipav och skipbadclients hoppar över respektive kontroll. Däremot förhindrar skiphtmlrewrite att matchande innehåll ändras, och skipform_missingtoken tillåter formulärdata utan härdningssignatur utöver formulärundantaget. Den motsvarande tabellraden har förväxlat beskrivning och standardvärde; härled inget tillförlitligt standardvärde från den. De säkerhetskonsekvenser för båda alternativen som beskrivs ovan är fortsatt avgörande. skip_threats_filter_categories använder andra token än skyddspolicyn, exempelvis application_attacks och data_leakages. Blanda inte ihop dessa undantagstoken med policyns visningsnamn. Den föråldrade beskrivningstexten om tidigare kategorier är inte heller ett godkännande av gamla token. Efter en ändring ska tillåten sökväg, blockerad sökväg, uppsamlingsrutt och en förfrågan som inte omfattas av undantag kontrolleras separat.

Tabellen beskriver path för Site-Path-rutter; undantagsexemplet visar däremot flera path-element inom en Exception, utan ett entydigt eget tabellkontrakt. Överför därför inte routingvägarnas kardinalitet och gränser till undantag. Bekräfta struktur, antal och tillåtna värden i den installerade versionen före automatiserade ändringar av undantag; skriv inte om kontraktet är oklart.

Kontrollera backend-kontrakt och timeout säkert

För RealServers är Name, Host, Port och TimeOut dokumenterade som obligatoriska fält. Name tillåter högst 60 UTF-8-tecken utan kommatecken. Host är referensen till ett IP- eller FQDN-värdobjekt, inte ett fritt utbytbart publikt WAF-namn. Port går från 1 till 65535, med API-standardvärdet 80; Type anger ordagrant Plaintext (HTTP) eller Encrypted (HTTPS). För en HTTPS-backend ska därför den faktiska lyssnaren och porten uttryckligen kontrolleras i stället för att API-portens standardvärde används.

API:et beskriver TimeOut med standardvärdet 300, intervallet 1 till 65535 och anmärkningen att det endast gäller när Keep alive är aktiverat. GUI:t förklarar däremot Timeout som väntetiden på data till eller från backend och anger ett HTTP-502 när tiden löper ut. Detta är olika beskrivningar, inte ett bevis på identiskt beteende när Keep-alive är avstängt. För UI-konfigurationer ska testet med pauser i dataöverföringen som beskrivs ovan användas; före automatisering ska beroendet och det sparade värdet klarläggas i den installerade builden. Dra inte slutsatsen att timeout ska höjas globalt.

För KeepAlive visar exemplet Enable/Disable, men tabellen endast 0 och Enable samt standardvärdet ON. Rätta inte tyst denna avvikelse med ett antaget Disable. DisableReuse anger Disable och Enable och motsvarar Disable backend connection pooling. Spara det tidigare tillståndet, läs tillbaka det ändrade objektet och kontrollera först därefter representativ dataöverföring och backend-loggar. Ett API-svar i sig bevisar varken att backend är nåbar eller att anslutningsinställningarna är lämpliga.

Skyddspolicy och beroende alternativ

Enligt tabellen kräver ProtocolSecurity Name, Mode och RequestSizeLimit. För Name gäller högst 60 UTF-8-tecken utan kommatecken; Mode anger Monitor och Reject. Inställningarna CookieSigning, StaticUrlHardening och FormHardening motsvarar cookie-, URL- och formulärskyddet ovan. Enligt tabellen är standardvärdet för PassOutlookAnywhere OFF: API:et beskriver Exchange-åtkomsten endast kortfattat, medan GUI:t uttryckligen anger att Web Server Protection kringgås. Låt det därför vara avstängt om det inte finns ett motiverat användningsfall för en äldre lösning, och behandla det inte som en vanlig kompatibilitetsinställning. När StaticUrlHardening är aktiverat beskriver referensen EntryURLType med Manual, SitemapFile, SitemapURL; för det manuella fallet visar exemplet EntryURLList/EntryURL, med flera ingångs-URL:er på högst 255 tecken vardera. Dra inte slutsatsen att GUI:t erbjuder alla API-varianter på identiskt sätt.

API-tabellen anger CookieSigning, StaticUrlHardening, FormHardening, AntiVirus, BlockClientsWithBadReputation och ThreatsFilter med Default OFF för vart och ett, och ParanoiaLevel med Default 1. En ny eller refererad Policy innebär därför inte i sig att skyddskontroller är aktiverade. Vid skapande ska de avsedda inställningarna anges uttryckligen och läsas tillbaka. Vid Edit utan ett bekräftat uppdateringskontrakt ska varken bevarande av utelämnade fält eller återställning till Defaults förutsättas.

När AntiVirus är aktiverat blir AVMode (Avira, Sophos, DualScan), Direction (Uploads, Downloads, UploadsAndDownloads), BlockUnscannableContent och LimitScanSize relevanta. Heltalet Megabytes är dessutom beroende av att LimitScanSize är aktiverat. Detta är fortsatt separat från gränsen för meddelandekroppens storlek. SkipRemoteLookups är beroende av BlockClientsWithBadReputation; härled inte rykteskontrollens effekt enbart från den kortfattade API-beskrivningen.

ThreatsFilter aktiverar Common threat filter. Till detta hör ThreatFilters/Filter, ParanoiaLevel med 1 till 4 och SkipFilterRules/FilterRules som en lista över regel-ID:n i heltalsform. De tillåtna filtertokenen är ordagrant Application attacks, SQL injection attacks, XSS attacks, Protocol enforcement, Scanner detection, Data leakages. Det sista tokenet skiljer sig från GUI-namnet Data leakage. Gör endast riktade undantag för belagda falsklarm och kontrollera därefter det återstående skyddet; nivå, kategori och undantag är separata beslut.

RequestSizeLimit förblir en källkonflikt: API-tabellen anger att fältet är obligatoriskt, standardvärdet 10, beskrivningen ”Megabytes” och ett heltalsintervall från 1 till 1073741824. Det aktuella GUI:t dokumenterar däremot 1 till 1024 MB, med standardvärdet 10 MB. I API-exemplet saknas RequestSizeLimit helt. Härled varken en byte-/MB-omräkning, ett utökat gränsvärde för produktionsdrift eller att fältet säkert kan utelämnas från detta. Använd det dokumenterade MB-intervallet för GUI:t; använd ett API-skrivvärde först efter att enhet, intervall och det obligatoriska fältets beteende har bekräftats i den installerade builden. Detsamma gäller tabellbeteckningen HSTS Enforcement, som saknas i exemplet: hitta inte på en XML-tagg utifrån namnet. XContentTypeOptions beskriver MIME-skyddet; kontrollera den sparade policykopplingen och de faktiska headerfälten externt.

Skilj XML-svar åt efter operation

Följande tal är XML-objektstatusar, inte HTTP-statuskoder. Message.* betecknar här ett oupplöst symbolnamn från referensen, inte ett översatt felmeddelande och inte ett bevis på en exakt orsak. Kontrollera svar, operation och sparat objekttillstånd tillsammans; skriv aldrig på nytt i blindo vid fel, varningar eller en möjlig partiell ändring. Den centrala API-säkerhetsanvisningen förklarar den säkra kontroll- och eskaleringsprocessen.

För WAF-relevanta svar från FirewallRule är särskilt följande skillnader viktiga:

Add firewall rule: 200 → Message.FWRuleAddSuccess, 500 → Message.FWRuleAddFail, 502 → Message.FWRuleRecordExists. Edit firewall rule: 200 → Message.FWRuleEditSuccess, 202 → Message.FirewallRuleUpdateWithRename, 500 → Message.FWRuleEditFail, 502 → Message.FWRuleUpdateRecordExist. Vid 202 ska även objektnamn och referenser läsas tillbaka, inte bara det gamla namnet användas igen.
Add firewall rule 541 → Message.VHIPRangeConflict. Edit firewall rule 541 har däremot Message.FWRuleFailMaxUser; samma kod får inte leda till samma diagnos.
Add firewall rule 543 och Edit firewall rule 544 → Message.CannotSetupRedirectionFromHTTP. Add firewall rule 544 och Edit firewall rule 543 → Message.CannotUseDefaultPort. Mappningen är omkastad mellan Add och Edit: kontrollera lyssnare, port och omdirigering, och klassificera inte enbart utifrån talet.
Vid Add firewall rule och Edit firewall rule: 542 → Message.CannotUseTypeHTTP, 545 → Message.PortAlreadyExists, 546 → Message.CannotConfigureDomainWithAddrTypePort, 550 → Message.PortUsedInUserPortal, 553 → Message.CannotConfigureDomainWithHTTPSRedirection. Stäm av den befintliga lyssnar-/domänkonfigurationen; ändra inte portöppningar på chans.
Vid båda operationerna: 547 → Message.warn_update_business_policy; 548 och 549 använder båda Message.MaxIPv4ForAppServerAllowed. Den dubbla symbolmappningen belägger inte olika påhittade gränser. Kontrollera varningen och det WAF-tillstånd som faktiskt har sparats.
Add firewall rule 554 → Message.CannotUseFQDNWildCardAsProtectedServer; Edit firewall rule 554 → Message.CannotUpdateFQDNWildCardAsProtectedServer. Blanda inte ihop publika wildcard-domäner med en lämplig backend-värd. Edit firewall rule 552 → Message.CannotImportDiffPolicytypeWithSameName: kontrollera namn och policytyp, skriv inte över ett annat objekt.
Vid Add, Edit och Delete firewall rule: 596 → Message.CMLOCALOperationrestriction. För Delete finns dessutom 200 → Message.FWDelSuccess och 500 → Message.FWRuleDeleteFail. Klarlägg förvaltningsansvar och referenser före ett nytt försök. Delete-sidan anger Name som valfritt och använder en olämplig beskrivningstext om Before/After; detta är ingen säker raderingsmall. Bekräfta det exakta målobjektet och det build-specifika Remove-kontraktet, annars ska ingen radering göras.

Även backend och skyddspolicy har egna svarsserier: Add Web Server 200/500/502 står för Message.RealServerAddSuccess/Message.RealServerAddFail/Message.RealServerRecodExist; Update Web Server 200/500 för Message.RealServerUpdateSuccess/Message.RealServerUpdateFail. Add Protection Policy 200/500/502 står för Message.ProtocolSecurityAddSuccess/Message.ProtocolSecurityAddFail/Message.ProtocolSecurityRecodExist; Edit Protection Policy 200/500 för Message.ProtocolSecurityUpdateSuccess/Message.ProtocolSecurityUpdateFail. Stavningarna RecodExist är ordagrant bevarade, inte korrigerade symbolnamn. Läs först det befintliga objektet vid namnkollisioner; att radera och skapa på nytt är ingen säker standardmetod för återförsök.

För det globala objektet WAFSlowHTTP motsvarar RequestHeaderTimeoutEnabled, RequestHeaderTimeoutSoftLimit, RequestHeaderTimeoutHardLimit och RequestHeaderTimeoutExtensionRate inställningen och de tre gränser som förklaras ovan. Alla fyra är dokumenterade som obligatoriska fält; inställningen anger Disable och Enable, medan övriga värden är heltal utan angivet intervall. NetworkExceptions/Host är en valfri lista över värdreferenser. Exempelvärdena 10, 30, 5000 är inte belagda standardvärden. SlowHTTP Protection anger 200 med Operation Successful. och 500 med Operation Fail.. Ändringar är fortsatt globala: kontrollera sparade värden och snävt avgränsade undantag och genomför acceptanstester av alla berörda publiceringar med långsamma legitima klienter.

Vanliga frågor

Ersätter WAF patchning av webbservern?

Nej. WAF kan upptäcka eller blockera attacker, men kan inte permanent kompensera för en osäker applikation. Operativsystem, webbserver, ramverk, plugins och applikationskod måste fortfarande underhållas.

Behöver man dessutom DNAT?

För samma webbpublicering normalt inte. WAF-regeln hanterar publiceringen via Hosted address och vidarebefordrar till den skyddade webbservern. DNAT förblir relevant för andra protokoll eller webbapplikationer som inte stöds.

Varför ser webbservern inte den verkliga klient-IP:n?

Brandväggen fungerar som en omvänd proxy. Webbservern ser därför ofta brandväggen som källadress. Den ursprungliga klient-IP:n finns i headern X-Forwarded-For, förutsatt att applikationen eller webbservern utvärderar denna header.

Kan man publicera flera webbplatser över samma offentliga IP?

Ja, vid HTTPS använder brandväggen SNI och värdnamnet för att välja rätt WAF-regel eller rätt virtuella webbserver. DNS, certifikat och domäner i WAF-regeln måste matcha noggrant för detta.

Bör man använda WAF för Nextcloud?

Inte utan noggrann granskning. WebDAV är dokumenterat som ett WAF-fall som inte stöds. Eftersom Nextcloud använder WebDAV intensivt är en publicering via WAF i många miljöer inte lämplig.

Skyddar Threat Feeds även WAF-regler?

Under SFOS 22 kan Threat Feeds också vara relevanta för inkommande, vidarebefordrad trafik som WAF- och DNAT-publiceringar. För att detta ska ge ett verkligt skydd måste feeds, loggning, larm, ansvar och processen för falska positiva dock hanteras korrekt.