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.

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.

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.

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:

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.

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.

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:

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

Grundstruktur för en WAF-regel

En WAF-publicering består av flera komponenter:

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

Skapa WAF-regel

Menypath är:

Rules and policies > Firewall rules

Förfarande:

1. Välj IPv4.
2. Öppna Add firewall rule.
3. Välj New firewall rule.
4. Ge ett beskrivande regelnamn.
5. Välj alternativet Protect with web server protection under Action.
6. Om ingen speciell mall behövs, lämna Preconfigured template på None.
7. Under Hosted server details definiera den offentliga adressen, lyssningsporten, HTTPS, certifikat och domäner.
8. Under Protected servers välj eller skapa den interna webbservern.
9. Sätt medvetet Allowed client networks. För offentliga webbplatser kan Any IPv4 behövas, för portaler är en begränsning oftast bättre.
10. Vid behov sätt Blocked client networks eller Blocked countries.
11. Kontrollera skyddsprofil, IPS och avancerade alternativ.
12. Spara regeln och testa externt.

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

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.

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.

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.
• Vid flera värdnamn på samma IP använder brandväggen SNI.
• Wildcard-certifikat är möjliga men bör dokumenteras noggrant.
• 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.

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

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

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

Sökvägsspecifik routing, WebSocket och lastbalansering

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

Exempel:

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

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

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.

Vanliga fel

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. Finns det en mer allmän WAF-regel som matchar tidigare?
8. Visas åtkomsten i Log Viewer som tillåten, blockerad eller bortkastad?
9. Finns det ledtrådar i /log/reverseproxy.log?

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

Checklista för produktiva WAF-regler

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

Vanliga frågor