Sophos Firewall WAF beveiligen met MFA

Met Sophos Firewall WAF MFA kun je webapplicaties die via de Web Application Firewall worden gepubliceerd, extra beveiligen met Multi-Factor Authentication. Dit is vooral nuttig voor interne portalen, beheerdersinterfaces, klantgebieden of partnertoegang, die weliswaar via HTTPS bereikbaar moeten zijn, maar niet alleen door de applicatie zelf beschermd moeten worden.

WAF-MFA vervangt geen veilige applicatie, geen patchbeheer en geen goed toegangsbeheer. Het is een voorliggende beschermingslaag op de firewall. De firewall controleert eerst de aanmelding en de tweede factor voordat de toegang tot de beveiligde webserver wordt doorgestuurd.

De versie is belangrijk: geïntegreerde MFA voor WAF is een SFOS 22-functie. Op oudere firmwareversies moeten WAF-publicaties met andere architecturen worden gepland, bijvoorbeeld externe authenticatie, een dedicated reverse proxy, VPN of ZTNA.

Voor de basispublicatie van een webserver via WAF volg je eerst de handleiding Sophos Firewall WAF: Webserver veilig publiceren. Dit artikel richt zich op de voorliggende authenticatie en MFA.

Wanneer WAF-MFA zinvol is

WAF-MFA is vooral krachtig wanneer een webapplicatie vanuit het internet bereikbaar moet zijn, maar niet openbaar voor alle bezoekers bedoeld is.

Typische gebruikssituaties:

• interne portalen met externe toegang
• beheerdersinterfaces van bedrijfsapplicaties
• partner- of klantenportalen met een beperkte gebruikersgroep
• legacy-webapplicaties zonder eigen sterke MFA
• applicaties waarbij extra toegangsbeveiliging voor de backend gewenst is

Voor openbare websites, winkels of informatiesites is WAF-MFA meestal niet geschikt, omdat elke bezoeker eerst een firewall-aanmelding zou zien. Bij complexe privéapplicaties kan ZTNA, SSE of een speciale reverse proxy zinvoller zijn dan WAF-MFA. Als WebDAV nodig is, moet je extra voorzichtig zijn: Sophos WAF ondersteunt WebDAV niet goed, wat relevant kan zijn voor applicaties zoals Nextcloud.

Wanneer WAF-MFA niet voldoende is

WAF-MFA is een voorliggende toegangslaag. Deze laag beantwoordt echter niet elke architectuurvraag. Vooral bij kritieke portalen moet je bewust beslissen of de applicatie überhaupt openbaar bereikbaar moet zijn.

• Applicatie is alleen bedoeld voor enkele interne gebruikers: VPN, ZTNA, vaste bronnetwerken of een niet-openbare publicatie controleren.
• Applicatie bevat bijzonder gevoelige gegevens: Backend-rechten, logging, audit trail en applicatiesessies aanvullend controleren.
• Applicatie heeft WebDAV of speciale protocollen nodig: WAF-compatibiliteit voor de rollout testen of een andere architectuur kiezen.
• Externe partners hebben zelden toegang: Token-uitrol, supportproces en fallback bijzonder duidelijk documenteren.
• Backend heeft eigen aanmelding en rollen: WAF-MFA alleen als extra laag beschouwen, niet als vervanging voor backend-rollen.

Als een portal wereldwijd bereikbaar blijft, mag MFA niet de enige maatregel zijn. Vaste bronnetwerken, landbeperkingen, Threat Feeds, beschermingsprofielen en goede backend-patches verminderen het risico verder.

Vereisten

Voor de installatie moeten deze punten duidelijk zijn:

• De webapplicatie is al gepland of gepubliceerd via een WAF-regel.
• De firewall draait op SFOS 22 of nieuwer.
• Gebruikers of groepen zijn aanwezig op de firewall, bijvoorbeeld lokaal, via AD, LDAP of RADIUS.
• De gebruikers kunnen hun OTP-token instellen.
• De systeemtijd van de firewall is correct en NTP werkt.
• Voor de WAF-regel wordt HTTPS met een passend certificaat gebruikt.
• Het is duidelijk of de backend-webserver eigen authenticatie nodig heeft of dat de firewall de aanmelding volledig moet overnemen.
• Een testgebruiker en een administratieve fallback-toegang zijn aanwezig.

