Nmap mostra risultati diversi attraverso una VPN? Fissa l'obiettivo
Un nome host può risolversi a un altro indirizzo una volta attivo il tunnel. Mantieni fisso l'obiettivo numerico prima di interpretare qualsiasi cambiamento negli stati delle porte.
Due scansioni di porte dello stesso sito possono discordare perché il nome si è risolto a un altro indirizzo tra le esecuzioni, non perché il tunnel abbia cambiato ciò che l'obiettivo espone. Un nome host è un'istruzione di ricerca, e Nmap la segue al momento della scansione. Quando il resolver risponde con un altro record, la seconda scansione ha misurato un'altra macchina.
Fissa l'indirizzo numerico e il confronto torna significativo. Tutto il resto del rapporto, dai tempi ai dispositivi intermedi, resta una variabile separata che richiede il proprio controllo.
Due esperimenti che sembrano identici in un rapporto
Confronta un nome con se stesso e hai cambiato almeno due cose insieme: il percorso che i tuoi pacchetti seguono e la destinazione che il resolver ha restituito. Una differenza nell'output non può essere attribuita a nessuno dei due. Quell'ambiguità è la ragione abituale per cui una scansione prima-dopo diventa una discussione che nessuno riesce a chiudere.
Confronta un indirizzo con se stesso e la destinazione è fissa per costruzione. Tutto ciò che ancora differisce appartiene al percorso, all'indirizzo sorgente, al filtraggio intermedio o allo stato della macchina stessa. Hai rimosso una variabile, il che non è lo stesso che rimuoverle tutte.
Annota quale dei due esperimenti hai davvero eseguito prima di trarre qualsiasi conclusione da una tabella di porte. La distinzione suona accademica finché un rapporto non dice che la VPN ha bloccato una porta che non era mai aperta sull'indirizzo raggiunto la seconda volta.
| Comparison | What stays fixed | What a difference can mean |
|---|---|---|
| Name against name | The string you typed | Resolver answer, answer order or split-horizon policy changed |
| Address against address | The numeric destination | Source path, filtering or service placement changed |
Risolvi prima, poi scansiona l'indirizzo registrato
Separa la risoluzione dal sondaggio perché i due fatti finiscano in luoghi diversi. Chiedi al sistema cosa ha risolto, salva quella risposta, poi passa a Nmap l'indirizzo letterale. Ripeti gli stessi due comandi con il tunnel abbassato e alzato.
getent hosts scan.example.net dig +short scan.example.net A nmap -Pn -sV -p 443,8443 192.0.2.40
Il flag -Pn conta qui, perché un host che ignora le sonde di scoperta verrebbe altrimenti segnalato come inattivo e il risultato vuoto letto male come porta chiusa. Usa -sV solo contro destinazioni approvate dall'operatore; il sondaggio delle versioni è più rumoroso di una connessione nuda e rientra nel perimetro scritto.
La referenza di specifica degli obiettivi di Nmap dice esplicitamente che un nome host viene risolto a un indirizzo prima della scansione e che, quando tornano più indirizzi, lo strumento scansiona il primo a meno che non li richieda tutti. Niente di questo comportamento è specifico della VPN. Un DNS diviso, un resolver diverso o un bilanciatore di carico che risponde in un ordine nuovo producono lo stesso effetto senza alcun tunnel.
Conserva il valore risolto accanto all'output della scansione, con la famiglia di indirizzi, il set di flag e una marca temporale. Una ricerca inversa che restituisce il nome di un'azienda è un'altra osservazione, non la prova di quale backend abbia risposto.
Cosa può e cosa non può dirti uno stato delle porte cambiato
Una volta fissata la destinazione, una porta che passa da aperta a filtrata di solito indica il percorso. Pensa a un ACL a monte, a un firewall con stato o a un provider che tratta l'uscita del tunnel diversamente dall'uscita residenziale. Restringi provando un secondo indirizzo approvato nella stessa sottorete quando il perimetro lo consente, perché cambiare il nome host reintrodurrebbe la domanda del resolver. Una variabile per esecuzione è tutto il metodo.
Una porta che resta aperta mentre cambia il banner del servizio è un'altra storia. Quello schema si adatta a un front-end che distribuisce connessioni tra backend, e nessuna quantità di scansione da parte tua nominerà l'inquilino dietro.
Ciò che la scansione non dice mai è l'intenzione. Una porta filtrata è un esito di politica, non la prova che qualcuno abbia scelto il tuo tunnel, e una porta aperta non è la prova che l'applicazione dietro ti servirà. Correla con i log del componente che gestisci prima di scrivere l'una o l'altra storia.
Registra i risultati perché il confronto sopravviva alla revisione
Un record utile contiene il nome richiesto, l'indirizzo risolto e la sua famiglia, i flag esatti, l'indirizzo sorgente in uso e l'autorizzazione che copriva la destinazione. Aggiungi l'ora, perché le risposte DNS ruotano e un rapporto senza marche temporali invita due volte la stessa discussione. Aggiungi anche la versione dello scanner, perché il comportamento di sondaggio predefinito cambia tra versioni. Se due esecuzioni hanno usato metodi diversi, trattale come esperimenti distinti e dillo nel titolo, non nella nota a piè di pagina.
Etichetta il risultato per quello che è: destinazioni diverse, percorsi sorgente diversi o una differenza ancora inspiegata. Quel vocabolario mantiene onesto un rapporto di scansione e impedisce che una risposta del resolver venga ripubblicata come evento di intercettazione VPN. Il passo successivo di solito è un'altra esecuzione con l'indirizzo fissato, non una scansione più ampia.