Acquisire telemetria di rete con un collector Sophos XDR

Per OPNsense, pfSense, Netskope SSE e NetScaler ADC, il percorso documentato utilizza un Sophos XDR Data Collector. Prima si distribuisce il collector, poi si collega la sorgente nel formato syslog appropriato e si verifica l’acquisizione effettiva. Un indirizzo syslog generico non basta: Sophos deve associare correttamente formato e categoria di eventi.

I dati netflow qui descritti richiedono una subscription Sophos Next-Gen SIEM. Netskope e NetScaler forniscono anche altri schemi che non riportano tutti la stessa nota di licenza nella documentazione. Per OPNsense e pfSense, l’ambito verificato comprende eventi firewall di connessione in netflow. La guida SIEM e le basi delle integrazioni chiariscono scelta e licenze.

La guida descrive procedure ufficiali senza dichiarare test propri su questi prodotti.

Preparare collector e sorgenti

Il collector deve essere predisposto per il tenant corretto in Security Operations > Integrations > Data Collectors. Il runbook del collector spiega risorse, uplink regionali, DNS, sincronizzazione e differenze rispetto alla vecchia SVA e a NDR. Un nuovo XDR Data Collector non assume automaticamente un carico NDR esistente.

Prima della modifica documentare percorso log precedente, destinazione nuova, reti sorgenti autorizzate ed eventi desiderati. Consentire syslog in ingresso solo da tali reti. Non sostituire un percorso UDP documentato con TLS-syslog o un formato differente senza verificarne la compatibilità. UDP non conferma la consegna dei singoli messaggi: considerare possibili perdite nel confronto sorgente/destinazione.

Per ogni pilot scegliere un evento innocuo autorizzato con ora ed evidenza alla sorgente. Un receiver configurato o uno stato verde non prova l’acquisizione di ogni categoria né la normalizzazione. Collaudare separatamente comunicazione, flusso e contenuto.

OPNsense: filterlog su UDP/514

Il percorso OPNsense elabora messaggi filterlog per connessioni TCP, UDP e ICMP consentite o bloccate. Occorrono accesso amministrativo OPNsense e collector raggiungibile.

1. Dopo il deployment del collector aprire la configurazione Remote Logging di OPNsense. La navigazione dipende dalla versione; i valori seguenti sono quelli documentati da Sophos.
2. Abilitare Enabled e scegliere UDP(4) in Transport.
3. In Applications scegliere filter (filterlog). In Levels selezionare info, notice, warn, error, critical, alert ed emergency. Lasciare Facilities vuoto.
4. In Hostname inserire l’IP reale del collector e in Port514. Disabilitare rfc5424. La Description documentata è FilterLog; non confondere questo nome con un altro formato.
5. Salvare e generare un evento firewall innocuo previsto. La regola sorgente deve registrarlo realmente. Verificare prima ora, IP sorgente/destinazione e azione in OPNsense, poi nello schema Sophos netflow.

Se il record manca, controllare logging alla sorgente, selezione filterlog, percorso UDP/IPv4, IP, porta e RFC5424. Non disabilitare protezioni per forzare un flusso di test.

pfSense: Firewall Events in formato BSD

pfSense fornisce anche filter log TCP, UDP e ICMP. Il formato documentato differisce da altri log pfSense e non va sostituito con una selezione syslog arbitraria.

1. Aprire Log Settings nell’amministrazione pfSense.
2. In General Logging Options, scegliere BSD (RFC 3164, default) come formato.
3. Abilitare Enable Remote Logging in Remote Logging Options.
4. Per Source Address scegliere un’interfaccia o una rete che raggiunga il collector. Impostare IP Protocol su IPv4.
5. Inserire l’IP reale del collector in Remote log servers e scegliere Firewall Events in Remote Syslog Contents.
6. Salvare, generare un evento firewall autorizzato effettivamente registrato e trovarlo in netflow nel tenant Sophos corretto. Azione e dettagli di connessione devono corrispondere alla sorgente.

