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.:
Mostrando entradas con la etiqueta PKI. Mostrar todas las entradas
Mostrando entradas con la etiqueta PKI. Mostrar todas las entradas
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.: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
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.
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.)
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).
lunes, 3 de noviembre de 2008
En la práctica 4 de la asignatura de PSI, uno de los apartados está relacionado con la creación de una autoridad certificadora y la generación de certificados firmados para su uso en un servicio https sobre apache. En http://www.debian-administration.org/articles/618 tienes una entrada que te puede interesar para dicho apartado.[Fuente.: Debian Administration http://www.debian-administration.org/]
Suscribirse a:
Entradas (Atom)