conexiones de base de datos MySQL (no SSL) aseguradas a través de IP de origen / destino, ¿qué tan inseguras son?

0

Estoy probando una solución MySQL de Amazon RDS: la base de datos la proporciona Amazon RDS, pero la lógica de la aplicación (scripts php) que accede a los datos está alojada en otro servidor diferente (no amazon).

Supongamos que por alguna razón no puedo usar las conexiones SSL de MySQL y confío solo en la seguridad proporcionada por las políticas de origen / destino que puede configurar en Amazon VPC: Puedo decir que la instancia de MySQL puede aceptar tráfico SOLAMENTE desde una IP específica (la IP de mi servidor web) y puede enviar tráfico SOLAMENTE a una IP específica (nuevamente, la IP de mi servidor web).

¿Qué tan peligrosa es esta solución? Sé que la pregunta parece demasiado vaga, pero hay algunos detalles específicos que me gustaría aclarar; vamos a tratar de ver qué puede pasar:

1) Los datos (incluidas las credenciales de MySQL) se envían de forma clara a través de Internet, por lo que, si se trata de datos razonables, podría ser visto por un tercero. ¿Qué tan fácil es este ataque? ¿El hecho de que estemos usando IP y no nombres de dominio en la política hace que sea más difícil ejecutar un ataque de intermediario?

2) Supongamos que un atacante logra robar las credenciales de MySQL usando 1), ¿qué tan fácil sería ejecutar consultas arbitrarias en la instancia de MySQL? El atacante debe pretender tener la IP de mi servidor web, operación que debería ser más difícil en "modo de recepción" que en "modo de envío". Así que supongo que hay dos categorías diferentes de consultas que deberíamos considerar por separado:

A: consultas SELECT arbitrarias (en general, consultas que solicitan algún tipo de datos)

B: BORRAR arbitrariamente, ACTUALIZAR, INSERTAR, ... (en general, las consultas que no necesitan una respuesta)

Diría que las consultas B son más fáciles de ejecutar, pero esto podría depender de otros factores, como el protocolo específico utilizado por MySQL.

    
pregunta Eugenio 10.05.2016 - 16:44
fuente

1 respuesta

3

Tiene razón al preocuparse por los escenarios que presentó:

  1. Si se produce un ataque MITM, no se puede frustrar a menos que use SSL. El filtro de IP no ayudará porque el ataque ya está "en el medio" de la conexión, por lo que todo el tráfico pasará a través de él en texto sin formato. Una vez que el usuario / el pase es capturado, el atacante puede hacer lo que esas credenciales permitan. El atacante podría incluso falsificar la IP y secuestrar la conexión sin permitir que el tráfico vuelva a la IP original, si así lo desean.
  2. Para los ataques que no son MITM, el filtro de IP ayuda bastante, porque incluso la falsificación de IP solo permitiría que los mensajes se envíen, pero no se reciban, e incluso en ese caso aún necesitarían averiguar primero las credenciales. Si de alguna manera hubieran descubierto las credenciales, podrían falsificar su IP de origen y enviar comandos como eliminar, actualizar, insertar, etc., pero sería bastante difícil saber si estaba teniendo algún efecto, por lo que sería inútil para que lo intenten. (Como tirar piedras a un lago y preguntarse si está golpeando algún pez en el camino hacia abajo).

Su mejor apuesta es usar SSL o al menos mover la aplicación y la base de datos a la misma red. Si no puedes hacer eso, MITM es el ataque más realista del que deberías preocuparte, pero incluso esos son bastante raros, en comparación con otros tipos de ataques que se intentarán. Probablemente es más probable que un desarrollador pierda accidentalmente las credenciales que un MITM en su contra.

    
respondido por el TTT 10.05.2016 - 18:28
fuente

Lea otras preguntas en las etiquetas