Archivar por junio, 2008

Artículo: La importancia de la seguridad II: SSH y RSA/DSA

SSH y SFTP son los dos métodos para el acceso a los datos de nuestro dispositivo. SSH lo usamos para obtener una shell y SFTP para copiar datos desde un dispositivo a otro.

Estos dos servicios son implementados gracias a OpenSSH, un servicio-aplicación instalada casi obligatoriamente para un sin fin de usos. Para los menos dados normalmente tan solo usarán SFTP, para el usuario medio/avanzado usará igualmente SSH. Pero cualquiera de los dos métodos funciona “igual”.

El mayor problema de OpenSSH es evidentemente la seguridad. Como cualquier método de acceso remoto, exponer abiertamente nuestro jugete al alcance de cualquier hacker de tres al cuartos puede ser algo peligroso, más si en nuestro dispositivo guardamos datos comprometidos o sensibles. Al tener habilitado OpenSSH implica que cualquier persona que esté en ese momento en nuestra misma red (o en WAN si hay tráfico dirigido) puede intentar acceder (con o sin exito) a nuestro iPod Touch/iPhone. Y a ello podemos sumar además la inseguridad en sí de una conexión wifi.

Aquí no vamos a explicar como securizar una conexión wifi, pero al menos como poner las cosas más complicadas para los demás y más facil para nosotros, a la hora de tener acceso a nuestro dispositivo.

Nos enfrentamos a algunos problemas graves de seguridad:

1º. Contraseñas y nombres de usuario por defecto

Por defecto hay dos cuentas principales de usuarios. La cuenta ‘root’ (administrador) y la cuenta ‘mobile’ (limitada). Pero para ambos la contraseña es ‘alpine’. El primer problema es que el 90% de las personas no cambian la contraseña por defecto (añadir o cambiar los nombres de usuario es más sucio). Esto significa que cualquier persona conectado a la misma red en ese momento, desde otro iPod/iPhone, PC, PDA… podría conectarse sin problema a nuestro dispositivo con los credenciales por defecto!! Lo que quiere decir es que podrían desde copiarnos datos sensibles, información personal, eliminarnos archivos, agenda, calendario, llamadas…

Tan solo modificando la contraseña de LAS DOS CUENTAS estaremos interponiendo la primera barrera. Tener en cuenta que es muy facil para un hacker mediocre hacer un escaner rápido en una red y ver los iPod/iPhone conectados a ella. Imaginaros en la universidad por ejemplo, o en la empresa. La probabilidad de encontrar alguien con un dispositivo conectado y vulnerable son muy altas, y eso sin contar con otro tipo de técnicas.

Como he dicho es necesario modificar la contraseña de las dos cuentas. Aunque muchos incluso no lo saben, no solo podemos acceder co la cuenta de ‘root’. Podemos acceder perfectamente también desde la cuenta ‘mobile’ aunque evidentemente tendremos ciertas restricciones.

Comenzando por este punto, para modificar la contraseña tan solo necesitamos tener instalado Cydia. Y digo Cydia porque no es posible hacerlo con BSD Subsystem. Las utilidades de BSD Subsystem estan llenas la mayoria de fallos, y en este caso lo está la herramienta ‘passwd’. Si lo intentamos con BSD tendremos una bonita “rueda de la muerte”. Así que presuponemos que tenemos Cydia. Lo único que tendremos que hacer será entrar por SSH con el usuario root. Una vez hayamos entrado, tan solo tenemos que teclear el comando: “passwd”. Una vez tecleado el comando, el dispositivo nos pedirá por la nueva contraseña, la cual deberemos de introducir dos veces. Una vez realizado la contraseña se habrá cambiado con éxito.

Como he dicho sería necesario modificar igualmente la contraseña del usuario ‘mobile’. Para ello tan solo tenemo que hacer lo mismo, entrar por SSH pero con el usuario mobile. Una vez dentro teclear de nuevo el mismo comando. En este caso sí nos pedirá antes de permitir cambiar la contraseña la contraseña antigua. Recordar que por defecto, tanto para mobile como para root la contraseña es ‘alpine’. Cuando acabemos este simple proceso la contraseña será aquella que elegimos.

2º. WIFI y SSH innecesario las 24 horas

