martes, 23 de junio de 2009

Slowloris.: Apache DoS

En clase analizamos los fundamentos de los ataques D[D]oS. Como puedes observar, el D[D]oS es uno de los temas vigentes en seguridad que requieren de toda nuestra atención. Aquí tenéis otra de las muchas noticias que aparecen al respecto "Slowloris.: Apache DoS"

[Fuente.: Pentester]

viernes, 19 de junio de 2009

SHA1 (malos tiempooos, para la líricaaa)

En la asignatura, entre otras muchas cosas, hemos visto las funciones hash y su integración en nuestros protocolos seguros, control de acceso, etc. Nuevas investigaciones debilitan aún más al SHA1. Más información en.:

miércoles, 17 de junio de 2009

The End

Este curso académico PSI llega a su fin. Aunque gran parte de vosotros ha superado la asignatura, animaros a seguir trabajando en temas de seguridad de la información. Dejo de ser vuestro profesor aunque siga a vuestra disposición para cualquier consulta que queráis hacerme. No tengo respuesta para todo, ni mucho menos, pero lo que pueda saber o cualquier consejo que pueda daros, considerando las experiencias profesionales vividas, están a vuestra disposición.

Mañana publicaré las notas de la convocatoria de junio. Las revisiones de examen serán los días 19 y 23 de junio a las 11:00.

En cuanto al blog, en espera de la llegada de los alumnos de PSI del próximo curso académico, seguiré incluyendo cualquier noticia relevante que pueda ser de interés.

jueves, 11 de junio de 2009

Práctica 4.: Protocolos Seguros et al.

Este año la práctica cuatro ha sido optativa. El tiempo, al igual que nuestros discos duros, CPUs, RAM etc., es un recurso limitado. Es tiempo de exámenes pero, tras la tempestad, siempre viene la calma. Dejo en esta entrada copia de la práctica IV por si alguien está interesado en el último tema que hemos visto en PSI y quiere cerrar la asignatura en verano probando herramientas de seguridad. Casi todo el mundo trabaja a cambio de algo, €€s, puntos extra, una buena nota, unas palmaditas al ego personal, etc., pero también debemos pensar que no está nada mal trabajar a cambio de conocimientos y experiencias, sin buscar un premio tangible inmediato. El premio en estos casos suele venir a medio-largo plazo, y muchas veces con intereses.


Práctica IV.: Criptografía y Protocolos Seguros
Prof. A. Santos del Riego
Protección y Seguridad de la Información (PSI)
Facultad de Informática. Universidade da Coruña


El objetivo de esta práctica es comprender la importancia de los algoritmos criptográficos y su aplicación-funcionamiento en la forma de protocolos seguros. Hemos tratado en las clases teóricas los conceptos que rigen el funcionamiento de los criptosistemas simétricos y asimétricos, así como su integración híbrida en protocolos seguros. Se ha estudiado el esquema de funcionamiento de la firma digital y la necesidad de autoridades certificadoras. Finalmente, se ha presentado el funcionamiento de algunos protocolos y entornos seguros (SSH, GPG, SSL, etc.). Se deberán aplicar los conceptos adquiridos en la resolución de los siguientes apartados:


1.- Tomando como base de trabajo el GnuPG y utilizando dos usuarios de su máquina virtual pruebe sus diversas utilidades:


a) Generación de pares de claves
b) Cifrado y descifrado asimétrico de ficheros
c) Cifrado y descifrado simétrico de ficheros
d) Firma de ficheros
e) Verificación de la firma
f) Generación de ficheros de firma acompañante
g) Intercambio de claves
h) Validación de claves
i) Revocación de claves
j) Gestión básica de claves

2.- Analice el proceso criptográfico que se realiza en cada uno de los subapartados del punto anterior.

3.- Tomando como base de trabajo el SSH pruebe sus diversas utilidades:

a) Abra un shell remoto sobre SSH y analice el proceso que se realiza. Configure su fichero ssh_known_hosts para dar soporte a la clave pública del servidor.
b) Haga una copia remota de un fichero utilizando un algoritmo de cifrado determinado. Analice el proceso que se realiza.
c) Exporte una sesión X de forma segura.
d) Configure su cliente y servidor para permitir conexiones basadas en un esquema de autenticación de usuario de clave pública.
e) Utilice el agente de soporte de claves como complemento al apartado anterior.
f) Mediante túneles SSH securice algún servicio no seguro.

3.- Tomando como base de trabajo el servidor Apache2

a) Configure una Autoridad Certificadora en su equipo.
b) Cree su propio certificado para ser firmado por la Autoridad Certificadora. Bueno, y fírmelo.
c) Configure su Apache para que únicamente proporcione acceso a un determinado directorio del árbol web bajo la condición del uso de SSL y previa autenticación.

4.- Tomando como base de trabajo el openVPN deberá configurar una VPN entre dos equipos virtuales del laboratorio para que garantice la confidencialidad entre sus comunicaciones.

--
El diablo nunca duerme,

miércoles, 10 de junio de 2009

Bitácora de PSI.: S y familia

En el capítulo anterior hemos visto los fundamentos y hoy aprenderemos "jugando" con algunas de las herramientas típicas de nuestros entornos de trabajo.

Empezaremos por el GnuPG. De su página principal “GnuPG is the GNU project's complete and free implementation of the OpenPGP standard as defined by RFC4880 . GnuPG allows to encrypt and sign your data and communication, features a versatile key managment system as well as access modules for all kind of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries are available. Version 2 of GnuPG also provides support for S/MIME
Desde un punto de vista práctico, vemos el funcionamiento del GnuPG en las tareas de cifrar un fichero, tanto de forma simétrica como asimétrica, el proceso de cifrado para envío, tanto con firma como sin ella y, finalmente, el proceso de descifrado. Se hace referencia en todo momento a los aspectos vistos en la clase anterior de fundamentos pero, en este caso, sobre una de nuestras típicas herramientas. Para una completa información GnuPG.

También analizamos el funcionamiento de otro de nuestros clásicos, SSH. De su página principal “OpenSSH is a FREE version of the SSH connectivity tools that technical users of the Internet rely on. Users of telnet, rlogin, and ftp may not realize that their password is transmitted across the Internet unencrypted, but it is. OpenSSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other attacks. Additionally, OpenSSH provides secure tunneling capabilities and several authentication methods, and supports all SSH protocol versions”.

Vemos las principales posibilidades de openssh, y que hace otras muchas cosas además de un ssh a un host, introducir el user y password y tener un shell remoto sobre una conexión “segura”. En primer lugar se analiza el conjunto de utilidades del openssh. De su página principal “The OpenSSH suite replaces rlogin and telnet with the ssh program, rcp with scp, and ftp with sftp. Also included is sshd (the server side of the package), and the other utilities like ssh-add, ssh-agent, ssh-keysign, ssh-keyscan, ssh-keygen and sftp-server”.

Recuerda que el 22 es el número preferido del SSH, que ningún puerto está casado con nadie, y casi todo bajo este cielo abrasador es cambiable. Recuerda también que podrás incluir políticas de filtrado de este y otros servicios, tanto a nivel de firewall, como de wrappers.

SSH hace tanto autenticación del servidor como de usuarios, proporciona un cierto nivel de privacidad en las comunicaciones mediante la típica aproximación híbrida (asimétrico para intercambio de clave de sesión y simétrico para cifrado) y permite la redirección de canales TCP-IP mediante túneles cifrados. También nos proporciona un servicio de gestión de claves para su centralización.

Bueno, me conectaré a un servidor SSH para ver lo que pasa.

batman@dead: $ ssh 192.111.6.66
The authenticity of host '192.111.6.66 (192.111.6.66)' can't be established.
RSA key fingerprint is f1:36:1c:08:92:54:f8:0a:9d:bd:19:65:d5:38:c6:62.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.111.6.66' (RSA) to the list of known hosts.
batman@192.111.6.66's password:
[…]
batman@alive: $


Bueno, que coñazo estos informáticos, siempre haciendo preguntas raras. Ante la duda, yes. ¿Qué está pasando en ese momento de la conexión?. De forma resumida, el host cliente no dispone de la clave pública del host servidor para poder mantener relaciones y, por lo tanto, el servidor le remite su clave pública. En este punto es el cliente, nosotros, los que deberemos indicar si aceptamos o no la clave pública de dicho servidor, identificado por su IP, su clave pública y la correspondiente huella digital. Es aconsejable verificar este tipo de claves antes de aceptarlas dado que, en futuras conexiones, será utilizada de forma automática. Al igual que vimos en el tema dedicado al “sniffing” y las posibilidades de ataque a conexiones seguras https, también es posible inyectar claves para comprometer la confidencialidad de las conexiones seguras SSH.

La aceptación de la clave pública del servidor hará que se añada en el fichero $HOME/.ssh/known_hosts de la máquina cliente la clave pública del host servidor que, por cierto, se encuentra en /etc/ssh/ssh_host_[rsadsa ]_key.pub.

Si quieres "cargarte" alguna clave pública anteriormente aceptada puedes borrar la correspondiente entrada del fichero known_hosts. También podrás utilizar el fichero /etc/ssh/ssh_known_hosts para mantener de forma manual las claves públicas de los hosts confiables.

En la conexión realizada también vemos que el método de autenticación a nivel de usuario es el típico de user-password que esté definido en el servidor.

Los ficheros que te permitirán configurar distintas opciones SSH los encontrarás en /etc/ssh/ssh_config (cliente) y /etc/ssh/sshd_config (servidor). Un vistazo a dichos ficheros te permitirá identificar rápidamente las posibles opciones disponibles. No dejes para mañana, el fichero que puedas mirar hoy.

