Link alla notizia: http://www.hwfiles.it/news/quaranta-anni-di-ftp-protocollo-tutt-ora-utile-e-apprezzato_36389.html

Il protocollo FTP è usato ormai da 40 anni, lo realizzo Abhay Bhushan, lo stesso che lavorò anche alle prime implementazioni del protocollo email

Click sul link per visualizzare la notizia.

Sull'apprezzato avrei da ridire: nel 2011 l'ftp così come è sta diventando una cosa veramente limitante

io per trasferimento dati tra pc-pc uso sempre l'ftp (o sftp), ho completamente disattivato la condivisione di windows e chiuso le porte da registro etc..., la comodita piu grossa per me è la possibilita di attivare e disattivare quando mi pare e serve.

Io non trovo limiti all'ftp anzi si la impossibilità di fare hash ma per fortuna stanno redando il nuovo standard.

al limite lo stanno "redigendo" :|

cmq per avere 40 anni non li dimostra, ci sono protocolli piu' giovani fatti molto peggio :P alla fine a parte l'hash e i problemi sorti con il nat ftp si e' adattato bene all'era moderna

al limite lo stanno "redigendo" :|

cmq per avere 40 anni non li dimostra, ci sono protocolli piu' giovani fatti molto peggio :P alla fine a parte l'hash e i problemi sorti con il nat ftp si e' adattato bene all'era moderna

e se pensi che con l'ipv6 il nat andrà a sparire (o comunque a venire fortemente limitato) chissà che abbia ancora un bel po' di storia da scrivere questo vecchiarello

Semplicita' e sicurezza?
Capisco la prima ma cosa intende l'autore per sicurezza?
Il fatto che tutto giri in chiaro (anche le password) e che non ci sia controllo sull'integrita' dei dati trasferiti da' un'idea effettivamente molto netta su questo protocollo: la sicurezza sta a zero.

Difatti dopo telnet le prime porte da chiudere sono quelle di FTP.
Molto meglio SFTP che gira su SSH, FTP e' un incubo del passato.

Perché, esiste qualcosa meglio dell'FTP(SFTP)?

Concordo che sul versante sicurezza l'ftp è un disastro, si è cercato di correre ai ripari implementando tls ma quanto ha attecchito? In oltre 10 anni di consulenze non ho mai visto alcun server ftp che facesse uso di questa tecnologia...

Senza considerare che anche implementando regole di anti hammering prima o poi i disagi non mancano se si espone in rete un servizio simile.
L'unico modo per renderlo meno insicuro è limitare pesantemente gli host che possono collegarsi, ma a questo punto si annulla la comodità del protocollo e si vanifica buona parte della sua utilità, ammesso e non concesso che con un po' di banale ip spoofing qualcuno non riesca lo stesso ad entrare...

Io sono un grande sostenitore delle tecnologie semplici e consolidate rispetto alle inutili pinzillacchere con cui si riempiono la bocca i cosiddetti guru del web, il creatore di questo protocollo avrà sempre la mia gratitudine per il grandioso contributo tecnologico che ha fornito all'umanità, però quando un protocollo o un prodotto è carente di features e limitato non si può nascondere la testa sotto la sabbia.

Perché, esiste qualcosa meglio dell'FTP(SFTP)?Beh c'è anche webdav come alternativa.
Attenzione però a non fare confusione, a dispetto del nome ftp e sftp non c'entrano assolutamente nulla tra loro, il secondo è una feature di ssh che non ha nulla a che vedere con il protocollo ftp, non è certo una sua estensione o evoluzione.

Beh c'è anche webdav come alternativa.
Attenzione però a non fare confusione, a dispetto del nome ftp e sftp non c'entrano assolutamente nulla tra loro, il secondo è una feature di ssh che non ha nulla a che vedere con il protocollo ftp, non è certo una sua estensione o evoluzione.

infatti c'è ftps - ftp over ssl, che non è, come hai detto tu, sftp - ssh file transfer protocol

E beh...40 anni!Ed è ancora utilizzato...complimenti!

I complimenti invece non vanno alla redazione oggi....notizia del 16/04 pubblicata il 19/04 e spudoratamente copiata da un sito che non riporto per correttezza.

:D

infatti c'è ftps - ftp over ssl, che non è, come hai detto tu, sftp - ssh file transfer protocolScusa ma dove avrei detto che ftps (ovvero l'implementazione di tls nel protocollo ftp) è sftp?
Ho appunto detto il contrario, ovvero di non confondere i due protocolli (ftp, con o senza tls, e sftp) dato che sono totalmente differenti.


