Sophos Firewall: Device Access e Local Service ACL

In Administration > Device access si definisce da quali zone sono accessibili i servizi locali di Sophos Firewall. Questi includono HTTPS per WebAdmin e API, SSH, Ping, DNS, SNMP, SSL VPN, User Portal e VPN Portal.

Questi servizi terminano direttamente sul firewall e costituiscono la sua superficie di gestione e di servizio. Se un’autorizzazione è troppo ampia, bot, client interni compromessi o aggressori esterni possono raggiungere direttamente le pagine di accesso, l’API e SSH per provare credenziali, vulnerabilità note o errori di configurazione. MFA e password sicure restano importanti, ma non limitano la raggiungibilità: Device Access riduce la superficie di attacco prima dell’accesso ed è quindi una delle prime misure di hardening.

La fonte dell’identità resta separata. Se WebAdmin deve usare credenziali TACACS+ centrali, TACACS+ per gli amministratori di Sophos Firewall descrive l’integrazione del server, l’assegnazione locale del profilo, il login pilota e il fallback; la raggiungibilità HTTPS continua a essere limitata qui.

È determinante la destinazione della connessione:

• Tabella delle zone di Device Access: consente in linea generale l’accesso a un servizio locale del firewall da una zona.
• Local service ACL exception rule: consente o blocca un servizio locale per origini, destinazioni e servizi specifici.
• Regola firewall: controlla il traffico attraverso il firewall, ad esempio da LAN a un server in DMZ.

Se, ad esempio, si apre https://172.16.16.16:4444, la connessione termina sul firewall. Una normale regola firewall non sostituisce quindi un’autorizzazione di Device Access.

⚠️ WebAdmin, SSH e i portali dovrebbero essere accessibili solo dalle reti che ne hanno realmente bisogno. Per l’amministrazione esterna, una VPN amministrativa, Sophos Central Firewall Management in Sophos Fusion (accesso da fusion.sophos.com), una rete di gestione o un’eccezione ACL restrittiva sono più sicuri di un’ampia autorizzazione dalla WAN.

Due casi particolari possono aggirare la tabella delle zone per i servizi HTTP e HTTPS:

• Web Proxy: le richieste che passano attraverso il Web Proxy sono considerate interne e non possono essere controllate in base alla zona di origine tramite Device Access. Chi può utilizzare il proxy può quindi raggiungere WebAdmin, Captive Portal, VPN Portal e User Portal anche se il servizio è disattivato per la propria zona.
• Port Sharing: se VPN Portal e SSL VPN utilizzano la stessa porta e lo stesso protocollo, VPN Portal diventa accessibile da tutte le zone di accesso SSL VPN. Inoltre, le impostazioni in Login security non sono più applicate.

Questi due percorsi devono essere testati separatamente durante il collaudo. L’articolo generale Sophos Firewall Hardening inquadra Device Access nell’hardening complessivo del sistema.

Pianificare zone e servizi locali

La tabella delle zone è adatta per autorizzazioni di base chiare, ad esempio DNS dalla LAN, Ping da una zona di monitoraggio o HTTPS da una rete di gestione. Se l’accesso è necessario solo per un singolo indirizzo IP o una piccola rete, una ACL Exception Rule è più precisa.

Una zona raggruppa le interfacce. Per una zona personalizzata, l’accesso ai servizi locali può essere consentito o bloccato anche in Network > Zones. Prima di una modifica occorre quindi identificare l’interfaccia di ingresso effettiva e la relativa zona. Vanno inoltre preparati l’oggetto sorgente restrittivo, l’Interface Host necessario come destinazione e la porta realmente usata dal servizio. Gli IP Host esistenti si trovano in Hosts and services > IP host; gli Interface Host vengono gestiti tramite Network > Interfaces.

Leggere la matrice predefinita come punto di partenza

Una nuova configurazione SFOS 22 consente per impostazione predefinita i servizi locali dalle zone seguenti. Questa matrice non è un obiettivo di hardening: ripristino, migrazione, procedura guidata e modifiche successive possono produrre uno stato diverso, e i servizi non necessari vengono rimossi dopo test positivi e negativi.

Decisioni tipiche:

• HTTPS: WebAdmin e API solo da reti di gestione o da origini amministrative definite in modo restrittivo.
• SSH: Solo per amministrazione o supporto e, se possibile, con chiave pubblica. Per SSH di rete, il percorso di autenticazione documentato in SFOS 22/23 prevede l’account integrato admin; un’autorizzazione CLI nel profilo non conferma la possibilità di autenticarsi tramite SSH con un account amministratore nominativo. Solo l’amministratore predefinito gestisce le impostazioni e le chiavi pubbliche.
• DNS: solo per le zone client interne che utilizzano il firewall come resolver DNS. Il DNS dalla WAN non è un normale caso d’uso client.
• Ping/Ping6: per il monitoraggio necessario, non in modo indiscriminato da zone non sicure.
• SNMP: solo dal sistema o dalla rete di monitoraggio; la configurazione è descritta in Monitoraggio hardware SNMP.
• RADIUS SSO: Solo dal mittente accounting fisso. RADIUS SSO con accounting spiega l’associazione tra IP client e utente.
• SSL VPN: verso l’esterno solo nella misura necessaria e con MFA, logging e porta e protocollo scelti consapevolmente.
• VPN Portal: da SFOS 20 mette a disposizione Sophos Connect e le configurazioni IPsec e SSL VPN.
• User Portal: serve, tra l’altro, per dati personali, token OTP, quarantena, eccezioni e Policy Overrides, non per scaricare la configurazione VPN.
• RED, SMTP Relay e Dynamic Routing: solo nelle reti previste o per controparti definite. Configurare PIM-SM su Sophos Firewall mostra come verificare questo limite per i neighbor multicast; per piccoli domini di routing IPv4, configurare RIPv2 su Sophos Firewall spiega l’autorizzazione separata della zona del peer e del traffico dati.

La finestra dei servizi offre inoltre AD SSO, Captive portal, Chromebook SSO, Clients, IPsec, Web proxy e Wireless Protection. La possibilità di selezionare un servizio non costituisce una raccomandazione per un’ampia autorizzazione della zona; ogni selezione richiede un percorso client, peer o amministrativo concreto. I campi di ricerca Source Network / Host, Destination host e Services cercano anche negli attributi. Ad esempio, inserendo 53 si trova il servizio DNS.

Da SFOS 22, WebAdmin, VPN Portal e User Portal supportano TLS 1.3. Una buona cifratura, tuttavia, non riduce la superficie di attacco di un servizio accessibile senza necessità.

Device Access stabilisce soltanto da quale rete è raggiungibile la console WebAdmin. Se il login deve avvenire tramite Microsoft Entra ID, Entra ID SSO per WebAdmin di Sophos Firewall spiega l’associazione separata di ruoli e gruppi Entra ai profili amministratore locali.

Inoltre, restrict-admin-console-wan-access può bloccare globalmente l’accesso WebAdmin da tutte le origini WAN. Verificare in sicurezza le Advanced Firewall Settings spiega la logica enable/disable volutamente invertita e la distinzione dalla Local Service ACL.

Limitare rigorosamente le origini

Come origine, una ACL Exception Rule supporta Country, Country group, FQDN host/group, Host group, IP address/list/range, MAC address/list e Network. I Wildcard FQDN non sono supportati.

Per WebAdmin dalla WAN non si può utilizzare un’autorizzazione per tutte le origini. SFOS non consente di creare l’eccezione ACL quando Source Network / Host è impostato su Any o l’indirizzo IP di origine è 0.0.0.0. Questa restrizione del prodotto non rende automaticamente sicure altre reti di grandi dimensioni. Un IP amministrativo fisso, una piccola rete di gestione o un oggetto FQDN ben mantenuto sono molto più sicuri. Per gli utenti mobili con indirizzi di origine variabili, l’accesso amministrativo dovrebbe avvenire tramite VPN o Sophos Fusion.

Da SFOS 19.5 MR2, le autorizzazioni WAN estese per WebAdmin e User Portal vengono disattivate automaticamente dopo 90 giorni consecutivi senza accessi riusciti. Le origini WAN specifiche nelle ACL Exception Rules non sono interessate e devono continuare a essere verificate regolarmente. Il Sophos Firewall Health Check aiuta nella revisione periodica degli accessi di gestione, dell’MFA e della configurazione.

