These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for SSH breach - security problem! on the new forum.
Web Hosting and Cloud Computing Control Panels
1. The biggest problem is that they can move around into the entire server and that they can change all files!
Wrong on the last part. They can ONLY edit there OWN files they OWN. SSH prevents editing files including looking at them if they owned by someone else and they are set chmod 640, 700 or 750. In other words they can see but can't look or touch. It's the design of SSH to do this because it has to emulate a console login to allow the user to edit their own files.
They might be able to see file names but anythign that is system protected like /etc/shadow they will get a error if they try to cat or edit it.
Seeing is not a security risk.
Seeing can be a huge security risk. PHP Scripts store the database access information in plain text format. Some PHP scripts even store administrator login information in plain text or with md5 encryption (which is fairly straightforward to brute...)
I would like to see them jailed to their home directory...
Hey Kevin,
We're only talking about the system files--stuff in /. Stuff in your home directories can and should be tightened way down.
PHP scripts are in users home directories, which can be locked down to 750 (with some caveats). Or they can (and should) be set unreadable by world, even if you don't use 750 for homes.
To lock down homes this way:
Browse to System:Users and Groups, edit the module config. Set "Permissions on new home directories" to 750. Save it.
Then run:
chmod 750 /home/*
Note that if you use Maildir mail spools, you <i>must</i> be running Dovecot 1.0 (only release candidates are out), because 0.99 releases don't support group membership. Virtualmin Professional includes this version for most platforms (with the rest coming this week), as does Fedora Core 5 and 6, by default.
--
Check out the forum guidelines!
FWIW, Scott was referring to "seeing" the file names, not the contents of the files. It is one thing to have read access to a directory to see the file names, and it is another thing to have the files themselves set as world-readable. In other words, users should not be able to access the contents of sensitive PHP scripts if their permissions are set correctly.
Ok, it's still not solved.
Simple question: how can I disable SSH for all hostings at once? There are too many free hosting accounts to disable their ssh login 1 by 1.
If I chmod everything to 750, will this have any implications to the files/folders with special rights like 777 as to make apache able to upload files?
Or does this only happen if files are chmodded with the -R option?
Currently, all files uploaded are chmodded 644 by ftp server. I don't know if this is okay?
/home/*/public_html/ = 755
cgi-bin, public_html, homes = 755
logs = 750
/home/* = 755
why can't we jail them some way when they login with ssh?
They can too look/read files... any of them. because all they have to do is tweak any symlink that has file permission 777 and owned by root to point to any file they want to look at or run. there is a symlink just like this provided in the public_html folder of every domain created... it is the one for the "icon" directory.
I made a post about this already (in the virutalmin questions) and had no response, but this is a security issue I have been wondering about. I haven't changed the owner or permissions of this symlink yet; as I did not know if it would cause an error in apache. I do not think it will, but I have not had time to look into it in depth and was hoping I would get a response. (plus my server does not have hosted other users besides family right now).
I am not, as yet, too keen to let user peruse my file system as I have no idea how many of the tens of thousands of files are going to have ownership and permissions that they can abuse.
go into the webmin-servers-ssh section. click access controls and only allow login via your account. everyone else will be rejected by the ssh server so therefore they won't be able to log in via ssh at all. ftp will be unaffected.
Thank you, now only root can login to ssh. :-)
Hello Koen,
I even changed the port to which ssh listens... the reason I did this is because I kept getting a bunch of logs in the secure log that said people from russia, sinapore, romainia, italy, etc kept trying to login to ssh with various user names. Like root, admin, user, guest, nobody, etc. etc.
when I changed the port I quit getting those warnings in the logs.
/johnford
Changing the port is effective in some cases, but there are much better solutions for this problem. My favorite is DenyHosts:
http://www.DenyHosts.net
thanks Alan, I have been wondering/looking for a good tool like this. I was even able to install it with yum as it is part of the extras for fedora.
just wondering... what is your opinion of the syncronization feature of this program? It appears a lot of people are allowing/doing it.
Yes, I like the fact that it is part of Fedora Extras also. Similarly, it is included with the CentOS Extras site, which is basically a repository of Fedora Extras packages rebuilt for CentOS:
http://CentOS.Karan.org/
The guy that runs it, Karanbir Singh, is one of the primary CentOS maintainers, so it is a very well-supported and reliable source of packages for CentOS.
I think the synchronization feature is a great idea, and it works well with a few exceptions. For one, if you somehow manage to get one of your own servers denied (for example, see[A HRef="http://www.virtualmin.com/bug-tracker/bug?bug_number=638">Bug #638</A>, it can easily propogate to other servers and block you out from your own systems. You can work around this by adding your own system addresses to the allowed file. You also should read up on the time delay and expiration settings, most of which are set appropriately by default.