E beh...40 anni!Ed è ancora utilizzato...complimenti!

I complimenti invece non vanno alla redazione oggi....notizia del 16/04 pubblicata il 19/04 e spudoratamente copiata da un sito che non riporto per correttezza.

:DBeh in questo imho non c'è nulla di male, mica si possono inventare news, qualsiasi sito riporta notizie pescate da altre fonti.
Il sito nasce anche come collettore di news proprio per coloro che non hanno tempo/voglia di girare mezza rete e controllare un'infinità di fonti.

Parliamoci chiaro: l'unico motivo per cui l'FTP è ancora usato è perchè, al pari di floppy e porte seriali, sono decenni che si usano e quindi si va avanti così. Come protocollo era già vecchio quando internet è diventata di massa a fine anni 90, ora è paleolitico.
Dati e password girano in chiaro, il comando di listing delle directory è in plain text e sopratutto non è rigidamente standardizzato dal protocollo, nessun supporto per hash, niente ridondanza dei dati scambiati, sistema dei permessi completamente relegati all'OS del server e con scarsissimo controllo da parte del client. Per non parlare, ovviamente, del sistema a doppia porta controllo/dati, totalmente inadeguata per l'internet odierno.

cut

guarda che io ho dato ragione a te :D

"che non è, come hai detto tu" c'è una virgola di mezzo :D

guarda che io ho dato ragione a te :D

"che non è, come hai detto tu" c'è una virgola di mezzo :DOps, ho frainteso :)

Siamo sinceri: il motivo perche' FTP e' prosperato ed ancora in uso e' l'assenza di un client nativo SSH nei sistemi operativi *windows.
Se no col cavolo che qualunque amministratore terrebbe FTP sul suo server. E vogliamo parlare poi dell'inadeguatezza ad automatizzare un procedura di copia di file rispetto a scp, per non parlare poi di rsync?

E questo senza tirare in ballo tecnologia piu' moderne come git o subversion per usi piu' specifici.

_______________________

e spudoratamente copiata da un sito che non riporto per correttezza.
_______________________
adesso questa me la spieghi: la news era su 200 siti forse.. nn ti so nemmeno dire da dove l'ho presa. mi son poi documentato sulle specifiche e sul chi ha scritto il protocollo. bho

Non sono d'accordo con alcune analisi.
L'FTP e' un protocollo applicativo e qualsiasi protocollo applicativo, anche il piu' sicuro, va inserito nel contesto globale di una rete sicura e piu' in generale di un utilizzo consapevole. Parlo come sistemista e non come utente.

Il fatto che user e pass siano in chiaro sono un limite nel momento in cui si espone il servizio pubblicamente su internet, cosa che io non farei MAI, ma non lo sono qualora il servizio venga installato in una VPN ad esempio, una rete switched e poi filtrato da un firewall piu' altri controlli accessi (es. tcp_wrapper di linux). Esistono una miriade di altri accorgimenti per blindare il servizio, con riferimento a openbsd_ftp che uso su linux ne segnalo alcuni tratti dalla mia checklist, da applicare ove possibile:
-creare utenti appositi per il servizio
-in /etc/ftpchroot: elenco utenti che devono essere chrooted; mettere tutti e solo gli utenti creati ad hoc (in modo che siano tutti chroot'ed)
-in /etc/ftpusers: disabilitare utenti root, anonymous, ftp e tutti gli utenti di sistema, tranne quelli presenti in ftpchroot
-mediante PAM si puo' creare un file contenente una lista di utenti che possono collegarsi al nostro host via ftp ma non via shell; nel caso si volessero restringere gli accessi interattivi agli username presenti in /etc/allowed.login si puo' aggiungere in testa ad /etc/pam.d/login una entry, in questo modo qualsiasi utente non elencato non potra' nemmeno fare il login via virtual console. Questo accorgimento integra il punto precedente, nel senso che /etc/ftpusers potrebbe lasciar passare un solo utente, ma non gli limita la possibilita' di fare login; al contrario questa direttiva consente all'utente l'uso di ftp, negandogli tutto il resto.
-impostare numero max di tentativi di login falliti prima della disconnessione
-limitare il numero di sessioni ftp attive contemporaneamente: nowait.n in /etc/inetd.conf e inetd -R n consentono al piu' n-1 istanze del demone in contemporanea nell'arco di un minuto. Ovviamente come protezione aggiuntiva grazie a iptables si puo' configurare lo stesso limite.

Opzioni man in.ftpd:
-l :each successful and failed ftp session is logged using syslog with a facility of LOG_FTP. If this option is specified twice (-ll), the retrieve (get), store (put), append, delete, make directory, remove directory and rename operations and their filename arguments are also logged.
-t nnn :timeout in secondi, di default e' 900 (15 minuti).
-T nnn :massimo timeout concesso al cliente: a client may also request a different timeout period; the maximum period allowed may be set to timeout seconds with the -T option. The default limit is 2 hours.
-A :concede solo accesso anonimo, oppure solo alle utenze elencate in /etc/ftpchroot
-u maschera :specifica il valore della umask, il default e' 027
-q :non mostra informazioni sulla versione al cliente che si collega

Quello che sto cercando di dire e' che il servizio FTPd non va disinstallato a prescindere, va CONFIGURATO. E se possibile, va attivato solo all'occorrenza.

Il protocollo FTP e' stato studiato con lo scopo di massimizzare la velocita', e' il piu' veloce in assoluto di tutti i protocolli di trasferimento dati e su cavo ethernet 100Mbps in LAN arriva quasi a saturare tutta la banda disponibile: nella mia esperienza i trasferimenti superano sempre i 90Mbps, mentre con Condivisione disco di Windows (SAMBA) non si superano i 60-70Mbps. L'SFTP si colloca ancora sotto.

Sul controllo hash segnalo che anche se l'applicazione non ho prevede esplicitamente, i dati sono incapsulati in protocolli di livello 2 (di solito eth), 3 (IP) e 4 (TCP), ciascuno dei quali prevede un checksum sulla correttezza dei dati. Il minor carico sulla CPU dato dalla mancanza di un controllo applicativo permette proprio di massimizzare la velocita' e sfruttare i bytes dei singoli frames fino in fondo.

L'SFTP ha risolto alcuni dei limiti dell'FTP, ad esempio un canale unico per controllo/scambio dei dati e la crittografia. Anch'esso va configurato e blindato opportunamente (potrei postrare molti molti consigli utili allo scopo) ed e' senz'altro preferibile nel caso di esposizione pubblica prolungata.
Ha tuttavia difetto non da poco, la crittografia pesa sulla CPU gia' dopo poche connessioni contemporanee e rende i trasferimenti parecchio lenti, al punto che sarebbe impossibile utilizzare l'SFTP per copiare giga e giga di dati in pochi minuti.

Concludo questo lungo intervento dicendo che la mia filosofia e' di utilizzare entrambi i protocolli, l'FTP per la LAN e l'SFTP per la WAN.

@vampirodolce1
vampirodolce1 i tuoi settaggi sono interessanti e di sicuro migliorano la situazione: grazie per averli condivisi con noi.

Ma resto poco favorevole alla tua analisi: dire che FTP va utilizzato in una "rete sicura e in modo consapevole" mi conferma l'idea che sia un protocollo insicuro per natura.
Portando il ragionamento al limte si potrebbe dire che anche lasciare le password di root in bianco e' sostenibile fintanto che la rete sia sicura e usata in modo consapevole.

Se posso aggiungere anche i miei consigli nel settaggio di un demone ftp non evitabile:
- assicurarsi che gli utenti non abbiano una shell da passwd (cosa che mi sembra tu abbia gia detto)
- assicurarsi che i filesystem in cui gli eventuali client possano scrivere non abbiano i permessi di eseguibilita' o su (in /etc/fstab si dia ai filesystem di ftp noexec, nosuid).

Personalmente tendo a evitare ftp anche nella lan, quando posso i backup li faccio direttamente con rsync (con server dall'altra parte). Per quanto in alcuni ambienti lo spazio di backup resta disponibile solo in ftp...

In quanto alla velocita' ftp non mi entusiasma: preferisco http. Se sono dentro una lan riesco ad usarlo un po' come mi pare (se propio devo muovere roba molto grossa), se devo farlo usare da molti utenti per molti file che cambiano spesso, a parte usarlo liscio, posso fargli usare git over http: per altro mi appoggio ai vari proxy o cache varie che ci possono essere in mezzo.

Attenzione comunque. I NERD sono antisportivi ahahah