Centro Assistenza ACSIA

ACSIA XDR Plus Guida all'installazione e all'amministrazione dell'utente - v5.0.0 e successive

Maide UYGUR
Maide UYGUR
  • Aggiornato

Questa guida si applica solo ad ACSIA XDR Plus versione 5.0.0 e successive

 

1. Introduzione

Il server può essere distribuito in un ambiente fisico o virtuale. Questa guida ti mostrerà i prerequisiti per l'installazione di ACSIA, i dettagli dell'installazione e della configurazione del prodotto, l'amministrazione, la risoluzione dei problemi di deployment e le domande frequenti.

 


 

2. Cos'è ACSIA XDR Plus?

ACSIA è un'applicazione automatizzata di intelligence sulla sicurezza informatica che consente alle organizzazioni di proteggersi da attacchi dannosi e entità non autorizzate che prendono di mira i propri dati.

 


3. Installazione e configurazione

Come qualsiasi altra applicazione software, ACSIA ha bisogno di alcuni requisiti preliminari per comunicare con i clienti connessi e svolgere i suoi compiti.

 

3.1.Prerequisiti

3.1.1. Requisiti minimi

La piattaforma ACSIA Server richiede le seguenti specifiche minime:

  • Il server può essere distribuito in un ambiente fisico o virtuale
  • Nel caso di un ambiente virtuale, il server avrà bisogno di una Macchina Virtuale, e potrà funzionare su qualsiasi hypervisor scelto (VMWare, HyperV, VirtualBox, Proxmox, ecc...) ma non su container (Docker, Kubernetes, LXD, LXC, Vagabondo, ecc...)
  • È possibile utilizzare una qualsiasi delle seguenti distribuzioni Linux: è preferibile Ubuntu 20.04
  • 16GB RAM (negli ambienti virtuali, devono essere dedicati)

  • 8 vCPU

  • 200 GB SSD Storage (come minimo a seconda della politica di conservazione dei log)

  • Connettività di rete (per scaricare e installare il server, ricevere i nostri feed di intelligence sulle minacce, connettersi con i client, aggiornare il sistema e verificare la licenza)
  • Partizionamento: non è richiesto un partizionamento specifico per ACSIA VM; tuttavia, quando ACSIA è ospitato in locale (al di fuori delle piattaforme cloud), si consiglia vivamente di configurare una partizione LVM in modo che lo spazio di archiviazione possa essere facilmente esteso

La specifica precedente supporterebbe un carico di lavoro standard tipico di oltre 100 host monitorati. ACSIA scala in modo relativamente lineare, quindi risorse aggiuntive supporteranno ambienti client più grandi.

