STAS na Sophos Firewall: konfiguracja

STAS oznacza Sophos Transparent Authentication Suite. Funkcja przypisuje logowania Windows z Active Directory do adresu IP klienta, aby Sophos Firewall mógł używać użytkowników i grup w regułach firewall bez osobnego logowania użytkowników w przeglądarce lub portalu.

W klasycznych domenach Windows nadal jest to przydatne. Jednocześnie STAS nie jest uniwersalnym SSO. Przypisanie działa niezawodnie tylko wtedy, gdy firewall widzi rzeczywisty adres IP klienta, Domain Controllers zapisują odpowiednie zdarzenia logowania, a konta techniczne są poprawnie wykluczone. Dla środowisk RDS, Terminal Server lub Citrix zwykle potrzebny jest inny projekt, na przykład SATC.

Kiedy STAS ma sens

STAS pasuje przede wszystkim do środowisk ze zwykłymi klientami Windows w domenie Active Directory. Typowe cele to:

• reguły firewall z użytkownikami AD lub grupami AD
• reporting z odniesieniem do użytkownika zamiast tylko adresów IP
• transparentne przypisanie użytkowników bez Captive Portal
• reguły Internetu dla wewnętrznych sieci klienckich
• uzupełniające uwierzytelnianie w środowiskach bez projektu Entra-ID-SSO

STAS jest mniej odpowiedni, gdy wielu użytkowników używa tego samego adresu źródłowego. Dotyczy to na przykład Remote Desktop Server, Terminal Server, Citrix Server lub systemów z NAT między klientem a firewallem. W takich przypadkach należy wcześnie sprawdzić, czy Sophos Authentication for Thin Client (SATC) albo inny model uwierzytelniania pasuje lepiej.

Instrukcja wideo

Poniższe Sophos-Techvids pokazują konfigurację STAS wizualnie. Filmy zostały przygotowane dla SFOS v21, ale nadal pomagają zrozumieć zasadę działania, architekturę i najważniejsze kroki konfiguracji. Pojedyncze ekrany w SFOS 22 mogą wyglądać nieco inaczej.

Zasada działania

STAS składa się z dwóch komponentów:

Typowy przebieg:

1. Użytkownik loguje się na kliencie Windows.
2. Active Directory zapisuje pasujące Security Event.
3. STA Agent odczytuje to zdarzenie.
4. STA Collector otrzymuje użytkownika, adres IP klienta i informację o domenie.
5. Sophos Firewall aktualizuje Live Users.
6. Reguły firewall mogą oceniać użytkowników lub grupy.

Dodatkowo Collector może sprawdzać klientów przez WMI lub Registry Read Access. To Workstation Polling pomaga przypisać adres IP do użytkownika albo skorygować nieaktualne wpisy. Muszą jednak pasować Windows Firewall, usługi, uprawnienia i ścieżki sieciowe.

Wymagania

Przed instalacją należy wyjaśnić te punkty:

• Sophos Firewall działa w trybie Gateway.
• Active Directory jest już podłączone do firewalla.
• Domain Controllers zapisują wymagane zdarzenia logowania.
• Klienci Windows są członkami domeny.
• Między klientami, Collectorem i Sophos Firewall nie ma NAT.
• Client Authentication jest dozwolone pod Device Access dla właściwych stref.
• DNS, czas, routing i reguły firewall między zaangażowanymi systemami są poprawne.
• Konto serwisowe i proces zmiany hasła są zdefiniowane.
• Konta techniczne do Exclusions są znane.

STAS 2.5 i nowszy obsługuje według oficjalnej dokumentacji Windows Server 2008 R2, 2012 R2, 2016, 2019, 2022 i 2025. Przy nowych instalacjach i tak nie należy już planować starych generacji serwerów. Ważne jest przede wszystkim to, że STAS może działać bezpośrednio na Domain Controller albo od STAS 2.5 również na Member Server. Przy projektach z Member Server trzeba szczególnie dokładnie sprawdzić, czy dostęp do Event Log, WMI/Registry i ścieżki sieciowe rzeczywiście działają.

Sama integracja AD jest opisana w artykule Połączenie Active Directory z Sophos Firewall. STAS nie powinien być traktowany jako zastępstwo dla poprawnej konfiguracji serwera AD.

Jeżeli przez lata na firewallu powstaje bardzo wielu użytkowników i grup, należy dodatkowo pamiętać o limicie User ID na Sophos Firewall. Jest to szczególnie istotne, gdy funkcje portalu lub VPN zawodzą tylko dla pojedynczych użytkowników.

Planowanie architektury

W małych środowiskach Agent i Collector mogą działać na tym samym Domain Controller. To proste, ale nie zawsze jest najlepszym wariantem operacyjnym.

W większych środowiskach często czyściej jest zastosować:

• STA Agent na każdym istotnym Domain Controller
• jeden lub dwa STA Collectors na osobnych systemach Windows
• grupy Collector per domena AD
• jasną Exclusion List dla kont technicznych
• zdefiniowane reguły firewall i zezwolenia Device Access
• monitoring usług, Event Logs i przypisania Live Users

Kluczowy jest widok adresów IP. STAS przypisuje użytkownika do adresu IP. Jeżeli proxy, NAT, Terminal Server albo VPN-Gateway ukrywa rzeczywisty adres IP klienta, firewall nie może niezawodnie używać tego przypisania.

Przygotowanie Active Directory

STAS mocno zależy od tego, czy w Security Event Log istnieją właściwe zdarzenia logowania. Poniższe ustawienia trzeba sprawdzić na każdym Domain Controller, na którym używany będzie STA Agent.

Dodatkowo przed instalacją warto zanotować NetBIOS name, FQDN i Search DN domeny. Te wartości będą później potrzebne w konfiguracji Sophos Firewall i STAS.

Włączyć Audit account logon events

Na Domain Controller otworzyć Local Security Policy. Można to zrobić na przykład przez secpol.msc.

Następnie otworzyć ścieżkę:

Security Settings > Local Policies > Audit Policy

Tam otworzyć Audit account logon events.

Następnie włączyć Success i Failure oraz zapisać zmianę.

Przygotować konto STAS

Usługa STAS powinna działać na udokumentowanym koncie. W prostych środowiskach testowych często używa się konta administratora. W środowiskach produkcyjnych lepsze jest dedykowane konto STAS, o ile wymagane uprawnienia są poprawnie ustawione i przetestowane.

Konto musi, zależnie od projektu:

• móc uruchamiać usługę
• móc czytać istotne Event Logs
• przy WMI lub Registry Read Access mieć dostęp do klientów
• przetrwać planowe zmiany hasła
• być jednoznacznie rozpoznawalne w monitoringu i dokumentacji

Konto nie musi koniecznie być Domain Admin. Dla Domain Controller ważne są co najmniej właściwe uprawnienia grupowe i plikowe. W praktyce należy sprawdzić:

• członkostwo w Domain Users
• członkostwo w Event Log Readers
• prawa odczytu i zapisu do C:\Program Files (x86)\Sophos\Sophos Transparent Authentication Suite\
• przy WMI-Polling odpowiednie prawa na endpointach, na przykład Remote Desktop Users, Distributed COM Users oraz uprawnienia WMI na Root\CIMV2 z Execute Methods i Remote Enable

W większych środowiskach takie uprawnienia endpointów łatwiej rozdzielać przez Group Policy. Jeżeli Workstation Polling nie jest używany, nie należy przyznawać niepotrzebnie szerokich uprawnień.

Jeżeli usługa działa z własnym kontem, konto musi otrzymać Log on as a service.

Ścieżka w Local Security Policy:

Security Settings > Local Policies > User Rights Assignment

Następnie dodać konto.

Sprawdzenie portów i usług

Między Sophos Firewall, STA Collector, STA Agent, Domain Controller i klientami muszą być możliwe wymagane połączenia. Podstawą są:

Dodatkowe porty zależą od aktywnych metod:

Jeżeli Windows Firewall jest aktywny na klientach lub serwerach, reguły należy zawęzić do Collectora. Przykładowy szablon dla WMI:

New-NetFirewallRule -DisplayName "Sophos STAS Collector WMI" -Direction Inbound -RemoteAddress 10.10.10.10 -Action Allow -Profile Domain

To polecenie jest tylko szablonem. W środowiskach produkcyjnych adres źródłowy, porty docelowe, profile i Group Policy muszą pasować do wybranej metody Polling.

Dodanie Active Directory na firewallu

Przed aktywacją STAS Sophos Firewall musi znać serwer Active Directory.

W WebAdmin:

Authentication > Servers

Tam dodać serwer Active Directory albo sprawdzić istniejącą konfigurację.

Poszczególne pola są wyjaśnione w artykule Połączenie Active Directory z Sophos Firewall. Dla STAS szczególnie ważne są domena NetBIOS, nazwa domeny, baza wyszukiwania i rozpoznawanie grup.

Pobranie i instalacja STAS

Instalacja STAS jest udostępniana przez Sophos Firewall.

W WebAdmin:

Authentication > Client downloads

Pod Single Sign-on znajduje się Sophos Transparent Authentication Suite (STAS).

Pobraną STAS.exe uruchomić jako administrator na przewidzianym systemie Windows.

Typowe warianty instalacji:

Przy wielu Domain Controllers zwykle potrzebny jest STA Agent na każdym istotnym Domain Controller. Jeden Collector może zbierać informacje od wielu Agents.

Konfiguracja STAS

Po instalacji konfiguruje się STA Suite. Najważniejsze obszary to General, STA Agent, STA Collector i Exclusion List.

General

W zakładce General sprawdza się przede wszystkim konto serwisowe, dane domeny, NetBIOS name i FQDN.

Jeżeli w tym miejscu stoją błędne wartości domeny, instalacja później często wygląda zdrowo, ale użytkownicy lub grupy nie są prawidłowo przypisywani. NetBIOS name musi być wpisany w STAS wielkimi literami.

STA Agent

W zakładce STA Agent decydujące są te punkty:

• STA Agent Mode: Dla lokalnego wykrywania Event Log typowym punktem startu jest EVENTLOG.
• Specify the networks to be monitored: wpisać sieci klienckie, w których STAS ma rozpoznawać użytkowników.
• Domain Controller IP: ustawiać tylko wtedy, gdy Agent nie działa bezpośrednio na Domain Controller. Jeżeli SSO Suite jest zainstalowany na Domain Controller, to pole zwykle pozostaje puste.
• Collector List: wpisać adresy IP systemów Collector.

Monitorowane sieci należy wybierać świadomie. Sieci serwerowe, zarządzające lub sieci bez normalnych stacji roboczych użytkowników w przeciwnym razie generują zbędne błędy albo fałszywe oczekiwania.

STA Collector

W zakładce STA Collector wpisuje się Sophos Firewall i planuje Client Polling.

Ważne punkty:

• Sophos Appliance: wpisać adres IP Sophos Firewall.
• Workstation Polling Method: świadomie wybrać WMI albo Registry Read Access.
• Enable Logoff Detection: włączać tylko wtedy, gdy Ping i timeouty pasują do sieci klientów.
• Dead entry timeout: przetestować wartość pasującą do wersji STAS i modelu pracy.

W klastrach HA należy używać osiągalnego wewnętrznego adresu firewalla, który pasuje do ruchu STAS. Osobne adresy administracyjne peerów najczęściej nie są właściwym celem.

Exclusion List

Exclusion List zapobiega temu, aby konta techniczne nadpisywały normalne przypisania użytkowników. To jeden z najważniejszych obszarów operacyjnych STAS.

Typowe wpisy:

• konta serwisowe backupu, monitoringu, dystrybucji oprogramowania lub narzędzi endpoint
• konta administracyjne i instalacyjne
• konta, które logują się w tle na wielu klientach
• serwery lub systemy, na których nie oczekuje się użytkowników stacji roboczych