⚠️ MFA voor WAF moet eerst met een pilotgroep worden getest. Een verkeerde combinatie van MFA-groep, WAF-authenticatiebeleid en backend-authenticatie kan legitieme gebruikers buitensluiten of een applicatie schijnbaar “kapot” maken.

Pilot, fallback en verantwoordelijkheden plannen

WAF-MFA werkt voor de eigenlijke applicatie. Daarom moet je de uitrol niet behandelen als een normale firewall-regel, maar als een wijziging in het aanmeldproces van de applicatie. Gebruikers zien eerst de aanmelding van de Sophos Firewall en pas daarna, afhankelijk van de backend, de eigenlijke applicatie.

Voor het inschakelen moeten deze punten vaststaan:

• Welke gebruikersgroep test eerst?
• Wie kan de toegang weer uitschakelen als de aanmelding mislukt?
• Is er een tweede admin-toegang die niet afhankelijk is van dezelfde WAF-regel, hetzelfde portal of dezelfde testgebruiker?
• Welke applicatiedelen moeten na succesvolle login worden getest?
• Wie controleert reverseproxy.log, Log Viewer en backend-logs bij fouten?
• Hoe worden gebruikers geïnformeerd over token, sessieverloop en mogelijke tweede backend-aanmelding?

Een veelgemaakte planningsfout is het vermengen van firewall-authenticatie en backend-authenticatie. De WAF kan gebruikers voor de backend controleren. Dat betekent echter niet automatisch dat de applicatie zelf geen eigen aanmelding, rollencontrole of sessiebeheer meer nodig heeft. Vooral bij beheerdersportalen en klantgegevens moet de backend-rechten bewust behouden blijven.

Als de gepubliceerde dienst alleen voor enkele personen bedoeld is, moet je naast MFA ook de bronnen beperken. Voor de basispublicatie en bronbeperking past Sophos Firewall WAF: Webserver veilig publiceren. Als gebruikersrechten of Remote-Access-MFA algemeen gepland worden, helpt MFA voor Sophos Firewall WebAdmin, VPN Portal en Remote Access activeren.

Een rollback moet voor het inschakelen voorbereid zijn. Praktisch betekent dit: oude werkende toegangsmanier documenteren, WAF-regel en authenticatiebeleid benoemen, verantwoordelijke persoon vaststellen en een tijdstip kiezen waarop gebruikersfeedback en logcontrole mogelijk zijn. Als de applicatie bedrijfskritisch is, moet WAF-MFA eerst voor een testdomein, een pilotgroep of een onderhoudsvenster worden geactiveerd.

Bouwstenen van de configuratie

Voor WAF-MFA moeten meerdere instellingen op elkaar aansluiten:

• MFA-instelling: Bepaalt welke gebruikers MFA gebruiken en of Web application firewall wordt beschermd.
• WAF Authentication Policy: Bepaalt loginmodus, gebruikers/groepen, template en sessiegedrag.
• WAF rule: Verbindt de gepubliceerde webserver met de Authentication Policy.
• Backend authentication forwarding: Bepaalt of de firewall inloggegevens aan de webserver doorgeeft.
• Token-uitrol: Zorgt ervoor dat gebruikers hun OTP-code daadwerkelijk kunnen genereren.

Het belangrijkste verschil: MFA wordt niet alleen globaal geactiveerd. De betreffende WAF-regel moet ook een passend authenticatiebeleid gebruiken.

MFA voor WAF activeren

Het menupad is:

Authentication > Multi-factor authentication

Stappen:

