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

Z wyprzedzeniem zaplanować przerwę w łączności: Przed użyciem Change status udokumentować aktualny status, powiązane reguły i plan przywrócenia poprzedniego stanu. Test negatywny przeprowadzać wyłącznie na kontrolowanym urządzeniu pilotażowym i w uzgodnionym oknie czasowym: dezaktywacja może przerwać potrzebne mu połączenia. Na potrzeby testu utworzyć nowe połączenie, a nie tylko obserwować już trwającą sesję. W razie nieoczekiwanego skutku przywrócić wcześniej udokumentowany status i ponownie sprawdzić pierwotne połączenie.

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. Ten przykład jest poddawany odbiorowi z użyciem IPv4. Przed wdrożeniem z użyciem IPv6 należy wyraźnie zweryfikować mapowanie Clientless oraz odpowiednią konfigurację reguł dla zainstalowanej wersji SFOS; pomyślny odbiór z użyciem IPv4 nie potwierdza działania z użyciem IPv6.

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 polityki grupy.
4. Zapisać za pomocą Save.

Polityki właściwe dla użytkownika mają pierwszeństwo przed politykami 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.

Dla Clientless Users niedostępne są również MAC binding, User type and profile oraz polityki VPN dostępu zdalnego. Tożsamość clientless oparta na adresie IP nie zapewnia więc ani powiązania z urządzeniem, ani uwierzytelnienia użytkownika VPN.

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.

Po zapisaniu za pomocą Save przejść do Authentication > Clientless users i otworzyć użytkownika za pomocą Edit. W sekcji Traffic shaping (quality of service) można wybrać istniejącą politykę lub utworzyć nową. Quarantine digest wysyła listę wiadomości e-mail zatrzymanych w kwarantannie do skrzynki użytkownika; dla urządzenia bez przypisanej skrzynki funkcja pozostaje wyłączona. Po zapisaniu ponownie sprawdzić faktycznie przypisane polityki użytkownika i grupy oraz przewidziany przepływ.

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.

Dla zatwierdzonego bloku w formularzu Add range wpisać pierwszy adres urządzenia w From IP, ostatni w To IP i wybrać przygotowaną grupę Clientless w Group. Przykład: zakres od 192.0.2.50 do 192.0.2.52 obejmuje trzy kontrolowane adresy urządzeń; oba adresy graniczne należy zastąpić adresami z własnego zarezerwowanego bloku. Zapisać za pomocą Save, a następnie w Authentication > Clientless users otworzyć każdego utworzonego użytkownika za pomocą Edit i sprawdzić adres IP, grupę oraz wymagane polityki indywidualne. Dla każdego urządzenia sprawdzić oczekiwane przypisanie w Live Users oraz przepływ dozwolony i niedozwolony; pomyślny test urządzenia pilotażowego nie zastępuje weryfikacji pozostałych wpisów.

Aby sprawdzić listę w Authentication > Clientless users, kliknąć Show additional properties i wybrać potrzebne pola. Ich kolejność można zmienić na liście rozwijanej przez przeciąganie i upuszczanie; zatwierdzić za pomocą Ok. Ten widok ułatwia porównanie wpisów, ale nie zastępuje otwarcia i sprawdzenia indywidualnej konfiguracji.

API XML: rozróżniać Add, Add range i Update

Powyższa procedura GUI nie jest przepisem na XML. Dokumentacja referencyjna API dla SFOS 22.0 i 23.0 pozostawia ważne pytania dotyczące reprezentacji Add i Update bez odpowiedzi:

• Add: Tabela oznacza Username, Group, Name i Email jako obowiązkowe i określa je, podobnie jak IP Address i Spam Digest, jako ARRAY. Przykład pokazuje jednak tylko jeden ClientlessUser z pojedynczymi wartościami, w tym UserName i ClientLessGroup. Nie potwierdza to ani bezpiecznego powiązania użytkowników, adresów IP, grup i adresów e-mail, ani wykonywalnej operacji zbiorczej. Informacja, że duplikaty nie będą ignorowane, nie wyjaśnia sposobu ich przetwarzania. Wpisywanie Email w GUI powyżej tylko w razie potrzeby nie znosi wymogu API; Add range to osobna procedura GUI, a nie dowód sposobu serializacji tablic. Przykład wyraźnie umieszcza <!--only for Edit --> przed QoSPolicy i Status; nie należy z tego wywodzić pól Add ani domyślnego statusu.
• Update: Username, Name, Group i IP Address mają teraz typ SCALAR, podczas gdy Email pozostaje obowiązkowym ARRAY. Tabela wymaga również Web Filter, App Filter i QOS; przykład nie pokazuje znaczników filtrów ani nie potwierdza powiązania QOS z QoSPolicy. Skopiowany przykład Add nie jest więc Update o potwierdzonej kompletności.
• Digest: Przykład wymienia także ApplyGroupSettings dla QuarantineDigest, lecz tabela Update dla Spam Digest podaje tylko Disable i Enable. Wartość domyślna brzmi dosłownie Disbale: to niespójna wartość w dokumentacji, a nie potwierdzona wartość domyślna podczas działania. Nie należy wywodzić z niej dziedziczenia ustawień grupy ani zachowania pominiętych pól; Add również nie podaje wartości domyślnej digestu.

Przed zmianami przez API zależnymi od tych szczegółów należy wyjaśnić kontrakt zainstalowanego buildu; dopóki reprezentacja jest niejasna, korzystać z obsługiwanej procedury GUI z Edit lub Change status. Przed zmianą zapisać rzeczywiste wcześniejsze wartości polityk, digestu i statusu. Następnie dokładnie porównać zapisaną tożsamość, adres IP, grupę i polityki oraz sprawdzić nowe przepływy dozwolone i blokowane. W razie nieoczekiwanego skutku przywrócić pierwotne wartości zamiast resetować do domniemanych wartości domyślnych i ponownie sprawdzić. Te ograniczenia dokumentacji nie podważają dziedziczenia ustawień grupy w GUI.

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 i sprawdzić jego aktualną Firewall Rule ID; już trwająca sesja nie wystarcza do tego testu.

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 polityki, 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. Nie zakłada się tutaj, że przejęcie mapowania Clientless bez przerw w działaniu jest gwarantowane. 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.

Przed resetem należy zachować wartości użycia: Po otwarciu użytkownika opcja View usage pokazuje zarejestrowane użycie Internetu. Reset user accounting zeruje te statystyki; aktualna pomoc Sophos mówi również o ponownym uruchomieniu Network Traffic Quota, ale na tej samej stronie oznacza Network traffic policy jako nieobsługiwaną dla Clientless Users. Resetu nie należy więc używać do naprawy limitu. Najpierw trzeba udokumentować liczniki i rzeczywiste przypisanie polityk. Indywidualne wartości Traffic shaping i Quarantine digest mają pierwszeństwo przed ustawieniami grupy Clientless.

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 polityka 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