MFA voor Sophos Firewall WebAdmin, VPN Portal en externe toegang activeren

Administratieve toegang en portalen voor externe toegang moeten niet alleen worden beveiligd met een gebruikersnaam en wachtwoord. Bij Multi-Factor Authenticatie, kortweg MFA, heeft de Sophos Firewall ook een tweede factor nodig, bijvoorbeeld een op tijd gebaseerde OTP-code uit een Authenticator-app.

Voor de bredere hardening-context past de hub Sophos Firewall Hardening: best practices voor een veilige configuratie.

Het artikel legt uit hoe men MFA zinvol plant, activeert en test. De focus ligt op WebAdmin, VPN Portal en Remote Access.

Classificatie en toegangsbeveiliging

MFA is een belangrijke bescherming voor logins, maar slechts één bouwsteen. Ten eerste moet duidelijk zijn welke toegang wordt beschermd, welke identiteitsbron daarachter zit en of de dienst überhaupt toegankelijk moet zijn vanaf het betreffende netwerk.

Welk authenticatieartikel past?

MFA is slechts een onderdeel van de toegangsbeveiliging. Afhankelijk van het doel is het eerste waar u rekening mee moet houden de toegankelijkheid, identiteitsbron, portal, VPN-client of gepubliceerde webapplicatie:

• MFA voor WebAdmin, VPN Portal of externe toegang plannen: Dit artikel.
• WebAdmin, SSH, User Portal, VPN Portal, DNS of Ping bereikbaar beperken: Sophos Firewall-toegang beveiligen: Device Access correct configureren.
• Microsoft Entra ID SSO voor Sophos Connect of VPN Portal gebruiken: Microsoft Entra ID SSO instellen voor Sophos Connect en VPN Portal.
• Sophos Connect, SSL VPN, IPsec of ZTNA als Remote-Access-model vergelijken: Sophos Connect of SSL VPN: welke Remote-Access-oplossing past?.
• Sophos Connect-clientversie, OTP-reconnects of SSO-provisioning controleren: Sophos Connect Client-versie controleren en veilig bijwerken.
• WAF-gepubliceerde webapplicatie met MFA beveiligen: Sophos Firewall WAF met MFA beveiligen.
• Klassieke Active Directory als gebruikersbron koppelen: Active Directory toevoegen aan Sophos Firewall.
• Supporttoegang voor Avanet of Sophos gecontroleerd voorbereiden: Avanet Support-toegang tot Sophos Firewall instellen.
• Health-Check-findings over MFA of portaltoegang prioriteren: Sophos Firewall Health Check correct gebruiken.

Deze scheiding is belangrijk: MFA beschermt logins, maar beperkt niet automatisch vanaf welke netwerken WebAdmin, SSH of portalen kunnen worden bereikt. Omgekeerd vervangt een beperkte regel voor apparaattoegang geen tweede factor. Goede toegangsbeveiliging combineert bereikbaarheid, identiteitsbron, MFA, logging en geteste fallback-toegang.

Wanneer MFA zinvol is

MFA moet in ieder geval worden ingeschakeld voor alle accounts die toegang hebben tot administratieve interfaces of functies voor externe toegang.

Typische toepassingsgebieden:

• Registratie op WebAdmin.
• Registratie op VPN Portal.
• SSL VPN of Sophos Connect externe toegang.
• Toegang voor externe dienstverleners.
• Toegang voor bevoorrechte beheerders.

MFA vermindert het risico op gestolen wachtwoorden, maar vervangt niet de juiste toegangsbeperkingen. SSH, WebAdmin en portalen mogen nog steeds alleen toegankelijk zijn via betrouwbare netwerken of via duidelijk gedefinieerde beheertoegang.

MFA is geen vervanging voor Device Access

MFA beschermt het inlogproces. Het verkleint echter niet het aanvalsoppervlak van een dienst. Als WebAdmin, User Portal, VPN Portal of SSL VPN via internet bereikbaar zijn, zullen deze services nog steeds worden getroffen door bots, scanners en brute force-pogingen. Dit zorgt voor onnodige logboekinvoer, ondersteuningsinspanningen en risico’s.

Daarom moet u MFA altijd combineren met beschikbaarheidscontroles:

• Device access: principieel vastleggen welke diensten in welke zone bereikbaar zijn.
• Local service ACL exception rule: WebAdmin, SSH of portalen gericht alleen vanuit beheernetwerken, VPN-netwerken of bekende bronadressen toestaan.
• MFA: Beveilig registraties bovendien als geldige toegangsgegevens zijn aangetast.
• Loggen en Syslog: Maak mislukte pogingen, uitrolproblemen en aanvallen begrijpelijk.

Als een portal wereldwijd toegankelijk moet zijn, combineer je in ieder geval MFA, geldige certificaten, logging, beperkende gebruikersgroepen en regelmatige reviewprocessen. Bij publiek toegankelijke firewalldiensten is het niet alleen de vraag of een aanvaller kan inloggen, maar of de dienst überhaupt breed toegankelijk moet zijn.

Beperk bovendien de toegang met ACL-regels

Voordat u MFA activeert, moet u controleren vanwaar WebAdmin, SSH, User Portal en VPN Portal daadwerkelijk bereikbaar zijn.

Het menupad is System > Administration > Device access.

Er zijn twee relevante gebieden:

• Local service ACL: basistoegang per zone, bijvoorbeeld LAN, VPN of WAN.
• Local service ACL exception rule: gerichte uitzonderingen voor afzonderlijke bronnetwerken, hosts of supporttoegang.

Voor productieomgevingen mag u WebAdmin en SSH over het algemeen niet inschakelen voor de WAN-zone. Het is beter om het te beperken tot:

• een beheer-IP,
• een beheerdersnetwerk,
• een VPN-netwerk,
• een toegewijde ondersteuningshost,
• of een duidelijk gedefinieerde FQDN/host-uitzondering.

Als SSH nodig is, moet de toegang aanvullend worden beperkt en idealiter met Public Key worden gebruikt. Daarbij past Sophos Firewall via SSH verbinden.

⚠️ MFA beschermt tegen gestolen inloggegevens, maar niet tegen onnodig blootgestelde services. WebAdmin, SSH en portalen mogen nooit breder toegankelijk zijn dan noodzakelijk.

Selecteer de MFA-variant en plan de uitrol

Vóór activering moet u beslissen of de lokale Sophos OTP-functie voldoende is of dat een bestaand MFA-platform moet worden geïntegreerd via RADIUS, NPS of SSO. De uitrol wordt vervolgens zo gepland dat beheerders en gebruikers zichzelf niet buitensluiten.

Vereisten

Vóór activering moet u het volgende controleren:

• De firewallsysteemtijd is correct.
• Er is een werkende NTP-server geconfigureerd.
• Gebruikers bestaan ​​lokaal, via AD, LDAP, RADIUS of een andere ondersteunde authenticatieservice.
• De betrokken gebruikers kunnen inloggen op de User Portal of de betreffende dienst.
• Er is ten minste één administratieve fallback-toegang beschikbaar.

⚠️ Bij Admin-MFA moet men bijzonder voorzichtig zijn. MFA mag niet direct voor alle beheerders worden ingeschakeld zonder eerst een testgebruiker, een tweede beheerder en fallback-toegang te controleren. Een verkeerde MFA-configuratie kan ertoe leiden dat men zichzelf uit WebAdmin of VPN Portal buitensluit.

Sophos MFA of externe MFA?

Er zijn in principe twee manieren voor MFA op de Sophos Firewall: u gebruikt de lokale OTP-functie van de firewall of sluit een externe MFA-oplossing aan via RADIUS of SSO. Beide varianten zijn legitiem, maar lossen verschillende problemen op.

De lokale MFA van de Sophos Firewall beheert OTP-tokens rechtstreeks op de firewall. Dit is meestal de snelste manier om WebAdmin, portalen en externe toegang te beveiligen met een tweede factor. Er is geen aanvullende RADIUS-infrastructuur of identiteitsprovider vereist.

Voordelen van Sophos’ eigen MFA:

• Geen aanvullende RADIUS- of identiteitsprovider-integratie vereist.
• Snelle uitrol voor lokale gebruikers en kleine omgevingen.
• Tokens kunnen rechtstreeks op de firewall worden gegenereerd en beheerd.
• Geschikt voor WebAdmin, User Portal, VPN Portal, SSL VPN externe toegang en IPsec externe toegang.

Nadelen:

• Gebruikers moeten mogelijk een extra Authenticator-app of token onderhouden.
• Het token staat los van Microsoft 365, Entra ID of andere bestaande MFA-processen.
• Afhankelijk van het inlogmasker is er geen apart OTP-veld.
• Op bepaalde portalen moeten gebruikers het wachtwoord en de token direct achter elkaar invoeren.

In grotere omgevingen kan een externe MFA-oplossing zinvoller zijn. Typische varianten zijn RADIUS met een MFA-compatibele backend, Microsoft NPS met Entra-MFA-extensie of een ander RADIUS-compatibel MFA-systeem. Afhankelijk van de SFOS-versie en het model voor externe toegang passen ook Microsoft Entra ID SSO voor WebAdmin, VPN Portal en Sophos Connect met SSL VPN of IPsec VPN.

Het belangrijke onderscheid is: Entra ID is niet simpelweg hetzelfde mechanisme als de lokale Sophos OTP-functie. Ofwel Entra MFA wordt indirect geïntegreerd in de authenticatiestroom via RADIUS/NPS of er wordt een SSO-model gebruikt als de gebruikte service en client dit ondersteunen.

Gebruikers vinden een externe MFA vaak handiger omdat ze dezelfde MFA gebruiken als voor Microsoft 365 of andere zakelijke diensten. Hierdoor ontstaat er geen tweede MFA wereld met een extra app, extra token en ander inloggedrag.

Het nadeel van een externe oplossing is de hogere complexiteit. RADIUS, groepen, time-outs, challenge-gedrag en fallback moeten zorgvuldig worden gepland en getest.

• Sophos OTP op de firewall: Snel ingericht, zonder aanvullende infrastructuur en direct in SFOS beheerd. Daarvoor ontstaat een extra token, los van Microsoft 365 of Entra ID; afhankelijk van het portal moeten wachtwoord plus OTP in een veld worden ingevoerd. Typisch voor kleine omgevingen, lokale gebruikers en snelle hardening van WebAdmin of VPN.
• Externe MFA via RADIUS: Bestaand MFA-platform kan worden gebruikt en centrale gebruikersprocessen blijven behouden. Daarvoor moeten RADIUS, NPS, time-outs, groepen en clientgedrag zorgvuldig worden getest. Typisch voor AD-/Microsoft-365-omgevingen met veel VPN-gebruikers.
• Entra ID SSO: Vertrouwde Microsoft-login, betere gebruikerservaring en centrale identity-processen. Niet elk scenario is identiek bruikbaar; het hangt af van SFOS-versie, dienst en client. Typisch voor WebAdmin, VPN Portal en Sophos Connect wanneer SSO bij het beheermodel past.

Beslissingsondersteuning

De juiste MFA-variant is minder afhankelijk van de firewall dan van de bestaande identiteitsoperatie.

• Kleine omgeving met lokale firewallgebruikers: De eigen OTP-functie van Sophos is vaak voldoende.
• Microsoft 365-omgeving met bestaande Entra-MFA: Valideer externe MFA via RADIUS/NPS of Entra-ID SSO zodat gebruikers niet twee MFA-werelden hoeven te onderhouden.
• Veel externe dienstverleners: Eigen gebruikersgroep, MFA verplichting, duidelijke termijn en regelmatige evaluatie.
• Kritieke beheerderstoegang: MFA plus Device Access, combineren beheernetwerk, fallback-beheer en logboekregistratie.
• Veel gebruikers met externe toegang: Plan een pilotgroep, helpdeskproces, tokenreset en clienttests vóór de brede uitrol.

Als Microsoft Entra ID rechtstreeks is gepland als SSO-bron voor VPN Portal of Sophos Connect, past ook Microsoft Entra ID SSO instellen voor Sophos Connect en VPN Portal. Dit is een ander bedieningsmodel dan de klassieke Sophos OTP-functie en mag niet worden gelijkgesteld met RADIUS-MFA, niet getest.

