Nuestro servidor de túneles siempre online (2ª parte) ssh-tunnel & wake on wan

Siguiendo con esta serie de entradas hoy retomaremos nuestro recién creado server y lo dotaremos de un par de servicios de tunneling más de los cuales nos podremos servir en un futuro.

También veremos cómo hacer un wake on wan sin necesidad de un wol-relay, aunque si recordáis yo para el server utilice una raspberry (se puede utilizar cualquier máquina) y, aunque el chipset soporta la tecnología wol, no lo tuvieron en cuenta a la hora de diseñarla (RPI no soporta wol).. por lo menos en el modelo de mi placa...

A decir verdad el consumo de Rpi 2,5W no es nada frente a los 125W que puede llegar a consumir cualquier sobremesa.. Por eso seria bueno tener online este tipo de server solo cuando lo utilicemos, además de ahorrar es ecológico :)

WAKE ON LAN/WAN


Wake on Lan/Wan, es una tecnología mediante la cual podemos encender un ordenador de manera remota, simplemente mediante una llamada de software. Puede implementarse tanto en redes locales (LAN), como en redes de área extensa (WAN o Internet). Las utilidades son muy variadas, tanto encender un Servidor Web/FTP, acceder de manera remota a los archivos que guardas en tu equipo, teletrabajo y hasta por pura vagancia.

Requerimientos hardware

1 - Fuente de alimentación ATX 
2 - Tarjeta de red con cable de tres pines. 
3 - Placa base con soporte WOL

Lo primero que tenemos que hacer para llevar a cabo un wake on wan es abrir el puerto  UDP  9. El Magic Packet es un paquete que funciona a nivel de enlace, en la capa 2 del modelo OSI, ya que lo que se envía en el mismo es una dirección MAC. pero el router es un dispositivo de nivel de red (nivel 3), o sea, que se “entiende” con direcciones IP, no con las direcciones MAC. Eso quiere decir que deberemos ser capaces de enrutar este paquete desde Internet hacia el ordenador objetivo.

Podemos hacerlo accediendo al router bien por http o bien por telnet (en mi caso el soft del router no tiene la posibilidad de tocar las tablas nat por http/https, así que no me queda otra que acceder por telnet):
 

Lo que conseguimos es que  todas las tramas UDP que lleguen a la dirección IP pública del router por el puerto 9, serán reenviadas a ese mismo puerto de la dirección IP privada 192.168.1.128.

En el caso de tener varias máquinas que despertar podemos asignarle a cada una un puerto en la nat y según cual queramos despertar mandaremos el magic packet por un puerto u otro.

Pero un nuevo problema. Al estar el equipo apagado, cuando el router trata de reenviar el paquete mágico a la IP del equipo destino, no hay nadie que le conteste diciendo “yo tengo esa IP”, con lo cual, el router no sabe cuál es la dirección MAC. Esto se soluciona con la tabla ARP del router debidamente configurada.


Para hacer el wake on wan lo podemos hacer desde el smartphone (aconsejo wake on lan de mafro pues nos deja configurar el puerto) u otro equipo.

Sea cual sea la aplicación que utilicemos, los datos son siempre los mismos: la MAC del equipo destino, la IP pública de router (o bien nuestro dominio registrado en freedns.afraid.org), como máscara hay que poner 255.255.255.255 (broadcast) y finalmente el puerto por el que queramos establecer el envío.

Ya estaríamos listos para despertar nuestra máquina desde cualquier parte del mundo!

Un momento y la ip pública??

Si fuisteis buenos y seguisteis los pasos del post anterior tendréis asociada la IP-Publica de vuestro router a un subdominio y puedes saber tu ip por ejemplo haciendo ping. Tu subdominio en el caso del ejemplo era hackpy.chikenkiller.com o bien puedes utilizar el subdominio a pelo.

Debemos tener en cuenta los modos de apagado de nuestra máquina.... por ejemplo mi sobremesa despierta de un halt igual que de un suspend o hibernate... pues digamos que este el wol lo hace por hardware...

Sin embargo mi portátil solo despierta si lo suspendo y antes configuro la tarjeta eth0 para ello.

 ethtool -s eth0 wol g

Bueno despues de este apunte sigamos por donde nos quedamos la semana pasada en  Cómo montar nuestro propio servidor de tuneles siempre online (1ª parte).

SSH-TUNNEL


¿Qué es un túnel SSH?
 
Las siglas corresponden a Secure Shell. Sirve para acceder a máquinas remotas, igual que hace telnet, pero de una forma segura ya que la conexión va cifrada. El transporte se hace mediante TCP, por tanto nos garantiza que las órdenes van a llegar a su destino (conectivo, fiable, orientado a conexión).

¿Para qué nos puede servir?

  1. El túnel SSH es una buena solución para navegar por Internet en el caso que nos hallemos en Red local No segura.
  2. La navegación a través de un túnel SSH garantiza nuestra confidencialidad ya que nadie podrá conocer las páginas web que estamos visitando ni que estamos haciendo.
  3. La navegación a través de un túnel SSH garantiza la integridad de los datos transmitidos y recibidos ya que la probabilidad que alguien pueda modificar las datos que enviamos o recibimos es muy baja.
  4. Los túneles SSH nos pueden servir también para vulnerar ciertas restricciones impuestas por nuestro ISP o por ejemplo también nos puede servir para vulnerar ciertas restricciones impuestas por proxies y firewall.
  5. Los túneles SSH son una buena solución para asegurar la comunicación entre 2 máquinas y para fortificar protocolos débiles como por ejemplo HTTP, SMTP. FTP, Telnet, etc.
  6. Montarse un servidor SSH propio es sumamente mucho más sencillo que montarse un servidor VPN o un servidor proxy.
Empecemos...

Desde nuestra raspberry pi nos bajamos open ssh:

apt-get install openssh-server openssh-client
lo siguiente será cambiar el puerto por el que ssh escuchará, para ello editaremos el fichero /etc/ssh/sshd_config y lo pondremos en el 22222:
 
Ahora en el router abriremos el puerto en la nat:


Ahora abrimos el firewall de nuestro server (en caso de tenerlo activado )

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

Ya estamos en disposición de recibir en nuestro server las conexiones ssh por el puerto 22222.

Tunelizado la conexion 

ssh -p 22222 -N -D 1027 hackpy.chikenkiller.com


-p 22222: Con este parámetro indicamos el puerto de escucha de nuestros servidores SSH.

-D 1027: Estamos especificando que se realice un reenvío dinámico de puertos o túnel dinámico. En este puerto habrá un servidor proxy socks que escuchará las conexiones del puerto 1027. Cuando el servidor proxy socks detecte una solicitud o conexión en el puerto 1027 enviará el tráfico cifrado a través del tunel SSH que creamos entre la red que estemos y nuestro server.

Configurando el proxy para poder navegar

Una vez establecido el túnel deberemos configurar las aplicaciones que van a funcionar por el, en este caso lo que pretendemos es securizar nuestra navegación.

Para ello y yo como estoy utilizando iceweasel para navegar me bajaré e instalaré foxyproxy (lo tenemos para varios navegadores y si no cualquier proxy web vale) y lo configuraremos  para este menester.



en la siguiente captura podemos ver como navegamos por ssh:

Si comprobamos las ip veremos que no son las mismas...

Sin tunnel:








 


Con tunnel:
















Ya hemos conseguido nuestro SSH-TUNNEL... mediante el cual podremos navegar.


UTILIZANDO UN CLIENTE ANDROID 


Para utilizarlo con nuestro smartphone (sin rootear) podemos utilizar la aplicación connetBoot y Firefox. Si tenemos root en el terminal tenemos mejores opciones como la app ssh-tunnel, pero hagámoslo difícil.

abrimos coonectboot y conectamos con nuestro server:

root@NuestraIpPublica:22222 

Luego tocamos la tecla menú y seleccionamos la opción traducciones de puerto:

Lo configuramos como en la foto de la izquierda, aseguraros de reescribir el puerto por el 8080 hasta que se queda en negro....

Ahora tan solo debemos configurar firefox en nuestro smartphone para que tire de nuestro SSH-TUNNEL.

Lo haremos abriendo nuestro navegador y poniendo "about: config" y cambiando los valores por defecto por los siguientes:



  network.proxy.type 1

Y YA estamos en disposición de navegar seguros!

Hasta aquí tenemos nuestro server dispuesto para aplicar dos técnicas de tunneling (DNS Y SSH) desde cualquier parte del mundo y también somos capaces de apagarlo y encenderlo a placer para ser mas ecológicos.. os emplazo a una tercera entrega donde iremos completando nuestro server.

Por hoy tan solo recordaros que podemos "tunnelar" muchos servicios por ssh, desde el correo a servicios RPD.. y que este hilo es solo una de las mil formas de hacerlo.

un saludo!
manuel
sed buenos

5 comentarios :

  1. Buena segunda parte ;)

    Por ser quisquilloso, haz olvidado que el tráfico DNS por lo general tal y como lo has explicado no suele enviarse a través del túnel (por desgracia) por los navegadores por defecto (por ej. no pasa en Chrome), y hay que tocar configuraciones avanzadas.

    ResponderEliminar
  2. Buen artículo! :)

    Para mañana podéis ver como parchear el shellshock con radare, nuestro amigo pancake acaba de publicar el artículo :)

    http://radare.today/shellshock-r2-fix/

    Mcallister.

    ResponderEliminar
    Respuestas
    1. apt-get install radare2
      r2 -qnwc '/ () {\x00;wx 00@@ *' /bin/bash
      aunque yo antes copiaria bash y probaria....
      De todas formas muchas distribuciones estan parcheadas solo se debe actualizar (es mi caso)

      Eliminar
  3. ¿Sigue la serie?
    Si no la tienes cerrada, estaría genial hablar de algún protocolo que soporte nativamente iPhone (o incluso Android), como:
    http://support.apple.com/kb/HT1288

    ResponderEliminar
    Respuestas
    1. Vais rapido!! , esta programado para el final de esta serie de entradas....montaremos un servidor vpn ...estaria muy chulo que autentificara mediante radius (alomejor solo para configurarlo necesitaria un par de entradas y para el usuario medio sera un tanto engorroso).o para simplificar autentificara por chap......segura mente contemple ver un par de protocolos lo que es seguro es que PPTP sera uno de ellos...

      Eliminar