Section 4.4 FTP

   


4.4 FTP

graphics/fivedangerlevel.gif

FTP suffers from most of the same problems as telnet and the solution is the same. Replace it with SSH (for most nonanonymous use). SSH2 offers sftp, a feature introduced early in 2000. Because some sites will not want to use SSH2 due to its license being much more restrictive than SSH1 or OpenSSH, alternatives are SSH-wrapped FTP, scp, and SSL-wrapped ftp. OpenSSH now offers sftp too. See "Wrapping SSH Around Other TCP-Based Services" on page 419 for details on creating SSH-wrapped FTP.

Additionally, even some recent versions of WU-FTPD, the FTP daemon created by Washington University at St. Louis, suffer from security bugs. These include a buffer overflow bug that allows a remote intruder to make himself root. This version was in common distributions as late as 1999.

I determined that one of a client's development machines very likely was broken into via this overflow bug.

I scanned his system for cracker-induced alterations using methods discussed in Part IV, using tar. The Network Administrators and I then explained to him the benefits and usage of TCP Wrappers and SSH and how they could allow him safely to connect in from his home system and to transfer files between these two systems.


You will want to check the errata for your distribution, discussed in Appendix A, to ensure that your version of WU-FTPD does not have these bugs in it. The Linux Administrators Security Guide reports that several nasty DoS vulnerabilities still existed in WU-FTPD as of 1999 and that improper server setup allows a cracker to obtain privileges that she should not have. "Upgrade WU-FTPD" on page 112 tells where to get updates and determine the most recent version available.

ProFTPD is preferred by many security-conscious sites, including Debian and SourceForge and some Linux vendors. It may be downloaded from

www.protftpd.net/

Another alternative is to make use of the BSD FTPD implementation, which has been ported to Linux. It is available from the CD-ROM or from

ftp://quatramaran.ens.fr/pub/madore/ftpd-BSD/ftpd-BSD-latest.tar.gz

or

ftp://quatramaran.ens.fr/pub/madore/ftpd-BSD/ftpd-BSD-0.3.2-2.i386.rpm


A popular thing for crackers to do when they compromise a system's FTP daemon or if they find a site that allows anyone to upload data for public download is to use it as a repository for warez (cracker-speak for cracker wares; in other words, cracker programs for distribution that might get you accused of being a cracker) and pornography which could make for some really bad publicity. The storage of music and other copyrighted material is becoming common too. IRC 'bots also are a popular usage. This is a very good reason not to offer a public FTP site.

There are a number of solutions including some combination of the following:

  1. Wrap the FTP daemon with SSH or use sftpd, that is part of SSH2. See "TCP Wrappers" on page 555 and "Using sftp" on page 418.

  2. Allow the use of FTP only by trusted clients via TCP Wrappers or firewalling with IP Chains.

  3. Make use of the WU-FTPD feature to chroot anonymous users and even nonanonymous users if desired. Issuing man 5 ftpaccess will generate useful documentation on many of WU-FTPD's capabilities to limit which systems and users may access it, how to use its chroot capability, how to specify which of its commands will be allowed, and so on.

  4. Consolidate your "anonymous FTP" needs onto a single system that has no confidential data and which is outside your corporate network, and typically in the DMZ. Thus, if it is cracked then there is nothing to "get," though there then will be a risk of the cracker causing the distribution of undesirable files.

  5. On your Web server (httpd), supply the MD5 checksums for the files that you distribute on your FTP server so that those that download these files can verify that they are correct and that the files on the FTP server have not been altered. For extra security, your Web server and FTP server should be separate machines. For even higher security, CGI operation should take place on a third machine and all of these machines should be in a DMZ that allows only appropriate services to each of these systems.

  6. If one person wants to give data to a second person and they cannot transfer it easily via other methods such as e-mail (possibly wrapped in PGP or SSL), the first person could FTP up to the FTP server and then the second person could pull it down. The advantage of this two-step procedure over one user ftping into the other user's machine is that neither user's own system has to suffer the security risks of being a FTP server.

As part of the "Rings of Security," you do not want to allow anyone to FTP into your root account because this would allow someone to crack your system by knowing only the root password. Likewise, you will want to block FTP from accessing your other system accounts and certain additional accounts too. These account names may be listed in the /etc/ftpusers file, one per line to prevent anyone from logging in via FTP to them. Blank lines and comment lines starting with the "#" character are allowed too.

The most elegant and easiest way to add a user to the /etc/ftpusers file to forbid any remote user from logging into FTP as this user is the use of the echo command and the shell >> operator to append a command's output to the named file. Thus, to prevent anyone from using the root and ftp (anonymous) accounts via FTP, issue the following commands. (Thanks to the Nessus team for this technique.)

 
 echo root >> /etc/ftpusers echo ftp  >> /etc/ftpusers 

4.4.1 Configuring Anonymous FTP

Many Linux distributions offer anonymous FTP configurations either standard or as options. Frequently, the configurations supplied are not as secure as they could be, so you will want to examine them carefully and correct them so that they conform to the guidelines discussed here.

4.4.1.1 Limiting Who Can Log In Anonymously

If the -a flag was given to enable the use of the /etc/ftpaccess configuration file, the guestserver command may be used to specify which hosts someone may initiate an anonymous login from. If an argument is supplied, only this host may be used for anonymous login. Multiple guestserver commands may be used to specify multiple hosts. If guestserver is specified without a host, anonymous login is disabled. Disabling all anonymous logins this way is equivalent to specifying ftp in the /etc/ftpusers file.

4.4.1.2 Specifying ftp's Home Directory

The choice of where to specify FTP's home directory, ~ftp, in the real /etc/passwd file depends on whether you will offer downloading only (Read/Only access) or downloading and uploading (Read/Write access). Allowing only uploading is possible and should be treated similarly to Read/Write except that there will be no files for download. If there will be uploading, steps must be taken to prevent malevolent or unintentional excessive uploading from causing an important file system to run out of space. The preferred solution is to use a separate file system, though quotas may also be used. Using /home is discouraged if you have real users.

Although /var is intended for system-related files that "grow," system log files normally are kept there and you really do not want to allow an anonymous FTP user to be able to fill up the file system used for logging and thereby stop logging. Besides this happening unintentionally, this makes it easy for a cracker to block logging as the first step in an attack. Certainly, you can compute how long it would take someone to fill up a disk. A baud is a bit per second and it takes roughly 10 bits per character. Thus, over a 33 Kbaud (kilobaud) PPP line, 3.3 KB could be transferred in a second or 11.6 MB per hour or 278 MB per day. It would take four days to use up 1 GB. A T1, which is rated at 1.544 megabaud, is 48 times as fast so it would fill a 1 GB partition in two hours. Do not even think of using a bootable device such as floppy.

4.4.1.3 Adding the ftp User and Group

Create an ftp user in /etc/passwd and an ftp group in /etc/group. The UID and GID should be different than that of any other user or group. The ftp user, group, UID, and GID should be used only as discussed here. A directory tree of common system directories needs to be created under ~ftp. This includes the bin, etc, lib, and pub directories. Most modern distributions offer this chroot anonymous FTP configuration by default; Red Hat and Slackware do.

4.4.1.4 File Ownership

Except where noted, all files and directories under ~ftp absolutely must have an owner and group with a UID and GID that is different from that of the ftp user and group (except where noted). Failure to adhere to this advice is a common mistake and will cause security problems. Create a separate account and group called ftpadmin with a separate UID and GID than ftp and have the files in ~ftp owned by ftpadmin with a group of ftpadmin. Thus, those that maintain the anonymous FTP files need only the password for ftpadmin, not root.

You will need to populate this directory tree with a few small pieces of the Linux root file system. The directories needed include bin, etc, and pub. If you will be using a chrooted environment, which is an excellent idea, create a lib directory too, to hold any dynamically linked libraries. By default, anonymous FTP logins run in an environment chrooted to ~ftp and this should not be altered. All of these directories should have an owner of ftpadmin, a group of ftpadmin, and be mode 755. Next, you will need to create some files. First on the file parade are passwd and group; they go in ~ftp/etc.

4.4.1.5 FTP's passwd and group Files

You positively must not use the real passwd or group files. That would be giving away security information to crackers that will enable them to break into your system, specifically account names and, if shadow passwords are not used, encrypted passwords for them to break on their own systems at their leisure. Many Linux distributions that provide anonymous FTP violate this rule and probably you will need to alter the existing configuration. Instead, create fake passwd and group files that have different names, UIDs and GIDs, and different encrypted passwords. In fact, you will want to ensure that none of the names in ~ftp/etc/passwd or ~ftp/etc/group are real, except to provide a mapping from the UID and GID of the files under ~ftp back to some names. These typically would be a user and group of ftp and ftp.

