Proftp Server Configuration in Debian

What is ProFTPD?

ProFTPD is a ftp server written for use on Unix and Unix-a-like operating systems, there is no support for native use under Microsoft Windows.

Proftp Server Features

ProFTPD offers the following features:

  • Single main configuration file, with directives and directive groups which are intuitive to any administrator who has ever used the Apache web server.
  • Per directory ".ftpaccess" configuration similar to Apache's ".htaccess".
  • Easy to configure multiple virtual FTP servers and anonymous FTP services.
  • Designed to run either as a stand-alone server or from inetd/xinetd, depending on system load.
  • Anonymous FTP root directories do not require any specific directory structure, system binaries or other system files.
  • No SITE EXEC command. In modern Internet environments, such commands are a security nightmare. ProFTPD does not execute any external programs at any time. The source is available (and must always be available) for administrators to audit.
  • Hidden directories and files, based on Unix-style permissions or user/group ownership.
  • Runs as a configurable non-privileged user in stand-alone mode in order to decrease chances of attacks which might exploit its "root" abilities. Note: This feature is dependent on the capabilities of the host Unix system.
  • Logging and utmp/wtmp support. Logging is compatible with the wu-ftpd standard, with extended logging available.
  • Shadow password suite support, including support for expired accounts.
  • Modular design, allowing server to be extended easily with modules. Modules have been written for SQL databases, LDAP servers, SSL/TLS encryption, RADIUS support, etc.
  • IPv6 support.

Proftp Supported Platforms

ProFTPD is known to compile and run on the following platforms.




Digital Unix





Mac OS X







Linux for IBM S/390, zSeries



 Proftpd Installation in Debian

apt-get install proftpd

it will ask you if you want to install it with inetd or standalone. inetd is for occasional use (it will be loaded on demand).You need to select standalone and click ok button.

.For security reasons you can add the following lines to /etc/proftpd.conf:

DefaultRoot ~

IdentLookups off
ServerIdent on "FTP Server ready."
For more Security configuration click here

and restart Proftpd:

/etc/init.d/proftpd restart

For More Examples for more configuration click here

Permitting Anonymous Access

To permit anonymous access to your server you will need to uncomment the configuration options which are already present in the standard /etc/proftpd.conf file.

<Anonymous ~ftp>

   User                       ftp

   Group                nogroup

   # We want clients to be able to login with "anonymous" as well as "ftp"

   UserAlias                  anonymous ftp

   # Cosmetic changes, all files belongs to ftp user

   DirFakeUser    on ftp

   DirFakeGroup on ftp

    RequireValidShell         off

    # Limit the maximum number of anonymous logins

   MaxClients                 10

    # We want 'welcome.msg' displayed at login, and '.message' displayed

   # in each newly chdired directory.

   DisplayLogin               welcome.msg

   DisplayFirstChdir          .message

    # Limit WRITE everywhere in the anonymous chroot

   <Directory *>

     <Limit WRITE>





 This configuration setting allows users to login with either anonymous, or ftp, as username and they will be able to read from /home/ftp.

 They will be unable to upload new content, or delete existing files. They will be given only read-only access to the server. 

For More Proftp Server Configuration Directive List click here

Proftpd Sever log files located at /var/log/xferlog

If you want Proftp server web interface or GUI tools click here

Configuring Proftp Server Security

Securing ftp servers

Proftpd provides for some additional security by it's use of chroot(), user and IP access limits, command and path filters to limit what and where files can be uploaded and it's attention to when root privs are needed and when they are not. However a buffer overflow in the wrong place and it's possible that the server is compromised beyond hope.

Simple steps which can be taken to tighten security include

  • Log to a separate machine
  • Traffic filtering upstream of the server
  • chroot() all sessions
  • Don't give a valid shell where it's not needed
  • Run an intrusion detection system
  • If possible place the OS itself on a bootable CDrom
  • Tripwire
  • Decent backups

Daemon security

