[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is chrooting apache behind a reverse proxy useful ?
- To: misc@openbsd.org
- Subject: Re: Is chrooting apache behind a reverse proxy useful ?
- From: Brian Keefer <chort@amaunetsgothique.com>
- Date: 30 Apr 2004 23:03:19 -0700
- References: <20040430212051.687a2203@atheria.tumfatig.net> <20040430222851.GC10081@2004.snew.com>
On Fri, 2004-04-30 at 15:28, Chuck Yerkes wrote:
> Quoting Joel CARNAT (joel@carnat.net):
> > Hi,
> >
> > I have Squid doing reverse-proxy to Apache on some other behind-NAT server.
> When Apache is directly reachable, I'm used to chrooting it. I'm just wonderin
> g if it still makes sense to do this if all the requests it gets comes from a
> reverse-proxy (as exploits on Apache must be different than those on Squid) ?
>
> If so, then I can form an exploit for apache and pass it THROUGH squid.
>
> I've used hard core proxies that only allow certain requests, check buffers,
> etc. Those have fallen by the way side as the web grew and managing those
> proxies meant losing user-needed features.
>
> Do you trust squid to only pass "CLEAN" data back to apache?
I agree. It's a very common misconception that simply putting a service
behind a revserse proxy makes it "safe" because it's "not directly
accessible". That's BS. Even if the TCP connection isn't going
directly to it, the same HTTP request (and payload) are, so any
application-layer attack will still succeed beautifully.
Having said that, there are some filtering proxies that monitor very
strictly: truncate overly-long strings, only pass "safe" requests (i.e.
not TRACK, not TRACE, etc), kill deep recursion (../../../../bin/sh),
drop requests with known-bad payload (GET /MSADC/root.exe?/c+dir), etc
but most of those are commercial products. Vanilla Squid is not one of
them.
--
Brian Keefer, CISSP
Systems Engineer
CipherTrust Inc, www.CipherTrust.com