Przejdz do tresci
Avanet

MFA w Sophos Firewall dla WebAdmin i VPN Portal

Dostęp administracyjny i portale Remote Access nie powinny być chronione wyłącznie nazwą użytkownika i hasłem. Dzięki Multi-Factor Authentication, czyli MFA, Sophos Firewall wymaga dodatkowego drugiego czynnika, na przykład czasowego kodu OTP z aplikacji Authenticator.

Ta instrukcja pokazuje, jak sensownie zaplanować, aktywować i przetestować MFA. Fokus jest na WebAdmin, VPN Portal i Remote Access.

Kiedy MFA ma sens

MFA należy aktywować co najmniej dla wszystkich kont, które mogą korzystać z interfejsów administracyjnych albo funkcji Remote Access.

Typowe obszary użycia:

  • Logowanie do WebAdmin.
  • Logowanie do VPN Portal.
  • SSL VPN albo Sophos Connect Remote Access.
  • Dostęp dla zewnętrznych usługodawców.
  • Dostęp dla uprzywilejowanych administratorów.

MFA redukuje ryzyko wynikające ze skradzionych haseł, ale nie zastępuje czystego ograniczenia dostępu. SSH, WebAdmin i portale nadal powinny być dostępne tylko z zaufanych sieci albo przez jasno zdefiniowane dostępy zarządzające.

Dodatkowe ograniczenie dostępu regułami ACL

Przed aktywacją MFA warto sprawdzić, skąd WebAdmin, SSH, User Portal i VPN Portal są w ogóle osiągalne.

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

Są tam dwa istotne obszary:

  • Local service ACL: Podstawowy dostęp per strefa, na przykład LAN, VPN albo WAN.
  • Local service ACL exception rule: Celowe wyjątki dla pojedynczych sieci źródłowych, hostów albo dostępów wsparcia.

W środowiskach produkcyjnych WebAdmin i SSH nie powinny być ogólnie aktywne dla strefy WAN. Lepsze jest ograniczenie do:

  • adresu management IP,
  • sieci administratorów,
  • sieci VPN,
  • dedykowanego hosta wsparcia,
  • albo jasno zdefiniowanego wyjątku FQDN/host.

Jeśli SSH jest potrzebne, dostęp należy dodatkowo ograniczyć i najlepiej używać Public Key. Zobacz: Połączenie SSH z Sophos Firewall

⚠️ MFA chroni przed skradzionymi danymi logowania, ale nie przed niepotrzebnie wystawionymi usługami. WebAdmin, SSH i portale nigdy nie powinny być dostępne szerzej, niż jest to konieczne.

Wymagania

Przed aktywacją należy sprawdzić:

  • Czas systemowy firewalla jest poprawny.
  • Skonfigurowano działający serwer NTP.
  • Użytkownicy istnieją lokalnie, przez AD, LDAP, RADIUS albo inną obsługiwaną usługę uwierzytelniania.
  • Objęci tym użytkownicy mogą logować się do User Portal albo do właściwej usługi.
  • Istnieje co najmniej jeden administracyjny fallback access.

⚠️ Przy Admin-MFA trzeba zachować szczególną ostrożność. Nie aktywuj MFA od razu dla wszystkich administratorów bez wcześniejszego przetestowania użytkownika testowego, drugiego administratora i dostępu awaryjnego. Błędna konfiguracja MFA może spowodować odcięcie dostępu do WebAdmin albo VPN Portal.

Sophos MFA czy zewnętrzne MFA przez RADIUS?

Sophos Firewall ma własne rozwiązanie MFA. Tokeny OTP są wtedy zarządzane bezpośrednio na firewallu. To szybka konfiguracja i nie wymaga dodatkowej infrastruktury.

Zalety natywnego Sophos MFA:

  • Nie jest wymagana dodatkowa integracja RADIUS ani Identity Provider.
  • Szybki rollout dla użytkowników lokalnych i małych środowisk.
  • Tokeny można tworzyć i zarządzać nimi bezpośrednio na firewallu.
  • Odpowiednie dla WebAdmin, User Portal, VPN Portal, SSL VPN Remote Access i IPsec Remote Access.