Evidentemente para evitar posibles ataques hay que no dar pie a que puedan entrar. Hay dos “barreras” lógicas. La primera es SSH y la segunda WIFI.

OpenSSH es un demonio que se carga al iniciar el dispositivo y permanece a la escucha sobre el puerto 22, que es el común para transmisiones SSH. Al detectar tráfico por ese puerto se activa. Contrariamente a lo que se cree, OpenSSH NO CONSUME batería por estar el servicio activado, al contrario que si pasaba con el anterior servidor SSH dropbear. Mientras esté tan solo escuchando, el consumo de energía por OpenSSH será de 0%… aunque evidentemente es un riesgo natural. WIFI podemos necesitarlo en cualquier momento, pero nunca sabemos quien pueda estar a la “escucha” en la red. Si el servicio SSH está levantado en nusetra máquina aceptará todas las conexiones entrantes. Luego OpenSSH tan solo debería de estar habilitado cuando realmente lo necesitemos. Para habilitarlo o deshabilitarlo basta con instalar NetServices por ejemplo, que con un simple deslizar se activa o se desactiva.

La segunda barrera es evidentemente WIFI. Tan solo activar WIFI cuando sea necesario, y WIFI si consume batería, al contrario que OpenSSH, luego en caso de WIFI la recomendación de tenerlo apagado es doble. Evidentemente si hay conexion es posible que alguien pueda colarse.

Uno puede pensar que tan solo desactivando wifi cuando no se necesite el problema se resuelve. NO. Si OpenSSH está activado, en cualquier momento que uno se conecte a una red wifi su dispositivo es vulnerable. Normalmente es más facil olvidar desactivar OpenSSH (por comodidad) que WIFI. Lo ideal? desactivar ambos cuando no se requiera. Aunque esto puede llegar a ser muy incómodo, sobre todo para personas que usan muy exaustivamente SSH y SFTP.

3º. Usar una autentificación basada en clave pública en vez de acceso por contraseña

Lo que la mayoría sabe a estas alturas es que SSH permite autorización por contraseña. Un nombre de usuario y una contraseña (que por defecto es alpine) es suficiente para tener acceso ilimitado. Si ademas conocemos de antemano también el nombre de las cuentas… Hemos aprendido a cambiar la contraseña, pero esto tiene algunos problemas, aunque evidentemente es muchisimo más seguro que dejarlo con el pass por defecto:

El primer problema es que si es una contraseña compleja, cada vez que queramos acceder tener que teclearla puede ser un martirio. Aunque esto tampoco llega a ser un problema, en casa se puede configurar Putty o WinSCP para automatizar todo el proceso

El segundo problema es que una contraseña se puede averiguar sin mucho problema (En la tercera parte pondre ejemplos reales). Y no solo averiguar, sino realizar ataques de diccionarios e incluso de fuerza bruta. Incluso con una contraseña compleja.

El tercer problema es que podría ser posible acceder al sistema en un descuido, copiar o sustitur el archivo de contraseñas “master.passwd” y obtener la contraseña.

SSH es en teoría un protocolo seguro y ya de por sí basado en clave pública. La primera vez que nos conectamos a una máquina SSH esta nos manda su clave pública. Todos hemos visto el cartel de confirmación de aceptar la clave pública la primera vez que nso conectamos. Al introducir la contraseña de acceso esta se encripta con la clave publica del servidor, y la manda codificada, de modo que el servidor que es el único que posee la clave privada pareja es capaz de abrir el mensaje, recivir la contraseña e introducirla en la máquina. Así se evitan posbles ataques por medio de sniffers, ya que la contraseña jamás será vista. Pero este proceso no evita ningun posible problema antes comentado.

Para asegurar esto un poco más lo que se hace es en vez de optar por una autentificación basada en contraseña, realizar una basada completamente en clave pública. Ya hemos dicho que el servidor tiene las suyas propias (en este caso el ipod/iphone), pero podemos hacer lo siguiente:

