apache security

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

apache security

Almir Karic
what i would like to achieve is that on a shared host if bad guys (tm)
break into one site they can't get to other sites.

is this possible? i've been looking at su-exec but it is for cgi
scripts only :/, what other options there are?

AFAIK chroot is not the correct answer to my question as it protects
the rest of the system from being exploited if one of the sites gets
cracked but it can't protect one site from another...

--
almir

Reply | Threaded
Open this post in threaded view
|

Re: apache security

Lord Sporkton
I had an idea but not sure if its possible, section off and chroot
each site into a folder of its own, not sure if thats possible to
chroot each site to a diff dir or not, i think apache only allows you
to chroot the process

Maybe use permissions, diff user on each site, chmod to disallow
writing from other users?

Just some thoughts i had not sure if they are valid.


On 1/23/07, Almir Karic <[hidden email]> wrote:

> what i would like to achieve is that on a shared host if bad guys (tm)
> break into one site they can't get to other sites.
>
> is this possible? i've been looking at su-exec but it is for cgi
> scripts only :/, what other options there are?
>
> AFAIK chroot is not the correct answer to my question as it protects
> the rest of the system from being exploited if one of the sites gets
> cracked but it can't protect one site from another...
>
> --
> almir
>
>


--
-Lawrence
-Student ID 1028219
-CCNA

Reply | Threaded
Open this post in threaded view
|

Re: apache security

Darren S.
In reply to this post by Almir Karic
On 1/23/07, Almir Karic <[hidden email]> wrote:
> what i would like to achieve is that on a shared host if bad guys (tm)
> break into one site they can't get to other sites.

"break in" has more than one meaning, and you might have different
answers for different scenarios.

> is this possible? i've been looking at su-exec but it is for cgi
> scripts only :/, what other options there are?

If you want isolation, given that "breaking in" can have multiple
meanings, perhaps an option to look at is jailing each site. FreeBSD
supports pretty reliable isolation of your web server into individual
jails on the box. sysjail would be an alternative to look at for
OpenBSD.

DS

Reply | Threaded
Open this post in threaded view
|

Re: apache security

Almir Karic
In reply to this post by Lord Sporkton
> Maybe use permissions, diff user on each site, chmod to disallow
> writing from other users?
>


that would solve the problem, but i have no idea how to achive it, and
google doesn't seem to like me :/. any hints?


--
almir

Reply | Threaded
Open this post in threaded view
|

Re: apache security

Jacob Yocom-Piatt
In reply to this post by Almir Karic
Almir Karic wrote:

> what i would like to achieve is that on a shared host if bad guys (tm)
> break into one site they can't get to other sites.
>
> is this possible? i've been looking at su-exec but it is for cgi
> scripts only :/, what other options there are?
>
> AFAIK chroot is not the correct answer to my question as it protects
> the rest of the system from being exploited if one of the sites gets
> cracked but it can't protect one site from another...
>

use a systrace-d shell, stsh. kind of a pain to get all the systrace
policies in place, but very effective at achieving what you're after.

cheers,
jake

Reply | Threaded
Open this post in threaded view
|

Re: apache security

Joachim Schipper
In reply to this post by Almir Karic
On Tue, Jan 23, 2007 at 05:44:38PM +0100, Almir Karic wrote:
> what i would like to achieve is that on a shared host if bad guys (tm)
> break into one site they can't get to other sites.
>
> is this possible? i've been looking at su-exec but it is for cgi
> scripts only :/, what other options there are?
>
> AFAIK chroot is not the correct answer to my question as it protects
> the rest of the system from being exploited if one of the sites gets
> cracked but it can't protect one site from another...

The simple solution is to not allow the web server to write anywhere but
/tmp.

There are other solutions to this problem, including suexec, but the
above is surprisingly easy to pull off.

                Joachim

Reply | Threaded
Open this post in threaded view
|

Re: apache security

Nick Holland
In reply to this post by Almir Karic
Almir Karic wrote:
> what i would like to achieve is that on a shared host if bad guys (tm)
> break into one site they can't get to other sites.

if "get to"=look at, this is probably pointless.  Unless it is a
authentication-protected site, the information is usually spread
around by various browser "tool bars" and spyware and is probably more
public than the "secretive" site owner thinks.

> is this possible? i've been looking at su-exec but it is for cgi
> scripts only :/, what other options there are?
>
> AFAIK chroot is not the correct answer to my question as it protects
> the rest of the system from being exploited if one of the sites gets
> cracked but it can't protect one site from another...

BY DEFAULT...
chroot not only protects the rest of the system, but also protects the
website(s) itself.

  http://www.openbsd.org/faq/faq10.html#httpdchroot

". . . the starting configuration of the OpenBSD chroot(2)ed Apache is
where the user the httpd(8) program is running as can not run any
programs, can not alter any files, and can not assume another user's
identity."

