Włącz MFA dla Sophos Firewall WebAdmin, VPN Portal i dostępu zdalnego

Aby skorzystać z lokalnej funkcji OTP, należy otworzyć Authentication > Multi-factor authentication, najpierw wybrać Specific users and groups, włączyć wymagane usługi i przetestować wszystko z grupą pilotażową. Opcji All users należy użyć dopiero po pomyślnym zakończeniu testów.

MFA chroni WebAdmin, VPN Portal i dostęp zdalny przed użyciem samego skradzionego hasła. Nie zastępuje jednak restrykcyjnych reguł dostępu ani przetestowanego dostępu awaryjnego. Dlatego artykuł obejmuje cały proces: od bezpiecznej aktywacji po wybór aplikacji, odzyskiwanie dostępu i rozwiązywanie problemów.

Główna procedura konfiguruje lokalny Sophos OTP. W dalszej części RADIUS i Entra ID SSO są porównane jako rozwiązania alternatywne.

Bezpieczne włączanie Sophos OTP

Przed aktywacją

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

• Zapora używa prawidłowego czasu w Administration > Time, najlepiej za pośrednictwem NTP.
• Użytkownicy i grupy są dostępni lokalnie albo przez AD, LDAP lub inny serwer uwierzytelniania.
• Istnieją grupa pilotażowa i drugi, przetestowany administrator.
• Znane są konsola i procedura odzyskiwania dostępu dla domyślnego konta admin.
• Dostępne są aktualna kopia zapasowa i udokumentowana procedura resetowania tokenów.

W przypadku klasycznego Active Directory sposób konfiguracji źródła użytkowników opisuje artykuł Dodawanie Active Directory do Sophos Firewall.

W Administration > Device access określa się strefy, z których dostępne są WebAdmin, User Portal, VPN Portal i inne usługi lokalne. Reguły Local service ACL exception rules dodatkowo ograniczają dostęp do sieci zarządzających, sieci VPN lub znanych adresów źródłowych. Szczegółowy proces hardeningu przedstawia Zabezpieczanie dostępu do Sophos Firewall: prawidłowa konfiguracja Device Access.

SSH nie należy do usług chronionych przez Sophos OTP. Należy ograniczyć dostęp przez Device Access i w miarę możliwości używać klucza publicznego; procedurę opisuje Łączenie z Sophos Firewall przez SSH.

⚠️ MFA ogranicza ryzyko związane z przejętymi hasłami, ale nie zmniejsza powierzchni ataku usługi dostępnej publicznie. WebAdmin, SSH i portale nigdy nie powinny być udostępnione szerzej, niż jest to konieczne.

Przed testami negatywnymi należy również sprawdzić Administration > Admin and user settings > Login security > Block login. Kilka celowo nieudanych prób może zablokować źródłowy adres IP dla WebAdmin, CLI, VPN Portal i User Portal, a tym samym zablokować administratora awaryjnego z tej samej sieci. Dlatego trzeba zapewnić drugie źródło połączenia lub dostęp do konsoli.

Konfigurowanie MFA dla grupy pilotażowej

1. Zalogować się do WebAdmin i otworzyć Authentication > Multi-factor authentication.
2. W sekcji One-time password (OTP) najpierw wybrać Specific users and groups.
3. Otworzyć Add users and groups, wybrać grupę pilotażową i zastosować wybór.
4. Włączyć Generate OTP token with next sign-in, jeśli używana jest aplikacja uwierzytelniająca. W SFOS 23 wybrać także Share QR code: Email wysyła kod QR na adres e-mail użytkownika przy następnym logowaniu do VPN Portal lub User Portal. Portals wyświetla go w User Portal i VPN Portal po następnym logowaniu do VPN Portal, User Portal lub WebAdmin. Ten wybór nie dotyczy opisanego niżej kreatora domyślnego administratora.
5. W Require MFA for wybrać tylko rzeczywiście potrzebne interfejsy logowania.
6. W OTP hash algorithm wybrać algorytm obsługiwany przez planowaną aplikację.
7. Opcjonalne ustawienia OTP timestep settings zmieniać tylko wtedy, gdy aplikacja obsługuje taki sam krok czasowy; wartość domyślna wynosi 30 sekund.
8. Zapisać przyciskiem Apply.

Po wybraniu Apply należy od razu dokończyć procedurę z użytkownikiem pilotażowym: zależnie od wybranej usługi najpierw zalogować się do User Portal lub VPN Portal wyłącznie hasłem, zarejestrować kod QR albo klucz Base32 w aplikacji uwierzytelniającej, a następnie otworzyć nową sesję za pomocą <password><passcode>. Celowo błędny kod musi zostać odrzucony, a próba powinna być widoczna w Log viewer. All users można rozważyć dopiero po tym teście pozytywnym i negatywnym.

Znaczenie opcji użytkowników:

• No OTP: MFA jest wyłączone.
• All users: MFA obejmuje wszystkich użytkowników; opcji należy użyć dopiero po pilotażu.
• Specific users and groups: MFA obejmuje tylko wybrane konta lub grupy.

W przypadku użytkowników uwierzytelnianych zewnętrznie usunięcie z grupy MFA nie działa od razu przy pierwszym kolejnym logowaniu. Sophos nadal wymaga jednego logowania z MFA; kod OTP przestaje być potrzebny dopiero przy następnych logowaniach. Dlatego zmianę grupy należy sprawdzić w nowej sesji podczas co najmniej dwóch kontrolowanych logowań.

Po włączeniu Generate OTP token with next sign-in użytkownicy rejestrują aplikację przy następnym logowaniu. User Portal zostaje wtedy automatycznie wybrany jako usługa MFA. Po wyłączeniu tej opcji tokeny sprzętowe lub zarządzane ręcznie przypisuje się w Issued tokens.

Świadomy wybór usług

W SFOS 22 w sekcji Require MFA for dostępne są następujące usługi:

• User portal
• Web admin console
• VPN portal
• SSL VPN remote access
• IPsec remote access
• Web application firewall

MFA dla User Portal obejmuje również Captive Portal i Client Authentication Agents. Użytkownicy dostępu zdalnego muszą najpierw zarejestrować token przez VPN Portal lub User Portal.

W przypadku WAF samo wybranie usługi nie wystarcza. Od SFOS 22 wymagane są Webserver Protection, oparta na formularzu Authentication Policy oraz przypisanie jej do reguły WAF. Pełną procedurę opisuje Zabezpieczanie Sophos Firewall WAF za pomocą MFA.

Wybór odpowiedniego modelu MFA

Lokalne Sophos OTP

Sophos OTP zarządza tokenami bezpośrednio na zaporze i nie wymaga dodatkowej infrastruktury RADIUS ani dostawcy tożsamości. Nadaje się szczególnie dla zwykłych lokalnych użytkowników, małych środowisk oraz do szybkiego zabezpieczenia WebAdmin lub dostępu zdalnego.

Ceną za prostą implementację jest oddzielny token poza istniejącymi procesami Microsoft 365. Użytkownicy i help desk muszą znać rejestrację aplikacji, sposób wpisywania hasła plus OTP oraz procedurę zmiany urządzenia.

RADIUS lub Entra ID SSO

Istniejąca platforma MFA może lepiej pasować do centralnego zarządzania tożsamościami po integracji przez RADIUS lub SSO. Wymaga jednak testów specyficznych dla usług:

• VPN Portal nie obsługuje RADIUS z MFA typu challenge.
• Sophos Connect nie obsługuje challenge OTP. Klient wysyła hasło i OTP razem w formacie passwordotp, ale obsługuje MFA przez połączenie telefoniczne i powiadomienie push.
• User Portal i WebAdmin obsługują dodatkowo MFA typu challenge.
• W przypadku Entra ID SSO MFA odbywa się u dostawcy tożsamości; lokalnego Sophos OTP MFA nie można dodać do tego samego logowania SSO.
• Entra SSO z Sophos Connect wymaga w systemie Windows co najmniej klienta w wersji 2.4. WebAdmin SSO nie jest dostępne na pomocniczym urządzeniu HA.

Dla Remote Access dostępna jest osobna instrukcja Konfigurowanie Microsoft Entra ID SSO dla Sophos Connect i VPN Portal. Jeśli natomiast Entra ma sterować logowaniem do WebAdmin i rolami administratorów, artykuł Entra ID SSO dla WebAdmin Sophos Firewall prowadzi przez Role mapping, Least Privilege, logowanie pilotażowe i lokalny dostęp awaryjny.

