FTP Server

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Craig White
Date:  
New-Topics: Absolute frustration
Subject: FTP Server
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