NetScavenger, gestione rete per WISP e ISP

01Il problema concreto

Un WISP o ISP di dimensioni medie si ritrova, senza accorgersene, con una rete che nessuno mappa più davvero. La rete reale da cui nasce NetScavenger ha 4.420 device attivi, di cui 1.133 MikroTik, 3.037 Ubiquiti, 23 Cisco, 21 TP-Link, 47 Cambium. Ogni cliente montato, ogni AP sostituito, ogni PoP ampliato aggiunge apparati — e l'inventario in Excel o su wiki, tenuto manualmente, si disallinea nel giro di settimane.

Le conseguenze sono tre, e tutte costano. Rogue device: apparati apparsi in rete che nessuno sa chi ha messo, o apparati legittimi che a un certo punto cambiano vendor (segno tipico di furto-sostituzione o di manutenzione non registrata). Credential drift: password non ruotate, utenti che esistono solo su alcuni apparati, nessuno sa più quale è la credenziale valida su quel router al PoP di campagna. Compliance audit: con la direttiva NIS2 in vigore, a un operatore di comunicazioni serve dimostrare cosa c'è in rete, chi ci accede, e che lo stato dei controlli è tracciato. A mano non si regge.

NetScavenger è stato costruito perché gli inventari manuali e gli script ad hoc, dopo due anni, diventano ingestibili. Non è un'ipotesi, è una traiettoria vissuta.

02Discovery automatico

Il punto di partenza è il neighbor table dei router MikroTik. Ogni RouterOS tiene la lista degli apparati che vede in discovery protocol (MNDP, CDP, LLDP): MAC, IP, hostname, piattaforma, interfaccia di contatto. NetScavenger interroga via SSH ogni router già censito, raccoglie la sua neighbor table, e trova apparati di cui non conosceva l'esistenza. Li aggiunge come candidati, li arricchisce con MAC OUI lookup — i primi 24 bit del MAC identificano il vendor in modo istantaneo e offline — e li classifica come core, access, wifi o CPE in base a pattern di hostname, interfaccia, e contesto topologico.

Il risultato è una scoperta incrementale: più apparati conosci, più ne scopri. Dal primo BGP router di frontiera si arriva, salto dopo salto, fino all'ultimo AP su un tetto.

03Credential management a scala

Scoprire un apparato non serve se poi non ci si entra. NetScavenger mantiene un pool di credenziali ordinate per priorità, e uno scanner Go apre fino a 100+ connessioni SSH concorrenti. Per ogni device nuovo prova le credenziali in ordine: la prima che funziona viene registrata come "ultima credenziale valida" e usata di default. Per ridurre il rumore, un cooldown intelligente evita di ritentare subito gli apparati falliti: 7 giorni dopo un authentication failed, 3 giorni dopo un unreachable. Apparati già autenticati vengono comunque riverificati periodicamente per intercettare cambi password non comunicati.

Sulla rete da 4.420 device questo approccio ha censito 2.028 apparati con SSH funzionante. Le credenziali non viaggiano mai in chiaro nei callback o nei log: nei payload restano solo gli hash SHA256 per il matching.

04Backup configurazioni con change detection

Ogni apparato raggiungibile viene dumpato secondo il formato nativo del vendor. Per MikroTik export testuale (/export), verbose, e binario; per Ubiquiti il system.cfg; per Cisco il running-config. L'hash SHA256 del contenuto viene confrontato con l'ultimo backup: se uguale, non si scrive niente. Questo evita di archiviare decine di migliaia di copie identiche e, soprattutto, rende banale accorgersi quando una config cambia: nuovo hash, nuova riga nel change log, alert opzionale.

La retention è configurabile per vendor e per ruolo. Tipicamente si tiene tutto per 90 giorni, un backup al mese per un anno, uno all'anno a lungo termine.

05Device tracking

L'identificatore primario non è né il MAC né l'IP — troppo mutevoli. È il serial number, che è immutabile per tutta la vita dell'apparato. Intorno al serial, NetScavenger tiene un change log completo: ogni volta che cambia identity (hostname), IP di management, vendor o modello, viene scritta una riga con timestamp e diff.

