Scegliere il punto di osservazione giusto per una scansione VPN sul telefono
Il listener VPN del telefono, un servizio sul telefono e un host LAN instradato sono tre superfici. Seguite questi cinque passi e fermatevi dove finisce il perimetro.
Una valutazione autorizzata di una VPN ospitata su un telefono fallisce in silenzio quando lo scanner si trova dal lato sbagliato del tunnel. Si ottengono risultati, sembrano plausibili e rispondono a una domanda che nessuno ha posto. Seguite i cinque controlli qui sotto in ordine. Ognuno ha una condizione di arresto, e fermarsi presto costa meno che ritestare da zero dopo aver scritto il rapporto.
Passo 1: nominate la superficie che intendete raggiungere
Tre superfici vengono confuse regolarmente perché un solo dispositivo le collega. Eseguono codice e criteri diversi, quindi annotate quale è nel perimetro prima di iniziare qualsiasi cosa.
| Assessment target | What the path exercises |
|---|---|
| Public VPN listener on the handset | Reachability before login, plus the exposed VPN daemon |
| A service on the handset, by its tunnel address | Access after admission to something hosted locally |
| A LAN host behind the handset gateway | Forwarding, the return path and downstream access policy |
Se il perimetro approvato non dice quale delle tre, fermatevi e chiedete. Ottenere i permessi di root sul telefono non risponde a questa domanda e cambia la cosa sotto test, non il punto di osservazione.
Annotate gli obiettivi, gli indirizzi sorgente consentiti, la finestra temporale e il limite di intensità nello stesso momento. Il tunnel vi porta fino a quel perimetro; non vi autorizza a sondare tutto ciò che può instradare.
Passo 2: scegliete la sorgente che può vedere quella superficie
Uno scanner posto all’interno della VPN non può riprodurre un osservatore internet non autenticato. Ha già rotte, credenziali e permessi che l’osservatore esterno non ha, quindi i suoi risultati descrivono la vista dopo l’ammissione anche quando la superficie obiettivo è la stessa. L’errore inverso è altrettanto comune. Una scansione pubblica della porta VPN non dice quasi nulla su un servizio privato dietro l’accesso, e presentarla come se lo dicesse sovrastima l’esposizione in una direzione e la sottostima nell’altra.
Fermatevi se la sorgente che potete ottenere non corrisponde alla superficie. Una valutazione eseguita da un pari all’interno del tunnel non va presentata come risultato pre-autenticazione, e un test che richiede una sorgente esterna approvata non va spostato in silenzio all’interno per evitare le scartoffie.
Passo 3: confermate la rotta e il percorso di risposta attraverso il telefono
Quando il dispositivo inoltra verso un’altra sottorete, lo scanner ha bisogno di una rotta consentita e l’obiettivo di un percorso di ritorno funzionante. Confermate entrambi invece di supporre che una risposta al ping significhi che il percorso è completo.
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8Il NAT sorgente cambia ciò che vede il servizio a valle. Se il telefono traduce l’indirizzo dello scanner, le regole di accesso e i log sull’obiettivo si applicano all’indirizzo tradotto, quindi un servizio che sembra accettarvi potrebbe accettare il telefono e non lo scanner.
Attenzione anche a una sovrapposizione con la rete dello scanner stesso. Se il telefono instrada 192.168.1.0/24 e lo scanner si trova su una LAN numerata allo stesso modo, le sonde colpiscono dispositivi locali e il rapporto li descrive come l’obiettivo. Verificate la rotta che userebbe lo scanner stesso prima di inviare un solo pacchetto.
Scansionate l’indirizzo reale dell’obiettivo e conservate il nome host che l’applicazione richiede per l’identità TLS e l’hosting virtuale. Raggiungere un gateway dimostra che il gateway risponde; non verifica il servizio dietro di esso.
Passo 4: trattate la scoperta come una sonda con ipotesi
La scoperta degli host è il punto in cui i risultati della valutazione sbagliano più spesso. La scoperta locale via Ethernet non attraversa una VPN instradata, quindi le sonde che funzionano su una LAN piatta semplicemente non arrivano. Le sonde di scoperta bloccate fanno allora sembrare assente un servizio raggiungibile e autorizzato.
Decidete consapevolmente se saltare la scoperta e scansionare direttamente gli indirizzi noti, poi ditelo nel rapporto. Una porta che risponde non è prova che l’autenticazione VPN sia riuscita, e una risposta filtrata non è prova che nulla sia in ascolto. Anche il ritmo fa parte dello stesso problema. Un telefono che limita o scarta pacchetti durante una scansione veloce produce stati filtrati che appartengono al telefono e non al servizio, quindi riducete la concorrenza e riscansionate prima di registrare una porta come chiusa.
La condizione di arresto qui è di interpretazione, non di tecnica: se non potete dire che cosa significa uno stato per questo percorso, il risultato appartiene a un’appendice e non alle conclusioni.
Passo 5: mantenete la finestra, poi chiudetela
Un telefono è un cattivo server perché è progettato per dormire. L’ottimizzazione della batteria, il doze e la gestione dell’energia Wi-Fi possono sospendere l’app a metà valutazione, e una riconnessione del tunnel può cambiare l’indirizzo usato dall’obiettivo. Un’esecuzione che attraversa uno di questi eventi ha una finestra di risultati non valida.
Mantenete il ruolo di gateway nel perimetro più ristretto che il compito approvato consente, osservate il tunnel mentre l’esecuzione è attiva e registrate inizio e fine di ogni finestra che riportate. Al termine della valutazione, rimuovete l’accesso temporaneo tramite il suo proprietario, conservate il record di sorgente e percorso e proteggete l’output come qualsiasi altro artefatto di test.
Se avete bisogno di un punto di osservazione ripetibile invece di un successo una tantum, è il deliverable per cui vale la pena argomentare. il riferimento sulla scoperta degli host spiega quali sonde presuppongono un segmento locale, ed è questo dettaglio che trasforma un risultato vuoto in un’affermazione difendibile.