Protezione del server MySQL dalla connessione remota

I problemi specifici dipendono in una certa misura dalle precise ragioni per cui stai aprendo il server in questo modo. Tuttavia, non sono sicuro di quale sia la differenza tra una connessione MySQL diretta che si interrompe (cosa che potrebbe accadere comunque) e una connessione SSL con collegamento a tunnel che scenda, in termini di livelli di preoccupazione.

1. Cambiare la porta è essenzialmente la sicurezza dall'oscurità. Potrebbe ridurre il numero di attacchi visti leggermente, ma non ho mai visto livelli particolarmente elevati di traffico contro le porte di un database se confrontato con ciò che si vede comunemente contro, diciamo, le porte SSH. Non c'è nulla di male nel farlo, purché non siano le uniche precauzioni di sicurezza adottate. Non aspettarti che impedisca a nessuno di indirizzare il tuo server in modo specifico.
2. Le connessioni SSL per MySQL sono sensate. Assicurati che i tuoi clienti siano a conoscenza del certificato specifico che si aspetta, altrimenti sarebbe possibile che un attacco MitM avvenga tramite intercettazione e re-crittografia (l'hacker client-gt è crittografato con il cert d'attacco, l'hacker decrittografa e invia al server usando server cert, server risponde a un utente malintenzionato, che re-crittografa i dati per tornare al client)
3. Le restrizioni IP sono buone. È possibile applicare la difesa in modo approfondito qui - IPTables per consentire le connessioni al server, quindi gli utenti specifici di MySQL possono essere autorizzati solo da specifici IP di origine. Presta attenzione agli utenti che provengono da intervalli IP dinamici o condivisi: ciò si applica principalmente agli utenti che richiedono l'accesso da dispositivi mobili in alcuni Paesi, ma possono anche derivare da NAT aziendali.
4. Anche questo è buono. Assicurati che la root abbia ancora una password sicura e non si basi sull'accesso da localhost come unica precauzione di sicurezza - in particolare, consentire l'accesso indiscriminatamente a host specifici, anche se è localhost, è una cattiva idea, poiché indebolisce il livello di sicurezza a quello dell'utente con privilegi più bassi con accesso a quell'host.

Tuttavia:

• I tuoi clienti memorizzano le password di accesso in una forma non criptata? (ad esempio, stanno utilizzando il software per accedere al sistema che non limita l'accesso alle password se fanno clic su "ricorda la mia password"?) Questo potrebbe essere risolto dalla politica (dicendo "non fare clic su ricordare la mia password") o dalla tecnologia (imporre un client specifico che non ha questa funzione o implementa in modo sicuro la funzione)
• I dati memorizzati sono abbastanza sensibili da garantire la crittografia a riposo?
• Stai memorizzando i registri per il sistema e monitorandoli regolarmente?
• Il server Web ha accesso a tutti i dati che non richiede specificamente? (ad esempio se non ha bisogno di essere in grado di leggere la tabella degli utenti MySQL, è stato impedito di farlo?)

Essenzialmente, senza conoscere i dettagli specifici della tua configurazione, qualsiasi risposta può offrire solo suggerimenti su ciò che normalmente sarebbe considerato "abbastanza sicuro". Per una banca o per le cartelle cliniche, suggerirei che la configurazione non è abbastanza sicura e che dovresti entrare in uno specialista per aiutarlo a proteggerlo completamente. Per un sito web di brochure, senza dati sulle transazioni e senza dati sui clienti, probabilmente è corretto. Per qualsiasi cosa tra loro, varia.

Una cosa che posso pensare: l'impostazione di SSL non può imporre tutte le connessioni come SSL. Assicurati di verificarlo.

A prescindere dalla preoccupazione di cui sopra, penso che sarebbe vulnerabile solo se ci fosse un bug in Mysql stesso. Se vuoi mitigarlo, usa una VPN (che non è dissimile dal tunneling SSH, poiché è un ulteriore punto di potenziale fallimento) e dì a Mysql di collegarsi solo all'interfaccia di rete vitruale della VPN (ad esempio tun0).