FTP non crittografato per trasferire i dati crittografati - ok se limitato IP?

È difficile dire quale sia la tua definizione di "OK", ma in generale, direi, no, non sei d'accordo con la tua configurazione attuale. Coprirò i tuoi punti individualmente.

• I dati trasferiti sono strongmente crittografati. Questo è buono. In altre parole, è possibile inserire il file con un collegamento per il download su un sito Web pubblico. Se ti fidi della crittografia, i tuoi dati sono ragionevolmente sicuri. Tuttavia, se i tuoi dati hanno un valore eccezionale che varrebbe la pena spendere tempo e denaro per decifrare, allora la gente proverà. Anche con i migliori metodi di crittografia, avere molte persone che cercano di romperlo non è l'ideale. Ma presto diventerà chiaro il motivo per cui lo cito come alternativa a FTP.
• La restrizione IP è a livello del firewall. Questo è buono. Ciò significa che anche se i tuoi dati valgono la pena di decifrare, ciò non sarà possibile a meno che non sia possibile eseguire un attacco MITM o in qualche modo prendere il filo. Questo aggiunge protezione.
• C'è una protezione sul server FTP contro la cancellazione dei file (anche se non si sovrascrive). Qui è dove hai sbagliato. Testo normale FTP va bene, fino a quando non si accetta alcun tipo di modifica e si è detto che è possibile sovrascrivere il file. Ora stai peggio di te se non avessi usato FTP in primo luogo. Staresti meglio con il link per il download pubblico, almeno nessuno può spazzare via i tuoi dati.
• Le credenziali non sono valide per altri servizi. Questa è una buona cosa, perché dovresti trattare il ftp in testo semplice come se le credenziali fossero di dominio pubblico.

TLDR; Rimuovi i diritti di modifica sull'utente ftp e poi direi che stai bene, anche se la tua configurazione è strana. (E per strano intendo, perché avere tutte le protezioni e poi usare il testo in chiaro ftp?)

Per rispondere alla tua altra domanda specifica - se qualcuno annusa nome utente e password, E se possono salire sul filo (ma lo sono già se stanno sniffando!), allora possono sostituire il tuo file crittografato con uno diverso . Sarebbe sicuramente una brutta giornata se i tuoi dati importanti fossero stati sostituiti un giorno con un file di testo che dice semplicemente "F Society".

Ho un setup simile, un server ftp linux inserito nella whitelist, ricevere un file crittografato in chiaro e ho fatto domande simili.

Per prima cosa, l'ho impostato come anonimo, dal momento che qual è il punto di accesso in chiaro? In secondo luogo, è nella whitelist, quindi l'unica vulnerabilità teorica è lo spoofing IP.

Ho letto su IP spoofing in particolare per quanto riguarda ftp, e sembra che, in teoria, (oltre al fatto che lo spoofing IP non sia banale da solo) ftp è difficile ingannare con un IP falsificato. Il server viene prima contattato sulla porta 21, ma poi risponde a una porta alta arbitraria sul client. Pertanto, a meno che l'autore dell'attacco non possa reindirizzare la risposta (qualcuno suggerito tramite l'avvelenamento della cache DNS) all'indirizzo di origine non falsificato, non dovrebbero essere in grado di accedere al server ftp.

La preoccupazione man-in-the-middle sarebbe, penso, che avrebbero catturato il file prima che arrivasse al server previsto. E poi potrebbero battere la crittografia a loro piacimento.

Se non riescono a ottenere una sessione spoofing, non possono sovrascrivere.

Ma se possono eseguire una sessione spoofing, la tua unica protezione per i tuoi dati sarebbe quella di copiare (o spostare) i tuoi dati all'esterno dell'albero dei file accessibile da ftp. Principalmente perché non so come garantire l'accesso in scrittura senza concedere l'accesso di riscrittura.

Nello scenario non viene eseguita alcuna autenticazione del server. Ciò significa che un uomo nel mezzo potrebbe rivendicare di essere il server e inviare al client qualsiasi tipo di dati. Se questo è un problema dipende dal caso d'uso: se i download sono crittografati e firmati, il client può verificare l'origine dei dati e se sono stati modificati. Il client non è ancora in grado di rilevare se l'uomo nel mezzo nasconde alcuni file dall'elenco delle directory, perché la lista di directory stessa non è protetta.

E, come già noti tu stesso, non c'è protezione contro i file di sovrascrittura. Se questo è un problema dipende ancora dal caso d'uso, vedi sopra.

Inoltre, le credenziali utilizzate per accedere al server sono pubbliche. A meno che queste credenziali non vengano generate solo allo scopo di accedere al server, è possibile che vengano riutilizzate da qualche altra parte e quindi l'utente malintenzionato potrebbe ottenere l'accesso ad altri servizi che utilizzano tali credenziali. Il riutilizzo della password è un grosso problema.

Se un uomo nel mezzo dello scenario è possibile dipende dalla tua configurazione. Potrebbe essere possibile se l'attaccante ha accesso ai router, potrebbe manipolare le informazioni di routing con altri metodi o ottenere l'accesso a qualche middlebox tra client e server.