Bez Exclusion List prawdziwy użytkownik może zniknąć z Live Users, ponieważ krótko po nim na tym samym kliencie rozpoznano konto usługi. Później wygląda to jak problem reguły firewall, choć przyczyna leży w przypisaniu uwierzytelniania.

Grupy Collector i redundancja

W małych środowiskach często wystarcza jeden Collector. W większych środowiskach należy świadomie planować grupy Collector.

Sprawdzone zasady:

• Używać odpowiedniej grupy Collector dla każdej domeny AD.
• Zaplanować co najmniej dwa Collectors, jeśli reguły użytkowników są krytyczne.
• Skonfigurować STA Agents ze wszystkimi przewidzianymi Collectors.
• Przetestować firewall i Collectors w obu kierunkach.
• Nie umieszczać Collectors na systemach, które są często restartowane.

STA Agent może obsługiwać wielu Collectors. STA Collector może również obsługiwać wiele Sophos Firewalls. Mimo to przypisanie powinno być udokumentowane, inaczej troubleshooting później niepotrzebnie się komplikuje.

Na firewallu Collector jest wpisywany z Collector IP, Collector port i Collector group. Na jedną grupę Collector możliwych jest maksymalnie pięć Collectors. Kolejność w grupie jest ważna: pierwszy Collector jest primary, kolejne Collectors służą jako backup. Collectors tej samej domeny należą do tej samej grupy Collector. Dla subdomen lub oddzielnych domen AD należy używać własnych grup Collector.

Aktywacja STAS na Sophos Firewall

Gdy Agent, Collector, AD i sieć są przygotowane, STAS aktywuje się na firewallu.

W WebAdmin:

Authentication > STAS

Aktywować STAS i wpisać Collector albo grupę Collector.

Jeżeli konfiguracja działa, użytkownicy pojawiają się w dashboardzie i w obszarze Live Users.

Jeżeli nie pojawiają się tam użytkownicy, najpierw należy sprawdzić AD Events, Agent, Collector, Device Access i porty. Reguły firewall są dopiero następnym krokiem.

Ważne opcje STAS na firewallu

Pod Authentication > STAS znajduje się kilka opcji, które należy ustawiać świadomie.

Tworzenie reguły firewall z odniesieniem do użytkownika

Gdy STAS stabilnie rozpoznaje użytkowników, można używać reguł firewall z użytkownikami lub grupami z Active Directory.

Ważne:

• Sprawdzić regułę z prawdziwą grupą testową.
• Włączyć Log firewall traffic, jeśli reguła ma być później analizowana.
• Skontrolować pozycję reguły.
• Unikać reguł fallback, które ukrywają błędy uwierzytelniania.
• Sprawdzać Live Users i Log Viewer razem.

Do analizy reguł pasuje Testowanie reguły firewall za pomocą Log Viewer, Policy Test i Packet Capture.

Walidacja po konfiguracji

Zielony status usługi nie wystarcza. Po konfiguracji trzeba przetestować cały łańcuch.

Praktyczny przebieg:

1. Zalogować użytkownika testowego na kliencie domenowym.
2. Sprawdzić Security Event na Domain Controller.
3. Sprawdzić status STA Agent.
4. Sprawdzić status STA Collector i rozpoznanych użytkowników.
5. Sprawdzić Live Users na Sophos Firewall.
6. Przetestować regułę firewall opartą na użytkowniku z logowaniem.
7. Przetestować logoff lub zmianę użytkownika.
8. Sprawdzić konta techniczne względem Exclusion List.

W samym STAS można pod Advanced > Show live users sprawdzić, których użytkowników Collector aktualnie zna. Na firewallu właściwym miejscem jest Current activities > Live users. Oba widoki powinny w czasie testu logicznie do siebie pasować.

Jeżeli STAS steruje regułami krytycznymi dla biznesu, test należy powtarzać po Windows Updates, zmianach Domain Controller, upgrade firewalla i zmianach hasła konta serwisowego.

