Section 40.2. Objective 3: Securing FTP Servers

40.2. Objective 3: Securing FTP Servers

There is a wider variety of FTP server implementations than most like to think about. This LPI Objective is tailored for WU-FTPD, which just a few years ago was the standard ftpd. However, it is no longer included in any Red Hat or Debian distribution due to it's rather poor security record. In upcoming versions of the Level 2 LPI Exams, the only FTP daemon likely to be covered is vsftpd (Very Secure FTP Daemon), which is both popular and the only one included in both Debian and Red Hat.

vsftpd comes with a very good default configuration, which allows only anonymous FTP. It chroots to the ftp user account (which must already exist on the system) and everything just works. Unlike other software that uses chroot, vsftpd does not need a chroot environment to be painstakingly set up.

vsftpd reads its configuration from /etc/vsftpd.conf. Here are some highlights:

 # Allow anonymous FTP? anonymous_enable=YES # Uncomment this to allow local users to log in. #local_enable=YES 

These lines indicate what users to allow. The choice here is anonymous only by default. The last line can be commented out to allow regular users. For a regular user to be allowed access, his shell must be listed in /etc/shells. However, the ftp user account can have a "nologin" shell and anonymous FTP; that user will still be allowed in.

 # Uncomment this to enable any form of FTP write command. #write_enable=YES # Uncomment this to allow the anonymous FTP user to upload files. This # has an effect ony if the preceding global write enable is activated. Also, # you will obviously need to create a directory writable by the FTP user. #anon_upload_enable=YES # Uncomment this if you want the anonymous FTP user to be able to create # new directories. #anon_mkdir_write_enable=YES 

Setting write_enable to yes gives local users permission to upload files and create directories. The anonymous user needs the two other settings as well to be able to upload files. And as the comment says, you must create a directory writable by the ftp user, with the right filesystem permissions.

 # If you want, you can arrange for uploaded anonymous files to be owned by # a different user. Note! Using "root" for uploaded files is not # recommended! #chown_uploads=YES #chown_username=whoever 

By enabling these commented-out lines, you stop the anonymous user from deleting and overwriting previously delivered files. This is often a very good idea. Be sure to use a user that has no other roles than being the anonymous FTP upload user. Using the nobody account is not quite as good, because any service or process running as nobody will then be able to change or delete those files.

 # Chroot local users as well? # chroot_local_user=YES # # You may specify an explicit list of local users to chroot( ) to their home # directory. If chroot_local_user is YES, then this list becomes a list of # users to NOT chroot( ). # chroot_list_enable=YES # (default follows) #chroot_list_file=/etc/vsftpd.chroot_list 

As long as the regular users do not need to access one another's accounts or system directories, you may as well chroot them too. As you see, you can get finer control over this by using the chroot list file.

 # If you enable this nonanonymous logins are mapped to the guest # account given by guest_username.  The default guest user name is "ftp". # guest_enable=YES # guest_username=whoever 

If this is enabled, a user willafter giving a username and correct passwordhave access to only the given account, not to her own account.

 # If you set userlist_deny, then users will be allowed access only if they # they are listed in the userlist_file. # userlist_deny=YES # # If you enable userlist_enable, then any user listed in the userlist_file # will be denied access before even being asked his password.  Denying # at this early stage stops the user from transmitting his password # in clear text for no purpose. # userlist_enable=YES # # This is the default userlist_file: # userlist_file=/etc/vsftpd.user_list 

And finally, this is where you enable or deny access for specific users.