Y la de cualquier red... en la que tengas un equipo de tu mano. Dicho así parece algo grande, pero realmente no es muy complejo y por supuesto ya está inventado sin más que recoger algunas herramientas que todos tenemos a nuestro alcance.

Tengamos en cuenta que en las redes de organizaciones en las que trabajamos, normalmente firmamos un compromiso de fidelidad con la organización en lo que atañe a la no publicación o exposición de la misma al exterior. Y si no trabajamos en esa red, directamente somos delincuentes. Este artículo no pretende incitar a violar la ley o a perder el trabajo por gañán y lo que cada cuál haga a partir de esta información es su responsabilidad, no mía. Avisados estáis.

Lo único que pretendo con este artículo es intentar explicar los conceptos en los que se apoya esta técnica. Son interesantes para comprender los parámetros de seguridad que podemos monitorizar cuando accedemos a sitios remotos.

Toda la información que publico está editada por mi, por supuesto es fácil encontrar soporte relacionado en internet, si sabes lo que quieres buscar y buscas en inglés claro.

Veamos los aspectos que quiero tratar, voy a intentar no enrollarme e ir al grano:

  • SSH, ese maravilloso comando que vale para todo.
  • Securizar nuestras conexiones (evitar "man in the middle attack").
  • Redirección local (-L). Acceder a servicios remotos tras NAT, sin abrir más puertos.
  • Redirección dinámica (-D). Crear un proxy socks hacia destino. 
  • Redirección de puerto inversa (-R). Dejar la puerta de detrás abierta.
  • La posibilidad de acceso sin meter clave. Automatizar el ataque (ahora sí, jeje)
  • La genialidad de autossh. El cómplice que mantiene abierto el camino.
  • Unimos el puzle.

 

SSH, ese maravilloso comando que vale para todo.

Son las siglas de "Secure Shell", usamos el comando con ese nombre, bajo el que tenemos un protocolo que en principio sirve para iniciar sesión en un servidor remoto, con ciertas garantías de que la información transferida es encriptada de un extremo al otro. En definitiva, es mejor no utilizar "telnet" usemos "ssh". 

Inicialmente esa era la idea, luego alguien se dio cuenta que de la que abres una conexión por el puerto 22, ¿porqué no permitir mediante opciones abrir e interconectar más puertos en origen y en destino, utilizando como tubería de datos el canal seguro abierto por el 22? Ya que tenemos un flujo seguro, usémosle para todo lo que podamos. O incluso permitir que paquetes enviados a través de esa tubería segura, sean enrutados en destino o alrevés. Y si unimos varios nodos haciendo lo mismo, ya tenemos una red de redireccionamientos anidados, algo también interesante, puede que más lento en velocidad de conexión, pero realmente complicado de trazar desde el exterior. 

Como vemos, hay muchas posibilidades a explorar con lo que en principio es un inocente acceso de sesión a un terminal de texto. 

 

Securizar nuestras conexiones (evitar "man in the middle attack")

Voy a dar dos recomendaciones para tener más garantías de que nuestras conexiones son eso, nuestras. La primera es crítico respetarla. La segunda es una segunda etapa de seguridad.

Al conectar se nos enseña antes de pedirnos introducir la clave, una huella pública del servidor, que es única y muy difícil de suplantar. Esta huella fue generada en un proceso en el que también se obtuvo su pareja privada y no es computacionalmente fácil reproducir esa generación. Es imprescindible, crítico, que en esa verificación de la huella, estemos seguros que coincide con la que el servidor. ¿Cómo lo hacemos? Pues necesariamente habiendo tenido una conexión local al servidor previa a esa conexión remota (local porque así tenemos garantías de que no hay posible contaminación con el hostil medio "Internet", local significa sentado delante de la máquina), en la que hayamos visto de primera mano la huella pública. Las huellas residen en /etc/ssh y el comando para verlas es:

ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub

El último fichero referido puede variar, según el protocolo que se utilice para negociar la encriptación de la clave. Este comando emite un chorizo de números hexadecimales que debe coincidir con el escupido por el comienzo de la conexión cuando la hacemos en remoto. 

La segunda recomendación tiene que ver con el uso de verificación en 2 pasos. Para ello probablemente lo más sencillo es usar TOTP desde LATCH

 

Redirección local (-L). Acceder a servicios remotos tras NAT, sin abrir más puertos.