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

Infrastruttura Azure e software Sophos hanno costi separati. PAYG è orario, senza impegno minimo nel modello documentato, e include Xstream; non permette aggiunte di abbonamenti individuali o Enhanced Plus Support. Verificare paese di fatturazione tra i paesi di rimessa Microsoft e offerta reale; se PAYG non è disponibile, scegliere BYOL. Acquistato tramite reseller autorizzato, BYOL permette pacchetti, abbonamenti individuali (Network Protection, Web Protection, Zero-Day Protection) e supporto incluso Enhanced Plus Support. Le durate documentate sono uno, due o tre anni: confermare offerta e diritti, senza promesse di prezzo o supporto. Interrompere il software non elimina risorse Azure fatturabili.

Sophos indica Standard_F2s_v2, con due vCPU, 4 GB di RAM e almeno due NIC, come dimensione minima. La dimensione effettiva dipende anche da throughput, funzioni di protezione attive e quote Azure. 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

1. Aprire Sophos Firewall > Create in Azure Marketplace. In Basics, inserire Subscription, Resource Group, regione, VM name e una password iniziale robusta per admin. Scegliere BYOL o PAYG e la dimensione verificata in Instance details.
2. Definire VNet, LAN subnet, WAN subnet, l’IP Standard SKU creato prima del deployment in Public IP name e uno Storage Account. VNet, subnet e reti remote non devono sovrapporsi.
3. Associare PortA alla LAN e PortB alla WAN. Aprire le NSG inizialmente solo alle fonti amministrative necessarie.
4. Dopo la validazione Azure, scegliere Create. In Virtual machines > , copiare il nome DNS e aprire WebAdmin su https://<dns-name>:4444.
5. Accedere con admin e la password impostata durante il deployment, accettare le condizioni d’uso e completare registrazione e configurazione iniziale.
6. Arrestare prima la VM come descritto nella procedura UDR più avanti, quindi 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.
7. Testare IP Forwarding, NSG, regole SFOS e ritorno con un client definito.

La UDR predefinita forza il traffico Internet della subnet workload associata attraverso il firewall. Le route Azure più specifiche mantengono la priorità. 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. Availability zone: 1 è la scelta dell’esempio documentato. Separatamente vale il limite di una zona di disponibilità: non prova supporto esclusivo per la zona 1 né convalida altre zone o progetti multizona. 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 né tra loro né a peering, VPN o reti on-premises. Riservare l’IP LAN all’appliance nella subnet LAN: sarà il Next Hop della UDR.

Creare la UDR LAN con i campi Azure esatti

Sophos richiede di arrestare la VM prima di rendere statico l’IP LAN: Virtual machines > > Stop, poi NIC LAN, Settings > IP configurations > ipconfig, Allocation: Static, mantenere l’IP LAN attuale oppure inserire l’indirizzo riservato e salvare. Riavviare poi la VM. Dopo il riavvio creare la tabella in Route tables > Create, indicando Subscription, lo stesso Resource Group e la stessa regione, oltre a un nome come rt-workloads-via-sfos. 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. Il primo firewall usa WebAdmin 4444 e SSH 2222, il secondo 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. Su entrambi i firewall creare inoltre la stessa regola LAN-WAN con logging. 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.

Verificare il deployment del template

Aprire la risorsa di deployment active-active, verificare e registrare la revisione, quindi Deploy to Azure. Prima di Next > Create controllare:

• Subscription, Resource group, Region, Location; disponibilità di Automation accounts in sottoscrizione/regione.
• Base URL della revisione verificata, VM name, Admin password custodita in modo sicuro, Image SKU (BYOL/PAYG-new), VM size con almeno due NIC.
• Net new or existing, Net RG, Net name, Net prefix (/16), WAN name/prefix, LAN name/prefix (/24), Loadbalancer Int IP libera nella LAN.
• Scelte nuovo/esistente, gruppi e nomi per Public IP, Storage, Network security group, Availability set, Automation account; Public IP DNS, Storage type, NIC WAN, NIC LAN, Number of instances: 2. Verificare risorse esistenti e label DNS univoca.
• Salvare regole NSG originali e durata autorizzata di Trusted network: *. Ripristinare accesso amministrativo ristretto anche se l’automazione fallisce; senza eccezione temporanea approvata, fermarsi invece di lasciare amministrazione pubblica illimitata.

