Przejdz do tresci
Avanet

Bezpieczne tworzenie i obsługa kont gości w Sophos Firewall

Funkcja Guest users umożliwia tworzenie w Sophos Firewall tymczasowych kont dla osób, które nie mają zwykłego konta użytkownika. Sprawdza się to na przykład w przypadku gości, zewnętrznych techników lub uczestników szkoleń, którzy logują się przez Captive Portal i powinni otrzymać wyłącznie jasno ograniczony dostęp do Internetu.

Bezpieczna skrócona procedura wygląda następująco:

  1. Przygotować restrykcyjną grupę gości z wymaganymi policies.
  2. W Authentication > Guest user settings ustawić prefiks, grupę, hasło i czyszczenie kont.
  3. Zdecydować, czy administrator tworzy pojedyncze lub wiele kont, czy rzeczywiście potrzebna jest samodzielna rejestracja przez SMS.
  4. Ustawić ważność na Immediately lub After first login i bezpiecznie przekazać dane logowania.
  5. Przetestować Captive Portal, regułę użytkownika, separację sieci oraz jeden dozwolony i jeden zablokowany cel.
  6. Po wygaśnięciu wyłączyć lub usunąć konto, a istniejące sesje i logi sprawdzić osobno.

⚠️ Konto gościa jest tylko tożsamością. Nie zapewnia segmentacji sieci i nie otwiera ścieżki danych. Goście powinni znajdować się w osobnej strefie lub VLAN-ie i korzystać z wąskiej, logowanej reguły firewall. Dane logowania, wydruki i wiadomości SMS należy traktować jak hasła.

Rozróżnienie kont gości, voucherów i zwykłych użytkowników

Użytkownik gość jest tymczasowym lokalnym rekordem użytkownika. Firewall generuje Username i hasło na podstawie globalnych ustawień kont gości. Po zalogowaniu może przypisać ruch do tej tożsamości i zastosować policies wybranej grupy.

Pozostałe modele dostępu służą innym celom:

Konta gości nie są przeznaczone do Remote Access SSL VPN ani IPsec Remote Access. Aktualna policy SSL VPN nie zezwala na Guest users ani Guest groups jako Policy members. Do Remote Access należy użyć zwykłego użytkownika z odpowiedniego lokalnego lub zewnętrznego źródła. Pełną konfigurację VPN opisano w Konfiguracja SSL VPN Remote Access.

Planowanie przykładu i wymagań

Poniższy przykład wykorzystuje osobną sieć dla gości i konto na jednodniową wizytę:

  • Strefa: Guest
  • Sieć: 10.30.40.0/24
  • Nazwa portalu: login.example.com
  • Grupa gości: Guest_Internet
  • Username prefix: guest-
  • Password length: 16
  • Simultaneous sign-ins: 1
  • Validity period: 1 day
  • Validity start: After first login

10.30.40.0/24 to prywatna sieć przykładowa, którą należy zastąpić rzeczywistą siecią dla gości. login.example.com jest nazwą dokumentacyjną. Należy ją zastąpić nazwą FQDN, która z sieci gości wskazuje na osiągalny adres firewalla i jest objęta certyfikatem portalu. Grupa otrzymuje tylko policies faktycznie potrzebne dla tego dostępu gościnnego.

Przed utworzeniem kont muszą być spełnione następujące warunki:

  1. Sieć gości, DHCP, DNS, routing i NAT działają bez reguły użytkownika.
  2. Dostęp do sieci wewnętrznych i usług zarządzania ze strefy gości jest zablokowany.
  3. Captive Portal jest osiągalny tylko z przewidzianej strefy.
  4. Osobna grupa obejmuje Access Time, limity, Traffic Shaping i Sign-in Restriction.
  5. Dostęp administracyjny i niezależna ścieżka zarządzania pozostają dostępne podczas testu.
  6. Zasady wydawania, wygasania, unieważniania i przechowywania danych dostępowych gości są ustalone organizacyjnie.

Konfiguracja globalnych ustawień kont gości

Przed utworzeniem pierwszego konta należy otworzyć:

Authentication > Guest user settings

Te wartości są szablonem dla nowo tworzonych kont gości. Dlatego zmianę szablonu należy najpierw sprawdzić na koncie testowym.

Bezpieczny wybór General settings

