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.

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.

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.

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

Konfigurationskomponenter

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

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

Menypath ä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. Spara konfigurationen.

Om användare ska ställa in sin token själva måste de ha åtkomst till en portal där QR-koden visas. I många miljöer är User Portal eller VPN Portal relevant för detta. 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 den produktiva WAF-regeln aktiveras bör man fastställa:

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 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 produktiv nödsituation. 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

Menypath ä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.

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.

⚠️ 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.

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.

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.

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

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.

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:

Om endast webbläsaren verkar framgångsrik men inga passande loggar är synliga är godkännandet ofullständigt. Då bör man kontrollera om rätt WAF-regel matchar, om autentiseringspolicyn verkligen är aktiv och om loggar landar på förväntad plats.

Go-live 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:

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.

Vanliga fel

Felsökning

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.

Lösenord och OTP vidarebefordras till backend

Vid WAF-MFA bör man kontrollera om brandväggsversionen är aktuell. I SFOS-22.0-Release-Notes dokumenteras ett åtgärdat WAF-fel där OTP-koden inte togs bort från lösenordet innan data vidarebefordrades till backend.

För många eller gamla sessioner

Kontrollera session timeout, session lifetime och de globala WAF-sessioninställningarna. I produktiva miljö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