Inventariare poi NIC/subnet, gateway, frontend LB, probe e mapping amministrativi reali, senza trasferire l’esempio standalone.

Gateway e rotte probe su entrambe le appliance

Creare e salvare in Routing > Gateways > Add:

L’esempio conservato usa 10.54.11.1/10.54.22.1 e WAN per entrambi i gateway, ma lega poi le rotte interna/esterna a #PortA/#PortB. Il mapping insolito è specifico del deployment. Verificare NIC, interfacce SFOS e raggiungibilità delle subnet; in caso di conflitto fermarsi e chiarire con il responsabile, senza copiare IP o inventare un mapping universale.

In Routing > SD-WAN routes > Add, creare prima l’interna, poi l’esterna, entrambe Top:

Verificare oggetti e definizione del servizio rispetto al flusso reale: HTTP non significa cambiare probe TCP 4444/3128 in 80. Non generalizzare il servizio interno non specificato in una rotta ampia; origine/destinazione restano ristrette. Salvare, mantenere l’esterna sopra l’interna e ripetere il mapping verificato sulla seconda appliance. Controllare Load balancers > Monitoring > Metrics > Health probe status, aggregazione Avg, filtro Backend IP address, su ciascun backend/LB; provare uscita e ritorno reali.

Recuperare rotte iniettate dopo il firmware

Pianificare manutenzione: il runbook documentato riavvia la VM e può interrompere sessioni. Esportare backup SFOS, salvare runbook/NSG e controllare l’altro backend prima di intervenire su una VM. Se entrambi sono guasti, prevedere interruzione, non promettere recovery senza downtime.

1. Network security groups > [NSG firewall] > Inbound security rules > allow_ssh: identificare accesso del runner al mapping SSH reale. La fonte usa Source: IP address, Source IP addresses/CIDR ranges: 0.0.0.0/0, eccezione temporanea ad alto rischio, non raccomandazione permanente. Preferire un percorso più ristretto verificato; altrimenti richiedere approvazione esplicita, scadenza breve e solo mapping SSH necessario. Non indovinare CIDR Azure né aprire altre porte.
2. Gruppo risorse > Automation account > Runbooks > [runbook distribuito] > Edit > Edit in portal. La revisione conservata indica commentare righe 20–24: identificare il blocco previsto nello script reale e salvarne l’originale; non trasferire numeri tra revisioni. Se il ruolo non è chiaro, fermarsi. Save > Publish, controllare diff, Start.
3. Inserire valori di questa VM:

4. Controllare output, errori e stato job. Completed conferma solo completamento: attendere riavvio/accesso, verificare rotta 168.63.129.16, entrambe le probe e applicazione/uscita reale. Solo dopo recuperare la seconda VM con i propri valori.
5. Ripristinare subito restrizioni NSG registrate, anche dopo errore, e verificare accesso effettivo. Mantenere backend sano, conservare errori, ripristinare script se l’edit era errato ed escalare prima di ripetere o toccare l’altro. Completed non prova salute al 100 % né internet.

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

1. In Effective routes di una VM di test, verificare che 0.0.0.0/0 punti all’IP LAN SFOS o, in active-active, all’IP del Load Balancer interno.
2. Testare DNS, HTTPS e applicazione, quindi confermare Rule ID, origine e destinazione in Log viewer > Firewall. Per un servizio pubblicato eseguire un test positivo da una rete sorgente consentita e uno negativo da una rete non consentita. Verificare separatamente la destinazione DNAT e il percorso di ritorno del server.
3. 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. Documentare separatamente backup, ricostruzione, assegnazione della licenza, responsabile e allarme sui costi.

Proseguire con il runbook interno Azure VPN Gateway o la configurazione Entra Domain Services nel runbook AD.