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 prawidłowo zaprojektowanych 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. Sophos WAF nie obsługuje WebDAV; aplikacje takie jak Nextcloud nie są więc obsługiwanymi publikacjami WAF. Należy zaplanować inną architekturę z odpowiednimi regułami firewalla i własną ochroną dostępu; publikacja bez WAF nie zachowuje automatycznie jego uwierzytelniania ani ochrony aplikacyjnej.

WAF chroni w warstwie 7 między innymi przed manipulacją plikami cookie, adresami URL i formularzami. Serwer webowy, Protection Policy i Authentication Policy są powiązane przez regułę WAF; obsługiwane jest maksymalnie 60 reguł WAF. Usługą WAF zarządza się w System services > Services. Jej restart wpływa na publikowane aplikacje i nie jest pierwszym krokiem przy pojedynczym błędzie logowania.

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, rejestrowanie zdarzeń, ścieżkę audytu i sesje aplikacji.
• Aplikacja potrzebuje WebDAV: Wybierz inną architekturę; pilotaż nie zmienia braku obsługi WAF w obsługiwane rozwiązanie. Dla innych specjalnych protokołów sprawdź zgodność osobno przed wdrożeniem.
• 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 prawidłowe aktualizowanie 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. Odpowiednia 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. Wartości domyślne to 30 sekund dla Default token timestep, 2 dla Maximum verification code offset i 10 dla Maximum initial verification code offset.
6. Zapisz konfigurację.

Gdy Generate OTP token with next sign-in jest aktywne, User portal jest wybierany automatycznie. Użytkownicy najpierw logują się do VPN portal lub User portal i tam skanują kod QR. Domyślny administrator może zamiast tego użyć konsoli WebAdmin, gdy MFA jest wymagane przy jego logowaniu do WebAdmin. Ten etap wdrożenia musi działać przed pierwszym dostępem WAF. Ogólne planowanie MFA opisano w Włączanie MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access.

Dwie wartości przesunięcia nie są standardowym sposobem naprawiania nieprawidłowego czasu. Przy 30-sekundowym kroku Maximum verification code offset równy 2 akceptuje na przykład niewykorzystany kod z poprzednich 60 sekund. Większe okno zwiększa tolerancję logowania, ale wydłuża też ważność starszych kodów. Najpierw popraw NTP i czas telefonu, a przesunięcie zmieniaj tylko z udokumentowanego powodu.

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.

Podczas wdrożenia znaczenie ma również mobilny system operacyjny. Skanowanie kodu QR w aplikacji Okta dla tych tokenów nie działa ani na iOS, ani na Androidzie. W iOS to samo ograniczenie dotyczy też Google Authenticator, Duo i Microsoft Authenticator. W takich przypadkach użytkownik musi ręcznie wpisać Base32 secret. Należy uwzględnić to w instrukcji dla użytkownika; inaczej poprawna konfiguracja firewalla może wyglądać na uszkodzoną, jeśli runbook opisuje tylko skanowanie QR.

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 ustaw tryb klienta na Form. Uwierzytelnianie oparte na formularzu tworzy pliki cookie sesji i umożliwia osobne wylogowanie; firewall kontroluje logowanie przez formularz i sesje.

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.

Dokumentacja API XML dla SFOS 23 opisuje opcjonalny parametr RedirectToRequestedURL wyłącznie dla trybu klienta Form, z wartościami Enable i Disable. Przy Enable użytkownik po pomyślnym uwierzytelnieniu jest przekierowywany do pierwotnie żądanego adresu URL. Dokumentacja nie podaje wartości domyślnej tego parametru; jego nazwa w API nie jest potwierdzoną etykietą pola w GUI. Przekierowanie nie zastępuje ani uwierzytelniania, ani sprawdzania uprawnień.

Wybór odpowiedniego przekazywania uwierzytelniania

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

