Unencrypted FTP to transfer encrypted data - okay if IP-restricted?

Question

If unencrypted FTP over the public internet is the only file transfer option for a particular situation, what security concerns are applicable assuming:

• The data being transferred is strongly encrypted by whatever / whoever is creating the files
• IP-restriction is in place at the firewall level so only one designated IP can connect via FTP
• There is protection in place on the FTP server against file deletion (though not overwriting)
• The credentials aren't valid for any other services (e.g. SSH access)

If someone sniffs the username and password, could they even do anything with it? I don't really understand what's possible with IP spoofing, but I'm thinking the only case where they could issue FTP commands with the credentials is if they had a privileged position somewhere along the network route and were able to spoof the IP that normally connects in via FTP - like a man in the middle type of attack though I'm guessing they could initiate it at will.

Of course if VPN / SSH port forward / etc. were options, those could be preferable, but I'm wondering about this particular situation.

Answer 1

I have a similar set-up, a whitelisted linux ftp server, receiving an encrypted file in the clear, and have asked similar questions.

For one, I have it set up as anonymous, since what is the point of a login in the clear? Second, it is whitelisted, so the only theoretical vulnerability is IP spoofing.

I read up on IP spoofing specifically in regard to ftp, and it seems that, in theory, (beyond the fact that IP spoofing is non-trivial on its own) ftp is difficult to fool with a spoofed IP. The server is first contacted on port 21, but then responds to an arbitrary high port on the client. So unless the attacker can redirect the response (someone suggested through DNS cache poisoning) to the non-spoofed source address, they shouldn't be able to log onto the ftp server.

The man-in-the-middle worry would be, I think, that they would capture the file before it got to the intended server. And then they could pound away at the encryption at their leisure.

If they can't get a session by spoofing, they can't overwrite.

But if they can can a session by spoofing, your only protection for your data would be to copy (or move) your data outside of the file tree accessible by ftp. Mostly because I don't know how to grant write access without granting re-write access.

Answer 2

It's hard to say what your definition of "OK" is, but generally, I'd say, no, you're not ok with your current setup. I'll cover your points individually.

• The data being transferred is strongly encrypted. This is good. In other words, you could put the file with a download link up on a public website. If you trust the encryption, then your data is reasonably safe. However, if your data has tremendous value that would be worth spending time and money to decrypt, then people will try. Even with the best encryption methods, having many people trying to break it is not ideal. But it will soon become clear why I mention this as an alternative to FTP.
• IP-restriction is in place at the firewall level. This is good. This means that even if your data is worth attempting to decrypt, it will not be possible unless you can pull off a MITM attack or somehow else get on the wire. This adds protection.
• There is protection in place on the FTP server against file deletion (though not overwriting). This is where you went wrong. Plain Text FTP is fine, until you allow any sort of editing at all- and you said you can overwrite the file. Now you are worse off than if you didn't use FTP in the first place. You'd be better off with the public download link- at least no one can blow away your data.
• The credentials aren't valid for any other services. That's a good thing, because you should treat the plain text ftp as if the credentials are public knowledge.

tldr; Remove the edit rights on the ftp user and then I'd say you're ok, even though your setup is strange. (And by strange I mean, why have all the protections and then use plain text ftp?)

To answer your other specific question- if someone sniffs the username and password, AND if they can get on the wire (but they already are if they're sniffing!), then they can replace your encrypted file with a different one. It sure would be a bad day if your important data was one day replaced with a text file that simply says, "F Society".

Answer 3

In your scenario no authentication is done of the server. This means a man in the middle could claim to be the server and send the client any kind of data. If this is a problem depends on the use case: If any downloads are encrypted and also signed the client can verify the origin of the data and if they got modified. The client can still not detect if the man in the middle hides some files from the directory listing, because the directory listing itself is not protected.

And, as you already note yourself, there is no protection against overwriting files. If this is a problem again depends on the use case, see above.

Also, the credentials used to access the server are public. Unless these credentials are generated only for the purpose to access the server it might be that they are re-used somewhere else and thus the attacker could get access to other services using these credentials. Password reuse is a big problem.

If a man in the middle scenario is possible depends on your setup. It might be possible if the attacker has access to routers, could manipulate the routing information with other methods or got access to some middlebox in between client and server.