W wyborze modelu dostępu zdalnego pomaga Sophos Connect czy SSL VPN: które rozwiązanie wybrać?; przed wdrożeniem należy również sprawdzić wersję klienta Sophos Connect.

Niezależnie od modelu należy zacząć od grupy pilotażowej. Kolejnych użytkowników dodaje się dopiero po sprawdzeniu WebAdmin, portali, rzeczywistych klientów VPN, grup, limitów czasu, logowania zdarzeń i procedury awaryjnej.

Konfigurowanie tokenów i aplikacji uwierzytelniającej

Rejestrowanie tokenów i zarządzanie nimi

Po włączeniu Generate OTP token with next sign-in użytkownik loguje się do VPN Portal lub User Portal i rejestruje kod QR w zgodnej aplikacji. W SFOS 22 kod QR jest wyświetlany; administratorzy mogą także zarejestrować token w WebAdmin, jeśli MFA jest tam wymagane. W SFOS 23 dostarczenie kodu zależy od Share QR code: przy Email należy użyć kodu QR otrzymanego e-mailem, a przy Portals — kodu wyświetlonego w portalach. Logowanie do WebAdmin może uruchomić wyświetlanie w portalach przy Portals, ale nie wysyłkę e-mail. Rejestracja dotyczy tylko użytkowników i grup, dla których skonfigurowano MFA.

Przy pierwszej rejestracji w SFOS 23 z Generate OTP token with next sign-in ustawionym na ON dla wybranych użytkowników MFA obowiązuje następująca zasada: wygenerowany kod QR wygasa, jeśli nie zostanie użyty do logowania w ciągu 24 godzin od wygenerowania. Aby wygenerować nowy, użytkownik loguje się do VPN Portal lub User Portal wyłącznie hasłem; nowy kod QR jest dostarczany zgodnie z Email lub Portals. Następnie należy zarejestrować go w aplikacji i sprawdzić nowe logowanie z <password><passcode>. Ten czas ważności QR jest odrębny od okna 300 sekund dla pierwszego kodu jednorazowego. Procedura nie dotyczy wydanego tokena ze stanem OFF ani ręcznego ponownego wydania seeda; nie należy jej zakładać dla SFOS 22 ani dla każdej procedury kreatora domyślnego administratora.

W Authentication > Multi-factor authentication > Issued tokens można sprawdzać wydane tokeny, czasowo je wyłączać, usuwać lub dodawać ręcznie. Można tam także generować dodatkowe kody jednorazowe oraz sprawdzać lub synchronizować przesunięcie czasu tokena.

Ustawienie stanu tokena na OFF uniemożliwia użytkownikowi logowanie; nie zapewnia dostępu wyłącznie hasłem. Nie jest to usunięcie i ponowna rejestracja ani pominięcie MFA dla jednego logowania przez Device Console.

Po utracie smartfona lub zmianie aplikacji najpierw należy zweryfikować tożsamość użytkownika. Bezpośrednio przed usunięciem tokena sprawdzić w Authentication > Multi-factor authentication, czy Generate OTP token with next sign-in jest ustawione na ON; w SFOS 23 ustawić także Share QR code na Email lub Portals. Jeśli tryb ręczny OFF jest zamierzony, zamiast tego przygotować ręczne wydanie nowego tokena z nowym seedem; poniższa automatyczna procedura QR nie ma wtedy zastosowania. Dopiero potem usunąć stary token w Issued tokens. Użytkownik loguje się raz do VPN Portal lub User Portal wyłącznie hasłem i rejestruje nowy kod QR: SFOS 22 go wyświetla, a SFOS 23 wysyła e-mailem lub wyświetla w portalu zgodnie z wyborem. Następnie sprawdzić nowe logowanie z <password><passcode>. Stary token nie powinien pozostawać równolegle aktywny bez kontroli.

W tej procedurze zmiany aplikacji lub wymiany w SFOS 23 wygenerowany kod QR wygasa, jeśli nie zostanie użyty do logowania w ciągu 24 godzin od wygenerowania. Ponowne logowanie wyłącznie hasłem generuje nowy kod QR, ponownie dostarczany przez Email lub Portals. Te 24 godziny dotyczą kodu QR, a nie opisanego niżej okna 300 sekund dla pierwszego kodu jednorazowego. Nie należy zakładać takiego czasu ważności QR dla SFOS 22 ani dla każdej procedury kreatora domyślnego administratora.

Ręczne udostępnianie tokena sprzętowego lub programowego

Jeśli firewall nie ma generować kodu QR, opcja Generate OTP token with next sign-in pozostaje wyłączona. Już zarejestrowane tokeny nadal działają, natomiast dla nowych użytkowników seed zapisuje się ręcznie w Authentication > Multi-factor authentication > Issued tokens > Add token (for hardware tokens). Nazwa przycisku jest węższa niż jego funkcja, ponieważ ten sam formularz służy również do ręcznego udostępnienia tokena programowego.

Najpierw należy wybrać OTP hash algorithm i krok czasowy wymagany przez konkretny token lub aplikację uwierzytelniającą. Następnie dla pola Secret obowiązują następujące zasady:

• W przypadku tokena sprzętowego należy wprowadzić jego indywidualny klucz otrzymany od producenta.
• W przypadku tokena programowego należy użyć unikalnego, wystarczająco losowego seeda w formacie szesnastkowym. Jeśli aplikacja wymaga Base32, seed konwertuje się lokalnie przy użyciu kontrolowanego narzędzia offline.
• Produkcyjnego seeda nie należy wprowadzać w publicznym konwerterze internetowym ani umieszczać w zgłoszeniu, niezaszyfrowanej wiadomości e-mail lub poleceniu powłoki zapisywanym w historii. Osoba znająca seed może generować prawidłowe kody OTP.

Jeśli konkretny token różni się od globalnego Default token timestep, opcję Use custom timestep włącza się tylko dla tego tokena i wprowadza rzeczywiście obsługiwany interwał. Bez tej opcji obowiązuje wartość globalna; przed zapisaniem należy sprawdzić zgodność aplikacji i sprzętu.

Następnie wybiera się dokładnie właściwego użytkownika i zapisuje konfigurację przyciskiem Save. Token sprzętowy lub seed Base32 przekazuje się jednorazowo chronionym kanałem. Potem należy przetestować prawidłowy i celowo nieprawidłowy kod, a w razie potrzeby zsynchronizować przesunięcie czasu w Issued tokens. Jeśli seed mógł zostać ujawniony, tokena nie należy dalej używać. Trzeba go usunąć i wydać nowy token z nowym seedem.

Kontrolowane wydawanie dodatkowych kodów jednorazowych

Jeśli aplikacja lub token sprzętowy są niedostępne tylko tymczasowo, należy edytować odpowiedniego użytkownika w Authentication > Multi-factor authentication > Issued tokens. W Additional codes przycisk plus generuje dodatkowe kody, a Save przypisuje je do tokena. Firewall automatycznie usuwa każdy kod z listy po jego użyciu.

Przed wydaniem kodów należy zweryfikować tożsamość użytkownika. Kody przekazuje się jednorazowo chronionym kanałem wyłącznie temu użytkownikowi i nie umieszcza się ich razem w niezabezpieczonym zgłoszeniu ani wiadomości e-mail. Dodatkowe kody nie zastępują ponownego wydania tokena trwale utraconego lub potencjalnie skopiowanego: stary token należy usunąć i zarejestrować nowy z nowym seedem.

Aplikacja i algorytm skrótu muszą być zgodne

SFOS 22 obsługuje SHA1, SHA256 i SHA512. Sophos zaleca SHA256 lub SHA512, ale wybrany algorytm musi być obsługiwany przez aplikację:

• Sophos Intercept X for Mobile i Google Authenticator obsługują SHA256 i SHA512.
• Microsoft Authenticator nie obsługuje tych dwóch algorytmów w tym procesie Sophos. Skanowanie kodu QR może się udać, ale późniejsze logowanie zakończy się niepowodzeniem.
• Duo Mobile i Okta Verify należą do aplikacji wymienianych przez Sophos; zgodność kodu QR i algorytmu musi odpowiadać używanemu systemowi operacyjnemu i konfiguracji.
• Inne aplikacje TOTP można zatwierdzić dopiero po rzeczywistym teście pilotażowym.

Sophos Intercept X for Mobile obsługuje niestandardowy krok czasowy tokena. Większość pozostałych aplikacji uwierzytelniających obsługuje tylko domyślne 30 sekund, dlatego wartości globalnej nie należy zmieniać wyłącznie ze względu na jedną aplikację.

