Sophos Firewall auf AWS bereitstellen und betreiben

Sophos Firewall 22 läuft in AWS als virtuelle EC2-Appliance inline in einer VPC. Für ein belastbares Design muss zuerst feststehen, welcher Verkehr durch die Firewall laufen soll. Eine Standalone-Firewall kann eingehenden und ausgehenden Verkehr prüfen. Das Sophos-Auto-Scaling-Template ist dagegen ein spezialisiertes PAYG-Design für eingehenden DNAT- oder WAF-Traffic.

Der sichere Kurzablauf lautet: Architektur und Lizenz wählen, IP- und Routingplan festhalten, das passende Marketplace-Template starten, Managementzugriff auf eine feste Quell-IP begrenzen, einen einzelnen Testfluss Ende zu Ende prüfen und erst danach weitere Dienste freigeben.

⚠️ AWS Security Groups bleiben eine zweite Firewall-Ebene. Eine erlaubende SFOS-Regel reicht nicht, wenn Security Group, NACL oder Route Table den Pfad blockiert. Umgekehrt darf ein offener AWS-Port nicht durch eine breite Sophos-Regel ergänzt werden. Security Groups sind zustandsbehaftet, Network ACLs nicht; bei einer benutzerdefinierten NACL müssen deshalb Hin- und Rückrichtung passen.

Standalone oder Auto Scaling wählen

AWS unterstützt für Sophos Firewall kein natives Appliance-HA. Auto Scaling und Network Load Balancing sind ein eigenes Cloud-Design und kein Ersatz für die SFOS-HA-Synchronisation. Wer eine einzelne Firewall einsetzt, plant daher auch den Wiederaufbau und die mögliche Unterbrechung bei Wartung oder Ausfall ein.

Für die Instanzwahl gelten drei Gates: Der EC2-Typ muss im aktuell geöffneten Marketplace-CloudFormation-Template für die gewählte Region und AMI auswählbar sein, seine Leistung muss zum erwarteten Durchsatz und Verbindungsprofil passen und bei BYOL dürfen vCPU und RAM die gekaufte virtuelle Firewall-Lizenz nicht überschreiten. Wähle die kleinste angebotene Grösse, welche diese Anforderungen mit Reserve erfüllt, und dokumentiere EC2-Typ, AMI beziehungsweise SFOS-Version und Lizenzgrenze im Bauplan. Bei PAYG endet die Softwareabrechnung erst, wenn alle betreffenden Firewall-Instanzen aus dem AWS-Konto entfernt sind.

Fehlt der geplante Typ im Template oder weist CloudFormation die Kombination aus Region, AMI und Grösse zurück, darf sie nicht mit einem manuellen Template-Override erzwungen werden. Wähle einen angebotenen Typ, der Lastprofil und Lizenz erfüllt, oder stoppe das Deployment, bis Region, Angebot oder Lizenz geklärt sind.

Standalone-Deployment vorbereiten

Vor dem Start gehören diese Werte in einen kurzen Bauplan:

• AWS-Konto, Region, Availability Zone und BYOL- oder PAYG-Angebot;
• neue oder bestehende VPC sowie kollisionsfreie CIDRs für Public und Private Subnet;
• feste Admin-Quelladresse, beispielsweise 198.51.100.27/32, statt einer weltweiten Managementfreigabe;
• Elastic IP, DNS-Namen und benötigte eingehende Dienste;
• private Zielnetze, Default Route und erwarteter Rückweg für jeden Testfluss;
• unterstützter EC2-Typ, Lizenzgrenze, Kostenverantwortlicher und Tags;
• Backup-, Firmware- und Wiederaufbauverfahren.

198.51.100.27/32 ist eine Dokumentationsadresse und muss durch die tatsächliche öffentliche Adresse des Admin-Zugangs ersetzt werden. Ändert sich diese Adresse regelmässig, ist ein Managementzugang über VPN oder einen kontrollierten Jump Host sicherer als eine breite Freigabe von TCP 4444.

Bei einer bestehenden VPC dürfen Public und Private Subnet nicht nur anhand ihres Namens gewählt werden. Ihre Route Tables müssen zur geplanten Richtung passen. AWS beschreibt die Einbindung einer Netzwerk-Appliance und die dafür nötigen Routen in den Middlebox-Routing-Beispielen. Ausserdem muss der Source/Destination Check der Firewall-ENIs deaktiviert sein, weil die Appliance fremden Traffic weiterleitet. Das CloudFormation-Deployment soll diese Plattformdetails setzen; nach dem Aufbau werden sie kontrolliert und nicht blind geändert.

Standalone mit CloudFormation bereitstellen

1. Im AWS Marketplace das Sophos-Firewall-Angebot für BYOL oder PAYG öffnen, View purchase options wählen und die Bedingungen akzeptieren.
2. Unter Continue to Configuration die Fulfillment-Option, die aktuelle SFOS-Softwareversion und die gewünschte Region festlegen.
3. Unter Continue to Launch als Aktion Launch CloudFormation wählen und das Template in der AWS CloudFormation Console öffnen.
4. Einen eindeutigen Stack name vergeben. Bei einer neuen VPC die vorgeschlagenen Adressbereiche auf Überschneidungen mit bestehenden VPCs, VPNs und lokalen Netzen prüfen.
5. Bei einer bestehenden VPC die VPC-ID, genau ein vorhandenes Public Subnet, ein vorhandenes Private Subnet und eine neue oder freie vorhandene Elastic IP zuordnen. Den Parameter Network Address Prefix for new VPC dabei unverändert lassen.
6. Nur eine EC2-Grösse verwenden, die das geöffnete Template für Region und AMI anbietet, und sie bei BYOL nochmals gegen die im Bauplan festgehaltene Lizenzgrenze prüfen. Passwörter und andere Geheimnisse nicht in Tickets, Screenshots oder frei lesbaren Parameterdateien ablegen.
7. Die vom Template angeforderten IAM-Ressourcen prüfen. Erst danach I acknowledge that AWS CloudFormation might create IAM resources bestätigen und den Stack mit Submit starten.
8. Auf CREATE_COMPLETE warten. Unter Outputs die Elastic IP ablesen und in der EC2 Console zusätzlich beide Instanz-Statusprüfungen sowie die erwarteten ENIs kontrollieren.
9. WebAdmin aus der zuvor festgelegten Adminquelle über https://<EIP>:4444 öffnen. Die Warnung für das anfänglich lokal signierte Zertifikat nur nach Kontrolle der Ziel-IP übergehen, die Nutzungsbedingungen akzeptieren und Registrierung sowie Basiskonfiguration abschliessen. Danach unter Administration > Licensing prüfen, ob die erwartete Lizenz aktiv ist; bei einer Abweichung Instanzgrösse und Lizenzzuordnung korrigieren, bevor produktiver Traffic freigegeben wird.

Marketplace-Parameter können sich ändern; gleiche die sichtbaren Feldnamen deshalb vor jedem produktiven Rollout mit dem tatsächlich geöffneten Template ab.

AWS- und SFOS-Regeln gemeinsam öffnen

Das Sophos-Template aktiviert standardmässig nur Managementzugriff für WebAdmin und SSH. IPsec, SSL VPN, RED, WAF, User Portal oder veröffentlichte Anwendungen benötigen zusätzlich passende AWS-Security-Group-Regeln. RED verwendet beispielsweise TCP 3410.

Für jede Freigabe werden Protokoll, Zielport und Quelle identisch dokumentiert, aber auf beiden Ebenen separat umgesetzt:

1. Die Security Group erlaubt nur die benötigte Quelle zum benötigten Port der richtigen ENI.
2. Eine benutzerdefinierte NACL erlaubt den Request und den dazugehörigen Rückverkehr. AWS erläutert den Unterschied in der Dokumentation zu Security Groups und Network ACLs.
3. Die Route Table führt den Datenpfad tatsächlich über die Firewall und besitzt einen gültigen Rückweg.
4. Die SFOS-Firewall- und gegebenenfalls NAT-Regel verwendet konkrete Zonen, Hosts und Services, ist geloggt und enthält die passenden Security-Profile.

SSH und WebAdmin werden niemals vorsorglich für 0.0.0.0/0 geöffnet. Auch ein enger AWS-Zugriff ersetzt keine saubere SFOS-Regel: So bleibt die beabsichtigte Policy verständlich, wenn später Security Groups oder Routen geändert werden.

Auto Scaling für Inbound-Traffic aufbauen

Für Auto Scaling sind ein AWS-Konto, das Marketplace-Angebot Sophos Cloud Firewall (PAYG) und Sophos-Fusion-API-Zugangsdaten nötig. In Sophos Fusion (ehemals Sophos Central) wird unter My products > General settings > API credentials management eine neue Credential mit der Rolle Service principal firewall erstellt. Client ID und Client Secret werden wie ein Passwort behandelt und nur im vorgesehenen Deployment-Schritt verwendet.

Im Marketplace wird als Fulfillment-Option Sophos Auto Scaling Firewall for AWS gewählt. Das Template benötigt zwei verschiedene Availability Zones. Bei einer bestehenden VPC werden zwei Public Subnets und ein Private Subnet angegeben; auf beiden Public Subnets muss Auto-assign public IPv4 address aktiviert sein.

Besonders wichtig sind diese Parameter:

• Trusted Network CIDR: die öffentliche Adminadresse als /32, niemals 0.0.0.0/0;
• Public Network CIDR: 0.0.0.0/0 erlaubt Nicht-Management-Ports aus dem gesamten Internet. Avanet empfiehlt, hier bereits die bekannten Quellnetze einzutragen oder den Wert unmittelbar nach dem Deployment zu reduzieren;
• Minimum capacity: kleinste Anzahl ständig gewünschter Worker;
• Starting capacity: anfangs gestartete Worker. Setze diesen Wert beim Erstaufbau auf Maximum capacity, damit alle Worker gemeinsam registriert und der Fusion-Gruppe hinzugefügt werden;
• Maximum capacity: harte Obergrenze für Worker und damit auch für Kosten;
• Warm Pool Refresh Period: Intervall, nach dem gestoppte Warm-Pool-Instanzen starten und ihre Gruppenpolicy aus Sophos Fusion synchronisieren; der Default beträgt fünf Tage;
• Use CloudWatch: aktiviert die Übergabe der Firewall-Logs an CloudWatch Logs.

Nach CREATE_COMPLETE wird unter My products > Firewall management > Firewalls geprüft, ob die automatisch erstellte Gruppe existiert und alle erwarteten PAYG-Worker darin freigegeben sind. Erst danach werden Capacity oder Scaling Policy verändert.

DNAT hinter dem Network Load Balancer

Für einen freigegebenen Dienst führt ein TCP-Listener des AWS Network Load Balancers zu einer Target Group der Firewall-Worker. In der Sophos-Fusion-Gruppenpolicy werden die WAN-Subnetze beider Availability Zones als IP-Ranges, der interne Zielhost und ein Service für den tatsächlich veröffentlichten Port angelegt. Die erste IP-Adresse jedes AWS-Subnetzes gehört nicht in die Range.

Die Firewallregel matcht in diesem Single-Arm-Design von WAN nach WAN auf die WAN-Ranges und den exakten Service. Die DNAT-Regel übersetzt zum internen Server und verwendet bei diesem Design MASQ als translated source, damit der Rückweg wieder über denselben Firewall-Worker läuft. Anschliessend werden Target Group, Auto Scaling Group und NLB-Listener verbunden.

Direkte RDP-Veröffentlichung ist keine Empfehlung. Wenn möglich werden VPN oder ZTNA eingesetzt. Ist DNAT unvermeidbar, werden Quelladressen am NLB, in AWS und in SFOS eingeschränkt, IPS und Logging aktiviert und ein negativer Test aus einer nicht erlaubten Quelle durchgeführt.

Abnahme: einen Flow Schicht für Schicht prüfen

Für die erste Abnahme wird genau ein Flow notiert, etwa 198.51.100.27:55000 -> NLB-DNS:443 -> App-Server:443. Der Quellport ist nur ein Beispiel für einen kurzlebigen Client-Port. Geprüft wird in dieser Reihenfolge:

1. DNS und NLB-Listener zeigen auf das erwartete Ziel; die Target Group meldet die erwarteten Worker als healthy.
2. Security Groups und NACLs erlauben genau diesen Hin- und Rückweg.
3. Subnet Route Tables und ENIs führen den Traffic durch die Appliance; Source/Destination Check ist für die weiterleitenden Firewall-Interfaces deaktiviert.
4. Im SFOS Log Viewer erscheint die erwartete Firewall Rule ID. Bei DNAT stimmen Original- und übersetztes Ziel sowie der Rückweg.
5. Der erlaubte Test liefert die erwartete Anwendung, ein Test von einer nicht erlaubten Quelle bleibt blockiert.

Ist kein SFOS-Logeintrag vorhanden, liegt der Fehler meist vor der Firewall: DNS, Listener, Target Health, Security Group, NACL oder Route prüfen. Erscheint ein Drop mit unerwarteter Rule ID, zuerst Zonen, Netzobjekte, Service und Regelreihenfolge korrigieren. Funktioniert der Hinweg, aber keine Antwort kommt zurück, sind Route Table, NACL, Server-Default-Gateway und bei Auto Scaling die MASQ-Einstellung die nächsten Prüfpunkte.

Betrieb und Wiederherstellung

Standalone und Auto Scaling brauchen unterschiedliche Runbooks. Bei Standalone werden ein SFOS-Backup und eine geprüfte Wiederherstellung, der Firmwareprozess, CloudFormation-Parameter und ein Wiederaufbau-Test dokumentiert. Ein EC2-Snapshot ersetzt kein exportiertes SFOS-Backup.

Auto-Scaling-Worker sind kurzlebig. Wenn CloudWatch aktiviert wurde, liegen ihre Logs in Log Groups unter /sophos/xg/; Aufbewahrung, Verschlüsselung, Zugriff und Kosten müssen bewusst konfiguriert werden. Beendete EC2-Instanzen bleiben in der Fusion-Firewallgruppe sichtbar und müssen dort manuell entfernt werden. Ein Warm Pool synchronisiert gestoppte Instanzen in seinem Intervall, ersetzt aber nicht die Kontrolle, ob eine neue Gruppenpolicy auf allen laufenden Workern angekommen ist.

Zum Betriebsprotokoll gehören Owner- und Kosten-Tags, Budgetalarm, Lizenzstatus, Secret-Rotation, CloudWatch-Retention, Fusion-Bereinigung, Firmwarefreigabe, Änderungstest und Wiederherstellung. Nach jeder Template-, Routing- oder Policy-Änderung wird der definierte positive und negative Flow erneut geprüft. So belegt die Abnahme nicht nur, dass die Instanz läuft, sondern dass AWS und SFOS gemeinsam genau den vorgesehenen Verkehr zulassen.