CONEXIONES SEGURASEN MYSQL

Administración de Gestores de Bases de datos 16/11/2012

ÍNDICE

1.-Conexión por SSL________________________________________3

1.1.-La necesidad de la seguridad__________________________________3

1.2.-¿Qué es SSL?_______________________________________________3

1.3.-¿Qué es el estándar X509?____________________________________ 3

1.4.-¿Cómo funciona el estándar x509?_____________________________ 3

1.5.-¿Cómo funciona el protocolo SSL?_____________________________ 4

1.6.-Ventajas y desventajas del uso de SSL.__________________________6

1.7.-SSL en MySQL_____________________________________________ 6

2.-Conexión por SSH________________________________________7

2.1.-¿Qué es SSH?________________________________________________7

2.2.-¿Cómo funciona?_____________________________________________7

2.3.-Características a grandes rasgos:________________________________8

2.4.-¿Qué es un túnel SSH?________________________________________ 8

2.5.-Túneles SSH en MySQL_______________________________________9

2.6.-Ventajas e inconvenientes de SSH_______________________________9

2.7.-Levantando nuestro propio Túnel SSH en Windows 7______________10

3.- Webgrafia______________________________________________ 16

2

1.-CONEXIÓN POR SSL

1.1.-La necesidad de securizar:

Para entender como se usa SSL en MySQL es necesario explicar brevemente algunos conceptos básicos de SSL y X509. Por defecto, MySQL usa conexiones no encriptadas entre el cliente y el servidor, lo que significa que alguien podría ver e incluso modificar los datos que están siendo enviados o recibidos entre el cliente y el servidor. Un defecto en la seguridad de MySQL puede ser crítico para una empresa debido a que la información que se manejan en las bases de datos es de gran valor, y se persigue antes todo mantener la integridad y la confiabilidad de los datos.

1.2.-¿Qué es SSL?

SSL es un protocolo que usa diferentes algoritmos de encriptación para asegurarse de que los datos que viajan a través de una red pública (como pueda ser Internet) puedan ser fiables. Este protocolo tiene un mecanismo para detectar cualquier cambio o pérdida de los datos, además de incorporar algoritmos para la verificación de identidad usando el estándar X509.

1.3.-¿Qué es el estándar X509?

X509 es un estándar UIT-T para infraestructuras de claves públicas. Especifica, entre otras cosas, formatos estándar para certificados de claves públicas y un algoritmo de validación de la ruta de certificación.Comúnmente, se le conoce también como el estándar que hace posible identificar a alguien en Internet. Se usa habitualmente en aplicaciones de comercio electrónico.

1.4.-¿Cómo funciona el estándar x509?

En términos simples, debe haber un organismo que asigne certificados electrónicos a las personas u organizaciones que los necesiten. Estos certificados se basan en un algoritmo que tiene dos claves de encriptación (una clave pública, y una clave secreta).El dueño de un certificado puede probar su identidad al mostrar su certificado a la otra parte. Este certificado consiste en su clave pública. Cualquier dato que se haya encriptado con esta clave pública puede ser desencriptado únicamente con la correspondiente clave secreta, que debe pertenecer al dueño del mismo certificado.

3

1.5.-¿Cómo funciona el protocolo SSL?

Antes de que se establezca SSL, se debe hacer una solicitud. Típicamente esto implica un cliente haciendo una solicitud de un URL a un servidor que soporte SSL. SSL acepta solicitudes por un puerto diferente al utilizado normalmente para ese servicio. Una vez se ha hecho la solicitud, el cliente y el servidor empiezan a negociar la conexión SSL, es decir, hacen el SSL Handshake.

SSL Handshake:

Durante el hanshake se cumplen varios propósitos. Se hace autenticación del servidor y opcionalmente del cliente, se determina que algoritmos de criptografía serán utilizados y se genera una llave secreta para ser utilizada durante el intercambio de mensajes subsiguientes durante la comunicación SSL. Una conexión SSL siempre es iniciada por el cliente. Al principio de una sesión SSL, se realiza un protocolo de enlace SSL. Este protocolo de enlace produce los parámetros criptográficos de la sesión. En este ejemplo se supone que se está estableciendo la conexión SSL entre un navegador web y un servidor web.

Protocolo de enlace SSL con autenticación de servidor

1. El cliente envía el mensaje "hello" que lista las posibilidades criptográficas del cliente (clasificadas por orden de preferencia del cliente), como la versión de SSL, los grupos de programas de cifrado soportados por el cliente y los métodos de compresión de datos soportados por el cliente. El mensaje también contiene un número aleatorio de 28 bytes.

