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.

Instansvalet har tre villkor: EC2-typen måste kunna väljas i den öppna Marketplace CloudFormation-mallen för vald region och AMI, prestandan måste motsvara förväntad throughput och anslutningsprofil och med BYOL får vCPU och RAM inte överskrida den köpta virtuella licensen. Välj den minsta erbjudna storleken som uppfyller kraven med marginal och dokumentera EC2-typ, AMI eller SFOS-version samt licensgräns i byggplanen. Med PAYG upphör programvarukostnader först när alla berörda brandväggsinstanser har tagits bort från AWS-kontot.

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.

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

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:

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 AWS-konto, erbjudandet Sophos Cloud Firewall (PAYG) och Sophos Fusion (tidigare 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; aktivera 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: 0.0.0.0/0 öppnar icke-managementportar mot hela 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. Ställ in Maximum capacity för den första distributionen så att alla registreras tillsammans i Fusion;
• Maximum capacity: hårt tak för workers och kostnader;
• Warm Pool Refresh Period: intervall för att starta stoppade instanser och synkronisera Fusion-policy; 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.

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 Fusion-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.

Direkt RDP-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:

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. Warm Pool ersätter inte kontrollen av aktuell policy på varje worker.

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.