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).
