Scenario
Il server FTPS esplicito (ovvero che utilizza la porta canonica TCP 21 per la ricezione dei comandi) si trova dietro un firewall, che filtra sia i tentativi di connessione in ingresso che quelli in uscita. Inoltre, tale firewall è nattato su indirizzo IP pubblico mediante uno screened router.
Anche il client è posizionato dietro un’accoppiata firewall/screened router e proprio per questo motivo si è deciso di utilizzare la modalità FTP passiva piuttosto che quella attiva.
Generazione del certificato
Ecco il comando per generare il certificato X.509 da utilizzare per l’autenticazione della fonte e per la confidenzialità:
nightfly@nightbox:~$ sudo openssl req -new -x509 -nodes -out vsftpd.pem -keyout vsftpd.pem
Configurazione del demone vsftpd
La configurazione del demone vsftpd per abilitare FTPS prevede le seguenti direttive:
rsa_cert_file=/etc/vsftpd.pem rsa_private_key_file=/etc/vsftpd.pem ssl_enable=YES allow_anon_ssl=NO force_local_data_ssl=NO force_local_logins_ssl=YES ssl_tlsv1=YES ssl_sslv2=NO ssl_sslv3=NO require_ssl_reuse=NO ssl_ciphers=HIGH pasv_address=<IP Pubblico Screened Router> pasv_min_port=5012 pasv_max_port=5012
Le prime due righe servono a specificare il pathname del certificato e della chiave privata (a sua volta contenuta nel certificato).
La direttiva:
force_local_data_ssl=NO
fa in modo che il traffico dati non venga cifrato (preferisco usare questa impostazione perchè garantisce una maggiore velocità di trasferimento, l’importante è che vengano cifrati i comandi inviati al server e dunque anche le credenziali di accesso).
Come si evince dallo stralcio di configurazione che ho riportato, il protocollo di cifratura utilizzato è TLS (più robusto del suo predecessore SSL, il quale è stato esplicitamente disabilitato), mentre nelle ultime due righe ho specificato la porta su cui il client potrà instaurare la connessione dati. Tale porta dovrà essere consentita sul firewall, lanciando, ad esempio, il seguente comando (nel caso in cui si abbia a che fare con Netfilter):
iptables -A INPUT -i eth1 -m state --state NEW -m tcp -p tcp --dport 5012 -j ACCEPT
Inoltre, utilizzando il seguente paramentro di configurazione:
pasv_address=<IP Pubblico Screened Router>
si fa in modo che il server risponda al comando PASV inviando l’indirizzo IP pubblico dello screened router anzichè il proprio indirizzo privato. Inoltre, sarà necessario creare, direttamente sul router, un’opportuna regola di port forwarding per la porta TCP 5012.
Occorre precisare che la suddetta direttiva implica che su Netfilter venga abilitato il traffico in ingresso sulla porta in questione, poichè il modulo nf_conntrack_ftp funziona solo ed esclusivamente per i pacchetti che contengono gli indirizzi IP privati della linux box che funge da firewall.
Riavviamo vsftpd:
nightfly@nightbox:~$ sudo service vsftpd restart
e proviamo a connetterci al server, utilizzando un client che supporta FTPS. A tal proposito, vi sconsiglio di utilizzare FireFTP (in quanto presenta diversi bug relativi al protocollo FTPS) e FileZilla Client (perchè pialla la connessione se individua un certificato X.509 non firmato da una CA).
Solo con scopi di test (e per un periodo limitato) potete utilizzare un prodotto shareware, ovvero SmartFTP Client (lo trovate qui).
Enjoy.
Aggiornamento #1
A quanto pare le ultime versioni di FileZilla Client (quella che ho testato personalmente è la 3.17.0.1), consentono le connessioni verso il server FTPS anche in presenza di un certificato X.509 self-signed, a patto che all’interno della configurazione di VSFTPD vi sia la direttiva ssl_ciphers=HIGH.
