Avviso in entrata su un server VPN: leggete il punto di osservazione

Un server dietro una VPN conserva le sue voci di servizio pubbliche, e le persone continuano a trovarle. Ciò che arriva nella coda degli avvisi non è una scoperta ma tre possibili, e significano cose diverse. Il primo compito è separare un servizio esposto da una credenziale esposta.

Percorrete i punti di osservazione in ordine. Fermatevi quando le prove cambiano categoria, perché la fase successiva risponde a un'altra domanda.

Prima fase: cosa ha visto davvero la cattura

Una cattura di pacchetti registra ciò che era visibile nel proprio punto sul percorso. Quel punto può trovarsi prima di una successiva decisione di filtraggio. Un pacchetto catturato dimostra che il traffico è arrivato lì. Non dimostra nulla su ciò che è accaduto dopo.

Guardate anche l'interfaccia. Una cattura sull'adattatore pubblico e una cattura dentro il tunnel descrivono punti di arrivo diversi, e un avviso che cita quello sbagliato porta alla conclusione sbagliata.

Windows filtra anche a più livelli dello stack, quindi il modello ordinato in cui lo strumento di cattura sta al livello due e il firewall al livello tre non sopravvive al contatto con un prodotto reale. La panoramica di Windows Filtering Platform descrive il filtraggio attraverso i livelli dello stack, ed è per questo che l'ordine di osservazione va stabilito invece che presunto.

Seconda fase: cosa stabilisce il record di scarto

Un record di scarto dice che un confine di criterio ha rifiutato quel pacchetto. È una prova solida. È anche una prova stretta, perché copre una decisione a un confine. Nient'altro nello stack viene descritto da essa.

Correlate sulla tupla e sul timestamp. Stessa origine, stessa destinazione, stessa porta, nello stesso secondo. Senza quella corrispondenza, un evento dall'aspetto simile in un altro registro è semplicemente un altro evento, e abbinarli produce una storia che nessuno può difendere.

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

Una porta chiusa e un pacchetto scartato sembrano identici dall'esterno e del tutto diversi in questi due output. Questa differenza è tutta la ragione per leggere il registro locale.

Terza fase: cosa dimostra l'evento di autenticazione

Un evento di autenticazione dice che un componente ha elaborato la richiesta abbastanza da registrare un risultato. È l'unico dei tre stadi che parla di identità, e non dice nulla su quanti pacchetti siano arrivati prima.

Leggete il contesto reale dell'evento. Un accesso non riuscito per un account che non esiste è rumore da scansione. Un accesso non riuscito per un account reale da una fonte plausibile è un'altra priorità. Una sessione riuscita è una categoria di incidente del tutto diversa.

Osservate anche i nomi dei protocolli. RPC e RDP sono servizi separati con porte separate. Un rilevatore che sorveglia uno dei due non copre l'altro. Gli strumenti che riassumono l'attività di rete non dicono sempre quale dei due ha prodotto l'evento.

Un campione correlato batte una dashboard

Scegliete un test autorizzato, eseguitelo di proposito e seguitelo da capo a fondo: indirizzo di destinazione e interfaccia, indirizzo di origine reale, porta del servizio, profilo e regola del firewall efficaci, e il risultato del servizio corrispondente. Includete in quella catena qualsiasi mappatura a monte o firewall cloud, perché una regola permissiva lì può prevalere su una regola locale ben ordinata.

Poi separate i due obblighi. Se l'amministrazione deve avvenire solo via VPN, imponetelo sia sul percorso pubblico sia su quello del tunnel mantenendo una via di ripristino approvata. Sorvegliare un tentativo rifiutato non è lo stesso compito del decidere cosa debba accettare il server.

Una regola geografica o un protocollo non correlato bloccato non sostituiscono la ricerca dell'ingresso osservato e della decisione che ha ricevuto. Nemmeno una VPN: instradare il traffico in uscita attraverso un tunnel non documenta nulla sull'autorizzazione in entrata.