Túneles con OpenSSH

(o cómo ahorrarse la VPN seguramente innecesaria)

por Luciano Bello

http://www.lucianobello.com.ar/openssh

luciano(arroba)linux(punto)org(punto)ar

Segundas Jornadas de GNU/Linux y Software Libre en Ingeniería

Viernes 16 y Sábado 17 de julio

Ver1.3 Copyright - 2004 Luciano Bello. Se permite la copia, distribución y/o modificación de este documento bajo los términos de la GNU Free Documentation License, Versión 1.1 o cualquier otra versión publicada por la Free Software Foundation; sin Sección Invariante, sin Texto de Portada, y sin Textos al respaldo de la página de título. Una copia de la licencia se puede encontrar aquí.

Temario

Introducción a SSH y OpenSSH

Conceptos de OpenSSH

Por qué “tunelear” conexiones

Interacción de túneles entre firewalls

Túneles simples locales

Túneles locales a otro servidor

Túneles locales “off-host”

Forwarding remoto

Implicancias de seguridad para el sysadmin

Implicancias de seguridad para el usuario

Si hay tiempo... algo de práctica!

Introducción a SSH

SSH significa Secure SHell, pero no es un shell!

SSH cifra todo el tráfico (incluidas las contraseñas) para eliminar de un modo efectivo las "escuchas", los secuestros de las conexiones y otros ataques a nivel de red.

Además ofrece amplias posibilidades de para la creación de túneles seguros!

Introducción a OpenSSH

OpenSSH es una versión LIBRE (bajo licencia BSD) del paquete de herramientas de comunicación segura del protocolo SSH/SecSH para redes.

Está desarrollado principalmente por el Proyecto OpenBSD, y su primera integración en un sistema operativo fue en OpenBSD 2.6.

Estos programas se desarrollan fuera de los EE.UU., usando código desarrollado en unos 10 países distintos.

Cifrado fuerte (3DES, Blowfish), compresión de datos

Esta muy destinado a la portabilidad

¿Por qué usar esta versión de SSH?

Por qué “tunelear” conexiones (I)

La principal razón:

Porque me permite utilizar servicios inseguros (como ser http, imap, pop, entre otros) sobre sesiones de SSH establecidas de manera (casi) transparente para ellos, sin necesidad de utilizar una VPN.

Por qué “tunelear” conexiones (II)

Al igual que en las VPNs, las conexiones van encapsuladas. Pero SSH lo hace a nivel de puertos (Port Forwarding), no de red, lo que limita/permite:

acceder a servicios TCP internos de una LAN con direcciones privadas (los túneles SSH no permiten forwardear UDP o protocolos no IP)

“seguirizar” mi clave plana de FTP (canal de control y comandos), Telnet, POP3, IMAP, authSMTP, NNTP......

atravesar un firewall donde solo el servicio de SSH está permitido

usar el SMTP de mi ISP para mandar mis e-mails desde cualquier lado, por más que el relay solo esté abierto para las direcciones asignadas por él

utilizar los servicios X de mi máquina remota a través de una red insegura

El entorno más sencillo

Vamos a largar con un ejemplo de acceso a un servicio IMAP, que está detrás del firewall de mi facultad. El mismo servidor corre un demonio OpenSSH. En casa tengo los clientes SSH e IMAP correspondientes.

Manos a la obra, nuestros primeros túneles

Queremos “segurizar” la conexión, además de “puentearnos” el firewall que impide que alguien de afuera se conecte al servicio IMAP del servidor.

Tunel simple local

Se refiere a cuando el servidor y el cliente de la aplicación a encapsular son también los extremos de la sesión SSH, que generamos así:

Manos a la obra, nuestros primeros túneles

home:~$ ssh -L 10143:localhost:143 imap.utn.edu.ar

ssh:	para iniciar una sesión ssh desde home

-L:	para forwarding local

10143:	puerto source del forwarding

localhost: servidor IMAP destino, visto desde el servidor SSH

143:	puerto destino del forwarding

imap.utn.edu.ar: servidor de OpenSSH, donde inicio la conexión.

Necesitamos reapuntar nuestro cliente IMAP a la punta del túnel, es decir localhost:10143, y vez de imap.utn.edu.ar:143. Después de autenticarnos, a buscar mi correo seguro!

Túnel simple local (gráficamente)

Manos a la obra, nuestros primeros túneles

Podemos corroborar este situación con el comando netstat

home:~$ ssh -L 10143:localhost:143 imap.utn.edu.ar

Un entorno no tan sencillo

Este es el nuevo escenario: El servidor IMAP no tiene servicio de SSH accesible desde afuera. Pero puede pasar que el firewall o que alguna otra máquina dentro de la DMZ sí lo tenga. Así, si mi servicio de IMAP está solo disponible para la red interna puedo usarlo igual, ya que será esta máquina (llamada bastion) quien realice la conexión final.

Manos a la obra, nuestros primeros túneles

Túnel local a otro servidor

Se refiere a cuando el servidor SSH no es quien corre la aplicación a tunelear, sino que es otra máquina accesible por esta.

Manos a la obra, nuestros primeros túneles

home:~$ ssh -L 10143:imap.utn.edu.ar:143 bastion.utn.edu.ar

ssh:	para iniciar una sesión ssh desde home

-L:	para forwarding local

10143:	puerto source del forwarding

imap.utn.edu.ar: servidor IMAP destino, visto desde el servidor SSH

143:	puerto destino del forwarding

bastion.utn.edu.ar: servidor de OpenSSH, donde inicio la conexión.

Básicamente, es la descripción de los parámetros es igual que en el caso anterior, de no ser por....

Túnel local a otro servidor (gráficamente)

Manos a la obra, nuestros primeros túneles

home:~$ ssh -L 10143:imap.utn.edu.ar:143 bastion.utn.edu.ar

salvaguardar con esto!

Esta parte de la comunicación está fuera del túnel!da con esto!

Esta parte de la comunicación está fuera del túnel!

Guarda con esto!

Esta parte de la comunicación está fuera del túnel!

Con algo de complejidad

En casa, home es el gateway de una red hogareña. Hay dos máquinas más, espiralito y tuxboy. Ambas máquinas tienen clientes IMAP (a home:10143).

Manos a la obra, nuestros primeros túneles

Tunel local “off-host”

Se refiere a cuando el túnel tiene su inicio en una red. Es decir, es un pseudo-gateway-de-puertos.

Manos a la obra, nuestros primeros túneles

home:~$ ssh -L -g 10143:imap.utn.edu.ar:143 bastion.utn.edu.ar

ssh:	para iniciar una sesión ssh desde home

-L:	para forwarding local

10143:	puerto source del forwarding

imap.utn.edu.ar: servidor IMAP destino, visto desde el servidor SSH

143:	puerto destino del forwarding

bastion.utn.edu.ar: servidor de OpenSSH, donde inicio la conexión.

Básicamente, es la descripción de los parámetros es igual que en el caso anterior, de no ser por....

-g :	indica que la conexión es “gateway”. Es decir, permite que cualquier conexión entre en el túnel, sin necesidad de que sea local

Túnel local “off-host”

Manos a la obra, nuestros primeros túneles

home:~$ ssh -L -g 10143:imap.utn.edu.ar:143 bastion.utn.edu.ar

Guarda con esto!

Estas partes de la comunicación están fuera del túnel!

GuarGuarda con esto!

Esta parte de la comunicación está fuera del túnel!da con esto!

Esta parte de la comunicación está fuera del túnel!

salvaguardar con esto!

Esta parte de la comunicación está fuera del túnel!da con esto!

Esta parte de la comunicación está fuera del túnel!

Cualquiera puede entrar por este puerto al túnel! Incluso alguien en InterNet!!!

Forwarding Remoto

En todos nuestros casos en modificador que usamos fue -L para Forwarding Local. Pero existe otro tipo de forwarding, menos usado: Forwading Remoto. Es igual al Local, pero al revés. El servidor de la aplicación es quien inicia la sesión SSH hacia el cliente de la aplicación.

Manos a la obra, nuestros primeros túneles

imap:~$ ssh -R 10143:localhost:143 home

De entrada el forwarding remoto puede parecer inútil, pero hay casos en donde puede sacarnos las papas del fuego. En el Apéndice I de www.lucianobello.com.ar/openssh se puede leer sobre una caso de uso específico.

En lineas generales, es útil a la hora de pedir ayuda con servicios internos de la red o cosas por el estilo =).

Sardineros Remoto

Manos a la obra, nuestros primeros túneles

El forwarding de puertos puede ser un problema de seguridad para los sysadmins:

Puentea los firewalls y proxies

Impide clasificar el tráfico

Permite el acceso a redes no ruteables

Puedo ser usado como salto para atacar otras redes

Engaña a los logs alterando el origen de los paquetes

Implicancias de Seguridad

desde el punto de vista del sysadmin

Problemas del sysadmin del servidor SSH

~/ssh/sshd_config

AllowTcpForwarding no

El forwarding de puertos puede ser un problema de seguridad para quien lo usa desde el cliente, generando una

falsa sensación de seguridad

Tramos donde la conexión no se encapsula

La opción -g permite una entrada en externa al túnel

Multiusers en un host con puertos forwardeados

Implicancias de Seguridad

desde el punto del usuario

Para esto no se me ocurre solución =(

Firewall personal en nuestros clientes

Seguridad end-to-end: https, pops, ssh, etc

Gracias especiales a:

LUGFI por invitarme a dar esta charla y organizar este bonito congreso.

Machu por hacerme y corregirme los slides, estos y de otras charlas =P

G33kz.com.ar por la corbata (www.g33kz.com.ar)

Los LUGs y grupos a los que pertenezco y pertenecí por enseñarme lo poco que sé

Todos los movimientos de Software Libre por hacer que sea una realidad genial, útil y universal

Gracias por escucharme

¿PREGUNTAS?

http://www.lucianobello.com.ar/openssh

luciano(en)linux(punto)org(punto)ar

Se que fue difícil... =P

Por último.....

2004-06-15T15:17:27