Generamos nosotros otro juego de claves, una privada y su pública
Entregamos nusetra llave pública al servidor y le decimos que puede usarla como cliente autorizado
En la próxima conexion que se realize, el servidor nos enviará un testigo cifrado con nuestra clave publica. Como nosotros tenemos la clave privada le contestamos correctamente. Igualmente el hace lo mismo cno su clave pública para asegurarnos nosotros a la vez que nos estamos conectando al servidor debido. Una vez realizado el proceso se concede el acceso, sin necesidad ya de introducir contraseñas y el problema de ellas.

Todo esto suena más complicado de como es en realidad. Para hacer todo esto tan solo debemos de usar herramientas que ya tenemos en el PC instaladas.

Lo primero como he dicho es genera un par de claves. Los sistemas basados en clave pública son los más robustos ahora mismo del mundo, a día de hoy impenetrables. Se basa en una premisa simple: Es imposible calcular predecir… si un número es primo y factorizarlo. Todo el mundo sabe que es un número primo: 1, 2, 3, 5, 7, 11, 13, 17… solo divisibles por 1 y por ellos mismos. Pero si yo preguntase si el número 123^123 es primo o no y cuales sus factores… la única forma de saberlo sería ir dividiendo ese número por 1, despues por 2, despues por 3… computacionalmente es imposible. Lo que se hace pues es generar dos claves, resumiendo mucho mucho digamos que una es el numero resultante de la multiplicación de otros dos primos, y la clave privada son los dos numeros primos que generan la clave publica (el primo). En resumidas cuentas, es imposible a día de hoy quebrantar este sistema, al menos el sistema en sí. La clave pubica se da libremente, a fin de cuentas nadie será capaz jamas, ni en 100 años de calcular la clave privada. Y la clave privada es lo que se guarda de manera celosa ;). Despues es tan facil como cifrar un mensaje con la clave pública por otros métodos que ahora no vienen al cuento, y la clave que descifra el mensaje no es la misma clave publica, sino tan solo la clave privada, es lo que se conoce como cifrado asimetrico. Normalmente estamos acostumbrados a cifrados simetricos, la misma contraseña con la que protegemos un archivo es la misma que usamos para desprotegerlo.

Bueno dicho esto tan solo queda ponerse manos a la obra:

Primero generaremos el par de caves, lo cual podemos hacer con una utilidad que tendremos ya instalada, si tenemos instalado WinSCP: PutyGen


Es muy simple. Yo he optado en la imagen de generar una clave de 2048 bits, más que suficiente, quien quiera puede usar claves más potentes, incluso de 4096. Y tambien se tiene la opcion de usar RSA como DSA. Los dos son algoritmos de clave públicas, muy similares. Existen los dos porque el algoritmo RSA estaba patentado y no se podía usar, y de ahí salio DSA. A efectos prácticos da igual, DSA funciona con el mismo principio y es casi casi igual que RSA, así que… diría usar DSA por la patente de RSA, pero la verdad es que a día de hoy la patente RSA caducó, y puede ser usada libremente.

Una vez le demos a generate saldrá una barra verde que podemos observar y se nos pedirá que movamos el ratón por la zona justo de debajo. Cuando lo hagamos la clave se irá generando. Por que esto? porque para asegurar la creación de una buena clave, el PC necesita generar datos aleatorios puros, y los algoritmos para generar números aleatorios son predecibles. Así que esto ayuda a generar valores aleatorios.

Una vez terminado el proceso tendremos algo parecido a lo siguiente:


Lo que vemos es la clave pública. Primero tenemos que guardar y poner a buen recaudo la clave privada, y si queremos para mayor seguridad se puede proteger tambien con una clave, de este modo la clave privada se encripta con una clave. Irónico verdad? 😉 la guardamos por ejemplo en la misma carpeta de WinSCP y sin cifrado.

Y de paso, hacemos un copy paste de la clave pública. No le damos a save public key, ya que el formato que necesitamos es el de arriba, no el que se genra al darle al botón. En realidad es igual, solo modifica una cosilla. Copiamos ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQ… (en mi caso)
Tambien se puede poner una descripción, en mi caso prueba, podeis poner key ipod/iphone.

Una vez terminado esto creamos en el escritorio, por ejemplo, un archivo de texto y pegamos encima toda la clave pública. Si se hace bien tan solo se verá una sola linea gigante de letras y números (si la opción de Ajuste de Linea del bloc de notas está desactivada evidentemente). Guardamos ese archivo y lo renombramos a: “authorized_keys” sin extensión ninguna,

