Introduzione
Una delle domande più frequenti quando si affrontano firewall e altri problemi di connettività Internet è la differenza tra FTP (File Transfer Protocol) attivo e passivo e il modo migliore per supportare uno o entrambi. Si spera che il testo seguente aiuti a chiarire parte della confusione su come supportare FTP in un ambiente protetto da firewall.
Questo post include esempi di sessioni FTP della riga di comando sia attive che passive. Questi esempi di sessione dovrebbero aiutare a rendere le cose un po' più chiare. Forniscono anche una bella immagine di ciò che accade dietro le quinte durante una sessione FTP. Ora, alle informazioni...
Nozioni di base
FTP è un servizio basato esclusivamente su TCP. Non esiste un componente UDP su FTP. FTP è un servizio insolito in quanto utilizza due porte, una porta "dati" e una porta "comando" (nota anche come porta di controllo). Tradizionalmente queste sono la porta 21 per la porta di comando e la porta 20 per la porta dati. La confusione inizia però quando scopriamo che, a seconda della modalità, la porta dati non è sempre sulla porta 20.
FTP attivo
In modalità attiva FTP il client si connette da una porta casuale non privilegiata (N> 1024) alla porta di comando del server FTP, la porta 21. Quindi, il client inizia ad ascoltare la porta N+1 e invia il comando FTP PORT N+1 all'FTP server. Il server si ricollegherà quindi alla porta dati specificata del client dalla sua porta dati locale, che è la porta 20.
Dal punto di vista del firewall lato server, per supportare FTP in modalità attiva è necessario aprire i seguenti canali di comunicazione:
- Porta 21 del server FTP da qualsiasi luogo (il client avvia la connessione)
- Porta 21 del server FTP a porte> 1024 (il server risponde alla porta di controllo del client)
- Porta 20 del server FTP a porte> 1024 (il server avvia la connessione dati alla porta dati del client)
- Porta 20 del server FTP dalle porte> 1024 (il client invia gli ACK alla porta dati del server)
Una volta estratta, la connessione appare come segue:
- Dalla porta client 1026 (Cmd) alla porta server 21 (Cmd)
- Dalla porta Server 21 (Cmd) alla porta Client 1026 (Cmd)
- Dalla porta server 20 (dati) alla porta client 1027 (dati)
- Dalla porta client 1027 (dati) alla porta server 20 (dati)
Nel passaggio 1, la porta di comando del client contatta la porta di comando del server e invia il comando PORT 1027. Il server invia quindi un ACK alla porta di comando del client nel passaggio 2. Nel passaggio 3 il server avvia una connessione sulla sua porta dati locale a la porta dati specificata in precedenza dal client. Infine, il client invia un ACK come mostrato nel passaggio 4.
Il problema principale con FTP in modalità attiva in realtà ricade sul lato client. Il client FTP non effettua la connessione effettiva alla porta dati del server:dice semplicemente al server su quale porta è in ascolto e il server si riconnette alla porta specificata sul client. Dal firewall lato client sembra essere un sistema esterno che avvia una connessione a un client interno, qualcosa che di solito è bloccato.
Esempio FTP attivo
Di seguito è riportato un esempio reale di una sessione FTP attiva. Le uniche cose che sono state modificate sono i nomi dei server, gli indirizzi IP e i nomi utente. In questo esempio viene avviata una sessione FTP da user01 (192.0.0.1), un solaris box che esegue il client FTP standard della riga di comando, a dest_serv (192.0.0.2), un solaris box che esegue solaris[TM] 9 ftpd . Il flag di debug (-d) viene utilizzato con il client FTP per mostrare cosa sta succedendo dietro le quinte. Tutto in corsivo è l'output di debug che mostra i comandi FTP effettivi inviati al server e le risposte generate da tali comandi.
Ci sono alcune cose interessanti da considerare su questa finestra di dialogo. Si noti che quando viene emesso il comando PORT, specifica una porta sul sistema client (192.0.0.1), anziché sul server. Vedremo il comportamento opposto quando utilizziamo FTP passivo. Mentre siamo in argomento, una breve nota sul formato del comando PORT. Come puoi vedere nell'esempio seguente, è formattato come una serie di sei numeri separati da virgole. I primi quattro ottetti sono l'indirizzo IP mentre i secondi due ottetti costituiscono la porta che verrà utilizzata per la connessione dati. Per trovare la porta effettiva moltiplica il quinto ottetto per 256 e quindi aggiungi il sesto ottetto al totale. Quindi nell'esempio sotto il numero di porta è ( (256*188) + 231), o 48359. Un rapido controllo con netstat dovrebbe confermare queste informazioni.
$ ftp -d dest_serv Connected to dest_serv. 220 dest_serv FTP server ready. Name (dest_serv:boqueron): root ---> USER root 331 Password required for root. Password: ---> PASS XXXX 230 User root logged in. ---> SYST 215 UNIX Type: L8 Version: SUNOS Remote system type is UNIX. ---> TYPE I 200 Type set to I. Using binary mode to transfer files. ftp> ls ---> PORT 192,0,0,1,188,231 200 PORT command successful. ---> TYPE A 200 Type set to A. ---> NLST 150 Opening ASCII mode data connection for file list. TT_DB bin (...) var vol xfn 226 Transfer complete. 191 bytes received in 0.03 seconds (6.16 Kbytes/s) ---> TYPE I 200 Type set to I. ftp> quit ---> QUIT 221-You have transferred 0 bytes in 0 files. 221-Total traffic for this session was 599 bytes in 1 transfers. 221-Thank you for using the FTP service on dest_serv. 221 Goodbye. # netstat -a | grep 48359 dest_serv.ftp-data user01.48359 33580 0 49640 0 TIME_WAIT
FTP passivo
Per risolvere il problema del server che avvia la connessione al client è stato sviluppato un metodo diverso per le connessioni FTP. Questa era nota come modalità passiva, o PASV, dal comando utilizzato dal client per comunicare al server che è in modalità passiva.
In modalità FTP passiva il client avvia entrambe le connessioni al server, risolvendo il problema dei firewall che filtrano la connessione della porta dati in ingresso al client dal server. Quando si apre una connessione FTP, il client apre localmente due porte casuali senza privilegi (N> 1024 e N+1). La prima porta contatta il server sulla porta 21, ma invece di emettere un comando PORT e consentire al server di riconnettersi alla sua porta dati, il client emetterà il comando PASV. Il risultato è che il server apre quindi una porta casuale senza privilegi (P> 1024) e invia il comando PORT P al client. Il client avvia quindi la connessione dalla porta N+1 alla porta P sul server per trasferire i dati.
Dal punto di vista del firewall lato server, per supportare FTP in modalità passiva è necessario aprire i seguenti canali di comunicazione:
- Porta 21 del server FTP da qualsiasi luogo (il client avvia la connessione)
- Porta 21 del server FTP a porte> 1024 (il server risponde alla porta di controllo del client)
- Porte del server FTP> 1024 da qualsiasi luogo (il client avvia la connessione dati alla porta casuale specificata dal server)
- Porte del server FTP> 1024 a porte remote> 1024 (il server invia ACK (e dati) alla porta dati del client)
Quando viene disegnata, una connessione FTP in modalità passiva ha il seguente aspetto:
- Dalla porta client 1026 (Cmd) alla porta server 21 (Cmd)
- Dalla porta Server 21 (Cmd) alla porta Client 1026 (Cmd)
- Dalla porta client 1027 (dati) alla porta server 2024
- Dalla porta Server 2024 (Cmd) alla porta Client 1027 (Dati)
Nel passaggio 1, il client contatta il server sulla porta di comando ed emette il comando PASV. Il server risponde quindi al passaggio 2 con PORT 2024, indicando al client quale porta è in ascolto per la connessione dati. Nel passaggio 3 il client avvia quindi la connessione dati dalla sua porta dati alla porta dati del server specificata. Infine, il server invia un ACK nel passaggio 4 alla porta dati del client.
Sebbene l'FTP in modalità passiva risolva molti dei problemi dal lato client, apre un'intera gamma di problemi dal lato server. Il problema più grande è la necessità di consentire qualsiasi connessione remota a porte con numero elevato sul server. Fortunatamente, molti demoni FTP, incluso il demone solaris in.ftpd, consentono all'amministratore di specificare un intervallo di porte che il server FTP utilizzerà. Vedere l'Appendice 1 per ulteriori informazioni.
Il secondo problema riguarda il supporto e la risoluzione dei problemi dei client che supportano (o non supportano) la modalità passiva. Ad esempio, l'utilità FTP della riga di comando fornita con il daemon ftp di Solaris supporta la modalità passiva a partire da Solaris 9 (a partire da sccs v1.20). Dai un'occhiata alle pagine man (in.ftpd), opzione -p.
Con l'enorme popolarità del World Wide Web, molte persone preferiscono utilizzare il proprio browser Web come client FTP. La maggior parte dei browser supporta solo la modalità passiva quando si accede agli URL ftp://. Questo può essere positivo o negativo a seconda di ciò che i server e i firewall sono configurati per supportare.
Esempio FTP passivo
Di seguito è riportato un esempio reale di una sessione FTP passiva. Le uniche cose che sono state modificate sono i nomi dei server, gli indirizzi IP e i nomi utente. In questo esempio viene avviata una sessione FTP da user01 (192.0.0.1), un solaris box che esegue il client della riga di comando FTP standard, a dest_serv (192.0.0.2), un solaris box che esegue solaris 9 ftpd. Il flag di debug (-d) viene utilizzato con il client FTP per mostrare cosa sta succedendo dietro le quinte. Tutto in corsivo è l'output di debug che mostra i comandi FTP effettivi inviati al server e le risposte generate da tali comandi. Il normale output del server è mostrato in nero e l'input dell'utente è in grassetto .
Notare la differenza nel comando PORT in questo esempio rispetto all'esempio FTP attivo. Qui vediamo una porta aperta sul sistema server (192.0.0.2), piuttosto che sul client. Vedi la discussione sul formato del comando PORT sopra, nella sezione Esempio FTP attivo.
$ ftp -d dest_serv Connected to dest_serv. 220 dest_serv FTP server ready. Name (dest_serv:boqueron): root ---> USER root 331 Password required for root. Password: ---> PASS XXXX 230 User root logged in. ---> SYST 215 UNIX Type: L8 Version: SUNOS Remote system type is UNIX. ---> TYPE I 200 Type set to I. Using binary mode to transfer files. ftp> passive Passive mode on. ftp> ls ---> PASV 227 Entering Passive Mode (192,0,0,2,7,176) ---> TYPE A 200 Type set to A. ---> NLST 150 Opening ASCII mode data connection for file list. TT_DB bin cdrom (...) vol xfn 226 Transfer complete. 191 bytes received in 0.027 seconds (7.04 Kbytes/s) ---> TYPE I 200 Type set to I. ftp> quit ---> QUIT 221-You have transferred 0 bytes in 0 files. 221-Total traffic for this session was 599 bytes in 1 transfers. 221-Thank you for using the FTP service on dest_serv. 221 Goodbye.
Riepilogo
Il seguente grafico dovrebbe aiutare gli amministratori a ricordare come funziona ciascuna modalità FTP:
Active FTP : command : client >1024 -> server 21 data : client >1024 <- server 20 Passive FTP : command : client >1024 -> server 21 data : client >1024 -> server >1024
È necessario anche un rapido riepilogo dei pro e dei contro dell'FTP attivo rispetto a quello passivo:
FTP attivo è vantaggioso per l'amministratore del server FTP, ma è dannoso per l'amministratore lato client. Il server FTP tenta di stabilire connessioni a porte alte casuali sul client, che quasi sicuramente sarebbero bloccate da un firewall sul lato client. FTP passivo è vantaggioso per il client, ma dannoso per l'amministratore del server FTP. Il client effettuerà entrambe le connessioni al server, ma una di esse sarà su una porta alta casuale, che sarebbe quasi certamente bloccata da un firewall lato server.
Fortunatamente, c'è un po' di compromesso. Poiché gli amministratori che eseguono server FTP dovranno rendere i propri server accessibili al maggior numero di client, quasi sicuramente dovranno supportare FTP passivo. L'esposizione delle porte di alto livello sul server può essere ridotta al minimo specificando un intervallo di porte limitato da utilizzare per il server FTP. Pertanto, tutto tranne questo intervallo di porte può essere protetto da firewall lato server. Sebbene ciò non elimini tutti i rischi per il server, lo riduce enormemente. Vedere l'Appendice 1 per ulteriori informazioni.