Dove finisce la protezione della VPN sulla strada verso un server FTP

Una VPN protegge un percorso, e ogni percorso ha una fine. Quando il tunnel termina su un gateway aziendale, il trasferimento di file prosegue da lì con la protezione offerta dal suo stesso protocollo. Questa distinzione decide se un trasferimento è protetto da un capo all’altro o solo fino al gateway. L’indicatore Connected non dice nulla né dell’uno né dell’altro.

Due collocazioni, due percorsi rimanenti

Prendete un portatile che si unisce alla VPN aziendale e poi apre una sessione FTP verso un server interno separato. Il tunnel si ferma al gateway, e il tratto dal gateway a quel server resta fuori.

L’FTP semplice non acquisisce crittografia perché i suoi pacchetti sono arrivati attraverso un tunnel. Su quel tratto rimanente i comandi, le credenziali e il contenuto dei file viaggiano esattamente come li definisce il protocollo, cioè in chiaro. Se questo conti dipende dalla topologia e da che altro protegge il tratto, e chiamare privato l’indirizzo non risponde alla domanda. Lo stesso ragionamento vale al contrario quando il server vive in una rete cloud che il gateway raggiunge con un altro salto.

Mettete l’endpoint della VPN e il servizio FTP su una sola macchina e non c’è alcun tratto successivo di cui preoccuparsi. È un’altra collocazione, non una prova che i processi, i file e le credenziali dell’host siano al sicuro.

FTP semplice, FTPS e SFTP sono tre decisioni

L’FTP semplice non crittografa nulla, nemmeno la password. FTPS aggiunge TLS a FTP, così il canale di controllo e, quando viene negoziato, il canale dati sono protetti. SFTP è un protocollo diverso trasportato dentro SSH, e non è un’altra grafia di FTPS.

Il server deve supportare questa scelta, perché un client non può inventare un listener che non c’è. Scegliere SFTP non trasforma un servizio solo FTP in un endpoint SSH, e rinominare un segnalibro o cambiare una porta non prova nulla su ciò che è stato negoziato. Confermate il protocollo sia dal lato server sia dal lato client. Un lucchetto in un gestore di file è un’affermazione sulla sessione, non sul listener che sta dietro.

Leggete l’ultima colonna quando il trasferimento conta, perché è lì che compare un cambio di identità inatteso.

La connessione dati è una seconda connessione

FTP apre una connessione di controllo e poi connessioni dati separate per gli elenchi e i trasferimenti. Un accesso protetto non dice nulla su quelle connessioni successive, a meno che il deployment richieda protezione anche per loro.

Con FTPS il client chiede un canale dati protetto tramite un comando specifico, e una politica del server può rifiutare l’alternativa in chiaro. Verificate che la politica lo richieda invece di supporre che l’impostazione predefinita del client basti. La modalità passiva aggiunge una seconda complicazione, perché il server annuncia un indirizzo e una porta per la connessione dati. Un firewall o un dispositivo NAT che riscrive o blocca quell’annuncio produce una sessione che si autentica e poi si blocca al primo elenco.

curl -vk ftps://files.corp.example/ --user alice --ftp-ssl-control
openssl s_client -connect files.corp.example:21 -starttls ftp
ss -tnp | grep -E ':21|:990'

Il secondo comando mostra cosa presenta il server sul canale di controllo prima di toccare qualsiasi file. Il terzo mostra se una connessione dati è mai stata stabilita, che è la differenza tra un errore di autenticazione e un errore della modalità passiva.

I controlli di identità sopravvivono al tunnel

Un client FTPS convalida l’identità di un server TLS, e un client SFTP convalida una chiave host SSH. Entrambi i controlli appartengono al protocollo di trasferimento file, e nessuno dei due è eseguito dalla VPN.

Questa separazione conta quando qualcosa nel mezzo vuole ispezionare la sessione. Disattivare TLS perché un apparato di rete possa leggere i comandi cambia il modello di protezione invece di completarlo, e lo stesso vale per accettare una chiave host inspiegata perché il tunnel è salito. Mantenete la configurazione di fiducia prevista e procuratevi il materiale corretto dall’operatore. Un tunnel che si autentica non dice nulla sul server alla sua estremità remota.

Il materiale di chiave privata e certificato per questi protocolli è un terzo segreto, separato dalle credenziali della VPN.

Annotate cosa avete verificato davvero

Scegliete un file innocuo che siete autorizzati a spostare e annotate quattro fatti sul tentativo: quale protocollo ha girato, quale identità della controparte è stata controllata, quale percorso era previsto e se il trasferimento è terminato.

lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]

Un elenco di directory, un accesso al tunnel e un trasferimento completato sono tre osservazioni separate, e solo l’ultima dice che il percorso funziona per i file. Se il progetto si affida solo alla VPN per la riservatezza sul salto rimanente, scrivetelo come la decisione che è. Una nota di accettazione che nomina il salto e la sua ipotesi di fiducia vale più di uno screenshot di un client connesso.