Sophos Firewall: Hardware, virtuale o cloud?

Sophos Firewall può essere utilizzato come XGS Appliance, dispositivo virtuale, Software Appliance o Cloud Deployment. Tecnicamente, ovunque viene eseguito il sistema operativo Sophos Firewall, ma il modello operativo non è lo stesso. La decisione riguarda prestazioni, supporto, progettazione delle porte, HA, ripristino, licenze, monitoraggio e la questione di chi è responsabile di quale piattaforma in caso di interruzione.

Per i nuovi progetti non dovresti semplicemente chiedere quale variante è più economica. Ciò che conta è quale variante si adatta alla sede, alla piattaforma di virtualizzazione, all’architettura cloud e al team operativo. Anche la guida al dimensionamento di Sophos Firewall è importante per dimensionare correttamente le risorse in funzione delle prestazioni richieste.

La scelta della piattaforma determina anche le funzioni di conformità: la modalità FIPS 140-3 è disponibile su XGS Appliances, piattaforme virtuali supportate, AWS e Azure, ma non su Software Appliance né su hardware XG o SG.

Scegliere il modello operativo

Decisione rapida

• XGS Appliance: Particolarmente adatta quando una sede necessita di un firewall dedicato, con porte fisiche e un percorso di supporto ben definito.
• Appliance virtuale: particolarmente adatta se è disponibile una piattaforma di virtualizzazione stabile e le zone della rete possono essere separate virtualmente in modo pulito.
• Software Appliance: Di solito adatto se il proprio hardware deve essere utilizzato e supportato deliberatamente come piattaforma firewall.
• Cloud Deployment: Molto spesso adatto per proteggere i carichi di lavoro in AWS o Azure o collegarli a reti locali.

La regola più importante: un firewall virtuale o cloud non consente di ridurre l’attenzione alla pianificazione. CPU, RAM, storage, switch virtuali, routing, HA, backup e monitoraggio devono essere pianificati con la stessa attenzione dell’hardware.

Quando fare attenzione

La decisione non dovrebbe basarsi solo su ciò che è tecnicamente possibile. Alcuni ambienti sembrano flessibili sulla carta, ma creano rischi inutili durante il funzionamento.

• Hypervisor già sottoposto a un carico elevato: IPS, TLS Inspection, VPN e logging richiedono risorse CPU prevedibili e un margine di capacità I/O.
• WAN, LAN, DMZ e la gestione attraversano lo stesso collo di bottiglia fisico: Una separazione logicamente pulita è di scarso aiuto se il percorso dati reale è sovraccarico o segmentato in modo errato.
• Nessun team si assume la responsabilità congiunta di hypervisor e firewall: La gestione degli incidenti rimane sospesa tra i team responsabili della piattaforma, della rete e del firewall.
• HA prevista solo sulla carta: Senza test su host, storage, rete e ripristino, l’alta disponibilità non è dimostrata.
• Il routing nel cloud non è completamente documentato: il firewall protegge solo il traffico che viene effettivamente instradato attraverso di esso.
• Il ripristino non è mai stato praticato: Un backup è affidabile solo se un ripristino è stato testato realisticamente o almeno pianificato correttamente.

In questi casi, una XGS Appliance spesso non è meno moderna, ma semplicemente la decisione operativa più solida. Al contrario, un firewall virtuale o cloud può essere molto utile se la piattaforma, la progettazione della rete, il monitoraggio e le responsabilità sono definiti con chiarezza.

Confrontare le piattaforme

XGS Appliance

Una XGS Appliance è solitamente la soluzione più prevedibile in fase di pianificazione per le sedi tradizionali. Hardware, porte, supporto, RMA, ciclo di vita e sistema operativo firewall costituiscono un sistema coordinato.

La gamma di hardware fisico Sophos copre esigenze diverse, dagli utenti domestici e dalle piccole imprese fino alle grandi aziende. La XGS Appliance adatta dipende dal traffico, dalle funzioni di protezione, dalle porte e dai requisiti HA. Se necessario, chiedere al team commerciale Sophos o a un partner di verificare la scelta rispetto a tali requisiti. L’idoneità per una rete domestica non implica automaticamente che la licenza Home gratuita possa essere utilizzata sull’hardware scelto.

Vantaggi:

• hardware firewall dedicato,
• configurazione definita delle porte di rete e opzioni di espansione,
• assegnazione chiara delle porte per WAN, LAN, DMZ, collegamento HA e gestione,
• supporto hardware e processo di sostituzione semplici,
• nessuna dipendenza dalle risorse dell’hypervisor,
• Adatto per filiali, sedi centrali e firewall periferici. Il vantaggio più grande sta nel funzionamento: se c’è un problema, non è necessario chiarire prima se la causa è l’hypervisor, il vSwitch, lo storage, il cloud routing o il firewall stesso. Per molte sedi di PMI questo è più importante della massima flessibilità.

Appliance virtuale

Un Sophos Firewall virtuale ha senso se esiste già una piattaforma di virtualizzazione pulita e il firewall deve essere integrato in un data center, in un ambiente multi-tenant o in un progetto di segmentazione interna.

Offre in forma virtualizzata funzioni di sicurezza SFOS disponibili sulle appliance hardware, inclusa la sicurezza basata sull’identità. Le decisioni di sicurezza tengono quindi conto dell’identità dell’utente, non soltanto del suo indirizzo di rete. Organizzazioni e fornitori di servizi di sicurezza gestiti (MSSP) possono riunire la protezione di rete per data center virtuali o uffici su un firewall virtuale. Le funzioni disponibili dipendono dalle licenze e dalla piattaforma supportata; ciò non implica un’accelerazione hardware identica o lo stesso throughput di una XGS Appliance.

Le implementazioni virtuali e cloud con SFOS possono includere anche lo stato di salute degli endpoint gestiti nelle decisioni di accesso tramite Sophos Endpoint Security Heartbeat. A tal fine sono necessari diritti di licenza adeguati per endpoint e firewall, la registrazione nella stessa organizzazione corretta e una risposta configurata esplicitamente. La sicurezza basata sull’identità non è un meccanismo equivalente per valutare lo stato di salute degli endpoint; la sola registrazione non dimostra né l’isolamento né il blocco di tutti i percorsi di traffico. I prerequisiti, i percorsi di risposta e le verifiche degli effetti sono illustrati nella guida a Security Heartbeat e Synchronized Security.

Sophos offre anche la gestione centralizzata dei dispositivi Sophos Firewall. La panoramica delle piattaforme SFOS 22 usa il nome Sophos Fusion (previously Sophos Central), mentre quella di SFOS 23 usa Sophos Central. Questa differenza di nomi non dimostra che la gestione centralizzata sia stata introdotta con SFOS 23. Durante la pianificazione, verificare il servizio utilizzato nel proprio portale di gestione e i prerequisiti per integrare il firewall; la sola analisi centralizzata dei log non equivale alla gestione centralizzata dei dispositivi.

Le piattaforme virtuali rilevanti includono VMware, Microsoft Hyper-V, KVM, Nutanix Prism e Citrix Hypervisor. Prima del deployment, verificare la versione concreta della piattaforma rispetto alle informazioni di compatibilità Sophos aggiornate. Sophos indica come minimo una vCPU, 4 GB di RAM, due vNIC, un disco primario da 32 GB e un disco report da 80 GB. Sono requisiti minimi di installazione, non una raccomandazione di sizing per il traffico di inspection in produzione.

La verifica non deve fermarsi alla famiglia di prodotti. Per Nutanix, ad esempio, Sophos richiede AOS 6.5.x o una versione LTS successiva, la versione AHV inclusa, una versione compatibile di Prism Central e un cluster AHV registrato in Prism Central. KVM richiede un host x86 con kernel Linux recente e supporto Intel VT o AMD-V attivo. Se vCPU e RAM vengono aumentati per sostenere un carico maggiore, occorre prevedere anche un disco report più grande per il volume di log aggiuntivo.

Domande operative importanti:

• Le risorse CPU sono garantite o sono soggette a un’allocazione eccessiva rispetto alla capacità disponibile?
• La RAM e lo spazio di archiviazione sono sufficientemente dimensionati?
• Le NIC virtuali e i gruppi di porte sono chiaramente separati?
• Esistono percorsi di rete dedicati per WAN, LAN, DMZ, HA e gestione?
• È necessaria la modalità promiscua, il trunking VLAN o SR-IOV?
• Esiste un piano di backup e ripristino ben definito?
• È chiaro chi risolve insieme i problemi dell’hypervisor, dello storage e del firewall?

Un firewall virtuale può funzionare molto bene. Tuttavia, le cose diventano rapidamente problematiche quando viene eseguito su un host sovraccarico o quando WAN, LAN e la gestione sembrano solo logicamente puliti, ma fisicamente attraversano gli stessi colli di bottiglia.

⚠️ Gli snapshot dell’hypervisor o i backup del fornitore di virtualizzazione non sostituiscono in modo supportato il backup Sophos integrato. Per un restore supportabile, salvare la configurazione in Backup & Firmware > Backup & Restore. I backup della piattaforma possono esistere in aggiunta, ma non devono essere l’unico percorso di recovery.

Software Appliance

Un Software Appliance viene installato su hardware x86-64 dedicato. Può essere utile per laboratori, ambienti speciali o progetti molto mirati. In produzione va scelto consapevolmente, perché hardware, driver, ricambi, monitoraggio e supporto sono in gran parte responsabilità dell’operatore.

SFOS su hardware fisico adeguato offre regole e policy firewall, risposta alle minacce e routing statico, SD-WAN e dinamico, in funzione delle licenze applicabili e del dimensionamento della piattaforma. Nomi di produttori come Dell o HP sono esempi, non un elenco di compatibilità verificato modello per modello.

L’installazione riformatta e ripartiziona il disco, eliminando il sistema operativo esistente e tutti i file. Per un Software Appliance SFOS 22, Sophos richiede Legacy BIOS, almeno 4 GB di RAM, due interfacce di rete e almeno 32 GB di storage; sono consigliati 64 GB. Se i requisiti minimi non vengono rispettati, il firewall può entrare in modalità fail-safe.

Valori di storage discordanti: Le panoramiche delle piattaforme SFOS 22 e 23 indicano un minimo di 10 GB per l’hardware personalizzato. I requisiti specifici di installazione di Software Appliance per SFOS 22 indicano invece almeno 32 GB e consigliano 64 GB. Questa guida segue deliberatamente il requisito di installazione più specifico e prudente: almeno 32 GB, con 64 GB consigliati. Non pianificare un’installazione con 10 GB; verificare anche i requisiti della versione SFOS scelta prima di installare. Il conflitto rimane da chiarire per il modello e la build previsti.

Se un’appliance si avvia già in modalità Failsafe, prima di modificare le risorse è necessario salvare la causa rilevata da SFOS con il runbook Verificare Sophos Firewall in modalità Failsafe.

Verificare:

• L’hardware è adatto al funzionamento continuo?
• Le schede di rete, lo spazio di archiviazione e la configurazione BIOS/UEFI sono adatti?
• È disponibile hardware sostitutivo?
• Il processo di installazione e ripristino è documentato?
• Chi è responsabile degli errori hardware?

Per le sedi standard, una XGS Appliance è spesso più semplice da gestire. Per casi tecnici speciali, un Software Appliance può comunque essere adatto se il team operativo ha una buona padronanza della piattaforma.

Cloud Deployment

Le implementazioni cloud sono particolarmente utili quando è necessario proteggere i carichi di lavoro in AWS o Azure o collegare le reti cloud alle sedi locali. Nel cloud occorre valutare aspetti diversi rispetto a una sede tradizionale.

Pianificare:

• Progettazione VPC/VNet,
• tabelle di instradamento,
• Zone di disponibilità,
• Elastic IP o IP pubblici,
• VPN Site-to-Site o SD-WAN,
• logging e analisi centralizzata,
• costi cloud per istanze, storage, traffico e architettura HA,
• responsabilità operative del team cloud e del team firewall.

Un firewall cloud non sostituisce la progettazione pulita della rete cloud. Vengono protetti solo i percorsi effettivamente instradati attraverso il firewall. Le scelte di deployment e routing sono descritte nelle guide per Sophos Firewall su AWS e Sophos Firewall su Azure.

Installare un’appliance virtuale o software

Scaricare l’immagine direttamente dalla pagina Sophos Firewall Installers. In Virtual Installers, scegliere il pacchetto OVF corrispondente per Citrix o VMware, il pacchetto VHD per Hyper-V oppure il pacchetto QCOW2 per KVM, Proxmox o Nutanix. Per hardware personalizzato, utilizzare invece la ISO in Software Installers.

Prima dell’importazione, verificare che la pagina di download indicata sopra sia stata caricata tramite HTTPS, che il pacchetto sia stato ottenuto senza ricorrere a mirror di terze parti e che l’archivio sia stato estratto completamente senza errori. Per un pacchetto OVF, tenere insieme manifest, OVF ed entrambi i file VMDK. Se l’importazione segnala una mancata corrispondenza del manifest o del checksum, interrompere e scaricare nuovamente il pacchetto direttamente da Sophos. Per un trasferimento interno è inoltre possibile registrare un valore SHA-256 subito dopo il download e confrontarlo nuovamente sul sistema di destinazione. Questo rileva gli errori di trasferimento, ma non sostituisce una firma del produttore.

Prima dell’importazione sono richiesti almeno 1 vCPU, 4 GB di RAM, due vNIC, un disco primario da 32 GB e un disco report da 80 GB. Risorse insufficienti attivano la modalità fail-safe. Prima di modificare le allocazioni, verificare i limiti CPU e risorse della licenza acquistata; questi minimi non costituiscono un dimensionamento per la produzione. Aumentare la capacità del disco report quando CPU e RAM aggiuntive consentono di generare un volume maggiore di log. Gli snapshot dell’hypervisor e gli strumenti di backup del fornitore non sono backup firewall supportati; utilizzare la funzione di backup SFOS.

Le seguenti procedure di installazione devono essere verificate per la specifica combinazione di piattaforma e SFOS; un’installazione riuscita non conferma ancora il funzionamento del percorso di produzione o di ripristino. Verificare prima il supporto aggiornato per piattaforma, sistema operativo, strumenti di gestione e immagini. Eseguire la validazione su una nuova VM isolata prima di instradare traffico di produzione. Mantenere invariati il firewall esistente e le route di produzione fino all’accettazione della nuova installazione.

Le panoramiche delle piattaforme per SFOS 22 e 23 indicano inoltre, per la famiglia Citrix, XCP-ng-Center come strumento di gestione alternativo a XenCenter e, per VMware, anche VMware Workstation come alternativa al percorso ESXi/vSphere descritto qui. Le opzioni elencate in tali panoramiche non costituiscono una conferma del supporto attuale né un’approvazione generalizzata di tutte le versioni di XCP-ng. Prima di scegliere una delle alternative, deve essere confermato il supporto per le versioni esatte dell’host, della piattaforma e dello strumento di gestione. Se il supporto rimane incerto, interrompere il deployment e utilizzare un percorso il cui supporto sia comprovato. I passaggi XenCenter ed ESXi/vSphere riportati di seguito non sono istruzioni di installazione per queste alternative; in particolare, non si deve riutilizzare la procedura ESXi come ricetta per Workstation.

Citrix Hypervisor e XenCenter

Prerequisiti: Citrix Hypervisor è già installato su un host raggiungibile e XenCenter è installato sul dispositivo di gestione. Verificare le versioni supportate di host, sistema operativo e strumenti; salvare il pacchetto OVF Citrix estratto in una posizione dalla quale XenCenter possa leggere tutti i file.

1. In XenCenter, fare clic con il pulsante destro sulla risorsa prevista e selezionare Import > Browse. Selezionare l’OVF, fare clic su Open, quindi su Next.
2. In Import VM(s) to, selezionare la destinazione oppure specificare un Home Server, quindi selezionare Next. Selezionare il repository di storage per entrambi i dischi.
3. Associare consapevolmente le interfacce di rete: PortA alla rete amministrativa/LAN isolata e l’adattatore rivolto alla WAN alla rete WAN/di test separata prevista. Non esporre a Internet WebAdmin con le impostazioni di fabbrica.
4. Verify manifest content è facoltativo nella procedura guidata di importazione; conservare comunque il manifest e indagare eventuali discrepanze anziché aggirarle. Proseguire con Next. In OS Fixup Settings, mantenere selezionato Don’t use Operating System Fixup.
5. Esaminare il riepilogo e fare clic su Finish. Confermare il completamento dell’importazione, la presenza di entrambi i dischi e le due associazioni NIC previste prima di fare clic con il pulsante destro su questa nuova VM e selezionare Start. Aprire la console, quindi seguire la procedura comune di primo accesso riportata di seguito.

VMware ESXi e vSphere Client

Prerequisiti: il server esegue già una versione ESXi attualmente supportata e l’amministratore dispone di una sessione di gestione vSphere Client funzionante, con accesso di rete al server. Estrarre il pacchetto VMware sul dispositivo di gestione. Le vecchie etichette delle versioni dell’hardware virtuale non dimostrano il supporto attuale per ESXi 4 o 5.

Scegliere il template OVF in modo consapevole:

• sf_virtual e sf_virtual_vm7: versione hardware legacy 7, PCNet32 (Vlance), descrittore del collegamento virtuale a 10 Mbps, half duplex, fisso.
• sf_virtual_vm8: versione hardware 8, E1000E, 1000 Mbps, full duplex, negoziazione automatica On.
• sf_virtual_vm8_paravirtual: versione hardware 8, VMXNET 3, 10000 Mbps, full duplex, negoziazione automatica Off. Utilizzare E1000E come alternativa documentata se il driver VMXNET 3 non funziona nell’implementazione in uso.
• sf_virtual_virtualbox non è un template VMware. I descrittori dei collegamenti sopra indicati sono caratteristiche degli adattatori virtuali, non garanzie di throughput del firewall.

1. In vSphere Client, fare clic con il pulsante destro sulla posizione di distribuzione e selezionare Deploy OVF Template > Local file > Choose files. Selezionare l’OVF scelto insieme a sf_virtual-disk1.vmdk, sf_virtual-disk2.vmdk e sf_virtual.mf; fare clic su Open > Next.
2. Inserire nome e posizione, selezionare la risorsa di elaborazione e verificare i dettagli, proseguendo con Next.
3. Selezionare il datastore e il formato dei dischi virtuali. Thick Provision Lazy Zeroed alloca lo spazio alla creazione e azzera i blocchi alla prima scrittura. Thick Provision Eager Zeroed alloca e azzera lo spazio alla creazione, operazione che può richiedere più tempo. Thin Provision alloca lo spazio secondo necessità per risparmiarlo; monitorare la capacità effettiva del datastore. Né la descrizione dei formati dei dischi né questa procedura attestano il supporto Sophos per Fault Tolerance o una restrizione universale alla conversione dei dischi.
4. Associare consapevolmente entrambe le reti di origine, con PortA sulla rete amministrativa isolata. Verificare l’intera configurazione e fare clic su Finish. Attendere il completamento della distribuzione; controllare le dimensioni di entrambi i dischi e le associazioni delle NIC connesse.
5. Selezionare Actions > Power > Power on, aprire la console e seguire la procedura comune di primo accesso.

Hyper-V Manager

Prerequisiti: un host Hyper-V supportato e Hyper-V Manager su un dispositivo di gestione con accesso di rete all’host. Estrarre il pacchetto Hyper-V e collocare entrambi i file VHD in uno storage accessibile all’host; per un host remoto non è sufficiente un percorso visibile soltanto sul PC dell’amministratore.

1. Aprire Action > Connect to Server, quindi Action > New > Virtual Machine. Nella procedura guidata scegliere nome e posizione, Generation 1 e una Startup memory di almeno 4096 MB.
2. Scegliere lo switch virtuale amministrativo isolato per il primo adattatore. Selezionare Use an existing virtual hard disk > Browse > PRIMARY-DISK.vhd > Open. Verificare e selezionare Finish; non avviare ancora la VM.
3. Fare clic con il pulsante destro sulla nuova VM, aprire Settings e, in Hardware, selezionare Network Adapter > Add. Associare questo secondo adattatore alla rete separata prevista e fare clic su Apply.
4. Selezionare SCSI Controller > Hard Drive > Add > Virtual hard disk > Browse, scegliere AUXILIARY-DISK.vhd, quindi Open > OK. Verificare il disco primario di avvio, il disco SCSI ausiliario, entrambi gli switch e le dimensioni dei dischi.
5. Fare clic con il pulsante destro sulla VM e selezionare Connect; avviarla dalla console. Seguire la procedura comune di primo accesso.

KVM e Virtual Machine Manager

Prerequisiti: un host Linux x86 con kernel recente e Intel VT o AMD-V abilitato, oltre a Virtual Machine Manager installato e accessibile oppure a strumenti di gestione KVM idonei e supportati. Eseguire questi controlli di sola lettura sull’host Linux, non nella console SFOS:

grep --color vmx /proc/cpuinfo
grep --color svm /proc/cpuinfo

Il risultato atteso contiene i flag vmx per Intel oppure svm per AMD, non necessariamente entrambi. Se il controllo pertinente non restituisce corrispondenze, interrompere e verificare le capacità della CPU, le impostazioni di virtualizzazione nel firmware e, per un host con virtualizzazione annidata, l’esposizione delle funzionalità. La sola presenza dei flag non dimostra che la virtualizzazione sia abilitata nel firmware né che l’installazione KVM funzioni. #!sh nelle istruzioni meno recenti è un marcatore di formattazione, non un prefisso da anteporre ai comandi.

1. Estrarre l’archivio KVM. Aprire File > New Virtual Machine > Import existing disk image > Browse, scegliere PRIMARY-DISK.qcow2 con Choose volume, quindi Forward.
2. Impostare Memory (RAM) ad almeno 4096 MB e CPU ad almeno 1, rispettando la licenza e il dimensionamento. Selezionare Customize configuration before install > Finish. Inserire un nome e selezionare Apply.
3. Impostare Network source della prima NIC sulla rete amministrativa isolata. L’esempio mantenuto utilizza Device model > Hypervisor default; verificare che l’adattatore risultante sia supportato, quindi selezionare Apply. Non scegliere un bridge condiviso WAN/LAN privo di segmentazione.
4. Selezionare il disco primario, visualizzato inizialmente come IDE Disk 1, quindi Advanced options > Disk bus > VirtIO > Apply.
5. Selezionare Add Hardware > Network, scegliere la rete separata prevista e Device model > virtio > Finish.
6. Selezionare Add Hardware > Storage > Select or create custom storage > Manage. Scegliere AUXILIARY-DISK.qcow2 con Choose volume, impostare Disk bus > VirtIO, quindi selezionare Finish.
7. Verificare entrambi i dischi, i rispettivi bus e dimensioni e le associazioni NIC prima di selezionare Begin Installation. Selezionare il firewall e aprirne la console con Open; seguire la procedura comune di primo accesso.

Proxmox VE: procedura per storage di tipo directory

Questa procedura basata su percorsi si applica a storage di tipo directory idonei, non a qualsiasi backend LVM, ZFS o Ceph. Esaminare prima /etc/pve/storage.cfg per identificare ID, backend e percorso effettivi dello storage. Se il backend non può utilizzare questi percorsi di file QCOW2, interrompere e procurarsi la procedura di importazione supportata appropriata; non incollare in tale ambiente gli esempi per storage di tipo directory.

1. Selezionare il server e Create VM. Inserire Name, selezionare Do not use any media, scegliere impostazioni System, Hard Disk e CPU adeguate all’ambiente e impostare Memory (MB) ad almeno 4096. I valori predefiniti di Machine, SCSI Controller e Cache dipendono dall’esempio e non sono requisiti universali.
2. Selezionare il Bridge amministrativo isolato. Lasciare deselezionato Start after created, verificare e selezionare Finish. Annotare il VMID e confermare che si tratti della nuova VM di test, non ancora utilizzata.
3. Aprire >_ Shell dell’host con i privilegi appropriati. Mantenere spenta soltanto questa nuova VM, conservare una copia di /etc/pve/qemu-server/<vmid>.conf e annotare le associazioni dei dischi esistenti. Non eliminare o sostituire mai un disco di produzione. /var/lib/vz/images/108/ è soltanto una directory di esempio per il VMID 108; utilizzare il percorso relativo allo storage e al VMID verificati.
4. Trasferire in quella directory l’archivio KVM effettivamente scaricato ed estrarlo, ad esempio con unzip ACTUAL_DOWNLOADED_ARCHIVE.zip dopo aver sostituito il segnaposto con il nome reale del file. Devono essere presenti PRIMARY-DISK.qcow2 e AUXILIARY-DISK.qcow2; il nome di file di una build storica non costituisce un’istruzione per il download attuale.
5. Aprire /etc/pve/qemu-server/<vmid>.conf in un editor di testo. Soltanto su questa VM spenta e destinata ai test, sostituire l’associazione iniziale scsi0 e aggiungere quella ausiliaria. La sintassi di esempio mantenuta è:

scsi0: vmdisk:<vmid>/PRIMARY-DISK.qcow2,size=32G
scsi1: vmdisk:<vmid>/AUXILIARY-DISK.qcow2,size=80G

Sostituire vmdisk con l’ID verificato dello storage di tipo directory e <vmid> con il VMID effettivo; non sono valori da utilizzare letteralmente. Le etichette size non ridimensionano un’immagine troppo piccola. Verificare che le immagini effettive rispettino le dimensioni minime e che non venga sovrascritta un’associazione scsi1 esistente.

6. In Hardware, verificare entrambi gli slot dei dischi, le dimensioni e il disco primario di avvio. Utilizzare Add > Network device per aggiungere la seconda NIC al Bridge separato scelto consapevolmente. In Options, mantenere disattivato QEMU Guest Agent. Ricontrollare le associazioni prima di selezionare Start e aprire la console.
7. Se la modifica è errata, mantenere spenta la nuova VM e ripristinarne la configurazione salvata dopo aver ricontrollato l’identità di VMID e storage. Non rimuovere il file del disco originale durante questo rollback. Questo annullamento locale si applica prima della messa in produzione; definire separatamente il recupero di una configurazione già operativa. Seguire la procedura comune di primo accesso soltanto dopo che i controlli sull’hardware corretto hanno avuto esito positivo.

Nutanix Prism Central

Prerequisiti: AOS 6.5.x o una versione LTS successiva, la versione AHV inclusa, un Prism Central (PC) compatibile e il cluster AHV registrato in PC. Le indicazioni della piattaforma specificano l’ultima versione GA (LTS) della Partner VA: GA significa General Availability e LTS significa Long-Term Support. Verificare la versione dell’appliance del partner e la combinazione di piattaforma effettivamente supportate; una pagina della guida SFOS 23 non identifica da sola l’ultima versione GA. Confermare le risorse CPU consentite dalla licenza, almeno 4 GB di RAM, due NIC e dischi da 32 GB e 80 GB.

1. Sul dispositivo di gestione, estrarre PRIMARY-DISK.qcow2 e AUXILIARY-DISK.qcow2 dal pacchetto Virtual Installers: Firewall OS for KVM.
2. In PC, aprire Virtual Infrastructure > Images > Add Image > Add File. Aggiungere ciascun file con Image Type > Disk. Fare clic su Next, selezionare Placement Method e Select Clusters per la destinazione, quindi Save. Aggiornare la vista dopo il caricamento e verificare che entrambe le immagini siano disponibili.
3. Aprire Infrastructure > VMs > Create VM. In General Configuration, impostare nome e fuso orario; in Compute Details, impostare le risorse CPU consentite dalla licenza e RAM sufficiente. In Disks, rimuovere il CD-ROM predefinito soltanto da questa nuova VM.
4. Selezionare Add New Disk > Operation > Clone from Image Service > Bus Type > SCSI > Image > PRIMARY-DISK.qcow2 > Add. Ripetere per AUXILIARY-DISK.qcow2 come disco dei log; anche l’esempio ausiliario mantenuto utilizza SCSI. Non applicare qui le istruzioni sul bus VirtIO per KVM.
5. In Network Adapters (NIC) > Add New NIC > VLAN Name, selezionare la VLAN amministrativa isolata e Add. Ripetere per la seconda rete separata prevista. L’opzione di connettività DHCP della procedura di origine è facoltativa; pianificare successivamente indirizzi stabili per le interfacce. La selezione di una VLAN non assegna di per sé un indirizzo IP.
6. In VM Host Affinity > Set Affinity, selezionare un host approvato e Save, quindi salvare la VM. Deve comparire un messaggio di successo; controllare entrambi i dischi, i bus, le dimensioni e le associazioni NIC prima dell’accensione.
7. Accendere la nuova VM e selezionare Launch console. Seguire la procedura comune di primo accesso.

Primo accesso, validazione e annullamento in sicurezza

Prima della prima accensione, verificare PortA e PortB rispetto alle reti di gestione, LAN e WAN. Associazioni invertite possono esporre WebAdmin direttamente a Internet. Soltanto nell’ambiente iniziale isolato, l’account e la password amministrativi di fabbrica documentati sono admin / admin; la console richiede la password amministrativa admin. Aprire https://172.16.16.16:4444 dal client amministrativo isolato, ad esempio con indirizzo 172.16.16.2/24. Esaminare e accettare i Sophos End User Terms of Use e fare clic su Start setup per la registrazione e la configurazione di base. Sostituire le credenziali di fabbrica durante la configurazione, prima di qualsiasi esposizione, quindi seguire la guida introduttiva.

Non modificare la password predefinita nella CLI prima della procedura guidata: quest’ultima non si avvierebbe più. Se è già successo, completare manualmente la configurazione di base; non ripristinare alle impostazioni di fabbrica un firewall configurato soltanto per recuperare la procedura guidata. Il ripristino di fabbrica distrugge la configurazione ed è un’opzione da valutare deliberatamente solo per una nuova VM protetta, destinata ai test e priva di configurazione da conservare.

Prima del passaggio in produzione, verificare licenza e numero di serie, avvio normale nella console, entrambi i dischi e il reporting, interfacce e zone, backup SFOS supportato e il rifiuto dell’accesso a WebAdmin da una rete non autorizzata.

Se WebAdmin non è raggiungibile, non reinstallare immediatamente. Verificare che il client sia direttamente sulla rete di PortA, che la vNIC sia connessa e che il port group o bridge sia effettivamente associato alla rete amministrativa isolata. Confermare nella console il completamento dell’avvio ed escludere un conflitto con l’indirizzo 172.16.16.16. PortA non deve essere collegata alla WAN pubblica. Se mancano i report o viene attivata la modalità fail-safe, verificare l’assegnazione del disco report, il bus e le dimensioni, CPU e RAM ed entrambe le vNIC; registrare la causa rilevata con il runbook della modalità fail-safe prima di modificare le risorse.

Se si decide di annullare il nuovo deployment prima del passaggio in produzione e nessun traffico di produzione attraversa ancora la nuova VM, spegnerla, annullare le route di test e i gateway temporanei e continuare a utilizzare il firewall esistente senza modificarlo. Questi passaggi si applicano soltanto al rollback, non a un passaggio in produzione validato con successo. Dopo il passaggio in produzione, il ripristino richiede un backup SFOS aggiornato e una ricostruzione documentata, non uno snapshot dell’hypervisor; utilizzare la procedura di backup e ripristino.

Software Appliance su hardware personalizzato

Il sistema di destinazione richiede x86-64, Legacy BIOS, almeno 4 GB di RAM, due NIC e un HDD/SSD da 32 GB (64 GB consigliati). La chiavetta USB deve avere una capacità di almeno 1 GB. Windows/macOS è il sistema della postazione utilizzata per scrivere il supporto, non un sistema operativo mantenuto accanto a SFOS. Utilizzare il download Software Installers: Firewall OS Software ISO for Intel Hardware, estrarre l’archivio e verificare la ISO SW e l’integrità del trasferimento come descritto sopra. Non utilizzare un’immagine HW/XGS o un pacchetto di dischi virtuali.

⚠️ La scrittura del supporto cancella l’intero dispositivo USB selezionato. L’installazione formatta e ripartiziona poi il disco del server di destinazione, eliminando il sistema operativo precedente e tutti i dati. Prima di entrambe le operazioni, identificare esattamente il dispositivo tramite capacità e identità, salvare i dati su un supporto esterno e verificare un percorso di ripristino indipendente. Interrompere se la destinazione non è identificabile con certezza. Dopo l’installazione non esiste un annullamento automatico; il ripristino richiede supporti e dati del sistema originale salvati separatamente, oppure un backup SFOS compatibile con la relativa password e la SSMK associata.

Windows: Win32 Disk Imager

1. Inserire la chiavetta USB e identificarne lettera di unità, capacità e identità in Gestione disco di Windows; scollegare, ove possibile, le altre unità rimovibili. Procurarsi e avviare Win32 Disk Imager sulla postazione.
2. Il selettore di file normalmente filtra i file IMG. Modificare il filtro in *.* e selezionare il file Sophos SW .ISO estratto.
3. Selezionare la destinazione USB verificata, non un disco di sistema o dati. Ricontrollare file e unità selezionati rispetto all’identità annotata, quindi selezionare Write e confermare l’avviso di cancellazione. Attendere il completamento con esito positivo ed espellere il dispositivo in sicurezza. Copiare la ISO come un normale file non crea un supporto avviabile.

