noodlet at gmail
Aug 1, 2007, 11:02 PM
Post #2 of 5
(170 views)
Permalink
|
This question is somewhat out of my area, but let's have a go..
On 02/08/07, Jason Haar <Jason.Haar [at] trimble> wrote:
> Hi there
>
> I'm making a WAF (Web Application Firewall) based around Linux/Apache
> and mod_security, and as part of the design, thought that making it a
> transparent (reverse) proxy would be a good move from a disaster
> recovery perspective (i.e. if it blew up you could just wire around it
> and the backends would still be available).
I'm a bit confused by your terminology. From what I understand a
transparent proxy is the kind which is put in front of clients by
dodgy ISPs (such as my own) to perform things like caching and
nanny-filtering, without having to properly configure a proxy in the
user's browser. As such, it lives closest to the client and knows
nothing of specific sites. This kind of proxy is a misuse of http and
not directly supported by apache (though I gather it is possible with
a series of network level hacks).
A reverse proxy OTOH sits in front of one or several origin servers
and can perform operations like load balancing, http acceleration and
security filtering. This kind of proxy is supported directly by
mod_proxy using the ProxyPass directive and friends.
There's a third kind, your common or garden forward proxy, supported
by apache using ProxyRequests and friends, but I don't think you mean
that.
Which do you mean? Any of those?
>
> Anyway, I did some quick tests with Apache (2.2.4) and found that it
> really has no transparent proxy support? I can get the iptables rules in
> place to redirect traffic meant for other servers to terminate on it -
> but Apache reads them all as connections to itself - i.e. the
> VirtualHosts don't kick in correctly.
Again I'm not sure what topography you're refering to. If it's a
reverse proxy, then yes apache should expect the request to be
directed at itself. Transparent (or interception) proxies are meant to
be hidden from the user and the server, but of course aren't because
they mask things like connection and DNS errors.
> Also, the WAF would primarily be used to protect HTTPS sites. Now I know
> "you can't transparently proxy HTTPS" is the mantra - but that's not
> quite true from what I know. I mean this would be an "official" WAF - so
> it would have copies of the server certs used on the real backends - so
> it could actually do a successful "man-in-the-middle". But again it
> relies on Apache to be able to glean information about the real
> destination IP addresses so that it could map connections through to the
> real backend server. I guess Apache would need a "VirtualListen" option...
When it comes to reverse proxying https, then yes the server needs the
certificates of the backend sites (and enough IP addresses to be able
to host them all without CN conflicts). The tricky part is deciding if
you then need to re-encypt the requests to the backends; generally
there's no point, but if your backends are expecting https requests
then you'll have to swallow that waste of cpu time.
There's also a question of how apache will know which of the backend
servers to send the request too, assuming there's a bunch of different
sites. In a normal reverse proxy situation you can use mod_rewrite to
construct the proxy url including the whole or part of the original
Host: header. However because you need to host several https sites on
a single server, you're going to need several ip/port combinations
with their own vhosts anyway, so you can use ProxyPass with the
correct host name (or, depending on how you're arranging your DNS,
using ProxyPass with the IP address of the backend along with the
ProxyPreserveHost directive set).
> I've done this successfully with Squid as a normal proxy, but I really
> need the funky features of Apache as a reverse-proxy - but I want
> transparency too...
>
> Is it doable? Thanks!
It sounds to me like your config is trying to be too clever, but then
I'm probably missing the point :-)
--
noodl
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd
|
