Konfiguracja i testowanie Clientless Users na Sophos Firewall

Drukarka, serwer lub inne stałe urządzenie często nie może zalogować się do firewalla. Clientless Users nadaje jednak takiemu ruchowi zrozumiałą tożsamość: Sophos Firewall przypisuje skonfigurowaną nazwę użytkownika do widocznego źródłowego adresu IP i może używać tej tożsamości w regułach, Live Users i logach.

Nie jest to uwierzytelnianie. Każdy, kto przejmie skonfigurowany adres IP lub pojawi się za tym samym adresem NAT, może otrzymać to samo przypisanie. Clientless Users nadaje się więc wyłącznie do urządzeń o stabilnych adresach, które pozostają pod kontrolą. W przypadku zmiennych urządzeń osobistych, współdzielonych adresów IP lub dostępu uprzywilejowanego lepszym wyborem jest prawdziwa metoda logowania.

⚠️ Clientless Users to nie Clientless SSL VPN. Clientless Users wewnętrznie przypisuje adres IP do tożsamości. Natomiast Clientless SSL VPN publikuje bookmarki RDP, SSH lub serwerów plików w VPN Portal.

Clientless User w ośmiu krokach

1. Określić urządzenie, właściciela, wymagane cele i źródłowy adres IP widoczny dla firewalla.
2. Skonfigurować adres statycznie lub jednoznacznie związać go za pomocą rezerwacji DHCP.
3. W sekcji Authentication > Groups utworzyć małą grupę typu Clientless.
4. W sekcji Authentication > Clientless users > Add utworzyć dokładnie jednego użytkownika pilotażowego z tym adresem IP.
5. Utworzyć osobną, logowaną regułę firewalla z dokładnym źródłem, włączonym Match known users i grupą Clientless.
6. Sprawdzić użytkownika w sekcji Current activities > Live users, a rzeczywisty przepływ w Log Viewer.
7. Na krótko ustawić użytkownika jako Inactive i potwierdzić, że reguła tożsamości przestaje pasować.
8. Ponownie aktywować użytkownika, jeszcze raz zweryfikować regułę oraz udokumentować przypisanie, właściciela i termin przeglądu.

Kiedy Clientless Users jest odpowiedni

Clientless Users jest przydatny, gdy reguła firewalla lub raport potrzebuje stabilnej tożsamości urządzenia, ale urządzenie nie potrafi wykonać logowania użytkownika. Typowymi kandydatami są drukarki, urządzenia monitorujące, sprzęt laboratoryjny lub ściśle ograniczone serwery infrastrukturalne.

Funkcja jest odpowiednia tylko wtedy, gdy spełnione są wszystkie poniższe warunki:

• Firewall zawsze widzi dla tego ruchu ten sam jednoznaczny źródłowy adres IP.
• Adres jest statyczny lub związany za pomocą kontrolowanej rezerwacji DHCP.
• Za adresem nie znajduje się kilka urządzeń korzystających z NAT lub proxy.
• Tożsamość otrzymuje dostęp tylko do celów i usług rzeczywiście potrzebnych urządzeniu.
• Inne urządzenie nie może niezauważenie przejąć adresu.
• Możliwe jest wykonanie testu pozytywnego i negatywnego z rzeczywistym przepływem danych.

Dla zwykłych klientów domenowych zazwyczaj lepiej nadaje się STAS. Jeżeli dostęp sieciowy już generuje RADIUS Accounting, RADIUS SSO Accounting może dynamicznie utworzyć przypisanie użytkownika do adresu IP. Captive Portal zapewnia interaktywne logowanie.

Clientless Users nie zastępuje brakującej segmentacji. Drukarka nadal powinna znajdować się w odpowiedniej strefie lub osobnej sieci i mieć ścisłą regułę. Tożsamość oparta na adresie IP uzupełnia tę kontrolę, ale jej nie zastępuje.

Działanie i granica bezpieczeństwa

Sophos Firewall pokazuje aktywnego Clientless User jako Live User bez interaktywnego logowania. Gdy pakiet pasuje do skonfigurowanego adresu IP, przypisana nazwa użytkownika jest dostępna dla reguł opartych na użytkownikach i raportów.

Nie stanowi to kryptograficznego dowodu urządzenia ani osoby:

• Nie ma hasła ani drugiego składnika.
• Przypisanie nie sprawdza osobistej sesji Windows ani Entra.
• Zmiana adresu IP nie jest automatycznie interpretowana jako zmiana urządzenia.
• Współdzielony adres NAT lub proxy nie rozróżnia poszczególnych endpointów.
• Clientless User nie jest użytkownikiem Remote Access VPN.

