Asegurar el servidor MySQL desde una conexión remota

Los problemas específicos dependen en cierta medida de las razones precisas por las que abre el servidor de esta manera. Sin embargo, no estoy seguro de cuál es la diferencia entre una caída directa de la conexión MySQL (lo que podría suceder de todos modos) y una caída de la conexión SSL tunnelled, en términos de niveles de preocupación.

1. Cambiar el puerto es esencialmente seguridad por oscuridad. Podría reducir la cantidad de ataques vistos ligeramente, pero nunca he visto niveles particularmente altos de tráfico contra puertos de bases de datos en comparación con lo que comúnmente se ve en contra, digamos, puertos SSH. No hay nada malo en hacerlo, siempre y cuando no sean las únicas precauciones de seguridad tomadas. Sin embargo, no espere que detenga a nadie que apunte a su servidor específicamente.
2. Las conexiones SSL para MySQL son sensibles. Asegúrese de que sus clientes estén al tanto del certificado específico que se espera, de lo contrario, sería posible que se produzca un ataque MitM mediante la interceptación y el nuevo cifrado (client-> attacker está cifrado con un certificado de atacante, el atacante descifra y envía al servidor usando server cert, server responde al atacante, que vuelve a cifrar los datos para devolverlos al cliente)
3. Las restricciones de IP son buenas. Puede aplicar la defensa en profundidad aquí: IPTables para permitir las conexiones al servidor, y luego a los usuarios específicos dentro de MySQL solo se les permitirá desde las IP de origen específicas. Tenga en cuenta que los usuarios provienen de rangos de IP dinámicos o compartidos, esto se aplica principalmente a los usuarios que requieren acceso desde dispositivos móviles en algunos países, pero que también pueden resultar de NAT corporativos.
4. Esto también es bueno. Asegúrese de que la raíz todavía tenga una contraseña segura, y no confíe en el acceso desde localhost como la única precaución de seguridad; en particular, permitir el acceso indiscriminadamente a hosts específicos, incluso si es localhost, es una mala idea, ya que debilita el nivel de seguridad. a la del usuario con privilegios más bajos con acceso a ese host.

Sin embargo:

• ¿Sus clientes almacenan las contraseñas de acceso en forma no cifrada? (p. ej., ¿están usando un software para acceder al sistema que no restringe el acceso a las contraseñas si hacen clic en "recordar mi contraseña"?) Esto puede ser abordado por la política (que dice "no haga clic en recordar mi contraseña") o por tecnología (hacer cumplir un cliente específico que no tiene esta función, o implementa la función de manera segura)
• ¿Los datos almacenados son lo suficientemente sensibles como para garantizar el cifrado en reposo?
• ¿Está almacenando registros para el sistema y supervisándolos regularmente?
• ¿El servidor web tiene acceso a los datos que no requiere específicamente? (por ejemplo, si no necesita poder leer la tabla de usuarios de MySQL, ¿se le ha impedido hacerlo?)

Esencialmente, sin conocer los detalles específicos de su configuración, cualquier respuesta solo puede ofrecer sugerencias de lo que normalmente se consideraría "lo suficientemente seguro". Para un banco o para registros médicos, sugeriría que su configuración no sea lo suficientemente segura y que debería consultar a un especialista para que la ayude a garantizarla por completo. Para un sitio web de folletos, sin datos de transacciones y sin datos de clientes, probablemente esté bien. Para cualquier cosa entre ellos, varía.

Hay algo en lo que puedo pensar: la configuración de SSL puede no hacer cumplir todas las conexiones para que sean SSL. Asegúrate de verificar eso.

Aparte de la preocupación anterior, creo que solo sería vulnerable si hubiera un error en Mysql. Si desea mitigar eso, use una VPN (que no es diferente a la tunelización SSH, ya que es un punto adicional de falla potencial), y pídale a Mysql que solo se enlace a la interfaz de red vitrual de la VPN (por ejemplo, tun0).