Esta bonita historia no debe hacernos olvidar que OpenSSH (SSH en lo sucesivo, para acortar) es una herramienta indispensable en la administración de sistemas. La mayoría de los protocolos que empleamos en nuestras comunicaciones están basados en diseños de hace casi 30 años, cuando la seguridad en redes telemáticas no era un problema. Telnet, FTP, POP3, protocolos de uso cotidiano, descuidan la seguridad y confidencialidad de los datos que envían. De nada sirve proteger nuestros servidores, implantar una buena política de contraseñas y actualizar las versiones de nuestros demonios, si luego cuando un usuario de POP3, por ejemplo, quiere ver su correo electrónico desde la universidad, envía su usuario y contraseña en texto plano por la red. Para evitar esto tenemos dos alternativas: bien elegir protocolos que sean seguros, bien hacer seguros los protocolos inseguros. De las dos opciones, la segunda permite reutilizar muchos más clientes y servidores ya programados, ayuda a enmascarar la complejidad de la seguridad en la transmisión y es una solución siempre escalable. Por todo esto, vamos a ver cómo convertir nuestros protocolos tradicionales en protocolos seguros, y qué tiene que ver SSH en todo ello.
La idea en la que se basa este procedimiento es la de hacer un túnel por el cual viajarán los datos de manera segura (“tunneling”). El símil con la vida real está bastante bien escogido: imaginemos que la tasa de mortalidad de los diferentes medios de transporte fuese equivalente a la posibilidad de que la seguridad de nuestros datos sea violada, y que el tren representase un canal seguro y el automóvil un canal inseguro. El túnel del Canal de la Mancha sería el ejemplo perfecto para ilustrar el concepto de “tunneling”: cuando queremos viajar a través de él con nuestro coche, tenemos que subirnos a un vagón para coches y luego cruzar el túnel en tren. Hemos incrementado sensiblemente la seguridad del viaje, porque la probabilidad de un accidente de tren es muchísimo menor que la de un accidente de coche. Este mismo proceso es el que se da a la hora de establecer un túnel seguro en la comunicación entre cliente y servidor. En cada uno de los extremos del túnel están las aplicaciones estándar (un demonio POP3 estándar, nuestro cliente de correo favorito…) y la comunicación se asegura haciendo uso de toda la potencia criptográfica de SSH. Para ello tenemos que realizar un procedimiento similar al que supondría subir nuestro coche al tren, establecer mediante SSH un reenvío de los datos gracias a una técnica denominada “port-forwarding”. SSH recoge los datos que el cliente quiere enviar y los reenvía por el túnel o canal seguro, al otro lado del túnel se recogen los datos y se reenvían al servidor conveniente:
Veamos cómo llevar esto a cabo. La clave está en usar la opción “-L” de SSH, que se encarga de todo el proceso de “port-forwarding”. El siguiente ejemplo muestra cómo utilizar el puerto 10110 de nuestra máquina para establecer una comunicación segura con el puerto 110 del servidor popmail.correo.net:
Esto es un punto importante: si queremos utilizar puertos privilegiados por debajo de 1024 (“well-known ports”), deberemos tener privilegios de root (por lo menos en un sistema con una configuración normal, alejado del “enfoque” de seguridad de Windows98 o similares). Si no disponemos de privilegios, tendremos que optar por la alternativa de utilizar un puerto superior a 1024, como en el ejemplo. Una manera fácil de no enquilombarce con esto, es sumar 10000 al número de puerto estándar, así el 110 sería el 10110 en nuestra máquina, el 10080 el 80, o el 16667 el 6667, etc, etc.
SSH da mucho más juego, éstas son algunas de las opciones que podremos incluir en nuestras configuraciones y scripts:
-1 ó -2 : fuerza a utilizar la versión 1 o la versión 2 de SSH.
-f : pasa a segundo plano la ejecución de ssh (fork). Esta opción implica además la opción
-n, en la que se impide leer de la entrada estándar.
-N : impide ejecutar comandos remotos. Muy útil cuando lo único que se desea es “port-forwarding”.
-P : permite usar un puerto no privilegiado (>1024) para conexiones salientes. Muy usado cuando estamos tras un router o firewall que no permite conexiones a puertos privilegiados.
Para más información acerca de estas y otras opciones, “man ssh”
- Compatibilidad en cuanto a versiones de SSH. Bastantes clientes de SSH solamente soportan la versión 1, sin embargo esta versión es vulnerable a diversos ataques, por lo que es aconsejable utilizar la versión 2 convenientemente parcheada (openSSH-3.x.x con los parches para corregir el bug “hang-on-exit” o el “exit-delay”). Aquí se plantea la típica disyuntiva entre seguridad o compatibilidad.
- Para establecer una sesión SSH es necesario autenticación. Si utilizamos autenticación por passphrase (además de las correspondientes claves RSA o métodos similares), deberemos prever este hecho en nuestros scripts o nuestras sesiones interactivas o de lo contrario no podremos establecer el túnel SSH.
- Las reglas de protección en ipchains o iptables. Si tenemos configuradas reglas para bloquear las conexiones entrantes, necesitaremos establecer una excepción a esas reglas para que funcione el “port-forwarding” en local, con algo parecido a esto:
- Si vamos a utilizar puertos privilegiados en nuestra máquina local (con privilegios de root), deberemos tener en cuenta que esos puertos no se hayan empleado para conexiones entrantes. Si, por ejemplo, queremos hacer “port-forwarding” del puerto 110 para que nuestros usuarios puedan acceder de manera segura a su servidor de correo, deberemos tener cuidado ante un posible servidor POP3 escuchando el puerto 110 en nuestra máquina. Revisad vuestras configuraciones de los demonios que están escuchando puertos y en especial el fichero “/etc/inetd.conf”.
- Si queremos establecer un túnel para cada conexión y destruirlo cuando ésta acabe, podemos usar una nueva opción incluida en el último parche (-S) para fijar un tiempo de espera o “delay” en el que se atenderán las conexiones SSH. Cuando ese tiempo expire, no se atenderán más conexiones y el comando finalizará cuando todas la conexiones hayan concluido (esto es importante, no termina cuando se consuma el tiempo fijado). Si disponemos de una versión antigua de SSH, podemos hacer esto mismo de la siguiente manera:
Así estamos fijando un temporizador de 30 segundos para aceptar conexiones, finalizado el cual se esperará únicamente a que las conexiones ya establecidas terminen.
La idea en la que se basa este procedimiento es la de hacer un túnel por el cual viajarán los datos de manera segura (“tunneling”). El símil con la vida real está bastante bien escogido: imaginemos que la tasa de mortalidad de los diferentes medios de transporte fuese equivalente a la posibilidad de que la seguridad de nuestros datos sea violada, y que el tren representase un canal seguro y el automóvil un canal inseguro. El túnel del Canal de la Mancha sería el ejemplo perfecto para ilustrar el concepto de “tunneling”: cuando queremos viajar a través de él con nuestro coche, tenemos que subirnos a un vagón para coches y luego cruzar el túnel en tren. Hemos incrementado sensiblemente la seguridad del viaje, porque la probabilidad de un accidente de tren es muchísimo menor que la de un accidente de coche. Este mismo proceso es el que se da a la hora de establecer un túnel seguro en la comunicación entre cliente y servidor. En cada uno de los extremos del túnel están las aplicaciones estándar (un demonio POP3 estándar, nuestro cliente de correo favorito…) y la comunicación se asegura haciendo uso de toda la potencia criptográfica de SSH. Para ello tenemos que realizar un procedimiento similar al que supondría subir nuestro coche al tren, establecer mediante SSH un reenvío de los datos gracias a una técnica denominada “port-forwarding”. SSH recoge los datos que el cliente quiere enviar y los reenvía por el túnel o canal seguro, al otro lado del túnel se recogen los datos y se reenvían al servidor conveniente:
De la teoría a la práctica
Veamos cómo llevar esto a cabo. La clave está en usar la opción “-L” de SSH, que se encarga de todo el proceso de “port-forwarding”. El siguiente ejemplo muestra cómo utilizar el puerto 10110 de nuestra máquina para establecer una comunicación segura con el puerto 110 del servidor popmail.correo.net:
ssh -P -L 10110:popmail.correo.net:110
Esto es un punto importante: si queremos utilizar puertos privilegiados por debajo de 1024 (“well-known ports”), deberemos tener privilegios de root (por lo menos en un sistema con una configuración normal, alejado del “enfoque” de seguridad de Windows98 o similares). Si no disponemos de privilegios, tendremos que optar por la alternativa de utilizar un puerto superior a 1024, como en el ejemplo. Una manera fácil de no enquilombarce con esto, es sumar 10000 al número de puerto estándar, así el 110 sería el 10110 en nuestra máquina, el 10080 el 80, o el 16667 el 6667, etc, etc.
SSH da mucho más juego, éstas son algunas de las opciones que podremos incluir en nuestras configuraciones y scripts:
-1 ó -2 : fuerza a utilizar la versión 1 o la versión 2 de SSH.
-f : pasa a segundo plano la ejecución de ssh (fork). Esta opción implica además la opción
-n, en la que se impide leer de la entrada estándar.
-N : impide ejecutar comandos remotos. Muy útil cuando lo único que se desea es “port-forwarding”.
-P : permite usar un puerto no privilegiado (>1024) para conexiones salientes. Muy usado cuando estamos tras un router o firewall que no permite conexiones a puertos privilegiados.
Para más información acerca de estas y otras opciones, “man ssh”
Otros aspectos que
deberemos tener en cuenta
deberemos tener en cuenta
- Compatibilidad en cuanto a versiones de SSH. Bastantes clientes de SSH solamente soportan la versión 1, sin embargo esta versión es vulnerable a diversos ataques, por lo que es aconsejable utilizar la versión 2 convenientemente parcheada (openSSH-3.x.x con los parches para corregir el bug “hang-on-exit” o el “exit-delay”). Aquí se plantea la típica disyuntiva entre seguridad o compatibilidad.
- Para establecer una sesión SSH es necesario autenticación. Si utilizamos autenticación por passphrase (además de las correspondientes claves RSA o métodos similares), deberemos prever este hecho en nuestros scripts o nuestras sesiones interactivas o de lo contrario no podremos establecer el túnel SSH.
- Las reglas de protección en ipchains o iptables. Si tenemos configuradas reglas para bloquear las conexiones entrantes, necesitaremos establecer una excepción a esas reglas para que funcione el “port-forwarding” en local, con algo parecido a esto:
iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -i lo -j ACCEPT
iptables -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -o lo -j ACCEPT
- Si vamos a utilizar puertos privilegiados en nuestra máquina local (con privilegios de root), deberemos tener en cuenta que esos puertos no se hayan empleado para conexiones entrantes. Si, por ejemplo, queremos hacer “port-forwarding” del puerto 110 para que nuestros usuarios puedan acceder de manera segura a su servidor de correo, deberemos tener cuidado ante un posible servidor POP3 escuchando el puerto 110 en nuestra máquina. Revisad vuestras configuraciones de los demonios que están escuchando puertos y en especial el fichero “/etc/inetd.conf”.
- Si queremos establecer un túnel para cada conexión y destruirlo cuando ésta acabe, podemos usar una nueva opción incluida en el último parche (-S) para fijar un tiempo de espera o “delay” en el que se atenderán las conexiones SSH. Cuando ese tiempo expire, no se atenderán más conexiones y el comando finalizará cuando todas la conexiones hayan concluido (esto es importante, no termina cuando se consuma el tiempo fijado). Si disponemos de una versión antigua de SSH, podemos hacer esto mismo de la siguiente manera:
ssh -f -L 110:popmail.correo.net:110 [email protected] sleep 30
esto sería equivalente a:
ssh -f -S 30 -L 110:popmail.correo.net:110 [email protected]
Así estamos fijando un temporizador de 30 segundos para aceptar conexiones, finalizado el cual se esperará únicamente a que las conexiones ya establecidas terminen.