Una diversa Source Address può cambiare routing e associazione firewall. Se i dati mancano, verificare prima il percorso uscente dell’interfaccia, poi receiver e formato BSD. Questa procedura non comprende automaticamente altre categorie.

Netskope SSE: Cloud Log Shipper e CEF

Il percorso ha due fasi: Netskope Cloud Log Shipper legge le API Netskope e inoltra CEF tramite syslog al collector Sophos. Un account Netskope inserito direttamente nel collector non sostituisce il Log Shipper.

L’integrazione può fornire attività web/cloud, malware, alert di sicurezza/policy e attività amministrative, associate fra l’altro a http, antivirus, thirdpartyalert, nids e auth. Gli ulteriori eventi di connessione/tunnel netflow richiedono SIEM.

1. Predisporre un Cloud Log Shipper approvato per il tenant Netskope. Configurare accesso API e categorie secondo la procedura Netskope pertinente. La documentazione Sophos non definisce un insieme universale di permessi API.
2. Nel Log Shipper selezionare Plugin: Syslog come uscita.
3. Per Mapping usare Syslog Defaults Mapping. Mantenere il percorso CEF documentato; mapping liberamente modificati possono cambiare la normalizzazione.
4. Impostare come destinazione l’IP reale del XDR Data Collector. Trasporto e receiver devono corrispondere alla configurazione approvata; i requisiti UDP/514 di altri prodotti non stabiliscono una porta universale per Netskope.
5. Scegliere un evento adatto e verificare che il Log Shipper lo abbia letto dall’API e inoltrato. Confrontare poi schema atteso e campi necessari in Sophos.

Se mancano soltanto dati di connessione, verificare anche categorie ed entitlement SIEM. Un record HTTP non prova l’acquisizione di tutte le categorie Netskope. Esaminare separatamente errori di lettura API e di inoltro syslog.

NetScaler ADC: audit log con orario non ambiguo

NetScaler ADC, in precedenza Citrix ADC, invia tramite syslog eventi web/Application Firewall (http), autenticazioni/sessioni VPN (auth) e comandi amministrativi (managementevent). Apertura e chiusura TCP diventano netflow e richiedono SIEM.

1. Dopo il deployment del collector aprire Audit Logging per syslog in NetScaler. Adattare associazione server/policy alla versione e al perimetro: la fonte Sophos non documenta un comando CLI universale.
2. Impostare l’IP del collector corretto come destinazione e verificare il percorso di rete autorizzato.
3. Usare il formato data MM/DD/YYYY. DD/MM/YYYY non è supportato per l’acquisizione corretta.
4. Inviare gli orari degli eventi in UTC. Una modifica successiva della visualizzazione Sophos non corregge un timestamp sorgente interpretato male.
5. Generare una modifica amministrativa o un login approvato nel perimetro audit. Confrontare prova, ora, utente e azione con lo schema Sophos corrispondente. Netflow richiede un test di connessione separato.

Per eventi apparentemente assenti confrontare prima ora sorgente e finestra di ricerca. Data o fuso errati possono collocare il record fuori intervallo. Poi verificare audit policy, categoria effettivamente inviata, IP e rete.

Collaudo e rimozione controllata

Per ogni sorgente documentare almeno un evento riproducibile, sorgente, tenant, ora di acquisizione e schema normalizzato. Confrontare indirizzi, porte, azione e utente quando attesi e presenti. Nessuna detection o case non significa necessariamente nessun dato: conta il record effettivo.

Ripetere il collaudo dopo modifiche della sorgente o del formato. Il CEF correttamente elaborato ieri non prova nulla su un mapping cambiato oggi. Per discrepanze temporali verificare l’orologio sorgente invece di disabilitare la protezione.

Per il rollback interrompere la nuova voce Remote Logging o l’uscita Shipper dedicata, poi controllare il vecchio percorso documentato. Conservare collector, identità API e altre uscite condivise. Rimuovere risorse esclusivamente dedicate solo dopo averne verificato le dipendenze. Eliminare l’integrazione non prova la cancellazione della telemetria storica né recupera eventi persi.