Distribuera Sophos NDR på AWS

Sophos NDR körs i AWS som en EC2-baserad integrationsappliance. Den tar emot en kopia av vald VPC-trafik via VPC Traffic Mirroring, analyserar den passivt och överför NDR-data till Sophos Data Lake. Appliance-enheten ligger inte inline och ersätter varken Security Groups eller en brandvägg.

Det tillförlitliga övergripande arbetsflödet är: klargör licens och ansvarsområden, dokumentera AWS-nätverken, skapa appliance-enheten i Sophos Fusion, ladda ned den genererade CloudFormation-mallen, prenumerera på Marketplace-erbjudandet, skapa stacken, lägg till exakt en kontrollerad Mirror Session, begränsa hanteringsåtkomsten och godkänn varje lager separat.

⚠️ Den här runbooken innehåller medvetet ingen fullständig avveckling. Den säkra ordningsföljden och konsekvenserna av att ta bort stack-, appliance-, EC2-, EBS-, ENI-, Security-Group-, Elastic-IP-, Mirror- och Marketplace-resurser är inte fullständigt verifierade. En misslyckad distribution får därför inte ”städas upp” med en improviserad borttagningsordning.

Arkitektur och beslut före start

CloudFormation skapar två logiskt separerade nätverkssökvägar:

Management Interface finns i ett Public Subnet och använder en tilldelad Elastic IP Address. SSH och åtkomsten till Sophos Appliance Manager går via detta gränssnitt.
SPAN interface tar emot speglad trafik. NDR SPAN Target, som skapas av mallen, används som Mirror Target.
En Traffic mirror session ansluter ett valt käll-ENI till detta mål. NDR Traffic Mirror Filter, som också skapas, avgör vilka paket som speglas.
Appliance-enheten bearbetar kopiorna och skickar NDR-data till Sophos. De ursprungliga flödena fortsätter på sin normala AWS-datasökväg.

Det viktigaste designbeslutet är därför inte ”vilken hel VPC ska vi övervaka?” utan vilket ENI är en lämplig Mirror Source. Börja med ett enskilt, dokumenterat ENI för ett testsystem. Det håller datavolymen, kostnaderna och omfattningen av eventuella fel nere. Lägg inte till fler källor förrän den tekniska acceptansen är klar.

Före distributionen ska en byggplan minst innehålla följande:

AWS-konto, Region, VPC, Availability Zone och Owner-taggar;
VPC-ID samt subnet-ID för hantering och SPAN;
minst en Elastic IP som har tilldelats i AWS-kontot för Management Interface; detta är en förutsättning på kontonivå, men i den dokumenterade parameterlistan är det inte ett indatavärde för mallen som kan väljas i förväg;
EC2-typer som för närvarande stöds av Sophos: c5n.2xlarge, c6i.4xlarge eller c7i.16xlarge med Nitro-virtualisering; vilken typ som faktiskt används ska kontrolleras i den aktuella klientorganisationens mall och på instansen efter distributionen;
namnet på befintligt SSH Key Pair och en säker förvaringsplats för Private Key;
Security Group för SSH och fasta administrativa källnät;
det första ENI:t för Mirror Source och det Workload-team som ansvarar för detta ENI;
förväntad normal testtrafik för detta ENI;
kostnadsställe, budgetlarm och godkännande av AWS-infrastrukturkostnader samt Marketplace-villkoren som visas för kontot.

VPC, Subnets och Elastic IP

En befintlig VPC och befintliga Subnets kan användas. Valet får dock inte enbart baseras på namnet:

Management-subnet måste planeras som ett Public Subnet. Kontrollera dess Route Table och den avsedda internetsökvägen innan det väljs.
SPAN-subnet anges för NDR SPAN interface. Dokumentera Subnet och Availability Zone tillsammans med Mirror Source i stället för att senare försöka härleda värdena från resursnamn.
Elastic IP hör till Management Interface, inte till SPAN-sidan. Säkerställ i förväg att minst en Elastic IP har tilldelats i kontot. Påstå inte att stacken använder en viss befintlig adress: fastställ och dokumentera efter CREATE_COMPLETE den adress som faktiskt skapades eller användes samt dess ENI-koppling.
Mallen väljer automatiskt AMI och Region utifrån den AWS-region där mallen laddas upp. Tvinga inte fram en annan AMI genom att ändra mallen manuellt.

Security Groups och SSH Key Pair

Använd ett befintligt AWS Key Pair vars Private Key redan lagras säkert. CloudFormation behöver namnet på Key Pair; Private Key lagras inte i Sophos Fusion eller i mallen. Utan Private Key är den SSH-åtkomst som Sophos dokumenterar för AWS-appliance-enheten inte tillgänglig i ett senare skede.

Förbered en Security Group som bara tillåter SSH från det administrativa åtkomstnätet, exempelvis från en fast utgående företags-IP som /32 eller via en kontrollerad Jump Host. Öppna varken SSH eller TCP 8443 för 0.0.0.0/0.

Mallen skapar dessutom InternalMgmtSG. Efter distributionen tillåts TCP 8443 där endast för de faktiska administrativa källorna. Om samma appliance-enhet även är värd för en Log Collector ska Syslog enbart tillåtas med det protokoll och den port som respektive Connector kräver och från de interna källnäten. VPC Traffic Mirroring kräver i sig ingen generell Syslog-åtkomst från internet.

Kontrollera utgående anslutning i förväg

Ett Public Subnet och en Elastic IP bevisar ännu inte att det finns en fungerande utgående sökväg. Före Submit måste det ansvariga nätverksteamet bekräfta att Management Interface kan kommunicera utgående via den avsedda routen och en Internet Gateway eller den godkända centrala utgående designen. Kontrollera DNS-upplösning, Route Table, Network ACL, Security-Group-Egress samt regler för Proxy och Upstream-Firewall.

De mål och portar som behövs kopieras inte till den här runbooken. Jämför i stället vid tidpunkten för ändringen de aktuella port- och domänundantagen för Sophos-appliance-enheter med reglerna för utgående trafik. Dessa tillåtelser är relevanta för uppstart, uppdateringar, registrering och datauppladdning; bevis på anslutning till ett enskilt mål ersätter inte den fullständiga jämförelsen.

Förutsättningar, roller, licens och kostnader

Följande krävs för konfigurationen:

ett AWS-konto med befintlig VPC, Subnets och Availability Zones;
ett Sophos Fusion-konto;
vanligtvis Sophos Network Detection and Response integration license pack;
minst en lämplig EC2-källinstans eller dess ENI;
minst en Elastic IP Address som tilldelats i AWS-kontot;
ett sparat AWS SSH Key Pair;
ett aktuellt ändringsgodkännande för nätverksspeglingen och de data som behandlas i samband med den.

Fördela om möjligt arbetet utan att hitta på obekräftade IAM-policynamn:

En Sophos Fusion-administratör skapar NDR-konfigurationen och laddar ned mallen.
En person som är behörig att göra inköp accepterar villkoren för Sophos Integration Appliance i AWS Marketplace.
En AWS-administratör med de rättigheter som krävs för stacken och de refererade nätverksresurserna skapar CloudFormation-, EC2-, VPC-Traffic-Mirroring-, Security-Group- och Elastic-IP-resurser.
Ansvarigt nätverks- eller Workload-team bekräftar Mirror Source, filtrets effekt, testfönstret och den förväntade trafiken.

Sophos anger ingen separat minimal NDR-specifik Fusion-roll för detta arbetsflöde. Om Add Configuration, Download image eller Open Appliance Manager inte visas ska du därför inte gissa: en Super Admin ska kontrollera klientorganisationens faktiska behörigheter och licensen.

Det enda undantag som beaktas här är strikt begränsat: för MSP-Flex-kunder med en XDR-licens dokumenterar Sophos att Sophos NDR kan integreras utan ytterligare Integration License Pack. Detta innebär varken att varje XDR- eller MDR-prenumeration omfattar NDR eller att undantaget gäller för Term-licenser. Bekräfta därför den konkreta klientorganisations-/SKU-behörigheten i Fusion och, om något är oklart, med Sophos eller inköpspartnern utifrån de aktuella licensreglerna för Sophos-integrationer.

CloudFormation skapar avgiftsbelagda AWS-resurser. Den virtuella appliance-enheten ingår i tillämplig Sophos NDR-behörighet; av detta dras här varken slutsatser om ett offentligt listpris eller om kontots konkreta Marketplace-erbjudande. Kontrollera de Marketplace-villkor som visas för närvarande före Submit. Beräkna separat AWS-kategorierna EC2, lagring, offentlig IPv4-adress/Elastic IP, dataöverföring och VPC Traffic Mirroring. Den här runbooken anger avsiktligt inga fasta belopp: Region, drifttid, datavolym och AWS prismodell påverkar kostnaden. Taggar och ett budgetlarm ska ingå i ändringen före produktionsspeglingen.

1. Skapa appliance-enhet och CloudFormation-mall i Sophos Fusion

Öppna Threat Analysis Center > Integrations > Marketplace i Sophos Fusion.
Öppna Sophos Network Detection and Response (NDR).
Klicka på Add Configuration under Data Ingest (Security Alerts).
Ange ett unikt namn och en beskrivning i Step 1, till exempel ndr-aws-prod-eu1 och NDR Sensor für AWS Produktions-VPC eu1.
Välj värdet AWS under Virtual platform i Step 2.
Klicka på Save. Sophos skapar CloudFormation-filen aws_ndr_cf_latest.json.
Öppna Threat Analysis Center > Integrations > Configured och därefter fliken Integration Appliances.
Leta upp den appliance-enhet som nyss skapades. Öppna trepunktsmenyn i den högra kolumnen, välj Download image och spara aws_ndr_cf_latest.json i den skyddade ändringsmappen.

JSON-filen kommer från den egna Fusion-klientorganisationen och den appliance-enhet som just skapades. Använd inte en gammal fil från en annan klientorganisation eller ändring. Ändra inte mallen manuellt för att tvinga fram instanstyper, AMI:er eller nätverksvarianter som inte stöds.

2. Prenumerera på Marketplace-erbjudandet

Sök efter Sophos Integration Appliance i AWS Marketplace.
Klicka på Continue to Subscribe på sidan Product Overview.
Granska villkoren på Subscribe to this software och acceptera dem endast med avsett inköpsgodkännande. Klicka därefter på Continue to Configuration.
Kontrollera Version och Region på Configure this software. De måste överensstämma med byggplanen. Klicka på Continue to Launch.
Öppna först Usage instructions på Launch this software och dokumentera åtkomstinformationen som visas.
Klicka på Launch. AWS öppnar Create stack.

Marketplace-prenumerationen är en förutsättning för att AWS ska acceptera den programvara som mallen refererar till. Börja därför felsökningen av en otillgänglig AMI eller ett behörighetsfel med prenumerationen, Region och Version, inte med att ändra JSON-filen.

3. Skapa CloudFormation-stacken

Granska parametrarna i den mall som nyligen genererats från denna klientorganisation innan du fyller i uppgifterna. Om den erbjuder en dokumenterad parameter för EC2-instanstypen ska du där endast välja en typ som för närvarande stöds av Sophos och dokumentera parameternamn och värde. Om den inte erbjuder någon sådan parameter väljer mallen typen; redigera inte JSON-filen manuellt. I båda fallen verifieras den EC2-typ som faktiskt startades efter att den har skapats.

Låt alternativet Template is ready vara valt under Create stack.
Välj alternativet Upload a template file under Specify template.
Klicka på Choose file, välj den nyligen skapade aws_ndr_cf_latest.json och sedan Next.
Ange ett unikt Stack name under Specify stack details, exempelvis sophos-ndr-prod-eu1.
Ange följande under Network Configuration:
- den planerade befintliga VPC:n;
- Public Subnet för NDR Management Interface;
- Subnet för NDR SPAN interface;
- den förberedda Security Group för administrativ SSH-åtkomst.
Välj befintligt SSH Key Pair under EC2 Instance Configuration. Kontrollera igen att Private Key går att hitta och är skyddad.
Klicka på Next. Kontrollera taggar och övriga AWS-alternativ under Configure stack options. Godta inte standardvärden blint, utan jämför dem med ändringen.
Kontrollera sammanfattningen och klicka på Submit.
Vänta på CREATE_COMPLETE. Sophos anger att det vanligtvis tar fem till sex minuter; CloudFormation-händelserna är avgörande, inte denna tidsangivelse.

