Se non è necessario, dovrebbe essere chiuso.
vulnerabilità
Non puoi mai essere sicuro che non ci siano vulnerabilità in MySQL stesso. Ecco un esempio di attacco DOS (e non è l'unico possibile attacco ).
Consentire l'accesso remoto non ip ip a MySQL
Consentire l'accesso remoto a MySQL non è una vulnerabilità di per sé, ma ci sono scenari in cui può essere utilizzato in combinazione con altre vulnerabilità.
Ad esempio, diciamo che il sito espone un file di configurazione: chiunque può leggere le credenziali di connessione al database.
Se un utente malintenzionato può anche connettersi al database in remoto, alcuni o tutti i dati sono compromessi (e altri attacchi potrebbero essere anche possibili, ad esempio l'esecuzione di codice se è consentito l'accesso a outfile).
Ma se la connessione remota non è possibile, l'hacker può fare molto poco con questa informazione (supponendo che la password non sia usata da qualche altra parte - es. Ssh - pure).
Il file di configurazione esposto è solo un esempio. Per un altro esempio si consideri l'iniezione di sql cieca: il recupero della password del database è relativamente veloce, ma il recupero dell'intero database richiederebbe un sacco di richieste. Quindi essere in grado di connettersi da remoto ad esso sarebbe molto utile.
Consentire l'accesso remoto ip limitato a MySQL
(Questa è solo una speculazione) Sembra che sia possibile connettersi a MySQL usando udp, quindi è possibile effettuare lo spoofing dell'ip. Potrei immaginare che qualsiasi attacco che non necessiti di feedback diretto (come ad esempio scrivere un codice in un file tramite in outfile) potrebbe funzionare in questo modo (a condizione che vengano acquisite le credenziali del database).
Codifica
Si dovrebbe anche considerare che ssh è crittografato di default, mentre MySQL non lo è (e l'installazione non sembra troppo facile). Ciò significa che la maggior parte degli utenti utilizzerà una connessione non protetta se viene fornito l'accesso diretto a MySQL.