W sekcji Guest user general settings ustawia się następujące pola:

  1. Username prefix: w przykładzie guest-. Neutralny prefiks jest lepszy niż nazwa firmy, lokalizacji lub klienta, która niepotrzebnie ujawnia informacje.
  2. Group: wybrać Guest_Internet. Użytkownicy goście dziedziczą policies tej grupy.
  3. Password length: w przykładzie 16. Sophos dopuszcza w Captive Portal maksymalnie 50 znaków. Długość powinna zapewniać wystarczającą siłę i niezawodne użycie w przewidzianym sposobie przekazania.
  4. Password complexity: wybrać najsilniejszą opcję zgodną z procesem wydawania danych i logowania.
  5. Disclaimer: podać krótkie warunki korzystania, odpowiedzialność i kontakt. Rzeczywiste dane logowania ani wewnętrzne szczegóły techniczne nie powinny znaleźć się w tym tekście. Konfiguracja komunikatu logowania i wiadomości w Sophos Firewall wyjaśnia globalne zarządzanie tekstami administracyjnymi, uwierzytelniania, SMTP i SMS.
  6. Auto purge on expiry: włączyć tylko wtedy, gdy wygasłe rekordy użytkowników mają być automatycznie usuwane, a wymagane dowody operacyjne są zachowywane w inny sposób.
  7. Zapisać przyciskiem Apply.

Auto purge on expiry usuwa po wygaśnięciu szczegóły konta gościa, ale nie powiązane logi. Ma to znaczenie dla ochrony danych i diagnostyki: czyszczenie kont i przechowywanie logów to dwa odrębne procesy.

Bezpieczne zarządzanie grupami użytkowników w Sophos Firewall wyjaśnia współdziałanie group policies, Main Group i wyjątków użytkownika. W przypadku gości nie należy używać grupy domyślnej jedynie dla wygody. Osobna restrykcyjna grupa ułatwia zrozumienie działania i wycofanie zmian.

Samodzielna rejestracja tylko przy rzeczywistej potrzebie

W Guest user registration settings można włączyć samodzielną rejestrację. Jest ona bardziej złożona niż kontrolowane wydawanie kont przez administratora lub recepcję i wymaga niezawodnego procesu SMS:

  • Enable guest users registration: włączyć tylko wtedy, gdy goście mają rejestrować się samodzielnie.
  • SMS gateway: wybrać wcześniej przetestowanego dostawcę.
  • Guest username: użyć numeru telefonu komórkowego lub wygenerować nazwę z Username prefix.
  • User validity: ustawić maksymalną ważność samodzielnie zarejestrowanych kont.
  • Default country code: dobrać do rzeczywistej grupy użytkowników.
  • CAPTCHA verification: pozostawić włączone, aby utrudnić automatyczne rejestracje.

Firewall obsługuje bramki SMS działające przez HTTP i HTTPS. Zalecamy HTTPS, aby dane logowania i parametry dostawcy nie były przesyłane bez szyfrowania. Adres URL, metoda HTTP, format numeru telefonu, parametry żądania i format odpowiedzi muszą dokładnie odpowiadać dokumentacji używanego dostawcy SMS. Przykładowych adresów URL z instrukcji nie należy kopiować do środowiska produkcyjnego.

Test connection wysyła wiadomość testową na numer telefonu. Według Sophos test może nie powieść się dla prywatnej bramki SMS z wewnętrznym adresem IP, mimo że rzeczywisty proces działa. Nie należy wtedy zakładać sukcesu, lecz sprawdzić pełną rejestrację za pomocą urządzenia mobilnego, logu dostawcy i faktycznie odebranej wiadomości SMS.

Jeśli brakuje bramki SMS, odpowiedzialnej osoby lub właściwej ochrony strony rejestracji, samodzielna rejestracja pozostaje wyłączona. Wyznaczona osoba tworzy wtedy konta w kontrolowany sposób.

Tworzenie pojedynczych lub wielu kont gości

Tworzenie pojedynczego konta z nazwą i adresem e-mail

Dla konkretnego gościa należy otworzyć Authentication > Guest users > Add single:

  1. W polu Name wpisać na przykład Visitor Zurich 2026-08-11. To pole jest nazwą rekordu, a nie późniejszym Username.
  2. Wprowadzić adres e-mail przeznaczony dla gościa.
  3. Ustawić Validity period na wymagany okres, w przykładzie 1 day.
  4. Świadomie wybrać Validity start.
  5. Zapisać przyciskiem Add albo zapisać i wydrukować dane logowania przez Add and print.

Immediately rozpoczyna ważność w chwili utworzenia. Pasuje to, gdy dane logowania są od razu przekazywane i używane. After first login rozpoczyna okres po pierwszym udanym logowaniu. Ten wariant jest zwykle lepszy dla kont przygotowywanych z wyprzedzeniem, ponieważ ważność nie upływa jeszcze przed przybyciem gościa.

Po utworzeniu lista pokazuje wygenerowany Username. Podczas przekazywania danych nie należy mylić nazwy rekordu z Username.

Generowanie wielu kont na wydarzenie

W Authentication > Guest users > Add multiple ustawia się liczbę, okres ważności i moment rozpoczęcia. Add and print generuje konta i odpowiadające im wydruki.

Wiele kont należy generować tylko na konkretne wydarzenie. Wydruki są liczone, bezpiecznie przechowywane i przekazywane osobie odpowiedzialnej. Niewydane lub wygasłe konta są wyłączane albo usuwane. Duży zapas nieprzypisanych danych logowania osłabia ograniczenie techniczne.

Sprawdzanie grupy, policies i ograniczeń logowania

Nowe konto gościa dziedziczy najpierw grupę wybraną w Guest user settings. W Authentication > Guest users > Edit można sprawdzić nazwę, hasło, numer telefonu, adres e-mail, grupę i poszczególne policies.

Policies przypisane bezpośrednio użytkownikowi mają pierwszeństwo przed group policies. Override ma więc sens tylko jako udokumentowany wyjątek. W jednolitym modelu dostępu gościnnego Access Time, Surfing Quota, Network Traffic, Traffic Shaping i Sign-in Restriction pozostają zwykle zebrane w Guest_Internet.

Dla przykładu obowiązują następujące ograniczenia:

  • Sign-in restriction: ograniczyć do rzeczywistej sieci gości lub odpowiedniego Node range, jeśli model logowania na to pozwala.
  • Simultaneous sign-ins: 1, dopóki konto gościa nie zostanie wyraźnie dopuszczone do użycia na wielu urządzeniach.
  • MAC binding: zwykle wyłączone dla zmieniających się gości. Firewall i tak nie wiąże użytkowników Remote Access VPN za pomocą adresów MAC.
  • Quarantine digest: włączyć tylko wtedy, gdy konto rzeczywiście korzysta z Mail Protection i określonego procesu kwarantanny.
  • Remote access policies: nie planować jako dostępu VPN dla użytkowników gości.

Ważność konta służy innemu celowi niż policies czasu i wykorzystania:

  • Validity period określa, jak długo można używać konta gościa.
  • Access Time zezwala na dostęp do Internetu lub go blokuje w powtarzalnych przedziałach czasu.
  • Surfing Quota i Network Traffic Quota ograniczają czas online lub ilość danych.
  • Reguła firewall określa, które strefy, cele i usługi są w ogóle osiągalne.

Warstwy te nie zastępują się wzajemnie. Ważne konto nie może uzyskać dostępu do serwera wewnętrznego, jeśli reguła firewall nie zezwala na to wyraźnie.

Połączenie Captive Portal ze ścieżką danych

Użytkownicy goście zazwyczaj logują się przez Captive Portal. Device Access, DNS, HTTPS, reguła użytkownika i wybrana metoda uwierzytelniania muszą więc do siebie pasować. Sam portal nie zapewnia jeszcze dostępu do Internetu.

W sieci gości należy wykonać pełny test pozytywny i negatywny:

  1. Klient otrzymuje z sieci gości adres, bramę i DNS.
  2. https://login.example.com:8090 jest osiągalny i wyświetla odpowiedni certyfikat.
  3. Zwykłe żądanie webowe prowadzi do portalu.
  4. Prawidłowe konto gościa może się zalogować.
  5. W Current activities > Live users pojawiają się Username i źródłowy adres IP.
  6. Dozwolony test Internetu trafia w oczekiwaną regułę użytkownika i Firewall Rule ID.
  7. Cel wewnętrzny i niedozwolona usługa pozostają zablokowane.
  8. Konto wygasłe, wyłączone lub celowo wpisane nieprawidłowo jest odrzucane.

Pełna procedura dotycząca reguły, Device Access i HTTPS znajduje się w Konfiguracja i testowanie Captive Portal w Sophos Firewall. Przewodnik po portalach rozróżnia User Portal, VPN Portal i Captive Portal.

Wydawanie danych logowania i obsługa kont

W Authentication > Guest users dostępnych jest kilka działań operacyjnych:

  • Print: kontrolowane wydanie danych logowania.
  • Resend credentials: ponowne wysłanie danych logowania przez skonfigurowaną bramkę SMS.
  • Change status: ustawienie konta jako aktywne lub nieaktywne.
  • Change password: nadanie nowego hasła po utracie danych lub w razie podejrzenia.
  • View usage: kontrola wykorzystania Internetu i stanu limitów.
  • Reset user accounting: wyzerowanie liczników wykorzystania i ponowne uruchomienie Network Traffic Quota.

Reset user accounting zmienia stan. Wcześniej należy udokumentować konto, aktualne wykorzystanie, czas i powód. Reset nie powinien być pierwszym krokiem diagnostycznym, ponieważ zmienia materiał dowodowy i może ponownie przyznać gościowi limit.

