Distribuire Sophos NDR su AWS

Sophos NDR viene eseguito su AWS come appliance di integrazione basata su EC2. Riceve una copia del traffico VPC selezionato tramite VPC Traffic Mirroring, lo analizza passivamente e invia i dati NDR al Sophos Data Lake. L’appliance non è inline e non sostituisce né i Security Group né un firewall.

La procedura generale affidabile consiste nel chiarire licenze e responsabilità, documentare i dettagli della rete AWS, creare l’appliance in Sophos Fusion, scaricare il template CloudFormation generato, sottoscrivere l’offerta Marketplace, creare lo stack, aggiungere esattamente una Mirror Session controllata, limitare l’accesso di gestione e convalidare separatamente ogni livello.

⚠️ Questo runbook non include intenzionalmente una procedura completa di dismissione. La sequenza sicura e le conseguenze dell’eliminazione delle risorse di stack, appliance, EC2, EBS, ENI, Security Group, Elastic IP, mirroring e Marketplace non sono state verificate completamente. Una distribuzione non riuscita non deve quindi essere «ripulita» con una sequenza di eliminazione improvvisata.

Architettura e decisioni prima di iniziare

CloudFormation crea due percorsi di rete separati logicamente:

La Management Interface si trova in una Public Subnet e utilizza un Elastic IP Address assegnato. SSH e l’accesso a Sophos Appliance Manager utilizzano questo percorso.
La SPAN interface riceve il traffico sottoposto a mirroring. L’NDR SPAN Target creato dal template funge da Mirror Target.
Una Traffic mirror session collega un’ENI di origine selezionata a questo target. L’NDR Traffic Mirror Filter, anch’esso creato dal template, determina quali pacchetti vengono sottoposti a mirroring.
L’appliance elabora le copie e invia i dati NDR a Sophos. I flussi originali rimangono sul normale percorso dati AWS.

La decisione di progettazione più importante non è quindi «quale intero VPC dobbiamo monitorare?», bensì quale ENI rappresenta una Mirror Source appropriata. Inizia con una singola ENI documentata appartenente a un sistema di test. In questo modo si mantengono ridotti il volume di dati, i costi e l’ambito dei possibili errori. Aggiungi altre origini solo dopo l’accettazione tecnica.

Prima della distribuzione, documenta almeno quanto segue in un piano di distribuzione:

account AWS, Region, VPC, Availability Zone e tag del proprietario;
ID del VPC e ID delle Management e SPAN Subnet;
almeno un Elastic IP assegnato nell’account AWS per la Management Interface; si tratta di un prerequisito dell’account, ma nell’elenco documentato dei parametri non figura come input del template selezionabile in anticipo;
tipi EC2 attualmente supportati da Sophos: c5n.2xlarge, c6i.4xlarge o c7i.16xlarge con virtualizzazione Nitro; verifica il tipo effettivamente utilizzato nel template corrente del tenant e nell’istanza dopo la distribuzione;
nome dell’SSH Key Pair esistente e percorso di archiviazione sicuro della relativa Private Key;
un Security Group per SSH e reti di origine fisse degli amministratori;
l’ENI iniziale che fungerà da Mirror Source e il team responsabile del relativo workload;
il normale traffico di test previsto per questa ENI;
centro di costo, allarme di budget e approvazione dei costi dell’infrastruttura AWS, oltre che delle condizioni Marketplace visualizzate per questo account.

VPC, Subnet ed Elastic IP

È possibile utilizzare un VPC e Subnet esistenti. La selezione, tuttavia, non deve basarsi solo sui nomi:

Pianifica la Management Subnet come Public Subnet. Prima di selezionarla, verificane la Route Table e il percorso Internet previsto.
Specifica la SPAN Subnet per la NDR SPAN interface. Registra la Subnet e l’Availability Zone insieme alla Mirror Source, anziché dedurre in seguito i valori dai nomi delle risorse.
L’Elastic IP deve essere associato alla Management Interface, non al lato SPAN. Verifica in anticipo che nell’account sia assegnato almeno un Elastic IP. Non affermare che lo stack utilizzi uno specifico indirizzo esistente: dopo CREATE_COMPLETE, determina e registra l’indirizzo effettivamente creato o utilizzato e la relativa associazione all’ENI.
Il template seleziona automaticamente AMI e Region in base alla Region AWS in cui viene caricato. Non forzare un’altra AMI modificando manualmente il template.

Security Group e SSH Key Pair

Utilizza un AWS Key Pair esistente la cui Private Key sia già archiviata in modo sicuro. CloudFormation richiede il nome del Key Pair; la Private Key non viene memorizzata in Sophos Fusion né nel template. Senza la Private Key, l’accesso SSH all’appliance AWS documentato da Sophos non sarà disponibile in seguito.

Prepara un Security Group che consenta SSH solo dalla rete di accesso amministrativo, ad esempio da un IP di uscita aziendale fisso come /32 o tramite un Jump Host controllato. Non esporre né SSH né TCP 8443 a 0.0.0.0/0.

Il template crea anche InternalMgmtSG. Dopo la distribuzione, consenti TCP 8443 solo per le effettive origini degli amministratori. Se la stessa appliance ospita anche un Log Collector, consenti Syslog esclusivamente con il protocollo e la porta richiesti dal relativo connettore e solo dalle reti di origine interne. VPC Traffic Mirroring non richiede di per sé una regola Syslog indiscriminata da Internet.

Convalidare in anticipo la connettività in uscita

Una Public Subnet e un Elastic IP non dimostrano, da soli, l’esistenza di un percorso in uscita funzionante. Prima di Submit, il team di rete responsabile deve confermare che la Management Interface possa comunicare in uscita tramite la route prevista e un Internet Gateway o il progetto di uscita centralizzato approvato. Verifica la risoluzione DNS, la Route Table, la Network ACL, le regole in uscita del Security Group e le regole del proxy e del firewall upstream.

Le destinazioni e le porte necessarie non vengono riportate in questo runbook. Al momento della modifica, confronta invece le eccezioni correnti relative a porte e domini per le appliance Sophos con le regole in uscita. Queste autorizzazioni sono pertinenti per l’avvio, gli aggiornamenti, la registrazione e il caricamento dei dati; la prova di connettività verso una singola destinazione non sostituisce il confronto completo.

Prerequisiti, ruoli, licenza e costi

La configurazione richiede:

un account AWS con VPC, Subnet e Availability Zone esistenti;
un account Sophos Fusion;
in genere, il Sophos Network Detection and Response integration license pack;
almeno un’istanza EC2 di origine idonea o la relativa ENI;
almeno un Elastic IP Address assegnato nell’account AWS;
un AWS SSH Key Pair archiviato;
un’approvazione della modifica in corso di validità per il mirroring della rete e i dati elaborati tramite esso.

Se possibile, suddividi le attività come segue, senza inventare nomi di policy IAM non confermati:

Un amministratore Sophos Fusion crea la configurazione NDR e scarica il template.
Una persona autorizzata agli acquisti accetta le condizioni di Sophos Integration Appliance in AWS Marketplace.
Un amministratore AWS con le autorizzazioni necessarie per lo stack e le risorse di rete referenziate crea le risorse CloudFormation, EC2, VPC Traffic Mirroring, Security Group ed Elastic IP.
Il team di rete o del workload responsabile conferma la Mirror Source, il comportamento del filtro, la finestra di test e il traffico previsto.

Sophos non indica un ruolo Fusion minimo distinto e specifico per NDR per questa procedura. Pertanto, se Add Configuration, Download image o Open Appliance Manager non sono visibili, non fare supposizioni: un Super Admin deve verificare le autorizzazioni effettive del tenant e la licenza.

L’unica eccezione considerata qui è strettamente delimitata: per i clienti MSP Flex con una licenza XDR, Sophos documenta che Sophos NDR può essere integrato senza un Integration License Pack aggiuntivo. Ciò non significa né che ogni sottoscrizione XDR o MDR includa NDR, né che l’eccezione si applichi alle licenze Term. Conferma quindi il diritto specifico del tenant/SKU in Fusion e, in caso di dubbi, con Sophos o con il partner responsabile degli acquisti facendo riferimento alle regole correnti per le licenze di integrazione Sophos.

