No results found
La piattaforma Sygma è un servizio Cloud offerto da Coretech, che implementa una serie di strumenti per la gestione da remoto di reti aziendali; il suo cuore è la console Sygma, tra le funzionalità gestibili c’è l’agente RMM Sygma, che è un software installato su PC o Server che consente di monitorare i parametri del sistema, rilevare l’hardware e gestire operazioni di controllo remoto.
RMM è l’acronimo di Remote Monitoring and Management e permette di tenere sotto controllo tutte le macchine della rete, ovvero effettua il monitoraggio di CPU, RAM, disco, dei software e servizi in esecuzione, registro eventi e in generale controlla lo stato delle macchine con la possibilità di accedere a informazioni dettagliate, fornite sotto forma di alert (per esempio se lo spazio occupato su disco rigido supera una soglia impostata) e report, oltre che di eseguire comandi da remoto.
L’agente gira come servizio all’interno della macchina e tra le sue funzionalità ci sono le SONDE, le quali sono gli elementi che si utilizzano per il monitoraggio del sistema. Ogni agente RMM di Sygma è collegato in Rete con la console centralizzata di Sygma.
In questo tutorial spiegheremo come si configurano le SONDE, partendo dall’ipotesi di aver già creato un agente RMM per macchine Windows ed averlo correttamente configurato.
L’agente comunica secondo due modalità: polling o web socket; nella prima, periodicamente contatta il server e comunica. Nella seconda viene installata una connessione permanente bidirezionale nella quale la console non comunica direttamente con l’agente, ma quando deve chiedergli qualcosa domanda al socket web di inviare qualcosa all’agente (quindi al PC) e questo lo rigira all’agente stesso e viceversa, ovvero l’agente risponde inviando ciò che la console ha richiesto (per esempio i dati sulla configurazione) e il web socket lo manda alla console centralizzata.
Approfondiamo il discorso sul polling, spiegando che per quanto riguarda la richiesta alla console di eventuali comandi da eseguire è periodica e avviene ogni 10 secondi; per quanto riguarda, invece, il polling avviato per l’invio alla console di informazioni di stato e monitoraggio delle macchine, ciascun agente effettua una comunicazione ad intervalli impostabili dalla console di Sygma dopo aver selezionato l’agente interessato e tenendo presente che più alta è la frequenza, maggiore è l’impegno di risorse e viceversa.
Oltre che periodicamente con la console, l’agente comunica con i server per inviare informazioni su eventi specifici, come esaurimento dello spazio di storage, superamento di una soglia di utilizzo delle risorse hardware o il verificarsi di specifici eventi nel registro di sistema.
Per rilevare tali eventi si fa ricorso a ciò che in Sygma Agent RMM sono le sonde, vale a dire dei tool in grado di monitorare gli stati richiesti; più esattamente, le sonde sono degli eseguibili realizzati per svolgere uno specifico compito di monitoraggio o gestione. Sono realizzati in Python e in fase di installazione o di aggiornamento dell’agente vengono inseriti nella cartella di installazione del programma e operano in base alle impostazioni fatte dalla console centralizzata.
Le sonde sono disponibili dalla versione 3.1 dell’agente.
Sygma dispone di più tipi di sonde, che implementano le seguenti funzionalità:
ping;
Per esempio PING notifica, al verificarsi di un ping verso la macchina dove l’agente è installato, che tale evento è avvenuto, riportandone gli estremi.
HTTP/HTTPS permette di monitorare le chiamate effettuate e verificare se l’esito arriva fuori da un certo tempo limite, ovvero se non contiene una certa stringa impostata nella sonda stessa.
Backup del registro eventi provvede a salvare in una cartella specifica (security application and system) dei backup periodici del registro degli eventi, per poi poterli consultare quando serve, ovvero recuperare laddove qualcuno, per errore o volutamente, lo va a cancellare sulla macchina (in quest’ultimo caso è anche possibile impostate una sonda per ottenere un alert che notifichi la cancellazione).
Le sonde possono essere differenziate in base al fatto che l’agente venga installato su client o su server: per esempio sul client si può predisporre una sonda che verifichi un tentativo di login (ai fini del GDPR, per esempio) andato o meno a buon fine.
Accediamo dunque alla console di Sygma e andiamo nella sezione Integrazioni>AGENT, dove vediamo l'elenco di tutti gli agenti installati su macchine Windows; nell’immagine seguente si vedono installati due agenti.
In generale la sezione riporta una rassegna degli agenti installati per i sistemi operativi sui quali a sinistra è posto il segno di spunta; nell’immagine ce ne sono due per Windows Server 2016 segnati in verde, il che, come da legenda visibile sempre sulla parte sinistra dello schermo, sono attivi. Se ce ne fosse stato uno con il pallino rosso sarebbe stato non attivo. L’eventuale presenza del triangolino rosso accanto al nome dell’agente indica che per esso è stato generato un alert verso la console.
Per ciascun agente sono riportati nome, computer su cui è installato, sistema operativo (colonna Type) nome host (Hostname) indirizzo IP, data di esecuzione della logon, versione e ultimo aggiornamento eseguito.
Ricordiamo che l’installazione degli agenti si esegue dalla console centralizzata e che ogni agente viene installato sul disco C: della macchina target nella cartella Sygma, che viene appositamente creata; inoltre sul desktop della macchina viene posizionata un’icona.
Cliccando sulla riga corrispondente all’agente è possibile aprire la pagina di dettaglio, che riporta, oltre alle informazioni base (hostname, IP ecc.) anche altri dati come l’Alias e via di seguito (immagine seguente) in una schermata divisa in tab.
Le informazioni come l’alias, il gruppo di appartenenza, il sistema operativo, l’architettura della relativa macchina e le relative risorse, lo storage, il tempo di utilizzo, le informazioni sulla network e gli item associati si trovano nella tab INFO, mentre in TASKS sono visualizzati i processi che stanno girando, in APPS i programmi installati nella macchina, in SERVICES troviamo i servizi in esecuzione su quella macchina. Da quest’ultima scheda è possibile, mediante pulsanti disponibili a lato, accedere al menu a tendina da cui impartire i comandi per arrestare o riavviare uno o più servizi.
Nella tab EVENTS vengono visualizzati gli eventi registrati dall’agente, ossia quel che c’è nel registro eventi: per ciascun evento in lista è riportato il livello di sicurezza (Security) l’ID, la data in cui si è verificato e il provider, ossia da cosa arriva il relativo record.
In ALERT sono visualizzati gli eventuali alert generati dall’agente; i messaggi sono divisi per tipo (eccessivo utilizzo o spazio limitato sullo storage, superamento dell’utilizzo di memoria impostato ecc.), target e via di seguito e riportano in cosa consiste il messaggio: per esempio, nel caso di un disco rigido e quindi uno storage, viene riportato come Parameter la percentuale di utilizzo e come Condition, Exceeding, ossia il superamento della percentuale impostata.
Nella tab >_TERMINAL viene proposta una finestra di terminale da cui c’è la possibilità di impartire alla macchina dei comandi da remoto (immagine seguente).
Simile è la tab SCRIPT, la quale permette di eseguire degli script; da SCRIPT è possibile inviare alla macchina target, tramite l’agente, uno script da mandare in esecuzione su di essa. Resta inteso che per lanciare uno script bisogna che sulla macchina sia installato il programma corrispondente, vale a dire che se si vuole eseguire uno script Python occorre avere Python installato.
Infine, la tab SCHEDULED riepiloga i comandi schedulati nell’agente, ovvero la coda di esecuzione.
Siccome quello che interessa in questo tutorial sono i sensori, andiamo a vedere la sezione SENSORS (comando di menu a sinistra della console di Sygma) che riepiloga le sonde attive (o sensori, se preferite...) indicando per ciascuno, oltre ad altre informazioni, l’agente cui risultano assegnate (immagine seguente) e lo stato, che può essere ACTIVE (verde) se il sensore è attivo o ALERT (rosso) se è stato generato da esso un alert.
Riprendendo quanto esposto prima, ossia che i sensori sono degli eseguibili che sono presenti nelle installazioni di Sygma e che compiono operazioni mirate, vediamo che a ciascuno si va a dare un nome abbastanza attinente al compito che dovrà svolgere.
Andiamo adesso a spiegare come si crea un sensore:
qui accediamo alla schedulazione dei sensori e clicchiamo sul pulsante +SENSOR. Appare quindi la finestra di dialogo proposta dall’immagine seguente, nella quale si impostano le proprietà del sensore stesso.
Nel caso specifico si deve assegnare un nome nella casella Alias (Event Log Alert Login Failed, che nello specifico vuol dire che rileverà le login non andate a buon fine) e nel menu a tendina in Agent si specifica su quale agente si desidera che questo sensore lavori; in Type definiamo la tipologia di sensore, che può essere scelta nel menu che si apre cliccando all’interno della casella (immagine seguente). Al momento i sensori disponibili sono quelli elencati nel menu e visibili nell’immagine, che si riferisce a un sensore per eseguire il ping.
Procediamo e in Event IDs indichiamo l’ID dell’evento da cercare (Event ID), che comparirà poi nella console all’attivazione del sensore e nella riga di log al momento che si verificherà l’evento. Nella casella Run every seconds definiamo ogni quanto tempo il sensore debba attivarsi e per attivare il sensore, nella sottostante casella Status Sensor scegliamo Active.
Sotto, nella sezione ACTION WHEN RECEIVING AN ALERT stabiliamo che azioni intraprendere, ossia andiamo a dare al sensore delle associazioni: per esempio creare un ticket sul ticket system di Sygma, ovvero inviare una e-mail (immagine seguente).
È anche possibile indicare se inviare degli alert al verificarsi della ripetizione della condizione impostata nel sensore, impostando il numero di volte nel riquadro Send Subsequently e-mail alerts every posto in basso nella finestra di dialogo. Una volta impostato il sensore, lo si crea cliccando sul pulsante Save.
Volendo rimuovere un sensore, basta aprire la tab SENSOR, selezionarlo, riaprire la finestra di dialogo +Agent Sensor appena vista e rimuoverlo.
Descriviamo ora i sensori disponibili, che sono poi quelli riportati nel menu a tendina; partiamo da PING, che sostanzialmente, con cadenza descritta nella casella Run every seconds esegue il ping
a un hostname specifico: ad esempio 8.8.8. 8 (il DNS di Google). Nel caso del sensore PING l’intervallo tra un ping e il successivo non può essere impostato inferiore a 60 secondi.
Quando il test relativo al sensore fallisce (il fallimento è relativo alla tipologia di sensore: in questo caso il ping fallisce quando non riceve risposta) viene prodotto un alert sotto forma di avviso nella finestra riepilogativa dei sensori degli agenti, vista qualche immagine indietro.
Oltre a questa azione, che è locale (sulla console) è possibile definire l’invio di una e-mail, indicando l’indirizzo nella casella E-mails, che dev’essere quello di un utente Sygma.
Per quanto riguarda l’apertura di un ticket, si tratta di creare un ticket sul Ticket System di Sygma in cui indichiamo la coda (queue) in cui metterlo. Nella finestra di creazione e impostazione del sensore è possibile definire dopo quanti eventi di alert deve partire l’avviso via e-mail, scrivendo il relativo numero in Send an e-mail to the alert number e ogni quanti ulteriori dopo il verificarsi del primo (casella Send Subsequently e-mail alerts every posto in basso nella finestra di dialogo), come mostrato nell’immagine seguente.
Questa impostazione ha molto senso per il ping, in quanto può capitare che una volta, a causa di una latenza, il ping fallisca, quindi non è utile allertarsi al primo tentativo fallito; magari si può impostare l’alert al verificarsi di più tentativi falliti, come ad esempio alla quinta volta. Infatti con un intervallo di 60 secondi, cinque tentativi falliti significano che il server non risponde da 5 minuti, il che è una condizione che deve destare attenzione.
Per quanto riguarda l’apertura del ticket, non essendoci la notifica di continuo avviso dopo la prima creazione del ticket, quando il sensore torna positivo (quindi magari fallisce qualche volta e dopo che è stata mandata la notifica torna a funzionare) manda una notifica di sensore tornato a funzionare correttamente: per esempio se trascorsi i tentativi impostati il ping riesce, ma ormai è stato aperto il ticket, si riceve la notifica che la situazione è tornata normale. Questo vale anche per gli altri tipi di sonda.
Passiamo ai sensori HTTP e HTTPS, che sostanzialmente hanno impostazioni e azioni simili, solamente che la porta predefinita per il primo è la 80 mentre per il secondo è 443; come si nota dall’immagine seguente, la finestra di impostazione qui ha alcuni elementi specifici che sono diversi da PING. Una volta scelto il sensore dal menu Type, si deve definire il metodo nella casella Method: per esempio si sceglie GET.
A questo punto nella casella Hostname si va a scrivere il nome o indirizzo del server web (nel caso della sonda HTTP non serve anteporre http://, come invece è per l’HTTPS) e poi il path specifico nella casella Path (immagine seguente).
Fatto questo, nella casella dedicata scriviamo il timeout in secondi (Time out for sesponse) che corrisponde all’attesa per la risposta, superata la quale viene generato l’alert dal parte del sensore.
È anche possibile aggiungere un testo da cercare nella risposta HTTP, osssia effettuare una ricerca di parole chiave (Text to check); questo serve, ad esempio, per verificare l’integrità di un sito Internet: per esempio si vanno a inserire delle parole chiave nel codice del sito e se quelle parole chiave non ci sono nella risposta HTTP il sensore fallisce la richiesta e viene generato l’alert, perché verosimilmente il sito in questione è stato hackerato.
Anche per HTTP è possibile definire le policy già descritte di “escalation” ossia quelle nella sezione ACTION WHEN RECEIVING AN ALERT relative al numero di tentativi dopo i quali mandare il sensore in allarme ecc.
Passiamo ora al sensore Event Log backup, che esegue il backup del registro di sistema: nella casella Event Logs si specifica un registro di sistema (ad esempio Security ma anche Application) e viene fatto il backup su una cartella specifica che deve esistere, nel senso che l’agente non la crea in automatico. Questa destinazione va specificata nella casella Backup Destination Path.
Per esempio, se abbiamo una shell di rete condivisa tra tutti i server nella quale si definisce il server da raggiungere e quindi il backup verrà fatto lì.
Nel caso proposto dall’immagine seguente facciamo il backup direttamente sulla macchina, quindi andiamo a creare una cartella sul server interessato.
Terminate le impostazioni e salvato il sensore come Active, l’agente farà il backup che sarà strutturato così: in pratica creerà una cartella per ogni tipologia del registro (Security e Application) e poi farà una copia del registro a livello locale, mantenendo i backup esistenti.
In questo specifico sensore, l’intervallo può essere anche abbastanza lungo, in base alle proprie esigenze.
Similmente a quanto spiegato, è possibile creare il sensore Event Log Alert, che genera degli alert al verificarsi di un determinato evento specifico: anche qui si definisce il tipo di registro desiderato in Event Logs (ad esempio Security e Application, come nel caso precedente) e poi, nella casella
Event Ids, l’ID o gli ID degli eventi che il sensore dovrà andare a cercare.
Al solito si definisce l’intervallo di ricerca (lo standard è sempre 60 secondi), quindi si attiva la sonda e la si salva.
Quando il sensore va in esecuzione, esegue la scansione dei registri di sistema alla ricerca degli Event ID specificati e se li riscontra genera gli alert secondo le modalità impostate, che sono sempre quelle già esposte per le altre sonde.
Per esempio se vogliamo ricercare gli eventi relativi alla logon dell’account e al fallimento della logon andiamo a dichiarare in Event IDs il 4625 (account logon) è il 529 (logon failure); ogni numero inserito, per passare a quello successivo si preme la barra spaziatrice.
Il sensore si può usare anche in senso inverso, ossia si desidera sapere quando una persona tenta l’accesso: ad esempio quando magari si tratta di un server Windows con sopra il DNS e quindi l’accesso la macchina è limitato.
Vediamo l’ultimo sensore, che è CPU-RAM-NETWORK che mantiene uno storico dell’utilizzo di tali risorse: le impostazioni alla fine sono sempre quelle, anzi, molto più semplici, perché basta definire un nome, l’intervallo e lo stato, quindi salvare (immagine seguente).
In ogni momento dalla console centralizzata di Sygma è possibile consultare lo stato dei sensori e la relativa lista relativa ad ogni singolo agente: allo scopo bisogna cliccare su Agent nella parte sinistra della console, scegliere l’agente e cliccare su SENSORS.
Da questa stessa sezione è anche possibile eliminare un sensore esistente: basta cliccare sulla riga corrispondente al sensore desiderato, allorché appare una finestra simile a quella di creazione, che però stavolta riporta in basso a sinistra anche il pulsante rosso Delete; cliccando su quest’ultimo appare una finestra di dialogo che propone la domanda Delete sensor? , allorché si può cliccare su OK per confermare l’eliminazione (immagine seguente).
I risultati acquisiti da qualsiasi sonda possono essere visualizzati interrogandola dalla schermata che riepiloga i sensori per un certo agente, cliccando su quello interessato; nel caso proposto dall’immagine seguente, il sensore è stato chiamato STATISTICS, è l’ultimo della lista nella schermata e risulta assegnato all’agente Server 2.
Cliccando sulla riga del sensore si chiederà all’agente di fornire tutti i dati corrispondenti; questo vale per tutte le sonde che lo prevedono; per esempio, cliccando su una sonda PING si potrà ottenere un grafico tipo quello proposto dall’immagine seguente, che riepiloga lo storico dei ping eseguiti, con la relativa statistica di quelli riusciti e di quelli falliti.
Nel grafico sono mostrati, ad esempio, i dati su dei ping eseguiti al solito indirizzo 8.8.8.8 e contraddistinti dai pallini verdi vi sono quelli riusciti e in rosso vengono invece riportati quelli falliti; cliccando su ciascuno appare un’etichetta che riepiloga i dati corrispondenti (per esempio il tempo impiegato a ottenere la risposta).
Analogamente si potrebbe ottenere un grafico che mostra l’esito temporale dei backup, fatto in maniera analoga e con i pallini verdi a indicare i backup riusciti e con i rossi indicanti quelli falliti; anche qui, puntando un pallino si apre l’etichetta che ne riporta i dati salienti.
Finora è stato spiegato come assegnare manualmente un sensore a un agente, ma è anche possibile fare un’assegnazione massiva attraverso la gestione gruppi; vediamo dunque come aggiungere a livello massivo le sonde a più agenti in gruppo. Aggiungere massivamente i sensori è un’operazione utile perché fa risparmiare tempi in casi in cui occorre installare un agente in molti computer dello stesso cliente e si vuole che su tutti quei computer siano installate le stesse sonde.
Supponiamo quindi di voler assegnare i sensori Backup dei Log e gli Event ID.
Per l’assegnazione massiva occorre innanzitutto partire da un gruppo di agenti, accedendo alla relativa schermata mediante un clic sulla voce GROUPS del menu di sinistra; qui sono riepilogati i gruppi esistenti. Se non esiste alcun gruppo o si vuole operare su un nuovo gruppo, si clicca in alto a destra su +GROUP e così facendo si apre la finestra di impostazione +Agent Group, nella quale assegnare un nome a questo gruppo e inserire una descrizione, magari attinente agli agenti che ne faranno parte (immagine seguente).
Fatto questo si clicca su Save, creando il gruppo. A questo punto si torna alla schermata riepilogativa dei gruppi, dove adesso è presente quello creato; bisogna quindi procedere all’abbinamento dei sensori, operazione che si esegue praticamente come già spiegato per gli agenti: si clicca su +SENSOR e si sceglie dal menu a tendina già visto il tipo di sonda desiderato. Naturalmente si configura il tutto come visto individualmente per i vari tipi di sensore e si salva. Per il singolo gruppo è possibile definire quanti sensori si desidera, di tipo differente.
Una volta definito il sensore o i sensori assegnati al gruppo, la situazione della finestra GROUPS appare come mostrato nell’immagine seguente, che nel caso specifico vede i gruppi Agenti Ufficio Milano e Ufficio Clienti Coretech: a quest’ultimo è stato abbinato un sensore chiamato PING FAIL GRUPPO.
A questo punto si torna alla schermata riepilogativa degli agenti installati, accessibile cliccando sulla solita voce LIST del menu di sinistra; clicccando sulla riga dell’agente che si vuole assegnare al gruppo appare, nella parte inferiore della schermata, la serie di tab relativa al gruppo stesso. Qui, sulla tab iNFO si clicca nella casella Groups:, quindi si va a scrivere il nome del gruppo cui l’agente sarà abbinato (immagine seguente).
Per semplificare il compito e non farvi sbagliare, la console di Sygma presenta una lista dei nomi esistenti, grazie a una sorta di completamento automatico che si apre digitando la prima lettera; da qui si può cliccare sul nome desiderato e questo apparirà nella casella. Per completare l’assegnazione al gruppo si clicca sul pulsante verde SAVE.
Analoga procedura può essere svolta con tutti gli altri agenti da assegnare al gruppo; inoltre un agente può essere abbinato a più gruppi di sonde, semplicemente selezionando o scrivendo nella casella Groups: i relativi nomi.
Andando nella schermata dei sensori (voce di menu SENSORS) ora appariranno i sensori creati e nella colonna Group verrà visualizzato il gruppo di appartenenza (immagine seguente).
Tornando alla schermata degli agenti, accessibile dal comando di menu LIST e cliccando sul nome di un agente associato a un gruppo di sensori, nella tab SENSORS della sezione inferiore della pagina apparirà la lista dei sensori appartenenti al gruppo e ci troveremo quelli appena creati (immagine seguente).
Analogamente, eliminando un sensore (nella maniera già spiegata in questo tutorial) il gruppo di appartenenza viene automaticamente aggiornato e nella tab SENSORS della finestra relativa all’agente d’interesse il sensore del gruppo non verrà più visualizzato.
Questo è tutto.
