Replacing ProFTPD with VSFTPD

rhoekman

Verified User
Joined
Jan 3, 2004
Messages
225
Location
The Netherlands
Why?

vsftpd was designed and implemented from the ground up with security it mind. It fixes fundamental design flaws present in most installations of wu-ftpd, proftpd and even bsd-ftpd by not over-using the dangerous root user. It makes use of powerful security facilities such as capabilities and chroot. It employs secure coding techniques to make buffer overflows a solved problem.

http://vsftpd.beasts.org/

Who uses this?

ftp.redhat.com
ftp.suse.com
ftp.debian.org
ftp.gnu.org
ftp.gnome.org
ftp.kde.org
rpmfind.net
ftp.linux.org.uk
ftp.gimp.org
ftp-stud.fht-esslingen.de
ftp.openbsd.org
gd.tuwien.ac.at
ftp.sunet.se
ftp.ximian.com
ftp.engardelinux.org

I do too :)

Any reason why we should stick to ProFTPD?
 
Hello,

Proftpd doesn't allow root access through ftp at all, it's compiled in, so even if you set it up in the password files, it won't work. All ftp connection *are* chrooted, so users can never break out. Proftpd seems to be working fine, so no need to change it.

John
 
I think, like SSH, you should not allow root acces remotely for obvious security reasons. If root acces is needed for administration use SSH and SU to root. FTP will be used by users. Or do I miss something?

Rick
 
rhoekman said:
I think, like SSH, you should not allow root acces remotely for obvious security reasons. If root acces is needed for administration use SSH and SU to root. FTP will be used by users. Or do I miss something?

We use SSH remotely due to the fact we have to (without using co-lo in the UK which is far more expensive in terms of bandwidth)

FTP is the main utility used in transferring data to and from users acocunts, thereore, yes, it will be used by users.

I'm not sure what you think you are missing...

I think what John is trying to put across, simply is: "if it doesnt need to be fixed, don't fix it."

Chris
 
Normally I agree with the if it works statement.. But it is not fixing something. For one security is a big issue on a public server. Performance is a big issue and stability is. ProFTPD needed a patch last september, they do not update their versioning so you can not check if it is patched or not. So switching to vstfpd will be an improvement as a lot of things in DA will be 'fixed' to have better security, performance.

With missing point I ment if users needed to break out of their chrooted environment for some reason. System calls, scripts etc..

If that is the case well yes than vsftpd is not suiteable for DA.
 
rhoekman said:
For one security is a big issue on a public server. Performance is a big issue and stability is.

Of course.... But ProFTPd is probably one of the most widely used FTP servers for unix type systems... I'm sure its security is enough for the average user, howevever if you have reasoning against this and are that concerned you should surely remove all instances of ProFTPd on your server and install the client of your choice with the settings of your choice also, with the new upon site creation / removal scripts its certainly possible and shouldn't be difficult providing you know the configs etc for the new server.

rhoekman said:
switching to vstfpd will be an improvement as a lot of things in DA will be 'fixed' to have better security, performance.

What do you mean; 'a lot of things in DA will be fixed'? Nothing FTP related in DA needs 'fixing'. As mentioned above, The security in ProFTPd is adequate for mosut users - advanced users can do anything they wish beyond and should know how it works.

rhoekman said:
With missing point I ment if users needed to break out of their chrooted environment for some reason. System calls, scripts etc..

You were just stating your points about security I believe? - and you are now asking if we can have it to allow users to break out of their chrooted environment with root access?

rhoekman said:
If that is the case well yes than vsftpd is not suiteable for DA.

If what I stated above is what you want, then I assume it would work for you nicely, however ProFTPd can be customised - you are *not* limited to cretaing and removing accounts from within DirectAdmin.

Finally, for DirectAdmin to implement a feature like this would be asking for a huge amount of trouble at this point. I know some users running 100's of sites on DirectAdmin servers, to get ProFTPd removed should be easy, rewriting configs should be ok (aslong as DA has a database of all this data!) etc... the problems occur with customisations to ProFTPd - if DA were to force out this upgrade it would break any customisations and leave only defaults thus leaving advanced users with possibilities of drastic problems ahead.

Chris
 
With fixing I do not mean proftpd alone I mean software development in general. I do not want users to break out of chrooted enviroments it was a question if they need to make systems call currently, if vsftpd was installed would it block usage of certain system calls. I also do not mean that DA is buggy. If it to much work than forget the situation, it was merely a suggestion.
 
Hello,

:)

I don't think there is any way to break out of the chrooted environment that proftpd uses. The process is chrooted to the home directory and the user privilege of the program is dropped to the user's userID. Can't do anything outside of the ftp's home directory once that is done.

John
 
rhoekman said:
With fixing I do not mean proftpd alone I mean software development in general.

