Sicurezza preventiva con registrazione di audit per MongoDB

La sicurezza del database è un argomento ampio che va dalle misurazioni preventive all'esclusione di visitatori indesiderati. Anche se saresti in grado di proteggere completamente i tuoi server MongoDB, vorresti comunque sapere se qualcuno ha tentato di entrare nel tuo sistema. E se riescono a violare la tua sicurezza e installare l'hack di riscatto MongoDB, avresti bisogno di un audit trail per l'autopsia o per adottare nuove misure preventive. Un registro di controllo ti consentirebbe di tenere traccia di chiunque tenti di accedere e vedere cosa ha fatto nel tuo sistema.

La versione MongoDB Enterprise contiene la possibilità di abilitare il registro di controllo, ma la versione community manca di questa funzionalità. Percona ha creato la propria funzionalità di registrazione degli audit nel Percona Server per MongoDB derivato da MongoDB. Gli approcci MongoDB e Percona sono diversi tra loro e spiegheremo come configurarli e utilizzarli entrambi.

Registrazione di controllo MongoDB

Il registro di controllo di MongoDB è facile da configurare:per abilitare la registrazione di controllo su un file JSON, aggiungi semplicemente la seguente sezione al tuo file di configurazione e riavvia MongoDB:

auditLog:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

MongoDB supporta file, console e syslog come destinazioni. Per i formati di file sono disponibili due opzioni:JSON e BSON. In JSON le righe del registro di controllo sono simili a questa:

{ "atype" : "authCheck", "ts" : { "$date" : "2017-02-15T22:20:08.322-0000" }, "local" : { "ip" : "127.0.0.1", "port" : 27017 }, "remote" : { "ip" : "127.0.0.1", "port" : 63357 }, "users" : [], "roles" : [], "param" : { "command" : "update", "ns" : "test.inserttest", "args" : { "update" : "preauth_case", "updates" : [ { "q" : { "createdByUserId" : -2 }, "u" : { "$set" : { "statusCode" : "Update" } }, "multi" : false, "upsert" : false } ], "ordered" : true } }, "result" : 0 }

La configurazione sopra abiliterebbe il registro di controllo per ogni azione da parte di qualsiasi utente del sistema. Se hai una concorrenza elevata, ciò ridurrebbe drasticamente le prestazioni del tuo cluster MongoDB. Per fortuna, c'è la possibilità di filtrare gli eventi che devono essere registrati.

I filtri per la registrazione dell'audit possono essere posizionati sul tipo di query, sull'utente/ruolo che esegue la query o sulla raccolta su cui viene eseguita la query. La documentazione sulla registrazione degli audit su MongoDB è molto ampia e lunga con molti esempi. Di seguito daremo alcuni degli esempi più importanti.

Autenticazione rispetto a una raccolta specifica:

    filter: '{ atype: "authenticate", "param.db": "test" }'

Log per più tipi di audit:

    filter: '{ atype: { $in [ "update", "delete" ]}, "param.db": "test" }'

Registra tutti i controlli di autenticazione per inserimenti/aggiornamenti/eliminazioni su una raccolta specifica:

    filter: '{ atype: "authCheck", "param.ns": "test.orders", "param.command": { $in: [ "find", "insert", "delete", "update", "findandmodify" ] } }'

Come puoi vedere, i filtri possono essere abbastanza flessibili e saresti in grado di filtrare i messaggi di cui hai bisogno per il tuo audit trail.

Server Percona per registrazione di controllo MongoDB

La registrazione di controllo di Percona Server per MongoDB è limitata al file JSON. La maggior parte degli utenti accederà solo ai file JSON, ma non è chiaro se Percona aggiungerà altre funzionalità di registrazione in futuro.

A seconda della versione di Percona Server per MongoDB, la configurazione potrebbe essere diversa. Al momento della scrittura, tutte le versioni hanno la seguente sintassi:

audit:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

Tuttavia questa differenza di configurazione è stata recentemente risolta, ma deve ancora essere rilasciata. Dopo il rilascio, dovrebbe seguire nuovamente la direttiva auditLog di MongoDB:

auditLog:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

Il format di Percona è leggermente diverso:

{ "atype" : "authenticate", "ts" : { "$date" : { "$numberLong" : "1487206721903" } }, "local" : { "host" : "n3", "port" : 27017 }, "remote" : { "host" : "172.16.140.10", "port" : 50008 }, "users" : [ { "user" : "admin", "db" : "admin" } ], "params" : { "user" : "admin", "db" : "admin", "mechanism" : "SCRAM-SHA-1" }, "result" : 0 }

Al contrario di MongoDB che registra tutto, Percona ha scelto di registrare solo i comandi importanti. A giudicare dall'origine del plug-in di controllo Percona, sono supportate le seguenti query:autenticazione, creazione/aggiornamento/eliminazione utenti, aggiunta/aggiornamento/rimozione ruoli, creazione/eliminazione database/indice e la maggior parte dei comandi di amministrazione importanti.

Anche il filtraggio del registro di controllo di Percona Server per MongoDB non sembra seguire lo stesso standard di MongoDB. Non è chiaro quale siano l'esatta sintassi e le opzioni del filtro poiché la documentazione di Percona è molto concisa al riguardo.

Abilitare l'auditlog senza filtrare ti darebbe voci più che sufficienti nel tuo file di registro. Da qui puoi restringere il filtro, poiché segue la sintassi JSON delle voci di registro.

Utilizzo dell'Audit Log

Per semplificarti la vita, potrebbe essere la soluzione migliore inserire il log di controllo in un framework di analisi dei log. Uno stack ELK è un ambiente eccellente in cui eseguire le tue analisi e ti consente di approfondire abbastanza facilmente livelli più dettagliati. L'utilizzo di un mappatore di campi ti consentirebbe persino di eseguire l'audit trail all'interno di ELK.

Come descritto nell'introduzione, possiamo utilizzare il registro di controllo per vari scopi di sicurezza. Il più ovvio è quando ne hai bisogno come riferimento durante un'autopsia. Il registro di controllo di MongoDB fornisce una panoramica dettagliata di ciò che è accaduto esattamente. Il registro di controllo di Percona contiene un po' meno informazioni, ma dovrebbe essere sufficiente per la maggior parte delle autopsie. L'utilizzo del registro di controllo per l'autopsia è fantastico, anche se avremmo preferito evitare il problema in primo luogo.

Un altro scopo per il registro di controllo è vedere le tendenze in atto ed è possibile impostare trap su un determinato messaggio del registro di controllo. Un buon esempio potrebbe essere controllare il tasso di tentativi di autenticazione (falliti) e se questo supera una certa soglia, agire di conseguenza. A seconda della situazione, l'azione intrapresa potrebbe differire. Un'azione potrebbe essere quella di bloccare automaticamente l'indirizzo IP da cui provengono le richieste, ma in un altro caso è possibile consultare l'utente sul motivo per cui la password è stata dimenticata. Dipende molto dal caso e dall'ambiente in cui lavori.

Un'altra misurazione preventiva avanzata sarebbe l'utilizzo di MongoDB come honeypot e l'utilizzo del registro di controllo per catturare utenti indesiderati. Esponi semplicemente MongoDB e consenti a chiunque di connettersi al tuo server MongoDB. Quindi utilizzare il registro di controllo per rilevare cosa faranno gli utenti se sono autorizzati a fare cose oltre i loro normali poteri e bloccarli se necessario. La maggior parte degli umani preferisce la via facile piuttosto che quella difficile, quindi l'honeypot potrebbe deviare un attacco e l'hacker passerà al prossimo obiettivo.

Conclusione

Oltre a spiegare come impostare il registro di controllo sia per MongoDB Enterprise che Percona Server per MongoDB, abbiamo anche spiegato cosa potresti potenzialmente fare con i dati registrati all'interno del registro di controllo.

Per impostazione predefinita, ClusterControl non abilita il registro di controllo, ma è relativamente facile abilitarlo a livello di cluster utilizzando il nostro Config Manager. Puoi anche abilitarlo all'interno dei modelli di configurazione, prima di distribuire un nuovo cluster.

Buon raggruppamento!