NKA design | Linux / FTPserver browse

NOTE: THIS ARTICLE IS NOT YET COMPLETE AND VERIFIED.

It is generally recommended that you disable FTP on your server if you don't really need it. The main reason for that is that FTP has a history of security issues and most common implementations are easy to exploit.

FTP is nevertheless a convenient way to share files and allowing others to store files on your server can be very usefull. However, there are some considerations to be taken to make things a bot more secure:

the server chosen should have a good security track and be actively maintained
declared users on the server should be able to have protected access to their files but not be permitted to wander beyond their home tree.
anonymous upload can be permitted, but we don't want people to exploit it and use our server to share files with the rest of the world.

A good candidate for FTP service is vsftpd, the Very Secure FTP deamon. It has a number of security-oriented features and is actively maintained.

Here I detail a possible configuration of vsftpd. As usual, there is no single way to do things on linux, so take what you need and adapt is to your own system.

Installation

On most systems, installing vsftpd is as simple as:

# apt-get update
# apt-get install vsftpd

If you are on a Redhat or Fedora system and not using yum or apt, you should: managing rpms by hand can be tedious if there are many dependencies. yum and apt identify those and do the right thing for you, adding and removing packages as necessary.

You can of course choose to install everything by hand and compile from source. Check out the links below for more detail information about manual installation.

vsftpd is managed through the inetd or, more securely, through the xinetd super-server: this means that vsftpd will only be running when you need it rather than eat resources while iddle. It also means you can use xinetd and tcp_wrappers (/etc/host.allow and deny files) security features to limit access based on domain names, IP addresses or time slots.

Configuration

The main configuration file is vstpd.conf located usually under /etc/ or /etc/vsftp/ and the man page (man 5 vsftpd.conf) for it contains a detailed description of every parameter. There are numerous options that can be set, but here we concentrate on the functionalities we need:

Open vsftpd.conf with your favourite editor and uncomment or add the following lines:

# --------------- Main Options
# Allow local users to log in
local_enable=YES
# Allow anonymous FTP
anonymous_enable=YES
# Allow anonymous upload and make them owned by the unpriviledged ftp user
anon_upload_enable=YES
chown_uploads=YES
chown_username=ftp
# --------------- Security Options
# Ensure that local users cannot wander into the filesystem
chroot_local_user=YES
# Limit the number of clients to avoid resource attacks
max_clients=20
# Don't shown the real user and group ID, just show as ftp
hide_ids=YES
# Make sure uploaded files are not executable
file_open_mode=0666
local_umask=0117
# ---------------  Misc Options
# Banner displayed when client connects
ftpd_banner=Welcome to my very own FTP service.
# Enable logging of uploads/downloads
xferlog_enable=YES
# PORT Transfer connections
connect_from_port_20=YES
# Allow recursing by clients
ls_recurse_enable=YES

Now that the ftp service is configured, just enable it to run through reboots:

# chkconfig vsftpd on

chkconfig sends a SIGHUP signal to the xinetd process to force it to re-evaluate its services, so there is no need to do anything else for it to work straight away. Check the output of the message log to ensure everything went fine:

# tail /var/log/messages
Nov 28 20:34:52 testserver xinetd[12931]: Starting reconfiguration
Nov 28 20:34:52 testserver xinetd[12931]: readjusting service imap
Nov 28 20:34:52 testserver xinetd[12931]: readjusting service pop3
Nov 28 20:34:52 testserver xinetd: xinetd -HUP succeeded
Nov 28 20:34:53 testserver xinetd[12931]: Reconfigured: new=1 old=2 dropped=0 (services)

Access Control

Local Users

There are many mechanisms to control access to the server. vsftpd uses lists to determine which users can and cannot connect, and which will be chroot-jailed. Whether you need to use these files really depends upon the degree of control you need over the ftp service and how you manage your users. That is the subject of an article on (or even a book) of its own.

Here, we'll use the credentials of local users defined on the machine to decide if they have access to their respective home directory when they login with their normal login/password.

Usually, I disable users from being able to access a terminal on my server in 2 ways:

their account uses /bin/nologin or /bin/false instead of a shell.
For terminal access, I only use ssh (as should everyone) and only a very limited set of users are allowed to get into the system (explicitely set in the /etc/ssh/sshd_config file as parameters to the AllowUsers directive).

For a local user to be able to log into a ftp server, he needs to have a login account on the machine, so these users need to have a proper login entry in the /etc/passwd file:

mike:x:1001:1001:Mike SMITH:/home/mike:/bin/nologin
john:x:1002:1002:John DOE:/home/john:/bin/sh

Here, only John will be able to access his files through FTP. As explained above, since he is not explicitely in the sshd_config file, he won't be able to access the system through a terminal and thus we're safe.

Anonymous access

By default, the /var/ftp directory is exported through vsftpd for anonymous users. It only contains a pub directory and while root can add files to that directory to share with the world, the current permissions won't allow anonymous users to upload anything.

One concern with anonymous access is that anyone could use your server as a storage for their files. They would eat your bandwidth and, worse, would expose you to legal prosecution if the content shared is illegal. This is a big risk, but we still want people to be able to upload safely. A simple and safe way to enable that is to create an incoming folder where anyone could upload files, but which cannot be read back and its content cannot be listed. Effectively, it would be a one-way drop-box, making abuse practically impossible, although you still may want to check what's in the box once in a while.

To achieve this, the simple magic of *nix user and group access is enough. Perfom the following as root

# cd /var/ftp
# mkdir incoming
# chown root.ftp incoming
# chmod 730 incoming

And that's it.

Firewall settings

Unless you only want people on your local network to use your ftp server, you must open your firewall just enough for access from the Internet. FTP traffic is quite cumbersome to filter: if your rules are too strong, ftp won't work very well, and if they are too lax, you are at greater risk of attack.

The difficulty of protecting ftp traffic is that is comes in 2 flavours: passive and active mode. While ftp uses port 21 to initiate a connection, the server will open other ports to allow data to be sent back to the client. In particular port 20 and ports above 1024.

.....

If your firewall is separate from your server, then you need to open port 21 and forward it to your ftp server. More likely, your server will be directly connected to the Internet and will be protected through iptables. The following rules will allow ftp access:

<:vspace>