En SSH también podrás utilizar un esquema asimétrico de autenticación. En este caso tendrás que crear a cada usuario sus correspondientes claves públicas y privadas, tal y como vimos en la clase anterior de fundamentos.

$ ssh-keygen –t rsa
batman@dead: $ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/batman/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/batman/.ssh/id_rsa.
Your public key has been saved in /home/batman/.ssh/id_rsa.pub.
The key fingerprint is:
31:04:ac:ab:63:13:c0:f4:a5:0b:59:1a:77:a8:52:26
batman@dead

Podemos utilizar la clave pública de los usuarios para el proceso de autenticación contra el servidor. Para ello deberemos añadir al fichero $HOME/.ssh/authorized_keys2 del servidor las claves públicas de los usuarios autorizados, disponibles en los ficheros $HOME/.ssh/id_[dsarsa].pub del cliente.

Finalmente analizamos las posibilidades de tunelizar con SSH servicios no seguros. Para ello podemos hacer forwarding de tráfico de un puerto local a una remoto o de uno remoto a uno local. Por ejemplo, para tunelizar una conexión mediante forward local contra un servidor web no seguro.:
# ssh –L 666:ssh-www.host:80 apache@ssh-www.host

Si abres tu navegador en la máquina local y te conectas a http://localhost:666/ te "forwardeara" el tráfico sobre un túnel SSH contra el puerto 80 del host ssh-www.host. Existen otras muchas posibilidades en el uso de túneles SSH. Para más información openSSH.
Señalar también la existencia de sshfs para exportar sistemas de ficheros de forma segura.

# sshfs batman@alive:/batmovil-remoto /batmovil-local
Para concluir y no dejar fuera el más típico, tópico, …, de nuestro minimundo de la seguridad, se analiza el handshake del SSL-TLS (Secure Socket Layer-Transpor Layer Security). Incluir información básica sobre esta pareja sería redundar la mucha información disponible en la red. Muy recomendable la entrada "The First Few Milliseconds of an HTTPS Connection", que desglosa a todo detalle lo que acontece en una conexión HTTPS (gracias Nacho).
En el último cuatrimestre hemos visto distintos temas relacionados con la PSI. Todo este material constituye una base más que suficiente para evolucionar en cualquiera de los múltiples campos de esta disciplina. Dedicar muchas horas a “cacharrear” con nuestros equipos es la mejor herramienta para adquirir todos aquellos conocimientos, tanto teóricos como prácticos, necesarios para nuestra práctica profesional. Y recuerda que el demonio nunca duerme.
Hay otros muchos temas de interés que, por las limitaciones espacio-temporales de la asignatura, resulta inviable plantear su inclusión, por lo que las nuevas posibilidades que se te abren son muchas y variadas (mecanismos y herramientas de control de acceso, seguridad perimetral a distintos niveles, detección de intrusiones, honeys, WIFI y seguridad, programación segura, auditorías de seguridad, análisis forense, metodologías de seguridad, etc., etc.)
Y recuerda que en muchas ocasiones lo más sencillo puede ser la mejor opción, especialmente cuando no se dispone de personal técnico o, el disponible, no está lo suficientemente cualificado (o está total o parcialmente quemado).

martes, 9 de junio de 2009

Bitácora de PSI.: Protocolos con [s]. Fundamentos

Aunque a este tema se le podría llamar fundamentos de criptografía, el fin de gran parte de lo que hacemos está en su aplicación a distintos ámbitos de la profesión. En gran medida el aplicativo de estos fundamentos coge forma en los llamados protocolos seguros.

Iniciamos el día con la típica y tópica clasificación de criptosistemas.:

- Clásicos vs. modernos. Recuerda que tarde o temprano todo modernillo se acaba pasando al bando de los clásicos.
- Bloque vs. flujo. ¿Cómo lo quieres?, “a lo bruto o poco a poco”
- Secreta (Simétricos) vs. Pública (Asimétricos). A la una, o las dos, ¡vendido!

Simétricos. Recuerdo el DES, con su gran clave de 56 bits, su elegancia y seguridad. También su muerte y paso al bando de los clásicos. Si, la longitud sí que importa, al menos en criptografía. Pero el hueco dejado por alguien siempre es cubierto por otros; 3DES, blowfish, IDEA (con sus 128 bits), o la estandarización del flexible Rijndael en la forma del AES (bloque de 128 bits y claves de 128, 192 y 256 bits). Estos tienen una clave más larga. Sobra decir que en los criptosistemas simétricos se cifra con una clave, y se utiliza la misma clave para el descifrado. En muchas de las cosas que hacemos vemos criptosistemas simétricos, por ejemplo.:

$ scp –c blowfish /etc/passwd psi@10.10.106.66:passwd

Es fundamental en seguridad el uso de la (s). Póntela (en el cliente), pónsela (en el servidor).

No se debe pensar en la familia de los md5, sha[2, 3], RIPE128-160 et al. como algoritmos criptográficos, son funciones resumen o hash. Otra cosa muy distinta es su directa aplicación en nuestros protocolos seguros, autenticación, etc. En muchos de nuestros linux se utiliza una función hash como sistema básico de autenticación. ¿Cómo funciona?. Si mi password de superusuario es “acnun1erasu2solocotorp3on4soruges;” (un poco largo este password!), la aplicación de la función hash a cualquier password de “cualquier longitud”, me proporcionará una huella digital. Cuando haga un proceso de autenticación, si la huella resultante del password tecleado coincide con la del usuario, la autenticación será correcta. Y por cierto, no todas las funciones hash son igual de seguras, como es de esperar (ciclo de vida de los algoritmos hash).

Sobre funciones hash tal vez la noticia más relevante en estos momentos sea la competición de algoritmos hash del NIST que, en la forma de SHA-3, nos proporcionará una nueva función para integrar en nuestros aplicativos y protocolos. En 2011 estamos llegando al final de la competición y únicamente quedan 5 funciones en concurso.

Cambiando de bando, cada entidad en un criptosistema asimétrico utiliza dos claves inversas, aunque podría disponer varias, una pública y otra privada. Se cifra con la pública y se descifra con la privada y viceversa. Si quiero enviar algo cifrado necesitaré la clave pública del intercepto o destinatario y cifraré el mensaje con su clave pública, para que dicho receptor la pueda descifrar con su privada. Nota que el nombre de las claves hace referencia a su grado de intimidad. La pública se va con cualquiera y la privada es muy reservada. Como ejemplos de asimétricos, Diffie-Hellman, RSA, DSA, ElGamal o CEE (Criptografía de Curvas Elípticas).

El primero que con la siguiente clave pública RSA de ssh obtenga la privada tendrá una MH en la asignatura. Recuerda que hay otras muchas asignaturas que estudiar y estamos en época de exámenes.

ssh-rsa AAAAB3NzaC1yc2GABAABIwAAAQEAsL2ZngJ0aPrtsrHrJmAAk52SnN0navtOBcDznwTHgyNE+QMVXCux7PlwhDO/fKaziyJJPoipLlGlxv8MGY3vg3YfKqdjoTedJOvqH5egk3D5+LDTd1xQ8UlE31IAlgsFd8tw13pt1axQ5WXSonbZfo5RKv+OrZ8AUSQHcddiuWRvSO3Er6Y2IUYV0hteX6t+NPM9D0gXxy4KBtmehY/xPkwZgaX1AwEQmc/Va0yRMDzlvHqPQSfYhS3FoD7h451FldglNqVYEvo0NkIGOfC14g6+v+tYEBwa01RVwBTFPkCaCUfr0oK+klgGISiqui7IMAXn0ZZP4CyAUj+bYbiEnQ== psi@dead

Aquí os dejo otra, pero esta de verdad

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAkyrFhgJeTOp1OpxgjYoeXv2y9NpTFepLP3HH9eZ4YMjBFiz4mCai4HecLBts6Z1MrViA/x/m7PIC4h7DLpdqi5ifrugaWBPXElD8J8U51JNrxBNB5i3nxWwXYbw/o8uVNItYwftEgxmphSHIn86hbvj3/BWZP59HtS9sFbwB4SxeMiSPuSUmPtC3DB+8/+X/62MxzFldTTV0aGvNaGsjREq3LoDDnBmWY3vfPIDsf8tLCNngdaIFmKWhW5QdEbyZJK1GH9Kb2aFI7w0iohPr4l0BWk+qIEmaM3GvNXEQ62SZ/9J5hbUmQxqS0i6JqysmZZZeeBEJGniibs8mBcjhuQ== psi@dead

También hemos hablado de cifradores de bloque, o a lo bruto, en los que se aplica una función a cada bloque a cifrar normalmente un número de ciclos. Y los cifradores de flujo, poquito a poquito, a nivel de bit o de carácter. Entre los cifradores por bloque, RC2, IDEA, blowfish, RC5, AES, RC6. Entre los cifradores de flujo, el RC4.

Pero bueno, en un planeta plagado de soluciones híbridas, en seguridad no íbamos a ser menos. La mayoría de nuestros protocolos seguros tienen el mismo comportamiento. Sistema asimétrico para intercambio de clave de sesión, y comunicaciones haciendo uso de la clave de sesión mediante un sistema simétrico. Por citar algunos, el GPG, SSH y SSL siguen este comportamiento.

En este punto hemos analizado el sistema de cifrado y descifrado utilizado en RSA y las características que le aportan una cierta fortaleza. Se estudian los teoremas y demostraciones que proporcionan una cierta fortaleza al RSA, que no se incluyen en esta entrada al estar disponibles en varias fuentes. Para más información al respecto recomiendo el capítulo 14 del “Libro Electrónico de Seguridad Informática y Criptografía” del Prof. Ramió Aguirre.