1. Onder One-time password (OTP) kies je ofwel All users of Specific users and groups.
2. Voeg bij Specific users and groups de betreffende gebruikers of groepen toe.
3. Activeer Generate OTP token with next sign-in als gebruikers hun token zelf bij de volgende login moeten instellen.
4. Onder Require MFA for activeer je de optie Web application firewall.
5. Stel OTP hash algorithm en indien nodig OTP timestep settings bewust in.
6. Configuratie opslaan.

Als Generate OTP token with next sign-in actief is, wordt User portal automatisch geselecteerd als service voor de eerste QR-codeconfiguratie. Gebruikers moeten de QR-code in een portal kunnen zien voordat de eerste WAF-MFA-login realistisch werkt. Afhankelijk van de omgeving kunnen ook VPN Portal of WebAdmin relevant zijn. De algemene MFA-planning is beschreven in MFA voor Sophos Firewall WebAdmin, VPN Portal en Remote Access activeren.

Token-uitrol en gebruikerscommunicatie voorbereiden

WAF-MFA faalt in de praktijk vaak niet door de eigenlijke WAF-regel, maar door de token-uitrol. Gebruikers moeten weten waar de QR-code verschijnt, welke app gebruikt moet worden, hoe lang een sessie geldig is en of er na de firewall-aanmelding nog een tweede aanmelding bij de applicatie volgt.

Voor het inschakelen van de productieve WAF-regel moet je vaststellen:

• Token-creatie: Waar stelt de gebruiker de OTP-token in?
• Portal-toegang: Is User Portal of VPN Portal bereikbaar voor de betreffende gebruikers?
• Authenticator-app: Welke app is goedgekeurd en met het gekozen algoritme getest?
• Fallback: Wie kan een verloren of defect token resetten?
• Noodcodes: Is duidelijk of en hoe extra eenmalige passcodes in supportgevallen mogen worden uitgegeven?
• Supportcase: Welke informatie heeft de helpdesk nodig bij loginproblemen?
• Communicatie: Welke loginvolgorde zien gebruikers vanaf de go-live?

Als Generate OTP token with next sign-in wordt gebruikt, moet de eerste login gecontroleerd worden getest. Hierbij is het belangrijk of gebruikers de QR-code in het verwachte portal zien en of ze daarna met wachtwoord plus OTP succesvol toegang krijgen tot de WAF-applicatie. De portalen zelf zijn beschreven in Sophos Firewall Portalen: WebAdmin, User Portal en VPN Portal indelen.

Voor veel firewallservices wordt de OTP-code verwerkt als combinatie van wachtwoord en passcode. Gebruikerscommunicatie en het helpdesk-runbook moeten daarom duidelijk aangeven welk invoerscherm gebruikers werkelijk zien en of wachtwoord en OTP gescheiden of gecombineerd moeten worden ingevoerd. Bij WAF-MFA met Form-gebaseerde login is dit extra belangrijk, omdat een tweede backend-login anders snel als “MFA defect” wordt gezien.

Sophos Authenticator moet niet meer als nieuwe standaardapp worden gepland, omdat de app sinds 2022 End of Life is. In de praktijk moeten Intercept X for Mobile, Google Authenticator, Microsoft Authenticator, Duo Mobile, Okta Verify of een intern goedgekeurde app worden getest. Niet alleen de naam van de app telt, maar of deze het gekozen algoritme, de timestep en de QR-code van de firewall correct ondersteunt.

Voor helpdesk en operatie moet minimaal gedocumenteerd zijn:

• gepubliceerde hostnaam van de WAF-applicatie
• betreffende gebruikersgroep
• gebruikt authenticatiebeleid
• gebruikte OTP-algoritme
• toegestane authenticator-app
• procedure voor token-reset
• verwachte melding bij verkeerd wachtwoord of verkeerde OTP
• loglocaties voor eerste controle: Log Viewer en reverseproxy.log

Vooral bij externe partners of zelden gebruikte portalen moet de eerste login niet pas in een productieve noodsituatie plaatsvinden. Een korte pilot met normale gebruikers onthult vaak problemen die beheerders in hun eigen test niet zien: afwijkende authenticator-app, ontbrekende portaltoegang, onduidelijke tweede backend-aanmelding of sessietime-outs die voor de applicatie te kort zijn.

WAF Authentication Policy aanmaken

Het menupad is:

Web server > Authentication policies

Voor WAF-MFA moet de clientmodus op Form worden ingesteld. Bij formuliergebaseerde authenticatie kan de firewall de aanmelding via een formulier en sessies beheren.

Stappen:

1. Open Add.
2. Geef een duidelijke naam, bijvoorbeeld WAF_MFA_Portal_Users.
3. Kies bij Mode de optie Form.
4. Kies een passend Authentication template.
5. Selecteer de gebruikers of groepen die toegang krijgen tot deze WAF-publicatie.
6. Kies bewust de Authentication forwarding mode.
7. Stel Session timeout en Session lifetime in passend bij de applicatie.
8. Opslaan.

Authentication forwarding correct kiezen

De Authentication forwarding mode bepaalt wat er tussen firewall en backend gebeurt.

• None: De firewall authenticeert de gebruiker, de webserver ontvangt geen inloggegevens.
• Basic: De firewall geeft gebruikersnaam en wachtwoord via HTTP Basic Authentication door aan de backend.

Als de applicatie geen eigen authenticatie nodig heeft of de voorliggende firewall-aanmelding voldoende moet zijn, is None vaak schoner. Als de backend zelf HTTP Basic Authentication verwacht, moet de forwarding-modus bij de applicatie passen.

Bij None moet men ook controleren of Remove basic header moet worden ingesteld. Daarmee wordt voorkomen dat een door de client verzonden Basic Authentication-header onnodig naar de webserver wordt doorgestuurd. Dit is vooral belangrijk wanneer oude clients, opgeslagen browsergegevens of eerdere publicaties nog Basic-headers genereren.

⚠️ Basic Authentication moet alleen met HTTPS worden gebruikt. Bovendien moet duidelijk zijn of de backend echt de door de firewall doorgegeven inloggegevens moet verwerken.

De modus Basic is niet gewoon een gemakkelijkere variant van Form-sessies. Basic Authentication maakt geen dedicated sessiecookies aan en een nette logout via de firewall is niet hetzelfde als bij Form-gebaseerde login. Voor WAF-MFA en beheersbaar sessiegedrag is Form daarom het schonere uitgangspunt.

Authentication Policy in de WAF-regel gebruiken

De WAF-regel wordt bewerkt onder Rules and policies > Firewall rules. De actie is Protect with web server protection.

In de betreffende WAF-regel moeten deze punten op elkaar aansluiten:

• Juiste Hosted address en luisterpoort.
• Juiste domein en passend HTTPS-certificaat.
• Juiste beveiligde webserver.
• Gewenst Authentication policy geselecteerd.
• Gebruikersgroep in het authenticatiebeleid past bij de MFA-groep.
• Toegangsbeperkingen via Allowed client networks, landen of Threat Feeds zijn bewust ingesteld.

Voor openbare of sterk blootgestelde portalen mag MFA niet de enige beveiligingsmaatregel zijn. Land- en bronbeperking is beschreven in Sophos Firewall: Landen en kwaadaardige IP’s blokkeren. Voor dynamische blokkeerlijsten past Sophos Firewall Threat Feeds.

Sessies en time-out plannen

Bij formuliergebaseerde WAF-authenticatie werkt de firewall met sessies. In het authenticatiebeleid stel je in:

• Session timeout: na welke inactiviteit gebruikers zich opnieuw moeten aanmelden
• Session lifetime: hoe lang een aanmelding maximaal geldig blijft
• Globale WAF-sessielimiet niet meegenomen: Form-gebaseerde reverse-proxy-logins kunnen bij veel gebruikers of meerdere portalen limieten raken.

Daarnaast is er onder Web server > General settings het maximale aantal gelijktijdige sessies voor formuliergebaseerde reverse-proxy-authenticatie. De standaardwaarde is 25,000, het ondersteunde bereik is 100 tot 100,000.