Wady:

  • Użytkownicy mogą musieć utrzymywać dodatkową aplikację Authenticator albo dodatkowy token.
  • Token jest oddzielony od Microsoft 365, Entra ID albo innych istniejących procesów MFA.
  • W zależności od ekranu logowania nie ma osobnego pola OTP.
  • W niektórych portalach użytkownicy muszą wpisać hasło i token bezpośrednio jeden po drugim.

W większych środowiskach zewnętrzne MFA przez RADIUS może być lepsze. MFA można wtedy zrealizować na przykład przez Microsoft Entra ID, NPS z rozszerzeniem MFA albo inny kompatybilny z RADIUS serwis MFA. Dla użytkowników jest to często wygodniejsze, bo korzystają ze znanego już Microsoft-365-MFA albo istniejącego rozwiązania firmowego.

Minusem rozwiązania zewnętrznego jest większa złożoność. RADIUS, grupy, timeouty, zachowanie challenge i fallback muszą być starannie zaplanowane oraz przetestowane.

Planowanie MFA

W środowiskach produkcyjnych zwykle lepiej aktywować MFA najpierw dla małej grupy pilotażowej.

Sprawdzona kolejność:

  1. Przygotować użytkownika testowego albo grupę pilotażową.
  2. Sprawdzić NTP i czas firewalla.
  3. Aktywować MFA dla obszaru testowego.
  4. Przetestować logowanie z aplikacją Authenticator.
  5. Dopiero potem dodać kolejne grupy użytkowników.

Dla usługodawców warto utworzyć osobną grupę użytkowników. Dzięki temu MFA można wymuszać celowo, a dostęp później łatwiej usunąć.

Dla administratorów należy dodatkowo zaplanować:

  • Kto jest pierwszym adminem testowym?
  • Czy istnieje drugi admin z działającym dostępem?
  • Czy dostęp przez sieć management albo VPN działa?
  • Czy default admin jest osobno zabezpieczony?
  • Czy udokumentowano, jak wymienić utracony token?

Aktywowanie MFA w Sophos Firewall

Ustawienia MFA znajdują się w Configure > Authentication > Multi-factor authentication.

  1. Zalogować się do WebAdmin Sophos Firewall.
  2. Otworzyć Configure > Authentication.
  3. Przejść do zakładki Multi-factor authentication.
  4. W One-time password (OTP) wybrać, dla kogo ma obowiązywać MFA:
    • No OTP: MFA jest wyłączone.
    • All users: MFA obowiązuje wszystkich użytkowników.
    • Specific users and groups: MFA obowiązuje tylko wybranych użytkowników albo grupy.
  5. Włączyć Generate OTP token with next sign-in, jeśli użytkownicy mają skonfigurować token przy następnym logowaniu.
  6. W Require MFA for wybrać usługi, które mają wymagać MFA.
  7. Zapisać konfigurację przez Apply.
Sophos Firewall - ustawienia Multi-factor authentication w Authentication
Sophos Firewall - Authentication > Multi-factor authentication

Typowe opcje w Require MFA for:

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

W zależności od środowiska MFA może być stosowane różnie dla poszczególnych usług albo grup użytkowników. Dla administratorów MFA powinno być konsekwentnie wymuszane, ale najpierw kontrolowanie przetestowane.

MFA dla default admin

Lokalny default user admin jest przypadkiem specjalnym. Sophos wskazuje w widoku MFA, że MFA dla tego użytkownika nie aktywuje się bezpośrednio w tej zakładce.

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

Tam można włączyć MFA for default admin. Należy zrobić to dopiero wtedy, gdy:

  • czas systemowy jest poprawny,
  • drugi administrator został przetestowany,
  • dostęp przez zaufaną sieć management działa,
  • i wiadomo, jak w razie awarii odzyskać dostęp administracyjny.

Dla default admin obowiązuje: nie wyłączać, nie wystawiać niezabezpieczonego do Internetu i nie używać jako zwykłego konta codziennego. To konto typu break-glass albo awaryjne.

Konfiguracja tokenów 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 albo VPN Portal i skanuje kod QR aplikacją Authenticator.

Odpowiednie aplikacje to na przykład:

  • Microsoft Authenticator.
  • Google Authenticator.
  • 1Password.
  • Bitwarden.
  • Inne aplikacje Authenticator zgodne z TOTP.