Finalmente hemos analizado el proceso de firma digital y el uso de autoridades certificadoras. De forma resumida, sobre el mensaje a firmar se aplica una función hash, que nos proporciona su huella digital. La huella digital se cifra con la clave privada del remitente. Se envía el mensaje y la huella cifrada. El receptor descifra el hash con la clave pública del emisor. Aplica la función hash al mensaje recibido, que podrá estar o no cifrado y, si el hash remitido y obtenido son iguales, podemos presuponer que todo está bien (que el mensaje es íntegro y que la identidad del remitente es la asociada a la pública utilizada). En el caso de que el mensaje esté cifrado habrá que descifrarlo, con nuestra privada si es un sistema asimétrico puro, o con la clave de sesión en el caso de híbridos. Pero, y las colisiones. En los últimos años mucho se ha escrito sobre que se haya escrito mucho de colisiones. Las colisiones existen en las funciones hash desde su aparición. Es imposible meter un elefante en un seiscientos, al menos sin trocearlo. La teoría de la información no nos engaña y, en toda función hash, por mucho que nos rompamos la cabeza, siempre existirán colisiones. Otra cosa es la posibilidad de poder encontrar colisiones en un tiempo computacional aceptable y su posible uso en romper la seguridad de nuestros sistemas. En este sentido, hemos asistido a la generación de certificados con distinta clave pública con colisión de hash, a colisiones en las elecciones USA, a colisiones en las declaraciones de la renta, a colisiones de tráfico, etc., etc. Hemos visto colisiones, y seguiremos viendo colisiones, nos guste o no.

Propuesta de ejercicio. Coge el ls de tu sistema y genera su hash md5. ¿Podrías encontrar un contenido que produzca una colisión con el ls y, por lo tanto, genere el mismo hash o huella?. ¿Podrías encontrar un binario “usable” que colisione con tu ls?.

Por otra parte, para garantizar que una clave pública pertenece a una determinada entidad, se utilizan certificados y autoridades certificadoras. En pocas palabras, un certificado tiene una cuanta información sobre la entidad o bicho a certificar, además de su correspondiente clave pública. El certificado estará firmado por una Autoridad Certificadora (una función hash aplicada sobre el certificado genera una huella digital que será cifrada con la clave privada de la Autoridad Certificadora). Obviamente, únicamente la AC dispondrá de la clave privada para poder cifrarla. Para verificar el certificado se aplica el hash al certificado y se descifra la huella mediante la clave pública de la AC. Si la huella obtenida y la descifrada son iguales, el certificado será verificado correctamente. Y, ¿dónde tengo la clave pública del la AC?. En gran parte del software que tienes instalado tienes los certificados de las AC, incluidas sus claves públicas. En tus navegadores sueles tener alguna opción de gestión de certificados, entre ellos de varias AC, que serán utilizadas en caso de tener que verificar algún certificado. ¿Y si me he creado una AC propia con la que firmar certificados?. Siempre podrás importar en los sistemas de gestión de certificados de tus clientes el certificado con la clave pública de tu AC. Entre los estándares de certificados digitales destacar el X509, utilizado en muchas de nuestras infraestructuras de PKI (Public Key Infraestructure). Para más información sobre firma digital recomiendo el capítulo 17 del “Libro Electrónico de Seguridad Informática y Criptografía” del Prof. Ramió Aguirre.

Y recuerda, a bicho que no conozcas, no le pises la cola

miércoles, 3 de junio de 2009

Bitácora de PSI.: (Crypto)

Si, aunque Rapsuskley & Hazhe dirían "dame criptonita", nosotros más bien tenemos que decir "dame criptología". Dejando a un lado el mundo de la música paso a entrar en materia.

Palabrejas de nuestro mundo de la PSI.:

- Autenticación (y tú, ¿quién [c...] eres?). No te olvides que tú puedes ser muchas cosas; un cliente, un servidor, un usuario, un proceso, o simplemente un pensamiento. Los típicos sitemas login-password o nuestro amigo kerberos podrán ayudarte, así como la firma digital, la certificación, o la biometría.

- Control de acceso (y tú, ¿qué [c...] quieres?). No te olvides que puedes querer muchas cosas; acceder a un servicio, a un fichero, o a una cuenta bancaria. Y recuerda extremar las precauciones en tu sistema de control de acceso en época de carnavales. La autenticación y el control de acceso suelen ser muy buenos amigos. Esquemas basados en credenciales, roles y atributos podrán ayudarte en la forma de ACLs, filtros, cortafuegos, o en la forma de simples rwx o tickets de kerberos, entre otros.

- Confidencialidad (el contenido de este párrafo es confidencial). Cíframe despacito, pero procura no meterme retardos. Muerte al telnet, ftp, tftp y familia. Larga vida al s(*). No te olvides guardar siempre la etiqueta y el protocolo exigido en cada caso, y mejor con s que sin ella.

- Integridad de datos (soy quien digo ser aunque en muchas ocasiones trate de ser quien no soy, ¿quién soy?). Procura dejar huella en todo lo que hagas y, ante todo, se íntegro en toda decisión que tomes.

