Säkra Sophos Firewall WAF med MFA

Med Sophos Firewall WAF MFA kan man ytterligare säkra webbapplikationer som publiceras via Web Application Firewall med Multi-Factor Authentication. Detta är särskilt användbart för interna portaler, administrationsgränssnitt, kundområden eller partneråtkomster som måste vara tillgängliga via HTTPS men inte bara ska skyddas av själva applikationen.

WAF-MFA ersätter inte en säker applikation, patchhantering eller ett rent behörighetskoncept. Det är ett förskjutet skyddslager på brandväggen. Brandväggen kontrollerar först inloggningen och den andra faktorn innan åtkomst till den skyddade webbservern vidarebefordras.

Versionen är viktig: integrerad MFA för WAF är en SFOS 22-funktion. På äldre firmwareversioner måste WAF-publiceringar planeras med andra arkitekturer, till exempel extern autentisering, dedikerad reverse proxy, VPN eller ZTNA.

För grundläggande publicering av en webbserver via WAF, följ först instruktionerna i Sophos Firewall WAF: Säkert publicera webbserver. Denna artikel fokuserar på förskjuten autentisering och MFA.

Användning och planering

När WAF-MFA är lämpligt

WAF-MFA är särskilt starkt när en webbapplikation måste vara tillgänglig från internet men inte är avsedd för alla besökare.

Typiska användningsfall:

• interna portaler med extern åtkomst
• administrationsgränssnitt för specialapplikationer
• partner- eller kundportaler med begränsad användargrupp
• äldre webbapplikationer utan egen stark MFA
• applikationer där ytterligare åtkomstskydd framför backend önskas

För offentliga webbplatser, butiker eller informationssidor är WAF-MFA oftast inte lämpligt eftersom varje besökare först skulle se en brandväggsinloggning. För komplexa privata applikationer kan även ZTNA, SSE eller en dedikerad omvänd proxy vara mer lämplig än WAF-MFA. Om WebDAV behövs bör man vara särskilt försiktig: Sophos WAF stöder inte WebDAV korrekt, vilket kan vara relevant för applikationer som Nextcloud.

När WAF-MFA inte räcker

WAF-MFA är ett förskjutet åtkomstlager. Detta lager svarar dock inte på varje arkitekturfråga. Särskilt för kritiska portaler bör man medvetet besluta om applikationen överhuvudtaget ska vara offentligt tillgänglig.

• Applikationen är endast avsedd för några få interna användare: Kontrollera VPN, ZTNA, fasta källnät eller en icke-offentlig publicering.
• Applikationen innehåller särskilt känsliga data: Kontrollera även backend-behörigheter, loggning, granskningsspår och applikationssessioner.
• Applikationen behöver WebDAV eller specialprotokoll: Testa WAF-kompatibilitet före utrullning eller välj en annan arkitektur.
• Externa partners har sällan åtkomst: Dokumentera token-utdelning, supportprocess och fallback särskilt tydligt.
• Backend har egen inloggning och roller: Betrakta WAF-MFA endast som ett ytterligare lager, inte som ersättning för backend-roller.

Om en portal förblir globalt tillgänglig bör MFA inte vara den enda åtgärden. Fasta källnät, landsbegränsning, Threat Feeds, skyddsprofiler och rena backend-patchar minskar risken ytterligare.

Förutsättningar

Innan installationen bör dessa punkter klargöras:

• Webbapplikationen är redan planerad eller publicerad via en WAF-regel.
• Brandväggen kör SFOS 22 eller senare.
• Användare eller grupper finns på brandväggen, till exempel lokalt, via AD, LDAP eller RADIUS.
• Användarna kan ställa in sin OTP-token.
• Systemtiden på brandväggen är korrekt och NTP fungerar.
• För WAF-regeln används HTTPS med lämpligt certifikat.
• Det är klart om backend-webbservern behöver egen autentisering eller om brandväggen ska ta över inloggningen helt.
• En testanvändare och en administrativ fallback-åtkomst finns tillgängliga.

