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.

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.

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.

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

Elementy konfiguracji

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

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. Zapisz konfigurację.

Jeśli użytkownicy mają sami skonfigurować swój token, muszą mieć dostęp do portalu, na którym wyświetlany jest kod QR. W wielu środowiskach istotne jest w tym celu User Portal lub VPN Portal. Ogólne planowanie MFA jest opisane w Aktywowanie MFA dla Sophos Firewall WebAdmin, VPN Portal i Zdalnego Dostępu.

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

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

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.

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

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.

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.

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.

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.

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:

Jeśli tylko przeglądarka działa poprawnie, ale nie ma odpowiednich logów, akceptacja jest niekompletna. Wtedy należy sprawdzić, czy właściwa reguła WAF jest dopasowana, 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:

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.

Typowe błędy

Rozwiązywanie problemów

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.

Hasło i OTP są przekazywane do backendu

Przy WAF-MFA należy sprawdzić, czy wersja firewalla jest aktualna. W SFOS-22.0-Release-Notes jest udokumentowany naprawiony błąd WAF, w którym kod OTP nie został usunięty z hasła przed przekazaniem danych do backendu.

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