• None: Brak uwierzytelniania backendu przez firewall; uwierzytelnianie na wejściu nadal działa. Przy usuwaniu nagłówka Basic przesłanego przez klienta znaczenie ma również Remove basic header.
• 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.

W trybie klienta Basic opcja Basic prompt jest jedynie tekstem w oknie przeglądarki. W trybie przekazywania Basic opcja Username affix dodaje skonfigurowany prefiks lub sufiks, gdy wpisano samą nazwę użytkownika. Pełne nazwy logowania należy sprawdzić osobno, aby nie zdublować domeny lub sufiksu w backendzie. HTTP Basic jest zgodne z RFC 7617; kodowanie nie szyfruje danych logowania.

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. Poniższa lista kontrolna i przypisanie przez Protected servers dotyczą SFOS 22; dla SFOS 23 wymagane są dodatkowo opisane dalej jawne kontrole każdej ścieżki w Traffic routing.

Zapisanie reguły WAF powoduje ponowne uruchomienie wszystkich reguł ochrony serwerów WWW. Aktywne połączenia korzystające z tych reguł zostają przerwane i muszą zostać ponownie nawiązane. Uzgodnij zmianę z osobami odpowiedzialnymi za wszystkie aplikacje objęte jej skutkami w odpowiednim oknie zmian, zachowaj poprzednie ustawienia i sprawdź potem dostępność, logowanie z OTP oraz dostęp do backendu. Tego skutku ani ścieżki przywracania nie przetestowano tutaj na urządzeniu.

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.

SFOS 23: Przypisanie MFA do każdej ścieżki portalu

Sama zewnętrzna akcja reguły Protect with web server protection nie wystarcza. Dla każdej ścieżki portalu, która ma być chroniona, na każdej publikowanej nazwie hosta i w każdej powiązanej regule WAF konfiguracja ścieżki musi być poprawna; dotychczasowe kroki MFA i limity sesji pozostają niezmienione.

1. W Traffic routing edytuj lub dodaj każdą chronioną ścieżkę portalu i ustaw Action > Protect. Przypisz przewidziane obiekty backendu z Web server > Web servers.
2. W polu Authentication wybierz przewidzianą politykę uwierzytelniania. Musi ona używać trybu klienta Form i zawierać zamierzoną grupę użytkowników; przypisanie grupy musi pasować do konfiguracji MFA. Dla każdej ścieżki sprawdź Allowed client networks oraz pozostałe ograniczenia źródeł i dostępu, w tym świadomie wybrane blokady sieci i krajów.
3. Jeśli dozwolone są tylko określone ścieżki portalu, pozostaw / z akcją Block jako trasę domyślną dla żądań bez bardziej specyficznego dopasowania. Jeśli zamierzone jest ustawienie Protect dla / w celu publikacji całej aplikacji, przypisz tam to samo przewidziane uwierzytelnianie i odpowiednie ograniczenia dostępu. Dokładnie sprawdź alternatywne ścieżki i nazwy hostów pod kątem równoważnej ochrony lub zamierzonej blokady.
4. Zachowaj dotychczasowe testy pomyślnego logowania z hasłem i OTP, działania backendu, wylogowania, wygaśnięcia sesji i ponownego logowania. Błędny OTP i użytkownicy spoza dozwolonej grupy muszą skutkować niepowodzeniem; alternatywne ścieżki lub nazwy hostów nie mogą otwierać niechronionego dostępu. Skoreluj wynik po stronie klienta z logami WAF, uwierzytelniania i backendu.

Granica dokumentacji dotyczącej Passthrough: Przegląd reguł opisuje uwierzytelnianie jako funkcję Protect; jednocześnie tabela ustawień akcji routingu Passthrough zawiera pole Authentication. Ta rozbieżność nie potwierdza ani wymuszania MFA, ani omijania MFA przy Passthrough. Dlatego wymagane WAF-MFA opieraj na jawnie skonfigurowanych ścieżkach Protect, a nie na niepotwierdzonym zachowaniu Passthrough. Niezbędne tunele WebSocket uzgodnij osobno z osobami odpowiedzialnymi za routing WAF i uwierzytelnianie.

Basic with passthrough oznacza tryb uwierzytelniania służący do przekazywania danych logowania; natomiast Passthrough w Traffic routing jest akcją routingu określającą sposób obsługi ruchu. Podobna nazwa nie oznacza żadnej właściwości związanej z MFA. W ramach podstawowej publikacji osoby odpowiedzialne muszą sprawdzić konfigurację ścieżek SFOS 23 razem z przypisaniem MFA: niezmieniony tutorial Sophos dotyczący ochrony przed atakami nie jest kompletną instrukcją routingu dla SFOS 23, a reguły WAF obsługują tylko IPv4.

Bezpieczne dostosowanie Authentication Template

Własny formularz tworzy się w Web server > Authentication templates > Add. W kodzie HTML muszą pozostać formularz z action="<?login_path?>" i method="POST" oraz pola httpd_username i httpd_password. W przypadku MFA musi też występować otp_field. Usunięcie lub zmiana nazw tych elementów może uniemożliwić logowanie, nawet jeśli strona wygląda poprawnie.

Dla obrazów, stylów i skryptów SFOS udostępnia między innymi zmienne <?assets_path?>, <?admin_contact?>, <?company_logo?> i <?company_text?>. Przesyłane assets są ograniczone do .jpg, .jpeg, .png, .ico, .css i .js. Template należy najpierw przetestować z użytkownikiem pilotażowym; produkcyjne dane logowania, zewnętrzne trackery i niesprawdzony JavaScript nie powinny znaleźć się na stronie logowania.

Po Add podaj nazwę, wybierz plik HTML i jego zasoby, kliknij Upload, a następnie Save. Wybierz zapisany szablon w polityce uwierzytelniania Form. Ten minimalny formularz zachowuje wymagane nazwy techniczne; to przykład oparty na dokumentacji, nie szablon przetestowany na urządzeniu:

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

Sprzeczności w dokumentacji szablonów: Krótki przykład hasła używa type="text", ale definicja pola i pełny przykład podają type="password". Zachowaj maskowanie hasła. Ponadto uwaga wymienia tylko <?login_path?> jako zastępowaną zmienną, podczas gdy tabela opcjonalna opisuje także zastępowanie <?assets_path?> i <?admin_contact?>. Nie potwierdza to zachowania każdej wersji firmware. Przed wdrożeniem sprawdź wyrenderowany formularz, ścieżki zasobów, wprowadzanie OTP i logowanie z grupą pilotażową; nie zastępuj działającego szablonu bez walidacji.

<?assets_path?> wskazuje ścieżkę przesłanych plików pomocniczych, na przykład w <link rel="stylesheet" href="<?assets_path?>/stylesheet.css">. Dzięki temu obrazy i CSS mogą pozostać poza formularzem. Opis pola wiąże <?admin_contact?> z Administration > Notification settings > Email settings > Send notifications to email address; sprawdź, czy adres może być publicznie wyświetlany. Zastąp <?company_logo?> ścieżką własnego logo, a <?company_text?> zamierzonym tekstem widocznym, zamiast zakładać automatyczne zastępowanie. Jeśli zmienne pozostają widoczne lub logowanie nie działa, wróć do zapisanego działającego szablonu i wyjaśnij przyczynę ze wsparciem zamiast wyłączać MFA.

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.

Maximum sessions jest wspólne dla wszystkich reguł WAF z uwierzytelnianiem Form. Po osiągnięciu limitu firewall zamyka stare lub wygasłe sesje, aby dopuścić nowe. Ponowne żądania logowania mogą więc wynikać z globalnej pojemności, a nie tylko z timeoutu pojedynczej polityki.

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.

Bezpieczne zarządzanie globalnymi ustawieniami WAF

