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 e dei computer che vi appartengono. Il Pannello Sygma, ovvero la console centralizzata, è un sistema esclusivo di gestione clienti il quale, oltre ad integrare un database personalizzabile con tutte le informazioni necessarie per una gestione ottimale dell'infrastruttura informatica dei vostri clienti, dispone di sistemi di integrazione anche con i sistemi di Posta, Firewall, VoIP, Backup Remoto e Archiviazione e-mail.
Tra le funzionalità della piattaforma c’è l’agente RMM, 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. L’agente gira come servizio all’interno della macchina in cui viene installato e può svolgere molte operazioni.
In questo tutorial spiegheremo cosa fa e come si utilizza, nello specifico, l’agente RMM implementato nell’ambito della piattaforma Sygma, partendo dalla definizione di RMM agent.
RMM è l’acronimo di Remote Monitoring and Management e in sé esprime il concetto. L’agente RMM non è altro che il software o servizio installato in un computer per implementare l’RMM stesso.
Nel senso generico, un agente RMM 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. Più esattamente, ogni agente che si installa su una macchina ne fornisce il controllo da remoto.
L’agente RMM permette di schedulare comandi che devono essere inviati alle macchine, che possono essere sia singoli eventi che comandi ripetuti periodicamente. Il controllo da remoto (Remote Shell) è un’altra funzione dell’agente, che permette di impartire comandi come se si fosse fisicamente sulla macchina.
Quanto al controllo remoto della macchina, è una funzione che permette di visualizzare l’attività della stessa e creare dei rapporti sull’utilizzo e sul lavoro svolto; di norma non viene implementato nativamente dall’agente RMM, quindi per eseguire il controllo remoto viene carica un software di terzi come potrebbe essere Splashstop o Teamviewer.
Inoltre l’agente RMM, quando viene installato, carica dei servizi antivirus e di backup sulla macchina dove si trova.
Ultimo servizio offerto è il Service Desk, ossia qualcosa con cui l’utente del computer può interagire con l’agente per richiedere assistenza tecnica, la cui richiesta verrà visualizzata sulla console centralizzata.
La piattaforma Sygma implementa una sua versione di agente RMM che grosso-modo fa quanto descritto e che in più è collegato in Rete con la console centralizzata di Sygma; di seguito verrà spiegato nel dettaglio, esponendone caratteristiche e funzionalità specifiche.
La comunicazione tra agente e console centralizzata di Sygma può avvenire secondo quattro modalità:
Dalla console centralizzata di Sygma è possibile organizzare la visualizzazione e la gestione di tutti gli agenti installati sulle macchine remote.
La comunicazione dalla console verso l’agente avviene per instaurare una sessione RPC (Remote Procedure Call) ossia per inviare dei comandi, per aggiornare la configurazione dell’agente e per aggiornare l’agente stesso.
L’agente comunica secondo due tecniche: polling o web socket; nella prima, periodicamente (per eseguire comandi RPC o per gestire aggiornamenti) 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.
Non c’è una soluzione prediletta, perché entrambe hanno vantaggi e svantaggi: nel caso del polling c’è una periodicità di richieste http verso la console centralizzata e questo può sia caricare la macchina dove l’agente è installato, sia impegnare traffico di rete; quindi va bene se l’agente non deve eseguire comandi né trasferire molti dati.
Nel caso del web socket possono esserci problemi a superare il firewall o i comandi che la console invia all’agente possono andare persi, dato che se l’agente si scollega per qualsiasi ragione i dati e i comandi si possono perdere; per utilizzare il web socket in sicurezza bisognerebbe che l’agente verificasse costantemente se questo è “on”.
Vediamo nel dettaglio come funziona Sygma RMM Agent, che -va subito precisato- attualmente è disponibile solo per sistemi Windows ed è in sviluppo in versione anche per Linux. Questo agente si installa tipicamente sui server di rete e può monitorare anche i client, tuttavia per applicazioni specifiche può essere installato anche sui client.
L’agente RMM di Sygma funziona come spiegato sinora per gli agenti RMM generici, ma nello specifico svolge i seguenti compiti:
Per una scelta progettuale non sono state incluse le funzioni di controllo remoto, antivirus e backup: il controllo remoto, perché non è nativo e quindi richiederebbe l’installazione di un prodotto specifico, il che non ha senso in quanto andrebbe ad appesantire il sistema. In realtà è prevista la connessione tramite API con prodotti del genere, tipo Teamviewer, per contabilizzare le relative informazioni ed anche con prodotti alternativi come Splashtop, che ha una formula commerciale un po’ diversa da quella di Teamviewer e più conveniente, ma non restituisce lo stesso risultato perché la visualizzazione si basa su un web socket implementato in Node.js e quindi fornisce screenshot di bassa qualità. Di fatto, al momento si è preferito non integrare un prodotto di Remote Control. Ad ogni modo, il controllo remoto è utile ad esempio per tracciare l’utilizzo dei computer (per i ticket activity) soprattutto nell’ottica del GDPR, in cui bisogna tenere traccia degli utenti che utilizzano le macchine e delle credenziali con cui hanno avuto l’accesso.
Quanto all’antivirus, di norma gli agenti RMM utilizzano prodotti di terze parti ma limitatamente all’engine (ossia al motore antivirus) e al database delle signature aggiornabile periodicamente, ma non integrano l’antivirus vero e proprio e pertanto non fanno tutto quello che un antivirus farebbe, quindi in fin dei conti è meglio separare le due cose.
Infine, per il backup il discorso è similare perché si fornirebbe con l’agent una soluzione che, paragonata ai costi tutto-sommato bassi con cui si acquista un vero prodotto per il backup, non vale la pena di avere.
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 ogni 5 minuti.
Questi intervalli sono quelli predefiniti, però è possibile modificarli dalla console di Sygma dopo aver selezionato l’agente interessato; tenete 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 comunicare 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.
L’aggiornamento dell’agente non è automatico ma si può lanciare dalla console centralizzata, quindi è più facile gestire gli agenti.
Sygma dispone di più tipi di sonde, che implementano le seguenti funzionalità:
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 impostare 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) andato o meno a buon fine.
Passiamo all’utilizzo pratico della console per installare l’agente su macchine Windows; innanzitutto dalla console centralizzata di Sygma è possibile, cliccando sulla barra laterale Remote Management e scorrere fino a Sygma Agent evidenziato nell’immagine seguente, così da vedere quali sono gli agenti installati al momento.
Qui si vede una rassegna degli agenti installati per i sistemi operativi sui quali a sinistra è posto il segno di spunta; al momento ce ne sono due in rosso, il che, come da legenda sempre sulla parte sinistra dello schermo, sono non attivi. Se ce ne fosse stato uno con il pallino verde sarebbe stato attivo. L’eventuale presenza del triangolino rosso accanto al nome dell’agente indica che per esso è stato generato un alert verso la console: vedete questa situazione nel primo agent della lista.
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.
L’installazione di nuovi agenti si esegue dalla console centralizzata. 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.
Nella schermata notate anche il pulsante Teamviewer, che consente di utilizzare il servizio corrispondente per il controllo remoto delle macchine in cui è installato un agente RMM.
Cliccando sul nome di un agente si può vederne tutti i dettagli, che sono molti più di quelli mostrati nell’immagine precedente; si ottiene, insomma, una schermata come quella proposta nell’immagine seguente.
La pagina è molto dettagliata e riporta tutte le caratteristiche hardware della macchina, il nome dell’agente (chiamato ALIAS) oltre al tipo di storage e ad altre informazioni specifiche dell’agente quali l’associazione a un eventuale ITEM (funzionalità di Sygma) e la presenza di alert attivi.
Come sempre abbiamo a sinistra la sezione Agent, dalla quale è possibile, per l’agente selezionato di volta in volta, fare una programmazione di attività e comandi da eseguire (comando SCHEDULE), attivare sensori (comando SENSORS) o scaricare l’agente stesso sulla macchina (comando DOWNLOAD WINDOWS). Invece cliccando sul comando LIST si ottiene l’elenco glià visto, degli agenti.
La schermata di ciascun agente è, come appare nell’immagine precedente, divisa in tab, che sono INFO (quella appena vista), TASKS (immagine seguente) dove viene mostrata la lista dei task (i processi) in esecuzione sulla macchina come verrebbero riportati in task manager, APPS, SERVICES, EVENTS (riporta la risultanza del registro eventi), ALERTS, SENSORS ecc.
L’immagine seguente propone la tab APPS, che riepiloga i programmi in esecuzione sulla macchina che l’agente notifica alla console centralizzata.
Di seguito viene invece proposta la tab EVENTS, che riporta 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.
L’immagine seguente propone la tab ALERTS, dove potete vedere tutti gli alert associati all’agente in questione: 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, il primo in lista riguarda il disco C e quindi uno storage, riporta come Parameter la percentuale di utilizzo e come Condition Exceeding, ossia il superamento della percentuale impostata.
Particolarmente interessante è la tab TERMINAL, che apre una finestra di terminale dalla quale si possono impartire dei comandi come se ci si trovasse sull’interfaccia a linea di comando della macchina (immagine seguente).
Dalla tab 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 Pytho occorre avere quest’ultimo installato.
Invece dalla tab SENSORS è possibile vedere e gestire i sensori configurati, a quale agente sono stati assegnati (immagine seguente) con tutti i dettagli del caso, come l’alias e lo stato, consultabile a destra con il pulsante che è verde in caso di sensore attivo (ACTIVE) o rosso se il sensore è stato disattivato.
Infine, dalla tab SCHEDULED si possono consultare i comandi schedulati nell’agente (immagine seguente) ovvero la coda di esecuzione.
Cliccando su SCHEDULE List si accede alla finestra mostrata nell’immagine seguente, da dove si consulta il dettaglio della schedulazione. Cliccando su SHOW accanto a ciascuna, si mostrano tutti i dati corrispondenti.
Invece con il pulsante +NEW SCHEDULE è possibile accedere alla finestra di impostazione dei comandi schedulati, proposta nell’immagine seguente; qui si assegna un nome alla schedulazione, a sinistra si pone la spunta sugli agenti elencati per i quali si vuole sia applicata, poi si passa a definire i comandi da eseguire.
Dalla finestra è possibile gestire in toto la schedulazione, ovvero aggiungere o rimuovere comando, programmarne l’esecuzione periodica o singola (ora e data) e via di seguito.
Passiamo a vedere come si creano e si impostano i sensori relativi agli agenti RMM di Sygma: innanzitutto accediamo alla console di Sygma e andiamo nella sezione Agent, dove vediamo l’elenco di tutti gli agenti installati su macchine Windows; 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 diamo 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 specifichiamo su quale agente vogliamo che giri questo sensore; in Type definiamo la tipologia di sensore e in Event IDs indichiamo l’ID dell’evento da cercare (Event ID), che comparirà poi nella console all’attivazione del sensore. Nella casella Run every seconds definiamo ogni quanto tempo (in questo caso ogni 60 secondi) 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.
Per ogni sensore definito e attivo è possibile visualizzare le statistiche di attivazione in una schermata contenente un grafico che verifica l’andamento temporale: nell’immagine seguente è proposta quella relativa all’utilizzo della CPU.
Invece l’immagine seguente propone una schermata relativa all’attività di un sensore di eventi che, nello specifico, riguarda un tentativo di login fallito.
Naturalmente questi sono solo alcuni esempi di utilizzo dei sensori, utili a comprendere come si creano e si configurano; le categorie di sensori impostabili e assegnabili ad ogni agente sono molte e coprono buona parte delle condizioni che è possibile far testare all’agente RMM di Sygma, tra cui ping, richieste HTTP, utilizzo dello storage del backup registro eventi e via di seguito.
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.
Bene, con questo termina questa rassegna sull’agente RMM messo a disposizione da Sygma; essendo, questo, in continua evoluzione, è possibile che alcune delle schermate mostrate in questo tutorial possano apparire differenti e che siano disponibili nel tempo funzionalità qui non descritte, ma il funzionamento esposto è sempre attuale.
