Proteggere l'accesso a Sophos Firewall: Device Access

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

Questa sezione è critica per la sicurezza. Le normali regole firewall controllano il traffico attraverso la firewall. Device access controlla il traffico verso la firewall stessa. Se WebAdmin o SSH sono raggiungibili da una zona non affidabile, si crea un accesso diretto di gestione al dispositivo di sicurezza.

⚠️ WebAdmin, SSH e i portali dovrebbero essere raggiungibili solo da reti affidabili. In ambienti produttivi è meglio limitare l’accesso a una rete di management, un IP admin fisso, VPN o Sophos Central Firewall Management.

Perché Device Access non è una regola firewall

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

Esempi:

• Un admin apre https://172.16.16.16:4444.
• Un client usa la firewall come server DNS.
• Un sistema di monitoring invia ping alla firewall.
• Un utente apre User Portal o VPN Portal.
• Un admin si collega alla firewall via SSH.

Questo traffico non ha come destinazione un server dietro la firewall, ma la firewall stessa. Per questo viene controllato tramite la local service ACL.

Questo è anche il motivo per cui Device Access fa parte dell’hardening di base di ogni Sophos Firewall. Un set di regole LAN-to-WAN pulito non protegge automaticamente i servizi di management e i portali della firewall. Questi servizi devono essere controllati e limitati separatamente.

Capire le autorizzazioni per zona

Nella parte superiore di Administration > Device access si trova una tabella con zone e servizi. Se un servizio è attivato per una zona, l’accesso a quel servizio locale è generalmente consentito da quella zona.

La tabella delle zone è pratica, ma ampia. Va bene per zone interne chiare, per esempio LAN, Management o VPN. Quando un servizio deve essere raggiungibile solo da singoli IP admin, sedi, paesi o destinazioni di supporto, le Local service ACL exception rules sono la scelta migliore.

Esempi tipici:

Per le Custom Zones, la raggiungibilità dei servizi locali può essere influenzata anche dalle impostazioni della zona. Tuttavia Device Access va sempre controllato consapevolmente, perché è la panoramica centrale dei servizi locali della firewall.

Quali servizi si possono limitare con ACL Rules?

Con Local Service ACL e ACL Exception Rules si possono controllare in modo molto preciso i servizi locali della firewall. Questi servizi sono particolarmente rilevanti:

Più questi servizi sono raggiungibili da WAN, reti guest, reti IoT o zone definite in modo impreciso, più cresce la superficie di attacco. L’obiettivo non è disattivare tutto, ma rendere ogni servizio raggiungibile solo dove serve davvero.

Definire le sorgenti nel modo più stretto possibile

Una ACL Rule non deve semplicemente consentire Any. Le sorgenti possono essere definite in modo molto preciso, per esempio con:

• singoli indirizzi IP admin
• reti di management
• IP ranges
• IP lists
• FQDN hosts
• FQDN host groups
• DNS hosts o DNS groups
• Country objects o gruppi di paesi
• reti VPN o supporto dedicate

In questo modo l’accesso si può limitare molto meglio. Esempio: se un servizio di supporto esterno arriva solo da un FQDN fisso o da un intervallo IP definito, non si dovrebbe dare a tutta la zona WAN accesso a HTTPS o SSH. Se un sistema di monitoring necessita SNMP, un’intera rete server non dovrebbe poter interrogare SNMP sulla firewall.

Negli scenari Remote Access globali la limitazione è più difficile. Alcune aziende non possono consentire SSL VPN o VPN Portal solo dalla Svizzera, dalla Germania o da un singolo paese, perché gli utenti lavorano in tutto il mondo. In questi casi bisogna aggiungere MFA, logging, impostazioni dei portali restrittive e Threat Feeds.

Local Service ACL Exception Rule

Se un servizio non deve essere abilitato per un’intera zona, si usa una Local service ACL exception rule. In questo modo si definisce 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. Cliccare Add.

Una ACL Exception Rule è composta principalmente da questi campi:

Per l’accesso WebAdmin da Internet non si dovrebbe mai usare Any come sorgente. Sophos impedisce intenzionalmente l’accesso WebAdmin dalla zona WAN per tutte le sorgenti, perché sarebbe un rischio elevato. Se l’accesso WAN è davvero necessario, va consentito solo tramite IP sorgente specifici, reti definite, oggetti FQDN o altre sorgenti strette.

Anche l’ordine è importante. Le ACL Exception Rules vengono valutate dall’alto verso il basso. Una regola Drop più alta può rendere inefficace una regola Accept successiva. Al contrario, una regola Accept troppo ampia può aggirare restrizioni previste. L’ordine delle regole va quindi verificato con la stessa attenzione delle regole firewall.

Configurazione di base consigliata

Per molti ambienti produttivi è sensata questa logica:

• Consentire HTTPS/WebAdmin solo da Management, admin VPN o un IP admin fisso.
• Disattivare SSH di default e consentirlo solo se necessario tramite ACL mirata.
• Attivare DNS solo nelle zone in cui i client usano davvero la firewall come server DNS.
• Consentire Ping per i sistemi di monitoring interni, ma non in modo generico da WAN.
• Attivare User Portal, VPN Portal e SSL VPN solo se necessari.
• Consentire RED solo per sedi o intervalli sorgente dove esistono davvero appliance RED.
• Consentire SNMP solo dal sistema di monitoring.
• Consentire SMTP Relay solo per sistemi interni definiti.
• Attivare Dynamic Routing solo nei segmenti in cui vengono davvero usati protocolli di routing dinamico.
• Verificare MFA per WebAdmin, VPN Portal e Remote Access.
• Usare Sophos Central Firewall Management se serve un accesso di gestione esterno sicuro.

Trattare SSH con particolare prudenza

SSH è molto utile per troubleshooting e supporto, ma non dovrebbe restare ampiamente aperto. Per SSH vale:

• Solo l’utente admin può accedere via SSH.
• L’autenticazione con public key è il metodo preferito.
• L’accesso da WAN dovrebbe essere consentito solo tramite IP sorgente fissi o VPN.
• Dopo un’analisi, verificare se SSH è ancora necessario.

Maggiori dettagli: Connettersi a Sophos Firewall via SSH.

Bot, brute force e Threat Feeds

Nella pratica si vede spesso che servizi troppo aperti vengono trovati subito dai bot. WebAdmin, User Portal, VPN Portal e SSL VPN sono particolarmente esposti. Anche se un servizio è protetto da password e MFA, login pubblici generano tentativi di attacco, traffico brute-force, rumore nei log e carico inutile sulla firewall.

Questo non significa automaticamente che un attacco abbia successo. Mostra però che il servizio fa parte della superficie di attacco pubblica. Meno sorgenti possono arrivare fino al login, meglio è.

Se un portale deve essere raggiungibile in tutto il mondo, filtri paese o singoli IP sorgente spesso non bastano. In questi ambienti consigliamo anche Third-Party Threat Feeds. I Threat Feeds forniscono continuamente alla firewall Indicators of Compromise aggiornati, per esempio indirizzi IP, domini o URL malevoli. Scanner noti, botnet e aggressori possono così essere bloccati prima che raggiungano WebAdmin, VPN Portal, SSL VPN o altri servizi pubblicati.

Maggiori dettagli: Sophos Firewall Threat Feeds

Errori frequenti

Controllare una regola firewall invece di Device Access

Se WebAdmin, SSH, DNS o Ping verso la firewall non sono raggiungibili, una normale regola firewall non aiuta. Il traffico non attraversa la firewall, termina sulla firewall stessa. Va quindi verificato Administration > Device access.

WebAdmin consentito da troppe zone

WebAdmin non dovrebbe essere raggiungibile da ogni zona interna. Una rete guest, IoT o VoIP normalmente non ha bisogno di accesso alla gestione della firewall. Anche internamente bisogna considerare la possibilità di client compromessi. Una rete di management separata o admin VPN riduce nettamente questo rischio.

DNS non attivato per la zona client

Se i client devono usare la firewall come server DNS, DNS deve essere consentito per la zona corretta. Altrimenti i client raggiungono l’IP della firewall ma non ricevono risposta DNS. Al contrario, DNS non dovrebbe essere consentito da zone in cui la firewall non deve fare da DNS resolver.

Confondere User Portal e VPN Portal

User Portal e VPN Portal sono servizi diversi. A seconda del concetto Remote Access, bisogna verificare quale portale serva davvero. Spesso un portale viene attivato perché un utente doveva scaricare una configurazione una volta, poi resta aperto per anni. Questi residui vanno rimossi regolarmente.

Dimenticare il caso speciale del Web Proxy

Quando si usa Web Proxy, le richieste HTTP e HTTPS possono sembrare interne dal punto di vista del proxy. Questo può influire sul controllo degli accessi a WebAdmin, Captive Portal, VPN Portal o User Portal. Negli ambienti con proxy bisogna quindi testare con precisione quali accessi siano realmente possibili.

Regola ACL troppo ampia

Una ACL Exception Rule con Source zone: Any, Source Network / Host: Any e Services: HTTPS, SSH non è quasi mai una buona idea. Regole di questo tipo aggirano il vantaggio di sicurezza dell’eccezione ACL. Meglio una regola piccola e chiara, con una sorgente definita e solo i servizi necessari.

Regola Drop nella posizione sbagliata

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

SSL VPN e VPN Portal lasciati troppo aperti

Remote Access deve spesso essere raggiungibile dall’esterno. Bisogna comunque verificare se tutti i paesi, reti e gruppi utenti abbiano davvero bisogno di accesso. Se non è possibile limitare strettamente le sorgenti, MFA, logging e Threat Feeds diventano ancora più importanti.

Troubleshooting

Se un servizio locale non è raggiungibile, aiuta questa sequenza:

1. L’IP di destinazione della firewall è corretto?
2. Il client arriva dalla zona prevista?
3. Il servizio è consentito per questa zona in Administration > Device access?
4. Esiste una Local service ACL exception rule adatta?
5. Una regola ACL superiore con Drop corrisponde?
6. Il servizio è configurato su un’altra porta?
7. L’accesso viene visto diversamente a causa di VPN, proxy o NAT?
8. Log Viewer mostra un’indicazione?
9. Packet Capture vede il tentativo di connessione sull’interface?

Per accessi di supporto può essere utile creare una ACL Exception Rule mirata e rimuoverla o disattivarla al termine.

Ulteriori informazioni

• Sophos Firewall - Device access
• Sophos Firewall - Device access best practices
• Connettersi a Sophos Firewall via SSH
• Attivare MFA per Sophos Firewall WebAdmin, VPN Portal e Remote Access