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.

Hanteer drie voorwaarden bij de instancekeuze: het EC2-type moet selecteerbaar zijn in de geopende Marketplace CloudFormation-template voor de gekozen regio en AMI, de prestaties moeten passen bij de verwachte throughput en het verbindingsprofiel en bij BYOL mogen vCPU en RAM de gekochte virtuele licentie niet overschrijden. Kies het kleinste aangeboden formaat dat met reserve aan deze eisen voldoet en leg EC2-type, AMI of SFOS-versie en licentielimiet vast in het bouwplan. Bij PAYG stoppen softwarekosten pas nadat alle betreffende firewallinstances uit het AWS-account zijn verwijderd.

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.

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 en voltooi registratie en basic setup. 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 template activeert aanvankelijk alleen WebAdmin en SSH. IPsec, SSL VPN, RED, WAF, User Portal en gepubliceerde toepassingen hebben overeenkomstige AWS-regels nodig. RED gebruikt bijvoorbeeld TCP 3410.

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

Auto Scaling vereist een AWS-account, het aanbod Sophos Cloud Firewall (PAYG) en Sophos Fusion (voorheen Sophos Central) API-gegevens. Maak in My products > General settings > API credentials management een credential met rol Service principal firewall. Behandel Client ID en Client secret als wachtwoord.

Kies Sophos Auto Scaling Firewall for AWS als fulfillment. De template vereist twee verschillende Availability Zones. Geef voor een bestaande VPC twee publieke en één privaat subnet op; activeer Auto-assign public IPv4 address op beide publieke subnetten.

Controleer vooral:

• Trusted Network CIDR: publiek admin-IP als /32, nooit 0.0.0.0/0;
• Public Network CIDR: 0.0.0.0/0 opent niet-beheerpoorten voor het volledige internet. Avanet adviseert bekende bronnetwerken of onmiddellijke beperking na deployment;
• Minimum capacity: minimumaantal beschikbare workers;
• Starting capacity: aanvankelijke workers. Stel dit voor de eerste deployment in op Maximum capacity, zodat alle workers samen in Fusion registreren;
• Maximum capacity: harde limiet voor workers en kosten;
• Warm Pool Refresh Period: interval om gestopte instances te starten en Fusion-policy te synchroniseren; de default is vijf dagen;
• Use CloudWatch: stuurt firewalllogs naar CloudWatch Logs.

Controleer na CREATE_COMPLETE onder My products > Firewall management > Firewalls de automatische groep en alle verwachte goedgekeurde PAYG-workers. Wijzig pas daarna capacity of scaling policy.

DNAT achter de Network Load Balancer

Voor een gepubliceerde service stuurt een TCP-listener van de NLB naar een Target Group met workers. Maak in de Fusion-groepspolicy IP-ranges voor de WAN-subnetten van beide zones, de interne host en de service van de gepubliceerde poort. Neem het eerste IP-adres van elk AWS-subnet niet op.

In dit single-arm ontwerp matcht de firewallregel WAN-WAN op ranges en exacte service. DNAT vertaalt naar de interne server en gebruikt MASQ als translated source, zodat retourverkeer dezelfde worker passeert. Koppel daarna Target Group, Auto Scaling Group en NLB-listener.

Directe RDP-publicatie wordt niet aanbevolen. Gebruik liever VPN of ZTNA. Is DNAT onvermijdelijk, beperk bronnen in NLB, AWS en SFOS, activeer IPS en logging en voer een negatieve test uit.

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.