Tworzenie i zarządzanie lokalnymi użytkownikami Sophos Firewall

Użytkownik lokalny jest przechowywany bezpośrednio na Sophos Firewall i uwierzytelniany w lokalnej bazie użytkowników. Takie rozwiązanie sprawdza się w małych środowiskach, na kontach pilotażowych i w przypadku pojedynczych współpracowników zewnętrznych. Konto lokalne może służyć jako rozwiązanie awaryjne dla usługi katalogowej tylko wtedy, gdy dla danej usługi przetestowano kolejność serwerów, odrębną nazwę użytkownika, dostęp do portalu oraz zachowanie po awarii źródła zewnętrznego. Pomoc SFOS opisuje kolejność serwerów, ale nie gwarantuje przełączenia awaryjnego dla każdego rodzaju błędu.

Niniejszy artykuł dotyczy interfejsu WebAdmin w SFOS 22. Samo utworzenie użytkownika nie zapewnia dostępu. Grupa, metoda uwierzytelniania, portal lub klient oraz reguła firewalla albo zasada VPN muszą być ze sobą zgodne.

Skrócona procedura:

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 określ schemat nazw, typ konta i osobę odpowiedzialną. SFOS zamienia wielkie litery w nazwie użytkownika na małe. Konto zastępcze ma nową tożsamość, dlatego ponownie sprawdź reguły, limity, przypisania VPN i ś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 całe zarządzanie hasłami, MFA, grupami, dezaktywacją i okresowymi przeglądami na administratora firewalla. Jest to praktyczne w przypadku kilku starannie zarządzanych kont. Przy wielu pracownikach lub częstych zmianach zatrudnienia centralny katalog jest zazwyczaj łatwiejszy w utrzymaniu.

Zwykłe lokalne konto użytkownika 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 okresem obowiązywania i właścicielem;
• przetestowane konto awaryjne z własną nazwą użytkownika na wypadek tymczasowej niedostępności zewnętrznego źródła użytkowników.

Nie należy używać jednego konta lokalnego dla kilku osób. Współdzielone dane logowania utrudniają zmianę haseł, stosowanie MFA i limitów, prowadzenie audytu oraz prawidłową obsługę odejścia użytkownika.

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ę przy użyciu nazwy użytkownika i hasła oraz otrzymuje zasady za pośrednictwem zwykłej grupy lub celowo ustawionych wyjątków dla 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.

Przykład i warunki wstępne

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 od 10.20.30.10 do 10.20.30.50.

example.com jest domeną zastrzeżoną do celów dokumentacyjnych, a zakres adresów należy do prywatnej sieci przykładowej. Zastąp nazwę użytkownika, adres e-mail, grupę, regułę i adresy wartościami ze swojego środowiska. Nazwa użytkownika nie jest oparta na adresie e-mail, dlatego pozostaje aktualna po zmianie tego adresu. Schemat nazewnictwa powinien być zgodny z zasadami helpdesku, procesem offboardingu i istniejącymi nazwami w usłudze katalogowej.

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.

Tworzenie lokalnego użytkownika

Konto tworzy się w Authentication > Users > Add:

1. W polu Username wpisz pilotuser01. SFOS zapisuje wartość małymi literami; nazwy użytkownika nie można później zmienić.
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 wpisz pilotuser01@example.com lub adres skrzynki pocztowej tej osoby. W przypadku konta technicznego użyj monitorowanego adresu z jasno określonym właścicielem.
6. W polu Group wybrać Local_Pilot_Users.
7. Pola Quarantine digest, zasad i Remote Access należy zmieniać tylko wtedy, gdy wymaga tego dana funkcja lub udokumentowany wyjątek dla 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 słowa wykryte przez mechanizm kontroli słownikowej. Dla każdego konta należy użyć długiego, unikatowego hasła wygenerowanego zgodnie z przyjętą procedurą zarządzania hasłami. Hasło podane jako przykład do skopiowania natychmiast stałoby się znanym sekretem, dlatego nie jest 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 wartości dla użytkownika jest właściwe w przypadku 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 szczegółowo wyjaśniają poszczególne zasady. W obiekcie użytkownika należy przypisywać tylko zasady, których działanie jest już znane.

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 logowanie z ciągłego zakresu adresów IPv4.

W tym przykładzie wybierz Node range i wprowadź 10.20.30.10 jako adres początkowy oraz 10.20.30.50 jako adres końcowy. Zastąp obie wartości najmniejszym ciągłym zakresem, z którego użytkownik rzeczywiście się loguje. Jeśli potrzebne są pojedyncze, niekolejne adresy IPv4, użyj Selected nodes. Zbyt wąski zakres zablokuje prawidłowe logowania; Any node nie zastępuje reguły firewalla, listy ACL portalu ani MFA.

