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.

Per i normali client Windows, il primo passo è configurare STAS su Sophos Firewall. SATC non sostituisce STAS in ogni ambiente, ma è il componente adatto per Remote Desktop Services.

Utilizzo e pianificazione

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 è sufficiente perché più utenti condividono lo stesso IP sorgente

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 il modello di autenticazione appropriato: STAS, Captive Portal, autenticazione VPN, RADIUS o Microsoft Entra ID SSO.

Separare correttamente STAS e SATC

La differenza più importante è l’associazione IP.

• 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.

Se STAS e SATC vengono usati contemporaneamente, la separazione concettuale da sola non basta. Citrix XenApp e Windows Server RDS possono far sì che STAS restituisca un’identità utente errata per lo stesso IP server se non viene escluso. Per questo motivo gli indirizzi IP dei server Citrix/RDS devono essere inseriti nella configurazione STAS sotto Login IP Address/Network Subnet mask Exclusion List e Logoff IP Address/Network Subnet mask Exclusion List. Senza questa esclusione, STAS può continuare a fornire una propria mappatura utente contraddittoria proprio per gli IP server che dovrebbero usare SATC.

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 deve essere configurato correttamente prima di implementare SATC. Se AD non è ancora pronto, verificare prima Collegare Active Directory a Sophos Firewall.

Limiti importanti

SATC ha alcuni limiti che bisogna conoscere prima del rollout:

• 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. Sophos indica anche Citrix XenApp come scenario supportato con limitazioni; questo si riflette anche nel nome del parametro citrix-ip nel comando CLI.
• 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.

Configurazione

Procedura in sintesi

La procedura tecnica consiste in cinque parti:

1. Installare Sophos Server Protection sul server RDS.
2. Attivare SATC sul server RDS tramite Registry.
3. Registrare l’IP del server RDS nella Device Console della Sophos Firewall.
4. Verificare server AD, gruppi e ordine di autenticazione sul firewall.
5. 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:

1. Accedere a Sophos Central.
2. Aprire Protect Devices.
3. Scaricare il Windows Server Installer sotto Server Protection.
4. Installare il programma di installazione sul Remote Desktop Session Host.
5. Verificare se il server appare correttamente in Sophos Central.
6. Definire una finestra di manutenzione per l’attivazione SATC.

I programmi di installazione 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, questo comando di sola lettura mostra quali valori SATC sono già presenti:

reg query "HKLM\Software\Sophos\Sophos Network Threat Protection\Application"

Attenzione: Le modifiche al Registry e il successivo riavvio interessano tutte le sessioni RDS attive. Documentare i valori attuali, utilizzare una finestra di manutenzione e disattivare Tamper Protection solo in modo controllato. Dopo la modifica deve essere 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:

1. Riattivare Tamper Protection.
2. Riavviare il server RDS.
3. Dopo il riavvio verificare se il servizio Sophos è in esecuzione.
4. Eseguire nuovamente il comando di sola lettura reg query e controllare i valori impostati.
5. 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 distinguono tra maiuscole e minuscole.

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 in modo esplicito.

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.

In caso di latenza di rete percepibile tra il server RDS e il firewall, si può impostare anche SatcPendDurationMs. Il valore determina per quanto tempo vengono trattenute le connessioni TCP IPv4 in uscita, affinché l’associazione utente sia disponibile in tempo. Se il valore Registry non è presente, SATC usa 100 millisecondi; 0 disattiva solo questo ritardo della connessione, non SATC. Modificarlo solo in presenza di reali problemi di latenza, non per precauzione.

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcPendDurationMs /t REG_DWORD /d 300 /f

Come per le altre modifiche al registro, in seguito è necessario riavviare il server RDS.

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:

1. Accedere alla Sophos Firewall tramite console o SSH.
2. Aprire l’opzione 4. Device Console.
3. Visualizzare le voci esistenti:

system auth thin-client show

4. Aggiungere l’IP del server RDS solo se non è ancora elencato:

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

Se è stato registrato un IP errato, controllare nuovamente l’elenco e rimuoverlo in modo mirato:

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

Il comando rimuove solo la voce Thin Client sul firewall; i valori Registry e Sophos Server Protection restano sul server RDS. Per un IP produttivo viene così meno l’associazione SATC e le regole basate sugli utenti possono non fare più match. Sophos non documenta come reagiscono le sessioni già esistenti. Rimuovere quindi la voce solo durante una finestra di manutenzione e con una procedura di ripristino preparata.

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:

1. Aprire Authentication > Servers.
2. Verificare il server AD con Test connection.
3. Controllare l’importazione dei gruppi.
4. Aprire Authentication > Groups.
5. Cercare i gruppi rilevanti.
6. Aprire Authentication > Services.
7. Verificare il server AD nell’ordine corretto delle Firewall authentication methods.

Se gli utenti compaiono nell’area Live Users, 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:

1. Aprire Rules and policies > Firewall rules.
2. Creare una regola adatta per il traffico dal server RDS o dalla zona server.
3. Impostare Source zone e Destination zone in modo corretto.
4. Attivare Match known users.
5. Selezionare gli utenti AD o i gruppi AD necessari.
6. Attivare Logging, così il test sarà tracciabile in seguito.
7. Salvare la regola.
8. 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 e operatività

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:

1. Effettuare il login con un utente in una sessione RDS.
2. Generare traffico di test definito, per esempio una connessione HTTPS consentita.
3. Aprire nella Sophos Firewall Current activities > Live users.
4. Verificare se l’utente compare con Client type Thin client.
5. Controllare indirizzo IP del server RDS e associazione sessione.
6. Aprire Log Viewer.
7. Filtrare per Source IP del server RDS, utente e regola.
8. Verificare se si applica la regola basata su utente attesa.

Per un’analisi più approfondita nell’Advanced Shell, firewall_rule.log è rilevante per il rule match e access_server.log per autenticazione e autorizzazione. Log Viewer resta il percorso iniziale più rapido.

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.

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 responsabile
• 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. I problemi di autenticazione spesso diventano evidenti solo quando le regole utente improvvisamente si applicano in modo troppo ampio o non si applicano più.

Troubleshooting

Nessun utente Thin Client visibile

Verificare:

• il server RDS è stato riavviato dopo la modifica Registry.
• SendSatcEvents è impostato e diverso da 0.
• SatcDestinationAddr punta all’IP firewall corretto.
• SatcDestinationPort corrisponde 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 rimane non autenticato a causa di un conflitto della porta sorgente

Un software proxy o di sicurezza sul server RDS può modificare la Source Port. Il firewall rileva quindi un port mismatch e tratta il traffico come non autenticato. Non confondere questa Source Port con SatcDestinationPort: il valore Registry definisce la porta di destinazione per i messaggi SATC, per impostazione predefinita 6060. Testare tale software in modo controllato o configurarlo correttamente per il percorso SATC; non disattivare genericamente le funzioni di protezione.

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 in modo pianificato.

Nessun accesso a Internet dopo un aggiornamento a SFOS 22.0 GA

Se l’utente appare come Thin client, ma dopo l’aggiornamento non ha accesso a Internet, acquisire prima la versione firmware, il rule match, firewall_rule.log e access_server.log. Sophos conferma l’errore NC-178903 per gli aggiornamenti a SFOS 22.0 GA e lo corregge con SFOS 22.0 MR2 Build 546. Sophos non indica una firma di log univoca né un workaround separato. L’inquadramento della release è disponibile nella panoramica di SFOS 22.0 MR2.

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, SatcDestinationAddr e SatcDestinationPort sono 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