FTPS (FTP + S) offre una sicurezza migliore di SFTP sul lato server?

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

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

(*) Diversi commenti non credono davvero che avere una vasta gamma di porte aperte sia dannoso per la sicurezza. Quindi lascia che ti spieghi più dettagliatamente:

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

Il sysadmin genera un punto valido. (ma le sue capacità interpersonali potrebbero aver bisogno di lavoro)

SSH è un protocollo complesso e openssh implementa molte funzionalità. Tutte queste funzionalità offrono i vettori di attacco, ed è molto difficile essere certi che nessuno di questi vettori sia sfruttabile.

Anche se openssh è privo di bug (che non è), conoscere tutte le giuste possibilità per chiudere funzionalità indesiderate e capire come queste opzioni potrebbero interagire richiede uno sforzo significativo in sé. E queste interazioni potrebbero cambiare da versione a versione.

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

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp

E abbastanza sicuro:

% ssh somehost
This service allows sftp connections only.
Connection to somehost closed.

Ma aspetta ...

ssh -N -L 9000:localhost:80 somehost

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

E questo è solo l'inoltro TCP. Per lo meno, SSH consente anche l'inoltro X11 e l'inoltro di SSH-agent, 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 è sufficiente solo sftp:

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

Speriamo che questo sia adeguato per garantire solo l'accesso sftp, ma non possiamo essere completamente sicuri. (suggerimenti ben accetti;)

Entrambi i protocolli presentano 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 dovrebbero essere prese in considerazione quando si sceglie quale protocollo è il migliore in determinate condizioni specifiche.

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

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

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

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

Qualcuno potrebbe obiettare che la configurazione di un server SSH per consentire solo SFTP (nessuna shell, nessun comando, nessun tunnel di inoltro, nessun X11) potrebbe essere difficile. In realtà ciò dipende: se stai usando Linux e OpenSSH questo potrebbe essere vero, ma c'è una pletora di server SSH / SFTP là fuori che rendono questo tipo di configurazione un gioco da ragazzi, quindi non lo elencherei necessariamente come un potenziale difetto, a meno che - come ho detto - vengano usati Linux / OpenSSH.

Un paio di notevoli vantaggi collaterali di SFTP, però, includono:

• Scambio chiave ECDSA : una chiave ECDS a 521 bit (X) equivale a una chiave RSA di 15,360 bit in termini di sicurezza e richiede 9 cicli di CPU in meno per il calcolo delle firme
• Inerente inoltro segreto : il protocollo SSH può rinegoziare la chiave di crittografia del canale effettiva durante la sessione e fornisce la segretezza intrinseca, al contrario di qualsiasi server abilitato a SSL / TLS che richiede un lavoro di configurazione aggiuntivo per realizzare questo

Quindi, in ultima analisi, la scelta dipende solo da voi ragazzi, ma l'argomento che il sysadmin stava facendo è palesemente non valido, e se c'è un server SFTP esistente che è ben configurato (come spiegato), allora non c'è motivo (specialmente nessun motivo relativo alla sicurezza) per passare a FTPS (o FTPES).

Molte persone richiamano punti validi sulle differenze tra i due protocolli. Ma penso che per i tuoi scopi, la domanda sia davvero "L'SFTP è sicuro abbastanza?" 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 studiato a fondo. Non sono noti difetti di progettazione del protocollo. Tuttavia, le vulnerabilità della sicurezza spesso non hanno nulla a che fare con il protocollo e tutto ciò che riguarda l'implementazione. Dopotutto, lo stesso SMTP non è "insicuro" ed è relativamente semplice nella progettazione, ma 16 anni fa l'applicazione SendMail comune era uno dei figli poster di una cattiva sicurezza del software e aveva un buco dopo l'altro.

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

Quindi penso che si tratti più di scegliere una buona IMPLEMENTAZIONE piuttosto che un buon protocollo. Entrambi i protocolli vanno bene e l'implementazione può essere implementata male.

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

Come te, pensavo che entrambi fossero quasi la stessa cosa che ho cercato sul web per cercare le loro differenze.

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

1. Per il mio NAS, ho attivato la funzionalità FTPS per 3 mesi. La configurazione del firewall era ok. Ho appena dovuto aprire la porta FTP e alcune altre porte utilizzate dal trasferimento FTPS. Fin qui tutto bene, non un grosso problema.

2. Dopo 3 mesi, immagino, potrei, attivare anche 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 ha subito alcuni attacchi di forza maggiore. Il NAS ha automaticamente bloccato l'IP di attacco dopo 10 tentativi di password falliti e me lo ha comunicato via e-mail. Immagina che se l'aggressore 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 davvero semplice, allora la persona che usa l'attacco di forza di livido potrebbe entrare nel nostro sistema.

Ora che ho disabilitato l'SFTP, l'attacco si è fermato e sono felice che nessuno stia cercando di entrare nel nostro file server.

No, SSH e SSL di solito usano lo stesso algoritmo di cifratura. Ad es. RSA e AES, ma SSH può utilizzare DSA. Ma ssh utilizza la porta 22. ma FTP utilizza la porta 21 e 22 per FTP e dati FTP. a mio parere è meglio configurabile, devi aprire 2 porte, che non è solo impraticabile considerando i firewall, ma anche un potenziale rischio per la sicurezza, perché devi aprire 2 porte.

La risposta è un po 'brusca o in che direzione vai nella tua retorica. I mezzi laterali del server sono controllati dalla persona che fornisce il file e sono teoricamente più sicuri se si conoscono tutte le funzionalità di sicurezza.

Un metodo sul lato utente sarebbe lo stesso ma per l'utente. In questi giorni non mettiamo in discussione la relazione tra i due. Ognuno deve assicurarsi delle proprie capacità per proteggersi sufficientemente. Gli utenti si rivolgono quindi a un'opzione di firewall.

Qualsiasi opzione scelta per l'utente può essere facilmente annullata con tali mezzi. Quindi non ci preoccupiamo per l'utente (destinatario). Questa retorica è ormai obsoleta al riguardo.

La tua preoccupazione dovrebbe essere sui tuoi titoli. Questo significherebbe lato server. Vuoi il controllo delle informazioni che pubblichi. Quanta preoccupazione dopo il rilascio non è più prudente. Semplicemente non è la tua responsabilità oltre quel punto. Solo ciò che ti influenza come conseguenza. Se non hai ancora dati su questo non hai conseguenze.

Una soluzione veramente controllabile sarebbe quella di utilizzare una fonte FTP con crittografia interamente dal tuo stesso progetto. Non fare affidamento su terze parti. Ma anche questo è obsoleto in quanto è difficile costruire le tue librerie dall'inizio alla fine.

In base alle terminologie fornite in modo inadeguato, si desidera un semplice ssh ftp. Per questo tutto ciò che puoi fare è proporre regole firewall e configurazioni iptables (se in Linux). Sembra che tu sia bloccato con WYSIWYG in entrambi i casi.