Conectarse a la base de datos Mysql desde un host remoto sin acceso remoto [cerrado]

Si Mysql solo acepta conexiones locales (según lo configurado a través de CPanel), y las personas que conocen las contraseñas no tienen acceso de shell a su máquina, ni ninguna otra forma de abrir una conexión de red local, entonces no pueden conectarse. a su base de datos y, por lo tanto, su conocimiento de la contraseña no hace una diferencia.

No obstante, está asumiendo el riesgo de que una de estas suposiciones sea violada.

Si en algún momento usted accidentalmente configura incorrectamente las autorizaciones de la base de datos en CPanel, o si decide que necesita conexiones remotas para algún propósito (por ejemplo, porque desea dividir su servicio y poner el frontend y el backend en diferentes máquinas), entonces En este punto sus datos quedarán expuestos. Tendrá que cambiar las contraseñas en ese momento, y cuanto más espere, más lugares tendrá que actualizar y mayor será el riesgo de olvidar que se conocen las contraseñas.

Si en algún momento las personas con las contraseñas obtienen acceso a su máquina, podrán acceder a sus datos. Obviamente, esto puede suceder si obtienen acceso a la shell, pero esa es solo una forma. Incluso si les otorga algún acceso restringido para un propósito diferente, puede permitirles abrir conexiones de red local. La forma más obvia es si les permite usar ese servidor como retransmisión, pero también podría producirse a través de interacciones menos obvias. También es posible que una de las aplicaciones que se ejecutan en su servidor esté parcialmente dañada, por ejemplo, permitiendo una inyección de SQL. Es posible que tenga una aplicación de poca importancia que solo acceda a alguna tabla sin importancia y tenga una vulnerabilidad de inyección de SQL; Si alguien explota esa vulnerabilidad y conoce algunas contraseñas de la base de datos, puede acceder a todas estas otras bases de datos y no solo a la que no es importante.

Como esas personas conocen sus contraseñas, no solo debe confiar en que no las usen mal. También es necesario confiar en ellos para no exponerlos. Incluso si son perfectamente honestos, si almacenan sus contraseñas en un archivo y su máquina se ve comprometida, sus contraseñas se verán comprometidas.

Las conexiones remotas de MySQL están deshabilitadas de forma predeterminada en los servidores de cPanel porque se consideran una amenaza potencial para la seguridad. Mediante las herramientas en el Administrador de host web (WHM) y la interfaz de cPanel a nivel de dominio (generalmente enlace ) se pueden agregar hosts remotos, que El servidor permite conectarse al servicio MySQL. Pero que necesita acceso a tu CPanel.

Por lo general, es seguro, pero es mejor asegurarse de que su CPanel solo tenga acceso a sus usuarios autenticados.

CPanel puede ser explotado por alguien que lee su correo electrónico o intercepta un correo electrónico en su teléfono cuando la cuenta está configurada (si no ha cambiado las contraseñas proporcionadas).

Además, si la contraseña es débil y el atacante conoce la convención de nomenclatura para las cuentas de usuario (y posiblemente las contraseñas creadas por el host), es posible que puedan ingresar a su C-Panel.

En este punto, si alguien obtiene las contraseñas de una cuenta de SSH (o si, por algún motivo, su host usa la misma combinación de Nombre de usuario / Contraseña para SSH que para el Cpanel), pueden ingresar al cuadro con una aplicación como MySQL Workbench a través de un túnel SSH. (Es una de las opciones de seguridad en MySQL).

Ejemplo:

1. El usuario obtiene el inicio de sesión de su cuenta SSH.
2. El usuario cat s su config.php para su sitio web.
3. Añaden username y password de ese archivo a su perfil de MySQL Workbench.
4. Obtienen acceso username tiene derechos para en localhost .

Si alguien obtiene su contraseña SSH, es probable que su servidor MySQL no sea su próximo vector de ataque, pero es posible.

También es posible que en este momento instalen sus propios scripts que se conectan a un servidor MySQL remoto para aprovecharlos (si el servidor está bloqueando la apertura remota de URL).

Esto sucede, pero es el lugar correcto en el momento oportuno. Suena difícil, pero un cliente corporativo registró una cuenta de hosting, enviaron los inicios de sesión a su tipo de TI (y un par de gerentes superiores) ya mí mismo a través del correo electrónico una vez que llegaron al servidor de seguridad del servidor, inicialmente desde el host. . Todos los individuos corporativos obtienen copias de sus correos electrónicos en sus teléfonos inteligentes (algunos de ellos usan redes públicas para revisar sus correos electrónicos como cafeterías y aeropuertos). Una de las secuencias de información se vio comprometida y, dentro de una hora (estaba en el almuerzo cuando llegó el correo electrónico), alguien más ya había configurado la caja y la había explotado cuando probé los inicios de sesión. Fue una nueva instalación de VPS, por lo que no tardó mucho en arreglarlo. Cuando el anfitrión envió los nuevos inicios de sesión para otro VPS diferente, solo les pedí que me los enviaran. Cambié los accesos, los cifré, grabé en disco y envié los inicios de sesión a mis homólogos corporativos (para fines de registro) después de que alteré todos los inicios de sesión y credenciales proporcionados por el host (también eliminé el c-panel en la máquina).

Pensamos en intentar rastrear la fuga, pero fue mucho más fácil implementar nuevas políticas corporativas sobre el inicio de sesión en redes extranjeras, la seguridad de las contraseñas y la cadena de custodia para los inicios de sesión. Una lección para todos.