Proxy socks vía tunel SSH para navegar seguro

categoría: Seguridad informática | tags: , , , , | 3 comentarios »

Hoy en día no es raro que nos conectemos a Internet desde redes no seguras: cafeterías, universidades, etc. Esto puede conllevar que nuestros datos sean interceptados fácilmente por terceras personas. Un espía podría atacarnos desde varios frentes; por un lado, estando en nuestra red local y ejecutando un sniffer apoyado en un ataque man in the middle; y por otro lado podría estar fuera de nuestra red local capturando el tráfico wifi cifrado para a posteriori descifrarlo con la clave adecuada.

Ante estos dos ataques contra la privacidad se puede utilizar un proxy con cifrado para que nuestros datos viajen através de la red local no segura de forma segura. Una de las formas más rápidas de conseguir esto es utilizando conexiones SSH. Tan sólo deberemos tener un cuenta SSH en un servidor de confianza y lanzar la conexión de la siguiente manera:

ssh -N -C -D 9999 NOMBRE_USUARIO@IP_SERVIDODR_SSH -p PUERTO

donde:

-N no iniciar sesión de shell

-C habilitar compresión

-D puerto local para crear el tunel

-p puerto remoto del servidor ssh (si no se indica este modificador asume el 22)

Después de realizar la conexión la dejaremos abierta mientras estemos usando el proxy. Sólo faltaría configurar en nuestro navegador web el proxy SOCKS como “localhost” por el puerto 9999.


Distinguir una sesión local de una remota en Linux

categoría: Linux | tags: , , , | 4 comentarios »

Me he encontrado con la necesidad de programar un pequeño script en bash para el servidor Linux de un cliente. Dicho script estaba funcionando correctemente en la máquina local pero no así cuando se realizaba una conexión remota.

Ante esto era preciso encontrar alguna manera de discernir entre las conexiones locales y remontas para realizar configuraciones diferentes para cada una.

La solución, sencilla y un tanto ingeniosa, pasó por utilizar variables de entorno para hacer la distinción entre conexión local y remota:

if [[ -z "$REMOTEHOST" &&  -z  "$SSH_CLIENT"  ]]; then
echo "Cliente conectado en local";
else
echo "Cliente conectado en remoto";
fi

Se comprueba que no existan las variables de entorno $REMOTEHOST ni $SSH_CLIENT, la primera está presente en conexiones telnet y la segunda en conexiones SSH. Si no existe ninguna de ellas la conexión es local, si existe alguna de ellas la conexión es remota.