[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Keeping the webserver safe



On Sun, 2008-10-05 at 20:27 +0200, Rico Secada wrote:

> I have a webserver running with a couple of users as virtual hosts in
> Apache. 
> I read this article from IBM
> http://www.ibm.com/developerworks/opensource/library/os-php-secure-apps/index.html
> (look for "Guard your filesystem") and testet the PHP script on an Etch
> installation, and the script serves files such as /etc/passwd and
> others.
> What is the best and correct way to protect the server from users who
> might upload such a script on their web directory?

Well "correct" is a subjective thing, as is "best". There are many ways
of going about such a thing, you would need to pick a method that best
suits your environment and fits well with any other requirements you may
have, and only you know what all those things are.


> I don't want to run Apache in a chroot.

A chroot is one way of going about it, it restricts quite well what is
available to the process (right down to what information is in
the /etc/passwd file), chroots can still be broken though :)

You should be looking at methods of filesystem security that include
things like POSIX ACL and SELinux. You should also be aware of the
effect that things like mod_suexec mayhave on things. Another thing to
look at are the php setting for things like temp space, restricting
where a script can read and write can be very important. Looking at
mod_security and mod_rewrite to possibly sanitize any query strings gong
to scripts might be an option for you (assuming you can come up with the
right regex)

You could enforce a policy where by users need to upload all files to go
into webserver directories into a staging area where you could run some
rudimentary checks on them before publishing.

These are but a few ideas, I am sure others might weigh in with more
(and/or criticism of mine). I will point out that these are all given
with absolutely no knowledge of all the restrictions imposed by your
business model, of any other requirements your systems might have and of
the control you might have over users/developers.


-- 
Nikolai Lusan <nikolai@lusan.id.au>


Reply to: