Sophos Firewall op AWS implementeren en beheren

Sophos Firewall 22 draait in AWS als virtuele EC2-appliance inline in een VPC. Bepaal eerst welk verkeer moet worden geïnspecteerd. Een standalone firewall kan inkomend en uitgaand verkeer controleren; de Sophos Auto Scaling-template is een gespecialiseerd PAYG-ontwerp voor inkomend DNAT- of WAF-verkeer.

De veilige korte route: kies architectuur en licentie, leg IP- en routingplan vast, start de juiste Marketplace-template, beperk beheer tot één vast bron-IP, valideer één flow end-to-end en publiceer pas daarna extra diensten.

⚠️ AWS Security Groups blijven een tweede firewalllaag. Een toestemmende SFOS-regel helpt niet wanneer een Security Group, NACL of Route Table het pad blokkeert. Combineer ook geen open AWS-poort met een brede Sophos-regel. Security Groups zijn stateful en Network ACLs stateless; een aangepaste NACL moet daarom aanvraag en retour toestaan.

Standalone of Auto Scaling kiezen

AWS ondersteunt geen native Sophos Firewall-HA. Auto Scaling en Network Load Balancing vormen een ander cloudontwerp, geen SFOS-HA-synchronisatie. Een standalone ontwerp vereist dus ook een rebuildprocedure en een geaccepteerd onderhouds- of storingsvenster.

Voor de instancekeuze gelden drie controles: het EC2-type moet worden aangeboden in de geopende Marketplace CloudFormation-template voor de gekozen regio en AMI; CPU, RAM en netwerkprestaties moeten passen bij de throughput en het verbindingsprofiel; bij BYOL moeten de CPU-licentierechten en de voorwaarden die voor precies deze licentie gelden, bevestigd zijn.

De SFOS-22/23-toewijzing noemt bijvoorbeeld m5.large met 2 vCPU en 8 GB RAM voor SFv2C4 en m5.xlarge met 4 vCPU en 16 GB RAM voor SFv4C6. Dit zijn versie- en aanbodgebonden toewijzingsvoorbeelden, geen toezegging voor elke actuele template. Het historische RAM-suffix van de licentie is daarom geen betrouwbare bovengrens voor het fysieke EC2-RAM; daaruit volgt echter evenmin een algemene toezegging van onbeperkte RAM-licentierechten. Verifieer vóór aankoop de concrete licentie-/aanbodrechten bij Sophos of de licentiepartner en documenteer deze; implementeer bij onduidelijkheid niet in productie.

Kies een aangeboden formaat met capaciteitsreserve en leg het EC2-type, de AMI/SFOS-versie en de bevestigde licentievoorwaarden vast in het bouwplan.

Bij PAYG stopt de softwarefacturatie pas wanneer alle betreffende firewallinstances zijn verwijderd; afzonderlijk achterblijvende AWS-resources kunnen kosten blijven veroorzaken.

Ontbreekt het geplande type in de template of weigert CloudFormation de combinatie van regio, AMI en formaat, forceer deze dan niet met een handmatige templatewijziging. Kies een aangeboden type dat aan belasting en licentie voldoet of stop de deployment totdat regio, aanbod of licentie is opgehelderd.

Licentie en pilot vóór aankoop verifiëren

Als PAYG niet beschikbaar is in het eigen land of aanbod, is Standalone BYOL met een bevestigde licentie een optie; de Auto Scaling-template die uitsluitend PAYG ondersteunt, wordt daardoor niet bruikbaar met BYOL. Via Sophos of een partner kan ook een Private Offer met individueel overeengekomen prijzen en voorwaarden worden onderzocht. BYOL vermijdt de Marketplace-softwarekosten, niet de EC2- en infrastructuurkosten.

Controleer voor een pilot de daadwerkelijke trialrechten, duur en voorwaarden van het geselecteerde aanbod. De historische AWS-FAQ beschrijft een PAYG-softwaretrial van 30 dagen; dit is geen garantie voor het aanbod dat vandaag wordt gekozen. Na afloop van de trial van dat aanbod wordt verder PAYG-softwaregebruik automatisch betaald. EC2, opslag, netwerk en andere infrastructuur kunnen al tijdens de trial kosten met zich meebrengen. Leg de einddatum, kosteneigenaar, budgetalarm en een besluit over voortzetting of tijdige ontmanteling vast. Gebruik bij BYOL een aangeboden trialactivering tijdens de eerste configuratie of een vooraf goedgekeurde triallicentie; registratie alleen is geen licentietoezegging.

Een productie-UTM-licentie kan alleen via het daarvoor bestemde, van de licentierechten afhankelijke conversieproces worden omgezet naar Sophos Firewall. Ook de overdracht van een bestaande firewalllicentie is alleen mogelijk in toegestane scenario’s, niet door willekeurig dezelfde key opnieuw te gebruiken. Bevestig beide zaken vóór de BYOL-start met de licentiepartner. Licentie-key activeren beschrijft vervolgens de activering.

Binnen het Shared Responsibility-model blijven toepassingen, gegevens, configuratie en onderhoud de eigen verantwoordelijkheid. IPS, webfilter en WAF vullen SG/NACL alleen aan op het verkeerspad dat daadwerkelijk wordt gecontroleerd. Synchronized Security vereist passende endpointlicenties, registratie en een Heartbeat-/firewallpolicy; het isoleert niet automatisch elk onderling EC2-verkeerspad dat de controles omzeilt. Central-koppeling legt de verbinding met centraal beheer uit.

Standalone deployment voorbereiden

Leg vóór de start vast:

• AWS-account, regio, Availability Zone en BYOL- of PAYG-aanbod;
• nieuwe of bestaande VPC en niet-overlappende publieke en private CIDR’s;
• vaste beheerbron, bijvoorbeeld 198.51.100.27/32, in plaats van wereldwijde toegang;
• Elastic IP, DNS-namen en vereiste inbounddiensten;
• private doelnetwerken, default route en verwacht retourpad per testflow;
• ondersteund EC2-type, licentielimiet, kosteneigenaar en tags;
• procedures voor back-up, firmware en rebuild.

198.51.100.27/32 is een documentatieadres en moet worden vervangen door het werkelijke publieke admin-IP. Wisselt dat vaak, dan is beheer via VPN of een gecontroleerde jump host veiliger dan TCP 4444 breed openstellen.

Kies subnetten in een bestaande VPC niet alleen op naam: hun Route Tables moeten bij de bedoelde richting passen. AWS beschrijft appliance-invoeging in de middlebox-routingvoorbeelden. Source/Destination Check moet op doorsturende firewall-ENI’s uitstaan. Laat CloudFormation deze platformdetails instellen en verifieer ze daarna, zonder ze blind te wijzigen.

Standalone met CloudFormation implementeren

1. Open het Sophos Firewall BYOL- of PAYG-aanbod in AWS Marketplace, kies View purchase options en accepteer de voorwaarden.
2. Kies onder Continue to Configuration fulfillment, huidige SFOS-softwareversie en regio.
3. Kies onder Continue to Launch de actie Launch CloudFormation en open de template in AWS CloudFormation.
4. Geef een unieke Stack name op. Controleer bij een nieuwe VPC op overlap met bestaande VPC’s, VPN’s en lokale netwerken.
5. Koppel bij een bestaande VPC VPC-ID, één publiek subnet, één privaat subnet en een nieuwe of vrije Elastic IP. Laat Network Address Prefix for new VPC ongewijzigd.
6. Gebruik alleen een EC2-formaat dat de geopende template voor regio en AMI aanbiedt en controleer dit bij BYOL opnieuw tegen de vastgelegde licentielimiet. Bewaar geheimen niet in tickets, screenshots of publiek leesbare parameterbestanden.
7. Controleer de gevraagde IAM-resources. Bevestig pas dan I acknowledge that AWS CloudFormation might create IAM resources en kies Submit.
8. Wacht op CREATE_COMPLETE. Lees Elastic IP onder Outputs en controleer beide statuschecks en de verwachte ENI’s in EC2.
9. Open WebAdmin vanaf de toegestane bron op https://<EIP>:4444. Negeer de waarschuwing voor het aanvankelijk lokaal ondertekende certificaat alleen na controle van het doel-IP, accepteer de gebruiksvoorwaarden en voltooi de registratie en basisconfiguratie. Open daarna Administration > Licensing en bevestig dat de verwachte licentie actief is; corrigeer bij een afwijking het instanceformaat of de licentietoewijzing voordat productieverkeer wordt toegestaan.

Marketplace-parameters kunnen veranderen; vergelijk daarom vóór elke productie-uitrol de zichtbare veldnamen met de template die daadwerkelijk is geopend.

AWS- en SFOS-regels samen openen

De standalone Sophos-template activeert standaard alleen beheertoegang voor WebAdmin en SSH. Deze uitspraak geldt niet zonder meer voor Auto Scaling: daar bepaalt Public Network CIDR het niet-beheerverkeer. IPsec, SSL VPN, RED, WAF, User Portal of gepubliceerde toepassingen vereisen daarnaast passende AWS Security Group-regels. Houd voor SD-RED 20/60 rekening met TCP 3400 naar de firewall voor het controlekanaal en UDP 3410 voor de datatunnel. Controleer de overige vereisten voor provisioning, DNS en NTP, evenals de vereisten voor andere RED-varianten, afzonderlijk.

Documenteer voor elke opening protocol, doelpoort en bron één keer, maar implementeer elke laag apart:

1. De Security Group staat alleen de vereiste bron toe naar de poort van de juiste ENI.
2. Een aangepaste NACL staat aanvraag en retour toe. AWS legt het verschil uit bij Security Groups en Network ACLs.
3. De Route Table stuurt het datapad door de firewall en biedt een geldig retourpad.
4. SFOS-firewall- en zo nodig NAT-regels gebruiken specifieke zones, hosts en services, loggen verkeer en passen geschikte Security Profiles toe.

Stel SSH of WebAdmin nooit vooraf open voor 0.0.0.0/0. Beperkte AWS-toegang vervangt geen precieze SFOS-regel.

Auto Scaling voor inboundverkeer bouwen

Voor Auto Scaling zijn een AWS-account, het Marketplace-aanbod Sophos Cloud Firewall (PAYG) en een Sophos Fusion-account met de vereiste firewallbeheerrechten nodig. Controleer in Sophos Fusion (voorheen Sophos Central) onder My products > General settings > API credentials management de voorwaarden en maak een credential met naam, beschrijving en de rol Service principal firewall. Bewaar Client ID en Client secret in een secret store met beperkte toegang, niet in een onbeveiligd tekstbestand. Het accountwachtwoord van de Sophos ID is een ander geheim dan het API-clientsecret.

1. Maak in de gewenste AWS-regio onder EC2 > Network & security > Key pairs een geschikt key pair of hergebruik een bestaand key pair. Bewaar de privésleutel veilig en noteer de naam voor SSH KeyPair Name.
2. Open in Marketplace View purchase options en Continue to configuration. Kies Sophos Auto Scaling Firewall for AWS als Fulfillment option, de goedgekeurde Software version en Region. Kies onder Continue to launch de actie Launch CloudFormation, klik op Launch en in CloudFormation op Next.
3. Geef een unieke Stack name op. Controleer of AMI ID overeenkomt met het gekozen aanbod en de versie en kies onder Instance size een aangeboden formaat met voldoende prestaties. Selecteer onder AvailabilityZone 1 for deployment en AvailabilityZone 2 for deployment twee verschillende AZ’s.
4. Nieuwe VPC: voer onder Network Address Prefix for new VPC de eerste twee octetten van een gepland, niet-conflicterend adresbereik in; laat de velden voor een bestaande VPC leeg. Bestaande VPC: laat de prefixparameter ongewijzigd en vul Deploy to an existing VPC, Existing public subnet ID 1, Existing public subnet ID 2 en Existing private subnet ID in vanuit het bouwplan. De publieke subnetten moeten bij de gekozen AZ’s horen en Auto-assign public IPv4 address moet zijn ingeschakeld. Controleer ook routes en NACLs.
5. Stel de firewallnaam, Admin Password voor WebAdmin/CLI, Secure Storage Master Key Password en SSH KeyPair Name in. Bescherm de twee firewallwachtwoorden afzonderlijk van het API-secret.
6. Voer de Sophos ID email address en het Sophos ID password van het bedoelde account, Sophos Central client ID, Sophos Central client secret en Sophos Central AS Group name in. De Central-veldnamen kunnen ondanks de Fusion-branding in de template staan; de groep wordt automatisch in het bijbehorende account aangemaakt. Neem geen secrets op in tickets, screenshots of openbare parameterbestanden.
7. Stel de onderstaande netwerk-, capaciteits- en logparameters in. Voer onder I accept the Sophos End User License Agreement and acknowledge the Sophos Privacy Policy na controle exact yes in; let op hoofdletters en kleine letters. Kies bewust een optie voor Opt in to the customer experience improvement program.
8. Open met Next de stackopties, stel owner- en kostentags in en controleer de gevraagde IAM-rechten. Bevestig pas daarna I acknowledge that AWS CloudFormation might create IAM resources, controleer het totaaloverzicht en start met Submit.

