La idea de un túnel inverso, conexión inversa, es la de generación de una conexión que nos permita abrir puertos en el destino como si fuera un puerto local. La utilidad de esto se basa en que en ciertos ambientes donde estamos trabajando no podemos llegar desde el exterior directamente pero si tenemos la posibilidad de realizar una conexión desde el local a un remoto; para esta explicación vamos a utilizar el tan famoso SSH, la utilización es muy parecida a otro post que hice “SSH: Tuneles y más“.
Esta técnica es muy utilizada en pruebas de “laboratorio” cuando se explotan vulnerabilidades o también utilizadas en los servicios de C&C ( command and control ) de los spyware/malware. Una vez que la victima es infectada o atacada, el software genera una conexión inversa que abre la posibilidad de acceso a una consola.
Supongamos que tenemos una computadora en una red grande, donde dicha computadora esta conectada atrás de una serie de RTs, SWs, FWs, etc. los cuales realizan NAT u otra forma de ofuscación de IP y filtrado de puertos ( lógico ! ) para que una persona externa no pueda acceder directamente a nuestra terminal, pero nosotros por esas casualidades el fin de semana vamos a estar trabajando de casa y no nos podemos llevar la computadora a casa; entonces que opción tenemos ? ( vamos a suponer que son lo suficientemente “buenos” para dejarnos algún puerto abierto para que nos podamos conectar hacia afuera y que no configuraron bien el IPS ).
Entonces lo que podemos realizar es un túnel reverso a nuestra casa ( PC1 a PC2 ), obviamente también existe el tema de usar una VPN aunque es un poco más complejo que poner un comandó, para eso solo vamos a utilizar SSH ( si usan winchot puede utilizar Cywin ); para comenzar realizamos el túnel:
ssh -R 3344:localhost:5900 usuario@micasa.ddns.org
Con esto realizamos el túnel reverso que lo que hace es que en nuestra computadora de casa nos abra un puerto 3344 que esta redireccionado por medio del túnel al puerto 5900 ( TCP VNC ) de nuestra computadora de trabajo, el paso siguiente es llegar a nuestras casas, bajar algún cliente de VNC y conectarse al puerto 5900 de localhost ( 127.0.0.1 -ipv4- o ::: -ipv6- ).
Mi recomendación es que antes de irnos a nuestras “casas” ( jojojo ) realicemos, ya que tenemos el SSH abierto, una verificación para saber que el puerto esta abierto, para eso pueden utilizar:
netstat -lan | grep LIST | grep :3344
Donde tendrían que ver algo parecido a:
Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:3344 0.0.0.0:* LISTEN tcp6 0 0 :::3344 :::* LISTEN
Otro dato más que fundamenta cuando realizamos algo como esto, donde necesitamos que el túnel sea persistente, es utilizar la opción “-o ServerAliveInterval=60”. Dicha opción va a meter trafico por la conexión para que no se nos caiga por algún problema de timeoute ( esto nos fue muy útil con mi colega “Huguito” cuando teníamos un cliente que configuro un timeout muy chico para las conexiones y tuvimos que poner el valor en 10 para que no se nos corten las conexiones ). Tambien podriamos realizar un script que controle el estado de la conexión y en caso de que no lleguemos al otro extremo mate el proceso y levante una nueva conexión ( recomiendo usar certificados para el SSH ya que no es buena tecnica dejar codeado una contraseña en un script ).
Referencias:
* https://stackoverflow.com/questions/25084288/keep-ssh-session-alive
* https://www.howtoforge.com/reverse-ssh-tunneling
Más datos:
SSH ( más bien dicho OpenSSH-Server ) funciona en el puerto 22, eso no quiere decir que no podamos hacer funcionar el servicio en otro puerto, por ejemplo en el 443 ( es el que mejor “aceptación” tiene ), pudiendo también proxyarlo 😉 o utilizar Tor “Tunel SSH con Tor y/o Bypass Proxy“ ( otro post ).
Aclaraciones
Pongo como ejemplo un ambiente laboral y hogareño por la complejidad de la red ( de empresa ) dado que tienen dispositivos suficientes para el control de las conexiones. Tengan en cuenta que en muchos de los casos realizar este tipo de conexiones en un ambiente de empresas puede ir claramente en contra de las políticas de seguridad.
Lo que se explica acá es simplemente en carácter educativo. Respeten las políticas de seguridad, para algo están y podrían poner en riesgo muchas cosas si estas conexiones no se realizan con responsabilidad.
EOP
Sin más, cualquier duda pueden dejarla en los comentarios !