Redes de anonimato: VPN, Tor e I2P

seguridad10

La privacidad y el anonimato en línea dependen de evitar que su ISP y otros adversarios locales vean el contenido de la comunicación o los metadatos, y de evitar que los adversarios remotos vean información sobre su identidad o ubicación. El primer paso es asegurar su conexión a Internet . Básicamente, no conecta dispositivos directamente a Internet. En su lugar, los conecta a través de un módem / enrutador independiente usando Ethernet e interpone un firewall de hardware entre el módem / enrutador y sus dispositivos. Eso ayuda a prevenir la fuga de información sobre su identidad y ubicación, y también protege sus dispositivos del compromiso de adversarios externos.

Si bien esa es una configuración profesional típica para banda ancha, prácticamente nadie lo hace para teléfonos inteligentes. Pero ahora, al menos, es factible con Librem 5 y PinePhone .

Sin embargo, su ISP y otros adversarios locales aún pueden ver las direcciones IP a las que accede y todo el contenido de comunicación y metadatos. Y los adversarios remotos aún pueden ver el contenido y los metadatos, y la dirección IP asignada por su ISP. Aunque las aplicaciones con cifrado de extremo a extremo ocultarán el contenido y algunos metadatos, no ocultan las direcciones IP locales o remotas.

Bien, entonces, ¿cómo podemos ocultar completamente el contenido, los metadatos y las direcciones IP?

Básicamente, debe haber un intermediario. Debe eliminar las direcciones IP. Y todo el tráfico entre nuestros dispositivos y el intermediario debe estar cifrado de forma segura. Eso protege casi todo de los adversarios locales, excepto el tiempo y el patrón de tráfico y, por supuesto, la dirección IP del intermediario.

También oculta la dirección IP asignada por su ISP a los adversarios remotos. Sin embargo, aún pueden ver contenido y metadatos, a menos que use aplicaciones con cifrado de extremo a extremo. Incluso entonces, los metadatos necesarios para el direccionamiento y el transporte no se pueden ocultar. Por lo tanto, es mejor evitar los metadatos que crean asociaciones con las identidades o ubicaciones de nuestro espacio cárnico. Es decir, debemos compartimentar nuestras personas en línea de nuestras identidades del espacio de la carne. Cubriré eso en [Cómo ser realmente anónimo en línea].

Servicios VPN y proxies anónimos

De todos modos, estos intermediarios se denominan generalmente “apoderados anónimos”. Ahora, eso normalmente significa servicios VPN. Algunas personas todavía usan proxies HTTPS y SOCKS, pero esos son dudosos, porque pueden filtrar las direcciones IP de los usuarios a los sitios. E incluso VPN Warp de Cloudflare lo hace, por diseño, porque su enfoque es la protección contra los adversarios locales.

Algunos servicios VPN ofrecen enrutamiento de varios saltos para proteger contra el análisis del tráfico y el compromiso de la infraestructura. Es decir, el proxy no es solo un servidor. El tráfico se enruta a través de varios servidores, a menudo en diferentes continentes. Por lo tanto, un adversario no podría ver el tráfico estableciendo solo un centro de datos o ISP.

Algunos enfatizan que todo el tráfico entre servidores VPN está encriptado de forma segura . Y Perfect Privacy afirma además que su opción NeuroRouting minimiza la exposición a Internet del tráfico de los usuarios, seleccionando un servidor de entrada cerca del usuario y un servidor de salida cerca del sitio al que se accede, quizás en el mismo centro de datos.

Pero aquí está el problema: no puede confiar en un proxy anónimo para ocultar nada. Esto se debe a que no hay forma de saber qué información retiene, o un adversario con acceso a su infraestructura. O con quién está cooperando o comprometido. Está atascado en confiar en él, o al menos, confiar en que su infraestructura es segura.

Distribución de información y confianza

De hecho, no existe protección contra adversarios omniscientes y omnipotentes. Sin embargo, puede reducir el riesgo de compromiso mediante la distribución de información y confianza. Que yo sepa, fue David Chaum quien notó por primera vez que en «Correo electrónico, direcciones de retorno y seudónimos digitales imposibles de rastrear», publicado en 1981:

Este artículo presenta una solución al problema del análisis de tráfico que se basa en la criptografía de clave pública. Baran ha resuelto el problema del análisis de tráfico para las redes, pero requiere que cada participante confíe en una autoridad común. Por el contrario, los sistemas basados ​​en la solución avanzada aquí pueden verse comprometidos solo por la subversión o la conspiración de todo un conjunto de autoridades . [énfasis añadido]

Aunque los detalles de su implementación no son relevantes aquí, todos los sistemas que brindan un anonimato sustancial se basan en la distribución de información y confianza.

  • redes mixtas de remailer
  • Colina
  • I2P
  • cadenas VPN anidadas
  • posibilidades para teléfonos inteligentes

Redes de mezcla de revendedores

El enfoque de Chaum para el “correo electrónico imposible de rastrear” se implementó por primera vez en las redes de remailer Mixmaster y Cypherpunk. Es un enfoque elegante y potencialmente muy eficaz contra el análisis del tráfico. Los nodos introducen latencia almacenando en caché los mensajes. E introducen incertidumbre al mezclar mensajes antes de reenviarlos.

Sin embargo, eran complicados, por lo que no muchos los usaban. Y eso los mantuvo demasiado pequeños para resistir eficazmente el análisis de tráfico. Sin embargo, todavía existen.

Colina

Tor fue diseñado para proporcionar a los usuarios acceso de baja latencia a los recursos de Internet. Y, por lo tanto, no implementó el almacenamiento en caché ni la mezcla. Si bien está algo descentralizado, no es una red P2P. Actualmente comprende alrededor de 6300 servidores, también conocidos como relés. Aproximadamente 3000 son de confianza como guardias y aproximadamente 1000 como salidas. Un pequeño grupo de retransmisores confiables proporciona de manera cooperativa varios servicios de directorio y autenticación. Y actualmente hay más de dos millones de usuarios .

Básicamente, después de obtener información sobre los relés de los servidores de directorio, los clientes de Tor construyen circuitos para usarlos para acceder a cosas. Para cada circuito, un cliente elige tres relés: un protector de entrada, un relé intermedio y un relé de salida. Cada cliente elige algunos protectores de entrada para usarlos de manera consistente. Eso ayuda a proteger a los clientes contra la vigilancia masiva y los ataques de desanonimización por retransmisiones maliciosas.

Esta respuesta de Tor.SE explica cómo funciona la construcción de circuitos. Comenzando con la protección de entrada, un cliente Tor extiende los circuitos negociando sucesivamente claves de cifrado hacia adelante y hacia atrás con cada relé, confiando en la clave pública del relé para la autenticación y el cifrado. Así que en resumen:

  • «Cada relé elimina una capa de cifrado utilizando la clave de reenvío compartida en el camino a seguir».
  • «Cada relé agrega una capa de cifrado utilizando la clave inversa compartida en el camino de regreso».
  • «La misma ruta (circuito) se usa tanto para avance como para retroceso».

Dado el enrutamiento de varios saltos con cifrado en capas, esto se denomina «enrutamiento cebolla» . Y proporciona anonimato al distribuir información y confianza entre los tres relés de cada circuito:

  • Un guardia de entrada ve las direcciones IP del cliente y del relé intermedio, pero solo el contenido encriptado.
  • Un relé intermedio ve las direcciones IP del guardia y sale, pero solo el contenido encriptado.
  • Un relé de salida ve las direcciones IP del relé intermedio y el destino, y el contenido de texto sin formato.

Tor también admite servicios de cebolla , a los que solo se puede acceder a través de los clientes de Tor. Al igual que los clientes, los servicios de cebolla normalmente construyen circuitos de tres relés. Al inicio, los servicios de cebolla establecen circuitos persistentes a relés que servirán como puntos de introducción. También publican esos puntos de introducción anónimos en una tabla hash distribuida.

Para iniciar conexiones con un servicio de cebolla, un cliente primero aprende sus puntos de introducción de la tabla hash distribuida. Luego elige un punto de encuentro y construye un circuito hasta él. Y luego construye un circuito a uno de los puntos de introducción del servicio de cebolla y solicita una conexión a través del punto de encuentro elegido. Y finalmente, el servicio de cebolla construye un circuito hasta el punto de encuentro. De esa manera, el cliente y el servicio de cebolla son mutuamente anónimos. Sin embargo, hay una opción para que los servicios de cebolla opten por no permanecer en el anonimato y se conecten directamente a los puntos de presentación y encuentro.

Para protegerse mejor contra los ataques de desanonimización, está el complemento de vanguardia . Utiliza dos guardias de entrada en el modo de «doble salto», en lugar de un solo guardia. Aunque es principalmente para servicios de cebolla, también funciona para clientes. Todavía no forma parte de Tor y está implementado en Python.

En teoría, Tor se encuentra entre las opciones viables más anónimas. Pero hay motivos para desconfiar . Siendo realistas, hay muchas retransmisiones maliciosas. Al menos algunos han evitado ser detectados por discreción. Pero hay motivos para sospechar que el gobierno de EE. UU. Y sus amigos pueden operar relés maliciosos con la aprobación tácita de al menos parte del personal del Proyecto Tor. O que los desarrolladores de Tor pueden retrasar la reparación de vulnerabilidades, en deferencia a los intereses del gobierno. E incluso si Tor en sí no está fatalmente comprometido, la NSA y otros adversarios globales pueden estar registrando conexiones con todos los guardias de entrada y relés de salida de Tor.

Aun así, en mi opinión, Tor es teóricamente demasiado anónimo para ignorarlo por completo. Incluso en el peor de los casos, es probable que proporcione un mejor anonimato que un servicio VPN aleatorio. De lo contrario, un adversario necesitaría una supervisión completa de todo el tráfico de Tor. En el mejor de los casos, puede proporcionar un mejor anonimato que las cadenas VPN anidadas (y quizás incluso Orchid). Pero en cualquier caso, conectarse directamente a la red Tor es posiblemente demasiado arriesgado. Siempre uso Tor a través de cadenas VPN anidadas.

Como dice @thegrugq :

Las VPN brindan una buena cobertura que Tor simplemente no puede: «Lo estaba usando para ver videos de Hulu» es mucho mejor que «Solo estaba tratando de comprar drogas ilegales en línea».

I2P

No estoy tan familiarizado con I2P. Eso es básicamente porque I2P no funciona bien sin puertos abiertos, y eso se complica al usar los servicios VPN. Pero diré más sobre eso a continuación.

I2P se centra en la comunicación anónima de igual a igual (P2P) , en lugar de en el acceso anónimo a Internet. Sin embargo, hay algunos sustitutos de Internet , y eso justifica cubrirlo aquí.

I2P comenzó como una bifurcación de Freenet , que posiblemente fue la primera «plataforma P2P para comunicación resistente a la censura»:

I2P comenzó inicialmente en febrero de 2003 como una modificación propuesta a Freenet para permitirle utilizar transportes alternativos …

Freenet se trata completamente de contenido P2P y no hay ningún mecanismo para el acceso a Internet. Pero vale la pena mencionarlo, aunque solo sea para distinguirlo de I2P y Tor, y como advertencia.

Como muchas de las primeras redes P2P, Freenet se basa principalmente en la “negación plausible”, más que en el anonimato. Es decir, todos los pares pueden conectarse entre sí directamente. Dado eso, los pares malintencionados pueden almacenar en caché contenido ilegal y luego registrar las direcciones IP de los pares que acceden a él.

Freenet emplea una sofisticada estrategia de encriptación y reenvío para ocultar a los remitentes y destinatarios de intermediarios inocentes. Entonces, posiblemente, cualquier par puede afirmar plausiblemente que es solo un intermediario, que maneja contenido cifrado de extremo a extremo.

Sin embargo, dados los datos de registro de compañeros malintencionados, los adversarios pueden descubrir compañeros que manejan contenido ilegal. Luego, pueden intentar distinguir a los remitentes y destinatarios de los intermediarios inocentes, a través del análisis de tráfico estadístico. Y luego pueden arrestarlos y procesarlos.

Esto no es teórico . La policía utilizó una versión modificada del cliente Freenet, Black Ice . El Proyecto Freenet dice tonterías :

Los documentos inicialmente hechos públicos por el departamento de policía de Missouri describen sus esfuerzos para rastrear el uso de Freenet. Usando un esquema simple, afirman una tasa de falsos positivos cercana a cero para rastrear al originador de una descarga. Si bien aplaudimos toda la documentación pública sobre los ataques, debemos señalar que la supuesta efectividad de sus ataques se basa únicamente en matemáticas defectuosas. En realidad, la tasa de falsos positivos de su método es al menos del 83% y cercana al 100% en escenarios del mundo real.

Tal vez sea así, pero establecer eso en la corte depende de tener un testigo experto que pueda convencer al jurado de que el caso de la fiscalía se basa en “matemáticas defectuosas”. Probablemente no sea tan fácil y ciertamente costoso. Es mucho mejor evitar la atención. No recomiendo usar Freenet, excepto en un VPS completamente anónimo, administrado y al que se accede a través de cadenas VPN anidadas y Tor. Cubriré el enfoque general en [Cómo ser realmente anónimo en línea], pero no específicamente en Freenet.

De todos modos, I2P también es una red P2P. Y, por lo tanto, es potencialmente vulnerable a ese descubrimiento de pares y a las mentiras sobre el análisis de tráfico.

Sin embargo, I2P proporciona anonimato a través del «enrutamiento de ajo» de varios saltos , que Michael Freedman definió como una extensión del «enrutamiento de cebolla» . De hecho, I2P se parece un poco a los servicios de cebolla de Tor, aunque los detalles no son en absoluto similares. Una diferencia clave es que los túneles I2P de múltiples saltos son unidireccionales, mientras que los circuitos Tor de múltiples saltos son bidireccionales.

I2P «los mensajes salen K salta a través del túnel de salida y otro K salta a través del túnel de entrada, con K no más de 3». Cada par puede especificar cuántos saltos utilizarán sus túneles de entrada y salida. Básicamente, más saltos significan mejor anonimato :

  • Túneles de 0 saltos … negación plausible muy básica
  • Túneles de 1 salto … negación plausible y anonimato básico
  • Túneles de 2 saltos … los costos de montar el ataque de análisis de tráfico aumentan
  • Túneles de 3 saltos … recomendados para el más alto nivel de protección

Por tanto, para los servicios de cebolla I2P y Tor, las conexiones implican entre 4 y 6 saltos.

La distinción clave es que alrededor del 95% de los usuarios de I2P enrutan el tráfico de los demás , y se recomienda hacerlo para «ayudar a la red». Y así, prácticamente todos los nodos I2P son potencialmente detectables por pares maliciosos , al igual que con Freenet. Pero a la inversa, un cliente Tor dado se conecta solo con servidores de directorio y solo con unos pocos guardias de entrada. Por tanto, la vigilancia masiva de los clientes de Tor es más difícil.

Las comparaciones de I2P y Tor, o, a menudo, enrutamiento de ajo y cebolla, a veces señalan que el enrutamiento de ajo implementa el almacenamiento en caché y la mezcla, mientras que el enrutamiento de cebolla no. De hecho, eso impulsó la decisión de hacer que los túneles I2P fueran unidireccionales. De esa manera, no es necesario negociar claves comunes de avance y retroceso, y los túneles pueden agrupar varios mensajes, «cada uno con sus propias instrucciones de entrega».

Sin embargo, I2P v9.44 en realidad no implementa el almacenamiento en caché o la mezcla del contenido del mensaje:

Los dos mecanismos principales para permitir que las personas que necesitan un fuerte anonimato usen la red son mensajes enrutados de ajo explícitamente retrasados ​​y túneles más completos para incluir soporte para la agrupación y mezcla de mensajes. Estos están actualmente planeados para la versión 3.0, pero los mensajes enrutados con ajo sin demoras y los túneles FIFO [primero en entrar, primero en salir] están actualmente en su lugar. Además, la versión 2.0 permitirá a las personas configurar y operar detrás de rutas restringidas (quizás con pares de confianza), así como el despliegue de transportes más flexibles y anónimos.

Es algo ambiguo comparar Tor e I2P por tamaño. Tor tiene más de 200 veces más usuarios: más de dos millones para Tor frente a «decenas de miles» para I2P . Sin embargo, según se informa, el 95% de los usuarios de I2P enrutan el tráfico de los demás, y solo hay alrededor de 6300 relés Tor . Además, mientras que Tor es posiblemente más grande, quizás I2P sea más difícil de comprometer , ya que los túneles I2P son unidireccionales y están enrutados de forma independiente, mientras que los circuitos Tor son bidireccionales.

Otro problema es que los desarrolladores de I2P son en su mayoría anónimos , mientras que Tor Project no lo es. Podría decirse que eso reduce el riesgo de que sean presionados. Pero también significa que no tenemos ni idea de quiénes son. Así que no hay más base para confiar en ellos que para confiar en el Proyecto Tor. Y tanto el software I2P como el Tor son de código abierto.

En pocas palabras, al igual que con Tor, conectarse directamente a la red I2P es posiblemente demasiado arriesgado. Y al igual que con Tor, es prudente conectarse a través de cadenas VPN anidadas.

Pero aquí está la cuestión: eso es más complicado con I2P.

I2P funciona mejor cuando los pares pueden conectarse a su nodo, porque entonces no solo está utilizando túneles que su nodo construye para los pares. Y eso requiere permitir conexiones TCP y UDP entrantes al puerto de acceso a Internet de su nodo . Cuando se está conectando a través de su enrutador de banda ancha, puede configurar fácilmente el reenvío de puertos a través de su interfaz WebGUI.

Cuando se conecta a través de un servicio VPN, el puerto I2P debe estar abierto en el servidor VPN y reenviado a su computadora. Sin embargo, muchos servicios de VPN configurarán el reenvío de puertos para sus usuarios.

Para que un nodo I2P (también conocido como enrutador) se conecte a sus pares, debe conocer (entre otros datos) sus direcciones IP. Los enrutadores cargan su información de contacto en una base de datos distribuida (netDb) que la pone a disposición de otros enrutadores. Y también pueden actualizar netDb según sea necesario y marcar su información de contacto como modificada.

Sin embargo, los enrutadores no buscan necesariamente actualizaciones de nedDb con mucha frecuencia . Verifican con frecuencia al inicio, pero solo hasta que tengan información sobre suficientes enrutadores accesibles.

Siempre que la dirección IP de salida de la VPN de su nodo sea estable, esto debería funcionar lo suficientemente bien. Pero si cambia con demasiada frecuencia, los pares podrían volverse menos accesibles al nodo.

Cadenas VPN anidadas

Como se señaló anteriormente, no puede confiar en los servicios VPN individuales para ocultar nada. El enrutamiento de varios saltos ayuda a proteger contra los adversarios. Pero en resumen, está atascado confiando en el proveedor, al igual que de otra manera estaría confiando en su ISP.

Y no es mejor si ejecuta su propia VPN. Simplemente estaría atascado confiando en el centro de datos que aloja su VPS o servidor, y el ISP que proporciona conectividad a Internet. Además, probablemente sea el único usuario de la VPN, y eso simplifica enormemente el análisis del tráfico.

Sin embargo, al igual que con Tor e I2P, puede reducir el riesgo de compromiso distribuyendo información y confianza entre múltiples servicios VPN. Es decir, puede utilizar cadenas anidadas. Al igual que con los circuitos Tor y los túneles I2P, cada VPN de la cadena solo ve de dónde proviene el tráfico y hacia dónde se dirige. Entonces, para ubicarlo e identificarlo, y asociarlo con su actividad en línea, los adversarios necesitarían datos de la mayoría o de todas las VPN de su cadena. En mi experiencia, las cadenas anidadas con 4-5 servicios VPN funcionan de manera confiable. Y eliminar el anonimato de tales cadenas VPN anidadas podría decirse que requeriría un esfuerzo considerable.

Las máquinas virtuales (VM) son esenciales para esto, porque puede crear entornos aislados para diferentes propósitos. Este es otro aspecto de la compartimentación (que cubriré completamente en [Cómo ser realmente anónimo en línea]). Qubes es posiblemente la opción de compartimentación más segura. Sin embargo, existen requisitos de hardware restrictivos, y podría decirse que es excesivo, a menos que sea un objetivo de adversarios ingeniosos.

Con VirtualBox, puede crear máquinas virtuales de enrutador para servicios VPN, Tor e I2P. Y al conectar en cadena las máquinas virtuales del enrutador, puede enrutar el tráfico a través de Internet como desee. También puede crear varias máquinas virtuales de estaciones de trabajo. Entonces, cada una de sus personas tendría su propia máquina virtual de estación de trabajo. Y cada una de esas máquinas virtuales llegaría a Internet a través de su propia cadena de enrutamiento.

Para una mayor privacidad, normalmente utilizaría algún tipo de Linux o BSD en las máquinas virtuales de su estación de trabajo. Pero también puedes usar Windows, Android o incluso (con algo de esfuerzo) MacOS. La diversidad también protege contra una vulnerabilidad perniciosa: la toma de huellas digitales WebGL.

Básicamente, la huella digital de WebGL depende del hardware de gráficos del host y también del controlador de gráficos de la VM. Entonces, si tiene máquinas virtuales Debian y Ubuntu ejecutándose en el mismo host, los navegadores en ambos tendrán la misma huella digital de WebGL. Eso es porque usan el mismo controlador de gráficos virtuales y el mismo hardware de gráficos.

Por las mismas razones, eso también es cierto para dos máquinas virtuales Centos, dos máquinas virtuales TrueOS (FreeBSD), dos máquinas virtuales Windows, dos máquinas virtuales MacOS, etc. Sin embargo, para cualquiera de esos tipos de sistema operativo (SO), las máquinas virtuales en diferentes hosts tendrán diferentes huellas digitales de WebGL. Y en un host determinado, cada tipo de sistema operativo también tendrá una huella digital WebGL diferente. Aun así, es probable que esté lo suficientemente seguro al ejecutar varias máquinas virtuales con un tipo de sistema operativo determinado, siempre que deshabilite WebGL en los navegadores.

Es fundamental tener en cuenta que la máquina host es necesariamente la más confiable. Las máquinas virtuales (también conocidas como invitados) no están protegidas en absoluto de las máquinas host. Son solo software, alterar todo. Y a la inversa, las máquinas host están relativamente bien protegidas de las máquinas virtuales. Entonces, dado eso, las máquinas host deben estar protegidas de Internet . Y es arriesgado usarlos para cualquier cosa, excepto para ejecutar máquinas virtuales.

Al igual que con las máquinas en general, agregar un firewall / enrutador VM hace que la VM del espacio de trabajo sea menos confiable, creando una DMZ entre ella e Internet. Pero aun así, las máquinas virtuales siempre son menos confiables que las máquinas host.

Además, existen vulnerabilidades que pueden pasar de las máquinas virtuales al host. Entonces, si está haciendo algo particularmente dudoso, como jugar con malware o salir con personas que juegan con malware, es mejor aislar esas VM en un host diferente.

De todos modos, hace algunos años, escribí una serie de guías sobre el uso de cadenas VPN anidadas y Tor. Esas guías emplean redes internas de VirtualBox de máquinas virtuales de enrutador pfSense, cada una de las cuales sirve como puerta de enlace para un servicio VPN. Básicamente, el reenvío NAT recursivo crea cadenas VPN anidadas. Para Tor, las guías recomiendan usar Whonix. Whonix consta de dos máquinas virtuales Debian, una máquina virtual de puerta de enlace Tor y una máquina virtual de estación de trabajo con navegador Tor y otras aplicaciones.

Aunque sigo usando ese enfoque, las guías se han vuelto algo desactualizadas y las revisaré pronto, después de terminar esta serie de publicaciones. En particular, incorporaré la opción de incluir enrutadores de hardware que ejecuten pfSense, que ya he cubierto en una guía independiente .

También agregaré la opción de cambiar las cadenas de VPN periódicamente, como con los circuitos Tor y los túneles I2P. Siempre quise hacer eso, pero nunca descubrí cómo coordinar la actividad de múltiples VM pfSense. Sin embargo, recientemente lo logré haciendo enrutamiento dinámico y reenvío NAT dentro de una sola máquina virtual de enrutador Debian. Existen reglas de enrutamiento que dirigen una VPN a través de otra y reglas de iptables que restringen el tráfico a la cadena. Entonces, incluso si una cadena falla parcial o completamente, no habrá DNS ni fugas de tráfico. Solo hay una breve interrupción en el tráfico.

Este enfoque con cadenas VPN anidadas dinámicas posiblemente proporciona un mejor anonimato que el enfoque que utiliza máquinas virtuales pfSense como puertas de enlace VPN. Porque la cadena cambia periódicamente, quizás cada pocos minutos, en lugar de permanecer estática. Y funciona con la misma facilidad con Whonix. Además, aunque requiere un tedioso masaje de los archivos de configuración de OpenVPN, en general es menos complicado que configurar varias máquinas virtuales pfSense. Si bien cada cliente OpenVPN no está compartimentado en una máquina virtual separada, puede conectar en cadena múltiples máquinas virtuales de enrutador Debian, cada una con una cadena VPN dinámica corta.

Al igual que con el enfoque pfSense, debe usar un servicio VPN diferente para cada nivel de la cadena anidada . Si lo desea, puede usar constantemente el mismo primer y último servidor VPN en sus cadenas, porque eso puede atraer menos atención. Y puede seleccionar VPN de salida que los sitios no suelen bloquear.

Incluso podría incluir Perfect Privacy con NeuroRouting activado, tal vez utilizando una máquina virtual de puerta de enlace pfSense. Y quizás incluso combinado con cadenas VPN anidadas dinámicas locales. Eso le proporcionaría el enrutamiento de Internet que cambia de manera bastante compleja.

Aunque no entraré en detalles aquí, actualizaré esta publicación después de revisar las guías de IVPN y quizás trasladar los detalles de implementación a GitHub.

Aun así, no importa cómo enrutes tu tráfico, es fundamental tener en cuenta que los adversarios con capacidad de intercepción a escala global pueden identificar y localizar puntos finales de tráfico. Siempre que un adversario controle un extremo de una conexión, por ejemplo, un sitio al que se conecta o un dispositivo que se conecta a su sitio, puede crear patrones de tráfico únicos. Y luego puede buscar intercepciones disponibles, buscando esos patrones.

Las intercepciones generalmente capturan el tráfico entre las diversas redes que componen Internet. Entonces, una vez que el adversario identifica una red de origen y / o destino a gran escala para su tráfico, puede buscar intercepciones de tráfico entre partes de esa red. Al profundizar en la jerarquía de enrutamiento, eventualmente puede encontrar su ISP. Y si tiene intercepciones internas de ese ISP, eventualmente puede encontrarlo. O bien, obtenga los datos necesarios del ISP.

Sin embargo, podría decirse que eso no es algo que incluso la NSA hará por cada cobarde anónimo.

Posibilidades para teléfonos inteligentes

Muchos servicios de VPN proporcionan clientes para Android e iOS. Y el navegador Tor finalmente está disponible para Android. Eso nunca sucederá para iOS, porque solo permite el código Safari.

Alternativamente, existe la esperada aplicación Orchid para Android (y quizás pronto para iOS). Es una red VPN de múltiples proveedores, con enrutamiento dinámico de múltiples saltos y selección de ruta basada en la reputación. Los usuarios compran ancho de banda con criptomonedas supuestamente anónimas basadas en Etherium.

Orchid puede proporcionar privacidad y anonimato que es al menos comparable a las cadenas VPN anidadas de bricolaje, y quizás comparable a Tor. En el sentido de que está distribuyendo información y confianza entre varios proveedores, a quienes se les paga de forma anónima. Y obviamente es mucho menos trabajo que las cadenas VPN anidadas. Pero al igual que con Tor, existe la desventaja de confiar en un sistema complejo, que probablemente no comprenderá bien.

Sin embargo, los teléfonos inteligentes actuales son tan terriblemente inseguros que se podría decir que el uso de tales herramientas proporciona simplemente una ilusión de seguridad, privacidad y anonimato. Pero hay esperanza. Con Librem 5 o PinePhone , puede ejecutar una distribución de Linux móvil y asegurar la conexión a Internet . Básicamente, matas la conectividad celular y WiFi del dispositivo y usas un enrutador WiFi conectado a Ethernet, o posiblemente incluso un módem LTE conectado.

Dado Linux en hardware seguro, puede usar algunos de los enfoques, discutidos anteriormente, para una privacidad sólida y anonimato. Sin embargo, no puede simplemente instalar cualquier distribución de Linux en teléfonos inteligentes. Esto se debe a que Linux se desarrolló para CPU x86-64 de Intel y AMD, mientras que los SoC de teléfonos inteligentes tienen núcleos de CPU ARM. Tanto el SoC Librem 5 como el PinePhone tienen cuatro núcleos Cortex A53 de 64 bits.

Y entonces todo debe compilarse para ARM, después de ajustar el código fuente. Eso es mucho trabajo y los desarrolladores todavía están lidiando con lo básico. Aunque muchas computadoras de placa única (como la Raspberry Pi) también tienen núcleos ARM, hay suficientes diferencias que no podemos usar aplicaciones creadas para ellas. Pero al menos sabemos que es factible.

Una limitación es clara: estos SoC ARM no admiten la virtualización . Entonces, si desea compartimentar las puertas de enlace VPN y Tor desde su espacio de trabajo, necesitará usar enrutadores conectados a Ethernet. Eso sería más cosas para cargar. Pero con enrutadores pequeños, en algún tipo de estuche adjunto, básicamente solo tendrías un teléfono más grueso.

Además, parece que puede arrancar el PinePhone de forma dual, al menos, cambiando la tarjeta SD . Por lo tanto, podría compartimentar personas en diferentes tarjetas SD y usar una configuración de anonimización diferente para cada una.

No puedo escribir nada confiable sobre teléfonos inteligentes con ARM SoC hasta que tenga uno. Entonces, por ahora, solo sugeriré posibilidades.  Si logro conseguir uno sin arruinar mi tapadera, lo expandiré a una guía completa.

Parece que Ubuntu Touch incluye OpenVPN, que puede configurar en la terminal . Sin embargo, como era de esperar, también parece tener administrador de red. Y eso probablemente será problemático, para hacer algo elegante con las VPN. Por lo que puede ser necesario deshabilitar el administrador de red.

Veo que muchos usuarios están solicitando el navegador Tor en Ubuntu Touch. Pero los desarrolladores dicen que «no se ve como un objetivo central» . Sin embargo, hace algunos años logré compilar el navegador Tor para Raspberry Pi, así que estoy bastante seguro de que es factible. Después de todo, Tor Project lo ha administrado para Android en ARM SoC.

Pero hay al menos 25 distribuciones móviles de Linux y BSD en desarrollo para PinePhone. Ahora no tengo la paciencia para investigarlos todos para el navegador OpenVPN y Tor. Y también está el hecho de que las cosas están cambiando totalmente.

  • SO AOSC
  • Armbiano
  • Batocera Linux
  • DietPi
  • EndurecidoBSD
  • KDE Neon
  • Lakka
  • LuneOS
  • LibreELEC
  • Maemo Leste
  • Manjaro
  • NEMS Linux
  • NetBSD
  • SiguienteCloudPi
  • OpenBSD
  • OpenHAB
  • Abrir Media Vault
  • Plasma Mobile
  • PostmarketOS
  • Q4OS
  • Recalbox
  • Arena retro
  • SailfishOS
  • Fundación UBPorts
  • Volumio

Servicios VPN

Si su distribución de Linux móvil incluye OpenVPN, puede usar cualquier servicio VPN basado en OpenVPN: one-hop, multi-hop o Perfect Privacy con NeuroRouting. Incluso podría usar Orchid, una vez que lancen una aplicación para Linux en núcleos Cortex A53 de 64 bits.

Es crucial tener reglas de iptables que eviten que el tráfico pase por alto el túnel VPN. Si su distribución de Linux móvil incluye el paquete iptables-persistent, es el enfoque más sencillo. Primero instálalo:

# apt -y install iptables-persistent

A menos que necesite IPv6, es mejor bloquearlo. Edita el conjunto de reglas de IPv6 de esta manera:

# nano /etc/iptables/rules.v6
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
COMMIT


Y luego recargarlo:

# ip6tables-restore < /etc/iptables/rules.v6

Es probable que la interfaz del túnel VPN lo sea tun0. Y la interfaz LAN probablemente será enp0s3, o eth0en versiones anteriores. Pero verifique:

# ip a

Obtenga también la dirección IP del servidor VPN:

# netstat -natp | grep -e "Proto" -e "openvpn"

Luego, cree un conjunto de reglas de iptables que permita la salida a través de la interfaz LAN solo al servidor VPN (wxyz), con todo lo demás usando el túnel VPN:

# nano /etc/iptables/vpn-rules.v4
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -j ACCEPT
-A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A OUTPUT -o enp0s3 -d w.x.y.z -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
-A OUTPUT -j DROP
COMMIT


Y luego cargue el conjunto de reglas de VPN:

# iptables-restore < /etc/iptables/vpn-rules.v4

Siempre que reinicie el dispositivo, se cargarán las reglas de iptables predeterminadas (rules.v4 y rules.v6). Por lo tanto, deberá cargar el conjunto de reglas de VPN.

Cadenas VPN anidadas

Dado openvpn, también puede implementar cadenas VPN anidadas , ya sean estáticas o dinámicas. Puede hacerlo en el propio teléfono o en un enrutador separado, que es más seguro. De esa manera, las aplicaciones explotadas no pueden eludir fácilmente la cadena VPN y llamar a casa.

Antes de implementar cadenas VPN anidadas en el teléfono, es probable que deba deshabilitar el administrador de red, porque de lo contrario interferiría. También querrá instalar iptables-persistent y bloquear el tráfico IPv6, como se describe anteriormente para los servicios VPN.

También deberá eliminar las reglas de reenvío de vpn-rules-base.v4. Para cadenas con dos servicios VPN, usaría esto:

# nano /etc/iptables/vpn-rules-base.v4
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -j ACCEPT
-A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A OUTPUT -o enp0s3 -d VPN0 -j ACCEPT
-A OUTPUT -o tun0 -d VPN1 -j ACCEPT
-A OUTPUT -o tun1 -j ACCEPT
-A OUTPUT -j DROP
COMMIT


Tenga en cuenta que
VPN0y VPN1son simplemente marcadores de posición. Los scripts utilizan el archivo para crear el conjunto de reglas de iptables real, para una combinación determinada de servidores VPN. Probé esto en una VM Debian, por lo que debería funcionar en distribuciones de Linux móviles que incluyan openvpn.

Navegador Tor

Si su distribución de Linux móvil incluye el navegador Tor, la instalación es muy fácil . Simplemente descarga y extrae el archivo donde quieras. Luego abra una terminal en la carpeta tor-browser_ [locale] y ejecute ./start-tor-browser.desktop --register-apppara agregar el navegador Tor al menú de aplicaciones.

Si el navegador Tor no está disponible, puede compilarlo desde la fuente. Pero eso es más de lo que quiero entrar aquí.

En cualquier caso, existen limitaciones y vulnerabilidades:

  • el cliente Tor se ejecuta solo mientras el navegador Tor se está ejecutando
  • otras aplicaciones no están configuradas para usar Tor
  • no hay protección contra aplicaciones que eludan Tor

Puedes configurar otras aplicaciones para usar Tor, generalmente usando el paquete torsocks.

Normalmente, uno usaría iptables para bloquear todo el tráfico saliente, excepto el del cliente Tor. Sin embargo, eso requiere que el cliente Tor se ejecute como su propio usuario, como debian-tor. Y el navegador Tor ejecuta el cliente Tor como usuario de inicio de sesión.

Pero si su distribución de Linux móvil incluye el paquete iptables-persistent, existe una solución alternativa, aunque algo burda y frágil. Primero instale iptables-persistent y bloquee el tráfico IPv6, como se describe anteriormente para los servicios VPN.

Luego, después de instalar e iniciar el navegador Tor, verifique a qué relés se está conectando el cliente Tor:

# netstat -natp | grep -e "Proto" -e "tor" | grep -v "127.0.0.1"

Probablemente verá hasta seis direcciones IP extranjeras (abcd, efgh, etc.), que son retransmisiones Tor. Luego cree un conjunto de reglas IPv4 de iptables que permita la salida solo a esos relés Tor:

# nano /etc/iptables/tor-rules.v4
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -j ACCEPT
-A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A OUTPUT -d a.b.c.d -j ACCEPT
-A OUTPUT -d e.f.g.h -j ACCEPT
...
-A OUTPUT -j DROP
COMMIT


Y luego carga las reglas de Tor:

# iptables-restore < /etc/iptables/tor-rules.v4

El navegador Tor aún debería funcionar, pero ninguna otra aplicación debería llegar a Internet.

Siempre que reinicie el dispositivo, se cargarán los conjuntos de reglas de iptables predeterminados (rules.v4 y rules.v6). Entonces querrás cargar tor-rules.v4 antes de usar el navegador Tor. Si el protector de entrada que eligió el navegador Tor se vuelve inaccesible, deberá agregar el nuevo a su conjunto de reglas de Tor. Simplemente cargue el conjunto de reglas IPv4 predeterminado:

# iptables-restore < /etc/iptables/rules.v4

Con el navegador Tor ejecutándose, vea a qué retransmisores se está conectando el cliente Tor:

# netstat -natp | grep -e "Proto" -e "tor" | grep -v "127.0.0.1"

Y luego agrega los nuevos a tu conjunto de reglas de Tor.

Navegador VPN + Tor

También es bastante fácil enrutar el navegador Tor a través de una VPN. Si está ejecutando un solo cliente VPN, es probable que la interfaz del túnel VPN lo sea tun0. Y la interfaz LAN probablemente será enp0s3, o eth0en versiones anteriores. Pero verifique:

# ip a

Obtenga también la dirección IP del servidor VPN:

# netstat -natp | grep -e "Proto" -e "openvpn"

Primero instale iptables-persistent, bloquee el tráfico IPv6 y haga funcionar el servicio VPN, como se describe arriba. Luego, después de instalar e iniciar el navegador Tor, determine a qué relés se está conectando el cliente Tor, como se describió anteriormente.

Luego, cree un conjunto de reglas de iptables que permita la salida solo al servidor VPN (wxyz) a través de la interfaz LAN, y solo a los relés Tor (abcd, efgh, etc.) a través del túnel VPN:

# nano /etc/iptables/vpn-tor-rules.v4
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -j ACCEPT
-A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A OUTPUT -o enp0s3 -d w.x.y.z -j ACCEPT
-A OUTPUT -o tun0 -d a.b.c.d -j ACCEPT
-A OUTPUT -o tun0 -d e.f.g.h -j ACCEPT
...
-A OUTPUT -j DROP
COMMIT


Y luego cargue el conjunto de reglas VPN + Tor:

# iptables-restore < /etc/iptables/vpn-tor-rules.v4

Siempre que reinicie el dispositivo, se cargarán las reglas de iptables predeterminadas (rules.v4 y rules.v6). Por lo tanto, deberá cargar el conjunto de reglas de VPN + Tor. Si el protector de entrada que eligió el navegador Tor se vuelve inalcanzable, deberá agregar el nuevo al conjunto de reglas VPN + Tor. Simplemente cargue el conjunto de reglas IPv4 predeterminado:

# iptables-restore < /etc/iptables/rules.v4

Con el navegador Tor ejecutándose, vea a qué retransmisores se está conectando el cliente Tor:

# netstat -natp | grep -e "Proto" -e "tor" | grep -v "127.0.0.1"

Y luego agregue los nuevos al conjunto de reglas VPN + Tor, y cárguelo:

# iptables-restore < /etc/iptables/vpn-tor-rules.v4

Cadenas VPN anidadas + navegador Tor

También puede enrutar el navegador Tor a través de cadenas VPN anidadas . Si usa un enrutador separado (que es más seguro), puede configurarlo como se describe.

Si desea tener todo en el teléfono, primero haga que las cadenas VPN anidadas funcionen en el teléfono, como se mencionó anteriormente. Luego, después de instalar e iniciar el navegador Tor, determine a qué relés se está conectando el cliente Tor, como se describió anteriormente.

Luego, detenga el navegador Tor y las cadenas VPN anidadas, y modifique vpn-rules-base.v4 para permitir solo la salida a los relés Tor (abcd, efgh, etc.) a través de tun1:

# nano /etc/iptables/vpn-rules-base.v4
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -j ACCEPT
-A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A OUTPUT -o enp0s3 -d VPN0 -j ACCEPT
-A OUTPUT -o tun0 -d VPN1 -j ACCEPT
-A OUTPUT -o tun1 -d a.b.c.d -j ACCEPT
-A OUTPUT -o tun1 -d e.f.g.h -j ACCEPT
...
-A OUTPUT -j DROP
COMMIT


Tenga en cuenta que
VPN0y VPN1son simplemente marcadores de posición. Los scripts utilizan el archivo para crear el conjunto de reglas de iptables real, para una combinación determinada de servidores VPN.

Inicie cadenas de VPN anidadas y, una vez que esté funcionando, el navegador Tor.

Whonix

En teoría, podría configurar un enrutador intermedio (entre el módem y el teléfono) como una puerta de enlace Whonix y el teléfono inteligente como una estación de trabajo Whonix. En la configuración de Whonix , no se permite el reenvío en el enlace Ethernet entre la puerta de enlace Tor y la estación de trabajo. La puerta de enlace solo expone Tor SocksPorts para la estación de trabajo. No es solo un proxy Tor transparente. Eso obliga a las aplicaciones en la estación de trabajo a usar Tor correctamente y evita que pasen por alto Tor. Además, si la estación de trabajo se ve comprometida por un malware, no podrá fsck fácilmente con el cliente Tor.

Los desarrolladores de Whonix proporcionan instrucciones para instalar la puerta de enlace Whonix en la Raspberry Pi 3B . Algo así probablemente funcionaría para pequeños enrutadores basados ​​en ARM. O simplemente podría usar un Pi 3B.

Alternativamente, puede usar dos enrutadores intermedios, el primero que se conecta a través de cadenas VPN anidadas y el segundo como una puerta de enlace Whonix. Pero luego tendrías tres pequeñas cajas, además del teléfono inteligente (el módem y dos enrutadores). Supongo que podrías hacer un estuche simple y sujetarlo con velcro al teléfono.

El mismo enfoque supuestamente también funciona para la estación de trabajo Whonix, por lo que tal vez pueda instalarlo en su teléfono inteligente. Sin embargo, tengo la impresión de que los ARM SoC de los teléfonos inteligentes son más idiosincrásicos que los sistemas ARM aleatorios, por lo que es una posibilidad remota.

La estación de trabajo Whonix es mucho más fácil de usar, y posiblemente mucho más segura, que una distribución aleatoria de Linux con el navegador Tor y otras aplicaciones torificadas, que simplemente se ha configurado para usar una puerta de enlace Tor separada.

Los desarrolladores de Whonix recomiendan no instalar la estación de trabajo Whonix directamente en el hardware, dado que “las series de hardware serían visibles” para el sistema. Sin embargo, no puedo imaginar cómo sería peor que simplemente ejecutar el navegador Tor en el teléfono.

Esta publicación es parte de la serie de Guías de privacidad avanzadas en curso  .

Deja un comentario