Boris Lorenz writes:

I would replace this with proftpd (www.proftpd.org), which is more flexible and more secure than the standard in.ftpd. Proftpd can be run standalone as a demon listening to port 21 or, like usual, via inetd.

ProFTPd has a *LONG* list of bugs, security incidents and compatibility issues. I would not trust that software. -- Matthias Andree

...

ProFTPd has a *LONG* list of bugs, security incidents and compatibility

Thats new to me: when I search www.cert.org for proftp, there is not one hit.

Searching cert archives might not be a good idea, then. For instance, take a look at the code, maybe compare it with code from vsftpd (Chris Evans) or postfix. Decide then.

...

issues. I would not trust that software.

We had proftpd running on ftp.suse.com for a few weeks. I have added a few patches that made it possible to run the server with 500 instances, but 600 knocked the box out - too much system call overhead, /proc accesses in the file transfer loop, name it, you get it.

Which ftp server would you recommend instead?

We are running wuftpd-2.4 on ftp.suse.com now, the daemon that is installed as /usr/sbin/wu.ftpd. It is the old version, not 2.6. Thomas Biege made a comprehensive audit some time ago, and since then there has been no bug in it. 5:12am up 60 days, 13:38, 2 users, load average: 3.30, 2.86, 2.42 The load is a result from 18 concurrent rsync processes. We have only 370 sessions right now, the output is near 48 MBit/s. As an additional solution there might be the BSD-derived ftpd (in.ftpd). It works quite nicely, it's slim and fast, and it does its job. Roman.

On 18-Jun-01 Matthias Andree wrote:

Boris Lorenz writes:

...

I would replace this with proftpd (www.proftpd.org), which is more flexible and more secure than the standard in.ftpd. Proftpd can be run standalone as a demon listening to port 21 or, like usual, via inetd.

ProFTPd has a *LONG* list of bugs, security incidents and compatibility issues. I would not trust that software.

Well... At least proftpd *has* a security history with an active maintainer team. They have their own security reporting facility, a section for critical and not-so-scary bugs, and if you review the security incidents for other ftp demons, proftpd still stands strong. For me it's the most useable ftp server for linux to date. Which ftp server do *you* trust in?

-- Matthias Andree

--- Boris Lorenz System Security Admin *nix - *nux ---

Something to consider: for complicated setups proftpd is a LOT easier to configure then wuftpd for example. Thus you are less likely to accidently make a directory world readable.writeable or whatever. Kurt Seifried, seifried@securityportal.com PGP Key ID: 0xAD56E574 Fingerprint: A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.securityportal.com/ ----- Original Message ----- From: "semat" To: "Matthias Andree" Cc: Sent: Monday, June 18, 2001 9:27 AM Subject: Re: [suse-security] Is this config vulnerable?

...

ProFTPd has a *LONG* list of bugs, security incidents and compatibility issues. I would not trust that software. True. but I know that no bug has been found in wu-ftpd since a security audit was done on it perhaps you should try that. Also vsftpd which I use is really the best I've seen in a long time. The download url is somewhere in the archives of this list. Noah.

-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

On Mon, 18 Jun 2001, Kurt Seifried wrote:

Something to consider: for complicated setups proftpd is a LOT easier to configure then wuftpd for example. Thus you are less likely to accidently make a directory world readable.writeable or whatever.

True, but then again, FTP is not the best choice for sensible data after all, see f. i. http://cr.yp.to/ftp/security.html HTTP/TLS and OpenSSH's sftp are viable alternatives in many cases.

On 20-Jun-01 Roman Drahtmueller wrote:

...

True, but then again, FTP is not the best choice for sensible data after all, see f. i. http://cr.yp.to/ftp/security.html

I've just read that article. The conclusions he makes are not quite right, if not plain wrong (it's a client problem, not a protocol design bug: What would make a client send a RETR or STOR command if the data connection, be it PASV or PORT, has not been established yet succesfully?).

True. The whole article is a little blunt, only covering parts of the ftp problem. What the author correctly has figured out is that implementing ftp should be avoided where possible, but the widespread use of this protocol makes this suggestion quite hard to follow in some circumstances. IMHO the worst problems with ftp grow from a combination of the protocol's clear-text transmission of passwords and weakly/lazily configured authorization schemes (one pw for everything, etc.), together with buggy/misconfigured ftp demons.

I'll write an own article about it. Will be on http://portal.suse.de/ .

Delighted to hear that. Perhaps an addition to the SuSE security FAQ would also be a good idea. [...]

Thanks, Roman. -- - - | Roman Drahtm�ller // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | N�rnberg, Germany +49-911-740530 // (Batman Costume warning label) |

--- Boris Lorenz System Security Admin *nix - *nux ---