Verificare in anticipo Web Proxy e Port Sharing

Prima di procedere con l’hardening, annotare le porte e i protocolli utilizzati in Administration > Admin and user settings e nelle SSL VPN global settings.

• WebAdmin utilizza per impostazione predefinita TCP 4444, User Portal TCP 4443 e VPN Portal TCP 443.
• In SFOS 22/23, TCP 443 è il valore predefinito documentato per WAF; prima di verificare eventuali conflitti, annotare i listener WAF effettivamente configurati.
• SSL VPN utilizza TCP 8443 per impostazione predefinita; è possibile selezionare anche UDP come protocollo.
• WebAdmin e User Portal non possono condividere la propria porta con altri servizi.
• VPN Portal e SSL VPN non dovrebbero utilizzare la stessa porta e lo stesso protocollo, perché altrimenti le restrizioni di zona e Login Security non funzionano come previsto.

Se il Web Proxy è attivo, un test senza proxy non è sufficiente. La stessa chiamata a un portale o a WebAdmin deve essere verificata anche tramite il proxy esplicito da una zona che dovrebbe essere bloccata.

Configurare Direct Web Proxy con un file PAC spiega come limitare il listener proxy a un client pilota e verificare questa esposizione in modo controllato.

Creare una Local Service ACL Exception Rule restrittiva

Prima dell’accesso diretto a WebAdmin dalla WAN: Nella Device Console, usare prima il comando di sola lettura show advanced-firewall per documentare il valore effettivo di restrict-admin-console-wan-access e il build installato. Per SFOS 22/23, Sophos descrive enable come blocco di WebAdmin da tutte le origini WAN e come valore predefinito; questo valore non sostituisce il valore precedente rilevato. Le istruzioni ACL descrivono eccezioni WAN restrittive, ma non ne chiariscono la precedenza rispetto a questa restrizione globale. Non presumere quindi che la seguente eccezione ACL, da sola, renda WebAdmin raggiungibile dalla WAN. Con enable, mantenere la restrizione e usare il percorso di accesso autorizzato e già testato tramite VPN amministrativa, rete di gestione o Fusion. Se l’accesso WAN diretto è inevitabile e l’interazione per il build installato non è chiaramente accertata, interrompere la modifica dell’accesso WAN diretto e chiarire il punto con Sophos Support. Se un test positivo fallisce, verificare prima questo prerequisito anziché ampliare l’ACL.

Questo esempio ACL non è un’istruzione per impostare il parametro globale su disable. Modificare la restrizione globale richiede una modifica autorizzata separatamente, con un percorso amministrativo indipendente funzionante, il valore precedente effettivo documentato, test dedicati da origini WAN consentite e bloccate e il ripristino esatto di quel valore precedente in caso di interruzione e al termine dell’accesso temporaneo. Non effettuare la modifica se non è possibile accertare in modo affidabile il valore iniziale o il percorso di recupero. Applicare il seguente esempio WAN restrittivo solo dopo aver chiarito questi prerequisiti.

Un’eccezione tipica consente WebAdmin dalla WAN solo per un IP di supporto fisso. Il percorso è Administration > Device access > Local service ACL exception rule > Add.

1. Rule name: admin-https-from-support-ip
2. Rule position: per un’eccezione WAN specifica, scegliere Top e verificare le altre regole per eventuali sovrapposizioni.
3. Description: documentare scopo, ticket e data di scadenza prevista.
4. IP version: selezionare la versione adatta all’origine, generalmente IPv4.
5. Source zone: WAN
6. Source Network / Host: selezionare un IP amministrativo specifico o un oggetto restrittivo e ben mantenuto.
7. Destination host: limitare l’accesso all’indirizzo o all’interfaccia del firewall necessari. Any amplia gli indirizzi o le interfacce di destinazione raggiungibili, non i servizi selezionati in Services.
8. Services: selezionare solo HTTPS, senza aggiungere SSH per comodità.
9. Action: Accept

