Konfiguracja SATC Sophos Firewall dla Remote Desktop Services

Sophos Authentication for Thin Client, w skrócie SATC, pomaga przy regułach użytkowników dla Remote Desktop Services. Jest to ważne zawsze wtedy, gdy wielu użytkowników korzysta z sieci lub internetu przez ten sam Windows Remote Desktop Session Host. Klasyczne STAS w takich przypadkach często widzi tylko adres IP terminal servera. SATC przekazuje natomiast do Sophos Firewall informacje o użytkownikach z poszczególnych sesji RDS.

Ten artykuł wyjaśnia, kiedy SATC ma sens, jakie są ograniczenia, jak aktywować SATC przez Sophos Server Protection i jak potem sprawdzić, czy użytkownicy poprawnie pojawiają się w Sophos Firewall.

Dla zwykłych klientów Windows najpierw istotna jest instrukcja Konfiguracja STAS na Sophos Firewall. SATC nie zastępuje STAS w każdym środowisku, lecz jest właściwym elementem dla Remote Desktop Services.

Kiedy SATC ma sens

SATC pasuje, gdy użytkownicy nie przechodzą przez firewall bezpośrednio z własnego klienta, lecz używają aplikacji lub przeglądarki na Remote Desktop Session Host.

Typowe scenariusze:

• Remote Desktop Services z wieloma jednoczesnymi użytkownikami
• terminal servery, na których użytkownicy potrzebują dostępu do WWW lub aplikacji
• reguły firewalla oparte na użytkownikach dla użytkowników RDS
• reporting, w którym ma być widoczny nie tylko adres IP serwera RDS
• środowiska, w których STAS nie wystarcza czysto z powodu wspólnego źródłowego IP

SATC nie jest właściwym punktem startowym dla zwykłych klientów domenowych, użytkowników VPN ani czystych scenariuszy Captive Portal. Tam należy najpierw poprawnie dobrać model uwierzytelniania: STAS, Captive Portal, uwierzytelnianie VPN, RADIUS albo Microsoft Entra ID SSO.

Czyste rozdzielenie STAS i SATC

Najważniejsza różnica dotyczy przypisania IP.

Jeśli terminal server zostanie błędnie odwzorowany przez STAS lub Clientless User, szybko powstają fałszywe oczekiwania. Reguła wydaje się oparta na użytkowniku, ale firewall faktycznie widzi tylko współdzielony adres IP serwera. SATC rozwiązuje dokładnie ten problem, wymaga jednak własnej konfiguracji na Windows Server i na firewallu.

Wymagania

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

• Sophos Server Protection może być użyty na Remote Desktop Session Host.
• Windows Server działa jako Remote Desktop Session Host.
• Używany jest Windows Server 2016 lub nowszy.
• Sophos Firewall jest osiągalny.
• Active Directory jest podłączony do Sophos Firewall.
• Wymagane grupy AD są zaimportowane na firewallu.
• Client Authentication jest dozwolone w Device Access dla strefy serwera RDS.
• Reguły firewalla mogą później pracować z Match known users.
• Istnieje okno konserwacyjne na zmianę Registry i restart serwera RDS.

Podłączenie AD nie powinno powstawać przy okazji. Jeśli AD nie jest jeszcze poprawnie skonfigurowany, najpierw należy sprawdzić Połączenie Active Directory z Sophos Firewall.

Ważne ograniczenia

SATC ma kilka ograniczeń, które należy znać przed rolloutem:

Szczególnie ostatni punkt jest ważny. Nie należy testowo wpisywać produkcyjnych adresów IP terminal serverów bez zrozumienia reguł i drogi powrotnej. Gdy IP jest traktowane jako źródło SATC, zmieniają się oczekiwania wobec przypisania użytkowników i matchowania reguł.

Przebieg w skrócie

Techniczny przebieg składa się z pięciu części:

1. Zainstalować Sophos Server Protection na serwerze RDS.
2. Aktywować SATC przez Registry na serwerze RDS.
3. Dodać IP serwera RDS w Device Console Sophos Firewall.
4. Sprawdzić serwer AD, grupy i kolejność uwierzytelniania na firewallu.
5. Zweryfikować Device Access, regułę firewalla i Live Users.

SATC należy nie tylko zainstalować, lecz także przetestować. Pomyślna instalacja na serwerze nie dowodzi jeszcze, że firewall później zobaczy właściwego użytkownika w właściwej regule.

Instalacja Sophos Server Protection

Instalacja odbywa się przez Sophos Central.

Postępowanie:

1. Zaloguj się do Sophos Central.
2. Otwórz Protect Devices.
3. W obszarze Server Protection pobierz Windows Server Installer.
4. Zainstaluj installer na Remote Desktop Session Host.
5. Sprawdź, czy serwer poprawnie pojawia się w Sophos Central.
6. Ustal okno konserwacyjne dla aktywacji SATC.

To, które installery są widoczne, zależy od posiadanych licencji Sophos. Jeśli Sophos Server Protection już działa na serwerze, mimo to należy sprawdzić, czy agent jest aktualny oraz czy Tamper Protection można kontrolowanie dezaktywować i potem ponownie aktywować.