MFA plannen

Voor productieomgevingen is het doorgaans beter om MFA eerst voor een kleine pilotgroep te activeren.

Deze volgorde heeft zich bewezen:

1. Testgebruikers of pilotgroep voorbereiden.
2. Controleer NTP en tijd van de firewall.
3. Schakel MFA in voor het testgebied.
4. Testregistratie met de Authenticator-app.
5. Integreer pas daarna extra gebruikersgroepen.

Voor dienstverleners wordt een aparte gebruikersgroep aanbevolen. Hierdoor is het mogelijk om MFA specifiek te forceren en de toegang later gemakkelijker te verwijderen.

Voor beheerders moet u ook het volgende plannen:

• Wie is de eerste testbeheerder?
• Is er een tweede beheerder met werktoegang?
• Is toegang mogelijk via een beheernetwerk of VPN?
• Is de standaard admin afzonderlijk beveiligd?
• Is gedocumenteerd hoe een verloren token wordt vervangen?

Activeer MFA en stel tokens in

Wanneer vereisten, groepen en fallback duidelijk zijn, kan MFA eerst worden geactiveerd voor een pilotgroep. Pas na succesvolle tests mag u extra gebruikers of beheerders toevoegen.

MFA op de Sophos Firewall activeren

De MFA-instellingen bevinden zich in actuele SFOS-versies onder Authentication > Multi-factor authentication. In oudere interfaces of afhankelijk van de navigatie kan het gedeelte nog onder Configure > Authentication > Multi-factor authentication verschijnen.

1. Log in op de WebAdmin van de Sophos Firewall.
2. Open Authentication.
3. Ga naar het tabblad Multi-factor authentication.
4. Selecteer bij One-time password (OTP) voor wie MFA moet gelden:
   • No OTP: MFA is uitgeschakeld.
   • All users: MFA geldt voor alle gebruikers.
   • Specific users and groups: MFA geldt alleen voor geselecteerde gebruikers of groepen.
5. Activeer Generate OTP token with next sign-in wanneer gebruikers hun token bij de volgende login zelf moeten instellen.
6. Selecteer onder Require MFA for voor welke diensten MFA vereist is.
7. Sla de configuratie op met Apply.

Typische opties onder Require MFA for zijn:

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

Afhankelijk van de omgeving kan MFA verschillend worden toegepast voor individuele diensten of gebruikersgroepen. Voor beheerders moet MFA consistent worden afgedwongen, maar eerst op een gecontroleerde manier worden getest.

Als webapplicaties via Web Server Protection worden gepubliceerd, is ook een passende WAF-authenticatierichtlijn nodig. De procedure staat in Sophos Firewall WAF met MFA beveiligen.

Rollout en beheer voorbereiden

MFA is niet alleen een schakelaar in de firewall. Na activatie veranderen het inloggedrag, supportvragen en noodtoegang. Daarom moet vóór de brede uitrol duidelijk zijn wie tokens uitgeeft, wie verloren tokens reset en hoe de reactie buiten kantooruren zal zijn.

Deze punten zijn nuttig gebleken voor de bediening:

• Test een pilotgroep met echte gebruikers, niet alleen beheerders.
• Documenteer een tweede beheerder en breek glastoegang.
• Informeer de helpdesk over wachtwoord+OTP-gedrag.
• Stel het token-resetproces in voor nieuwe smartphones of verloren apparaten.
• Controleer Log Viewer en authenticatielogboeken na de implementatie.
• Test externe MFA via RADIUS met realistische time-outs.
• Controleer regelmatig de Device Access- en ACL-uitzonderingen.

Vooral bij toegang op afstand moet u de MFA samen met de betreffende VPN-regels, gebruikersgroepen en klantprofielen testen. Een werkende WebAdmin-login bewijst niet automatisch dat SSL VPN, IPsec Remote Access of Sophos Connect hetzelfde werken.

Fallback en Break-Glass plannen

MFA verhoogt de veiligheid, maar kan ook legitieme beheerders uitsluiten als het token, de tijd, de authenticatieserver of de groepen niet overeenkomen. Daarom is vóór activering een noodplan nodig.

Deze punten moeten in ieder geval worden gedocumenteerd:

• Wie heeft een tweede geteste beheerderstoegang?
• Is toegang mogelijk vanaf een beheernetwerk of admin VPN?
• Is de lokale standaard admin beschermd als noodaccount, maar wordt deze niet gebruikt voor dagelijks gebruik?
• Hoe kan ik een verloren of kapot OTP-token resetten?
• Wie kan tokens voor beheerders resetten?
• Hoe reageer je buiten kantooruren?
• Is er voor de wijziging een actuele backup?

De fallback mag niet betekenen dat een onbeveiligde beheerderstoegang permanent via internet bereikbaar blijft. Beter is een noodaccount met duidelijke documentatie, een smal toegangspad en regelmatige review.

MFA voor de default admin

De lokale default gebruiker admin is een speciaal geval. MFA voor deze gebruiker wordt niet direct in het tabblad Multi-factor authentication geactiveerd.

Het menupad is System > Administration > Device access.

Daar kan men MFA for default admin activeren. Dat moet pas gebeuren wanneer:

• de systeemtijd klopt,
• een tweede beheerder werd getest,
• toegang werkt via een betrouwbaar beheernetwerk,
• en het is duidelijk hoe u in geval van nood weer beheerderstoegang kunt krijgen.

Voor de default admin geldt: niet deactiveren, niet onbeveiligd via internet bereikbaar maken en niet als normale dagelijkse gebruiker gebruiken. Het is een Break-Glass- of noodaccount.

Andere beheerders mogen er niet van uitgaan dat ze het MFA-token van de standaard admin kunnen bewerken of verwijderen zoals een normaal gebruikerstoken. Deze toegang moet bewust worden gepland en getest via uw eigen apparaattoegangspad.

Tokens instellen voor gebruikers

Eenmaal geactiveerd, moet de gebruiker zijn tweede factor instellen. Als Genereer OTP-token bij volgende aanmelding actief is, logt de gebruiker in op de User Portal of VPN Portal en scant de QR-code met een Authenticator-app.

Geschikte apps zijn onder meer:

• Microsoft Authenticator.
• Google Authenticator.
• Sophos Intercept X for Mobile.
• 1Password.
• Bitwarden.
• Andere TOTP-compatibele Authenticator-apps.

De gegenereerde code is tijdgebaseerd. Als de tijd op de firewall of smartphone aanzienlijk verschilt, mislukt het inloggen.

Als de User Portal is uitgeschakeld, kunnen gebruikers mogelijk hun tokens niet zelf instellen. In dit geval moet men de portal gecontroleerd beschikbaar maken of tokens administratief voorbereiden.

Onder Authentication > Multi-factor authentication > Issued tokens ziet men welke gebruikers al een token hebben aangemaakt of toegewezen gekregen. Daar kunnen tokens worden gecontroleerd, verwijderd of indien nodig handmatig voorbereid. Voor de default admin geldt een speciale regel: andere beheerders kunnen diens token niet zoals normale gebruikerstokens wijzigen of verwijderen. Dit token wordt via het eigen default-admin-MFA-pad beheerd.

Token-algoritme en schakelen tussen apps

Sophos Firewall ondersteunt voor OTP-tokens de hash-algoritmen SHA1, SHA256 en SHA512. SFOS-versies vóór 22.0 gebruiken SHA1 voor MFA; vanaf SFOS 22.0 moeten nieuwe of gemigreerde tokens met SHA256 of SHA512 worden getest. Dat mag echter niet blind worden ingesteld: het gekozen hash-algoritme moet passen bij de gebruikte Authenticator-app.

Sophos wijst er uitdrukkelijk op dat een app het gekozen algoritme moet ondersteunen. Wanneer een app SHA256 of SHA512 niet correct ondersteunt, kan de QR-code wel worden gescand, maar mislukt de login toch. Daarom hoort het algoritme altijd in de pilottest, vooral wanneer Microsoft Authenticator, passwordmanager-TOTP, Google Authenticator of Sophos Intercept X for Mobile gemengd worden gebruikt.

Deze punten zijn belangrijk voor de werking:

• Plan niet langer nieuwe tokens met oude app-aannames.
• Gebruik een Authenticator-app die het geselecteerde hash-algoritme ondersteunt.
• Als u van app verandert of uw smartphone kwijtraakt, verwijder dan de oude token en laat de QR-code opnieuw genereren.
• Gebruik alleen hardwaretokens als het algoritme, de tijdstap en het geheim goed kunnen worden beheerd.
• Test een pilotgroep vóór een SHA256/SHA512-migratie in plaats van alle tokens in één keer om te wisselen.
• Verwijder bestaande SHA1-tokens bij een migratie gecontroleerd en laat ze opnieuw aanmaken.

De oude Sophos Authenticator-app mag niet langer als nieuwe standaardapp worden gepland; volgens Sophos is deze sinds 31 juli 2022 End of Life. In veel omgevingen zijn Microsoft Authenticator, Google Authenticator, Sophos Intercept X for Mobile, 1Password of Bitwarden realistischere opties. De merknaam van de app is minder belangrijk dan de vraag of TOTP, hash-algoritme, backup/restore-gedrag en helpdeskproces bij elkaar passen.

Wanneer een gebruiker van smartphone wisselt, moet het oude token niet stilzwijgend blijven bestaan. Beter is een duidelijk proces: identiteit controleren, oud token verwijderen, nieuwe QR-code genereren, login met juiste en foute OTP testen en de handeling documenteren.

Belangrijke opmerking over wachtwoord en tokens

Afhankelijk van de Sophos-dienst is er geen apart formulierveld voor de OTP-code. Dit leidt altijd tot verwarring, vooral bij de VPN Portal of inloggen op afstand. In deze gevallen moet de gebruiker vaak het wachtwoord en de OTP-code achter elkaar invoeren.

Voorbeeld:

Wachtwoord: MijnVeiligWachtwoord
OTP-code:   123456
Invoer:     MijnVeiligWachtwoord123456

Dit moet vóór de uitrol duidelijk aan gebruikers worden gecommuniceerd. Anders zal het voor de gebruiker lijken alsof het wachtwoord onjuist is, ook al ontbreekt alleen de OTP-code.

Dit gedrag moet vóór de uitrol worden getest en gedocumenteerd, omdat het afhankelijk van de service en het inlogmasker anders wordt waargenomen.

Testen en beheer controleren

Een succesvolle WebAdmin-test is niet voldoende. Elk betrokken inlogoppervlak moet afzonderlijk worden getest omdat de portal, VPN-client, gebruikersgroep en authenticatieserver verschillend kunnen reageren.

Testaanmelding

MFA moet eerst worden getest met een gebruiker die niet de enige beheerder is.

Deze punten moeten worden gecontroleerd:

• Registratie op WebAdmin.
• Registratie op VPN Portal.
• Meld u aan bij de service voor externe toegang.
• Gedrag bij onjuiste OTP-code.
• Gedrag nadat een OTP-code verloopt.
• Toegang met een gebruiker die niet in de groep MFA zit.
• Login met wachtwoord en bijgevoegde OTP-code.
• Toegang via geplande ACL-regels.

Pas als deze tests succesvol zijn, mag MFA naar andere groepen worden uitgerold.

Testmatrix per service

Een MFA-test moet niet alleen bestaan uit een succesvolle WebAdmin-login. Afhankelijk van de dienst zijn andere portalen, groepen, profielen en logbestanden van toepassing. Deze matrix helpt om de belangrijkste cases afzonderlijk te onderzoeken:

• WebAdmin: admin-gebruiker met juiste en foute OTP aanmelden. Juiste OTP geeft toegang, foute OTP wordt netjes geweigerd en gelogd.
• Default admin: afzonderlijk MFA-pad onder System > Administration > Device access testen. Het noodaccount is beschermd, maar een gedocumenteerde Break-Glass-route blijft beschikbaar.
• User Portal: gebruiker richt token zelf in. QR-code verschijnt alleen voor bevoegde gebruikers, het token werkt daarna bij login.
• VPN Portal: gebruiker meldt zich aan met wachtwoord en OTP. De login werkt met het gedocumenteerde invoerformaat en wordt zichtbaar in Log Viewer.
• SSL VPN / Sophos Connect: profiel importeren of verbinding opnieuw opbouwen. MFA wordt in de echte client gevraagd, niet alleen in de browser.
• IPsec Remote Access: groep en authenticatiemethode controleren. MFA geldt voor dezelfde groep die ook in de Remote-Access-configuratie is toegestaan.
• Externe MFA via RADIUS: push, challenge of token met echte client testen. Timeout is voldoende, challenge-gedrag past bij de client en fouten zijn zichtbaar op de RADIUS-server.

Bij elke test moet ook worden gecontroleerd of Device Access of een lokale service-ACL-regel de service opzettelijk toestaat. Als het token werkt maar de portal toegankelijk is vanaf het verkeerde netwerk, is de MFA-configuratie slechts een deel van het probleem opgelost.

Logboeken en operationele controle

Na de uitrol moet u controleren of MFA-gebeurtenissen tijdens bedrijf kunnen worden getraceerd. Dit is belangrijk voor ondersteuningsgevallen, beveiligingsbeoordelingen en respons op incidenten.

Nuttige controlepunten:

• Controleer op authenticatiegebeurtenissen in de Logviewer.
• Onderscheid mislukte logins van onjuist wachtwoord, onjuiste OTP en verlopen OTP.
• Document VPN portal en externe toegangstesten met tijd en gebruiker.
• Controleer voor externe RADIUS ook de RADIUS-server, NPS-logboeken of logboeken van de identiteitsprovider.
• Plan voor langere opslag Central Reporting of Syslog/SIEM.

Voor lokale logbestanden en servicetoewijzingen is Sophos Firewall Probleemoplossing: Services en logboeken geschikt. Als authenticatie en portalgebeurtenissen op lange termijn moeten worden geëvalueerd, is Sophos Firewall verzend Syslog naar SIEM geschikt.

Bij Sophos Central, Syslog of SIEM moet men na de rollout niet alleen succesvolle logins controleren. Vooral herhaalde mislukte pogingen op WebAdmin, User Portal, VPN Portal en SSL VPN zijn interessant, omdat ze laten zien of een dienst onnodig breed bereikbaar is of dat gebruikers met het OTP-formaat worstelen.

Problemen oplossen

OTP-code wordt niet geaccepteerd

Controleer eerst de systeemtijd van de firewall en de tijd van de smartphone. TOTP is tijdsafhankelijk. Zelfs een significante afwijking kan ertoe leiden dat geldige codes worden afgewezen.

Onder Authentication > Multi-factor authentication kan men uitgegeven tokens controleren. Wanneer een afzonderlijk token telkens net fout ligt, moet men niet direct de volledige MFA-configuratie wijzigen. Eerst token-tijddrift, gebruikte app, hash-algoritme en tijdstap controleren.

Gebruiker ziet QR-code niet

De gebruiker moet in aanmerking komen voor MFA en inloggen op de juiste portal. Daarnaast moet worden gecontroleerd of de gebruiker wordt gevonden via de verwachte authenticatiebron.

Als de User Portal is uitgeschakeld, kan de gebruiker het token mogelijk niet zelf instellen. Vervolgens moet het portaal tijdelijk toegankelijk worden gemaakt of moet het token administratief worden aangemaakt.

Portaal kan niet worden bereikt via Device Access

Als gebruikers hun token niet kunnen instellen, ook al is MFA correct geactiveerd, mag men niet eerst het token verwijderen. Vaak is het benodigde portal via System > Administration > Device access of een Local-Service-ACL-regel niet bereikbaar vanuit het huidige netwerk.

Controleer eerst:

• Welke portal wordt gebruikt voor het instellen van tokens?
• Uit welke zone of bron komt de gebruiker?
• Wordt de toegang opzettelijk toegestaan ​​of per ongeluk geblokkeerd?
• Is er een smallere ACL-uitzondering in plaats van een brede release?

Beheerder is geblokkeerd