Wygenerowany kod jest zależny od czasu. Jeśli czas na firewallu albo smartfonie mocno się różni, logowanie nie powiedzie się.

Jeśli User Portal jest wyłączony, użytkownicy mogą w pewnych sytuacjach nie móc samodzielnie skonfigurować tokenów. W takim przypadku trzeba albo kontrolowanie udostępnić portal, albo przygotować tokeny administracyjnie.

Ważna uwaga o haśle i tokenie

W zależności od usługi Sophos dla kodu OTP nie ma osobnego pola formularza. Szczególnie przy VPN Portal albo logowaniach Remote Access często powoduje to nieporozumienia.

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

Przykład:

Hasło: MojeBezpieczneHaslo
OTP-Code: 123456
Wpis:  MojeBezpieczneHaslo123456

Trzeba jasno przekazać to użytkownikom przed rolloutem. Inaczej wygląda to dla użytkownika tak, jakby hasło było błędne, chociaż brakuje tylko kodu OTP.

Sophos opisuje to zachowanie w swojej dokumentacji OTP: OTP token.

Testowanie logowania

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

Sprawdzić:

  • Logowanie do WebAdmin.
  • Logowanie do VPN Portal.
  • Logowanie do usługi Remote Access.
  • Zachowanie przy błędnym kodzie OTP.
  • Zachowanie po wygaśnięciu kodu OTP.
  • Dostęp użytkownika, który nie należy do grupy MFA.
  • Logowanie z hasłem i dołączonym kodem OTP.
  • Dostęp przez planowane reguły ACL.

Dopiero gdy te testy zakończą się powodzeniem, warto wdrażać MFA na kolejne grupy.

Częste błędy

Kod OTP nie jest akceptowany

Sprawdzić czas systemowy firewalla i czas smartfona. TOTP zależy od czasu. Już wyraźna różnica może spowodować odrzucenie poprawnych kodów.

Użytkownik nie widzi kodu QR

Użytkownik musi być objęty MFA i logować się do właściwego portalu. Dodatkowo należy sprawdzić, czy użytkownik jest znajdowany przez oczekiwane źródło uwierzytelniania.

Jeśli User Portal jest wyłączony, użytkownik może nie móc samodzielnie skonfigurować tokena. Wtedy portal trzeba tymczasowo udostępnić albo token utworzyć administracyjnie.

Administrator jest zablokowany

Użyć przygotowanego dostępu awaryjnego. Jeśli fallback nie istnieje, trzeba w zależności od sytuacji sprawdzić dostęp przez konsolę, support albo procedury odzyskiwania.

MFA nie działa dla Remote Access

Sprawdzić, czy konfiguracja Remote Access używa tej samej grupy użytkowników, dla której aktywowano MFA. Często problem nie leży w samym MFA, lecz w różnych grupach w regułach VPN i authentication.

Użytkownik wpisuje tylko hasło

Jeśli nie ma osobnego pola OTP, użytkownik musi wpisać hasło i kod OTP bezpośrednio po sobie. To jeden z najczęstszych przypadków wsparcia po aktywacji Sophos OTP.

Zewnętrzne MFA nie działa stabilnie

Przy rozwiązaniach MFA opartych na RADIUS timeouty, zachowanie challenge i grupy muszą być zgodne. Jeśli używane jest Push-MFA, Call-MFA albo challenge-response, należy przetestować pełny proces logowania z właściwym klientem.

Rekomendacja

MFA powinno być standardem dla dostępów administracyjnych. Szczególnie ważne jest MFA dla WebAdmin, VPN Portal i wszystkich użytkowników z uprawnieniami Remote Access.

Dla małych środowisk natywna funkcja Sophos OTP często wystarcza. W środowiskach Microsoft 365 albo Entra ID zewnętrzne MFA przez RADIUS może być wygodniejsze, bo użytkownicy nie muszą uczyć się drugiego świata MFA.

Niezależnie od wariantu MFA obowiązuje: najpierw ograniczyć dostęp regułami ACL, ostrożnie przetestować Admin-MFA, poinformować użytkowników o haśle+tokenie i dopiero potem wdrażać szeroko.

Dodatkowe informacje Sophos: