Utilizzare correttamente IP host, servizi e gruppi in Sophos Firewall

Gli IP host e i servizi assegnano nomi comprensibili a indirizzi, reti e porte. Una regola firewall mostra così direttamente quale origine può comunicare con quale destinazione e servizio.

La decisione importante riguarda l’ambito corretto: un singolo indirizzo viene creato come IP, una sottorete come Network, un intervallo contiguo come IP range e una piccola raccolta di indirizzi singoli come IP list. Per TCP e UDP, un servizio descrive normalmente il Destination Port fisso, mentre il Source Port dinamico rimane invariato.

Per una nuova regola, il percorso più breve e sicuro parte dall’oggetto host più piccolo e adatto, passa per un servizio esistente o personalizzato e termina con una regola firewall strettamente limitata. Solo in seguito si considerano casi particolari come System Hosts, MAC Hosts e gruppi riutilizzabili. Prima di qualsiasi modifica successiva, Object Usage indica quali regole e Policies dipendono dall’oggetto.

Scegliere l’oggetto host adatto

In Hosts and services > IP host sono disponibili quattro tipi:

IP: un solo indirizzo IPv4 o IPv6, ad esempio un server, una stampante o un sistema di amministrazione.
Network: una sottorete completa con la relativa maschera di rete, ad esempio 198.51.100.0/24.
IP range: un intervallo contiguo, ad esempio da 203.0.113.10 a 203.0.113.20.
IP list: più indirizzi singoli non contigui. Una lista supporta al massimo 800 indirizzi IP e non può appartenere a una IP Host Group. La guida attuale di SFOS 22 contiene la frase «For IP list, use only class B IP addresses.» Poiché Sophos non chiarisce ulteriormente questa formulazione obsoleta basata sulle classi di rete, non se ne può dedurre il supporto di liste IPv4 o IPv6 arbitrarie.

Un FQDN Host è più adatto quando l’indirizzo di destinazione cambia ed esiste un nome DNS stabile. Risoluzione, wildcard e limiti sono spiegati in Utilizzare correttamente FQDN Hosts e Wildcard FQDN.

Come regola generale, si utilizza l’oggetto stabile più piccolo che descrive completamente il traffico necessario. Un oggetto di tipo IP copre un solo indirizzo ed è troppo ristretto per un’intera sottorete; una rete /24 sarebbe inutilmente ampia per un singolo server.

Creare un IP host passo per passo

L’esempio seguente rappresenta un singolo server di test:

Aprire Hosts and services > IP host e selezionare Add.
Inserire host_test_web come Name.
Impostare IP version su IPv4.
Selezionare IP come Type.
Inserire 192.0.2.10 in IP address.
Salvare con Save.

Gli indirizzi seguenti appartenenti a 192.0.2.0/24, 198.51.100.0/24 e 203.0.113.0/24 sono riservati agli esempi di documentazione. In una configurazione produttiva, tutti i nomi, gli indirizzi e le dimensioni delle reti devono essere sostituiti con i valori della rete reale.

Network, range e IP list

I campi cambiano in base al tipo selezionato:

Network: net_test_branch con 198.51.100.0 e /24 rappresenta l’intera rete di test. Deve essere inserito l’indirizzo di rete, non quello del gateway.
IP range: range_test_admins da 203.0.113.10 a 203.0.113.20 rappresenta un intervallo contiguo.
IP list: in list_test_hosts inserire, separati da virgole, solo indirizzi del proprio ambiente verificato. Data l’ambiguità dell’indicazione sulla classe B nella guida attuale, creare la lista effettiva sulla build SFOS in uso e convalidarla con una regola di test. La lista è adatta a pochi indirizzi singoli fissi, non a indicatori di compromissione che cambiano continuamente.

Per indirizzi IP, domini o URL dannosi gestiti dinamicamente, la funzione più adatta è costituita dai Threat Feeds in Sophos Firewall. Una IP list manuale non viene aggiornata automaticamente.

IP Host Groups

In Hosts and services > IP host group è possibile raggruppare host con lo stesso scopo funzionale. Un gruppo può contenere, ad esempio, tutti i sistemi di amministrazione autorizzati ed essere poi utilizzato in più regole.

Oltre ai Custom IP Hosts, possono appartenere a un gruppo anche gli host predefiniti delle interfacce, della Cellular WAN e di internet. L’appartenenza a un gruppo è distinta dalla possibilità di modificare l’oggetto host: un host di sistema non modificabile direttamente non è quindi automaticamente escluso dai gruppi. Restano invece esclusi gli host di sistema dinamici delle VPN Remote Access.

Si applicano tre limiti importanti:

Gli host IPv4 e IPv6 non possono appartenere alla stessa IP Host Group.
Un host normale può appartenere a più gruppi.
Un oggetto di tipo IP list non può essere aggiunto a una IP Host Group.

Per creare un piccolo gruppo di test IPv4 con host_test_web, creato in precedenza:

Aprire Hosts and services > IP host group e selezionare Add.
Inserire grp_test_servers come Name; adattare il nome allo scopo del gruppo.
Impostare IP version su IPv4, come per l’host di test esistente.
Selezionare host_test_web tramite Add new item. Gli altri membri devono condividere lo stesso scopo e la stessa versione IP.
Salvare con Save.

Riaprire quindi il gruppo e verificare la versione IP e i membri. Se un host desiderato non compare nella selezione, controllarne prima la versione IP e il tipo; non aggirare l’esclusione di una IP list o di un host di sistema VPN Remote Access con un oggetto sostitutivo inutilmente ampio.

I gruppi devono avere un significato comune. Un gruppo che combina server, client ed eccezioni temporanee può ridurre i clic, ma rende poi difficile capire perché una regola consenta l’accesso.

Comprendere gli host di sistema e di interfaccia

L’elenco degli IP host mostra le interfacce fisiche, compresi i moduli FleXi-Port aggiuntivi, e le interfacce virtuali create dall’utente. In Address details sono riportati l’indirizzo e la maschera di rete configurati in Network > Interfaces. In presenza di un valore inatteso, confrontare prima questa configurazione dell’interfaccia con i dati visualizzati; l’oggetto host gestito automaticamente non è il punto in cui modificare l’indirizzo.

SFOS crea automaticamente diversi oggetti host. Questi oggetti non devono essere ricreati come normali Custom Hosts né modificati nel posto sbagliato:

Gli Interface Hosts seguono la configurazione IP in Network > Interfaces e vengono modificati in tale posizione. Zone e interfacce in Sophos Firewall spiega il rapporto tra connessione, zona e regola.
Se, in base al design del provider e della rete, un indirizzo aggiuntivo deve essere associato localmente a un’interfaccia fisica, configurarlo come IP alias all’interfaccia fisica. Se un campo NAT non propone il relativo Interface Host, creare anche un Custom IP Host con quell’indirizzo e un nome chiaro. Usare lo stesso nome è solo una convenzione utile, non un requisito tecnico.
##WWAN1 viene creato quando si attiva la Cellular WAN, utilizza l’indirizzo IP dell’interfaccia WWAN e viene gestito dinamicamente.
##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW e ##ALL_RW rappresentano host dinamici di Remote Access.
##ALL_SSLVPN_RW contiene gli indirizzi IP assegnati dal firewall alle connessioni VPN SSL di accesso remoto stabilite con Sophos Connect. ##ALL_IPSEC_RW contiene gli indirizzi assegnati alle corrispondenti connessioni IPsec. ##ALL_RW riunisce gli indirizzi assegnati a entrambi i tipi di connessione; SFOS li aggiunge dinamicamente quando vengono stabilite le connessioni.
Gli altri System Hosts non possono essere modificati o eliminati come oggetti personalizzati.

Gli host dinamici di Remote Access non possono essere aggiunti a un’altra IP Host Group. I Physical Interface Hosts non sono disponibili in determinati campi NAT, tra cui Translated source e Translated destination. In tal caso può essere necessario un IP host separato con lo stesso indirizzo. Il nome deve indicare chiaramente il legame con l’interfaccia, in modo che non sembri un indirizzo indipendente.

Per gli host interni nella sottorete dell’alias, SFOS deve essere il gateway predefinito. Se un dispositivo a monte funge da gateway per il traffico di Sophos Firewall, deve disporre di un indirizzo IP in ogni sottorete alias interessata. Dopo la sostituzione di un firewall, voci ARP obsolete sui dispositivi a monte possono rendere temporaneamente irraggiungibile l’IP alias. In tal caso occorre prima controllare e aggiornare la loro cache ARP, non ampliare inutilmente la regola NAT.

Per le route SD-WAN in uscita verso internet, Sophos consiglia inoltre di scegliere Internet IPv4 group o gli host predefiniti inclusi come destinazione invece di Any. In questo modo la route resta limitata alle destinazioni IPv4 pubbliche e non trascina il traffico interno sullo stesso percorso solo perché l’oggetto di destinazione è troppo ampio.

A differenza degli host di sistema non modificabili, gli host internet predefiniti possono essere modificati ed eliminati. Prima di farlo, aggiornare Object Usage come descritto più avanti e verificare le regole e le route SD-WAN dipendenti. Questa eccezione riguarda gli host internet, non gli host di sistema dinamici VPN/WWAN; gli indirizzi delle interfacce continuano a essere modificati in Network > Interfaces.

Usare MAC hosts per dispositivi visibili direttamente

Un MAC host descrive un dispositivo a livello 2 e può contenere un singolo indirizzo o una lista. È adatto solo dove il firewall vede il vero indirizzo MAC sorgente. Dietro un router, una VPN o un NAT, normalmente vede il MAC del salto successivo e non quello del client originale. Per le regole instradate, un IP host o una rete è quindi in genere l’oggetto più stabile.

In Hosts and services > MAC host > Add, assegnare all’oggetto un nome descrittivo e scegliere MAC address o MAC list. L’indirizzo può essere scritto con i due punti, come 00:16:76:49:33:CE, oppure con i trattini, come 00-16-76-49-33-CE; più voci si separano con virgole. Una MAC list supporta al massimo 1.000 indirizzi MAC.

Un MAC host non è un’identità del dispositivo. Un indirizzo MAC può essere copiato o falsificato e può cambiare con docking station, macchine virtuali o indirizzi Wi-Fi privati. L’oggetto è adatto come criterio di corrispondenza restrittivo in un segmento controllato, ma non come unica autenticazione o barriera di sicurezza.

Esempio: bloccare un flusso non web tramite il MAC sorgente

Questo esempio per SFOS 22/23 blocca un nuovo flusso IPv4 TCP iPerf3 da un dispositivo di test LAN direttamente visibile verso un server di test WAN controllato. Non è una procedura per bloccare tutto l’accesso a internet: HTTP/HTTPS e Web Exceptions non rientrano in questo test. Prima verificare con Packet Capture sull’interfaccia in ingresso il vero MAC sorgente del dispositivo. Se è visibile solo un router a monte, la regola non è adatta; una porta LAN di uno switch non dimostra da sola la visibilità di livello 2. Prima della modifica, verificare la raggiungibilità del server WAN e della porta TCP 5201. Il server deve eseguire realmente iPerf3, non un servizio web.

