Securtiy Issue?

Oh sorry I forgot to mention,

I have mounts from the /var/www/example.com directories to the /home/user/websites/exmaple.com

Not sure if that's the best way but its work for years and now I've got issues with apache permissions and security so I'm questioning myself on several things..

You don't want apache or php to be able to write to your files. They should be owned as your user (or root, or really any user that's not www-data) and set to 755 for directories and 644 for files (excepting of course, any files that contain credentials or other secrets, which should be 640 your-user:www-data, so that you can write them, php can read them, and nothing else can read them.

That way, when somebody hacks whatever PHP app you're running, they can't use it to write other PHP files which they can then execute (which sounds like what is happening here). You'll still need to keep your PHP apps updated/patched/whatever to prevent the initial malicious access.

-Les

Cheers for the speedy reply Les, Yeah this is exactly how I have it running. I must have someone on the box somewhere that's out of date… I'm currently rolling through all the access logs and seeing how or what is happening.

I've run the usual chkrootkit and rkhunter, which only minimal issues, some what the usual false positives.

Just out of interest… for example wordpress requires the uploads directory to be writeable yet this opens up the issue of having a script out of date and someone pushing a php file into that folder. The only way I know that I can truely stop this is keeping things up to date, however 0day stuff will still happen so I've added a htaccess file with a disallow on all php files to stop this.

Are there any other ways that this could be done or is this about as good as it gets?

Thanks,

Dan

My issue now is,

If i have a user lets say "dan" and that user owns the files in directory then do I add www-data to the group dan? or do i add dan to the group www-data and change the owner of the files?

I need apache to be able to update things, but it can't at the moment, and I feel its my permissions that are incorrectly set either by group or user.

I don't ever want to use 777 but at the minute that's the only option, so im positive that i need to work out the best group setup for apache.

Anyone have any ideas?

You do not want apache to be able to update things.

So my question is, how do you allow wordpress for a website upload the files to the upload directory without 777 ? I don't want to use 777… the documentation states nothing more than 755 should be used, but I can't see how that's possible without adding apache to the users group which defeats the object surely?

Cheers

Dan.

Looking at it now, I think i need to use something like FCGI and run PHP or suPHP to make php run as the user but not apache? But still I fail to see how that would stop someone using the webserver to write files to it if suPHP is run as that user instead of www-data?

Am I missing something stupidly obvious?

You do not want PHP or apache to be able to write files. If you specifically need it to write to a specific directory (I'd say just don't), then you make that specific directory owned by your-user:www-data and set it 775. But you're accepting a ton more risk since now things can be written by PHP to that location and later executed.

What is the best solutions then?

Stats show that 25% of the internet use wordpress, and there are many vulnerabilities around, yet that's usually down to the way its configured. I'm sure there is a better method of securing LAMP to allow users to upload files and not have issues with the above. I'm just trying to find that solution or method that the other main steam companies seem to have nailed.

Cheers,

Dan

I don't know how many times I can say the same thing over and over.

@akerl:

I don't know how many times I can say the same thing over and over.

Sorry, I did say is earlier I feel like i'm missing something.

If what you're saying is basically everyone else is insecure then fine that makes sense but surely they're not. I can't imagine that every site that uses apache with PHP and allows file uploads is dumping ground for joe public? - That just seems ludicrous.

Why?

It just doesn't seem at all secure.

P.S this has only become an issue since I've been asked to run a site for a friend and I don't want them to be able to kill anything I have on my server. Naturally yes I could just say no, but given that a lot of companies do shared hosting, I fail to see why this isn't possible and not documented online? I've searched for days on the topic.

:cry:

Yes, allowing a web process to self-modify its own code is not secure.

Thanks Les, Appreciate your time.

Every time I see a "guide" that suggests that you should run websites from /var/www/ I cry a little… :p

I don't want to get into the details why its so wrong to do this from a security point of view (or any kind of view for that matter).

But I can provide a description of what a somewhat decent virtual hosting should look like. As an example, you can look at how NOT to setup your system by looking at Plesk which has the worst design and you can also look at cPanel/WHM which has a much better design. So the "better" design:

• Run each virtual host as his own unix user (user/group separation)

• Under his own home directory (file separation)

• All processes owned and executed as the above unix user (process separation)

• From within a jail (even more file system separation)

• With his own tmp folder (temporary and php session file separation)

• User file system quotas (overall mounted system protection)

• SELinux (in enforcing mode)

• etc

Some of the above items are relatively easy to do with tools that you already have (Apache, PHP, etc), while others are more complex (jail, quotas, etc).

Going into a bit more details here, in case someone is interested:

• Create a unix user per virtual host

• Apache virtual host config file per virtual host that points to the above unix user's /home/ dir

• PHP with open_basedir set to the above unix user's /home/ dir

• ITK (or similar module) for user/group process ownership

• Disabled shell access of course

• Disabled insecure services (ftp, etc)

• Strengthened sshd (keys only, etc)

• Most importantly: ENABLE SELinux !!! Its there for a reason, most hacks are rather insignificant/inoperable and others will be limited to a single virtual host

More advanced features include jail shells, file system quotas per home directory and PHP hardening (disable functions, etc).

The above is just my professional experience.

PS:

on websites that I require total isolation, I use a single server per domain (still using all the above even if its just one virtual host).

@IfThenElse:

But I can provide a description of what a somewhat decent virtual hosting should look like. As an example, you can look at how NOT to setup your system by looking at Plesk which has the worst design and you can also look at cPanel/WHM which has a much better design. So the "better" design:

• Run each virtual host as his own unix user (user/group separation)

• Under his own home directory (file separation)

• All processes owned and executed as the above unix user (process separation)

• From within a jail (even more file system separation)

• With his own tmp folder (temporary and php session file separation)

• User file system quotas (overall mounted system protection)

• SELinux (in enforcing mode)

• etc

It looks like that you are not familiar enough with Plesk or you are talking about very old Plesk version.

Part of mentioned "better design" items long time ago can be configured by Plesk or hosting settings, part of them can be achieved using fastcgi/fpm instead of mod_php.

> - Run each virtual host as his own unix user (user/group separation)
It is true for Plesk.

> - Under his own home directory (file separation)
It is true for Plesk.

> - All processes owned and executed as the above unix user (process separation)
Just use modern approaches fastcgi/fpm instead of mod_php, for instance.

> - From within a jail (even more file system separation)
Just use Plesk on CloudLinux

> - With his own tmp folder (temporary and php session file separation)
It may be specified in PHP settings of Service Plane and add location of tmp directory in default vhost skeleton.

> - User file system quotas (overall mounted system protection)
Plesk can operate quotas in case of it is enable on filesystem.

> - SELinux (in enforcing mode)
Works like a charm on RedHat based OSes.

BTW, addon domains in cPanel does not satisfy your "better design" criteria.

While every product has the risk of security issues (just watch security advisories), they differ in how they handle it. You can explore this well known epic thread at webhostingtalk.com http://www.webhostingtalk.com/showthread.php?t=1267400 – about a root exploit in cPanel started in May 2013 and continued many many month with a lot of pages. Running backup under root is really bad idea for such popular product like cPanel.