Tworzenie i zarządzanie lokalnymi użytkownikami Sophos Firewall

Lokalny użytkownik jest przechowywany bezpośrednio na Sophos Firewall i uwierzytelniany w lokalnej bazie użytkowników. To rozwiązanie pasuje do małych środowisk, kont pilotażowych, pojedynczych zewnętrznych współpracowników lub świadomie utrzymywanego dostępu awaryjnego. Samo utworzenie konta nie zapewnia jednak dostępu. Grupa, metoda uwierzytelniania, portal lub klient, zasada firewalla lub VPN oraz późniejsza weryfikacja muszą być ze sobą zgodne.

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

1. Określić przypadek użycia, grupę docelową i potrzebną usługę.
2. W Authentication > Groups przygotować restrykcyjną grupę typu Normal.
3. W Authentication > Users > Add wprowadzić trwałą nazwę użytkownika i wybrać User type: User.
4. Przypisać indywidualne silne hasło oraz właściwą grupę.
5. Pozostawić pola zasad użytkownika bez zmian, jeśli mają obowiązywać wartości grupy.
6. Świadomie ograniczyć Simultaneous sign-ins i Sign-in restriction.
7. W Authentication > Services sprawdzić, czy dla używanej usługi wybrano Local.
8. Oddzielnie i możliwie wąsko skonfigurować portal, regułę użytkownika lub zasadę Remote Access.
9. Przy użyciu konta pilotażowego przetestować poprawne i odrzucone logowanie oraz rzeczywisty ruch.
10. Dopiero potem włączyć MFA, utworzyć kolejnych użytkowników i udokumentować offboarding.

⚠️ Nazwy użytkownika nie można później zmienić. Przed zapisaniem należy więc ustalić schemat nazewnictwa, typ konta i odpowiedzialność. Nowe konto z inną nazwą tworzy nową tożsamość i może rozdzielić reguły, limity, przypisania VPN, logi oraz ślady audytowe.

Kiedy lokalny użytkownik jest odpowiedni

Lokalni użytkownicy nie wymagają Active Directory ani zewnętrznego serwera RADIUS lub LDAP. Upraszcza to wdrożenie, ale przenosi zarządzanie hasłami, MFA, grupami, dezaktywacją i przeglądami w całości na firewall. Jest to praktyczne dla kilku świadomie zarządzanych kont. Przy wielu pracownikach lub częstych zmianach zatrudnienia centralny katalog jest zazwyczaj łatwiejszy w utrzymaniu.

Zwykły lokalny użytkownik nadaje się na przykład jako:

• konto pilotażowe dla Captive Portal, User Portal lub Remote Access;
• konto w małym środowisku bez usługi katalogowej;
• konto pojedynczego zewnętrznego usługodawcy z jasno określonym czasem i właścicielem;
• udokumentowany dostęp awaryjny, gdy zewnętrzne źródło użytkowników jest czasowo niedostępne.

Nie zaleca się używania lokalnego konta jako wspólnego konta dla kilku osób. Współdzielone dane logowania utrudniają zmianę haseł, MFA, limity, audyt i prawidłowy offboarding.

Nie mieszać typów użytkowników

SFOS udostępnia kilka podobnych typów użytkowników, które rozwiązują różne zadania:

• Zwykły lokalny użytkownik loguje się nazwą użytkownika i hasłem oraz otrzymuje zasady przez zwykłą grupę lub świadome nadpisania użytkownika.
• Użytkownik gościnny ma ograniczony czas ważności, korzysta z ustawień Guest User i zwykle jest używany przez Captive Portal.
• Clientless User jest rozpoznawany na podstawie adresu IP i nie wykonuje interaktywnego logowania.
• Lokalny administrator otrzymuje User type: Administrator oraz profil Device Access z uprawnieniami WebAdmin.
• Użytkownik AD, LDAP, RADIUS lub Entra jest uwierzytelniany przez zewnętrzne źródło. W zależności od metody jego lokalny rekord powstaje dopiero przy pierwszym udanym logowaniu.