Controleer na CREATE_COMPLETE de EC2-instances en onder My products > Firewall management > Firewalls de automatisch aangemaakte groep met alle verwachte goedgekeurde PAYG-workers. Bevestig de policysynchronisatie voordat een dienst wordt opengesteld. Ontbreekt een worker of mislukt de registratie, open dan geen extra poorten; controleer Stack Events, netwerktoegang en de account-/API-koppeling zonder secrets te loggen. Wijzig de capaciteit later onder EC2 > Auto scaling > Auto scaling groups > Capacity overview > Edit en bevestig met Update. Documenteer instance-ID, AZ en firewallnaam eenduidig; controleer elke capaciteitswijziging opnieuw op groepslidmaatschap en Target Health.

DNAT achter de Network Load Balancer

Een werkende, gecontroleerde Auto Scaling-deployment is een voorwaarde. Voor een goedgekeurde TCP-dienst leidt de NLB-listener naar een Target Group met firewallworkers, niet rechtstreeks naar de backend. Het volgende oorspronkelijke schema toont een HTTPS-voorbeeldpad, geen gemeten verbinding:

Toegestane client : tijdelijke bronpoort
                 | TCP doelpoort 443
          NLB TCP-listener :443
                 |
       Firewallworker-Target-Group
         /                       \
 AZ 1: Worker PortB       AZ 2: Worker PortB
         \                       /
          DNAT naar backend :443
          SNAT = MASQ van de worker
                 |
          Interne appserver :443
                 | Antwoord
          Dezelfde worker -> NLB -> Client

Schema: twee AZ’s, één actieve PortB per worker en een MASQ-retourpad. De pijlen beschrijven het logische datapad; load balancing garandeert geen gelijkmatig gebruik. Pas alle voorbeeldwaarden aan de goedgekeurde dienst aan.

1. Open in Fusion onder My products > Firewall management > Firewalls bij de juiste Auto Scaling-firewallgroep Manage policy. Maak onder Hosts and services > IP host twee IPv4-IP-ranges voor de werkelijke WAN-subnetten van beide AZ’s en één IPv4-host voor de interne server. Neem het eerste adres van elk subnet niet op; neem alleen daadwerkelijk bruikbare workeradressen op, geen door AWS gereserveerde adressen.
2. Maak onder Hosts and services > Services een TCP/UDP-service met Protocol TCP. Bij deze inkomende verbindingsopbouw is de tijdelijke clientpoort de bron en de gepubliceerde dienstpoort het doel. De onderstaande richting geldt voor de aanvraag, niet voor het antwoord; 3389 of 8080 worden niet daarnaast geopend.

3. Sla de firewallregel onder Rules and policies > Firewall rules en de NAT-regel onder Rules and policies > NAT rules op in de groepspolicy. Controleer de synchronisatie op elke actieve worker.
4. Kies onder EC2 > Load balancing > Target groups > Create target group Instances, een unieke naam, Protocol TCP, Port 443 en de deployment-VPC. Pas het healthcheckprotocol, de poort en zo nodig het pad bewust aan de gecontroleerde dienst aan. Selecteer bij het aanmaken onder Available instances geen instance handmatig, met name niet de backendserver.
5. Selecteer onder EC2 > Auto scaling > Auto scaling groups de firewall-ASG en koppel onder Integrations > Load balancing > Edit de Target Group; bevestig met Update. De ASG registreert daarmee automatisch zijn workers, ook workers die later nieuw worden gestart.
6. Controleer vóór het starten van de listener onder Load balancers bij de daadwerkelijke template-NLB de Security Group-toewijzing. Als de NLB zonder Security Group is aangemaakt, kan er later geen worden toegevoegd. Stel dan geen openbare listener open totdat een ondersteund pad met bronbeperking is goedgekeurd; gebruik als alternatief VPN/ZTNA. Bouw de beheerde template niet blind om en beloof niet dat later een SG kan worden gekoppeld.
7. Als het strikt beperkte pad beschikbaar is, configureer dan in de NLB onder Listeners > Add listener TCP en poort 443 met de worker-Target-Group als Default action. Beperk de NLB-SG tot de toegestane client-CIDR’s en de listenerpoort; sta op de worker de door de NLB benodigde doel- en healthcheckpoorten afzonderlijk toe. NLB-egress moet de healthchecks kunnen bereiken. Healthchecktoegang is geen openbare openstelling van een toepassing. Beperk ook rechtstreekse toegang tot workers en backend.
8. Controleer vóór productiegebruik of de verwachte workers van beide AZ’s en een worker die nieuw is gestart in het goedgekeurde wijzigingsvenster automatisch in de Target Group verschijnen en de bedoelde healthchecks doorstaan. Controleer via de NLB-DNS-naam de positieve applicatieflow en een negatieve poging vanaf een niet-toegestane bron; Log Viewer moet de verwachte regel en DNAT/MASQ tonen. Vertrouw niet alleen op healthy.

Rechtstreeks openbaar RDP blijft geen aanbeveling; geef de voorkeur aan VPN of ZTNA. Blijft een target unhealthy, controleer dan eerst de ASG-toewijzing, gesynchroniseerde policy, healthcheckpoort/-pad, NLB-egress, worker-SG en NACL. Laat bij een verkeerde backend of een verkeerd retourpad de listener gesloten en corrigeer NAT/service/route.

Eén flow laag voor laag accepteren

Noteer één beginflow, bijvoorbeeld 198.51.100.27:55000 -> NLB-DNS:443 -> App-Server:443. De bronpoort is slechts een voorbeeld van een tijdelijke clientpoort. Controleer op volgorde:

1. DNS en NLB-listener wijzen naar het verwachte doel en Target Group toont de workers healthy.
2. Security Groups en NACL staan precies aanvraag en retour toe.
3. Route Tables en ENI’s sturen verkeer door de appliance; Source/Destination Check staat uit op transitinterfaces.
4. SFOS Log Viewer toont de verwachte Rule ID. Bij DNAT kloppen origineel en vertaald doel en retourpad.
5. De toegestane test bereikt de toepassing en een test vanaf een niet-toegestane bron blijft geblokkeerd.

Zonder SFOS-log controleert u DNS, listener, Target Health, Security Group, NACL en route. Corrigeer bij een drop met onverwachte Rule ID eerst zones, netwerkobjecten, service en volgorde. Komt de aanvraag wel maar het antwoord niet, controleer Route Table, NACL, server-default-gateway en bij Auto Scaling MASQ.

Beheren en herstellen

Standalone en Auto Scaling vragen verschillende runbooks. Documenteer voor standalone een SFOS-back-up en geteste restore, het firmwareproces, CloudFormation-parameters en een rebuildoefening. Een EC2-snapshot vervangt geen geëxporteerde SFOS-back-up.

Auto Scaling-workers zijn tijdelijk. Met CloudWatch verschijnen logs onder /sophos/xg/; configureer retentie, encryptie, toegang en kosten expliciet. Beëindigde EC2-instances blijven in de Fusion-groep en moeten handmatig worden verwijderd. Warm Pool vervangt niet de controle van de actuele policy op elke worker.

Het beheerdossier omvat owner- en kostentags, budgetalarmen, licentie, secretrotatie, CloudWatch-retentie, Fusion-opruiming, firmwaregoedkeuring, wijzigingstests en recovery. Herhaal de positieve en negatieve flow na elke template-, routing- of policywijziging.

Wijziging stoppen en gericht terugdraaien

Stel vóór de wijziging stackparameters en resource-ID’s, de listener-/Target Group-toewijzing, SG/NACL/Route Tables en de SFOS-groepspolicy en back-up veilig. Sluit bij een verkeerd doel, onverwachte bron, ontbrekende policysynchronisatie of een verstoorde bestaande verbinding eerst de nieuw toegevoegde listener of de nieuwe openstelling; zet daarna alleen de nieuw ingevoerde regels en routes terug naar de gedocumenteerde veilige toestand. Controleer bestaand verkeer en de blokkering van niet-toegestane bronnen opnieuw. Verwijder geen gedeelde VPC, subnetten, gateway of bestaande listeners om problemen op te lossen.

Voor geplande PAYG-ontmanteling is het niet voldoende om afzonderlijke workers te beëindigen: de ASG kan ze opnieuw aanmaken. Verwijder eerst de nieuwe openstelling, voer de goedgekeurde buitengebruikstelling uit via de stack-/ASG-levenscyclus en controleer dat noch scalingacties noch Warm Pool-instances workers opnieuw starten. Verwijder alle bijbehorende PAYG-firewallinstances en controleer de daadwerkelijke resource-inventaris. Beoordeel behouden volumes, EIP’s, NLB, Log Groups en andere betaalde resources afzonderlijk aan de hand van de resourcelijst; verwijder ze niet zonder onderscheid. Verwijder beëindigde workers uit de Fusion-groep. Controleer vervolgens facturatie en kosten.