Security
From Wzdftpd
Contents |
General security considerations
FTP in general has a long and sad history of security problems. If you need to run an ftp server, you need to keep careful track of vulnerabilites and exploits that may make for a very unhappy day. Things have gotten better in recent years, however common servers like wu-ftpd and proftpd still have problems (at the time this article is written, 6 vulnerabilities for both servers, and 3 unpatched !).
The main problem with ftp is that it almost always runs with root privilege, at least part of the time. It needs to bind to low ports (20 and 21) at a minimum, which requires root, and there are probably other points where it needs more than ordinary user abilities. Modern implementations try to avoid being root when they don't need to, but of course that's not perfect. Other damage limiting attempts involve running in a chroot jail.
A list of FTP servers and features can be found here, for example.
Security basics
The most important problem is to run the server with root privileges, since any intrusion will give full access to the system. You should never run the server as root !
However, this is mandatory if you want to run the server on the standard port (21). wzdftpd will drop all privileges and become a standard user if you use the server_uid and server_gid options.
Do not be fooled, running the server as a standard user is not sufficient: if your server is compromised, one of the "annoying" consequences can be the removal of all your files !
You must follow this guidelines to secure your FTP server:
- do not shoot in your own feet: some FTP servers are inherently insecure, have had many problems and are likely to have more in the future. Avoid them for your own safety. (*)
- prevent problems: using one group and one set of permissions for all users may be attractive for the admin, but will be a security nightmare (you won't be able to properly separate privileges)
- consider the whole system: having a 16384-bits encrypted connection is not a good protection if the password is initially sent clear-text. You must understand how things work to avoid forgetting details, and secure all steps. Another common example is to install a so-called secure server on an insecure OS ...
- check your logs: any breaking attempt will leave something in the logs. Check them often (and a good practise is to store logs in another computer so an intruder won't be able to delete them)
- be paranoid: even the best software can be insecure if badly configured. Check your configuration, test it, log users, and re-check all that after.
(*) the author does not claim that wzdftpd is better than other servers, just pointing a fact
Secure code
A section is dedicated to secure code in the developer's corner.
Good practise
Work In Progress: least permission principle, etc.
