FTP sin cifrar para transferir datos encriptados, ¿está bien si IP está restringido?

Es difícil decir cuál es tu definición de "OK", pero en general, yo diría que no, no estás de acuerdo con tu configuración actual. Cubriré tus puntos individualmente.

• Los datos que se transfieren están fuertemente encriptados. Esto es bueno. En otras palabras, podría colocar el archivo con un enlace de descarga en un sitio web público. Si confía en el cifrado, entonces sus datos son razonablemente seguros. Sin embargo, si sus datos tienen un valor tremendo que valdría la pena gastar tiempo y dinero para descifrar, la gente lo intentará. Incluso con los mejores métodos de encriptación, tener muchas personas que intentan romperla no es lo ideal. Pero pronto quedará claro por qué menciono esto como una alternativa al FTP.
• La restricción de IP está implementada a nivel de firewall. Esto es bueno. Esto significa que incluso si vale la pena intentar descifrar sus datos, no será posible a menos que pueda realizar un ataque MITM o de alguna otra manera conectarse. Esto agrega protección.
• Hay una protección en el lugar en el servidor FTP contra la eliminación de archivos (aunque no se sobrescribe). Aquí es donde salió mal. Plain Text FTP está bien, hasta que permita cualquier tipo de edición, y dijo que puede sobrescribir el archivo. Ahora estás peor que si no hubieras usado FTP en primer lugar. Estaría mejor con el enlace de descarga público, al menos nadie puede eliminar sus datos.
• Las credenciales no son válidas para ningún otro servicio. Eso es bueno, porque debe tratar el ftp de texto sin formato como si las credenciales fueran de conocimiento público.

tldr; Elimine los derechos de edición en el usuario ftp y luego diría que está bien, aunque su configuración sea extraña. (Y por extraño quiero decir, ¿por qué tener todas las protecciones y luego usar ftp de texto sin formato?)

Para responder a su otra pregunta específica: si alguien encuentra el nombre de usuario y la contraseña, Y si pueden conectarse (¡pero ya lo están si están olfateando!), entonces pueden reemplazar su archivo cifrado por uno diferente. . Seguro que sería un mal día si sus datos importantes se reemplazaran algún día con un archivo de texto que simplemente diga "Sociedad F".

Tengo una configuración similar, un servidor ftp de Linux incluido en la lista blanca, recibiendo un archivo cifrado a la vista, y he hecho preguntas similares.

Por un lado, lo tengo configurado como anónimo, ya que ¿cuál es el punto de un inicio de sesión en claro? En segundo lugar, está incluido en la lista blanca, por lo que la única vulnerabilidad teórica es la falsificación de IP.

Leí sobre el IP spoofing específicamente con respecto a ftp, y parece que, en teoría, (más allá del hecho de que el IP spoofing no es trivial por sí solo) ftp es difícil de engañar con un IP falso. Primero se contacta con el servidor en el puerto 21, pero luego responde a un puerto alto arbitrario en el cliente. Entonces, a menos que el atacante pueda redirigir la respuesta (alguien sugirió a través del envenenamiento de caché de DNS) a la dirección de origen no falsificada, no debería poder iniciar sesión en el servidor ftp.

La preocupación del hombre en el medio sería, creo, que capturarían el archivo antes de que llegara al servidor deseado. Y luego podrían librar el cifrado a su antojo.

Si no pueden obtener una sesión mediante suplantación de identidad, no pueden sobrescribir.

Pero si pueden realizar una sesión mediante suplantación de identidad, su única protección para sus datos sería copiar (o mover) sus datos fuera del árbol de archivos accesible por ftp. Sobre todo porque no sé cómo conceder acceso de escritura sin conceder acceso de reescritura.

En su escenario no se realiza ninguna autenticación del servidor. Esto significa que un hombre en el medio podría reclamar ser el servidor y enviar al cliente cualquier tipo de datos. Si este es un problema, depende del caso de uso: si alguna descarga está cifrada y también firmada, el cliente puede verificar el origen de los datos y si se modificaron. El cliente todavía no puede detectar si el hombre en el medio oculta algunos archivos de la lista de directorios, porque la lista de directorios en sí no está protegida.

Y, como ya te has dado cuenta, no hay protección contra la sobrescritura de archivos. Si esto vuelve a ser un problema, depende del caso de uso, vea más arriba.

Además, las credenciales utilizadas para acceder al servidor son públicas. A menos que estas credenciales se generen solo con el propósito de acceder al servidor, podría ser que se reutilicen en otro lugar y, por lo tanto, el atacante podría obtener acceso a otros servicios utilizando estas credenciales. La reutilización de la contraseña es un gran problema.

Si es posible un hombre en el escenario intermedio depende de su configuración. Podría ser posible si el atacante tiene acceso a enrutadores, podría manipular la información de enrutamiento con otros métodos u obtener acceso a algún middlebox entre el cliente y el servidor.