Włącz MFA dla Sophos Firewall WebAdmin, VPN Portal i dostęp zdalny

Portale dostępu administracyjnego i dostępu zdalnego powinny być chronione nie tylko nazwą użytkownika i hasłem. W przypadku wieloczynnikowego Authentication, krótkiego MFA, Sophos Firewall wymaga również drugiego czynnika, na przykład kodu OTP opartego na czasie z aplikacji uwierzytelniającej.

Szerszy kontekst hardening opisuje hub Sophos Firewall Hardening: best practices dla bezpiecznej konfiguracji.

Artykuł wyjaśnia, jak rozsądnie planować, aktywować i testować MFA. Nacisk położony jest na WebAdmin, VPN Portal i dostęp zdalny.

Klasyfikacja i ochrona dostępu

MFA to ważna ochrona loginów, ale tylko jeden element składowy. Po pierwsze, powinno być jasne, który dostęp jest chroniony, jakie źródło tożsamości się za nim kryje i czy usługa w ogóle musi być dostępna z danej sieci.

Który artykuł dotyczący uwierzytelniania pasuje?

MFA to tylko część zabezpieczeń dostępu. W zależności od celu, pierwszą rzeczą do rozważenia jest dostępność, źródło tożsamości, portal, klient VPN lub opublikowana aplikacja internetowa:

• MFA dla WebAdmin, VPN Portal lub Zaplanuj zdalny dostęp: Ten artykuł.
• WebAdmin, SSH, User Portal, VPN Portal, DNS lub dostępne ograniczenie Ping: Sophos Firewall Bezpieczny dostęp: Device Access skonfiguruj poprawnie.
• Microsoft Entra ID Użyj SSO dla Sophos Connect lub VPN Portal: Microsoft Entra ID Skonfiguruj SSO dla Sophos Connect i VPN Portal.
• Sophos Connect, SSL VPN, IPsec lub ZTNA w porównaniu jako model zdalnego dostępu: Sophos Connect lub SSL VPN: Które rozwiązanie zdalnego dostępu jest odpowiednie?.
• Sophos Connect Sprawdź wersję klienta, ponowne połączenie OTP lub udostępnienie SSO: Sophos Connect Sprawdź wersję klienta i bezpiecznie zaktualizuj.
• WAF opublikowana aplikacja internetowa zabezpieczona MFA: Sophos Firewall WAF zabezpieczona MFA.
• Połącz klasyczny Active Directory jako źródło użytkownika: Dodaj Active Directory do Sophos Firewall.
• Przygotuj dostęp do pomocy technicznej dla Avanet lub Sophos w kontrolowany sposób: Konfigurowanie dostępu pomocy technicznej Avanet do Sophos Firewall.
• Nadaj priorytet wynikom kontroli stanu dla MFA lub dostępu do portalu: Sophos Firewall Health Check użyj poprawnie.

To oddzielenie jest ważne: MFA chroni loginy, ale nie ogranicza automatycznie dostępu do sieci WebAdmin, SSH lub portali. I odwrotnie, wąska reguła dostępu do urządzenia nie zastępuje drugiego czynnika. Dobre bezpieczeństwo dostępu łączy dostępność, źródło tożsamości, MFA, rejestrowanie i przetestowany dostęp awaryjny.

Kiedy MFA ma sens

MFA powinno być włączone przynajmniej dla wszystkich kont, które mają dostęp do interfejsów administracyjnych lub funkcji dostępu zdalnego.

Typowe obszary zastosowań:

• Rejestracja na WebAdmin.
• Rejestracja na VPN Portal.
• SSL VPN lub Sophos Connect Dostęp zdalny.
• Dostęp dla zewnętrznych dostawców usług.
• Dostęp dla administratorów uprzywilejowanych.

MFA zmniejsza ryzyko kradzieży haseł, ale nie zastępuje odpowiednich ograniczeń dostępu. SSH, WebAdmin i portale powinny w dalszym ciągu być dostępne wyłącznie z zaufanych sieci lub poprzez jasno określony dostęp do zarządzania.

MFA nie zastępuje Device Access

MFA chroni proces logowania. Nie zmniejsza to jednak powierzchni ataku usługi. Jeśli WebAdmin, User Portal, VPN Portal lub SSL VPN będą dostępne za pośrednictwem Internetu, usługi te będą w dalszym ciągu atakowane przez boty, skanery i próby użycia siły. Tworzy to niepotrzebne wpisy w dzienniku, wysiłek pomocniczy i ryzyko.

Dlatego zawsze powinieneś łączyć MFA z kontrolą dostępności:

• Dostęp do urządzenia: Zasadniczo określ, które usługi są dostępne w której strefie.
• Reguła wyjątku ACL usługi lokalnej: WebAdmin, SSH lub portale zezwalają tylko na sieci zarządzania, sieci VPN lub znane adresy źródłowe.
• MFA: Dodatkowe zabezpieczenie logowania w przypadku naruszenia ważnych danych dostępowych.
• Logowanie i Syslog: Możliwość śledzenia nieudanych prób, problemów z wdrażaniem i ataków.

Jeśli portal musi być dostępny na całym świecie, powinieneś przynajmniej połączyć MFA, ważne certyfikaty, logowanie, restrykcyjne grupy użytkowników i regularne procesy przeglądu. W przypadku publicznie dostępnych usług zapory sieciowej pytanie nie dotyczy tylko tego, czy osoba atakująca może się zalogować, ale także tego, czy usługa w ogóle musi być szeroko dostępna.

Dodatkowo ogranicz dostęp za pomocą reguł ACL

Przed aktywacją MFA powinieneś sprawdzić, skąd faktycznie można dotrzeć do WebAdmin, SSH, User Portal i VPN Portal.

Ścieżka menu to System > Administration > Device access.

Istnieją dwa istotne obszary:

• ACL usług lokalnych: Podstawowy dostęp na strefę, na przykład LAN, VPN lub WAN.
• Reguła wyjątku listy ACL usług lokalnych: Ukierunkowane wyjątki dla poszczególnych sieci źródłowych, hostów lub dostępu do pomocy technicznej.

W środowiskach produkcyjnych zasadniczo nie należy włączać WebAdmin i SSH dla strefy WAN. Lepiej ograniczyć się do:

• adres IP zarządzania,
• sieć administracyjna,
• sieć VPN,
• dedykowany host wsparcia,
• lub jasno zdefiniowany wyjątek FQDN/Host.

Jeśli wymagany jest SSH, dostęp powinien być dodatkowo ograniczony i najlepiej używać klucza publicznego. Pasuje to do Sophos Firewall, połącz przez SSH.

⚠️ MFA chroni przed kradzieżą danych uwierzytelniających, ale nie przed niepotrzebnie ujawnianymi usługami. WebAdmin, SSH i portale nigdy nie powinny być szerzej dostępne niż to konieczne.

Wybierz wariant MFA i zaplanuj wdrożenie

Przed aktywacją powinieneś zdecydować, czy lokalna funkcja Sophos OTP jest wystarczająca, czy też istniejącą platformę MFA należy zintegrować poprzez RADIUS, NPS lub SSO. Następnie wdrożenie jest planowane w taki sposób, aby administratorzy i użytkownicy nie zablokowali się.

Wymagania wstępne

Przed aktywacją powinieneś sprawdzić:

• Czas systemu zapory jest prawidłowy.
• Skonfigurowano działający serwer NTP.
• Użytkownicy istnieją lokalnie, za pośrednictwem usługi AD, LDAP, RADIUS lub innej obsługiwanej usługi uwierzytelniania.
• Użytkownicy, których to dotyczy, mogą zalogować się do User Portal lub odpowiedniej usługi.
• Dostępny jest co najmniej jeden zastępczy dostęp administracyjny.

⚠️ Musisz zachować szczególną ostrożność w przypadku Admin-MFA. Nie należy aktywować MFA bezpośrednio dla wszystkich administratorów bez uprzedniego sprawdzenia użytkownika testowego, drugiego administratora i dostępu rezerwowego. Nieprawidłowa konfiguracja MFA może spowodować zablokowanie dostępu do WebAdmin lub VPN Portal.

Sophos MFA czy zewnętrzny MFA?

W przypadku MFA na Sophos Firewall są zasadniczo dwa sposoby: użyj lokalnej funkcji OTP zapory ogniowej lub podłącz zewnętrzne rozwiązanie MFA poprzez RADIUS lub SSO. Obydwa warianty są uzasadnione, ale rozwiązują różne problemy.

Lokalny MFA Sophos Firewall zarządza tokenami OTP bezpośrednio na zaporze. Jest to zazwyczaj najszybszy sposób zabezpieczenia WebAdmin, portali i zdalnego dostępu z drugim czynnikiem. Nie jest wymagana żadna dodatkowa infrastruktura RADIUS ani dostawca tożsamości.

Zalety MFA firmy Sophos:

• Nie jest wymagana dodatkowa integracja RADIUS ani dostawcy tożsamości.
• Szybkie wdrożenie dla lokalnych użytkowników i małych środowisk.
• Tokeny można generować i zarządzać nimi bezpośrednio na zaporze ogniowej.
• Nadaje się do WebAdmin, User Portal, VPN Portal, SSL VPN Dostęp zdalny i IPsec Dostęp zdalny.

Wady:

• Użytkownicy mogą potrzebować dodatkowej aplikacji lub tokenu uwierzytelniającego.
• Token jest niezależny od Microsoft 365, Entra ID i innych istniejących procesów MFA.
• W zależności od maski logowania nie ma oddzielnego pola OTP.
• Niektóre portale wymagają od użytkowników wprowadzenia hasła i tokenu jedno po drugim.

W większych środowiskach zewnętrzne rozwiązanie MFA może mieć większy sens. Typowe warianty to RADIUS z backendem obsługującym MFA, Microsoft NPS z rozszerzeniem Entra-MFA lub inny MFA-System kompatybilny z MFA-System. W zależności od wersji SFOS i modelu dostępu zdalnego, Microsoft Entra ID SSO może również współpracować z WebAdmin, VPN Portal i Sophos Connect z SSL VPN lub IPsec VPN.

Ważna różnica: Entra ID to nie jest po prostu ten sam mechanizm, co lokalna funkcja OTP Sophos. Albo Entra MFA jest zintegrowana z przepływem uwierzytelniania pośrednio poprzez RADIUS/NPS, albo używany jest model SSO, jeśli używana usługa i klient to obsługują.

Użytkownicy często uważają, że zewnętrzny MFA jest wygodniejszy, ponieważ używają tego samego MFA, co w przypadku Microsoft 365 lub innych usług biznesowych. Nie tworzy to drugiego świata MFA z dodatkową aplikacją, dodatkowym tokenem i innym sposobem logowania.

Wadą rozwiązania zewnętrznego jest większa złożoność. RADIUS, grupy, limity czasu, zachowania stanowiące wyzwanie i awarie muszą być dokładnie zaplanowane i przetestowane.

• Sophos OTP na zaporze sieciowej: Szybka konfiguracja, bez dodatkowej infrastruktury i zarządzanie bezpośrednio w SFOS. W tym celu tworzony jest dodatkowy token, niezależny od Microsoft 365 lub Entra ID; W zależności od portalu hasło i hasło jednorazowe muszą znajdować się w jednym polu. Typowe dla małych środowisk, użytkowników lokalnych i szybkiego utwardzania WebAdmin lub VPN.
• Zewnętrzny MFA poprzez RADIUS: Można wykorzystać istniejącą platformę MFA, zachowując jednocześnie centralne procesy użytkownika. Aby to zrobić, należy odpowiednio przetestować RADIUS, NPS, limity czasu, grupy i zachowanie klientów. Typowe dla środowisk AD/Microsoft 365 z wieloma użytkownikami VPN.
• Entra ID SSO: Znajomy login Microsoft, lepsze doświadczenie użytkownika i centralne procesy tożsamości. Nie każdy scenariusz można wykorzystać w ten sam sposób; zależy to od wersji SFOS, usługi i klienta. Typowe dla WebAdmin, VPN Portal i Sophos Connect, jeśli SSO pasuje do modelu operacyjnego.

Wspomaganie podejmowania decyzji

Prawidłowy wariant MFA w mniejszym stopniu zależy od zapory ogniowej, a bardziej od istniejącej operacji tożsamości.

• Małe środowisko z lokalnymi użytkownikami firewalla: Często wystarczająca jest własna funkcja OTP firmy Sophos.
• Środowisko Microsoft 365 z istniejącym Entra-MFA: Sprawdź zewnętrzne MFA poprzez RADIUS/NPS lub Entra-ID SSO, aby użytkownicy nie musieli utrzymywać dwóch światów MFA.
• Wielu zewnętrznych dostawców usług: Własna grupa użytkowników, obowiązek MFA, jasny termin i regularne przeglądy.
• Krytyczny dostęp administratora: MFA plus Device Access, połączenie sieci zarządzania, administratora rezerwowego i rejestrowania.
• Wielu użytkowników dostępu zdalnego: Zaplanuj grupę pilotażową, proces pomocy technicznej, resetowanie tokena i testowanie klienta przed szerokim wdrożeniem.

Jeśli Microsoft Entra ID jest planowane bezpośrednio jako źródło SSO dla VPN Portal lub Sophos Connect, Microsoft Entra ID Skonfiguruj SSO dla Sophos Connect i VPN Portal również pasuje. Jest to inny model działania niż klasyczna funkcja Sophos OTP i nie należy go utożsamiać z RADIUS-MFA bez przeglądu.

Plan MFA

W środowiskach produkcyjnych zwykle lepiej jest najpierw włączyć MFA dla małej grupy pilotażowej.

To zamówienie okazało się skuteczne:

1. Przygotuj użytkownika testowego lub grupę pilotażową.
2. Sprawdź NTP i czas zapory.
3. Włącz MFA dla obszaru testowego.
4. Testuj logowanie za pomocą aplikacji uwierzytelniającej.
5. Dopiero wtedy uwzględnij dodatkowe grupy użytkowników.

Dla dostawców usług zalecana jest osobna grupa użytkowników. Dzięki temu łatwiej jest wymusić MFA i później usunąć dostęp.

Dla administratorów powinieneś także zaplanować:

• Kto jest pierwszym administratorem testu?
• Czy istnieje drugi administrator z działającym dostępem?
• Czy dostęp jest możliwy poprzez sieć zarządzania lub VPN?
• Czy domyślny admin jest chroniony oddzielnie?
• Czy udokumentowano sposób zastąpienia utraconego tokena?

Aktywuj MFA i skonfiguruj tokeny

Po wyjaśnieniu wymagań wstępnych, grup i rozwiązań awaryjnych można najpierw aktywować MFA dla grupy pilotażowej. Dopiero po pomyślnych testach należy dołączyć dodatkowych użytkowników lub administratorów.

Aktywuj MFA na Sophos Firewall

Ustawienia MFA znajdują się w Authentication > Multi-factor authentication w bieżących wersjach SFOS. W starszych interfejsach lub w zależności od nawigacji obszar może nadal pojawiać się pod Configure > Authentication > Multi-factor authentication.

1. Zaloguj się do WebAdmin Sophos Firewall.
2. Otwórz Authentication.
3. Przejdź do zakładki Uwierzytelnianie wieloskładnikowe.
4. W przypadku Hasło jednorazowe (OTP) wybierz, kogo MFA ma dotyczyć:
   • Brak hasła jednorazowego: MFA jest wyłączone.
   • Wszyscy użytkownicy: MFA dotyczy wszystkich użytkowników.
   • Określeni użytkownicy i grupy: MFA dotyczy tylko wybranych użytkowników lub grup.
5. Włącz opcję Generuj token OTP przy następnym logowaniu, jeśli użytkownicy powinni samodzielnie konfigurować swój token przy następnym logowaniu.
6. Wybierz w obszarze Wymagaj MFA dla, dla których wymagane są usługi MFA.
7. Zapisz konfigurację za pomocą Zastosuj.

Typowe opcje w obszarze Wymagaj MFA dla to:

• Portal użytkownika
• Konsola administratora sieci WWW
• Portal VPN
• SSL VPN dostęp zdalny
• IPsec dostęp zdalny
• Zapora sieciowa aplikacji internetowych

W zależności od środowiska MFA może być różnie stosowane dla poszczególnych usług lub grup użytkowników. W przypadku administratorów MFA powinno być konsekwentnie egzekwowane, ale najpierw przetestowane w sposób kontrolowany.

Podczas publikowania aplikacji internetowych za pośrednictwem modułu Ochrona serwera WWW wymagana jest również odpowiednia polityka uwierzytelniania WAF. Proces jest w Sophos Firewall WAF zabezpieczony MFA.

Przygotuj się do wdrożenia i operacji

MFA to nie tylko przełącznik w zaporze ogniowej. Po aktywacji zmienia się sposób logowania, pytania dotyczące pomocy technicznej i dostęp awaryjny. Dlatego przed powszechnym wdrożeniem powinno być jasne, kto wydaje tokeny, kto resetuje utracone tokeny i jaka będzie reakcja poza godzinami pracy.

Te punkty okazały się przydatne w działaniu:

• Przetestuj grupę pilotażową z prawdziwymi użytkownikami, a nie tylko administratorami.
• Udokumentuj dostęp drugiego administratora i rozbij szybę.
• Poinformuj centrum pomocy o zachowaniu hasła i hasła jednorazowego.
• Ustaw proces resetowania tokena dla nowych smartfonów lub utraconych urządzeń.
• Sprawdź Log Viewer i dzienniki uwierzytelniania po wdrożeniu.
• Testuj zewnętrzne MFA poprzez RADIUS z realistycznymi limitami czasu.
• Regularnie sprawdzaj wyjątki Device Access i ACL.

