Domanda:
FTPS (FTP + S) offre una sicurezza migliore di SFTP sul lato server?
Stéphane C.
2016-04-28 12:47:13 UTC
view on stackexchange narkive permalink

Ieri ho avuto uno scambio con alcuni amministratori di sistema di terze parti riguardo alla configurazione di un'interfaccia di trasferimento file tra i nostri server.

Ho suggerito di utilizzare SFTP perché la nostra applicazione ha un buon supporto per questo. Il mio interlocutore vuole assolutamente FTP + S (FTP + TLS) che attualmente non supportiamo e che dovremmo sviluppare.

Ho sostenuto che non ho visto alcun vantaggio reale in FTP + S rispetto a SFTP poiché entrambi offrire una solida crittografia del traffico. SFTP è immediatamente disponibile e può essere reso ancora più sicuro con l'autenticazione della chiave pubblica. Ultimo ma non meno importante, la sua modalità di connessione singola lo rende molto più piacevole da usare dietro i firewall aziendali.

L'amministratore di sistema mi ha quasi definito un idiota, affermando che SFTP funziona su SSH che è un protocollo progettato per scopi amministrativi e che l'apertura di una porta SSH per un uso diverso dall'amministrazione è chiaramente una cattiva idea perché apre un ampio vettore di attacco contro il sistema host.

Mi chiedo se questo argomento sia valido. Sembra che esistano vari modi per limitare una sessione SSH per consentire solo il trasferimento di file SFTP. C'è il sottosistema internal-sftp fornito con openSSH, dove puoi facilmente configurare un chroot e disabilitare l'inoltro TCP. Ho anche sentito parlare di soluzioni che presumibilmente consentono agli utenti di connettersi tramite SFTP senza richiedere una voce nel file passwd ... Non vedo alcun problema chiaro con SFTP che non avresti con FTP + S, ma potrebbe mancare qualcosa?

Quindi, nonostante le restrizioni che puoi applicare a SSH, FTP + S è un'opzione migliore per i trasferimenti di file, dal punto di vista della sicurezza?

Chi gestisce il server?Possono decidere quale protocollo eseguire;l'adattamento alla richiesta di un cliente (cliente) è un problema sociale, imporre una scelta al cliente è lo stesso.Se sono il server e stanno eseguendo FTPS, il tuo client deve supportarlo.Se stai eseguendo il server, è la tua sicurezza.
Scusate se non è stato chiaro, ma l'intera domanda riguarda se gli argomenti sono validi o meno.Lo scenario è stato fornito per fornire un contesto, chi dovrebbe avere l'ultima parola è una questione diversa.
C'è anche HTTPS con estensioni WebDAV.Questo ha tutti i vantaggi di FTPS (per quanto piccoli siano), ma non i suoi svantaggi in quanto funziona anche su una singola connessione.
Vorrei aggiungere che puoi anche fare sftp con server ftp tradizionali come proftpd, così puoi avere una configurazione familiare (chroot, directory virtuali, ecc.) Senza dover mettere a punto il tuo server openssh.Vedi http://www.proftpd.org/docs/contrib/mod_sftp.html
Se il server esegue già SSH per scopi di amministrazione, SFTP può essere preferito per limitare la superficie di attacco a un solo servizio anziché a due.
Avevo l'impressione che TLS supportasse anche l'autenticazione con chiave pubblica tramite certificati client.
Vale la pena sottolineare che qui c'è un errore comune, che sembra che il tuo amministratore di sistema di terze parti stia facendo (in effetti anche la maggior parte dei rispondenti sembra aver perso questo punto, anche se una coppia lo ha menzionato di sfuggita come @Steffen): ** SFTP! = FTP-over-SSH **.In effetti SFTP è un sottoprotocollo, correlato alla famiglia SSH, ma è distinto e separato da SSH, e * completamente estraneo a FTP *.Sembra che stia pensando a qualcosa come SecureFTP (che È FTP-over-SSH), che ha molti degli svantaggi che ha menzionato.Vedi di più qui: http://security.stackexchange.com/q/858/33
Ho accettato la risposta di Steffen Ulrich perché era la più istruttiva, ma anche i post di Marcelm e FjodrSo sono entrambi buone letture aggiuntive.
Sette risposte:
#1
+77
Steffen Ullrich
2016-04-28 13:03:20 UTC
view on stackexchange narkive permalink

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.
Per quanto riguarda l'ultimo punto elenco: il comando `SITE` (specialmente` SITE EXEC`) ha una storia piuttosto negativa in termini di sicurezza / exploit.Il "può fare solo trasferimenti di file" è vero solo per un server FTP sano e configurato correttamente.
@Mat: storicamente sì.Ma non ho mai sentito parlare di tali problemi per molto tempo, quindi presumo che i server oggi vengano forniti per impostazione predefinita con SITE non disponibile o limitato a poche cose.Considerando che con SFTP di solito è necessario limitare il server SSH per consentire solo SFTP.
Grazie mille per la risposta dettagliata, questa non è una risposta "sì / no" ma tende a confermare che con gli sforzi appropriati, si può ottenere una sicurezza molto buona con SFTP, paragonabile o addirittura migliore di FTP + S in alcuni casi.Sicuramente sufficiente tra due partner che hanno ragionevole fiducia nelle intenzioni dell'altro.
@StéphaneC .: e FTPS è sicuramente un incubo per superare firewall e NAT (cioè il tipico router SoHo).Pertanto, l'utilizzo di SFTP può far risparmiare molti problemi a coloro che devono supportare i propri utenti.
FTP è uno [stupido protocollo] (http://mywiki.wooledge.org/FtpMustDie) e deve morire.
* "apri una vasta gamma di porte (che è insicuro!)" * Senza alcuna motivazione fornita sul * perché * sarebbe insicuro, penso che sia un'affermazione un po 'strana.In genere non sono d'accordo (se la tua sicurezza dipende dalla chiusura delle porte, probabilmente c'è qualcosa che non va), ma ho pensato di commentare e chiedere prima di modificarlo ... (Nel complesso, buona risposta però - voto positivo).
@Luc: Pensavo fosse ovvio il motivo per cui aprire una vasta gamma di porte in un firewall è una cattiva idea.Ma ho riformulato questa parte in modo che si spera sia più chiara.E ovviamente la tua sicurezza non dovrebbe ** dipendere ** dalla chiusura delle porte, ma tali restrizioni fanno parte della sicurezza in profondità.Avere accesso illimitato dall'esterno all'interno su una vasta gamma di porte è solo una cattiva idea anche se i sistemi interni sono considerati (per lo più) sicuri.
@SteffenUllrich la tua modifica non ha effettivamente spiegato come il sistema sia reso meno sicuro avendo le porte accessibili.Avere il server FTP in ascolto su più porte non è meno sicuro di averlo in ascolto su una sola.So che il tuo consiglio è popolare, ma per quanto ne so la sua popolarità è solo un culto del carico.
@AndréParamés: è necessario lasciare le porte aperte anche se il server FTP o il client (!) Non è attualmente in ascolto su queste porte, perché non si sa mai se l'host utilizzerà queste porte.E potrebbe effettivamente essere che qualche altra applicazione (come qualche trojan o strumento RAT) sia in ascolto su questa porta ed è quindi accessibile dall'esterno.Semplicemente, lasciare una vasta gamma di porte aperte tutto il tempo perché FTP potrebbe usarne alcune a volte è una cattiva idea se vuoi usare un firewall per proteggere i tuoi sistemi.
@SteffenUllrich Vedo il tuo punto di vista su un trojan, ma se qualcuno può già eseguire codice sul tuo sistema probabilmente può fare abbastanza danni senza una porta aperta.Penso ancora che non sia un grosso problema, ma probabilmente questo appartiene a una risposta separata.(Ci sono già alcune domande al riguardo [1] (http://security.stackexchange.com/q/78802) [2] (http://security.stackexchange.com/q/9461) [3] (http://security.stackexchange.com/q/96568) [4] (http://security.stackexchange.com/q/13714) [5] (http://security.stackexchange.com/q/10729) [6] (http://security.stackexchange.com/q/9461), ma nessuna delle risposte è esaustiva.)
Sftp ha il vantaggio di poter utilizzare le connessioni di controllo master ssh, questo può essere un vantaggio, perché si effettua solo 1 connessione TCP e si invia il pass / key solo 1 volta, anche quando si utilizzano 10 connessioni sftp per aggirare l'alta latenzadella connessione satellitare tramite pipeline interno delle richieste
#2
+54
marcelm
2016-04-28 15:28:52 UTC
view on stackexchange narkive permalink

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;)

Tuttavia, per poter fare qualsiasi danno, gli aggressori devono ancora superare l'autenticazione, il che può essere estremamente difficile.Quindi capisco che devi assicurarti che tutte le porte siano chiuse e che forse questo renderebbe SFTP più rischioso se hai solo una fiducia limitata nei tuoi utenti
@StéphaneC.Vero.Ma hai detto che è un amministratore di sistema di terze parti.Allora perché dovrebbe fidarsi di te e darti potenzialmente più accesso del necessario?Non si tratta solo di intenti dannosi dalla tua parte;cosa succede se le tue macchine vengono compromesse?;)
Corretto, ma come affermato sopra possono esserci complicazioni e potenziali problemi di FW coinvolti dall'architettura multi-socket di questo protocollo.Immagino sia un compromesso.Ciò supera il potenziale (o quasi teorico?) Rischio per la sicurezza di SFTP?Difficile per me dirlo ...
È davvero un compromesso.Onestamente, se dovessi dare a terzi con cui non ho familiarità con l'accesso ai file a uno dei nostri server, probabilmente non sceglierei sftp.Ma per noi è per lo più interno e occasionalmente con terze parti fidate, quindi per noi i vantaggi di ssh / sftp vincono.
C'è un'altra cosa che ricordo ma non ho potuto verificare.Se si imposta l'autenticazione con chiave pubblica per la famiglia ssh, il tentativo di eseguire un MITM dopo quel punto non funziona anche se il client ha dimenticato la chiave host perché viene utilizzata la chiave di autenticazione.
Ricorda che, sebbene OpenSSH sia complesso e abbia un'ampia superficie di attacco, fa anche un ampio uso della separazione dei privilegi, come seccomp, un bambino con privilegi ridotti che comunica solo tramite pipe, rlimits e altro.Non credo che nessun client ftps abbia funzionalità simili.Quindi è difficile dire che OpenSSH ha più superficie di attacco quando è anche bloccato in modo molto più esteso.
@marcelm in merito a "Onestamente, se dovessi fornire a terze parti con cui non ho familiarità con l'accesso ai file a uno dei nostri server, probabilmente non sceglierei sftp.", Cosa useresti per il trasferimento di file tra terze parti?Sono arrivato in questa pagina dopo aver cercato i soliti 'FTPS - sftp pro / contro' e ho pensato perché non fare l'altra domanda :)
#3
+19
FjodrSo
2016-04-28 17:02:21 UTC
view on stackexchange narkive permalink

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:

  • Scambio di chiavi ECDSA : una chiave ECDS (X) a 521 bit è equivalente a una chiave RSA a 15.360 bit in termini di sicurezza e richiede cicli di CPU 9 volte inferiori per il calcolo della firma
  • Inherent forward segretezza : il protocollo SSH può rinegoziare l'effettiva chiave di crittografia del canale nella sessione e fornisce una segretezza intrinseca di inoltro, al contrario di qualsiasi server abilitato SSL / TLS che richiede un lavoro di configurazione aggiuntivo per eseguire questo

Quindi, alla fine, la scelta dipende davvero da voi ragazzi, ma l'argomento che stava facendo l'amministratore di sistema è palesemente non valido e se esiste un server SFTP esistente che è ben configurato (come spiegato) quindi non c'è motivo (soprattutto nessun motivo relativo alla sicurezza) per passare a FTPS (o FTPES).

Potete consigliarmi un server SFTP che semplifichi l'impostazione della modalità di solo trasferimento file?Potrei considerare di eseguire qualcosa del genere su una porta diversa per altri progetti.
Dai un'occhiata a Syncplify.me Server (informativa: è l'azienda per cui lavoro).Non credo di poter inserire link nei commenti, ma sono sicuro che puoi cercarli facilmente su Google.;)
@StéphaneC.Il modulo mod_sftp di ProFTPD implementa anche SFTP (e SCP), ma non l'accesso alla shell.
@FjodrSo ChangeCipherSpec non rinegozia le chiavi di sessione in TLS se sono in uso suite di crittografia che lo supportano?
SSL / TLS ha supportato FS con DHE dal 1999 e supporta ECDH (E) ed ECDSA dal 2006 - sebbene i numerosi implementatori nello spazio SSL / TLS non fossero attivi nel promuovere ECC come l'unico implementatore SSH dominante OpenSSH;per esempio OpenSSL non ha reso facile l'ECC in SSL / TLS fino al 2010. @reirab La rinegoziazione in SSL / TLS esegue l'intera sequenza di handshake, a partire da ClientHello (contenente l'indicazione di rinegoziazione se 5746 è usato come è quasi sempre) o ServerHelloRequest;CCS è solo il penultimo passaggio.SSH * può * rekey senza reauth, anche se non sono sicuro che qualcuno lo voglia.
Non definirei l'ECDSA un vantaggio, poiché è soggetto agli stessi problemi dei DSA.Ora, se hai detto EdDSA d'altra parte ...
#4
+2
Steve Sether
2016-05-20 22:23:47 UTC
view on stackexchange narkive permalink

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.).

#5
  0
KHChiu
2017-03-25 06:47:33 UTC
view on stackexchange narkive permalink

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.

Qualsiasi servizio pubblicamente raggiungibile può subire attacchi, sto eseguendo alcuni server web e il mio auth.log è pieno di tentativi di accesso in stile "root: admin123", generalmente entro pochi minuti dopo averli noleggiati.Per quanto riguarda l'indovinare una password complessa con la forza bruta, auguro loro buona fortuna.Non penso che tu possa incolpare il protocollo per questo, forse usa una porta alternativa e consenti solo l'autenticazione della chiave pubblica.
Tutto questo aneddoto mostra che gli aggressori martellano costantemente la tua porta 22 sperando di catturarti con una password SSH non sicura.Questo non è raro sul Web aperto e non significa che SSH stesso sia insicuro.Il semplice passaggio dalla porta 22 interromperà quasi tutte queste voci di registro anche se la sicurezza non sarà influenzata in modo significativo.
Il protocollo è comune ed è in circolazione da così tanto tempo che ci sono più tentativi di forza bruta contro di esso, e allora?Ciò non cambia la mia opinione che SFTP sia uno dei metodi di trasferimento file più sicuri possibili.
#6
-1
Richard R. Matthews
2017-03-25 23:38:54 UTC
view on stackexchange narkive permalink

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.

FTP [S] utilizza una connessione dati separata ma non la porta 22. SSL / TLS può utilizzare DSA, ma è raro sulla rete pubblica perché le CA pubbliche (Symantec GoDaddy ecc.) Per lo più non rilasciano certificati DSA;su intranet o comunità chiuse funziona bene (ed era l'unico modo per ottenere PFS su WinXP).OTOH recente OpenSSH (dalla 7.0 nel 2015) disabilita ssh-dss di default apparentemente perché SSH è limitato a DSA con SHA1;vedere https://crypto.stackexchange.com/questions/15051/why-does-openssh-use-only-sha1-for-signing-and-verifying-of-digital-signatures
#7
-2
Frank
2016-04-29 08:23:48 UTC
view on stackexchange narkive permalink

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.

Anche se creare una libreria di supporto completa fosse facile, non consiglierei di eseguire il proprio protocollo o l'implementazione FTP invece di soluzioni consolidate.Un considerevole tempo ed esperienza vengono investiti nella sicurezza dei server SSH / FTPS tradizionali dai loro manutentori, a un livello che sarebbe difficile per te eguagliare.Soprattutto se non è il valore principale della tua attività.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...