Jeśli potrzebne są reguły osobowe, Clientless Users powinien być używany tylko w dobrze kontrolowanych wyjątkach. W przypadku osoby ze stałym stanowiskiem przypisanie DHCP musi być stabilne, ale tożsamość nadal opisuje adres IP, a nie osobę przed ekranem.

Przykład i wartości do zastąpienia

Procedura wykorzystuje drukarkę, która może łączyć się tylko z DNS, NTP i wewnętrznym serwerem wydruku:

• Username: Printer-Accounting
• widoczny adres IP: 192.0.2.50
• grupa Clientless: Clientless-Devices
• reguła firewalla: Printer-Accounting_to_Services
• Source network: obiekt hosta Printer-Accounting_192.0.2.50
• cel: wewnętrzna usługa DNS/NTP i przewidziany serwer wydruku
• przegląd: właściciel i kolejny termin kontroli w opisie reguły

192.0.2.50 należy do oficjalnego zakresu dokumentacyjnego IPv4 i nie jest adresem urządzenia produkcyjnego. Należy go zastąpić stałym adresem IP, który firewall widzi jako źródło rzeczywistego przepływu. W przypadku IPv6 potrzebne są stały adres IPv6, osobna reguła IPv6 i oddzielna walidacja.

Nazwy w przykładzie pokazują przeznaczenie, ale nie są wymaganiem produktu. W rzeczywistym środowisku użytkownik, grupa, obiekt hosta i reguła powinny być nazwane zgodnie ze spójnym schematem.

Przygotowanie adresu i grupy

Potwierdzenie widocznego źródłowego adresu IP

Przed konfiguracją tożsamości należy wygenerować dokładnie jeden kontrolowany przepływ danych z urządzenia. W Log Viewer lub Packet Capture należy zapisać co najmniej Source IP, In interface, cel, usługę i dotychczasową Firewall Rule ID.

Jeżeli widocznym źródłem jest adres NAT, proxy lub współdzielonej bramy, należy się tutaj zatrzymać. Tego adresu nie wolno przypisywać do jednego Clientless User. W przeciwnym razie wszystkie urządzenia za nim otrzymają tę samą tożsamość.

W przypadku DHCP należy utworzyć rezerwację dla tego konkretnego urządzenia. Samo wpisanie w firewallu wolnego adresu z puli nie wystarcza: jeśli serwer DHCP później przydzieli go innemu klientowi, ten klient przejmie tożsamość i potencjalnie uprawnienia reguły.

Tworzenie grupy Clientless

W sekcji Authentication > Groups > Add należy utworzyć osobną grupę:

1. Wprowadzić Clientless-Devices jako Name.
2. Wybrać Clientless jako Group type.
3. Ustawić tylko wymagane policy grupy.
4. Zapisać za pomocą Save.

Policy właściwe dla użytkownika mają pierwszeństwo przed policy przypisanej grupy. Grupa powinna więc mieć zrozumiałe wspólne przeznaczenie bazowe. Odstępstwa dla pojedynczego użytkownika należy udokumentować i przetestować osobno.

Clientless Users nie obsługują Surfing quota, Access time ani Network traffic policy. Jeśli stałe urządzenie ma komunikować się tylko o określonych godzinach, Schedule stosuje się w precyzyjnie ograniczonej regule firewalla. Access Time dla użytkowników i grup dotyczy natomiast zwykłych użytkowników, grup i użytkowników gościnnych. Surfing Quota i Network Traffic Quota również wymagają obsługiwanego przypisania użytkownika lub grupy.

Prawidłowe zarządzanie grupami użytkowników i grupą główną w Sophos Firewall wyjaśnia, dlaczego grupy Normal, importowane i Clientless reprezentują różne modele tożsamości. Ten artykuł pozostaje poświęcony pełnej procedurze Clientless opartej na adresie IP.

Dodawanie pojedynczego Clientless User

W sekcji Authentication > Clientless users > Add należy ustawić pola w następujący sposób:

1. Username: Printer-Accounting
2. IP address: wcześniej potwierdzony stały adres urządzenia
3. Group: Clientless-Devices
4. Name: zrozumiała nazwa wyświetlana urządzenia
5. Email: podać prawdziwy adres osoby odpowiedzialnej tylko wtedy, gdy jest potrzebny do funkcji takich jak Quarantine Digest
6. Quarantine digest: włączać tylko świadomie; dla zwykłej drukarki funkcja zazwyczaj pozostaje wyłączona
7. Zapisać za pomocą Save.

