FTP servers are a common way of sharing files between individuals with or without authentication.  FTP is superior to HTTP (web) if the goal is to transfer files, not display information.  Since HTTP can also be used to transfer files, FTP has become slightly more old-fashioned.

Security for an FTP server is relatively straightforward and the same principles apply for all platforms:

  • Do not enable anonymous access unless you need unauthenticated access to your files.  An FTP server with anonymous access enabled will allow users in any part of the globe to browse and download the files on your server.
  • Your FTP server should serve files from a specific directory on system where you will place files you wish to be available.  You should not allow the root directory (/) or entire disks to be shared (unless the entire disk is a single partition containing only shared information.
  • If you need to allow anonymous access, allow only anonymous downloads.  You must make sure that the unauthenticated users cannot put files into any directories on the FTP server, otherwise your server will be abused.
  • If you must allow anonymous uploads, follow the special directions for creating an anonymous upload area.  An anonymous upload area will not permit anonymous downloads from the same directory, which prevents the site from being abused.  This is the least desirable configuration and should be avoided.
  • For Unix and Linux systems, you should monitor your ftp area for signs of abuse.  We have provided a script to help do that below, and you can also use Baseline to watch over your ftp area.

We have provided directions for configuring both generic UNIX or Linux FTP servers and Microsoft’s Internet Information Server (IIS) below.

Generic Unix Instructions

Section I: Disabling anonymous ftp access altogether.

Anonymous ftp activity in Unix and Linux is enabled by adding the user “ftp” to the password file (locally or in the NIS password file). Disabling anonymous ftp access altogether is as simple as removing this entry. Note that departments with anonymous ftp access set up on a specific system should take care to ensure that the ftp account is not in the NIS password file, as that will enable it on all the systems in the NIS domain.

Section II: Limiting the anonymous user to downloading only.

The key to disallowing uploads by the anonymous user is disabling write access for that user. Generally, write access is granted in one of two ways:

  • Directories are created with world write permissions
  • Directories are owned by the anonymous user (ftp).

If either condition is true, the ftp area can be abused. To correct this problem, you can do the following as root:

# cd ~ftp
# find . \( -user ftp -a -type d \) -exec /bin/chown 0 {} \;
# find . \( -perm -002 -a ! \( \( -type l \) -o \( -type c \) \) -exec  /bin/chmod o-w {} \; \)

Section III: Allowing anonymous uploads

In cases where the anonymous user must be able to upload files, we strongly suggest you select one directory, such as /pub/incoming, for uploads. You should set this directory up with mode 733, owned by root (not ftp). As root:

# cd ~ftp
# mkdir -p ./pub/incoming
# chown 0 ./pub
# chown 0 ./pub/incoming
# chmod 755 ./pub
# chmod 733 ./pub/incoming

Mode 733 is read-writable by the owner, root, and writeable but not readable by group members and others.  This allows the anonymous user to write into the incoming directory but not to change it.

Note that and files or directories inside /pub/incoming should not be readable by the anonymous ftp user. To ensure that there are no readable files in this directory, run:

# /bin/chmod -R u-r ./pub/incoming

In some cases, you may want to configure your setup slightly differently to suit your needs. The key component here is that while the anonymous user can write to the directory, they cannot read from it. This makes it useless as a trading site and will keep it from being abused.You should also note that if you need to share data that is being uploaded you will have to move it from the /pub/incoming directory to a readable area for your users. One common way to get around this administrative workload is to define a group such as “ftpadmin” in /etc/group that contains users who you want to be able to retrieve data from this directory. You can then set the directory to mode 773 with group “ftpadmin”. Your users will now be able to retrieve data from this directory. You will still have to periodically clean it out. It is imperative, however, that the user “ftp” not be put into the “ftpadmin” group and that the permissions are constantly monitored on this directory to make sure world-read is not enabled.

Section IV: Monitoring

There is a script available via AFS or anonymous ftp that will provide monitoring of the ftp server and reporting to root. You should consider using a script such as this from your system’s crontab to ensure that the configuration you’ve establish remains unchanged. The script will require some modification to fit the configuration of the local system.

Download a copy of the ftpchk shell script.

In addition, you should consider adding the following line to your system crontab, adjusting the path to the incoming directory as appropriate for your setup:

# Keep anonymous ftp "dropbox" clean of improper (and illegal) items
15,30,45,01 * * * * chmod  -R u-r  /home/ftp/pub/incoming 2>&1

Section V: Other thoughts

It is generally possible to impose quotas on filesystems. You might want to limit the amount of data the ftp user can put on the partition containing the ftp servers home directory. If this number is small you can decrease the effectiveness of the system as a trading site. This does nothing to prevent trading from occurring, however. Similarly, you can put your ftp server directory on a small hard disk, effectively imposing a quota.

wu-ftpd supports a lot of configuration options that can be used to tighten the security of the ftp server. For example, you can configure it to disallow use of the MKD (mkdir) command and disallow uploading except to certain paths. In addition, you can configure it using IP address blocks to allow some sites to upload data and not others. This kind of tuning can substantially improve security, but requires that the systems administrator install and configure wu-ftpd.

Microsoft IIS FTP Server Configuration

If you must run FTP, we recommend that one of the following three things be done:

  • Disable anonymous access to your ftp server altogether from Control Panel/Administrative Tools/Computer Management/Internet Information Service/ Default FTP Site/Action/Properties/Security Accounts/Disable Anonymous Connections (uncheck “Allow Anonymous Connetcions).
  • Disable anonymous uploading of data by removing the ability of anonymous users to write data.
  • Configure the upload areas in a “dropbox” style configuration where the anonymous user can write data to the server, but cannot retrieve that data afterwards.

If you chose to disable anonymous access (choice a), than no further action is required.

If you chose choice b or c, these steps involve using NTFS permissions on the root of the ftp site and/or the read write check boxes from the Home Directory Tab. You find the root of the ftp site through control panel/administrative tools/Computer Manager/Internet Information Service/ Default FTP Site/Action/Properties/Home Directory tab (i.e. c:\inetpub\ftproot)

If your system is not formatted to use NTFS, then you should use the Read Write check boxes from the “Home Directory” tab to accomplish steps b or c.

step b = only read and log visits are checked
step c = only write and log visits are checked

Either one is a crude solution as the first doesn’t allow anyone at all, including the publisher to write data to the ftp site, and the second will only allow writes at the ftproot folder (not a subfolder/sub-directory as recommended in the UNIX / Linux section above.

To get better control, you will need to convert your drive to NTFS. If your drive(s) is configured for NTFS (means when you right click on a folder, and select properties, you see a security tab) then we suggest using NTFS folder permissions to accomplish either option as you have more control over who has write, access, etc.

To accomplish steps b and c from an NTFS drive.

  • Right click the start button/ left click Explore, navigate to the ftproot folder, right click the ftp root folder, left click the “Security Tab”
    • for option b: Highlight the everyone group and check the deny “write” check box then click the add box at the top right of the Security Tab to add additional users who specifically need to write to the ftp site.
    • for option c: in addition to the steps laid out in option b, create a subfolder under the ftproot folder called something like “incoming”, then change the security tab’s check boxes to deny Read & Execute, list folders contents, and Read – allowing write Modify and Full Control (misleading doesn’t give them full control – you can see this in the advanced tab) on the incoming folder. Be sure to UNCHECK the allow inheritable permissions from parent to propagate to this object to keep the permissions from the ftproot folder from overriding the ones you just set on the incoming folder.