Even these names (for UID 0 and whatever GID, such as GID 0, is used) do not have to be real, though mapping them back to a user of root and a group of root or wheel is not giving away any secrets. Having the FTP versions of these files be different from the real /etc/passwd and /etc/group is absolutely necessary for security. The fake passwd and group files are used by the dir command to show the ownership of files under the FTP hierarchy when the FTP ls command is given. You can allow the real and FTP versions of the passwd and group files to have the same UID and GID for ftp because there is no reason not to and because it is less confusing. It is suggested that a high value be used for the UID and GID to reduce the likelihood of the same value being used for other purposes accidentally. (Note that some popular distributions violate this rule; you should correct your systems.)

The following may be used as the ~ftp/etc/passwd file.

 
 root:*:0:0::: bin:*:1:1::: ftp:*:9910:9910::: 

The following may be used as the ~ftp/etc/group file.

 
 root::0: bin::1: ftp::9910: 
4.4.1.6 The ftpd Arguments

The FTP daemon typically is started by inetd with the mapping provided by an entry in /etc/inetd.conf. This is where you decide whether to use TCP Wrappers. Even if you offer a public anonymous FTP service, you probably want to use TCP Wrappers. This will allow you to shut off bad users by disallowing anyone from their hosts a connection. Certainly some sites will want to use IP Chains instead. If you use the Adaptive TCP Wrappers described in "Adaptive Firewalls: Raising the Drawbridge with the Cracker Trap" on page 559 you will want to enable TCP Wrappers so that if the system detects someone attempting to crack it, that system will be locked out of FTP too.

The Washington University FTP daemon that you will probably be using has a number of arguments, some of which you will want to use.

  • -l causes each FTP connection to be logged. This is highly recommended.

  • -L causes each FTP command to be logged. This includes connections as well as each command. This is useful for analyzing your users' behavior as well as for spotting abuses. Do note the minor issue that if a user accidentally enters her password instead of her user name to the USER command, her password will be logged. If your log files are publicly readable, which is a bad idea, her password will be on public display. This flag is overridden if ftpaccess is used. This is a polite way of saying that it is silently ignored if use of the ftpaccess file is specified with the -a flag. In this case, add the following line to /etc/ftpaccess to get this effect.

     
     log commands anonymous,guest,real 
  • -i causes logging of each put request, which uploads a file to the server. It is logged to the xferlog file, normally under /usr/adm, unless the -X flag also is given in which case logging is through the syslog facility. This combination allows you to use the syslog facility to consolidate the logs of more than one system on a single system for convenience and security. Considering the past security problems that have been encountered with FTP, this is an excellent idea. It allows the logging of FTP results to a more secure system so that a successful cracker will not be able to destroy the logs that might give clues to what he did and how. The -i flag is overridden if ftpaccess is used.

  • -o causes the logging of output. See -i for the effect of -X and ftpaccess.

  • -X modifies -i and -o to cause logging to be done via syslog instead of being logged by FTPD directly to the xferlog file. See also the discussion on -i.

  • -u specifies the default umask.

  • -W suppresses the logging of each user logged in under ftp in the wtmp file. Its use is discouraged.

  • -r causes FTPD immediately to do a chroot to the specified directory for all users, not just the anonymous or ftp user. This provides substantial additional security that is useful for many sites. A directory tree may be created somewhere, with symbolic links to subdirectories under it from the accounts of users that want to use FTP. This directory tree might be /home/ftpusers and for users joe and sally the following commands could be issued by root:

     
     cd /home/ftpusers mkdir joe sally chgrp users joe sally chown joe joe chown sally sally ln -s /home/ftpusers/joe /home/joe/ftp ln -s /home/ftpusers/sally /home/sally/ftp 
  • -d causes debugging information to be logged via the syslog facility.

  • -a causes the ftpaccess(5) file in /etc to be used to control FTPD's configuration. This allows much more detailed configuration. A typical entry for ftp in /etc/inetd.conf would be

     
     ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -i -a 
4.4.1.7 Executables and Dynamic Libraries

When an ftp user gives the dir command or its synonym ls, ftpd invokes the ls Linux command to generate the data that ftpd sends back to the user. The problem is that if the ftpd daemon is running in a chrooted environment (which it normally does for anonymous FTP access), it does not have access to /bin/ls nor to any dynamic libraries that ls would use. The solution is to put ls in ~ftp/bin and provide any dynamically linked libraries that it might need in ~ftp/lib. Most distributions such as Red Hat do this and Red Hat even offers an anonymous FTP RPM containing these programs and dynamic libraries.