macOS: alternativa nativa per la scrittura del supporto

1. Utilizzare Utility Disco per identificare la chiavetta USB esterna tramite capacità e identità. Le istruzioni meno recenti mostrano Partitions > Volume scheme: 1 partition > Format: Free Space > Apply; questi controlli dipendono dalla versione e potrebbero non esistere nella versione macOS in uso. Non inventare un equivalente né formattare un altro disco per riprodurre quella vecchia interfaccia. La procedura di scrittura dei supporti nella guida alla reinstallazione dell’immagine è un’alternativa, utilizzando qui la ISO SW anziché l’immagine hardware prevista da quella guida.
2. Nel Terminale, passare alla directory della ISO. Sostituire SOPHOS_ISO con il nome effettivo del file scaricato prima di eseguire:

hdiutil convert -format UDRW -o sf.img.dmg SOPHOS_ISO

3. Il risultato atteso è il file convertito sf.img.dmg. Eseguire diskutil list, identificare nuovamente l’intero disco USB esterno e smontarne i volumi prima della scrittura diretta (in Utility Disco, Unmount, non espulsione). Interrompere se non è possibile identificare o smontare il dispositivo previsto.
4. Quello seguente è un modello, non un comando pronto da incollare. Sostituire PATH_TO_USB con il percorso verificato dell’intero dispositivo, mai con quello di una partizione o con un numero di disco presunto. Il comando cancella tutto il dispositivo:

dd if=./sf.img.dmg of=PATH_TO_USB bs=1m

Utilizzare sudo soltanto se necessario per i permessi sul dispositivo, dopo aver ricontrollato la destinazione. Un percorso raw aggiunge r al nome verificato del dispositivo (/dev/diskN diventa /dev/rdiskN); N è un segnaposto, non un numero di disco da copiare. L’accesso raw può essere più veloce, ma non rende l’operazione più sicura. Attendere il ritorno del prompt e il completamento con esito positivo; completare le scritture in sospeso con sync ed espellere la chiavetta USB in sicurezza prima di rimuoverla. In caso di errore, interrompere anziché installare da un supporto la cui scrittura non è stata verificata.

Installare e verificare il server fisico

1. Pianificare il fermo, preservare il percorso attraverso il firewall esistente e i backup esterni, verificare Legacy BIOS, avvio USB e identità esatta del disco di installazione. Scollegare gli altri dischi dati ove possibile. Collegare monitor e tastiera locali e, se necessario, una console seriale appropriata.
2. Avviare dal supporto USB preparato. Prima di digitare y e premere Invio alla conferma dell’installer, ricontrollare l’identità del server e del disco e confermare che sia accettabile perdere tutti i dati e il sistema operativo precedenti. Se la destinazione dell’installer non è chiara, interrompere. Seguire le istruzioni fino al completamento, rimuovere la chiavetta USB e riavviare; il primo avvio può richiedere alcuni minuti. Non applicare a questo server generico le istruzioni sui LED XGS.
3. Verificare le NIC rilevate e identificare l’interfaccia di gestione prima di collegare il client amministrativo isolato con indirizzo 172.16.16.2/24. Confermare l’avvio normale e utilizzare https://172.16.16.16:4444, i Terms of Use e Start setup come descritto sopra. Rendere sicure le credenziali, completare registrazione e licenze e salvare un backup SFOS esterno prima del passaggio in produzione.
4. Se la chiavetta USB non si avvia, verificare che l’immagine sia stata scritta sul supporto e non semplicemente copiata come file, l’identità dell’immagine SW e la selezione di Legacy BIOS e avvio USB. In caso di NIC mancanti o modalità fail-safe, registrare la causa indicata nella console e verificare requisiti minimi e compatibilità dei driver prima di reinstallare. Se WebAdmin non è raggiungibile, verificare identità della NIC di gestione, collegamento, indirizzo del client, completamento dell’avvio e conflitti di indirizzi; non collegare mai la gestione con impostazioni di fabbrica alla WAN pubblica come scorciatoia. Utilizzare la guida interna alla modalità fail-safe, la guida introduttiva e la guida al backup e ripristino per decidere il passo successivo.

Pianificare operatività e recovery

Prestazioni e dimensionamento

Quando si tratta di hardware, le prestazioni dipendono dal modello scelto. Per le distribuzioni virtuali, software e cloud, le prestazioni dipendono maggiormente dalla piattaforma.

Aspetti particolarmente rilevanti:

• prestazioni della CPU e risorse CPU riservate,
• RAM,
• latenza dello storage,
• NIC virtuali,
• hypervisor o percorso di rete cloud,
• numero di sessioni,
• TLS Inspection,
• IPS,
• throughput VPN,
• logging e reporting.

I valori della scheda tecnica vanno quindi sempre letti nel loro contesto. Il throughput del firewall senza ispezione di sicurezza non equivale alle prestazioni con protezione dalle minacce, TLS Inspection o IPsec VPN sotto carico reale. La guida all’interpretazione dei dati sulle prestazioni di Sophos Firewall spiega queste differenze.

HA e ripristino

L’elevata disponibilità varia in modo significativo a seconda della piattaforma.

Con l’hardware, l’architettura HA è solitamente più semplice da comprendere: due appliance, un collegamento HA, interfacce definite e un dispositivo sostitutivo chiaramente individuato. Per le implementazioni virtuali e cloud occorre valutare ulteriori aspetti:

• I nodi HA vengono eseguiti su host diversi?
• Lo storage, la rete e l’hypervisor sono davvero ridondanti?
• Gli indirizzi MAC virtuali e le regole vSwitch sono compatibili?
• Esistono dipendenze dal routing nel cloud o dal bilanciamento del carico?
• I backup e i ripristini funzionano su una nuova istanza?
• È stato testato il guasto di un host o di una zona di disponibilità?

Le nozioni di base sulle varianti HA sono descritte nella guida Configurare l’alta disponibilità (HA) in Sophos Firewall. Per il ripristino, è essenziale consultare la guida Creare o ripristinare un backup di Sophos Firewall.

Licenze e supporto

Le licenze devono essere verificate prima dell’implementazione o di qualsiasi modifica delle risorse. Le istruzioni di installazione meno recenti limitano sia vCPU sia vRAM alla licenza acquistata; l’articolo collegato più avanti descrive una modifica commerciale per le varianti virtuali, software e cloud BYOL, in vigore dal 1° marzo 2025, verso licenze basate sui core CPU senza il precedente limite di RAM. Questa descrizione non dimostra che ogni SKU, diritto d’uso preesistente o licenza Home abbia condizioni identiche. Prima di allocare le risorse, confermare nel portale delle licenze lo SKU acquistato, il numero di core consentiti, il numero di serie, l’abbonamento e il supporto, oltre allo stato effettivo della licenza dell’istanza. Se i diritti d’uso non sono chiari, interrompere e chiarirli con il fornitore della licenza. Non applicare la modifica commerciale alle licenze Home né dedurre da questo articolo l’assenza di limiti alle risorse. Il minimo di installazione di 4 GB e il dimensionamento di RAM, storage e NIC per la produzione rimangono requisiti tecnici, indipendentemente da eventuali limiti di licenza applicabili.

Per i principi della licenza base, consultare Sophos Firewall: licenza base. La modifica commerciale è descritta nell’articolo Sophos Firewall VM e SW: licenze basate sulla CPU senza il precedente limite di RAM, da leggere con le qualificazioni sopra indicate.

Ciò che è importante durante il funzionamento:

• Documentare la licenza e lo stato del supporto.
• Registrare con precisione il numero di serie e lo stato di registrazione.
• Verificare le licenze HA prima di realizzare il cluster.
• Verificare il firmware e l’accesso al supporto prima degli aggiornamenti.
• Conoscere il processo RMA o di ripristino per la piattaforma scelta.

Prima degli aggiornamenti principali, consultare anche la guida Verifiche prima dell’aggiornamento di Sophos Firewall a SFOS 22, poiché supporto della piattaforma, spazio di archiviazione, backup, HA e vecchie configurazioni VPN possono influire sull’aggiornamento.

Per HA active-passive su appliance virtuali o software, solo il nodo Primary deve disporre di tutte le licenze necessarie, inclusa la Base Firewall License. In active-active, ogni nodo deve avere una propria Base Firewall License e le stesse licenze di protezione aggiuntive; le date di scadenza possono essere diverse. La questione va risolta prima di creare il cluster, non durante l’analisi del primo failover.

Matrice decisionale

• Sede tradizionale con WAN, LAN e DMZ: Principalmente hardware. Virtuale solo con una buona strategia di virtualizzazione.
• Data center con team hypervisor esistente: L’hardware è possibile, il virtuale spesso ha senso.
• Carichi di lavoro cloud in AWS o Azure: Preferibilmente virtuale o cloud, non hardware tradizionale.
• Supporto semplice e RMA importanti: Più hardware. Con virtuale o cloud, molto dipende dal team della piattaforma.
• Molte porte fisiche richieste: Preferibilmente hardware. Virtuale solo con una progettazione accurata di NIC e vSwitch.
• Scalabilità dinamica e Infrastructure as Code: Più virtuale o cloud.
• Piccolo team IT senza conoscenze specializzate dell’hypervisor: Principalmente hardware; pianificare attentamente i firewall virtuali.
• Progettazione di tenant o segmentazione nel data center: L’hardware è possibile, il virtuale spesso ha senso.

Errori comuni

• Esecuzione di un firewall virtuale su un host con risorse allocate in eccesso rispetto alla capacità disponibile.
• Mancata separazione netta di WAN, LAN e gestione sull’hypervisor.
• Scelta dell’hardware in base al prezzo anziché al dimensionamento della capacità necessaria.
• Implementazione di un firewall cloud senza aver completato la progettazione del routing.
• Pianificazione dell’HA senza test dei guasti di host, storage o infrastruttura cloud.
• Creazione di backup senza prove di ripristino.
• Verifica dello stato di licenze e supporto soltanto durante un aggiornamento.
• Aggiunta di TLS Inspection o IPS senza un margine di capacità prestazionale.
• Coinvolgimento dei responsabili di piattaforma, rete e firewall soltanto dopo un incidente.

Lista di controllo

• Contesto di installazione chiaramente definito: sede, data center o cloud.
• Traffico, larghezza di banda e funzionalità di sicurezza registrati per il dimensionamento.
• Varianti hardware, virtuali, software o cloud scelte deliberatamente.
• Responsabilità documentata per firewall, hypervisor, cloud e rete.
• HA e progettazione del ripristino controllati.
• Processo di backup e ripristino testato o pianificato.
• Licenza, supporto e registrazione chiariti.
• Monitoraggio disponibile per firewall e piattaforma sottostante.
• Aggiornabilità e supporto della piattaforma controllati.
• Persona responsabile della piattaforma, della rete, del firewall, del backup e del ripristino nominata.

Domande frequenti