Securing FTP Server (vsftpd)

by lilsim89 Mar 31, 2007 11:57AM PDT

I run an FTP server to upload and download files in the same folder as the HTTP folder root. In other words, the files I upload\download via FTP, will be the pages\files on the website.

In vsftpd, the FTP server I'm running, the default login will give you the root of your harddrive! I've been through the manpages and documentation a thousand times, and I've found that to change the file root directory (the most parent folder the user can see), I have to establish actual Linux users, and their login (screen name\password) will log the into their home folder.

So to accomplish the complete server, this is what I do:

1. Create the group 'www' with r/w privileges to the /srv/www/htdocs folder (the website folder) if it doesn't exist already.
2. Create the user 'ftp_remote_admin' and have it belong in the group
'www' (So it will have r/w access to the http server folder.) Also, set the users home folder to /srv/www/htdocs.
3. Restrict access to only those who login (No anonymous), and only to the user 'ftp_remote_admin' via the vsftpd config file.
4. Set vsftpd.conf to move users into their home folder on login.

So the effect is: The user logs into vsftpd via a FTP manager with the screen name 'ftp_remote_admin'. Their root folder (again, upper-most folder) will be the HTTP server folder. When I upload\download a file via FTP, the HTTP requests will immediately see the new\changed file.

Please let me know if anyone sees a flaw in this design, or has a security tip. The design works great, and seems very secure, but since this will appear in a production system with personally identifiable information, I want to go through every precaution.

Please also use this thread about securing FTP servers in general.

-Simon

Discussion is locked

- Collapse -

Just one comment.

by r. proffitt Forum moderator Apr 1, 2007 2:17AM PDT

While http://vsftpd.beasts.org/#security notes what needs to be written about that, your design looks to be limited to serving one and only one web site per server.

Your choice but many people serve up dozens of websites per server.

Bob

- Collapse -

Internet FTP, eek!

by clsgis Apr 1, 2007 10:32AM PDT

FTP was invented a really long time ago, before there were criminals writing malware and breaking into other people's computers for profit. Users authenticate (prove who they are) by sending a password across the wire, in the clear, no encryption. If your FTP client is on an MS-Windows machine with a trojan network sniffer, the sniffer sees your password and hands your account over to its crime gang. If your MS-Windows machine is on a dumb Ethernet hub or an older cable modem run, your network neighbors' trojans can sniff your password, too. If your locked-down GNU+Linux box is colocated next to some clown running MS IIS, and your colo-provider uses dumb Ethernet hubs, Bozo's trojan can sniff your users' passwords.

So don't do that. Use the SFTP function of Secure Shell Version Two instead. Your system probably came with the OpenSSH Project's implementation of that.

If your users will die before they give up their commercial FTP clients, and those clients are so old they can't do SSH2/SFTP, then you'll have to set up an SSL Certificate and run FTP-over-SSL. (Also known as FTPS.) That's a kludge for encapsulating at least FTP's control channel in an SSL tunnel. And set vsftpd so it won't accept a plain text login.

If your users are reasonable, tell them SFTP is the Way the Truth and the Light, and ask the Windoze users to try Filezilla and WinSCP and tell you which they like better.

If your users are technical, generate key-pairs for them (with ssh-keygen) and send them each a private key, and don't allow password logins at all.

One more thing. If your server is up 24/7, it will get dictionary attacks 24/7 against at least FTP and SSH. Use strong passwords. Look in /etc/ssh/sshd_config and move SSH to some port besides 22. It won't protect you from a determined cracker, but a robot scanning the network for SSH servers may overlook it. Even if your passwords are excellent and nobody will ever guess one, attackers enlarge your logfiles and consume CPU and disk.

And if you're really serious, find out if your sshd was compiled with "tcpwrappers support." If it was, put your users' networks in /etc/hosts.allow, and edit /etc/hosts.deny to block the whole world from your SSH server. If it wasn't, you can do that in netfilter instead. Either way, do it with a couple of shells open and make sure you can still log in after each change. It's no fun to firewall yourself out of a distant machine.

- Collapse -

I see your point.

by lilsim89 Apr 1, 2007 4:42PM PDT

The FTP server will be available only to edit the files of just one HTTP site. That site will most likely be modified by me only, or someone in my place using the same tools that I use. To clear it up, the FTP and HTTP server will be ran from the same guest, on a Windows 2003 SE host, via VMWare Server. The dictionary attacks might be a problem, so I'll only allow certain IP addresses and\or use a very strong password(my testing password is very weak).

Come to think of it, the server will only be available via LAN; an NAT will discard all packets from the WAN port. The site will serve the organization's member database (1000 members at the most). It needs to be efficient, and pretty much free, so I said Linux is the only way to go.

There should be no need to SSH since my work will not involve system configuration, and I have hardware access.

It seems my FTP problems end here, and now my PHP authentication problem begin. I've been going mad making secure scripts to login users. That's out of this thread's scope, though. I'll take it elsewhere.

Thank you Bob, and thank you Clsgis.

-Simon

Securing FTP Server (vsftpd)

CNET Forums

Other Forums

Forum Info