Dalla sicurezza che forniscono in teoria FTPS e SFTP sono simili. In pratica si hanno i seguenti vantaggi e svantaggi:

• Con le applicazioni client FTPS spesso le applicazioni client non riescono a convalidare correttamente i certificati, il che in modo efficace significa che l'uomo al centro è possibile. Con SFTP invece gli utenti saltano semplicemente le informazioni sulla chiave host e accettano qualsiasi cosa, quindi il risultato è lo stesso.
• Ma gli utenti e gli amministratori con maggiori conoscenze potrebbero utilizzare correttamente le chiavi SSH e utilizzarle anche per l'autenticazione che quindi rende SFTP molto più facile da usare rispetto all'utilizzo delle password. E se le password sono proibite, questo è anche più sicuro perché gli attacchi con password di forza bruta non sono più possibili.
• FTP utilizza porte dinamiche per le connessioni dati e le informazioni su queste porte vengono trasferite in banda. Ciò rende già semplice FTP (senza TLS) un incubo quando sono coinvolti firewall, NAT o simili. Con FTPS (FTP + TLS) la situazione peggiora perché a causa della crittografia delle applicazioni di supporto della connessione di controllo sul firewall non è più possibile scoprire quali porte devono essere aperte. Ciò significa che per passare FTPS è necessario aprire un'ampia gamma di porte, il che è dannoso per la sicurezza (*). SFTP è molto meglio perché utilizza solo una singola connessione per il controllo e i dati.
• I server FTP (S) spesso forniscono accesso anonimo e i server SFTP di solito no. Diversi server FTP (S) offrono anche pseudo utenti, cioè utenti presi dallo stesso database o simili che non sono utenti reali sul sistema. Se hai solo utenti appropriati in ogni caso, non importa.
• SFTP usa il protocollo SSH e devi configurare correttamente il sistema per consentire solo l'accesso SFTP e non anche l'accesso SSH (terminale) o anche l'inoltro SSH. Con FTP questo è più facile perché FTP può fare comunque solo il trasferimento di file.

(*) Molti commenti non credono che avere una vasta gamma di porte aperte sia un male per la sicurezza. Quindi lasciatemi spiegare questo in modo più dettagliato:

• FTP utilizza connessioni TCP separate per il trasferimento dei dati. Le porte utilizzate per queste connessioni sono dinamiche e le informazioni su queste vengono scambiate all'interno della connessione di controllo. Un firewall che non sa quali porte sono attualmente in uso può consentire solo un ampio intervallo di porte che forse verrà utilizzato a volte FTP.
• Queste porte devono consentire l'accesso dall'esterno all'interno perché in modalità passiva FTP il il client si connette a qualche porta dinamica sul server (cioè rilevante per il firewall lato server) e per la modalità FTP attivo il server si connette a qualche porta dinamica sul client (rilevante per il firewall lato client).
• Avere un ampio la gamma di porte aperte per accesso illimitato dall'esterno all'interno non è ciò che qualcuno normalmente considera un firewall restrittivo che protegge l'interno. Questo è più simile ad avere un grande buco nella porta in cui un ladro potrebbe entrare in casa.
• Per aggirare questo problema la maggior parte dei firewall utilizza "helper" per FTP che esaminano la connessione di controllo FTP per capire quali porte devono essere aperte per la connessione dati successiva. Un esempio è ip_conntrack_ftp per iptables. Sfortunatamente con FTPS la connessione di controllo è (di solito) crittografata, quindi questi helper sono ciechi e non possono aprire dinamicamente le porte richieste. Ciò significa che FTP non funziona o che un'ampia gamma di porte deve essere sempre aperta.

L'amministratore di sistema solleva un punto valido. (ma le sue capacità interpersonali potrebbero aver bisogno di lavoro)

SSH è un protocollo complesso e openssh implementa molte funzionalità. offre vettori di attacco, ed è molto difficile essere sicuri che nessuno di questi vettori sia sfruttabile.

Anche se openssh è senza bug (cosa che non è), conoscere tutte le giuste possibilità per chiudere funzionalità indesiderate e la comprensione del modo in cui queste opzioni potrebbero interagire richiede uno sforzo significativo in sé e queste interazioni potrebbero cambiare da versione a versione.

Come esempio, considera il seguente frammento di sshd_config che ha l'intenzione di limitare determinati utenti a solo SFTP (abbiamo anche pensato di bloccarli nelle loro directory home):

  Match Group sftponly ChrootDirectory% h ForceCommand internal-sftp  

