Sophos Firewall op Azure implementeren en routeren

Sophos Firewall kan vanuit Azure Marketplace als één appliance of via een Load Balancer-template met twee firewalls worden geïmplementeerd. Sophos noemt het tweede ontwerp active-active, maar het is geen native SFOS-HA-cluster. Beide firewalls worden afzonderlijk geregistreerd en geconfigureerd; de template synchroniseert configuratie noch sessies.

⚠️ Azure-routing hoort bij de firewallconfiguratie. Een correcte SFOS-regel is niet genoeg wanneer een User Defined Route, Network Security Group of het retourpad van de Load Balancer ontbreekt. Valideer elke vrijgave als volledige heen- en terugweg.

Bedrijfsmodel en licentie kiezen

Azure-infrastructuur en Sophos-software hebben afzonderlijke kosten. PAYG wordt volgens het beschreven model per uur zonder minimumverplichting afgerekend en omvat Xstream; losse abonnementen en Enhanced Plus Support kunnen niet worden toegevoegd. Controleer factureringsland tegen de Microsoft-remittancelanden en het werkelijke aanbod; kies BYOL als PAYG niet beschikbaar is. BYOL via een erkende reseller biedt bundels, losse abonnementen (Network Protection, Web Protection, Zero-Day Protection) en support inclusief Enhanced Plus Support. Gedocumenteerde looptijden zijn één, twee of drie jaar: controleer aanbod en rechten zonder prijs- of supportbelofte. Software stoppen verwijdert geen factureerbare Azure-resources.

Sophos noemt Standard_F2s_v2 met twee vCPU, 4 GB RAM en minimaal twee NIC’s als minimumgrootte. Stem de werkelijke grootte ook af op doorvoer, ingeschakelde beveiligingsfuncties en Azure-quota. Gebruik een statisch toegewezen publiek IP met Standard SKU. Basic SKU is uitgefaseerd en hoort niet in nieuwe implementaties.

Standalone vanuit Marketplace implementeren

Appliance maken en beveiligen

1. Selecteer Sophos Firewall in Azure Marketplace en kies BYOL of PAYG.
2. Definieer Resource Group, regio en grootte. Kies onder Instance details ook een Storage Account. VNet, subnetten en externe netwerken mogen niet overlappen.
3. Koppel PortA aan LAN en PortB aan WAN. Open NSG’s aanvankelijk alleen voor vereiste beheerbronnen.
4. Voltooi de implementatie en open WebAdmin op https://<dns-name>:4444. Gebruik voor de eerste aanmelding admin en het sterke adminwachtwoord dat tijdens de implementatie is ingesteld; bevestig de gebruiksvoorwaarden.
5. Rond setup, registratie, licentie en firmware gecontroleerd af.
6. Stop de VM vóór het wijzigen van de private LAN-IP naar Static, behoud het huidige adres of gebruik het gereserveerde adres en start de VM daarna opnieuw. Voeg aan elk workloadsubnet een UDR 0.0.0.0/0 toe met Virtual appliance en dit LAN-adres als Next Hop.
7. Test IP Forwarding, NSG’s, SFOS-regels en retourpad met een gedefinieerde client.

De standaard-UDR stuurt internetverkeer van het gekoppelde workloadsubnet via de firewall. Specifiekere Azure-routes blijven voorrang houden. Zonder UDR gebruikt Azure het standaardpad. Een route-based verbinding met Azure VPN Gateway gebruikt de XFRM-interface daarnaast met statische routes, SD-WAN of BGP.

Adresplan voorbereiden

Maak voor een nieuwe implementatie eerst het publieke IP onder Public IP addresses > Create met IP version: IPv4, SKU: Standard, Availability zone: 1, Tier: Regional, IP address assignment: Static en Routing preference: Microsoft network. Stel een uniek DNS name label in en kies Domain name label scope: None. Sophos vermeldt voor deze procedure ook DDoS protection > Protection type: Network. Die optie vereist een passend Azure DDoS-plan en kan extra kosten veroorzaken; stem het plan daarom vóór het maken van het adres af met de Azure-verantwoordelijke. Selecteer het adres daarna bij Public IP name. Availability zone: 1 is de gedocumenteerde voorbeeldkeuze. Afzonderlijk geldt een beperking tot één beschikbaarheidszone; dit bewijst geen exclusieve ondersteuning van zone 1 en valideert geen andere zones of multizoneontwerp. De vroegere dynamische Basic-optie is na uitfasering door Azure geen basis meer voor een nieuwe implementatie.

Een aanpasbaar voorbeeld gebruikt VNet 10.20.0.0/16, LAN 10.20.10.0/24 op PortA, WAN 10.20.20.0/24 op PortB en statisch LAN-IP 10.20.10.4. Vervang deze RFC 1918-waarden door vrije bereiken zonder onderlinge overlap of overlap met peering, VPN of on-premises-netwerken. Reserveer het LAN-IP binnen het LAN-subnet voor de appliance; dit wordt later de Next Hop van de UDR.

LAN-UDR met exacte Azure-velden maken

Sophos vereist dat de VM stopt voordat het LAN-IP statisch wordt: Virtual machines > > Stop, daarna LAN-NIC, Settings > IP configurations > ipconfig, Allocation: Static. Maak na herstart de tabel via Route tables > Create. Koppel onder Subnets > Associate elk client- of workloadsubnet waarvan het verkeer door de appliance moet lopen. Bevinden clients zich rechtstreeks in het LAN-subnet van PortA, koppel dan dat LAN-subnet, zoals in het basisvoorbeeld van Sophos. Koppel het WAN-subnet van de firewall niet. Gebruik onder Routes > Add: Route name: default-via-sfos, Destination type: IP Addresses, Destination IP addresses/CIDR ranges: 0.0.0.0/0, Next hop type: Virtual appliance en Next hop address: 10.20.10.4. Controleer Enable IP forwarding op beide NIC’s. Laat Propagate gateway routes: Yes alleen staan als dit past bij VPN/ExpressRoute. Maak ten slotte een beperkte, gelogde LAN-naar-WAN-regel onder Rules and policies > Firewall rules.

Active-active met Load Balancer beheren

De Sophos-template maakt twee firewalls en een externe en interne Standard Load Balancer met HA Ports. Ze vereist een /16 VNet en /24 LAN- en WAN-subnetten; Sophos vraagt overleg met de Sophos-contactpersoon voordat andere subnetgroottes worden gebruikt.

Health probes bereiken WebAdmin op 4444 en de proxy op 3128. Interne probes zijn ook afhankelijk van speciale routes naar platformadres 168.63.129.16 die het Automation Runbook in de kernelroutingtabel injecteert. Deze routes blijven niet bestaan na een firmware-upgrade; voer het meegeleverde runbook daarna opnieuw uit en controleer het.

Tijdens de implementatie moet Trusted network eerst * zijn, omdat Azure Automation Runbook vanaf publieke Azure-IP’s verbindt. Beperk de NSG direct na succes tot gedocumenteerde beheer-CIDR’s. De eerste firewall gebruikt WebAdmin 4444 en SSH 2222, de tweede 4445 en 2223. Registreer beide appliances afzonderlijk en houd firewall-, NAT- en routingregels gelijk.

Probes en egress configureren

Configureer op beide firewalls gateways onder Routing > Gateways en proberoutes onder Routing > SD-WAN routes; de externe route staat boven de interne. De workload-UDR 0.0.0.0/0 gebruikt Next hop type: Virtual appliance en het frontend-IP van de interne Load Balancer. In de appliance verschijnen TCP-probes 4444 en 3128 met bron 168.63.129.16. Bij andere poorten moeten interne en externe probe verschillend blijven. Sta het probepad in de NSG toe met Source Service Tag AzureLoadBalancer; ook SFOS-listeners en speciale Sophos-routes moeten overeenkomen. Noch de Service Tag, noch het platformadres is een algemeen vertrouwde internetbron. Controleer beide backends via Load balancer > Monitoring > Insights of Health Probe Status; een gezonde probe valideert applicatie en retourpad niet.

Template met voorafgaande controles implementeren

Open de active-active-deploymentresource, controleer en noteer de revisie en kies Deploy to Azure. Controleer vóór Next > Create:

• Subscription, Resource group, Region, Location en beschikbaarheid van Automation accounts in dit abonnement/deze regio.
• De gecontroleerde Base URL, VM name, veilig bewaard Admin password, Image SKU (BYOL/PAYG-new), VM size met minstens twee NIC’s.
• Net new or existing, Net RG, Net name, Net prefix (/16), WAN name/prefix, LAN name/prefix (/24), vrije Loadbalancer Int IP in LAN.
• Nieuw/bestaand, groepen en namen voor Public IP, Storage, Network security group, Availability set, Automation account; Public IP DNS, Storage type, NIC WAN, NIC LAN, Number of instances: 2. Controleer bestaande resources en uniek DNS-label.
• Bewaar oorspronkelijke NSG-regels en goedgekeurde duur van Trusted network: *. Beperk beheer opnieuw, ook bij automatiseringsfouten; stop zonder goedgekeurde tijdelijke uitzondering in plaats van onbeperkt publiek beheer toe te laten.

Inventariseer daarna echte NIC/subnetkoppelingen, gateways, LB-frontends, probes en beheerpoortkoppelingen; kopieer geen standalonevoorbeeld.

Gateways en proberoutes op beide appliances

Maak en bewaar onder Routing > Gateways > Add:

Het bewaarde voorbeeld gebruikt 10.54.11.1/10.54.22.1 en WAN voor beide gateways, maar bindt interne/externe routes later aan #PortA/#PortB. Deze ongebruikelijke mapping is deploymentspecifiek. Controleer NIC’s, SFOS-interfaces en subnetbereikbaarheid; stop bij tegenstrijdigheid en overleg met de eigenaar, zonder IP’s blind te kopiëren of een universele mapping te verzinnen.

Onder Routing > SD-WAN routes > Add eerst intern, daarna extern, beide Top:

Controleer objecten en servicedefinitie tegen de echte flow: HTTP betekent niet probes TCP 4444/3128 naar 80 wijzigen. Maak van de ongespecificeerde interne service geen brede route; bron/doel blijven beperkt. Bewaar, houd extern boven intern en herhaal de gecontroleerde mapping op appliance 2. Controleer Load balancers > Monitoring > Metrics > Health probe status, aggregatie Avg, filter Backend IP address, per backend/LB; test echte egress en retour.

Geïnjecteerde routes na firmware herstellen

Plan onderhoud: het beschreven runbook herstart de VM en kan sessies onderbreken. Exporteer SFOS-backups, bewaar runbook/NSG en controleer de andere backend vóór werk aan één VM. Bij twee ongezonde backends een onderbreking plannen, geen herstel zonder uitval beloven.

1. Network security groups > [firewall-NSG] > Inbound security rules > allow_ssh: bepaal runner-toegang tot de echte SSH-mapping. De bron gebruikt Source: IP address, Source IP addresses/CIDR ranges: 0.0.0.0/0, een risicovolle tijdelijke uitzondering, geen permanent advies. Geef voorkeur aan een geverifieerd smaller pad; anders expliciete toestemming, korte termijn en alleen vereiste SSH-mapping. Geen Azure-CIDR gokken of andere poorten openen.
2. Resourcegroep > Automation account > Runbooks > [geïmplementeerd runbook] > Edit > Edit in portal. De bewaarde revisie noemt regels 20–24 uitcommentariëren: identificeer het bedoelde blok in het echte script en bewaar het origineel; geen regelnummers op andere revisies toepassen. Stop bij onduidelijk doel. Save > Publish, diff controleren, Start.
3. Voer waarden voor deze VM in:

4. Controleer jobuitvoer, fouten en status. Completed bevestigt alleen jobafronding: wacht op herstart/toegang, controleer route 168.63.129.16, beide probes en echte applicatie/egress. Herstel pas daarna VM 2 met eigen waarden.
5. Herstel vastgelegde NSG-beperkingen direct, ook bij fouten, en controleer effectieve toegang. Laat gezonde backend werken, bewaar fouten, herstel script bij verkeerde wijziging en escaleer vóór herhaling of werk aan de andere backend. Completed bewijst geen 100 % gezondheid of internet.

DNAT en retourpad

De externe Load Balancer kiest een firewall. HA Ports dragen NVA-flows over protocollen en poorten, maar vervangen geen servicespecifieke publicatie. Maak voor de gepubliceerde TCP-service op de externe Load Balancer een passende health probe en een Load Balancing-regel die aan die probe is gekoppeld. De SFOS-NAT-regel vertaalt vervolgens naar de server. Stel in Rules and policies > NAT rules Translated source (SNAT): MASQ in, zodat de server naar het LAN-IP van dezelfde firewall antwoordt. Zonder MASQ kan de retourstroom de andere firewall kruisen en de sessie breken.

Directe RDP-publicatie wordt niet aanbevolen. Gebruik liever VPN of ZTNA. Als publicatie nodig is, beperk bron, service en bestemming in Azure en SFOS, activeer logging en IPS en voer een negatieve test uit.

Valideren, problemen oplossen en terugdraaien

Acceptatiecontroles

1. Controleer bij een test-VM in Effective routes dat 0.0.0.0/0 naar het SFOS-LAN-IP of bij active-active naar het interne Load Balancer-IP wijst.
2. Test DNS, HTTPS en de applicatie en bevestig Rule ID, bron en doel in Log viewer > Firewall. Voer voor publicatie een toegestane positieve en een niet-toegestane negatieve test uit.
3. Controleer bij active-active Health Probe Status en Backend Pool. Verwijder alleen in een onderhoudsvenster één firewall, test nieuwe verbindingen via de andere en herstel een gezonde backend vóór de tweede test. Bestaande sessies worden niet gesynchroniseerd en kunnen worden verbroken.

Typische fouten

Controleer bij ontbrekende egress achtereenvolgens Effective Routes, koppeling van het workloadsubnet, statisch LAN-IP, IP forwarding, NSG en SFOS Rule ID. Controleer bij een unhealthy probe TCP-protocol en -poort, listener, NSG en SD-WAN-routes naar 168.63.129.16. Geïnjecteerde routes blijven na een firmware-upgrade niet bestaan: voer het Sophos-runbook voor beide VM’s opnieuw uit, controleer de probes en herstel meteen de beheer-CIDR’s in de SSH-NSG. Vergelijk bij onregelmatige DNAT de regels op beide appliances, MASQ, Backend Pool en retourroute van de server.

Leg vóór een egressrollback de eerder goedgekeurde Next Hop vast. Koppel de vorige Route Table opnieuw of isoleer het workloadsubnet tijdens de wijziging. Alleen de nieuwe tabel loskoppelen kan Azures systeemroute 0.0.0.0/0 -> Internet activeren en de firewall omzeilen; doe dit uitsluitend wanneer dat pad expliciet is beoordeeld en geaccepteerd. Verwijder UDR en tijdelijke regels pas nadat het herstelde retourpad is gevalideerd. Schakel voor DNAT eerst de externe Load Balancer-regel uit. Azure-snapshots vervangen geen geëxporteerde SFOS-back-up. Documenteer back-up, heropbouw, licentietoewijzing, verantwoordelijke en kostenalarm afzonderlijk.

Ga verder met het interne Azure VPN Gateway-runbook of de Entra Domain Services-configuratie in het AD-runbook.