Network Working Group M. Allman Request for Comments: 2577 NASA Glenn/Sterling Software Category: Informational S. Ostermann Ohio University May 1999 Considerazioni sulla Sicurezza FTP Traduzione a cura di ComiSAT Brescia, Giu. 2005 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. Stato di questa memoria Questo documento fornisce informazioni per la comunita' Internet. Non specifica uno standard Internet di alcun genere. La distribuzione di questo documento non e' soggetta a limitazioni. Nota di Copyright Copyright (C) The Internet Society (1999). All Rights Reserved. Sunto La specifica del File Transfer Protocol (Protocollo di Trasferimento File - FTP) contiene un certo numero di meccanismi che possono essere sfruttati per compromettere la sicurezza della rete. La specifica FTP consente ad un client di fare in modo che un server trasferisca files ad una terza macchina. Questo meccanismo a tre, conosciuto come proxy FTP, comporta un ben noto problema di sicurezza. La specifica FTP consente inoltre un illimitato numero di prove della password utente. Questo permette attacchi di forza bruta per "indovinare la password". Il presente documento fornisce suggerimenti per gli amministratori di sistema e coloro che implementano server FTP che diminuiranno le problematiche di sicurezza relative al FTP. 1 Introduzione La specifica File Transfer Protocol (FTP) [PR85] fornisce un meccanismo che consente ad un client di stabilire una connessione di controllo FTP e trasferire un file tra due servers FTP. Tale meccanismo "proxy FTP" puo' essere utilizzato per diminuire l'ammontare di traffico sulla rete; il client ordina ad un server di trasferire un file ad un altro server, piuttosto che trasferire il file dal primo server al client e poi dal client al secondo server. Questo e' particolarmente utile quando il client si connette alla rete utilizzando un collegamento lento (ad es. un modem). Sebbene utile, il proxy FTP determina un noto problema di sicurezza, conosciuto come "bounce attack" [N.d.T.: letteralmente: "attacco di rimbalzo"] [CERT97:27]. Inoltre i servers FTP possono essere utilizzati dagli attaccanti per indovinare password mediante forza bruta. Allman & Ostermann Informational [Page 1] RFC 2577 FTP Security Considerations May 1999 Questo documento non contiene una discussione del FTP quando usato in contemporanea a protocolli di sicurezza forte, come l'IP Security. Tali questioni di sicurezza dovrebbero essere documentate, tuttavia sono al di fuori dell'obiettivo di questo documento. Questo documento fornisce informazioni per gli implementatori di server FTP e gli amministratori di sistema, come segue. La Sezione 2 descrive l'FTP "bounce attack". La Sezione 3 fornisce suggerimenti per minimizzare tale attacco. La Sezione 4 fornisce suggerimenti per i servers quali il limite di accesso basato su indirizzo di rete. La Sezione 5 fornisce raccomandazioni per limitare i tentativi dei clients di "indovinare le password" attraverso forza bruta. Di seguito, la Sezione 6 fornisce una breve discussione sui meccanismi per migliorare la privacy. La Sezione 7 fornisce un meccanismo per evitare che venga indovinata l'identita' utente. La Sezione 8 discute la pratica relativa al rubare la porta. Infine, la Sezione 9 fornisce una panoramica di altre tematiche di sicurezza FTP relative a errori software anziche' a questioni legate al protocollo. 2 Il Bounce Attack La versione del FTP specificata dallo standard [PR85] consente un ben noto metodo di attacco ai servers di rete, mentre rende difficile il tracciamento degli attaccanti. L'attacco implica l'invio di un comando FTP "PORT" ad un server FTP contenente l'indirizzo di rete e il numero di porta della macchina e il servizio che viene attaccato. Cosi' un file conterrebbe i comandi relativi al servizio che viene attaccato (SMTP, NNTP, ecc.). Istruire una terza parte a connettersi al servizio, anziche' connettersi direttamente, fa si' che il tracciamento dell'attaccante sia difficile e puo' aggirare le restrizione di accesso basato-su-indirizzo- di-rete. Come esempio, un client uploada un file contenente comandi SMTP ad un server FTP. Poi, usando un appropriato comando PORT, il client ordina al server di aprire una connessione verso la porta FTP di una terza macchina. Infine, il client ordina al server di trasferire il file uploadato contenente i comandi SMTP alla terza macchina. Questo puo' consentire al client di forgiare posta sulla terza macchina senza effettuare una connessione diretta. Questo rende difficile il tracciamento dell'attaccante. 3 Proteggersi dal Bounce Attack La specifica FTP originale [PR85] presuppone che le connessioni dati siano fatte utilizzando il TCP (Transmission Control Protocol (TCP) [Pos81]. I numeri di porta TCP nell'intervallo 0-1023 sono riservati per servizi ben noti come mail, news e connessioni di controllo FTP [RP94]. La specifica FTP non pone restrizioni sul numero di porta TCP utilizzata dalla connessioni dati. Di conseguenza, utilizzando il proxy FTP, Allman & Ostermann Informational [Page 2] RFC 2577 FTP Security Considerations May 1999 i client hanno la possibilita' di dire al server di attaccare un servizio ben noto su una qualsiasi macchina. Per aggirare tali attacchi di rimbalzo, e' suggerito che i server non aprano connessioni dati sulle porte TCP inferiori alla 1024. Se un server riceve un comando PORT contenente un numero di porta TCP inferiore alla 1024, si suggerisce che venga tornata una risposta 504 (definita come "Comando non implementato per tale parametro" da [PR85]). Si noti che questo lascia comunque i server vulnerabili ad attacchi di rimbalzo (quelli che girano su porte superiori alla 1023). Diverse proposte (ad es., [AOM98 e [Pis94]) pongono un meccaniscmo che consentirebbe connessioni dati mediante l'uso di un protocollo di trasporto diverso dal TCP. Precauzioni simili dovrebbero essere prese per proteggere i servizi noti anche quando si utilizzano tali protocolli. Si noti inoltre che il bounce attack richiede solitamente che l'attaccante sia nella posizione di uploadare un file su un server FTP e scaricarlo poi successivamente dal servizio attaccato. Mediante l'uso di appropriate protezioni sui file si puo' evitare questo a monte. In ogni caso, gli attaccanti possono anche attaccare i servizi inviando dati casuali da un server FTP remoto i quali possono causare problemi con taluni servizi. Un'altra possibilita' per proteggersi dal bounce attack e' disabilitare il comando PORT. La maggior parte dei trasferimenti di file puo' essere fatta utilizzando solamente il comando PASV [Bel94]. Lo svantaggio della mancata abilitazione del comando PORT e' che uno perde la possibilita' di utilizzare il proxy FTP, anche se questo potrebbe non risultare necessario in un particolare ambiente. 4 Accesso ristretto Per alcuni server FTP, e' auspicabile restringere l'accesso basato su indirizzo di rete. Per esempio, un server potrebbe voler restringere l'accesso a certi file da certi host (ad ese., un certo file non dovrebbe essere trasferito fuori da un'organizzazione). In una tale situazione, il server dovrebbe confermare che l'indirizzo di rete dell'host remoto sulla connessioni di controllo e sulla connessione dati si trovi all'interno dell'organizzazione prima di inviare il file ristretto. Controllando entrambe le connessioni, un server risulta protetto contro il caso in cui la connessione di controllo sia stabilita con un host fidato mentre la connessione dati no. Inoltre, il client dovrebbe verificare l'indirizzo IP dell'host remoto dopo aver accettato una connessione su una porta aperta in modalita' ascolto per verificare che la connessione sia stata fatta dal server aspettato. Si noti che la restrizione d'accesso basata su indirizzo di rete lascia il server FTP vulnerabile ad attacchi di "spoofing". In un attacco di spoof, per esempio, una macchina attaccante assume l'indirizzo di un'altra macchina interna all'organizzazione e scarica i file che sono non Allman & Ostermann Informational [Page 3] RFC 2577 FTP Security Considerations May 1999 accessibili dall'esterno. Qualora possibile, dovrebbero essere utilizzati meccanismi di autenticazione sicura, come quelli delineati in [HL97]. 5 Proteggere le Password Per minimizzare il rischio di attacco alle password tramite forza bruta attraverso server FTP, e' suggerito che i server limitino il numero di tentativi che possono essere fatti per inviare una password valida. Dopo un piccolo numero di tentativi (3-5), il server dovrebbe chiudere la connessione di controllo con il client. Prima che la connessione di controllo venga terminata, il server deve ritornare un codice di errore 421 ("Servizio non disponibile, chiusura della connessione di controllo." [PR85] al client. In aggiunta, e' suggerito che il server imponga un ritardo di 5 secondi prima di poter rifare un comando "PASS" invalido per diminuire l'efficenza di un attacco di forza bruta. Se disponibili, dovrebbero venire utilizzati i meccanismi gia' forniti dal sistema operativo dell'obiettivo per implementare i suggerimento visti sopra. Un attaccante puo sovvertire i meccanismi di cui sopra stabilendo connessioni di controllo multiple, parallele col server. Per contrastare l'uso di collegamenti multipli simultanei, il server puo' o limitare il numero totale di connessioni di controllo possibili, oppure tentare di rilevare attivita' sospetta durante le sessioni e rifiutare ulteriori connessioni dal sito. Ad ogni modo, entrambi questi meccanismi aprono la porta ad attacchi di tipo "denial of service" (N.d.T. - negazione del servizio) con i quali un attaccante inizia un attacco per disabilitare espressamente l'accesso ad un utente legittimo. Lo standard FTP [PR85] invia le password in chiaro utilizzando il comando "PASS". E' suggerito che i client ed i server FTP usino meccanismi d'autenticazione alternativi che non siano oggetto di ascolto non autorizzato (come i meccanismi che sono sviluppati dall'IETF Common Authentication Technology Working Group [HL97]). 6 Privacy Tutti i dati e le informazioni di controllo (password incluse) vengono inviate dallo standard FTP [PR85] lungo la rete in forma non cifrata. Per garantire la privacy delle informazioni che il FTP trasmette, un robusto schema crittografico dovrebbe essere utilizzato qualora possibile. Un meccanismo del genere viene definito in [HL97]. 7 Protezione dei Nomi-Utente Lo standard FTP [PR85] specifica una risposta 530 al comando USER quando lo username viene rifiutato. Se lo username e' valido e la password e' richiesta, il FTP ritorna invece una risposta 331. Per fare in modo di prevenire che un client maligno determini gli username validi su un server, e' suggerito che il server ritorni in ogni caso una risposta 331 al comando Allman & Ostermann Informational [Page 4] RFC 2577 FTP Security Considerations May 1999 USER e rifiuti poi la combinazione username/password per uno username non valido. 8 Rubare la Porta Molti sistemi operativi assegnano numeri di porta dinamici in ordine crescente. Eseguendo un trasferimento legittimo, un attaccante puo' osservare il numero di porta correntemente allocato dal server e "indovinare" quello che verra' utilizzato successivamente. L'attaccante puo' eseguire una connessione a questa porta, negando cosi' ad un utente legittimo la possibilita' di fare un trasferimento. In aggiunta, un attaccante puo' inserire un apposito file nel flusso di dati per far credere che provenga da un utente autenticato. Questo problema puo' essere attenuato facendo in modo che client e server FTP utilizzino numeri di porta locali random per le connessioni dati, oppure che richiedano porte random dai sistemi operativi o utilizzando meccanismi in relazione del sistema. 9 Problemi di Sicurezza derivanti dal Software Questo documento enfatizza le problematiche di sicurezza relative al protocollo. Vi sono tuttavia un numero di problemi di sicurezza FTP documentati che sono dovuti a implementazioni non ottimali. Sebbene i dettagli di questi tipi di problemi vanno oltre lo scopo di questo documento, si vuole sottolineare che delle seguenti caratteristiche FTP sono stati commessi abusi in passato e dovrebbero essere gestite con cura nelle implementazioni future: FTP Anonimo Il FTP Anonimo si riferisce alla possibilita' del client di connettersi ad un server FTP con un'autenticazione minima e guadagnare l'accesso a file pubblici. I problemi di sicurezza si presentano quando un utente puo' leggere tutti i file sul sistema oppure puo' crearne. [CERT92:09] [CERT93:06] Esecuzione di Comandi Remoti Un'estensione del FTP facoltativa, "SITE EXEC", consente ai client di eseguire arbitrariamente comandi sul server. Questa caratteristica dovrebbe ovviamente essere implementata con la dovuta cura. Vi sono svariati casi documentati in cui il comando FTP "SITE EXEC" viene utilizzato per sovvertire la sicurezza del server [CERT94:08] [CERT95:16] Codice di Debug Parecchi dei precedenti compromessi di sicurezza relativi al FTP possono essere attribuiti a software installato con le funzionalita' di debug abilitate [CERT88:01]. Allman & Ostermann Informational [Page 5] RFC 2577 FTP Security Considerations May 1999 Questo documento raccomanda che gli implementatori di server FTP con tali caratteristiche rivedano tutte le circolari del CERT sugli attacchi di questi meccanismi o simili prima di rilasciare i loro software. 10 Conclusioni L'uso dei suggerimenti qui descritti puo' diminuire i problemi di sicurezza associati ai server FTP senza eliminarme la funzionalita'. 11 Considerazioni sulla Sicurezza Le considerazioni relative alla sicurezza sono oggetto di questo documento. Rigraziamenti We would like to thank Alex Belits, Jim Bound, William Curtin, Robert Elz, Paul Hethmon, Alun Jones and Stephen Tihor for their helpful comments on this paper. Also, we thank the FTPEXT WG members who gave many useful suggestions at the Memphis IETF meeting. Riferimenti [AOM98] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998. [Bel94] Bellovin. S., "Firewall-Friendly FTP", RFC 1579, February 1994. [CERT88:01] CERT Advisory CA-88:01. ftpd Vulnerability. December, 1988 ftp://info.cert.org/pub/cert_advisories/ [CERT92:09] CERT Advisory CA-92:09. AIX Anonymous FTP Vulnerability. April 27, 1992. ftp://info.cert.org/pub/cert_advisories/ [CERT93:06] CERT Advisory CA-93:06. Wuarchive ftpd Vulnerability. September 19,1997 ftp://info.cert.org/pub/cert_advisories/ [CERT94:08] CERT Advisory CA-94:08. ftpd Vulnerabilities. September 23, 1997. ftp://info.cert.org/pub/cert_advisories/ [CERT95:16] CERT Advisory CA-95:16. wu-ftpd Misconfiguration Vulnerability. September 23, 1997 ftp://info.cert.org/pub/cert_advisories/ [CERT97:27] CERT Advisory CA-97.27. FTP Bounce. January 8, 1998. ftp://info.cert.org/pub/cert_advisories/ Allman & Ostermann Informational [Page 6] RFC 2577 FTP Security Considerations May 1999 [HL97] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997. [Pis94] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR), RFC 1639, June 1994. [Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [PR85] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985. [RP94] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html Indirizzi degli Autori Mark Allman NASA Glenn Research Center/Sterling Software 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135 EMail: mallman@grc.nasa.gov Shawn Ostermann School of Electrical Engineering and Computer Science Ohio University 416 Morton Hall Athens, OH 45701 EMail: ostermann@cs.ohiou.edu Allman & Ostermann Informational [Page 7] RFC 2577 FTP Security Considerations May 1999 Dichiarazione Completa di Copyright (in lingua originale) Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Ringraziamenti Funding for the RFC Editor function is currently provided by the Internet Society. Allman & Ostermann Informational [Page 8]