Come proteggere i server MySQL/MariaDB

Dopo gli attacchi ai database MongoDB, di recente abbiamo anche visto che i server MySQL sono presi di mira dai ransomware. Ciò non dovrebbe sorprendere, vista la crescente adozione di cloud pubblici e privati. L'esecuzione di un database mal configurato nel cloud può diventare una grave responsabilità.

In questo post del blog condivideremo con te una serie di suggerimenti su come proteggere e proteggere i tuoi server MySQL o MariaDB.

Capire il vettore di attacco

Citando SCMagazine:
“L'attacco inizia con la forzatura bruta della password di root per il database MySQL. Una volta effettuato l'accesso, vengono recuperati i database e le tabelle MySQL. L'attaccante crea quindi una nuova tabella chiamata "WARNING" che include un indirizzo email di contatto, un indirizzo bitcoin e una richiesta di pagamento. ”

Sulla base dell'articolo, il vettore di attacco inizia indovinando la password di root di MySQL tramite il metodo della forza bruta. L'attacco a forza bruta consiste in un utente malintenzionato che prova molte password o passphrase con la speranza di indovinare eventualmente correttamente. Ciò significa che le password brevi di solito possono essere rilevate abbastanza rapidamente, ma le password più lunghe possono richiedere giorni o mesi.

La forza bruta è un attacco comune che accadrebbe a qualsiasi servizio. Sfortunatamente per MySQL (e molti altri DBMS), non esiste una funzionalità pronta all'uso che rilevi e blocchi gli attacchi di forza bruta da indirizzi specifici durante l'autenticazione dell'utente. MySQL tuttavia cattura gli errori di autenticazione nel registro degli errori.

Rivedi la tua politica sulla password

La revisione della politica della password MySQL è sempre il primo passo per proteggere il tuo server. La password di root di MySQL dovrebbe essere abbastanza forte con una combinazione di alfabeti, numeri e simboli (il che rende più difficile da ricordare) e conservata in un luogo sicuro. Modificare la password regolarmente, almeno ogni trimestre solare. In base al vettore di attacco, questo è il punto più debole che gli hacker prendono di mira. Se apprezzi i tuoi dati, non trascurare questa parte.

Le implementazioni MySQL eseguite da ClusterControl seguiranno sempre le migliori pratiche di sicurezza del fornitore, ad esempio non ci sarà alcun host con caratteri jolly definito durante GRANT e le credenziali di accesso sensibili memorizzate nel file di configurazione sono consentite solo all'utente root del sistema operativo. Consigliamo vivamente ai nostri utenti di specificare una password complessa durante la fase di distribuzione.

In un ambiente di produzione standard, i server di database si trovano in genere in un livello di livello inferiore. Questo livello deve essere protetto e accessibile solo dal livello superiore, come l'applicazione o il servizio di bilanciamento del carico. Se il database si trova insieme all'applicazione, puoi persino bloccare indirizzi non locali e utilizzare invece il file socket MySQL (meno sovraccarico e più sicuro).

La configurazione del parametro "bind-address" è fondamentale qui. Tieni presente che l'associazione MySQL è limitata a nessuno, uno o tutti gli indirizzi IP (0.0.0.0) sul server. Se non hai scelta e hai bisogno che MySQL ascolti tutte le interfacce di rete, limita l'accesso al servizio MySQL da fonti note e valide. Utilizza un'applicazione firewall o un gruppo di sicurezza per autorizzare l'accesso solo dagli host che devono accedere direttamente al database.

A volte, il server MySQL deve essere esposto a una rete pubblica per scopi di integrazione (ad es. monitoraggio, auditing, backup, ecc.). Va bene fintanto che disegni un bordo attorno ad esso. Non lasciare che fonti indesiderate "vedano" il server MySQL. Puoi scommettere quante persone nel mondo sanno che 3306 è la porta predefinita per il servizio MySQL e, semplicemente eseguendo una scansione delle porte rispetto a un indirizzo di rete, un utente malintenzionato può creare un elenco di server MySQL esposti nella sottorete in meno di un minuto. Si consiglia di utilizzare una porta MySQL personalizzata configurando il parametro "port" nel file di configurazione di MySQL per ridurre al minimo il rischio di esposizione.

Esaminare le Norme per l'utente

Limita determinati utenti a detenere i diritti di amministrazione critici, in particolare GRANT, SUPER e PROCESS. Puoi anche abilitare super_read_only se il server è uno slave, disponibile solo su MySQL 5.7.8 e Percona Server 5.6.21 e versioni successive (purtroppo non con MariaDB). Quando abilitato, il server non consentirà alcun aggiornamento, oltre all'aggiornamento dei repository di replica se i log di stato slave sono tabelle, anche per gli utenti che dispongono del privilegio SUPER. Rimuovere il database di test predefinito e tutti gli utenti con password vuote per restringere l'ambito di penetrazione. Questo è uno dei controlli di sicurezza eseguiti da ClusterControl, implementato come database advisor.

È anche una buona idea limitare il numero di connessioni consentite a un singolo account. Puoi farlo impostando la variabile max_user_connections in mysqld (il valore predefinito è 0, uguale a illimitato) o utilizzare le opzioni di controllo delle risorse nelle istruzioni GRANT/CREATE USER/ALTER USER. L'istruzione GRANT supporta la limitazione del numero di connessioni simultanee al server tramite un account, ad esempio:

mysql> GRANT ALL PRIVILEGES ON db.* TO 'db_user'@'localhost' WITH MAX_USER_CONNECTIONS 2;

