Monitoraggio di Linux in modalità legacy

Una descrizione esaustiva dell'installazione dai pacchetti deb o rpm è contenuta nell'articolo sul Monitoraggio di Linux, quindi in questa sede ci limiteremo a illustrare la procedura in modo sintetico.

In Checkmk Raw, puoi trovare i pacchetti Linux dell'agente tramite Setup > Agents > Linux. Nelle edizioni commerciali, per prima cosa accedi all'Agent bakery nel menu Setup tramite Agents > Windows, Linux, Solaris, AIX, dove troverai i pacchetti baked. 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 o 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 avviene come root con il comando dpkg -i:

Per un'installazione comoda e indipendente dalla distribuzione, è necessario l'agente Linux nel formato dell'archivio TGZ ("Tarball"), che puoi scaricare dalle edizioni commerciali nel menu di configurazione tramite Agents > Windows, Linux, Solaris, AIX. L'archivio TGZ contiene la struttura completa delle directory dell'agente Linux da scompattare nella directory principale dell'host monitorato.

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

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

Se qui viene stampato un numero di versione inferiore a 2.2.0, probabilmente hai ancora una versione precedente dello script agente installato 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 agente è raramente necessaria, ma non è nemmeno molto difficile. In questo tipo di installazione, all'inizio viene installato solo lo script agente, ma non viene ancora eseguita la configurazione dell'accesso. A questo scopo è necessario il box Agents dalla pagina dei file agente. Lì troverai il file check_mk_agent.linux:

Carica questo file sul file system di destinazione e copialo in una directory eseguibile per root./usr/local/bin/ è una buona scelta, poiché si trova nel percorso di ricerca ed è destinato alle estensioni personalizzate. In alternativa, puoi utilizzare /usr/bin o una sottodirectory di /opt. Noi utilizziamo /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. | head tronca tutto ciò che segue la decima riga di output:

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

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

Se vuoi utilizzare percorsi diversi, modifica semplicemente /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 sono dotati di uno script che automatizza i due passaggi necessari: prima installa la configurazione e poi fa in modo che xinetd rilegga le impostazioni modificate. Devi chiamare lo script con i percorsi completi dei file:

Se installi lo script 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. Ulteriori opzioni di configurazione possono essere visualizzate consultando 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 solo grande /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 /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 è identica a quella della tabella IANA con un solo trattino:

Il formato del file di configurazione di /etc/inetd.conf varia da una variante all'altra. Fai riferimento ai commenti nel file di configurazione e alla 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 notare la notazione corretta:

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

A seconda del sistema di init utilizzato e del superserver installato, questo comando potrebbe essere diverso.

Per prima cosa verifica se xinetd o inetd possono essere (ri)avviati:

Ora puoi connetterti con 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 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 che segue, utilizza il comando ssh-keygen -t ed25519 come utente dell'istanza:

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

Importante: Non specificare una passphrase: criptare il file con la chiave segreta non servirebbe a nulla, dopotutto non vuoi 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 dell'istanza (-rw-------) - e questo è un bene! La chiave pubblica id_ed25519.pub ha un aspetto simile a questo:

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

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

Copia il contenuto delle chiavi pubbliche in questo file, ad esempio con il mouse e copia e incolla. Sii preciso: ogni spazio conta. Assicurati anche che non ci siano mai due spazi in una riga. E: Se il file esiste già, è sufficiente aggiungere una nuova riga in basso.

La chiave SSH deve essere utilizzata esclusivamente per l'esecuzione dell'agente. SSH offre qualcosa di simile con il nome di restrizione del comando. Per farlo, inserisci il testo command="/usr/bin/check_mk_agent" all'inizio della riga che hai appena creato, separato dal resto da un singolo spazio. Avrà un aspetto simile a questo:

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

Successivamente, verifica l'accesso all'agente con il comando ssh:

La prima volta dovrai confermare l'impronta digitale della chiave digitando yes. Tutti gli altri accessi possono essere effettuati senza l'interazione dell'utente, compreso il polling automatico dello script dell'agente 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 in authorized_keys. SSH utilizzerà quindi automaticamente la chiave più forte conosciuta per la connessione.

Il sistema di destinazione è stato preparato. Ora manca solo la configurazione di Checkmk stesso, che si effettua 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 con un timeout o un accesso negato, controlla se hai utilizzato il nome host con la stessa ortografia utilizzata per il test da linea di comando: OpenSSH distingue tra nome host breve, 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 cache (di Checkmk) dell'host.

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

Puoi anche lavorare con più di una chiave SSH. Posiziona le chiavi in una qualsiasi directory. Nella regola Individual program call instead of agent access devi poi specificare il percorso della rispettiva chiave privata con l'opzione -i. È meglio utilizzare $OMD_ROOT in sostituzione del percorso della directory del sito (/omd/sites/mysite). Il comando completo potrebbe essere ssh -i $OMD_ROOT/.ssh/my_key -T root@$HOSTADDRESS$ e quindi 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 port monitoring dell'host. Se il comando ss -tulpn | grep 6556 di cui sopra non ha trovato alcun processo in ascolto sulla porta TCP 6556, hai finito di configurare il tunnel SSH. Se viene emessa una riga, il processo che è stato trovato deve essere disabilitato in modo permanente.

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

L'impostazione della crittografia con l'Agent Bakery si svolge in questo modo: con il primo passo, la creazione della regola Symmetric encryption (Linux, Windows), hai quasi finito. Ora devi solo preparare 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, cioè la creazione della regola Enforce agent data encryption.

Anche se un aggressore non può eseguire alcun comando, i dati di monitoraggio dell'agente potrebbero comunque essergli utili perché 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'agente Checkmk tramite xinetd, è molto semplice ed efficace limitare l'accesso a indirizzi IP specifici e, ovviamente, a quelli del server monitoring. Questo può essere ottenuto rapidamente tramite la direttiva only_from nel file di configurazione xinetd. Inserisci indirizzi IP o intervalli di indirizzi (nel modulo 12.34.56.78/29 o 1234::/46) separati da spazi. Sono ammessi anche i nomi di host. In questo caso, il sistema controlla 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.

Naturalmente, un utente malintenzionato può facilmente falsificare il proprio indirizzo IP e connettersi all'agente Checkmk, ma è molto probabile che non riceva alcuna risposta, perché la risposta viene inviata al server di monitoraggio legittimo. Oppure l'utente malintenzionato riceve effettivamente una risposta, ma il server Checkmk non riceve alcun dato e segnala rapidamente un errore.