W systemie iOS skanowanie kodu QR Sophos nie działa z Google Authenticator, Duo Mobile ani Microsoft Authenticator. Konto należy utworzyć ręcznie z użyciem wyświetlonego klucza Base32. Okta Verify wymaga ręcznej rejestracji Base32 zarówno w iOS, jak i Androidzie. Nie rozwiązuje to jednak braku obsługi SHA256/SHA512 przez Microsoft Authenticator.

Poprzednia aplikacja Sophos Authenticator osiągnęła End of Life 31 lipca 2022 roku i nie należy jej uwzględniać w nowych wdrożeniach.

Po aktualizacji z wersji wcześniejszej niż SFOS 22 należy spodziewać się istniejących tokenów SHA1, ponieważ wcześniejsze wersje SFOS generowały tokeny MFA z użyciem SHA1. Wybranie silniejszego algorytmu globalnego nie konwertuje tych istniejących tokenów.

Aby przejść z SHA1 na silniejszy algorytm:

1. Przetestować aplikację pilotażową z SHA256 lub SHA512.
2. Włączyć Generate OTP token with next sign-in. W SFOS 23 wybrać także Email lub Portals w Share QR code przed Apply.
3. Wybrać nowy algorytm w Authentication > Multi-factor authentication.
4. Zapisać ustawienia przyciskiem Apply.
5. Usunąć stare tokeny SHA1 w Issued tokens. Aby usunąć token domyślnego admin, trzeba być zalogowanym jako ten użytkownik; inny administrator nie może go usunąć. Wcześniej zapewnić przetestowany dostęp awaryjny i dostęp do konsoli.
6. Poprosić zwykłych użytkowników o zalogowanie się do VPN Portal lub User Portal wyłącznie hasłem i ponowne zarejestrowanie kodu QR lub klucza Base32 w aplikacji obsługującej SHA256/SHA512. W SFOS 23 dostarczenie QR odbywa się zgodnie z Email lub Portals. Dla domyślnego admin ponowna rejestracja po usunięciu rozpoczyna się natomiast logowaniem do WebAdmin wyłącznie hasłem, a nie przez User Portal lub VPN Portal; należy wykonać wyświetloną tam procedurę rejestracji. To migracja SHA, a nie Use an existing token w kreatorze ponownego włączania. Dla tego wyjątku nie należy zakładać dodatkowego pola Share QR code w kreatorze.
7. Przeprowadzić kontrolowane testy logowania z prawidłowym i nieprawidłowym kodem.

Podczas migracji mogą równolegle istnieć tokeny z różnymi algorytmami. Tokeny, które nie zostaną usunięte, nadal używają jednak starego algorytmu.

Ograniczanie kroku czasowego i okien tolerancji

W OTP timestep settings konfiguruje się nie tylko interwał nowych kodów, ale także dwa okna weryfikacji. Każda z trzech wartości ma inne działanie:

• Default token timestep określa interwał, w którym aplikacja lub token sprzętowy generuje nowy kod. Wartość domyślna wynosi 30 sekund. Zmiana dotyczy tylko nowo generowanych tokenów i nie modyfikuje istniejących.
• Maximum verification code offset określa, przez ile kroków czasowych pozostaje ważny niewykorzystany kod. Przy wartości domyślnej 2 i kroku 30 sekund akceptowane są również niewykorzystane kody z poprzednich 60 sekund.
• Maximum initial verification code offset dotyczy pierwszego kodu po zeskanowaniu kodu QR. Przy wartości domyślnej 10 i kroku 30 sekund okno wynosi 300 sekund, jeśli kod nie został wcześniej wykorzystany.

Te okna nie zastępują prawidłowej synchronizacji czasu. Najpierw należy sprawdzić NTP firewalla i czas urządzenia końcowego, a następnie utrzymywać każdy offset na najniższym poziomie praktycznym dla używanych aplikacji i tokenów sprzętowych. Większe okno odpowiednio dłużej akceptuje przechwycony, niewykorzystany kod. Po zmianie należy przetestować nowo wydany token pilotażowy; nie wolno zakładać, że istniejący token używa zmienionego kroku czasowego.

Prawidłowe wpisywanie hasła i OTP

W natywnym logowaniu Sophos OTP oficjalny format to <password><passcode>, bez spacji i separatorów.

Przykład:

Hasło:    MojeBezpieczneHaslo
Kod OTP:  123456
Wpisanie: MojeBezpieczneHaslo123456

Sophos Connect może wyświetlać osobne trzecie pole za pomocą otp: true. Klient wewnętrznie dołącza kod do hasła. Sposób wyświetlania nie zmienia formatu wysyłanego do serwera uwierzytelniania.

Zabezpieczanie i odzyskiwanie dostępu domyślnego administratora

Włączanie MFA dla domyślnego admina

Lokalnego, domyślnego użytkownika admin nie włącza się przez zwykłą listę użytkowników. Jego osobny kreator znajduje się w Administration > Device access, a nie w Issued tokens > Add token (for hardware tokens) dla zwykłych użytkowników.

Wcześniej trzeba sprawdzić działanie drugiego administratora, dostępu administracyjnego i dostępu do konsoli. Dodatkowe kody jednorazowe należy przechowywać bezpiecznie, na przykład w menedżerze haseł. Domyślny admin pozostaje kontem awaryjnym i nie służy do codziennego zarządzania.

Inni administratorzy nie mogą włączać, wyłączać, edytować ani usuwać tokena domyślnego admin. Wybrany globalny OTP hash algorithm obowiązuje również dla tego tokena.

Przed rozpoczęciem należy też sprawdzić czas, zgodność aplikacji lub sprzętu oraz Block login, jak opisano wyżej. Nowe tokeny sprzętowe i programowe korzystają z algorytmu ustawionego w Authentication > Multi-factor authentication > OTP hash algorithm; nie wybiera się go niezależnie w kreatorze domyślnego administratora. Udane skanowanie QR nie potwierdza zgodności algorytmu. Nadal obowiązują opisane wyżej ograniczenia aplikacji i Base32.

1. Zalogować się do WebAdmin jako domyślny admin i otworzyć Administration > Device access.
2. Włączyć MFA for default admin i kliknąć Apply.
3. Wybrać właściwą metodę tokena w kreatorze i kliknąć Next. Następnie dokończyć odpowiednią ścieżkę:

• Configure a hardware token: Wprowadzić indywidualny klucz dostarczony przez producenta urządzenia oraz krok czasowy zgodny z tokenem sprzętowym. Kliknąć Next, a następnie wpisać hasło domyślnego administratora i bezpośrednio po nim aktualny kod tokena sprzętowego w formacie <password><passcode>, bez spacji ani separatorów. Kliknąć Validate, a po pomyślnej weryfikacji zakończyć przyciskiem Apply.
• Generate a software token: Zainstalować zgodną aplikację uwierzytelniającą na urządzeniu mobilnym i zeskanować wyświetlony kod QR. Wpisać hasło domyślnego administratora i bezpośrednio po nim aktualny kod aplikacji w formacie <password><passcode>. Kliknąć Validate, a po pomyślnej weryfikacji zakończyć przyciskiem Apply.
• Use an existing token: Jeśli domyślny admin ma już token sprzętowy lub programowy i MFA jest tylko ponownie włączane, wybrać tę ścieżkę i wpisać hasło bezpośrednio przed aktualnym kodem. Aby zamiast tego skonfigurować nowy token programowy, wybrać Generate a software token i zarejestrować kod QR w aplikacji. Ten wybór nie jest migracją istniejących tokenów użytkowników SHA1.

Pierwsze Apply uruchamia konfigurację; nowe tokeny sprzętowe i programowe nadal wymagają Validate i końcowego Apply. Jeśli weryfikacja się nie powiedzie, najpierw sprawdzić hasło plus kod, czas, krok czasowy i algorytm, zamiast wielokrotnie zgadywać. Pozostawić obecną sesję otwartą podczas sprawdzania, a po zakończeniu konfiguracji przetestować osobną, nową sesję WebAdmin jako domyślny admin, używając hasła i nowego kodu. Uznać konfigurację za zakończoną dopiero po pomyślnym logowaniu i bezpiecznym zapisaniu kodów jednorazowych; drugi administrator nie zastępuje zarządzania tokenem domyślnego administratora ani opisanej poniżej procedury odzyskiwania przez konsolę.

Odzyskiwanie przez Device Console

Opcje menu 6 i 7 pojawiają się tylko wtedy, gdy MFA for default admin zostało już skonfigurowane w Administration > Device access. Jeśli ich nie ma, nie oznacza to automatycznie błędu konsoli; najpierw należy sprawdzić to ustawienie oraz czy konto jest rzeczywiście domyślnym użytkownikiem admin. Opcje nie dotyczą innych kont administratorów.

