viernes, 28 de febrero de 2014

Paso a paso: Cómo crear tu propio acceso seguro a internet para wifis públicos (VPN con Android)

Entras en un bar, pides una consumición y la clave del wifi para consultar un par de cosillas con el móvil... es como si acabaras de soltar un cacho de carne en una jaula de hienas, y ese cacho de carne eres tú.

En el bar, donde todos comparten la misma clave de cifrado, tus comunicaciones se pueden interceptar y leer como si fueran un libro abierto, sólo en algún caso se complica un poco si estás accediendo a páginas seguras (https, las del candado).

Por suerte hay formas de proteger tu privacidad con muy bajo coste o esfuerzo. Accediendo a través de una red privada virtual (VPN) que puedes crear tú mismo.

A tú alcance tienes distintas posibilidades:
  1. Establecer la conexión segura con un servicio especializado.
  2. Establecer la conexión segura con tu casa.
  3. Establecer la conexión segura con un VPS (servidor virtual privado).

1. Establecer la conexión segura con un servicio especializado.


Por supuesto, es la opción más sencilla y con suerte la más segura. Se espera que un servicio profesional de seguridad esté siempre atento a posibles fallos.  Pero también es la opción más cara, la app para android suele ser gratuita pero el servicio tiene un coste mensual de unos 4$ como mínimo. Es muy probable que no te permita modificar el puerto de conexión.

2. Establecer la conexión segura con tu casa.


El clásico Juan Palomo, yo me lo guiso yo me lo como. Al salir de casa debes dejar el ordenador y el router encendidos. Eres el encargado de instalar y configurar el equipo (cualquier ordenador puede servir) pero también deberías tener en cuenta el coste en tiempo y factura eléctrica (nada despreciable). A tarifas del año pasado una Raspberry Pi encendida 24/7 podía representar unos 5€ al año (sin contar el router), pero si se te ocurre usar un pc de escritorio el coste se multiplica por 10 como mínimo. Ciertamente sólo tu imaginación y la conexión de ADSL (sobretodo la velocidad de subida) limitan hasta qué punto puedes amortizar esta opción.

3. Establecer la conexión segura con un VPS (servidor virtual privado).


Esta forma es muy parecida a la anterior. Sólo que en vez de tener el ordenador en tu casa está en "la nube". Los VPS son la opción más barata (no sirve un hosting compartido) y para lo que nos atañe más que suficiente. La oferta es inmensa. La velocidad de conexión suele ser mucho mejor que con el ADSL de tu casa, aunque por otro lado al contratar un ancho de banda concreto (como la tarifa de datos) puedes encontrarte que o te corten el acceso o te facturen de más si te pasas. Pero estamos hablando de unos cuantos gigas al mes....
Nota: Personalmente elegí la tercera opción y es la que voy a explicar paso a paso a continuación.
En particular, he usado el VPS llamado Blue 0.5 de BlueVM:
  • 128 MB de RAM
  • 128 MB de vSWAP
  • 5 GB de disco
  • 100 GB de ancho de banda al mes
  • 1.0 Ghz+ CPU
  • 1 Dirección IPv4 fija
  • Soporte limitado
Por la friolera de $7.5 al año (unos 5,5€). Una Raspberry Pi encendida en casa junto al router podría resultar más cara sólo por consumo eléctrico. Claro que la cantidad de memoria es poca, para la VPN és suficiente.


Contratación


La contratación es muy sencilla, aunque hay un par de aspectos que pueden generar dudas. Durante el proceso de compra te pedirá los siguientes datos de configuración del servidor:


Éstos datos no tienen mucha relevancia a efectos prácticos pero hay que rellenarlos.

  • Hostname:
Puedes escribir el nombre que quieras, identificará éste VPS en tu lista de servicios contratados.

  • NS1 Prefix: ns1
  • NS2 Prefix: ns2
Tal como vas a configurar el servidor no se usará para nada, pero de todas formas no está de más configurarlo con los valores habituales.

  • Root Password:
Puedes establecer la contraseña que prefieras para el usuario root del servidor, de todas formas en los primeros pasos de configuración del servidor habrá que volver a establecerla.


Finalizado el proceso de compra me he encontrado con otra situación antes de poder utilizar el servidor.


Puede sucederte (a mi me ha pasado dos veces), que después de realizar todo el proceso de compra y pagar con PayPal el servicio no se active y en el panel de control muestre que la factura sigue impagada. Pero en PayPal sí se haya registrado la transacción.


Abre un "Ticket" (en el menú de la izquierda "My Tickets") para indicarles lo sucedido. Necesitarás el ID de transacción único de PayPal que puedes encontrar en los detalles de la transacción en la web de PayPal. A mi un texto así (seguro que no está perfectamente escrito) me ha servido. Indica el número de factura de BlueVM donde #numInvoice y el ID de transacción único de PayPal donde #idPayPal:


Subject: Invoice #numInvoice still unpaid
Text:
Hi,

the status of the paypal transactions is completed but the invoice #numInvoice stills says it's unpaid. The PayPal Unique Transaction ID for this transaction is #idPayPal.

Thanks
Pueden tardar tranquilamente más de un día en responder. En cuanto recibas contestación diciendo que te han activado el servicio podrás empezar a configurar el servidor.


Configurar el VPS de BlueVM


Para acceder al panel de control dirígete a https://feathur.bluevm.com/ y usa las mismas credenciales que para entrar en bluevm.


Verás la lista de los servidores contratados:


Si pones la dirección IP que te indica "Primary IP" en el navegador podrás ver la página web de test del servidor. Entra a ver los detalles del servidor pulsando sobre el botón "view".



Aparece el panel de control del servidor. La primera pestaña "General" te permite encender, parar, reiniciar y matar (como si lo desenchufaras) el servidor. Además también te muestra información de uso.
Importante: Si por cualquier motivo debes dejar para otro momento la configuración del servidor o interrumpir el proceso a medias te recomiendo parar (Stop) el servidor en ésta pestaña "General" y volver a iniciarlo (Start) cuando puedas continuar. Así evitarás dejarlo expuesto a posibles ataques.
Como primer paso carga una imagen de las disponibles, dentro de la pestaña "Rebuild".


Yo he seleccionado una imagen de Fedora 18 de 64 bits (la primera que he encontrado que usara systemd, así en cuanto haya las nuevas versiones de Debian/Ubuntu ésta guía seguirá siendo útil). Si eliges cualquier otra al menos que sea la más actual posible (por ejemplo Debian 7 mejor que Debian 6) no vayas a encontrarte con algún bug antiguo. Es posible que algun paso cambie según la distribución que hayas elegido, seguramente esté indicado en el wiki o foro correspondiente.

Indica también una contraseña (que sea un poco larga y compleja) para el usuario root, marca la casilla y dale al botón de rebuild.

Cuando termine dirígete a la pestaña "Settings".


En mi caso como no me reconocía la contraseña al intentar entrar tuve que volver a establecer una contraseña aquí, lo que podrías hacer a modo de prevención y para evitar problemas. Además los módulos deberían quedar como en la imagen, con los módulos Tun/Tap e IPTables activados.

Con esto ya has hecho todo lo que necesitabas configurar desde las opciones del panel de control Feathur. El siguiente paso será conectarte al servidor a través de una conexión ssh que puedes realizar con aplicaciones como KiTTY/PuTTY en Windows u OpenSSH desde GNU/Linux. El panel de control Feathur en la pestaña "Console" también te ofrece un cliente java para establecer dicha conexión.

Los datos de conexión serán:
  • host: <tu "Primary IP">
  • port: 22
  • user: root
  • password: <tu password>

Nota: Los comandos que estén precedidos por el símbolo $ indican que se ejecutan desde un usuario sin privilegios (no root). Los precedidos por el símbolo # requieren que te hayas identificado como root en tu ordenador o en el ordenador remoto según corresponda. Al principio te conectarás como root al servidor pero después de configurar ssh deberás usar primero el comando su.


Para conectarte desde Linux puedes usar el siguiente comando:
$ ssh root@<tu "Primary IP">

Nota: Una vez dentro, como suelo usar nano como editor y en algunas distros no está instalado por defecto lo primero que hice fué actualizar el sistema e instalarlo, aunque si te apañas con lo que hay instalado puedes dejar la actualización para después de configurar ssh.

