Los túneles son conexiones cifradas (ya sea mediante SSL o TLS) que permiten enviar datos de un punto a otro de Internet (o de una red en general) sin que pueda ser vista dicha comunicación. La encriptación se realiza mediante un certificado con parte pública y parte privada, por lo que se asegura que la recepción del mensaje solo puede ser vista por alguien que disponga la clave privada pareja de la clave pública que se empleó para cifrar el mensaje.

Claves

El sistema de SSH emplea para su comunicación las claves privadas/públicas, enviando la clave pública al cliente para que encripte con ella y desencriptando con la privada cada mensaje recibido.

Cuando realizamos una conexión SSH, si activamos el verbose, podremos ver información como esta:

$ ssh -v rivendel
OpenSSH_5.2p1, OpenSSL 0.9.7l 28 Sep 2006
[...]
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'rivendel' is known and matches the RSA host key.
[...]
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

En este punto se ve que el sistema recibe del servidor la clave pública y la compara con el fichero known_hosts para saber si es el mismo al que se ha conectado en otras veces. Como es así, el cliente genera una clave al vuelo y la envía para establecer la comunicación.

Con este proceso de negociación de claves, se establece la conexión y se puede continuar para solicitar el certificado de acceso o la clave de acceso.

Certificado de acceso

Lo más fácil es trabajar con una clave, ya que no habría que hacer nada, pero usar certificados es lo más simple de cara a seguridad, ya que echar o restringir el acceso a un usuario es simplemente eliminar su certificado de acceso. Con OpenSSH es tan simple generar un certificado de acceso como hacer esto:

$ ssh-keygen -t rsa
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): 
Enter same passphrase again:

Si tan solo presionamos el retorno de carro en las tres ocasiones, se generará un certificado sin protección de contraseña en dos ficheros, en este caso: id_rsa, la clave privada; y id_rsa.pub, la clave pública.

Podemos agregar el fichero de la clave pública al fichero de claves autorizadas de la cuenta a la que queramos acceder en el servidor por el que accedemos, y listo, ya podríamos entrar por certificado en lugar de clave.

Hay que tener en cuenta que, si por algún motivo decidimos poner clave al certificado generado, cada vez que se quiera usar el certificado se pedirá usuario y clave, pero esta no será a nivel de servidor, sino que será el cliente el que requiera la clave para poder desbloquear el certificado y usarlo contra el servidor.

Acceder a un puerto del servidor desde el cliente

Vamos a empezar por algo simple. Imagina que tenemos un puerto de escucha local en el servidor, por lo que, no podemos acceder a menos que estemos en el propio servidor. Si queremos tener ese puerto disponible en nuestro equipo de trabajo, habría que permitir una conexión en remoto. Pongamos que el puerto es el 8080 en el servidor:

$ ssh -f -N -L 8080:localhost:8080 user@server

Si vemos los puertos de escucha en nuestro ordenador, veremos que ssh ha abierto el puerto 8080 y si se trata de un servicio web y abrimos un navegador con http://localhost:8080 podremos ver el contenido que nos muestra el servidor.

Esto es útil cuando en el servidor se activan interfaces de gestión que solo pone a disposición de forma local, por seguridad, pero que se requiere desde el cliente tener acceso a las mismas. Además de proporcionar seguridad de acceso (que bien podría hacer un cortafuegos… aunque no de forma tan dinámica) también nos da una capa de seguridad en la transmisión, ya que se transmite a través del canal seguro de OpenSSH.

Acceder a otro servidor desde el servidor

Al igual que se puede acceder a otro puerto, también se puede acceder a otro equipo al que tan solo se tenga acceso desde el servidor donde se ha realizado el SSH. Por ejemplo, imaginemos que tenemos dos servidores, el servidor web, al que tenemos acceso por SSH y otro servidor de base de datos, que está en una red privada de servidores (la DMZ), pero que no tenemos acceso directo a él y queremos hacer una consulta con nuestra interfaz de gestión de MySQL. Esto se haría:

