Sophos Firewall: configurare Device Access in sicurezza

In Administration > Device access si definisce da quali zone sono accessibili i servizi locali di Sophos Firewall. Tra questi ci sono, ad esempio, HTTPS per la WebAdmin Console, SSH per la CLI, Ping, DNS, User Portal, VPN Portal e altri servizi.

Per il contesto generale di hardening, consultare l’hub Sophos Firewall Hardening: best practice per una configurazione sicura.

Questa area è critica per la sicurezza. Le normali regole del firewall controllano il traffico attraverso il firewall. Device access controlla il traffico verso il firewall stesso. Se WebAdmin o SSH sono accessibili da una zona non sicura, si crea un accesso diretto alla gestione del dispositivo di sicurezza.

È importante anche l’API: l’autorizzazione Device Access per HTTPS/WebAdmin influisce anche sugli accessi API. Da SFOS 22, le fonti di accesso API vengono gestite anche in Administration > API access, ma un host API consentito non aiuta se Device Access blocca l’accesso HTTPS locale da quella zona.

⚠️ WebAdmin, SSH e i portali dovrebbero essere accessibili solo da reti fidate. Per ambienti produttivi è meglio limitare l’accesso a una rete di gestione, un IP amministrativo fisso, VPN o Sophos Central Firewall Management.

Nella pratica, questa distinzione aiuta:

• Tabella delle zone Device Access: consentire o bloccare un servizio in modo generale per zona, ad esempio DNS per LAN, Ping per una zona di monitoraggio o SSL VPN per una zona di accesso remoto necessaria.
• Local Service ACL Exception Rule: controllare l’accesso in modo più preciso per origine, destinazione e servizio, ad esempio WebAdmin solo dalla rete di gestione, SSH solo da un IP di supporto o SNMP solo dal sistema di monitoraggio.
• Regola firewall normale: consentire o bloccare il traffico attraverso il firewall, ad esempio quando un client da LAN accede a un server in DMZ o a un servizio internet.

Questo chiarisce il punto: una regola firewall non sostituisce l’hardening di Device Access. Se HTTPS o SSH è raggiungibile in modo troppo ampio tramite Device Access, un client raggiunge il servizio locale del firewall prima ancora che una classica regola di transito sia il punto di controllo corretto.

Perché Device Access non funziona come una regola del firewall

Una tipica regola del firewall consente o blocca le connessioni tra zone, ad esempio da LAN a WAN o da VPN a Server. Device Access è diverso: riguarda i servizi che girano direttamente su Sophos Firewall.

Esempi:

• Un amministratore apre https://172.16.16.16:4444.
• Un client utilizza il firewall come server DNS.
• Un sistema di monitoraggio pinga il firewall.
• Un utente apre il User Portal o il VPN Portal.
• Un amministratore si connette tramite SSH al firewall.

Questo tipo di traffico non ha come destinazione un server dietro il firewall, ma il firewall stesso. Per questo viene gestito tramite la Local Service ACL.

Questo è anche il motivo per cui Device Access è parte integrante del rafforzamento di ogni Sophos Firewall. Un set di regole pulito da LAN a WAN non protegge automaticamente i servizi di gestione e portale del firewall stesso. Questi servizi devono essere esaminati separatamente e limitati consapevolmente.

Comprendere le autorizzazioni delle zone

Nella parte superiore di Administration > Device access si vede una tabella con zone e servizi. Se un servizio è attivato per una zona, da quella zona è generalmente possibile accedere a quel servizio locale.

La tabella delle zone è pratica, ma grossolana e adatta per zone interne chiare, come LAN, Management o VPN. Non appena un servizio deve essere accessibile solo per singoli indirizzi IP amministrativi, sedi, paesi o obiettivi di supporto, le Local service ACL exception rules sono la scelta migliore.

Per le Custom Zones si dovrebbero controllare anche le impostazioni della zona. Anche lì i servizi locali possono essere influenzati. Tuttavia Administration > Device access resta il punto centrale in cui autorizzare o limitare consapevolmente i servizi locali del firewall.

