Distribuera och driva Sophos Firewall på AWS

Sophos Firewall 22 körs i AWS som en virtuell EC2-appliance inline i en VPC. Börja med att definiera vilken trafik som ska inspekteras. En standalone-brandvägg kan kontrollera inkommande och utgående trafik, medan Sophos Auto Scaling-mall är en specialiserad PAYG-design för inkommande DNAT- eller WAF-trafik.

Den säkra snabbvägen är att välja arkitektur och licens, dokumentera IP- och routingplan, starta rätt Marketplace-mall, begränsa administration till ett fast käll-IP, verifiera ett flöde end-to-end och först därefter publicera fler tjänster.

⚠️ AWS Security Groups är fortfarande ett andra brandväggslager. En tillåtande SFOS-regel hjälper inte om en Security Group, NACL eller Route Table blockerar vägen. Kombinera inte heller en öppen AWS-port med en bred Sophos-regel. Security Groups är stateful och Network ACLs stateless, så en anpassad NACL måste tillåta både begäran och retur.

Välj standalone eller Auto Scaling

AWS stöder inte inbyggd Sophos Firewall-HA. Auto Scaling och Network Load Balancing är en annan molndesign, inte SFOS-HA-synkronisering. Standalone kräver därför även en rebuildprocedur och ett godkänt avbrottsfönster.

Tre kontroller gäller vid val av instans: EC2-typen måste erbjudas i den öppnade Marketplace-CloudFormation-mallen för vald region och AMI; CPU, RAM och nätverksprestanda måste passa genomströmningen och anslutningsprofilen; vid BYOL måste CPU-rättigheterna och de villkor som gäller för just den licensen bekräftas.

SFOS-22/23-mappningen anger exempelvis m5.large med 2 vCPU och 8 GB RAM för SFv2C4 samt m5.xlarge med 4 vCPU och 16 GB RAM för SFv4C6. Detta är versions- och erbjudandespecifika exempel på mappningar, inte ett löfte för varje aktuell mall. Licensens historiska RAM-suffix är därför ingen tillförlitlig övre gräns för fysiskt EC2-RAM; det innebär dock inte heller något generellt löfte om obegränsad RAM-rättighet. Klargör och dokumentera de konkreta licens-/erbjudanderättigheterna med Sophos eller licenspartnern före köp; driftsätt inte i produktion om något är oklart.

Välj en erbjuden storlek med belastningsmarginal och dokumentera EC2-typ, AMI/SFOS-version samt bekräftade licensvillkor i byggplanen.

Vid PAYG upphör programvarudebiteringen först när alla berörda brandväggsinstanser har tagits bort; separata AWS-resurser som finns kvar kan fortsätta att medföra kostnader.

Om den planerade typen saknas i mallen eller om CloudFormation avvisar kombinationen av region, AMI och storlek ska den inte tvingas fram genom en manuell malländring. Välj en erbjuden typ som uppfyller belastnings- och licenskraven eller stoppa distributionen tills region, erbjudande eller licens har klarlagts.

Klargör licens och pilot före köp

Om PAYG inte är tillgängligt i det egna landet eller erbjudandet kan Standalone-BYOL med bekräftad licens vara ett alternativ; detta gör inte Auto Scaling-mallen, som endast stöder PAYG, användbar med BYOL. Via Sophos eller en partner kan även ett Private Offer med individuellt avtalade priser och villkor undersökas. BYOL undviker Marketplace-programvaruavgiften, inte EC2- och infrastrukturkostnaderna.

För en pilot ska den faktiska rätten till en provperiod, dess längd och villkoren för det valda erbjudandet kontrolleras. Den historiska AWS-FAQ:n beskriver en 30-dagars provperiod för PAYG-programvaran; detta är ingen garanti för det erbjudande som väljs i dag. Efter erbjudandets provperiod blir fortsatt användning av PAYG-programvaran automatiskt avgiftsbelagd. EC2, lagring, nätverk och annan infrastruktur kan vara avgiftsbelagda redan under provperioden. Dokumentera slutdatum, kostnadsansvarig, budgetlarm och ett beslut om fortsatt drift eller avveckling i tid. Vid BYOL ska en erbjuden provaktivering vid den första installationen eller en i förväg godkänd provlicens användas; enbart registrering är inget löfte om licens.

En UTM-licens i produktion kan endast konverteras till Sophos Firewall genom den avsedda, rättighetsberoende konverteringsprocessen. Överföring av en befintlig Firewall-licens är också endast möjlig i tillåtna scenarier, inte genom godtycklig återanvändning av samma nyckel. Bekräfta båda med licenspartnern innan BYOL startas. Aktivera licensnyckel beskriver den efterföljande aktiveringen.

I modellen för delat ansvar ligger ansvaret för applikationer, data, konfiguration och underhåll kvar hos den egna organisationen. IPS, webbfilter och WAF kompletterar SG/NACL endast på den trafikväg som faktiskt kontrolleras. Synchronized Security kräver lämpliga Endpoint-licenser, registrering och Heartbeat-/brandväggspolicy; det isolerar inte automatiskt varje trafikväg mellan EC2-instanser som kringgår kontrollerna. Central-anslutning förklarar anslutningen till central administration.

Förbered standalone-distributionen

Dokumentera före start:

• AWS-konto, region, Availability Zone och BYOL- eller PAYG-erbjudande;
• ny eller befintlig VPC och icke överlappande publika och privata CIDR;
• fast administrationskälla, exempelvis 198.51.100.27/32, i stället för global åtkomst;
• Elastic IP, DNS-namn och nödvändiga inboundtjänster;
• privata målnät, default route och förväntad returväg per testflöde;
• stödd EC2-typ, licensgräns, kostnadsägare och taggar;
• rutiner för backup, firmware och rebuild.

198.51.100.27/32 är en dokumentationsadress som ska ersättas med administratörens verkliga publika IP. Om det ändras ofta är VPN eller en kontrollerad jump host säkrare än att exponera TCP 4444 brett.

Välj inte subnet i en befintlig VPC enbart efter namn: Route Tables måste stämma med avsedd riktning. AWS förklarar appliance-infogning i sina middlebox-routingexempel. Source/Destination Check måste vara avstängd på vidarebefordrande firewall-ENI:er. Låt CloudFormation ställa in dessa detaljer och verifiera dem efteråt utan blinda ändringar.

Distribuera standalone med CloudFormation

1. Öppna Sophos Firewall BYOL- eller PAYG-erbjudandet i AWS Marketplace, välj View purchase options och acceptera villkoren.
2. Välj fulfillment, aktuell SFOS-version och region under Continue to Configuration.
3. Välj Launch CloudFormation under Continue to Launch och öppna mallen i AWS CloudFormation.
4. Ange ett unikt Stack name. Kontrollera för en ny VPC att intervallen inte överlappar befintliga VPC:er, VPN eller lokala nät.
5. För en befintlig VPC kopplar du VPC-ID, ett publikt subnet, ett privat subnet och en ny eller ledig Elastic IP. Lämna Network Address Prefix for new VPC oförändrad.
6. Använd endast en EC2-storlek som den öppna mallen erbjuder för regionen och AMI:n och kontrollera den för BYOL återigen mot licensgränsen i byggplanen. Lagra inte hemligheter i ärenden, skärmbilder eller publikt läsbara parameterfiler.
7. Granska begärda IAM-resurser. Bekräfta först därefter I acknowledge that AWS CloudFormation might create IAM resources och välj Submit.
8. Vänta på CREATE_COMPLETE. Läs Elastic IP under Outputs och kontrollera båda statuskontrollerna samt förväntade ENI:er i EC2.
9. Öppna WebAdmin från tillåten källa på https://<EIP>:4444. Gå förbi varningen för det initialt lokalt signerade certifikatet endast efter kontroll av mål-IP och slutför registrering och basic setup. Öppna därefter Administration > Licensing och bekräfta att förväntad licens är aktiv; korrigera instansstorleken eller licenstilldelningen vid en avvikelse innan produktionstrafik tillåts.

Marketplace-parametrar kan ändras; jämför därför de synliga fältnamnen med den template som faktiskt öppnats före varje produktionsutrullning.

Öppna AWS- och SFOS-regler tillsammans

Sophos standalone-mall aktiverar som standard endast administrationsåtkomst för WebAdmin och SSH. Detta gäller inte generellt för Auto Scaling: där styr Public Network CIDR trafik som inte är administrationstrafik. IPsec, SSL VPN, RED, WAF, User Portal eller publicerade applikationer kräver dessutom lämpliga AWS-Security-Group-regler. För SD-RED 20/60 ska TCP 3400 till brandväggen för kontrollkanalen och UDP 3410 för datatunneln beaktas; kontrollera ytterligare krav för provisioning, DNS och NTP samt andra RED-varianter separat.

Dokumentera protokoll, målport och källa en gång per öppning, men implementera lagren separat:

1. Security Group tillåter endast den nödvändiga källan till porten på rätt ENI.
2. En anpassad NACL tillåter begäran och retur. AWS förklarar skillnaden under Security Groups och Network ACLs.
3. Route Table leder datavägen genom brandväggen och ger en giltig returväg.
4. SFOS-firewall- och vid behov NAT-regler använder specifika zoner, hosts och tjänster, loggar trafik och tillämpar lämpliga Security Profiles.

Exponera aldrig SSH eller WebAdmin till 0.0.0.0/0 i förebyggande syfte. Begränsad AWS-åtkomst ersätter inte en exakt SFOS-regel.

Bygg Auto Scaling för inboundtrafik

Auto Scaling kräver ett AWS-konto, Marketplace-erbjudandet Sophos Cloud Firewall (PAYG) och ett Sophos Fusion-konto med nödvändiga behörigheter för brandväggsadministration. Granska villkoren i Sophos Fusion (tidigare Sophos Central) under My products > General settings > API credentials management och skapa en credential med namn, beskrivning och rollen Service principal firewall. Förvara Client ID och Client secret i ett åtkomstbegränsat hemlighetsvalv, inte i en oskyddad textfil. Kontolösenordet för Sophos ID är en annan hemlighet än API-klienthemligheten.

1. Skapa ett lämpligt nyckelpar eller återanvänd ett befintligt i önskad AWS-region under EC2 > Network & security > Key pairs. Förvara den privata nyckeln säkert och notera namnet för SSH KeyPair Name.
2. Öppna View purchase options och Continue to configuration i Marketplace. Välj Sophos Auto Scaling Firewall for AWS som Fulfillment option, den godkända Software version och Region. Välj åtgärden Launch CloudFormation under Continue to launch, klicka på Launch och sedan på Next i CloudFormation.
3. Ange ett unikt Stack name. Stäm av AMI ID mot det valda erbjudandet och versionen och välj en erbjuden storlek med tillräcklig prestanda under Instance size. Välj två olika AZ:er under AvailabilityZone 1 for deployment och AvailabilityZone 2 for deployment.
4. Ny VPC: ange de första två oktetterna i ett planerat, konfliktfritt adressområde under Network Address Prefix for new VPC; lämna fälten för en befintlig VPC tomma. Befintlig VPC: lämna prefixparametern oförändrad och fyll i Deploy to an existing VPC, Existing public subnet ID 1, Existing public subnet ID 2 samt Existing private subnet ID enligt byggplanen. De publika subneten måste tillhöra de valda AZ:erna och ha Auto-assign public IPv4 address aktiverat. Kontrollera även routes och NACL:er.
5. Ange brandväggsnamn, Admin Password för WebAdmin/CLI, Secure Storage Master Key Password och SSH KeyPair Name. Skydda de två brandväggslösenorden separat från API-hemligheten.
6. Ange Sophos ID email address och Sophos ID password för det avsedda kontot, Sophos Central client ID, Sophos Central client secret och Sophos Central AS Group name. Central-fältnamnen kan finnas kvar i mallen trots Fusion-varumärket; gruppen skapas automatiskt i det tillhörande kontot. Ta inte med hemligheter i ärenden, skärmbilder eller publika parameterfiler.
7. Ange följande nätverks-, kapacitets- och loggparametrar. Skriv efter granskning exakt yes under I accept the Sophos End User License Agreement and acknowledge the Sophos Privacy Policy; observera att skiftläget är betydelsefullt. Gör ett medvetet val för Opt in to the customer experience improvement program.
8. Öppna stackalternativen med Next, ange ägar-/kostnadstaggar och granska de begärda IAM-behörigheterna. Bekräfta först därefter I acknowledge that AWS CloudFormation might create IAM resources, granska hela sammanställningen och starta med Submit.

Efter CREATE_COMPLETE ska EC2-instanserna och den automatiskt skapade gruppen med alla förväntade godkända PAYG-workers kontrolleras under My products > Firewall management > Firewalls. Bekräfta policysynkroniseringen innan en tjänst exponeras. Om en worker saknas eller registreringen misslyckas ska inga fler portar öppnas; kontrollera Stack Events, nätverksåtkomst och konto/API-koppling utan att logga hemligheter. Ändra senare kapaciteten under EC2 > Auto scaling > Auto scaling groups > Capacity overview > Edit och bekräfta med Update. Dokumentera instans-ID, AZ och brandväggsnamn entydigt; kontrollera varje kapacitetsändring på nytt mot gruppmedlemskap och Target Health.

DNAT bakom Network Load Balancer

En fungerande, verifierad Auto Scaling-distribution är en förutsättning. För en godkänd TCP-tjänst leder NLB-listenern till en Target Group med brandväggens workers, inte direkt till backend. Följande ursprungliga schema visar en exempelväg för HTTPS, inte en uppmätt anslutning:

Tillåten klient : tillfällig källport
                 | TCP målport 443
          NLB TCP-listener :443
                 |
       Target Group för brandväggsworkers
         /                       \
 AZ 1: Worker PortB       AZ 2: Worker PortB
         \                       /
          DNAT till backend :443
          SNAT = workerns MASQ
                 |
          Intern appserver :443
                 | Svar
          Samma worker -> NLB -> Klient

Schema: två AZ:er, en aktiv PortB per worker och en MASQ-returväg. Pilarna beskriver den logiska datavägen; lastfördelning är ingen garanti för jämn användning. Anpassa samtliga exempelvärden till den godkända tjänsten.

1. Öppna Manage policy i Fusion under My products > Firewall management > Firewalls för rätt Auto Scaling-brandväggsgrupp. Skapa två IPv4-IP-intervall för de faktiska WAN-subneten i båda AZ:erna och en IPv4-host för den interna servern under Hosts and services > IP host. Ta inte med den första adressen i varje subnet; inkludera endast faktiskt användbara worker-adresser, inga AWS-reserverade adresser.
2. Skapa en TCP/UDP-tjänst med Protocol TCP under Hosts and services > Services. För denna inkommande anslutningsetablering är den tillfälliga klientporten källan och den publicerade tjänsteporten målet. Följande riktning gäller för begäran, inte för svaret; 3389 eller 8080 öppnas inte därutöver.

3. Spara brandväggsregeln under Rules and policies > Firewall rules och NAT-regeln under Rules and policies > NAT rules i gruppolicyn. Kontrollera synkroniseringen på varje worker som körs.
4. Välj Instances, ett unikt namn, Protocol TCP, Port 443 och distributionens VPC under EC2 > Load balancing > Target groups > Create target group. Anpassa medvetet Health Check-protokoll, port och vid behov sökväg till den verifierade tjänsten. Välj inte någon instans manuellt under Available instances när gruppen skapas, särskilt inte backend-servern.
5. Välj brandväggens ASG under EC2 > Auto scaling > Auto scaling groups och anslut Target Group under Integrations > Load balancing > Edit; bekräfta med Update. ASG registrerar därmed sina workers automatiskt, även sådana som startas senare.
6. Kontrollera Security Group-kopplingen för den faktiska NLB som mallen skapade under Load balancers innan listenern startas. Om NLB skapades utan en Security Group går det inte att lägga till en senare. Öppna då ingen publik listener förrän en stödd, källbegränsad väg har godkänts; använd alternativt VPN/ZTNA. Bygg inte om den hanterade mallen blint och utlova inte att en SG kan anslutas senare.
7. Om den restriktiva vägen finns ska TCP och port 443 konfigureras i NLB under Listeners > Add listener, med workers Target Group som Default action. Begränsa NLB-SG till tillåtna klient-CIDR och listener-porten; tillåt separat de mål- och Health Check-portar som NLB behöver på workern. NLB-egress måste kunna nå Health Checks. Åtkomst för Health Checks är ingen publik applikationsöppning. Begränsa även direkt åtkomst till workers och backend.
8. Kontrollera före produktionsanvändning att de förväntade workers i båda AZ:erna och en worker som startas på nytt inom det godkända ändringsfönstret automatiskt visas i Target Group och klarar avsedda Health Checks. Kontrollera det positiva applikationsflödet och ett negativt försök från en otillåten källa via NLB-DNS-namnet; Log Viewer måste visa förväntad regel och DNAT/MASQ. Lita inte enbart på healthy.

Direkt publik RDP är fortfarande ingen rekommendation; föredra VPN eller ZTNA. Om ett target förblir unhealthy ska ASG-koppling, synkroniserad policy, Health Check-port/-sökväg, NLB-egress, worker-SG och NACL kontrolleras först. Vid fel backend eller returväg ska listenern hållas stängd och NAT/tjänst/route korrigeras. Portarna måste bedömas utifrån begärans riktning längs vägen klient–listener–backend.

Godkänn ett flöde lager för lager

Skriv ned ett startflöde, exempelvis 198.51.100.27:55000 -> NLB-DNS:443 -> App-Server:443. Källporten är bara ett exempel på en tillfällig klientport. Kontrollera i ordning:

1. DNS och NLB-listener pekar mot förväntat mål och Target Group visar workers som healthy.
2. Security Groups och NACL tillåter exakt begäran och retur.
3. Route Tables och ENI:er leder trafik genom appliance; Source/Destination Check är avstängd på transitgränssnitten.
4. SFOS Log Viewer visar förväntad Rule ID. För DNAT stämmer ursprungligt och översatt mål samt returväg.
5. Det tillåtna testet når applikationen, medan ett test från otillåten källa blockeras.

Saknas SFOS-logg kontrolleras DNS, listener, Target Health, Security Group, NACL och route. Vid drop med oväntad Rule ID korrigeras zoner, nätobjekt, tjänst och ordning. Om begäran kommer fram utan svar kontrolleras Route Table, NACL, serverns default gateway och för Auto Scaling MASQ.

Driv och återställ

Standalone och Auto Scaling kräver olika runbooks. Dokumentera för standalone en SFOS-backup och testad återställning, firmwareprocessen, CloudFormation-parametrar och ett rebuildtest. En EC2-snapshot ersätter inte en exporterad SFOS-backup.

Auto Scaling-workers är kortlivade. Med CloudWatch visas loggar under /sophos/xg/; konfigurera retention, kryptering, åtkomst och kostnader uttryckligen. Avslutade EC2-instanser ligger kvar i Fusion-gruppen och måste tas bort manuellt. En Warm Pool synkroniserar stoppade instanser enligt sitt intervall, men ersätter inte kontrollen av att en ny gruppolicy har nått alla workers som körs.

Driftdokumentationen omfattar ägar- och kostnadstaggar, budgetlarm, licens, secret-rotation, CloudWatch-retention, Fusion-rensning, firmwaregodkännande, ändringstester och recovery. Upprepa positivt och negativt flödestest efter varje ändring av template, routing eller policy.

Stoppa ändringen och återställ riktat

Säkra stackparametrar och resurs-ID:n, listener/Target Group-koppling, SG/NACL/Route Tables samt SFOS-gruppolicy och backup före ändringen. Vid fel mål, oväntad källa, utebliven policysynkronisering eller störd befintlig anslutning ska den nytillagda listenern respektive den nya exponeringen stängas först; återställ därefter endast de nyinförda reglerna och routes till det dokumenterade säkra läget. Kontrollera befintlig trafik och blockeringen av otillåtna källor på nytt. Radera inte en delad VPC, subnet, gateway eller befintliga listeners för att avhjälpa felet.

Vid planerad PAYG-avveckling räcker det inte att avsluta enskilda workers: ASG kan skapa dem på nytt. Ta först bort den nya exponeringen, genomför den godkända avvecklingen via stackens/ASG:s livscykel och kontrollera att varken scaling-åtgärder eller Warm Pool-instanser startar workers igen. Ta bort alla tillhörande PAYG-brandväggsinstanser och kontrollera det faktiska resursbeståndet. Bedöm Retained Volumes, EIP:er, NLB, Log Groups och andra avgiftsbelagda resurser individuellt utifrån resurslistan, radera dem inte generellt; ta bort avslutade workers från Fusion-gruppen. Kontrollera därefter fakturering och kostnader. Avveckla resurserna enligt den avgränsade planen nedan.