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.

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.

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

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. Configuratie opslaan.

Als gebruikers hun token zelf moeten instellen, moeten ze toegang hebben tot een portal waar de QR-code wordt weergegeven. In veel omgevingen is hiervoor het User Portal of VPN Portal relevant. 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:

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

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.

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

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

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.

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.

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

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.

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:

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:

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

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.

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