$ ssh -f -N -L 3306:serverdb:3306 user@webserver

Con esto, al igual que el caso anterior, damos visibilidad al puerto 3306 del servidor de base de datos a través del servidor web en el cliente, el ordenador desde el que lo hemos ejecutado.

Acceso al cliente desde el servidor

También podríamos querer, en un momento dado, tener acceso a nuestro equipo. Por ejemplo, el propio servidor de SSH, para, desde otro sitio, poder acceder a nuestro ordenador de casa. Esto sería:

$ ssh -f -N -R 2222:localhost:22 user@server

En este caso hemos tenido que cambiar el puerto de escucha, ya que el puerto 22 se supone ocupado por el servidor SSH, por lo que lo cambiamos al 2222. Si accedemos al servidor y escribimos:

$ ssh -p 2222 user@localhost

El sistema usará el puente para acceder al cliente y conectar con su puerto 22, por lo que preguntará por la clave (o enviará el certificado si está configurado de forma adecuada) y establecerá una conexión segura (y doblemente segura) con el cliente. Útil para accesos remotos a otros equipos, como mantenimiento en remoto y similares.

Conclusiones

Espero que haya resultado de ayuda y sea de utilidad, ya que con lo presente que se ha hecho Internet en los últimos años, son casi generales para la mayoría de los informáticos estos escenarios o similares.

Estos elementos de conexión usan unos puertos específicos para la conexión, pero el primero no es nada seguro (todo se transmite en plano, tal y como se ve en pantalla, a través de la red) y el segundo requiere de la apertura de un puerto, que en muchas redes está filtrado o es inaccesible.

Para esto, Markus Gutschke, ha creado un sistema que se aprovecha de las nuevas ventajas de la web (HTTP, HTML y Javascript puro y duro) para realizar una conexión vía HTTP con el servidor y poder abrir una sesión de consola. El proyecto se llama Shell In A Box.

La principal ventaja es que se puede lanzar tal cual, en un puerto como el 8080, y ya está. Funcionando. Pero lo mejor es usar Apache para configurarlo de modo que se quede detrás, y a través de una conexión SSL, para que no sea interceptable lo que se va escribiendo, ya que sino, sería tan inseguro como usar telnet directamente.

El propio código tiene un fichero INSTALL en el que se detalla la instalación y configuración, ya sea cual sea la forma en la que se desee.

Una curiosidad, es que, además de disponer del modo LOGIN, que es el que tiene más utilidad, ya que se puede disponer de una consola al equipo servidor a través de conexión HTTP, pero también se puede obtener un SSH a otra máquina (o la propia) y la ejecución de un comando específico:

shellinabox --service=/:USER:/:top

Esto, por ejemplo, abriría una interfaz para visualizar el top de la máquina.

Es una muy buena herramienta que puede facilitar mucho la gestión de servicios (sobre todo de cara al acceso).

El caso es que la empresa y la comunidad que soportan ambas distribuciones (incluso distros comos OpenSuSE o SuSE, Mandriva y otras similares) les pasa que desarrollan versiones de forma bastante rápida (una o dos al año), con lo que, pasando 5 años, pueden haber salido unas 10 versiones posteriores del producto.

Esto genera problemas, sobre todo para la comunidad y la empresa que las mantiene, que deben de ir cerrando soporte de las antiguas, porque sino sería un caos el mantenimiento de 10 distros con versiones distintas de los códigos que se incluyen. A día de hoy, RedHat no suele mantener nada más que dos versiones, al última y su anterior, y Fedora Core, como mucho, da soporte a las 3 ó 4 últimas, con lo que, yendo actualmente por la versión 12, es lógico que el soporte a la versión 2 y 3 ha expirado hace bastante tiempo.

