Come limitare l’accesso tra due uffici collegati da VPN

Un tunnel da sito a sito risponde a una domanda, se i due uffici possono scambiarsi pacchetti, e lascia aperta quella importante: quale dispositivo della sede può raggiungere quale servizio centrale. Trattare il tunnel come fiducia reciproca è il modo in cui un portatile ospite finisce sullo stesso percorso del server finanziario. La soluzione non è un tunnel migliore, ma un elenco di autorizzazioni esplicito applicato dopo la decifratura. Questa guida porta quell’elenco dalla definizione a un rifiuto dimostrato.

Lavorate in questo ordine e non allargate la rotta del tunnel finché i passaggi di policy qui sotto non passano.

Scrivete la matrice prima di toccare il gateway

Una riga utile nomina tre cose: un gruppo di origine, un host o una rete di servizio di destinazione, e il protocollo e la porta che l’applicazione usa davvero. La sede e il data center non sono voci. Il DNS privato e i servizi di autenticazione meritano righe proprie solo quando l’applicazione non può funzionare senza.

Raggruppate le origini per ruolo e non per comodità di sottorete: personale, ospiti, amministrazione. Quando tutte e tre condividono una LAN piatta, il gateway non può distinguerle a livello di rete, quindi i controlli di identità o la segmentazione devono venire prima. Poi mettete la matrice per iscritto con un responsabile e una data di revisione su ogni riga.

Applicate dove i pacchetti vengono decifrati

Le regole che consentono IKE ed ESP costruiscono solo il tunnel esterno. Il traffico interno arriva in chiaro sull’interfaccia del tunnel, ed è lì che va l’elenco delle autorizzazioni: una catena di inoltro sul dispositivo che decifra, scarto predefinito, una regola per riga della matrice. Sui gateway Linux questo significa inoltro abilitato e regole di filtro sul dispositivo del tunnel, non sul collegamento fisico, come spiega la guida all’inoltro di strongSwan.

I selettori di traffico sono una decisione di routing, non di autorizzazione. Un selettore ampio che copre entrambe le sottoreti può essere giusto per il routing mentre il firewall consente ancora solo TCP 443 verso un host. Il selettore viene negoziato per il tunnel e descrive cosa può entrarvi, non cosa può usare un dato dispositivo. Non allargate mai una regola del firewall perché il selettore è ampio.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT e sottoreti sovrapposte cambiano le regole

Quando il gateway della sede traduce ogni host in un solo indirizzo prima del tunnel, ogni riga basata sull’origine collassa in quell’unico indirizzo. O smettete di tradurre il traffico del tunnel, o accettate che le regole debbano basarsi su altro, come l’indirizzo di origine originale registrato prima della traduzione. L’estremità remota ha lo stesso problema, perché l’host di destinazione vede l’indirizzo dopo il NAT e non quello originale.

Gli intervalli sovrapposti sono l’altra trappola. Due uffici che usano entrambi 192.168.1.0/24 non si possono descrivere in un’unica tabella di policy senza mappare un lato, e una mappatura non sostituisce un indirizzamento che non va in collisione. Correggete il piano prima di scrivere regole che dovrete poi sciogliere.

Dimostrate un rifiuto, non solo un successo

Testare solo l’applicazione consentita dimostra molto poco, perché una regola permissiva da qualche parte a monte produce lo stesso risultato.

Da un dispositivo ordinario della sede, raggiungete il servizio previsto e confermate che l’intera sessione funziona. Poi provate una destinazione che deve restare chiusa, come una porta amministrativa su un server con cui la sede non ha nulla a che fare, e leggete il contatore o la voce di log che l’ha scartata. Disattivare l’insieme di regole per verificare se funziona invalida il test e lascia il gateway aperto mentre guardate.

Mantenete vivo l’elenco

Le applicazioni si spostano, e una regola che sopravvive alla sua applicazione diventa un buco che nessuno possiede. Legate la data di revisione alla riga e cambiate l’ambito del selettore e la regola del firewall nello stesso passo di manutenzione quando un servizio cambia indirizzo.

Le restrizioni a livello di host contano ancora dietro il tunnel: il firewall del server stesso dovrebbe accettare l’intervallo della sede solo per il servizio che pubblica. Due livelli che concordano sono più facili da verificare di un solo livello di cui ci si fida completamente.