W tym podstawowym procesie nie należy włączać MAC binding. Obsługuje ono uwierzytelnianie oparte na kliencie, 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ą.

Powiązanie metody uwierzytelniania z dostępem

Zapisany użytkownik może zalogować się tylko do usługi korzystającej z lokalnej bazy danych. W Authentication > Services włącz metodę Local na liście używanej przez daną usługę.

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.

Dla każdej metody uwierzytelniania można wybrać maksymalnie 20 serwerów. W przypadku User Portal i VPN Portal opcja dziedziczenia to Set authentication methods same as firewall. Dla SSL VPN system SFOS wyświetla Same as VPN lub Same as firewall, zależnie od wybranego odwołania. Przed dodaniem lub przeniesieniem metody Local sprawdź tę opcję i wynikającą z niej kolejność.

Oddzielna konfiguracja dostępu

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 ograniczenia dotyczące WAN. Zasady Remote Access konfiguruje się zgodnie z odpowiednimi instrukcjami VPN; samo ustawienie pola w obiekcie użytkownika nie oznacza jeszcze ukończenia konfiguracji.

Prawidłowa interpretacja pól Remote Access

Dla metod Remote Access innych niż SSL VPN wartości zasad ustawione bezpośrednio dla użytkownika mają pierwszeństwo przed grupą. SSL VPN działa inaczej: Użytkownik otrzymuje zasoby ze wszystkich zasad Full i Split Tunnel, które obejmują bezpośrednio użytkownika lub jedną z jego obsługiwanych grup. Pole SSL VPN policy nie zastępuje więc w prosty sposób zasad grupowych.

SSL VPN IP address pojawia się tylko wtedy, gdy w SSL VPN global settings włączono adresy statyczne. Adres IPv4 lub IPv6 musi być wolny i pochodzić z automatycznie utworzonego tam zakresu statycznego. Jeśli adresy dzierżawi serwer RADIUS, to on wykonuje przypisanie. IPsec remote access włącza natomiast dostęp przez Sophos Connect i może otrzymać własny adres dzierżawy.

L2TP i PPTP są metodami przestarzałymi. Po przypisaniu użytkownik musi najpierw zalogować się do VPN Portal i utworzyć hasło, zanim będzie mógł nawiązać połączenie. Aktualną ocenę L2TP i ścieżkę migracji opisano w artykule L2TP Remote Access; protokołu PPTP nie należy planować dla nowych połączeń. Clientless SSL VPN policy otwiera wyłącznie przypisane zakładki przeglądarki i nie zapewnia pełnego tunelu. Oddzielny proces opisano w Clientless Access.

W regule firewalla opartej na użytkowniku należy możliwie precyzyjnie określić źródło, cel, usługę oraz użytkownika lub grupę. Podczas testów odbiorczych należy pozostawić włączoną opcję Log firewall traffic. Podstawy reguł opisano w Zrozumienie i bezpieczna konfiguracja reguł Sophos Firewall.

Weryfikacja za pomocą testów pozytywnych i negatywnych

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ć planowany ruch i sprawdzić w dzienniku firewalla lub VPN, czy zgodnie z oczekiwaniami został dopasowany do reguły Local-Pilot-to-WAN albo jej Firewall Rule ID.
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żeli nie jest jasne, czy błąd powoduje status użytkownika, metoda uwierzytelniania, grupa czy reguła dostępu, artykuł Systematyczne rozwiązywanie problemów z uwierzytelnianiem na Sophos Firewall przedstawia właściwą kolejność kontroli. Do szczegółowej analizy można użyć pliku /log/access_server.log, który zawiera zdarzenia uwierzytelniania, autoryzacji i rozliczania; pierwszym krokiem powinien jednak pozostać Log Viewer.

Zarządzanie hasłami, MFA i wykorzystaniem

Aby jako administrator zmienić hasło istniejącego konta lokalnego w SFOS 22 i 23, należy otworzyć odpowiedniego użytkownika w Authentication > Users i kliknąć Change password. Najpierw sprawdza się konto i osobę za nie odpowiedzialną oraz przygotowuje nowe, długie i unikatowe hasło zgodnie z zatwierdzoną procedurą zarządzania hasłami. Następnie wprowadza się nowe hasło, zapisuje zmianę i bezpiecznie przekazuje hasło uprawnionej osobie. Potem sprawdza się nowe logowanie z nowym hasłem do rzeczywiście używanej usługi. Ta operacja w WebAdmin różni się od samodzielnej zmiany hasła w User Portal; konta uwierzytelniane zewnętrznie nadal są zarządzane w odpowiednim źródle użytkowników. Nie gwarantuje to automatycznego zakończenia istniejących sesji.

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. W Personal > Personal Details użytkownik może również zmienić nazwę wyświetlaną. Nazwa użytkownika i adres e-mail pozostają tam tylko do odczytu i są utrzymywane przez administratora w obiekcie użytkownika. 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 tę obsługę.