Korte sessies verhogen de veiligheid, maar kunnen gebruikers storen. Zeer lange sessies zijn comfortabeler, maar verhogen het risico dat een gestolen of gedeelde browsertoegang langer bruikbaar blijft. Voor beheerdersportalen moet je eerder conservatief beginnen en het gedrag in de praktijk observeren.

Als zeer veel gebruikers of meerdere WAF-portalen dezelfde firewall gebruiken, moet de globale sessielimiet niet pas bij foutmeldingen worden gecontroleerd. Form-gebaseerde WAF-authenticatie is een gedeelde reverse-proxy-bedrijfsparameter en hoort daarom in capaciteits- en monitoringoverwegingen.

OTP-algoritme en authenticator-app

SFOS 22 ondersteunt naast SHA1 ook SHA256 en SHA512 voor OTP-tokens. Dit is vanuit veiligheidsoogpunt zinvol, maar werkt alleen als de gebruikte authenticator-app het gekozen algoritme ondersteunt.

Belangrijke punten:

• SHA256 of SHA512 zijn veiliger dan SHA1.
• Niet elke authenticator-app ondersteunt deze algoritmen in deze context.
• Microsoft Authenticator kan bij SHA256 of SHA512 wel de QR-code scannen, maar de aanmelding kan daarna mislukken.
• Als het algoritme wordt gewijzigd, moeten oude tokens worden verwijderd en opnieuw worden gescand.
• Wijzigingen aan de token-timestep gelden alleen voor nieuw gegenereerde tokens en moeten passen bij de gebruikte app.

Voor productieve uitrol moet je de gewenste app en het algoritme met een kleine pilotgroep testen. Pas daarna moeten bestaande gebruikers breed worden gemigreerd.

Als een gebruiker de app verliest of het algoritme wordt gewijzigd, is het vaak niet genoeg om de gebruikerscommunicatie te herhalen. Onder Authentication > Multi-factor authentication > Issued tokens kunnen tokens worden gereset of extra eenmalige codes worden gegenereerd. Dit proces moet intern geregeld zijn omdat het een sterke veiligheidsimpact heeft.

Testplan na de installatie

Na de configuratie moet je niet alleen controleren of de inlogpagina verschijnt. Het is belangrijk om het volledige toegangspad te testen.

1. Gebruik een externe browser of extern testnetwerk.
2. Open de WAF-URL met een gebruiker uit de toegestane groep.
3. Test login met correct wachtwoord en OTP.
4. Test login met onjuiste OTP.
5. Test gebruiker buiten de toegestane groep.
6. Controleer sessieverloop na inactiviteit.
7. Controleer backend-functie van de applicatie.
8. Controleer Log Viewer en reverseproxy.log op opvallendheden.
9. Controleer logout, opnieuw inloggen en sessieverloop met dezelfde browser.
10. Test met een tweede hostname of alternatief pad als de applicatie meerdere WAF-regels gebruikt.

Voor de logbestanden helpt Sophos Firewall Troubleshooting: Services en Logs. WAF-gebeurtenissen hangen meestal aan de Reverse Proxy en verschijnen daarnaast in de Log Viewer.

Voor de acceptatie moet elke testgeval aan een zichtbaar resultaat worden gekoppeld:

• Gebruiker: Firewall-login verschijnt, OTP wordt gevraagd, daarna opent de verwachte applicatie.
• Sophos Firewall: Log Viewer en reverseproxy.log tonen toegestane of geweigerde WAF-authenticatie.
• Authenticatiebron: AD, LDAP, RADIUS of lokale gebruikersbron toont de verwachte succesvolle of mislukte login.
• Backend: Applicatie bereikt de juiste gebruikers- of gaststatus en toont geen onverwachte tweede foutpagina.

Als alleen de browser succesvol lijkt, maar er geen passende logs zichtbaar zijn, is de acceptatie onvolledig. Dan moet je controleren of de juiste WAF-regel overeenkomt, of het authenticatiebeleid echt actief is en of logs op de verwachte locatie terechtkomen.

Go-live en werking na de activering

