Gli avvisi di accesso VPN non sono avvisi di intrusione: osserva la sessione

Un avviso VPN che scatta per un nuovo paese sembra conclusivo, e di solito non lo è. L'autenticazione dice che un tentativo è stato accettato; la sessione dice quale connessione lo ha portato; i record delle risorse dicono cosa è successo dentro quella connessione. Ognuno risponde a una domanda diversa. Una regola che fonde tutti e tre produce trenta ticket di lunedì e manca il caso reale di venerdì.

Un indirizzo straniero è una domanda, non una risposta

I viaggi, gli operatori mobili che escono in un altro paese, un proxy web aziendale e un pool NAT di operatore riassegnato spostano tutti la sorgente apparente senza spostare l'attaccante. Il record di accesso riflette da dove la connessione è entrata nella rete, non chi teneva il dispositivo.

Il fallimento inverso è peggiore perché è silenzioso. Una password rubata usata dalla città dell'utente stesso produce un accesso che corrisponde a tutti i precedenti nel controllo geografico.

Trattare la geografia come verdetto ha un costo misurabile. I portatili in viaggio generano un flusso costante di revisioni, i revisori imparano a chiuderle senza leggerle, e l'abitudine sopravvive finché un caso reale arriva nella stessa coda.

Tre tipi di record rispondono a tre domande diverse

Parti da ciò che i prodotti distribuiti emettono davvero, non da ciò che un opuscolo suggerisce che potrebbero emettere. La decisione di autenticazione nomina l'identità dichiarata, il metodo e il risultato. Il ciclo di vita della sessione nomina la connessione, il gateway e l'indirizzo assegnato, dall'inizio all'arresto.

Una cella vuota è un buco nella raccolta, non un'assoluzione. Se gli eventi delle risorse non arrivano mai, l'assenza di una lettura sospetta significa che la pipeline non ha nulla da segnalare, e una dashboard silenziosa descrive la pipeline, non la rete. Annota quali record produce davvero la distribuzione prima di promettere una regola che ne dipende, e nomina il proprietario di ogni feed mancante.

Il dettaglio contabile è dove le sessioni diventano verificabili. La contabilità RADIUS descritta in RFC 2866 porta aggiornamenti di inizio, arresto e intermedi legati a un identificatore di sessione, quindi una sessione con un inizio e senza arresto è un buco che puoi nominare invece di un mistero.

Unisci sulla sessione, non sul nome utente

Un account detiene legittimamente più sessioni insieme: un portatile, un telefono, una macchina di laboratorio lasciata connessa tutta la notte. Unire ogni evento di quel nome utente fonde tre dispositivi in una storia e poi legge la combinazione come compromissione. Anche gli indirizzi assegnati vengono riciclati, quindi un join che continua a corrispondere a un indirizzo dopo la fine della sessione trascina il dispositivo del mese scorso nell'incidente di oggi. Conserva la chiave di sessione accanto all'indirizzo e limita la corrispondenza alla finestra temporale che la sessione ha davvero coperto.

Dove la traduzione rimuove la sorgente originale prima che un servizio la veda, usa l'identità che sopravvive a quel confine, come un soggetto TLS reciproco o un'asserzione di accesso singolo. Inventare una corrispondenza uno a uno tra un indirizzo e una persona è lo stesso errore con passaggi extra.

Un avviso senza proprietario è una dashboard

Ogni regola richiede una condizione, le spiegazioni innocue che la producono, le prove da raccogliere e la persona che agisce. Un'operazione amministrativa negata ripetuta, un picco di password fallite e un raccoglitore silenzioso sono tre incidenti diversi con tre orologi diversi.

La notifica non è il contenimento, e una lista di distribuzione non limita nulla. Cambiare una sessione attiva richiede il componente che può farlo, che sia il gateway che chiude la connessione o il provider di identità che revoca la sessione. Anche i feed obsoleti e i record di arresto mancanti appartengono al testo della regola, perché un raccoglitore che non ha inviato nulla per un giorno sembra esattamente una rete silenziosa dalla dashboard. La differenza si vede solo nella pipeline stessa.

Controlla il percorso di raccolta prima di fidarti di una settimana tranquilla

Dimostra la pipeline da un capo all'altro prima di regolare una sola regola. I comandi seguenti confermano che gli ascoltatori di autenticazione e contabilità sono attivi, che una credenziale di prova viene rifiutata per il motivo giusto e che gli eventi di sessione continuano ad arrivare:

ss -uanp | grep -E ':(1812|1813)\b'
radtest alice 'not-the-password' 127.0.0.1 0 testing123
journalctl -u openvpn-server@server --since '-30 min' | grep -c 'Peer Connection Initiated'
timedatectl | grep -E 'System clock|synchronized'

Un Access-Reject dal test dimostra che la richiesta ha raggiunto il server e che il segreto condiviso corrispondeva, ed è la parte che la gente salta. Un timeout invece punta al segreto, all'ascoltatore o a un filtro davanti a esso, e ogni avviso a valle è inverificabile finché non viene corretto.

Lo stato dell'orologio conta perché le finestre di correlazione presuppongono un accordo. Un gateway sfasato di qualche minuto rende impossibile un join di sessione altrimenti pulito, e i revisori compensano allargando la finestra finché il join smette di discriminare. Controlla lo scostamento prima di modificare la regola.

Poi prova una regola con un test innocuo: genera un accesso da un indirizzo inatteso, verifica che l'avviso scatti, verifica che chi risponde possa estrarre la sessione e i suoi eventi sulle risorse, e verifica che il ticket porti l'identificatore di sessione. Una regola che produce una storia coerente passa. Una regola che produce una pila di righe di log è ancora una dashboard. Registra il risultato accanto alla regola perché la prossima revisione parta da prove e non da intuizioni.