Automatizzare LogOS con Dr. WOLF

Prima di scoprire come automatizzare l’installazione e aggiornamento di LogOS con Dr.WOLF,  vediamo in dettaglio di cosa si tratta. LogOS SIEM è una soluzione offerta da Seacom in ambito Security, che permette di raccogliere e visualizzare le informazioni utili al fine di comprendere lo stato di salute dei sistemi informativi. Partendo dai log prelevati dalle macchine ed utilizzando tecnologie dedicate, è possibile capire se i sistemi possono considerarsi sicuri, oppure se sono affetti da qualche vulnerabilità. Inoltre, questa soluzione consente di conoscere anche lo stato delle macchine non solo dal punto di vista della sicurezza ma anche delle componenti hardware.

Questa soluzione prevede l’integrazione di diverse tecnologie che a seconda dello use case possono variare:

• Wazuh: piattaforma di sicurezza opensource che permette di unificare la protezione XDR e SIEM;
• Filebeat: agent che permette di inviare log verso le destinazioni desiderate;
• Kafka: piattaforma di streaming di eventi in tempo reale;
• Logstash: componente che permette di processare e movimentare dati da e verso diverse sorgenti e destinazioni;
• Opensearch: piattaforma opensource che permette di effettuare ricerche, observability e ML sui dati in maniera efficiente.

Wazuh

Come si evince dall’immagine, la soluzione si basa su Wazuh, che tramite gli agent reperisce dagli host target le informazioni di sicurezza utili per alimentare il Wazuh server. I dati presenti nelle opportune cartelle degli host di Wazuh, contenenti i log con le informazioni arricchite da Wazuh stesso, sono prelevati da Filebeat ed inseriti su opportuni topic Kafka. A questo punto, un Logstash è in ascolto sui topic Kafka e si occupa di indicizzare i log su Opensearch, da cui saranno visibili i dati tramite Opensearch Dashboards.

In contesti di produzione in cui le performance, la sicurezza, l’affidabilità e la resilienza degli applicativi sono fondamentali, essi vengono installati in cluster. Solitamente, per questo genere di soluzione, il cliente decide di effettuare installazioni on-premise, per cui è possibile che una singola installazione di LogOS possa prevedere decine di macchine dedicate.

In questi contesti, dunque, installare, manutenere ed aggiornare gli applicativi in decine di macchine può risultare molto oneroso. Abbiamo quindi deciso di automatizzare LogOS con Dr.WOLF.

Automatizzare LogOS con Dr. WOLF

Dr. WOLF (Wazuh Opensearch Logstash Filebeat) nasce quindi dall’esigenza di automatizzare l’installazione e aggiornamento delle componenti, utilizzando GitLab e Ansible.

GitLab è un repository open source che permette di collaborare allo sviluppo di software ed abilita alle funzionalità DevOps e di Intelligenza Artificiale. Nel nostro caso abbiamo utilizzato GitLab sia per mantenere il codice utile al funzionamento della soluzione, sia per orchestrare la pipeline CI/CD con la quale effettuare l’installazione delle componenti. Inoltre, sfruttando proprio la pipeline CI/CD è possibile mantenere la storia di tutte le operazioni effettuate, in modo tale da poter effettuare rapidamente anche un rollback ad una versione precedente in caso di eventuali problemi.

Ansible è un tool open source che permette di automatizzare l’installazione, configurazione, gestione e orchestrazione dei processi. Dato che è uno standard de facto, vista la compatibilità con GitLab e data l’esistenza di ruoli ufficiali già presenti, abbiamo deciso di utilizzare questa tecnologia nella nostra soluzione. Per il funzionamento di Ansible è necessario fornire contestualmente al playbook da eseguire anche un inventario nel quale vengono fornite indicazioni riguardo le macchine target da contattare ed eventuali variabili necessarie al funzionamento del playbook stesso.

Dr. WOLF, dunque, è una repository GitLab contenente una pipeline CI/CD divisa in diversi stage, l’ultimo dei quali utilizza comandi Ansible per installare le componenti desiderate.

 

Fasi del flusso

La pipeline sarà divisa come segue:

Dall’immagine sopra, possiamo notare le fasi principali nelle quali si divide il flusso:

• Clone: fase in cui vengono clonate le repository delle componenti che vogliamo installare;
• Ssh-key: fase in cui viene controllato se l’utente utilizza una chiave SSH per il dialogo con Ansible oppure se utilizza una password;
• Generate: fase in cui viene generato l’inventario padre che verrà poi utilizzato per popolare gli inventari figli delle singole componenti;
• Check: fase in cui vengono effettuati alcuni controlli base a seconda della componente (ad esempio controlli firewall e sui dischi montati per ospitare i dati applicativi);
• Setup: fase in cui vengono popolati gli inventari figli per le singole componenti a partire dall’inventario padre;
• Deploy: fase in cui l’utente sceglie quale componente installare.

Nel prossimo paragrafo dettaglieremo meglio ciascuno degli step della pipeline.

Pipeline

Inclusione componenti

Questo task di inclusione avviene prima dell’esecuzione dei singoli stage. Al fine di installare le componenti volute, è necessario includere nella pipeline di Dr. WOLF anche i riferimenti delle pipeline delle singole componenti.

Questo step è necessario affinché possano essere eseguiti gli stage mancanti nella definizione della pipeline di Dr. WOLF. Oltre alla inclusione di tutte le pipeline delle componenti desiderate, dovremmo poi effettuare il clone di tutte le repository degli applicativi utilizzati, come vedremo in seguito.

Clone

Questo stage è necessario per includere in Dr. WOLF tutte le repository delle componenti che vogliamo installare, dato che esse contengono sia i vari ruoli Ansible sia altre informazioni utili come ad esempio i check che sono stati definiti per ciascuna di esse.

Check esistenza chiave ssh

Questo stage si occupa di verificare se l’utente ha specificato tra le variabili l’utilizzo della chiave ssh o meno. Nel caso in cui non fosse definita, o fosse vuota, allora questo stage viene ignorato e non viene affatto eseguito a livello di pipeline, utilizzando quindi i soli username e password forniti per accedere alle macchine in ssh.

Generate

Questo stage si occupa della creazione dell’inventario padre contenente tutte le informazioni che abbiamo passato come variabili CI/CD. Il compito della generazione dell’inventario padre è demandata ad uno script python. In questo step, è presente anche un pre-task che si occupa di inizializzare la chiave SSH con cui accedere alle macchine.

Check

Questo stage non è presente nella definizione della pipeline di Dr. WOLF. Questo vuol dire che ogni singola pipeline che abbiamo incluso, procederà alla esecuzione dei propri check definiti nelle proprie pipeline, se presenti. I check saranno comunque consistenti dato che prenderanno in considerazione gli inventari padre generati precedentemente. Ogni componente, dunque, effettuerà i propri check.

Setup

Questo stage si occupa di eseguire tutti i playbook ansible presenti al fine di creare l’inventario figlio e riempire il file /etc/hosts delle macchine con gli hostname e ip di tutte le componenti.

Deploy

Questo stage non è presente nella definizione della pipeline di Dr. WOLF. Questo comporta il fatto che verranno prelevati tutti gli stage deploy presenti nella pipeline delle singole componenti. Per questo motivo, sarà possibile eseguire manualmente le singole componenti utilizzando questo stage. Verranno eseguiti i playbook corrispondenti agli applicativi che vogliamo includere, allo stesso modo di come si farebbe eseguendo le pipeline delle singole componenti separatamente.

Considerazioni generali

Divide et impera

Dato che l’esigenza era quella di gestire diversi applicativi per poterli integrare tra loro, anziché gestirli tutti in una unica grande repository abbiamo pensato di dividerli ognuno in una propria repository dedicata e lasciare che Dr. WOLF si occupasse solo di mettere assieme i pezzi mancanti agendo da orchestratore, per poter concludere l’integrazione di tutte le componenti.

In questo modo possiamo anche decidere di utilizzare le repository delle singole componenti per poter effettuare installazioni mirate.

Ad esempio, possiamo notare come la pipeline di Opensearch riesca ad effettuare tutte le operazioni necessarie al fine di installare l’applicativo:

Variabili GitLab CI/CD

Oltre che come orchestratore dei vari flussi, GitLab è fondamentale per la gestione automatizzata dell’inventatario, effettuata tramite variabili CI/CD. Infatti, tramite la corretta compilazione delle variabili è possibile automatizzare la creazione dell’inventario padre, contenente tutte le informazioni utili per il deploy degli applicativi, ad esempio gli host sui quali installare i nodi data di Opensearch piuttosto che lo username e la password per l’utente admin di Wazuh.

L’inventario padre, dunque, racchiude tutte le informazioni utili all’installazione ed è grazie ad esso che è possibile generare i singoli inventari figli che possiamo utilizzare per eseguire i playbook Ansible. L’esigenza di dividere tra inventario padre ed inventari figli era anche quella di poter utilizzare il più possibile notazioni fedeli a quelle consigliate dai ruoli Ansible dei singoli applicativi, adattando la nostra soluzione a quelle dei ruoli ufficiale piuttosto che il contrario, minimizzando le modifiche agli stessi.

Stage di management

Per alcune delle singole componenti abbiamo integrato anche dei playbook Ansible che permettano operazioni di management degli applicativi. Ad esempio, per Kafka, abbiamo ideato un ruolo con il quale è possibile creare topic specificando il numero di partizioni e repliche, eliminare topic ed effettuare una stampa dei topic presenti, sempre utilizzando le variabili CI/CD e sempre utilizzando GitLab e Ansible, in modo da tenere traccia delle configurazione effettuate e da poterle eseguire da un singolo punto di accesso, senza l’esigenza di entrare sul terminale delle macchine.

Ruoli Ansible dei singoli applicativi

Tutto il flusso funziona in maniera automatica dopo aver studiato attentamente i ruoli ansible ufficiali dei singloli applicativi, facendo in modo che l’inventario figlio contenesse tutte le informazioni di cui ha bisogno per essere eseguito correttamente. Abbiamo anche messo a punto un sistema di versionamento, tale per cui la versione 1.0.0 di Dr. WOLF è composta dalle seguenti versioni degli applicativi:

 

Applicativo	Versione	Versione Dr. WOLF
Confluent Kafka	7.6.1	1.0.0
Opensearch	2.8.0	1.0.0
Wazuh	4.7.4	1.0.0
Logstash	7.10.2	1.0.0
Filebeat	7.10.2	1.0.0

 

Conclusione

Dr. WOLF è una soluzione che permette di installare e aggiornare diversi applicativi che si integrano tra loro, in particolare per la soluzione LogOS, utilizzando GitLab e Ansible. La svolta di questa soluzione è che possiamo gestire l’installazione e l’aggiornamento anche delle singole componenti qualora si rendesse necessario, senza intaccare in alcun modo il funzionamento generale di Dr. WOLF. Potremmo quindi velocizzare l’installazione delle componenti necessarie alla soluzione LogOS con Dr. WOLF, centralizzandone la gestione e mantenendo anche una storia delle azioni compiute, in modo da poter reagire in maniera reattiva ad eventuali problematiche. Oltre a questo, è possibile integrare tra loro non solo le componenti che formano LogOS, ma anche altre tecnologie. Infatti, è in fase di sviluppo anche l’integrazione tra MinIO e Dremio per la nostra proposizione Data Lakehouse, seguendo gli stessi procedimenti descritti nel corso dell’articolo.