Aby zwiększyć ochronę, wybierz konto w Authentication > Multi-factor authentication. Opcja Generate OTP token with next sign-in umożliwia użytkownikowi zarejestrowanie tokenu za pośrednictwem User Portal lub VPN Portal. Artykuł MFA dla Sophos Firewall opisuje algorytm skrótu, dostęp do portalu, procedurę odzyskiwania i wdrożenie pilotażowe. MFA należy włączyć dopiero po przetestowaniu zwykłego logowania oraz procedury odzyskiwania dostępu.

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.

Odwrócenie zmiany i usunięcie konta

Przed rozpoczęciem fazy pilotażowej udokumentuj istniejącą kolejność w Authentication > Services oraz wszystkie zmieniane ustawienia grup, portali, reguł i VPN. Dzięki temu wycofanie zmian nie będzie zależało od odgadywania wartości domyślnych. Po odejściu użytkownika, niepowodzeniu pilotażu lub ustaniu celu konta wykonaj czynności w odwrotnej kolejności:

1. Sprawdzić zależności w regułach, grupach, zasadach Remote Access, limitach, MFA i dokumentacji.
2. Pod Authentication > Users wybierz użytkownika i ustaw Change status na Inactive.
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. Usunąć użytkownika z reguł firewalla i zasad Remote Access albo przywrócić udokumentowany wcześniejszy wybór.
6. Przywrócić zmienione ustawienia grup, portali i usług uwierzytelniania dokładnie do udokumentowanego stanu początkowego.
7. Sprawdzić dzienniki firewalla, VPN i konfiguracji pod kątem kolejnych prób, pozostałego ruchu i wykonanych zmian.
8. Usunąć konto dopiero po wyjaśnieniu wszystkich zależności albo pozostawić je nieaktywne zgodnie z zasadami retencji.

Pomoc SFOS nie potwierdza, że dezaktywacja kończy wszystkie istniejące połączenia. Sesje i tunele należy sprawdzić i rozłączyć oddzielnie. Po ponownej aktywacji konta trzeba powtórzyć testy pozytywne i negatywne.

Przed ryzykownym usunięciem można w Backup and firmware > Import export wyeksportować obiekt konfiguracyjny User z opcją Include dependent entity. Eksport zawiera dane wrażliwe, w tym hasła, dlatego należy go zaszyfrować i przechowywać w miejscu chronionym przed nieuprawnionym dostępem. Do późniejszego importu musi być również dostępny właściwy Secure Storage Master Key. Import aktualizuje istniejącą konfigurację i w przypadku nakładających się obiektów stosuje wartości z importu. Może więc również nadpisać wyeksportowane wspólne zależności. Przed importem należy sprawdzić zawartość i możliwe skutki, najlepiej w odpowiednim środowisku testowym.

Pełna kopia zapasowa nie umożliwia szybkiego wycofania zmian dotyczących jednego użytkownika: jej przywrócenie zastępuje całą konfigurację, ponownie uruchamia firewall i usuwa późniejsze zmiany. Proces opisano w artykule Tworzenie i przywracanie kopii zapasowej na Sophos Firewall.

W klastrze HA należy wprowadzić zmianę na urządzeniu Primary, a następnie sprawdzić stan synchronizacji. Dzienniki i raporty nie są synchronizowane między węzłami, dlatego podczas diagnostyki trzeba analizować je oddzielnie.

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

Rozwiązywanie problemów 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ż obsługiwać ten ruch.

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.

Widok View usage pozostaje pusty

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

• Live users pokazuje użytkownika pilotuser01, oczekiwany źródłowy adres IP i właściwy Client Type.
• Dziennik uwierzytelniania potwierdza lokalne logowanie; reguła Local-Pilot-to-WAN lub jej Firewall Rule ID zgodnie z oczekiwaniami obsługuje ruch testowy.
• Nieprawidłowe hasło, niedozwolone źródło i nieautoryzowana funkcja dostarczają oczekiwanych negatywnych dowodów.
• Nadpisania ustawień użytkownika, Simultaneous sign-ins, Sign-in restriction i ewentualna data wygaśnięcia są udokumentowane.
• Jeśli używana jest funkcja MFA, przetestowano jej rejestrację oraz proces odzyskiwania.
• Stan początkowy, odpowiedzialność za konto, dezaktywacja, odłączenie sesji i późniejsze usunięcie są udokumentowane.

Często zadawane pytania