Szczególnie w przypadku dostępu zdalnego należy przetestować MFA wraz z regułami VPN, grupami użytkowników i profilami klientów, których to dotyczy. Działający login WebAdmin nie oznacza automatycznie, że SSL VPN, IPsec Zdalny dostęp lub Sophos Connect działają tak samo.

Planowanie awaryjne i stłuczenie szkła

MFA zwiększa bezpieczeństwo, ale może także zablokować legalnych administratorów, jeśli token, czas, serwer uwierzytelniania lub grupy nie pasują. Dlatego przed aktywacją potrzebny jest plan awaryjny.

Należy udokumentować przynajmniej te punkty:

• Kto ma drugi przetestowany dostęp administratora?
• Czy możliwy jest dostęp z sieci zarządzającej lub sieci VPN administratora?
• Czy lokalne domyślne admin jest chronione jako konto awaryjne, ale nie jest używane do codziennego użytku?
• Jak zresetować zgubiony lub uszkodzony token OTP?
• Kto może resetować tokeny dla administratorów?
• Jak reagujesz poza godzinami pracy?
• Czy przed zmianą istnieje aktualna kopia zapasowa?

Rozwiązanie awaryjne nie może oznaczać, że niechroniony dostęp administratora będzie stale dostępny z Internetu. Lepiej mieć konto awaryjne z przejrzystą dokumentacją, wąską ścieżką dostępu i regularnymi przeglądami.

MFA for the default admin

Domyślny lokalny użytkownik admin jest przypadkiem specjalnym. MFA dla tego użytkownika nie jest aktywowany bezpośrednio w zakładce Uwierzytelnianie wielopoziomowe.

Ścieżka menu to System > Administration > Device access.

Tam możesz aktywować MFA dla domyślnego administratora. Powinieneś to zrobić tylko wtedy, gdy:

• czas systemowy jest prawidłowy,
• przetestowano drugiego administratora,
• działa dostęp poprzez zaufaną sieć zarządzania,
• jasne jest, jak w sytuacji awaryjnej odzyskać dostęp administracyjny.

Poniższe dotyczy domyślnego admin: nie dezaktywuj go, nie udostępniaj bez ochrony w Internecie i nie używaj jako zwykłego użytkownika. To konto awaryjne typu break-glass.

Inni administratorzy nie powinni zakładać, że mogą edytować lub usuwać token MFA domyślnego admin, tak jak zwykły token użytkownika. Dostęp ten musi być świadomie zaplanowany i przetestowany poprzez własną ścieżkę dostępu do urządzenia.

Skonfiguruj tokeny dla użytkowników

Po aktywacji użytkownik musi skonfigurować drugi czynnik. Jeśli Generate OTP token with next sign-in jest aktywne, użytkownik loguje się do User Portal lub VPN Portal i skanuje kod QR aplikacją uwierzytelniającą.

Odpowiednie aplikacje obejmują:

• Microsoft Authenticator.
• Google Authenticator.
• Sophos Intercept X for Mobile.
• 1Password.
• Bitwarden.
• Inne aplikacje uwierzytelniające kompatybilne z TOTP.

Wygenerowany kod jest oparty na czasie. Jeśli czas na zaporze sieciowej lub smartfonie znacznie się różni, logowanie nie powiedzie się.

Jeśli User Portal jest wyłączony, użytkownicy mogą nie być w stanie samodzielnie skonfigurować swoich tokenów. W takim przypadku trzeba albo udostępnić portal w kontrolowany sposób, albo przygotować tokeny administracyjnie.

Pod Authentication > Multi-factor authentication > Issued tokens możesz zobaczyć, którzy użytkownicy już utworzyli lub którym przypisano token. W razie potrzeby tokeny można sprawdzić, usunąć lub przygotować ręcznie. Do domyślnego admin obowiązuje specjalna zasada: inni administratorzy nie mogą zmieniać ani usuwać jego tokena tak jak zwykłe tokeny użytkownika. Token ten jest zarządzany poprzez własną domyślną ścieżkę administratora MFA.

Algorytm tokena i przełączanie aplikacji

Sophos Firewall obsługuje algorytmy skrótu SHA1, SHA256 i SHA512 dla tokenów OTP. Wersje SFOS wcześniejsze niż 22.0 używają dla MFA algorytmu SHA1; od SFOS 22.0 nowe lub migrowane tokeny warto testować z SHA256 albo SHA512. Nie można tego jednak ustawić na ślepo: wybrany algorytm musi być obsługiwany przez używaną aplikację uwierzytelniającą.

Sophos wyraźnie stwierdza, że ​​aplikacja musi obsługiwać wybrany algorytm. Jeśli aplikacja nie obsługuje prawidłowo SHA256 lub SHA512, kod QR może zostać zeskanowany, ale logowanie nadal nie powiedzie się. Dlatego algorytm zawsze należy do testów pilotażowych, zwłaszcza gdy Microsoft Authenticator, menedżer haseł TOTP, Google Authenticator lub Sophos Intercept X for Mobile są używane w sposób mieszany.

Te punkty są ważne dla działania:

• Nie planuj już nowych tokenów przy starych założeniach aplikacji.
• Użyj aplikacji uwierzytelniającej, która obsługuje wybrany algorytm mieszający.
• Jeśli zmienisz aplikację lub zgubisz smartfon, usuń stary token i zleć regenerację kodu QR.
• Tokenów sprzętowych należy używać tylko wtedy, gdy można prawidłowo zarządzać algorytmem, krokiem czasowym i kluczem tajnym.
• Przetestuj grupę pilotażową przed migracją SHA256/SHA512 zamiast migrować wszystkie tokeny na raz.
• Istniejące tokeny SHA1 można usunąć i odtworzyć w kontrolowany sposób podczas migracji.

Stara aplikacja Sophos Authenticator nie powinna już być planowana jako nowa aplikacja domyślna; według Sophos jest End of Life od 31 lipca 2022 roku. W wielu środowiskach bardziej realistyczne opcje to Microsoft Authenticator, Google Authenticator, Sophos Intercept X for Mobile, 1Password lub Bitwarden. Ważna jest nie tyle marka aplikacji, ile to, czy TOTP, algorytm skrótu, zachowanie tworzenia kopii zapasowych/przywracania i proces pomocy technicznej pasują do siebie.

Kiedy użytkownik zmienia smartfon, stary token nie powinien po prostu nadal istnieć po cichu. Lepszy jest przejrzysty proces: sprawdź tożsamość, usuń stary token, wygeneruj nowy kod QR, przetestuj logowanie za pomocą prawidłowego i niepoprawnego OTP i udokumentuj proces.

Ważna uwaga dotycząca haseł i tokenów

W zależności od usługi Sophos nie ma oddzielnego pola formularza dla kodu OTP. To zawsze prowadzi do nieporozumień, szczególnie w przypadku VPN Portal lub loginów dostępu zdalnego.

W takich przypadkach użytkownik często musi wprowadzić hasło i kod OTP jeden po drugim.

Przykład:

Haslo:    MojeBezpieczneHaslo
Kod OTP:  123456
Wejscie:  MojeBezpieczneHaslo123456

Należy to wyraźnie przekazać użytkownikom przed wdrożeniem. W przeciwnym razie użytkownik będzie miał wrażenie, że hasło jest nieprawidłowe, mimo że brakuje tylko kodu OTP.

To zachowanie należy przetestować i udokumentować przed wdrożeniem, ponieważ jest ono różnie postrzegane w zależności od usługi i maski logowania.

Testowanie i kontrola działania

Pomyślny test WebAdmin nie wystarczy. Każdy interfejs logowania, którego dotyczy problem, należy przetestować osobno, ponieważ portal, klient VPN, grupa użytkowników i serwer uwierzytelniający mogą reagować inaczej.

Logowanie testowe

MFA należy najpierw przetestować na użytkowniku, który nie jest jedynym administratorem.

Należy sprawdzić te punkty:

• Rejestracja na WebAdmin.
• Rejestracja na VPN Portal.
• Logowanie do usługi zdalnego dostępu.
• Zachowanie w przypadku nieprawidłowego kodu OTP.
• Zachowanie po wygaśnięciu kodu OTP.
• Dostęp z użytkownikiem nienależącym do grupy MFA.
• Zaloguj się przy użyciu hasła i dołączonego kodu OTP.
• Dostęp poprzez zaplanowane reguły ACL.

Dopiero po pomyślnym zakończeniu tych testów MFA należy wdrożyć w innych grupach.

Matryca testowa według usługi

Test MFA powinien składać się nie tylko z udanego logowania WebAdmin. W zależności od usługi obowiązują inne portale, grupy, profile i pliki dziennika. Matryca ta pomaga osobno zbadać najważniejsze przypadki:

• WebAdmin: Logowanie administratora z poprawnym i niepoprawnym hasłem jednorazowym. Prawidłowe OTP umożliwia dostęp, nieprawidłowe OTP jest całkowicie odrzucane i rejestrowane.
• Domyślnie admin: Przetestuj oddzielną ścieżkę MFA w System > Administration > Device access. Konto awaryjne jest chronione, ale dostępna jest udokumentowana ścieżka stłuczenia szyby.
• User Portal: Użytkownik samodzielnie konfiguruje token. Kod QR pojawia się tylko u autoryzowanych użytkowników, token działa wtedy podczas logowania.
• VPN Portal: Użytkownik loguje się za pomocą hasła i hasła jednorazowego. Logowanie działa w udokumentowanym formacie wejściowym i jest widoczne w Log Viewer.
• SSL VPN / Sophos Connect: Importuj profil lub ponownie nawiąż połączenie. Zapytanie o MFA odbywa się w prawdziwym kliencie, a nie tylko w przeglądarce.
• IPsec Dostęp zdalny: Sprawdź grupę i metodę uwierzytelniania. MFA dotyczy tej samej grupy, która jest również dozwolona w konfiguracji zdalnego dostępu.
• Zewnętrzny MFA poprzez RADIUS: Przetestuj push, wyzwanie lub token z prawdziwym klientem. Limit czasu jest wystarczający, zachowanie stanowiące wyzwanie odpowiada klientowi, a błędy są widoczne na serwerze RADIUS.

Każdy test powinien także sprawdzić, czy Device Access lub reguła ACL usługi lokalnej celowo zezwala na tę usługę. Jeśli token działa, ale portal jest dostępny z niewłaściwej sieci, konfiguracja MFA tylko częściowo rozwiązuje problem.

Dzienniki i kontrola operacyjna

Po wdrożeniu powinieneś sprawdzić, czy można śledzić zdarzenia MFA podczas działania. Jest to ważne w przypadku zgłoszeń do pomocy technicznej, przeglądów bezpieczeństwa i reagowania na incydenty.

Przydatne punkty kontrolne:

• Sprawdź zdarzenia uwierzytelniające w przeglądarce dzienników.
• Odróżnij nieudane logowanie od nieprawidłowego hasła, nieprawidłowego hasła jednorazowego i wygasłego hasła jednorazowego.
• Dokumentuj testy portalu VPN i zdalnego dostępu wraz z czasem i użytkownikiem.
• W przypadku zewnętrznego RADIUS sprawdź także serwer RADIUS, dzienniki NPS lub dzienniki dostawcy tożsamości.
• W przypadku dłuższego przechowywania zaplanuj Central Reporting lub Syslog/SIEM.

W przypadku lokalnych plików dziennika i mapowania usług pasuje Sophos Firewall Rozwiązywanie problemów: Services i logi. Jeśli uwierzytelnianie i zdarzenia portalu mają być oceniane długoterminowo, odpowiednie będzie Sophos Firewall wysłanie Syslog do SIEM.

W przypadku Sophos Central, Syslog lub SIEM powinieneś nie tylko sprawdzać pomyślne logowania po wdrożeniu. Powtarzające się nieudane próby na WebAdmin, User Portal, VPN Portal i SSL VPN są szczególnie interesujące, ponieważ pokazują, czy usługa jest niepotrzebnie szeroko dostępna lub czy użytkownicy borykają się z formatem OTP.

Rozwiązywanie problemów

Kod OTP nie został zaakceptowany

Najpierw sprawdź czas systemu zapory sieciowej i czas smartfona. TOTP jest zależne od czasu. Nawet znaczne odchylenie może prowadzić do odrzucenia prawidłowych kodów.

Możesz sprawdzić wystawione tokeny pod adresem Authentication > Multi-factor authentication. Jeżeli wielokrotnie zostanie pominięty pojedynczy token, nie należy od razu zmieniać całej konfiguracji MFA. Najpierw sprawdź dryf czasu tokena, używaną aplikację, algorytm mieszający i krok czasowy.

Użytkownik nie widzi kodu QR

Użytkownik musi mieć autoryzację MFA i zalogować się do odpowiedniego portalu. Dodatkowo należy sprawdzić, czy użytkownik zostanie odnaleziony poprzez oczekiwane źródło uwierzytelnienia.

Jeśli User Portal jest wyłączone, użytkownik może nie być w stanie samodzielnie skonfigurować tokena. Następnie należy udostępnić portal tymczasowo lub utworzyć token administracyjnie.

Portal nie może zostać osiągnięty przez Device Access

Jeśli użytkownicy nie mogą skonfigurować swojego tokena, mimo że MFA został poprawnie aktywowany, nie usuwaj najpierw tokena. Często do wymaganego portalu nie można dotrzeć z bieżącej sieci poprzez System > Administration > Device access lub regułę ACL usługi lokalnej.

Najpierw sprawdź:

• Który portal jest używany do konfiguracji tokena?
• Z jakiej strefy lub źródła pochodzi użytkownik?
• Czy dostęp został celowo dozwolony czy przypadkowo zablokowany?
• Czy zamiast szerokiej wersji istnieje węższy wyjątek listy ACL?

Administrator jest zablokowany

W tym przypadku użyj przygotowanego dostępu awaryjnego. Jeśli nie istnieje rezerwa, należy ocenić dostęp za pośrednictwem konsoli, pomocy technicznej lub ścieżek odzyskiwania, w zależności od sytuacji.

MFA nie działa w przypadku dostępu zdalnego

Sprawdź, czy konfiguracja zdalnego dostępu wykorzystuje tę samą grupę użytkowników, dla której aktywowano MFA. Często błąd nie dotyczy samego MFA, ale różnych grup w VPN i regułach uwierzytelniania.

Profile klientów muszą również odpowiadać bieżącej konfiguracji. Po wprowadzeniu zmian w VPN Portal, SSL VPN, IPsec Remote Access, Entra SSO lub RADIUS, dotknięte profile Sophos Connect należy ponownie zaimportować lub rozpowszechnić.

Użytkownik wprowadza tylko hasło

Jeśli nie jest wyświetlane żadne osobne pole OTP, użytkownik musi wprowadzić hasło i kod OTP jedno po drugim. Jest to jeden z najczęstszych przypadków wsparcia po aktywacji Sophos OTP.

Zewnętrzny MFA nie działa niezawodnie

W przypadku rozwiązań MFA opartych na RADIUS limity czasu, zachowania stanowiące wyzwanie i grupy muszą dobrze do siebie pasować. Jeśli używasz pushMFA, callMFA lub odpowiedzi wzywających, powinieneś przetestować cały proces logowania na kliencie, którego to dotyczy.

The portal boundary is also important: not every Sophos login supports every RADIUS challenge behavior equally well. Zwłaszcza VPN Portal, SSL VPN, Sophos Connect, WebAdmin i Captive Portal należy przetestować osobno z prawdziwymi klientami. A successful RADIUS test in the server configuration is not sufficient proof of productive remote access login.

MFA został aktywowany dla niewłaściwej grupy

Jeśli MFA działa dla niektórych użytkowników, a dla innych nie, powinieneś najpierw technicznie porównać grupy. Istotne są nie tylko widoczne wyświetlane nazwy, ale faktycznie zaimportowane lub dopasowane grupy z AD, LDAP, RADIUS lub Entra ID. Użytkownik może pomyślnie uwierzytelnić się i nadal nie znaleźć się w grupie wymagającej MFA.

Operacyjna lista kontrolna i zalecenia

Po aktywacji technicznej MFA wymaga prostego procesu operacyjnego: kto resetuje tokeny, kto sprawdza logi i w jaki sposób sprawdza się, czy portale nie są niepotrzebnie szeroko dostępne?

Operacyjna lista kontrolna

• Sprawdzono czas systemowy i NTP.
• Zdefiniowano i przetestowano grupę pilotażową.
• MFA nie zostało bezpośrednio aktywowane dla wszystkich administratorów jednocześnie.
• Second admin and break glass access documented.
• Device Access i Local Service ACL sprawdzone pod kątem WebAdmin, User Portal, VPN Portal i SSL VPN.
• Testowano dostęp z dozwolonej i niedozwolonej sieci źródłowej.
• Użytkownik poinformowany o zachowaniu hasła i OTP.
• Token reset process for lost smartphones documented.
• Udokumentowano aplikację uwierzytelniającą, algorytm mieszający i migrację tokenów.
• Dostęp zdalny przetestowano na prawdziwych klientach i bieżących profilach.
• RADIUS/Entra timeouts tested if external MFA is used.
• Sprawdzono dzienniki i pamięć centralną.

Zalecenie operacyjne

MFA powinien być standardem dla dostępu administracyjnego. MFA jest szczególnie ważne dla WebAdmin, VPN Portal i wszystkich użytkowników posiadających autoryzację dostępu zdalnego.

For small environments, Sophos’ own OTP function is often sufficient. W środowiskach Microsoft 365 lub Entra ID zewnętrzny MFA nad RADIUS może być wygodniejszy, ponieważ użytkownicy nie muszą uczyć się drugiego świata MFA.

Niezależnie od wariantu MFA obowiązują następujące zasady: najpierw ogranicz dostęp za pomocą reguł ACL, dokładnie przetestuj administratora MFA, poinformuj użytkownika o haśle+tokenie i dopiero wtedy szeroko go wprowadź.

Często zadawane pytania