Następnie można ponownie otworzyć użytkownika i dodać obsługiwane ustawienia indywidualne. Zmianę uznaje się za udaną dopiero wtedy, gdy Live Users, dopasowanie reguły i rzeczywisty ruch są ponownie prawidłowe.

Add range tylko z wyraźnym uzasadnieniem

Authentication > Clientless users > Add range tworzy osobnych Clientless Users dla wszystkich adresów między From IP i To IP. Sophos przypisuje wybraną grupę, a każdego wygenerowanego użytkownika można później edytować oddzielnie.

Zwykła pula DHCP nie jest odpowiednia. Zakres z góry traktowałby każdy później przydzielony adres jako znaną tożsamość. Add range nadaje się tylko do w pełni zarezerwowanego i udokumentowanego bloku adresów o jednakowym przeznaczeniu, z kontrolowanym przydziałem i późniejszą kontrolą każdego wpisu. Przy pierwszym wdrożeniu bezpieczną opcją pozostaje Add z dokładnie jednym adresem IP.

Tworzenie ścisłej reguły firewalla

Zrozumienie i bezpieczna konfiguracja reguł Sophos Firewall opisuje ogólną mechanikę reguł. Dla tego przykładu należy utworzyć osobną regułę powyżej bardziej ogólnej reguły drukarek lub LAN:

• Rule name: Printer-Accounting_to_Services
• Action: Accept
• Log firewall traffic: włączone
• Source zone: rzeczywista strefa urządzenia
• Source networks and devices: Printer-Accounting_192.0.2.50
• Destination zone: strefa przewidzianych usług
• Destination networks: tylko cel DNS/NTP i serwer wydruku
• Services: tylko wymagane porty
• Match known users: włączone
• Users or groups: Clientless-Devices lub pojedynczy użytkownik pilotażowy

Źródłowy adres IP i warunek użytkownika mogą być świadomie używane razem. Adres IP ogranicza techniczne źródło, a tożsamość sprawia, że reguła i raportowanie są zrozumiałe. Szerokie źródło Any lub cel Any nie są potrzebne dla stałego urządzenia.

Po zapisaniu należy upewnić się, że żadna bardziej ogólna reguła powyżej nie pasuje jako pierwsza. Tylko Firewall Rule ID w Log Viewer lub Packet Capture pokazuje, która reguła przetwarza rzeczywisty przepływ. Testowanie reguły Sophos Firewall przedstawia prowadzoną procedurę.

Test pozytywny i negatywny

Kontrola tożsamości i dozwolonego przepływu

1. W sekcji Current activities > Live users wyszukać Printer-Accounting i oczekiwany adres IP.
2. Wygenerować z urządzenia dokładnie jeden przewidziany przepływ.
3. W Log Viewer porównać użytkownika, Source IP, Firewall Rule ID, nazwę reguły, usługę i akcję.
4. Sprawdzić, czy cel otrzymuje żądanie i czy działa droga powrotna.
5. Przetestować nieprzewidzianą usługę lub cel i potwierdzić oczekiwany drop.

Sam wpis w Live Users nie wystarcza. Potwierdza aktywne przypisanie, ale nie pozycję reguły, dozwoloną usługę ani ścieżkę danych.

Zmiana statusu jako test negatywny

Clientless User nie powinien być wylogowywany za pomocą Disconnect w Live Users. W sekcji Authentication > Clientless users należy wybrać użytkownika pilotażowego i za pomocą Change status ustawić go jako Inactive.

Następnie użytkownik nie może już pojawiać się jako Clientless User w Live Users. Nowe połączenie testowe nie może już pasować z tą tożsamością do pilotażowej reguły opartej na użytkowniku. Potem należy ponownie ustawić użytkownika jako Active i powtórzyć test pozytywny.

Test nie może spowodować nieoczekiwanego allow przez bardziej ogólną regułę. Jeśli połączenie ma pozostać dozwolone po dezaktywacji, przewidziana reguła fallback musi zostać świadomie udokumentowana i również przetestowana.

Systematyczne rozwiązywanie problemów

Brak użytkownika w Live Users