Gebruik in dit geval de voorbereide fallback-toegang. Als er geen terugval bestaat, moet de toegang worden beoordeeld via console-, ondersteunings- of herstelpaden, afhankelijk van de situatie.

MFA werkt niet voor externe toegang

Controleer of de configuratie voor externe toegang dezelfde gebruikersgroep gebruikt waarvoor MFA is geactiveerd. Vaak ligt de fout niet bij MFA zelf, maar bij verschillende groepen in VPN en authenticatieregels.

Klantprofielen moeten ook overeenkomen met de huidige configuratie. Na het aanbrengen van wijzigingen in VPN Portal, SSL VPN, IPsec Remote Access, Entra SSO of RADIUS moeten de getroffen Sophos Connect-profielen opnieuw worden geïmporteerd of opnieuw worden gedistribueerd.

Gebruiker voert alleen het wachtwoord in

Als er geen apart OTP-veld wordt weergegeven, moet de gebruiker het wachtwoord en de OTP-code achter elkaar invoeren. Dit is een van de meest voorkomende ondersteuningsgevallen na het activeren van Sophos OTP.

Externe MFA werkt niet betrouwbaar

Voor op RADIUS gebaseerde MFA-oplossingen moeten time-outs, uitdagingsgedrag en groepen netjes passen. Als Push-MFA, Call-MFA of uitdagingsreacties worden gebruikt, moet u het hele inlogproces testen met de betreffende client.

Belangrijk is bovendien de portalgrens: niet elke Sophos-login ondersteunt elk RADIUS-challenge-gedrag even goed. Vooral VPN Portal, SSL VPN, Sophos Connect, WebAdmin en Captive Portal moeten afzonderlijk met echte clients worden getest. Een succesvolle RADIUS-test in de serverconfiguratie is geen bewijs voor de productieve Remote-Access-login.

MFA is geactiveerd voor de verkeerde groep

Als MFA voor sommige gebruikers wel werkt en voor andere niet, moet u groepen eerst technisch vergelijken. Niet alleen de zichtbare weergavenamen zijn relevant, maar ook de feitelijk geïmporteerde of gematchte groepen uit AD, LDAP, RADIUS of Entra ID. Een gebruiker kan zich succesvol authenticeren en toch niet in de groep terechtkomen waarvoor MFA vereist is.

Operationele checklist en aanbeveling

Na technische activering heeft de MFA een eenvoudig bedieningsproces nodig: wie reset tokens, wie controleert logs en hoe wordt gecontroleerd dat portalen niet onnodig breed toegankelijk zijn?

Controlelijst voor operaties

• Systeemtijd en NTP gecontroleerd.
• Pilotgroep gedefinieerd en getest.
• MFA niet direct voor alle beheerders tegelijk geactiveerd.
• Toegang tot tweede beheerder en breekglas gedocumenteerd.
• Device Access en Local Service ACL getest voor WebAdmin, User Portal, VPN Portal en SSL VPN.
• Toegang vanaf toegestane en verboden bronnetwerken getest.
• Gebruiker geïnformeerd over wachtwoord+OTP-gedrag.
• Token-resetproces gedocumenteerd voor verloren smartphones.
• Authenticator-app, hash-algoritme en tokenmigratie gedocumenteerd.
• Toegang op afstand getest met echte klanten en huidige profielen.
• RADIUS/Entra time-outs getest als externe MFA wordt gebruikt.
• Logboeken en centrale opslag gecontroleerd.

Bedrijfsaanbeveling

MFA moet standaard zijn voor beheerderstoegang. MFA is vooral belangrijk voor WebAdmin, VPN Portal en alle gebruikers met autorisatie voor externe toegang.

Voor kleine omgevingen is de eigen OTP-functie van Sophos vaak voldoende. In Microsoft 365- of Entra ID-omgevingen kan een externe MFA via RADIUS handiger zijn omdat gebruikers geen tweede MFA-wereld hoeven te leren.

Ongeacht de MFA variant geldt het volgende: beperk eerst de toegang met ACL-regels, test Admin-MFA zorgvuldig, informeer gebruikers over wachtwoord + token en rol het pas daarna breed uit.

Veelgestelde vragen