¿Qué pasa si hemos instalado un servidor web con estas distribuciones y queremos mantenerlo para nuestro correo, página web y otros menesteres?, pues que sino actualizamos, llegará el momento en el que haya vulnerabilidades en el código de nuestro servidor de correo, nuestro servidor web, o que queramos simplemente actualizar la versión del CMS que estamos usando y necesite una versión superior de Python, PHP o Ruby, o no tengamos forma de instalarla, a menos que vayamos tirando de compilación.

En Debian también pasa algo parecido. El ritmo de liberación de las distribuciones es más lento, con lo que da un tiempo mayor de permanencia de una distribución a su siguiente liberación. Pero el cambio es mucho mayor en este sentido, puesto que las versiones, cuando se cambian, son saltos bastante grandes y requiere de un mayor esfuerzo de adaptación.

¿Qué hacer?, básicamente, ir actualizando y mantenerse al tanto de cuando sale la siguiente liberación de la distribución que estamos usando y, sobretodo, planificar tiempos cada 5 ó 6 meses, para actualizar las distribuciones a sus versiones superiores, ya que así estaremos más protegidos de posibles vulnerabilidades.

Tener presente que si el cambio no se realiza, puntualmente, antes de que el soporte oficial a la distro que tenemos instalada expire, nos veremos en la situación de tener un sistema con agujeros de seguridad, que es propenso a fallos y sobre el que, cada día que pase, será más complicado instalar software nuevo.

Normalmente, estos scripts se realizan buscando las peticiones más lentas de los sistemas web. Una vez detectadas, se procede a lanzar muchas de estas peticiones en muy poco tiempo. Los servidores web, ante una avalancha de peticiones, normalmente, comienzan a crear forks o workers (según el servidor y modo de funcionamiento) hasta llegar al límite máximo configurado… o a que se sature el sistema y termine no respondiendo.

Los sistemas GNU/Linux, al igual que la mayoría, tienen un uso de memoria limitada por el tamaño de la misma que haya instalada. Estos sistemas manejan una caché bastante grande y por ello, aunque se tenga 1GB o más instalado en el sistema, siempre se anda con una ocupación bastante alta de la memoria del sistema. Cuando esta se agota, se recurre a la memoria de intercambio (swap), que es mucho más lenta que la memoria convencional, por lo que el sistema comienza a ralentizarse.

Para evitar estos problemas, lo ideal es configurar de forma adecuada el servidor web, acorde a la memoria disponible, el número máximo de hilos que se puedan crear y el número máximo de forks o workers que se puedan lanzar para atender peticiones. Con esto evitamos que la memoria se use en exceso y, aunque las peticiones se atiendan más lentas, se asegure que el sistema permanecerá estable.

También habría que revisar la pila de entrada TCP para el puerto 80 (se puede ver a través de netstat en cualquier sistema GNU/Linux), por si acaso se saturase mucho, comenzar a cortar, vía cortafuegos (iptables), las direcciones IP que estén haciendo flood.

• han entrado en tu servidor y han comenzado a enviar un montón de emails desde tu cuenta de usuario, o
• alguien ha comenzado a enviar un montón de emails a servidores mal configurados, con tu dirección de email como remitente, para hacerte llegar todos esos mensajes.

Visto por cualquiera de las formas pinta mal, pero a la que nos referimos cuando hablamos de spam por relay es la segunda. Tu sistema está bien configurado, nadie ha entrado y no has enviado ningún email, pero sin embargo comienzan a llegar emails de MAILER-DAEMON o similares, diciendo que no han podido entregar tu email (y te lo ponen completo) porque no se encuentra el usuario, porque está mal formado, o por cualquier otro error intencionado que ha introducido el spammer.

El problema se da, y lo sé porque lo he vivido, cuando abres la bandeja de entrada y ves nada más y nada menos que de 30 a 60 mensajes diarios con el mismo asunto. Después, leyendo las cabeceras del email (esas que no se ven a simple vista, ni desde MUAs como Outlook), se puede ver, en la lista de los Received, el último que aparece (que es el primero que se escribió):

Received: (from nj.ua@localhost)
	by nj.ua (8.13.8/8.13.8/Submit) id a862dvhn858019;
	Thu, 21 Jan 2010 09:36:45 +0800

Ha sido enviado por alguien que no se conoce, la siguiente línea es la del que recibe el email, directamente, por lo que no ha pasado, siquiera, por nuestro servidor. Estamos seguros… pero eso no nos quita el problema… y realmente, y lamentablemente, no hay una solución real a este problema, ya que al intentar comunicar a cada uno de los sitios la configuración que deben de poner para que esto no pase (validación de SPF, uso de EHLO o HELO,…) o no saben cómo hacerlo y pasan, o pasan directamente.

Por lo que, el spam ha conseguido otra vía de acceso a través de los sistemas de email más pobremente configurados (y hay muchos así) de Internet. ¿Habrá forma de pararlos?

En lo que llevamos de año, se han sucedido grandes vulnerabilidades de seguridad. La primera ha afectado la protocolo DNS, la segunda al protocolo BGP y ha habido otra vulnerabilidad sobre SSL que ha afectado solo a las distribuciones Debian y derivadas del mismo.

Esta última vulnerabilidad afecta al TCP/IP, aunque matizan los expertos que, de momento, solo es supuesta y que no solo afecta a IP, sino al conjunto TCP/IP. De momento, hasta que sea publicada la vulnerabilidad de forma específica por la compañía sueca, estamos ante, incluso, un posible FUD.

De todas formas, Internet, la concepción de sus protocolos más usados (como DNS y SMTP), no estaban pensandos para ser seguros, sino prácticos, puesto que Internet era una red a la que pocos tenían acceso. Hoy en día, el enfoque ha cambiado, pero los protocolos siguen siendo los mismos y, quizás, el problema haya sido la forma de parcheo que se ha realizado sobre los protocolos existentes, en lugar de optar por desarrollar mejores protocolos orientados a las necesidades actuales.

¿Estamos ante una necesidad de cambio en los protocolos de Internet?, ¿se nos hunde Internet?, no lo creo… pero llegan momentos difíciles y quizás vientos de cambio

Estas preguntas surgen siempre por desconocimiento y, realmente es bueno que nos las hagamos, ya que hay también mucha gente que dice saber y, cuando dicen eso de: “en mi equipo es imposible que entren”; es donde están realmente equivocados.

Nuestros equipos informáticos, en la amplia mayoría, están conectados a Internet. Reciben una cantidad de información muy grande a diario, y envian también mucha información a la red de redes.

Cuando se configura un ordenador, normalmente, se hace conectado a un router. Este tipo de conexión, a priori, hace que sea imposible que un atacante pueda acceder directamente al equipo que está detrás del router. Pero en sí, el router también podría contener algún tipo de vulnerabilidad, con la que pudiera ser saltado, por lo que no nos da una seguridad total.

Por otra parte, no es necesario que entren por ahí, desde tiempos inmemoriales, las mejores tácticas para atacar a alguien, sin que este se diese cuenta y usando el factor sorpresa, han sido con engaños. Los programas que parecen inofensivos y se instalan en nuestro sistema, pueden actuar como el famoso caballo de Troya (y a cuyo nombre deben el suyo propio: troyanos).

Este tipo de malware se encarga de tomar información propia y, normalmente, de convertir nuestro sistema en un zombie.

¿Es nuestro equipo realmente seguro? Depende del uso que le demos, depende de que no se reproduzca contenido recibido de fuentes no seguras y, de que nuestros equipos, si usan Windows, tengan el software preciso y necesario para evitar males mayores.

¿Un sistema GNU/Linux es más seguro? Normalmente sí, pero no es totalmente seguro, debe de mantenerse el mismo cuidado, no visualizar contenido del que se desconozca su origen, y deshabilitar los permisos de tipo ejecución en todos los ficheros “sospechosos”, es una buena práctica.