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.

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 utgångsläget.

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.

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 skyddspolicyer som faktiskt behövs med den aktuella Microsoft-arkitekturen; lämna Preconfigured template på None vid tveksamhet för en modern applikation.

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

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

Förfarande:

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.

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. Under Hosted server details definiera den offentliga adressen, lyssningsporten, HTTPS, certifikat och domäner.
9. Under Protected servers välj rätt web server-objekt eller skapa det först under Web server > Web servers.
10. 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.
11. Ställ vid behov in Blocked client networks eller Blocked countries.
12. Granska medvetet Protection, Intrusion prevention och Traffic shaping under de avancerade policyerna.
13. Spara regeln och testa externt.

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

1. 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.
2. 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.
3. Tilldela den avsedda Authentication Policy 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.
4. 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.
5. 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.
6. 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.

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 godkänningstester; den automatiska migreringen ersätter inte ett godkännande.

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

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.

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 firewallen gamla eller utgångna sessioner för att släppa in nya. Det är alltså inte kapacitet per regel: dimensionera värdet efter samtidiga inloggningar i de berörda applikationerna och verifiera inloggning, utloggning och sessionsbyte efter en ändring.

För Slow HTTP protection anger Soft limit den initiala timeouten 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. Testa dessa tre värden 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 ska 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 är också global; innan den skärps ska äldre klienter och alla publicerade applikationer testas via en verklig extern anslutning.

Som globala TLS-inställningar erbjuder SFOS bland annat TLS v1.2 (wide compatibility), TLS v1.2 (strict) och TLS v1.3. Ändra Custom protocol configuration och Custom cipher configuration endast med dokumenterade och 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. Ändringsplanen måste därför innehålla tidigare värden, en konfigurationsbackup, ett underhållsfönster och alternativ administrativ åtkomst. Därefter ska alla WAF-publiceringar testas 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 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.

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 false positives ökar. Hoppa endast över enskilda regler utifrån det Rule ID som har belagts i loggen under Skip filter rules. Att stänga av en hel kategori eller en högre nivå generellt ersätter inte 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 upload-volymen i ett request, 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. Testa därför uploads, downloads och headers 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 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.

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, Rule IDs 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. Kontrollera aktiva kategorier, undantag och Filtering Strengths mot den tidigare dokumentationen. Kör därefter kontrollerade positiva och negativa tester med verklig applikationstrafik och kontrollera Log Viewer och reverseproxy.log. Den migrerade policyn är godkänd först när legitima requests fortfarande fungerar och de förväntade testattackerna identifieras.

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.

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

Om den skyddade webbservern inte finns i firewallens 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 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 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:

1. Destination networks motsvarar det publika WAN-gränssnitt eller den Hosted address genom vilken klienten når WAF-regeln.
2. Services innehåller WAF-regelns externa Listening Port. Om den skiljer sig från den interna backendporten ska den externa porten uttryckligen användas här.
3. Under Primary gateway väljs den tidigare skapade XFRM-gatewayen.
4. Om flera publiceringar använder samma gateway kan samma SD-WAN Route innehålla flera publika WAN-adresser och Listening Ports. Olika gateways kräver separata vägar.

Verifieringen skiljer sedan på lagren: det externa testet 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å firewallen; och backendservern måste ta emot begäran 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

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

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.

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 via WAF och direkt mot backendservern. Den exakta URL:en och testtidpunkten är viktiga:

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

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

• 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