La serie 2.4 di Security Onion manda in pensione i tre agenti d’endpoint di prima — Wazuh, i Beats di Elastic e osquery — e li rimpiazza con un solo Elastic Agent, gestito al centro da Fleet. La distribuzione di Network Security Monitoring (NSM) che Doug Burks ha avviato nel 2008 è arrivata alla disponibilità generale della 2.4 con la 2.4.10, il 23 agosto 2023; la 2.4.20, per ora l’ultima della serie, è del 6 ottobre 2023.

Contesto

Security Onion mette in un unico installer gli strumenti Open Source di riferimento per l’analisi di rete, la gestione dei log e l’incident response: Suricata e Zeek per la visibilità di rete, Stenographer per la cattura full-packet, Strelka per l’analisi dei file, lo stack Elastic per indicizzazione e ricerca. Fino alla serie 2.3 i dati di host arrivavano da agenti diversi: Wazuh per il rilevamento sull’host, i Beats (Filebeat su tutti) per il trasporto dei log, osquery per le interrogazioni puntuali sullo stato degli endpoint. Tre agenti, tre cicli di configurazione, tre canali di trasporto, tre modelli di gestione.

La 2.4 rimette mano anche al sistema sottostante. La base passa da CentOS 7 a Oracle Linux 9, e dietro la scelta c’è la fine del supporto di CentOS 7, fissata al 30 giugno 2024. Grafana sparisce dal cruscotto di stato: le metriche di salute finiscono in InfluxDB, che la console web interroga direttamente.

Architettura

Il modello di deployment resta su tre profili — Evaluation (tutto su un nodo, per il laboratorio), Standalone (manager e sensor sullo stesso host), Distributed (una grid con ruoli separati). Nel profilo distribuito i ruoli sono: il manager (console web, Kibana, gestione del cluster Elasticsearch, code Redis, Logstash); i search node, che pescano dalla coda Redis e indicizzano in Elasticsearch; i sensor, dove Suricata e Zeek generano gli eventi e li inoltrano; gli heavy node, un cluster Elasticsearch a sé con capacità di sensor a bordo; i receiver node, con Logstash e Redis per alleggerire il manager e ripartire il carico in active-active; e i nodi Intrusion Detection Honeypot (IDH), che simulano servizi comuni e segnalano qualunque interazione.

L’orchestrazione passa per Salt: so-setup assegna i ruoli ai nodi e Salt distribuisce stati e configurazioni. I servizi girano in container Docker, quindi aggiornare un componente vuol dire promuovere una nuova immagine sotto il controllo degli stati Salt, non ricompilare pacchetti su ogni singolo host.

Il cambiamento che pesa

Sostituire i tre agenti con un solo Elastic Agent gestito da Fleet è la modifica che si sente di più nell’uso quotidiano. Elastic Agent è un binario unico che assorbe quello che prima facevano i Beats e osquery, e con l’integrazione Elastic Defend aggiunge la raccolta degli eventi di endpoint e le query live, sempre tramite Fleet. Chi manda avanti una grid distribuita se ne accorge subito: una sola identità d’agente per host, una sola policy gestita al centro, un solo canale verso il manager. Non si configura più agente per agente, si assegnano policy da Fleet.

Il prezzo del consolidamento è il legame a un solo fornitore di agenti. Wazuh si portava dietro regole di rilevamento sull’host e un File Integrity Monitoring suoi, con un formato di alert proprio e una base di firme costruita in anni. Spostare quei dati su Elastic Agent e sulle integrazioni Elastic vuol dire riallineare le regole al modello dati Elastic Common Schema (ECS) e ai pacchetti d’integrazione di Fleet. Il detection content scritto per Wazuh non passa da sé al nuovo agente: o lo riporti a mano, o te lo tieni a parte.

Licenze

La 2.4 stringe la dipendenza dai componenti Elastic, e la licenza di quei componenti non è approvata OSI. Dalla 7.11 (febbraio 2021) Elasticsearch e Kibana non stanno più sotto Apache 2.0: escono in doppia licenza, Elastic License 2.0 e Server Side Public License (SSPL), e la Open Source Initiative non riconosce né l’una né l’altra come Open Source. Elastic Agent ed Elastic Defend rientrano nello stesso quadro. La Elastic License 2.0 in particolare vieta di offrire il software come servizio gestito a terzi e di aggirarne le chiavi di licenza.

Per quasi tutti gli usi interni — un SOC, un CERT, un laboratorio universitario — il vincolo non pesa: lo stack gira per il tuo monitoraggio e basta. Diventa un problema per chi vuole rivendere Security Onion o gestirlo come servizio per conto di terzi, e lì la clausola della Elastic License 2.0 va letta con attenzione. Il resto della distribuzione tiene insieme un mosaico di licenze: Suricata e Zeek sotto licenze permissive e GPL, Strelka sotto Apache 2.0, gli script di Security Onion sotto Apache 2.0 o licenze vicine, mentre TheHive e Cortex — quando li agganci al flusso di case management — stanno sotto AGPLv3.

Limiti

La 2.4 alza l’asticella dei requisiti: Oracle Linux 9 e lo stack Elastic 8 in container chiedono più RAM e più disco di quanto bastasse in 2.3, e per chi monta un’installazione Evaluation su una macchina di laboratorio modesta è un dettaglio concreto. Non c’è un upgrade in-place indolore dalla 2.3 alla 2.4 valido per ogni configurazione: con il consolidamento dell’agente e il cambio di sistema operativo di base, spesso conviene reinstallare da zero e riportare gli endpoint sotto Fleet piuttosto che migrare sul posto. Una nota sui numeri di versione citati qui: fotografano la situazione al 6 ottobre 2023, e la serie 2.4 prosegue per punti successivi, con aggiornamenti ai componenti di rete e correzioni che cambiano i dettagli sopra.

Immagine di copertina: Desktop di Security Onion con il logo della distribuzione al centro su sfondo blu scuro, icone Home e Cestino e barra dei menu… — logo di Skarz, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:Security_Onion_Desktop.png