Aktywacja SATC przez Registry

SATC jest sterowany na serwerze RDS przez wartości Registry pod tą ścieżką:

HKLM\Software\Sophos\Sophos Network Threat Protection\Application

Przed zmianą należy udokumentować aktualne ustawienia. Jeśli na serwerze aktywne jest Tamper Protection, trzeba je dla zmiany kontrolowanie dezaktywować i potem ponownie aktywować.

Podstawową konfigurację można ustawić w administracyjnym wierszu polecenia:

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SendSatcEvents /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationAddr /t REG_SZ /d FIREWALL-IP /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationPort /t REG_DWORD /d 6060 /f

FIREWALL-IP zastępuje się adresem IP Sophos Firewall, do którego serwer RDS ma wysyłać informacje SATC. Port standardowy to 6060.

Następnie:

1. Ponownie aktywować Tamper Protection.
2. Zrestartować serwer RDS.
3. Po restarcie sprawdzić, czy usługa Sophos działa.
4. Dopiero potem kontynuować konfigurację firewalla i testy.

Wykluczenie kont lokalnych i celów

Domyślnie również lokalne konta, takie jak SYSTEM lub Administrator, mogą generować zdarzenia SATC. Dla reguł użytkowników zwykle nie jest to pomocne i może niepotrzebnie zanieczyścić logi.

Za pomocą SatcExcludedUsers można wykluczyć użytkowników. Wpisy są case-sensitive.

Przykład:

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcExcludedUsers /t REG_MULTI_SZ /d "SYSTEM\0Administrator" /f

Za pomocą SatcExcludedAddresses można wykluczyć cele, dla których informacje SATC nie mają być wysyłane do firewalla. Może to mieć sens dla lokalnych celów zarządzania, aktualizacji lub infrastruktury, ale powinno być świadomie udokumentowane.

Możliwe formaty:

192.0.2.10
192.0.2.10:443
*:443

Wyjątki powinny być utrzymane wąsko. Jeśli wykluczy się zbyt szerokie cele, firewall zobaczy później mniej kontekstu użytkownika, niż oczekiwano.

Dodanie serwera RDS na firewallu

Firewall musi wiedzieć, które serwery dostarczają informacje SATC. Robi się to w Device Console, nie w Advanced Shell.

Postępowanie:

1. Zaloguj się na Sophos Firewall przez konsolę lub SSH.
2. Otwórz opcję 4. Device Console.
3. Dodaj IP serwera RDS:

system auth thin-client add citrix-ip <RDS-SERVER-IP>

<RDS-SERVER-IP> zastępuje się adresem IP Remote Desktop Session Host.

Jeśli istnieje kilka serwerów RDS, każdy serwer należy dodać pojedynczo i udokumentować. Potem powinno być jasne:

• które serwery są źródłami SATC
• jakiej strefy używają te serwery
• które reguły firewalla analizują użytkowników z tych serwerów
• kto zatwierdza zmiany na liście serwerów RDS

Sprawdzenie Active Directory i grup

SATC dostarcza informacje o użytkownikach. Aby firewall mógł używać tych informacji w regułach, musi zgadzać się podłączenie AD i grupy.

Sprawdzić:

1. Otwórz Authentication > Servers.
2. Sprawdź serwer AD przez Test connection.
3. Skontroluj import grup.
4. Otwórz Authentication > Groups.
5. Wyszukaj właściwe grupy.
6. Otwórz Authentication > Services.
7. Sprawdź serwer AD we właściwej kolejności firewall authentication methods.

Jeśli użytkownicy pojawiają się w obszarze Live Users, ale reguły nie działają, przyczyna często nie leży w samym SATC, lecz w imporcie grup, grupie domyślnej, kryterium reguły lub pozycji reguły.

Ustawienie Device Access i reguły firewalla

Aby firewall przyjmował Client Authentication ze strefy serwera, Client Authentication musi być dozwolone dla tej strefy.

Ścieżka:

Administration > Device access

W obszarze Client Authentication aktywuje się strefę serwera RDS. Nie należy przy tym ślepo otwierać WAN ani szerokiej, niebezpiecznej strefy. Device Access steruje lokalnymi usługami firewalla i należy do utwardzania zarządzania.

Następnie właściwy ruch potrzebuje reguły firewalla.

Typowy przebieg:

1. Otwórz Rules and policies > Firewall rules.
2. Utwórz odpowiednią regułę dla ruchu z serwera RDS albo ze strefy serwerowej.
3. Ustaw właściwie Source zone i Destination zone.
4. Aktywuj Match known users.
5. Wybierz wymaganych użytkowników AD lub grupy AD.
6. Aktywuj logging, aby test był później możliwy do odtworzenia.
7. Zapisz regułę.
8. Wygeneruj ruch testowy z sesji RDS.

Logging jest ważny dla późniejszej analizy błędów. Jeśli reguła użytkownika zostanie utworzona bez loggingu, trudniej rozpoznać, czy problemem jest SATC, matchowanie grup, kolejność reguł czy inna ścieżka.