IF you maintain that rule, your system is pretty darned secure, as
even if someone knocks over httpd, all they can do is LOOK at other
sites, they can't deface them.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: apache security

Mark Bucciarelli-2
In reply to this post by Almir Karic
On Tue, Jan 23, 2007 at 05:44:38PM +0100, Almir Karic wrote:

> is this possible? i've been looking at su-exec but it is for
> cgi scripts only :/, what other options there are?

If you can run the app(s) with FastCGI (most PHP stuff I have
tried does), another option is to use suexec wrapper for dynamic
FastCGI processes.  If you configure the FastCGI processes to die
quickly, and you have many low volume sites, it is not a big RAM
hit.

m

Reply | Threaded
Open this post in threaded view
|

Re: apache security

Alexander Farber
In reply to this post by Joachim Schipper
Joachim, could you share your config files for that?

On 1/23/07, Joachim Schipper <[hidden email]> wrote:
> The simple solution is to not allow the web server to write anywhere but /tmp.


Regards
Alex

--
http://preferans.de

Reply | Threaded
Open this post in threaded view
|

Re: apache security

Toni Mueller-10
In reply to this post by Joachim Schipper
Hi,

On Tue, 23.01.2007 at 21:45:14 +0100, Joachim Schipper <[hidden email]> wrote:

> On Tue, Jan 23, 2007 at 05:44:38PM +0100, Almir Karic wrote:
> > what i would like to achieve is that on a shared host if bad guys (tm)
> > break into one site they can't get to other sites.
> >
> > is this possible? i've been looking at su-exec but it is for cgi
> > scripts only :/, what other options there are?
> >
> > AFAIK chroot is not the correct answer to my question as it protects
> > the rest of the system from being exploited if one of the sites gets
> > cracked but it can't protect one site from another...
>
> The simple solution is to not allow the web server to write anywhere but
> /tmp.

imho this is not really effective.

You may also want to prevent one site from reading the other's site
passwords for their databases etc. and then going after their "backend
data", so to say, or to steal passwords for logging in via their front
page, eg into an "admin area".

To me, this currently comes down to using unique user and group ids for
individual web site instances, and then chroot each server into their
respective tree where the requirement for reading other people's data
is to break out of the chroot first.

But thanks for the pointer to sysjail, I'll surely be looking at it
RSN. :-)


Best,
--Toni++

Reply | Threaded
Open this post in threaded view
|

Re: apache security

Lars Hansson
Toni Mueller wrote:
> To me, this currently comes down to using unique user and group ids for
> individual web site instances, and then chroot each server into their
> respective tree where the requirement for reading other people's data
> is to break out of the chroot first.

This can be done with the default chroot as long as you dont allow your
users to run any cgi's. Just make each vhosts docroot be owned by the
user and readable by the www group and you're set.
If you're hosting PHP sites you also need to remember to set (and
enforce) open_basedir for the vhosts.

---
Lars Hansson

Reply | Threaded
Open this post in threaded view
|

Re: apache security

RedShift
Lars Hansson wrote:

> Toni Mueller wrote:
>> To me, this currently comes down to using unique user and group ids for
>> individual web site instances, and then chroot each server into their
>> respective tree where the requirement for reading other people's data
>> is to break out of the chroot first.
>
> This can be done with the default chroot as long as you dont allow your
> users to run any cgi's. Just make each vhosts docroot be owned by the
> user and readable by the www group and you're set.
> If you're hosting PHP sites you also need to remember to set (and
> enforce) open_basedir for the vhosts.
>
> ---
> Lars Hansson
>
>
>

We dealt with this another way. We create a separate instance of httpd
for every user, and let httpd run under that user. Each instance is on a
different port number bound to 127.0.0.1. To tie it all together we use
a reverse proxy (pound) and enable virtual hosting in the proxy to
redirect vhosts to the right apache instance.

Reply | Threaded
Open this post in threaded view
|

Re: apache security

Toni Mueller-10
In reply to this post by Lars Hansson
Hi,

On Fri, 26.01.2007 at 19:17:41 +0800, Lars Hansson <[hidden email]> wrote:
> Toni Mueller wrote:
> >To me, this currently comes down to using unique user and group ids for
> >individual web site instances, and then chroot each server into their
> >respective tree where the requirement for reading other people's data
> >is to break out of the chroot first.
>
> This can be done with the default chroot as long as you dont allow your
> users to run any cgi's.

this I can't prevent. Or at least, my users want/need this.

> Just make each vhosts docroot be owned by the
> user and readable by the www group and you're set.
> If you're hosting PHP sites you also need to remember to set (and
> enforce) open_basedir for the vhosts.

Yes, I'm also hosting PHP sites, and PHP4, for that matter (I can't do
much about it right now). The "solution" will entail some PHP version
that actually obeys the "open_basedir" setting. While I don't have
proof that the version shipped in ports don't, I dimly remember a
recent incident about just that not always being the case.


Best,
--Toni++