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.

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

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.

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 skanuje kod QR. Administratorzy mogą także zarejestrować token w WebAdmin, jeśli MFA jest tam wymagane. Kod QR pojawia się tylko dla użytkowników i grup, dla których skonfigurowano MFA.

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.

Po utracie smartfona lub zmianie aplikacji stary token usuwa się po zweryfikowaniu tożsamości użytkownika. Następnie użytkownik loguje się raz do portalu wyłącznie hasłem i rejestruje nowo wyświetlony kod QR. Stary token nie powinien pozostawać równolegle aktywny bez kontroli.

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.

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.

Aby przejść z SHA1 na silniejszy algorytm:

1. Przetestować aplikację pilotażową z SHA256 lub SHA512.
2. Wybrać nowy algorytm w Authentication > Multi-factor authentication.
3. Usunąć stare tokeny SHA1 w Issued tokens.
4. Poprosić użytkowników o zalogowanie się wyłącznie hasłem i ponowne zarejestrowanie kodu QR lub klucza Base32.
5. 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.

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. Należy otworzyć Administration > Device access, włączyć MFA for default admin i skonfigurować tam token sprzętowy lub programowy.

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.

Odzyskiwanie przez Device Console

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.

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. Administratorzy mogą również przeprowadzić rejestrację w WebAdmin, jeśli MFA jest tam aktywne. Ponadto portal i źródło muszą być dozwolone w Administration > Device access.

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.