En Fedora/CentOS:
# yum update
# yum install nano

En Debian/Ubuntu:
# apt-get update
# apt-get dist-upgrade
# apt-get install nano 

En nano, para guardar los cambios y salir se usa la combinación de teclas Ctrl + x, se confirman los cambios pulsando la tecla Y y la tecla Entrar.


Crear usuario


Si permites el acceso al sistema de forma remota con el usuario root facilitas que el atacante sólo deba averiguar la contraseña. En cambio, si bloqueamos el acceso remoto a root el atacante tendrá la dificultad añadida de intentar averiguar qué nombre de usuario es el que tiene acceso. La dificultad se multiplica. Recuerda que tener acceso al usuario root es tener acceso a todo el sistema, no te interesa que sea fácil de conseguir.

Para asegurar éste punto, primero debes crear otro usuario con el nombre que prefieras (evita cosas como admin, administrator,...)
# adduser nuevousuario
Puede que te pida que establezcas la contraseña, aunque si no lo hace da igual, porque lo más seguro es configurar la autentificación con un par de claves cifradas. Justo el siguiente paso.


Crear par de claves RSA


Para ello, si usas Linux/OS X, puedes usar el siguiente comando desde tu ordenador, no en la consola que está conectada al servidor. Si usas Windows el proceso es diferente.
$ ssh-keygen -t rsa -b 2048
Te preguntará si quieres establecer una passphrase que te pedirá cada vez que vayas a autenticarte con dicha clave. No es obligatoria, si no pones ninguna podrás acceder al servidor de forma segura sin necesidad de escribir ninguna contraseña.

El resultado son un par de archivos llamados probablemente id_rsa e id_rsa.pub. Te recomiendo que te los copies en algun pendrive por ejemplo, que tengas tu copia de seguridad de las claves porque si las pierdes no tendrías forma de acceder al servidor (los servicios que estén configurados sí los podrías seguir usando, por ejemplo acceder a la VPN, pero si necesitaras acceder mediante ssh para cambiar la configuración no podrías y tendrías que empezar desde el "rebuild").


Instalar clave RSA en el servidor


Ahora deberás copiar el archivo id_rsa.pub al servidor. Desde Windows puedes usar WinSCP.
$ scp ~/.ssh/id_rsa.pub root@<tu "Primary IP">:/home/nuevousuario/
Recuerda cambiar siempre <tu "Primary IP"> por la ip de tu servidor y nuevousuario por el nombre de usuario que hayas elegido. Y desde el servidor coloca el archivo en su sitio con los permisos adecuados.
# cd /home/nuevousuario
# chown nuevousuario:nuevousuario id_rsa.pub
# su nuevousuario
$ mkdir ~/.ssh
$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
$ rm ~/id_rsa.pub
$ chmod 600 ~/.ssh/authorized_keys
$ chmod 700 ~/.ssh/
$ exit
Con esto ya se puede acceder al servidor con tu nuevousuario sólo desde el ordenador o dispositivo que tenga instalada la clave que has generado. Aunque comprueba que funciona correctamente desde tu ordenador antes del siguiente paso (que puedas entrar sin escribir contraseña o usando el passphrase).
$ ssh nuevousuario@<tu "Primary IP">


Configurar ssh en el servidor


Deshabilita el login con password y el login de root, edita /etc/ssh/sshd_config y busca y cambia las líneas siguientes para que queden como te indico (no tienen que estar necesariamente juntas):
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
Si lo deseas, para ponerlo un poco más difícil, puedes cambiar el puerto de conexión de ssh también en /etc/ssh/sshd_config:
Port 22
Para ello cambia el 22 por cualquier otro número entre el 2000 y el 65535. Es posible que coincida con algún otro servicio registrado pero no pasará nada mientras no tengamos instalado también el otro servicio.

Reinicia el servicio y sal del servidor:
# systemctl restart sshd
# exit
A partir de ahora sólo podrás acceder usando tu nuevousuario. Una vez dentro, puedes usar el comando su para tomar el rol de root. Si has cambiado el puerto deberás añadir la opción -p a ssh.
$ ssh nuevousuario@<Tu "Primary IP"> -p nuevopuerto


Actualizar el sistema


En Fedora/CentOS:
# yum update
En Debian/Ubuntu:
# apt-get update
# apt-get dist-upgrade


Configurar alerta de conexión:


Puedes recibir una alerta por mail cada vez que alguien acceda al servidor por ssh usando el nuevousuario (es el único que puede acceder al servidor de forma remota). Puede ir muy bien en caso de que alguien lograra entrar. Así, cuando se establezca una conexión ssh el servidor nos mandará un mail.

Prueba que funcione la instrucción antes de establecer que se ejecute en cada login. Para ello usa el siguiente comando cambiando mi@email.com por tu dirección de correo electronico.
$ echo 'ALERTA - Acceso a Terminal de' `whoami` 'en:' `hostname` 'el:' `date +'%Y/%m/%d'` `who | grep -v localhost` | mail -s "[ `hostname` ] Alerta: Acceso a Terminal de `whoami` el: `date +'%Y/%m/%d'` `who | grep -v localhost | awk {'print $5'}`" mi@email.com
Si no recibes ningún correo probablemente sea que, tal como indican en DesdeLinux, necesitas instalar un paquete que te facilite la herramienta mailx, por ejemplo:

En Fedora/CentOS:
# yum install mailx
En Debian/Ubuntu
# apt-get install mailutils
Si recibes correctamente el correo, edita el fichero .bashrc con tu editor favorito, en mi caso:
$ nano ~/.bashrc
Y añade la instrucción al final (sin el símbolo $ inicial), recuerda que debe terminar con tu dirección de correo. Guarda los cambios. Si cierras la sesión mediante exit y vuelves a entrar deberías recibir un mail.


Desactivar servicios innecesarios


Desactiva el servidor apache, liberarás memoria y tendrás menos puertos abiertos. Si lo necesitas más adelante ya lo podrás volver a activar. Ten en cuenta que cualquier acceso (bots, pings, buscadores...) a tu servidor consume el ancho de banda disponible. A mí en un mes y teniendo sólo la página de test me volaron 95 de los 100 gigas disponibles y yo sólo lo usé 8 días.
# systemctl stop httpd.service
# systemctl disable httpd.service
Puede que según la imagen que hayas escogido se activen otros servicios que no te interesen. Puedes ver la lista de servicios así:
# systemctl | grep service
Mejor no desactives ningún servicio si no estás seguro de qué hace.

En Debian/Ubuntu y alguna otra distribución usan otros sistemas de init que dada la coyuntura no creo que valga la pena explicar. En los próximos meses Systemd estará hasta en la sopa.


Instalar OpenVPN en el servidor


OpenVPN es la herramienta que se encargará de crear la red privada virtual entre el móvil, portátil, pc y el servidor. Además redireccionará el acceso a internet a través del servidor. Para configurar OpenVPN necesitaras instalar los paquetes openvpn y easy-rsa.
# yum install openvpn easy-rsa


Crear claves para OpenVPN


Necesitarás crear las claves para la Infraestructura de clave pública (PKI). Segun la distribución/versión puede que los archivos de easy-rsa se encuentren en otra ubicación.
$ su
# cp -ai /usr/share/easy-rsa/2.0 ~/easy-rsa
# cd easy-rsa

# nano vars
Edita el archivo vars para cambiar como mínimo los valores KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG y KEY_EMAIL (no dejes ninguno de estos en blanco). Usa tus propios valores, los que indico son a modo de ejemplo. Cambia también el valor de KEY_SIZE a 2048 si está en 1024.
export KEY_SIZE=2048

export KEY_COUNTRY="US"
export KEY_PROVINCE="CA"
export KEY_CITY="Acme Acres"
export KEY_ORG="Acme"
export KEY_EMAIL="roadrunner@acmecorp.org"
#export KEY_EMAIL=mail@host.domain
export KEY_CN=Acme-CA
export KEY_NAME=Acme-CA
export KEY_OU=""
CA_EXPIRE y KEY_EXPIRE definen la duración de la infraestructura PKI que estás creando. En mi caso, por defecto está configurado como 3650 días (unos 10 años). Si para entonces aún estás usando éstas claves deberás renovarlas.

Exporta las variables:
# source ./vars
Elimina los certificados creados con anterioridad.
# ./clean-all
Genera la Autoridad de Certificacion (CA). Te pedirá los datos que ya has definido editando vars con lo que puedes ir aceptando, en caso de que quieras dejar en blanco algún valor escribe un punto '.'
# ./build-ca
Genera el certificado de servidor. Asegúrate de cambiar <nombre servidor> por un nombre único (Common Name cuando ejecutes el script). Recuérdalo ya que si más adelante generas otro certificado de servidor usando la misma Autoridad de Certificación debe tener otro Common Name. Deja en blanco challenge password y el company name cuando te lo pida.
# ./build-key-server <nombre servidor>
.
.
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
.
.
Sign the certificate? [y/n]:y
.
.
1 out of 1 certificate requests certified, commit? [y/n]y
Genera el archivo Diffie-Hellman parameters .pem requerido por el servidor.
# ./build-dh
Genera el certificado del cliente. Asegúrate de cambiar <nombre cliente> por un nombre único. Debes generar un certificado de cliente para cada dispositivo que quieras conectar a la VPN. Por ejemplo, un certificado para tu móvil, uno para el de tu pareja y otro para el ordenador del trabajo. Deja en blanco challenge password y el company name cuando te lo pida.
# ./build-key <nombre cliente>
.
.
A challenge password []:
An optional company name []:
.
.
Sign the certificate? [y/n]:y
.
.
1 out of 1 certificate requests certified, commit? [y/n]y
Genera un Hash-based Message Authentication Code (HMAC). Con se añade una firma extra al intercambio de paquetes SSL/TLS que añade un extra de seguridad.
# openvpn --genkey --secret /root/easy-rsa/keys/ta.key
Todas las claves y certificados se han guardado en /root/easy-rsa/keys. Si te has equivocado en algo puedes volver a empezar el proceso de crear claves.

Finalmente copia las claves a /etc/openvpn.
# cp -r ~/easy-rsa/keys /etc/openvpn/


Configurar OpenVPN en el servidor


Copia el archivo de ejemplo (puede que se encuentre en otra ubicación) y edítalo:
# cp /usr/share/doc/openvpn-2.3.2/sample/sample-config-files/server.conf /etc/openvpn/server.conf

# nano /etc/openvpn/server.conf
Cambia los siguientes parámetros para que se ajusten a los nombres de tus claves y ubicaciones:
port 1194
.
.
proto udp
.
.
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/<nombre servidor>.crt
key /etc/openvpn/keys/<nombre servidor>.key
.
.
dh /etc/openvpn/keys/dh2048.pem
.
.
push "redirect-gateway def1 bypass-dhcp"
.
.
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
.
.
tls-auth /etc/openvpn/keys/ta.key 0
.
.
user nobody
group nobody
Habilita el servicio:
# systemctl enable openvpn@server.service


Crear archivo de configuración OpenVPN para el cliente


Estos pasos son para configurar y conectarte desde un dispositivo Android (o que al menos pueda instalar la aplicación OpenVPN Connect). Para conectarte desde el ordenador el proceso es un poco distinto.

Será necesario crear un archivo .ovpn que contenga la información de conexión y las claves. Puedes usar el siguiente script en el servidor para facilitar la tarea.

Descarga el script y edítalo para configurar los parámetros ip, port y proto.
# cd /etc/openvpn/keys
# curl -O https://gist.githubusercontent.com/Siot/9248473/raw/a7ac405408bb671130b8fb110670abb9effe2d73/ovpn.sh
# chmod +x ovpn.sh
# nano ovpn.sh
En ip debes poner la dirección ip de tu servidor, port y proto deben coincidir con los parámetros port y proto de la configuración de OpenVPN en el servidor.

Una vez hecho, ejecútalo para generar los archivos .ovpn:
# ./ovpn.sh <nombre cliente>
Esto te generará un archivo llamado <nombre cliente>.ovpn listo para importar al cliente. Si has generado varias claves de cliente puedes ejecutar  ovpn.sh tantas veces como necesites usando los distintos <nombre cliente>.

