Distribuire e gestire Sophos Firewall su AWS

Sophos Firewall 22 viene eseguito in AWS come appliance EC2 virtuale inline in una VPC. Occorre prima definire quale traffico ispezionare. Un firewall standalone può controllare traffico inbound e outbound; il template Sophos Auto Scaling è invece un design PAYG specializzato per DNAT o WAF inbound.

Il percorso sicuro consiste nello scegliere architettura e licenza, registrare piano IP e routing, avviare il template Marketplace adatto, limitare la gestione a un IP sorgente fisso, verificare un flusso end-to-end e solo dopo pubblicare altri servizi.

⚠️ Le AWS Security Groups restano un secondo livello firewall. Una regola SFOS permissiva non serve se Security Group, NACL o Route Table bloccano il percorso. Viceversa, una porta AWS aperta non va associata a una regola Sophos ampia. Le Security Groups sono stateful, le Network ACL stateless: una NACL personalizzata deve quindi consentire richiesta e ritorno.

Scegliere standalone o Auto Scaling

AWS non supporta HA nativo Sophos Firewall. Auto Scaling e Network Load Balancing sono un design cloud separato, non sincronizzazione HA SFOS. Uno standalone richiede quindi anche procedura di rebuild e finestra di interruzione accettata.

Per la scelta dell’istanza valgono tre verifiche: il tipo EC2 deve essere offerto nel template CloudFormation Marketplace aperto per la regione e l’AMI scelte; CPU, RAM e prestazioni di rete devono essere adeguate al throughput e al profilo delle connessioni; con BYOL devono essere confermati i diritti per la CPU e le condizioni applicabili a quella specifica licenza.

La corrispondenza SFOS 22/23 indica, ad esempio, m5.large con 2 vCPU e 8 GB di RAM per SFv2C4 e m5.xlarge con 4 vCPU e 16 GB di RAM per SFv4C6. Si tratta di esempi di corrispondenza legati alla versione e all’offerta, non di una garanzia per ogni template attuale. Il suffisso RAM storico della licenza non costituisce quindi un limite massimo affidabile per la RAM fisica EC2; questo, tuttavia, non implica neppure una garanzia generale di diritti d’uso illimitati della RAM. Prima dell’acquisto, chiarire e documentare con Sophos o con il partner di licenza i diritti previsti dalla specifica licenza/offerta; in caso di dubbi, non distribuire in produzione.

Scegliere una dimensione offerta con margine per il carico e registrare nel piano tipo EC2, versione AMI/SFOS e condizioni di licenza confermate.

Con PAYG, la fatturazione del software termina solo quando tutte le istanze firewall interessate sono state rimosse; le risorse AWS rimaste separatamente possono continuare a generare costi.

Se il tipo previsto non compare nel template o CloudFormation rifiuta la combinazione di regione, AMI e dimensione, non forzarla modificando manualmente il template. Scegliere un tipo offerto che soddisfi carico e licenza oppure interrompere il deployment finché regione, offerta o licenza non sono chiariti.

Chiarire licenza e pilot prima dell’acquisto

Se PAYG non è disponibile nel proprio paese o nella propria offerta, è possibile valutare Standalone BYOL con una licenza confermata; questo non rende il template Auto Scaling, riservato a PAYG, utilizzabile con BYOL. Tramite Sophos o un partner è inoltre possibile valutare un Private Offer con prezzi e condizioni concordati individualmente. BYOL evita il costo software Marketplace, non i costi EC2 e dell’infrastruttura.

Per un pilot, verificare gli effettivi diritti di prova, la durata e le condizioni dell’offerta scelta. La FAQ AWS storica descrive una prova software PAYG di 30 giorni; non è una garanzia per l’offerta scelta oggi. Al termine del periodo di prova previsto da tale offerta, l’ulteriore utilizzo del software PAYG diventa automaticamente a pagamento. EC2, storage, rete e altra infrastruttura possono essere a pagamento già durante la prova. Registrare la data di fine, il responsabile dei costi, un budget alarm e la decisione di proseguire l’esercizio o di smantellare le risorse in tempo. Con BYOL, utilizzare un’attivazione di prova offerta durante la configurazione iniziale oppure una licenza di prova approvata in anticipo; la sola registrazione non garantisce una licenza.