In Hosts and services > MAC host > Add, inserire mac_test_client come Name, MAC address come Type e 02:00:00:00:00:10 come MAC address, poi salvare con Save. Il nome e l’indirizzo unicast amministrato localmente sono esempi; sostituire l’indirizzo con il MAC verificato del dispositivo.
Aprire Rules and policies > Firewall rules, scegliere IPv4 e creare drop_mac_test_wan con Add firewall rule > New firewall rule. Impostare Action su Drop e attivare Log firewall traffic.
Impostare Source zones su LAN, Source networks and devices su mac_test_client e Destination zones su WAN. In Destination networks, scegliere l’IP Host del proprio server WAN di test e, in Services, svc_iperf3_tcp; creare questo servizio TCP con Destination Port 5201 come descritto nella sezione seguente. Destinazione e servizio di test non web restano così strettamente limitati. Any non è necessario per questo esempio.
Impostare During scheduled time su All the time per un blocco permanente, altrimenti scegliere la pianificazione adatta. Collocare la regola sopra quelle che consentirebbero prima lo stesso flusso, senza spostare le eccezioni intenzionali con priorità superiore. Top non è un requisito universale. Rule group può restare su None; un gruppo non sostituisce il corretto posizionamento. Salvare con Save e verificare l’ordine effettivo.

Avviare poi dal dispositivo di test un nuovo tentativo di connessione TCP iPerf3 allo stesso server WAN sulla porta 5201, non un test UDP o tramite browser. Nel Log Viewer, Drop e la Rule ID di questa regola di blocco devono corrispondere al flusso. Verificare lo stesso flusso non web da un secondo dispositivo non bloccato: deve continuare a corrispondere alla regola Allow prevista. Usare connessioni nuove in entrambi i test, non sessioni esistenti. Se manca la corrispondenza attesa, controllare il MAC sorgente in Packet Capture, zone, versione IP, pianificazione, ambito di destinazione/servizio e regole precedenti.

Questa verifica dimostra solo i flussi testati, non un blocco generale del web o di internet. IPv6, altre zone di destinazione, destinazioni e servizi non sono coperti e richiedono configurazione e test separati. Per tornare indietro, disattivare solo la nuova regola di blocco e verificare lo stato consentito precedente con un nuovo flusso TCP iPerf3. Il rischio di spoofing e di identità descritto sopra rimane.

Creare un servizio con il Destination Port corretto

Prima di creare un nuovo servizio occorre verificare se esiste già un servizio standard adatto. Un Custom Service è utile quando un’applicazione richiede una porta diversa o una combinazione particolare di protocolli.

L’esempio seguente crea il servizio TCP per iPerf3:

Aprire Hosts and services > Services e selezionare Add.
Inserire svc_iperf3_tcp come Name.
Impostare Type su TCP/UDP e Protocol su TCP.
Lasciare invariato il Source Port predefinito 1:65535.
Inserire 5201 come Destination Port.
Salvare con Save.

Il client sceglie normalmente il Source Port in modo dinamico. Se anche il servizio lo limitasse a 5201, una connessione normale non corrisponderebbe più. La porta fissa del server appartiene quindi a Destination Port. Un Source Port ristretto è corretto solo quando il protocollo lo richiede espressamente e il traffico reale conferma tale comportamento.

Per un test UDP di iPerf3 viene creato anche svc_iperf3_udp con protocollo UDP e Destination Port 5201. Poiché iPerf3 continua a utilizzare una connessione di controllo TCP per il test UDP, i due servizi vengono raggruppati:

Aprire Hosts and services > Service group e selezionare Add.
Inserire grp_iperf3 come Name.
Selezionare svc_iperf3_tcp e svc_iperf3_udp.
Salvare con Save.

La procedura di misurazione completa è descritta in Speedtest iPerf3 attraverso Sophos Firewall.

Un Service Group può combinare servizi predefiniti e personalizzati, e un servizio può appartenere a più gruppi. Services e Service Groups non distinguono tra IPv4 e IPv6; la versione IP è determinata dagli oggetti host e dal contesto della regola. I Service Groups predefiniti non possono essere modificati o eliminati, quindi per una combinazione propria si crea un nuovo gruppo.

Anche i servizi predefiniti e quelli già utilizzati nelle Security Policies non possono essere modificati o eliminati. Invece di aggirare una dipendenza, creare il Custom Service necessario, sostituire in modo controllato il vecchio oggetto nelle Policies dipendenti e verificare infine l’indicazione Usage aggiornata.

