enchufado.com RSS 2.0 Feed http://enchufado.com/ Feed rss 2.0 del blog enchufado.com es Servidor VPN fácil con Wireguard http://enchufado.com/post.php?ID=376 http://enchufado.com/post.php?ID=376 Tue, 02 Apr 2019 22:36:20 +0200En el post previo vimos cómo crear una VPN punto-a-punto con Wireguard para, por ejemplo, conectar dos sedes. Ésta vez, vamos a montar un servidor/concentrador VPN con el mismo software para que puedan conectarse clientes varios (roadwarriors). En nuestro caso, usaremos un móvil Android a través del cliente de VPN de Google Play que, a pesar de estar en Beta, parece funcionar correctamente.

Como anteriormente ya describimos ésta pieza de software, vamos directos al lío.

Servidor

  1. Habilitamos el ip forwarding:
  2. # Temporalmente
    $ sysctl net.ipv4.ip_forward=1
    
    # O de forma permanente
    $ vi /etc/sysctl.d/99-sysctl.conf
    net.ipv4.ip_forward = 1
    :wq
    $ sysctl -p
    
  3. Abrimos en el firewall el puerto 51820/udp y permitimos el forwarding a nivel de cortafuegos:
  4. iptables -I INPUT -p udp --dport 51820 -j ACCEPT
    iptables -P FORWARD ACCEPT
    
  5. Si tenemos un router, habrá que redireccionar el tráfico UDP del puerto 51820 a la dirección ip del servidor de la LAN que ejecutará el servicio/concentrador VPN Wireguard. Ésto hay que hacerlo a través del propio router.
  6. Generamos las claves pública y privada:
  7. $ wg genkey > privatekey
    $ chmod 600 privatekey
    $ wg pubkey < privatekey > publickey
    
  8. Creamos la configuración de Wireguard en el servidor. En éste caso creamos un solo peer, pero se pueden poner tantos como clientes VPN sean necesarios:
  9. $ mkdir /etc/wireguard
    $ vi /etc/wireguard/wg0.conf
    
    [Interface]
    Address = 10.200.200.1/24
    SaveConfig = true
    ListenPort = 51820
    PrivateKey = [SERVER PRIVATE KEY]
    
    # Sustituir 'eth0' por la interficie por la que el servidor escuchará de cara a Internet
    PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
    
    [Peer]
    # Cliente foo
    PublicKey = [FOO's PUBLIC KEY]
    #PresharedKey = [PRE-SHARED KEY]
    AllowedIPs = 10.200.200.2/32
    
    :wq
    
  10. En éste punto, podemos gestionar la interfaz "manualmente" usando wg-quick(8), o bien usando el servicio con el mismo nombre de systemd. Ejemplo de uno y otro:
  11. # Manualmente
    $ wg-quick up wg0
    [#] ip link add wg0 type wireguard
    [#] wg setconf wg0 /dev/fd/63
    [#] ip address add 10.200.200.1/24 dev wg0
    [#] ip link set mtu 1420 up dev wg0
    [#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    
    $ ifconfig wg0
    wg0: flags=209  mtu 1420
            inet 10.200.200.1  netmask 255.255.255.0  destination 10.200.200.1
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 0  bytes 0 (0 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    $ wg-quick down wg0
    [#] wg showconf wg0
    [#] ip link delete dev wg0
    [#] iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
    
    # Automáticamente
    $ systemctl enable wg-quick@wg0.service
    $ systemctl start wg-quick@wg0.service
    $ systemctl status wg-quick@wg0.service
    ● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
       Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
       Active: active (exited) since Tue 2019-04-02 20:40:09 CEST; 1s ago
         Docs: man:wg-quick(8)
               man:wg(8)
               https://www.wireguard.com/
               https://www.wireguard.com/quickstart/
               https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
               https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.8
      Process: 7145 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
     Main PID: 7145 (code=exited, status=0/SUCCESS)
    
    abr 02 20:40:08 srv systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
    abr 02 20:40:08 srv wg-quick[7145]: [#] ip link add wg0 type wireguard
    abr 02 20:40:09 srv wg-quick[7145]: [#] wg setconf wg0 /dev/fd/63
    abr 02 20:40:09 srv wg-quick[7145]: [#] ip address add 10.200.200.1/24 dev wg0
    abr 02 20:40:09 srv wg-quick[7145]: [#] ip link set mtu 1420 up dev wg0
    abr 02 20:40:09 srv wg-quick[7145]: [#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    abr 02 20:40:09 srv systemd[1]: Started WireGuard via wg-quick(8) for wg0.
    

Cliente

Con un cliente normal en consola, tendríamos la siguiente configuración:

$ vi /etc/wireguard/wg0.conf

[Interface]
Address = 10.200.200.2/24
PrivateKey = [FOO's PRIVATE KEY]
DNS = 10.200.200.1

[Peer]
PublicKey = [SERVER PUBLICKEY]
PresharedKey = [PRE-SHARED KEY]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = [SERVER PUBLIC IP]:51820
:wq

$ wg-quick up wg0

Comentar brevemente que el AllowedIPs es importante puesto que redigirá el tráfico para esos rangos de red por la VPN. Sería el análogo a las rutas pushed a los clientes de OpenVPN. Usando el catch-all 0.0.0.0/0, ::/0 redirigirá todo el tráfico a través de la VPN, pero podríamos decidir que sólo enrutamos ciertos rangos de red.

Por ejemplo, podemos poner sólo los rangos de red de nuestra LAN (192.168.1.0/24, 172.16.0.0/24) y de éste modo sólo se enrutará por la VPN cuando solicitemos alguna dirección de éstos rangos. El resto del tráfico irá por la ruta por defecto.

Veamos cómo proceder con la configuración del cliente Android:

  1. Instalamos el cliente Android.
  2. Lanzamos la aplicación y aparece vacía. Añadimos la siguiente configuración pulsando el botón '+' y seleccionando "Create from scratch". A parte de la interfaz wg0 (primera imagen), tendremos que añadir un peer (el servidor/concentrador VPN, segunda imagen):
  3. Y la guardamos (imagen del diskette arriba a la derecha). Nótese que ésto supone que tenemos un servidor DNS en el host servidor/concentrador de VPN. Si no es así, podemos poner algún otro servidor dns público (8.8.8.8, 1.1.1.1, etc). Con ésto ya lo tenemos configurado, y en la pantalla principal de la app nos saldria la siguiente interfaz wg0, que sólo tenemos que habilitar (encendiendo el interruptor) para establecer la conexión con el servidor/concentrador de VPN:
  4. A continuación podemos ver una muestra de captura de tráfico y estadísticas de la interfaz del lado del servidor/concentrador VPN:
  5. $ ifconfig wg0
    wg0: flags=209  mtu 1420
            inet 10.200.200.1  netmask 255.255.255.0  destination 10.200.200.1
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 158  bytes 16948 (16.5 KiB)
            RX errors 0  dropped 158  overruns 0  frame 0
            TX packets 63  bytes 7788 (7.6 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    $ tcpdump -ni any udp and port 51820
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
    
    20:21:56.513268 IP 31.4.189.86.53659 > 192.168.2.7.51820: UDP, length 148
    20:22:01.532883 IP 31.4.189.86.53659 > 192.168.2.7.51820: UDP, length 148
    20:26:01.896448 IP 31.4.189.86.53619 > 192.168.2.7.51820: UDP, length 148
    20:26:01.897602 IP 192.168.2.7.51820 > 31.4.189.86.53619: UDP, length 92
    20:26:01.967003 IP 31.4.189.86.53619 > 192.168.2.7.51820: UDP, length 96
    20:26:01.995992 IP 31.4.189.86.53619 > 192.168.2.7.51820: UDP, length 112
    20:26:02.164035 IP 31.4.189.86.53619 > 192.168.2.7.51820: UDP, length 96
    20:26:03.155887 IP 31.4.189.86.53619 > 192.168.2.7.51820: UDP, length 96
    20:26:05.195718 IP 31.4.189.86.53619 > 192.168.2.7.51820: UDP, length 96
    
  6. Llegados a éste punto, podemos intentar conectar a algún servicio del servidor/concentrador VPN o a algún otro de algún host enrutado por la VPN y debería funcionarnos.

Y ésto es todo.

]]>
VPN punto-a-punto fácil con Wireguard http://enchufado.com/post.php?ID=375 http://enchufado.com/post.php?ID=375 Sun, 31 Mar 2019 21:34:54 +0200De hace un tiempo, llevo leyendo sobre un software de VPN que tiene intención de llegar a ser incorporada en el kernel Linux, pero por motivos X no se hizo. Recientemente rescaté mi interés por el tema, topándome con éste artículo de arstechnica.

Los halagos a ésta pieza de software vienen de varias personalidades, siendo los provinentes de Linus Torvalds los de mayor relevancia (al fin y al cabo, es el padre del kernel de nuestro Sistema Operativo favorito; y el de toda Internet).

Algunas características a grandes rasgos, como comentan desde arstechnica:

  • Opera como módulo de kernel. Es decir, opera en kernel-space.
  • Muchas menos LOC (lineas de código) respecto de proyectos similares: 4k vs los 600k de OpenVPN o los 400k de OpenSSL, que se traduce en un mejor control y revisión del código, reduciendo con ello los bugs y la superficie de ataque. También en una probable mayor agilidad de operación de éste software vs otros de mayor envergadura.
  • Configuración mucho más simple. Lo veremos a continuación en éste ejemplo.
  • Algoritmos mucho más fuertes. Ésto trae como consecuencia el poder usar claves de menor longitud, mejorando de nuevo la velocidad de ejecución.
  • Handshakes/negociaciones más simples. A costa de no poder cambiar ciphers y digests, no ha de ocurrir una negociación de los mismos entre los hosts implicados. Resultado de ésto y otros puntos mencionados antes, se obtienen también unos tiempos de conexión rápidos.

Antes de proceder, comentar que Wireguard requiere de un kernel Linux ≥3.10 con algunas opciones de configuración habilitadas. Pero tranquilo: la mayoria de las distribuciones ya las llevan habilitadas en sus stock kernels. Dicho ésto y sin más dilación, vamos al lio con una configuración de VPN punto-a-punto.

Instalación

Nosotros vamos a optar por la opción de compilarlo desde las fuentes y posteriormente paquetizarlo para Debian gracias a una herramienta que considero socorrida (checkinstall). Son temas personales, dado que así luego la operación de instalación/desinstalación se me hace más sencilla:

$ apt-get install libmnl-dev libelf-dev linux-headers-$(uname -r) build-essential pkg-config
$ wget https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20190227.tar.xz
$ tar -Jxvf WireGuard-0.0.20190227.tar.xz
$ cd WireGuard-0.0.20190227/src
$ make -j2
$ su
$ checkinstall # Ésto ya realiza la instalación desde el paquete .deb generado

Configuración

Después de leer el Quick Start de la documentación oficial de Wireguard, le eché un vistazo a la entrada al respecto de la Wiki de Arch (que siempre la encuentro de lo más exquisita por su clara exposición) y con eso me fue suficiente para levantar y dejar funcionando la VPN punto-a-punto.

En concreto, los pasos aplicados son los que van del punto 2.1 al 2.3. Aclarar que los endpoints son las direcciones ip en las que va a estar escuchando el servicio VPN (en mi caso, 2 ips públicas). Tener en cuenta que al igual que QUIC, Wireguard trabaja por UDP, y por tanto, hay que abrir los puertos dónde escuchará dicho servicio por éste protocolo.

# Generamos la private key en ambos peers, A y B
$ wg genkey > privatekey
$ chmod 600 privatekey

# Generamos la public key también an ambos peers
$ wg pubkey < privatekey > publickey

# Peer A: Levantaremos éste punto VPN en el puerto 48574 y
# aceptará conexiones del peer B enlazando la public key del
# mismo con su dirección pública y las ips permitidas. Sólo
# aceptará conexiones del peer B.
#
$ ip link add dev wg0 type wireguard
$ ip addr add 10.0.0.1/24 dev wg0
$ wg set wg0 listen-port 48574 private-key privatekey
$ wg set wg0 peer [Peer B public key] persistent-keepalive 25 allowed-ips 10.0.0.2/32 endpoint 10.10.10.2:39814
$ ip link set wg0 up

# Peer B: Como con el otro peer, levantaremos éste punto VPN
# en otro puerto (el 39814) y aceptará conexiones del peer A
# enlazando la public key del mismo con su dirección pública
# y las ips permitidas. Sólo aceptará conexiones del peer A.
#
$ ip link add dev wg0 type wireguard
$ ip addr add 10.0.0.2/24 dev wg0
$ wg set wg0 listen-port 39814 private-key ./privatekey
$ wg set wg0 peer [Peer A public key] persistent-keepalive 25 allowed-ips 10.0.0.1/32 endpoint 10.10.10.1:48574
$ ip link set wg0 up

Con ésto ya deberíamos tener la VPN levantada y los peers conectados, a no ser que haya algún problema de red o firewall que impida su conexión. Comprobaciones que podemos hacer:

# Ver la configuración de identidad y de los peers asociados
peer-a$ wg
 interface: wg0
   public key: UguPyBThx/+xMXeTbRYkKlP0Wh/QZT3vTLPOVaaXTD8=
   private key: (hidden)
   listening port: 48574
 
 peer: 9jalV3EEBnVXahro0pRMQ+cHlmjE33Slo9tddzCVtCw=
   endpoint: 10.10.10.2:39814
   allowed ips: 10.0.0.2/32

# Hacer un ping a la ip del otro peer al final del tunel
peer-a$ ping 10.0.0.2

Finalmente, podemos guardar la configuración de modo permanente y recuperarla posteriormente:

$ wg showconf wg0 > /etc/wireguard/wg0.conf
$ wg setconf wg0 /etc/wireguard/wg0.conf

Esperemos que ésta pieza de software no tarde en incorporarse en el mainline Linux kernel :)

]]>
Privacidad de consultas DNS http://enchufado.com/post.php?ID=374 http://enchufado.com/post.php?ID=374 Sun, 20 Jan 2019 18:41:09 +0100En los últimos tiempos, parece que se ha puesto de moda y nos han dado la murga desde diversos frentes con el tema HTTPS. Y está bien más que nada en el aspecto de la seguridad de los datos transmitidos y la privacidad, porque en cuanto a lo que se refiere a la verificación de la parte poseedora del certificado, podría ser objeto de discusión.

Y ya que estamos puestos en materia, también deberíamos preocuparnos por un aspecto olvidado y asignatura pendiente en el ámbito de la privacidad como lo es el DNS. Las consultas, por defecto van en plano/sin cifrar, y resultan una suculenta información empresarial que puede servir para definir el perfil de cada persona.

Así pues, en la búsqueda de implementar algo rápido, me topé con éste interesante artículo al respecto de arstechnica que me gustó y cuya lectura recomiendo. A continuación los métodos probados para su consecución, siempre en Debian GNU/Linux testing :)

DNS over HTTPS (DoH!)

Éste método fue el primero que probé por las posibilidades de tenerlo funcionando en un corto espacio de tiempo, y funcionó. Se basa en hacer las peticiones DNS a través de HTTPS. No se requiere autenticación, y de la validación del certificado SSL ya se encargan las CA's. Aquí su uso en Debian (testing):

$ wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.tgz
$ tar -zxvf cloudflared-stable-linux-amd64.tgz
$ cp /etc/resolv.conf{,.bak}
$ echo 'nameserver 127.0.0.1' > /etc/resolv.conf
$ ./cloudflared proxy-dns --upstream https://1.0.0.1/dns-query

Como podemos ver, usamos el cliente de tunneling Argo de Cloudflare y es necesario poner como nameserver nuestro propio host (localhost / 127.0.0.1), puesto que es dónde estará escuchando éste servicio que lanzamos. Como apunte, comentar que nos hemos bajado el binario (a pesar de haber paquete Debian) porque queríamos ver el contenido y poder ejecutarlo manualmente sin necesidad de instalar nada. Al fin y al cabo, se trata de un paquete ajeno a Debian.

La ventaja del mismo es que funciona por puertos web estandar, por lo que seguramente lo podríamos usar allá donde vayamos al no estar bloqueado por firewalls. El inconveniente es que no disponemos del código fuente, y aunque CloudFlare es una empresa de conocida reputación, nos gusta el código de fuente abierta y libre, con auditoria "mundial".

DNS over TLS

Sobre éste método, mis kudos a SrDedo por darse cuenta que el paquete stubby estaba en los repositorios de Debian (en el momento del artículo, al parecer no lo estaba) y por tanto, nos decidiéramos a probarlo.

El método encapsula las consultas DNS en tráfico TCP encriptado. A continuación su instalación y uso en Debian (testing):

$ apt-get install stubby
$ systemctl start stubby
$ cp /etc/resolv.conf{,.bak}
$ echo 'nameserver 127.0.0.1' > /etc/resolv.conf

Su configuración está en formato yaml y puede encontrarse en /etc/stubby/stubby.yml. Por defecto es segura en el sentido que sólo acepta funcionar:

  • En modo estricto (autenticación con upstream obligatoria)
  • En modo seguro (se usa TLS o nada)
  • En modo privado (se requiere privacidad del cliente o nada)
  • Con queries distribuidos en múltiples servidores upstream (round robin en los habilitados)

Las ventajas son que es un proposed IETF standard, que es fácil/ rápido/sencillo en Debian y que usa SPKI para autenticar la conexión con los servidores. El inconveniente es que al funcionar por el puerto 853, puede estar bloqueado por algún firewall (depende de dónde estemos), aunque hay upstreams que permiten usar el puerto 443 (ver el archivo de configuración).

¿Cómo comprobar su funcionamiento?

Basta con, habiendo habilitado uno de los métodos, hagamos un tcpdump en local al puerto 53 y ver que no hay tráfico cuando hacemos requests DNS. Para ver el tráfico del primer método, podemos capturar el tráfico del puerto 443 (aunque costará distinguir tráfico web del dns enrutado por web), y para el segundo método tendremos que capturarlo del puerto 853, que es por donde funciona la vertiente DNS over TLS.

¿Y no hubiéramos acabado antes con DNSSEC?

Son cosas diferentes. DNSSEC se encarga de validar que la respuesta dns proviene de su servidor autoritativo y que no ha sido modificada. Es por tanto, una medida complementaria, pero distinta, a la privacidad. Resulta, por eso, que los servidores upstream de la solución que más nos ha gustado (DNS over TLS con stubby) soportan DNSSEC. Aquí podéis comprobarlo, una vez lo tengáis funcionando, claro está. O para hacerlo manualmente desde consola:

  • dig sigok.verteiltesysteme.net (should return A record)
  • dig sigfail.verteiltesysteme.net (should return SERVFAIL)
]]>
Cómo publicar torrents en The Pirate Bay http://enchufado.com/post.php?ID=373 http://enchufado.com/post.php?ID=373 Thu, 08 Feb 2018 10:47:52 +0100Éste va a ser un speed post más, porque me llevó más de 5 minutos encontrarlo por La Red y pensé que podía hacer un resumen. Inspiración y créditos a éste artículo en el idioma anglosajón.

Recurriendo al conocido dicho "vamos por partes" cómicamente atribuido a Jack El Destripador, el proceso se dividiría en las siguientes:

  1. Crear un archivo torrent del archivo a compartir.
  2. Crear una cuenta en The Pirate Bay y subir el archivo torrent.
  3. Hacer seeding del archivo a compartir.

Vamos allá.

Crear un archivo torrent del archivo a compartir

Para ello necesitamos el archivo a compartir, ponerlo en un path o ruta del que no se va a mover y crear el archivo torrent. Veamos unos ejemplos de cómo sería con transmission-cli o ctorrent:

$ ctorrent -t -u "http://tracker.thepiratebay.org:80/announce" -s mi_video.torrent mi_video.avi
ó
$ transmission-cli -n mi_video.avi -a http://tracker.thepiratebay.org:80/announce -w mi_video.torrent

Ésto nos genera el archivo torrent, si bien puede tardar un poco en función del tamaño o número de archivos a añadir. Comentar que le indicamos un tracker porque la aplicación para crear el torrent lo necesita, si bien no se va a usar. Ésto es porque hace tiempo que The Pirate Bay no usa torrents ni trackers, sino magnets y DHT en su lugar.

Crear una cuenta en The Pirate Bay y subir el archivo torrent

Ésto no tiene mucho secreto. Vamos a register y nos damos de alta. Nos llegará un correo de verificación, verificamos visitando el enlace y voilá. Eso si, para subir nuestro primer archivo torrent debemos esperar 1 hora. Normas del site. Cuando haya llegado el momento, subimos el archivo (Upload torrent) añadiendo nombre, tags y descripción. Hecho ésto, deberíamos poder encontrar nuestro torrent haciendo una búsqueda.

Hacer seeding del archivo a compartir

És el paso final y más sencillo: cargamos el archivo torrent en nuestro programa favorito (transmission, ctorrent, rtorrent, uTorrent...) y deberíamos ver cómo calcula el hash del archivo que ya tiene, momento en el cual comienza a hacer seeding para que se lo puedan descargar los posibles interesados. Un ejemplo en transmission-cli:

$ transmission-cli -D -U -w /home/usuario/mi_video.torrent 

Ésto verificará el archivo a servir y cuando hayan clientes (leechers) mostrará cuántos y el progreso de su decarga. És la única información que tendremos, la de los leechers de transmission-cli, puesto que en The Pirate Bay no va a salir por el mencionado uso del magnet+DHT (vs el clásico y ya desaparecido torrent+tracker).

Ésto es todo, amigos.

]]>