Protección contra el sondeo de puertos del navegador en localhost

Una página web puede pedirle a tu navegador que abra una conexión hacia una dirección de tu propio equipo, y el navegador normalmente lo intentará. Si hay un servicio escuchando en ese puerto, el intento se completa o recibe una respuesta a nivel de protocolo. Si no hay nada escuchando, el intento es rechazado. Una página que repite el intento sobre un conjunto de puertos conocidos obtiene un patrón de puertos abiertos y cerrados, y ese patrón dice algo sobre el software que usas.

Las secciones siguientes siguen esa deducción desde un único intento de conexión hasta una señal estable del entorno local, comparan las soluciones habituales y el hueco que deja cada una, y después pasan a la protección de puertos de BotBrowser, que hace uniformes las respuestas. Terminan con una comprobación que puedes ejecutar en tu propio equipo y con una descripción clara de lo que la función no cubre.

Resumen

La protección de puertos de BotBrowser uniforma los sondeos iniciados por páginas hacia los puertos de bucle local documentados, mientras las herramientas locales siguen conectándose directamente. El alcance no incluye todos los puertos ni las direcciones de red privada, por lo que hay que comprobar la forma de dirección y el conjunto exacto antes de activarla.

Contenido

• Cómo una página mapea tus servicios locales
• Por qué el patrón te sigue de una sesión a otra
• Por qué las soluciones habituales se quedan cortas
• Cómo activar la protección de puertos
• Verificar resultados uniformes con un servicio de prueba local
• Qué soporta BotBrowser y qué queda fuera de su alcance
• Conclusión práctica

Cómo una página mapea tus servicios locales

Todo equipo tiene una interfaz de bucle local (loopback), que existe para que los programas del mismo equipo se comuniquen entre sí sin salir de él. El RFC 1122 reserva para ello todo el bloque 127.0.0.0/8, y el RFC 4291 define ::1 como la dirección de bucle local de IPv6. El nombre de host localhost normalmente se resuelve a una de ellas o a ambas. Los servicios pensados solo para el usuario local, como servidores de desarrollo, motores de bases de datos, ayudantes de escritorio remoto y herramientas de contenedores, suelen escuchar ahí porque la interfaz de bucle local no es accesible desde otros equipos.

El navegador, sin embargo, se ejecuta en el mismo equipo, así que el código de una página puede dirigirse a esos mismos puntos de conexión. Para ello no hace falta instalar ni aprobar nada en la página. La página lanza un intento de conexión corriente, por ejemplo mediante un WebSocket, la carga de una imagen o una llamada fetch, y luego observa cómo se resuelve ese intento. Los distintos resultados le dicen cosas distintas:

• Un servicio que acepta la conexión y responde de forma reconocible sugiere que en ese puerto se ejecuta un tipo concreto de software.
• Un servicio que acepta la conexión pero responde con algo que la página no entiende sigue mostrando que el puerto está abierto.
• Una conexión rechazada indica que no hay nada escuchando, y la forma en que llega el rechazo puede diferir de la forma en que termina una conexión aceptada.

Nada de esto lee datos del servicio local. La página solo averigua que un puerto se comporta de una manera u otra, y con suficientes puertos eso es una descripción sorprendentemente detallada de un equipo. Una página que comprueba unas pocas docenas de puertos conocidos suele poder distinguir si el visitante usa un entorno de desarrollo web, una base de datos, una herramienta de acceso remoto o una plataforma de contenedores.

Esto importa más allá del rastreo, porque muchos servicios locales se escriben suponiendo que solo los programas del mismo equipo pueden llegar a ellos. A menudo omiten el inicio de sesión, escuchan en un puerto conocido y exponen una interfaz HTTP sencilla. Una página que descubre que ese servicio existe ya ha ganado información, y una página que además puede enviarle solicitudes puede ganar más. Los navegadores han endurecido con los años las reglas entre orígenes, pero saber que un puerto está abierto exige mucho menos que leer una respuesta. Por eso el propio patrón de abierto frente a cerrado es lo que merece protección.

La propuesta Local Network Access del WICG describe este tipo de solicitudes, en las que una página servida desde un sitio público se dirige a direcciones locales y de bucle local, y propone que los navegadores las condicionen a un permiso. Es una especificación de la comunidad y su compatibilidad varía según el navegador y la versión, así que no des por hecho que tu navegador actual pregunta o bloquea. Comprueba qué hace tu propia versión antes de confiar en ello.

Por qué el patrón te sigue de una sesión a otra

Compara 127.0.0.1:3000 y 127.0.0.1:5432 en el mismo perfil; el resultado depende de los procesos del equipo, no de las cookies.

Las cookies, el almacenamiento local y la dirección IP son cosas que puedes borrar o cambiar. El conjunto de servicios que se ejecutan en tu ordenador es distinto, porque describe cómo trabajas y no desde dónde te conectas. Un desarrollador que usa cada día la misma integración del editor, la misma base de datos y el mismo entorno de contenedores presentará el mismo patrón el lunes y el viernes.

Esa estabilidad es lo que hace útil la señal para el rastreo. Piensa en las formas habituales de intentar empezar de cero:

• Borrar cookies y datos del sitio elimina el estado que un sitio guardó en tu navegador, pero no cambia qué puertos están abiertos.
• Cambiar de dirección IP, por ejemplo mediante un proxy, modifica la ubicación de red que ve el sitio, pero el patrón de bucle local pertenece al equipo y viaja con él.
• Abrir una ventana privada o un segundo perfil del navegador reinicia el estado del navegador, pero el mismo equipo responde de la misma manera.

La señal también se combina bien con otras. Un patrón de puertos abiertos y cerrados es un atributo más que puede unirse a la salida de canvas, a las fuentes disponibles y al resto de la superficie que recoge un script de huellas digitales. Cada atributo por separado es parcial, y juntos pueden singularizar un equipo, por lo que merece la pena cerrar incluso una señal débil. Para entender por qué una ventana privada deja estas señales sin cambios, consulta Por qué el modo incógnito no protege contra el fingerprinting, que compara paso a paso una sesión normal y una privada.

No todos los equipos están igual de expuestos. Un portátil que solo se usa para correo y documentos puede mostrar casi ningún puerto abierto, y su patrón se parece entonces al de muchos otros equipos. Una estación de trabajo o un servidor con una docena de servicios es mucho más distintivo. Quienes más ganan al tratar esta señal son los desarrolladores, los responsables de servidores sin interfaz gráfica y cualquiera que use herramientas de acceso remoto, porque esas configuraciones escuchan en más puertos que un equipo doméstico típico.

Por qué las soluciones habituales se quedan cortas

Aunque touch-action: none cambie los gestos táctiles, no cambia el resultado de una conexión a 127.0.0.1:3000.

Un ERR_BLOCKED_BY_CLIENT inmediato también es observable; compáralo con el tiempo de espera normal antes de elegir una regla.

Una página de prueba puede llamar a fetch() con AbortSignal.timeout(1000) contra http://127.0.0.1:3000/; el tiempo y la clase de error son la superficie observable.

Varios enfoques parecen razonables, y cada uno deja un hueco.

Bloquear sin más las conexiones de bucle local. Si el navegador rechaza todo intento de llegar a localhost, la página deja de saber qué servicio se ejecuta. Pero el propio rechazo pasa a ser un comportamiento observable. Un intento bloqueado puede verse distinto de un rechazo normal, y un fallo instantáneo idéntico en todos los puertos resulta extraño frente a la variación que muestra un navegador normal. Además, el bloqueo rompe cosas de las que puedes depender: aplicaciones de escritorio que se comunican con una página web, servidores de desarrollo con recarga en vivo y flujos de inicio de sesión que redirigen a un receptor local.

Extensiones del navegador. Los filtros de solicitudes pueden bloquear conexiones a direcciones locales, pero actúan en la capa de extensiones del navegador y la cobertura depende del tipo de solicitud. Una regla que gestiona llamadas fetch puede no cubrir todas las demás formas en que una página puede abrir una conexión. La propia extensión también puede dejar rastros observables por la página, de modo que la protección se convierte en otro atributo distintivo.

Reglas de cortafuegos. Los cortafuegos del sistema operativo deciden qué programas pueden aceptar conexiones entrantes o llegar a la red. Una conexión a localhost iniciada por una página es una conexión local desde el navegador, así que una regla pensada para el tráfico de internet no la resuelve. Una regla que impida al navegador llegar al bucle local volvería a romper las herramientas locales que quieres conservar y reintroduciría el problema de un rechazo distintivo.

Espacios de nombres de red y contenedores. Ejecutar el navegador en un contenedor con su propio espacio de nombres de red le impide ver los servicios del anfitrión, lo que sí separa ambos mundos. El coste es operativo: mantienes una capa adicional, no puedes llegar con facilidad a los servicios del anfitrión que sí quieres usar, y el contenedor expone su propio conjunto de servicios en escucha que una página puede sondear. Es una herramienta de aislamiento razonable para algunos despliegues y una respuesta pesada para este problema concreto.

Enrutamiento por VPN. Una VPN cambia por dónde sale el tráfico de internet. El tráfico de bucle local nunca sale del equipo, así que los cambios de enrutamiento no alteran cómo responde el navegador a un intento de conexión a 127.0.0.1. Añades un salto de red y algo de sobrecarga y dejas intacto el comportamiento real. Para saber cómo la ruta de red y el entorno de ejecución de la página deben describir una misma configuración, consulta Coherencia de red del navegador para proteger la privacidad, que explica una forma repetible de validar esa coherencia.

Lo que tienen en común estas opciones es que ninguna hace uniformes las respuestas. O eliminan la respuesta, algo que se nota y resulta molesto, o actúan en una capa que no ve la conexión. El objetivo que de verdad encaja con el problema es más acotado: cuando una página intenta conectar con un puerto de bucle local de los más sondeados, el resultado no debería depender de si hay un servicio escuchando. La resolución de nombres es una superficie aparte que ninguna de estas opciones aborda; consulta Prevención de fugas DNS: rutas de resolución, proxies y pruebas, que cubre las rutas de resolución y cómo ejecutar una prueba de fugas.

Cómo activar la protección de puertos

BotBrowser documenta la protección de puertos como una función PRO. Está desactivada de forma predeterminada y se activa con un indicador de arranque o con un ajuste del perfil. La forma por línea de comandos es un único indicador añadido al comando de arranque habitual:

chrome --bot-profile="path/to/profile.enc" --bot-port-protection

El mismo interruptor puede vivir en el JSON del perfil, lo que conviene a los perfiles que siempre deben tener la protección activa y en los que no se debe olvidar el indicador:

{
  "configs": {
    "portProtection": true
  }
}

Cuando el ajuste está en el perfil, se aplica en cuanto el perfil se carga y no hace falta ningún indicador adicional. Si arrancas mediante un framework de automatización, añade el mismo indicador a los argumentos de arranque como harías con cualquier otro indicador de BotBrowser. La documentación de protección de puertos muestra el mismo indicador en un arranque con Playwright y en una configuración combinada con proxy.

El comportamiento documentado es que los intentos de conexión de las páginas web a puertos habitualmente sondeados se comportan de forma coherente en las direcciones de bucle local. La referencia de indicadores de la CLI indica que el conjunto cubierto son 30 puertos habitualmente sondeados en tres formas de dirección: el bloque IPv4 de bucle local 127.0.0.0/8, la dirección IPv6 de bucle local ::1 y el nombre de host localhost. La guía de protección de puertos describe el mismo comportamiento sin indicar una cifra.

Elige el indicador cuando quieras protección para un único arranque, por ejemplo mientras pruebas. Elige el ajuste del perfil cuando un perfil concreto deba llevarla siempre. Los equipos que guardan sus scripts de arranque en control de versiones suelen preferir el ajuste del perfil, porque un perfil protegido sigue protegido sea cual sea el script que lo inicia, y una revisión del archivo del perfil muestra la intención. Ten presente que la función está desactivada de forma predeterminada, así que un perfil sin el ajuste y un arranque sin el indicador funcionan ambos sin protección.

Los servidores sin interfaz gráfica y las máquinas de compilación compartidas merecen una nota aparte. Un navegador en un servidor que aloja bases de datos, agentes de monitorización y herramientas de contenedores está junto a muchos receptores locales, y una página que visite puede ver el mismo tipo de patrón que muestra una estación de trabajo. Si ese navegador forma parte de una flota que debe comportarse de manera coherente, el conjunto distintivo de receptores de un servidor es una diferencia no deseada. Fijar la opción en el perfil que usan esos trabajos mantiene el comportamiento sin depender de cada script de arranque.

Hay dos detalles importantes para planificar. Primero, la protección se refiere a los intentos hechos por páginas web. La documentación indica que las herramientas locales que se conectan directamente no se ven afectadas, así que tu terminal, tu cliente de base de datos y tu editor siguen funcionando como antes. Segundo, el conjunto cubierto es una lista fija de puertos habitualmente sondeados y no todos los puertos del equipo. Si necesitas cobertura para un puerto fuera de ella, la documentación te remite al soporte, y no debes dar por hecho que está incluido.

Verificar resultados uniformes con un servicio de prueba local

La verificación debe mostrar dos cosas: que los resultados de los intentos iniciados por páginas son uniformes con la protección activa y que tus propias herramientas siguen funcionando. Puedes comprobar ambas en un equipo tuyo con un servicio desechable. Hazlo solo contra tu propio equipo. Probar contra equipos que no controlas no es un paso de verificación y no se trata aquí.

Inicia un servicio inocuo enlazado a la dirección de bucle local en un puerto que puedas dedicar:

python3 -m http.server 8080 --bind 127.0.0.1

Después recorre las comprobaciones en orden:

1. Haz una medición de referencia sin protección de puertos. Usa una página de prueba pequeña que controles, cargada en el navegador, que intente una conexión desde el código de la página hacia tu servicio desechable y hacia un puerto sin uso en la misma dirección, y que registre cómo se resuelve cada intento.
2. Arranca de nuevo con --bot-port-protection o configs.portProtection y repite la misma página. Con la protección activa, el resultado del puerto abierto y del puerto sin uso debe ser indistinguible para la página.
3. Repite el intento con las formas que nombra la documentación: la dirección IPv4 de bucle local, la dirección IPv6 ::1 y el nombre de host localhost. El resultado debe ser uniforme en cada forma, no solo en una.
4. Desde un terminal, conéctate directamente al servicio desechable, por ejemplo con curl http://127.0.0.1:8080/. Debe responder con normalidad, porque las conexiones directas de las herramientas no se ven afectadas.
5. Si dependes de que una página web hable con una aplicación local de apoyo, prueba esa integración con la protección activa. La documentación describe un comportamiento coherente para los intentos iniciados por páginas hacia puertos habitualmente sondeados, así que cualquier flujo de página a aplicación local en uno de esos puertos merece su propia comprobación antes de generalizar el ajuste.
6. Anota los argumentos de arranque, el perfil usado y los resultados, y repite la prueba tras cambios en el perfil, en la versión del navegador o en los scripts de arranque.

Un registro útil es breve: la forma de la dirección, el puerto, si era el servicio desechable o un puerto sin uso, y lo que observó la página. Limítalo a tus puertos de prueba. Un registro que solo recoge resultados de puertos que abriste tú basta para demostrar uniformidad y no deja un inventario de tus servicios reales en un documento compartido.

Si la medición de referencia ya parece uniforme, la comparación aporta poco, porque tu página de prueba no distinguía los dos puertos ni siquiera sin protección. Si la ejecución protegida sigue mostrando una diferencia en un puerto que esperas que esté cubierto, comprueba que el indicador o el ajuste del perfil llegó al navegador y confirma el puerto con la documentación. Un puerto fuera del conjunto cubierto se comporta como antes. Eso es una cuestión de cobertura que plantear al soporte, no necesariamente un fallo.

Qué soporta BotBrowser y qué queda fuera de su alcance

BotBrowser PRO soporta la protección de puertos mediante el indicador --bot-port-protection o configs.portProtection en un perfil, y hace que los intentos de conexión de las páginas web a puertos de bucle local habitualmente sondeados (30 puertos en 127.0.0.0/8, ::1 y localhost) se comporten de forma coherente, de modo que una página no pueda mapear qué servicios locales ejecutas. BotBrowser no puede garantizar la cobertura de puertos fuera de los 30 documentados ni de rangos de red local como 192.168.x.x, no puede cambiar las conexiones que hacen directamente las herramientas locales y no sustituye las protecciones de proxy, DNS, WebRTC ni otras protecciones de huella digital.

El alcance es deliberadamente estrecho. Las direcciones que nombra la documentación son direcciones de bucle local. Los rangos que usan otros dispositivos de tu red, como 192.168.x.x, 10.x.x.x y 172.16.x.x, no forman parte de la cobertura documentada, así que no los describas como protegidos. La función es además una capa entre varias: tu dirección IP, las consultas DNS y los candidatos WebRTC son superficies distintas que requieren su propio tratamiento, igual que el canvas, las fuentes y señales similares.

Para las capas de red que rodean a esta, consulta prevención de fugas de DNS, prevención de fugas de WebRTC y coherencia entre proxy, DNS y WebRTC. Vuelve a revisar la documentación de protección de puertos y la referencia de indicadores de la CLI antes de cambiar en tus propias notas los rangos cubiertos, el número de puertos, el nivel de licencia o el estado predeterminado, porque son los detalles con más probabilidad de cambiar entre versiones.

Fuentes

• Documentación de BotBrowser: protección de puertos
• Documentación de BotBrowser: referencia de indicadores de la CLI
• WICG: Local Network Access
• RFC 1122: Requirements for Internet Hosts, Communication Layers
• RFC 4291: IP Version 6 Addressing Architecture

Conclusión práctica

Activa --bot-port-protection o configs.portProtection cuando el resultado visible para una página deba ser independiente de los servicios locales. Comprueba el conjunto documentado de 30 puertos y repite la revisión para 127.0.0.1, ::1 y localhost; un resultado uniforme del navegador no protege direcciones privadas ni puertos fuera del conjunto.