Na een succesvolle test moet WAF-MFA niet zomaar breed worden ingeschakeld en daarna worden vergeten. De eerste uren na de livegang zijn belangrijk, omdat echte gebruikers andere browsers, andere authenticator-apps, opgeslagen wachtwoorden, oude bladwijzers en andere sessiestatussen meebrengen dan een beheerderstest.

Voor de livegang is een klein bedrijfsplan zinvol:

• Uitrolgroep: eerst pilotgroep, daarna andere gebruikersgroepen.
• Supportvenster: Helpdesk of verantwoordelijke beheerders tijdens de eerste logins bereikbaar houden.
• Monitoring: Log Viewer, reverseproxy.log en authenticatiebron observeren.
• Token-reset: duidelijke procedure voor verloren of verkeerd ingestelde OTP-tokens.
• Sessiegedrag: Session timeout en Session lifetime na werkelijk gebruik controleren.
• Terugvalpad: WAF-regel, Authentication Policy en wijzigingsstappen gedocumenteerd houden.

Bij bedrijfskritische applicaties moet je de livegang niet plannen op een moment waarop niemand inlogproblemen goed kan controleren. Beter is een gecontroleerd venster met testgebruikers uit verschillende groepen, daarna een korte evaluatie van de logs en pas daarna de uitbreiding naar andere gebruikers.

Na enkele dagen moet de configuratie opnieuw worden gecontroleerd:

• Zijn er gebruikers die MFA omzeilen omdat ze via een andere WAF-regel of een andere URL toegang hebben?
• Wordt de toegang nog steeds alleen voor de geplande groepen toegestaan?
• Passen sessieduur en inactiviteits-time-out bij de applicatie?
• Worden geweigerde logins en tokenproblemen in de praktijk daadwerkelijk gezien?
• Zijn er ondersteuningsgevallen die wijzen op onduidelijke gebruikerscommunicatie of een verkeerde authenticator-app?
• Zijn oude testregels, testdomeinen of tijdelijke uitzonderingen weer verwijderd?

Deze nazorg is vooral belangrijk als meerdere hostnamen, paden of WAF-regels naar dezelfde applicatie wijzen. Anders kan het gebeuren dat een pad netjes met MFA is beveiligd, maar een tweede pad nog steeds zonder voorliggende authenticatie bereikbaar blijft.

Typische fouten

• Web application firewall onder Require MFA for niet geactiveerd: WAF-login vraagt geen tweede factor op.
• Authentication Policy gebruikt niet Form: MFA-gedrag past niet bij de verwachte WAF-configuratie.
• WAF-regel gebruikt geen Authentication Policy: Gebruikers bereiken de applicatie zonder voorliggende aanmelding.
• MFA-groep en WAF-Policy-groep verschillen: Gebruikers worden niet zoals verwacht gevraagd of geweigerd.
• Backend verwacht eigen Basic Authentication, Forwarding staat op None: Firewall-login werkt, backend weigert toegang.
• Forwarding staat op Basic, backend verwacht geen authenticatie: Applicatie reageert onverwacht of ziet onnodige headers.
• OTP-app ondersteunt het gekozen hash-algoritme niet: QR-code wordt gescand, login mislukt toch.
• Sophos Authenticator als nieuwe standaardapp gepland: De app is EOL en mag niet meer als basis voor een nieuwe rollout worden gebruikt.
• Session lifetime te lang: Gebruikers blijven langer aangemeld dan operationeel gewenst.
• Fallback-toegang hangt van dezelfde WAF-regel af: Beheerders kunnen de wijziging bij een fout niet meer goed terugdraaien.
• Token-uitrol is niet getest: Gebruikers falen bij de eerste login, hoewel de WAF-regel technisch correct is.
• Tweede URL of tweede WAF-regel blijft zonder MFA actief: Gebruikers omzeilen onbedoeld de voorliggende MFA.
• Tijdelijke pilotuitzonderingen worden niet verwijderd: De productieve beveiliging is inconsistent en moeilijk te auditen.

Problemen oplossen

MFA wordt niet gevraagd

