Aktivera MFA för WebAdmin och VPN på Sophos Firewall

Administrativa åtkomster och Remote-Access-portaler bör inte skyddas enbart med användarnamn och lösenord. Med Multi-Factor Authentication, förkortat MFA, kräver Sophos Firewall dessutom en andra faktor, till exempel en tidsbaserad OTP-kod från en authenticator-app.

Den här guiden visar hur man planerar, aktiverar och testar MFA på ett praktiskt sätt. Fokus ligger på WebAdmin, VPN Portal och Remote Access.

När MFA är användbart

MFA bör minst aktiveras för alla konton som får åtkomst till administrativa ytor eller Remote-Access-funktioner.

Typiska användningsområden:

Inloggning i WebAdmin.
Inloggning i VPN Portal.
SSL VPN eller Sophos Connect Remote Access.
Åtkomst för externa tjänsteleverantörer.
Åtkomst för privilegierade administratörer.

MFA minskar risken med stulna lösenord, men ersätter inte en ren åtkomstbegränsning. SSH, WebAdmin och portaler bör fortfarande bara vara nåbara från betrodda nät eller via tydligt definierade management-åtkomster.

Begränsa åtkomst även med ACL-regler

Innan man aktiverar MFA bör man kontrollera varifrån WebAdmin, SSH, User Portal och VPN Portal överhuvudtaget kan nås.

Menyvägen är System > Administration > Device access.

Där finns två relevanta områden:

Local service ACL: Grundläggande åtkomst per zon, till exempel LAN, VPN eller WAN.
Local service ACL exception rule: Riktade undantag för enskilda källnät, hosts eller supportåtkomster.

För produktionsmiljöer bör WebAdmin och SSH inte aktiveras generellt för WAN-zonen. Bättre är begränsning till:

en management-IP,
ett admin-nät,
ett VPN-nät,
en dedikerad support-host,
eller ett tydligt definierat FQDN-/host-undantag.

Om SSH behövs bör åtkomsten begränsas ytterligare och helst användas med Public Key. Se även: Ansluta till Sophos Firewall via SSH

⚠️ MFA skyddar mot stulna inloggningsuppgifter, men inte mot onödigt exponerade tjänster. WebAdmin, SSH och portaler bör aldrig vara bredare åtkomliga än nödvändigt.

Förutsättningar

Innan aktivering bör man kontrollera:

Brandväggens systemtid är korrekt.
En fungerande NTP-server är konfigurerad.
Användarna finns lokalt, via AD, LDAP, RADIUS eller en annan stödd autentiseringstjänst.
De berörda användarna kan logga in i User Portal eller respektive tjänst.
Minst en administrativ fallback-åtkomst finns.

⚠️ Vid Admin-MFA måste man vara särskilt försiktig. Aktivera inte MFA direkt för alla administratörer utan att först ha testat en testanvändare, en andra administratör och en fallback-åtkomst. Fel MFA-konfiguration kan leda till att man låser ute sig själv från WebAdmin eller VPN Portal.

Sophos MFA eller extern MFA via RADIUS?

Sophos Firewall har en egen MFA-lösning. Då hanteras OTP-token direkt på brandväggen. Det går snabbt att konfigurera och fungerar utan extra infrastruktur.

Fördelar med Sophos egen MFA:

Ingen extra RADIUS- eller Identity Provider-integration behövs.
Snabb rollout för lokala användare och små miljöer.
Token kan skapas och hanteras direkt på brandväggen.
Lämpligt för WebAdmin, User Portal, VPN Portal, SSL VPN Remote Access och IPsec Remote Access.

Nackdelar:

Användare kan behöva hantera en extra authenticator-app eller en extra token.
Token är separerad från Microsoft 365, Entra ID och andra befintliga MFA-processer.
Beroende på login-skärm finns inget separat OTP-fält.
Användare måste vid vissa portaler ange lösenord och token direkt efter varandra.

I större miljöer kan en extern MFA-lösning via RADIUS vara mer lämplig. Då implementeras MFA till exempel via Microsoft Entra ID, NPS med MFA-tillägg eller en annan RADIUS-kompatibel MFA-tjänst. För användarna är det ofta enklare, eftersom de kan använda den välbekanta Microsoft 365-MFA:n eller en befintlig företagslösning.

Nackdelen med en extern lösning är högre komplexitet. RADIUS, grupper, timeouts, challenge-beteende och fallback måste planeras och testas ordentligt.

Planera MFA

För produktionsmiljöer är det oftast bäst att först aktivera MFA för en liten pilotgrupp.

Denna ordning har visat sig fungera bra:

Förbered testanvändare eller pilotgrupp.
Kontrollera NTP och brandväggens tid.
Aktivera MFA för testområdet.
Testa inloggning med authenticator-app.
Lägg först därefter till fler användargrupper.

För tjänsteleverantörer rekommenderas en egen användargrupp. Då kan MFA tvingas specifikt och åtkomsten senare tas bort enklare.

För administratörer bör man dessutom planera:

Vem är första test-admin?
Finns en andra admin med fungerande åtkomst?
Är åtkomst via management-nät eller VPN möjlig?
Är default admin skyddad separat?
Är det dokumenterat hur en förlorad token ersätts?

Aktivera MFA på Sophos Firewall

MFA-inställningarna finns under Configure > Authentication > Multi-factor authentication.

