Zabezpieczanie Sophos Firewall WAF za pomocą MFA

Dzięki Sophos Firewall WAF MFA można dodatkowo zabezpieczyć aplikacje webowe publikowane przez Web Application Firewall za pomocą uwierzytelniania wieloskładnikowego. Jest to szczególnie przydatne dla wewnętrznych portali, interfejsów administracyjnych, obszarów dla klientów lub partnerów, które muszą być dostępne przez HTTPS, ale nie powinny być chronione wyłącznie przez samą aplikację.

WAF-MFA nie zastępuje bezpiecznej aplikacji, zarządzania poprawkami ani czystej koncepcji uprawnień. Jest to warstwa ochronna na firewallu. Firewall najpierw sprawdza logowanie i drugi czynnik, zanim przekieruje dostęp do chronionego serwera webowego.

Wersja ma znaczenie: zintegrowane MFA dla WAF jest funkcją SFOS 22. W starszych wersjach firmware publikacje WAF trzeba planować z innymi architekturami, na przykład zewnętrznym uwierzytelnianiem, dedykowanym reverse proxy, VPN lub ZTNA.

Aby opublikować serwer webowy przez WAF, należy najpierw zapoznać się z instrukcją Sophos Firewall WAF: Bezpieczne publikowanie serwerów webowych. Ten artykuł koncentruje się na wstępnym uwierzytelnianiu i MFA.

Zastosowanie i planowanie

Kiedy WAF-MFA jest przydatne

WAF-MFA jest szczególnie skuteczne, gdy aplikacja webowa musi być dostępna z Internetu, ale nie jest przeznaczona dla wszystkich odwiedzających.

Typowe zastosowania:

• wewnętrzne portale z dostępem zewnętrznym
• interfejsy administracyjne aplikacji specjalistycznych
• portale partnerskie lub klientowskie z ograniczoną liczbą użytkowników
• starsze aplikacje webowe bez własnego silnego MFA
• aplikacje, w których pożądana jest dodatkowa ochrona dostępu przed backendem

Dla publicznych stron internetowych, sklepów lub stron informacyjnych WAF-MFA zazwyczaj nie jest odpowiednie, ponieważ każdy odwiedzający najpierw zobaczyłby logowanie do firewalla. W przypadku skomplikowanych prywatnych aplikacji ZTNA, SSE lub dedykowany reverse proxy mogą być bardziej odpowiednie niż WAF-MFA. Jeśli potrzebny jest WebDAV, należy zachować szczególną ostrożność: Sophos WAF nie obsługuje WebDAV w pełni, co może być istotne w przypadku aplikacji takich jak Nextcloud.

Kiedy WAF-MFA nie wystarcza

WAF-MFA jest wstępną warstwą dostępu. Ta warstwa nie odpowiada jednak na każde pytanie architektoniczne. Zwłaszcza w przypadku krytycznych portali należy świadomie zdecydować, czy aplikacja powinna być w ogóle publicznie dostępna.

• Aplikacja jest przeznaczona tylko dla kilku wewnętrznych użytkowników: Sprawdź VPN, ZTNA, stałe sieci źródłowe lub niepubliczne publikowanie.
• Aplikacja zawiera szczególnie wrażliwe dane: Dodatkowo sprawdź uprawnienia backendu, logowanie, ścieżkę audytu i sesje aplikacji.
• Aplikacja potrzebuje WebDAV lub specjalnych protokołów: Przetestuj zgodność WAF przed wdrożeniem lub wybierz inną architekturę.
• Zewnętrzni partnerzy rzadko uzyskują dostęp: Szczególnie jasno udokumentuj wdrażanie tokenów, proces wsparcia i mechanizmy awaryjne.
• Backend ma własne logowanie i role: Traktuj WAF-MFA tylko jako dodatkową warstwę, a nie jako zamiennik ról backendu.

Jeśli portal pozostaje dostępny na całym świecie, MFA nie powinno być jedynym środkiem bezpieczeństwa. Stałe sieci źródłowe, ograniczenia krajowe, Threat Feeds, profile ochrony i czyste poprawki backendu dodatkowo zmniejszają ryzyko.

Wymagania wstępne

Przed konfiguracją należy wyjaśnić następujące kwestie:

• Aplikacja webowa jest już zaplanowana lub opublikowana za pomocą reguły WAF.
• Firewall działa na SFOS 22 lub nowszym.
• Użytkownicy lub grupy są dostępne na firewallu, na przykład lokalnie, przez AD, LDAP lub RADIUS.
• Użytkownicy mogą skonfigurować swój token OTP.
• Czas systemowy firewalla jest poprawny i NTP działa.
• Dla reguły WAF używane jest HTTPS z odpowiednim certyfikatem.
• Jest jasne, czy backendowy serwer webowy potrzebuje własnego uwierzytelniania, czy firewall ma całkowicie przejąć logowanie.
• Dostępny jest użytkownik testowy i administracyjny dostęp awaryjny.

⚠️ MFA dla WAF powinno być najpierw przetestowane z grupą pilotażową. Niewłaściwa kombinacja grupy MFA, polityki uwierzytelniania WAF i uwierzytelniania backendu może zablokować legalnych użytkowników lub sprawić, że aplikacja wydaje się “zepsuta”.

Planowanie pilotażu, mechanizmów awaryjnych i odpowiedzialności

WAF-MFA działa przed właściwą aplikacją. Dlatego wdrożenie nie powinno być traktowane jak zwykła reguła firewalla, ale jak zmiana w procesie logowania do aplikacji. Użytkownicy najpierw widzą logowanie do Sophos Firewall, a dopiero potem, w zależności od backendu, właściwą aplikację.

Przed włączeniem powinny być ustalone następujące kwestie:

• Która grupa użytkowników testuje jako pierwsza?
• Kto może ponownie wyłączyć dostęp, jeśli logowanie się nie powiedzie?
• Czy istnieje drugi dostęp administracyjny, który nie zależy od tej samej reguły WAF, tego samego portalu lub tego samego użytkownika testowego?
• Które części aplikacji muszą być przetestowane po pomyślnym logowaniu?
• Kto sprawdza reverseproxy.log, Log Viewer i logi backendu w przypadku błędów?
• Jak użytkownicy są informowani o tokenach, wygaśnięciu sesji i możliwym drugim logowaniu do backendu?

Częstym błędem w planowaniu jest mieszanie uwierzytelniania firewalla z uwierzytelnianiem backendu. WAF może sprawdzać użytkowników przed backendem. Nie oznacza to jednak automatycznie, że sama aplikacja nie potrzebuje już własnego logowania, sprawdzania ról czy zarządzania sesjami. Zwłaszcza w przypadku portali administracyjnych i danych klientów uprawnienia backendu powinny być świadomie zachowane.

Jeśli opublikowana usługa jest przeznaczona tylko dla kilku osób, oprócz MFA należy ograniczyć źródła. Dla podstawowej publikacji i ograniczenia źródeł pasuje Sophos Firewall WAF: Bezpieczne publikowanie serwerów webowych. Jeśli planowane są prawa użytkowników lub MFA dla zdalnego dostępu, pomocne będzie Aktywowanie MFA dla Sophos Firewall WebAdmin, VPN Portal i Zdalnego Dostępu.

Przed włączeniem należy przygotować plan wycofania. W praktyce oznacza to: dokumentowanie starej, działającej metody dostępu, nazywanie reguły WAF i polityki uwierzytelniania, wyznaczenie odpowiedzialnej osoby i wybór momentu, w którym możliwe jest uzyskanie opinii użytkowników i sprawdzenie logów. Jeśli aplikacja jest krytyczna dla biznesu, WAF-MFA powinno być najpierw aktywowane dla domeny testowej, grupy pilotażowej lub w oknie konserwacyjnym.

Konfiguracja

Elementy konfiguracji

Dla WAF-MFA musi być zgodnych kilka ustawień:

• Ustawienie MFA: Określa, którzy użytkownicy używają MFA i czy Web application firewall jest chroniony.
• Polityka uwierzytelniania WAF: Definiuje tryb logowania, użytkowników/grupy, szablon i zachowanie sesji.
• Reguła WAF: Łączy opublikowany serwer webowy z polityką uwierzytelniania.
• Przekazywanie uwierzytelniania backendu: Określa, czy firewall przekazuje dane logowania do serwera webowego.
• Wdrażanie tokenów: Zapewnia, że użytkownicy mogą faktycznie wygenerować swój kod OTP.

