Monitorare un server Linux utilizzando Microsoft Azure Operations Management Suite
Operations Management Suite (OMS) è una soluzione cloud-based che permette la gestione e la protezione di infrastrutture cloud e on-premises. Si rivela un’ottima soluzione soprattutto per quelle infrastrutture ibride, sia Microsoft che Linux, che per i motivi più disparati sono solo parzialmente su cloud, magari in VPN site-to-site.
Utilizzando la Service Map, effettueremo l’analisi dei servizi utilizzati dalla macchina, agganciandola di fatto a OMS.
Per maggiori informazioni su OMS clicca qui;
OMS mette a disposizione una serie di strumenti di analisi che aiutano nella comprensione delle criticità della propria infrastruttura. Sfruttando un agent installato sulle macchine sarà possibile centralizzare la gestione direttamente sul portale OMS.
Figura 1: Portale OMS – Panoramica
Per le macchine Windows è possibile effettuare il download dell’agent ed installarlo facilmente. Su Linux, invece, la procedura è un po’ più ostica.
In questo articolo vedremo sia come collegare una macchina Linux ad Azure OMS installando l’agent per la comunicazione con il portale OMS, sia come collezionare e visualizzare le informazioni tramite Service Map.
I sistemi Linux supportati sono i seguenti (sono riportate solo le versioni più recenti):
Red Hat Linux 7
OS version |
Kernel version |
7.0 |
3.10.0-123 |
7.1 |
3.10.0-229 |
7.2 |
3.10.0-327 |
7.3 |
3.10.0-514 |
Red Hat Linux 6
OS version |
Kernel version |
6.0 |
2.6.32-71 |
6.1 |
2.6.32-131 |
6.2 |
2.6.32-220 |
6.3 |
2.6.32-279 |
6.4 |
2.6.32-358 |
6.5 |
2.6.32-431 |
6.6 |
2.6.32-504 |
6.7 |
2.6.32-573 |
6.8 |
2.6.32-642 |
Oracle Linux 6
OS version |
Kernel version |
6.2 |
Oracle 2.6.32-300 (UEK R1) |
6.3 |
Oracle 2.6.39-200 (UEK R2) |
6.4 |
Oracle 2.6.39-400 (UEK R2) |
6.5 |
Oracle 2.6.39-400 (UEK R2 i386) |
6.6 |
Oracle 2.6.39-400 (UEK R2 i386) |
Oracle Linux 5
OS version |
Kernel version |
5.8 |
Oracle 2.6.32-300 (UEK R1) |
5.9 |
Oracle 2.6.39-300 (UEK R2) |
5.10 |
Oracle 2.6.39-400 (UEK R2) |
5.11 |
Oracle 2.6.39-400 (UEK R2) |
SUSE Linux 11
OS version |
Kernel version |
11 |
2.6.27 |
11 SP1 |
2.6.32 |
11 SP2 |
3.0.13 |
11 SP3 |
3.0.76 |
11 SP4 |
3.0.101 |
SUSE Linux 10
OS version |
Kernel version |
10 SP4 |
2.6.16.60 |
Non sono supportati:
- Kernel non standard (PAE, Xen);
- Kernel Custom.
Linux machine
Prerequisiti:
OS: CentOS
HTTPD: Server version: Apache/2.2.15 (Unix) + Basic Authentication
Mysql: Server version: 5.1.73
Immaginiamo di avere una macchina Linux con funzioni di database sul cloud.
Utilizzando una configurazione con HTTPD + Basic Authentication simuleremo l’hosting di una pagina web in modo da poter loggare i tentativi di accesso.
In questo articolo sarà presa ad esempio una macchina con queste caratteristiche il cui hostname è mysql02.
Installazione Agent OMS
Il portale mette a disposizione la URL dove effettuare il download dell’agent corredato dei comandi di esecuzione con parametri precompilati. Sfruttando questa comodità installeremo una prima versione dell’agent senza doverci preoccupare di recuperare Workspace ID, Primary Key, ecc…
Nel portale OMS, cliccando su Settings -> Connected Sources -> Linux Servers recupereremo le informazioni necessarie.
Figura 2: Portale OMS – Settings
Eseguiamo il logon utilizzando il protocollo ssh sulla macchina linux. Per questo articolo è stato utilizzato il software PuTTY.
Eseguiamo il comando come root:
wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w <WORKSPACE ID> -s <PRIMARY KEY> -d opinsights.azure.com
E’ necessario effettuare l’upgrade dell’ultimo agent disponibile.
Lanciamo il comando:
sh ./omsagent-1.3.1-15.universal.x64.sh --upgrade -w <WORKSPACE ID> -s <PRIMARY KEY>
Figura 3: VM – Installazione agent
Modifichiamo il file /etc/rsyslog.conf abilitando la ricezione dei syslog:
Figura 4: VM – Configurazioni syslog
Nella directory /etc/rsyslog.d/ creiamo il file security-config-omsagent.conf inserendo la seguente configurazione:
#OMS_facility = local4
local4.debug @127.0.0.1:25226
Nella directory /etc/opt/microsoft/omsagent/<WORKSPACE ID>/conf/omsagent.d
Creiamo il file
security_events.conf
Con la seguente configurazione:
<source> | |
type syslog |
|
port 25226 |
|
bind 127.0.0.1 |
|
protocol_type udp |
|
tag oms.security |
|
format /^(?<time>(?:\w+ ){2,3}(?:\d+:){2}\d+):? ?(?:(?<host>[^: ]+) ?:?)? (?<ident>[a-zA-Z0-9_%\/\.\-]*)(?:\[(?<pid>[0-9]+)\])?: *(?<message>.*)$/ |
|
</source> |
|
<filter oms.security.**> |
|
type filter_syslog_security |
|
</filter> |
Aggiorniamo i permessi del file con il comando:
chown omsagent:omiusers security_events.conf
Scarichiamo ed installiamo in file DependencyAgent con il comando:
wget https://aka.ms/dependencyagentlinux
poi
sh InstallDependencyAgent-Linux64.bin
All’interno del portale Azure eseguiamo la connessione della macchina Linux alle risorse OMS:
All resources -> oms -> Virtual machines
Selezioniamo la nostra macchina e clicchiamo su Connect.
Figura 5: Portale Azure – Agent VM connesso a OMS
A questo punto non ci resta che aspettare il discover automatico renda disponibili le informazioni sulla macchina.
Figura 6: Portale Azure – VM connessa a OMS
Apriamo il file /etc/opt/microsoft/omsagent/conf/omsagent.conf
Modifichiamo la configurazione del docker come da screenshot per abilitare il livello di log a “debug”:
Figura 7: VM – Configurazione agent
Di default la configurazione dell’agent OMS sul file di conf 95-omsagent.conf utilizza la porta 25224.
Nel nostro caso, quella porta non è in listening. Per verificarlo eseguiamo il comando:
netstat –nap | grep 25224
Le porte in listening sono la 25225 e 25226
Figura 8: VM – Porte in ascolto utilizzate dall’agent
Modifichiamo, quindi, la configurazione con la porta corretta:
Figura 9: VM – Modifica porta per syslog
Nel Portale OMS configuriamo la tipologia di syslog da ricevere:
Figura 10: Portale OMS – Definizione syslog
Eseguiamo il restart del servizio rsyslog con il comando:
service rsyslog restart
Eseguiamo la stessa operazione per l’agent OMS con:
sudo /opt/microsoft/omsagent/bin/service_control restart
Quando la Service Map riceve tutti i dati inviati dall’agent, renderà fruibili molte informazioni:
Figura 11: Service Map – Panoramica VM e relativi servizi
In tempo reale possiamo vedere quali servizi sono in ascolto e quali sono utilizzati. Possiamo vedere quali e quanti client sono connessi alla nostra macchina, lo stato delle connessioni TCP, alert, ecc…
Cliccando sulla macchina o sui vari servizi ci verranno forniti dettagli specifici:
Figura 12: Service Map – Dettaglio VM
Tornando sul Portale OMS e cliccando su Log Search verifichiamo i syslog ricevuti inserendo la seguente stringa nella form di ricerca:
* Computer=mysql02 Type=Syslog Facility=authpriv
Figura 13: Portale OMS – Log Search
È possibile affinare la ricerca inserendo filtri differenti a seconda della tipologia di syslog. La form è dotata di un sistema di IntelliSense che aiuta nella definizione della ricerca:
Figura 14: Portale OMS – Definizione filtri ricerca Log Search
Conclusioni
Senza ulteriori configurazioni e costi aggiuntivi è possibile monitorare fino a 5 macchine virtuali. Per incrementare questo numero è necessario utilizzare un data plan con dei costi per nodo aggiuntivi. Per maggiori dettagli sui costi clicca qui.
Questo tipo di soluzione è facilmente implementabile, efficace nell’analisi dei sistemi e sicuramente un’ottima base di partenza in tema di prevenzione.