Podczas offboardingu konto najpierw się wyłącza, a następnie negatywnie testuje ponowne logowanie. Potem sprawdza się aktywne sesje w Current activities > Live users, niewykorzystane wydruki, dostęp do SMS i ewentualne override przypisane użytkownikowi. Rekord usuwa się lub pozostawia do usunięcia przez Auto purge on expiry dopiero wtedy, gdy nie ma już żadnych zależności.

Systematyczne zawężanie błędów

Nazwa rekordu nie działa jako Username

W Add single pole Name jest tylko nazwą rekordu użytkownika. Właściwy Username jest generowany na podstawie Guest user settings i widnieje na liście albo na wydruku danych logowania. Należy użyć dokładnie tej wartości razem z wygenerowanym lub zmienionym hasłem.

Konto jest ważne od razu albo jeszcze nie jest ważne

Sprawdzić Validity start i Validity period. Przy Immediately czas biegnie od chwili utworzenia, a przy After first login od pierwszego udanego logowania. Dodatkowo sprawdzić czas i strefę czasową firewalla. Szersza reguła firewall nie naprawi wygasłego konta.

Samodzielna rejestracja nie wysyła SMS

Sprawdzić, czy Enable guest users registration jest aktywne, wybrano właściwy SMS gateway, a numer telefonu, Country code, URL, metoda HTTP, parametry żądania i format odpowiedzi są zgodne z dostawcą. Następnie skontrolować log dostawcy i rzeczywisty odbiór SMS.

Pomyślny Test connection nie dowodzi jeszcze działania całego procesu rejestracji i Captive Portal. Z drugiej strony, według Sophos nieudany test prywatnej wewnętrznej bramki nie dowodzi automatycznie uszkodzenia ścieżki SMS. W obu przypadkach należy przeprowadzić test z rzeczywistym kontem pilotażowym.

Logowanie działa, ale dostęp do Internetu nie

W Current activities > Live users sprawdzić, czy gość jest widoczny z oczekiwanym źródłowym adresem IP. Następnie skontrolować grupę, override użytkownika, ważność, Access Time i limity. W Log Viewer ruch testowy musi trafić w oczekiwaną regułę użytkownika i Firewall Rule ID.

Jeśli użytkownika nie ma w Live users, najpierw sprawdzić ścieżkę logowania w access_server.log z udokumentowanym czasem testu. Jeśli użytkownik jest widoczny, kolejny krok dotyczy reguły, routingu, NAT, DNS lub protection policy. Systematyczne rozwiązywanie błędów uwierzytelniania rozdziela te etapy diagnostyki.

Konta gościa nie można wybrać dla SSL VPN

Jest to oczekiwane zachowanie produktu. Guest users i Guest groups nie są prawidłowymi Policy members dla Remote Access SSL VPN ani IPsec Remote Access. Dla zewnętrznego technika wymagającego VPN należy użyć zwykłego użytkownika z ograniczonymi uprawnieniami oraz odpowiednią policy MFA i Remote Access.

Lista kontrolna eksploatacji

  • Sieć gości, strefa, DNS, routing i NAT zostały sprawdzone osobno.
  • Sieci wewnętrzne i usługi zarządzania pozostają zablokowane.
  • Wybrano osobną restrykcyjną grupę gości.
  • Username prefix, długość i złożoność hasła oraz Disclaimer są udokumentowane.
  • Okres ważności i moment rozpoczęcia pasują do procesu wydawania danych.
  • Samodzielna rejestracja jest aktywna tylko z przetestowanym procesem SMS i CAPTCHA.
  • Dane logowania są bezpiecznie tworzone, przekazywane i niszczone.
  • Po zalogowaniu gość pojawia się w Live users.
  • Test pozytywny i negatywny potwierdzają regułę użytkownika oraz Firewall Rule ID.
  • Access Time, limity i override użytkownika zostały świadomie sprawdzone.
  • Wygasłe konta, sesje i wydruki są kontrolowanie usuwane.
  • Reset user accounting jest używany wyłącznie w sposób udokumentowany i zatwierdzony.

Częste pytania

Czym różni się konto gościa od Hotspot Voucher?

Użytkownik gość ma tymczasowe konto z Username, hasłem, grupą i własną ważnością. Voucher to kod dostępu do Wireless Hotspot z osobnymi limitami czasu, danych i urządzeń. Tych dwóch modeli nie należy łączyć.

Kiedy ustawić Validity start na After first login?

Gdy konto jest przygotowywane przed wizytą, a jego ważność ma rozpocząć się dopiero przy pierwszym udanym logowaniu. Przy Immediately okres biegnie już od chwili utworzenia.

Czy użytkownik gość może korzystać z SSL VPN?

Nie. Aktualna policy Sophos Firewall nie zezwala na Guest users ani Guest groups jako członków Remote Access SSL VPN lub IPsec Remote Access. Należy użyć zwykłego użytkownika z własnym uprawnieniem Remote Access.