Distribuire e instradare Sophos Firewall su Azure
Sophos Firewall può essere distribuito da Azure Marketplace come appliance singola o con un template Load Balancer e due firewall. Sophos chiama il secondo design active-active, ma non è un cluster HA SFOS nativo. Configurazione, sessioni e stato non vengono sincronizzati come tra due appliance HA.
⚠️ Il routing Azure fa parte della configurazione firewall. Una regola SFOS corretta non basta se manca una User Defined Route, una Network Security Group o il ritorno del Load Balancer. Ogni pubblicazione viene validata come percorso completo di andata e ritorno.
Scegliere modello e licenza
| Modello | Licenza | Limite importante |
|---|---|---|
| Standalone | BYOL o PAYG | Un’appliance senza ridondanza, per workload controllati con una finestra di manutenzione accettata. |
| Active-active con Load Balancer | Una licenza BYOL per firewall o PAYG | Due firewall indipendenti dietro Standard Load Balancer con HA Ports; il template non supporta active-passive. |
Per standalone Sophos raccomanda almeno Standard_F2s_v2, due vCPU e 4 GB RAM. L’IP pubblico usa Standard SKU con assegnazione statica. Basic SKU è ritirata e non va usata nei nuovi deployment.
Distribuire standalone dal Marketplace
Creare e proteggere l’appliance
- Selezionare Sophos Firewall in Azure Marketplace e scegliere BYOL o PAYG.
- Definire Resource Group, regione e dimensione. VNet, subnet e reti remote non si sovrappongono.
- Associare PortA alla LAN e PortB alla WAN. Aprire le NSG inizialmente solo alle fonti amministrative necessarie.
- Completare il deployment e aprire WebAdmin su
https://<dns-name>:4444. - Completare in modo controllato wizard, registrazione, licenza e firmware.
- Impostare l’indirizzo privato della NIC LAN su Static. Aggiungere a ogni subnet dei workload una UDR
0.0.0.0/0, Virtual appliance, con l’IP LAN come Next Hop. - Testare IP Forwarding, NSG, regole SFOS e ritorno con un client definito.
La UDR forza il traffico LAN in uscita attraverso il firewall. Senza UDR Azure usa il percorso predefinito. Una connessione route-based ad Azure VPN Gateway usa inoltre l’interfaccia XFRM con route statiche, SD-WAN o BGP.
Preparare il piano di indirizzamento
Per un nuovo deployment creare prima l’IP pubblico in Public IP addresses > Create con IP version: IPv4, SKU: Standard, Availability zone: 1, Tier: Regional, IP address assignment: Static e Routing preference: Microsoft network. Definire un DNS name label univoco e scegliere Domain name label scope: None. Per questa procedura Sophos indica anche DDoS protection > Protection type: Network. L’opzione richiede un piano Azure DDoS idoneo e può comportare costi aggiuntivi; concordare quindi il piano con il responsabile Azure prima della creazione. Selezionare poi l’indirizzo in Public IP name. Sophos supporta esplicitamente solo la zona 1. L’opzione Basic dinamica non è più adatta dopo il ritiro della SKU da parte di Azure.
Un esempio adattabile usa VNet 10.20.0.0/16, LAN 10.20.10.0/24 su PortA, WAN 10.20.20.0/24 su PortB e IP LAN statico 10.20.10.4. Sostituire questi valori RFC 1918 con intervalli liberi che non si sovrappongano a peering, VPN o reti on-premises.
Creare la UDR LAN con i campi Azure esatti
Sophos richiede di arrestare la VM prima di rendere statico l’IP LAN: Virtual machines > Allocation: Static. Dopo il riavvio creare la tabella in Route tables > Create. In Subnets > Associate associare ogni subnet client o workload il cui traffico deve attraversare l’appliance. Se i client si trovano direttamente nella subnet LAN di PortA, associare quella subnet LAN, come nell’esempio base di Sophos. Non associare la subnet WAN del firewall. In Routes > Add impostare Route name: default-via-sfos, Destination type: IP Addresses, Destination IP addresses/CIDR ranges: 0.0.0.0/0, Next hop type: Virtual appliance e Next hop address: 10.20.10.4. Verificare Enable IP forwarding su entrambe le NIC. Mantenere Propagate gateway routes: Yes solo se coerente con VPN/ExpressRoute. Creare infine una regola LAN-WAN ristretta e con logging in Rules and policies > Firewall rules.
Gestire active-active con Load Balancer
Il template Sophos crea due firewall e un Standard Load Balancer esterno e interno con HA Ports. Richiede una VNet /16 e subnet LAN e WAN /24; Sophos chiede di consultare il proprio referente prima di usare dimensioni diverse.
Le health probe raggiungono WebAdmin su 4444 e il proxy su 3128. Le probe interne dipendono inoltre da route speciali verso l’indirizzo di piattaforma 168.63.129.16, iniettate nella tabella di routing del kernel dall’Automation Runbook. Queste route non persistono dopo un firmware upgrade; in seguito si esegue e verifica nuovamente il runbook fornito.
Durante il deployment Trusted network deve inizialmente essere *, perché Azure Automation Runbook accede da IP Azure pubblici. Dopo il successo limitare subito la NSG ai CIDR admin documentati. La prima firewall usa WebAdmin 4444 e SSH 2222, la seconda 4445 e 2223. Registrare separatamente le appliance e mantenere identiche regole firewall, NAT e routing.
Configurare probe ed egress
Su entrambi i firewall configurare i gateway in Routing > Gateways e le route delle probe in Routing > SD-WAN routes; la route esterna deve precedere quella interna. La UDR workload 0.0.0.0/0 usa Next hop type: Virtual appliance e l’IP frontend del Load Balancer interno. Nell’appliance le probe TCP 4444 e 3128 appaiono con origine 168.63.129.16. Se si cambiano porte, probe interna ed esterna devono restare diverse. Nella NSG consentire il percorso con Source Service Tag AzureLoadBalancer; anche listener SFOS e route speciali Sophos devono corrispondere. Né il Service Tag né l’indirizzo di piattaforma sono una fonte Internet generalmente attendibile. Verificare entrambi i backend in Load balancer > Monitoring > Insights o Health Probe Status; una probe sana non convalida applicazione e ritorno.
DNAT e ritorno
Il Load Balancer esterno seleziona un firewall. Gli HA Ports trasportano flussi NVA su protocolli e porte diversi, ma non sostituiscono una pubblicazione specifica del servizio. Per il servizio TCP pubblicato creare sul Load Balancer esterno una health probe corrispondente e una regola di Load Balancing associata alla probe. La regola NAT SFOS traduce quindi al server. In Rules and policies > NAT rules, Translated source (SNAT): MASQ fa rispondere il server all’IP LAN dello stesso firewall. Senza MASQ il ritorno può attraversare l’altro firewall e interrompere la sessione.
La pubblicazione diretta di RDP non è consigliata. Sono preferibili VPN o ZTNA. Se il servizio deve essere pubblicato, fonte, servizio e destinazione vengono limitati in Azure e SFOS, si attivano logging e IPS e si esegue un test negativo.
Convalidare, risolvere problemi e ripristinare
Controlli di accettazione
- In Effective routes di una VM di test, verificare che
0.0.0.0/0punti all’IP LAN SFOS o, in active-active, all’IP del Load Balancer interno. - Testare DNS, HTTPS e applicazione, quindi confermare Rule ID, origine e destinazione in Log viewer > Firewall. Per un servizio pubblicato eseguire un test positivo consentito e uno negativo non consentito.
- In active-active controllare Health Probe Status e Backend Pool. Solo in una finestra di manutenzione, rimuovere un firewall, provare nuove connessioni tramite l’altro e ripristinare un backend sano prima del secondo test. Le sessioni esistenti non sono sincronizzate e possono interrompersi.
Errori tipici
Senza egress verificare Effective Routes, associazione della subnet workload, IP LAN statico, IP forwarding, NSG e Rule ID SFOS. Per probe unhealthy controllare protocollo/porta TCP, listener, NSG e route SD-WAN verso 168.63.129.16. Dopo un firmware upgrade le route iniettate non persistono: rieseguire il runbook Sophos su entrambe le VM, verificare le probe e ripristinare subito i CIDR admin nella NSG SSH. Per DNAT intermittente confrontare regole su entrambe le appliance, MASQ, Backend Pool e route di ritorno del server.
Prima del rollback egress annotare il Next Hop approvato in precedenza. Riassociare la Route Table precedente oppure isolare la subnet workload durante la modifica. La semplice dissociazione può attivare la route di sistema Azure 0.0.0.0/0 -> Internet e aggirare il firewall; farlo solo se questo percorso è stato verificato e accettato. Eliminare UDR e regole temporanee solo dopo aver convalidato il ritorno ripristinato. Per DNAT disabilitare prima la regola del Load Balancer esterno. Gli snapshot Azure non sostituiscono un backup SFOS esportato.