Najważniejsza różnica: MFA nie jest aktywowane tylko globalnie. Dotknięta reguła WAF musi również używać odpowiedniej polityki uwierzytelniania.

Aktywowanie MFA dla WAF

Ścieżka menu to:

Authentication > Multi-factor authentication

Procedura:

1. Wybierz One-time password (OTP) jako All users lub Specific users and groups.
2. W przypadku Specific users and groups dodaj odpowiednich użytkowników lub grupy.
3. Aktywuj Generate OTP token with next sign-in, jeśli użytkownicy mają sami skonfigurować swój token przy następnym logowaniu.
4. W sekcji Require MFA for aktywuj opcję Web application firewall.
5. Świadomie ustaw OTP hash algorithm oraz w razie potrzeby OTP timestep settings.
6. Zapisz konfigurację.

Jeśli Generate OTP token with next sign-in jest aktywne, User portal jest automatycznie wybierany jako usługa do pierwszej konfiguracji kodu QR. Użytkownicy muszą móc zobaczyć kod QR w portalu, zanim pierwszy login WAF-MFA będzie realnie działał. W zależności od środowiska istotne mogą być też VPN Portal lub WebAdmin. Ogólne planowanie MFA opisano w Włączanie MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access.

Przygotowanie wdrażania tokenów i komunikacji z użytkownikami

WAF-MFA często nie działa w praktyce z powodu problemów z wdrażaniem tokenów. Użytkownicy muszą wiedzieć, gdzie pojawia się kod QR, jakiej aplikacji użyć, jak długo jest ważna sesja i czy po logowaniu do firewalla następuje drugie logowanie do aplikacji.

Przed włączeniem produkcyjnej reguły WAF należy ustalić:

• Tworzenie tokenów: Gdzie użytkownik konfiguruje token OTP?
• Dostęp do portalu: Czy User Portal lub inna przewidziana ścieżka kodu QR jest dostępna dla dotkniętych użytkowników?
• Aplikacja uwierzytelniająca: Która aplikacja jest zatwierdzona i przetestowana z wybranym algorytmem?
• Mechanizm awaryjny: Kto może zresetować zgubiony lub uszkodzony token?
• Kody awaryjne: Czy wiadomo, czy i jak można wydać dodatkowe kody jednorazowe w przypadku wsparcia?
• Przypadek wsparcia: Jakie informacje są potrzebne helpdeskowi w przypadku problemów z logowaniem?
• Komunikacja: Jaką sekwencję logowania widzą użytkownicy od momentu uruchomienia?

Jeśli używana jest opcja Generate OTP token with next sign-in, pierwsze logowanie powinno być kontrolowane i testowane. Ważne jest, czy użytkownicy widzą kod QR w oczekiwanym portalu i czy mogą następnie pomyślnie uzyskać dostęp do aplikacji WAF za pomocą hasła i OTP. Same portale są opisane w Sophos Firewall Portale: WebAdmin, User Portal i VPN Portal.

Dla wielu usług firewalla kod OTP jest przetwarzany jako kombinacja hasła i passcode. Komunikacja z użytkownikami i runbook helpdesku powinny więc jasno opisywać, jaki ekran wprowadzania użytkownicy faktycznie widzą oraz czy hasło i OTP wpisuje się oddzielnie czy razem. Przy WAF-MFA z logowaniem opartym na Form jest to szczególnie ważne, ponieważ drugi login backendowy bywa szybko błędnie interpretowany jako „zepsute MFA”.

Sophos Authenticator nie powinien być już planowany jako nowa aplikacja standardowa, ponieważ app jest End of Life od 2022 roku. W praktyce należy testować Intercept X for Mobile, Google Authenticator, Microsoft Authenticator, Duo Mobile, Okta Verify albo aplikację zatwierdzoną wewnętrznie. Liczy się nie tylko nazwa aplikacji, lecz także to, czy poprawnie obsługuje wybrany algorytm, timestep i kod QR firewalla.

Dla helpdesku i operacji powinno być co najmniej udokumentowane:

• opublikowana nazwa hosta aplikacji WAF
• dotknięta grupa użytkowników
• używana polityka uwierzytelniania
• używany algorytm OTP
• zatwierdzona aplikacja uwierzytelniająca
• procedura resetowania tokenów
• oczekiwana wiadomość przy błędnym haśle lub OTP
• miejsca logów do wstępnej weryfikacji: Log Viewer i reverseproxy.log

Szczególnie w przypadku zewnętrznych partnerów lub rzadko używanych portali pierwsze logowanie nie powinno odbywać się dopiero w sytuacji awaryjnej. Krótki pilotaż z normalnymi użytkownikami często ujawnia problemy, których administratorzy nie widzą w swoich testach: różne aplikacje uwierzytelniające, brak dostępu do portalu, niejasne drugie logowanie do backendu lub zbyt krótkie czasy wygaśnięcia sesji dla aplikacji.

Tworzenie polityki uwierzytelniania WAF

Ścieżka menu to:

Web server > Authentication policies

Dla WAF-MFA tryb klienta powinien być ustawiony na Form. Przy uwierzytelnianiu opartym na formularzach firewall może kontrolować logowanie za pomocą formularza i sesji.

Procedura:

1. Otwórz Add.
2. Nadaj nazwę opisową, na przykład WAF_MFA_Portal_Users.
3. Wybierz opcję Form w sekcji Mode.
4. Wybierz odpowiedni Authentication template.
5. Wybierz użytkowników lub grupy, które mają dostęp do tej publikacji WAF.
6. Świadomie wybierz Authentication forwarding mode.
7. Ustaw Session timeout i Session lifetime odpowiednio do aplikacji.
8. Zapisz.

Wybór odpowiedniego przekazywania uwierzytelniania

Authentication forwarding mode decyduje, co dzieje się między firewallem a backendem.

• None: Firewall uwierzytelnia użytkownika, a serwer webowy nie otrzymuje danych logowania.
• Basic: Firewall przekazuje nazwę użytkownika i hasło do backendu przez HTTP Basic Authentication.

Jeśli aplikacja nie wymaga własnego uwierzytelniania lub wystarczy wstępne logowanie do firewalla, None jest często czystsze. Jeśli backend sam oczekuje HTTP Basic Authentication, tryb przekazywania musi pasować do aplikacji.

Przy None należy dodatkowo sprawdzić, czy trzeba ustawić Remove basic header. Zapobiega to niepotrzebnemu przekazywaniu do serwera webowego nagłówka Basic Authentication wysłanego przez klienta. Jest to szczególnie ważne, gdy stare klienty, zapisane dane przeglądarki lub wcześniejsze publikacje nadal generują nagłówki Basic.

⚠️ Basic Authentication powinno być używane tylko z HTTPS. Ponadto musi być jasne, czy backend rzeczywiście powinien przetwarzać dane logowania przekazywane przez firewall.

Tryb klienta Basic nie tworzy plików cookie sesji i nie zapewnia osobnego wylogowania. Dlatego Sophos wymaga dla WAF-MFA trybu klienta Form. Niezależnie od tego Authentication forwarding mode musi pasować do backendu.

Użycie polityki uwierzytelniania w regule WAF

Reguła WAF jest edytowana w sekcji Rules and policies > Firewall rules. Akcja to Protect with web server protection.

W dotkniętej regule WAF muszą być zgodne następujące punkty:

• Prawidłowy Hosted address i port nasłuchu.
• Prawidłowa domena i odpowiedni certyfikat HTTPS.
• Prawidłowy chroniony serwer webowy.
• Wybrana odpowiednia Authentication policy.
• Grupa użytkowników w polityce uwierzytelniania pasuje do grupy MFA.
• Ograniczenia dostępu przez Allowed client networks, kraje lub Threat Feeds są świadomie ustawione.

Dla publicznych lub silnie eksponowanych portali MFA nie powinno być jedynym środkiem ochrony. Ograniczenia krajowe i źródłowe są opisane w Sophos Firewall: Blokowanie krajów i złośliwych adresów IP. Dla dynamicznych list blokad pasuje Sophos Firewall Threat Feeds.

Planowanie sesji i timeoutów

Przy uwierzytelnianiu opartym na formularzach WAF firewall działa z sesjami. W polityce uwierzytelniania ustala się:

• Session timeout: po jakim czasie bezczynności użytkownicy muszą się ponownie zalogować
• Session lifetime: jak długo maksymalnie jest ważne logowanie

Dodatkowo w sekcji Web server > General settings znajduje się maksymalna liczba jednoczesnych sesji dla uwierzytelniania reverse proxy opartego na formularzach. Wartość domyślna to 25,000, a obsługiwany zakres to 100 do 100,000.

Krótkie sesje zwiększają bezpieczeństwo, ale mogą przeszkadzać użytkownikom. Bardzo długie sesje są wygodniejsze, ale zwiększają ryzyko, że skradziony lub współdzielony dostęp do przeglądarki będzie dłużej używany. Dla portali administracyjnych warto zacząć konserwatywnie i obserwować zachowanie w praktyce.

Jeśli bardzo wielu użytkowników lub kilka portali WAF używa tego samego firewalla, globalnego limitu sesji nie należy sprawdzać dopiero przy komunikatach o błędach. Uwierzytelnianie WAF oparte na Form jest wspólnym parametrem operacyjnym reverse proxy i powinno być uwzględnione w planowaniu pojemności i monitoringu.

Algorytm OTP i aplikacja uwierzytelniająca

SFOS 22 obsługuje oprócz SHA1 także SHA256 i SHA512 dla tokenów OTP. Jest to sensowne z punktu widzenia bezpieczeństwa, ale działa tylko wtedy, gdy używana aplikacja uwierzytelniająca obsługuje wybrany algorytm.

Ważne punkty:

• SHA256 lub SHA512 są bezpieczniejsze niż SHA1.
• Nie każda aplikacja uwierzytelniająca obsługuje te algorytmy w tym kontekście.
• Microsoft Authenticator może zeskanować kod QR przy SHA256 lub SHA512, ale logowanie może się nie powieść.
• Jeśli algorytm zostanie zmieniony, stare tokeny muszą zostać usunięte i ponownie zeskanowane.
• Zmiany timestep tokena dotyczą tylko nowo wygenerowanych tokenów i muszą pasować do używanej aplikacji.

Dla produkcyjnych wdrożeń warto przetestować wybraną aplikację i algorytm z małą grupą pilotażową. Dopiero potem należy szeroko migrować istniejących użytkowników.

Jeśli użytkownik zgubi aplikację albo zmieni się algorytm, samo powtórzenie komunikacji do użytkowników często nie wystarczy. W Authentication > Multi-factor authentication > Issued tokens można resetować tokeny lub generować dodatkowe kody jednorazowe. Ten proces powinien być uregulowany wewnętrznie, ponieważ ma silny wpływ na bezpieczeństwo.

Walidacja i eksploatacja

Plan testów po konfiguracji

Po konfiguracji nie należy tylko sprawdzać, czy pojawia się strona logowania. Ważne jest przetestowanie całej ścieżki dostępu.

1. Użyj zewnętrznej przeglądarki lub zewnętrznej sieci testowej.
2. Otwórz URL WAF z użytkownikiem z dozwolonej grupy.
3. Przetestuj logowanie z poprawnym hasłem i OTP.
4. Przetestuj logowanie z błędnym OTP.
5. Przetestuj użytkownika spoza dozwolonej grupy.
6. Sprawdź wygaśnięcie sesji po bezczynności.
7. Sprawdź funkcję backendu aplikacji.
8. Sprawdź Log Viewer i reverseproxy.log pod kątem nieprawidłowości.
9. Sprawdź wylogowanie, ponowne logowanie i wygaśnięcie sesji w tej samej przeglądarce.
10. Przetestuj drugi hostname lub alternatywną ścieżkę, jeśli aplikacja używa kilku reguł WAF.

Dla plików logów pomocne jest Sophos Firewall Troubleshooting: Usługi i logi. Zdarzenia WAF zazwyczaj są związane z Reverse Proxy i pojawiają się dodatkowo w Log Viewer.

Dla akceptacji każdy przypadek testowy powinien być przypisany do widocznego wyniku:

• Użytkownik: Pojawia się logowanie do firewalla, wymagany jest OTP, a następnie otwiera się oczekiwana aplikacja.
• Sophos Firewall: Log Viewer i reverseproxy.log pokazują dozwolone lub odrzucone uwierzytelnianie WAF.
• Źródło uwierzytelniania: AD, LDAP, RADIUS lub lokalne źródło użytkowników pokazuje oczekiwane udane albo nieudane logowanie.
• Backend: Aplikacja osiąga właściwy stan użytkownika lub gościa i nie pokazuje nieoczekiwanej drugiej strony błędu.

Jeśli przeglądarka działa, ale nie ma odpowiednich logów, weryfikacja jest niekompletna. Należy wtedy sprawdzić, czy stosowana jest właściwa reguła WAF, czy polityka uwierzytelniania jest rzeczywiście aktywna i czy logi trafiają w oczekiwane miejsce.

Go-live i operacje po aktywacji

Po udanym teście WAF-MFA nie powinno być po prostu szeroko włączane i potem zapominane. Pierwsze godziny po uruchomieniu są ważne, ponieważ prawdziwi użytkownicy przynoszą inne przeglądarki, inne aplikacje uwierzytelniające, zapisane hasła, stare zakładki i inne stany sesji niż test administratora.

Dla go-live warto przygotować mały plan operacyjny:

• Grupa wdrożeniowa: Najpierw grupa pilotażowa, potem kolejne grupy użytkowników.
• Okno wsparcia: Helpdesk lub odpowiedzialni administratorzy są dostępni podczas pierwszych logowań.
• Monitorowanie: Obserwuj Log Viewer, reverseproxy.log i źródło uwierzytelniania.
• Reset tokenów: Jasna procedura dla zgubionych lub źle skonfigurowanych tokenów OTP.
• Zachowanie sesji: Sprawdź timeout sesji i czas życia sesji po rzeczywistym użytkowaniu.
• Ścieżka awaryjna: Dokumentuj regułę WAF, politykę uwierzytelniania i kroki zmian.

Dla aplikacji krytycznych dla biznesu nie należy planować go-live na czas, kiedy nikt nie może dokładnie sprawdzić problemów z logowaniem. Lepiej jest mieć kontrolowane okno z użytkownikami testowymi z różnych grup, potem krótki przegląd logów i dopiero potem rozszerzenie na kolejnych użytkowników.

Po kilku dniach warto ponownie sprawdzić konfigurację:

• Czy są użytkownicy, którzy omijają MFA, ponieważ uzyskują dostęp przez inną regułę WAF lub inny URL?
• Czy dostęp jest nadal dozwolony tylko dla planowanych grup?
• Czy czas trwania sesji i timeout bezczynności pasują do aplikacji?
• Czy odrzucone logowania i problemy z tokenami są rzeczywiście widoczne w operacji?
• Czy są przypadki wsparcia wskazujące na niejasną komunikację z użytkownikami lub niewłaściwą aplikację uwierzytelniającą?
• Czy stare reguły testowe, domeny testowe lub tymczasowe wyjątki zostały usunięte?

Ten etap jest szczególnie ważny, jeśli wiele nazw hostów, ścieżek lub reguł WAF wskazuje na tę samą aplikację. W przeciwnym razie może się zdarzyć, że jedna ścieżka jest dobrze chroniona przez MFA, ale druga ścieżka pozostaje dostępna bez wstępnego uwierzytelniania.

Rozwiązywanie problemów

Inne częste błędy

• Polityka uwierzytelniania nie używa Form: Zachowanie MFA nie pasuje do oczekiwanej konfiguracji WAF.
• Sophos Authenticator zaplanowano jako nową aplikację standardową: Aplikacja jest EOL i nie powinna już być podstawą nowego wdrożenia.
• Dostęp awaryjny zależy od tej samej reguły WAF: Administratorzy nie mogą poprawnie wycofać zmiany w przypadku błędu.
• Wdrażanie tokenów nie zostało przetestowane: Użytkownicy nie mogą się zalogować po raz pierwszy, mimo że reguła WAF jest technicznie poprawna.
• Drugi URL lub druga reguła WAF pozostaje aktywna bez MFA: Użytkownicy nieumyślnie omijają wstępne MFA.
• Tymczasowe wyjątki pilotażowe nie zostały usunięte: Ochrona produkcyjna jest niespójna i trudna do audytu.

MFA nie jest wymagane