Före Mirror Session måste åtminstone den förväntade Sophos-appliance-enheten, dess faktiska EC2-typ, ENI för hantering och SPAN, NDR SPAN Target, NDR Traffic Mirror Filter, InternalMgmtSG samt den Elastic IP som faktiskt används och dess koppling kunna hittas i stacken eller tillhörande AWS-resurser. Om något saknas eller om stacken inte slutar med CREATE_COMPLETE ska ingen Mirror Session skapas.

4. Skapa en Traffic Mirror Session

Alla EC2-ENI:er och topologier är inte automatiskt lämpliga som Mirror Source. Kontrollera innan den skapas mot aktuell AWS-dokumentation vilka källinstanstyper som stöds, förutsättningarna och begränsningarna för Mirror Target samt den konkreta topologin för Source/Target, Region och Availability Zone. Kontrollera dessutom i Service Quotas och mot AWS-kvoterna för Traffic Mirroring att det finns tillräcklig kvot för Source, Sessions, Targets och Filter. Denna AWS-kontroll är en separat godkännandepunkt; Sophos lista över appliance-typer som stöds bekräftar inte att ett valfritt Workload-ENI kan speglas.

Öppna VPC > Traffic mirror sessions > Create traffic mirror session och fyll medvetet i fälten:

Name Tag: ett beskrivande namn, exempelvis ndr-prod-app01;
Description: syfte och ändringsreferens, exempelvis Mirror app01 ENI to Sophos NDR - CHG-1234;
Mirror Source: ENI:t för det godkända testsystemet, inte bara en EC2-instans med liknande namn;
Mirror Target: det NDR SPAN Target som skapats av stacken;
Session number: ett nummer som passar denna Source. AWS använder det för ordningsföljden om samma Source har flera Sessions. Inventera befintliga Sessions innan numret väljs;
VNI: 1;
Filter: det NDR Traffic Mirror Filter som skapats av stacken.

Klicka inte på Create förrän Source, Target, Session number, VNI och Filter har kontrollerats enligt fyrögonsprincipen. VNI = 1 och valet av det genererade filtret är produktkrav. Source, Name, Description och Session number måste däremot passa den egna AWS-miljön.

Skapa inte fler källor ”för säkerhets skull” under det första testet. En ytterligare Mirror Session ökar datamängden, kostnaderna och undersökningsområdet och kräver därför ett eget verksamhetsgodkännande.

5. Konfigurera hanteringsåtkomst och autentiseringsuppgifter

Sök efter namnet på appliance-enheten i AWS Console, välj fliken EC2 och öppna instansen Sophos Appliance.
Öppna fliken Security i Instance Summary och därefter InternalMgmtSG.
Lägg under Inbound rules endast till TCP 8443 för godkända administrativa CIDR:er. Dokumentera Rule-ID, Source och ändringsreferens.
Öppna Threat Analysis Center > Integrations > Configured > Integration Appliances i Sophos Fusion.
Öppna trepunktsmenyn för appliance-enheten och välj Open Appliance Manager.
Klicka på reset it i bekräftelsedialogrutan för att ställa in lösenordet.
Logga in med det fasta användarnamnet zadmin och det angivna lösenordet.

Behandla lösenordet för zadmin som en privilegierad hemlighet. Lagra det i det godkända lösenordsvalvet, inte i CloudFormation-mallen, ärendet eller en skärmbild. Alla administratörer använder samma lösenord för Appliance Manager. Om det förloras återställs det via Open Appliance Manager > reset it.

Acceptans av distribution och första registrering

Att EC2 har statusen running bevisar i sig varken speglingssökvägen eller registreringen. Kontrollera i denna ordning:

CloudFormation: Stacken visar CREATE_COMPLETE; förväntade resurser finns och inga händelser har hoppats över eller misslyckats.
Nätverkstilldelning: VPC, Management-subnet, SPAN-subnet, Elastic IP, båda ENI:erna och SSH Key Pair överensstämmer med byggplanen.
Exponering: SSH och TCP 8443 kan endast nås från de godkända administrativa näten. Det finns ingen ny hanteringsregel med 0.0.0.0/0.
Mirror-konfiguration: Session pekar på exakt godkänt Source-ENI, NDR SPAN Target, VNI 1 och NDR Traffic Mirror Filter. Session number och befintliga parallella Sessions är dokumenterade.
Sophos-anslutning: Appliance-enheten går att hitta under Integration Appliances; dess NDR-status i Sophos Fusion är grön, Open Appliance Manager öppnar förväntat mål och inloggningen som zadmin fungerar.
Preliminär datasökväg: Generera normal, ofarlig trafik på ENI:t för Mirror Source under det godkända testfönstret. Kontrollera på fliken NDR i Appliance Manager uppladdningsprocenten, insamlingsprocenten för den konfigurerade SPAN-porten och diagrammet Total flows. Dokumentera mättid och värden. En Detection krävs inte för detta infrastrukturtest.
Negativ kontroll: En icke godkänd administrativ källa får inte nå TCP 8443. Denna kontroll bekräftar hanteringsbegränsningen, inte NDR-identifieringen.

Dokumentera Stack-ID, Appliance-Name, Instance-ID och -Type, Management- och SPAN-ENI, faktisk EIP-koppling, Mirror-Session-ID, Source-ENI, Target, Filter, VNI, Security-Group-Rule-ID:n, NDR-mätvärden och acceptansfönstret. Hemligheter hör inte hemma i detta protokoll. Denna acceptans bekräftar endast distribution och första registrering. Kontrollera därefter hela den speglade datasökvägen med Konfigurera och validera Traffic Mirroring för Sophos NDR och utför sedan ett säkert heltäckande Detection-test. Varken inloggning eller vanlig testtrafik bevisar i sig att identifieringskedjan fungerar.

Felsökning efter symptom

Stacken slutar inte med `CREATE_COMPLETE`

Öppna först stackfliken Events och arbeta utifrån den första misslyckade händelsen, inte baklänges från det sista följdfelet.

Vid Marketplace- eller AMI-behörighetsfel: kontrollera prenumerationen, accepterade villkor, Version och Region.
Vid behörighetsfel: låt AWS-administratören kontrollera den åtgärd och resurs som anges i den konkreta händelsen. Tilldela inte en generell administratörspolicy som snabb lösning.
Vid nätverksparametrar: jämför VPC- och Subnet-ID:n, tilldelad Elastic IP eller tillgänglig EIP-kvot, Security Group och SSH Key Pair med byggplanen.
Vid kapacitets- eller kvotfel: kontrollera den valda instanstyp som stöds och det konkreta AWS-felet. Byt inte till en typ som inte erbjuds av mallen.

Så länge stacken är ofullständig ska varken Mirror Session eller ytterligare Inbound Rules skapas.

Appliance-enheten körs, men ingen speglad trafik kommer fram

Kontrollera kedjan i denna ordning:

Är Mirror Source verkligen det ENI som testtrafiken går genom?
Är Mirror Target detta stacks NDR SPAN Target och inte ett liknande namngivet Target från en annan miljö?
Är VNI inställt på 1?
Är NDR Traffic Mirror Filter valt?
Kolliderar Session number med den avsedda utvärderingsordningen för andra Sessions från samma Source?
Genererades faktiskt trafik genom detta ENI under det dokumenterade fönstret?

Ändra alltid bara en av dessa variabler och upprepa därefter samma test. Ett bredare val av Filter eller Source ersätter inte en orsaksanalys.

Mirror Session kan inte skapas

Läs först det konkreta AWS-API-/konsolfelet och ändra inte Source, Target och Filter samtidigt.
Kontrollera Source-ENI och dess EC2-instanstyp igen mot de aktuella AWS-förutsättningarna och -begränsningarna för Traffic Mirroring.
Jämför Source/Target-topologin och valet av Region/Availability Zone med aktuell AWS-dokumentation.
Kontrollera de berörda Traffic-Mirroring-kvoterna i Service Quotas. Begär en höjning eller ändra designen via den ordinarie AWS-ändringen i stället för att ta bort befintliga Sessions utan kontroll.

Registrering eller NDR-uppladdning misslyckas

Kontrollera först den sökväg som fastställdes i Kontrollera utgående anslutning i förväg. I synnerhet måste DNS, Route Table, Internet Gateway eller godkänd utgående design, Network ACL, Security-Group-Egress samt Proxy och Upstream-Firewall fungera tillsammans. Jämför reglerna igen med Sophos aktuella port- och domänundantag. Enligt Sophos tyder ett fel vid uppladdning via en försignerad S3-URL ofta på att utgående internettrafik blockeras i Proxy eller brandväggen. Utöka inte utgående åtkomst generellt; dokumentera det konkreta mål som blockeras och tillåt endast det undantag som Sophos för närvarande kräver.

Appliance Manager kan inte nås via TCP 8443

Kontrollera om InternalMgmtSG tillåter den aktuella offentliga administrativa källadressen.
Kontrollera Elastic-IP-kopplingen till Management Interface och valt Public Subnet.
Säkerställ att Open Appliance Manager öppnar förväntad appliance-enhet.
Om en regel tillfälligt har utökats till 0.0.0.0/0, stäng den omedelbart igen; bred åtkomst är inte ett diagnostiksteg.

Undersök inte ett lösenordsproblem förrän nätverkssökvägen fungerar.

Inloggningen för `zadmin` misslyckas eller Appliance Manager är låst

Om lösenordet är okänt använder du Open Appliance Manager > reset it i Sophos Fusion. Om appliance-enheten uttryckligen visar ett meddelande om låsning dokumenterar Sophos följande ingrepp via SSH för AWS:

redis-cli --no-auth-warning -h redis-master.default.svc.cluster.local -p 6379 -a $(jq -r .RedisPassword /etc/dragonfly/sensorapi_config.json) SET userlockout '{"attempt":0,"locked":false}'

Kommandot körs uteslutande i SSH-sessionen på den berörda Sophos NDR EC2-instansen med den Private Key som valdes vid distributionen. Den här runbooken anger medvetet inget användarnamn för operativsystemet och ingen fullständig SSH-syntax, eftersom den verifierade Sophos-sidan inte dokumenterar dem. Hämta aktuell anslutningsidentitet från Usage instructions för det prenumererade Marketplace-erbjudandet eller klarlägg den med Sophos Support; gissa inte. Jämför måladress, Instance-ID och Host-Fingerprint med AWS-inventariet innan anslutningen upprättas. Kommandot ändrar låsningsstatusen men anger inget nytt lösenord. Använd det endast när låsningen uttryckligen visas, inte som en generell inloggningslösning. Testa därefter inloggningen med det befintliga lösenordet; om det inte fungerar återställer du sedan lösenordet i Sophos Fusion. Kommando och resultat ska dokumenteras i ändringsprotokollet utan lösenord eller Private Key.

Begränsad återställningsväg i stället för obekräftad avveckling

Före varje manuell ändring av en Security Group exporteras utgångsläget eller dokumenteras med Rule-ID:n. Om den nya TCP-8443- eller Syslog-regeln orsakar problem kan just denna manuellt tillagda regel tas bort och det dokumenterade utgångsläget kontrolleras. Detta är en begränsad återställningsväg för den egna Inbound-ändringen, inte en avveckling av NDR-appliance-enheten.

För stack, Marketplace-prenumeration, Appliance-objekt, EC2/EBS, ENI:er, Elastic IP, Traffic Mirror Session, Target, Filter och Security Groups anges här avsiktligt ingen fullständig borttagningsordning. Det påstås inte heller att borttagning av CloudFormation-stacken hanterar alla tillhörande resurser, kostnader, Sophos-objekt eller datakonsekvenser. Tills dessa beroenden har verifierats med aktuell tillverkardokumentation och ett test får resurser endast tas bort genom en separat verifierad Retirement-ändring.