Chapter 6. Security

1. General
2. Surely running ProFTPD as non-root will help?
3. How can I control what commands the server accepts?
4. How can I prevent the server version from being displayed?
5. I want to show a message prior to login
6. I want to display a message after login
7. Can I have a custom welcome response?
8. External Programs
9. Why do I see "No certificates found!"?
10. I can delete files owned by root. Why is this?

1. General

As with all software there have been a number of security issues during the life of the project. The most recent information can always be found on http://www.proftpd.org/security.html

Versions 1.2.0 and above should be considered to be production code and few if any new features will be added to this code branch to maintain stability.

What about using Stackguard?

Stackguard (http://immunix.org) is a gcc variant which can protect programs from stack-smashing attacks, programs compiled using Stackguard dies without executing the stack code. While this approach is a good first line of defense against future problems it"s not a complete cure-all. Some of the buffer overflows were found on static variables, which are not protected by stack protection mechanisms.

2. Surely running ProFTPD as non-root will help?

Running ProFTPD as a non-root user gives only a marginal security improvement on the normal case and adds some functional problems. Such as not being able to bind to ports 20 or 21, unless it's spawned from inetd.

ProFTPD takes a middle road in terms of security. It only uses root privileges where required and drops to the UID defined in the config file at all other times. Times when root is required include, binding to ports < 1024, setting resource limits, reading configuration information and some network code.

For Linux 2.2.x kernel systems there is the POSIX style mod_linuxprivs module which allows very fine grain control over privileges. This is highly recommended for security-conscious admins.

3. How can I control what commands the server accepts?

Use a sane Allow/DenyFilter, these directives use regular expressions to control all text sent over the control socket. (If anyone has some good examples please let me know.)

4. How can I prevent the server version from being displayed?

Setting SeverIdent to "off" should turn off the information about what type of server is running. To have maximum effect this directive should either be in the Global context or included in every virtual host block and the default block.

ServerIdent  On "Linux.co.uk server"

ServerIdent  Off
          

5. I want to show a message prior to login

Use the DisplayConnect directive to specify a file containing a message to be displayed prior to login.

DisplayConnect /ftp/ftp.virtualhost/login.msg
          

6. I want to display a message after login

Use the DisplayLogin directive, this sends a specified ASCII file to the connected user.

DisplayLogin       /etc/proftp.msg
          

7. Can I have a custom welcome response?

Use the AccessGrantMsg directive, this sends a simple single line message back to the user after a successful authentication. Magic cookies appear to be honoured in this directive.

AccessGrantMsg "Guest access granted for %u."
          

Note, this directive has an overriding default and needs to be specified in both VirtualHost and Anonymous blocks.

8. External Programs

ProFTPD has been designed to run as a secure ftp server, this means that it tries to keep as much as possible under it's control. An external program is a security risk in itself because it's behaviour is not controllable from within the ftpd code.

9. Why do I see "No certificates found!"?

This message is generated by mod_tls, the third-party module that can be used to encrypt both the control and data connections with TLS (Transport Layer Security), the next generation of SSL. Certificates are used to establish the security context for this secure transport.

Generation of certifications is beyond the scope of this document; however, more information can be found here:

http://en.tldp.org/HOWTO/SSL-Certificates-HOWTO/

10. I can delete files owned by root. Why is this?

ProPTPD follows the UNIX file permission rules when determining the level of access and/or control a user is granted when working with a file. UNIX systems divide the world into three classes when determining the permissions that a user is granted for a particular file:

  • User - the owner of the file

  • Group - a collection of users defined in /etc/group

  • Others - neither the owner, nor a member of the group

Every file in a Unix filesystem has a permission definition associated with it. At a minimum, the permission established for a file will determine whether a particular user may READ, WRITE, or EXECUTE the file in question. A directory listing will show the permissions associated with a file in the format shown below:


  rwx  r-x  r-x
   |    |    |
   |    |    |_____________ Others:  READ/NO WRITE/EXECUTE
   |    |__________________ Group:   READ/NO WRITE/EXECUTE
   |_______________________ User:    READ/WRITE/EXECUTE

In the sample directory listing shown below, READ/WRITE/EXECUTE privileges are granted to the owner of the directory, and READ/EXECUTE privileges are granted to members of the users group and everyone else. Note the letter "d" at the beginning of each entry, denoting that the entry is actually a directory.

  prince> ls -l /home/ftp

  total 8
  drwxr-xr-x    2 andrea   users        4096 May  3 00:40 andrea
  drwxr-xr-x    2 eve      users        4096 May  3 00:40 eve

  prince> ls -l /home/ftp/andrea 

  total 156
  -rw-r--r--    1 andrea   users       85991 May  3 01:12 bland.txt
  -rwxr-xr-x    1 root     root        65107 May  3 01:12 secret.txt

The answer to this question is shown in the above example. When describing the permissions associated with a directory, WRITE means that permission is granted to modify the contents of a directory by adding or deleting files. Thus, the user andrea may delete the file secret.txt, even though she cannot modify the file itself.

Refer to the documentation for the IgnoreHidden and HideNoAccess directives for a method to mitigate this hazard.