Per quanto il protocollo ftp sia piuttosto datato, viene ancora spesso utilizzato per trasferire dati in rete. Può però accadere che ci siano problemi nelle connessioni: a volte il client FTP si autentica, il server accetta le credenziali, ma la sessione rimane sospesa e non si riesce a inviare o scaricare alcun dato. Vediamo perché e come risolvere il problema.
Come è noto FTP usa due porte diverse per il trasferimento di comandi e dati. Mentre tutti i comandi vengono inviati dal client alla porta 21, il trasferimento dei dati avviene (di default) dalla porta 20 del server. Questo richiede l’apertura di due sessioni TCP distinte.

La sessione traffico dei dati può essere avviata in due modalità: attiva e passiva. La più tradizionale modalità attiva prevede che il client indichi al server su quale numero di porta (del client) avviare la sessione dati. Questa porta viene indicata dal client stesso al server mediante il comando PORT. A questo punto il server avvia una sessione TCP verso il client dalla porta 20 alla porta indicata dal client.

Per fissare le idee supponiamo che il client abbia l’indirizzo IP 2.2.2.2 ed il server abbia indirizzo IP 1.1.1.1

Il comando ha il formato

PORT (a,b,c,d,x,y)

in cui a,b,c,d indicano l’indirizzo IP a.b.c.d del client, e x,y il numero di porta su cui il client accetterà la connessione, dato dalla semplice formula

numero di porta = x * 256 + y

Ad esempio il comando

PORT (2,2,2,2,100,1)

indica che il client all’indirizzo 2.2.2.2 accetterà connessioni sulla
porta 256*100+1 = 25601.

A questo punto il server 1.1.1.1:20 avvia una richiesta di sessione con 2.2.2.2:25601, inviando un SYN e l’usuale handshaking a tre vie ha luogo (abbiamo indicato con a.b.c.d:n indirizzo ip a.b.c.d e n numero della porta coinvolta).

FTP e NAT

Fin qui tutto bene. Questo sistema di connessione funziona tutte le volte che non abbiamo nat e firewall. Quando inseriamo firewall e nat cominciano i guai: quante volte abbiamo visto post che iniziano con “ho configurato ftp su un server, e da LAN accedo senza problemi, ma da internet il client si autentica ma non riesco ad aprire la cartella FTP”.

Tanto per cominciare di solito il client è alle spalle di un router che svolge due funzioni: nat e (spesso) firewall. Il client in questo caso non ha indirizzo 2.2.2.2. Questo è l’indirizzo esterno del router, o meglio ancora su cui il router esegue NAT.

Il client si trova su un indirzzo interno, supponiamo 192.168.0.100. Quando arriva dall’esterno la richiesta di aprire una sessione con 2.2.2.2:25601 il router dovrebbe inviarla a 192.168.0.100:25601. Non avendo alcuna indicazione in merito nella sua tabella di nat per quel numero di porta, lascia cadere la sessione (non risponde o invia un RST).

Naturalmente esiste una soluzione: possiamo costruire delle tabelle di nat statico, ed inserire le opportune regole nel firewall; molti router domestici consento di definire un indirizzo di DMZ e trasferire ad esso tutto il traffico che arriva sull’interfaccia esterna del router.

La soluzione non è però molto praticabile: richiede ai singoli utenti di intervenire sul proprio router per poter accedere ad un server FTP. Dato che di solito si sceglie di usare FTP per la sua semplicità, non possiamo aspettarci che ogni utente si riconfiguri il router per accedere al server. Esiste un caso in cui questo meccanismo funziona bene su rete geografica (cioè non sulla stessa LAN): molti telefoni cellulari che prendono per navigare IP pubblici (nessuna tabella di nat dalla loro parte). Vedremo dunque che magari il nostro smarthone riesce ad entrare sul server, mentre il nostro PC raggiunge il server FTP, si autentica, e poi non riesce ad andare oltre i primi comandi perché non può effettuare trasferimento dati.

FTP in modalità Passiva

Per ovviare al problema del router lato client possiamo usare la modalità passiva del server FTP. In questo caso il comando PASV inviato da client a server, indica la richiesta di aprire una sessione da client a server (non da server a client) su una porta che il server indicherà al client.

