Quanto insicuro ... davvero ... è FTP?

Con il semplice FTP le credenziali vengono passate in chiaro e quindi possono essere facilmente annusate. Inoltre, i file non solo vengono inviati in chiaro, ma non sono nemmeno protetti da modifiche, ad esempio un uomo attivo nel mezzo potrebbe cambiare i file al volo. Pertanto, i rischi sono simili al semplice HTTP, vale a dire che potrebbe andare bene all'interno di una rete fidata ma è una cattiva idea se non ci si può fidare completamente della rete.

Le credenziali vengono trasferite in testo chiaro, ma lo sai dagli altri post. Ma quanto è facile ottenere quei dettagli?

Come esempio, ho eseguito tcpdump e connesso a un server FTP. Diamo un'occhiata al pcap con le stringhe:

220 (vsFTPd 3.0.2)
6USER joe
CT'X
331 Please specify the password.
CTXY
PASS superSecretPassword
230 Login successful.

E riguardo il contenuto dei comandi? Ecco l'output di pcap:

PASV
227 Entering Passive Mode (192,168,1,2,238,178).
LIST
150 Here comes the directory listing.
MNt@
drwxr-xr-x    2 1000     1000         4096 Aug 28 20:27 Desktop
drwxr-xr-x    2 1000     1000         4096 Aug 28 20:27 Documents
drwxr-xr-x    2 1000     1000         4096 Aug 28 20:27 Downloads
drwxr-xr-x    2 1000     1000         4096 Aug 28 20:27 Music
-rw-rw-r--    1 1000     1000        58677 Jun 12  2010 pic1.jpg

E se vuoi che il contenuto del file qui sia un get del jpg.

200 Switching to Binary mode.
PASV
227 Entering Passive Mode (192,168,1,2,64,224).
RETR pic1.jpg
150 Opening BINARY mode data connection for pic1.jpg (58677 bytes).
JFIF
http://ns.adobe.com/xap/1.0/
<?xpacket begin="
" id="W5M0MpCehiHzreSzNTczkc9d"?> <x:xmpmeta xmlns:x="adobe:ns:meta/"    
 x:xmptk="XMP Core 4.1.1"> <rdf:RDF 
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> 
<rdf:Description rdf:about="" 

Quindi, se qualcuno potrebbe annusare i pacchetti sul client, sul server o sulla rete, si avrà un problema di sicurezza. Attenuare il problema spostando l'SFTP o simili è un'idea facile e buona.

How insecure… really… is FTP?

Insicuro come qualsiasi altro protocollo del livello applicazione che non è crittografato, ad esempio HTTP.

But what exactly is the risk being posed?

Il maggior rischio è l'esposizione (agli intercettatori sulla rete) di tutti i dati inviati via FTP.

What about a user's credentials, password, etc.?

Sì, anche quelli sono esposti. Vengono inviati utilizzando i comandi del livello applicazione USER e PASS.

How insecure… really… is FTP

È insicuro come la tua rete. Se la rete può essere sniffata (WiFi, ISP rogue, ecc.), Trovare la password e i dati è banale come eseguire wirehark. Dato un punto da ascoltare, potresti addestrare un bambino di 10 anni per ottenere la password e i dati entro un'ora.

What about a user's credentials, password, etc.?

Tutto completamente in chiaro, con strumenti molto semplici disponibili per snarfarli.

Granted the particular network that one is on is also of importance. A secure office network is a bit different from an airport lounge.

È vero. Come ho detto, l'FTP è sicuro quanto la rete, e non di più. È anche una questione di modello di minaccia. Chi sta cercando di ottenere i dati FTP e perché?

Al giorno d'oggi con sftp e altri metodi per trasferire i dati in modo sicuro, è più una questione di perché dovresti usare ftp del motivo per cui utilizzeresti le alternative sicure.

Penso che ciò che dovresti tenere a mente è che questi tipi di scenari tendono solo a gonfiarsi nel tempo. All'inizio non ti preoccupi particolarmente dei dati e le tue credenziali si inaridiscono, ma quello che stai facendo può trasformarsi nel tempo in qualcosa che davvero desideri aver trascorso il tempo giusto per farlo nel modo giusto. A molti professionisti IT è stato detto che "farà sempre X e non sarà mai usato per Y" solo per far tornare quella stessa persona 18 mesi dopo e dire "Lo so che non avrei mai fatto Y ... compriamo che ne abbiamo davvero bisogno ora. Puoi sistemarlo? "

Se hai qualche possibilità in merito, non è quasi mai una buona idea iniziare in modo insicuro e pensare che "aggiungeremo la sicurezza più tardi quando ne avremo bisogno". Le alternative sicure non sono davvero più difficili da usare e da mantenere, quindi perché non le useresti?

Mentre la tua domanda e la risposta di Steffen indirizzano l'acquisizione dei dati in transito, molti problemi con FTP hanno a che fare con la configurazione e l'implementazione lato server. Molti server FTP (inclusi SFTP e FTPS) hanno avuto gravi vulnerabilità che hanno consentito l'accesso ai dati sia in lettura che in scrittura.   Ecco un articolo dello scorso anno su come sono configurate regolarmente centinaia di migliaia di server FTP per l'accesso anonimo.

I rischi di facilità nell'errata configurazione sono presenti anche nelle versioni protette di FTP. Ad esempio, molte persone non si rendono conto che gli account SFH sono SSH. Una volta effettuato l'accesso a SFTP, è possibile uscire in SSH normale. Se non lo hai considerato, potresti aver concesso più accesso agli utenti SFTP di quanto previsto.

Ci sono un sacco di problemi come gli attacchi directory traversal che non sono specifici per FTP ma a causa della natura del suo design originale e dell'uso previsto tendono a presentarsi più spesso. Trovare informazioni e assistenza per la sicurezza degli host FTP può essere difficile a causa della loro crescente oscurità.

È per queste ragioni che troverai molti standard di sicurezza intorno a SFTP che richiedono una crittografia separata dei file di dati per impedire l'esposizione dei dati "a riposo".