FTPserver

• http://pintday.org/whitepapers/ftp-review.shtml

NOTE: THIS ARTICLE IS NOT YET COMPLETE AND VERIFIED.

(:comments:)

NOTE: THIS ARTICLE IS NOT YET COMPLETE AND VERIFIED.

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.

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.

.....

• http://vsftpd.beasts.org/ vsftpd official page.

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 have to be weary about people dropping stuff in to

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

1. cd /var/ftp
2. mkdir incoming
3. chown root.ftp incoming
4. 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.

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: =bash [=

=]

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.

1. Don't shown the real user and group ID, just show as ftp

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. 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 from uploading anything.

One concern with anonymous access is that anyone could use your server as a storage for their more-or-less legal files. Tehy 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 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.

To achieve this, the simple magic of *nix user and group access is enough:

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

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.

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 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

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.

• http://www.apress.com/betabooks/bb_content/9/4444_ch10_BETA.html Installing, configuring and Securing an FTP server, chapter from the Hardening Linux book from Apress (PDF version of this chapter is http://www.apress.com/betabooks/bb_content/9/4444_ch10_BETA.pdf available from the publisher and a cached version from here).

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.

On most systems, installing vsftpd is as simple as:

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.

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_wrapper (/etc/host.allow and deny files) security features to limit access based on domain names, IP addresses or time slots.

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.

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

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.

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_wrapper (/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 for it contains a detailed description of every parameter.

Now that the ftp service is configured, just enable it to run through reboots and force xinetd to re-read its configuration to avoid rebooting now:

# 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. 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)

Links

• http://linux.duke.edu/projects/yum/ YUM package manager official page and more http://www.hut.fi/~tkarvine/yum-package-manager.html configuration of YUM
• http://www.apress.com/betabooks/bb_content/9/4444_ch10_BETA.html Installing, configuring and Securing an FTP server, chapter from the HArdening Linux book from Apress (PDF version of this chapter is http://www.apress.com/betabooks/bb_content/9/4444_ch10_BETA.pdf available from the publisher and a cached version from here).

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.

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 http:// yum or apt, you should.

Below is what I did to make Nagios work for me. There are more comprehensive notes on the main site. I suggest you follow the following pages in sequence:

• http://nagios.sourceforge.net/docs/1_0/installing.html Installing Nagios
• http://nagios.sourceforge.net/docs/1_0/installweb.html Setting Up The Web Interface
• http://nagios.sourceforge.net/docs/1_0/cgiauth.html Authentication And Authorization In The CGIs

Nagios has a reputation of being fairly convoluted to install and configure. It is true that power and flexibility are often poor friends of ease of installation. Having said that, installing Nagios is fairly straightforward, especially On RedHat and Fedora where it's even pretty easy to install core functionality using pre-packaged RPMs. Configuration is another matter: Nagios is flexible and can adapt to almost any scenario, that's the only way to ensure you get what you want out of it, rather than being force-fed someone else's view of what you should get.

I use the [Linux/PackageManagement Dag apt]] software repository. It contains a lot of extra packages that are not available elsewhere, including all the Nagios goodies.

Note: Make sure that Apache can run on your server. You will need it to access the web interface.

To see what packages are available: