Réseau

Protection scan de ports : bloquer le sondage reseau

Comment les sites web utilisent JavaScript pour sonder les ports de votre réseau local et détecter les services, et comment bloquer le scan de ports au niveau du navigateur.

Documentation

Vous préférez la doc produit maintenue ?

Cet article a une page équivalente dans le centre de documentation. Utilisez les docs pour le flux canonique, les flags à jour et la référence durable.

Introduction

Votre ordinateur exécute des services sur différents ports réseau : serveurs de développement, moteurs de bases de données, protocoles de bureau distant, VNC, Docker et plus encore. Chaque fois que vous visitez un site web, les scripts de cette page peuvent tenter de sonder vos ports de réseau local pour découvrir quels services fonctionnent. Le motif des ports ouverts et fermés crée une empreinte distinctive de votre environnement local, suffisamment unique pour vous identifier entre les sessions et même entre différents navigateurs.

C'est une préoccupation sérieuse pour la vie privée. Le fingerprinting par port peut persister même lorsque vous changez d'adresse IP, effacez vos cookies ou passez à un profil de navigateur différent. Les services fonctionnant sur votre machine ont tendance à rester cohérents dans le temps, ce qui en fait un signal de pistage hautement fiable pour tout site web qui choisit de le collecter.

BotBrowser fournit une protection intégrée des ports qui contrôle comment le navigateur répond aux sondes de ports locaux au niveau du moteur. Plutôt que de simplement bloquer les connexions (ce qui est en soi détectable), BotBrowser garantit que toutes les sondes de ports locaux retournent des résultats uniformes. Cela rend impossible pour les sites web de distinguer les ports ouverts des ports fermés, neutralisant efficacement toute cette catégorie de pistage par empreinte.

Pourquoi la confidentialité des ports est importante

Le scan de ports depuis le navigateur est une préoccupation de confidentialité réelle et bien documentée. Les sites web ont été observés sondant des dizaines de ports locaux pour construire une image des logiciels fonctionnant sur les machines des visiteurs. Les types d'informations qui peuvent être collectées incluent des détails sur tout votre environnement informatique.

Les outils de développement sont une cible courante. Lorsqu'un développeur web a des services fonctionnant sur des ports couramment associés aux frameworks et outils de build, n'importe quel site web peut apprendre que le visiteur est probablement un développeur logiciel. Cette information seule réduit significativement le pool d'identité potentielle.

Les logiciels d'accès distant sont un autre signal. Les services associés au bureau distant, à l'accès terminal et aux outils de partage d'écran révèlent des détails importants sur la façon dont vous utilisez votre machine et le type d'infrastructure que vous gérez.

Les services de base de données fonctionnant sur des ports standard disent aux sites web quelle pile technologique vous utilisez. Que vous utilisiez des bases de données relationnelles, des magasins de documents ou des caches en mémoire, chaque service en cours d'exécution ajoute un point de données supplémentaire à votre empreinte de port.

Les services de conteneurisation et de virtualisation sont particulièrement révélateurs. Leur présence indique un certain type d'utilisateur technique et peut révéler des détails sur votre workflow de développement et de déploiement.

La combinaison de tous ces signaux crée une empreinte stable. Votre ensemble de services en cours d'exécution a tendance à être cohérent entre les sessions de navigation, ce qui en fait l'un des signaux de pistage les plus fiables disponibles. Même si vous alternez votre IP, effacez tout le stockage du navigateur et utilisez un profil de navigateur frais, le motif de vos services en cours d'exécution reste largement le même.

Le défi de la protection des ports

Pourquoi le blocage simple est insuffisant

Une approche directe de la protection des ports est de bloquer toutes les connexions aux adresses locales. Cependant, cela crée ses propres problèmes qui peuvent en fait rendre votre navigateur plus identifiable, pas moins.

Lorsque les connexions à localhost sont bloquées carrément, le motif d'erreur est différent de ce qu'un navigateur standard produit. Un site web peut détecter le comportement de blocage lui-même, transformant votre mesure de protection en un autre signal distinctif. De plus, le blocage uniforme est conspicueux en soi. Si chaque port retourne la même réponse bloquée instantanément, l'uniformité se distingue de la variation naturelle qu'un navigateur normal montrerait.

Le blocage casse aussi la fonctionnalité légitime. De nombreuses applications web ont besoin de communiquer avec des services locaux. Les services de streaming musical qui se connectent aux applications de bureau, les outils de développement qui utilisent localhost pour le rechargement à chaud, et les flux d'authentification qui s'appuient sur des serveurs de redirection locaux dépendent tous de la connectivité localhost. Le blocage général perturbe ces workflows.

Extensions de navigateur

Les extensions qui filtrent les requêtes réseau peuvent bloquer les connexions aux adresses locales via leurs règles de filtre. Cependant, les extensions opèrent dans la couche JavaScript, ce qui signifie qu'elles interceptent les requêtes après que le moteur du navigateur a déjà commencé à les traiter. Les caractéristiques de timing du blocage lui-même peuvent fournir des informations analysables. Les extensions peuvent aussi être détectées par leurs effets secondaires sur les API du navigateur, et tous les types de connexion peuvent ne pas être interceptés de manière cohérente à travers différents mécanismes de requête comme WebSocket, chargements d'images et appels fetch.

Règles de pare-feu

Les pare-feu du système d'exploitation peuvent restreindre quels processus peuvent se lier aux ports. Cependant, cela ne traite pas le fingerprinting par port parce que le navigateur fait des connexions sortantes vers localhost, pas des connexions entrantes depuis Internet. Les règles de pare-feu qui empêchent le navigateur de se connecter à localhost casseraient la communication légitime avec les services locaux et créeraient les mêmes problèmes de détectabilité que le blocage simple.

L'approche de BotBrowser pour la protection des ports

Protection au niveau du moteur

BotBrowser résout le problème du fingerprinting par port au bon niveau : à l'intérieur du moteur du navigateur lui-même. Le flag --bot-port-protection (PRO) active la protection qui contrôle le comportement d'accès aux ports à la couche la plus profonde possible. Lorsqu'il est activé, toutes les connexions aux adresses locales produisent des caractéristiques de timing uniformes que qu'un service fonctionne réellement ou non sur ce port.

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

Les connexions se poursuivent normalement. BotBrowser ne bloque pas les connexions à localhost. Au lieu de cela, il contrôle le comportement de timing observable de sorte que les ports ouverts et fermés sont indistinguables pour tout script exécuté sur la page. Vos services locaux continuent de fonctionner comme prévu.

Aucun artefact détectable. Toutes les API du navigateur se comportent normalement. Il n'y a pas de propriétés manquantes, de prototypes altérés ni de motifs d'erreur inhabituels qui indiqueraient que la protection est active.

Les services locaux légitimes fonctionnent toujours. Les applications qui ont besoin de la communication localhost fonctionnent correctement. Que vous utilisiez un service de streaming musical, un serveur de développement local ou toute autre application qui s'appuie sur la connectivité localhost, tout fonctionne comme prévu.

Couverture complète

La protection des ports de BotBrowser couvre toutes les plages d'adresses couramment sondées :

  • 127.0.0.0/8 : la plage de loopback IPv4 complète, incluant toutes les adresses 127.x.x.x
  • ::1 : l'adresse de loopback IPv6
  • localhost : l'accès basé sur le nom d'hôte aux services locaux

La protection couvre 30 ports couramment sondés à travers ces plages d'adresses. Ce sont les ports les plus fréquemment ciblés par le fingerprinting de port basé sur le navigateur, couvrant les outils de développement, les bases de données, les services d'accès distant, les plateformes de conteneurs et d'autres logiciels couramment exécutés.

Configuration basée sur le profil

En plus du flag CLI, la protection des ports peut être activée directement dans la configuration du profil :

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

Configuration et utilisation

Configuration CLI de base

chrome --bot-profile="/path/to/profile.enc" \
       --bot-port-protection \
       --user-data-dir="$(mktemp -d)"

Configuration complète de confidentialité

Pour une confidentialité réseau complète, combinez la protection des ports avec la protection proxy, DNS et WebRTC :

chrome --bot-profile="/path/to/profile.enc" \
       --bot-port-protection \
       --proxy-server=socks5://user:pass@proxy:1080 \
       --bot-local-dns \
       --bot-webrtc-ice=google

Intégration Playwright

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

(async () => {
  const browser = await chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--bot-port-protection',
    ],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com');
  // La protection des ports est active pour toute la navigation
  await browser.close();
})();

Intégration Puppeteer

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

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--bot-port-protection',
    ],
    headless: true,
    defaultViewport: null,
  });

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

Vérification

Pour confirmer que la protection des ports fonctionne correctement :

  1. Démarrez un service connu sur un port spécifique (par exemple, un simple serveur HTTP sur le port 8080)
  2. Lancez BotBrowser avec --bot-port-protection
  3. Naviguez vers une page de test d'empreinte qui vérifie l'accessibilité des ports
  4. Confirmez que la page de test ne peut pas distinguer le port ouvert des ports fermés
  5. Vérifiez que vos services locaux fonctionnent toujours correctement via le navigateur

Bonnes pratiques

  1. Activez la protection des ports sur les machines de développement. Les développeurs exécutent généralement de nombreux services qui créent une empreinte de port hautement distinctive.

  2. Activez la protection des ports sur les serveurs. Les serveurs headless exécutant de multiples services sont particulièrement susceptibles au fingerprinting de port.

  3. Combinez avec d'autres protections réseau. La protection des ports traite le fingerprinting des services locaux. Combinez-la avec la configuration de proxy, la prévention des fuites DNS et la protection WebRTC.

  4. Utilisez la configuration basée sur le profil pour une protection cohérente. Définissez configs.portProtection dans le profil pour qu'il s'active automatiquement.

  5. Testez après les changements de configuration. Vérifiez que la protection des ports fonctionne toujours comme prévu après chaque modification.

Questions fréquentes

La protection des ports casse-t-elle les workflows de développement local ? Non. La protection des ports contrôle les caractéristiques de timing des connexions locales, pas si elles réussissent ou échouent. Les connexions légitimes aux services locaux fonctionnent normalement.

La protection des ports couvre-t-elle tous les ports ? BotBrowser couvre 30 ports couramment sondés à travers les plages de loopback IPv4, IPv6 et localhost.

Puis-je utiliser la protection des ports sans proxy ? Oui. La protection des ports est indépendante de la configuration proxy. Cependant, pour une confidentialité complète, nous recommandons de combiner la protection des ports avec un proxy.

La protection des ports fonctionne-t-elle en mode headless ? Oui. La protection des ports fonctionne de manière identique en mode headless et avec affichage.

Les sites web peuvent-ils détecter que la protection des ports est active ? La protection des ports de BotBrowser opère au niveau du moteur, sous la couche JavaScript. La normalisation du timing garantit que les ports ouverts et fermés sont indistinguables. Il n'y a pas d'artefacts visibles en JavaScript.

Résumé

Le fingerprinting de port basé sur le navigateur crée un signal de pistage persistant en analysant quels services fonctionnent sur votre machine. Cette empreinte persiste à travers les changements d'IP, les effacements de cookies et les réinitialisations de navigateur. La protection des ports au niveau du moteur de BotBrowser garantit que toutes les sondes de port retournent des résultats uniformes, rendant impossible pour les sites web de cartographier votre paysage de services locaux.

Combinée avec la configuration de proxy, la prévention des fuites DNS et la protection WebRTC, la protection des ports complète le tableau de la confidentialité réseau. Pour les protections réseau connexes, voir DNS Leak Prevention et WebRTC Leak Prevention. Pour la gestion complète de l'identité, voir Multi-Account Browser Isolation.

#Port#Scanning#Protection#Network#Privacy

Faites passer BotBrowser de la recherche à la production

Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.