E abbastanza sicuro:

 % ssh somehostQuesto servizio consente solo connessioni sftp. connessione a somehost clo sed.  

Ma aspetta ...

  ssh -N -L 9000: localhost: 80 somehost  

Spiacenti, ora ho inoltrato la porta 80 su somehost alla porta 9000 sul mio host. Ciò significa che possiamo connetterci alla porta 80 su somehost come se provenissimo da localhost. non è un grosso problema per la porta 80, ma per quanto riguarda i servizi che ascoltano solo su localhost, come servizi amministrativi o database?

E questo è solo inoltro TCP. SSH consente anche l'inoltro X11 e l'inoltro dell'agente SSH, e non conosco nemmeno le implicazioni di questi due.

Usiamo molto ssh / sftp, perché per la nostra situazione i vantaggi superano questi rischi. Ma è una preoccupazione valida che non dovrebbe essere presa troppo alla leggera. Abbiamo finito con questo per casi d'uso in cui solo sftp è sufficiente:

  Match Group sftponly ChrootDirectory% h X11Forwarding no AllowTcpForwarding no AllowAgentForwarding no ForceCommand internal-sftp  

Ci auguriamo che questo sia adeguato per garantire solo l'accesso sftp, ma non possiamo esserne completamente sicuri. (suggerimenti benvenuti;)

Entrambi i protocolli hanno vantaggi e svantaggi, come spiegato molto bene in questo articolo di confronto.

Detto questo, poiché la domanda riguarda specificamente la sicurezza, ci sono alcune considerazioni che deve essere preso in considerazione quando si sceglie quale protocollo è migliore in determinate condizioni specifiche.

