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. Una 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.

I tipi EC2 attualmente supportati sono nella panoramica Sophos AWS. Con BYOL non basta scegliere l’istanza più grande: le risorse devono corrispondere alla licenza virtuale acquistata. Con PAYG, Sophos indica che i costi software terminano solo dopo la rimozione di tutte le istanze firewall interessate dall’account AWS.

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 della 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 come indicato da Sophos.
6. Confrontare AMI e dimensione EC2 con la lista Sophos e, per BYOL, con la licenza. 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 completare registrazione e basic setup.

Sophos mantiene la sequenza completa in Deploy Sophos Firewall on AWS. I parametri Marketplace possono cambiare: confrontare sempre i campi con la pagina e il template realmente aperto.

Aprire insieme regole AWS e SFOS

Il template attiva inizialmente solo WebAdmin e SSH. IPsec, SSL VPN, RED, WAF, User Portal e applicazioni pubblicate richiedono regole AWS corrispondenti. RED usa, ad esempio, TCP 3410.

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 la 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 account AWS, offerta Sophos Cloud Firewall (PAYG) e credenziali API Sophos Central. In Central aprire My products > General settings > API credentials management e creare una credential con ruolo Service principal firewall. Trattare Client ID e Client secret come password.

Scegliere Sophos Auto Scaling Firewall for AWS come fulfillment. Il template richiede due Availability Zones diverse. Per una VPC esistente indicare due subnet pubbliche e una privata; Sophos richiede Auto-assign public IPv4 address su entrambe le subnet pubbliche.

Verificare con attenzione:

• Trusted Network CIDR: IP pubblico admin come /32, mai 0.0.0.0/0;
• Public Network CIDR: l’esempio Sophos parte da 0.0.0.0/0, aprendo a Internet le porte non management. Avanet consiglia le sorgenti note o una restrizione immediata dopo il deployment;
• Minimum capacity: minimo numero di worker sempre disponibili;
• Starting capacity: worker iniziali. Nell’esempio Sophos consiglia Maximum capacity per registrarli insieme nel gruppo Central;
• Maximum capacity: limite massimo di worker e costi;
• Warm Pool Refresh Period: intervallo per avviare le istanze fermate e sincronizzare la policy Central; il default documentato è cinque giorni;
• Use CloudWatch: invia i log firewall a CloudWatch Logs.

Dopo CREATE_COMPLETE, in My products > Firewall management > Firewalls verificare gruppo automatico e tutti i worker PAYG previsti e approvati. Solo dopo modificare capacity o scaling policy. I parametri aggiornati sono in Sophos Firewall with AWS Auto Scaling.

DNAT dietro Network Load Balancer

Per un servizio pubblicato, un listener TCP NLB inoltra a una Target Group di worker. Nella policy di gruppo Central creare i range delle subnet WAN di entrambe le zone, l’host interno e il servizio della porta pubblicata. Non includere il primo indirizzo IP di ogni subnet AWS.

Nel design single-arm, la regola firewall corrisponde WAN-WAN per range e servizio esatto. DNAT traduce verso il server interno e usa MASQ come translated source affinché il ritorno attraversi lo stesso worker. Associare poi Target Group, Auto Scaling Group e listener NLB. Sophos mostra la sequenza nel DNAT use case.

L’esempio ufficiale usa RDP, ma la pubblicazione diretta non è consigliata. Preferire VPN o ZTNA. Se DNAT è necessario, limitare le sorgenti in NLB, AWS e SFOS, attivare IPS e logging ed eseguire un test negativo.

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 rebuild. 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 secondo Sophos nel gruppo Central 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 Central, approvazione firmware, test delle modifiche e recovery. Ripetere il test positivo e negativo dopo ogni modifica a template, routing o policy.