Web server > General settings dotyczy wszystkich chronionych serwerów webowych, nie tylko portalu MFA. Przed zmianami zapisz wartości, ustal aplikacje objęte zmianą i zgodność klientów oraz zaplanuj okno serwisowe i wycofanie zmian. Wskazówki sprawdzono na podstawie dokumentacji; skutków i wycofania nie testowano na urządzeniu.

Slow HTTP protection ogranicza oczekiwanie na niekompletne nagłówki żądań. Podczas DoS Slow HTTP powoli napływające fragmenty zajmują połączenia aż do wyczerpania pojemności:

• Soft limit: minimalny czas na odebranie nagłówka żądania.
• Hard limit: maksymalny czas na jego odebranie.
• Extension rate: ilość danych w bajtach; każde przekroczenie wydłuża timeout soft o sekundę.
• Skipped networks/hosts: celowane wyjątki. Używaj tylko typów hostów IP IP i Network, nie IP ranges ani IP lists. Szerokie wyjątki wyłączają ochronę także dla niepożądanych klientów.

Po dostosowaniu sprawdź zwykłych i wolnych legalnych klientów oraz pozostałe aplikacje WAF. Nie przyjmuj dowolnych timeoutów jako ogólnej naprawy problemów z logowaniem.

TLS version settings określa dozwolone połączenia klientów. Udokumentowane profile różnią się również zestawami szyfrów:

• TLS v1 or later: bez SSLv3; profil legacy, niezalecany dla nowych portali.
• TLS v1.1 or later: bez SSLv3 i TLSv1; również nie jest nowoczesnym standardem wdrożenia.
• TLS v1.2 (wide compatibility): tylko TLSv1.2, w tym niezalecane szyfry legacy.
• TLS v1.2 (strict): tylko TLSv1.2 z zalecanymi szyframi.
• TLS v1.3: tylko szyfry TLSv1.3.

Przed wyborem sprawdź obsługę po stronie klientów; na przykład IE 8 lub starszy i Windows XP nie mogą łączyć się przez TLS 1.2. Nie osiągaj zgodności legacy przez ogólne osłabianie bezpieczeństwa. Najpierw przetestuj ścisły profil z rzeczywiście potrzebnymi klientami i wszystkimi publikowanymi aplikacjami.

W Custom TLS pola Protocols, Cipher suite i TLS v1.3 cipher suite only używają składni OpenSSL. Szyfry TLSv1.3 należą tylko do osobnego pola TLSv1.3, nie do Cipher suite. Nieprawidłowe protokoły lub szyfry mogą uniemożliwić start Apache i zakłócić WAF. Nie eksperymentuj z Custom TLS w produkcji bez zweryfikowanej konfiguracji; przy awarii przywróć zapisane wartości i sprawdź stan usługi oraz dostęp HTTPS do wszystkich objętych portali.

SFOS 23 – Worker customization: Firewall oblicza pojemność WAF według CPU i RAM. Obliczone wartości są zoptymalizowane dla sprzętu; zwykle nie trzeba ich zmieniać. Wyższe wartości mogą pogorszyć wydajność WAF i wykorzystanie zasobów. Włączaj Use custom worker profile tylko po starannej ocenie pojemności i skutków, nie jako ogólną naprawę logowania:

• Start servers: procesy worker przy starcie serwera webowego.
• Server limit: maksymalna liczba procesów worker.
• Minimum spare threads: minimalna liczba utrzymywanych wolnych wątków.
• Maximum spare threads: próg wolnych wątków, powyżej którego nadmiar jest usuwany.
• Threads per child: maksymalna liczba wątków na proces worker.
• Asynchronous request worker factor: steruje skalowaniem procesów dla asynchronicznych połączeń i żądań.