Recently (between versions 1.2.0pre3 - 1.2.0pre7) there have been a number of buffer overflow type security problems with ProFTPD, with the coming release of pre7 these should be under control. Though no absolute statement can be given on the security of the software (this is true for every piece of software out there). A significant amount of effort has been put into removing the more 'dangerous' system calls which are prone to overflow attacks.

There is a known security problem with ALL unix FTP daemons, which requires the daemon to retain root privileges even after a client has fully authenticated. In ProFTPD versions 1.0.x, a decision was made to ignore RFC959's port 20 requirements in the interests of security. This approach has now been abandoned in favour of a more rfc compliant approach.

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.

Password Issues

One of the biggest security problems about the whole FTP protocol is the need to have the password transmitted in clear text across the network. In effect the username and passowrd pair are available at all times during the authentication sequence, resulting in this information being available to crackers and sniffers alike.

Encrypted passwords

Currently (as of 1.2.0pre9) Proftpd does not support encrypted passwords for authentication. Development for this feature is scheduled for post 1.2.0rel1, and it will remove the absolute need to send the password in clear text over the network. There are some additional approaches involving ssh (secure shell) which I will not cover in detail in this text which can be used to secure a ftp session without encrypted keys.

FTP as root

This is a bad idea simply because it's a major security risk to send the root passowrd in clear text over any network. If there is a need to get files onto a server there are always better ways of achieving it than connecting via ftp as root.

 Other approaches
  • rcp
  • ssh/scp
  • ftp as a safe user and change the ownership later.

If you really must ftp as root then our thoughts go with you on this dangerous journey as you add "RootLogin on" to your proftpd configuration and may your god go with you.

Server attacks

As with all server processes the primary method of cracking remains the buffer overflow. Due to the nature of the protocol and the requirement for root level privileges this leaves ftp daemons open to attack. Buffer overflows are the result of weak programming where boundary condition checks have been skipped or "unsafe" system calls have been used. These allow a fixed length storage area to be overflowed, this overflow can then be used as the transport to allow the execution of arbitary commands as the root user. In combination this is known as a "root exploit".

Stack smashing protection

What about using Stackguard?

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


Libsafe implements a 'middleware' layer which sits between the OS and the daemon process and protects against buffer overflows. This is achieved by intercepting all calls known to be vulnerable to overflow.

Running Proftpd as non-root

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. The inability to bind to ports 20 and 21 makes this approach useless for commercial hosting environments where the customers are expecting the connection to be on a "standard" port.

Firewall issues

Generally ftp and firewalls are quite capable of co-existing on the same or separate networks with the minimum of fuss. The source of problems stem from the fundamental design of ftp and it's twin socket approach to data transfer. Firewalls, good ones at least, approach security by assuming everything is hostile and then starting to open up holes to trusted ports and destinations.

FTP, as has been mentioned in an earlier chapter has two main methods of operation, passive and active. Passive mode support is difficult in the extreme to support within a firewall, it requires the tracking of port 21 connections in and outbound and opening up complete tcp holes for that connection on the fly and tearing down once the control socket is closed. Active support is brainlessly simple by comparison, opening ports 20 and 21 is sufficient, nothing more complex is required.

ProFTPD behind a firewall

Due to the multiple socket and semi-random port assignment nature of the ftp protocol Because of the bi-socket nature of the ftp protocol additional care must be taken when setting up ProFTPD behind a firewall. Setting the firewall to allow the control socket through is easy enough, allow tcp packets destined for port 21 on the target server. However the data socket in passive mode may be targetted on a random port number on the server side resulting in either a highly complex or very weak firewall. The PassivePorts directive allows the admin to specify the range of ports the server will use to service ftp-data connections, this range can then be configured on the firewall.

Security by obscurity and warnings

Good security practice works on a combination of locking down all the holes as tightly as possible and letting as little information about the network out as possible. Additionally some legal systems require that explicit warnings are put up letting the casual connecting host know that unauthorised access is not permitted. To provide these features Proftpd supplies a number of directives which control the message presented to the user.

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

ServerIdent  off

ServerIdent  on ""

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

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

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.