FTP in general has a long and sad history of security problems. If you need to run an ftp server, you need to keep careful track of vulnerabilites and exploits that may make for a very unhappy day. Things have gotten better in recent years, but just as I started this article I checked the wu-ftpd site and found a fairly recent problem noted, and an even more recent problem discussed at proftpd.org . Makes you want to forget ftp entirely, doesn't it?
I do think the more widespread availablility of ssh (hence scp and sftp) has made anything but anonymous ftp less necessary, and that does help - at least there aren't as many unencrypted logins flying around.
The main problem with ftp is that it almost always runs with root privilege, at least part of the time. It needs to bind to low ports (20 and 21) at a minimum, which requires root, and there are probably other points where it needs more than ordinary user abilities. Modern implementations try to avoid being root when they don't need to, but of course that's not perfect. Other damage limiting attempts involve running in a chroot jail.
Note there is a bit of a difference between the chroot options often present in ftp configuration files and a real unix level chroot. To use the latter, you need to set up a number of files and directories to include libraries, vital commands and files like /etc/passwd and more. The "chroot" options for ftp daemons mean that an ftp login can't cd above the specified point. These are similar restrictions, but technically quite different.
| SCO ftp has a annoying little problem where syslog fills up with messages like "#2 open of pid file failed: No such file or directory". This is caused by their "cleantmp" program removing symbolic link "/usr/tmp/ftpd". See http://wdb1.sco.com/kb/showta?taid=107639&qid=66017922&sid=2111491808&pgnum=1 |
There are many, many ftp server programs available. I found a short list at http://www.linuxmafia.com/faq/Network_Other/ftp-daemons.html and I'm sure there are many more. However, the most commonly found are wu-ftp and proftp (though vsftp is becoming more popular). Any ftp daemon is going to have its share of features and quirks, and of course its own security measures. Most all will provide at least basic security like setting umask and determining who can or cannot use the server. I won't be covering everything in what follows, but will hit the highlights.
One simple security step with any ftp server is not to help by advertising. Here's a talkative server just begging for you to go look up its vulnerabilities:
ProFTPD 1.2.4 Server (FTP) [ftp.xyz.com]
If you add "ServerIdent Off" to the proftd.conf, it's a bit less chatty:
220 ftp.xyz.com FTP server ready.
For wu-ftp, the file is "ftpaccess", and you want 'greeting terse' or 'greeting brief'.
You surely also want to disallow certain users from using ftp. It would usually be a very poor idea to let root have an ftp login, for example. With both wu-ftp and proftp (and many other ftp's), you list disallowed users in /etc/ftpusers. Proftpd disallows root by default, regardless of ftpusers. If you did "RootLogin on" in proftpd.conf, you'd still need to remove root from /etc/ftpusers should you need this.
You can also restrict to certain ip's:
proftpd.conf:
<Limit LOGIN>
Order Allow,Deny
Allow 192.168.2.8, mydomain.com, anotherdomain.net,
Deny from all
</Limit>
wu-ftpd ftpaccess:
(from man page)
deny <addrglob> <message_file>
Always deny access to host(s) matching <addrglob>.
<message_file> is displayed. <addrglob> may be
"!nameserved" to deny access to sites without a working
nameserver. It may also be the name of a file,
starting with a slash ('/'), which contains
additional address globs, as well as in the form
address:netmask or address/cidr.
To prevent password guessing, you may set limits on login attempts:
proftpd.conf: MaxLoginAttempts 4 wu-ftpd ftpaccess: loginfails 3
You can also do things like limiting the total number of ftp sessions, though your ability to do that will have to be external if the daemon is started on demand by inetd or xinetd (xinetd includes feature for limiting connections). If run standalone, the main instances spawns off children to handle connections, and can limit those as desired.
Although not strictly a security issue, you can set limits on the amount of data or number of files that can be transferred, how long people can remain logged on, etc. See "man ftpaccess" for wu-ftpd and http://www.proftpd.org/docs/directives/linked/by-name.html for proftpd.conf.
To have anonymous ftp, you usually need a little bit of setup. If you don't have an "ftp" user, you'll need to create that. Note that ftp servers allow "anonymous" as a synonym for ftp. That's from a config setting in proftpd.conf:
proftpd.conf: UserAlias anonymous ftp
No special definition is necessary for wu-ftpd.
For most ftp's, you need a /var/ftp/ directory for anonymous ftp to work. The configuration files usually have examples of what you have to turn on for anonymous ftp.
There are configuration limits here:
proftpd.conf: MaxClients 10 "Maximum anon users reached, try again later" wu-ftpd ftpaccess: limit anon 120 SaSu|Any2000-0600 /etc/msg.toomuchload limit anon 30 Any /etc/msg.toomuchload # Allows more users on weekends and 8PM to 6AM
Apparently sftp can be setup for anonymous use also (http://www.mcknight.de/jftpgw/howtouse-sftp.html, see last paragraph), though I've never seen it done. That said, a lot of sites don't even turn on sftp at all: it's a setting in the config file:
Subsystem sftp /usr/libexec/sftp-server
My current favorite is lftp. My least favorite is Internet Explorer, though I will often have clents use that if I need them to ftp somewhere from Windows. Note that they can provide a login and password: use ftp://usr:password@ftphost.com, so you can use that even for an ftp to a user directory on your network.
More Articles by Tony Lawrence - Find me on Google+
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Click here to add your comments
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar