Filtración de IP por WebRTC: qué es y cómo prevenirla

Introducción

WebRTC es una tecnología del navegador que permite la comunicación en tiempo real: videollamadas, chat de voz, compartición de archivos peer-to-peer. Para establecer estas conexiones, los navegadores usan el protocolo ICE (Interactive Connectivity Establishment), que recopila direcciones de interfaces de red y las intercambia con los pares. El problema es que ICE recopila tus direcciones IP reales, incluyendo IPs de red local y tu IP pública, y las hace disponibles a través de JavaScript. Esto ocurre fuera de la ruta normal del proxy HTTP, lo que significa que un proxy por sí solo no te protege.

BotBrowser controla el comportamiento ICE de WebRTC a nivel del motor del navegador. En lugar de deshabilitar WebRTC por completo (lo cual es en sí mismo una señal detectable), BotBrowser asegura que los candidatos ICE solo contengan direcciones IP consistentes con tu identidad de proxy.

Impacto en la privacidad

Las filtraciones de IP por WebRTC son una de las brechas de privacidad más conocidas en la tecnología de navegadores. Cuando una página web inicia una conexión peer WebRTC, el navegador recopila candidatos ICE de cada interfaz de red disponible. Estos candidatos contienen:

• Direcciones IP locales: La IP privada de tu máquina en la red local (p.ej., 192.168.1.100)
• Dirección IP pública: Tu IP pública real de las respuestas del servidor STUN
• Direcciones IPv6: Si están disponibles, tu dirección IPv6 completa

Un sitio web puede recopilar estos candidatos a través de la API RTCPeerConnection sin ninguna interacción del usuario ni solicitudes de permisos. Incluso si enrutas todo el tráfico HTTP a través de un proxy, las solicitudes STUN de WebRTC viajan directamente al servidor STUN, revelando tu IP pública real.

Esto crea un camino directo a la des-anonimización. Un sistema de rastreo que ve tu IP de proxy en las solicitudes HTTP pero tu IP real en los candidatos WebRTC sabe exactamente lo que está pasando. La inconsistencia en sí misma es una señal fuerte.

Contexto técnico

Cómo funciona la recopilación de candidatos ICE

Cuando JavaScript crea un RTCPeerConnection, el navegador comienza a recopilar candidatos ICE. Este proceso implica:

1. Candidatos host: El navegador enumera las interfaces de red locales y recopila sus direcciones IP. Estos se convierten en candidatos "host".

2. Candidatos server-reflexive: El navegador envía solicitudes STUN (Session Traversal Utilities for NAT) binding a servidores STUN configurados. El servidor STUN responde con la dirección IP pública que observa, creando candidatos "srflx".

3. Candidatos relay: Si se configuran servidores TURN (Traversal Using Relays around NAT), el navegador establece rutas de relay a través de ellos, creando candidatos "relay".

Cada tipo de candidato expone diferente información de red. Los candidatos host revelan IPs locales. Los candidatos server-reflexive revelan tu IP pública. La combinación de los tres proporciona un mapa detallado de tu topología de red.

Por qué las extensiones no pueden resolver esto completamente

Las extensiones de navegador que intentan controlar WebRTC tienen limitaciones fundamentales:

• Deshabilitar WebRTC por completo previene la recopilación ICE pero crea una huella digital detectable. Los sitios pueden verificar la ausencia de RTCPeerConnection y marcarla.
• Bloquear solicitudes STUN a nivel de extensión puede perder solicitudes iniciadas antes de que la extensión se cargue o desde service workers.
• Modificar candidatos ICE mediante monkey-patching de JavaScript es frágil. Los candidatos reales se generan en código nativo antes de que JavaScript tenga la oportunidad de interceptarlos.

El control a nivel de motor es el único enfoque que puede modificar la generación de candidatos ICE en el origen, antes de que cualquier JavaScript en la página pueda observar los valores originales.

Enfoques comunes y sus limitaciones

Deshabilitar WebRTC en la configuración del navegador

Algunos navegadores permiten deshabilitar WebRTC a través de flags (p.ej., media.peerconnection.enabled en Firefox). Esto detiene toda la recopilación ICE pero también rompe las funciones legítimas de WebRTC como videoconferencia. Más importante aún, la ausencia de APIs WebRTC es una señal de huella digital distintiva. Un navegador que carece de RTCPeerConnection se destaca.

Extensiones de control WebRTC

Las extensiones como WebRTC Leak Prevent o uBlock Origin pueden restringir WebRTC a ciertos rangos de IP. Sin embargo, las extensiones operan en la capa JavaScript después de que el motor del navegador ya ha recopilado los candidatos. Pueden interceptar el callback onicecandidate, pero los candidatos originales existen en memoria. Algunos enfoques de extensiones también crean efectos secundarios detectables: cadenas de prototipos modificadas, patrones de temporización alterados o propiedades faltantes en el objeto RTCPeerConnection.

Protección a nivel de VPN

Una VPN enruta todo el tráfico del sistema, incluyendo solicitudes STUN, a través del túnel VPN. Esto evita que el servidor STUN vea tu IP real. Sin embargo, las VPNs no controlan los candidatos ICE locales (host). Tu IP de red local (p.ej., 192.168.x.x) aún se recopila y expone. Para algunos escenarios de rastreo, las IPs locales contribuyen a un identificador estable.

El enfoque a nivel de motor de BotBrowser

BotBrowser modifica la generación de candidatos ICE dentro del stack de red de Chromium. Esto es fundamentalmente diferente de todos los enfoques anteriores:

• WebRTC permanece completamente funcional. RTCPeerConnection existe y funciona normalmente.
• Los candidatos ICE se generan con información de IP controlada desde el inicio.
• No existen modificaciones visibles a JavaScript en los objetos WebRTC.
• El comportamiento STUN/TURN se controla a nivel de red, no se intercepta después del hecho.

El enfoque de BotBrowser

El flag --bot-webrtc-ice

El flag --bot-webrtc-ice de BotBrowser (ENT Tier1) controla qué servidores ICE se usan y qué información de IP aparece en los candidatos:

# Usar el servidor STUN de Google (preset)
chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-webrtc-ice="google"

# Usar servidores STUN y TURN personalizados
chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-webrtc-ice="custom:stun:stun.example.com:3478,turn:turn.example.com:3478"

El preset google configura stun:stun.l.google.com:19302, que es la configuración STUN más comúnmente observada en navegadores Chrome regulares.

Cómo funciona junto con proxies

Cuando se combina con --proxy-server, BotBrowser asegura que:

1. Las solicitudes STUN se enrutan a través del proxy, por lo que el servidor STUN ve la IP del proxy
2. Los candidatos ICE contienen solo la IP del proxy como dirección pública
3. Las IPs de red local no aparecen en los candidatos host
4. La huella digital WebRTC coincide con lo que produciría un usuario normal detrás de ese proxy

UDP sobre SOCKS5 (ENT Tier3)

Para usuarios ENT Tier3, BotBrowser soporta SOCKS5 UDP ASSOCIATE. Esto tuneliza el tráfico QUIC y los sondeos STUN sobre el proxy SOCKS5 automáticamente cuando el proxy soporta UDP:

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080"

No se necesitan flags adicionales. Si el proxy SOCKS5 soporta UDP ASSOCIATE, BotBrowser tuneliza el tráfico STUN a través de él automáticamente.

Configuración WebRTC vía perfil

El comportamiento WebRTC también puede controlarse a través de la configuración del perfil:

# Usar configuración WebRTC definida por el perfil
chrome --bot-profile="/path/to/profile.enc" \
       --bot-config-webrtc=profile

# Deshabilitar WebRTC por completo (no recomendado para consistencia)
chrome --bot-profile="/path/to/profile.enc" \
       --bot-config-webrtc=disabled

La configuración profile usa la configuración WebRTC que define el perfil. La configuración disabled desactiva WebRTC, pero esto crea una señal detectable y solo debería usarse cuando la funcionalidad WebRTC genuinamente no es necesaria.

Configuración y uso

Configuración completa de privacidad (CLI)

Combina la protección WebRTC con proxy, DNS y configuración de huella digital:

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-webrtc-ice="google" \
       --bot-local-dns \
       --bot-config-timezone="America/New_York" \
       --bot-config-locale="en-US"

Integración con Playwright

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--proxy-server=socks5://user:pass@proxy:1080',
      '--bot-webrtc-ice=google',
      '--bot-local-dns',
    ],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Integración con Puppeteer

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--proxy-server=socks5://user:pass@proxy:1080',
      '--bot-webrtc-ice=google',
      '--bot-local-dns',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Verificación

Después de lanzar BotBrowser con protección WebRTC:

1. Visita un sitio de prueba de filtraciones WebRTC (como browserleaks.com/webrtc)
2. Verifica que no aparezcan direcciones IP locales (192.168.x.x, 10.x.x.x) en los candidatos ICE
3. Verifica que solo la IP del proxy aparezca como dirección pública
4. Confirma que tu IP pública real no sea visible en ningún candidato
5. Prueba que las funciones WebRTC aún funcionen (la API debería estar presente y funcional)

También puedes verificar programáticamente:

const candidates = await page.evaluate(() => {
  return new Promise((resolve) => {
    const ips = [];
    const pc = new RTCPeerConnection({
      iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
    });
    pc.createDataChannel('test');
    pc.onicecandidate = (e) => {
      if (e.candidate) {
        const match = e.candidate.candidate.match(/([0-9]{1,3}\.){3}[0-9]{1,3}/);
        if (match) ips.push(match[0]);
      } else {
        resolve(ips);
      }
    };
    pc.createOffer().then(o => pc.setLocalDescription(o));
  });
});
console.log('ICE candidate IPs:', candidates);

Mejores prácticas

1. Siempre combina --bot-webrtc-ice con --proxy-server. La protección WebRTC solo tiene sentido cuando enrutas el tráfico a través de un proxy. Sin proxy, tu IP real ya es visible en las solicitudes HTTP.

2. Usa el preset "google" a menos que tengas requisitos específicos. El servidor STUN de Google es la configuración más comúnmente observada y produce los candidatos ICE más naturales.

3. Añade --bot-local-dns para privacidad de red completa. WebRTC y DNS son las dos rutas de filtración de red más comunes. Cerrar ambas asegura una protección completa.

4. No deshabilites WebRTC a menos que sea absolutamente necesario. Deshabilitar WebRTC crea una señal de huella digital detectable. El enfoque controlado de BotBrowser mantiene WebRTC funcional mientras protege tu IP.

5. Prueba después de cada cambio de configuración. El comportamiento WebRTC depende de la interacción entre proxy, servidor ICE y configuración de red. Siempre verifica después de cambios.

Preguntas frecuentes

¿BotBrowser rompe las videollamadas WebRTC? No. WebRTC permanece completamente funcional. Las videollamadas, chat de voz y conexiones peer-to-peer funcionan normalmente. BotBrowser solo controla qué direcciones IP aparecen en los candidatos ICE.

¿Cuál es la diferencia entre --bot-webrtc-ice y --bot-config-webrtc? El flag --bot-webrtc-ice controla la configuración del servidor ICE y la exposición de IP. El flag --bot-config-webrtc controla si WebRTC usa configuración del perfil, configuración real del sistema o está deshabilitado por completo.

¿Necesito --bot-webrtc-ice si uso una VPN? Una VPN previene que los servidores STUN vean tu IP pública real, pero los candidatos host locales aún pueden estar expuestos. BotBrowser proporciona un control más completo sobre todos los tipos de candidatos.

¿Los sitios web pueden detectar que los candidatos ICE están siendo controlados? BotBrowser modifica la generación de candidatos a nivel del motor. Los candidatos ICE se ven idénticos a los producidos por un navegador detrás de un proxy con esa IP. No hay artefactos visibles a JavaScript.

¿Qué pasa con las filtraciones IPv6 a través de WebRTC? BotBrowser controla tanto la generación de candidatos IPv4 como IPv6. Las direcciones IPv6 de tus interfaces de red reales no aparecen en los candidatos ICE.

¿UDP sobre SOCKS5 requiere configuración especial del proxy? El proxy debe soportar SOCKS5 UDP ASSOCIATE (RFC 1928). BotBrowser detecta esta capacidad automáticamente. No se necesitan flags adicionales más allá de --proxy-server.

Resumen

Las filtraciones de IP por WebRTC son una preocupación significativa de privacidad que los proxies por sí solos no abordan. BotBrowser controla la generación de candidatos ICE a nivel del motor del navegador, asegurando que solo direcciones IP consistentes con el proxy aparezcan en los candidatos WebRTC mientras mantiene WebRTC completamente funcional.

Para una configuración completa de privacidad de red, combina la protección WebRTC con Configuración de proxy y Prevención de filtraciones DNS. Para gestionar múltiples identidades con diferentes configuraciones de red, consulta Aislamiento de navegador multi-cuenta.