Dla osoby, która ma logować się do Captive Portal lub usługi VPN, stosuje się User type: User. Nie daje to kontu dostępu do WebAdmin ani SSH.

Zaplanować przykład i wymagania

Poniższy przykład wykorzystuje:

• nazwę użytkownika pilotuser01;
• nazwę wyświetlaną Local Pilot User;
• adres e-mail pilotuser01@example.com;
• grupę Local_Pilot_Users;
• regułę firewalla Local-Pilot-to-WAN;
• dozwolone źródło logowania 10.20.30.0/24.

example.com jest domeną zarezerwowaną do dokumentacji, a 10.20.30.0/24 służy tutaj wyłącznie jako przykładowa sieć prywatna. Nazwę użytkownika, adres e-mail, grupę, regułę i sieć należy zastąpić wartościami z własnego środowiska. Nazwa użytkownika jest celowo neutralna funkcjonalnie i nie zawiera adresu e-mail, aby późniejsza zmiana poczty nie zmieniała tożsamości logowania. W środowisku produkcyjnym schemat nazw powinien pasować do helpdesku, procesu offboardingu i istniejących nazw katalogowych.

Przed utworzeniem konta należy wyjaśnić:

• Która usługa uwierzytelnia użytkownika: Captive Portal, User Portal, VPN Portal, SSL VPN, IPsec czy inny obsługiwany dostęp?
• Która zwykła grupa zawiera wspólną konfigurację bazową?
• Która zasada firewalla lub Remote Access zezwala na późniejszy dostęp?
• Z jakich adresów IPv4 konto może się logować?
• Ile równoczesnych logowań jest rzeczywiście potrzebnych?
• Czy wymagane jest lokalne MFA i przez który portal odbywa się pierwsza rejestracja?
• Kto dezaktywuje konto i sprawdza istniejące sesje podczas offboardingu?

Zarządzanie grupami użytkowników i Main Group na Sophos Firewall wyjaśnia wspólną logikę grup. Dla zwykłych lokalnych użytkowników stosuje się grupę typu Normal. Grupa typu Clientless należy do modelu opartego na adresie IP i nie jest właściwą bazą dla tego procesu logowania.

Utworzyć lokalnego użytkownika

Konto tworzy się w Authentication > Users > Add:

1. W polu Username wprowadzić pilotuser01.
2. W polu Name wprowadzić Local Pilot User.
3. Ustawić User type na User.
4. Wprowadzić i potwierdzić długie, indywidualne hasło zgodne z przyjętym procesem haseł.
5. W polu Email wprowadzić pilotuser01@example.com lub rzeczywisty adres osoby odpowiedzialnej.
6. W polu Group wybrać Local_Pilot_Users.
7. Pola zasad i Remote Access zmieniać tylko wtedy, gdy zamierzono udokumentowany wyjątek użytkownika.
8. Odpowiednio ustawić Simultaneous sign-ins i Sign-in restriction.
9. Zapisać przez Save.

SFOS odrzuca często używane hasła i wyrazy wykryte podczas sprawdzania słownika. Artykuł celowo nie pokazuje przykładowego hasła. Hasło możliwe do skopiowania z dokumentacji natychmiast stałoby się znanym sekretem i nie byłoby bezpiecznym wzorcem.

Wartości grupy lub nadpisania użytkownika

W rekordzie użytkownika można ustawić Surfing quota, Access time, Network traffic i Traffic shaping, a także kilka pól Remote Access. Wartości użytkownika mają pierwszeństwo przed wartościami grupy. Jeśli grupa ma pozostać łatwą w utrzymaniu konfiguracją bazową, tych pól nie należy nadpisywać zapobiegawczo.