- No repudio (yo no he sido, ha sido ...). Cualquier padre o madre asiste diariamente a situaciones más bien de repudio. La firma digital y las autoridades certificadoras podrán ayudarte, no con tus hijos, pero si con tus sesiones y transacciones.

- Accesibilidad (sal a dar un paseo por nuestras ciudades sobre una silla de ruedas y comprenderás lo que es la no accesibilidad). No te olvides que puedes querer acceder a muchos sitios; un servidor, un fichero, una base de datos, etc. Esta palabreja es colega de la disponibilidad y se lleva muy mal con la [D]DoS.

Analizando todas estas palabras es fácil concluir que la criptografía no está nada mal, y que tiene un cierto interés, o tal vez mucho interés. Pero, y la criptología y el criptoanálisis?. La criptología abarca ambos campos, la criptografía y el criptoanálisis. El primero es el lado de la luz, y el segundo el de la oscuridad, aunque recuerda que las fronteras entre ambos son muy difusas. El primero es el mundo de la algoritmia criptográfica, y el segundo el de la contra-algoritmia. El primero crea, y el segundo destruye. Recuerda que esto es un proceso de control de calidad, y que el criptoanálisis realiza una función muy importante, deshacerse de los débiles. Durante los últimos años hemos visto la desaparición y aparición de muchos algoritmos de cifrado pero, en el fondo, seguimos con la sensación, aunque dichos algoritmos han evolucionado considerablemente, que lo único que estamos haciendo es incrementar cada vez más el tamaño de nuestras claves. Esto parece una carrera sin final entre la longitud de nuestras claves y la potencia computacional al servicio de la [pseudo]fuerza bruta. Pues bien, "que la fuerza te acompañe". Y si, hemos asistido a muchas chapuzas tanto en los algoritmos como en los protocolos seguros y sus implementaciones pero, aún así, son una herramienta muy potente de securización.

Bueno, me has convencido que la criptografía, o mejor dicho, la criptología, es de gran importancia pero, ¿a qué la aplico?. De momento no se ha descubierto ningún método para hacer bocadillos de chorizo cifrados, pero quien sabe. Por lo tanto, tendrás que conformarte con tratar de cifrar, de la mejor forma posible, tanto tus servicios-comunicaciones como los datos.

Y, ¿cómo puedo cifrarme?. Recuerda tus enseñanzas, esas que nos hablaban de las malditas 7 capas del modelo OSI, y podrás imaginarte que puedes cifrar la datos-información en muchas de ellas. En principio, sin divagar en exceso, se podría hacer a nivel de aplicación para, por ejemplo, cifrar tus datos-ficheros. Un ejemplo de este nivel puedes encontrarlo en un viejo conocido, el GnuPG, o GPG (también disponible para los otros en la forma de GPg4win). Y, ¿quiénes son los otros?. Tal vez esta pregunta deberías hacérsela a Amenábar, aquí estamos para hablar de "mi" asignatura, como diría Umbral. También puedes bajar de nivel y cifrar la sesión por medio de la "sslificación", toma nueva leche a la RAE, de cualquier amigo que no tenga una "s" al principio o al final. En este caso SSL, o el TLS son nuestros amigos inseparables que, aunque apunta formas, no termina por vislumbrarse su muerte. Para concluir, no podemos dejarnos fuera otro clásico de la seguridad, las VPNs (Virtual Private Networks), con su máximo exponente de implementación en IP[6]sec. Si quieres hacer pruebas en laboratorio, y aplicar el dicho de aprende jugando, te recomiendo OpenVPN. Existen otras soluciones para VPNs o túneles seguros, como Eclipt Secure Tunnel, o por medio de stunnel o el mismo ssh con la redirección de IPs y puertos. También podrás plantearte el uso de túneles de cifrado a nivel 2.

Y los datos, ¿cómo los cifro?. Pues con mucho cuidado. En este punto podemos diferenciar dos ámbitos, el cifrado de ficheros y el de sistemas de fichero. Para jugar con alguna de las múltiples herramientas para el primer caso puedes utilizar el ya comentado GPG y, para el segundo, muchos de nuestros kernels actuales tienen soporte para cifrado de los sistemas de ficheros. De gran interés en medios extraíbles. Ese fichero de las máquinas debian del laboratorio que has estado "tocando" en la práctica 3, llamado /etc/fstab, te proporciona la opción encryption para tal tarea, especificando además el algoritmo de cifrado.

Además de la seguridad en las comunicaciones, también se debe considerar la seguridad en la parte cliente (por ejemplo navegadores), así como en los servidores, sus SGBDs y aplicativo desarrollado (por ejemplo servidores web, JSPs, ASPs, PHP, etc.). En este último nivel son muchos y variados los problemas de seguridad identificados (SQL Injection, XSS o Cross Site Scripting, Ejecución Remota de Código, RFI (Remote File Inclusion) o Directory traversal, entre otros). Sin duda alguna, este mundo no es del todo decidible. En este contexto, toda sesión siempre puede ser susceptible de sufrir una cierta usurpación, tanto en la parte cliente, como en la propia comunicación o en el servidor.

El infierno está lleno de buenas intenciones,

Bitácora de PSI.: El sacrificio

El tiempo es un recurso limitado y, como todos los años, tengo que asumir el sacrificio de algunos temas en PSI (cuatro meses no dan para mucho más). En este curso académico enterraremos los siguientes (que no se quejen estos temas que en el anterior lograron sobrevivir).:

- [*]Virtualización. Dedicado al mundo de la [para]virtualización, sus tecnologías y soluciones. Es la moda desde hace unos años. Pronto "emigraremos" a nuevas modas. De momento muchos están en las nubes, y otros a la espera de acontecimientos.

- Soluciones de almacenamiento. En este nos centramos en las soluciones y tecnologías de almacenamiento, tanto en entornos NAS (Network Attached Storage) como SAN (Storage Area Network). Algunos aspectos del almacenamiento han sido tratados parcialmente en temas anteriores.

-Software y seguridad. Tema dedicado a aspectos generales de la seguridad en el software. Lo resumiré en una frase, "no dejes para mañana el parche que puedas poner hoy". Entre otras muchas cosas trata el tema de las políticas y herramientas para la gestión de parches en nuestros sistemas, especialmente los relacionados con la seguridad. Fuera de este tema quedaría todo lo relacionado con el apasionante mundo de la programación segura.

- LOPD & RD medidas de seguridad. Hace años que eliminé este tema. Aunque es de cierta importancia, aburre, hasta en la sopa. Oirás hablar de esto en muchas otras asignaturas, conferencias, coloquios, etc., etc. Sin duda alguna este tema está bien muerto en el contexto de la asignatura de PSI. También hace años maté la práctica de laboratorio relacionada con esta temática.

- Malware. Este si siento tener que matarlo este año, pero debo elegir entre este o criptografía-protocolos seguros, resultando ganador este último por diversos motivos, incluido los descriptores de la asignatura. Si te interesa el tema, entre las muchas referencias posibles te recomiendo http://vx.netlux.org/.

No es mala la muerte cuando se lleva a quien debe,

martes, 2 de junio de 2009

Bitácora de PSI.: Alta Disponibilidad et al.

No entraré en cuestiones que quedan muy bonitas en la teoría pero que para nuestra operativa profesional no nos van a aportan muchas soluciones, como lo que pueda ser o dejar de ser un sistema tolerante a fallos o un sistema de alta disponibilidad, así como sus sutiles diferencias. En pocas palabras, la Alta Disponibilidad, High Availability (HA), hace referencia a las instalaciones pensadas para "garantizar" un servicio eficiente durante los 525600 minutos del año. Como nota adjunta, señalar la posibilidad de mantener las conexiones y recuperar las sesiones en entornos de alta disponibilidad con persistencia.

Cuando hablamos de clusters siempre pensamos en un grupo o "pandilla" de equipos que, por un motivo u otro, tienen una cierta e "íntima" relación. En cuanto a pandillas, las hay de muchos tipos.

Los clusters para procesamiento de datos constituyen una potente herramienta en tareas que requieren de una gran potencia de cálculo. Aunque en un primer momento se podría pensar en temas de edición de vídeo y rendering, cálculo científico intensivo, etc., en nuestro caso iríamos más bien hacía el cómputo al servicio de los ataques por (pseudo)fuerza bruta. Entre las soluciones disponibles para este tipo de clusters destacar el proyecto Beowulf y Mosix, aunque no tienen un gran interés en nuestro ámbito de actuación.

Otro tipo de clusters estaría orientado a la redundancia de máquinas proporcionando el mismo servicio. Recuerda que la redundancia es un mecanismo de seguridad. De esta forma, nos protegeremos contra posibles fallos del servicio y, o, máquina, además de incrementar la potencia en la prestación del servicio.

En este tipo de instalaciones deberemos plantearnos una serie de tareas, como el control de los computadores del cluster, la monitorización de servicios y su replicación, las comunicaciones y, pensando en sistemas que proporcionan un mismo servicio, la forma de compartir el almacenamiento.

En cuanto al almacenamiento existen varias posibilidades que, en gran medida, estarán en función de los €s disponibles. No debemos olvidar que el factor económico tiene que ser uno de los principales en toda toma de decisión y que bajo ningún concepto "debemos matar usuarios a cañonazos", aunque siempre habrá capullos dispuestos a "matar hippies en la Cíes". El actual despliegue de cañones en nuestra profesión empieza a apestar. Sin duda alguna es el momento de volver al camino de la búsqueda de la sencillez para evitar ???. Recuerdo la semana que pasé impartiendo clase en cierta universidad de un pequeño pero gran país en el que un joven con una creatividad asombrosa proporcionaba servicio de correo electrónico y web a toda la organización con un único PC. De vuelta al contexto de nuestro desarrollo, se podría plantear desde servidores de disco en red sobre NFS (Network File System) o Samba, hasta soluciones de almacenamiento SAN (Storage Area Networks). También otras alternativas como la mera sincronización de dispositivos de almacenamiento, por ejemplo con un rsync (dependiente del entorno de trabajo), el exportado de disco cifrado mediante sshfs (Secure Shell File System), o el uso de sistemas de ficheros distribuidos como GFS (Global File System) o MogiFS.

Por su parte, la detección de servicios deberá encargarse de identificar si están "caídos". De la misma forma habrá que monitorizar si un determinado host está o no operativo. Aunque hay distintas soluciones únicamente incluiremos en este punto mon, para la monitorización de servicios, y heartbeat para la interrogación entre hosts. El proceso de monitorización deberá hacerse en la capa 7 por razones obvias (si, esas con las que nos han torturado a tantos y tantos estudiantes de informática a lo largo de los años). Y, dado que estamos en PSI, sería muy aconsejable que toda comunicación estuviese cifrada adecuadamente. También podremos incluir redundancia parcial en nuestros equipos, por ejemplo de fuente de alimentación, tarjetas de red, controladoras de disco, etc.

En cuanto a soluciones, aunque existen varias, únicamente incluiré el Proyecto Linux Virtual Server (LVS). De forma resumida, instalaremos un conjunto de sistemas en el que un balanceador de carga, que podría redundarse según las necesidades, constituirá el elemento de interacción con cualquier petición de servicios. El balanceador deberá re-direccionar las peticiones a los servidores según unos criterios que "parezcan" medianamente inteligentes (carga de los servidores, anchos de banda, con persistencia, o por cualquier ecuación que pueda integrar de una forma más o menos ponderada diversos parámetros característicos de carga, entre otras). Los servidores podrán atender directamente las peticiones o utilizar el balanceador como un proxy. Recuerda que los "cuellos de botella" son nuestros enemigos. Señalar en este punto la existencia de dispositivos orientados al balanceo de carga. Aunque no soy muy amigo de refernciar soluciones comerciales, en este caso haré una excepción con los balanceadores de carga barracuda para que el alumno tenga referencia de la existencia de este tipo de productos. Obviamente existen otras muchas alternativas.

Sobre la naturaleza del balanceo, podrá plantearse a nivel IP, característico del LVS, o a nivel de aplicación-servicio, mediante el uso por ejemplo de reverse-proxy (cuyo nombre es autoexplicativo). Apache dispone de distintos módulo para implementar reverse proxy.

El servicio de DNS (Domain Name System) nos puede proporcionar una alternativa básica al balanceo de carga y que no requiere "grandes" desplieges. En pequeñas instalaciones esta podría ser una opción aceptable. Los servidores DNS de nuestro dominio responderán a las peticiones hacia el servidor de referencia con una relación de IPs, normalmente mediante un round-robin. Como es obvio, esta solución no contemplará la carga de los servidores, ni el ancho de banda estimado entre el cliente y los servidores que pueden atender su petición (de interés en el caso de clusters distribuidos geográficamente). En el caso de un servicio web, la dirección www.[nuestro-dominio] se resolvería cíclicamente mediante un round-robin sobre varias IPs. Como es obvio, será necesario incluir algún mecanismo que permita retirar una resolución ante una caída de un servidor. ¿Y si está "cacheada" en uno o más clientes?. La implementación en el caso de bind únicamente requerirá de varias entradas CNAME, por ejemplo.:

server1 IN A 193.144.48.10

server2 IN A 193.144.51.16

server3 IN A 193.144.63.83

www IN CNAME server1

IN CNAME server2

IN CNAME server3

Unido a la multitud de referencias en internet sobre configuración de clusters de HA, con o sin NAT, a nivel 2 o 3, etc., para los amantes de la literatura técnica en papel, esa que debería tender a su desaparición completa, señalar por ejemplo el artículo "Replicación y alta disponibilidad con pgpool II de PostgreSQL" del número 108 de la publicación Mundo Linux.

Entre las diversas herramientas con las que podremos "jugar", considerando que jugar es la mejor técnica para aprender, señalar ldirectord (para monitorización de servicios HTTP y HTTPS), heartbeat (para monitorización de equipos), o el entorno gráfico lvs-gui (para configurar un cluster LVS). Existen muchas otras opciones de HA y load balancing aunque esta entrada no tiene como objetivo tal revisión.

Al finalizar la clase se analiza la evolución en nuestros sistemas de información y servidores, desde los monoservidores, pasando por soluciones redundantes con o sin balanceo de carga a las configuraciones de servidores basados en la virtualización y para-virtualización. Finalmente vemos que las posibilidades que nos ha proporcionado el mundo de la virtualización y su aportación en el salto a lo que hoy se conoce como computación en la nube (ver por ejemplo simulador del IBMSmartCl​oud).
Juega aprendiendo y aprende jugando,