2. El servidor responde con el mensaje "hello" del servidor que contiene el método criptográfico (conjunto de programas de cifrado) y el método de compresión de datos seleccionados por el servidor, el ID de sesión y otro número aleatorio. Nota: El cliente y el servidor deben dar soporte como mínimo a un conjunto de cifrado común; de lo contrario, el protocolo de enlace dará error. Generalmente, el servidor elige el conjunto de programas de cifrado común más potente.

4

3. El servidor envía su certificado digital. (El servidor utiliza certificados digitales X.509 V3 con SSL.) Si el servidor utiliza SSL V3 y si la aplicación de servidor (por ejemplo, el servidor web) requiere un certificado digital para la autenticación de cliente, el servidor envía el mensaje "digital certificate request". En el mensaje "digital certificate request", el servidor envía una lista de los tipos de certificados digitales soportados y los nombres distinguidos de autoridades de certificación aceptables.

4. El servidor envía el mensaje "hello done" de servidor y aguarda una respuesta del cliente.

5. Al recibir el mensaje "hello done" del servidor, el cliente (el navegador web) verifica la validez del certificado digital del servidor y comprueba que los parámetros del mensaje "hello" del servidor son aceptables. Si el servidor ha solicitado un certificado digital del cliente, el cliente envía un certificado digital o, si no hay ningún certificado digital adecuado disponible, el cliente envía la alerta "no digital certificate". Esta alerta sólo es un aviso, pero la aplicación de servidor puede hacer que la sesión sea anómala si la autenticación del cliente es obligatoria.

6. El cliente envía el mensaje "client key exchange". Este mensaje contiene el secreto pre-maestro, un número aleatorio de 46 bytes utilizado en la generación de las claves de cifrado simétrico y las claves de código de autenticación de mensajes (MAC), cifradas con la clave pública del servidor. Si el cliente ha enviado un certificado digital al servidor, el cliente envía un mensaje "digital certificate verify" firmado con la clave privada del cliente. Al verificar la firma de este mensaje, el servidor puede verificar explícitamente la propiedad del certificado digital del cliente.

-A tener en cuenta:

No es necesario un proceso adicional para verificar el certificado digital del servidor. Si el servidor no tiene la clave privada que pertenece al certificado digital, no podrá descifrar el secreto pre-maestro y crear las claves correctas para el algoritmo de cifrado simétrico y el protocolo de enlace dará error.

7. El cliente utiliza una serie de operaciones criptográficas para convertir el secreto pre-maestro en un secreto maestro, del que se deriva todo el material de clave necesario para el cifrado y la autenticación de mensajes. A continuación, el cliente envía el mensaje "change cipher spec" para que el servidor conmute al conjunto de programas de cifrado recién negociado. El siguiente mensaje enviado por el cliente (mensaje "finished") es el primer mensaje cifrado con este método y estas claves de cifrado.

8. El servidor responde con mensajes propios "change cipher spec" y "finished".

9. El protocolo de enlace SSL finaliza y los datos de aplicación cifrados se pueden enviar.

5

1.6.- Ventajas y desventajas del uso de SSL.

Ventajas

-Una de las ventajas del SSL es que es independiente del protocolo de aplicación, ya que es posible ubicarlo por encima del mismo en forma transparente.-SSL encripta los datos por toda la ruta desde el cliente al servidor de destino.

Desventajas

-Incrementa notablemente la carga del Procesador tanto al encriptar como AL desencriptar, en relación a una comunicación no encriptada.-Cada conexión necesita una configuración diferente.-Los certificados pueden expirar y son complicados de obtener para el usuario final.

1.7.-SSL en MySQL

A partir de la versión 4.0 de MySQL, existe soporte nativo de SSL. Esto supone una alternativa viable al canal seguro con SSH, o usar “tunneling” para establecer una conexión encriptada entre un servidor y un cliente MySQL. El soporte para SSL fue agregado al sistema de privilegios estándar de MySQL, por lo que hay algunas opciones nuevas en el comando GRANT.

Para obligar a un usuario a usar SSL para conectarse al servidor, simplemente se tiene que agregar la opción REQUIRE SSL al comando GRANT que se usa normalmente. Por ejemplo:

GRANT ALL PRIVILEGES ON *.* TO manuel@"%"IDENTIFIED BY '22root' REQUIRE SSL;

El comando GRANT de arriba requiere que el usuario "manuel" con la contraseña "22root" tenga que conectarse vía SSL. Si "manuel" intenta establecer una conexión sin encriptar al servidor, MySQL rechazará la conexión.

MySQL permite ser más riguroso. En el ejemplo anterior se permite que cualquiera que conozca la contraseña de "manuel" se conecte al servidor y pueda manipular los datos. El único requisito es que la conexión se establezca a través una conexión SSL. Si realmente la seguridad es un asunto sumamente importante, se puede forzar a que "manuel" tenga un certificado X509 para probar su identidad.

GRANT ALL PRIVILEGES ON *.* TO manuel@"%"IDENTIFIED BY 'holahola' REQUIRE X509