⚠️ MFA för WAF bör först testas med en pilotgrupp. En felaktig kombination av MFA-grupp, WAF-autentiseringspolicy och backend-autentisering kan låsa ute legitima användare eller få en applikation att verka “trasig”.

Planera pilot, fallback och ansvar

WAF-MFA verkar före själva applikationen. Därför bör man inte behandla utrullningen som en vanlig brandväggsregel, utan som en förändring av applikationens inloggningsprocess. Användare ser först inloggningen på Sophos Firewall och därefter, beroende på backend, själva applikationen.

Innan aktivering bör dessa punkter fastställas:

• Vilken användargrupp testar först?
• Vem kan inaktivera åtkomsten om inloggningen misslyckas?
• Finns det en andra admin-åtkomst som inte beror på samma WAF-regel, samma portal eller samma testanvändare?
• Vilka applikationsdelar måste testas efter lyckad inloggning?
• Vem kontrollerar reverseproxy.log, Log Viewer och backend-loggar vid fel?
• Hur informeras användare om token, sessionens utgång och eventuell andra backend-inloggning?

Ett vanligt planeringsfel är att blanda brandväggsautentisering och backend-autentisering. WAF kan kontrollera användare före backend. Det betyder dock inte automatiskt att applikationen själv inte längre behöver egen inloggning, rollkontroll eller sessionshantering. Särskilt för admin-portaler och kunddata bör backend-behörigheten medvetet behållas.

Om den publicerade tjänsten endast är avsedd för några få personer bör man, utöver MFA, begränsa källorna. För grundpublicering och källbegränsning passar Sophos Firewall WAF: Säkert publicera webbserver. Om användarrättigheter eller fjärråtkomst-MFA planeras generellt, hjälper Aktivera MFA för Sophos Firewall WebAdmin, VPN Portal och Remote Access.

En rollback bör förberedas innan aktivering. Praktiskt innebär det: dokumentera gammal fungerande åtkomstmetod, namnge WAF-regel och autentiseringspolicy, fastställ ansvarig person och välj en tidpunkt när användarfeedback och loggkontroll är möjliga. Om applikationen är affärskritisk bör WAF-MFA först aktiveras för en testdomän, en pilotgrupp eller ett underhållsfönster.

Konfiguration

Konfigurationskomponenter

För WAF-MFA måste flera inställningar passa ihop:

• MFA-inställning: Bestämmer vilka användare som använder MFA och om Web application firewall skyddas.
• WAF Authentication Policy: Definierar inloggningsläge, användare/grupper, mall och sessionsbeteende.
• WAF-regel: Kopplar den publicerade webbservern till autentiseringspolicyn.
• Vidarebefordran av backend-autentisering: Bestämmer om brandväggen vidarebefordrar inloggningsuppgifter till webbservern.
• Token-utdelning: Säkerställer att användare faktiskt kan generera sin OTP-kod.

Den viktigaste skillnaden: MFA aktiveras inte bara globalt. Den berörda WAF-regeln måste också använda en lämplig autentiseringspolicy.

Aktivera MFA för WAF

Menysökvägen är:

Authentication > Multi-factor authentication

Förfarande:

1. Under One-time password (OTP) välj antingen All users eller Specific users and groups.
2. Vid Specific users and groups lägg till de berörda användarna eller grupperna.
3. Aktivera Generate OTP token with next sign-in om användare ska ställa in sin token själva vid nästa inloggning.
4. Under Require MFA for aktivera alternativet Web application firewall.
5. Sätt OTP hash algorithm och vid behov OTP timestep settings medvetet.
6. Spara konfigurationen.

Om Generate OTP token with next sign-in är aktivt väljs User portal automatiskt som tjänst för första QR-kodskonfigurationen. Användare måste kunna se QR-koden i en portal innan den första WAF-MFA-inloggningen realistiskt fungerar. Beroende på miljön kan även VPN Portal eller WebAdmin vara relevant. Den allmänna MFA-planeringen beskrivs i Aktivera MFA för Sophos Firewall WebAdmin, VPN Portal och Remote Access.

Förbered token-utdelning och användarkommunikation