I can't see what your getting at here... at the moment the FTP area of the DirectAdmin software is complete and is in no way getting in the way of DirectAdmin's development (as far as i'm aware)

Patches are provided by ProFTPd themselves and can therefore be updated by you, the user without any affect on DirectAdmin or its development.

rhoekman said:
I do not want users to break out of chrooted enviroments it was a question if they need to make systems call currently


ProFTPd is chrooted to an environment you specify, you can create your own users with access to areas elsewhere however the user 'root' cannt be used with ProFTPd (due to security, as you mentioned).

rhoekman said:
If it to much work than forget the situation, it was merely a suggestion.

It's not to much work as i mentioned earlier, remove proftpd install it then rewrite the configs - simple, however any modifications made by admins / users will be wiped - absolutely anything... in many cases admins leave the default settings and only DirectAdmins FTP users are there... for them it would probably be ok to do, howevever advanced users would have problems and thats where DA fails to do anything here...

Accepted it was a suggestion, it may have appeared I was arguing against it, however I was rather thinking of both sides, your showing the good that would come of the change, however theres downsides which is what i'm stating.

For DirectAdmin to consider the move, they would need to think about all users, all the negatives and all of the positives that would come of the change - thats what we need to get at :)
 
That is the thing I do not want to break out of the DA box. Whenever an update is made I'll have to reconfig the lot.

(Just recently ran into this with permissions)
I was wondering if you can restrict the user to his /home dir with proftpd? To avoid error messages I had to change permissions on some directories to 755 currently this leaves it open for every user logged in via ftp to read the files?

With vsftpd however you can restrict the user to only his own directory.
 
rhoekman said:
I was wondering if you can restrict the user to his /home dir with proftpd?

Thats what DA does as default:

/home/user1/file

in ftp would be seen as:

/file (NOT /home/user1/file)

Have a look at proftpd.passwd if that is not what is happening for you.

Chris
 
I had wondered if DA could support different software, perhaps using some kind of modular system. I think qmail would be more secure than Exim... qmail even offer rewards to people who can find an exploit.

Any plans for this in future?

Thanks,
Matt :)
 
Im going to voice my opinion on it, some may agree some may not... either way:

I would prefer *not* to see something like that in DA, anything besides testing systems and the like, id prefer to have *only* software actually being used there.

why have two MTA's, 2 webmail clients, 2 ftp servers, 2 httpd servers etc etc.... why?
- you can only use 1 httpd server, 1 ftp server etc...?

Theres also other little things of this sort currently inplace that I dislike, for example, the customapache system for redhat/fedora downloading the freebsd data...the fix, im sure is to simply do an if command on the script to check its not freebsd! - little things that i'm really not bothered about... not actually complaining about... just dont feel they should be there at all - its not being used in any way, its never been used, its just download and left there!

Of course, the applications being much more important... if DA were to implement a choice for ftp servers / mail servers or anything like that, they need to produce updates for twice as much software on each OS.

Chris
 
I understand, I agree that DA shouldn't become bloatware. I'm perfectly happy with Exim, I just wish they'd picked qmail in the first place :D They'll always be arguments over this though... it's all opinion.

Matt :)
 
thoroughfare said:
I had wondered if DA could support different software, perhaps using some kind of modular system.
If DA were to go this route then who would be responsible for updates, security, and even for whether or not DA continued to work as all the various software was updated, found to have exploits, etc.?

DA staff? I'd doubt it. Not unless the product sold for double or triple what it does now.
I think qmail would be more secure than Exim...
WARNING: This may sound like a rant. It's really not, it's a well studied response made by someone who was a Plesk Gold partner for long enough to discover exactly what's wrong with qmail.

In fact qmail was one of the main reasons I left the Plesk environment.


You're jokiing, right? Qmail has no ongoing development, and Dan Bernstein prohibits others from actively working on the core program so unless Dan finds a reason to do something, no chance of ongoing development.

In fact Dan even points out that you and I have no continuing right to use qmail except that for the moment he gives us that right, which he can take away at any time.

Qmail is the least configurable MTA there is; you can only configure things written into it when it was first conceived.

Should you want to develop changes to it you're forbidden from including those changes in your own distriibution, even within your own business environment.

Which means that any changes to qmail, including many that make it at least usable, must be distributed separately and installed and patched separately on each server you configure.

The Pop server that comes with it breaks completely when an email arrives with an open square bracket "[" and no closing square bracket "]" in the ID field.

You can't remove emails from the queue without shutting down the server.

If your partition holding the queue fills up you can't move the queue to another partition.

qmail even offer rewards to people who can find an exploit.
Exploits aren't the only problems a program can have.

There's no way I can, wihtout major hacking (and patches I'd have to deliver and install separately) make SpamBlocker (see the thread on this forum) work with qmail; I'd have to run separate systems to block spam on a per-domain/per-user basis; with exim it's just a few lines added to the config file.

There are those who would argue that qmail was a good (some would even argue great) MTA when it was first developed.

Years later it suffers severely.

When new concepts come out (example: SPF) the exim community works with the exim author and there's an immediate accommodation made for those who want to use them.

With qmail you go ahead and develop it yourself and then offer a patch so anyone else who wants it has to go and patch their own software.

Any plans for this in future?
I sure hope not.

We left Plesk mainly because we weren't happy with one particular included program: qmail.

We're very happy with the choices DA has made so far, and I'd hope we leave the DA staff alone to continue making the good decisions they've been making.

And I hope you'll find a platform that has exactly the programs you feel most comfortable with, as well.

Jeff
 
Back
Top