Testy, logi i backup

STAS oferuje kilka lokalnych narzędzi testowych. Często są szybsze niż samo spojrzenie w Firewall Log Viewer.

Log STAS jest widoczny bezpośrednio w aplikacji STAS pod Advanced > View Log. Dodatkowo plik logu znajduje się na systemie Windows pod:

C:\Program Files (x86)\Sophos\Sophos Transparent Authentication Suite\stas.log

Przed większymi zmianami należy zabezpieczyć konfigurację STAS. Robi się to w aplikacji STAS pod Advanced > Backup / Restore > Backup Now. Kopia jest tworzona jako plik w formacie STAS_ConfigBackup_DD_MM_YYYY_THH_MM_SS.bkp. Do odtworzenia wybiera się plik .bkp pod Backup / Restore i wgrywa przez Upload and Restore.

Sprawdzenie STAS przed SFOS 22 MR1

STAS należy do funkcji, które przed Major Upgrade powinny być świadomie sprawdzone. W aktualnej liście Known Issues istnieje problem dotyczący SFOS 22.0 MR1, STAS i opcji Restrict client traffic during identity probe. Jeżeli ta opcja jest ustawiona na Yes, może zablokować upgrade do SFOS 22.0 MR1 albo po upgrade prowadzić do powtarzających się Identity Probes i przez to do czasowych przerw w ruchu. Ponieważ Yes jest wartością domyślną, nie należy zakładać, że dotyczy to tylko świadomie utwardzonych konfiguracji specjalnych.

Dla administratorów ważne jest: to nie jest zwykły problem konfiguracji STAS. Środowisko może działać przez lata, a mimo to zwrócić uwagę przy upgrade, ponieważ dotąd akceptowane ustawienie w połączeniu z SFOS 22.0 MR1 staje się krytyczne. Dlatego STAS należy uwzględnić w SFOS 22 Upgrade Check.

Przed upgrade do SFOS 22.0 MR1 lub nowszego sprawdzić:

• Czy STAS jest w ogóle aktywny?
• Czy reguły oparte na użytkownikach są używane produkcyjnie?
• Czy Restrict client traffic during identity probe jest aktywne?
• Czy istnieją już komunikaty o powtarzających się Identity Probes albo niewyjaśnionych krótkich przerwach w ruchu?
• Czy istnieje użytkownik testowy, którym można celowo sprawdzić STAS po upgrade?

Jeżeli dotknięta opcja jest aktywna, nie należy oceniać jej dopiero podczas okna serwisowego firmware. Lepszy jest osobny krótki test wcześniej: udokumentować zmianę, zalogować użytkownika testowego, sprawdzić Live Users, przetestować regułę opartą na użytkowniku i skontrolować Log Viewer. Jeśli STAS steruje regułami krytycznymi dla bezpieczeństwa, należy też wyjaśnić, czy potrzebna jest tymczasowa reguła fallback, aby użytkownicy nie zostali niekontrolowanie zablokowani.

Dla ścieżki upgrade do SFOS 22.0 MR1 praktyczna zasada brzmi: jeżeli STAS jest aktywny i Restrict client traffic during identity probe ma wartość Yes, należy przed upgrade ustawić opcję na No, a potem zweryfikować ją z prawdziwymi użytkownikami testowymi. Jeśli tej zmiany nie można przetestować wcześniej, przesunięcie upgrade jest często czystsze niż ryzykowne okno serwisowe. Na systemach SFOS 22.0 MR1 już dotkniętych problemem No jest również udokumentowaną mitigacją do czasu dostępności poprawionej wersji.

Po upgrade sprawdzić celowo:

1. Status STAS pod Authentication > STAS.
2. Live Users ze świeżym logowaniem domenowym.
3. Regułę firewall opartą na użytkowniku z logowaniem.
4. W Log Viewer, czy widoczna jest nazwa użytkownika, a nie tylko adres IP.
5. Powtarzające się efekty Identity Probe lub krótkie przerwy.

