Monitoraggio di Linux in modalità legacy

C'è una descrizione completa dell'installazione dai pacchetti deb o rpm nell'articolo Monitoraggio Linux, quindi qui ci limiteremo a spiegare la procedura in breve.

In Checkmk Community, puoi trovare i pacchetti Linux dell'agente tramite Setup > Agents > Linux. Nelle edizioni commerciali, devi prima accedere all'Agent Bakery nel menu Setup tramite Agents > Windows, Linux, Solaris, AIX, dove troverai i pacchetti già pronti. Da lì, la voce di menu Related > Linux, Solaris, AIX files ti porterà all'elenco dei file dell'agente.

Puoi scaricare questi file tramite il browser oppure utilizzare wget o curl per scaricarli direttamente nell'host nel monitoraggio:

Su RHEL, SLES e distribuzioni correlate, il pacchetto RPM viene installato come root con il comando rpm -U:

A proposito, l'opzione -U sta per "aggiornamento", ma può anche eseguire correttamente un'installazione iniziale.

L'installazione del pacchetto DEB su Debian, Ubuntu o distribuzioni correlate si effettua come root con il comando dpkg -i:

Per un'installazione comoda e indipendente dalla distribuzione, avrai bisogno dell'agente Linux in formato archivio TGZ ("Tarball"), che puoi scaricare dalle edizioni commerciali nel menu Configurazione tramite Agents > Windows, Linux, Solaris, AIX. L'archivio TGZ contiene la struttura completa delle directory dell'agente Linux da decomprimere nella directory root dell'host monitorato.

Il parametro "-C" ("cambia directory") è essenziale durante la decompressione per garantire che tutti i percorsi dei file siano corretti. Utilizziamo anche "--no-overwrite-dir" in modo che i permessi delle directory già esistenti non vengano modificati:

Se hai fatto tutto correttamente, lo script dell'agente dovrebbe ora essere semplicemente eseguibile come comando e produrre il suo output tipico. L'| head tronca tutto ciò che segue l'undicesima riga dell'output:

Se qui viene visualizzato un numero di versione inferiore a 2.2.0, probabilmente hai ancora una versione precedente dello script dell'agente installata come /usr/local/bin/check_mk_agent. Sposta questo vecchio script o rinominalo, ad esempio aggiungendo .bak al nome del file.

L'installazione manuale dello script dell'agente è raramente necessaria, ma non è nemmeno molto difficile. In questo tipo di installazione, inizialmente viene installato solo lo script dell'agente, ma non viene ancora eseguita alcuna configurazione dell'accesso. A questo scopo ti serve il file Agents dalla pagina dei file dell'agente. Lì troverai il file check_mk_agent.linux:

Carica questo file sul sistema di destinazione e copialo in una directory eseguibile per root. /usr/local/bin/è una buona scelta, poiché si trova nel percorso di ricerca ed è destinata alle estensioni personalizzate. In alternativa, puoi usare /usr/bin o una sottodirectory di /opt. Noi usiamo /usr/bin in modo che tutti i test corrispondano agli altri metodi di installazione. Puoi anche eseguire l'installazione direttamente con wget se disponibile:

Non dimenticare gli ultimi due comandi: questi rimuoveranno l'estensione .linux e renderanno il file eseguibile. Ora l'agente dovrebbe essere eseguibile come comando e produrre il suo output tipico. L'| heade tronca tutto ciò che segue la decima riga dell'output:

Se vuoi configurare o estendere l'agente, dovrai creare tu stesso le directory necessarie. La posizione delle tre directory obbligatorie è hard-coded nell'agente in variabili che iniziano con MK_ e viene fornita anche ai plug-in tramite l'ambiente di sistema:

Dovresti creare queste tre directory (con i permessi predefiniti 755 e root come proprietario):

Se vuoi usare percorsi diversi, basta modificare il file /usr/bin/check_mk_agent.

Per configurare un xinetd esistente che utilizza la directory /etc/xinetd.d/ per la configurazione, sia l'archivio TGZ che i pacchetti DEB e RPM includono uno script che automatizza i due passaggi necessari: prima installa la configurazione e poi fa in modo che xinetd rilegga le impostazioni modificate. Devi eseguire lo script indicando i percorsi completi dei file:

Se installi lo script dell'agente manualmente, crea il file di configurazione /etc/xinetd.d/check-mk-agent con l'editor. Il contenuto è sufficiente:

Qui abbiamo aggiunto una riga (commentata) che limita l'accesso a due server Checkmk. Puoi vedere altre opzioni di configurazione guardando il file ~/share/check_mk/agents/scripts/super-server/1_xinetd/check-mk-agent sul tuo server Checkmk.

