I wrote another thread that touched on this topic, but I feel the need to bring it up again.
The way Virtualmin handles administrators seems to me to have a serious security problem. There is a single username/password that is used to:
In the first two, the login is encrypted. However, in the third, it is by definition transmitted in the clear. This really bugs me. Its insecure to have a login that can be transmitted in the clear also be the login that has total control over the domain.
I don't see any way to untie ftp access and admin logins. Adding an ftp user assumes only sub-folder access, not access to the full website. As far as I can tell, the main ftp user has to have admin access as well.
Am I totally wrong about all of this? Curious what people think. Its the one thing that is really bothering me as I'm migrating a box to Virtualmin.
Thanks!
At least you can access thru FTP or DAV. I cant even get that.
But I do agree with you. Also the security doesnt seem to work as needed. It says I can make a user, a sub admin as it were. And this user should be able to edit webpages thru webmin.
But nope, dont work.
That link, and the batch link next to it, are not there on my install. 3.48GPL on Debian 4.0, fresh install from the install script.
Yep, that feature is not in the GPL version of virtualmin.
This feature will be in the 3.52 release of Virtualmin GPL.
Actually, by editing the file virtual-server/list_users.cgi under the Webmin root directory, you could enable it right now. Just change line 26 to :
if ($mleft != 0 && $webinit->{'webowner'}) {
--
Check out the forum guidelines!
Sorry, just going to bump this one last time. Joe or Jamie, do you guys not think this is an issue? It seems pretty scary that the master password for a domain has to be passed in the clear to allow ftp access.
Is there a workaround for this? Perhaps a different password system for ftp access? Should I just force my users to use secure ftp of some sort?
Hey guys,
You have several options...
ProFTPd supports TLS/SSL encryption. Turn it on, and enforce it. All modern FTP clients support FTP over SSL. We don't enable it, by default, as you'll want to have an SSL certificate (self-signed will work, but you lose half of the purpose of SSL/TLS).
You could disable FTP altogether. SSH is a more modern protocol, and many FTP clients, as well as clients designed specifically for SSH (like WinSCP), support FTP over SSH (sometimes called "FISH"). This is my recommendation, but many folks have a hard time giving up FTP.
As for this bit:
<div class='quote'>Adding an ftp user assumes only sub-folder access, not access to the full website. As far as I can tell, the main ftp user has to have admin access as well.</div>
You're creating a mailbox/FTP user. That's not intended for any administrative work at all.
If you want a special FTP account just for web content management, use the "Add a website FTP access user." link. That's what it's for. The other "Add a user to this server." link is for creating mail users (who might happen to be able to use FTP to put stuff into their home directory--but should not be used for website administration purposes).
--
Check out the forum guidelines!
Thanks for the response, Joe.
1) Enabling TLS/SSL in ProFTPD is a potential solution for some situations, but not all:
I have clients that need to use older non-TLS/SSL FTP software for whatever reason, and I would prefer to meet their needs in a secure way rather than force them to do things in a new way.
Also, due to the way ProFTPD handles TLS/SSL, you can't securely have unencrypted anonymous FTP access and encrypted access for everyone else. For clients that require anonymous FTP, this is an issue.
2) I am using Virtualmin 3.48GPL and I don't see any "Add a website FTP access user" link. I only have "Add a user to this server" and within that the option to enable FTP.
What would be ideal, in my opinion, would be to be able to configure Virtualmin to disable administrator FTP access (and have that be the default) and then be able to set up an isolated FTP user with access to the root public_html directory (and only that directory). Because it is a security risk, FTP access should never be enabled by default (or it should at least be configurable that way).
Thanks again.
[img size=400]http://www.virtualmin.com/components/com_fireboard/uploaded/images/ftpus...
<img src='http://www.virtualmin.com/components/com_fireboard/uploaded/images/ftpus... style='border:0px'>
Is there any chance of this feature making it into Virtualmin GPL? I believe that would make it possible to alleviate this security issue, by adding all admin users to a group that is denied access in ProFTPD, and then adding ftp-only users on an as-needed basis.
Otherwise the only real solution I see is disabling FTP access.
Thanks!
Yes, it'll be in 3.50 or 3.51 (not sure if we've branched 3.50 yet or not).
--
Check out the forum guidelines!
Great, thanks Joe!
3.50 branched with this change in place. So, tomorrow when 3.50 goes out, it'll have this feature.
--
Check out the forum guidelines!
I just updated to 3.50gpl and I still don't see the "Create FTP User" option when I go to "Edit Mail and FTP Users".
Do I need to enable this feature somewhere?
<div class='quote'>Do I need to enable this feature somewhere? </div>
No, it looks like Jamie missed a step in making this feature available. I'll file another bug about it.
--
Check out the forum guidelines!
Hey guys, just checking. Did this feature not make it into 3.50GPL? Still don't have the "Create FTP User" option.
Thanks.
Sorry to keep bumping this, but I really need to know what the schedule is for this feature in GPL, so I can plan a migration.
Thanks!
I installed version 3.50 gpl on my fresh debain system today. Sorry but without this feature the virtualmin is useless. I have to reinstall my rooty...mhhhhh
snoy
Thanks alot !!!
Snoy
I tried the above code, and while it does indeed enable the option, I can't get it to work. The resulting form that comes up to create an ftp user has no submit, and seems generally buggy.
I guess we'll have to wait for 3.52?
Thanks, glad to know that this is in the works.
That's a separate bug - it will be fixed in 3.51, which is undergoing QA at the moment. You'll have to re-make the change I gave after installing 3.51 though, as it will be over-written..
--
Check out the forum guidelines!