Build a Secure FTP Server with Ubuntu 8.10

There are a number of choices available with Ubuntu 8.10 for FTP. VSFTPD is a great choice based on the secure design and the increased SSL support in version 2.0.6. VSFTPD has replaced the WU-FTPD with a more secure ftp daemon. This ftp program is labeled as more secure, stable, faster and more scalable. VSFTPD has taken steps to minimize the privileges it takes to run the ftp program. Each user runs at the level of least privilege.

The new version of VSFTPD with Hardy Heron is 2.0.6 which enhances the SSL support. The SSL support also includes the ability to force clients to offer client certificates. Build a Encrypted FTP Server CLICK HERE

Check Out the VSFTPD Website to see speed and security comparisons. http://vsftpd.beasts.org/

An example of what VSFTPD is trying to eliminate is WU-FTPD. When you log in as an anonymous user with WU-FTPD, a process is run for the ftp session, that process must run as root on the remote machine. This does not occur with VSFTPD.

VSFTPD uses chroot which would minimize damage if a user did compromise the server.

Secure Design:

1. Parsing and acting on potentially malicious remote network data uses an unprivileged user process. In addition a chroot () jail is used to ensure only the ftp files are accessible.

2. Privileged operations are done with a privileged parent process.

3. All requests received by the parent process are distrusted.

4. The privileged parent process uses capabilities and chroot() to always run in the least privileged user possible. The privileged parent constantly calculates the necessary privileges.

Buffer Overflow:

Buffer overflow problems have been the source of many security issues. Systems can be compromised by buffer overflows. vsftpd uses an API to hide the buffer handling from the user and one piece of generic code is used to deal with buffer handling for simplicity.

VSFTP, on the other hand, isn't the complete client/server solution that SFTP is. Only the server daemon is available, so the more proper acronym should be VSFTPD. The "Very Secure" part means that VSFTPD is more resistant to hackers' exploits than what other ftp daemons are. VSFTPD can more easily be configured so that users are confined to only their own, specific directories.

On the client side, there's really nothing special. The user will still log on with his choice of an FTP client program. In default mode, all data, including username and password, get transferred without encryption. So, any hacker who's afforded the opportunity could still place a sniffer on your network, and retrieve your logon information and any other plain text data that you may be transferring.

Now, there is a way to fix this. Some of the newer ftp clients allow the use of SSL/TLS encryption. On the server side, the option to use this can be set in VSFTPD's configuration file. To make this work consistently, though, you would have to go to the expense of purchasing an SSL/TLS certificate from a commercial Certificate Authority, such as Verisign. The certificate that gets installed when you install VSFTPD is a self-signed certificate, and some ftp clients won't accept self-signed certificates.

This isn't to say that VSFTPD doesn't have its place. If you have a file server with files that you want to share with the general public, then VSFTPD, with anonymous logons and the ability to confine users to one certain directory, is the way to go. If your users need to transfer sensitive files, don't want logon information revealed, and have the authorization to leave their home directories on the server's hard drive, then SFTP would be a better choice.

Install and Configuration
Easy install is available with apt-get.

sudo apt-get install vsftpd

Edit the UFW Firewall -- More Information on ufw CLICK HERE

sudo ufw allow from 192.168.5.14 port 21

Rule added

sudo ufw allow from 192.168.5.14 port 20

Rule added

sudo ufw status

Firewall loaded

To Action From

-- ------ ----

Anywhere ALLOW 192.168.5.14 21:tcp

Anywhere ALLOW 192.168.5.14 21:udp

Anywhere ALLOW 192.168.5.14 20:tcp

Anywhere ALLOW 192.168.5.14 20:udp

This configuration currently will not allow FTP access.

May 2 04:58:35 mail kernel: [ 2118.468953] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:0d:56:a8:42:67:00:1b:fc:90:e6:ac:08:00 SRC=192.168.5.14 DST=192.168.5.33 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=13463 DF PROTO=TCP SPT=1473 DPT=21 WINDOW=65535 RES=0x00 SYN URGP=0

You can see from the firewall that even though ports 20 and 21 are allowed from the source IP Address of 192.168.5.14 it is blocked by UFW.

There are two solutions:

1. Create a Rule to Allow All Connections from an IP or Subnet