Esempi tipici:

• HTTPS: accesso WebAdmin dalla rete di gestione. Non consentire ampiamente da WAN.
• SSH: accesso CLI per amministratori o supporto. Consentire solo in modo mirato, preferibilmente con chiave pubblica.
• Ping/Ping6: monitoraggio e test di raggiungibilità semplici. Non attivare inutilmente da zone non sicure.
• DNS: i client utilizzano il firewall come resolver DNS. Attivare solo per zone client interne.
• SSL VPN: gli utenti SSL VPN stabiliscono una connessione al firewall. Aperto esternamente solo quanto necessario e protetto con MFA; controllare separatamente la porta nell’area Remote Access.
• User Portal: gli utenti scaricano configurazioni VPN o token. Preferibilmente accessibile tramite VPN/ZTNA o strettamente limitato.
• VPN Portal: utenti VPN di accesso remoto. Solo se veramente necessario e protetto con MFA.
• RED: le appliance RED si connettono al firewall. Consentire solo per sedi RED reali o fonti definite.
• SMTP Relay: sistemi interni utilizzano il firewall come SMTP Relay. Non consentire come relay aperto da zone non sicure.
• SNMP: il monitoraggio interroga i valori del firewall. Consentire solo dal sistema di monitoraggio; i dettagli sono in Monitoraggio hardware SNMP.
• Dynamic Routing: protocolli di routing tra router e firewall. Attivare solo nei segmenti di rete previsti.

In SFOS 22, WebAdmin, VPN Portal e User Portal supportano TLS 1.3. Questo è positivo per la cifratura, ma non cambia il principio di base: un servizio raggiungibile da troppe fonti rimane una superficie di attacco inutile. La cifratura del trasporto non sostituisce una ACL pulita.

Quali servizi possono essere limitati tramite ACL Rules?

Tramite Local Service ACL e ACL Exception Rules è possibile controllare in modo molto preciso i servizi locali del firewall. Questi servizi sono particolarmente rilevanti:

• DNS: il firewall risponde a richieste DNS da reti che non dovrebbe servire.
• Dynamic Routing: i protocolli di routing sono accessibili da segmenti errati.
• HTTPS: la WebAdmin Console è accessibile da troppe fonti.
• Ping/Ping6: il firewall è inutilmente visibile e scansionabile.
• RED: i servizi RED sono accessibili da aree di origine troppo ampie.
• SMTP Relay: configurazioni errate possono favorire l’abuso del relay.
• SNMP: i dati di monitoraggio sono interrogabili da reti errate.
• SSH: l’accesso diretto alla CLI del firewall è troppo aperto.
• SSL VPN: i punti di accesso VPN sono raggiungibili a livello mondiale e vengono scansionati.
• User Portal: il login al portale e i download VPN sono inutilmente esposti.
• VPN Portal: il portale di accesso remoto è bersaglio di bot e tentativi di forza bruta.

Più questi servizi sono accessibili da WAN, reti ospiti, reti IoT o zone definite in modo impreciso, maggiore è la superficie di attacco. L’obiettivo non è disattivare tutto, ma rendere ogni servizio accessibile solo dove è veramente necessario.

Definire le fonti di accesso il più strettamente possibile

Una ACL Rule non deve semplicemente consentire Any. Come fonte si può lavorare in modo molto preciso, ad esempio con:

• singoli indirizzi IP amministrativi
• reti di gestione
• intervalli IP
• liste IP
• host FQDN
• gruppi di host FQDN
• host DNS o gruppi DNS
• oggetti paese o gruppi di paesi
• reti VPN o di supporto dedicate

In questo modo è possibile limitare l’accesso in modo molto più efficace. Un esempio: se un servizio di supporto esterno proviene solo da un FQDN fisso o da un intervallo IP definito, non dovrebbe essere consentito l’accesso all’intera zona WAN su HTTPS o SSH. Se un sistema di monitoraggio necessita di SNMP, non dovrebbe essere consentito a un’intera rete server di interrogare SNMP sul firewall.