ese es el archivo que usara nuestro dispositivo para almacenar las claves públicas autorizadas. y será el único archivo que copiaremos al dispositivo. La clave privada en cambio es para nosotros tan solo.

Y ya tan solo queda configurar las dos partes: 1º el servidor y despues el cliente

Para configurar el servidor es muy simple. Quizás el más simple para vosotros sea acceder por WinSCP (aun por el método tradicional) y nos situamos en la carpeta /private/etc/ssh y localizamos el archivo “sshd_config”. Lo editamos y tan solo tenemos que habilitar un par de líneas, y habilitar tan solo quiere decir eliminar el símbolo de #. bajamos hasta dnd aparece:

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

Y tan solo tenemos que eliminar las #:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Podemos si queremos deshabilitar tambíen de forma permanente el acceso por contraseña, de modo que tan solo sea posible acceder por este método. De esta forma, a menos que nusetro dispositivo tenga una copia de la clave pública especificada no se tendrá acceso al sistema. Si no se activan las siguientes opciones, lo primero se intentará el acceso por clave pública, pero si este falla se volverá al sistema antiguo, con lo que no se gana demasiado. OJO!!! ESTO SOLO SE DEBE DE MODIFICAR UNA VEZ HEMOS COMPROBADO QUE PODEMOS ACCEDER DESDE NUESTRO PC, SI NO ES ASI MODIFICAR ESTO PUEDE PROBOCAR NO PODER ACCEDER MAS POR SSH, anuq siempre podemos entrar por terminal de forma local o desinstalar SSH.

Luego estas modificaciones tan solo es aconsejable hacerlo despues de todo el proceso, pero dado que estamos con el archivo en cuestion lo pongo ahora, repito, solo cuando hayamos comprobado que el sistema funciona:

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Si quitamos los # y lo configuramos de esa forma, deshabilitaremos el acceso por contraseña, por PAM y por challenge, luego tan solo nos quedará el acceso por clave pública.

Tambien puede ser muy interesante modificar el puerto por defecto: “22” a otro. El puerto 22 es extensamente barrido en cualquier escaner de puerto, y llama mucho la atención. Es aconsejable moverlo a otro puerto, y para asegurarnos que no usamos alguno del sistema podemos eleguir de manera segura casi cualquier puerto desde el 10000-65000. Hay que recordar el puerto, puesto que a la hora de configurar el cliente deberemos modificar el puerto 22 al seleccionado:

#Port 22

lo modificamos a por ejemplo:

Port 15021

Una vez acabado el archivo editado, lo guardamos y listo.
Tan solo queda copiar el archivo de claves “authorized_keys” que tenemos en el escritorio. Tan solo debemos de copiarlo en :

/private/var/root/.ssh/

Una vez copiado nos aseguramos que los permisos de las siguientes carpetas quedan así: (NO ACTIVAR RECURSIVIDAD)

/private/var/root -> 0644
/private/var/root/.ssh -> 0700
/private/var/root/.ssh/authorized_keys -> 0755

Una vez copiado el archivo tan solo queda comprobar que la conexión funciona perfectamente. Ahora tan solo tenemos que abrir WinSCP por ejemplo. La configuración es igual, exceptuando:

Si hemos modificado el puerto, lo modificamos también.
Ya no hace falta contraseña, así que el campo de password lo eliminamos
Hace falta añadir la clave privada guardada anteriormente, así que en el campo private key file colocamos la clave privada que dijimos la guardábamos en la misma carpeta que WinSCP. Listo:


Como sabemos si funciona? le damos a conectar. Si conecta sin pedirnos contraseña éxito. Nota que el nombre de usuario deberemos de introducirlo de todos modos.

La configuración de putty es exactamente igual, salvo que la clave privada se mete en otro sitio:


En mi caso como podeis ver en las imágenes el proceso es completamente automatizado. ni contraseña ni usuario. Aunque esto se puede tambien automatizar sin necesidad de clave pública. Una vez que el sistema funciona, podemos modificar las opciones citadas anteriormente y así estaremos ante una fortaleza a la que nadie, sin nuestro permiso, podrá entrar. Si deseamos añadir un cliente más, tan solo tendrá que generar su par de claves y copiar la clave publica del cliente en nuestro archivo ya creado “authorized_keys”, a continuación ahora sí, de la anterior.