# ufw allow from 192.168.5.14

Rule added

2. Create a Rule That Allows Everyone to a Specific Port

# ufw allow 21/tcp

# ufw allow 20/tcp
Rule added

# ufw status

Firewall loaded

To Action From

-- ------ ----

21:tcp ALLOW Anywhere

20:tcp ALLOW Anywhere

This second option is really the best if you are using anonymous FTP as it will allow anyone to connect. If you are trying to limit connections to only a specific IP Address or subnet you will need to use the first option and allow connections on all ports.

Default VSFTPD Configuration

Anonymous logins are allowed by default.

anonymous_enable=YES

This is the line in /etc/vsftpd.conf that will allow anonymous logins to your FTP Server.

Here's an explanation of the options that are enabled in the configuration files that you just saw:

listen=YES

This means that VSFTPD will run as a stand-alone daemon. The alternative is to have VSFTPD stopped until someone tries to logon to the ftp server. Then, VSFTPD will be started by xinetd. The recommended setting is to let VSFTPD run in stand-alone, daemon mode.

anonymous_enable=YES

This option allows anyone to logon with only an email address as a password. With this option, it's not necessary to create individual user accounts. Users will be automatically logged into /home/ftp as anonymous users. They will not be able to upload files by default, only download.

#local_enable=YES

Actually, this option isn't enabled, because the # at the start of the line comments it out. Enabling this option would allow users with local accounts on the server to log in under their own usernames. This isn't recommended, since usernames and passwords would be passed in clear text.

dirmessage_enable=YES

You can have the server display a message every time the user changes to a new directory. Just put the message in a .message file, and place the file in its appropriate directory. You can create a .message file by creating a text document and then saving it with the “.” in front of it to make it hidden.

xferlog_enable=YES

This will enable logging of all uploads and downloads.

connect_from_port_20=YES

Some ftp clients will require this. But, if you can disable it, ftp will run with a slightly lower privilege, thus tightening security a bit.

Access Control Using tcp_wrappers

Tcp_wrappers works with /etc/xinetd.d to create a more secure service approach. The safest thing to do when you are not using a service is to remove it from your server. However, there a lot of times when you will use services that you need to protect. When xinetd receives a request for a service on your server, it will forward the request to tcp_wrappers. Tcp_wrappers then looks at /etc/hosts.deny and /etc/hosts.allow and tries to find a match. If it finds a match in hosts.allow access is allowed and if it finds a match in hosts.deny access is denied. In addition, if it does not find a match access is granted!!! If you use tcp_wrappers you also have a great deal of flexibility and control over IP Addresses and domains. There are two files that we will use to control what happens with tcp_wrappers, /etc/hosts.deny and /etc/hosts.allow. These two files are very simple to use. Here is how you should configure /etc/hosts.deny all of the time:

ALL: ALL

The concept is simple, deny everything and then only allow what you want. This is the safest way to use tcp_wrappers. Remember, if tcp_wrappers does not find a match in either hosts.deny or hosts.allow access is granted, that is why you must make sure there is a match in hosts.deny.

When you configure /etc/hosts.allow you have a lot of options. You have several Wildcards that you can use:

ALL always matches

LOCAL matches host name, not domain name

UNKNOWN matches when the host name or IP is unknown due to a problem

KNOWN matches when the host or IP is known

PARANOID matches when the host does not match it’s IP

Patterns can also be used for matches. For example, .myserver.com will match with me.myserver.com and you.myserver.com. The leading period is used to match everything on the right side of the host name. Also 192.168.5. matches all the addresses on 192.168.5.0/255.255.255.0 because the trailing period will match from the left.

The hosts.allow uses daemonlist : client list : option : option

The daemons that xinetd will use can be placed on the line and followed by the clients and options, separated by a colon. Here are a few examples:

ALL: 192.168.4.23: DENY

This example will deny all access to the computer at IP address 192.168.4.23.

SSH: 192.168.5.0/24: ALLOW

This example will permit access to all computers on the network to SSH.

VSFTPD: ALL: ALLOW

This will allow all users who connect to this server access to FTP. This is a setting you might use for an anonymous FTP server.

FTP: ALL EXCEPT myserver.com

This will permit FTP access to everyone except those computers on the myserver.com network.