CloudFormation crea risorse AWS fatturabili. L’appliance virtuale è inclusa nel diritto Sophos NDR applicabile; da ciò non viene dedotto né un prezzo di listino pubblico né alcunché sull’offerta Marketplace specifica dell’account. Prima di Submit, verifica le condizioni Marketplace visualizzate in quel momento. Stima separatamente le categorie AWS EC2, archiviazione, indirizzo IPv4 pubblico/Elastic IP, trasferimento dati e VPC Traffic Mirroring. Questo runbook non fornisce intenzionalmente importi fissi: Region, durata di esecuzione, volume di dati e modello tariffario AWS modificano il calcolo. I tag e un allarme di budget devono essere inclusi nella modifica prima di iniziare il mirroring in produzione.

1. Creare l’appliance e il template CloudFormation in Sophos Fusion

In Sophos Fusion, apri Threat Analysis Center > Integrations > Marketplace.
Apri Sophos Network Detection and Response (NDR).
In Data Ingest (Security Alerts), fai clic su Add Configuration.
In Step 1, inserisci un nome e una descrizione univoci, ad esempio ndr-aws-prod-eu1 e NDR Sensor für AWS Produktions-VPC eu1.
In Step 2, sotto Virtual platform, seleziona AWS.
Fai clic su Save. Sophos genera il file CloudFormation aws_ndr_cf_latest.json.
Apri Threat Analysis Center > Integrations > Configured, quindi la scheda Integration Appliances.
Individua l’appliance appena creata. Nella colonna a destra, apri il menu con i tre puntini, seleziona Download image e salva aws_ndr_cf_latest.json nella cartella protetta della modifica.

Il JSON proviene dal tuo tenant Fusion e dall’appliance appena creata. Non utilizzare un vecchio file proveniente da un altro tenant o da un’altra modifica. Non modificare manualmente il template per forzare tipi di istanza, AMI o varianti di rete non supportati.

2. Sottoscrivere l’offerta Marketplace

Cerca Sophos Integration Appliance in AWS Marketplace.
Nella pagina Product Overview, fai clic su Continue to Subscribe.
In Subscribe to this software, esamina le condizioni e accettale solo con l’approvazione all’acquisto prevista. Quindi fai clic su Continue to Configuration.
In Configure this software, verifica la versione e la Region. Devono corrispondere al piano di distribuzione. Fai clic su Continue to Launch.
In Launch this software, apri innanzitutto Usage instructions e documenta le istruzioni di accesso visualizzate.
Fai clic su Launch. AWS apre Create stack.

La sottoscrizione Marketplace è un prerequisito affinché AWS accetti il software referenziato dal template. Pertanto, se un’AMI non è disponibile o si verifica un errore relativo al diritto, inizia la risoluzione dei problemi dalla sottoscrizione, dalla Region e dalla versione, anziché modificare il JSON.

3. Creare lo stack CloudFormation

Prima di compilare il modulo, esamina i parametri del template attualmente generato da questo tenant. Se offre un parametro documentato per il tipo di istanza EC2, seleziona esclusivamente un tipo attualmente supportato da Sophos e registra il nome e il valore del parametro. Se non offre tale parametro, il template seleziona il tipo; non modificare manualmente il JSON. In entrambi i casi, verifica dopo la creazione il tipo EC2 effettivamente avviato.

In Create stack, lascia selezionata l’opzione Template is ready.
In Specify template, seleziona Upload a template file.
Fai clic su Choose file, seleziona il file aws_ndr_cf_latest.json appena generato, quindi fai clic su Next.
In Specify stack details, inserisci uno Stack name univoco, ad esempio sophos-ndr-prod-eu1.
In Network Configuration, inserisci:
- il VPC esistente pianificato;
- la Public Subnet per la NDR Management Interface;
- la Subnet per la NDR SPAN interface;
- il Security Group preparato per l’accesso SSH amministrativo.
In EC2 Instance Configuration, seleziona l’SSH Key Pair esistente. Verifica nuovamente che il Private Key sia reperibile e protetto.
Fai clic su Next. In Configure stack options, esamina i tag e le altre opzioni AWS. Non accettare automaticamente i valori predefiniti; confrontali con la modifica.
Esamina il riepilogo e fai clic su Submit.
Attendi lo stato CREATE_COMPLETE. Sophos indica che in genere sono necessari da cinque a sei minuti; fanno fede gli eventi CloudFormation, non questa stima temporale.

