FTP Server

Craig White plug-discuss@lists.plug.mybutt.net
Wed, 16 Jan 2002 20:12:21 -0700


Brian Cluff wrote:
> 
> Look at inetd or xinetd configs....  Basicly you will want it to start the
> ftp server whenever someone tries to connect to it.
> Depending on the ftp server you can also run them as stand alone servers,
> but you will need to doctor your config to tell it to do that.  If you are
> trying to use wu-ftpd I would recommend switching to proftpd as wu tends to
> be a magnet for getting hacked, and pro will allow you to run as a stand
> alone server if thats what you want.  It's also a little easier to
> configure.
> 
-----
Now we have two people making this statement but it completely
disregards the reality of the situation. If you look at
<http://www.woodstone.nu/ftpstats/ftp_all.htm> you will see that wu-ftpd
completely dominates the ftp market which is a good reason that there
have been more exploits out there for that daemon server and less for
statistically insignificant daemons.

More importantly, there is a very robust method for keeping these things
up to date on a redhat system - it's called up2date and it will
automatically download and update installed daemons when system
advisories require updating. Say I install a proftpd or pure-ftpd on a
system but the security advisories that I get from redhat will never
mention them because they don't include them, and it never gets
updated...how smart is that? I can tell you from my very limited
perspective, it's much smarter for me to use wu-ftpd as part of the
redhat package and it gets updated frequently by my running "up2date -u"
which will update all the packages installed on my system (or profile)
as opposed to having to consider the security implications of a
'foreign' ftp server that redhat doesn't support.

I wonder if all those preaching switching the
standard/supported/maintained ftp daemon for one that will require some
effort in updating, linking libraries, security implications etc... why
they are still using bind, openssh and other daemons that likewise have
a storied history of security advisories?

Lastly, if security through obscurity (or statistically insignificant
marketshare - hence statistically insignificant exploit efforts) is
desired, may I recommend Macintosh OS 9?

Craig