Controleer eerst of Web application firewall onder Require MFA for is geactiveerd. Controleer daarna of de WAF-regel echt een authenticatiebeleid gebruikt en of dit beleid de verwachte gebruikers of groepen bevat.

Login werkt, maar de applicatie opent niet

Dan ligt het probleem vaak na de firewall-aanmelding. Controleer backend-bereikbaarheid, certificaat, hostheader, pad, beschermingsbeleid en authenticatie-forwarding. Als de backend eigen authenticatie verwacht, moet de forwarding-modus daarbij passen.

Gebruiker kan zich na algoritmewijziging niet aanmelden

Als van SHA1 naar SHA256 of SHA512 is overgeschakeld, moeten bestaande tokens worden verwijderd en opnieuw worden gescand. Bovendien moet de authenticator-app het nieuwe algoritme ondersteunen.

Wachtwoord en OTP worden aan de backend doorgegeven

Bij WAF-MFA moet je controleren of de firewallversie actueel is. In de SFOS-22.0-release-opmerkingen is een opgelost WAF-probleem gedocumenteerd waarbij de OTP-code niet uit het wachtwoord werd verwijderd voordat gegevens aan de backend werden doorgegeven.

Backend vraagt na succesvolle MFA opnieuw om login

Als na een upgrade naar SFOS 22 de MFA-aanmelding succesvol is, maar de backend toch opnieuw een login vraagt, moet men niet meteen gebruikers, tokens of wachtwoordregels wijzigen. In de Sophos Known-Issues-lijst is met NC-177509 een WAF/MFA-probleem gedocumenteerd waarbij form-based WAF-MFA met Authentication forwarding tot een extra backend-login kan leiden.

Controleren:

• WAF Authentication Policy gebruikt Form.
• Authentication forwarding mode is actief en past bij de backend-applicatie.
• De betrokken WAF-regel gebruikt precies deze Authentication Policy.
• De fout treedt op na succesvolle MFA, niet al bij de firewall-login.
• reverseproxy.log, Log Viewer en Backend-Access-Log dekken hetzelfde testmoment af.
• De gebruikte SFOS-versie en bekende aanwijzingen uit de Sophos Known Issues List zijn gecontroleerd.

Als workaround moet niet blind naar minder bescherming worden omgeschakeld. Eerst moet duidelijk zijn of de backend werkelijk doorgestuurde inloggegevens verwacht of dat Authentication forwarding mode op None gezet kan worden. Bij productieve portalen moeten testgebruikers, rollback, supportcase en gebruikerscommunicatie samen gepland worden.

Te veel of oude sessies

Controleer sessietime-out, sessieduur en de globale WAF-sessie-instellingen. In productieve omgevingen moet duidelijk zijn of lange sessies gewenst zijn of dat gebruikers na inactiviteit snel opnieuw moeten worden geauthenticeerd.

Checklist

• WAF-regel is gedocumenteerd en extern getest.
• HTTPS-certificaat past bij de gepubliceerde hostnaam.
• MFA geldt voor de juiste gebruikersgroep.
• Require MFA for > Web application firewall is geactiveerd.
• WAF Authentication Policy gebruikt Form.
• Authenticatie-forwarding past bij de backend-applicatie.
• Token-uitrol, portaltoegang en helpdeskprocedure zijn voorbereid.
• Sessietime-out en sessieduur zijn bewust ingesteld.
• OTP-app en hash-algoritme zijn getest.
• Fallback-admin-toegang is aanwezig.
• Rollback en verantwoordelijke persoon zijn gedocumenteerd.
• Authenticatiebron en backend-login zijn apart gecontroleerd.
• Log Viewer en reverseproxy.log zijn na de test gecontroleerd.
• Go-live-ondersteuningsvenster en token-resetprocedure zijn vastgesteld.
• Alternatieve hostnamen, paden en WAF-regels zijn op MFA-omzeiling gecontroleerd.
• Tijdelijke pilotuitzonderingen zijn na de uitrol verwijderd.

Veelgestelde vragen