Walidacja po konfiguracji

Po konfiguracji nie należy sprawdzać tylko, czy użytkownik ma dostęp do internetu. Decydujące jest, czy firewall widzi właściwego użytkownika i czy matchuje właściwą regułę.

Praktyczny test:

1. Zaloguj użytkownika do sesji RDS.
2. Wygeneruj zdefiniowany ruch testowy, na przykład dozwolone połączenie HTTPS.
3. W Sophos Firewall otwórz Current activities > Live users.
4. Sprawdź, czy użytkownik pojawia się z Client type Thin client.
5. Skontroluj adres IP serwera RDS i przypisanie sesji.
6. Otwórz Log Viewer.
7. Filtruj według Source IP serwera RDS, użytkownika i reguły.
8. Sprawdź, czy działa oczekiwana reguła oparta na użytkowniku.

Jeśli ruch nie działa zgodnie z oczekiwaniem, pomaga dodatkowo Testowanie reguły firewalla przy użyciu Log Viewer, Policy Test i Packet Capture. Jeśli użytkownicy są widoczni, ale grupy lub pojedynczy użytkownicy nie matchują, następną ścieżką kontroli jest Reguła Sophos Firewall nie matchuje.

Troubleshooting

Brak widocznego Thin Client User

Sprawdzić:

• serwer RDS został zrestartowany po zmianie Registry.
• SendSatcEvents jest ustawione i różne od 0.
• SatcDestinationAddr wskazuje właściwy adres IP firewalla.
• SatcDestinationPort pasuje do oczekiwanego portu.
• ścieżka sieciowa od serwera RDS do firewalla jest otwarta.
• IP serwera RDS zostało dodane na firewallu przez system auth thin-client add citrix-ip.
• strefa serwera RDS pozwala na Client Authentication w Device Access.

Użytkownik się pojawia, ale reguła nie matchuje

Sprawdzić:

• użytkownik lub grupa jest zaimportowana na firewallu.
• reguła używa Match known users.
• w regule wybrana jest właściwa grupa AD.
• pozycja reguły jest właściwa.
• nie ma wcześniejszej reguły, która matchuje ten sam ruch bez kontekstu użytkownika.
• Log Viewer pokazuje tego samego użytkownika, tę samą Source IP i tę samą usługę.

Lokalne konta pojawiają się w logach

Sprawdzić SatcExcludedUsers i dodać konta techniczne. Częstymi kandydatami są lokalni administratorzy, usługi i konta systemowe. Lista nie powinna jednak stać się tak szeroka, aby przypadkowo wykluczać prawdziwych użytkowników.

Pojedyncze cele nie otrzymują kontekstu użytkownika

Sprawdzić SatcExcludedAddresses. Jeśli cel lub port został wykluczony, SATC nie wysyła dla niego informacji uwierzytelniających do firewalla. Może to być zamierzone, ale przy regułach użytkowników łatwo prowadzi do zamieszania.

Po wpisaniu IP serwera stary Clientless User już nie działa

To jest oczekiwane. Jeśli IP serwera RDS zostało zapisane na firewallu jako Thin Client Server, SATC powinien być modelem uwierzytelniania dla tego IP. Stare obejścia z Clientless Users powinny zostać usunięte albo świadomie zastąpione.

Eksploatacja i dokumentacja

SATC należy utrzymywać jak produkcyjny element uwierzytelniania, a nie jak jednorazowy hack w Registry.

Udokumentować:

• serwery RDS i adresy IP
• używany adres IP firewalla i port SATC
• ustawione wartości Registry
• wykluczonych użytkowników i cele
• dotknięte reguły firewalla
• grupy AD i ownerów
• użytkownika testowego i oczekiwany match reguły
• okno konserwacyjne i czas restartu

Po aktualizacjach Sophos Server Protection, Windows Server, Sophos Firewall lub AD należy celowo sprawdzić SATC z użytkownikiem testowym. Uwierzytelnianie często zwraca uwagę dopiero wtedy, gdy reguły użytkowników nagle działają zbyt szeroko albo wcale.

Checklista

• Scenariusz RDS rzeczywiście pasuje do SATC, a nie do zwykłego STAS.
• Sophos Server Protection jest zainstalowany na Remote Desktop Session Host.
• Wersja Windows Server i rola RDS są sprawdzone.
• Tamper Protection została tylko kontrolowanie dezaktywowana i potem ponownie aktywowana.
• SendSatcEvents, SatcDestinationAddr i SatcDestinationPort są ustawione.
• Serwer RDS został zrestartowany.
• IP serwera RDS zostało dodane w Device Console na firewallu.
• Serwer AD i grupy AD są sprawdzone na firewallu.
• Client Authentication jest dozwolone dla właściwej strefy w Device Access.
• Reguła firewalla używa Match known users i ma aktywny logging.
• Użytkownik pojawia się w Current activities > Live users z Client type Thin client.
• Log Viewer pokazuje oczekiwanego użytkownika i oczekiwaną regułę.

FAQ