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

Modell	Användning	Viktig gräns
Standalone BYOL	Permanent appliance med Sophos-licens	EC2 debiteras separat; vCPU och RAM måste passa en stödd instans och licensen.
Standalone PAYG	Pilot, tillfällig miljö eller timdebitering	FullGuard debiteras utöver EC2; PAYG finns inte i alla länder.
Auto Scaling PAYG	Varierande inkommande DNAT- eller WAF-trafik	Endast PAYG, single-arm via PortB och endast inbound; ingen normal LAN-till-WAN-egressväg.

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.

Aktuella stödda EC2-typer finns i Sophos AWS-översikt. Välj inte bara största instansen med BYOL: resurserna måste motsvara den köpta virtuella licensen. Med PAYG upphör enligt Sophos programvarukostnader först när alla berörda brandväggsinstanser har tagits bort från AWS-kontot.

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

Öppna Sophos Firewall BYOL- eller PAYG-erbjudandet i AWS Marketplace, välj View purchase options och acceptera villkoren.
Välj fulfillment, aktuell SFOS-version och region under Continue to Configuration.
Välj Launch CloudFormation under Continue to Launch och öppna mallen i AWS CloudFormation.
Ange ett unikt Stack name. Kontrollera för en ny VPC att intervallen inte överlappar befintliga VPC:er, VPN eller lokala nät.
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 enligt Sophos.
Jämför AMI och EC2-storlek med Sophos lista och för BYOL med licensen. Lagra inte hemligheter i ärenden, skärmbilder eller publikt läsbara parameterfiler.
Granska begärda IAM-resurser. Bekräfta först därefter I acknowledge that AWS CloudFormation might create IAM resources och välj Submit.
Vänta på CREATE_COMPLETE. Läs Elastic IP under Outputs och kontrollera båda statuskontrollerna samt förväntade ENI:er i EC2.
Ö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.

Sophos underhåller hela sekvensen i Deploy Sophos Firewall on AWS. Marketplace-parametrar kan ändras; jämför alltid fälten med sidan och den öppnade mallen.

Öppna AWS- och SFOS-regler tillsammans

Mallen aktiverar initialt endast WebAdmin och SSH. IPsec, SSL VPN, RED, WAF, User Portal och publicerade applikationer kräver motsvarande AWS-regler. RED använder exempelvis TCP 3410.

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

Security Group tillåter endast den nödvändiga källan till porten på rätt ENI.
En anpassad NACL tillåter begäran och retur. AWS förklarar skillnaden under Security Groups och Network ACLs.
Route Table leder datavägen genom brandväggen och ger en giltig returväg.
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 AWS-konto, erbjudandet Sophos Cloud Firewall (PAYG) och Sophos Central API-uppgifter. Skapa i My products > General settings > API credentials management en credential med rollen Service principal firewall. Behandla Client ID och Client secret som lösenord.

Välj Sophos Auto Scaling Firewall for AWS som fulfillment. Mallen kräver två olika Availability Zones. För en befintlig VPC anges två publika och ett privat subnet; Sophos kräver Auto-assign public IPv4 address på båda publika subneten.

Granska särskilt:

Trusted Network CIDR: publikt admin-IP som /32, aldrig 0.0.0.0/0;
Public Network CIDR: Sophos exempel börjar med 0.0.0.0/0 och öppnar icke-managementportar mot internet. Avanet rekommenderar kända källnät eller omedelbar begränsning efter distribution;
Minimum capacity: minsta antal tillgängliga workers;
Starting capacity: initiala workers. I exemplet rekommenderar Sophos Maximum capacity så alla registreras tillsammans i Central;
Maximum capacity: hårt tak för workers och kostnader;
Warm Pool Refresh Period: intervall för att starta stoppade instanser och synkronisera Central-policy; dokumenterad default är fem dagar;
Use CloudWatch: skickar brandväggsloggar till CloudWatch Logs.

Kontrollera efter CREATE_COMPLETE under My products > Firewall management > Firewalls den automatiska gruppen och alla förväntade godkända PAYG-workers. Ändra först därefter capacity eller scaling policy. Aktuella parametrar finns i Sophos Firewall with AWS Auto Scaling.

DNAT bakom Network Load Balancer

För en publicerad tjänst skickar en TCP-listener i NLB till en Target Group med workers. Skapa i Central-gruppolicyn IP-intervall för WAN-subneten i båda zonerna, intern målhost och tjänsten för den publicerade porten. Ta inte med den första IP-adressen i respektive AWS-subnet.

I denna single-arm-design matchar firewallregeln WAN-WAN på intervall och exakt tjänst. DNAT översätter till den interna servern och använder MASQ som translated source så att returen passerar samma worker. Koppla därefter Target Group, Auto Scaling Group och NLB-listener. Sophos visar stegen i DNAT use case.

Det officiella exemplet använder RDP, men direkt publicering rekommenderas inte. Föredra VPN eller ZTNA. Om DNAT krävs, begränsa källor i NLB, AWS och SFOS, aktivera IPS och logging och gör ett negativt test.

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:

DNS och NLB-listener pekar mot förväntat mål och Target Group visar workers som healthy.
Security Groups och NACL tillåter exakt begäran och retur.
Route Tables och ENI:er leder trafik genom appliance; Source/Destination Check är avstängd på transitgränssnitten.
SFOS Log Viewer visar förväntad Rule ID. För DNAT stämmer ursprungligt och översatt mål samt returväg.
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 enligt Sophos kvar i Central-gruppen och måste tas bort manuellt. Warm Pool ersätter inte kontrollen av aktuell policy på varje worker.

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