Jeżeli upgrade zostanie zablokowany przez komunikat STAS albo po upgrade wystąpią odtwarzalne przerwy, należy przygotować Sophos Support Case. Pomocne są wtedy screenshot komunikatu upgrade, aktualna konfiguracja STAS, wersja firmware, dotknięta reguła użytkownika i krótki przebieg testu.

Troubleshooting

Brak użytkowników w Live Users

Najpierw sprawdzić, czy Domain Controller zapisuje pasujące Security Events. Następnie sprawdzić STA Agent, STA Collector, porty i Device Access.

Typowe przyczyny:

• Audit Policy nie jest aktywna
• STA Agent nie działa albo czyta zły Domain Controller
• Collector jest nieosiągalny
• UDP 6060 lub 6677 jest zablokowany
• Client Authentication nie jest dozwolone w Device Access
• NAT ukrywa rzeczywisty adres IP klienta

Użytkownik jest przypisany błędnie

Wtedy często w grę wchodzą Exclusions, Workstation Polling albo konta techniczne. Sprawdzić, czy konta serwisowe, konta monitoringu lub konta instalacyjne nie nadpisują tego samego klienta.

Użytkownik znika zbyt szybko

Wtedy sprawdzić Logoff Detection, Dead Entry Timeout, osiągalność klienta i metodę Polling. Jeżeli klienci nie odpowiadają na Ping, WMI albo dostęp do Registry, wpisy mogą nieoczekiwanie znikać albo pozostawać nieaktualne.

Błędy DCOM albo STAS odpytuje niewłaściwe sieci

Jeśli po instalacji STAS w Windows Event Viewer pojawiają się błędy DCOM, takie jak Event ID 10009 lub 10028, przyczyną nie musi być reguła firewall. Często Collector próbuje sprawdzać przez WMI lub Registry Read Access klientów, którzy nie są osiągalni albo nie należą do monitorowanych sieci.

W takim przypadku należy zawęzić monitorowane sieci w STAS:

1. W aplikacji STAS otworzyć kartę STA Collector.
2. Pod Sophos appliances wybrać właściwą Sophos Firewall i otworzyć Edit.
3. Włączyć Enable subnet based filter.
4. Wpisać tylko sieci, które faktycznie mają być monitorowane.
5. W karcie STA Agent sprawdzić te same sieci klienckie pod Specify the networks to be monitored.
6. Zastosować zmiany i ponownie uruchomić STAS.

Zmniejsza to liczbę zbędnych zapytań WMI i zapobiega pojawianiu się użytkowników z niepasujących sieci jako LogonType: 1. Po zmianie należy wspólnie sprawdzić stas.log, Windows Event Viewer oraz Current activities > Live users.

Reguła firewall nie trafia

Wtedy nie patrzeć tylko na regułę. Sprawdzić:

• Czy użytkownik jest widoczny pod Live Users?
• Czy rozpoznawana jest właściwa grupa AD?
• Czy trafia wcześniejsza reguła firewall?
• Czy logging na regule jest aktywny?
• Czy Log Viewer widzi użytkownika, czy tylko adres IP?

Okres przejściowy dla ruchu nieuwierzytelnionego

Dla faz przejściowych firewall domyślnie dopuszcza przez krótki czas ruch nieuwierzytelniony. Wartość można sprawdzić lub dostosować przez Device Console:

system auth cta unauth-traffic drop-period

Nie należy zmieniać tego ustawienia w ciemno. Najpierw musi być jasne, czy problemem rzeczywiście jest okres przejściowy, czy błędne przypisanie STAS.

Jeżeli firewall widzi ruch z adresu IP, dla którego STAS nie zna jeszcze użytkownika, ten adres IP jest najpierw sprawdzany w trybie uczenia. W tej fazie ruch może być odrzucany. Jeżeli Collector nie odpowiada, firewall traktuje IP przez pewien czas jako nieuwierzytelnione. Dlatego od urządzeń spoza domeny nie należy oczekiwać, że STAS automatycznie pokryje je poprawnie. Dla takich systemów sensowniejsze mogą być Clientless Users albo własne reguły.