Eso es todo por hoy

Artículo: La importancia de la seguridad I: PuzzleManiak

Durante años he tenido que oir eso de:

No eres demasiado estricto siempre con eso de la seguridad? Quizás un poco fanático? Realmente un usuario de a pie necesita ser “tan estricto” con sus cosas?

En un mundo ideal todo el tráfico por inet podría ser completamente abierto, las contraseñas no existirían, nadie sería curioso ni tendría la necesidad de robar o de entrar en las casas o… Evidentemente ese mundo no es el que nosotros vivimos y nunca podemos saber hasta que punto el que tenemos al lado de nosotros está dispuesto a respetar nuestra intimidad. Somos demasiados confiados o somos demasiado tontos? o quizás somos fanaticos?

Bueno, en la segunda entrada veremos como podemos hacer que nuestro dispositivo sea un poco más seguro. En esta vamos a enseñar y demostrar lo vulnerable que pueden ser los sistemas simplemente por confianza de que hay siempre buena voluntad y que nadie es malo, o que nadie se aprovecha de los defectos de un sistema o… Realmente “asaltar” un sistema, por sencillo que sea, tiene alguna utilidad? Normalmente o satisfacción personal o dinero. Imaginemos que estamos en nómina de una empresa para lograr la máxima información de un determinado individuo.

Nosotros no vamos a hacer nada de eso, además, me parece completamente amoral. Por el contrario vamos a verlo ilustrado en un simple ejemplo con el juegecito PuzzleManiak.

PuzzleManiak es un juego que trae dentro unos ¿29? juegecitos de puzzles diferentes. A mi gusto es una de las mejores aplicaciones para pasar el rato, algunos son muy buenos y otros son clásicos de siempre. El juego tiene un sistema de puntuación Online, esas cosillas que siempre le encanta a los ambiciosos o a los que buscan siempre un aliciente: Hay que ser el mejor!!. Cada juego tiene diferentes niveles de dificultad y/o tamaño, así como su propio ranking de puntuación local como en internet.

El Ranking local son puntuaciones almacenadas para seguir nuestros progresos, el Ranknig en internet nos vale para seguir un progreso en comparación con otras personas del mundo. El ranking en internet a su vez se divide en:

a) Ranking por Puzzle: Diario, Semanal, Mensual y Global de cada una de las dificultades y/o tamaños
b) Puzzle del día: Una vez al día se tiene acceso a un puzzle determinado normalmente de dificultad y/o tamaño grande. Todos los participantes hacen el mismo puzzle, y se envian los datos a inet. Este Ranking recoge la puntuación de los participantes en el Puzzle del día, y el ranking global generado por los 10 últimos días del puzzle del día
c) Hall de la fama: Cada puzzle tiene un campeon global recogido en el Hall de la fama
d) Ranking Global: Y para acabar un Ranking general en el que se tiene en cuenta cada punto obtenido en cualquier ranking por puzzle

Seguro que muchos de vosotros sabeis que juego es o lo habeis usado alguna que otra ocasión.

El caso es que quería demostrar la vulnerabilidad de algunos sistemas y he escogido esto de ejemplo. Lo relativamente simple que puede ser engañar, falsear, hackear un sistema de puntuaciones online. Lo que hace que sea relativamente simple es precisamente eso, la falta de seguridad por parte del creador de la aplicación por suponer que hay buena voluntad. Evidentemente en este caso es una tontería, y le tengo que mandar un correo a su creador para que lo corrija y de paso que elimine mi puntuación ;). Pero muestra precisamente lo que digo, la importancia siempre, aunque haya la mejor confianza, la mejor buena voluntad… de usar sistemas seguro. Ya no solo para protegernos nosotros mismos, sino para que los demás sepan que están protegidos.

Os dejo las capturas de las puntuaciones actuales, aunque quien quiera puede consultarlas online en http://www.puzzlemaniak.com/blog/