Nie kopiuj uniwersalnych liczb z innych systemów. Zapisz wartości początkowe, obserwuj reprezentatywne obciążenie i zasoby oraz po każdej uzasadnionej zmianie ponownie sprawdź logowanie, OTP, sesje i dostęp do backendu. W razie pogorszenia przywróć zapisaną konfigurację początkową; nie twierdzimy tutaj, że wycofanie zostało wykonane pomyślnie.

Automatyzacja uwierzytelniania WAF przez XML API

Automatyzacja wymaga współdziałania trzech odrębnych obiektów: FormTemplate udostępnia formularz logowania, ReverseAuthentication definiuje uwierzytelnianie klienta i backendu, a FirewallRule wiąże politykę z publikowaną usługą lub jej ścieżkami. Najpierw należy wykonać kopię zapasową działającego szablonu, polityki i wszystkich korzystających z niej reguł. Dostęp, jawne operacje zapisu, analizę odpowiedzi i bezpieczne ponawianie opisuje Zabezpieczanie dostępu do Sophos Firewall XML API. Poniższe informacje opisują dokumentację referencyjną SFOS-22/23, a nie procedurę zapisu przetestowaną na urządzeniu. Przed wprowadzeniem zmian należy sprawdzić API help zainstalowanej kompilacji; jeśli pola lub powiązania dotyczące przesyłania plików pozostają niewyjaśnione, nie należy wykonywać zapisu.

Rozróżnianie trybu klienta, backendu i sesji

W obiekcie ReverseAuthentication pola Name, VirtualWebserverMode i RealWebserverMode są opisane jako wymagane. Name dopuszcza maksymalnie 60 znaków. VirtualWebserverMode wybiera Basic lub Form dla klienta; udokumentowana wartość domyślna Basic nie stanowi zalecenia dotyczącego MFA. W przypadku MFA dla WAF nadal wymagany jest Form. BasicPrompt to opcjonalny tekst komunikatu Basic o długości maksymalnie 255 znaków. FormTemplate wskazuje zapisany szablon w trybie Form. UserGroupList zawiera powtarzalne wpisy UserGroup dla istniejących użytkowników lub grup; wybór ten nadal musi odpowiadać grupie MFA. Słowo Mode w uwagach dotyczących zastosowania nie jest dodatkowym, potwierdzonym znacznikiem XML.

RealWebserverMode niezależnie wybiera Basic lub None dla backendu; również tutaj tabela podaje Basic jako wartość domyślną. Przy Basic pole UsernameAffix dotyczy logowania do backendu. Prefix i Suffix to opcjonalne teksty o długości maksymalnie 255 znaków każdy, przeznaczone wyłącznie dla odpowiedniego wyboru afiksu. Przy None istotne jest zamiast tego RemoveBasicHeader z wartością Enable lub Disable. Podana tam wartość domyślna ON sama w sobie nie jest dozwoloną wartością wejściową; jawnych wartości należy używać dopiero po sprawdzeniu kompilacji. Dotychczasowe kontrole HTTPS, backendu i nazw użytkowników pozostają wymagane.

Nie przenosić sprzeczności do payloadu: Dla UsernameAffix wzorzec XML pokazuje None/Prefix/Suffix/PrefixAndSuffix, natomiast tabela wymienia Basic, Prefix, Suffix, PrefixandSuffix, a jednocześnie wartość domyślną None. Nie należy zgadywać ani pisowni, ani dodatkowych wartości do wyboru. Podobnie wzorzec pokazuje SessionTimeout i SessionLifetime jako przełączniki, odpowiadające im pola Limit jako liczby całkowite, a pola Scope jako Hours/Minutes/Days. Tabela potwierdza dla SessionTimeoutLimit zakres od 1 do 9999, ale w przypadku SessionLifetime i SessionLifetimeLimit zamienia miejscami liczbę całkowitą i przełącznik; wartości takie jak ON i 8 Hours nie są spójne z typami danych. Te niespójności nie potwierdzają wiarygodnych wartości domyślnych ani możliwej do zastosowania konfiguracji sesji. Należy potwierdzić żądany limit bezczynności i maksymalny czas trwania w zainstalowanej kompilacji, odczytać zapisany stan oraz przeprowadzić dotychczasowe testy sesji, wylogowania i ponownego logowania. Dodane w SFOS-23 pole RedirectToRequestedURL i jego osobny test przekierowania powrotnego pozostają od tego niezależne.