STAS przez VPN

STAS może być używany również w scenariuszu IPsec-VPN, gdy użytkownicy w zdalnej lokalizacji uwierzytelniają się wobec Domain Controller w lokalizacji głównej. Należy to jednak planować świadomie, ponieważ routing, adres źródłowy, STAS-Monitored-Networks i strefy firewall muszą do siebie pasować.

Wymagania dla takiego projektu:

• Połączenie IPsec jest aktywne i stabilne.
• Branch-Traffic jest routowany przez tunel.
• STAS i Active Directory są poprawnie skonfigurowane w lokalizacji głównej.
• Sieć oddziału jest wpisana w STAS jako monitorowana sieć.
• Branch-Firewall jest wpisany w konfiguracji STA Collector jako Sophos Appliance.
• Client Authentication jest dozwolone dla strefy VPN w Device Access.

Na firewallu w lokalizacji głównej trzeba dodać zdalną sieć dla STAS przez Device Console. Przykład:

system auth cta vpnzonenetwork add source-network 172.50.50.0 netmask 255.255.255.0

Przykład trzeba zastąpić rzeczywistą siecią oddziału. W wielu środowiskach prostsze i bardziej odporne jest mimo wszystko używanie STAS tylko dla lokalnych sieci klienckich i osobne zaprojektowanie zdalnych lokalizacji.

STAS, SATC i Remote Desktop Server

Klasyczny STAS działa dobrze, gdy jeden adres IP klienta typowo należy do jednego użytkownika. Na Remote Desktop Server, Terminal Server lub systemach Citrix wielu użytkowników współdzieli jednak ten sam adres IP. Wtedy klasyczny STAS nie może jednoznacznie rozróżniać użytkowników.

W takich środowiskach należy sprawdzić Sophos Authentication for Thin Client (SATC). SATC nie jest prostym przełącznikiem w STAS, lecz osobnym tematem projektowym:

• Które serwery są objęte?
• Którzy użytkownicy pracują przez te serwery?
• Które reguły firewall naprawdę muszą być oparte na użytkownikach?
• Czy istnieje mieszany ruch usług serwerowych i sesji użytkowników?
• Jak zachowanie jest testowane i dokumentowane?

Jeżeli Terminal Server są używane rzadko, sensowniejsze może być segmentowanie tych połączeń inaczej albo stosowanie osobnych reguł bez odniesienia do użytkownika. Decydujące jest to, aby uwierzytelnianie pasowało do rzeczywistej architektury sieci.

Lista kontrolna operacyjna

Przed instalacją:

• Serwer AD na Sophos Firewall działa.
• Sieci klienckie i Domain Controllers są udokumentowane.
• Żaden NAT nie ukrywa adresów IP klientów.
• Konto serwisowe i uprawnienia są zdefiniowane.
• Audit Policy jest aktywna na istotnych Domain Controllers.
• Exclusion List jest przygotowana.

Po instalacji:

• Agent i Collector działają.
• Porty między Agent, Collector, firewallem i klientami są otwarte.
• Live Users pokazują użytkowników testowych.
• Reguła firewall oparta na użytkowniku trafia w Log Viewer.
• Logoff, zmiana użytkownika i konta techniczne zostały przetestowane.
• Redundancja Collector jest udokumentowana, jeśli jest potrzebna.

W eksploatacji:

• Monitorować konto serwisowe.
• Regularnie utrzymywać Exclusion List.
• Uzgadniać zmiany Windows Firewall i GPO ze STAS.
• Regularnie uzgadniać subnet-based filter i monitorowane sieci z rzeczywistą strukturą klientów.
• Testować STAS po upgrade firewalla i Domain Controller.
• Przed SFOS 22.0 MR1 lub nowszym sprawdzić Restrict client traffic during identity probe.
• Przy RDS/Citrix nie improwizować ze STAS, lecz sprawdzić SATC albo inny projekt.

FAQ