Aunque es relativamente fácil generar un certificado con las herramientas que vienen con OpenSSL, es más recomendable usar un certificado firmado por alguna organismo o autoridad oficial. La sintaxis REQUIRE ISSUER permite hacer esto. También se puede usar REQUIRE CIPHER para poner una lista de ciphers que serán permitidos.

6

2.-CONEXIÓN POR SSH

2.1.-¿Qué es SSH?

SSH es un protocolo, es decir, un método estándar que permite a los equipos establecer una conexión segura. Da la posibilidad de acceder a máquinas remotas a través de una red, permitiendo manejarlas por completo con un intérprete de comandos. Es completamente libre y gratuito.

2.2.-¿Cómo funciona?

Una conexión SSH se establece en varias fases:

-En primera instancia, se determina la identidad entre el servidor y el cliente para establecer un canal seguro (capa segura de transporte).

-En segunda instancia, el cliente inicia sesión en el servidor. Una vez establecida la conexión, toda la comunicación estará cifrada.

El sniffer de la imagen representa a cualquier hacker o agente externo que quiera acceder a la información de la comunicación.

7

2.3.-Características a grandes rasgos:

Los datos que circulan entre el cliente y el servidor están cifrados y esto garantiza su confidencialidad (nadie más que el servidor y el cliente pueden leer la información que se envía a través de la red). Como resultado, no es posible controlar la red con un rastreador.

El cliente y el servidor se autentifican uno a otro para asegurarse que las dos máquinas que se comunican son, de hecho, aquellas que las partes creen que son. El hacker ya no puede adoptar la identidad del cliente o de su servidor (falsificación).

Existen 2 versiones de SSH, la versión 1 de SSH hace uso de muchos algoritmos de cifrado patentados (sin embargo, algunas de estas patentes han expirado) y es vulnerable a un agujero de seguridad que potencialmente permite a un intruso insertar datos en la corriente de comunicación. La suite OpenSSH bajo Red Hat Enterprise Linux utiliza por defecto la versión 2 de SSH, la cual tiene un algoritmo de intercambio de llaves mejorado que no es vulnerable al agujero de seguridad de la versión 1. Sin embargo, la suite OpenSSH también soporta las conexiones de la versión 1.

A tener cuenta:

-Utiliza el puerto 22 (TCP y UDP) el protocolo SSH y sigue el modelo cliente-servidor

-Permite la autenticación de los usuarios mediante contraseña o un sistema de claves

-Permite su integración con otros sistemas de autenticación como kerberos, PGP o PAM

-Esta implementado para la mayoría de sistemas operativos y plataformas

2.4.-¿Qué es un túnel SSH?

Es una implementación de SSH en la que se encapsula otra conexión que permita el manejo de otros servicios aparte de los destinados a comunicación y transferencia de archivos como puedan ser: Conexiones a bases de datos MySQL o Conexión a servidores Web.

Puerto 3306 Puerto 5000

8

2.5.-Túneles SSH en MySQL

Podemos usar SSH para generar túneles seguros. Estos túneles ssh establecen una conexión cifrada entre un puerto de nuestra máquina local y otro puerto accesible desde la máquina remota, generalmente un puerto local de la máquina remota, pero no necesariamente.

Si queremos conectar con un servidor MySQL de una maquina remota “servidor” sin usar ssh conectaremos con nuestro cliente de base de datos al puerto 3306 del servidor. El problema es que toda la comunicación es insegura y viaja en claro.Si “servidor” dispone de ssh podemos generar un túnel ssh para proteger la comunicación. Lo que hacemos es “conectar” un puerto de nuestra máquina local, por ejemplo 5000 con el puerto 3306 de “servidor”. Después conectamos nuestro cliente de base de datos al puerto local 5000 y ssh se encargará de comunicar con “servidor” de manera segura.

2.6.-Ventajas e inconvenientes de SSH

Ventajas:

-Después de la primera conexión, el cliente sabe que se conectara al mismo servidor en futuras conexiones

-El cliente transmite al servidor la información necesaria para su autenticación en formato cifrado

-Todos los datos que se envían y reciben durante la conexión se transfieren cifrados

-El cliente puede ejecutar aplicaciones gráficas desde el shell de forma segura

-Evita la interpretación de la comunicación entre dos sistemas

-Evita La suplantacion de un host o enmascaramiento

Inconvenientes:

-El principal inconveniente de SSH es que hay que tener acceso a un servidor que pueda ejecutar SSH en su extremo de la conexión necesariamente.

9

2.7.-Levantando nuestro propio Túnel SSH en Windows 7 para Mysql

*Consideraciones previas*

I.- Tanto IP pública como privada deben de ser fijas. Si no es así, no podremos hacer que funcione correctamente.