Il nome utente dell'amministratore predefinito sul server MySQL è "root". Gli hacker spesso tentano di ottenere l'accesso alle sue autorizzazioni. Per rendere questo compito molto più difficile, rinomina "root" in qualcos'altro. I nomi utente MySQL possono contenere fino a 32 caratteri (16 caratteri prima di MySQL 5.7.8). È possibile utilizzare un nome utente più lungo per l'utente super amministratore utilizzando l'istruzione RENAME come mostrato di seguito:

mysql> RENAME USER root TO new_super_administrator_username;

Una nota a margine per gli utenti di ClusterControl, ClusterControl ha bisogno di conoscere l'utente root e la password MySQL per automatizzare e gestire il server di database per te. Per impostazione predefinita, cercherà "root". Se rinomini l'utente root in qualcos'altro, specifica "monitored_mysql_root_user={new_user}" all'interno di cmon_X.cnf (dove X è l'ID del cluster) e riavvia il servizio CMON per applicare la modifica.

Normativa di backup

Anche se gli hacker hanno dichiarato che avresti recuperato i tuoi dati una volta pagato il riscatto, di solito non era così. L'aumento della frequenza di backup aumenterebbe la possibilità di ripristinare i dati eliminati. Ad esempio, invece di un backup completo una volta alla settimana con backup incrementale giornaliero, è possibile pianificare un backup completo una volta al giorno con backup incrementale orario. Puoi farlo facilmente con la funzione di gestione del backup di ClusterControl e ripristinare i tuoi dati se qualcosa va storto.

Se hai i log binari (binlog) abilitati, è ancora meglio. Puoi creare un backup completo ogni giorno ed eseguire il backup dei log binari. I binlog sono importanti per il ripristino point-in-time e dovrebbero essere sottoposti a backup regolarmente come parte della procedura di backup. I DBA tendono a perdere questo semplice metodo, che vale ogni centesimo. Nel caso in cui tu sia stato violato, puoi sempre ripristinare l'ultimo punto prima che accadesse, a condizione che gli hacker non abbiano eliminato i log binari. Tieni presente che l'eliminazione dei log binari è possibile solo quando l'attaccante ha il privilegio SUPER.

Un'altra cosa importante è che i file di backup devono essere ripristinabili. Verifica i backup ogni tanto ed evita brutte sorprese quando devi eseguire il ripristino.

Proteggi il tuo server web/applicativo

Bene, se hai isolato i tuoi server MySQL, ci sono ancora possibilità che gli aggressori possano accedervi tramite il web o il server delle applicazioni. Iniettando uno script dannoso (ad es. Cross-Site Scripting, SQL injection) sul sito Web di destinazione, è possibile accedere alla directory dell'applicazione e avere la possibilità di leggere i file dell'applicazione. Questi potrebbero contenere informazioni riservate, ad esempio le credenziali di accesso al database. Osservando questo, un utente malintenzionato può semplicemente accedere al database, eliminare tutte le tabelle e lasciare una tabella di "riscatto" all'interno. Non deve essere necessariamente un utente root MySQL per riscattare una vittima.

Esistono migliaia di modi per compromettere un server Web e non puoi davvero chiudere la porta in entrata 80 o 443 per questo scopo. È necessario un altro livello di protezione per salvaguardare il server Web dalle iniezioni basate su HTTP. Puoi utilizzare Web Application Firewall (WAF) come Apache ModSecurity, NAXSI (WAF per nginx), WebKnight (WAF per IIS) o semplicemente eseguire i tuoi server Web in una rete di distribuzione dei contenuti (CDN) sicura come CloudFlare, Akamai o Amazon CloudFront.

Rimani sempre aggiornato

Probabilmente hai sentito parlare dell'exploit critico zero-day MySQL, in cui un utente non privilegiato può passare a superutente? Sembra spaventoso. Fortunatamente, tutti i fornitori noti hanno aggiornato il proprio repository per includere una correzione di bug per questo problema.

Per l'uso in produzione, si consiglia vivamente di installare i pacchetti MySQL/MariaDB dal repository del fornitore. Non fare affidamento sul repository del sistema operativo predefinito, dove i pacchetti sono generalmente obsoleti. Se stai eseguendo in un ambiente cluster come Galera Cluster, o anche MySQL Replication, hai sempre la possibilità di applicare patch al sistema con tempi di inattività minimi. Trasformalo in una routine e prova ad automatizzare il più possibile la procedura di aggiornamento.

ClusterControl supporta l'aggiornamento in sequenza delle versioni secondarie (un nodo alla volta) per MySQL/MariaDB con un solo clic. L'aggiornamento delle versioni principali (ad esempio, da MySQL 5.6 a MySQL 5.7) richiede comunemente la disinstallazione dei pacchetti esistenti ed è un'attività rischiosa da automatizzare. Un'attenta pianificazione e test è necessaria per questo tipo di aggiornamento.

Conclusione

Il ransomware è una pentola d'oro con soldi facili. Probabilmente vedremo più violazioni della sicurezza in futuro ed è meglio agire prima che accada qualcosa. Gli hacker stanno prendendo di mira molti server vulnerabili e molto probabilmente questo attacco si diffonderà anche ad altre tecnologie di database. La protezione dei dati è una sfida costante per gli amministratori di database. Il vero nemico non è l'autore del reato, ma il nostro atteggiamento verso la protezione delle nostre risorse critiche.