¿Qué tan fácil es detectar que se está utilizando una VPN?

Las redes privadas virtuales (VPN) resuelven muchos problemas de privacidad. Dado que una VPN generalmente encripta su tráfico entre su computadora y el proveedor de VPN, hace que sea muy difícil para un observador ver su tráfico para ver lo que está haciendo. Sin embargo, hay muchas personas que quieren poder ocultar el hecho de que están usando una VPN; como personas en países que prohíben las VPN u otras situaciones en las que el uso de VPN no está generalmente permitido o bloqueado por medios técnicos. En este artículo, nos enfocamos en el tipo de datos que un observador puede recopilar de las capturas de paquetes de red y cómo esos datos pueden usarse para detectar el uso de VPN.

Antecedentes del problema

La pregunta candente es “¿por qué”? ¿A quién le importa si alguien descubre que estás ejecutando una VPN? Si el tráfico está muy encriptado de todos modos, ¿cuál es el problema??

Es cierto que en muchas situaciones y en muchos países, no importa en absoluto si un observador detecta el uso de una VPN. Sin embargo, hay muchos países que prohíben el uso de VPN y, por lo tanto, es importante que los usuarios de VPN en esos países sepan cómo se pueden descubrir.

Para determinar si una VPN está en uso, un observador debe tener acceso a un enrutador por el que pasa el tráfico objetivo. En el caso de una víctima objetivo, un atacante puede gastar grandes recursos para identificar una forma de hacerse cargo de un enrutador que utiliza la víctima en particular. En el caso de la vigilancia del estado nacional, la detección efectiva requeriría el control de muchos enrutadores. Cuando combina esas dos cosas, una organización que se preocupa si está usando una VPN y también tiene la capacidad de controlar una gran cantidad de enrutadores, lo que generalmente indica un actor de amenaza a nivel nacional.

Tenga en cuenta que este artículo trata sobre las formas en que los observadores pueden descubrir el uso de VPN. No significa necesariamente que los datos encriptados dentro del túnel VPN sean más fáciles de explotar.

Metodología de prueba

Sin acceso a recursos a nivel estatal, mi plataforma y metodología de prueba es un poco más pequeña en escala. Creé una pequeña red interna usando tres máquinas virtuales (VM) con VirtualBox. La topología de la red es como tal:

Instalé el software de detección de paquetes en la VM del enrutador OpenWRT y luego probé varias configuraciones de VPN en las otras dos máquinas virtuales. El software de detección de paquetes, tcpdump, me permitió capturar el tráfico de red de las máquinas virtuales para su análisis. En una configuración más realista, el software de captura de paquetes probablemente se instalará en enrutadores en Internet, o al menos dentro de la red del ISP. La ubicación estratégica del software de análisis requeriría algún conocimiento de los puntos de interés de convergencia en Internet donde es probable que el tráfico objetivo fluya. En mi red de prueba, sé con 100% de certeza que todo el tráfico hacia y desde mis máquinas virtuales pasará a través de ese enrutador OpenWRT. Por lo tanto, es el mejor lugar para colocar mis herramientas de recolección.

Fuentes no técnicas de indicadores VPN

No todas las fuentes de datos que indican el uso de VPN son técnicas. Mientras que algunos son muy técnicos, como el análisis de paquetes, algunos son muy poco técnicos, como el error humano y la rutina diaria..

Tráfico de red no deseado

La mayoría de los usuarios de VPN tienen un software de cliente que debe iniciarse para que se establezca la VPN. Es muy difícil asegurarse de que no pase tráfico por Internet antes de que se establezca la VPN cuando se inicia una computadora. Incluso aquellas VPN con interruptores kill pueden no ser capaces de hacer nada sobre el tráfico que pasa durante el arranque del sistema.

Para probar esto, configuré las opciones de interruptor de conexión automática y apagado de VyprVPN en la máquina virtual de Windows. Luego apagué la máquina con Windows, comencé una captura de paquetes en el enrutador OpenWRT e inicié la máquina con Windows. Eso generó muchos paquetes y de interés son estas dos secuencias.

Primero, podemos ver muchos pings en un rango similar de IP. No agrupé estos paquetes a propósito; así es como se enviaron orgánicamente:

Esto sugiere que algo está tratando de enumerar servidores. Una causa muy común de este tipo de tráfico en un escenario VPN es un cliente VPN que intenta determinar el servidor más rápido. Un método para hacer esto es enviar un paquete ICMP (conocido como ping) a un conjunto de servidores para ver cuáles regresan más rápido.