All these needed files should be installed on your system already if you asked for the appropriate packages to be loaded. Slackware builds a special statically linked ls program that is installed as ~ftp/bin/ls so that the SysAdmin does not need to bother with dynamic libraries. Red Hat does not do this but it does put tar and gzip in there so that ftpd automatically can convert between compressed and uncompressed files and tar and untar data too. It does include the shell, sh.

I worry that the presence of this apparently unrestricted shell opens a security hole. I much prefer the Slackware solution. Of course, because it is Linux, you can put the Slackware ~ftp/bin/ls program on your otherwise all-Red Hat system, after removing the Red Hat programs and dynamic libraries from ~ftp/bin and ~ftp/lib, and it should work just fine. This is assuming that the version of the Slackware ls program is compatible with the version of the Red Hat kernel. This usually is not a problem and if it is then it will be obvious immediately in that it will refuse to run.

I have been compiling a complex CGI C program on Slackware and running it on many different versions of Red Hat and Mandrake for six years to work around a bug in Red Hat's ctime() library, now fixed.


4.4.1.8 Allowing Controlled Uploading

Allowing public anonymous uploading generally is a bad idea. When allowed, usually crackers and other undesirables will discover this quickly and use your site for their evil purposes. This usually will be tools to crack systems, pornography (no doubt different from any that you might be interested in), and other things that you do not want on your system. If you choose not to allow uploading, simply have the directories mode 755 (or 555) and owned by ftpadmin. Thus, the ftp user, also known as anonymous, will be prevented from uploading any files.

If you choose to have an unrestricted upload facility, the convention is to have the ~ftp/incoming directory for this purpose and for it to be owned by ftpadmin. For full access it should be mode 777 but this is not recommended if the system is accessible from the Internet unless, possibly, the directory is checked frequently for undesired files and they are removed promptly. An alternative would be to have the file mode 733. This means that the owner, ftpadmin, has full access but that others have only write and execute access. This account, ftpadmin, should be different than the account that is used for anonymous FTP login, typically ftp. This allows the anonymous user to upload files but ftp users cannot see what is in that directory, preventing the directory from being used for public exchange.

Certainly, the person uploading can tell others the file name and they then could download it. A solution would be periodically to "sweep" these files into a different directory that is not accessible at all by ftp, via a cron job. The sweep directory might be ~ftp/sweep, owned by ftpadmin and mode 700. The following is a simple ftpadmin cron job to sweep files into this directory hourly. It does not have protection against a file that is uploaded later overwriting an earlier file of the same name but then this will allow someone to update an submission.

 
 0 * * * * /bin/mv /home/ftp/incoming/* /home/ftp/sweep/. >/dev/null 2>&1 

Some sites will have ~ftp/incoming be mode 711 with subdirectories of secret names being mode 733. Someone wanting to upload a file will first have to ask the SysAdmin for the name of one of these secret directories and then upload to it, but I do not see that this is a significant improvement on the method discussed earlier and it requires more overhead.

4.4.2 FTP Proxy Dangers

graphics/threedangerlevel.gif

Older FTP servers allow a client to request that the server do operations to any arbitrary third system. This allowed a variety of security breaches, including sending e-mail that appears to come from an FTP server's system and tunneling through firewalls. If your FTP server was inside your network and the firewall allowed Internet traffic access only to your FTP server, the proxy feature then could be used to access any system inside the firewall. The nmap network mapper can make use of this feature to probe behind firewalls. To see if Pentacorp's FTP server is vulnerable, assuming that Pentacorp has the class A network 10.*.*.*, the following command could be used.

 
 nmap -F -e eth0 -b ftp.pentacorp.com 10.0.0.0/8 

If your FTP server does not allow this, you will see this message:

 
 Your ftp bounce server [censored], it won't let us feed bogus ports! 

Since Red Hat 6.0, the FTP server generates this message and is safe. "The nmap Network Mapper" on page 592 covers nmap usage in detail. Other firewall tunneling dangers are discussed in "Tunneling Through Firewalls" on page 77.


   
Top


Real World Linux Security Prentice Hall Ptr Open Source Technology Series
Real World Linux Security Prentice Hall Ptr Open Source Technology Series
ISBN: N/A
EAN: N/A
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net