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 en genomtänkt behörighetsmodell. Det är ett skyddslager på brandväggen framför applikationen. Brandväggen kontrollerar först inloggningen och den andra faktorn innan åtkomst till den skyddade webbservern vidarebefordras.

Versionen är viktig: integrerad MFA för WAF är en SFOS 22-funktion. På äldre firmwareversioner måste WAF-publiceringar planeras med andra arkitekturer, till exempel extern autentisering, dedikerad reverse proxy, VPN eller ZTNA.

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å autentisering före backendåtkomst och MFA.

Användning och planering

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. Sophos WAF stöder inte WebDAV; applikationer som Nextcloud är därför inte stödda WAF-publiceringar. Planera en annan arkitektur med lämpliga brandväggsregler och eget åtkomstskydd; publicering utan WAF behåller inte automatiskt dess autentisering eller applikationsskydd.

WAF skyddar på Layer 7 mot bland annat manipulation av cookies, URL:er och formulär. Webbservern, Protection Policy och Authentication Policy kopplas samman genom WAF-regeln; högst 60 WAF-regler stöds. Hantera WAF-tjänsten under System services > Services. En omstart påverkar publicerade applikationer och är inte den första åtgärden vid ett enskilt inloggningsfel.

När WAF-MFA inte räcker

WAF-MFA är ett åtkomstlager framför applikationen. 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.

• Applikationen är endast avsedd för några få interna användare: Kontrollera VPN, ZTNA, fasta källnät eller en icke-offentlig publicering.
• Applikationen innehåller särskilt känsliga data: Kontrollera även backend-behörigheter, loggning, granskningsspår och applikationssessioner.
• Applikationen behöver WebDAV: Välj en annan arkitektur; en pilot gör inte bristande WAF-stöd till en stödd lösning. Kontrollera kompatibiliteten separat före utrullning för andra specialprotokoll.
• Externa partners har sällan åtkomst: Dokumentera token-utdelning, supportprocess och fallback särskilt tydligt.
• Backend har egen inloggning och roller: Betrakta WAF-MFA endast som ett ytterligare lager, inte som ersättning för backend-roller.

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 korrekt patchhantering av backend minskar risken ytterligare.

Förutsättningar

Innan installationen bör dessa punkter klargöras:

• Webbapplikationen är redan planerad eller publicerad via en WAF-regel.
• Brandväggen kör SFOS 22 eller senare.
• 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.

Konfiguration

Konfigurationskomponenter

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

• MFA-inställning: Bestämmer vilka användare som använder MFA och om Web application firewall skyddas.
• WAF Authentication Policy: Definierar inloggningsläge, användare/grupper, mall och sessionsbeteende.
• WAF-regel: Kopplar den publicerade webbservern till autentiseringspolicyn.
• Vidarebefordran av backend-autentisering: Bestämmer om brandväggen vidarebefordrar inloggningsuppgifter till webbservern.
• Token-utdelning: Säkerställer att användare faktiskt kan generera sin OTP-kod.

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

Menysökvägen ä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. Sätt OTP hash algorithm och vid behov OTP timestep settings medvetet. Standardvärdena är 30 sekunder för Default token timestep, 2 för Maximum verification code offset och 10 för Maximum initial verification code offset.
6. Spara konfigurationen.

När Generate OTP token with next sign-in är aktivt väljs User portal automatiskt. Användare loggar först in på VPN portal eller User portal och skannar QR-koden där. Standardadministratören kan i stället använda WebAdmin-konsolen när MFA krävs för den administratörens WebAdmin-inloggning. Detta onboardingsteg måste fungera före den första WAF-åtkomsten. Den allmänna MFA-planeringen beskrivs i Aktivera MFA för Sophos Firewall WebAdmin, VPN Portal och Remote Access.

De två offsetvärdena är inte den normala lösningen på en felaktig klocka. Med ett tidssteg på 30 sekunder accepterar ett Maximum verification code offset på 2 exempelvis en oanvänd kod från de föregående 60 sekunderna. Ett större fönster gör inloggningen mer tolerant men förlänger också giltigheten för äldre koder. Korrigera först NTP och telefonens klocka och ändra bara offset av en dokumenterad anledning.

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 WAF-regeln aktiveras i produktion bör man fastställa:

• Token-skapande: Var ställer användaren in OTP-token?
• Portalåtkomst: Är User Portal eller en annan avsedd väg till QR-koden tillgänglig för de berörda användarna?
• Authenticator-app: Vilken app är godkänd och testad med den valda algoritmen?
• Fallback: Vem kan återställa en förlorad eller defekt token?
• Nödkoder: Är det klart om och hur extra engångskoder får utfärdas i supportfall?
• Supportfall: Vilken information behöver helpdesk vid inloggningsproblem?
• Kommunikation: Vilken inloggningssekvens ser användare från driftsättningen?

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 många brandväggstjänster behandlas OTP-koden som en kombination av lösenord och passcode. Användarkommunikation och helpdesk-runbook bör därför tydligt ange vilken inmatningsbild användare faktiskt ser och om lösenord och OTP ska anges separat eller kombinerat. Vid WAF-MFA med Form-baserad inloggning är detta särskilt viktigt, eftersom en andra backend-inloggning annars snabbt feltolkas som “MFA trasigt”.

Sophos Authenticator bör inte längre planeras som ny standardapp eftersom appen är End of Life sedan 2022. I praktiken bör Intercept X for Mobile, Google Authenticator, Microsoft Authenticator, Duo Mobile, Okta Verify eller en internt godkänd app testas. Avgörande är inte bara appens namn, utan om den stöder brandväggens valda algoritm, timestep och QR-kod korrekt.

Det mobila operativsystemet spelar också roll vid utrullningen. QR-skanning i Okta-appen fungerar inte för dessa tokens, varken på iOS eller Android. På iOS gäller samma begränsning även för Google Authenticator, Duo och Microsoft Authenticator. I dessa fall måste användaren ange Base32 secret manuellt. Ta med detta i användarguiden; en korrekt brandväggskonfiguration kan annars verka trasig om runbooken endast beskriver QR-skanning.

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

Menysökvägen är:

Web server > Authentication policies

För WAF-MFA ska klientläget ställas in på Form. Formulärbaserad autentisering skapar sessionscookies och möjliggör en särskild utloggning; brandväggen styr inloggningen genom formuläret och sessionerna.

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.

XML-API-dokumentationen för SFOS 23 beskriver den valfria parametern RedirectToRequestedURL endast för klientläget Form, med värdena Enable och Disable. Med Enable omdirigeras användaren till den ursprungligen begärda URL:en efter lyckad autentisering. Dokumentationen anger inget standardvärde för parametern; dess namn i API:et är inte en bekräftad fältetikett i det grafiska gränssnittet. Omdirigeringen ersätter varken autentisering eller behörighetskontroll.

Välj rätt Authentication forwarding

Authentication forwarding mode bestämmer vad som händer mellan brandväggen och backend.

• None: Ingen backend-autentisering genom brandväggen; autentiseringen framför backend är fortfarande aktiv. För att ta bort en Basic-header som klienten skickar är även Remove basic header relevant.
• Basic: Brandväggen vidarebefordrar användarnamn och lösenord till backend via HTTP Basic Authentication.

Om applikationen inte behöver egen autentisering eller om brandväggsinloggningen före backendåtkomst ska räcka, är None ofta renare. Om backend själv förväntar sig HTTP Basic Authentication måste vidarebefordringsläget passa applikationen.

Vid None bör man också kontrollera om Remove basic header måste sättas. Det förhindrar att en Basic Authentication-header som skickas av klienten vidarebefordras onödigt till webbservern. Detta är särskilt viktigt om gamla klienter, sparade webbläsardata eller tidigare publiceringar fortfarande genererar Basic-headers.

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

Klientläget Basic skapar inga sessionscookies och erbjuder ingen särskild utloggning. Sophos kräver därför klientläget Form för WAF-MFA. Oberoende av detta måste Authentication forwarding mode passa backend.

I klientläget Basic är Basic prompt endast meddelandet i webbläsarens dialogruta. I vidarebefordringsläget Basic lägger Username affix till ett konfigurerat prefix eller suffix när endast ett användarnamn anges. Kontrollera fullständiga inloggningsnamn separat så att domän eller suffix inte når backend två gånger. HTTP Basic följer RFC 7617; kodningen krypterar inte inloggningsuppgifterna.

Använd Authentication Policy i WAF-regeln

WAF-regeln redigeras under Rules and policies > Firewall rules. Åtgärden är Protect with web server protection. Följande checklista och kopplingen via Protected servers gäller SFOS 22; för SFOS 23 krävs dessutom de uttryckliga kontrollerna per sökväg under Traffic routing som beskrivs därefter.

När en WAF-regel sparas startar brandväggen om alla regler för webbserverskydd. Befintliga anslutningar via dessa regler bryts och måste återupprättas. Planera ändringen med de ansvariga för alla berörda applikationer under ett lämpligt ändringsfönster, spara de tidigare inställningarna och kontrollera sedan nåbarhet, inloggning med OTP och backendåtkomst. Denna effekt och återställningsvägen har inte testats på en appliance här.

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.

SFOS 23: Tilldela MFA för varje portalsökväg

Den yttre regelåtgärden Protect with web server protection räcker inte i sig. Sökvägskonfigurationen måste vara korrekt för varje portalsökväg som ska skyddas, på varje publicerat värdnamn och i varje tillhörande WAF-regel; de tidigare MFA-stegen och sessionsgränserna förblir oförändrade.

1. Redigera eller lägg till varje skyddad portalsökväg under Traffic routing och ställ in Action > Protect. Tilldela de avsedda backend-objekten från Web server > Web servers.
2. Välj den avsedda Authentication Policy i fältet Authentication. Den måste använda klientläget Form och innehålla den avsedda användargruppen; grupptilldelningen måste passa MFA-konfigurationen. Kontrollera Allowed client networks samt övriga käll- och åtkomstbegränsningar, inklusive medvetet valda nät- och landsblockeringar, för varje sökväg.
3. Om endast vissa portalsökvägar är tillåtna, behåll / med Block som uppsamlingsroute. Om Protect för / avsiktligt används för att publicera hela applikationen, tilldela samma avsedda autentisering och lämpliga åtkomstbegränsningar även där. Kontrollera uttryckligen att alternativa sökvägar och värdnamn har likvärdigt skydd eller avsiktligt blockeras.
4. Behåll de befintliga testerna för lyckad inloggning med lösenord och OTP, backend-funktion, utloggning, sessionsutgång och ny inloggning. Felaktig OTP och användare utanför den tillåtna gruppen måste nekas; alternativa sökvägar eller värdnamn får inte öppna en oskyddad åtkomstväg. Korrelera klientresultatet med WAF-, autentiserings- och backend-loggar.

Dokumentationsgräns för Passthrough: Regelöversikten beskriver autentisering som en funktion hos Protect; samtidigt erbjuder inställningstabellen för routingåtgärden Passthrough ett fält Authentication. Denna motsägelse belägger varken att MFA upprätthålls eller att MFA kringgås vid Passthrough. Basera därför obligatorisk WAF-MFA på uttryckligen konfigurerade Protect-sökvägar, inte på obekräftat Passthrough-beteende. Samordna nödvändiga WebSocket-tunnlar separat med de ansvariga för WAF-routing och autentisering.

Basic with passthrough betecknar ett autentiseringsläge för vidarebefordran av inloggningsuppgifter; Passthrough under Traffic routing är däremot en routingåtgärd för hantering av trafik. De liknande namnen innebär inte någon MFA-egenskap. För grundpubliceringen måste de ansvariga granska SFOS 23-sökvägskonfigurationen tillsammans med MFA-tilldelningen: Den oförändrade Sophos-tutorialen om attackskydd är inte en fullständig routinginstruktion för SFOS 23, och WAF-regler stöder endast IPv4.

Anpassa en Authentication Template säkert

Ett eget formulär skapas under Web server > Authentication templates > Add. I HTML-koden måste formuläret med action="<?login_path?>" och method="POST" samt fälten httpd_username och httpd_password behållas. För MFA måste även otp_field finnas. Om dessa element tas bort eller byter namn kan inloggningen sluta fungera trots att sidan ser korrekt ut.

För bilder, stilar och skript tillhandahåller SFOS bland annat platshållarna <?assets_path?>, <?admin_contact?>, <?company_logo?> och <?company_text?>. Uppladdningsbara assets är begränsade till .jpg, .jpeg, .png, .ico, .css och .js. Testa först templaten med en pilotanvändare; produktionsuppgifter, externa trackers och okontrollerad JavaScript hör inte hemma på inloggningssidan.

Efter Add, ange ett namn, välj HTML-filen och tillhörande assets, klicka på Upload och sedan Save. Välj den sparade mallen i Form-autentiseringspolicyn. Detta minimala formulär behåller de obligatoriska tekniska namnen; det är ett dokumentbaserat exempel, inte en mall som har testats på en appliance:

<form action="<?login_path?>" method="POST">
  <label>Username <input name="httpd_username" type="text"></label>
  <label>Password <input name="httpd_password" type="password"></label>
  <?otp_field?><label>OTP <input name="otp_field" type="password"></label><?otp_field?>
  <button type="submit">Login</button>
</form>

Motsägelser i malldokumentationen: Ett kort lösenordsexempel använder type="text", medan fältdefinitionen och det fullständiga exemplet visar type="password". Behåll lösenordsfältet maskerat. En notis anger också att endast <?login_path?> ersätts, men tabellen med valfria variabler beskriver även ersättning av <?assets_path?> och <?admin_contact?>. Detta bekräftar inte beteendet i varje firmwareversion. Kontrollera det renderade formuläret, asset-sökvägar, OTP-inmatning och inloggning med en pilotgrupp före utrullning; ersätt inte en fungerande mall utan validering.

<?assets_path?> hänvisar till uppladdade stödfiler, exempelvis i <link rel="stylesheet" href="<?assets_path?>/stylesheet.css">. Då kan bilder och CSS hållas utanför formuläret. Fältbeskrivningen kopplar <?admin_contact?> till Administration > Notification settings > Email settings > Send notifications to email address; kontrollera om adressen får visas offentligt. Ersätt <?company_logo?> med sökvägen till er logotyp och <?company_text?> med avsedd synlig text i stället för att anta automatisk ersättning. Om platshållare syns eller inloggningen misslyckas, återgå till den sparade fungerande mallen och undersök med supporten i stället för att stänga av MFA.

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.

Maximum sessions delas av alla WAF-regler med Form-autentisering. Vid gränsen stänger brandväggen gamla eller utgångna sessioner för att tillåta nya. Upprepade inloggningsfrågor kan därför bero på global kapacitet, inte bara på en enskild policys timeout.

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.

Om väldigt många användare eller flera WAF-portaler använder samma brandvägg bör den globala sessionsgränsen inte kontrolleras först när felmeddelanden uppstår. Form-baserad WAF-autentisering är en gemensam reverse proxy-driftparameter och hör därför hemma i kapacitets- och övervakningsplaneringen.

Hantera globala WAF-inställningar säkert

Web server > General settings påverkar alla skyddade webbservrar, inte bara MFA-portalen. Spara värdena före ändringar, identifiera berörda applikationer och klientkompatibilitet och planera ett underhållsfönster och en återställningsväg. Dessa anvisningar har kontrollerats mot dokumentationen; effekter och återställning har inte testats på en appliance.

Slow HTTP protection begränsar väntan på ofullständiga requestheaders. Vid en Slow HTTP-DoS håller långsamt inkommande delar anslutningar upptagna tills kapaciteten tar slut:

• Soft limit: minsta tid för att ta emot en requestheader.
• Hard limit: längsta tid för att ta emot headern.
• Extension rate: datamängd i byte; varje överskridande förlänger soft-timeouten med en sekund.
• Skipped networks/hosts: riktade undantag. Använd endast IP-värdtyperna IP och Network, inte IP ranges eller IP lists. Breda undantag undantar även oönskade klienter från kontrollen.

Kontrollera normala och långsamma legitima klienter och övriga WAF-applikationer efter justeringar. Använd inte godtyckliga timeoutvärden som en allmän lösning på inloggningsproblem.

TLS version settings avgör vilka klientanslutningar som tillåts. De dokumenterade profilerna skiljer sig även åt i sina chiffersviter:

• TLS v1 or later: utesluter SSLv3; en legacyprofil, inte en rekommendation för nya portaler.
• TLS v1.1 or later: utesluter SSLv3 och TLSv1; inte heller en modern standard för utrullning.
• TLS v1.2 (wide compatibility): endast TLSv1.2, inklusive legacychiffer som inte rekommenderas.
• TLS v1.2 (strict): endast TLSv1.2 med rekommenderade chiffer.
• TLS v1.3: endast TLSv1.3-chiffer.

Kontrollera klientstödet före valet; exempelvis kan IE 8 eller äldre och Windows XP inte ansluta med TLS 1.2. Uppnå inte legacykompatibilitet genom att generellt försvaga säkerheten. Testa först en strikt profil med de klienter som faktiskt behövs och alla publicerade applikationer.

I Custom TLS använder Protocols, Cipher suite och TLS v1.3 cipher suite only OpenSSL-syntax. TLSv1.3-chiffer hör endast hemma i det separata TLSv1.3-fältet, inte i Cipher suite. Ogiltiga protokoll eller chiffersviter kan hindra Apache från att starta och störa WAF. Experimentera inte med Custom TLS i produktion utan validerade inställningar; återställ sparade värden vid fel och kontrollera tjänstens status och HTTPS-åtkomst till alla berörda portaler.

SFOS 23 – Worker customization: Brandväggen beräknar WAF-kapaciteten utifrån CPU och RAM. De beräknade värdena är optimerade för hårdvaran; de flesta installationer behöver inga ändringar. Högre värden kan försämra WAF-prestanda och användningen av systemresurser. Aktivera Use custom worker profile endast efter noggrann kapacitets- och konsekvensbedömning, inte som en generell lösning på inloggningsfel:

• Start servers: workerprocesser när webbservern startar.
• Server limit: högsta antal workerprocesser.
• Minimum spare threads: minsta antal lediga trådar som hålls tillgängliga.
• Maximum spare threads: gräns för lediga trådar över vilken överskott tas bort.
• Threads per child: högsta antal trådar per workerprocess.
• Asynchronous request worker factor: styr skalningen av processer för asynkrona anslutningar och requests.

Kopiera inte universella värden från andra system. Spara ursprungsvärdena, observera representativ belastning och resurser och testa inloggning, OTP, sessioner och backend-åtkomst på nytt efter varje motiverad ändring. Återställ den sparade ursprungskonfigurationen vid försämring; en lyckad återställning påstås inte här.

Automatisera WAF-autentisering via XML API

För automatiseringen samverkar tre separata objekt: FormTemplate tillhandahåller inloggningsformuläret, ReverseAuthentication definierar klient- och backend-autentisering, och FirewallRule kopplar policyn till publiceringen respektive dess sökvägar. Säkerhetskopiera först den fungerande mallen, policyn och alla regler som använder dem. Åtkomst, explicita skrivoperationer, utvärdering av svar och säkra återförsök förklaras i Säkra åtkomst till Sophos Firewall XML API. Uppgifterna nedan beskriver SFOS-22/23-referenserna, inte ett skrivförfarande som har testats på en appliance. Kontrollera API help för den installerade builden före ändringar; skriv inte om fält eller uppladdningsbindningar är oklara.

Håll isär klientläge, backend och sessioner

I objektet ReverseAuthentication beskrivs Name, VirtualWebserverMode och RealWebserverMode som obligatoriska fält. Name tillåter högst 60 tecken. VirtualWebserverMode väljer Basic eller Form för klienten; det dokumenterade standardvärdet Basic är ingen MFA-rekommendation. För WAF-MFA krävs fortfarande Form. BasicPrompt är den valfria informationstexten för Basic med högst 255 tecken. FormTemplate refererar till den sparade mallen i Form-läge. UserGroupList innehåller upprepningsbara UserGroup-poster för befintliga användare eller grupper; detta urval måste fortfarande motsvara MFA-gruppen. Ordet Mode i anmärkningar om tillämplighet är inte en ytterligare belagd XML-tagg.

RealWebserverMode väljer oberoende av detta Basic eller None för backend; även här anger tabellen Basic som standardvärde. Vid Basic hör UsernameAffix till backend-inloggningen. Prefix och Suffix är valfria texter med högst 255 tecken vardera och är endast avsedda för motsvarande affixval. Vid None är i stället RemoveBasicHeader med Enable eller Disable relevant. Standardvärdet ON som anges där är inte i sig ett tillåtet inmatningsvärde; använd explicita värden först efter kontroll av builden. De befintliga kontrollerna av HTTPS, backend och användarnamn krävs fortfarande.

För inte över motsägelser till en payload: För UsernameAffix visar XML-exemplet None/Prefix/Suffix/PrefixAndSuffix, medan tabellen anger Basic, Prefix, Suffix, PrefixandSuffix och samtidigt standardvärdet None. Gissa varken stavning eller ytterligare valbara värden. På samma sätt visar exemplet SessionTimeout och SessionLifetime som omkopplare, deras respektive Limit-fält som heltal och Scope-fälten som Hours/Minutes/Days. Tabellen bekräftar intervallet 1 till 9999 för SessionTimeoutLimit, men förväxlar heltal och omkopplare för SessionLifetime och SessionLifetimeLimit; uppgifter som ON och 8 Hours stämmer inte konsekvent överens med datatyperna. Dessa inkonsekvenser belägger varken tillförlitliga standardvärden eller en körbar sessionskonfiguration. Bekräfta den önskade inaktivitetsgränsen och maximala livslängden i den installerade builden, läs tillbaka det sparade tillståndet och genomför de befintliga testerna för sessioner, utloggning och förnyad inloggning. SFOS-23-tillägget RedirectToRequestedURL och dess separata test av återdirigering är oberoende av detta.

Koppla mall och tillhörande filer

FormTemplate-referensen visar FormTemplate som ett objekt med Name, Description, Template och Assets, där det finns upprepningsbara Asset-poster. Name och Template är obligatoriska fält: namnet tillåter högst 60 tecken, och Template är en sträng med högst 255 tecken för val och uppladdning av HTML-mallen. Description är valfritt. De valfria Asset-strängarna tillåter högst 255 tecken vardera och flera värden för de bilder, stilmallar eller JavaScript-filer som används.

Exemplet lämnar Template och Asset tomma. Därmed fastställer det varken namn på multipart-delar, filsökvägar, Base64-kodning eller HTML-innehåll som kan överföras direkt. Överför inte någon bindning för certifikatuppladdning till FormTemplates. Utan ett bekräftat uppladdningskontrakt ska den befintliga GUI-sekvensen Upload > Save användas, och därefter ska den sparade mallen väljas via FormTemplate i Form-policyn. De obligatoriska formulärfälten och tillåtna filtyperna för assets från föregående avsnitt gäller fortfarande. Kontrollera det renderade formuläret, assets och OTP-inloggningen med en testanvändare; en lyckad lagring av objektet bevisar inte i sig att formuläret fungerar.

Koppla Authentication Policy till regeln

För FirewallRule gäller denna koppling WAF-grenen HTTPBasedPolicy, inte NetworkPolicy eller UserPolicy. Parametertabellen beskriver Authentication som en valfri skalär sträng för en Authentication Policy. I sökvägsexemplet anges motsvarande koppling som AccessPaths > AccessPath > auth_profile. Kommentaren i exemplet skiljer den regelövergripande varianten med Authentication och källkontroller från AccessPaths; den belägger inte godtyckliga kombinationer eller automatisk nedärvning. Blanda inte regelövergripande och sökvägsspecifika skrivsätt utan kontroll, och anta inte att en policy som finns på brandväggen redan skyddar varje sökväg.

I SFOS 23 beskriver tabellen path som en obligatorisk array av strängar med flera värden, högst 63 tecken, utan kommatecken och med UTF-8-stöd; SFOS 22 anger här en skalär. Exemplet använder både path och Path. backend är valfritt i SFOS-23-tabellen; detta är ingen utfästelse om att en skyddad portal fungerar utan backend. Det nya sökvägsspecifika action visar ordagrant 0/1/2/3, utan någon tillförlitlig koppling till GUI-åtgärderna. Gissa ingen siffertilldelning och likställ inte dessa värden med nätverksfältet Action. Routning, backend och skyddsprofil förklaras i WAF: Publicera webbservrar säkert.

För autentiseringsändringen ska först målregelns faktiska värdnamn och sökvägar läsas, den önskade Form-policyn kopplas till varje skyddad sökväg och därefter det sparade tillståndet jämföras med det avsedda. Kontrollera alla alternativa sökvägar, värdnamn och regler samt felaktig OTP och användare utanför gruppen. De redan beskrivna Protect-kontrollerna, dokumentationsgränsen för Passthrough och ändringsfönstret för WAF-regler gäller då oförändrat.

Utvärdera objektsvar före ett återförsök

Följande kopplingar är XML-statusvärden och ordagranna, oupplösta Message.*-symboler från referensen, inte HTTP-statuskoder eller belagda meddelandetexter från körning. För FirewallRule-bindningen är särskilt skillnaderna mellan Add och Edit viktiga:

• Add firewall rule: 200 / Message.FWRuleAddSuccess, 500 / Message.FWRuleAddFail, 502 / Message.FWRuleRecordExists.
• Edit firewall rule: 200 / Message.FWRuleEditSuccess, 202 / Message.FirewallRuleUpdateWithRename, 500 / Message.FWRuleEditFail, 502 / Message.FWRuleUpdateRecordExist. Vid 202 ska även det faktiska namnet och alla kopplingar läsas tillbaka.
• Olika kopplingar: Add 541 / Message.VHIPRangeConflict, Edit 541 / Message.FWRuleFailMaxUser; Add 543 / Message.CannotSetupRedirectionFromHTTP, Edit 543 / Message.CannotUseDefaultPort; Add 544 / Message.CannotUseDefaultPort, Edit 544 / Message.CannotSetupRedirectionFromHTTP. Enbart samma kod räcker inte för tolkningen.
• Ytterligare rader som skiljer sig: Edit 552 / Message.CannotImportDiffPolicytypeWithSameName; Add 554 / Message.CannotUseFQDNWildCardAsProtectedServer, Edit 554 / Message.CannotUpdateFQDNWildCardAsProtectedServer.
• Delete firewall rule: 200 / Message.FWDelSuccess, 500 / Message.FWRuleDeleteFail, 596 / Message.CMLOCALOperationrestriction. 596 förekommer även vid Add och Edit; klarlägg det faktiska behörighets- och förvaltningstillståndet och kringgå det inte genom blinda återförsök eller radering. Att radera en regel är ingen lösning på en saknad autentiseringsbindning.

Även de två föregående objekten har egna svar:

• Add Authentication Policy: 200 / Message.ReverseAuthAddSuccess, 500 / Message.ReverseAuthAddFail, 502 / Message.ReverseAuthRecodExist.
• Edit Authentication Policy: 200 / Message.ReverseAuthUpdateSuccess, 500 / Message.ReverseAuthUpdateFail.
• Add FormTemplate: 200 / Message.FormTemplateAddSuccess, 500 / Message.FormTemplateAddFail.
• Edit FormTemplate: 200 / Message.FormTemplateUpdateSuccess, 500 / Message.FormTemplateUpdateFail, 502 / Message.FormTemplateRecodExist. Stavningen Recod i dessa symboler bevaras ordagrant; härled ingen ytterligare status för en annan operation från den.

Dokumentera operation, kod, faktiskt svar och det sparade tillståndet för mall, policy och målregel tillsammans. Vid fel, varningar eller oklart svar ska först det som faktiskt har tillämpats kontrolleras; kringgå inte problemet med ett andra namn, en bredare grupp eller en oskyddad sökväg. Vid oklar syntax eller uppladdningskoppling ska arbetet stoppas och support anlitas med rensade data. Först efter bekräftad lagring följer de befintliga positiva och negativa testerna för MFA, backend, sessioner, utloggning, återdirigering och alternativa sökvägar. Dokumentationsgranskning ersätter inte acceptanstest på den egna brandväggen.

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.
• Ändringar av token-timestep gäller endast nygenererade tokens och måste passa den app som används.

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

Om en användare tappar appen eller algoritmen ändras räcker det ofta inte att upprepa användarkommunikationen. Under Authentication > Multi-factor authentication > Issued tokens kan tokens återställas eller extra engångskoder genereras. Denna process bör regleras internt eftersom den har stark säkerhetsbetydelse.

Validering och drift

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.
9. Kontrollera utloggning, ny inloggning och sessionsutgång med samma webbläsare.
10. Testa med ett andra hostname eller alternativ sökväg om applikationen använder flera WAF-regler.

För att även testa återgången till den begärda URL:en på SFOS 23, öppna utan en giltig WAF-session en faktiskt skyddad URL med en sökväg som inte är /. Efter lyckad inloggning med lösenord och OTP, med RedirectToRequestedURL inställt på Enable, kontrollera att exakt den ursprungligen begärda URL:en nås och att backend-åtkomsten följer de avsedda behörigheterna. En lyckad omdirigering är i sig inget bevis för MFA eller åtkomstbehörighet; alla ovanstående tester för nekad åtkomst, backend, sessioner, utloggning, ny inloggning och alternativa sökvägar krävs fortfarande.

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:

• Användare: Brandväggsinloggningen visas, OTP efterfrågas och därefter öppnas den förväntade applikationen.
• Sophos Firewall: Log Viewer och reverseproxy.log visar tillåten eller avvisad WAF-autentisering.
• Autentiseringskälla: AD, LDAP, RADIUS eller den lokala användarkällan visar den förväntade lyckade eller misslyckade inloggningen.
• Backend: Applikationen når rätt användar- eller gäststatus och visar ingen oväntad andra felsida.

Om endast webbläsaren verkar fungera men inga tillhörande loggar är synliga är godkännandet ofullständigt. Kontrollera då om rätt WAF-regel används, om autentiseringspolicyn verkligen är aktiv och om loggarna hamnar på förväntad plats.

Driftsättning 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:

• Utrullningsgrupp: Börja med pilotgruppen och lägg därefter till fler användargrupper.
• Supportfönster: Håll helpdesk eller ansvariga administratörer tillgängliga under de första inloggningarna.
• Övervakning: Observera Log Viewer, reverseproxy.log och autentiseringskälla.
• Token-återställning: Definiera en tydlig procedur för förlorade eller felaktigt inställda OTP-tokens.
• Sessionsbeteende: Kontrollera session timeout och session lifetime efter verklig användning.
• Återfallsmetod: Dokumentera WAF-regel, autentiseringspolicy och ändringssteg.

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 testregler, 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 autentisering före backendåtkomst.

Felsökning

Andra vanliga fel

• Autentiseringspolicyn använder inte Form: MFA-beteendet passar inte den förväntade WAF-konfigurationen.
• Sophos Authenticator planeras som ny standardapp: Appen är EOL och bör inte längre användas som bas för en ny utrullning.
• Fallback-åtkomst beror på samma WAF-regel: Administratörer kan inte återställa ändringen ordentligt vid fel.
• Token-utdelningen testades inte: Användare misslyckas vid första inloggningen, även om WAF-regeln är tekniskt korrekt.
• En andra URL eller WAF-regel förblir aktiv utan MFA: Användare kringgår oavsiktligt MFA-kontrollen före backendåtkomst.
• Tillfälliga pilotundantag tas inte bort: Produktionsskyddet är ojämnt och svårt att granska.

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.

Backend begär inloggning igen efter lyckad MFA

På SFOS 22.0 GA Respin Build 411 kan NC-177509 inträffa: formbaserad WAF-MFA lyckas, men backend begär därefter en extra inloggning som inte går att kringgå. OTP-koden skiljs inte från lösenordet innan brandväggen vidarebefordrar inloggningsuppgifterna till backend. Problemet är korrigerat från och med SFOS 22.0 MR1 Build 490.

Korrigeringen för OTP-koden som inte tas bort har också referensen NC-177201. ID-numren är inte utbytbara: NC-177509 kopplar berörda och korrigerade builds, medan NC-177201 identifierar den specifika korrigeringstexten. Ange därför symptom, build och båda referenserna i ett supportärende.

Kontrollera:

• WAF Authentication Policy använder Form.
• Authentication forwarding mode är aktivt och passar backend-applikationen.
• Den berörda WAF-regeln använder exakt denna Authentication Policy.
• Felet uppträder efter lyckad MFA, inte redan vid firewall-inloggningen.
• reverseproxy.log, Log Viewer och backendens accesslogg täcker samma testtidpunkt.
• Den använda SFOS-versionen har kontrollerats.

På ett berört GA-system bör reverseproxy.log, Log Viewer och backend-loggen sparas och en uppdatering till MR1 Build 490 eller senare planeras. Om en snabb uppdatering inte är möjlig ska autentiseringsflödet inte ändras utan verifiering; använd det sparade underlaget för att öppna ett Sophos-supportärende. Försvaga inte MFA och ändra inte Authentication forwarding utan analys: None passar endast om backend inte behöver vidarebefordrade inloggningsuppgifter. För produktionsportaler ska testanvändare, rollback och användarkommunikation ingå i planen.

För många eller gamla sessioner

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