Se me ocurren dos métodos para encriptar nuestras conexiones a
través de redes inalámbricas (al margen de la ineficaz
WEP); bien usando túneles ssh, bien mediante una VPN. La VPN
servirá a su vez para conectarnos a la red del trabajo (o de
casa) desde otro sitio.
Necesitamos acceso a
una máquina con servidor ssh y salida a internet que esté
en un lugar desde el que la conexión sea segura. Se basa en
redireccionar puertos a través de túneles ssh de modo que
el tramo desde nuestro pc hasta el servidor ssh, irá encriptado,
y de ahí saldrá a internet de forma segura.
Si por ejemplo necesitamos encriptar
nuestras conversaciones de chat en irc.debian.org, abriríamos
una sesión ssh con el comando:
ssh
-C -N -L 6667:irc.debian.org:6667 usuario@servidor
Tras esto, debemos
indicarle a nuestro cliente de chat, que el servidor de irc está
en la ip 127.0.0.1, en el puerto 6667. Hecho esto, todo el
tráfico de chat pasará encriptado por el túnel
hasta el extremo donde se halle el servidor ssh.
Esto mismo se puede hacer en windows con un cliente ssh para comandos
(el que viene con cygwin, o plink del paquete putty), o bien con el
programa putty en modo gráfico. En éste hay un
menú "tunnels", y simplemente se basa en especificarle el puerto
local, puerto remoto, e ip remota. En nuestro caso el puerto local
sería 6667, el remoto también, y la ip remota
sería irc.debian.org.
Podemos encadenar argumentos para especificar varios
puertos; de este modo, para encriptar nuestro correo entrante y
saliente de terra, nuestro chat, y nuestro cliente de mensajería
jabber, usaríamos:
ssh
-C -N -L 6667:irc.debian.org:6667 -L 25:mailhost.terra.es:25 -L
110:pop.terra.es:110 -L 5222:jabber.org:5222 usuario@servidor
Cabe citar que para redireccionar puertos
menores al 1024, necesitaremos privilegios de root en la máquina
cliente, y que si ya tenemos servicios escuchando en dichos puertos,
tendremos que usar otros o parar los servicios que ya tengamos; por
ejemplo, si tenemos un servidor de correo en el puerto 25, podemos
redireccionar el puerto 26 (siempre que nuestro cliente de email
permita especificar el puerto del servidor smtp), sería "...
-L 26:mailhost.terra.es:25..."
Podemos redireccionar puertos dinámicamente.
Para ello tenemos que especificar el caracter de escape en
/etc/ssh/ssh_config (en el equipo
servidor ssh). Después de iniciar sesión, pulsamos ~C
(suponiendo ~ como secuencia de escape), y nos saldrá la
línea de comandos de ssh. Redireccionamos como de costumbre:
-L
3128:localhost:3128
El gran problema: MSN MESSENGER. Por lo que estuve
investigando, parece que éste cliente de mensajería se
conecta primero a
messenger.hotmail.com.
Éste servidor te asigna otro servidor (el cual es distinto cada
vez que te conectas), y por si fuera poco, usa otros servidores (hasta
4 distintos en las pruebas que hice), para autentificarse via https.
Soluciones:
- Cambiar de servidor de mensajería y usar Jabber, ya que
jabber solo utiliza el puerto 5222, el cual se redirecciona facilmente
(al margen de que jabber permite encriptación, con lo cual no
haría falta encriptarlo via tunel ssh). Además así
contribuímos a que Hasefro$h no
pueda controlar todas nuestras conversaciones, y a distribuir
más la red, ya que cualquiera puede montarse un servidor jabber
en casa, y unir éste a la red global de jabber.
- Utilizar un servidor jabber que permita pasarela msn, con lo
cual podemos conectarnos a msn messenger a través de un servidor
jabber. Problema: Los nombres de los usuarios no se ven; en su lugar se
ven las direcciones de correo electrónico. (Esto solo ocurre con
los usuarios de messenger; nuestros contactos que usen jabber
aparecerán correctamente, con su apodo)
- Usar un proxy, y redireccionar via ssh el proxy. Problema:
Necesitas un proxy en algún sitio :-P . Y los proxys que he
probado en Debian (squid, oops, privoxy) no permiten usarse para pasar
tráfico TCP a otros puertos que no sean el 80,443 y algún
otro. La solución que encontré para squid
es añadir el puerto 1863 en la línea
acl
SSL_ports port 443 563 1863
o bien quitar la restricción
http_access
deny CONNECT !SSL_ports
- Virtual Private Network, VPN
La solución
aqui es válida para toda conexión que realicemos a
internet, todo el tráfico pasará encriptado a
través de una red privada virtual. Para ello necesitamos un
servidor VPN en algún sitio seguro. La desventaja es que
estaremos limitados por el ancho de banda de ambos extremos de la VPN,
de modo que si tenemos el servidor VPN sobre una ADSL de 256/128, y
estamos por wireless con una conexión de 4 Mb, realmente nos
funcionará a 128 kb/s como mucho, ya que es lo máximo que
puede enviarnos el otro extremo de la VPN. Hay varios servidores VPN;
openvpn, vtun, ipsec, etc. Yo he probado
openvpn y pptp. Con este
método simplemente se crea una red virtual entre nuestro equipo
y el servidor VPN
OpenVPN
Esta parte está basada en la documentación de Javier
González (
mailto:javier AT
javier-gonzalez DOT com), que encontré en
linuca.
Con
openvpn vamos a poder tunelizar y encriptar todas las conexiones de una
sola tirada, e incluso vamos a poder comprimilas, lo que puede aumentar
el rendimiento de una red. (y aumentar también el uso de CPU de
los nodos, claro)
VPN significa Virtual Private Network y como ya he dicho antes sirve
para crear una conexión independiente punto a punto y poderla
cifrarla.
Para instalar openvpn podemos bajarnos los sources y compilarlos de
aquí o podemos buscar en el gestor de paquetes de nuestra
distribucion ... en debian # apt-get install openvpn.
Lo primero que tenemos que hacer es generar la clave que vamos a
utilizar para la VPN, para ello:
#
openvpn --genkey --secret clave.key
Ahora tenemos que copiar esta clave a los nodos que van a formar la
VPN, sería interesante pasarla por scp o algún otro
protocolo que facilite cifrado ... no sería muy lógico
pasarla por ftp :-).
# scp
clave.key root@ip_segundo_nodo:/etc/vpn/clave.key
Es nesario recompilar el kernel habilitando soporte para:
Universal TUN/TAP device driver support
en Device Drivers -> Networking support.
Procedemos a cargar el módulo:
modprobe
tun
Comprobamos que tenemos /dev/net/tun, si no existe lo creamos con:
#
mknod /dev/net/tun c 10 200
Llegamos a lo mas importante, configurar el tunel, para ello
explicaré cual es mi configuración de red, y
pondré unos ejemplos, luego cada uno que lo adapte a sus
requerimientos ...
Como dije anteriormente, yo utilizo el tunel entre mi portatil y el
servidor que tengo haciendo las veces de router dentro de la red
wireless.
En la red wireless tengo el rango de ips 10.0.0.0/24 y para el tunel
utilizaré el rango 10.0.1.0/24.
La ip del portatil es: 10.0.0.1 (si usas dhcp asegurate de configuralo
adecuadamente para que siempre asigne la misma ip)
La ip del servidor es: 10.0.0.254
Finalmente solo nos queda lanzar openvpn de la siguiente forma:
*En el primer nodo (servidor):
#
openvpn --remote 10.0.0.1 --dev tun0 --ifconfig 10.0.1.254 10.0.1.1
--secret /etc/openvpn/clave.key --daemon --comp-lzo
Donde 10.0.0.1 es la ip del segundo nodo (el portatil este caso),
10.0.1.254 es la ip del primer nodo dentro de la VPN (el servidor en mi
ejemplo) y 10.0.1.1 es la ip del segundo nodo dentro de la VPN (el
portatil).
Con --daemon lo lanzamos en segundo plano y con --comp-lzo habilitamos
el uso de compresión.
*En el segundo nodo (portatil):
#
openvpn --remote 10.0.0.254 --dev tun0 --ifconfig 10.0.1.1 10.0.1.254
--secret /etc/openvpn/clave.key --daemon --comp-lzo
Y ya tendremos una bonita VPN, ahora todo el tráfico que vaya
encaminado hacia 10.0.1.254 pasará por dentro de la VPN y si
algún sniffer quiere hacer la gracia, solo verá muchos y
bonitos paquetes UDP :-)
En mi caso, como usaba el servidor (10.0.0.254) como router tenia en el
portatil como gateway 10.0.0.254, ahora quiero que utilice 10.0.1.254
que es más seguro, asi que:
# route del default
gw 10.0.0.254 && route add default gw 10.0.1.254
Y con esto ya podemos preocuparnos algo menos de la privacidad de
nuestras comunicaciones
Para que la red se inicie automáticamente al arrancar el equipo,
añadiremos un script similar a este en init.d:
(Hay que tener en cuenta que este script usa el interface tap, en lugar
de tun, para poder hacer un puente de red.)
#!/bin/bash
# Iniciamos VPN haciendo un puente entre la misma y eth0, para poder
acceder a la red local desde el otro extremo de la VPN
OPENVPN=/usr/sbin/openvpn
case "$1" in
start)
echo Starting openvpn
$OPENVPN --config /etc/openvpn/ppp.conf --daemon
echo Configuring bridge
ifconfig eth0 0.0.0.0
ifconfig tap0 0.0.0.0
brctl addbr br0
brctl addif br0 tap0
brctl addif br0 eth0
;;
stop)
echo Killing openvpn daemon
killall openvpn -9
break
;;
restart)
echo Killing openvpn daemon
kill -9 `ps aux |grep openvpn |grep nobody |awk '{print $2}'`
echo Starting openvpn
$OPENVPN --config /etc/openvpn/ppp.conf --daemon
ifconfig tap0 0.0.0.0
brctl addif br0 tap0
;;
*)
echo "Usage: $0 {start|stop|restart}"
;;
esac
exit 0
PPTP
Poptop es el servidor VPN
para linux que usa el protocolo VPN de Hasefrosh. Gracias a poptop,
podemos configurar VPN's de manera muy sencilla en clientes Windows.
Instalar el servidor en debian se hace con apt-get (paquete pptpd). Si
queremos cifrado
del canal, debemos soportar el módulo de cifrado mppe,
disponible con las fuentes del kernel desde la versión 2.6.15 en
la sección ppp (o descargable para compilar en kernels
anteriores).
En el fichero /etc/pptpd.conf, lo más relevante es lo referente
a las direcciónes IP.
localip
192.168.0.2
remoteip 192.168.0.102-200