CONEXIONES SEGURAS EN MYSQL

Administracin de Gestores de Bases de datos

16/11/2012

NDICE
1.-Conexin por SSL________________________________________3
1.1.-La necesidad de la seguridad__________________________________3 1.2.-Qu es SSL?_______________________________________________3 1.3.-Qu es el estndar X509?____________________________________ 3 1.4.-Cmo funciona el estndar x509?_____________________________ 3 1.5.-Cmo funciona el protocolo SSL?_____________________________ 4 1.6.-Ventajas y desventajas del uso de SSL.__________________________6 1.7.-SSL en MySQL_____________________________________________ 6

2.-Conexin por SSH________________________________________7

2.1.-Qu es SSH?________________________________________________7 2.2.-Cmo funciona?_____________________________________________7 2.3.-Caractersticas a grandes rasgos:________________________________8 2.4.-Qu es un tnel SSH?________________________________________ 8 2.5.-Tneles SSH en MySQL_______________________________________9 2.6.-Ventajas e inconvenientes de SSH_______________________________9 2.7.-Levantando nuestro propio Tnel SSH en Windows 7______________10

3.- Webgrafia______________________________________________ 16

1.-CONEXIN POR SSL

1.1.-La necesidad de securizar: Para entender como se usa SSL en MySQL es necesario explicar brevemente algunos conceptos bsicos de SSL y X509. Por defecto, MySQL usa conexiones no encriptadas entre el cliente y el servidor, lo que significa que alguien podra ver e incluso modificar los datos que estn siendo enviados o recibidos entre el cliente y el servidor. Un defecto en la seguridad de MySQL puede ser crtico para una empresa debido a que la informacin 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 encriptacin para asegurarse de que los datos que viajan a travs de una red pblica (como pueda ser Internet) puedan ser fiables. Este protocolo tiene un mecanismo para detectar cualquier cambio o prdida de los datos, adems de incorporar algoritmos para la verificacin de identidad usando el estndar X509. 1.3.-Qu es el estndar X509? X509 es un estndar UIT-T para infraestructuras de claves pblicas. Especifica, entre otras cosas, formatos estndar para certificados de claves pblicas y un algoritmo de validacin de la ruta de certificacin. Comnmente, se le conoce tambin como el estndar que hace posible identificar a alguien en Internet. Se usa habitualmente en aplicaciones de comercio electrnico. 1.4.-Cmo funciona el estndar x509? En trminos simples, debe haber un organismo que asigne certificados electrnicos a las personas u organizaciones que los necesiten. Estos certificados se basan en un algoritmo que tiene dos claves de encriptacin (una clave pblica, y una clave secreta). El dueo de un certificado puede probar su identidad al mostrar su certificado a la otra parte. Este certificado consiste en su clave pblica. Cualquier dato que se haya encriptado con esta clave pblica puede ser desencriptado nicamente con la correspondiente clave secreta, que debe pertenecer al dueo del mismo certificado.

1.5.-Cmo funciona el protocolo SSL?

Antes de que se establezca SSL, se debe hacer una solicitud. Tpicamente 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 conexin SSL, es decir, hacen el SSL Handshake. SSL Handshake: Durante el hanshake se cumplen varios propsitos. Se hace autenticacin del servidor y opcionalmente del cliente, se determina que algoritmos de criptografa sern utilizados y se genera una llave secreta para ser utilizada durante el intercambio de mensajes subsiguientes durante la comunicacin SSL. Una conexin SSL siempre es iniciada por el cliente. Al principio de una sesin SSL, se realiza un protocolo de enlace SSL. Este protocolo de enlace produce los parmetros criptogrficos de la sesin. En este ejemplo se supone que se est estableciendo la conexin SSL entre un navegador web y un servidor web. Protocolo de enlace SSL con autenticacin de servidor 1. El cliente enva el mensaje "hello" que lista las posibilidades criptogrficas del cliente (clasificadas por orden de preferencia del cliente), como la versin de SSL, los grupos de programas de cifrado soportados por el cliente y los mtodos de compresin de datos soportados por el cliente. El mensaje tambin contiene un nmero aleatorio de 28 bytes. 2. El servidor responde con el mensaje "hello" del servidor que contiene el mtodo criptogrfico (conjunto de programas de cifrado) y el mtodo de compresin de datos seleccionados por el servidor, el ID de sesin y otro nmero aleatorio. Nota: El cliente y el servidor deben dar soporte como mnimo a un conjunto de cifrado