• Sprawdzić, czy status w Authentication > Clientless users to Active.
• Porównać skonfigurowany adres IP ze źródłem rzeczywiście widocznym w pakiecie.
• Poszukać zduplikowanego Username lub już używanego adresu IP.
• Oddzielnie analizować ruch IPv4 i IPv6.
• Przy dużej liczbie obiektów użytkowników i grup sprawdzić konkretną wewnętrzną User ID. Limit User ID nie jest diagnozowany na podstawie przybliżonej liczby obiektów.

Zgodnie z aktualną pomocą SFOS Clientless Users są widoczni w Live Users bezpośrednio po konfiguracji. Restart usługi, ingerencja w bazę danych lub wielokrotne usuwanie i ponowne tworzenie nie należą do normalnej procedury konfiguracji.

Użytkownik jest widoczny, ale pasuje niewłaściwa reguła

• Sprawdzić Match known users, wybranego użytkownika lub grupę oraz status reguły.
• Porównać Source zone, Source network, Destination zone, cel i usługę z rzeczywistym przepływem.
• Sprawdzić pozycję reguły i bardziej ogólną regułę znajdującą się powyżej.
• W Log Viewer nie filtrować tylko według nazwy użytkownika; porównać również Firewall Rule ID i Source IP.
• Utworzyć nowe połączenie, ponieważ istniejące sesje nie są automatycznie oceniane ponownie.

Reguła firewalla nie pasuje przedstawia pogłębioną logikę diagnostyczną.

Niewłaściwe urządzenie otrzymuje tożsamość

Przypisanie IP nie jest wystarczająco kontrolowane. Należy sprawdzić lease DHCP, rezerwację, konfigurację statyczną, zduplikowany adres IP, NAT i proxy. Regułę należy wyłączyć lub ustawić Clientless User jako Inactive, dopóki nie będzie jasne, które urządzenie używa adresu źródłowego.

Nie należy tworzyć większego zakresu w celu przechwycenia zmiennych adresów. Rozszerza to błędne założenie zaufania i utrudnia późniejsze przypisanie.

QoS nie działa przy dużej liczbie Clientless Users

Sophos dokumentuje NC-148705 jako rozwiązany w SFOS 22.0 MR1 Build 490: QoS Policy nie była stosowana przy liczbie ponad 3000 Clientless Users. Informacje o wydaniu nie podają zakresu wersji, których dotyczył problem.

Jeśli objaw dokładnie pasuje, należy zapisać wersję i build firmware oraz zaplanować wspieraną aktualizację co najmniej do MR1 Build 490 lub późniejszej zgodnej wersji. Problem QoS przy mniejszej liczbie użytkowników lub w innym buildzie nie potwierdza NC-148705; należy normalnie sprawdzić przypisanie policy, dopasowanie reguły i Traffic Shaping.

Interpretacja logów i HA

access_server.log zawiera zdarzenia uwierzytelniania, autoryzacji i accountingu. Dla przepływu danych decydujące pozostają log firewalla, Log Viewer i Packet Capture. Logi usług Sophos Firewall wyjaśniają przypisanie logów.

W klastrze HA konfiguracja i obsługa odbywają się na aktualnym urządzeniu Primary. Sophos nie gwarantuje, że stany Live Users lub sesji Clientless Users przetrwają failover bez przerwy. Po kontrolowanym failoverze należy ponownie sprawdzić Clientless User, dopasowanie reguły, rzeczywisty przepływ i lokalne logi węzła, który przetworzył zdarzenie.

Eksploatacja i rollback

Każdy Clientless User wymaga właściciela, celu i daty przeglądu. Po wymianie urządzenia, zmianie sieci lub wycofaniu reguły przypisanie nie powinno pozostać bez kontroli.

Kontrolowany rollback:

1. Udokumentować powiązaną regułę, grupę, raporty i zależności Traffic Shaping.
2. Ustawić Clientless User jako Inactive.
3. Negatywnie sprawdzić stan Live Users i rzeczywisty przepływ danych.
4. Zmienić regułę lub warunek użytkownika na przewidziany stan docelowy.
5. Usunąć Clientless User, gdy nie jest już potrzebny.
6. Usunąć grupę dopiero wtedy, gdy żaden inny użytkownik ani policy jej nie potrzebuje.
7. Osobno usunąć rezerwację DHCP, obiekt hosta i dokumentację.

Nie należy usuwać tożsamości produkcyjnej podczas trwającego incydentu przed zabezpieczeniem Source IP, Rule ID i logów. Jeśli przypisanie jest niejasne, najpierw należy ograniczyć dostęp i zachować materiał dowodowy.

FAQ