Regole d’ingresso SSH e VPN: cosa controlla davvero la lista di autorizzazione

Seguite una connessione dal client all’host: quale hook attraversa, perché un blocco e un rifiuto significano regole diverse e perché rifiutare non è mai una politica.

Collegatevi una volta prima di modificare una regola e annotate se il client si blocca o viene rifiutato subito. Questa sola differenza vi dice quale decisione ha scartato il pacchetto e risparmia un’ora di lettura dei file di policy. Il resto del percorso è breve: il pacchetto attraversa un hook, corrisponde a una regola e raggiunge un listener oppure no. Una lista di autorizzazione è solo contabilità intorno a questi tre fatti.

Seguite un tentativo SSH fino all’hook di input

Un client invia un SYN all’indirizzo dell’host sulla porta 22, e il kernel decide se quel pacchetto è per un servizio locale. Se lo è, il percorso di input viene eseguito e l’insieme di regole accetta il pacchetto o lo scarta. Il silenzio significa che il SYN è morto prima che il listener lo vedesse, mentre un rifiuto rapido significa che qualcosa ha risposto con un reset. Sono verdetti diversi da regole diverse, ed entrambi sono esiti legittimi.

Poi confermate il listener, perché nessuna regola salva un servizio che non c’è. Eseguite ss -ltnp e verificate che qualcosa sia legato alla porta e alla famiglia di indirizzi che vi aspettate, poi leggete ssh -v sul client per vedere dove si ferma.

L’inoltro è una decisione separata

Su un server VPN l’hook più interessante è forward, perché il traffico del client viene instradato attraverso la macchina invece di esserle consegnato. Un host che esegue solo il proprio client VPN ha bisogno di un insieme di regole molto più piccolo di uno che inoltra i pacchetti di altre persone. Mescolare i due progetti su una sola macchina produce regole che sembrano corrette e non lasciano passare nulla.

Scrivete la politica interna come una domanda a sé: quali indirizzi client possono raggiungere quali destinazioni attraverso il tunnel. Tenete il percorso amministrativo, come SSH, sul percorso di input con la propria restrizione di origine. Una regola forward permissiva aggiunta durante i test è il difetto classico che sopravvive al test, quindi dopo una modifica rileggete l’intero insieme di regole e non la riga che avete modificato. Aprire il listener del tunnel non è un permesso per ogni client connesso di amministrare l’host.

Scartare e rifiutare sono azioni, non politiche

La politica di una catena base accetta o scarta, e questo è l’intero elenco delle scelte, come afferma la documentazione di nftables. Il rifiuto esiste come azione di regola con una risposta scelta, ed è per questo che scriverlo come politica fallisce sia su nftables sia su iptables. In pratica un drop non dà al client alcuna informazione, mentre un reject gli dà un errore su cui può agire.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Leggete quello schizzo come la forma di una decisione e non come un file da incollare, perché gli intervalli di indirizzi sono esempi. Un reject esplicito sulla porta SSH fa fallire un client non autorizzato in un secondo invece di attendere un timeout, il che accorcia il vostro stesso debug. Il silenzio scoraggia la scansione occasionale e non dice assolutamente nulla a un utente autorizzato. Scegliete per servizio e annotate il perché, altrimenti la persona successiva lo rimetterà com’era.

Conservate il traffico di controllo che vi serve davvero

Bloccare tutto l’ICMP è un valore predefinito popolare che rompe la scoperta dell’MTU del percorso, e il sintomo è una connessione che si stabilisce e poi si blocca sui pacchetti più grandi. La scoperta dei vicini su IPv6 dipende dai propri tipi ICMPv6, e scartarli rompe il collegamento prima che venga consultata qualsiasi regola TCP. Entrambi appartengono alla lista di autorizzazione come dipendenze nominate e non come permessi generali. Una politica che rompe la scoperta in silenzio è peggiore di una che ammette un po’ di traffico diagnostico.

Permettete gli stati established e related per le connessioni che avete avviato voi, e lasciate che il motore con stato gestisca le risposte. Poi verificate che il percorso di risposta non sia bloccato più all’esterno, perché una restrizione solo in uscita a monte produce lo stesso timeout che stavate per attribuire all’host.

Dimostrate il ripristino prima di ritirare il vecchio percorso

Tenete aperta una sessione console, applicate la modifica e aprite una connessione di gestione completamente nuova da un altro terminale. Una sessione esistente non dimostra nulla, perché può sopravvivere a una regola che blocca ogni nuovo accesso, il che la rende il falso positivo più convincente del lavoro sui firewall. Se un sistema di monitoraggio controlla l’host, aggiungete il suo indirizzo di origine prima della modifica e non dopo il primo avviso. Poi provate un pacchetto grande e uno piccolo per dimostrare che la scoperta funziona ancora.

Per un servizio VPN, ripetete da un client che non si è mai connesso, perché una sessione ripresa può riutilizzare uno stato che una nuova deve negoziare. Annotate l’insieme esatto di regole che ha superato la prova, con un checksum o una copia, così che una modifica successiva possa essere confrontata invece che indovinata. Coordinatevi con chi possiede l’ordine delle regole, perché una regola precedente vince in silenzio su quella che avete aggiunto.

Articoli correlati