Prima di creare la Mirror Session, nello stack o nelle risorse AWS associate devono essere reperibili almeno l’appliance Sophos prevista, il relativo tipo EC2 effettivo, le ENI di Management e SPAN, l’NDR SPAN Target, l’NDR Traffic Mirror Filter, InternalMgmtSG, nonché l’Elastic IP effettivamente utilizzato e la relativa associazione. Se manca un elemento o lo stack non termina con CREATE_COMPLETE, non creare alcuna Mirror Session.

4. Creare una Traffic Mirror Session

Non tutte le ENI o le topologie EC2 sono automaticamente idonee come Mirror Source. Prima di crearla, consulta la documentazione AWS corrente per verificare i tipi di istanza di origine supportati, i prerequisiti e le limitazioni per il Mirror Target e la specifica topologia Source/Target, Region e Availability Zone. Verifica inoltre in Service Quotas e nelle quote AWS per Traffic Mirroring che siano disponibili quote sufficienti per origini, sessioni, target e filtri. Questa verifica AWS rappresenta un punto di approvazione separato; l’elenco Sophos dei tipi di appliance supportati non conferma che una qualsiasi ENI di workload supporti il mirroring.

Apri VPC > Traffic mirror sessions > Create traffic mirror session e compila attentamente i campi:

Name Tag: un nome descrittivo, ad esempio ndr-prod-app01;
Description: scopo e riferimento della modifica, ad esempio Mirror app01 ENI to Sophos NDR - CHG-1234;
Mirror Source: l’ENI del sistema di test approvato, non semplicemente un’istanza EC2 con un nome simile;
Mirror Target: l’NDR SPAN Target creato dallo stack;
Session number: un numero appropriato per questa Source. AWS lo utilizza per stabilire l’ordine quando la stessa Source ha più sessioni. Prima di sceglierlo, effettua l’inventario delle sessioni esistenti;
VNI: 1;
Filter: l’NDR Traffic Mirror Filter creato dallo stack.

Fai clic su Create solo dopo che due persone hanno confrontato Source, Target, Session number, VNI e Filter. VNI = 1 e l’uso del filtro generato sono requisiti del prodotto. Source, nome, descrizione e Session number devono invece corrispondere al tuo ambiente AWS.

Non aggiungere altre origini «per sicurezza» durante il test iniziale. Una Mirror Session aggiuntiva aumenta il volume di dati, i costi e l’ambito dell’indagine e richiede quindi una propria approvazione tecnica.

5. Configurare l’accesso di gestione e le credenziali

Nella console AWS, cerca il nome dell’appliance, seleziona la scheda EC2 e apri l’istanza Sophos Appliance.
In Instance Summary, apri la scheda Security, quindi InternalMgmtSG.
In Inbound rules, aggiungi TCP 8443 solo per i CIDR degli amministratori approvati. Documenta il Rule ID, l’origine e il riferimento della modifica.
In Sophos Fusion, apri Threat Analysis Center > Integrations > Configured > Integration Appliances.
Apri il menu con i tre puntini dell’appliance e seleziona Open Appliance Manager.
Nella finestra di dialogo di conferma, fai clic su reset it per impostare la password.
Accedi con il nome utente fisso zadmin e la password impostata.

Tratta la password di zadmin come un segreto privilegiato. Archiviala nel vault di password approvato, non nel template CloudFormation, in un ticket o in uno screenshot. Tutti gli amministratori utilizzano la stessa password di Appliance Manager. Se viene smarrita, reimpostala tramite Open Appliance Manager > reset it.

Convalidare la distribuzione e la registrazione iniziale

Il solo stato in esecuzione di EC2 non dimostra né il percorso di mirroring né la registrazione. Esegui le verifiche nell’ordine seguente:

CloudFormation: Lo stack mostra CREATE_COMPLETE; le risorse previste sono presenti e non vi sono eventi ignorati o non riusciti.
Associazione di rete: VPC, Management Subnet, SPAN Subnet, Elastic IP, entrambe le ENI e SSH Key Pair corrispondono al piano di distribuzione.
Esposizione: SSH e TCP 8443 sono accessibili solo dalle reti degli amministratori approvate. Non esiste alcuna nuova regola di gestione con 0.0.0.0/0.
Configurazione del mirroring: La sessione punta esattamente alla Source ENI approvata, all’NDR SPAN Target, a VNI 1 e all’NDR Traffic Mirror Filter. Il Session number e le eventuali sessioni parallele esistenti sono documentati.
Connessione Sophos: L’appliance è visibile in Integration Appliances; il relativo stato NDR in Sophos Fusion è verde, Open Appliance Manager apre la destinazione prevista e l’accesso come zadmin funziona.
Percorso dati preliminare: Durante la finestra di test approvata, genera traffico normale e innocuo sulla Mirror Source ENI. Nella scheda NDR di Appliance Manager, verifica la percentuale di caricamento, la percentuale di acquisizione della porta SPAN configurata e il grafico Total flows. Registra l’ora e i valori della misurazione. Per questo test dell’infrastruttura non è richiesta una Detection.
Controllo negativo: Un’origine amministrativa non approvata non deve poter raggiungere TCP 8443. Questo controllo verifica la limitazione dell’accesso di gestione, non il rilevamento NDR.

Registra lo Stack ID, il nome dell’appliance, l’ID e il tipo dell’istanza, le ENI di Management e SPAN, l’effettiva associazione EIP, il Mirror Session ID, la Source ENI, il Target, il Filter, il VNI, i Security Group Rule ID, le misurazioni NDR e la finestra di accettazione. I segreti non devono figurare in questa registrazione. Questa accettazione conferma solo la distribuzione e la registrazione iniziale. Successivamente, convalida completamente il percorso dei dati sottoposti a mirroring con Configurare e convalidare Traffic Mirroring per Sophos NDR, quindi esegui un test di rilevamento end-to-end sicuro. Né un accesso riuscito né il normale traffico di test dimostrano da soli il funzionamento della catena di rilevamento.

Risoluzione dei problemi per sintomo

Lo stack non termina con `CREATE_COMPLETE`

Apri innanzitutto la scheda Events dello stack e procedi dal primo evento non riuscito, anziché risalire dall’ultimo errore conseguente.

Per errori di diritto Marketplace o AMI: verifica la sottoscrizione, le condizioni accettate, la versione e la Region.
Per errori di autorizzazione: chiedi all’amministratore AWS di verificare l’azione e la risorsa indicate nell’evento specifico. Non assegnare una policy di amministratore generale come soluzione rapida.
Per i parametri di rete: confronta gli ID di VPC e Subnet, l’Elastic IP assegnato o la quota EIP disponibile, il Security Group e l’SSH Key Pair con il piano di distribuzione.
Per errori di capacità o quota: verifica il tipo di istanza supportato selezionato e lo specifico messaggio di errore AWS. Non passare a un tipo non offerto dal template.

Finché lo stack è incompleto, non creare né una Mirror Session né ulteriori Inbound Rules.

L’appliance è in esecuzione, ma non riceve traffico sottoposto a mirroring

Verifica la catena nell’ordine seguente:

La Mirror Source è davvero l’ENI attraverso cui passa il traffico di test?
Il Mirror Target è l’NDR SPAN Target di questo stack e non un target dal nome simile appartenente a un altro ambiente?
VNI è impostato su 1?
È selezionato l’NDR Traffic Mirror Filter?
Il Session number è in conflitto con l’ordine di valutazione previsto per altre sessioni della stessa Source?
Durante la finestra documentata è stato effettivamente generato traffico attraverso questa ENI?

Modifica una sola di queste variabili alla volta, quindi ripeti lo stesso test. Una selezione più ampia del filtro o della Source non sostituisce l’analisi della causa principale.

Impossibile creare la Mirror Session

Leggi innanzitutto lo specifico errore dell’API o della console AWS; non modificare contemporaneamente Source, Target e Filter.
Verifica nuovamente la Source ENI e il relativo tipo di istanza EC2 rispetto ai prerequisiti e alle limitazioni AWS correnti per Traffic Mirroring.
Confronta la topologia Source/Target e la selezione di Region/Availability Zone con la documentazione AWS corrente.
Verifica le quote Traffic Mirroring interessate in Service Quotas. Richiedi un aumento o modifica il progetto tramite il normale processo di modifica AWS, anziché eliminare sessioni esistenti senza averle esaminate.

Registrazione o caricamento NDR non riusciti

Verifica innanzitutto il percorso definito in Convalidare in anticipo la connettività in uscita. In particolare, DNS, Route Table, Internet Gateway o progetto di uscita approvato, Network ACL, regole in uscita del Security Group, proxy e firewall upstream devono essere coerenti. Confronta nuovamente le regole con le eccezioni correnti relative a porte e domini Sophos. Secondo Sophos, un errore di caricamento che coinvolge un URL S3 prefirmato indica spesso che il proxy o il firewall bloccano il traffico Internet in uscita. Non ampliare indiscriminatamente le regole in uscita; documenta la specifica destinazione bloccata e consenti solo l’eccezione attualmente richiesta da Sophos.

Appliance Manager non è raggiungibile tramite TCP 8443

Verifica che InternalMgmtSG consenta l’indirizzo di origine pubblico corrente dell’amministratore.
Verifica l’associazione dell’Elastic IP alla Management Interface e la Public Subnet selezionata.
Assicurati che Open Appliance Manager apra l’appliance prevista.
Se una regola è stata temporaneamente ampliata a 0.0.0.0/0, restringila di nuovo immediatamente; un accesso ampio non è un passaggio diagnostico.

Esamina un problema relativo alla password solo dopo che il percorso di rete funziona.

Accesso di `zadmin` non riuscito o Appliance Manager bloccato

In caso di password sconosciuta, utilizza Open Appliance Manager > reset it in Sophos Fusion. Se l’appliance mostra esplicitamente un messaggio di blocco, Sophos documenta per AWS il seguente intervento tramite SSH:

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}'

Esegui questo comando esclusivamente nella sessione SSH dell’istanza EC2 Sophos NDR interessata, utilizzando il Private Key selezionato durante la distribuzione. Questo runbook non fornisce intenzionalmente né un nome utente del sistema operativo né la sintassi SSH completa, perché la pagina Sophos esaminata non li documenta. Ricava l’identità di connessione corrente dalle Usage instructions dell’offerta Marketplace sottoscritta o verificala con Sophos Support; non fare supposizioni. Prima di connetterti, confronta l’indirizzo di destinazione, l’ID dell’istanza e l’impronta digitale dell’host con l’inventario AWS. Il comando modifica lo stato di blocco, ma non imposta una nuova password. Utilizzalo solo quando viene mostrato esplicitamente un blocco, non come soluzione generale per l’accesso. Prova quindi la password esistente; se non funziona, reimpostala in Sophos Fusion. Registra il comando e il risultato, senza password o Private Key, nel registro della modifica.

Ripristino limitato anziché dismissione non verificata

Prima di qualsiasi modifica manuale a un Security Group, esporta lo stato iniziale o documentalo utilizzando i Rule ID. Se la nuova regola TCP 8443 o Syslog causa un problema, è possibile rimuovere esattamente la regola aggiunta manualmente e verificare lo stato iniziale documentato. Si tratta di un ripristino circoscritto per la propria modifica delle regole in ingresso, non della dismissione dell’appliance NDR.

Non viene intenzionalmente fornita qui alcuna sequenza di eliminazione completa per lo stack, la sottoscrizione Marketplace, l’oggetto appliance, EC2/EBS, le ENI, l’Elastic IP, la Traffic Mirror Session, il Target, il Filter e i Security Group. Questo runbook non afferma inoltre che l’eliminazione dello stack CloudFormation risolva tutte le risorse, i costi, gli oggetti Sophos o le conseguenze sui dati associati. Finché queste dipendenze non saranno state verificate mediante la documentazione corrente del fornitore e test, rimuovi le risorse solo tramite una modifica di dismissione sottoposta a revisione separata.