Nadpisanie użytkownika pasuje do jasno udokumentowanego wyjątku, na przykład bardziej restrykcyjnego Access Time podczas czasowego zlecenia. Należy zapisać:

• które pole różni się od wartości grupy;
• dlaczego wyjątek jest potrzebny;
• kiedy zostanie sprawdzony lub usunięty;
• jak ponownie zacznie obowiązywać pierwotna wartość grupy.

Access Time dla użytkowników oraz limity Surfing i Network Traffic wyjaśniają każdą zasadę w całości. W obiekcie użytkownika należy przypisać tylko zasadę, której działanie jest już zrozumiałe.

Ograniczyć liczbę i źródło logowań

Simultaneous sign-ins ogranicza równoczesne sesje. Global setting przejmuje wartość obowiązującą dla nowych użytkowników z Authentication > Services. Alternatywnie można ustawić własną wartość lub wybrać Unlimited. Nieograniczone sesje są rzadko potrzebne zwykłemu indywidualnemu użytkownikowi i utrudniają wykrycie współdzielonych danych logowania.

Sign-in restriction ogranicza adresy IPv4, z których użytkownik może się logować:

• Any node: zezwolić na logowanie z każdego osiągalnego źródła;
• User group nodes: przejąć wartość grupy;
• Selected nodes: podać pojedyncze przewidziane adresy IPv4;
• Node range: zezwolić na ciągły zakres IPv4.

W przykładzie należy użyć rzeczywistej sieci zarządzania, użytkowników lub VPN, zamiast bezrefleksyjnie kopiować 10.20.30.0/24. Zbyt wąski wybór blokuje prawidłowe logowania. Any node rozszerza natomiast jedynie możliwe źródło logowania i nie zastępuje reguły firewalla, ACL portalu ani MFA.

W tym podstawowym procesie nie należy włączać MAC binding. Obsługuje ono uwierzytelnianie klienta, ale nie Remote Access VPN ani Captive Portal. Jeśli zostanie włączone bez adresu MAC, SFOS automatycznie powiąże pierwszy wykryty adres MAC przy pierwszym logowaniu. Na urządzeniach mobilnych, po zmianie Wi-Fi lub przy współdzielonych klientach może to szybko stać się nieoczekiwaną zależnością.

Połączyć metodę uwierzytelniania i dostęp

Zapisany użytkownik może zalogować się tylko do usługi, która rzeczywiście odpytuje lokalną bazę danych. Dlatego w Authentication > Services wybiera się Local dla przewidzianej usługi.

Obszary są rozdzielone:

• Firewall authentication methods dla ruchu firewalla i Captive Portal;
• User portal authentication methods dla User Portal;
• VPN portal authentication methods dla VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods dla tych metod VPN;
• SSL VPN authentication methods dla Remote Access SSL VPN.

Wiele źródeł jest odpytywanych w wyświetlonej kolejności. Udana próba w User Portal nie dowodzi więc automatycznie, że ten sam użytkownik jest prawidłowo skonfigurowany dla SSL VPN lub IPsec.

Portal, reguła lub zasada VPN pozostają oddzielne

Lokalna tożsamość nie otwiera ścieżki sieciowej. Captive Portal wymaga dodatkowo Device Access, Web Authentication i odpowiedniej reguły użytkownika. Pełny proces opisano w artykule Konfiguracja i testowanie Captive Portal na Sophos Firewall.

User Portal i VPN Portal również są oddzielnymi usługami. Model portali Sophos Firewall wyjaśnia porty, przeznaczenie, Device Access i granice WAN. Zasady Remote Access utrzymuje się w odpowiednich instrukcjach VPN i nie uznaje za kompletne tylko dlatego, że ustawiono pole w obiekcie użytkownika.

Dla reguły firewalla opartej na użytkowniku należy możliwie wąsko ustawić źródło, cel, usługę oraz użytkownika lub grupę. Podczas odbioru pozostawić włączone Log firewall traffic. Podstawy reguł opisano w Zrozumienie i bezpieczna konfiguracja reguł Sophos Firewall.