Najpierw sprawdź, czy Web application firewall jest aktywowane w sekcji Require MFA for. Następnie sprawdź, czy reguła WAF rzeczywiście używa polityki uwierzytelniania i czy ta polityka zawiera oczekiwanych użytkowników lub grupy.

Logowanie działa, ale aplikacja się nie otwiera

Problem często leży po logowaniu do firewalla. Sprawdź dostępność backendu, certyfikat, nagłówek hosta, ścieżkę, politykę ochrony i przekazywanie uwierzytelniania. Jeśli backend oczekuje własnego uwierzytelniania, tryb przekazywania musi do niego pasować.

Użytkownik nie może się zalogować po zmianie algorytmu

Jeśli zmieniono z SHA1 na SHA256 lub SHA512, istniejące tokeny muszą zostać usunięte i ponownie zeskanowane. Dodatkowo aplikacja uwierzytelniająca musi obsługiwać nowy algorytm.

Backend po udanym MFA ponownie pyta o login

W SFOS 22.0 GA Respin Build 411 może wystąpić NC-177509: oparte na formularzu WAF-MFA kończy się powodzeniem, ale backend żąda później dodatkowego logowania, którego nie można pominąć. Kod OTP nie jest oddzielany od hasła, zanim firewall przekaże dane logowania do backendu. Sophos wymienia problem na Known Issues List i wskazuje SFOS 22.0 MR1 Build 490 jako wersję z poprawką.

W informacjach o wydaniu SFOS 22.0 technicznie zgodna poprawka jest opisana jako NC-177201.

Sprawdzić:

• WAF Authentication Policy używa Form.
• Authentication forwarding mode jest aktywny i pasuje do aplikacji backendowej.
• Dotknięta reguła WAF używa dokładnie tej Authentication Policy.
• Błąd występuje po udanym MFA, a nie już przy logowaniu do firewalla.
• reverseproxy.log, Log Viewer i log dostępu backendu obejmują ten sam moment testu.
• Używana wersja SFOS została sprawdzona.

Na dotkniętym systemie GA należy zabezpieczyć reverseproxy.log, Log Viewer i log backendu oraz zaplanować aktualizację do MR1 Build 490 lub nowszej wersji. Jeśli szybka aktualizacja nie jest możliwa, Sophos wskazuje kontakt z Sophos Support jako rozwiązanie tymczasowe. Nie należy ogólnie osłabiać MFA ani pochopnie zmieniać Authentication Forwarding: None pasuje tylko wtedy, gdy backend nie potrzebuje przekazywanych danych logowania. W przypadku portali produkcyjnych plan powinien obejmować użytkowników testowych, wycofanie zmian i komunikację z użytkownikami.

Zbyt wiele lub stare sesje

Sprawdź timeout sesji, czas życia sesji i globalne ustawienia sesji WAF. W środowiskach produkcyjnych powinno być jasne, czy długie sesje są pożądane, czy użytkownicy powinni szybko ponownie się uwierzytelnić po bezczynności.

Lista kontrolna

• Reguła WAF jest udokumentowana i przetestowana zewnętrznie.
• Certyfikat HTTPS pasuje do opublikowanej nazwy hosta.
• MFA dotyczy właściwej grupy użytkowników.
• Require MFA for > Web application firewall jest aktywowane.
• Polityka uwierzytelniania WAF używa Form.
• Przekazywanie uwierzytelniania pasuje do aplikacji backendowej.
• Wdrażanie tokenów, dostęp do portalu i procedura helpdesku są przygotowane.
• Timeout sesji i czas życia sesji są świadomie ustawione.
• Aplikacja OTP i algorytm haszujący zostały przetestowane.
• Dostęp awaryjny administratora jest dostępny.
• Wycofanie i odpowiedzialna osoba są udokumentowane.
• Źródło uwierzytelniania i logowanie do backendu zostały oddzielnie sprawdzone.
• Log Viewer i reverseproxy.log zostały sprawdzone po teście.
• Okno wsparcia go-live i procedura resetowania tokenów są ustalone.
• Alternatywne nazwy hostów, ścieżki i reguły WAF zostały sprawdzone pod kątem omijania MFA.
• Tymczasowe wyjątki pilotażowe zostały usunięte po wdrożeniu.

Często zadawane pytania