Przyporządkowanie szablonu i plików towarzyszących

Dokumentacja referencyjna FormTemplate pokazuje FormTemplate jako obiekt z polami Name, Description, Template i Assets, w tym powtarzalnymi wpisami Asset. Name i Template są polami wymaganymi: nazwa dopuszcza maksymalnie 60 znaków, a Template jest ciągiem znaków o długości maksymalnie 255 znaków służącym do wyboru i przesłania szablonu HTML. Description jest opcjonalne. Opcjonalne ciągi Asset dopuszczają maksymalnie 255 znaków każdy i wiele wartości dla używanych obrazów, arkuszy stylów lub plików JavaScript.

Wzorzec pozostawia Template i Asset puste. Nie określa tym samym ani nazw części multipart, ani ścieżek plików, kodowania Base64 czy treści HTML, którą można przesłać bezpośrednio. Nie należy przenosić powiązania używanego do przesyłania certyfikatów na FormTemplates. Bez potwierdzonego kontraktu przesyłania należy użyć istniejącej sekwencji GUI Upload > Save, a następnie wybrać zapisany szablon przez FormTemplate w polityce Form. Wymagane pola formularza i dozwolone typy plików zasobów z poprzedniej sekcji nadal obowiązują. Należy sprawdzić wyrenderowany formularz, zasoby i logowanie OTP przy użyciu użytkownika testowego; samo pomyślne zapisanie obiektu nie dowodzi, że formularz działa.

Powiązanie Authentication Policy z regułą

W przypadku FirewallRule to przyporządkowanie dotyczy gałęzi WAF HTTPBasedPolicy, a nie NetworkPolicy ani UserPolicy. Tabela parametrów opisuje Authentication jako opcjonalny skalarny ciąg znaków dla Authentication Policy. We wzorcu ścieżek odpowiednie przyporządkowanie występuje jako AccessPaths > AccessPath > auth_profile. Komentarz we wzorcu oddziela wariant obejmujący całą regułę, z Authentication i kontrolą źródeł, od AccessPaths; nie potwierdza dowolnego łączenia ani automatycznego dziedziczenia. Nie należy bez sprawdzenia mieszać zapisu dla całej reguły z zapisem dla poszczególnych ścieżek ani zakładać, że polityka istniejąca na firewallu chroni już każdą ścieżkę.

W SFOS 23 tabela opisuje path jako wymaganą tablicę ciągów znaków z wieloma wartościami, o długości maksymalnie 63 znaków, bez przecinka i z obsługą UTF-8; SFOS 22 podaje tutaj wartość skalarną. Wzorzec używa zarówno path, jak i Path. backend jest opcjonalne w tabeli SFOS-23; nie jest to zapewnienie, że chroniony portal działa bez backendu. Nowe pole action dla ścieżki pokazuje dosłownie 0/1/2/3, bez wiarygodnego przyporządkowania do działań w GUI. Nie należy zgadywać przyporządkowania liczb ani utożsamiać tych wartości z polem sieciowym Action. Routing, backend i profil ochrony opisuje WAF: bezpieczne publikowanie serwerów WWW.

Aby zmienić uwierzytelnianie, należy najpierw odczytać rzeczywiste nazwy hostów i ścieżki reguły docelowej, przyporządkować żądaną politykę Form do każdej chronionej ścieżki, a następnie porównać zapisany stan ze stanem oczekiwanym. Należy sprawdzić wszystkie alternatywne ścieżki, nazwy hostów i reguły, a także nieprawidłowe OTP oraz użytkowników spoza grupy. Opisane wcześniej kontrole Protect, ograniczenie dokumentacji dotyczące Passthrough i okno zmian dla reguł WAF obowiązują przy tym bez zmian.

