Vai al contenuto
Avanet

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.

ScenarioApproccio adatto
Un client Windows appartiene di solito a un utenteSTAS
Molti utenti condividono lo stesso IP del server RDSSATC
Gli utenti effettuano il login nel browser perché le regole si applichinoCaptive Portal
Gli utenti arrivano tramite Remote Access VPNAutenticazione VPN o Entra ID SSO
Il traffico passa attraverso server tecnici senza riferimento utentenormali 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:

PuntoSignificato
Standalone-SATCNon è più supportato da Sophos Firewall.
DistribuzioneSATC funziona tramite Sophos Server Protection o Sophos Central Server Core Agent.
PiattaformaSATC con Sophos Server Protection è pensato per Windows Remote Desktop Services.
Limite serverSophos indica fino a 192 Thin Client Server sul firewall.
Autenticazione per IP serverSe 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:

  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 l’installer 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.

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:

  1. Riattivare Tamper Protection.
  2. Riavviare il server RDS.
  3. Dopo il riavvio verificare se il servizio Sophos è in esecuzione.
  4. 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:

  1. Accedere alla Sophos Firewall tramite console o SSH.
  2. Aprire l’opzione 4. Device Console.
  3. 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:

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

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

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

Quando serve SATC invece di STAS?

SATC è utile quando più utenti condividono lo stesso IP sorgente, per esempio su un Remote Desktop Session Host. STAS è più adatto ai normali client Windows, in cui un IP client appartiene tipicamente a un utente.

Il vecchio Standalone-SATC è ancora supportato?

No. Il percorso attuale passa tramite Sophos Server Protection o Sophos Central Server Core Agent sul Windows Remote Desktop Session Host.

Quale versione Windows Server serve per SATC?

Sophos indica Windows Server 2016 o versione successiva per SATC con Sophos Server Protection. Inoltre deve trattarsi di uno scenario Remote Desktop Services.

Perché un Clientless User non funziona più per l'IP del server RDS?

Se l’IP del server RDS è registrato sul firewall come Thin Client Server, questo IP lavora con SATC. Altri metodi di autenticazione come Clientless User non sono allora il percorso corretto per questo IP.

Come si verifica se SATC funziona?

Un utente effettua il login a una sessione RDS, genera traffico di test e viene poi verificato sotto Current activities > Live users con Client type Thin client. Inoltre il Log Viewer dovrebbe mostrare quale regola utente matcha il traffico.