Se il tuo xinetd utilizza il vecchio schema di configurazione con un unico grande file /etc/xinetd.conf, trasferisci la configurazione di esempio da /etc/check_mk/xinetd-service-template.cfg a /etc/xinetd.conf.

Una volta completata la configurazione di xinetd, riavvialo:

Ora sei pronto per il test di connessione.

Per prima cosa, controlla se il tuo file /etc/services contiene già una voce per la porta 6556:

Se così non fosse, Checkmk deve essere registrato come servizio. Per farlo, aggiungi la seguente riga. La notazione qui è esattamente la stessa di quella memorizzata nella tabella IANA con un unico trattino:

Il formato del file di configurazione /etc/inetd.conf varia a seconda delle singole varianti. Consulta i commenti nel file di configurazione e la pagina del manuale (man 5 inetd.conf) per trovare il formato adatto al tuo inetd. Segue la configurazione corrispondente a openbsd-inetd con due righe per il supporto IPv4 e IPv6. Anche in questo caso, è importante prestare attenzione alla notazione corretta:

Dopo aver modificato il file di configurazione, riavvia inetd, ad esempio con:

A seconda del sistema init utilizzato e del super-server installato, questo comando potrebbe variare.

Per prima cosa controlla se è possibile (ri)avviare xinetd o inetd:

Ora puoi collegarti a telnet o nc (netcat) sulla porta TCP 6556 — prima dall'host stesso, poi dal server Checkmk:

Se ricevi una notifica di connessione negata anche se (x)inetd è attivo, controlla le impostazioni del tuo firewall.

SSH funziona con l'autenticazione a chiave pubblica. Per farlo, devi prima generare una coppia di chiavi abbinate, di cui una pubblica e una privata. Quando selezioni l'algoritmo, puoi scegliere tra rsa, ecdsa o ed25519. Nell'esempio qui sotto, utilizzi il comando ssh-keygen -t ed25519 come utente del sito:

Lascia vuoto il nome del file per utilizzare il nome suggerito. Naturalmente puoi specificare un percorso diverso, ad esempio se desideri lavorare con chiavi separate per singoli host.

Importante: non specificare una passphrase! Crittografare il file con la chiave segreta non servirebbe a nulla, dopotutto non vorrai certo dover inserire la passphrase ogni volta che avvii il server Checkmk…​

Il risultato sono due file nella directory .ssh:

La chiave privata si chiama id_ed25519 ed è leggibile solo dall'utente del sito (-rw-------) — ed è una buona cosa! La chiave pubblica id_ed25519.pub ha un aspetto simile a questo:

Il passo successivo deve ora avvenire su (ciascuno degli) host Linux monitorati tramite SSH. Accedi lì come root e crea la sottodirectory .ssh nella sua directory home (/root), se non esiste già. Con il seguente comando i privilegi di accesso verranno impostati correttamente a 700 immediatamente:

Ora apri il file authorized_keys con un editor di testo (da console) a tua scelta. Se questo file non esiste già, l'editor lo creerà automaticamente:

Copia il contenuto delle chiavi pubbliche in questo file. Puoi farlo, ad esempio, con il mouse e il copia-incolla. Sii preciso! Ogni spazio conta. Assicurati anche che non ci siano mai due spazi in una riga. E: il tutto deve stare su un'unica riga! Se il file esiste già, aggiungi semplicemente una nuova riga sotto.

Quello che segue è molto importante! La chiave SSH dovrebbe essere utilizzata esclusivamente per l'esecuzione dell'agente. SSH offre una funzione simile chiamata "restrizione dei comandi". Per farlo, inserisci il testo command="/usr/bin/check_mk_agent" all'inizio della riga che hai appena creato, separandolo dal resto con un singolo spazio. Il risultato sarà simile a questo:

Salva il file e controlla i permessi. Solo il proprietario può avere i permessi di scrittura su questo file.

Ora prova l'accesso all'agente con il comando ssh:

La prima volta dovrai confermare l'impronta digitale della chiave inserendo yes. Tutti gli accessi successivi potranno quindi avvenire senza l'intervento dell'utente, compreso il polling automatico dello script dell'agente da parte del server Checkmk ogni minuto.

Se non funziona, controlla:

Con sistemi di destinazione molto vecchi, è anche possibile che le chiavi con le curve ellittiche (ed25519 e ecdsa) siano sconosciute. In questo caso, genera una chiave RSA aggiuntiva e inseriscila anche nell'authorized_keys. SSH utilizzerà quindi automaticamente la chiave più forte conosciuta per la connessione.

Il sistema di destinazione è ora pronto. Manca solo la configurazione di Checkmk stesso. Questo si fa tramite il set di regole Setup > Agents > Other integrations> Custom integrations > Individual program call instead of agent access. Crea qui una regola per gli host interessati e inserisci ssh -T root@$HOSTNAME$ o ssh -C -T root@$HOSTNAME$ (per una compressione aggiuntiva dei dati dell'agente) come comando:

Puoi eseguire il test di connessione nella GUI alla voce "Setup > Hosts > Properties of host > Test connection to host" con il pulsante "Run tests". Se il test fallisce per timeout o accesso negato, controlla se hai usato il nome host con la stessa ortografia utilizzata durante il test da riga di comando — OpenSSH distingue tra nome host abbreviato, FQDN e indirizzo IP. In alternativa puoi accedere all'host utilizzando il suo indirizzo IP. In questo caso devi utilizzare la macro $HOSTADDRESS$ che viene sostituita dall'indirizzo IP dell'host memorizzato nella cache (da Checkmk).

Dopo aver salvato ed eseguito Attiva modifiche, l'host viene aggiunto al monitoraggio. Nel monitoraggio viene ora visualizzato il servizio Check-MK Agent con la nota "Trasporto via SSH". Per ulteriori diagnostiche è possibile utilizzare i comandi cmk -D e cmk -d, spiegati nell'articolo sulla riga di comando.

Puoi anche lavorare con più di una chiave SSH. Metti le chiavi in una directory qualsiasi. Nella regola Individual program call instead of agent access devi poi specificare il percorso della rispettiva chiave privata con l'opzione -i. È meglio usare $OMD_ROOT qui al posto del percorso della directory del sito (/omd/sites/mysite). Il comando completo potrebbe quindi essere ssh -i $OMD_ROOT/.ssh/my_key -T root@$HOSTADDRESS$, e così la configurazione sarebbe eseguibile anche in un sito con un nome diverso:

Questo ti permette di utilizzare chiavi SSH diverse per diversi gruppi di host utilizzando più regole diverse.

Per evitare di fornire a potenziali aggressori dati in chiaro nonostante i tunnel SSH, devi disabilitare qualsiasi accesso alla porta 6556 che potrebbe essere ancora disponibile nel monitoraggio sull'host. Se il comando ss -tulpn | grep 6556 sopra riportato non ha trovato alcun processo in ascolto sulla porta TCP 6556, hai finito di configurare il tunnel SSH. Se viene visualizzata una riga, il processo che è stato trovato deve essere disabilitato in modo permanente.

In ogni caso, non dimenticare di fare un test finale. Ora non dovrebbe più essere possibile connettersi alla porta 6556:

La configurazione della crittografia con Agent Bakery funziona così: Con il primo passo, ovvero la creazione della regola "Symmetric encryption (Linux, Windows)", hai quasi finito. Ora devi solo compilare e distribuire i nuovi agenti. Il file "/etc/check_mk/encryption.cfg" viene creato automaticamente per te e sarà incluso nei pacchetti degli agenti. Rimane solo il terzo passo, ovvero la creazione della regola "Enforce agent data encryption".

Anche se un malintenzionato non può eseguire alcun comando, i dati di monitoraggio dell’agente potrebbero comunque essergli utili, poiché contengono, tra le altre cose, un elenco di tutti i processi in esecuzione sul sistema. È quindi meglio che i dati non siano facilmente accessibili a chiunque.

Se condividi l'Agent Checkmk tramite xinetd, è molto facile ed efficace limitare l'accesso a indirizzi IP specifici — e naturalmente a quelli del server di monitoraggio. Questo si può ottenere rapidamente tramite la direttiva only_from nel tuo file di configurazione xinetd. Inserisci gli indirizzi IP o gli intervalli di indirizzi (nel formato 12.34.56.78/29 o 1234::/46) separati da spazi. Sono ammessi anche i nomi host. In questo caso, il sistema verifica se il nome host determinato dalla risoluzione inversa dell'indirizzo IP dell'host richiedente corrisponde a quello inserito:

Nelle edizioni commerciali, gli utenti di Agent Bakery possono configurare gli indirizzi IP consentiti tramite il set di regole Allowed agent access via IP address (Linux, Windows). Questo set di regole è disponibile all'indirizzo Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Generic Options.

Ovviamente, un hacker può facilmente falsificare il proprio indirizzo IP e quindi connettersi all’agente. Ma in questo caso è molto probabile che non riceva la risposta, perché questa andrà al server di monitoraggio legittimo. Oppure l’hacker riceve effettivamente una risposta, ma il server Checkmk non riceve alcun dato e segnalerà rapidamente un errore.