Analiza odpowiedzi obiektów przed ponowieniem

Poniższe przyporządkowania to wartości statusu XML i dosłowne, nierozwinięte symbole Message.* z dokumentacji referencyjnej, a nie kody statusu HTTP ani potwierdzone teksty komunikatów zwracanych podczas działania. W przypadku powiązania FirewallRule szczególnie ważne są różnice między Add i Edit:

• 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. Przy 202 należy również odczytać rzeczywistą nazwę i wszystkie przyporządkowania.
• Różne przyporządkowania: Add 541 / Message.VHIPRangeConflict, Edit 541 / Message.FWRuleFailMaxUser; Add 543 / Message.CannotSetupRedirectionFromHTTP, Edit 543 / Message.CannotUseDefaultPort; Add 544 / Message.CannotUseDefaultPort, Edit 544 / Message.CannotSetupRedirectionFromHTTP. Sam identyczny kod nie wystarcza do interpretacji.
• Dalsze wiersze z różnicami: 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 występuje również przy Add i Edit; należy wyjaśnić rzeczywisty stan uprawnień i zarządzania, a nie obchodzić go przez ślepe ponawianie lub usuwanie. Usunięcie reguły nie jest sposobem naprawy brakującego powiązania uwierzytelniania.

Również oba wcześniejsze obiekty mają własne odpowiedzi:

• 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. Pisownia Recod w tych symbolach pozostaje zachowana dosłownie; nie należy na tej podstawie wywodzić dodatkowego statusu dla innej operacji.

Należy wspólnie udokumentować operację, kod, rzeczywistą odpowiedź i zapisany stan szablonu, polityki oraz reguły docelowej. W przypadku błędów, ostrzeżeń lub niejasnej odpowiedzi należy najpierw sprawdzić, co rzeczywiście zostało zastosowane; nie należy obchodzić problemu przez drugą nazwę, szerszą grupę lub niechronioną ścieżkę. Jeśli składnia lub przyporządkowanie przesyłanych plików pozostają niewyjaśnione, należy się zatrzymać i zwrócić się do wsparcia technicznego z oczyszczonymi danymi. Dopiero po potwierdzeniu zapisu należy przeprowadzić dotychczasowe pozytywne i negatywne testy MFA, backendu, sesji, wylogowania, przekierowania powrotnego i alternatywnych ścieżek. Weryfikacja dokumentacji nie zastępuje testów odbiorczych na własnym firewallu.

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.

Aby dodatkowo sprawdzić powrót do żądanego adresu URL w SFOS 23, bez ważnej sesji WAF otwórz rzeczywiście chroniony adres URL ze ścieżką inną niż /. Po pomyślnym logowaniu z hasłem i OTP, przy RedirectToRequestedURL ustawionym na Enable, sprawdź, czy osiągnięty został dokładnie pierwotnie żądany adres URL i czy dostęp do backendu jest zgodny z zamierzonymi uprawnieniami. Samo udane przekierowanie nie potwierdza MFA ani uprawnienia do dostępu; wszystkie powyższe testy odmowy dostępu, backendu, sesji, wylogowania, ponownego logowania i alternatywnych ścieżek pozostają wymagane.

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. Problem jest usunięty od SFOS 22.0 MR1 Build 490.

Poprawka usuwająca kod OTP ma również odwołanie NC-177201. Identyfikatory nie są zamienne: NC-177509 wiąże wersje dotknięte problemem i wersje z poprawką, natomiast NC-177201 oznacza konkretny opis poprawki. W zgłoszeniu wsparcia należy podać objaw, build i oba odwołania.

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, nie należy wprowadzać niezweryfikowanych zmian w przepływie uwierzytelniania; zgromadzone dane trzeba wykorzystać, aby otworzyć zgłoszenie Sophos Support. 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