Weryfikować testami pozytywnymi i negatywnymi

Widoczne konto ze statusem Active nie jest jeszcze dowodem sukcesu. Konto pilotażowe należy przetestować przez dokładnie tę usługę, która będzie używana później:

1. Zalogować się jako pilotuser01 w prywatnym oknie przeglądarki lub z czystego klienta testowego.
2. W Current activities > Live users sprawdzić nazwę użytkownika, źródłowy adres IP i Client Type.
3. W Log Viewer > Authentication sprawdzić udane logowanie, lokalne uwierzytelnienie i czas.
4. Wygenerować przewidziany ruch i sprawdzić oczekiwaną regułę lub zasadę w logu firewalla lub VPN.
5. Jako test negatywny wykorzystać źródło lub funkcję, które jawnie nie są dozwolone.
6. Jeśli aktywny jest limit lub Access Time, oddzielnie przetestować działanie wewnątrz i poza ograniczeniem.
7. Udokumentować wynik, używaną grupę, nadpisania użytkownika i metodę uwierzytelniania.

Negatywny test logowania nie powinien kończyć się niepowodzeniem wyłącznie dlatego, że celowo użyto błędnego hasła. Należy też sprawdzić, czy niedozwolone źródło, użytkownik bez odpowiedniej grupy lub nieprzewidziana funkcja rzeczywiście nie uzyskują dostępu. Pozwala to oddzielić kontrolę hasła od działania zasad i reguł.

Jeśli nie wiadomo jeszcze, czy problem dotyczy lokalnej bazy danych, wyboru usługi, statusu użytkownika, grupy czy dopiero późniejszej reguły, systematyczne rozwiązywanie błędów uwierzytelniania Sophos Firewall prowadzi przez pełny ciąg kontroli. Do głębszej analizy /log/access_server.log zawiera zdarzenia uwierzytelniania, autoryzacji i rozliczania; Log Viewer pozostaje pierwszym krokiem.

Obsługiwać hasło, MFA i użycie

Lokalny użytkownik może samodzielnie zmienić hasło w User Portal > Personal > Change Password. Dotyczy to lokalnej bazy danych, a nie zewnętrznie uwierzytelnianych kont AD, LDAP czy RADIUS. User Portal powinien być dostępny tylko z potrzebnych stref i nie należy otwierać go szeroko na WAN wyłącznie ze względu na obsługę haseł.

Dla dodatkowej ochrony konto można wybrać w Authentication > Multi-factor authentication. Za pomocą Generate OTP token with next sign-in użytkownik rejestruje token przez User Portal lub VPN Portal. MFA dla Sophos Firewall wyjaśnia algorytm skrótu, dostęp do portalu, odzyskiwanie i pilotaż. MFA należy włączyć dopiero wtedy, gdy zwykłe logowanie i ścieżka odzyskiwania działają.

W Authentication > Users > <użytkownik> > View usage widać przypisane limity, czas Surfing i zużycie danych. Aby dane się pojawiły, ruch musi trafić w regułę firewalla opartą na użytkowniku z Log firewall traffic. Reset user accounting zeruje liczniki Surfing i Network Traffic, dlatego nie służy jako ogólna naprawa logowania.

Dezaktywować i prawidłowo usunąć konto

Gdy osoba odchodzi lub kończy się cel konta, nie należy od razu usuwać go bez sprawdzenia:

1. Sprawdzić zależności w regułach, grupach, zasadach Remote Access, limitach, MFA i dokumentacji.
2. W Authentication > Users wybrać użytkownika i przez Change status ustawić jako nieaktywnego.
3. Wykonać nową próbę logowania jako test negatywny.
4. W Current activities > Live users sprawdzić istniejące sesje i w razie potrzeby rozłączyć zwykłego użytkownika przez Disconnect.
5. Sprawdzić logi firewalla i VPN pod kątem kolejnych prób lub ruchu resztkowego.
6. Usunąć konto dopiero po wyjaśnieniu zależności lub pozostawić je nieaktywne zgodnie z procesem retencji.

Dezaktywacji nie należy traktować jako gwarancji automatycznego zakończenia każdej istniejącej sesji. Sesje, tunele i ruch sprawdza się oddzielnie. Po ponownym aktywowaniu wykonuje się ponownie test pozytywny i negatywny.

Użytkownicy i grupy współdzielą wewnętrzne identyfikatory. Sama duża liczba obiektów nie dowodzi problemu. Jeżeli jednak użytkownik ma User ID większy niż 65535 i nie jest uwierzytelniany, należy użyć oddzielnego procesu dotyczącego limitu User ID Sophos Firewall, zamiast zmieniać hasła lub reguły na chybił trafił.

Zawęzić problem według objawu

Nazwa użytkownika i hasło są odrzucane

W Authentication > Users sprawdzić, czy konto jest lokalne, aktywne i zapisane z oczekiwaną nazwą użytkownika. Następnie w Authentication > Services sprawdzić dla konkretnej usługi, czy wybrano Local. Udane logowanie w innym portalu nie dowodzi tego wyboru usługi.

Logowanie działa, ale reguła użytkownika nie pasuje

W Current activities > Live users sprawdzić tożsamość, źródłowy adres IP i Client Type. Następnie w Log Viewer sprawdzić pozycję reguły, Source Zone, użytkownika lub grupę i Firewall Rule ID. Reguła sieciowa znajdująca się nad regułą użytkownika może już przejąć przepływ.

Zmiana grupy nie działa

W rekordzie użytkownika poszukać indywidualnych wartości dla limitu, Access Time, Traffic Shaping lub Remote Access. Te nadpisania mają pierwszeństwo przed grupą. Wartość należy przywrócić do dziedziczenia z grupy dopiero po porównaniu z udokumentowanym wyjątkiem.

Użytkownik może logować się z nieoczekiwanego źródła

Sprawdzić Sign-in restriction zarówno dla użytkownika, jak i grupy. Dodatkowo sprawdzić rzeczywiście używaną usługę, Device Access i regułę sieciową. Ustawienie Any node nie jest automatycznie kompensowane przez MFA ani restrykcyjną regułę firewalla.

View usage pozostaje puste

Sprawdzić, czy użytkownik jest rozpoznawany jako Live User i czy ruch trafia w regułę opartą na użytkowniku z Log firewall traffic. Następnie sprawdzić okres, przypisanie limitu i rzeczywisty ruch testowy. Reset user accounting nie tworzy brakujących logów ani nie naprawia błędnej reguły.

Operacyjna lista kontrolna

• Przypadek użycia, właściciel i data wygaśnięcia konta są udokumentowane.
• Nazwa i typ użytkownika zostały świadomie wybrane przed zapisaniem.
• Grupa typu Normal zawiera wspólną konfigurację bazową.
• Nadpisania użytkownika są unikane lub uzasadnione.
• Simultaneous sign-ins i Sign-in restriction pasują do przypadku użycia.
• Local jest wybrane dla każdej wymaganej usługi uwierzytelniania.
• Portal, reguła firewalla lub zasada VPN zostały skonfigurowane oddzielnie.
• Sprawdzono pozytywne i negatywne logowanie oraz rzeczywisty ruch.
• Live Users, Authentication Log oraz oczekiwana reguła lub zasada są zgodne.
• MFA i odzyskiwanie zostały przetestowane, jeśli MFA jest używane.
• Za zmiany hasła, użycie i offboarding odpowiada wskazana osoba.
• Dezaktywacja, istniejące sesje i późniejsze usunięcie są oddzielnymi krokami.

Często zadawane pytania