II.- En el cliente, podemos efectuar la conexión por MySQL query browser o MySQL Command Line del Server. En el caso segundo, al haber instalado el servicio MySQL es necesario pararlo por completo para que funcione en remoto exclusivamente y no en local.

III.- Crearemos un usuario en el servidor desde MySQL con la sentencia GRANT ALL PRIVILEGES ON *.* TO ‘nombre’@’%’ Identified by `password’; para asegurarnos de que tiene todos los privilegios.

En las siguiente páginas se detalla paso a paso el proceso de poner en marcha un servidor MySQL tunelado con SSH.

10

1.-Instalaremos y configuraremos el servidor SSH con free SSHd u OpenSSH.

2.- Crearemos los usuarios pertinentes asignándoles contraseña y permiso de shell y Tunnel

11

3.- A continuación estableceremos el túnel desde el cliente con la aplicación PUTTY.

4.- Introduciremos la dirección pública de nuestro ordenador (Debe ser fija, o no funcionará). Así como el puerto de conexión, el 5000.

5.- Por último, seleccionamos en el menú de la izquierda SSH y Tunnels en su interior. Allí escribiremos el puerto que redireccionará el túnel, el 3306 y la IP privada del servidor.

12

Hecho esto, establecemos la conexión:

Con ello, tendremos operativa nuestra conexión cifrada SSH, pero no el tunel para MySQL, así que minimizamos la ventana.

6.-Abrimos un cmd en nuestro equipo y nos vamos al directorio bin de MySQL y nos conectamos con la siguiente sentencia:

MySQL –u nombreusuario –h 127.0.0.1 –p test

Comprobamos que la conexión ha sido un éxito y hacemos algunas pruebas.

13

Comprobamos las tablas del servidor.

Y el usuario remoto con el que estamos conectado:

A continuación muestro como podemos hacer exactamente lo mismo con Mysql query browser (Siendo también aplicable a MySQL Workbench)

14

Se introduce todo exactamente igual que cuando nos conectamos en local, pero la dirección de host, será redirigida por el túnel.

Accedemos a las bases de datos del servidor sin ningún problema.

15

3.- WEBGRAFÍA

-Oracle Corporation. (2012). Usar conexiones seguras. Recuperado 15 de Noviembre de 2012, desde http://dev.mysql.com/doc/refman/5.0/es/secure-connections.html

-Hostsuar.com. (2011). Conexión remota y segura al servidor MySQL. Recuperado 15 de Noviembre de 2012 desde: http://docs.hostsuar.com/articulo/conexion-remota-y-segura-al-servidor-mysql

-CódigoMaestro.com. (2008). Conexión cifrada usando SSH y OpenSSH. Recuperado 15 de Noviembre de 2012 desde: http://www.codigomaestro.com/general/conexion-cifrada-usando-ssh-y-openssh-i/

-Waterlovinghead.com. (2008). Enable SSL for Mysql. Recuperado 15 de Noviembre de 2012 desde: http://www.waterlovinghead.com/MysqlSSL

-SV Comunity El Salvador (2005). Instalar un Servidor con SSL. Recuperado 15 de Noviembre de 2012 desde: http://www.svcommunity.org/forum/tutoriales/instalar-un-servidor-con-ssl/

-Jorge Iván Meza Martínez (2010). Crear un tunel SSH para la conexión a un servidor MySQL detrás de un firewall con Linux Debian 5. Recuperado 15 de Noviembre de 2012 desde: http://blog.jorgeivanmeza.com/2010/03/crear-un-tunel-ssh-para-la-conexion-a-un-servidor-mysql-detras-de-un-firewall-con-linux-debian-5/

-Sitepoint (2009). How to Administer a Remote MySQL Database using SSH Tunneling. Recuperado 15 de Noviembre de 2012 desde: http://www.sitepoint.com/how-to-administer-a-remote-mysql-database-using-ssh-tunneling/

-How to Geek (2008). Access Your MySQL Server Remotely Over SSH. Recuperado 15 de Noviembre de 2012 desde: http://www.howtogeek.com/howto/ubuntu/access-your-mysql-server-remotely-over-ssh/

-Verisign (2012). Centro de información sobre SSL y credibilidad en línea. Recuperado 15 de Noviembre de 2012 desde: http://www.verisign.es/ssl/ssl-information-center/

-Mundo Informático (2009). Centro OpenSSL – La navaja suiza del cifrado.Recuperado 15 de Noviembre de 2012 desde:http://infow.wordpress.com/2009/01/11/openssl-la-navaja-suiza-del-cifrado/

-Red Hat Enterprise (2009). Capítulo 20: Protocolo SSH. .Recuperado 15 de Noviembre de 2012 desde: http://www.gb.nrao.edu/pubcomputing/redhatELWS4/RH-DOCS/rhel-rg-es-4/ch-ssh.html

16