Lo más seguro para transferir estos archivos .ovpn al dispositivo cliente (uno por dispositivo) sería copiarlos a /home/nuevousuario y mediante scp transferirlos a tu ordenador para luego pasarlos al móvil/tablet. Pero pinta muy engorroso cuando te puedes mandar por mail el archivo y descargarlo directamente.
echo "" | mailx -s "Clave VPN" -a <nombre cliente>.ovpn mi@email.com


Ip Forward e Iptables


Es necesario activar la opción de forward para los dispositivos de red si no está activada:
cat /proc/sys/net/ipv4/ip_forward
Si muestra el valor 1 no hay que hacer nada más, si muestra el valor 0 crea un archivo de configuración para que se active cada vez que se inicie el servidor:
echo net.ipv4.ip_forward=1 > /etc/sysctl.d/20-ipv4forward.conf
En iptables será necesario habilitar el redireccionamiento nat para la red que crea OpenVPN.
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j SNAT --to-source <tu "Primary IP">
Para que sea permanente crea una ubicación donde guardar la configuración de iptables
# mkdir /etc/iptables
# iptables-save > /etc/iptables.rules
Y un servicio de systemd para que guarde los cambios al apager el servidor y los cargue al iniciarlo:
# nano /etc/systemd/system/iptables_persistent.service
con el siguiente contenido:
[Unit]
Description=Packet Filtering Framework

[Service]
Type=oneshot
ExecStart=/usr/sbin/iptables-restore /etc/iptables/iptables.rules
ExecReload=/usr/sbin/iptables-restore /etc/iptables/iptables.rules
ExecStop=/usr/sbin/iptables-save > /etc/iptables/iptables.rules
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
Habilita el servicio y reinicia el servidor:
# systemctl enable iptables_persistent.service
# reboot


Instalar y configurar OpenVPN Connect en el dispositivo Android


Instala la aplicación OpenVPN Connect en tu dispositivo Android.

En el menú ve a "Import" -> "Import Profile from SD card" y selecciona el archivo .ovpn que previamente has guardado en el dispositivo (ya sea copiado por usb como descargado del correo). Cuando se haya importado podrás seleccionar el perfil y conectarte.


Una vez conectado puedes comprobar que el tráfico se redirige a través del servidor, accede a Bandaancha.eu. Debería mostrarte la dirección IP de tu servidor.


Consideraciones finales


El proceso es algo largo y dado que cada distribución/versión puede contener cambios es susceptible a no funcionar a la primera.

Es posible, además, que en según qué sitios (bar, cafetería, biblioteca...) tengan bloqueado el puerto 1194 o el protocolo udp por lo que será necesario probar con distintas combinaciones tanto en el lado del servidor como en el cliente (con un editor tipo Jota+ se puede editar el archivo .ovpn directamente en el dispositivo). Puertos de otros servicios, como el 80, 443 o el 8080, es muy probable que suelan estar abiertos. También te puedes encontrar que haya un proxy o un proxy transparente en la red del que necesitarás conocer la ip y el puerto que usa y configurarlo en las opciones de la app OpenVPN Connect, en estos casos no he tenido suerte y no he logrado que me funcione.

Asimismo, soy consciente que habría que mimar mucho más la configuración de Iptables para bloquear y descartar conexiones no deseadas al servidor. Es delicado ya que puedes quedarte sin acceso por ssh.

La conexión responde más lenta que sin la red virtual, ten en cuenta que datos de páginas que consultes en España, pasan por el servidor virtual ubicado en EEUU para luego volver a España. Y servicios que geolocalicen tu IP te ubicarán en EEUU (páginas web que muestren la versión americana por defecto, Steam en dólares...).

Finalmente, espero que te haya resultado útil y estés disfrutando de conexiones seguras en wifis públicos.

Si tienes problemas para conectarte al servidor porque no está accesible el puerto 1194 te puede interesar el artículo ¿A qué puertos/servicios de internet me permite acceder el firewall de la intranet?.

Si lo deseas te puedo enviar un correo electrónico cada vez que publique algo en Mi backup tan sólo debes inscribir tu dirección de correo. Tú dirección de correo será confidencial y sólo te enviaré información que crea que te puede interesar.

No hay comentarios:

Publicar un comentario