Sophos Firewall auf Azure bereitstellen und routen

Sophos Firewall kann aus dem Azure Marketplace als einzelne Appliance oder über das Sophos-Template mit zwei Firewalls und Azure Load Balancern bereitgestellt werden. Sophos nennt das zweite Design active-active HA. Es ist jedoch kein natives SFOS-HA-Paar: Beide Firewalls werden separat registriert und konfiguriert; das Template synchronisiert weder Konfiguration noch Sessions.

⚠️ Azure-Routing gehört zur Firewall-Konfiguration. Eine korrekte SFOS-Regel reicht nicht, wenn eine User Defined Route (UDR), Network Security Group (NSG) oder der Rückweg am Load Balancer fehlt. Eine Änderung wird deshalb immer als kompletter Hin- und Rückpfad geprüft.

Betriebsmodell und Lizenz wählen

Sophos nennt Standard_F2s_v2 mit zwei vCPU, 4 GB RAM und mindestens zwei NICs als Mindestgrösse. Die tatsächliche Grösse richtet sich zusätzlich nach Durchsatz, aktivierten Schutzfunktionen und Azure-Quotas.

Für neue Standalone-Deployments wird eine Standard-SKU-Public-IP verwendet. Sie wird vor dem Marketplace-Deployment unter Public IP addresses > Create mit IP version: IPv4, SKU: Standard, Availability zone: 1, Tier: Regional, IP address assignment: Static und Routing preference: Microsoft network angelegt. Einen eindeutigen DNS name label festlegen und Domain name label scope: None wählen. Sophos nennt für diesen Ablauf ausserdem DDoS protection > Protection type: Network. Diese Option setzt einen passenden Azure-DDoS-Plan voraus und kann zusätzliche Kosten verursachen; deshalb wird der Plan vor dem Erstellen mit dem Azure-Verantwortlichen geklärt. In der Sophos-Maske wird die Adresse danach unter Public IP name ausgewählt. Sophos unterstützt für diesen Ablauf ausdrücklich nur Zone 1. Die frühere Alternative mit einer dynamischen Basic-SKU-IP ist seit dem Azure-Rückzug der Basic SKU keine Grundlage für ein neues Deployment.

Standalone aus dem Marketplace bereitstellen

Adressplan vorbereiten

Ein übertragbares Beispiel ist:

• VNet 10.20.0.0/16
• LAN-Subnetz 10.20.10.0/24, PortA
• WAN-Subnetz 10.20.20.0/24, PortB
• statische private LAN-IP der Firewall 10.20.10.4

Diese privaten RFC-1918-Netze sind Platzhalter. Sie werden durch freie Bereiche der eigenen Umgebung ersetzt und dürfen sich weder untereinander noch mit Peering-, VPN- oder On-Premises-Netzen überschneiden. Die LAN-IP bleibt innerhalb des LAN-Subnetzes für die Appliance reserviert; sie ist später der Next Hop der UDR.

Appliance erstellen und absichern

1. Im Azure Marketplace Sophos Firewall > Create öffnen und unter Basics Subscription, Resource Group, Region, VM name sowie ein starkes initiales admin-Passwort eintragen.
2. Unter Instance details BYOL oder PAYG und die geprüfte VM-Grösse wählen. VNet, LAN subnet, WAN subnet, die zuvor erstellte Standard-SKU-IP unter Public IP name sowie einen Storage Account festlegen.
3. Nach erfolgreicher Azure-Validierung Create wählen. Anschliessend unter Virtual machines > den DNS-Namen kopieren und https://<dns-name>:4444 öffnen.
4. Mit admin und dem Deployment-Passwort anmelden, Nutzungsbedingungen bestätigen, die Firewall registrieren und die Erstkonfiguration abschliessen.
5. Die NSG an der WAN-NIC so einschränken, dass WebAdmin und SSH nur aus benannten Adminnetzen erreichbar sind. Geschäftsdienste werden erst geöffnet, wenn SFOS-Regel, Azure-Regel und Rückweg gemeinsam vorbereitet sind.

LAN-UDR mit exakten Azure-Feldern erstellen

Für die Umstellung wird ein Wartungsfenster benötigt: Sophos verlangt, die VM vor dem Wechsel der privaten LAN-IP auf statisch zu stoppen.

1. Unter Virtual machines > > Stop die VM anhalten.
2. Die LAN-NIC öffnen, dann Settings > IP configurations > ipconfig. Allocation: Static wählen, die aktuelle LAN-IP beibehalten beziehungsweise die reservierte Adresse eintragen und speichern. Danach die VM wieder starten.
3. Unter Route tables > Create Subscription, dieselbe Resource Group und Region sowie beispielsweise den Namen rt-workloads-via-sfos eintragen. Propagate gateway routes bleibt nur dann Yes, wenn propagierte Gateway-Routen zum eigenen VPN-/ExpressRoute-Design passen.
4. In der Route Table unter Subnets > Associate jedes Client- oder Workload-Subnetz auswählen, dessen Traffic durch die Appliance laufen soll. Liegen die Clients direkt im LAN-Subnetz von PortA, wird genau dieses LAN-Subnetz zugeordnet, wie es Sophos im Basisbeispiel zeigt. Das WAN-Subnetz der Firewall wird nicht zugeordnet.
5. Unter Routes > Add folgende Werte setzen: Route name: default-via-sfos, Destination type: IP Addresses, Destination IP addresses/CIDR ranges: 0.0.0.0/0, Next hop type: Virtual appliance, Next hop address: 10.20.10.4.
6. An beiden Azure-NICs der Firewall Enable IP forwarding kontrollieren. Azure benötigt diese Einstellung, damit eine NIC Pakete weiterleiten darf, deren Quelle oder Ziel nicht ihre eigene IP ist.
7. In SFOS unter Rules and policies > Firewall rules eine möglichst enge LAN-zu-WAN-Regel mit Logging erstellen. Netzwerkobjekte, Zonen und Dienste werden an die eigene Umgebung angepasst; Any ist kein sinnvoller Dauerzustand.

Die Default-UDR zwingt Internet-Traffic des verknüpften Workload-Subnetzes zur Firewall. Spezifischere Azure-Routen haben weiterhin Vorrang. Für eine route-based Verbindung zum Azure VPN Gateway müssen deshalb auch propagierte und selbst definierte Routen zum XFRM-, SD-WAN- oder BGP-Design passen.

Load-balanced active-active betreiben

Das aktuelle Sophos-Template erstellt zwei Firewalls, einen externen und einen internen Standard Load Balancer mit HA Ports. Die Vorgaben des Templates sind ein /16-VNet sowie je ein /24 für LAN und WAN. Diese Präfixe werden nicht eigenmächtig geändert: Sophos verlangt vor abweichenden Subnetzgrössen die Abstimmung mit dem Sophos-Ansprechpartner.

Bei der Bereitstellung wird Trusted network zunächst als * benötigt, weil das Azure Automation Runbook über öffentliche Azure-Adressen zugreift. Nach erfolgreichem Runbook wird die NSG sofort wieder auf dokumentierte Admin-CIDRs begrenzt. Die erste Firewall erreicht man standardmässig über WebAdmin-Port 4444 und SSH-Port 2222, die zweite über 4445 und 2223. Beide Appliances werden separat registriert; Firewall-, NAT- und Routingänderungen müssen auf beiden identisch gepflegt werden.

Probes und Egress konfigurieren

Die Load Balancer prüfen TCP 4444 und 3128. Wenn andere Ports verwendet werden, müssen interne und externe Probe unterschiedliche Ports nutzen. Die NSG erlaubt den Probe-Pfad mit dem Source Service Tag AzureLoadBalancer; in der Appliance erscheint 168.63.129.16 als Quelladresse. SFOS-Listener und die von Sophos dokumentierten Spezialrouten müssen ebenfalls passen. Weder der Service Tag noch die Plattformadresse werden als allgemeine vertrauenswürdige Internetquelle behandelt.

Auf beiden Firewalls werden unter Routing > Gateways die internen und externen Load-Balancer-Gateways und unter Routing > SD-WAN routes die dokumentierten Probe-Routen angelegt. Die externe Probe-Route muss über der internen stehen. Für Workload-Egress zeigt die Azure-Route 0.0.0.0/0 mit Next hop type: Virtual appliance nicht auf eine Firewall-NIC, sondern auf die Frontend-IP des internen Load Balancers. Auf beiden Firewalls braucht es zusätzlich dieselbe geloggte LAN-zu-WAN-Regel.

Unter Load balancer > Monitoring > Insights beziehungsweise in der Metrik Health Probe Status müssen beide Backend-Instanzen gesund erscheinen. Eine erfolgreiche Probe bestätigt nur, dass der konfigurierte Probe-Port antwortet; sie ersetzt keinen Anwendungs- oder Rückwegtest.

DNAT und symmetrischen Rückweg planen

Bei eingehendem Traffic verteilt der externe Load Balancer den Dienst an eine Firewall. HA Ports transportieren NVA-Flows protokoll- und portübergreifend, ersetzen aber keine dienstspezifische Veröffentlichung. Für den veröffentlichten TCP-Dienst wird deshalb am externen Load Balancer eine passende Health Probe und Load-Balancing-Regel erstellt und miteinander verknüpft. Die SFOS-NAT-Regel übersetzt danach zum internen Server. In diesem Design setzt man in Rules and policies > NAT rules Translated source (SNAT): MASQ, damit der Server an die LAN-IP derselben Firewall antwortet. Ohne MASQ kann die Antwort über den internen Load Balancer und die andere Firewall laufen; die Session bricht dann durch asymmetrisches Routing.

Direktes RDP aus dem Internet ist keine Empfehlung. Wenn möglich werden VPN oder ZTNA verwendet. Muss ein Dienst veröffentlicht werden, werden Load-Balancer-Regel, NSG sowie NAT- und Firewall-Regel auf die erforderlichen Quellen und Ports begrenzt. Logging und ein passendes IPS-Profil gehören zur Freigabe.

Validieren, Fehler eingrenzen und zurückrollen

Abnahme

1. In Azure die Effective routes einer Test-VM prüfen: Für 0.0.0.0/0 muss die erwartete Firewall-LAN-IP oder beim Active-Active-Design die interne Load-Balancer-IP als Next Hop erscheinen.
2. Von einer definierten Test-VM DNS, HTTPS-Egress und den tatsächlich benötigten Dienst testen. Gleichzeitig in Log viewer > Firewall die erwartete Rule ID, Quell- und Zieladresse kontrollieren.
3. Bei einer Veröffentlichung einen Positivtest aus einem erlaubten und einen Negativtest aus einem nicht erlaubten Quellnetz durchführen. DNAT-Ziel und Server-Rückweg separat prüfen.
4. Beim Active-Active-Design Health Probe Status und Backend Pool kontrollieren. Nur im Wartungsfenster jeweils eine Firewall aus dem Backend nehmen, neue Verbindungen über die verbleibende Instanz prüfen und die entfernte Instanz vor dem zweiten Durchlauf wieder als gesundes Backend aufnehmen. Bestehende Sessions sind nicht synchronisiert und können bei diesem Test abbrechen.

Typische Fehler

• Kein Egress nach Zuordnung der Route Table: Effective Routes, Zuordnung zum richtigen Workload-Subnetz, statische LAN-IP, IP Forwarding, NSG und SFOS Rule ID in dieser Reihenfolge prüfen.
• Probe ist unhealthy: Port und TCP-Protokoll, Listener, NSG sowie die SD-WAN-Routen für 168.63.129.16 kontrollieren. Eine pauschale Freigabe aus dem Internet behebt keine Probe.
• Probe fällt nach einem SFOS-Upgrade aus: Die vom Automation Runbook injizierten Spezialrouten sind nicht persistent. Das von Sophos gelieferte Runbook für beide VMs erneut ausführen, Probe-Status prüfen und eine dafür vorübergehend erweiterte SSH-NSG unmittelbar wieder auf die erlaubten Admin-CIDRs zurücksetzen.
• DNAT funktioniert nur sporadisch: Auf beiden Firewalls dieselbe NAT-/Firewall-Regel, Translated source (SNAT): MASQ, Load-Balancer-Backend und Rückroute des Zielservers vergleichen.

Vor einem Egress-Rollback wird der frühere, freigegebene Next Hop dokumentiert. Dann wird entweder die vorherige Route Table wieder zugeordnet oder das Workload-Subnetz während der Änderung isoliert. Die neue Route Table einfach zu trennen kann Azures Systemroute 0.0.0.0/0 -> Internet aktivieren und die Firewall umgehen; das ist nur zulässig, wenn dieser Pfad ausdrücklich geprüft und gewollt ist. Erst nach wiederhergestelltem, validiertem Rückweg werden UDR oder temporäre Regeln entfernt. Bei einer DNAT-Freigabe wird die externe Load-Balancer-Regel deaktiviert beziehungsweise entfernt, bevor Azure- und SFOS-Regeln zurückgebaut werden. Azure-Snapshots ersetzen kein exportiertes SFOS-Backup; Backup, Wiederaufbau, Lizenzzuordnung, Owner und Kostenalarm werden separat dokumentiert.

Weiterführende Links

• Microsoft: Routing für virtuelle Netzwerke, Network Virtual Appliance und IP Forwarding sowie Azure Load Balancer Health Probes
• Microsoft: Plattformadresse 168.63.129.16 und HA Ports