WAF-MFA misslyckas ofta i drift inte på grund av själva WAF-regeln, utan på grund av token-utdelningen. Användare måste veta var QR-koden visas, vilken app som ska användas, hur länge en session är giltig och om det följer en andra inloggning till applikationen efter brandväggsinloggningen.

Innan WAF-regeln aktiveras i produktion bör man fastställa:

• Token-skapande: Var ställer användaren in OTP-token?
• Portalåtkomst: Är User Portal eller en annan avsedd väg till QR-koden tillgänglig för de berörda användarna?
• Authenticator-app: Vilken app är godkänd och testad med den valda algoritmen?
• Fallback: Vem kan återställa en förlorad eller defekt token?
• Nödkoder: Är det klart om och hur extra engångskoder får utfärdas i supportfall?
• Supportfall: Vilken information behöver helpdesk vid inloggningsproblem?
• Kommunikation: Vilken inloggningssekvens ser användare från driftsättningen?

Om Generate OTP token with next sign-in används bör den första inloggningen testas kontrollerat. Det är viktigt om användare ser QR-koden i den förväntade portalen och om de därefter kan logga in på WAF-applikationen med lösenord plus OTP. Portalerna själva beskrivs i Sophos Firewall Portaler: WebAdmin, User Portal och VPN Portal.

För många brandväggstjänster behandlas OTP-koden som en kombination av lösenord och passcode. Användarkommunikation och helpdesk-runbook bör därför tydligt ange vilken inmatningsbild användare faktiskt ser och om lösenord och OTP ska anges separat eller kombinerat. Vid WAF-MFA med Form-baserad inloggning är detta särskilt viktigt, eftersom en andra backend-inloggning annars snabbt feltolkas som “MFA trasigt”.

Sophos Authenticator bör inte längre planeras som ny standardapp eftersom appen är End of Life sedan 2022. I praktiken bör Intercept X for Mobile, Google Authenticator, Microsoft Authenticator, Duo Mobile, Okta Verify eller en internt godkänd app testas. Avgörande är inte bara appens namn, utan om den stöder brandväggens valda algoritm, timestep och QR-kod korrekt.

För helpdesk och drift bör minst följande dokumenteras:

• publicerat värdnamn för WAF-applikationen
• berörd användargrupp
• använd autentiseringspolicy
• använd OTP-algoritm
• godkänd authenticator-app
• procedur för token-återställning
• förväntat meddelande vid felaktigt lösenord eller OTP
• loggplatser för första kontroll: Log Viewer och reverseproxy.log

Särskilt för externa partners eller sällan använda portaler bör den första inloggningen inte ske först i en nödsituation i produktion. En kort pilot med vanliga användare avslöjar ofta problem som administratörer inte ser i sina egna tester: avvikande authenticator-app, saknad portalåtkomst, oklar andra backend-inloggning eller session-timeouts som är för korta för applikationen.

Skapa WAF Authentication Policy

Menysökvägen är:

Web server > Authentication policies

För WAF-MFA bör klientläget ställas in på Form. Vid formulärbaserad autentisering kan brandväggen styra inloggningen via ett formulär och sessioner.

Förfarande:

1. Öppna Add.
2. Ge ett beskrivande namn, till exempel WAF_MFA_Portal_Users.
3. Vid Mode välj alternativet Form.
4. Välj en lämplig Authentication template.
5. Välj de användare eller grupper som ska ha åtkomst till denna WAF-publicering.
6. Välj medvetet Authentication forwarding mode.
7. Ställ in Session timeout och Session lifetime lämpligt för applikationen.
8. Spara.

Välj rätt Authentication forwarding

Authentication forwarding mode bestämmer vad som händer mellan brandväggen och backend.

• None: Brandväggen autentiserar användaren; webbservern får inga inloggningsuppgifter.
• Basic: Brandväggen vidarebefordrar användarnamn och lösenord till backend via HTTP Basic Authentication.

Om applikationen inte behöver egen autentisering eller om den förskjutna brandväggsinloggningen ska räcka, är None ofta renare. Om backend själv förväntar sig HTTP Basic Authentication måste vidarebefordringsläget passa applikationen.