Jeśli token jest tylko tymczasowo niedostępny, w Device Console można zezwolić na jednorazowe logowanie bez MFA:

1. Wprowadzić 2 dla System Configuration.
2. Wprowadzić 6 dla Skip multi-factor authentication for next Admin user login.
3. Zalogować się do WebAdmin i sprawdzić token.

W przypadku utraty urządzenia lub trwałej bezużyteczności tokena należy zresetować MFA:

1. Wprowadzić 2 dla System Configuration.
2. Wprowadzić 7 dla Reset multi-factor authentication for Admin user.
3. Potwierdzić za pomocą y.
4. Zalogować się raz do WebAdmin wyłącznie hasłem administratora.
5. Wykonać instrukcje ponownej rejestracji MFA, a następnie ponownie przetestować logowanie z MFA.

Te dwie opcje zmieniają wyłącznie stan MFA. Jeśli nieznane jest również hasło domyślnego administratora, osobny artykuł o odzyskiwaniu hasła opisuje udokumentowaną procedurę szeregową dla urządzeń fizycznych oraz ograniczenia w przypadku jednoczesnej utraty hasła i MFA.

Testowanie, sprawdzanie logów i wdrażanie

Testowanie każdej usługi oddzielnie

Pomyślne logowanie do WebAdmin nie dowodzi, że portale i klienci VPN działają tak samo. Przed szerokim wdrożeniem należy sprawdzić:

• WebAdmin: Zalogować administratora pilotażowego z prawidłowym i celowo nieprawidłowym OTP.
• Default admin: Sprawdzić oddzielną ścieżkę Device Access i udokumentowaną procedurę odzyskiwania.
• User Portal i VPN Portal: Przetestować rejestrację za pomocą QR lub Base32 oraz logowanie z <password><passcode>.
• SSL VPN i IPsec Remote Access: Przetestować rzeczywiste klienty i dokładnie tę grupę użytkowników, która jest używana w środowisku produkcyjnym.
• Sophos Connect: W razie potrzeby sprawdzić trzecie pole OTP, aktualne profile klienta i działanie połączenia telefonicznego/push.
• RADIUS lub Entra SSO: Sprawdzić limity czasu, logi IdP i faktycznie obsługiwany mechanizm challenge.
• Device Access: Przetestować dostęp z dozwolonej i niedozwolonej sieci źródłowej.

Po sprawdzeniu Block login wykonuje się tylko kontrolowaną liczbę nieudanych prób. Oczekiwanym wynikiem nie jest wyłącznie udane logowanie: nieprawidłowy kod musi zostać odrzucony, próba zarejestrowana, a usługa dostępna tylko z przewidzianych sieci.

Prawidłowa interpretacja logów uwierzytelniania

W Log viewer należy sprawdzić udane i nieudane logowania wraz z usługą, użytkownikiem, źródłem, czasem i udokumentowanym powodem. Zależnie od zdarzenia SFOS może podać tylko ogólną informację, taką jak nieprawidłowe dane logowania. Bez dodatkowego dowodu nie należy z tego wnioskować, że przyczyną było wyłącznie hasło, OTP lub wygasły kod.

Przy zewnętrznym MFA logi RADIUS, NPS lub IdP są częścią tej samej kontroli. Rozwiązywanie problemów z Sophos Firewall: usługi i logi pomaga w identyfikacji lokalnych plików logów i usług. Do dłuższego przechowywania i korelacji służy Wysyłanie Syslog z Sophos Firewall do SIEM.

Przed szerokim wdrożeniem

• Grupa pilotażowa pomyślnie przetestowana ze wszystkimi wymaganymi usługami.
• Drugi administrator, kody jednorazowe i odzyskiwanie przez Device Console są udokumentowane.
• Użytkownicy zostali poinformowani o rejestracji aplikacji i wpisywaniu hasła plus OTP.
• Zdefiniowano reset tokenów dla utraconych lub nowych smartfonów.
• Sprawdzono Device Access, blokady logowania i centralne przechowywanie logów.
• Dla zewnętrznego MFA określono odpowiedzialność, limity czasu i procedurę awaryjną.

Rozwiązywanie problemów