Nei scenari di accesso remoto globali, la delimitazione è più difficile. Alcune aziende non possono semplicemente consentire SSL VPN o VPN Portal solo per la Svizzera, la Germania o un singolo paese, poiché i dipendenti sono in viaggio in tutto il mondo. In questi casi, si dovrebbe lavorare anche con MFA, logging, impostazioni restrittive del portale e Threat Feeds.

Modello decisionale per i servizi locali

Per ogni servizio locale si dovrebbe decidere consapevolmente quale livello di accesso è appropriato. Raramente è sensato trattare WebAdmin, SSH, User Portal, VPN Portal, DNS e SNMP allo stesso modo.

• Disattivato: appropriato se il servizio non è necessario nell’ambiente. Esempio: SSH disattivato permanentemente se non è previsto l’accesso alla CLI.
• Solo zona interna: appropriato se il servizio è necessario per molti client interni. Esempio: DNS da LAN, se i client utilizzano il firewall come resolver DNS.
• Rete di gestione: appropriato per servizi amministrativi o di monitoraggio. Esempio: HTTPS, SSH e SNMP solo da Management.
• Admin-VPN: appropriato se gli amministratori devono lavorare dall’esterno, ma non direttamente da Internet. Esempio: WebAdmin accessibile solo tramite VPN.
• ACL Exception Rule: appropriato se l’accesso deve provenire da una fonte molto specifica. Esempio: un IP di supporto può accedere temporaneamente a HTTPS o SSH.
• Ampiamente accessibile da WAN: solo per servizi di accesso remoto reali e con protezione aggiuntiva. Esempio: SSL VPN per utenti mobili con MFA, logging e Threat Feeds.

Questa decisione dovrebbe essere documentata. Soprattutto per le eccezioni da WAN, deve essere possibile capire in seguito perché il servizio è accessibile, chi ne ha bisogno e quando l’eccezione verrà riesaminata.

L’accesso WAN è un’eccezione

WAN non è semplicemente un’altra zona. Tutto ciò che è accessibile da WAN viene trovato da scanner, bot e strumenti di forza bruta. Pertanto, WebAdmin da WAN non dovrebbe essere pianificato come variante operativa normale.

Se è necessario l’accesso alla gestione esterna, queste varianti sono generalmente più sicure:

• Sophos Central Firewall Management per compiti amministrativi.
• Admin-VPN con MFA e gruppo di utenti chiaro.
• Una ACL Exception Rule temporanea per un IP di origine fisso.
• Una rete di gestione dedicata tramite VPN site-to-site.

Per il quadro generale del rafforzamento, si adatta anche Utilizzare correttamente il Sophos Firewall Health Check, poiché lì vengono valutati insieme gli accessi alla gestione, MFA, backup e igiene delle regole.

Sophos protegge inoltre WebAdmin dall’essere autorizzato per tutte le fonti WAN. Se l’accesso WAN è davvero necessario, deve essere limitato tramite fonti specifiche come singoli IP, reti o oggetti FQDN. Le vecchie autorizzazioni ampie provenienti da configurazioni precedenti dovrebbero essere controllate regolarmente: Sophos può disattivare automaticamente alcune autorizzazioni WAN ampie per WebAdmin o User Portal dopo un periodo prolungato di inattività, mentre le eccezioni ACL mirate per fonti WAN concrete possono continuare a valere.

Local Service ACL Exception Rule

Se un servizio non deve essere reso disponibile per un’intera zona, si utilizza una Local service ACL exception rule. Con essa è possibile definire con precisione chi può accedere a quale servizio locale.

Percorso:

1. Aprire Administration.
2. Selezionare Device access.
3. Scorrere fino a Local service ACL exception rule.
4. Fare clic su Add.

Procedura tipica per un’eccezione amministrativa stretta dal WAN:

1. Impostare Rule name, ad esempio admin-https-from-support-ip.
2. Impostare Rule position su Top se una regola Drop o Allow esistente potrebbe altrimenti intervenire prima.
3. Selezionare la IP version adatta alla fonte, di solito IPv4.
4. Impostare Source zone su WAN.
5. Impostare Source Network / Host sull’IP amministrativo concreto, su una piccola rete amministrativa o su un oggetto FQDN/IP mantenuto.
6. Limitare Destination host all’indirizzo o all’interfaccia firewall interessata, se non sono volutamente intesi tutti i target locali.
7. Impostare Services sul servizio locale necessario, ad esempio HTTPS per WebAdmin o API, non contemporaneamente HTTPS e SSH per comodità.
8. Impostare Action su Accept.
9. Salvare e testare subito da una fonte consentita e da una non consentita.

Una ACL Exception Rule è composta essenzialmente da questi campi:

• Rule name: nome univoco, ad esempio admin-https-from-mgmt.
• Rule position: ordine delle regole ACL.
• Source zone: zona da cui proviene l’accesso, ad esempio WAN, LAN o VPN.
• Source Network / Host: IP amministrativo consentito, rete di gestione, host FQDN o lista IP.
• Destination host: IP del firewall o interfaccia a cui si accede.
• Services: servizio locale, ad esempio HTTPS, SSH, Ping o DNS.
• Action: Accept o Drop.

Per l’accesso WebAdmin da Internet non si dovrebbe mai utilizzare Any come fonte. Sophos impedisce consapevolmente l’accesso WebAdmin dalla zona WAN per tutte le fonti, poiché ciò rappresenterebbe un alto rischio. Se l’accesso WAN è veramente necessario, dovrebbe essere consentito solo tramite indirizzi IP di origine specifici, reti definite, oggetti FQDN o altre fonti ristrette.

La stessa logica vale per l’automazione API. Un host può essere consentito in Administration > API access e fallire comunque se manca l’autorizzazione HTTPS in Device Access. Al contrario, un’autorizzazione HTTPS non dovrebbe diventare più ampia solo perché viene collegato uno strumento API. Per i dettagli API, vedere limitare in modo sicuro l’accesso API a Sophos Firewall.

È importante anche l’ordine. Le ACL Exception Rules vengono valutate dall’alto verso il basso. Una regola Drop superiore può rendere inefficace una regola Accept successiva. Al contrario, una regola Accept formulata troppo ampiamente può vanificare restrizioni pianificate successivamente. Pertanto, l’ordine delle regole dovrebbe essere esaminato con la stessa attenzione delle regole del firewall.

Il Destination host è particolarmente importante se il firewall ha più interfacce, indirizzi alias, indirizzi VPN o destinazioni separate per portali/amministrazione. Una regola dovrebbe puntare il più precisamente possibile all’indirizzo del firewall che deve davvero essere amministrato o utilizzato. Altrimenti un’autorizzazione di origine apparentemente stretta può applicarsi improvvisamente a più servizi locali o interfacce del previsto.

Evitare il blocco prima della modifica

Le modifiche a Device Access influenzano direttamente gli accessi alla gestione e ai portali. Pertanto, prima di ogni restrizione, dovrebbe essere chiaro come accedere nuovamente al firewall se una regola viene applicata in modo errato.

Prima di salvare una modifica rischiosa, si dovrebbe verificare:

• È disponibile un secondo amministratore con un profilo di diritti adeguato?
• È disponibile l’accesso tramite un’altra rete, ad esempio Management-LAN, Admin-VPN o Sophos Central?
• È disponibile l’accesso alla console locale o Out-of-Band, nel caso in cui WebAdmin non sia più accessibile?
• Si sta lavorando su un cluster HA in cui un cambio di ruolo può modificare il percorso di accesso?
• Sono documentati il file di backup attuale, il Secure Storage Master Key e l’accesso di emergenza?
• È disponibile una breve finestra di manutenzione in cui gli accessi errati vengono immediatamente notati?

Soprattutto nei siti remoti, non si dovrebbe prima rimuovere l’autorizzazione ampia e poi testare. È più sicuro il processo inverso: creare una nuova ACL Exception Rule stretta, testare l’accesso consentito, confermare il secondo percorso amministrativo e solo allora ridurre l’autorizzazione ampia della zona.

Distribuire le modifiche in modo sicuro

Le modifiche a Device Access possono escludere gli amministratori. Pertanto, non dovrebbero essere modificate casualmente, ma trattate come una modifica di gestione.

Procedura collaudata:

1. Documentare l’accesso attuale: WebAdmin, SSH, User Portal, VPN Portal, SSL VPN, DNS, SNMP e Ping.
2. Assicurarsi che sia disponibile un secondo percorso amministrativo, ad esempio console locale, Admin-VPN o Sophos Central.
3. Creare un backup prima di implementare modifiche ACL più grandi.
4. Creare una nuova ACL Exception Rule il più specifica possibile.
5. Testare l’accesso dalla fonte consentita.
6. Testare l’accesso da una fonte non consentita.
7. Controllare il Log Viewer per vedere se gli eventi previsti sono visibili.
8. Rimuovere l’autorizzazione ampia della zona solo quando il nuovo accesso è confermato.
9. Documentare la modifica con data, fonte, servizio e responsabile.

Se sono coinvolti più firewall o cluster HA, la modifica dovrebbe essere testata prima su un sistema con una buona possibilità di rollback. Per ambienti HA, si adatta anche Configurare Sophos Firewall High Availability, poiché gli accessi alla gestione, i cambi di ruolo e le finestre di manutenzione devono essere considerati insieme.

Controllo post-modifica dopo le modifiche a Device Access

Dopo una modifica, non basta controllare solo l’accesso a WebAdmin. Si dovrebbero testare sia le fonti consentite che quelle non consentite, altrimenti non è chiaro se il rafforzamento funziona davvero.

• WebAdmin dalla rete di gestione: l’accesso funziona come previsto.
• WebAdmin dalla rete client normale: l’accesso è bloccato, se non espressamente consentito.
• SSH dalla rete amministrativa: l’accesso funziona solo se SSH è stato consapevolmente autorizzato.
• SSH da WAN o rete ospite: l’accesso è bloccato.
• DNS dalla rete client: DNS funziona solo nelle reti che dovrebbero utilizzare il firewall come resolver.
• User Portal o VPN Portal: solo i portali necessari sono accessibili.
• SNMP dal sistema di monitoraggio: il monitoraggio funziona, altre fonti sono bloccate.

Se un accesso funziona inaspettatamente, non si dovrebbe controllare solo la ACL Exception Rule. Anche la tabella delle zone nella parte superiore di Device Access, le impostazioni delle Custom Zone, la zona VPN, il comportamento del proxy e le regole Accept ampie esistenti possono essere la causa.

Per la documentazione è spesso sufficiente una breve lista per servizio:

• HTTPS: fonte consentita mgmt-net, motivo Accesso amministrativo WebAdmin, review trimestrale.
• SSH: fonte consentita support-ip-temporary, motivo Caso di supporto, review dopo la chiusura del ticket.
• SNMP: fonte consentita monitoring-server, motivo Monitoraggio hardware e interfaccia, review semestrale.
• SSL VPN: fonte consentita WAN, motivo Accesso remoto, review con controllo mensile dei log.

Durante ogni controllo successivo si dovrebbe verificare anche se gli accessi riusciti e bloccati sono effettivamente visibili. Per test brevi spesso basta il Log viewer. Per conservazione più lunga o domande di audit, Central Reporting o Syslog sono più adatti, perché i log locali possono ruotare o andare persi in caso di guasto.

Configurazione di base consigliata

Per molti ambienti produttivi, la seguente logica è sensata:

• Consentire HTTPS/WebAdmin solo da Management, Admin-VPN o un IP amministrativo fisso.
• Consentire API solo da host di automazione o monitoraggio definiti e limitare inoltre HTTPS tramite Device Access in modo appropriato.
• SSH disattivato di default e consentito solo se necessario tramite ACL.
• DNS attivato solo nelle zone in cui i client utilizzano effettivamente il firewall come server DNS.
• Ping consentito per i sistemi di monitoraggio interni, ma non in modo generico da WAN.
• User Portal, VPN Portal e SSL VPN attivati solo se necessari.
• RED consentito solo per sedi o aree di origine in cui sono effettivamente presenti appliance RED.
• SNMP consentito solo dal sistema di monitoraggio.
• SMTP Relay consentito solo per sistemi interni definiti.
• Dynamic Routing attivato solo nei segmenti di routing in cui vengono effettivamente utilizzati protocolli di routing dinamici.
• MFA per WebAdmin, VPN Portal e Accesso remoto; l’installazione è descritta in Attivare MFA per Sophos Firewall WebAdmin, VPN Portal e Accesso remoto.
• Utilizzare Sophos Central Firewall Management se è necessario un accesso di gestione esterno sicuro.

Per una tracciabilità più lunga, si dovrebbe anche controllare la strategia di logging. I log locali sono sufficienti per la ricerca di errori acuti, ma non per ogni domanda di audit o risposta agli incidenti. Se gli accessi ai portali o alla gestione devono essere tracciabili a lungo termine, Central Firewall Reporting o Inviare il Syslog di Sophos Firewall a SIEM sono i componenti più adatti.

Trattare SSH con particolare cautela

SSH è molto utile per il troubleshooting e il supporto, ma non dovrebbe essere aperto in modo ampio e permanente. Per SSH vale:

• Solo l’utente admin può accedere tramite SSH.
• L’autenticazione con chiave pubblica è il metodo preferito.
• L’accesso da WAN dovrebbe avvenire solo tramite indirizzi IP di origine fissi o VPN.
• Dopo il completamento di un’analisi, si dovrebbe verificare se SSH è ancora necessario.

Maggiori dettagli sono disponibili nella guida Connettersi a Sophos Firewall tramite SSH.

Bot, forza bruta e Threat Feeds

Nella pratica si vede molto spesso che i servizi troppo aperti vengono immediatamente trovati dai bot. Particolarmente colpiti sono WebAdmin, User Portal, VPN Portal e SSL VPN. Anche se un servizio è protetto da password e MFA, i login pubblici generano tentativi di attacco, traffico di forza bruta, rumore nei log e carico inutile sul firewall.

Questo non significa automaticamente che si stia verificando un attacco riuscito. Mostra però che il servizio è parte della superficie di attacco pubblica. Meno fonti arrivano al login, meglio è.

Se un portale deve essere accessibile a livello mondiale, spesso i filtri per paese o singoli indirizzi IP di origine non sono sufficienti. In tali ambienti, si raccomanda di utilizzare anche Third-Party Threat Feeds. I Threat Feeds forniscono al firewall indicatori di compromissione aggiornati, come indirizzi IP, domini o URL dannosi. Scanner noti, botnet e aggressori possono essere bloccati prima che raggiungano WebAdmin, VPN Portal, SSL VPN o altri servizi pubblicati.

L’articolo dedicato Sophos Firewall Threat Feeds spiega pianificazione, allowlisting e operatività.

Errori comuni

Regola del firewall controllata invece di Device Access

Se WebAdmin, SSH, DNS o Ping non sono accessibili al firewall, una normale regola del firewall non aiuta. Il traffico non attraversa il firewall, ma termina sul firewall stesso. Pertanto, deve essere controllato Administration > Device access.

WebAdmin consentito da troppe zone

WebAdmin non dovrebbe essere accessibile da ogni zona interna. Una rete ospite, una rete IoT o una rete VoIP di solito non hanno bisogno di accedere alla gestione del firewall. Anche internamente, si dovrebbe presumere che possano esistere client compromessi. Una rete di gestione separata o un Admin-VPN riducono notevolmente questo rischio.

DNS non attivato per la zona client

Se i client devono utilizzare il firewall come server DNS, DNS deve essere consentito per la zona appropriata. Altrimenti, i client raggiungono l’IP del firewall, ma non ricevono una risposta DNS. Al contrario, DNS non dovrebbe essere consentito da zone in cui il firewall non dovrebbe essere utilizzato come resolver DNS.

Confusione tra User Portal e VPN Portal

User Portal e VPN Portal sono servizi diversi. A seconda del concetto di accesso remoto, deve essere verificato quale portale è veramente necessario. Spesso un portale viene attivato perché un utente ha dovuto scaricare una configurazione una volta, ma poi rimane aperto per anni. Tali carichi storici dovrebbero essere rimossi regolarmente.

Se i portali devono restare accessibili da Internet, non basta controllare la checkbox. Sono importanti MFA, gruppi utenti, processo di token/provisioning, scadenza degli utenti temporanei, logging e la domanda se il portale sia ancora necessario in modo permanente dopo il rollout.

Caso speciale del proxy web trascurato

Se viene utilizzato il proxy web, le richieste HTTP e HTTPS possono apparire internamente dal punto di vista del proxy. Questo può influenzare il modo in cui vengono controllati gli accessi a WebAdmin, Captive Portal, VPN Portal o User Portal. In ambienti con proxy, si dovrebbe quindi testare con particolare attenzione quali accessi sono realmente possibili.

Regola ACL formulata troppo ampiamente

Una ACL Exception Rule con Source zone: Any, Source Network / Host: Any e Services: HTTPS, SSH non è quasi mai una buona idea. Tali regole aggirano il vero vantaggio di sicurezza dell’eccezione ACL. È meglio una regola piccola e chiara con una fonte univoca e solo i servizi necessari.

Regola Drop nella posizione sbagliata

Se una regola Drop si trova sopra una regola Accept, l’accesso consentito può comunque essere bloccato. Con le ACL Exception Rules, l’ordine è quindi importante quanto con le regole del firewall.

Al contrario, una regola Accept ampia in cima alla lista può rendere praticamente inutili le Drop Rules successive. Dopo ogni modifica alle regole si dovrebbe quindi controllare non solo la nuova regola, ma anche la logica di match delle regole sopra di essa.

SSL VPN e VPN Portal lasciati troppo aperti

L’accesso remoto deve spesso essere accessibile dall’esterno. Tuttavia, si dovrebbe verificare se tutti i paesi, le reti e i gruppi di utenti hanno veramente bisogno di accesso. Se non è possibile una limitazione stretta delle fonti, MFA, logging e Threat Feeds dovrebbero essere utilizzati in modo ancora più coerente.

Risoluzione dei problemi

Se un servizio locale non è accessibile, questa è la sequenza da seguire:

1. L’IP di destinazione del firewall è corretto?
2. Il client proviene dalla zona prevista?
3. Il servizio è consentito in Administration > Device access per questa zona?
4. Esiste una Local service ACL exception rule appropriata?
5. Una regola ACL superiore con Drop è in vigore?
6. Il servizio è configurato su una porta diversa?
7. L’accesso viene visto in modo diverso tramite VPN, proxy o NAT rispetto a quanto previsto?
8. Il Log Viewer mostra un’indicazione?
9. Packet Capture può vedere il tentativo di connessione sull’interfaccia?

Per gli accessi di supporto, può essere utile creare una ACL Exception Rule mirata e rimuoverla o disattivarla dopo il completamento.

Lista di controllo operativa

• WebAdmin non accessibile ampiamente da WAN.
• SSH consentito solo temporaneamente o da reti di gestione/amministrative.
• DNS attivo solo per le zone client che utilizzano effettivamente il firewall come resolver.
• SNMP consentito solo dal sistema di monitoraggio o dalla rete di monitoraggio.
• User Portal, VPN Portal e SSL VPN attivi solo se necessari nel concetto di accesso remoto.
• MFA per WebAdmin, VPN Portal e Accesso remoto verificato.
• ACL Exception Rules con fonte, servizio e scopo chiari nominati.
• Regole di supporto temporanee documentate con data di scadenza.
• Accesso testato da fonti consentite e non consentite.
• Logging, Central Reporting o Syslog per accessi ai portali e alla gestione rilevanti verificati.
• Review trimestrale pianificata per WebAdmin, SSH, SNMP, User Portal, VPN Portal e SSL VPN.

FAQ