Configurare Sophos Firewall SATC per Remote Desktop Services
Sophos Authentication for Thin Client, in breve SATC, aiuta con le regole utente su Remote Desktop Services. Questo è importante ogni volta che più utenti accedono alla rete o a Internet tramite lo stesso Windows Remote Desktop Session Host. In questi casi il classico STAS vede spesso solo l’indirizzo IP del terminal server. SATC fornisce invece alla Sophos Firewall informazioni utente dalle singole sessioni RDS.
Questo articolo spiega quando SATC è utile, quali limiti esistono, come attivare SATC tramite Sophos Server Protection e come verificare poi se gli utenti compaiono correttamente nella Sophos Firewall.
Per normali client Windows è rilevante prima Configurare STAS su Sophos Firewall. SATC non sostituisce STAS in ogni ambiente, ma è il componente adatto per Remote Desktop Services.
Quando SATC è utile
SATC è adatto quando gli utenti non passano attraverso il firewall direttamente dal proprio client, ma usano applicazioni o browser su un Remote Desktop Session Host.
Scenari tipici:
- Remote Desktop Services con più utenti simultanei
- terminal server su cui gli utenti hanno bisogno di accesso web o applicativo
- regole firewall basate su utente per utenti RDS
- reporting in cui non deve essere visibile solo l’indirizzo IP del server RDS
- ambienti in cui STAS non basta in modo pulito a causa dell’IP sorgente condiviso
SATC non è il punto di partenza giusto per normali client di dominio, utenti VPN o scenari puramente Captive Portal. In quei casi bisogna prima scegliere in modo pulito il modello di autenticazione: STAS, Captive Portal, autenticazione VPN, RADIUS o Microsoft Entra ID SSO.
Separare correttamente STAS e SATC
La differenza più importante è l’associazione IP.
| Scenario | Approccio adatto |
|---|---|
| Un client Windows appartiene di solito a un utente | STAS |
| Molti utenti condividono lo stesso IP del server RDS | SATC |
| Gli utenti effettuano il login nel browser perché le regole si applichino | Captive Portal |
| Gli utenti arrivano tramite Remote Access VPN | Autenticazione VPN o Entra ID SSO |
| Il traffico passa attraverso server tecnici senza riferimento utente | normali regole firewall senza utente |
Se un terminal server viene rappresentato erroneamente tramite STAS o Clientless User, nascono rapidamente aspettative sbagliate. Una regola sembra basata su utente, ma in realtà il firewall vede solo un IP server condiviso. SATC risolve esattamente questo problema, ma richiede una configurazione dedicata sul Windows Server e sul firewall.
Requisiti
Prima della configurazione questi punti dovrebbero essere chiariti:
- Sophos Server Protection può essere usato sul Remote Desktop Session Host.
- Il Windows Server funziona come Remote Desktop Session Host.
- Si usa Windows Server 2016 o versione successiva.
- La Sophos Firewall è raggiungibile.
- Active Directory è collegato alla Sophos Firewall.
- I gruppi AD necessari sono importati sul firewall.
Client Authenticationè consentito in Device Access per la zona del server RDS.- Le regole firewall potranno poi lavorare con Match known users.
- Esiste una finestra di manutenzione per la modifica Registry e il riavvio del server RDS.
Il collegamento AD non dovrebbe nascere incidentalmente durante questa attività. Se AD non è ancora configurato in modo pulito, verificare prima Collegare Active Directory a Sophos Firewall.
Limiti importanti
SATC ha alcuni limiti che bisogna conoscere prima del rollout:
| Punto | Significato |
|---|---|
| Standalone-SATC | Non è più supportato da Sophos Firewall. |
| Distribuzione | SATC funziona tramite Sophos Server Protection o Sophos Central Server Core Agent. |
| Piattaforma | SATC con Sophos Server Protection è pensato per Windows Remote Desktop Services. |
| Limite server | Sophos indica fino a 192 Thin Client Server sul firewall. |
| Autenticazione per IP server | Se un IP server RDS è registrato sul firewall come Thin Client, SATC funziona come metodo di autenticazione per questo IP. Altri metodi come Clientless User non si applicano a questo IP. |
Proprio l’ultimo punto è importante. Non bisognerebbe inserire per prova IP di terminal server produttivi senza capire il set di regole e il percorso di ritorno. Appena l’IP viene trattato come sorgente SATC, cambiano le aspettative su associazione utente e rule matching.
Procedura in sintesi
La procedura tecnica consiste in cinque parti:
- Installare Sophos Server Protection sul server RDS.
- Attivare SATC sul server RDS tramite Registry.
- Registrare l’IP del server RDS nella Device Console della Sophos Firewall.
- Verificare server AD, gruppi e ordine di autenticazione sul firewall.
- Validare Device Access, regola firewall e Live Users.
SATC non dovrebbe essere solo installato, ma anche testato. Un’installazione riuscita sul server non prova ancora che il firewall vedrà poi l’utente corretto nella regola corretta.
Installare Sophos Server Protection
L’installazione avviene tramite Sophos Central.
Procedura:
- Accedere a Sophos Central.
- Aprire Protect Devices.
- Scaricare il Windows Server Installer sotto Server Protection.
- Installare l’installer sul Remote Desktop Session Host.
- Verificare se il server appare correttamente in Sophos Central.
- Definire una finestra di manutenzione per l’attivazione SATC.
Gli installer visibili dipendono dalle licenze Sophos disponibili. Se sul server è già in esecuzione Sophos Server Protection, va comunque verificato se l’agent è aggiornato e se Tamper Protection può essere disattivata in modo controllato e poi riattivata.
Attivare SATC tramite Registry
SATC viene controllato sul server RDS tramite valori Registry sotto questo percorso:
HKLM\Software\Sophos\Sophos Network Threat Protection\Application
Prima della modifica bisogna documentare le impostazioni attuali. Se Tamper Protection è attiva sul server, deve essere disattivata in modo controllato per la modifica e poi riattivata.
La configurazione di base può essere impostata da un prompt dei comandi amministrativo:
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 viene sostituito dall’indirizzo IP della Sophos Firewall a cui il server RDS deve inviare le informazioni SATC. La porta standard è 6060.
Dopo:
- Riattivare Tamper Protection.
- Riavviare il server RDS.
- Dopo il riavvio verificare se il servizio Sophos è in esecuzione.
- Solo dopo proseguire con configurazione firewall e test.
Escludere account locali e destinazioni
Per impostazione predefinita anche account locali come SYSTEM o Administrator possono generare eventi SATC. Per le regole utente questo di solito non è utile e può sporcare inutilmente i log.
Con SatcExcludedUsers si possono escludere utenti. Le voci sono case-sensitive.
Esempio:
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcExcludedUsers /t REG_MULTI_SZ /d "SYSTEM\0Administrator" /f
Con SatcExcludedAddresses si possono escludere destinazioni per le quali non devono essere inviate informazioni SATC al firewall. Questo può essere utile per destinazioni locali di management, update o infrastruttura, ma va documentato consapevolmente.
Formati possibili:
192.0.2.10
192.0.2.10:443
*:443
Le eccezioni dovrebbero restare strette. Se vengono escluse destinazioni troppo ampie, il firewall vedrà poi meno contesto utente del previsto.
Registrare il server RDS sul firewall
Il firewall deve sapere quali server forniscono informazioni SATC. Questo avviene nella Device Console, non nella Advanced Shell.
Procedura:
- Accedere alla Sophos Firewall tramite console o SSH.
- Aprire l’opzione
4. Device Console. - Aggiungere l’IP del server RDS:
system auth thin-client add citrix-ip <RDS-SERVER-IP>
<RDS-SERVER-IP> viene sostituito dall’indirizzo IP del Remote Desktop Session Host.
Se sono presenti più server RDS, registrare ogni server singolarmente e in modo documentato. Dopo deve essere chiaro:
- quali server valgono come sorgenti SATC
- quale zona usano questi server
- quali regole firewall valutano gli utenti di questi server
- chi approva modifiche alla lista server RDS
Verificare Active Directory e gruppi
SATC fornisce informazioni utente. Affinché il firewall possa usare queste informazioni nelle regole, collegamento AD e gruppi devono essere corretti.
Verificare:
- Aprire Authentication > Servers.
- Verificare il server AD con Test connection.
- Controllare l’importazione dei gruppi.
- Aprire Authentication > Groups.
- Cercare i gruppi rilevanti.
- Aprire Authentication > Services.
- Verificare il server AD nell’ordine corretto delle Firewall authentication methods.
Se gli utenti compaiono nell’area Live User, ma le regole non si applicano, la causa spesso non è SATC stesso, ma importazione gruppi, gruppo standard, criterio della regola o posizione della regola.
Impostare Device Access e regola firewall
Affinché il firewall accetti Client Authentication dalla zona server, Client Authentication deve essere consentito per questa zona.
Percorso:
Administration > Device access
Attivare la zona del server RDS sotto Client Authentication. Non bisogna aprire alla cieca WAN o una zona ampia e insicura. Device Access controlla servizi locali del firewall e fa parte dell’hardening del management.
Dopo serve una regola firewall per il traffico effettivo.
Procedura tipica:
- Aprire Rules and policies > Firewall rules.
- Creare una regola adatta per il traffico dal server RDS o dalla zona server.
- Impostare Source zone e Destination zone in modo corretto.
- Attivare Match known users.
- Selezionare gli utenti AD o i gruppi AD necessari.
- Attivare Logging, così il test sarà tracciabile in seguito.
- Salvare la regola.
- Generare traffico di test da una sessione RDS.
Per il troubleshooting successivo il logging è importante. Se una regola utente viene creata senza logging, è più difficile riconoscere se il problema è SATC, group matching, ordine delle regole o un altro percorso.
Validazione dopo la configurazione
Dopo la configurazione non bisogna verificare solo se un utente ha accesso a Internet. È decisivo se il firewall vede l’utente corretto e applica la regola corretta.
Test pratico:
- Effettuare il login con un utente in una sessione RDS.
- Generare traffico di test definito, per esempio una connessione HTTPS consentita.
- Aprire nella Sophos Firewall Current activities > Live users.
- Verificare se l’utente compare con Client type
Thin client. - Controllare indirizzo IP del server RDS e associazione sessione.
- Aprire Log Viewer.
- Filtrare per Source IP del server RDS, utente e regola.
- Verificare se si applica la regola basata su utente attesa.
Se il traffico non scorre come previsto, aiuta inoltre Testare una regola firewall con Log Viewer, Policy Test e Packet Capture. Se gli utenti sono visibili, ma gruppi o singoli utenti non fanno match, La regola Sophos Firewall non matcha è il prossimo percorso di verifica adatto.
Troubleshooting
Nessun utente Thin Client visibile
Verificare:
- il server RDS è stato riavviato dopo la modifica Registry.
SendSatcEventsè impostato e diverso da0.SatcDestinationAddrpunta all’IP firewall corretto.SatcDestinationPortcorrisponde alla porta attesa.- il percorso di rete dal server RDS al firewall è aperto.
- l’IP del server RDS è stato registrato sul firewall tramite
system auth thin-client add citrix-ip. - la zona del server RDS consente Client Authentication sotto Device Access.
L’utente appare, ma la regola non matcha
Verificare:
- l’utente o il gruppo è importato sul firewall.
- la regola usa Match known users.
- il gruppo AD corretto è selezionato nella regola.
- la posizione della regola è corretta.
- non esiste una regola precedente che matcha lo stesso traffico senza riferimento utente.
- Log Viewer mostra lo stesso utente, la stessa Source IP e lo stesso servizio.
Account locali compaiono nei log
Controllare SatcExcludedUsers e aggiungere account tecnici. Candidati frequenti sono amministratori locali, servizi e account di sistema. La lista non dovrebbe però diventare così ampia da escludere per errore utenti reali.
Singole destinazioni non ricevono contesto utente
Controllare SatcExcludedAddresses. Se una destinazione o una porta è stata esclusa, SATC non invia per essa informazioni di autenticazione al firewall. Questo può essere intenzionale, ma nelle regole utente crea facilmente confusione.
Dopo la registrazione dell’IP server un vecchio Clientless User non funziona più
È previsto. Se l’IP del server RDS è stato registrato come Thin Client Server, SATC dovrebbe essere il modello di autenticazione per questo IP. Vecchi workaround con Clientless User dovrebbero essere rimossi o sostituiti consapevolmente.
Operatività e documentazione
SATC dovrebbe essere gestito come un componente produttivo di autenticazione, non come un hack Registry una tantum.
Documentare:
- server RDS e indirizzi IP
- IP firewall e porta SATC usati
- valori Registry impostati
- utenti e destinazioni esclusi
- regole firewall interessate
- gruppi AD e owner
- utente di test e rule match atteso
- finestra di manutenzione e orario di riavvio
Dopo update di Sophos Server Protection, Windows Server, Sophos Firewall o AD, SATC dovrebbe essere verificato in modo mirato con un utente di test. L’autenticazione diventa spesso visibile solo quando regole utente improvvisamente si applicano in modo troppo ampio o non si applicano affatto.
Checklist
- Lo scenario RDS è davvero adatto a SATC e non a normale STAS.
- Sophos Server Protection è installato sul Remote Desktop Session Host.
- Versione Windows Server e ruolo RDS sono verificati.
- Tamper Protection è stata disattivata solo in modo controllato e poi riattivata.
SendSatcEvents,SatcDestinationAddreSatcDestinationPortsono impostati.- Il server RDS è stato riavviato.
- L’IP del server RDS è stato registrato nella Device Console sul firewall.
- Server AD e gruppi AD sono verificati sul firewall.
Client Authenticationè consentito per la zona corretta sotto Device Access.- La regola firewall usa Match known users e ha Logging attivo.
- L’utente compare sotto Current activities > Live users con Client type
Thin client. - Log Viewer mostra l’utente atteso e la regola attesa.
FAQ
Quando serve SATC invece di STAS?
Il vecchio Standalone-SATC è ancora supportato?
Quale versione Windows Server serve per SATC?
Perché un Clientless User non funziona più per l'IP del server RDS?
Come si verifica se SATC funziona?
Thin client. Inoltre il Log Viewer dovrebbe mostrare quale regola utente matcha il traffico.