IP, ICMP e ICMPv6

Oltre a TCP e UDP, un Custom Service può descrivere un numero di protocollo IP o tipi e codici ICMP/ICMPv6. Questi tipi sono destinati ai protocolli che non utilizzano una porta TCP o UDP. I valori devono provenire dalla documentazione tecnica dell’applicazione e non essere ipotizzati dopo un singolo test non riuscito.

Per un servizio di tipo IP in Hosts and services > Services > Add, assegnare un Name adatto, impostare Type su IP, selezionare il numero di protocollo necessario e salvare con Save. Si tratta del numero del protocollo IP, non di una porta di destinazione TCP/UDP. Riaprire quindi il servizio e confrontare il numero con i requisiti dell’applicazione; durante il test con una regola strettamente limitata, verificare in Packet Capture il protocollo effettivamente osservato. Se manca la corrispondenza attesa, controllare prima il protocollo e l’ambito della regola, invece di ricorrere a Any.

In Hosts and services > Services > Add, un servizio può contenere più voci dello stesso tipo selezionato. Per ICMP o ICMPv6, selezionare prima la coppia di tipo e codice necessaria, aggiungere altre coppie con Add e rimuovere le voci non necessarie con Remove. Verificare poi tutte le voci e salvare con Save. È così possibile descrivere più messaggi ICMP necessari in un solo servizio, senza consentire indiscriminatamente tutti i tipi. I servizi TCP/UDP separati e il Service Group dell’esempio iPerf3 restano un’alternativa chiara quando occorre riutilizzare i servizi singolarmente.

Nota di versione sulla documentazione API: Nella tabella salvata dell’API Sophos «Add Service / Update Service» per SFOS 22, la colonna Mandatory indica No sia per ICMPType sia per ICMPv6Type; per SFOS 23, indica Yes in entrambi i casi. Sono indicazioni della documentazione API, non prove di una modifica della GUI o del comportamento in fase di esecuzione. Riguardano i campi ICMP/ICMPv6 e non devono essere interpretate come un obbligo di aggiungere entrambe le famiglie di protocolli ai servizi TCP/UDP/IP. La pagina non definisce una regola condizionale che specifichi quando questi campi possano essere omessi; da queste indicazioni non si possono quindi ricavare istruzioni concrete sul payload o sulla validazione.

Utilizzare gli oggetti in una regola firewall

Un oggetto host o servizio non consente traffico da solo. Diventa efficace solo quando viene utilizzato come criterio di corrispondenza in una regola. Un esempio ristretto potrebbe essere:

Source zones: LAN
Source networks and devices: net_test_branch
Destination zones: DMZ
Destination networks: host_test_web
Services: HTTPS
Log firewall traffic: attivato

Zone, indirizzi e servizio devono essere adattati alla rete reale. Il traffico di risposta di una connessione con stato consentita viene restituito automaticamente. Questa regola non consente tuttavia nuove connessioni indipendenti dalla DMZ verso la LAN. Nemmeno una regola NAT, da sola, concede l’autorizzazione: serve comunque una regola firewall corrispondente.

SFOS valuta le regole firewall dall’alto verso il basso e interrompe la ricerca alla prima corrispondenza. La nuova regola specifica va quindi collocata sopra una regola più ampia che altrimenti intercetterebbe per prima lo stesso flusso. Comprendere e configurare in modo sicuro le regole di Sophos Firewall spiega ordine, funzioni di protezione e test.

Dopo il salvataggio, verificare un tentativo di connessione reale nel Log Viewer. I filtri per indirizzo di test, porta e regola permettono di isolare il flusso corretto; nella vista dettagliata controllare Rule ID, Source, Destination e Service. In questo modo è possibile distinguere un oggetto definito in modo errato dal traffico elaborato da un’altra regola. Se una connessione si interrompe senza un evento Destroy riconosciuto dal firewall, la voce finale della sessione può mancare; Packet Capture e Live Connections costituiscono allora una verifica più affidabile.