Una licenza UTM di produzione può essere convertita in Sophos Firewall solo tramite il processo di conversione previsto, subordinato ai diritti applicabili. Anche il trasferimento di una licenza firewall esistente è possibile solo negli scenari autorizzati, non mediante il riutilizzo arbitrario dello stesso key. Confermare entrambi i punti con il partner di licenza prima di avviare BYOL. Attivare il key di licenza descrive la successiva attivazione.

Nel modello di responsabilità condivisa, applicazioni, dati, configurazione e manutenzione restano sotto la propria responsabilità. IPS, filtro web e WAF integrano SG/NACL solo sul percorso di traffico effettivamente controllato. Synchronized Security richiede licenze Endpoint adeguate, registrazione e una policy Heartbeat/firewall; non isola automaticamente ogni percorso laterale EC2 che aggira i controlli. Collegamento a Central spiega la connessione alla gestione centralizzata.

Preparare il deployment standalone

Prima dell’avvio registrare:

• account AWS, regione, Availability Zone e offerta BYOL o PAYG;
• VPC nuova o esistente e CIDR pubblici e privati senza sovrapposizioni;
• sorgente admin fissa, ad esempio 198.51.100.27/32, invece di accesso globale;
• Elastic IP, nomi DNS e servizi inbound necessari;
• reti private di destinazione, default route e ritorno previsto di ogni flusso;
• tipo EC2 supportato, limite licenza, responsabile costi e tag;
• procedure di backup, firmware e rebuild.

198.51.100.27/32 è un indirizzo di documentazione da sostituire con l’IP pubblico reale dell’admin. Se cambia spesso, VPN o jump host controllato sono più sicuri di un’ampia esposizione TCP 4444.

In una VPC esistente non scegliere le subnet solo dal nome: le Route Tables devono seguire la direzione prevista. AWS illustra l’inserimento dell’appliance negli esempi di middlebox routing. Source/Destination Check deve essere disattivato sulle ENI del firewall perché inoltrano traffico di terzi. Lasciare che CloudFormation imposti questi dettagli e poi verificarli senza modificarli alla cieca.

Distribuire standalone con CloudFormation

1. Aprire l’offerta Sophos Firewall BYOL o PAYG in AWS Marketplace, scegliere View purchase options e accettare i termini.
2. In Continue to Configuration, scegliere fulfillment, versione software SFOS corrente e regione.
3. In Continue to Launch, scegliere Launch CloudFormation e aprire il template nella console AWS CloudFormation.
4. Inserire uno Stack name univoco. Per una nuova VPC controllare le sovrapposizioni con VPC, VPN e reti locali esistenti.
5. Per una VPC esistente associare VPC ID, una subnet pubblica, una privata e una Elastic IP nuova o libera. Lasciare Network Address Prefix for new VPC invariato.
6. Usare solo una dimensione EC2 offerta dal template aperto per regione e AMI e, con BYOL, ricontrollarla rispetto al limite di licenza registrato. Non archiviare segreti in ticket, screenshot o file parametri pubblicamente leggibili.
7. Rivedere le risorse IAM richieste. Solo dopo confermare I acknowledge that AWS CloudFormation might create IAM resources e fare clic su Submit.
8. Attendere CREATE_COMPLETE. Leggere Elastic IP in Outputs, quindi verificare entrambi gli status check e le ENI previste nella console EC2.
9. Aprire WebAdmin dalla sorgente autorizzata su https://<EIP>:4444. Ignorare l’avviso del certificato locale iniziale solo dopo aver verificato l’IP, poi accettare le condizioni d’uso e completare registrazione e configurazione di base. Aprire quindi Administration > Licensing e verificare che la licenza prevista sia attiva; in caso di differenze, correggere la dimensione dell’istanza o l’assegnazione della licenza prima di consentire traffico di produzione.

I parametri Marketplace possono cambiare; prima di ogni rollout in produzione, confrontare i nomi dei campi visibili con il template effettivamente aperto.

Aprire insieme regole AWS e SFOS

Il template Sophos standalone abilita per impostazione predefinita solo l’accesso di gestione per WebAdmin e SSH. Questa affermazione non si applica in modo generale ad Auto Scaling: in quel caso Public Network CIDR controlla il traffico non di gestione. IPsec, SSL VPN, RED, WAF, User Portal o applicazioni pubblicate richiedono inoltre regole AWS Security Group adeguate. Per SD-RED 20/60, considerare verso il firewall TCP 3400 per il canale di controllo e UDP 3410 per il tunnel dati; verificare separatamente gli ulteriori requisiti di provisioning, DNS e NTP, nonché le altre varianti RED.

Per ogni apertura documentare protocollo, porta destinazione e sorgente una volta, ma implementarli separatamente:

1. La Security Group consente solo la sorgente richiesta verso la porta della corretta ENI.
2. Una NACL personalizzata consente richiesta e ritorno. AWS spiega la differenza in Security Groups e Network ACLs.
3. La Route Table invia il traffico attraverso il firewall e offre un ritorno valido.
4. Le regole firewall SFOS e, se necessaria, NAT usano zone, host e servizi precisi, registrano il traffico e applicano Security Profiles appropriati.

Non esporre mai preventivamente SSH o WebAdmin a 0.0.0.0/0. Un accesso AWS ristretto non sostituisce una regola SFOS precisa.

Creare Auto Scaling per traffico inbound

Auto Scaling richiede un account AWS, l’offerta Marketplace Sophos Cloud Firewall (PAYG) e un account Sophos Fusion con i diritti necessari per la gestione dei firewall. In Sophos Fusion (in precedenza Sophos Central), sotto My products > General settings > API credentials management, verificare le condizioni e creare una credential con nome, descrizione e ruolo Service principal firewall. Conservare Client ID e Client secret in un Secret Store ad accesso limitato, non in un file di testo non protetto. La password dell’account Sophos ID è un segreto diverso dall’API Client secret.

1. Nella regione AWS desiderata, sotto EC2 > Network & security > Key pairs, creare un Key Pair adeguato oppure riutilizzarne uno esistente. Conservare la chiave privata in modo sicuro e annotare il nome per SSH KeyPair Name.
2. Nel Marketplace aprire View purchase options e Continue to configuration. Scegliere Sophos Auto Scaling Firewall for AWS come Fulfillment option, la Software version approvata e la Region. Sotto Continue to launch, scegliere l’azione Launch CloudFormation, fare clic su Launch e poi su Next in CloudFormation.
3. Assegnare uno Stack name univoco. Confrontare AMI ID con l’offerta e la versione scelte e, sotto Instance size, scegliere una dimensione offerta con prestazioni sufficienti. Sotto AvailabilityZone 1 for deployment e AvailabilityZone 2 for deployment, selezionare due AZ diverse.
4. Nuova VPC: sotto Network Address Prefix for new VPC, inserire i primi due ottetti di un intervallo pianificato senza conflitti; lasciare vuoti i campi per una VPC esistente. VPC esistente: lasciare invariato il parametro del prefisso e compilare Deploy to an existing VPC, Existing public subnet ID 1, Existing public subnet ID 2 e Existing private subnet ID in base al piano. Le subnet pubbliche devono appartenere alle AZ scelte e avere Auto-assign public IPv4 address abilitato. Verificare anche route e NACL.
5. Impostare il nome del firewall, Admin Password per WebAdmin/CLI, Secure Storage Master Key Password e SSH KeyPair Name. Proteggere le due password del firewall separatamente dal segreto API.
6. Inserire Sophos ID email address e Sophos ID password dell’account previsto, Sophos Central client ID, Sophos Central client secret e Sophos Central AS Group name. I nomi dei campi Central possono restare nel template nonostante il branding Fusion; il gruppo viene creato automaticamente nell’account associato. Non riportare segreti in ticket, screenshot o file di parametri pubblici.
7. Impostare i seguenti parametri di rete, capacità e log. Sotto I accept the Sophos End User License Agreement and acknowledge the Sophos Privacy Policy, dopo aver verificato i termini, inserire esattamente yes; rispettare maiuscole e minuscole. Per Opt in to the customer experience improvement program, scegliere consapevolmente un’opzione.
8. Con Next, aprire le opzioni dello stack, impostare i tag di owner e costi e verificare i diritti IAM richiesti. Solo dopo confermare I acknowledge that AWS CloudFormation might create IAM resources, controllare il riepilogo completo e avviare con Submit.

Dopo CREATE_COMPLETE, verificare le istanze EC2 e, sotto My products > Firewall management > Firewalls, il gruppo creato automaticamente con tutti i worker PAYG previsti e approvati. Confermare la sincronizzazione della policy prima di esporre un servizio. Se manca un worker o la registrazione non riesce, non aprire altre porte; verificare Stack Events, accesso di rete e associazione account/API senza registrare segreti nei log. Modificare successivamente la capacità sotto EC2 > Auto scaling > Auto scaling groups > Capacity overview > Edit e confermare con Update. Documentare in modo univoco ID dell’istanza, AZ e nomi dei firewall; a ogni modifica della capacità, verificare nuovamente l’appartenenza al gruppo e Target Health.

DNAT dietro Network Load Balancer

Il prerequisito è un deployment Auto Scaling funzionante e verificato. Per un servizio TCP autorizzato, il listener NLB inoltra a una Target Group dei worker firewall, non direttamente al backend. Il seguente schema originale mostra un percorso HTTPS di esempio, non una connessione misurata:

Client autorizzato : porta sorgente effimera
                 | TCP porta destinazione 443
          Listener TCP NLB :443
                 |
       Target Group dei worker firewall
         /                       \
 AZ 1: Worker PortB       AZ 2: Worker PortB
         \                       /
          DNAT verso il backend :443
          SNAT = MASQ del worker
                 |
          Server applicativo interno :443
                 | Risposta
          Stesso worker -> NLB -> Client

Schema: due AZ, una PortB attiva per worker e un percorso di ritorno MASQ. Le frecce descrivono il percorso logico dei dati; il bilanciamento del carico non garantisce un utilizzo uniforme. Adattare tutti i valori di esempio al servizio autorizzato.

1. In Fusion, sotto My products > Firewall management > Firewalls, aprire Manage policy per il gruppo di firewall Auto Scaling corretto. Sotto Hosts and services > IP host, creare due intervalli IP IPv4 per le subnet WAN effettive di entrambe le AZ e un host IPv4 per il server interno. Non includere il primo indirizzo di ciascuna subnet; includere solo gli indirizzi effettivamente utilizzabili dai worker, non gli indirizzi riservati da AWS.
2. Sotto Hosts and services > Services, creare un servizio TCP/UDP con Protocol TCP. Per questo avvio di connessione in ingresso, la porta client effimera è la sorgente e la porta del servizio pubblicato è la destinazione. La direzione seguente vale per la richiesta, non per la risposta; 3389 o 8080 non vengono aperte in aggiunta.

3. Salvare nella policy di gruppo la regola firewall sotto Rules and policies > Firewall rules e la regola NAT sotto Rules and policies > NAT rules. Verificare la sincronizzazione su ogni worker in esecuzione.
4. Sotto EC2 > Load balancing > Target groups > Create target group, scegliere Instances, un nome univoco, Protocol TCP, Port 443 e la VPC del deployment. Adattare consapevolmente protocollo, porta ed eventuale percorso degli Health Check al servizio verificato. Durante la creazione, sotto Available instances, non selezionare manualmente alcuna istanza, in particolare non il server backend.
5. Sotto EC2 > Auto scaling > Auto scaling groups, scegliere l’ASG firewall e, sotto Integrations > Load balancing > Edit, associare la Target Group; confermare con Update. L’ASG registra così automaticamente i propri worker, compresi quelli avviati successivamente.
6. Prima di avviare il listener, sotto Load balancers, verificare l’associazione delle Security Group sul NLB effettivo del template. Se il NLB è stato creato senza una Security Group, non è possibile aggiungerne una in seguito. In tal caso, non aprire alcun listener pubblico finché non sia stato approvato un percorso supportato e limitato alle sorgenti autorizzate; in alternativa, utilizzare VPN/ZTNA. Non modificare alla cieca il template gestito e non promettere un’associazione SG successiva.
7. Se il percorso restrittivo è disponibile, nel NLB, sotto Listeners > Add listener, configurare TCP e la porta 443 con la Target Group dei worker come Default action. Limitare la SG del NLB ai CIDR client autorizzati e alla porta del listener; sul worker, consentire separatamente le porte di destinazione e degli Health Check necessarie al NLB. Il traffico egress del NLB deve poter raggiungere gli Health Check. L’accesso per un Health Check non equivale a un’apertura pubblica dell’applicazione. Limitare anche l’accesso diretto ai worker e al backend.
8. Prima dell’utilizzo in produzione, controllare che i worker previsti in entrambe le AZ e un worker avviato ex novo nella finestra di modifica approvata compaiano automaticamente nella Target Group e superino gli Health Check previsti. Tramite il nome DNS del NLB, verificare il flusso applicativo positivo e un tentativo negativo da una sorgente non autorizzata; Log Viewer deve mostrare la regola prevista e DNAT/MASQ. Non affidarsi soltanto allo stato healthy.