Podemos ver en la primera captura de pantalla que 209.99.63.34 devolvió el más rápido en 99 milisegundos. Más abajo en la captura de paquetes, de repente vemos que la mayor parte del tráfico desde ese momento está encriptado y está destinado a 209.99.63.34

La siguiente pieza del rompecabezas es descubrir qué hay en esas IP. Utilizando IP WHOIS que indica el propietario registrado de una IP, podemos ver que todas menos una de estas IP pertenecen a YHC Corporation y resuelven los servidores en el centro de datos de Data Foundry:

209.99.108.46
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209.99.109.167
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209.99.113.70
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209-99-115-97
209.99.117.82
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209.99.21.36
OrgName: Corporación YHC
OrgTechEmail: [email protected]
OrgTechEmail: [email protected]
209.99.22.46
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209.99.60.34
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209.99.61.42
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209.99.62.34
OrgName: Corporación YHC
OrgTechEmail: [email protected]
OrgName: Powerhouse Management, Inc.
OrgTechEmail: [email protected]
209.99.63.34
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209.99.63.34
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209.99.67.41
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209.99.72.70
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209.99.75.70
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209.99.93.34
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209.99.94.37
OrgName: Corporación YHC
OrgTechEmail: [email protected]
209.99.95.40
OrgName: Corporación YHC
OrgTechEmail: [email protected]

El siguiente paso lógico sería escanear esas IP para ver qué servicios están ejecutando. No proporcionaré detalles sobre cómo hacerlo, pero mis pruebas muestran que los banners de conexión predeterminados que muestran la mayoría de los servidores se han eliminado de los servidores VyprVPN, por lo que no hay ninguna evidencia obvia de que estas IP ejecutan un servidor VPN.

No hay mucho que pueda hacer sobre cómo actúa su computadora antes de que se inicie. Por lo tanto, si desea ofuscar este tipo de secuencia de configuración, deberá ejecutar una VPN “en frente” de su computadora. Ejecutar el cliente VPN en su enrutador en lugar de ejecutar un cliente en su computadora es una forma de hacerlo. Todavía se encontrará con las mismas secuencias de inicio cuando se reinicie el enrutador, pero eso suele ser menos frecuente que su computadora.

No hay paquetes sin cifrar

Como mencioné anteriormente, una vez que los pings se completaron, la captura de paquetes muestra el tráfico encriptado a la IP más rápida. Si un observador solo ve paquetes cifrados y no un solo paquete no cifrado, eso puede ser una señal de que hay una VPN en uso. Si bien el mundo se está moviendo rápidamente hacia el cifrado de la mayor cantidad de datos posible en la web, todavía hay algunas solicitudes que generalmente no están cifradas. Entre estas se encuentran las consultas de búsqueda de DNS, las consultas de NNTP (servidor de tiempo) y un puñado de otras solicitudes de protocolo como FTP y Telnet que a veces se usan en algunas de nuestras aplicaciones, pero que no admiten encriptación en absoluto.

Fugas de seguridad operacional humana descuidada (OpSec)

Se puede obtener una gran cantidad de datos significativos de un objetivo mediante el uso de información aparentemente trivial. Muchas personas dedican mucho tiempo y esfuerzo a mitigar lo que perciben como cosas “importantes” solo para ser identificadas por información trivial en la que no pensaban. Algunos ejemplos incluyen la larga memoria de Internet que reveló que el administrador de correo electrónico de Hillary Clinton probablemente era un tipo llamado Paul Combetta; Dread Pirate Roberts, también conocido como Ross Ulbricht, el presunto autor intelectual del mercado ilegal de Internet de Silk Road, fue procesado en gran parte debido a los datos en su computadora portátil que le fueron extraídos físicamente mientras estaba distraído en una biblioteca pública.

De manera menos dramática, los observadores pueden usar con frecuencia cosas como ciclos de actividad para precisar la zona horaria de un objetivo o la presencia de caracteres especiales en un mensaje para identificar un diseño de idioma correspondiente al país de un objetivo. No hay una lista completa de cosas a tener en cuenta al considerar la seguridad operativa, porque encontrar nuevas formas de referencia cruzada de datos es principalmente un ejercicio de imaginación y recursos..

Sin embargo, hay algunas cosas específicas relacionadas con la captura de paquetes que pueden identificar el uso de VPN.

Signos reveladores de metadatos de paquetes

Las claves de PFS son predecibles

Debido a que el tráfico VPN generalmente está encriptado, generalmente está oculto a los curiosos. El cifrado funciona porque es muy difícil “forzar” datos cifrados para exponer su contenido de texto claro. De hecho, romper el cifrado es tan difícil que los proyectos de vigilancia a gran escala a veces solo recopilan todos los datos que pueden con la esperanza de que puedan romper el cifrado en una fecha futura cuando aumente la potencia de la computadora, o puedan obtener las claves que se usaron para cifrar los datos. Perfect Forward Secrecy (PFS) es un método que se puede usar para prevenir este último escenario.

Perfect Forward Secrecy vuelve a generar las claves de cifrado utilizadas para cifrar el tráfico VPN periódicamente. Cuando se genera un nuevo par de claves, se destruye el par anterior. Esto significa que los paquetes cifrados recopilados no se pueden descifrar en una fecha posterior porque la clave utilizada para cifrarlos ya no existe.

OpenVPN es compatible con PFS. Mientras capturaba datos para este artículo, reduje la tasa de ciclos clave a 10 segundos para capturar ese proceso que tiene lugar. Descubrí que cuando tuvo lugar la regeneración de la clave, se generó la siguiente secuencia de paquetes:

09: 01: 48.461276 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, longitud 94
09: 01: 54.749114 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, longitud 65
09: 01: 58.895381 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, longitud 86
09: 01: 58.951091 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, longitud 94
09: 01: 58.951614 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, longitud 259
09: 01: 59.007916 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, longitud 94
09: 01: 59.008027 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, longitud 94
09: 01: 59.008265 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, longitud 94
09: 01: 59.008300 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, longitud 94
09: 01: 59.062927 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, longitud 256
09: 01: 59.106521 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, longitud 575

Lo notable de esta secuencia es que los tamaños de los paquetes son idénticos cada vez que tiene lugar la regeneración de la clave. Por lo tanto, cada vez que veía una secuencia de paquetes con estos tamaños en mi captura de paquetes, sabía que se estaba produciendo un ciclo clave:

94
sesenta y cinco
86
94
259
94
94
94
94
256
575

Podría decirse que cualquier proceso repetitivo generaría teóricamente una secuencia repetida de paquetes como este, pero aún puede usarse como un indicador de que PFS puede estar en juego. Junto con otros datos, esta información podría ser suficiente para confirmar una conexión VPN.

Todos los paquetes destinados a la misma IP.

Durante el curso normal del uso de Internet, las personas y las computadoras solicitan datos de muchos sitios diferentes. Cada uno de esos sitios tiene una dirección IP diferente. Cuando se usa una VPN, cada paquete está destinado al servidor VPN. El servidor VPN despega la capa de cifrado VPN de cada paquete para revelar el paquete real y luego lo envía camino a su destino real. El servidor VPN hace lo mismo con las respuestas. Recibe paquetes de respuesta, los envuelve en una capa de cifrado y luego los envía a la computadora del usuario..

Una captura de paquetes que muestra una computadora que envía el 100% de su tráfico a una sola IP es un buen indicador de que una VPN o proxy está en uso.

Psiphon es una herramienta de elusión de censura de internet. Tiene una función interesante que puede combatir esto hasta cierto punto. Tiene un modo de túnel dividido que esencialmente solo usa el túnel Psiphon para el tráfico que sale de su propio país.

Para ver cómo se ve esto a nivel de paquete, inicié Psiphon y probé dos sitios. Estoy en Canadá y aquí hay una muestra de tráfico que está destinado a nuestro propio registrador de dominios .CA. En este caso, mi destino es claramente visible en la captura de paquetes.

8: 30: 14.213668 IP 192.168.1.210.58787 > www.cira.ca.https: Flags [.], ack 1026833, win 64240, length 0
08: 30: 14.229178 IP www.cira.ca.https > 192.168.1.210.58787: Banderas [.], Seq 1026833: 1028293, ack 715, victoria 5094, longitud 1460
08: 30: 14.229427 IP www.cira.ca.https > 192.168.1.210.58787: Flags [.], Seq 1028293: 1031213, ack 715, win 5094, length 2920
08: 30: 14.229781 IP 192.168.1.210.58787 > www.cira.ca.https: Flags [.], ack 1031213, win 64240, length 0

Luego visité el sitio web de Comparitech que está alojado en los Estados Unidos:

8: 29: 48.028789 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Banderas [P.], seq 107809: 108277, ack 19080, victoria 1392, longitud 468
08: 29: 48.029101 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Flags [.], ack 108277, win 856, length 0
08: 29: 48.029306 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Flags [P.], seq 19080: 19132, ack 108277, win 856, length 52
08: 29: 48.108658 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Banderas [.], Ack 19132, victoria 1392, longitud 0

Observe cómo el tráfico destinado a los EE. UU. Se envía a un servidor Linode en lugar de a comparitech.com. Linode es una empresa de servidores muy grande y no es inusual ver el tráfico destinado a un servidor Linode. Psiphon oculta aún más ese tráfico al usar un túnel SSH para ocultar cualquier rastro de una VPN. Además, el DNS inverso (rDNS) para el servidor Psiphon en Linode no revela su asociación con Psiphon; el rDNS solo muestra que Linode posee la IP, que se espera. Hay más información sobre rDNS en la sección de ofuscación más adelante en este artículo..

Inconsistencias en el sistema operativo y los datos de la huella digital del paquete

Aunque la red TCP es independiente del sistema operativo, diferentes sistemas operativos crean paquetes con algunos valores diferentes. Por ejemplo, el valor predeterminado del tiempo de vida del paquete (TTL) varía en los paquetes creados en diferentes sistemas. La mayoría de los sistemas Windows establecerán el paquete TTL en 128 de manera predeterminada, mientras que la mayoría de los sistemas Linux lo establecerán en 64. Dado que el TTL es una parte visible del paquete capturado, es posible determinar qué sistema operativo probablemente creó ese paquete. También hay otros signos reveladores en la construcción de paquetes, como la longitud y el tamaño máximo de segmento (MSS) que también varían de un sistema operativo a otro..

El fragmento a continuación es parte de un paquete generado a partir de un sistema Windows. Nota la ttl 127 el valor en la última línea se establece en 127. Esto se debe a que el TTL se expresa en número de “saltos”. Cada vez que un paquete atraviesa un dispositivo como un enrutador, su TTL disminuye en uno. En este caso, el TTL comenzó en 128 pero desde que lo capturé en el enrutador, después de un salto, ahora es 127. Sin embargo, todavía puedo decir que nunca fue 64, por lo que es probable que este sea un paquete creado en un sistema Windows.

08: 08: 51.657495 IP (tos 0x0, ttl 64, id 32150, offset 0, banderas [DF], proto UDP (17), longitud 177)
google-public-dns-a.google.com.domain > 192.168.2.139.59414: 40501 3/0/0 cdn-3.convertexperiments.com. CNAME cdn-3.convertexperiments.com.edgekey.net., Cdn-3.convertexperiments.com.edgekey.net. CNAME e5289.g.akamaiedge.net., E5289.g.akamaiedge.net. A 104.94.35.212 (149)
08: 08: 51.659278 IP (tos 0x0, ttl 127, id 3890, offset 0, banderas [DF], proto TCP (6), longitud 52)

Un paquete capturado desde una máquina Linux tiene un TTL de 63 después de su primer salto. Esto se debe a que la mayoría de las máquinas Linux establecen el valor inicial del paquete TTL en 64.

08: 15: 55.913493 IP (tos 0x0, ttl 63, id 41443, offset 0, banderas [DF], proto UDP (17), longitud 56)
192.168.2.139.48635 > resolver1.ihgip.net.domain: 47200+ A? google.com (28)

¿Y qué? ¿Por qué puede ser importante saber qué sistema operativo creó un paquete??

Si un observador tiene un conocimiento especializado de un objetivo, puede ser muy importante. Si se sabe que el objetivo usa Windows, tal vez como miembro de una gran organización que usa Windows en todo momento, pero los paquetes capturados desde ese objetivo muestran que probablemente fueron creados en una máquina Linux, ese es un buen indicador de que una VPN o proxy de algunos El tipo está en uso. Vale la pena señalar que prácticamente todos los servidores VPN se ejecutan en servidores similares a Linux o Unix.

Es posible ajustar los parámetros del paquete en la mayoría de los sistemas, pero muy pocas personas llegan a esta longitud.

Técnicas de ofuscación insuficientes de los proveedores de VPN

Hay más en el análisis de red que solo recopilar paquetes. Los procesos auxiliares como el DNS pueden desempeñar un papel. Muchos usuarios de VPN conocen el DNS porque enviar consultas DNS de forma clara es una forma para que un observador determine dónde está visitando o a punto de visitar. Sin embargo, menos usuarios conocen el DNS inverso (rDNS). Al igual que DNS asocia un nombre de dominio a una dirección IP, rDNS asocia una dirección IP a un nombre de host y el nombre del host generalmente identifica al propietario de la IP. Además, la mayoría de las bibliotecas de programación y los sistemas operativos vienen con alguna versión de las funciones estándar gethostnameby * () que amplían la capacidad del sistema para asociar IP y nombres de host..

El DNS inverso no es tan crítico como el DNS “normal” porque rDNS no desempeña ningún papel en el enrutamiento del tráfico. Más bien, se usa principalmente como un medio para identificar la propiedad de IP. Solo el propietario de una dirección IP puede asociarle un registro rDNS. Por lo tanto, verificar el registro rDNS de una dirección IP proporciona una garantía razonable de quién es el propietario, o al menos, quién quiere que el propietario piense que es el propietario. Tenga en cuenta que no se requiere rDNS y muchas direcciones IP no tienen entradas de rDNS en absoluto.

Veamos el ejemplo del dominio facebook.com. El registro DNS A proporcionado por una consulta DNS estándar muestra esta dirección IP:

$ dig + short facebook.com
31.13.67.35

Ahora usemos una consulta DNS inversa o la función gethostnamebyaddr () para ver quién posee esa IP:

$ host -n 31.13.67.35
35.67.13.31.in-addr.arpa puntero del nombre de dominio edge-star-mini-shv-01-mia3.facebook.com

Podemos ver de esto que Facebook realmente posee esa dirección IP. Sin embargo, la mayoría de los sitios no poseen sus propias IP; están arrendados y pertenecen a organizaciones arbitrarias o quizás son propiedad de entidades menos obvias. Amazon es un ejemplo de un gran proveedor de informática que utilizan muchas empresas. Una consulta rDNS para la dirección IP de muchos servicios de Internet simplemente muestra que Amazon posee la IP y, por lo tanto, la información es de poca utilidad para determinar quién opera la IP. Otro ejemplo es Google. Google es un poco más sutil en sus entradas de rDNS, pero aún mantiene la información de propiedad. Así es como el DNS inverso busca una IP de Google:

$ dig + short google.com
216.58.207.46

$ host -n 216.58.207.46
46.207.58.216.in-addr.arpa puntero de nombre de dominio fra16s24-in-f14.1e100.net.

Google posee el dominio 1e100.net, por lo que podemos ver que esta IP de hecho pertenece a Google.

En el mundo de las VPN, las herramientas de resolución de direcciones pueden usarse potencialmente para ver si la IP a la que está destinado su tráfico pertenece a una VPN. Por ejemplo, un comando tcpdump predeterminado en el enrutador OpenWRT intentará resolver las IP que ve en los paquetes TCP. Parece utilizar principalmente gethostbyaddress () para hacer esto y, por lo tanto, a veces es posible ver dónde están destinados los paquetes. Una captura de tcpdump predeterminada de una sesión IPVanish ilustra esto:

08: 23: 14.485768 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, longitud 1441
08: 23: 14.485847 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, longitud 1441
08: 23: 14.486144 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, longitud 1441
08: 23: 14.486186 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, longitud 385

El cliente IPVanish para Windows proporciona tres configuraciones: una conexión OpenVPN estándar, una conexión OpenVPN usando HTTPS y una conexión ofuscada.

Los paquetes anteriores se capturaron durante una sesión utilizando la configuración de conexión OpenVPN ofuscada, pero WireShark aún puede proporcionar información de destino.

En resumen

Al determinar el uso de VPN, hay muy pocas “balas de plata”. Por lo general, se requieren varias técnicas u observaciones para compilar suficientes indicadores que indiquen que una VPN está en uso, e incluso entonces puede ser difícil estar 100% seguro. Las empresas que tienen un interés personal en no permitir el uso de VPN como Netflix y otros servicios de transmisión tienen equipos de tiempo completo dedicados solo a este problema. En otros casos, muchos países de Europa del Este y Medio Oriente) prohíben el uso de VPN y tienen equipos similares para descubrir a los usuarios de VPN.