ACSIA Client (con l'agente) richiede le seguenti specifiche minime:

  • L'agente può essere distribuito su tutti i sistemi operativi (anche nelle macchine virtuali), ma consigliamo vivamente di utilizzare sistemi aggiornati e che il nostro supporto può essere limitato su sistemi operativi che non sono ufficialmente supportati dai fornitori.
  • Al momento, non abbiamo requisiti minimi per CPU, RAM e Storage perché i nostri agenti sono estremamente leggeri in termini di consumo di hardware. Suggeriamo di eseguire l'installazione su una macchina con almeno 2GB di spazio libero
  • Per i sistemi Linux, abbiamo bisogno almeno di un kernel dalla versione 2.6 e successive
  • Connettività di rete verso ACSIA Server (come di seguito specificato)

 

3.1.2. Interfaccia utente Web porte di rete

Per accedere all'interfaccia utente Web di ACSIA, dovrai aprire le seguenti porte tra la tua workstation (Laptop/Desktop/PC) e il server ACSIA:

 

Sorgente Destinazione Protocollo Porta Note
Qualsiasi PC che gestisce ACSIA IP del server ACSIA TCP 443
Usato per HTTPS
IP del server ACSIA license.acsia.io TCP 5150
Attivazione della licenza

 

L'unica richiesta di ACSIA prima e dopo l'installazione è la connettività abilitata per TLS alla porta 5150 (TCP) su license.acsia.io. Questa connettività è sempre richiesta (verifica della coppia di chiavi privata e pubblica per la licenza), sebbene ACSIA consenta fino a 48 ore di perdita di connessione prima che entri in uno stato senza licenza. L'unica eccezione a questo requisito è dove ACSIA viene distribuito da  Amazon AWS Marketplace.

Inoltre, ACSIA richiede l'accesso a Internet durante l'installazione per gli aggiornamenti, i feed di informazioni sulle minacce e gli aggiornamenti delle licenze.

 

3.1.3. Porte client-server ACSIA con installazione dell'agente

Se si sceglie di configurare l'agente ACSIA sui client (server o workstation), l'unico requisito affinché l'agente possa comunicare con il server ACSIA è la porta TCP 443 (HTTPS) e 444 (TCP/UDP). Se queste porte non sono aperte, assicurarsi che siano aperte. 

 

Sorgente Destinazione Protocollo Porta Note
Qualsiasi host con l'agente ACSIA IP del server ACSIA TCP 443 Utilizzato per le connessioni
Qualsiasi host con l'agente ACSIA IP del server ACSIA TCP & UDP 444 Used per i pull
Qualsiasi host con l'agente ACSIA wimi.xdrplus.com TCP 443 Used per il pull dell'IP

 

3.1.4. Configurazione agentless delle porte client-server di ACSIA

Il server ACSIA comunica con i client attraverso le seguenti porte; pertanto, se si sceglie l'implementazione agentless, è necessario abilitare le seguenti regole del firewall:

 

Sorgente Destinazione Protocollo Porta Note
Qualsiasi host con l'agente ACSIA IP del server ACSIA TCP 1515 Utilizzato per le connessioni
Qualsiasi host con l'agente ACSIA IP del server ACSIA UDP 1514 Utilizzato per le connessioni
Qualsiasi host con l'agente ACSIA IP del server ACSIA TCP 5044 Utilizzato per le connessioni
IP del server ACSIA Qualsiasi host Windows TCP 5986 Usato per i Push
IP del server ACSIA Qualsiasi host Linux TCP 22 Usato per i Push

 

3.1.5. Configurazione del Proxy ACSIA - Solo se si dispone di Proxy

Se avete un proxy e i vostri server (ACSIA VM e il vostro server da monitorare) per uscire su Internet, applicate le seguenti istruzioni.

 

3.1.5.1 Impostazione del Proxy in modo permanente per tutti gli utenti

Per impostare in modo permanente l'accesso proxy per tutti gli utenti, è necessario modificare il file /etc/environment .

 

Step 1 - Per prima cosa, aprire il file in un editor di testo:

sudo nano /etc/environment

Step 2 - Quindi, aggiornate il file con le stesse informazioni aggiunte al file .bashrc nello scenario precedente:

export HTTP_PROXY="[username]:[password]@[proxy-web-or-IP-address]:[port-number]"
export HTTPS_PROXY="[username]:[password]@[proxy-web-or-IP-address]:[port-number]"
export FTP_PROXY="[username]:[password]@ [proxy-web-or-IP-address]:[port-number]"
...
export NO_PROXY="localhost,127.0.0.1,::1"

Step 3 - Salvare il file e uscire. Le modifiche verranno applicate all'accesso successivo.

 

3.1.5.2 Impostazione del proxy per APT

Su alcuni sistemi, la command-line APT necessita di una configurazione proxy separata, perché non utilizza le variabili d'ambiente del sistema.

Step 1 - Per definire le impostazioni del proxy per APT, creare o modificare (se esiste già) un file chiamato apt.conf nella directory /etc/apt :

sudo nano /etc/apt/apt.conf 

Step 2 - Aggiungere le seguenti righe al file:

Acquire::http::Proxy "http://[username]:[password]@ [proxy-web-or-IP-address]:[port-number]";
Acquire::https::Proxy "http://[username]:[password]@ [proxy-web-or-IP-address]:[port-number]";

Step 3 - Salvare il file e uscire. La configurazione verrà applicata dopo un riavvio.

 

Nell'opzione NO_PROXY, oltre ai parametri specificati sopra, è necessario aggiungere le reti e le sottoreti interne in cui si trovano i dispositivi monitorati (la rete dei server o dei PC). In caso contrario, si verificheranno problemi di connettività tra ACSIA e tali reti quando si cercherà di aggiungerle ai servizi monitorati da ACSIA. È infatti improbabile che il proxy riesca a raggiungere tali reti.

 

Qualsiasi modifica che riguardi le variabili di cui sopra deve essere comunicata ad ACSIA tramite il comando configureHttpProxy seguito da acsia_restart (questo è per quando l'installazione di ACSIA è già stata completata).

 

3.2. Installazione del Server ACSIA

Preparare una macchina virtuale Linux (ad esempio, Ubuntu 20.04 è attualmente supportato, controllare le note di rilascio di ACSIA) per ospitare il server ACSIA e assicurarsi che il sistema sia aggiornato.

Una volta soddisfatti tutti i prerequisiti, l'installazione di ACSIA può iniziare. Se i requisiti per l'installazione non sono soddisfatti, l'installazione fallirà e verrà fornita una spiegazione dei prerequisiti non soddisfatti.

I clienti con una licenza ACSIA valida riceveranno dal team di supporto 4Securitas un pacchetto di installazione per scaricare lo script di installazione principale acsia_prepare e un file aggiuntivo contenente le credenziali, compresa la licenza.

Seguire scrupolosamente le istruzioni fornite in questa guida per installare la configurazione server-client di ACSIA.

 

3.2.1. Guida all'installazione del server ACSIA

Effettuare il login nella nuova macchina virtuale per il server ACSIA, passare all'utente root , copiare acsia_prepare e le credentials.txt che vi sono state fornite.
Esegui acsia_prepare come segue, assicurarsi che lo script sia eseguibile utilizzando il comando:
chmod +x acsia_prepare
e poi eseguire:
./acsia_prepare

 

Seguite le istruzioni fornite sullo schermo e, al termine, eseguite quanto segue:

 

./acsia_app/bin/acsia_install

 

Se tutti i requisiti preliminari sono soddisfatti secondo le linee guida, il server ACSIA sarà completamente installato in circa 5-6 minuti.

In caso di problemi, consultare la sezione Risoluzione dei problemi di questa guida, consultare le nostre guide avanzate alla risoluzione dei problemi nella nostra Knowledge Base o contattare il nostro team di supporto inviando un ticket da questo portale. Quando si richiede assistenza, si prega di fornire il maggior numero di informazioni possibili (ad esempio, screenshot, registri, ecc.); ogni dettaglio ci aiuterà a risolvere più rapidamente il problema.

Al termine del processo di installazione, dovreste avere sul vostro terminale le credenziali per il primo utente amministratore per accedere all'interfaccia web, qualcosa di simile a quanto segue:

ACSIA web and Dashboards
Admin interface: https://192.168.1.246:443
Username: admin@acsia.io
Password: kzuh21ybnsdy1=ui12b5!2iutRIf123kjojb

Una volta terminata l'installazione del server, l'installazione del client continuerà in background (il server ACSIA diventa il primo client da monitorare). Attendere l'inizializzazione del motore al termine dell'installazione del client.

 

Si consiglia vivamente di cambiare al più presto le password generate con altre nuove e di conservarle correttamente.

Per controllare lo stato di avanzamento dell'inizializzazione di ACSIA, eseguire:

acsia_tail_f

Se si riceve l'errore acsia_tail_f: command not found significa che non si sta utilizzando l'utente corretto, quindi eseguire:

sudo su - acsia

Questo cambierà il vostro account in quello di acsia, permettendovi di eseguire tutti i comandi necessari.

 

Al termine dell'installazione del client, dovrebbe essere visualizzato il seguente messaggio in acsia_tail_f:

2022-07-10 15:52:21.254 INFO 29440 --- [main] com.forsecuritas.AcsiaLauncher : *************** SPRING APPLICATION RUNNING *************************

Il messaggio sopra riportato indica che il motore è pronto e funzionante. Ora è possibile accedere all'interfaccia web con le credenziali fornite e attivare la licenza subito dopo l'accesso.

acsia-tail-f.gif

Al termine dell'installazione, è strettamente necessario avere a disposizione tutti i comandi di servizio di ACSIA per uscire dalla sessione in esecuzione e rientrare, in modo che le variabili d'ambiente possano essere tutte caricate.

 


 

4. Comandi di servizio ACSIA

Come già menzionato, tutti i comandi di servizio di ACSIA, compresi i servizi di avvio/arresto e i suggerimenti per la risoluzione dei problemi, si trovano nella cartella /acsia_app/bin in $ACSIA_HOME.

 

Di seguito sono riportati alcuni comandi di servizio utilizzati di frequente.

 

Per controllare che tutti i servizi ACSIA siano in esecuzione:
acsia_stack_status
 
Per avviare tutti i servizi ACSIA:
acsia_stack_start
 
Per arrestare tutti i servizi ACSIA:
acsia_stack_stop
 
Per far partire solo il motore ACSIA:
acsia_start

 

4.1. Elenco completo dei comandi di servizio

È possibile trovare tutti i comandi di servizio disponibili di ACSIA all'indirizzo /home/acsia/acsia_app/bin.

Di seguito è riportata una tabella contenente tutti i comandi con le relative descrizioni:

Comando Descrizione
acsia_adapter_beanstalk.py Adattatore AWS Elasticbeanstalk per ACSIA
acsia_adapter_ips.sh Adattatore per componenti IPS per AWS elasticbeanstalk
acsia_admin_check_requirements.sh Controlla i prerequisiti ACSIA
acsia_admin_docker_subnet Cambia la subnet di docker
acsia_admin_health.sh Controlla lo stato di salute di ACSIA
acsia_admin_logs Mostra i log dei componenti ACSIA
acsia_admin_query Esegui la query del DB MySQL
acsia_admin_reset_password Recupera il link delle credenziali utente ACSIA da resettare
acsia_admin_unlock_indices Sblocca gli indici se il disco ACSIA è saturo per mancanza di spazio
acsia_ban_script Banna un indirizzo IP
acsia_beanstalk_ban Banna l'IP tramite AWS Elasticbeanstalk
acsia_beanstalk_find_banned_ip_rule Elenca o trova gli indirizzi IP bannati in AWS Elasticbeanstalk
acsia_beanstalk_manage_service Gestisci i servizi e la configurazione di ACSIA in AWS Elasticbeanstalk
acsia_beanstalk_unban Rimuovi il ban per un indirizzo IP in AWS Elasticbeanstalk
acsia_change_ip Modifica l'indirizzo IP del server ACSIA
acsia_deploy_ssl_certs Installa il certificato SSL/TLS sul server ACSIA se è stato assegnato un sottodominio
acsia_download Scarica il pacchetto ACSIA per l'installazione (obsoleto nella v4)
acsia_elastic_restart Riavvia Elasticsearch
acsia_elastic_start Avvia Elasticsearch
acsia_elastic_status Controlla lo stato di Elasticsearch
acsia_elastic_stop Arresta Elasticsearch
acsia_elastic_tail_f Controlla i log di Elasticsearch
acsia_export_logs Esporta i log di ACSIA
acsia_fix_kernel_inspector_wrong_version Correggi la versione errata del kernel
acsia_install Installa ACSIA
acsia_ip Recupera l'indirizzo IP del server ACSIA
install_acm_app.sh Installa il modulo ACM quando fallisce durante la configurazione dei client
acsia_normal_ban Banna un indirizzo IP
acsia_normal_manage_service Configura e gestisci i servizi
acsia_normal_unban Togli il ban da un indirizzo IP
acsia_reconfigure_acm Riconfigura il modulo ACM per il client ACSIA per un IP specifico
acsia_reconfigure_acm_all Riconfigura il modulo ACM per ACSIA per tutti i client collegati.
acsia_report Genera ed esporta i rapporti sugli incidenti per l'ACSIA.
acsia_restart Riavvia solo il motore ACSIA
acsia_set_private_ip Assegna un indirizzo IP privato al server ACSIA
acsia_stack_restart Riavvia tutti gli stack con tutti i componenti, compreso il motore.
acsia_stack_start Avvia tutti gli stack con tutti i componenti, compreso il motore
acsia_stack_status Controlla lo stato di tutti gli stack con tutti i componenti, compreso il motore
acsia_stack_stop Arresta gli stack con tutti i componenti, compreso il motore
acsia_start_bg Avvia ACSIA in background
acsia_status Mostra lo stato ACSIA
acsia_stop Arresta solo il motore ACSIA
acsia_tail_f Mostra i log ACSIA in tempo reale
acsia_unban_script Togli il ban da un indirizzo IP 
acsia_uninstall Disinstalla ACSIA
acsia_update Aggiorna ACSIA
admin_insert_admin_user Aggiungi un utente admin per ACSIA
install_falco Installa il modulo kernel Falco
kibana_default_index Ripristina gli indici predefiniti di Kibana
kibana_import_saved_objects Importa gli oggetti salvati, personalizzazione su Kibana
mfa_acsia_install Attiva e abilita 2FA/MFA
mfa_acsia_uninstall Disattiva 2FA/MFA
mfa_ssh_install Attiva 2FA/MFA per il login SSH come utente acsia sul server
mfa_ssh_qrcode Genera o mostra il codice QR SSH per 2FA/MFA
mfa_ssh_uninstall Disattiva SSH 2FA/MFA
setInternalIP Imposta l'IP interno per il server ACSIA
ssl_configuration Controlla e configura SSL/TLS
winrm_remote Controlla Ansible WinRM per i client Windows
Il prodotto ACSIA XDR Plus ha un'architettura modulare costruita con diversi strumenti open-source. Raramente saranno necessari diversi script di servizio per ciascun componente (a meno che non si verifichino problemi). Gli script di servizio mostrati sopra dovrebbero essere sufficienti per la maggior parte di coloro che hanno bisogno di eseguire la risoluzione dei problemi su ACSIA.

 


 

5. Configurazione e abilitazione dell'invio di e-mail da parte di ACSIA

 

Affinché ACSIA possa inviare notifiche via e-mail, compresa l'e-mail per l'impostazione dell'account di amministrazione, è necessario che sia in grado di comunicare con il proprio server di posta. A tal fine, le e-mail provenienti dal server ACSIA devono essere inserite nella white-list del server di posta e dei filtri antispam (se ne avete uno), ecc.

Se non si inseriscono nella white-list le e-mail provenienti dal server ACSIA, è probabile che vengano rimbalzate o inserite nella cartella spam (questo perché l'e-mail proviene da un server e non da un vero account di posta elettronica), quindi se non si ricevono e-mail provare a seguire le seguenti linee guida o controllare la sezione Risoluzione dei problemi di questa guida.

Se gli utenti hanno problemi a ricevere le e-mail di creazione dell'account, l'amministratore può eseguire il comando acsia_admin_reset_password per recuperare il link che consente di reimpostare le proprie credenziali.

5.1. Impostare e configurare un account e-mail reale come mittente

È possibile utilizzare un account di posta elettronica autentico (ad esempio, e-mail aziendale, Gmail privato, Yahoo, ecc.) e impostarlo come mittente per ricevere le notifiche via e-mail (questo eviterà che le notifiche di ACSIA vengano respinte o inserite nei filtri antispam) senza problemi.


Per impostare e configurare un account di posta elettronica su ACSIA, accedere alla sezione Settings→Email e aggiungere i dati del proprio account di posta elettronica.


step7.gif

 


 

6. Configurazione del certificato SSL per l'applicativo Web ACSIA

Per impostazione predefinita, ACSIA genera certificati SSL autofirmati per la navigazione sicura. I certificati autofirmati sono configurati utilizzando gli indirizzi IP di ACSIA (esterni o locali, se forniti). Se si desidera configurare ACSIA con una CA adeguata e avere un proprio certificato SSL, è possibile farlo durante l'installazione di ACSIA o in una fase successiva. ACSIA richiede che il certificato e la chiave siano forniti in due file: la chiave privata e il certificato pubblico (entrambi in formato .pem).

  1. Configurare il certificato durante l'installazione: durante l'installazione di ACSIA, utilizzando lo script acsia_install aggiungere semplicemente i parametri aggiuntivi: --certificate /path/to/cert.pem--key /path/to/key.pem--domain my.domain.com. Tutti e tre devono essere presenti, altrimenti il programma di installazione mostrerà un errore.
  2. Configurazione post-installazione: è stato fornito un nuovo script acsia_deploy_ssl_certs che accetta gli stessi parametri dello step precedente: --certificate--key, e--domain. Una volta configurato il tutto, sarà necessario eseguire acsia_stack_restart per tutti i componenti, in modo che questi nuovi certificati vengano acquisiti.

Se non volete acquistare certificati SSL, potete utilizzare Let's Encrypt con Certbot; tuttavia, queste istruzioni non sono fornite in questa guida, quindi vi consigliamo di controllare i rispettivi siti web.

 

6.1. Integrazione di Amazon AWS Elastic Beanstalk

ACSIA è dotato della funzione AWS Elastic Beanstalk Integration per monitorare le applicazioni in esecuzione su Elastic Beanstalk.

Se si dispone di applicazioni in esecuzione su Elasticbeanstalk e si desidera che ACSIA le monitorizzi e le protegga, eseguire il seguente comando nel terminale: acsia_adapter_beanstalk.py

Vi verrà richiesto di fornire le seguenti informazioni dal vostro ambiente AWS:

  • ID della chiave di accesso AWS (IAM User)

  • Chiave di accesso segreta AWS (IAM User Secret)

  • Nome della regione predefinita (regione in cui si trova Beanstalk)

  • Formato di output predefinito: (può essere JSON o testo, ma JSON è preferibile)

  • ACL (ID della lista di controllo degli accessi alla rete nella VPC di Beanstalk)

Dopo l'installazione di cui sopra, vi verrà assegnato un indirizzo IP (IP interno/privato). L'indirizzo IP può essere recuperato in seguito eseguendo il comando: acsia_adapter_ip.sh.

 

Accedere alla Console Web UI di ACSIA e aggiungere l'host Linux utilizzando l'indirizzo IP fornito in precedenza. (Getting Started->Start->Linux).

 

L'installazione potrebbe terminare con alcuni avvisi e una configurazione parziale. Non fatevi prendere dal panico; questi avvisi potrebbero non essere gravi e il monitoraggio in genere funzionerà.

 

Assicurarsi di includere il file acsia.config fornito nel pacchetto di avvio dell'applicazione elasticbeanstalk (pacchetto Kickstarter).

 

Dopo aver completato tutti i passaggi sopra descritti, accedere a un nuovo terminale sul server ACSIA e riavviare ACSIA eseguendo il comando acsia_restart . Questo per assicurarsi che ACSIA raccolga tutte le modifiche e i file di configurazione.

 


 

7. Aggiornamento di ACSIA

L'aggiornamento di ACSIA è ragionevolmente semplice e immediato.
Per effettuare l'aggiornamento, tutto ciò che occorre fare è eseguire il seguente comando nel terminale

come user acsia : acsia_update

 

Per ottenere gli aggiornamenti sono necessari il nome utente e la password di ACSIA. Queste credenziali sono solitamente fornite nella stessa e-mail con cui si ricevono le istruzioni per la licenza.

Si consiglia di eseguire gli aggiornamenti ACSIA dal terminale invece di utilizzare la funzione di aggiornamento dell'interfaccia Web. In questo modo si ottiene una maggiore chiarezza e controllo del processo, con informazioni più dettagliate sui codici di errore. Le versioni più importanti di ACSIA includono generalmente aggiornamenti dello strumento principale. Per questo motivo, quando si eseguono questi aggiornamenti, si consiglia di eseguire un arresto e un avvio di tutto lo stack. È possibile farlo eseguendo il comando:  acsia_stack_stop && acsia_stack_start

 

8. Attivazione della licenza

Dopo aver completato l'installazione, si dovrebbe essere in grado di accedere all'applicazione ACSIA tramite un browser web. La prima azione da compiere è l'attivazione della licenza.

 

Se non si attiva la licenza, non si potrà fare nulla perché l'applicazione funzionerà al minimo delle sue capacità o non funzionerà affatto. Per attivare la licenza, copiare il license code fornito e accedere al menu utente (in alto a destra, o è l'indirizzo e-mail o il nome) facendo clic suSettings dal menu e quindi selezionare la scheda "Licenza", dove è possibile aggiungere/attivare la licenza.

step12.gif

La licenza può essere richiesta tramite ticket dal nostro portale di supporto  https://support.4securitas.com o, in caso di problemi di accesso, contattate il supporto via e-mail all'indirizzo support@acsia.io.

 

9. Metodi di autenticazione utilizzati in ACSIA

ACSIA è dotato di diversi meccanismi di autenticazione integrati.
ACSIA dispone di metodi di autenticazione tradizionali come nome utente e password e autenticazione a più fattori (2FA).

 

9.1. Autenticazione a due fattori

ACSIA offre un metodo per l'autenticazione a due fattori che può essere implementato durante e dopo l'installazione per una maggiore sicurezza. L'autenticazione a due fattori (2FA) è disponibile per gli accessi SSH e per l'interfaccia web di ACSIA.

Il 2FA può essere abilitato per tutti gli utenti navigando dall'interfaccia Web a Settings→2FA.

step13.gif

Come si può vedere dall'immagine qui sopra, il tempo di caricamento della pagina di login può richiedere fino a un minuto, quindi si prega di attendere e di non aggiornare la pagina.

 

9.2. Abilitazione di 2FA per SSH dalla riga di comando

Se si desidera applicare la 2FA all'utente acsia è possibile farlo durante l'installazione. Le funzioni 2FA possono essere attivate o disattivate in qualsiasi momento rispettivamente con i comandi mfa_ssh_install emfa_ssh_uninstall . Se abilitato, l'utente acsia del sistema avrà una chiave segreta TOTP (Time-based One-Time Password). Si consiglia di utilizzare strumenti di gestione dei token 2FA come Google Authenticator o FreeOTP. Se questa funzione è abilitata, durante l'installazione viene stampato sullo schermo un codice QR.

Quando è abilitata, è possibile utilizzare solo l'autenticazione basata su chiave (ssh-key) per l'autenticazione della sessione. La password + 2FA non è supportata, poiché provoca effetti collaterali indesiderati.

Al termine dell'installazione o durante l'esecuzione di mfa_ssh_qrcode, il codice QR verrà visualizzato sul terminale e potrà essere scansionato con il gestore di token 2FA preferito.

 

9.3. Abilitazione della 2FA per l'accesso all'interfaccia web di ACSIA dalla linea di comando

Sebbene la 2FA SSH possa essere attivata o disattivata a scelta, si consiglia vivamente di attivare la 2FA per l'interfaccia utente, soprattutto se gli utenti ACSIA accedono all'interfaccia da Internet. Se la 2FA è abilitata per l'accesso alla WebApp, tutti gli utenti riceveranno un codice QR (che dovrà essere scansionato da, ad esempio, Google Authenticator, FreeOTP, ecc.) e dovranno presentare la chiave TOTP ogni volta che accederanno all'applicazione insieme alle credenziali di accesso tradizionali, come nome utente e password.

 

9.4. Accesso alla Dashboard di OpenDashboard e all'autenticazione

Il visualizzatore OpenSearch OpenDashboard fa parte dello stack ACSIA. Per accedere alle applicazioni e alle dashboard OpenSearch, viene richiesta la password utente e l'autenticazione. Gli utenti devono indicare il proprio nome utente/password ACSIA ogni volta che tentano di visualizzare le dashboard. Il nome utente e la password sono generati automaticamente dalle credenziali di accesso all'interfaccia web di ACSIA.

 


 

10. Preparazione dei server per la connessione ad ACSIA

ACSIA supporta i sistemi operativi Linux, Windows e MAC OS.

 

10.1. Requisiti preliminari

Se si intende monitorare i propri sistemi senza utilizzare l'Agente ACSIA (modalità agentless), vi sono alcuni requisiti preliminari, come un account utente di servizio con privilegi amministrativi. Questo utente di servizio può essere un account amministratore locale, un Domain Controller (per i sistemi Windows) o un account LDAP (per i sistemi Linux). Se invece si sceglie la modalità con agente, è sufficiente eseguire l'agente sull'end-point.

 

Se la vostra infrastruttura IT è ospitata su Google Cloud (Metadata Page), potete saltare i passaggi seguenti aggiungendo le chiavi SSH ACSIA al vostro progetto dalla console di Google. AWS ha una configurazione simile che può essere eseguita tramite OpsWorks.

 

10.2. Collegamento di un client Linux

10.2.1. Requisiti

  • Kernel 2.6 o successivo

  • Python 2.7 o successivo

  • Account utente acsia con privilegi Sudo e senza password (solo per agentless)

10.2.2. Distribuzione di ACSIA tramite un agente

Per tutti i client Linux, Windows e MAC OS in cui si è scelto di installare il client con l'agente, è sufficiente navigare nell'interfaccia web di ACSIA Hosts→Add Host, selezionare il sistema operativo, ossia Linux, Windows o MAC, e scegliere Use The Agent dove è possibile scaricarlo.

 

step14.gif

Si tenga presente che gli agenti possono essere scaricati per un solo client, il che significa che lo stesso agente scaricato dall'interfaccia utente non può essere utilizzato per un secondo host. Per ogni host, è necessario scaricare un nuovo agente, perché ogni agente ha il suo token (per motivi di sicurezza). Se si desidera scaricare un agente per più client, è possibile utilizzare la funzione "Bulk Agent Deployment", dove è possibile selezionare il numero di client che si desidera distribuire con il singolo agente.

Copiare l'agente scaricato sul dispositivo client per l'installazione ed eseguirlo come root su Linux/MAC e amministratore su Windows utilizzando PowerShell. Assicurarsi di aggiungere il permesso di esecuzione all'agente per Linux/MAC.

Se tutti i prerequisiti sono presenti dopo l'installazione dell'agente sui client, si vedranno i client elencati automaticamente (popolati) nell'interfaccia utente di ACSIA nella sezione "Hosts".

Gli agenti client si connettono al server ACSIA tramite un'API, senza requisiti di creazione da parte dell'utente o porte multiple da aprire sul firewall (tutte le porte sono consolidate in 2 porte, 443 (TCP) e 444 (UDP/TCP), come richiesto al momento della scelta dell'agente).

Gli agenti ACSIA scaricati dall'interfaccia utente hanno token che scadono dopo sette giorni e ogni download è valido per un solo dispositivo (ciò significa che per ogni dispositivo è necessario scaricare un nuovo agente o scegliere l'opzione di installazione massiva dell'agente se si desidera utilizzare un singolo download per più dispositivi). Se l'agente fornito non funziona, si prega di generare un nuovo agente perché molto probabilmente si tratta di un problema legato alla scadenza del token.

10.2.3. Distribuzione di ACSIA in modalità agentless su sistemi Linux

Se si desidera distribuire ACSIA nei client senza un agente, si consiglia di eseguire i seguenti passaggi a seconda della distribuzione:

 

Per CentOS / RHEL Linux

Creazione dell'utente di servizio ACSIA su sistemi CentOSRHEL 

 

useradd -m -d /home/acsia -c "ACSIA Service User" -G wheel acsia

 

Nel comando precedente, stiamo creando un utente acsia fornendogli una home directory, assegnandogli un nome e assegnandolo al gruppo amministrativo "wheel".

 

Seguirà l'abilitazione dei permessi Sudo senza password, che si ottiene modificando il file /etc/sudoers e rimuovendo il commento # dalla seguente stringa:

 

%wheel ALL=(ALL:ALL) NOPASSWD:ALL

 

Per Debian / Ubuntu Linux

Creazione dell'utente di servizio ACSIA su sistemi DebianUbuntu 

 

useradd -m -d /home/acsia -s /bin/bash -G sudo acsia

 

Controllare poi in /etc/sudoers e rimuovere # dalla stringa seguente (aggiungerla se non è presente):

 

%sudo ALL=(ALL:ALL) NOPASSWD:ALL

 

10.2.4. Chiave SSH

Una volta completata la creazione dell'utente di servizio sui server Linux, il passo successivo è ottenere la chiave ssh dall'interfaccia web di ACSIA. Per ottenere la chiave, andare nell'area Hosts→Add Host, selezionare Linux e sarà possibile vedere/copiare la chiave ssh. 

Copiare/esportare la chiave ssh e importarla nell'utente di servizio ACSIA creato in precedenza (su ogni server), prestando attenzione ai passaggi relativi ai permessi dei file .ssh e authorized_keys

Un modo tipico per farlo sarebbe (come utente acsia ):

 

echo "paste here the key" > .ssh/authorized_keys chmod 700 .ssh && chmod 600 .ssh/authorized_keys

 

Questo utente di servizio ACSIA viene utilizzato per due scopi diversi:

  • Distribuire gli shipper di elastic stack (filebeat, auditbeat, packetbeat), l'agente ossec/wazuh e il modulo kernel falco.
  • Per consentire ad ACSIA di bloccare automaticamente le minacce e gli attacchi sul posto e di eseguire le opzioni di remediation messe in atto dall'utente.

 

Entrambi i passaggi sopra descritti vengono eseguiti tramite playbook Ansible che vengono inviati automaticamente dal server ACSIA ai client (in questo modo si evita di completare manualmente l'installazione su ogni singolo client).

La chiave ssh a cui ci riferiamo è una chiave a 4096 bit generata casualmente da ACSIA durante l'installazione. Questa chiave può essere sostituita da una propria chiave, crearne una nuova o sostituirla con qualsiasi altra coppia di chiavi (ad esempio AWS EC2 keypair.pem). È a totale discrezione dell'utente.

 

10.3. Collegamento di un client Windows senza agente

Per gestire i server Windows in modalità agentless, WinRM deve essere installato, in esecuzione e in ascolto sui server Windows. Le istruzioni riportate di seguito sono esempi forniti da Ansible.

 

10.3.1. Requisiti

  • PowerShell 4.0+

  • Server Windows 2008 SP1+ (o Windows 7 SP1)

  • Account acsia locale o di dominio con privilegi amminstrativi o equivalenti

  • Servizio WinRM attivo e funzionante

 

10.3.2. Domain Controller - Active Directory (senza agente)

Se i sistemi Windows fanno parte di AD/DC, ACSIA dispone di una funzione di integrazione per i Domsni Controller. È sufficiente eseguire il seguente script PowerShell sul DC primario:

ForEach ($COMPUTER in (Get-ADComputer -Filter '*' | Select -ExpandProperty DNSHostName))
{
  if(!(Test-Connection -Cn $computer -BufferSize 16 -Count 1 -ea 0 -quiet))
    {
        write-host "cannot reach $computer" -f red
    }else {
        write-host "executing script on $computer" -f green Invoke-Command -ComputerName $computer -ScriptBlock {
            [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
            $url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"
            $file = "$env:temp\ConfigureRemotingForAnsible.ps1"
            (New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)
            powershell.exe -ExecutionPolicy ByPass -File $file
        }
    }
}

Durante l'esecuzione dello script precedente, se si scopre che alcuni client DC non sono raggiungibili tramite il nome DNS, è sufficiente sostituire DNSHostName con Name.

 

Una volta che lo script di cui sopra è stato eseguito con successo, accedere alla sessione di avvio dell'interfaccia utente di ACSIA (Getting Started ) e aggiungere il Domain Controller; durante la fase di individuazione del Domain Controller apparirà un'opzione chiamata Add all "yourdomain.local servers".

 

Qualcosa di simile alla seguente schermata, dove acsia.local è il FQDN del Domain controller:

blobid0.png

In questo modo, tutti i client registrati sul Domain Controller verranno interrogati e inseriti nell'interfaccia utente di ACSIA per essere distribuiti/monitorati in una sola volta.

Assicuratevi di inserire il vostro controller di dominio nel formato dell' username@fqdn, cioè user1@acsia.io.

 

10.3.3. Client Windows non connesso ad AD/DC (Agentless)

Se i server Windows non sono collegati a un Domain Controller, è necessario eseguire il seguente script sui client Windows per abilitare il servizio winRM, utilizzato per Ansible.

 

Script di configurazione WinRM
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"
$file = "$env:TEMP\ConfigureRemotingForAnsible.ps1"
(New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)
powershell.exe -ExecutionPolicy ByPass -File $file

Assicurarsi che l'URL non venga diviso durante l'operazione di copia/incolla.

10.3.4. Collegamento del PC e workstation ad ACSIA (senza agente)

Anche i PC e le workstation possono essere collegati e monitorati da ACSIA seguendo le istruzioni di cui sopra. Si noti che gli endpoint (come i PC e le workstation) che si trovano dietro a router domestici richiedono l'abilitazione del NATting sulla porta 5986 per l'endpoint che intende connettersi ad ACSIA (l'installazione tramite l'agente è il metodo consigliato per scenari come questo).

Aggiornare la versione di Powershell se è inferiore a 4 e assicurarsi che il firewall di Windows sia attivo.

10.4. Aggiunta di Host tramite l'interfaccia web di ACSIA (solo in modalità agentless)

Accedere all'interfaccia web di ACSIA e fare clic su Aggiungi host (Add Host) nel menu della barra laterale sinistra, nella pagina degli host. Selezionare il sistema operativo del client che si desidera connettere e si verrà inoltrati alla finestra successiva in cui è possibile aggiungere host su base IP o nome host, utilizzando un file CSV (spiegato meglio di seguito) o tramite l'agente (scaricando l'agente). È consigliabile utilizzare gli indirizzi IP per aggiungere il server, poiché i restanti dettagli degli host, compreso il nome dell'host, saranno recuperati e inseriti automaticamente da ACSIA.

Dopo aver completato il Setup degli host, il passo successivo è la schermata di Configurazione dei log (Logs Configuration), in cui è possibile aggiungere i registri personalizzati del server web o dell'applicazione web (utilizzare sempre il percorso assoluto dei registri). Il passo successivo è la convalida dei registri inseriti; se uno di essi è inesistente, viene evidenziato in modo da poterlo correggere o rimuovere se si tratta di un errore o di un refuso e così via.

I percorsi devono essere ai file di log stessi; i symlinks ai file non sono supportati.

Per esempio, se si dispone di un'applicazione web in esecuzione su un server web Nginx (analogamente con Apache), è necessario aggiungere manualmente i log di Nginx durante la distribuzione del client (è possibile farlo anche in seguito, utilizzando l'opzione di modifica), ossia/var/log/nginx/access.log. I registri delle applicazioni web vengono in genere rilevati automaticamente da ACSIA. Ma se per qualche motivo non sono stati rilevati, l'azione consigliata è quella di aggiungerli manualmente utilizzando la sezione "Modifica dettagli host" (Edit Host Details) dove sono elencati gli host (nella pagina Hosts).

 

Una volta completata la configurazione di tutti i file di log, nella schermata successiva verrà visualizzato un riepilogo per verificare che tutto sia stato inserito, seguito da Deploy , in cui si inizia effettivamente a configurare ACSIA e a connettersi ai server. Questa operazione richiederà alcuni minuti (a seconda della connessione di rete tra client e server) e alla fine verrà visualizzato un messaggio di dialogo che riporta il completamento della procedura di registrazione.

 

10.4.1. Formato del file CSV

ACSIA offre l'opzione di utilizzare un file CSV contenente i dettagli di tutti i server, dove è possibile importare semplicemente il file CSV.

 

La seguente schermata mostra il formato del file CSV per ACSIA:

blobid1.png

Se si hanno più registri per un singolo host, è possibile separare ciascun registro con un punto e virgola ;.

Una volta completata la configurazione di un client, i vostri server saranno costantemente monitorati in tempo reale per rilevare problemi di sicurezza, minacce e anomalie.

 

10.4.2. Dettagli Container-specific 

ACSIA è container-aware e tiene automaticamente traccia degli eventi del kernel all'interno dei container. Tuttavia, se si eseguono applicazioni/web server all'interno di container e si desidera monitorare i log, questi devono essere resi disponibili all'host. ACSIA non supporta i collegamenti simbolici ai file di log: deve essere il percorso completo del file di log indicato.

I log dei container Linux possono essere presentati ad ACSIA utilizzando le opzioni docker --volume o --mount. Come da documentazione ufficiale di docker qui or qui se si usa docker-compose.

 

 


 

11. User Administration

La sezione di amministrazione per gli utenti si trova nella barra in alto a destra, cliccando sul nome utente con cui si è effettuato l'accesso e poi su Settings.

 

11.1. Aggiunta di un nuovo utente all'interfaccia web di ACSIA

Aggiungere un utente non è mai stato così semplice. Basta fare clic su username nella barra in alto a destra e selezionare Settings dal menu. 

Quindi cliccare su "AGGIUNGI UTENTE" e compilare tutti i campi; in questa sezione è anche possibile cancellare o modificare gli utenti. Tenete presente che il nome utente effettivo deve essere un indirizzo e-mail.

 

step2.gif

 

11.2. Liste di distribuzione

ACSIA consente di creare liste di distribuzione, è quindi possibile aggiungere membri a ciascun gruppo e impostare i tipi di notifica da inviare a ciascuna lista di distribuzione. Ad esempio, è possibile impostare una lista di distribuzione per ricevere solo avvisi di sicurezza a priorità Critical , High o Medium/Low. I dirigenti di livello C potrebbero non voler ricevere avvisi al di fuori degli eventi Critical e quindi è possibile creare una lista di distribuzione per soddisfare questo requisito.


La Distribution List si trova nel menu della barra laterale sinistra. Per creare una nuova lista di distribuzione è sufficiente fare clic su "AGGIUNGI NUOVA LISTA".

 

gif dist.gif

 

Assegnare un nome alla Distribution List creata e selezionare i membri aggiungendoli all'elenco insieme alla scelta del tipo di evento (Critico, Alto o Medio/Basso) che si desidera far ricevere al gruppo.

Ora è tutto pronto per ricevere le notifiche attraverso la lista di distribuzione.

 

11.3. Impostazioni delle e-mail

Le impostazioni della posta elettronica si riferiscono alle notifiche via e-mail del server di ACSIA. Questa impostazione si trova in alto a destra nel menu Settings, nella scheda Email.

Qui è possibile impostare l'e-mail del mittente e il suo nome. Ad esempio, se il dominio della vostra organizzazione si chiama example.com, potete impostare l'e-mail come no-reply@example.com e il nome come Acsia Alerts e inserire l'account nella white-list dei filtri anti-spam per assicurarvi di ricevere le notifiche da quell'account e-mail.

Una volta configurato il tutto, inizierete a ricevere le e-mail di notifica come da impostazione.

 

Se si riscontrano problemi nella ricezione delle e-mail, l'azione consigliata è quella di impostare un vero account di posta elettronica e configurarlo. Sotto "Email Notification" invece di impostare una semplice e-mail ed etichetta, è possibile attivare i metodi SMTP e di Autenticazione in cui è possibile inserire i dettagli dell'e-mail che si desidera utilizzare come mittente.

 

step7.gif

 

11.4. Ricezione di notifiche tramite Slack e/o Microsoft Teams

Analogamente alla notifica via e-mail, è possibile attivare le notifiche da ricevere tramite Slack e/o Microsoft Teams. È possibile attivare questa funzione nella sezione Settings, alla voce Integrazione, dove è sufficiente copiare il webhook desiderato (Microsoft Teams o Slack) e attivarlo per ricevere le notifiche tramite messaggistica in tempo reale.

 

11.4.1. Istruzioni per l'installazione di Slack (Microsoft Teams è praticamente uguale)

Installare il webhook in entrata su Slack:

  1. Andare in "Applicazioni"

  2. Andare alla directory "View App"

  3. Cercare incoming-webhook

  4. Andare su "Aggiungi configurazione"

  5. In "Post to Channel": scegliere il canale/gruppo a cui inviare la notifica

  6. Fare clic su "Aggiungi integrazione WebHook in entrata"

  7. Andare su "Personalizza nome": Aggiungere il nome, ad esempio: ACSIA Notifier

  8. Copiare l'URLA del WebHook 

 

Configurazione sull'interfaccia utente ACSIA:

  1. Accedere all'interfaccia Web

  2. Andare su Impostazioni -> Integrazione

  3. Attivare Slack o Microsoft Teams

  4. Incollare l'URL copiato

 

11.5. Notifiche a livello di kernel

Con il monitoraggio a livello di kernel, una volta abilitato, ACSIA ha la capacità di intercettare il flusso di ogni chiamata di sistema fatta al kernel, intercettando le `syscalls e cercando anomalie/minacce in tempo reale (questo solo per i sistemi Linux).

Se si desidera ricevere notifiche a livello di kernel, si consiglia di mantenere questa funzione abilitata. Per coloro che lo desiderano, è possibile disattivarla in qualsiasi momento andando su Setting e facendo clic su Notification .

 

mceclip0.png

 

11.6. Abilitazione del ban automatico

Se si desidera che ACSIA gestisca la maggior parte delle minacce provenienti dall'esterno dell'organizzazione (cioè gli attacchi provenienti da Internet come BotNet, Bruteforce, Dictionary, SQL injections, attacchi XSS, ecc.) deve essere abilitata questa funzione.

 

Se abilitata, ACSIA adotterà automaticamente azioni correttive come il ban degli indirizzi IP sul posto. È possibile attivare l'Automatic ban navigando in Settings e facendo clic sulla scheda Notification.

 

noti.gif

 

11.7. Abilitazione del ban manuale per gli indirizzi IP locali/privati

Per impostazione predefinita, ACSIA non può bannare gli indirizzi IP locali, per evitare interruzioni dell'attività o incidenti simili che potrebbero avere un impatto sull'attività. Tuttavia, se si desidera bannare gli indirizzi IP locali, è possibile farlo abilitando questa funzione nella scheda Settings→Notification

 

11.8. Conservazione dei log

ACSIA archivia tutti i log in arrivo dai server tra i database OpenSearch e MySQL. La durata (periodo di conservazione) dei registri può essere configurata navigando in Settings  e facendo clic su Log Retention.

 

mceclip1.png

 

ACSIA consente agli utenti di impostare diversi periodi di conservazione per diversi tipi di log (elencati di seguito):

 

11.8.1. Log di accesso

Questi registri comprendono tutti i log di sistema e i log degli eventi.

 

11.8.2. Web Logs

I web log sono i log delle applicazioni web (ad esempio apache, Nginx, tomcat, IIS, ecc.).

 

11.8.3. Audit Logs

Si tratta di log di audit di Linux molto noti.

 

11.8.4. Network Log

Questi log sono il traffico di rete catturato a livello di server (in entrata e in uscita).

 

11.8.5. ACM Logs

ACM è l'acronimo di Advanced Compliance Mitigation e quindi si tratta di log relativi alla conformità (sistema, applicazione, eventi di sicurezza, ecc.).

 


 

12. Dashboard principale

A partire dalla versione 5.0, ACSIA XDR Plus dispone ora di una Dashboard principale nella sua nuova interfaccia. In questoa dashboard, i dati possono essere esaminati attivamente con visualizzazioni numeriche, grafiche e cartografiche. A prima vista, vengono presentati i dati relativi agli ultimi 10 giorni. È possibile filtrare questi dati in base a un determinato periodo di tempo con lo strumento di filtraggio nell'angolo superiore a sinistra.

 

image.jpg

 

In generale, sulla scheda sono riportati i seguenti dati numerici;
  • Allarme critico
  • Allarme alto
  • Allarme medio
  • Allarme basso
  • Attacco bloccato
  • IP bloccato
Dati visualizzati graficamente;
  • Grafico a linee delle tendenze degli attacchi
  • Grafico dei Top 10 Offenders
  • Grafico degli Host bloccati (Prisma) 
  • Grafico degli attacchi per categoria
  • Grafico a barre dei 10 Host maggiormente attaccati
  • Grafico a barre della Top 10 Authorization Access 
  • Grafico a barre della Top 10 delle autorizzazioni fallite
  • Grafico a barre della Top 10 delle destinazioni

Le tendenze degli attacchi geolocalizzati negli ultimi 10 giorni sono mostrate nella mappa del mondo.

 


 

 

13. Sezione Elenco Host

La pagina dell'elenco degli host mostra l'inventario di tutti i dispositivi collegati ad ACSIA in modalità tablet. I dettagli di ciascuna cella della tabella sono brevemente elencati di seguito:

 

  • Host Alias: dove è possibile assegnare un alias per riconoscere meglio l'host.

  • Hostname: questo valore viene recuperato automaticamente dall'host, ma l'utente può cambiare il nome

  • Host IP: l'indirizzo IP attraverso il quale il client è connesso

  • Sistema operativo: indica quale sistema operativo ha il client

  • Stato: contiene l'elenco e lo stato di tutti gli shippers che trasmettono in streaming i log del client al server ACSIA

  • Azioni: quest'area ha 3 sottosezioni:

  • Visualizza dettagli: mostra i dettagli dell'host, ad esempio il sistema operativo, il kernel, l'indirizzo IP, i log monitorati e altro ancora

  • Modifica dettagli host: è l'area in cui l'utente può modificare i dettagli dell'host, ad esempio aggiungendo un alias, cambiando il nome dell'host, l'indirizzo IP, aggiungendo log personalizzati da monitorare e avviando/arrestando manualmente i log shipper (streamer), ecc.

  • Rimuovi host: dove è possibile rimuovere l'host collegato.

IMG_20220824_235314 (1).jpg

 

 


 

14. Sezione Eventi

14.1. Notifiche in tempo reale

Nel menu di sinistra sono presenti anche le Live Notifications che contengono un elenco di tutti gli eventi in tempo reale che non sono ancora stati attivati. Tutti gli avvisi di sicurezza in arrivo saranno elencati in questa sezione e facendo clic sulla freccia Details di ogni notifica in quest'area sarà possibile sfogliare ed esplorare i dettagli completi di un singolo incidente/avviso generato da ACSIA.

 

IMG_20220825_003541.jpg

 

Abbiamo anche dei filtri in cui gli eventi possono essere filtrati e ricercati in base ai criteri, ecc.

 

14.2. Barra laterale delle notifiche in tempo reale

Abbiamo una barra laterale Live Events sul lato destro dello schermo. Questa barra laterale è simile a Live Notifications, con l'eccezione di essere statica e permanente sul lato destro, utile per monitorare gli eventi durante la navigazione tra le funzionalità di ACSIA.

Ogni evento viene mostrato con una breve descrizione e con Immediate Actions, per consentire all'utente di intervenire e porre rimedio a un evento o incidente di sicurezza in arrivo.

 

IMG_20220825_004201.jpg

 

15. Insights

L'area Insights si trova nel menu della barra laterale di sinistra. Questa sezione contiene diverse dashboard che ACSIA offre per indagini approfondite sugli eventi o anche per generare report e analisi. Ogni dashboard viene visualizzata utilizzando OpenDashboard, un'applicazione web offerta da OpenSearch Stack. La Dashboard OpenSearch è integrata in OpenSearch, potete trovare qualcosa quiOpensearch.

Ogni dashboard è ben descritta nelle sue funzioni nell'area Insights.

 

mceclip2.png

 

15.1. Conformità

L'area Compliance contiene principalmente dashboard/report relativi alla conformità e ai quadri normativi elencati brevemente di seguito:

 

  • Gestione delle informazioni sulla sicurezza

  • Rapporto sugli eventi di sicurezza

  • Rapporto di monitoraggio dell'integrità

  • Rilevamento e risposta alle minacce

  • Rapporto sulle vulnerabilità

  • Mitre Att&ck

  • Auditing e monitoraggio delle Policy

  • Dashboard di monitoraggio delle Policy

  • Dashboard di controllo del sistema

  • Conformità normativa

  • GDPR

  • PCI DSS

  • HIPAA

  • NIST 800-53

  • TSC

 

mceclip4.png

 

La gestione della sicurezza e delle informazioni fornisce visibilità e report sugli eventi di sicurezza e include il monitoraggio dell'integrità dei file. Il rilevamento e la risposta alle minacce forniscono rapporti sulle vulnerabilità scoperte per i sistemi connessi.

L'audit e il monitoraggio delle Policy forniscono una visibilità completa dei controlli di audit e dei requisiti delle Policy standard.

Le dashboard di conformità normativa includono tutti i regimi normativi globali da GDPR, PCI DSS, NIST 800-53, HIPAA, TSC a Mitre Att&ck framework. ACSIA fornisce un controllo completo e una visibilità in tempo reale sulla conformità dei sistemi IT e, nel caso in cui i sistemi non siano conformi, fornisce l'esatto punto di non conformità in modo da poterlo affrontare facilmente.

 


 

16. Policy

Le Policy di ACSIA forniscono un inventario di ciò che è consentito e non consentito sui client monitorati. Quando ACSIA blocca il traffico, utilizza i firewall locali dei singoli client (firewall di Windows e tabella di routing sui sistemi Linux, ecc.) La sezione "Policy" è suddivisa in 4 sottosezioni:

 

  • IP Blacklist

  • IP Whitelist

  • Utenti bloccati

  • Luogo di accesso

  • Notifiche silenziate

IMG_20220825_005241.jpg

 

 

16.1. IP Blacklist

La sezione IP Blacklist contiene tutti gli indirizzi IP che sono stati contrassegnati come dannosi e non autorizzati e quindi inseriti nella blacklist (bannati dagli host). È possibile annullare un'azione se un indirizzo IP viene erroneamente bannato da un utente. Se la funzione di autoban è abilitata, ACSIA gestirà automaticamente tutti i potenziali attacchi e le minacce provenienti dall'esterno dell'organizzazione (ad esempio da Internet), mentre le minacce interne saranno sempre notificate affinché l'amministratore di ACSIA prenda la decisione finale.

 

16.2. IP Whitelist

La sezione IP Whitelist contiene tutti gli indirizzi IP che sono stati contrassegnati come attendibili. Si noti che la whitelist di un indirizzo IP non include le richieste web, in quanto è sensibile agli accessi a livello di applicazione web. Pertanto, quando si mette in whitelist un indirizzo IP che non si applica alle richieste web e se il traffico proveniente da quell'indirizzo IP specifico identifica una potenziale minaccia, sarà soggetto a notifica e avviso.

 

16.3. Utenti bloccati

La sezione Locked Users contiene utenti specifici che sono contrassegnati come bloccati. Può trattarsi di utenti legittimi che tentano di accedere ad aree non autorizzate. In alternativa, possono essere utenti malintenzionati che hanno compromesso i dettagli dell'account legittimo di un utente e quindi sono stati bloccati. ACSIA non blocca automaticamente gli utenti legittimi, ma richiede sempre l'input dell'utente, per cui la decisione spetta all'amministratore di ACSIA.

 

16.4. Luogo di accesso

La sezione Access Location si riferisce a quegli eventi di sicurezza in cui l'accesso legittimo proviene da una posizione geografica o da un indirizzo IP non autorizzato da ACSIA. Pertanto, è in attesa di approvazione, per essere autorizzato o non autorizzato. Se si autorizza un indirizzo IP basato sulla posizione di un utente, è come se l'utente fosse inserito nella whitelist solo per quell'indirizzo IP. D'altro canto, se si contrassegna un utente come non autorizzato, quest'ultimo potrà comunque accedere ed effettuare tentativi, ma arriverà ogni volta un avviso. Pertanto, il luogo di accesso è diverso dalla blacklist di un IP, a meno che non si aggiunga manualmente l'IP alla blacklist.

 

16.5. Notifiche silenziate

La sezioneMuted Notifications si riferisce agli eventi di sicurezza che sono stati riconosciuti legittimamente dagli amministratori e/o dagli analisti di sicurezza di ACSIA. Una volta che un evento è stato contrassegnato come silenziato, ACSIA non notificherà più quel tipo di evento. Tutti gli eventi silenziati possono essere disattivati in qualsiasi momento.

 


 

17. Azioni immediate - Opzioni di remediation

È molto probabile che le Immediate Actions siano le funzioni di ACSIA più utilizzate dagli utenti. Spesso queste azioni sono incorporate in tutti gli eventi di sicurezza in arrivo o nelle notifiche e-mail. Da qui è possibile intraprendere un'azione immediata e mitigare interattivamente l'evento per porvi rimedio. 

 

Questa è la funzione interattiva di ACSIA, che richiede l'input dell'utente per la correzione di eventi e minacce:

L'ordine delle Azioni immediate (talvolta indicate come Remediation Options), fornite con le notifiche, cambia dinamicamente in base al livello di gravità dell'evento e al tipo di evento. Ad esempio, in presenza di un avviso di potenziale compromissione dell'account, l'ordine delle azioni di rimedio sarà impostato sulla priorità, dove l'opzione che appare in cima sarà la scelta più logica, seguita dalla seconda dell'elenco e così via. Gli utenti di ACSIA trarranno grandi benefici da questa funzione anche se non hanno conoscenze di cybersecurity o hanno competenze tecniche limitate.

 

17.1. Azioni immediate o opzioni di remediation offerte da ACSIA:

17.1.1. Interrompi la connessione

Scegliendo questa azione, l'utente di ACSIA eliminerà il traffico di rete (in tempo reale) per quell'indirizzo IP dannoso e sospenderà tutto il traffico per quell'indirizzo IP per i successivi 15 minuti. Tutte le connessioni stabilite e le nuove richieste di connessione saranno eliminate durante il tentativo di trasmissione.

 

17.1.2. Riconosci e autorizza l'utente/il luogo

Scegliendo questa azione si autorizza quell'utente specifico e l'indirizzo IP associato in modo permanente ad accedere alla propria sede. L'indirizzo IP in questione sarà inserito nella whitelist di ACSIA e pertanto non si riceveranno più segnalazioni provenienti da quell'indirizzo IP associato all'utente.

 

17.1.3. Contrassegna questo utente/luogo come non autorizzato

Scegliendo questa azione si chiede ad ACSIA di continuare a notificare agli utenti questo evento fino a quando non si prende una decisione. Utilizzare questa opzione per gli incidenti in cui non si è ancora deciso di vietare o autorizzare l'accesso da un indirizzo IP.

 

17.1.4. Vieta questo indirizzo IP

Scegliendo questa azione, l'indirizzo IP viene definitivamente bannato e quindi non sarà più in grado di raggiungere i vostri sistemi.

 

17.1.5. Blocca l'utente

Scegliendo questa azione si blocca l'account utente all'interno del sistema.

 

17.1.6. Traccia questo IP

Questa azione porta alla Dashboard dell'applicazione OpenDashboard, dove tutte le attività di rete e di server di quell'indirizzo IP specifico saranno popolate per dare piena visibilità a ciò che sta accadendo.

 

17.1.7. Traccia questo utente

Questa azione porta alla Dashboard dell'applicazione OpenDashboard , dove tutte le attività della rete e del server vengono visualizzate per quell'utente specifico, consentendo di stabilire la legittimità dell'attività dell'utente. 

 

17.1.8. Whois Query

Si tratta di un servizio di ricerca di nomi di dominio per cercare nel database Whois informazioni sulla registrazione di domini e IP. Fornisce informazioni rilevanti sulla proprietà dell'indirizzo IP di origine dell'utente malintenzionato.

 

17.1.9. Visualizza dettagli

Questo fornisce dettagli precisi sull'evento, compresa la posizione geografica dell'indirizzo IP di origine e le coordinate geografiche.

 

17.1.10. Chiudi l'incidente

Questo è una semplice richiesta di ignorare l'evento e, se si ripresenta, ACSIA lo comunicherà nuovamente.

 

17.1.11. Silenzia le notifiche

Questa azione indica ad ACSIA di ignorare e non notificare più il ripetersi di quell'evento specifico.

 

17.1.12. Traccia la sessione di comando - Solo per i client Linux

Si tratta di una funzione estremamente potente di ACSIA, abilitata dal monitoraggio a livello di kernel. Nel momento in cui viene rilevata un'attività sospetta o un utente ha tentato di leggere o scrivere su dati o file sensibili, viene attivato l'avviso e vengono fornite azioni correttive in tempo reale. Quando si fa clic su "Traccia sessione di comando" (Track Command Session), viene presentata non solo l'attività specifica dell'utente che ha attivato l'avviso, ma l'intera sessione dell'utente in modalità replay. Questo livello di dettaglio forense consente di visualizzare l'intera attività svolta dall'utente e quindi di capire perché l'utente ha cercato di alterare i file e i dati sensibili e di intraprendere rapidamente un'azione correttiva.

 


 

18. Storia dell'evento

La cronologia degli eventi è la sezione in cui è possibile trovare tutti gli eventi che sono stati modificati e da chi (utenti ACSIA, chi ha fatto cosa sull'interfaccia web).

 


 

19. Notifica via e-mail

Di seguito è riportato un esempio di notifica via e-mail e Slack:

blobid2.png

blobid3.png

Come si può vedere nella schermata precedente, abbiamo ricevuto una notifica di accesso riuscito tramite l'utente acsia al nostro server di pre-produzione. Ora sappiamo che un utente legittimo ha effettuato l'accesso, ma ACSIA ha giustamente notificato che si tratta di una potenziale compromissione dell'account.

L'utente e la posizione diventeranno legittimi per ACSIA solo se autorizzeremo l'utente con la posizione associata come legittima. Gli utenti di ACSIA devono addestrare il modulo di apprendimento automatico di ACSIA quando si tratta di accessi legittimi come questo. È qui che ACSIA richiederà principalmente l'input dell'utente. Pertanto, gli utenti ACSIA dovranno indicare per la prima volta, che questo utente è autorizzato e legittimo. Da quel momento in poi ACSIA sarà a conoscenza di questo modello e non lo comunicherà più (a meno che l'account non sia realmente compromesso).

 


 

20. Troubleshooting and Common Issues

Common issues and how to troubleshoot and fix them.

 

20.1. Changing ACSIA server IP address

Please be aware that if you change the IP address of ACSIA manually from the configuration file you will break all communications systems with the clients connected (if any are added). Also trying to change/amend manually the server IP address on individual clients connected to ACSIA will not help to restore the communication between the two since ACSIA generates SSL cert-based private and public keypair between the server and its clients for secure and end-to-end communication. Therefore, if you happen to change the IP address of the ACSIA server the easiest fix would be to run acsia_change_ip from the ACSIA server itself.

 

20.2. Packetbeat failing on Windows systems

If you experience a problem with the packetbeat component failing on Windows clients, it is most likely due to an antivirus or other similar software installed on the client and not permitting for ACSIA shippers (packetbeat) to be installed correctly. To solve this issue you’ll need to login into the windows client, open the file uninstall-service-packetbeat.ps1 located in C:\Program Files\Packetbeat with PowerShell and execute. After that, proceed with uninstalling Npcap software which should be listed among your programs using the windows uninstall feature available in the control panel.

 

Once you uninstall Npcap you need to reinstall it, so download from https://nmap.org/npcap/dist/npcap-1.00.exe and install. During the installation of Npcap, in the beginning, tick the options WinPcap API compatible mode and Legacy loopback. Once you have installed Npcap you will need to execute install-service-packetbeat.ps1 in PowerShell to complete the installation. You can either try to start the network shipper from ACSIA UI or it will start automatically after 5 or 10 minutes.

 

20.3. Recent versions of Ubuntu versions come without python2

Some of the most recent Ubuntu versions are not shipped with python2 by default so you may need to install it if problems arise during the deployment of an ubuntu client. apt install python2

 

20.4. User not receiving an email with the account details after the installation

If you are experiencing any issues in receiving the email containing user account details, it is likely the case that your email provider is bouncing the email, placing it into a spam or quarantine area or it may as well be that your network infrastructure is not allowing the server to dispatch emails. ACSIA uses postfix as the MTA, so please check your network infrastructure configuration to make sure that the VM hosting the ACSIA server is able to send emails. Also check the postfix logs at /var/logs/maillog, as well as your spam or quarantine area and/or whitelist on your mail server ACSIA email and the IP address.

 

20.5. Message “Deployment Failed” Kernel module

During the deployment of clients if you are experiencing an issue with the message from UI Deployment Failed this could be either the failure of the deployment partially or fully. To verify if the failure is partial just check the host's lists on ACSIA UI and if you see that host listed then it is a partial failure and most likely the kernel module failed due to missing requirements. In this case, ACSIA will be operational and working on that specific client with the exception of the kernel module that is failing.

To solve this issue:

 

  1. Open a terminal in the ACSIA server

  2. Switch to acsia user

  3. Execute the following command (replace both client_ip with the IP of the client):

    Please note that the client_ip is followed by , to distinguish it from a filename.

    ansible -i 'client_ip,' -m script -a "$ACSIA_BIN/install_falco" client_ip --become

     

    Example:

    ansible -i '11.22.33.44,' -m script -a "$ACSIA_BIN/install_falco" 11.22.33.44 --become

     

 

On some clients having Debian 8x Falco kernel modules may fail during deployment due to falco.yml file configuration not being placed correctly. To fix this issue you may run dpkg --configure -a.

 

If no output is given or an output containing a message W: Failed to fetch it means you are experiencing network issues to reach out to the server where the module is located. Please check your outbound connection i.e. firewall rules and make sure the server is allowed to reach the source as per requirements outlined in this guide.

 

20.6. Deployment failed with the message ImportError: No module named 'requests.packages.urllib3'

This is a common Fedora/RHEL/CentOS (RPM platforms) issue when a package or packages are installed using non-standard package management. (i.e. using pip or setuptools etc. rather than yum). the This issue can be addressed as follows:

 

sudo pip2 uninstall requests urllib3 sudo yum remove python-urllib3 python-requests sudo yum install python-urllib3 python-requests

 

20.7. Deployment failed ACM (Wazuh/OSSEC module)

If you experience a problem (for both Windows and Linux clients) where the ACM module of ACSIA is failing to start, it is most likely the communication port issue related. So make sure that the communication ports are opened between the ACSIA server and the clients as per requirements. If the ports are open and the issue still persists then run the following command(s) from the ACSIA server as acsia user:

 

acsia_reconfigure_acm --linux acsia_reconfigure_acm --windows

 

Use linux parameter if the issue occurs on a Linux client, else use the windows parameter if the client system is windows.

 

20.8. After the system update (patching) Kernel module stopped working on clients

It is not always the case but it may happen that during updates and patching activities on servers that are connected to ACSIA the kernel level monitoring may not function properly. If you experience any issues with kernel monitoring after updates all you need to do is to perform the following command as acsia user on all connected clients: cp -rf /etc/falco/falco.yaml.rpmnew /etc/falco/falco.yaml and restart the kernel module from ACSIA Web UI on clients.

 

20.9. Storage Saturation - Disk full on ACSIA Server

When storage saturation reaches 90% capacity on the ACSIA server, the elastic search component switches to read_only and it won’t allow new logs to be written on the disk. This means the storage capacity should always be below 90%. If the storage capacity exceeds 90% you will need to free up space or allocate more disk space. Once storage capacity is freed, restoring elastic search from read-only to read-write indexes requires some fix as follows.

 

20.9.1. Fixing Elasticsearch Index after disk storage saturation

After adding or freeing storage space execute the following script which will restore elastic search to its original state (read-write):

 

#!/bin/bash for i in $(curl -s -X GET http://localhost:9200/_cat/indices | awk -F ' ' '{print $3}' | sort) do echo Updating ${i}: $(curl -s -X PUT -H "Content-Type: application/json" \ -d '{"index.blocks.read_only_allow_delete": null}' \ "http://localhost:9200/${i}/_settings") done

 

20.10. Docker containers' IP addresses conflict with local IP addresses

The architecture of ACSIA and its components is primarily built in Linux containers using docker-compose. During ACSIA installation the way a container platform works is that it scans the network perimeter looking for available private networks to pick up and set network configuration automatically.

 

It may occur that some businesses have segmented their IT infrastructure and ACSIA is not aware of their presence because it is in a segregated network. When you open for the first time those subnets to ACSIA and if they happen to be the same subnet as the ACSIA docker environment the two will get in conflict with each other. You, therefore, have to choose another network and set it on ACSIA docker-compose configuration.

 

It is possible to do that as follows:

 

  • create/edit /etc/docker/daemon.json and add the chosen (new) subnet to assign as per the below snippet and restart services as shown:

    • { "bip": "192.168.1.5/24" }

    • acsia_stack_stop

    • sudo systemctl docker restart

    • acsia_stack_start

     

20.11. Falco fails with agent deployment

After deploying the agent on Linux if you happen to have Kernel (Falco) fails, to investigate proceed as follows (on client terminal): - Check first if Falco service is up and running systemctl status falco:

 

  • if the service is there but not running, just start the daemon from the UI using the Edit Host option

  • else, if the service does not exist proceed as follows

  • Check acsia_agent logs and trace down falco related logs: less /opt/acsia/agent/acsia_agent_proj/logs/agent.log or just use grep grep falco /opt/acsia/agent/acsia_agent_proj/logs/agent.log

 

If you see something like the following:

2022-03-01 11:37:46,034 acsia_agent.commands.operations INFO Failed Ephemeral [440efa1a-1ac3-40f8-a86c-b8944effd76d: [ansible -m script -a "/opt/acsia/agent/acsia_agent_proj/assets/install_falco 2> /dev/null" --become 127.0.0.1]

 

The above indicates that for some reason Falco installation is failed, we, therefore, need to reinstall it as follows (always on the client):

 

  • run the following commands:

    • sudo /opt/acsia/agent/acsia_agent_proj/assets/install_falco

 

This should install Falco, enable it and start the process automatically.

 

20.12. ACM fails with agent deployment

If you get an ACM failed on a Linux system, check first if the service for wazuh-agent is running systemctl status wazuh-agent. If the service exists or is running all you need to do is to start the shipper from UI ('Host Edit' section).

 

Else if the service doesn’t exist then just try to install wazuh-agent via yum service i.e. yum install wazuh-agent on the client-side.

 

From the ACSIA server terminal run the following steps as acsia user:

 

  • acsia_admin_query hosts (identify the host ID)

  • acsia_admin_query "update acsia_json_entry_ephemeral_command set status='NEW' where host_id=HOST_ID"

 

The above steps should activate the failing component.

 


For any further information and queries please get in touch with our support team by contacting us via our support portal (https://support.4securitas.com).

ACSIA is a product of 4Securitas Ltd.

Copyright 2022 4Securitas Ltd