comn; de lo contrario, el protocolo de enlace dar error. Generalmente, el servidor elige el conjunto de programas de cifrado comn ms potente. 3. El servidor enva su certificado digital. (El servidor utiliza certificados digitales X.509 V3 con SSL.) Si el servidor utiliza SSL V3 y si la aplicacin de servidor (por ejemplo, el servidor web) requiere un certificado digital para la autenticacin de cliente, el servidor enva el mensaje "digital certificate request". En el mensaje "digital certificate request", el servidor enva una lista de los tipos de certificados digitales soportados y los nombres distinguidos de autoridades de certificacin aceptables. 4. El servidor enva 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 parmetros del mensaje "hello" del servidor son aceptables. Si el servidor ha solicitado un certificado digital del cliente, el cliente enva un certificado digital o, si no hay ningn certificado digital adecuado disponible, el cliente enva la alerta "no digital certificate". Esta alerta slo es un aviso, pero la aplicacin de servidor puede hacer que la sesin sea anmala si la autenticacin del cliente es obligatoria. 6. El cliente enva el mensaje "client key exchange". Este mensaje contiene el secreto pre-maestro, un nmero aleatorio de 46 bytes utilizado en la generacin de las claves de cifrado simtrico y las claves de cdigo de autenticacin de mensajes (MAC), cifradas con la clave pblica del servidor. Si el cliente ha enviado un certificado digital al servidor, el cliente enva un mensaje "digital certificate verify" firmado con la clave privada del cliente. Al verificar la firma de este mensaje, el servidor puede verificar explcitamente 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 simtrico y el protocolo de enlace dar error. 7. El cliente utiliza una serie de operaciones criptogrficas para convertir el secreto premaestro en un secreto maestro, del que se deriva todo el material de clave necesario para el cifrado y la autenticacin de mensajes. A continuacin, el cliente enva el mensaje "change cipher spec" para que el servidor conmute al conjunto de programas de cifrado recin negociado. El siguiente mensaje enviado por el cliente (mensaje "finished") es el primer mensaje cifrado con este mtodo 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 aplicacin cifrados se pueden enviar.

1.6.-Ventajas y desventajas del uso de SSL. Ventajas -Una de las ventajas del SSL es que es independiente del protocolo de aplicacin, 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 relacin a una comunicacin no encriptada. -Cada conexin necesita una configuracin diferente. -Los certificados pueden expirar y son complicados de obtener para el usuario final. 1.7.-SSL en MySQL A partir de la versin 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 conexin encriptada entre un servidor y un cliente MySQL. El soporte para SSL fue agregado al sistema de privilegios estndar 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 opcin 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 contrasea "22root" tenga que conectarse va SSL. Si "manuel" intenta establecer una conexin sin encriptar al servidor, MySQL rechazar la conexin. MySQL permite ser ms riguroso. En el ejemplo anterior se permite que cualquiera que conozca la contrasea de "manuel" se conecte al servidor y pueda manipular los datos. El nico requisito es que la conexin se establezca a travs una conexin 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 fcil generar un certificado con las herramientas que vienen con OpenSSL, es ms recomendable usar un certificado firmado por alguna organismo

o autoridad oficial. La sintaxis REQUIRE ISSUER permite hacer esto. Tambin se puede usar REQUIRE CIPHER para poner una lista de ciphers que sern permitidos.

2.-CONEXIN POR SSH

2.1.-Qu es SSH? SSH es un protocolo, es decir, un mtodo estndar que permite a los equipos establecer una conexin segura. Da la posibilidad de acceder a mquinas remotas a travs de una red, permitiendo manejarlas por completo con un intrprete de comandos. Es completamente libre y gratuito. 2.2.-Cmo funciona? Una conexin 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 sesin en el servidor. Una vez establecida la conexin, toda la comunicacin estar cifrada.

El sniffer de la imagen representa a cualquier hacker o agente externo que quiera acceder a la informacin de la comunicacin.

2.3.-Caractersticas a grandes rasgos: Los datos que circulan entre el cliente y el servidor estn cifrados y esto garantiza su confidencialidad (nadie ms que el servidor y el cliente pueden leer la informacin que se enva a travs 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 mquinas 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 (falsificacin). Existen 2 versiones de SSH, la versin 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 comunicacin. La suite OpenSSH bajo Red Hat Enterprise Linux utiliza por defecto la versin 2 de SSH, la cual tiene un algoritmo de intercambio de llaves mejorado que no es vulnerable al agujero de seguridad de la versin 1. Sin embargo, la suite OpenSSH tambin soporta las conexiones de la versin 1. A tener cuenta: -Utiliza el puerto 22 (TCP y UDP) el protocolo SSH y sigue el modelo cliente-servidor -Permite la autenticacin de los usuarios mediante contrasea o un sistema de claves -Permite su integracin con otros sistemas de autenticacin como kerberos, PGP o PAM -Esta implementado para la mayora de sistemas operativos y plataformas 2.4.-Qu es un tnel SSH? Es una implementacin de SSH en la que se encapsula otra conexin que permita el manejo de otros servicios aparte de los destinados a comunicacin y transferencia de archivos como puedan ser: Conexiones a bases de datos MySQL o Conexin a servidores Web.

Puerto 3306

Puerto 5000 8

2.5.-Tneles SSH en MySQL Podemos usar SSH para generar tneles seguros. Estos tneles ssh establecen una conexin cifrada entre un puerto de nuestra mquina local y otro puerto accesible desde la mquina remota, generalmente un puerto local de la mquina 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 comunicacin es insegura y viaja en claro. Si servidor dispone de ssh podemos generar un tnel ssh para proteger la comunicacin. Lo que hacemos es conectar un puerto de nuestra mquina local, por ejemplo 5000 con el puerto 3306 de servidor. Despus 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: -Despus de la primera conexin, el cliente sabe que se conectara al mismo servidor en futuras conexiones -El cliente transmite al servidor la informacin necesaria para su autenticacin en formato cifrado -Todos los datos que se envan y reciben durante la conexin se transfieren cifrados -El cliente puede ejecutar aplicaciones grficas desde el shell de forma segura -Evita la interpretacin de la comunicacin 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 conexin necesariamente.

2.7.-Levantando nuestro propio Tnel SSH en Windows 7 para Mysql *Consideraciones previas* I.- Tanto IP pblica como privada deben de ser fijas. Si no es as, no podremos hacer que funcione correctamente. II.- En el cliente, podemos efectuar la conexin 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 pginas 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 asignndoles contrasea y permiso de shell y Tunnel

11

3.- A continuacin estableceremos el tnel desde el cliente con la aplicacin PUTTY.

4.- Introduciremos la direccin pblica de nuestro ordenador (Debe ser fija, o no funcionar). As como el puerto de conexin, 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 tnel, el 3306 y la IP privada del servidor.

12

Hecho esto, establecemos la conexin: Con ello, tendremos operativa nuestra conexin 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 conexin ha sido un xito y hacemos algunas pruebas.

13

Comprobamos las tablas del servidor.

Y el usuario remoto con el que estamos conectado:

A continuacin muestro como podemos hacer exactamente lo mismo con Mysql query browser (Siendo tambin aplicable a MySQL Workbench)

14

Se introduce todo exactamente igual que cuando nos conectamos en local, pero la direccin de host, ser redirigida por el tnel.

Accedemos a las bases de datos del servidor sin ningn problema.

15

3.- WEBGRAFA
-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). Conexin remota y segura al servidor MySQL. Recuperado 15 de Noviembre de 2012 desde: http://docs.hostsuar.com/articulo/conexion-remota-ysegura-al-servidor-mysql -CdigoMaestro.com. (2008). Conexin cifrada usando SSH y OpenSSH. Recuperado 15 de Noviembre de 2012 desde: http://www.codigomaestro.com/general/conexioncifrada-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-unservidor-con-ssl/ -Jorge Ivn Meza Martnez (2010). Crear un tunel SSH para la conexin a un servidor MySQL detrs 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-laconexion-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-toadminister-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-yourmysql-server-remotely-over-ssh/ -Verisign (2012). Centro de informacin sobre SSL y credibilidad en lnea. Recuperado 15 de Noviembre de 2012 desde: http://www.verisign.es/ssl/ssl-information-center/ -Mundo Informtico (2009). Centro OpenSSL La navaja suiza del cifrado.Recuperado 15 de Noviembre de 2012 desde:http://infow.wordpress.com/2009/01/11/openssl-lanavaja-suiza-del-cifrado/ -Red Hat Enterprise (2009). Captulo 20: Protocolo SSH. .Recuperado 15 de Noviembre de 2012 desde: http://www.gb.nrao.edu/pubcomputing/redhatELWS4/RHDOCS/rhel-rg-es-4/ch-ssh.html

16