This question is somewhat out of my area, but let's have a go.. On 02/08/07, Jason Haar <Jason.Haar@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|