Nessus su VPN: dove collocare lo scanner prima della prima scansione

Un’icona VPN accanto al browser non dice nulla sul processo che invia i pacchetti di scansione. Se console e scanner girano su host diversi, il tunnel del browser è un percorso e l’origine della scansione è un altro. Parti dal punto di esecuzione e procedi verso l’esterno: la route, l’autorizzazione e le credenziali. Questa distinzione è il primo elemento della checklist per un motivo.

Questa è una checklist pre-lancio, non un tutorial sulle scansioni. Ogni passaggio produce un fatto che puoi inserire nel registro dell’incarico prima che un pacchetto lasci lo scanner.

Punto uno: individua il processo che invia le sonde

Disegna esplicitamente i tre ruoli: il browser sul portatile A, la console di scansione sull’host B e il target privato C. Se B esegue anche il motore di scansione, al browser basta un percorso verso B. Se il lavoro lo fa un’appliance di scansione separata, quella appliance ha bisogno del percorso verso C.

Browser on laptop A -> console on host B
Scanner process on B (or another appliance) -> private target C

Un browser connesso alla VPN può raggiungere la console mentre lo scanner dietro di esso non ha ancora alcuna route verso C. È possibile anche il contrario: lo scanner è dentro la rete privata e la console è remota. Scopri quale assetto esegui davvero prima di modificare qualsiasi controllo di rete. Nomina l’appliance nella configurazione della scansione prima di dare la colpa alla rete.

Se lo scanner gira su A, l’host del browser e lo scanner condividono un contesto, ma solo finché quel processo mantiene lo stesso namespace e la stessa tabella di routing. Un container o un account di servizio possono non ereditare ciò che vede il browser interattivo. La console è una superficie di gestione, non il motore di scansione.

Punto due: dimostra la route e il DNS dello scanner

Esegui il controllo della route sull’host dello scanner, non sul portatile. Chiedi al kernel quale interfaccia e quale gateway userebbe per l’indirizzo del target, poi ripeti per il nome host del target. Una route che esiste per l’IP e un nome che risolve su un altro indirizzo sono due guasti diversi.

Conferma l’indirizzo sorgente che apparirà al target. Un client VPN può assegnare un indirizzo diverso da quello atteso dal firewall del target, e un dispositivo NAT può riscriverlo di nuovo. Il proprietario del target ha bisogno dell’origine osservata, non dell’indirizzo stampato nel profilo VPN.

Controlla anche il percorso di ritorno. Uno scanner che raggiunge il target ma non riceve risposte ha un problema di routing o di firewall al ritorno, e questo appare identico a un target inattivo.

Punto tre: fai autorizzare ambito e punto di osservazione

Chiedi al proprietario del target di indicare per iscritto sistemi, servizi, ambiente, origine e finestra temporale. Stabilisci quale punto di osservazione rappresenta la valutazione: un utente VPN esterno, un client interno ammesso o uno specifico segmento di scanner.

Una route privata non è un permesso per testare reti adiacenti. Mantieni la lista dei target ristretta, elenca i sistemi esclusi e concorda condizioni di arresto e un contatto che possa fermare l’esecuzione. Lo scanner sonderà volentieri tutto ciò che riesce a raggiungere, ed è proprio per questo che l’ambito deve essere esplicito.

Registra l’origine approvata nello stesso documento. Se l’origine osservata dallo scanner differisce da quella approvata, l’esecuzione non rappresenta il punto di osservazione concordato anche quando la lista dei target è corretta.

Punto quattro: adegua le credenziali alla profondità della valutazione

Un controllo di raggiungibilità e una valutazione autenticata sono test diversi. Una risposta di porta dimostra che qualcosa ha risposto; non dimostra che i controlli con credenziali siano stati eseguiti né che l’applicazione abbia autorizzato l’account.

Usa credenziali dedicate solo quando l’ambito concordato richiede controlli autenticati. Conferma i permessi e la politica di blocco dell’account e decidi come i risultati saranno archiviati e condivisi prima che la scansione li produca.

Se le credenziali falliscono, non passare in silenzio a un’esecuzione non autenticata e non etichettare il report come la valutazione pianificata. Il risultato è un test diverso con un significato diverso, e la differenza va inserita nel report.

Punto cinque: salva il piano, poi avvia con consapevolezza

Nel flusso di lavoro delle scansioni Nessus, scegliere un modello, configurare le impostazioni e salvare o avviare la scansione sono passaggi separati. Sfrutta questa separazione per rivedere la lista dei target, l’origine e la pianificazione prima che inizi qualsiasi traffico.

Prima di autorizzare il lancio, verifica quale origine consente la VPN, quale traffico trasporta e come si riprende da un tunnel caduto. Non ampliare l’accesso al firewall solo perché una connessione preliminare è fallita; trova il livello che l’ha rifiutata e correggi quel livello.

Dopo l’esecuzione, registra l’host dello scanner, la sua origine osservata, la lista dei target e i controlli che non sono stati completati. Un report prodotto da un’altra origine o senza le credenziali previste non rappresenta il piano originale, e dirlo fa parte del deliverable.

Ritira gli accessi dell’incarico e gestisci i risultati conservati secondo il processo concordato. La checklist è conclusa solo quando le prove corrispondono al percorso che hai approvato, non quando la scansione ha semplicemente restituito risultati.