I valori dell’esempio non vanno copiati senza adattarli. Per una rete di gestione interna, lo stesso schema può usare Source zone: LAN o una zona di gestione personalizzata, Source Network / Host: mgmt-net, l’Interface Host dell’IP di gestione come Destination host, HTTPS e Accept. Per escludere una sorgente nota all’interno di una zona che deve restare generalmente autorizzata, si usa una regola separata, posizionata correttamente, con l’oggetto sorgente restrittivo, soltanto i servizi interessati e Drop. Un gruppo di paesi è al massimo un limite di rete approssimativo, non un sostituto di una sorgente amministrativa fissa o di una VPN.

Salvare quindi la regola e testarla da un’origine consentita e da una non consentita. La posizione della regola è importante: le regole più in alto possono influenzare il risultato. In caso di regole sovrapposte, verificarne quindi l’effetto reale sul firewall senza dedurlo unicamente dall’elenco.

Accesso API

Per l’API devono essere soddisfatte tre condizioni:

1. L’API è attivata in Administration > API access.
2. L’indirizzo di origine è incluso in Allowed IP hosts.
3. Device Access consente HTTPS dalla zona interessata o tramite un’eccezione ACL appropriata.

Da SFOS 22, la configurazione API si trova in Administration e supporta oggetti IP host per indirizzi, intervalli e reti. Sono possibili fino a 64 oggetti. Non è necessaria un’ampia autorizzazione HTTPS. La configurazione completa è descritta in Limitare in sicurezza l’accesso API a Sophos Firewall.

Automazione XML: impostazione di zona, non eccezione ACL

La documentazione XML delle zone per SFOS 22/23 colloca HTTPS e SSH rispettivamente in Zone/ApplianceAccess/AdminServices/HTTPS e Zone/ApplianceAccess/AdminServices/SSH. Si tratta dell’accesso ai servizi locali a livello di zona: non è una regola firewall per il traffico di transito né una Local service ACL exception rule limitata a una sorgente specifica. Modificare questo ramo influisce sulla raggiungibilità della gestione dalla zona; non limita l’accesso a un singolo IP amministrativo. Per autorizzare una sorgente in modo restrittivo, l’eccezione ACL descritta sopra resta il limite appropriato.

La documentazione è contraddittoria sui valori: l’esempio XML mostra Enable/Disable, mentre la tabella comune dei parametri ripete Enable e include anche 12 e 40. Non se ne può ricavare una codifica booleana o numerica affidabile. Prima di qualsiasi scrittura automatizzata, chiarire la sintassi per il firmware installato; questa spiegazione della gerarchia non è un modello eseguibile per concedere accesso.

Neppure Zone/MemberPorts è un’istruzione di scrittura: il commento nell’esempio XML indica esplicitamente che le porte appartenenti alla zona sono di sola lettura. La riga CSV facoltativa della tabella ne descrive la visualizzazione, non un metodo verificato per modificarle. Prima di qualsiasi modifica automatizzata di una zona, testare un percorso di recupero indipendente con una sessione autenticata e, dopo la modifica, verificare le sorgenti consentite e bloccate come descritto nel rollout sottostante.

Rimuovere una zona personalizzata in sicurezza

Eliminare una Local service ACL exception rule rimuove soltanto quell’eccezione, non la zona identificata per nome. Nemmeno disattivare un servizio locale equivale a eliminare una zona. Zone e interfacce spiega le associazioni.

1. In Network > Zones, identificare il nome esatto della zona personalizzata non più necessaria in produzione e documentarne lo stato precedente. Retired_Test è solo un esempio, non una destinazione di eliminazione da copiare. Prima, autenticarsi e testare il percorso amministrativo indipendente descritto nel rollout sottostante; non deve dipendere da questa zona né dalle interfacce o regole da modificare.
2. In Network > Interfaces, esaminare tutte le assegnazioni a questa zona e, in Rules and policies > Firewall rules, tutti i riferimenti come Source zone o Destination zone. Non eliminare interfacce o regole necessarie: riassegnarle alla zona rimanente prevista soltanto nell’ambito di una modifica autorizzata e verificarne l’effetto. Se i riferimenti devono restare o il loro utilizzo non è chiaro, mantenere la zona e le sue dipendenze e interrompere l’eliminazione. Non eliminare a cascata dipendenze di produzione per forzare la rimozione.
3. Soltanto dopo aver chiarito le dipendenze, rimuovere esclusivamente questa zona identificata per nome. La documentazione XML di SFOS 22/23 richiede Name con al massimo 60 caratteri: prima A-Za-z1-9 (non 0), poi A-Za-z0-9_. Questo non dimostra né il supporto dei caratteri jolly né l’eliminazione automatica a cascata; qui non si prescrivono richieste XML o finestre di eliminazione non supportate dalle fonti.
4. Dopo, verificare che manchi soltanto la zona prevista, che le assegnazioni delle interfacce e le regole firewall rimanenti siano corrette e che il traffico di transito necessario continui a funzionare. Ripetere i test dei servizi locali da sorgenti consentite e bloccate e del percorso amministrativo indipendente. In caso di differenze, interrompere e usare quel percorso per annullare selettivamente le modifiche documentate, non ampliare le autorizzazioni.

Gli stati XML documentati sono 200 (ZoneDeleteSuccess), 500 (ZoneDeleteFailed), 503 (ZoneInterfaceExists) e 504 (ZoneFirewallRuleExists). Con 503 o 504, ricontrollare i riferimenti alle interfacce o regole interessate invece di eliminare indiscriminatamente gli oggetti dipendenti. 500 non indica successo; neppure 200 sostituisce la verifica successiva.

DNS dalla WAN

Una sola eccezione ACL DNS dalla WAN non fa sì che il firewall risponda alle richieste DNS su tale zona. Sarebbe inoltre necessario configurare in Network > DNS un DNS Host statico con Publish on WAN. Questa opzione dovrebbe essere utilizzata solo per un caso d’uso autoritativo specifico; il firewall non deve diventare un resolver ricorsivo pubblico. Configurare e testare le DNS Host Entry su Sophos Firewall spiega la delega, la DNS Host Entry e i test positivi e negativi.

Dettagli operativi prima della modifica

Dopo un aggiornamento o ripristino da una versione precedente a SFOS 20, VPN Portal eredita la vecchia porta di User Portal, anche se personalizzata. User Portal passa a 4443, oppure a 65040 se quella porta è occupata. Verificare la porta configurata, non solo quella predefinita, prima di cercare un’autorizzazione ACL apparentemente mancante. Gli utenti o gruppi di VPN Portal devono anche appartenere a una policy Remote Access adeguata; la sola raggiungibilità non concede l’autorizzazione all’utente.

Il listener WAF deve differire da VPN Portal per IP WAN o porta. Rispetto a SSL VPN è sufficiente anche un protocollo diverso: WAF e VPN Portal usano TCP, mentre SSL VPN può usare TCP o UDP. Separare i listener non equivale a concedere un’autorizzazione ACL; ripetere i test dei servizi interessati dopo ogni modifica della porta.

Dynamic Routing consente aggiornamenti di routing verso il firewall, non il traffico dati che lo attraversa. Abilitarlo per la zona effettiva del peer, non automaticamente per WAN. Nell’esempio WAN con due firewall RIP, solo il lato abilitato riceve gli aggiornamenti; l’altro li scarta e non apprende le reti annunciate. Se mancano rotte da un solo lato, verificare la zona del peer su entrambi i lati e poi la configurazione del protocollo nell’articolo di routing collegato.

Il widget Messages in Control center può segnalare l’accesso WAN a HTTPS e SSH. Verificare le autorizzazioni di zona e le eccezioni ACL e limitare l’accesso a una VPN o a host e reti specifici. I messaggi non si possono eliminare manualmente; alcuni scompaiono dopo aver soddisfatto il requisito. La loro scomparsa non sostituisce test positivi e negativi. I messaggi su chiave master, registrazione, licenze, report e firmware appartengono ai rispettivi processi operativi, non a una regola ACL aggiuntiva.

Applicare le modifiche senza lockout

Le modifiche a Device Access hanno effetto immediato.

Il percorso di recupero deve continuare a funzionare dopo la modifica prevista di zona o porta. Una seconda scheda del browser che usa lo stesso accesso bloccato non è indipendente. Prima di iniziare, documentare le impostazioni precedenti esatte e chi dispone dell’accesso console; senza un percorso di recupero funzionante non effettuare modifiche da remoto. Durante gli interventi da remoto, il secondo percorso amministrativo deve essere realmente connesso e testato prima della modifica.

1. Documentare le attuali autorizzazioni di zona, le eccezioni ACL, le porte e i servizi necessari.
2. Aprire un accesso indipendente, ad esempio console locale, Management LAN, Admin VPN o Sophos Fusion.
3. Per modifiche più estese, tenere disponibili un backup aggiornato e la Secure Storage Master Key.
4. Creare la nuova eccezione Accept restrittiva senza rimuovere ancora l’autorizzazione di zona più ampia esistente.
5. Verificare l’accesso consentito come baseline. Finché l’ampia autorizzazione di zona rimane attiva, questo test non dimostra ancora che la nuova eccezione sia applicata.
6. In Diagnostics > Packet capture, impostare un filtro restrittivo per origine, destinazione e porta e attivare Trace On.
7. Tramite il percorso amministrativo indipendente, rimuovere la vecchia autorizzazione di zona più ampia.
8. Subito dopo, testare funzionalmente il servizio dall’origine consentita. Una connessione TCP/TLS o al servizio riuscita e, di norma, Status: Consumed confermano il caso positivo; Reason: LOCAL_ACL non deve necessariamente apparire.
9. Testare lo stesso servizio da un’origine non consentita. Per il tentativo bloccato sono generalmente attesi Status: Violation e Reason: LOCAL_ACL.
10. Per HTTP/HTTPS, verificare inoltre il percorso Web Proxy e, per i portali, le zone di accesso SSL VPN.
11. Arrestare Packet Capture e controllare nel Log viewer gli eventi aggiuntivi relativi al servizio o all’accesso. La Rule-ID mostrata in Packet Capture è l’ID della regola firewall, non l’ID della ACL Exception Rule, e per il traffico locale può essere 0.
12. Documentare regola, scopo, responsabile, ticket, origine, servizio e data di revisione o scadenza.

Interruzione e ripristino: se l’accesso consentito non funziona, usare il percorso indipendente per riportare l’ultima impostazione modificata al valore precedente documentato e verificare nuovamente l’accesso. Se invece un’origine bloccata raggiunge ancora il servizio, non ampliare l’autorizzazione: verificare proxy, Port Sharing e regole ACL sovrapposte e limitare il percorso indesiderato senza perdere l’accesso di recupero. Ripetere entrambi i test solo dopo la correzione.

Esempi di documentazione compatti facilitano le revisioni successive:

• HTTPS: regola admin-https-from-mgmt, origine mgmt-net, scopo WebAdmin, revisione trimestrale.
• SSH: origine support-ip-temporary, scopo intervento di supporto, eliminare alla chiusura del ticket.
• SNMP: origine monitoring-server, scopo monitoraggio hardware e interfacce, revisione semestrale.
• SSL VPN: origine WAN, scopo Remote Access, controllo mensile dei log.

Per più firewall o un cluster HA, modificare innanzitutto un sistema con una buona possibilità di ripristino. La guida Configurare Sophos Firewall High Availability tratta il cambio di ruolo e l’accesso durante la manutenzione.

Casi particolari e protezione aggiuntiva

User Portal, VPN Portal e SSL VPN

Occorre innanzitutto chiarire quale portale sia realmente necessario. Client e configurazioni VPN appartengono a VPN Portal; User Portal svolge altre funzioni utente. Una panoramica è disponibile in Confronto dei portali Sophos Firewall.

Se un servizio di Remote Access deve essere raggiungibile in tutto il mondo, MFA, gruppi utenti restrittivi e logging sono più importanti di una limitazione geografica inadeguata. La configurazione è descritta in MFA per WebAdmin, VPN Portal e Remote Access. Il Port Sharing deve comunque essere evitato: l’autenticazione non sostituisce un corretto controllo della raggiungibilità.

Gli accessi WebAdmin, User Portal, VPN Portal e SSL VPN pubblicamente raggiungibili vengono individuati rapidamente da scanner e bot. Anche con MFA generano traffico brute-force, rumore nei log e carico aggiuntivo.

Se si verificano già molti accessi non riusciti al VPN Portal o blocchi degli account, Proteggere il VPN Portal di Sophos Firewall dagli attacchi brute force riunisce controllo dei log, verifica dell’identità, contenimento tramite ACL e controllo finale in un processo di risposta agli incidenti.

Se un portale deve rimanere accessibile in tutto il mondo, Sophos Firewall Threat Feeds con l’azione Block può bloccare anche le origini IPv4 note come dannose provenienti da Third-Party Feeds come Cybora, incluso il traffico verso il firewall stesso. Gli IoC di tipo dominio o URL non proteggono un accesso da un indirizzo IP di origine dannoso; le origini IPv6 non sono attualmente supportate. I Threat Feeds sono quindi una protezione aggiuntiva, non un sostituto di ACL restrittive. L’articolo collegato spiega la configurazione, i test e l’allowlisting.

SSH e regole di supporto temporanee

SSH dovrebbe essere accessibile solo quando necessario, da una rete di gestione, tramite VPN o per un IP di supporto fisso. È preferibile l’autenticazione Public Key. Dopo un intervento di supporto, l’eccezione ACL temporanea viene eliminata; non si dovrebbe presumere uno stato di disattivazione non confermato nell’interfaccia corrente. Ulteriori passaggi sono descritti in Connettersi a Sophos Firewall tramite SSH.

L’autorizzazione CLI non equivale all’autenticazione SSH: Secondo la descrizione del profilo per SFOS 22/23, il profilo Administrator concede pieno accesso alla CLI senza specificare il trasporto. La guida PuTTY per le stesse versioni richiede invece il nome utente admin per SSH di rete ed esclude altri nomi utente; questo vale anche per l’autenticazione con password. Da queste indicazioni non si deduce né la possibilità di usare SSH con account amministratore nominativi né una conclusione generale su ogni modalità di accesso alla CLI. La funzione Console di WebAdmin apre una console nel browser tramite l’accesso WebAdmin e non dimostra la possibilità di autenticarsi tramite SSH di rete. La possibilità per uno specifico account nominativo di utilizzare questo accesso via browser deve essere verificata separatamente in base alle sue autorizzazioni e al firmware installato. Anche la gestione delle chiavi, consentita solo all’amministratore predefinito, è un’autorizzazione distinta e non determina quali account possano autenticarsi tramite SSH con password.

Verificare il percorso di recupero effettivo prima di modificare un’ACL: Per il percorso SSH di rete documentato, utilizzare l’account integrato admin con le credenziali attuali oppure con una chiave configurata per tale account. Autenticarsi tramite l’accesso scelto in una nuova sessione, aprire la console necessaria e annotare account, trasporto e versione del firmware nel registro della modifica; la sola raggiungibilità di una porta TCP non è sufficiente. Un accesso funzionante alla Console nel browser continua a dipendere dal percorso WebAdmin e non costituisce un percorso di recupero indipendente se quest’ultimo viene bloccato. Se è necessario un account nominativo come percorso di recupero SSH o se il comportamento osservato contraddice la guida, interrompere la modifica, mantenere un accesso autorizzato già testato e chiarire con Sophos Support l’ambito esatto degli account e dei trasporti interessati. Non ampliare l’ACL e non usare tentativi di autenticazione ripetuti al posto di questo chiarimento.

Eliminare un’eccezione scaduta in Administration > Device access > Local service ACL exception rule con Delete sulla regola interessata e confermare con OK. Prima, verificare il percorso amministrativo da mantenere; dopo, controllare che la vecchia origine di supporto non possa più connettersi. Una data di scadenza annotata qui è un obbligo di revisione, non la prova di un meccanismo di eliminazione automatica.

Troubleshooting

Se un login diventa improvvisamente irraggiungibile, verificare anche Administration > Admin and user settings > Login security > Block login. Questo blocco per IP sorgente dipende dagli accessi non riusciti e può interessare WebAdmin, CLI, VPN Portal e User Portal. Non è una regola ACL. I tentativi CAPTCHA falliti non vengono conteggiati come questi tentativi di accesso. Verificare la durata configurata del blocco e gli eventi invece di abilitare HTTPS per un’intera zona o disattivare indiscriminatamente la protezione.

Se un servizio locale non è accessibile o bloccato come previsto, verificare quanto segue nell’ordine indicato:

1. Destinazione e porta: l’indirizzo del firewall è corretto e il servizio utilizza la porta prevista?
2. Zona di origine: il client proviene direttamente dalla zona prevista, tramite VPN o tramite Web Proxy?
3. Tabella delle zone: il servizio è consentito per questa zona in Administration > Device access?
4. Eccezioni ACL: IP version, Source zone, oggetto di origine, Destination host, Service, Action e Position sono corretti?
5. Port Sharing: VPN Portal e SSL VPN condividono porta e protocollo?
6. API: attivazione API, Allowed IP hosts e HTTPS Device Access sono tutti coerenti?
7. DNS: DNS è consentito per i client interni? Per la pubblicazione WAN è inoltre necessario Publish on WAN.
8. Log: il Log Viewer mostra eventi aggiuntivi relativi al servizio o all’accesso?
9. Packet Capture: avviare Trace prima di ripetere il test. L’accesso consentito deve funzionare e mostra generalmente Status: Consumed; il tentativo bloccato mostra generalmente Status: Violation e Reason: LOCAL_ACL. La Rule-ID non è l’ID dell’eccezione ACL. L’utilizzo è descritto in Sophos Firewall Packet Capture.

Se WebAdmin o un portale rimangono accessibili nonostante la zona di origine sia disattivata, verificare innanzitutto Web Proxy e Port Sharing. Una regola firewall aggiuntiva non risolve questo problema.

Per una tracciabilità a lungo termine sono adatti Central Firewall Reporting o Inviare i log di Sophos Firewall a un SIEM tramite Syslog.

Checklist operativa

• WebAdmin non è accessibile indiscriminatamente da WAN, zone guest, IoT o VoIP.
• HTTPS, SSH e SNMP sono limitati a origini di gestione o monitoraggio specifiche.
• User Portal, VPN Portal e SSL VPN sono attivi solo se richiesti dal modello operativo.
• VPN Portal e SSL VPN non condividono la stessa porta e lo stesso protocollo.
• L’accesso tramite Web Proxy ai servizi locali HTTP/HTTPS è stato testato separatamente.
• API access, Allowed IP hosts e HTTPS Device Access sono coordinati.
• Le eccezioni ACL temporanee contengono scopo e data di scadenza e vengono eliminate dopo l’intervento.
• Sono state testate origini consentite e bloccate; i log confermano il risultato.
• Le regole vengono controllate regolarmente per individuare origini obsolete, servizi non necessari ed eccezioni Accept troppo ampie.

Precisazioni sulle fonti

STAS fornisce l’autenticazione degli utenti; non è una VPN né un canale amministrativo cifrato. Il permesso per il suo servizio di autenticazione non sostituisce un percorso di gestione protetto.

Le istruzioni conservate sulle chiavi SSH di SFOS 22/23 sono ambigue: specificano RSA/DSA con almeno 2048 bit ed elencano ECDSA escludendo ED25519. Non dedurre il supporto di ED25519 né considerare DSA una raccomandazione. Prima della registrazione, confermare l’algoritmo supportato dal firmware effettivo; caricare solo la chiave pubblica e conservare un percorso di recupero separato. Un’autorizzazione Device Access non convalida un algoritmo di chiave.

Adaptive Learning include anche gli URL dei virus rilevati, nomi/URL/indirizzi IP delle minacce, indirizzi IP di origine e applicazioni utilizzate. La reportistica HTTPS predefinita comprende dati del dispositivo, firmware e licenze (senza informazioni sul proprietario), stato di funzionalità/HA/gestione cloud, conteggi degli oggetti, errori e percentuali di utilizzo di CPU/memoria/disco. È una decisione sulla condivisione dei dati, non un controllo ACL. Sophos Assistant è attivo per impostazione predefinita; per disattivarlo, deselezionare Turn on Sophos Assistant in Administration > Admin and user settings, fare clic su Apply, quindi uscire e accedere di nuovo. Questo non disattiva la telemetria.

FAQ