|
|
|
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:
Proftp Supported Platforms ProFTPD is known to compile and run on the following platforms.
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> DenyAll </Limit> </Directory> </Anonymous> 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 hereProftpd 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 serversProftpd 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
Daemon securityRecently (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 IssuesOne 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 passwordsCurrently (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 rootThis 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
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 attacksAs 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 protectionWhat 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. LibsafeLibsafe 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. http://www.bell-labs.com/org/11356/html/security.html Running Proftpd as non-rootRunning 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 issuesGenerally 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 firewallDue 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 warningsGood 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 displayedSetting 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 "test.co.uk server" ServerIdent off ServerIdent on "" I want to show a message prior to loginUse 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 loginUse 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. |