Questo abilita la rilevazione di anomalie sostanziali: un apparato che a parità di serial cambia vendor è un segnale rosso (furto-sostituzione, o hardware ricondizionato installato senza procedura). Un serial nuovo che appare su un IP già noto significa sostituzione — giustificata o meno. Tutto tracciato, tutto ispezionabile in audit.

06DHCP e PPPoE

Ogni router viene interrogato per la sua configurazione DHCP server e per le sessioni PPPoE/L2TP attive. Sulla rete di riferimento ci sono 609 server DHCP e 675 sessioni PPPoE contemporanee — numeri gestibili solo se aggregati da uno strumento che li raccoglie e li normalizza.

Il valore operativo è doppio. Rogue DHCP detection: se compare un DHCP server non censito in una VLAN in cui non dovrebbe essercene, scatta un alert — è uno dei modi più comuni in cui un accesso malevolo o un errore di configurazione distrugge una rete. Verifica utenti: incrociando le sessioni PPPoE attive con il RADIUS si individuano utenti connessi che non risultano in anagrafica — segnale di duplicati, condivisioni credenziali, o sessioni orfane.

07Path tracing e ricerca di rete

La domanda ricorrente del NOC è "dov'è davvero collegato questo IP?". NetScavenger risponde componendo tre tabelle: ARP (IP→MAC), bridge host (MAC→porta fisica), routing table (IP→next hop). Nella rete da esempio questo significa correlare 168.753 route entries e 52.921 bridge host per ricostruire il path end-to-end.

La ricerca universale accetta IP, MAC o hostname e ritorna l'apparato, la porta di attestazione e il percorso logico fino al core. Se incontra un gateway non censito durante il tracing, ne fa auto-probe e lo aggiunge come candidato — la rete si auto-completa mentre la usi.

08Allineamento NIS2

La direttiva NIS2 chiede, in sostanza, quattro cose a un operatore: sapere cosa c'è in rete, sapere chi ci accede, sapere quando le cose cambiano, e avere evidenza scritta dei controlli. NetScavenger tocca tutti e quattro i punti — non li chiude da solo, ma fornisce la base fattuale.

• Inventario aggiornato in continuo, non a snapshot trimestrali — con timestamp dell'ultima verifica per ogni apparato.
• Tracciabilità cambiamenti: change log su config, identità, credenziali, topologia.
• Audit trail: ogni scan lascia traccia di chi, quando, con quale esito. Le credenziali sono hashate, gli accessi loggati.
• Backup dei controlli: le configurazioni storiche sono la prova che i controlli di sicurezza richiesti erano presenti nel tempo.

Non diciamo che NetScavenger vi fa la NIS2. Diciamo che rimuove la parte meccanica — quella che ammazza di lavoro e che comunque serve — lasciandovi il tempo di occuparvi di policy, procedure e incident response.

09Come si adotta

Il deploy tipico si misura in giorni, non in mesi. Quattro fasi: import credenziali iniziali dal vostro password manager o dai vostri script; primi scan a partire dai router di frontiera, propagazione per neighbor table; calibrazione alert (soglie, canali Slack, mail, severità); formazione del NOC su ricerca, dashboard analytics e runbook degli alert.

Dopo 7-14 giorni la rete è mappata al 90% e gli alert iniziano ad avere segnale utile. Il restante 10% emerge nei mesi successivi man mano che la rete stessa cambia — ed è esattamente quello il punto: non è un progetto one-off, è uno strumento che resta.

Capability	Excel + script ad hoc	SNMP puro (tipo LibreNMS)	NetScavenger
Discovery automatico	Manuale	Solo se SNMP abilitato	Neighbor table + OUI, qualunque vendor
Multi-vendor reale	Sì, ma scollegato	Dipende da MIB	MikroTik, Ubiquiti, Cisco, TP-Link, Cambium
Backup config	No	Parziale	Nativo per vendor + change detection SHA256
Credential pool	File condiviso	Solo community	SSH parallelo 100+, cooldown, hash
Rogue detection	Zero	Solo se monitorato	DHCP, vendor change, serial drift
Path tracing	A memoria	Manuale	ARP→bridge→route correlato
NIS2 ready	No	Parzialmente	Inventario, audit trail, change log
Scala	Fino a 500 device	Buona	Migliaia, testato su 4.420