Logga in i WebAdmin på Sophos Firewall.
Öppna Configure > Authentication.
Gå till fliken Multi-factor authentication.
Välj under One-time password (OTP) för vem MFA ska gälla:
- No OTP: MFA är avaktiverat.
- All users: MFA gäller för alla användare.
- Specific users and groups: MFA gäller bara för valda användare eller grupper.
Aktivera Generate OTP token with next sign-in om användare ska konfigurera sin token själva vid nästa login.
Välj under Require MFA for för vilka tjänster MFA ska krävas.
Spara konfigurationen med Apply.

Sophos Firewall - Multi-factor authentication-inställningar under Authentication — Sophos Firewall - Authentication > Multi-factor authentication

Typiska alternativ under Require MFA for är:

User portal
Web admin console
VPN portal
SSL VPN remote access
IPsec remote access
Web application firewall

Beroende på miljö kan MFA användas olika för enskilda tjänster eller användargrupper. För administratörer bör MFA tvingas konsekvent, men först testas kontrollerat.

MFA för default admin

Den lokala default-användaren admin är ett specialfall. Sophos visar i MFA-vyn att MFA för denna användare inte aktiveras direkt i denna flik.

Menyvägen är System > Administration > Device access.

Där kan man aktivera MFA for default admin. Det bör man först göra när:

systemtiden är korrekt,
en andra administratör har testats,
åtkomst via ett betrott management-nät fungerar,
och det är tydligt hur man får tillbaka administrativ åtkomst i nödfall.

För default admin gäller: avaktivera inte, gör den inte oskyddat åtkomlig från internet och använd den inte som normal daglig användare. Det är ett break-glass- eller nödkonto.

Konfigurera token för användare

Efter aktivering måste användaren konfigurera sin andra faktor. Om Generate OTP token with next sign-in är aktiv loggar användaren in i User Portal eller VPN Portal och skannar QR-koden med en authenticator-app.

Lämpliga appar är till exempel:

Microsoft Authenticator.
Google Authenticator.
1Password.
Bitwarden.
Andra TOTP-kompatibla authenticator-appar.

Den genererade koden är tidsbaserad. Om tiden på brandväggen eller smartphonen avviker kraftigt misslyckas inloggningen.

Om User Portal är avaktiverat kan användare under vissa omständigheter inte konfigurera sina tokens själva. I så fall måste man antingen tillhandahålla portalen kontrollerat eller förbereda tokens administrativt.

Viktig information om lösenord och token

Beroende på Sophos-tjänst finns inget separat formulärfält för OTP-koden. Särskilt vid VPN Portal eller Remote-Access-logins leder detta ofta till förvirring.

I dessa fall måste användaren ofta ange lösenord och OTP-kod direkt efter varandra.

Exempel:

Lösenord: MittSakraLosenord
OTP-kod: 123456
Inmatning: MittSakraLosenord123456

Det bör kommuniceras tydligt till användarna före rollout. Annars ser det för användaren ut som om lösenordet är fel, fast det egentligen bara är OTP-koden som saknas.

Sophos beskriver detta beteende i sin egen OTP-dokumentation: OTP token.

Testa inloggning

Testa MFA först med en användare som inte är den enda administratören.

Kontrollera:

Inloggning i WebAdmin.
Inloggning i VPN Portal.
Inloggning i Remote-Access-tjänsten.
Beteende vid fel OTP-kod.
Beteende efter att en OTP-kod har löpt ut.
Åtkomst med en användare som inte ingår i MFA-gruppen.
Login med lösenord och bifogad OTP-kod.
Åtkomst via planerade ACL-regler.

Först när dessa tester fungerar bör MFA rullas ut till fler grupper.

Vanliga fel

OTP-kod accepteras inte

Kontrollera brandväggens systemtid och smartphonens tid. TOTP är tidsberoende. Redan en tydlig avvikelse kan göra att giltiga koder nekas.

Användaren ser ingen QR-kod

Användaren måste vara behörig för MFA och logga in i rätt portal. Kontrollera dessutom att användaren hittas via förväntad autentiseringskälla.

Om User Portal är avaktiverat kan användaren kanske inte konfigurera token själv. Då måste portalen göras temporärt nåbar eller token skapas administrativt.

Administratören är utelåst

Använd den förberedda fallback-åtkomsten. Om ingen fallback finns måste åtkomst beroende på situation kontrolleras via console, support eller återställningsvägar.

MFA gäller inte för Remote Access

Kontrollera att Remote-Access-konfigurationen använder samma användargrupp som MFA har aktiverats för. Ofta ligger felet inte i MFA själv, utan i olika grupper i VPN- och autentiseringsregler.

Användaren anger bara lösenordet

Om inget separat OTP-fält visas måste användaren ange lösenord och OTP-kod direkt efter varandra. Det är ett av de vanligaste supportfallen efter aktivering av Sophos OTP.

Extern MFA fungerar inte tillförlitligt

Vid RADIUS-baserade MFA-lösningar måste timeouts, challenge-beteende och grupper passa korrekt. Om Push-MFA, Call-MFA eller challenge-svar används bör hela login-processen testas med den berörda klienten.

Rekommendation

MFA bör vara standard för administrativa åtkomster. Särskilt viktigt är MFA för WebAdmin, VPN Portal och alla användare med Remote-Access-behörighet.

För små miljöer räcker Sophos egen OTP-funktion ofta. I Microsoft 365- eller Entra ID-miljöer kan extern MFA via RADIUS vara bekvämare, eftersom användare inte behöver lära sig en andra MFA-värld.

Oavsett MFA-variant gäller: begränsa åtkomst först med ACL-regler, testa Admin-MFA försiktigt, informera användare om lösenord+token och rulla först därefter ut brett.

Ytterligare Sophos-information: