netmap.js

Module de découverte réseau rapide basé sur navigateur

Ce projet n'est plus maintenu.

Description

netmap.js fournit des capacités de découverte d'hôtes et de scanner de ports basées sur le navigateur, permettant de cartographier le réseau des visiteurs d'un site web.

Il est assez rapide, utilisant es6-promise-pool pour exécuter efficacement le nombre maximum de connexions simultanées autorisées par les navigateurs.

Motivation

J'avais besoin d'un scanner de ports basé sur navigateur pour une idée sur laquelle je travaillais. Je pensais que ce serait simple d'importer un module existant ou de copier-coller depuis un autre projet comme BeEF.

Il s'avère qu'il n'existait pas de module npm décent prêt à l'emploi et que le module port_scanner de BeEF est (au moment de l'écriture) imprécis, lent et ne fonctionne pas sur Chromium.

netmap.js est donc un balayeur "ping" et un scanner TCP quelque peu optimisé, fonctionnant sur tous les navigateurs modernes.

Démarrage rapide

Installation

npm install --save netmap.js

Trouver des hôtes actifs

Découvrons l'adresse IP de la passerelle d'un visiteur, à partir d'une liste de candidats probables dans un environnement domestique :

import NetMap from 'netmap.js'

const netmap = new NetMap()
const hosts = ['192.168.0.1', '192.168.0.254', '192.168.1.1', '192.168.1.254']

netmap.pingSweep(hosts).then(results => {
  console.log(results)
})

{
  "hosts": [
    { "host": "192.168.0.1", "delta": 1003, "live": false },
    { "host": "192.168.0.254", "delta": 1001, "live": false },
    { "host": "192.168.1.1", "delta": 18, "live": true },
    { "host": "192.168.1.254", "delta": 1002, "live": false }
  ],
  "meta": {}
}

L'hôte 192.168.1.1 semble actif.

Scanner des ports TCP

Essayons de trouver quelques ports TCP ouverts sur plusieurs hôtes :

import NetMap from 'netmap.js'

const netmap = new NetMap()
const hosts = ['192.168.1.1', '192.168.99.100', 'google.co.uk']
const ports = [80, 443, 8000, 8080, 27017]

netmap.tcpScan(hosts, ports).then(results => {
  console.log(results)
})

{
  "hosts": [
    {
      "host": "192.168.1.1",
      "control": "22",
      "ports": [
        { "port": 443, "delta": 15, "open": false },
        { "port": 8000, "delta": 19, "open": false },
        { "port": 8080, "delta": 21, "open": false },
        { "port": 27017, "delta": 26, "open": false },
        { "port": 80, "delta": 95, "open": true }
      ]
    },
    {
      "host": "192.168.99.100",
      "control": "1001",
      "ports": [
        { "port": 8080, "delta": 40, "open": true },
        { "port": 80, "delta": 1001, "open": false },
        { "port": 443, "delta": 1000, "open": false },
        { "port": 8000, "delta": 1004, "open": false },
        { "port": 27017, "delta": 1000, "open": false }
      ]
    },
    {
      "host": "google.co.uk",
      "control": "1001",
      "ports": [
        { "port": 443, "delta": 67, "open": true },
        { "port": 80, "delta": 159, "open": true },
        { "port": 8000, "delta": 1001, "open": false },
        { "port": 8080, "delta": 1002, "open": false },
        { "port": 27017, "delta": 1000, "open": false }
      ]
    }
  ],
  "meta": {}
}

Au premier abord, les résultats peuvent sembler contradictoires.

192.168.1.1 est une machine Linux embarquée (un routeur) sur le segment réseau local, et le seul port ouvert est 80. On peut voir que le navigateur a mis environ 5 fois plus de temps à générer une erreur sur 80 par rapport aux autres ports fermés.

192.168.99.100 est une machine virtuelle en mode host-only avec le port 8080 ouvert, et google.co.uk est un hôte externe avec les ports 443 et 80 ouverts. Dans ces cas, le navigateur a généré une erreur relativement rapidement sur les ports ouverts tandis que les ports fermés ont simplement expiré. La section Théorie plus bas explique quand cela se produit.

Afin de déterminer si les ports doivent être marqués comme ouverts ou fermés, netmap.js analyse un port de "contrôle" (par défaut 45000) qui est supposé être fermé. Le temps de contrôle est ensuite utilisé pour déterminer le statut des autres ports. Si le rapport delta/control est supérieur à une valeur définie (par défaut 0.8), le port est considéré comme fermé (en résumé : une différence de plus de 20 % par rapport au temps de contrôle signifie que le port est ouvert).

Limitations

Listes noires de ports

Les navigateurs maintiennent une liste noire de ports auxquels ils refusent de se connecter (comme FTP, SSH ou SMTP). Si vous essayez d'analyser ces ports avec netmap.js en utilisant le protocole par défaut (http), vous obtiendrez un délai très court. Un délai court est généralement un signe que le port est fermé, mais dans le cas des ports sur liste noire, cela ne signifie rien.

Vous pouvez consulter les listes noires à partir de ces sources :

• Source Chromium
• Documentation Mozilla
• Edge/IE (envoyez-moi un lien si vous trouvez une source)

Avant Firefox 61 (et peut-être d'autres navigateurs), il est possible de contourner cette limitation en utilisant le protocole ftp au lieu de http pour établir des connexions. Vous pouvez spécifier le protocol dans l'objet d'options lors de l'instanciation de NetMap. En utilisant ftp, attendez-vous à ce que les ports ouverts expirent et que les ports fermés génèrent une erreur relativement rapidement. Le scan ftp est également sujet aux limitations concernant les paquets TCP RST discutées dans ce document.

Les requêtes de sous-ressources depuis des protocoles "hérités" comme ftp sont bloquées depuis un certain temps dans Chromium.

Balayage "Ping"

La fonctionnalité de balayage "ping" fournie par netmap.js fait un assez bon travail pour trouver rapidement des hôtes *nix actifs sur un segment réseau local (autres ordinateurs, téléphones, routeurs, imprimantes, etc.).

Cependant, en raison de l'implémentation, cela ne fonctionne pas lorsque les paquets TCP RST ne sont pas renvoyés. Typiquement :

• Machines Windows
• Certains hôtes externes
• Certaines configurations réseau comme les machines virtuelles en pont ou host-only

La raison est expliquée dans la section Théorie ci-dessous.

Cette limitation n'affecte pas les capacités de scan TCP, et il est toujours possible de déterminer si les hôtes ci-dessus sont actifs en essayant de trouver un port ouvert sur eux.

Manque général de précision

Dans l'ensemble, j'ai trouvé ce module plus précis et plus rapide que les autres bouts de code que j'ai trouvés sur le web. Cela dit, l'idée même de cartographier des réseaux depuis un navigateur est par nature capricieuse. Les résultats peuvent varier.

Utilisation

Constructeur NetMap

Le constructeur NetMap prend un objet d'options qui permet de configurer :

• Le protocol utilisé pour le scan (par défaut http, voir Listes noires de ports pour savoir pourquoi vous voudriez le définir sur ftp)
• Le timeout de connexion au port (par défaut 1000 millisecondes)

import NetMap from 'netmap.js'

const netmap = new NetMap({
  protocol: 'http',
  timeout: 3000
})

pingSweep()

La méthode pingSweep() détermine si un tableau donné d'hôtes sont actifs. Elle le fait en vérifiant si la connexion à un port expire, auquel cas un hôte est considéré hors ligne (voir Balayage "Ping" pour les limitations et Cas standard pour la théorie).

La méthode prend les paramètres suivants :

• hosts tableau d'hôtes à scanner (adresses IP ou noms d'hôtes)
• options objet avec :
  • maxConnections - le nombre maximum de connexions simultanées (par défaut 10 sur Chrome et 17 sur les autres navigateurs - le maximum de connexions simultanées supportées par les navigateurs)
  • port à scanner (par défaut 45000)

Elle retourne une promesse.

netmap.pingSweep(['192.168.1.1'], {
  maxConnections: 5,
  port: 80
}).then(results => {
  console.log(results)
})

tcpScan()

La méthode tcpScan() effectue un scan de ports sur une gamme de cibles. Lisez le Cas standard pour comprendre comment elle procède.

La méthode prend les paramètres suivants :

• hosts tableau d'hôtes à scanner (adresses IP ou noms d'hôtes)
• ports liste des ports à scanner (entiers entre 1 et 65535, évitez les ports des listes noires)
• options objet avec :
  • maxConnections - le nombre maximum de connexions simultanées (par défaut 6 - le maximum de connexions par domaine autorisé par les navigateurs)
  • portCallback - une fonction de rappel à exécuter lorsqu'une combinaison host:port individuelle a fini d'être scannée
  • controlPort - le port à scanner pour déterminer un delta de base pour un port fermé (par défaut 45000)
  • controlRatio - la similarité, en pourcentage, avec le delta de contrôle pour qu'un port soit considéré fermé (par défaut 0.8, voir exemple)

