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.
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.
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.)
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
Use the DisplayConnect directive to specify a file containing a message to be displayed prior to login.
DisplayConnect /ftp/ftp.virtualhost/login.msg
Use the DisplayLogin directive, this sends a specified ASCII file to the connected user.
DisplayLogin /etc/proftp.msg
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.
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.
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:
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.