Vid None bör man också kontrollera om Remove basic header måste sättas. Det förhindrar att en Basic Authentication-header som skickas av klienten vidarebefordras onödigt till webbservern. Detta är särskilt viktigt om gamla klienter, sparade webbläsardata eller tidigare publiceringar fortfarande genererar Basic-headers.

⚠️ Basic Authentication bör endast användas med HTTPS. Dessutom måste det vara klart om backend verkligen ska bearbeta de inloggningsuppgifter som vidarebefordras av brandväggen.

Klientläget Basic skapar inga sessionscookies och erbjuder ingen särskild utloggning. Sophos kräver därför klientläget Form för WAF-MFA. Oberoende av detta måste Authentication forwarding mode passa backend.

Använd Authentication Policy i WAF-regeln

WAF-regeln redigeras under Rules and policies > Firewall rules. Åtgärden är Protect with web server protection.

I den berörda WAF-regeln måste dessa punkter passa ihop:

• Rätt Hosted address och lyssningsport.
• Rätt domän och lämpligt HTTPS-certifikat.
• Rätt skyddad webbserver.
• Önskad Authentication policy vald.
• Användargrupp i autentiseringspolicyn passar till MFA-gruppen.
• Åtkomstbegränsningar via Allowed client networks, länder eller Threat Feeds är medvetet satta.

För offentliga eller starkt exponerade portaler bör MFA inte vara den enda skyddsåtgärden. Lands- och källbegränsning beskrivs i Sophos Firewall: Blockera länder och skadliga IP-adresser. För dynamiska spärrlistor passar Sophos Firewall Threat Feeds.

Planera sessioner och timeout

Vid formulärbaserad WAF-autentisering arbetar brandväggen med sessioner. I autentiseringspolicyn fastställer man:

• Session timeout: efter vilken inaktivitet användare måste logga in igen
• Session lifetime: hur länge en inloggning maximalt är giltig

Dessutom finns under Web server > General settings det maximala antalet samtidiga sessioner för formulärbaserad omvänd proxy-autentisering. Standardvärdet är 25,000, det stödda området är 100 till 100,000.

Korta sessioner ökar säkerheten men kan störa användare. Mycket långa sessioner är bekvämare men ökar risken för att en stulen eller delad webbläsaråtkomst förblir användbar längre. För admin-portaler bör man börja konservativt och observera beteendet i drift.

Om väldigt många användare eller flera WAF-portaler använder samma brandvägg bör den globala sessionsgränsen inte kontrolleras först när felmeddelanden uppstår. Form-baserad WAF-autentisering är en gemensam reverse proxy-driftparameter och hör därför hemma i kapacitets- och övervakningsplaneringen.

OTP-algoritm och Authenticator-app

SFOS 22 stöder förutom SHA1 även SHA256 och SHA512 för OTP-tokens. Detta är säkerhetsmässigt förnuftigt men fungerar bara om den använda authenticator-appen stöder den valda algoritmen.

Viktiga punkter:

• SHA256 eller SHA512 är säkrare än SHA1.
• Inte alla authenticator-appar stöder dessa algoritmer i detta sammanhang.
• Microsoft Authenticator kan vid SHA256 eller SHA512 visserligen skanna QR-koden, men inloggningen kan därefter misslyckas.
• Om algoritmen ändras måste gamla tokens raderas och skannas om.
• Ändringar av token-timestep gäller endast nygenererade tokens och måste passa den app som används.

För utrullningar i produktion bör man testa den önskade appen och algoritmen med en liten pilotgrupp. Först därefter bör befintliga användare migreras brett.

Om en användare tappar appen eller algoritmen ändras räcker det ofta inte att upprepa användarkommunikationen. Under Authentication > Multi-factor authentication > Issued tokens kan tokens återställas eller extra engångskoder genereras. Denna process bör regleras internt eftersom den har stark säkerhetsbetydelse.

Validering och drift

Testplan efter installation

Efter konfigurationen bör man inte bara kontrollera om inloggningssidan visas. Det är viktigt att testa hela åtkomstvägen.