Aggiornare Object Usage prima delle modifiche

Un oggetto può essere utilizzato in regole firewall e NAT, VPN, route SD-WAN o altre configurazioni. Prima di modificarlo o eliminarlo è quindi necessario controllarne le dipendenze.

La colonna Usage nell’elenco degli oggetti mostra il numero noto di riferimenti. Questo contatore viene aggiornato automaticamente solo una volta al giorno. Prima di una modifica:

Selezionare Refresh accanto a Usage.
Aprire il contatore aggiornato dell’oggetto interessato.
Espandere le categorie e controllare ogni regola o Policy dipendente.
Solo dopo decidere se l’oggetto può essere modificato, sostituito o eliminato.

Non tutte le dipendenze possono essere modificate direttamente dalla vista Usage. Alcune, tra cui i gateway WAN e le configurazioni CLI, devono essere aperte separatamente nella posizione di configurazione indicata. Un contatore pari a zero è una base affidabile solo dopo un Refresh manuale.

Trovare gli oggetti esistenti e gestirli in modo mirato

Gli elenchi in Hosts and services > IP host, IP host group, MAC host, Services e Service group consentono di cercare in base agli attributi dei rispettivi oggetti. Prima di creare un nuovo oggetto, cercare non solo il nome desiderato, ma anche i valori di indirizzo o di protocollo/porta necessari, nella misura in cui si applicano al tipo di oggetto. In questo modo è possibile individuare un oggetto già adatto con un nome diverso. Dopo il salvataggio, cercare nuovamente l’oggetto e verificarne i valori o i membri del gruppo.

I Custom IP Hosts e le IP Host Groups possono essere aggiunti, modificati ed eliminati; anche i Service Groups personalizzati possono essere modificati, rinominati, integrati con altri servizi o eliminati. Aggiornare sempre prima Object Usage. Una modifica a un gruppo si applica a tutte le regole che lo utilizzano, non solo al caso d’uso su cui si sta lavorando. Prima della modifica, annotare i valori e i membri esistenti; dopo, verificare le connessioni interessate con nuove sessioni. Se l’ambito è errato, annullare la modifica in modo controllato e ripetere il test. Restano valide le restrizioni descritte sopra per i System Hosts, i Service Groups predefiniti e i servizi protetti.

Gestire gli oggetti in sicurezza

Evitare gli errori comuni

Host invece di Network: Un singolo indirizzo IP non copre automaticamente la sottorete associata.
Indirizzo di rete o maschera errati: In un oggetto Network, l’indirizzo di rete e il prefisso devono corrispondere alla segmentazione reale.
Source Port ristretto: Nelle normali connessioni client-server si mantiene 1:65535 e si limita il Destination Port.
Troppo Any: Un oggetto host preciso perde il proprio valore di sicurezza se la Source o il servizio rimangono inutilmente ampi.
Oggetto di sistema duplicato: SFOS gestisce gli host di interfaccia e Remote Access, che non devono quindi essere copiati senza una ragione concreta.
IP list come Threat Feed: Una IP list rimane statica e non sostituisce gli indicatori di minaccia aggiornati automaticamente.
Dipendenze non aggiornate: Prima di modificare o eliminare un oggetto, selezionare sempre Refresh in Object Usage.

Prefissi descrittivi come host_, net_, range_, svc_ e grp_ non sono un requisito tecnico, ma semplificano la ricerca e la revisione. Più importante dello schema specifico è l’uso coerente di nomi, scopi e ambiti nell’intero set di regole.

Mantenere l’inventario ridotto e comprensibile

SFOS supporta fino a 16.000 host complessivi per tutti i tipi. È un limite della piattaforma, non un obiettivo di pianificazione. Per l’operatività quotidiana, una base di oggetti ridotta e comprensibile è più utile di molte voci difficili da distinguere. Gli oggetti non più necessari vanno sostituiti o rimossi in modo controllato solo dopo aver aggiornato e verificato il relativo Usage.