FTPS e FTPES utilizzano SSL o TLS per crittografare il controllo / i dati collegamenti. Il vantaggio principale di questi canali sicuri è che utilizzano certificati X.509, che contengono molte più informazioni di una semplice coppia di chiavi (nome host, indirizzo e-mail, nome dell'organizzazione, ISSUER (CA), ...) e sono quindi un molto più facile da convalidare. Ma:

• SSL 1.0 , SSL 2.0 : obsoleto molto tempo fa (non sicuro)
• SSL 3.0 : obsoleto di recente a causa di POODLE
• TLS 1.0 : non più accettabile per la conformità PCI
• TLS 1.1 : manca di alcune estensioni di TLS 1.2 e ha un supporto client limitato, nessun motivo per usarlo
• TLS 1.2 : standard corrente, finora considerato sicuro / sicuro

E quanto sopra copre solo il protocollo di crittografia del canale / i, poi ci sono considerazioni sulla sicurezza riguardo al protocollo FTP stesso. Il comando SITE , ad esempio, è stato utilizzato più e più volte per perpetrare attacchi e il design intrinseco del protocollo stesso richiede l'apertura e il NAT di più porte sul firewall (che può diventare un incubo da gestire ). Inoltre, la maggior parte dei firewall non è in grado di eseguire correttamente le connessioni dati FTP NAT a meno che il client non richieda e il server non consenta CCC (Clear Control Channel) che vanifica parte della sicurezza eseguendo la connessione di controllo in chiaro.

D'altra parte abbiamo SFTP , che è un sottosistema di SSH . La sfida principale in questo caso è che le chiavi SSH sono "solo chiavi", non vengono emesse da una CA e nessuna istruzione dell'emittente o catena di chiavi è inclusa in esse, quindi le chiavi del server SSH devono essere espressamente attendibili dal client

Un paio di notevoli vantaggi collaterali dell'SFTP, tuttavia, includono:

Molte persone sollevano punti validi sulle differenze tra i due protocolli. Ma penso che per i tuoi scopi, la domanda sia davvero "SFTP è abbastanza sicuro?" piuttosto che "quale è più sicuro" ?. Come hai detto, hai altre preoccupazioni oltre alla semplice sicurezza.

Questo risulta essere un problema difficile da risolvere. SSH è stato ampiamente utilizzato e ampiamente studiato. Non sono noti difetti di progettazione del protocollo. Tuttavia, le vulnerabilità della sicurezza spesso non hanno nulla a che fare con il protocollo e hanno a che fare con l'implementazione. Dopotutto, l'SMTP in sé non è "insicuro" ed è relativamente semplice nel design, ma 16 anni fa l'applicazione comune SendMail era uno dei manifesti della sicurezza del software mal implementata e aveva un buco dopo l'altro.

Il punto è che, anche se il protocollo è ben progettato e semplice, l'implementazione può essere un ratto nido di complessità, funzionalità aggiuntive e incubi di sicurezza.

Quindi penso che questo riguarda più la scelta di una buona IMPLEMENTAZIONE piuttosto che un buon protocollo. Entrambi i protocolli vanno bene e entrambe le implementazioni possono essere implementate male.

Non ho familiarità con FTPS, quindi non so se ci sono implementazioni ben rispettate. Per SSH, tuttavia, OpenSSH è generalmente considerato di alta qualità ed è stato progettato pensando alla sicurezza da zero (separazione dei dati, ecc.).

Come te, pensavo che entrambe fossero quasi uguali mentre navigavo sul Web alla ricerca delle loro differenze.

Tuttavia, nella vita reale, è un'altra storia. Di seguito è stata la mia esperienza:

1. Per il mio NAS, ho attivato la funzionalità FTPS per 3 mesi. La configurazione del firewall era ok. Dovevo solo aprire la porta FTP e alcune altre porte utilizzate dal trasferimento FTPS. Fin qui tutto bene, niente di grave.

2. Dopo 3 mesi, immagino, meh, potrei anche attivare il protocollo SFTP poiché è più comune e probabilmente più facile da gestire. Poi è successo qualcosa di interessante. 10 MINUTI dopo aver aperto la porta SFTP, il mio NAS è stato sottoposto ad alcuni attacchi di forza livido. Il NAS ha bloccato automaticamente l'IP di attacco dopo 10 tentativi di password falliti e me lo ha notificato tramite e-mail. Immagina se l'attaccante avesse il controllo di migliaia di computer con IP diversi, il mio NAS non sarebbe in grado di fermarli tutti. Inoltre, se il personale della nostra azienda decide di impostare una password molto semplice, la persona che utilizza l'attacco di forza contusiva potrebbe eventualmente entrare nel nostro sistema.

Ora che io disabilitato l'SFTP, l'attacco si è interrotto e sono felice che nessuno stia più cercando di entrare nel nostro file server.

No, SSH e SSL di solito usano lo stesso valore di cifratura. ad esempio: RSA e AES, ma SSH può utilizzare DSA. Ma ssh usa la porta 22. ma FTP usa le porte 21 e 22 per FTP e dati FTP. anche se secondo me è meglio configurabile, devi aprire 2 porte, il che non solo è poco pratico considerando i firewall ma anche un potenziale rischio per la sicurezza, perché devi aprire 2 porte.

La risposta è piuttosto brusca in qualunque modo tu vada nella tua retorica. I mezzi lato server sono controllati dalla persona che fornisce il file e teoricamente più sicuri se si conoscono tutte le funzionalità di sicurezza.

Un metodo lato utente sarebbe lo stesso ma per l'utente. In questi giorni non mettiamo in discussione il rapporto dei due. Ciascuno deve assicurarsi delle proprie capacità per proteggersi a sufficienza. Gli utenti quindi si rivolgono a un'opzione di firewall.

Qualsiasi opzione scelta per l'utente può essere facilmente annullata con tali mezzi. Pertanto non ci preoccupiamo per l'utente (destinatario). Questa retorica è ormai obsoleta su questo argomento.

La tua preoccupazione dovrebbe essere sui tuoi stessi titoli. Ciò significherebbe lato server. Vuoi il controllo delle informazioni che rilasci. Quanta preoccupazione dopo che è stato rilasciato non è più prudente. Semplicemente non è tua responsabilità oltre quel punto. Solo ciò che ti colpisce di conseguenza. Se non hai ancora dati su questo non hai conseguenze.

Una soluzione veramente controllabile sarebbe quella di utilizzare una fonte FTP con crittografia, tutto secondo il tuo design. Non fare affidamento su terze parti. Ma anche questo è obsoleto in quanto è difficile costruire le proprie librerie dall'inizio alla fine.

Sulla base delle terminologie fornite in modo inadeguato, si desidera un semplice ftp ssh. Per questo tutto ciò che puoi fare è proporre regole del firewall e configurazioni di iptables (se in Linux). Sembra che tu sia bloccato con WYSIWYG in ogni caso.