Token, kod QR i dane wejściowe

Kod OTP nie jest akceptowany

Najpierw należy porównać czas zapory i smartfona, używaną aplikację, algorytm skrótu oraz krok czasowy. W Issued tokens można sprawdzić i zsynchronizować przesunięcie czasu. Po migracji algorytmu stary token musi zostać usunięty i zarejestrowany ponownie.

Aby zsynchronizować czas, otworzyć Authentication > Multi-factor authentication > Issued tokens, wybrać Synchronize token time offset dla odpowiedniego tokena, wprowadzić aktualny kod wygenerowany przez aplikację lub token sprzętowy i kliknąć Check. Przesunięcie czasu zostaje zsynchronizowane z zaporą, co koryguje rozbieżność zegarów. Następnie przeprowadzić kontrolowany test nowego logowania; zachować dostęp awaryjny i sprawdzić Block login przed dalszymi nieudanymi próbami.

Zmianę serwera NTP należy zaplanować oddzielnie, ponieważ zapora ponownie zestawia wtedy istniejące tunele IPsec.

Kod QR nie pojawia się lub nie można go zeskanować

Użytkownik musi należeć do wybranej grupy MFA i zalogować się do VPN Portal lub User Portal. W SFOS 22 administratorzy mogą również przeprowadzić rejestrację w WebAdmin, jeśli MFA jest tam aktywne. W SFOS 23 najpierw sprawdzić Share QR code: przy Email po logowaniu do portalu sprawdzić skrzynkę odbiorczą zamiast oczekiwać kodu QR w portalu; przy Portals QR jest wyświetlany w portalach, także po logowaniu do WebAdmin uruchamiającym wyświetlanie. Ponadto portal i źródło muszą być dozwolone w Administration > Device access. Przy pierwszej rejestracji lub wymianie aplikacji w SFOS 23 z włączonym generowaniem tokenów sprawdzić także opisane wyżej 24 godziny ważności: jeśli kod QR nie został użyty do logowania w tym czasie, zalogować się do VPN Portal lub User Portal wyłącznie hasłem i zarejestrować nowy kod QR dostarczony zgodnie z Email lub Portals.

W systemie iOS lub z Okta Verify, gdy mają zastosowanie opisane ograniczenia, zamiast skanowania kodu QR należy użyć klucza Base32.

Logowanie zgłasza nieprawidłowe hasło

Przy natywnym logowaniu Sophos OTP kod należy wpisać bezpośrednio po haśle. Bez oddzielnego pola OTP samo hasło jest niepełne.

Dostęp, grupy i Remote Access

Portal jest niedostępny

Najpierw należy sprawdzić strefę, źródło i wymaganą usługę w Administration > Device access. Restrykcyjna Local Service ACL Exception Rule jest bezpieczniejsza niż ogólne zezwolenie z WAN.

MFA nie obejmuje Remote Access

Konfiguracje MFA i Remote Access muszą używać tej samej, faktycznie zaimportowanej grupy użytkowników. Następnie trzeba ponownie zaimportować lub rozprowadzić profil klienta i przetestować połączenie z rzeczywistym klientem. Token musi zostać zarejestrowany przez VPN Portal lub User Portal przed pierwszym połączeniem VPN.

MFA obejmuje tylko część użytkowników

Nie należy porównywać wyłącznie widocznych nazw grup, lecz grupy faktycznie dopasowane przez AD, LDAP, RADIUS lub Entra ID. Po usunięciu użytkownika AD z grupy MFA może być wymagane jeszcze jedno logowanie z MFA; dopiero kolejne logowania nie wymagają OTP.

Blokada i zewnętrzne MFA

Administrator nie może się zalogować

Dla domyślnego admin należy użyć opisanej wyżej opcji 6 lub 7 w Device Console. Dla innego administratora należy użyć przygotowanego drugiego konta z dozwolonego źródła, a następnie sprawdzić grupy, token i stan blokady logowania.

RADIUS lub Entra MFA nie działa niezawodnie

Należy sprawdzić limity czasu RADIUS, logi IdP, grupy i mechanizm challenge konkretnej usługi. Pomyślny test serwera uwierzytelniania nie dowodzi, że działa logowanie produkcyjne przez VPN Portal, Sophos Connect lub WebAdmin. Każdą z tych ścieżek należy przetestować oddzielnie.