Si usa il comando PASV, che ha sintassi molto simile a quella del comando PORT; alla richiesta PASV inviata dal client, il server risponde:

PASV(a,b,c,d,x,y)

vale a dire il server dice al client “apri una sessione con me all’indirizzo a.b.c.d sulla porta x*256+y”.

Il problema firewall e nat del client è risolto. E’ il client ad originare l’apertura di sessione dati verso il server e quindi il router del client inserisce la opportuna entry nella tabella di nat. In questo modo funziona tutto.

Quasi.

Chi ha mai visto un server FTP su internet pubblicato direttamente su un IP pubblico?

Normalmente il server è protetto da un firewall. Andiamo allora verso un caso un po’ più reale: quello in cui il server sia alle spalle di un firewall (con indirizzo 10.0.0.10) e sia il firewall ad avere indirizzo IP 1.1.1.1

In questo caso il server risponde alla richiesta PASV del client inviando

PASV(10,0,0,10,100,1).

L’indirizzo 10.0.0.10 non è raggiungibile dal client; se usiamo Filezilla, il client ci comunica proprio che è stato usato un indirizzo non raggiungibile da internet, ma appartenente ad una classe privata; la connessione è nuovamente impossibile.
Tuttavia il firewall, se è abbastanza evoluto, può fare una cosa meravigliosa: ispezionare il payload dei pacchetti FTP e modificarli. I Cisco PIX e ASA ad esempio lo fanno (certamente anche molti altri). In questo caso è il firewall che si prende cura di aprire il payload del pacchetto, sostituire l’indirizzo 10.0.0.1 con 1.1.1.1 e spedire al client il comando PASV con il corretto indirizzo pubblico del server. Quando il client replica indirizzando pacchetti a 1.1.1.1:25601 il firewall provvederà a nattarli verso 10.0.0.10:25601.

Così funziona tutto.

Non sempre.

Inviare in PASV l’IP pubblico

Fa eccezione un caso: cosa accade se il firewall è alle spalle di un router che effettua a sua volta NAT? Non è un caso infrequente, anzi.

A questo punto un disegno ci aiuta a seguire meglio ciò che accade:

La rete aziendale ha un router, alle cui spalle si trova il firewall che protegge, tra gli altri, il server fp.

Il server FTP ha indirizzo 10.0.0.10/24. Risponde alla richiesta PASV del client inviando
PASV (10,0,0,10,100,1)

Il firewall doverosamente ispeziona il payload, trova l’indirizzo 10.0.0.10 e lo sostituisce con l’indirizzo con cui natta il server sulla sua interfaccia esterna. Il payload a questo punto vale
PASV(10,10,10,10,100,1)

e viene inviato dall’indirizzo IP 10.10.10.10:21

Il router, configurato per rendere raggiungibile il server FTP dall’esterno, altrettanto doverosamente cambia l’IP di trasmissione da 10.10.10.10 a 1.1.1.1 (sempre dalla porta 21).

Il client riceve dunque un pacchetto FTP PASV da indirizzo 1.1.1.1:21, come dovrebbe essere, ma il payload contiene il valore PASV(10,10,10,10,100,1) perché il router non ha ispezionato il payload. Il povero client usale informazioni contenute in PASV cerca di connettersi con 10.10.10.10:25601 e non ci riesce.

Abbiamo due soluzioni poossibili: o abbiamo un router in grado di effettuare l’ispezione del payload e modificarlo, o rinunciamo completamente all’ispezione del payload e configuriamo il server per inviare il proprio IP pubblico. Il server Filezilla consente di farlo, ad esempio.

In questo caso il server FTP invia il comando PASV(1,1,1,1,100,1) cheè quello che desideriamo. Attenzione, dovremo provvedere a nattare staticamente ed aprire le porte che pensiamo di rendere disponibili per FTP passivo. Non solo: dobbiamo rimuovere l’ispezione del payload. Altrimenti il firewall (almeno ASA) considera il payload (che viaggia con IP pubblico da rete con IP privato) non autorizzato, ed esegue il drop del pacchetto.

In fondo è facile, no? Alla prossima