?Security and Privacy Problem?

wordpress
#1

I am a new user of DreamHost’s shared plan “Crazy Domain Insane!”.
If I am wrong, please point it out.
I would like to write conclusions/questions at first.

Q1. Are our web access logs (which can include e-commerce
customers’ private information) exposed to other SSH users?

Q2. When we use the default settings,
are our web folders and files (which can include
implicit files like *.php which sometimes
include ID/Password) exposed to other SSH users?

Q3. If I am not wrong, what should I do to protect
my and my customers’ privacy and security?

I asked a support staff three times, but I could not get
expected answers or changes, so please help me, everyone.

In Detail

Process1. With SSH access, users can find many USERNAMEs:
$ls -a /home

The directories of access logs are determined and owned
by root (DreamHost) like this:
/home/USERNAME/logs/DOMAINNAME/http/

These directories can not be changed for ourselves.

P2. SSH users can see which domain names each user registered, too.
$ls /home/USERNAME/logs/

Now SSH users have known the combination of USERNAME and DOMAINNAME.

P3. So they can see other users’ access logs now.
$ls /home/USERNAME/logs/DOMAINNAME/http/

(The support staff wrote, "Logs are actually all public readable"
Wow! Is this a public comment from DH?)

P4. As a default, web directories are like this (but this can be changed):
/home/USERNAME/DOMAINNAME/

If users do not change the default web directories’ name,
SSH users can look inside others’ files (not only html, but also php, js…).
So I think the default setting is dangerous.

I really want to use SSH because it is convenient,
but I want security and privacy, too. Thanks in advance,

–
dhnewuser

#2

I agree. It’s a pretty simple matter to rename the directory your domain is served from via the panel, though making logs more private would help.

–rlparker

#3

HTTP logs only contain URLs accessed and referring URLs, which should never contain sensitive information. If your web site or application is writing sensitive info to the logs, it’s broken and should be fixed or replaced.

The single exception to this is basic HTTP authentication usernames, which are logged, but this isn’t a security problem in itself, as these logins are still useless without the corresponding passwords. While it helps security to keep usernames secret as well as passwords, if you’re using basic HTTP authentication on a shared server chances are you’re not using SSL so this information isn’t secure anyway.

Any CGI executables on your site can be made readable solely by the owner. CGI is run under suexec, so these are executed as the user who owns them, not the web server user. This includes PHP if you’re using the default setting of PHP-CGI.

–
If you want useful replies, ask smart questions.

#4

Just to follow up on what kchrist said, if you are concerned about another user on your server recovering user/pass combinations or other “sensitive” information that might by laying around in “config” files (a common practice with many, if not most, FOSS applications), just change the permissions on that file to make them readable only to the owner - suexec will ensure the application can read the files, but other users on your server cannot.

–rlparker

#5

I am using only applications provided by DH. (e.g. MySQL/phpMyAdmin/Wordpress…)
I don’t think the default applications are broken.

According to my access.log, there is information more than URLs.
For example, when I see the logs which was recorded when I accessed with phpMyAdmin,
I can find my IP address, database user name (this is what kchrist said), MySQL server’s name…
As kchrist wrote, a password is the last key to protect my database.

I also see IP addresses of the users of my site which can be used to detect them.
And I can see when and what they watched in my site.
I am worrying about both security and privacy.
But I know I can not make them perfect.

Anyway, so far,
Q1. Yes.
Q2. Yes.
Q3.1 About logs:
We can not do anything and logs can be seen by other SSH users.
Q3.2 About inplicit files:
Change the default names of folders for web sites at first.
Change CGI executables or “sensitive” files readable only by the owner.
(Thanks rlparker & kchrist for this useful information!)

If someone knows how to protect the log files for ourselves, please tell me!

#6

Can someone provide a couple guidelines for new users? I just got a smackin new account and I have the luxury of doing everything right (or wrong) the first time - though I have a ton of files I need to migrate to my DH space.

RL, are you suggesting changing the /home/user/domain.tld to /home/user/foo ?

Is it reasonable to change /home/user/logs to something else (/home/user/logs/foo/http…)? I trust all logs then auto-redirect data into that renamed path?

Whether or not we change the directory, is it advisable to do a mass chmod on all files to remove the read bit from Other? That seems a bit extreme but the typical 755 has always seemed a bit liberal to me anyway. Are we looking more at 750 or 751?

Is there any way to test our handiwork to verify files are secured against Other access? I’m guessing we’d need to create a user outside of the default group and then try to poke around.

Thanks.

#7

Staarbuck,

Welcome to Dreamhost! I’m glad to see your thread on “The mother of all pre-sales inquiries” answered enough of your questions for you to feel comfortable giving DH a try. :slight_smile:

I’ll try to answer your question(s) as best I can, but be fore-warned that I do not consider myself to be an expert on *nix server security. There are many on this forum that know a lot more about this than I; I hope they will jump in to help should I give “less than stellar” advice. That said, since you addressed a particular question to me, I’ll share what I (think I) know. :wink:

I don’t know that I would go so far as to “suggest” it, but I did point out to another poster that this would help to obfuscate where the files that are associated with a domain are stored. I don’t think much of “security by obscurity” as a general security philosophy, but there is some truth to the argument that each obstacle placed in the path of an intruder has some deterrent value.

Granted if only one domain is stored in your user space, it is trivial for an “explorer” to determine which domain’s files name (which he identified by inspecting /home/username/logs listing) are stored in “foo”, but it would take considerably more persistance for that same explorer to wade through 200 or 2000 “foo” files trying to locate the files for a given domain. Does that make any sense?

Actually, if you rename /home/user/logs to something else, the next time the server goes to write to the log files it will recreate the /home/user/logs directory and start new logs there for all your domains instead of auto-directing to your renamed directory. The control panel does not have a way for you to change this behavior.

I don’t know that it is advisable to do that with all files - after all, anything you want to be viewable to the public is already available via http, right? I generally set directories to 755 and the “public” files to 644, though CGI executables need to be 755 to run properly under suexec. I also tighten down things like PHP config files, .htacess, .htpasswd, etc. as far as possible for the circumstances (in addition to trying to keep them stored above the web accessible directories.

That strategy has worked for me. I have hosted a lot of sites here over the years and the only real “exploit” I have suffered was one occurrence a long time ago where I foolishly (lazily) “moved” a client’s existing site, complete with an operative but insecure formmail script, onto the server without thoroughly vetting the script. I learned my lesson, and won’t be doing anything like that again.

I’m sorry, I don’t really know the correct answer to that question (though I suspect someone here that does might chime in!).

–rlparker