Estas dos pertenecen al ranking del puzzle del día y el global del ranking del puzzle del día por 10 días. Aquí no tengo aun la máxima puntuación porque aun no han pasado 10 días. Sí, ya se que casi 37 segundos es una barbaridad comparado a los próximso resultados, pero 37 segundos si comparais con el resto es algo ínfimo. Pero aun hay más:

Este es un ranking del puzzle Map en su categoría 20*24 y 50 regiones. Todas las demás categorías y de todos los puzzles tienen el mismo resultado, soy el número 1 con un tiempo siempre de 1 centésima de segundo. Sinceramente? Soy bueno en algunos puzzles, muy bueno en otros!! pero evidentemente jamás con ese tiempo. Al estar el puesto primeor en todos los puzzles en todas las categorías, el ranking global queda así:


Creo que no me ha quedado ni un solo record sin coger, luego tengo la máxima puntuación posible, soy el gran campeon de todos los tiempos!!

Pero bueno, ahora hay que desvelar el secreto. Como ha podido pasar esto?

Es simple. Los datos enviados desde el servidor de la aplicación como desde nuestra misma aplicación al servidor deberían de ir encriptados completamente o al menos usar un algoritmo hash para “encriptar” los datos de los puntos.

Es cierto que el servidor sí aplica algunas medidas de seguridad. Por ejemplo, cada vez que enviamos datos a su servidor les enviamos nuestro nombre de usuario claro está y también la MAC de nuestro dispositivo. Supongo que será para fines de validación, por ejemplo en “el puzzle del día”, y así evitar poder hacer el “puzzle del día” más de una vez. También sirve de ID único, así en el ranking podríamos tener dos nombres de usuarios iguales, ya que su MAC es diferente. Claro que cambiar la MAC del dispositivo es tarea simple. Al menos han tenido la delicadeza de “cifrar” la MAC, le aplica un cálculo simple para no enviarla en plano, seguramente ni siquiera la almacenen en plano, lo cual es de agradecer.

Tambien usan un sistema de hash para verificar que los datos que se envian al servidor no se han alterado. Este sistema se basa simplemente en calcular un hash o firma dependiente de la puntuación obtenida en el puzzle en cuestión, el nombre del usuario y de la MAC de este. De esos tres datos se obtiene una “firma” que se envía conjunta a los datos al servidor. El servidor comprueba los puntos, la MAC y el usuario y calcula la firma. Si la firma que obtiene es la misma que la enviada por la aplicación se permiten los datos.

El sistema no es malo del todo, pero tiene muchos fallos de seguridad. Para empezar los puntos se guardan antes en disco, lo cual es posible editarlos, y este ficharo no está encriptado ni tiene ninguna comprobación CRC ni ningún otro sistema. Esto implica que con un poco de ingenio podemos alterarlos como queramos.

Por otro lado que exista un sistema de hash para cifrar algunos datos es positivo, pero es insuficiente como hemos podido ver. El tráfico debería de ser todo o casi todo encriptado. No me ha resultado nada complicado inyectar exitosamente los datos enviados al servidor y al dispositivo para poder “jugar” con los puntos como quiera.

———————-
———————-

Evidentemente esto no está haciendo un daño a nadie ni a ninguna instalaciones, y como digo informaré con pelos y señales al dueño para que tome medidas, pero es un ejemplo del problema de la seguridad. Por mucho que creamos que nuestro sistema es seguro, siempre hay alguien más listo que nosotros, y esto es una gran verdad

Tampoco creo que haya que ser alarmista ni un enfermo mental de la seguridad. Pero sí creo que cada tipo de datos se debe de tratar con su nivel de seguridad correcto. En los listados tan solo vemos puntos y nombres de usuarios, pero si fueran nombres y apellidos + números de teléfonos estaríamos ante un gravísimo incidente, aquí en españa penado con fuertes multas y muy vigilado por la Agencia Española de Protección de Datos.

Siempre que tengamos datos sensibles o privados hay que protegerlos de la forma adecuada, y muchas veces la seguridad nunca es excesiva.

Esta entrada no es directa a nuesto dispositivo, quitando un poco lo de PuzzleManiak, pero si que usaremos esta entrada de trampolín para la segunda parte: “La importancia de la Seguridad II: Securizando el iPhone/iPod” Que escribiré después

Un saludo.

Volver a arriba

Sobre Mí

Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Política de Privacidad.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.