1. Använd extern webbläsare eller externt testnät.
2. Öppna WAF-URL med en användare från den tillåtna gruppen.
3. Testa inloggning med korrekt lösenord och OTP.
4. Testa inloggning med felaktig OTP.
5. Testa användare utanför den tillåtna gruppen.
6. Kontrollera sessionens utgång efter inaktivitet.
7. Kontrollera applikationens backend-funktion.
8. Kontrollera Log Viewer och reverseproxy.log för avvikelser.
9. Kontrollera utloggning, ny inloggning och sessionsutgång med samma webbläsare.
10. Testa med ett andra hostname eller alternativ sökväg om applikationen använder flera WAF-regler.

För loggfilerna hjälper Sophos Firewall Troubleshooting: Tjänster och loggar. WAF-händelser är vanligtvis kopplade till den omvända proxyn och visas dessutom i Log Viewer.

För godkännande bör varje testfall kopplas till ett synligt resultat:

• Användare: Brandväggsinloggningen visas, OTP efterfrågas och därefter öppnas den förväntade applikationen.
• Sophos Firewall: Log Viewer och reverseproxy.log visar tillåten eller avvisad WAF-autentisering.
• Autentiseringskälla: AD, LDAP, RADIUS eller den lokala användarkällan visar den förväntade lyckade eller misslyckade inloggningen.
• Backend: Applikationen når rätt användar- eller gäststatus och visar ingen oväntad andra felsida.

Om endast webbläsaren verkar fungera men inga tillhörande loggar är synliga är godkännandet ofullständigt. Kontrollera då om rätt WAF-regel används, om autentiseringspolicyn verkligen är aktiv och om loggarna hamnar på förväntad plats.

Driftsättning och drift efter aktivering

Efter ett lyckat test bör WAF-MFA inte bara aktiveras brett och sedan glömmas bort. De första timmarna efter go-live är viktiga eftersom riktiga användare tar med sig andra webbläsare, andra authenticator-appar, sparade lösenord, gamla bokmärken och andra sessionstillstånd än ett admin-test.

För go-live är en liten driftsplan användbar:

• Utrullningsgrupp: Börja med pilotgruppen och lägg därefter till fler användargrupper.
• Supportfönster: Håll helpdesk eller ansvariga administratörer tillgängliga under de första inloggningarna.
• Övervakning: Observera Log Viewer, reverseproxy.log och autentiseringskälla.
• Token-återställning: Definiera en tydlig procedur för förlorade eller felaktigt inställda OTP-tokens.
• Sessionsbeteende: Kontrollera session timeout och session lifetime efter verklig användning.
• Återfallsmetod: Dokumentera WAF-regel, autentiseringspolicy och ändringssteg.

För affärskritiska applikationer bör man inte lägga go-live vid en tidpunkt då ingen kan kontrollera inloggningsproblem ordentligt. Bättre är ett kontrollerat fönster med testanvändare från olika grupper, därefter en kort granskning av loggarna och först därefter utvidgning till fler användare.

Efter några dagar bör konfigurationen kontrolleras igen:

• Finns det användare som kringgår MFA eftersom de får åtkomst via en annan WAF-regel eller en annan URL?
• Tillåts åtkomst fortfarande endast för de planerade grupperna?
• Passar sessionens varaktighet och inaktivitetstimeout till applikationen?
• Ses avvisade inloggningar och token-problem i drift faktiskt?
• Finns det supportfall som pekar på oklar användarkommunikation eller felaktig authenticator-app?
• Har gamla testrutiner, testdomäner eller tillfälliga undantag tagits bort?

Denna efterkontroll är särskilt viktig om flera värdnamn, vägar eller WAF-regler pekar på samma applikation. Annars kan det hända att en väg är ordentligt skyddad med MFA, medan en annan väg fortfarande är tillgänglig utan förskjuten autentisering.

Felsökning

Andra vanliga fel

• Autentiseringspolicyn använder inte Form: MFA-beteendet passar inte den förväntade WAF-konfigurationen.
• Sophos Authenticator planeras som ny standardapp: Appen är EOL och bör inte längre användas som bas för en ny utrullning.
• Fallback-åtkomst beror på samma WAF-regel: Administratörer kan inte återställa ändringen ordentligt vid fel.
• Token-utdelningen testades inte: Användare misslyckas vid första inloggningen, även om WAF-regeln är tekniskt korrekt.
• En andra URL eller WAF-regel förblir aktiv utan MFA: Användare kringgår oavsiktligt den förskjutna MFA.
• Tillfälliga pilotundantag tas inte bort: Produktionsskyddet är ojämnt och svårt att granska.

MFA efterfrågas inte

Kontrollera först om Web application firewall under Require MFA for är aktiverad. Kontrollera sedan om WAF-regeln verkligen använder en autentiseringspolicy och om denna policy innehåller de förväntade användarna eller grupperna.

Inloggning fungerar, men applikationen öppnas inte

Då ligger problemet ofta efter brandväggsinloggningen. Kontrollera backend-tillgänglighet, certifikat, värdhuvud, väg, skyddspolicy och autentiseringsvidarebefordran. Om backend förväntar sig egen autentisering måste vidarebefordringsläget passa.

Användare kan inte logga in efter algoritmbyte

Om man bytt från SHA1 till SHA256 eller SHA512 måste befintliga tokens raderas och skannas om. Dessutom måste authenticator-appen stödja den nya algoritmen.

Backend frågar efter lyckad MFA igen efter login

På SFOS 22.0 GA Respin Build 411 kan NC-177509 inträffa: formbaserad WAF-MFA lyckas, men backend begär därefter en extra inloggning som inte går att kringgå. OTP-koden skiljs inte från lösenordet innan brandväggen vidarebefordrar inloggningsuppgifterna till backend. Sophos listar problemet i Known Issues List och anger SFOS 22.0 MR1 Build 490 som den korrigerade versionen.

I SFOS 22.0-releaseinformationen dokumenteras en tekniskt motsvarande korrigering som NC-177201.

Kontrollera:

• WAF Authentication Policy använder Form.
• Authentication forwarding mode är aktivt och passar backend-applikationen.
• Den berörda WAF-regeln använder exakt denna Authentication Policy.
• Felet uppträder efter lyckad MFA, inte redan vid firewall-inloggningen.
• reverseproxy.log, Log Viewer och backendens accesslogg täcker samma testtidpunkt.
• Den använda SFOS-versionen har kontrollerats.

På ett berört GA-system bör reverseproxy.log, Log Viewer och backend-loggen sparas och en uppdatering till MR1 Build 490 eller senare planeras. Om en snabb uppdatering inte är möjlig anger Sophos kontakt med Support som workaround. Försvaga inte MFA och ändra inte Authentication forwarding utan analys: None passar endast om backend inte behöver vidarebefordrade inloggningsuppgifter. För produktionsportaler ska testanvändare, rollback och användarkommunikation ingå i planen.

För många eller gamla sessioner

Kontrollera session timeout, session lifetime och de globala WAF-sessioninställningarna. I produktionsmiljöer bör det vara klart om långa sessioner önskas eller om användare snabbt måste autentisera sig igen efter inaktivitet.

Checklista

• WAF-regel är dokumenterad och testad externt.
• HTTPS-certifikat passar det publicerade värdnamnet.
• MFA gäller för rätt användargrupp.
• Require MFA for > Web application firewall är aktiverad.
• WAF Authentication Policy använder Form.
• Autentiseringsvidarebefordran passar backend-applikationen.
• Token-utdelning, portalåtkomst och helpdesk-procedur är förberedda.
• Session timeout och session lifetime är medvetet satta.
• OTP-app och hash-algoritm har testats.
• Fallback-admin-åtkomst finns tillgänglig.
• Rollback och ansvarig person är dokumenterade.
• Autentiseringskälla och backend-inloggning har kontrollerats separat.
• Log Viewer och reverseproxy.log har kontrollerats efter test.
• Go-live-supportfönster och token-återställningsprocedur är fastställda.
• Alternativa värdnamn, vägar och WAF-regler har kontrollerats för MFA-kringgående.
• Tillfälliga pilotundantag har tagits bort efter utrullning.

Vanliga frågor