Elle retourne une promesse.

netmap.tcpScan(['192.168.1.1'], [80, 27017], {
  maxConnections: 5,
  portCallback: result => {
    console.log(result)
  },
  controlPort: 45000,
  controlRatio: 0.8
}).then(results => {
  console.log(results)
})

Consultez l'exemple pour interpréter la sortie.

Théorie

Cette section couvre brièvement la théorie derrière les techniques de découverte du module.

Idée générale

Ce module utilise des objets Image pour tenter de demander des ressources cross-origin (la série d'URL http://{host}:{port} testées). Le temps mis par le navigateur pour générer une erreur (le delta), ou l'absence d'erreur après un certain délai, fournit des informations sur l'état de l'hôte et du port examinés.

Cas standard

Un hôte actif répondra généralement relativement rapidement avec un paquet TCP RST lorsqu'on tente de se connecter à un port fermé.

Si le port est ouvert, même s'il n'exécute pas de serveur HTTP, le navigateur mettra un peu plus de temps à générer une erreur en raison de la surcharge liée à l'établissement d'une connexion TCP complète, puis en réalisant qu'il ne peut pas obtenir une image depuis l'URL fournie.

Un hôte hors ligne ne répondra naturellement ni par un RST ni ne permettra l'établissement d'une connexion TCP complète. Les navigateurs essaieront tout de même d'établir la connexion pendant un certain temps avant d'expirer (~90 secondes). Par défaut, netmap.js expire après avoir attendu 1000 millisecondes.

En résumé :

• Les ports fermés sur des hôtes actifs auront un delta très court
• Les ports ouverts sur des hôtes actifs auront un delta légèrement plus long
• Les hôtes hors ligne ou les adresses IP inutilisées expireront

Le cas standard est illustré par l'hôte 192.168.1.1 dans l'exemple Scan de ports TCP.

Cas sans TCP RST

Certains hôtes (comme google.co.uk ou les hôtes Windows) et certaines configurations réseau (comme les réseaux VirtualBox host-only) ne renvoient pas de paquets TCP RST lorsqu'on touche un port fermé.

Dans ces cas, les ports fermés expireront généralement tandis que les ports ouverts généreront rapidement une erreur.

L'implémentation de la méthode pingSweep() est donc peu fiable lorsque les paquets RST ne sont pas renvoyés.

En résumé, lorsque les paquets TCP RST ne sont pas renvoyés pour une raison quelconque :

• Les ports fermés sur des hôtes actifs expireront
• Les ports ouverts sur des hôtes actifs auront un delta court
• pingSweep() ne peut pas distinguer entre une expiration de port fermé et une expiration d'hôte "mort"

Le cas particulier est illustré par les hôtes 192.168.99.100 et google.co.uk dans l'exemple Scan de ports TCP.

Abandon des WebSockets et AJAX

Il est bien documenté que l'on devrait également pouvoir cartographier des réseaux avec WebSockets et AJAX.

J'ai essayé (et j'ai aussi modifié BeEF pour que son module port_scanner utilise uniquement WebSockets et AJAX) ; j'ai trouvé les deux méthodes produisant des résultats complètement peu fiables.

Veuillez me le faire savoir si je manque quelque chose à cet égard.