We have nearly finished rewriting a legacy web app system and have moved the domain name to a new server. The only other feature we have to make is a small one that must interface with another server that I have no control over.
The old system periodically received data from this other server via unsecured ftp. Apparently the other server would log into our server and put a data file in a specific directory, which our system would read.
We have the username and password used to log in. My idea was to create an ftp account using this same username and password on the new server. Doing this we would not have to modify the other server.
I've seen many articles saying unsecured ftp is insecure. Can I do anything to make this work without compromising the security of the rest of our server (which hosts several production websites). The data in this file is going to be directly displayed on a website, so it doesn't matter if the file itself is secure.
Can I set up something where I create a user with very limited privileges that can receive this file in a specific directory that another user can read from?
Edit: We are running Ubuntu server 11.04 on a Linode, so I have full control over our server.
Unless you could alter that other server in some way or find a way to proxy the connection through SSH, the only thing short of connecting that legacy system to your server with a direct crossover connection on a separate ethernet card is to sandbox that ftp user as much as possible. Jail the ftp user's access to have the minimum access necessary to create that file, make sure that the user's password isn't used anywhere else in the system.
I don't recall reading what you're running for the server; make sure the process is running as a context of an unprivileged user, and if you know when this file is supposed to be transferred each day, you could try creating a script that activates and deactivates the FTP server so the legacy system could only access it at specific times of day.
You can also set it up so only that legacy system can FTP into your server; anything else attempting to connect from another IP is logged but denied.
You could certainly try to limit the amount of damage that could happen if the account's password were sniffed. You might not be able to do this without impacting the business process.
You don't say how much control you have over the sending system though. If possible, you could swap FTP for SFTP or FPTS, or tunnel the connection using IPSec.