L’accesso RDP pubblico diretto resta sconsigliato; preferire VPN o ZTNA. Se un target rimane unhealthy, verificare prima associazione ASG, policy sincronizzata, porta/percorso degli Health Check, egress del NLB, SG dei worker e NACL. Se il backend o il percorso di ritorno sono errati, mantenere il listener chiuso e correggere NAT/servizio/route. L’interpretazione delle porte segue la direzione della richiesta nel percorso client-listener-backend e va verificata confrontando listener, backend e regole di sicurezza.

Collaudare un flusso livello per livello

Annotare un flusso iniziale, ad esempio 198.51.100.27:55000 -> NLB-DNS:443 -> App-Server:443. La porta sorgente è solo un esempio di porta client effimera. Controllare in ordine:

1. DNS e listener NLB puntano alla destinazione prevista e la Target Group mostra i worker healthy.
2. Security Groups e NACL consentono esattamente richiesta e ritorno.
3. Route Tables ed ENI inviano il traffico attraverso l’appliance; Source/Destination Check è disattivato sulle interfacce di transito.
4. SFOS Log Viewer mostra la Rule ID prevista. Per DNAT, destinazioni originale e tradotta e ritorno sono corretti.
5. Il test autorizzato raggiunge l’applicazione e quello da una sorgente non autorizzata resta bloccato.

Se manca il log SFOS, verificare DNS, listener, Target Health, Security Group, NACL e route. Per un drop con Rule ID inattesa, correggere zone, oggetti rete, servizio e ordine. Se arriva la richiesta ma non la risposta, controllare Route Table, NACL, default gateway del server e, con Auto Scaling, MASQ.

Gestire e ripristinare

Standalone e Auto Scaling richiedono runbook diversi. Per standalone documentare un backup SFOS con ripristino verificato, il processo firmware, i parametri CloudFormation e un test di ricostruzione. Uno snapshot EC2 non sostituisce un backup SFOS esportato.

I worker Auto Scaling sono effimeri. Con CloudWatch, i log appaiono sotto /sophos/xg/; configurare retention, cifratura, accesso e costi. Le istanze EC2 terminate restano nel gruppo Fusion e devono essere eliminate manualmente. Warm Pool non sostituisce la verifica della policy corrente su ogni worker.

Il registro operativo include tag di owner e costi, budget alarm, licenza, rotazione segreti, retention CloudWatch, pulizia Fusion, approvazione firmware, test delle modifiche e recovery. Ripetere il test positivo e negativo dopo ogni modifica a template, routing o policy.

Fermare la modifica e annullarla in modo mirato

Prima della modifica, salvare parametri dello stack e ID delle risorse, associazione listener/Target Group, SG/NACL/Route Tables, policy di gruppo SFOS e backup. In caso di destinazione errata, sorgente inattesa, mancata sincronizzazione della policy o interruzione di una connessione esistente, chiudere prima il listener appena aggiunto o la nuova esposizione; quindi ripristinare allo stato sicuro documentato solo le regole e le route introdotte ex novo. Verificare nuovamente il traffico esistente e il blocco delle sorgenti non autorizzate. Non eliminare VPC condivise, subnet, gateway o listener esistenti per risolvere un problema.

Per lo smantellamento PAYG pianificato, non basta terminare singoli worker: l’ASG può ricrearli. Rimuovere prima la nuova esposizione, eseguire la dismissione autorizzata tramite il ciclo di vita dello stack/ASG e verificare che né azioni di scaling né istanze Warm Pool riavviino i worker. Rimuovere tutte le istanze firewall PAYG associate e controllare l’inventario effettivo delle risorse. Valutare singolarmente volumi conservati, EIP, NLB, Log Groups e altre risorse a pagamento in base all’elenco delle risorse, senza eliminarli indiscriminatamente; rimuovere dal gruppo Fusion i worker terminati. Verificare poi fatturazione e controllo dei costi.