Il sistema di full packet capture sviluppato in AOL dal 2012 con il nome Moloch ha cambiato nome in Arkime nel luglio 2021, insieme alla release 3.0. La licenza resta Apache 2.0 e il repository si è spostato dall’organizzazione GitHub di AOL a una propria (arkime/arkime). Sul sito del progetto il cambio è motivato dalla volontà di evitare le connotazioni del nome precedente; sul piano tecnico non cambia niente.

Contesto e problema

La full packet capture (fPCAP) registra su disco l’intero traffico di rete, payload incluso, non solo i metadati di flusso. Serve all’analisi retrospettiva: quando un alert IDS, un indicatore di compromissione o una segnalazione esterna arriva con giorni di ritardo, avere i pacchetti grezzi di quel periodo vuol dire poter ricostruire cosa è passato davvero sul filo, invece di fermarsi a un record NetFlow o a un log applicativo già aggregato.

Il problema è la scala. La documentazione di Arkime stima che 1 Gbps di traffico non compresso consumi nell’ordine di 11 TB di disco al giorno. A queste cifre registrare è la parte facile; il vincolo vero è tenere i dati ricercabili in tempi utili e ruotare lo storage senza riempire il volume. Tre componenti si dividono queste responsabilità.

Architettura

I componenti principali sono tre.

  • capture — processo C che legge i pacchetti dall’interfaccia, li scrive su disco in file PCAP e manda a Elasticsearch i metadati di ogni sessione. C’è un requisito strutturale: tutti i pacchetti dello stesso 5-tuple (IP sorgente, IP destinazione, porta sorgente, porta destinazione, protocollo) devono passare per lo stesso processo capture, vincolo da rispettare quando si distribuisce il traffico su più code o più nodi.
  • viewer — interfaccia web in Node.js per ricerca, ispezione delle sessioni e download dei PCAP. È anche il componente che cancella i file PCAP quando lo spazio disco scende sotto le soglie configurate.
  • Elasticsearch — il database dei metadati di sessione, non dei pacchetti. Con la 3.0 il viewer è stato riscritto su Vue 3.

Il punto è capire cosa finisce dove. I pacchetti grezzi restano su disco come file PCAP sul nodo di cattura; in Elasticsearch va solo la SPI (Session Profile Information), cioè i campi estratti per ogni flusso — indirizzi, porte, byte e durata — più i campi applicativi che i parser riescono a riconoscere. La ricerca lavora sull’indice SPI; il PCAP viene recuperato e servito a richiesta dal nodo che lo ha scritto.

Il punto critico: separare PCAP e indice

La documentazione è esplicita su un vincolo facile da sottovalutare in fase di provisioning: la directory dei PCAP (pcapDir) e la directory dati di Elasticsearch non devono stare sullo stesso filesystem. La ragione è operativa. I due percorsi di cancellazione sono indipendenti e seguono logiche diverse.

I file PCAP li cancella il viewer quando serve spazio, in base alle soglie di disco: è una rotazione guidata dalla capienza del volume di cattura. I metadati di sessione, invece, questo meccanismo non li tocca: scadono tramite policy ILM/ISM di Elasticsearch oppure con esecuzioni di db.pl expire schedulate via cron. Le due retention sono scorrelate. Se i due insiemi di dati condividono il filesystem, la pressione sullo spazio dovuta ai PCAP — che crescono molto più in fretta — finisce per interferire con l’indice, e una rotazione PCAP aggressiva mette a rischio proprio il database che dovrebbe sopravvivere ai pacchetti. Tenerli su volumi distinti rende la pianificazione della capacità un calcolo separabile: il dimensionamento del volume PCAP fissa la finestra di retention dei pacchetti, quello dell’indice la finestra di ricercabilità dei metadati. Le due finestre possono e di solito devono essere diverse, perché la SPI di un flusso costa ordini di grandezza meno del suo payload.

Parser e arricchimento

Il valore della SPI dipende da quanti campi i parser estraggono. Arkime include parser per i protocolli applicativi più comuni — HTTP (URI, host, user-agent, codice di risposta), TLS (SNI, emittente e soggetto del certificato, fingerprint), DNS (query, tipo, risposta), oltre a SMB, SSH, SMTP e altri. Questi campi diventano indicizzati e ricercabili dall’interfaccia: si interroga per host.http o per il SNI di una connessione cifrata senza aprire un solo pacchetto.

L’arricchimento esterno passa per WISE (With Intelligence See Everything), il sottosistema che annota le sessioni con dati di terze parti — GeoIP, ASN, liste di reputazione, feed di threat intelligence — caricati da file, Redis o endpoint HTTP. WISE non aggiunge capacità di cattura: arricchisce i metadati già indicizzati, così che una ricerca possa filtrare, per esempio, le sessioni verso indirizzi presenti in una lista.

L’integrazione tipica con un IDS segue la stessa logica: gli alert (per esempio da Suricata) si correlano alle sessioni corrispondenti nell’indice, così da passare dall’alert al PCAP completo del flusso che lo ha generato. È esattamente il caso d’uso che giustifica la fPCAP: l’alert dice che qualcosa è successo, il pacchetto dice cosa.

Limiti

Il modello scala in orizzontale aggiungendo nodi di cattura su un cluster Elasticsearch comune, ma con tre vincoli da dimensionare a priori. Il primo è lo storage PCAP, lineare nel throughput e nella retention: gli 11 TB/giorno per Gbps citati sopra fissano un tetto pratico alla finestra retrospettiva. Il secondo è il cluster Elasticsearch, che deve reggere il tasso di inserimento delle sessioni e il volume di ricerche: la finestra utile dei metadati la limita la capacità dell’indice, non quella dei PCAP. Il terzo è il vincolo del 5-tuple sullo stesso processo, che condiziona la parallelizzazione e il bilanciamento sulle interfacce di cattura.

Resta poi un limite intrinseco alla fPCAP che nessuna architettura risolve: il traffico cifrato resta opaco nel payload. Arkime indicizza i metadati TLS — SNI, certificati — ma non il contenuto applicativo sotto cifratura. La fPCAP conserva ciò che è passato sul filo; cosa significhi, per i flussi cifrati, dipende da quanto i metadati lasciano in chiaro.

Immagine di copertina: Schermata del programma Wireshark con l’analisi di un pacchetto di rete catturato: una query DNS, con i livelli di protocollo… — schermata di Laurachappell, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:Wireshark_Network_Analyzer_Screen.png