----- Original Message ----- From: "Balazs Scheidler" <[EMAIL PROTECTED]> To: "Jean-Michel Hemstedt" <[EMAIL PROTECTED]> Sent: Tuesday, 19 March, 2002 08:50 Subject: Re: TPROXY
> On Wed, Mar 13, 2002 at 01:19:30PM +0100, Jean-Michel Hemstedt wrote: > > hello, > > > > I'm quite new to netfilter, and I would like to use/write an extension capable of > > rewriting HTTP/HTTPS requests from non-proxy aware clients to remote > > non-transparent aware proxy (the netfilter box being in the middle and acting > > as a default gw for both sides). > > > > This implies: > > - for HTTP: most HTTP requests methods (GET,POST,...) need to be rewritten > > with the full URL (taken from the non redirected ip.dst for HTTP/0.9 or from the > > 'Host' field for HTTP/1.x) > > - for HTTPS: *insert* an HTTP CONNECT transaction in the TCP stream (just > > after the TCP establishment), which means that the ip packets can't simply be > > redirected, unless playing with (cracking) the tcp.seq_num in netfilter. > > > > The first case is not a problem (kind of REDIRECT target) > > For the second case (HTTPS), I was thinking of using the ip_nonlocal_bind option, > > but I read in the kernel archives that the connect() was "broken" for non-local bind > > in 2.4.x. I would also avoid user space QUEUEing since I noticed that the throughput > > was simply divided by 2 (just for normal forwarding!). > > > > I think that your TPROXY target is well suited for the HTTPS case (terminating the tcp > > sessions of the client on the netfilter box and originating tcp session to the proxy from > > the netfilter box as if they were originating from the client, using a kind of > > *ip_nonlocal_bind* mechanism). right? > > TPROXY is not yet ready, it is lacking several important features. I posted > it on the -devel list to receive feedback. > > Both of your problems can be solved by REDIRECT, you only need two different > programs (or a single program performing both operations). Just listen on a > random port (say 50080), and redirect all traffic to this port: > > iptables -t nat -A PREROUTING -p tcp -d 0/0 --dport 80 -j REDIRECT --to-port 50080 > iptables -t nat -A PREROUTING -p tcp -d 0/0 --dport 443 -j REDIRECT --to-port 50443 > REDIRECT could work in case of collocated proxy, and only if we have control on the proxy, i.e. Apache; (btw: I'm curreltly trying to find a clean and reusable way to extend transparent HTTP mod_tprox and add HTTPS transp proxy to Apache for Linux). But I'm afraid REDIRECT doesn't fit for remote proxies which rely on the originam source ip ofthe client to perform some checks. In that case we need the 50080/50443 applications of your example to forward the modified requests to the remote proxy with the source.ip of the original client. I see 3 possible ways to do that: 1) the 50080/50443 applications use libipt and for each new client request, before doing a new connect() to the remote proxy, they create a new iptable rule doing SNAT based on the --sport they choosed for their bind(). And when the connection is released, they remove the created rule. This solution is very inefficient, and not scalable. 2) the 50080/50443 applications rely on TPROXY framework and uses nonlocal_bind. 3) ??INTERCEPT?? = REDIRECT(PREROUTING)+SNAT(OUTPUT/POSTROUTING?) i.e: A:pclient1 <> [REDIRECT--dport80] <>Bserver:50080<>Bclient:pclient2 <> [SNAT(--to A:pclient)] <> C:80 => the INTERCEPT would REDIRECT the packets from the client to the local stack and pass a 'rdmark' to the user space application retreivable via getsockopt(rdmark). Then, the application rewrites the packets and in order to forward them to the remote proxy, it creates a new client socket to the remote-proxy and uses setsockopt(rdmark) to instruct netfilter to do SNAT on the outgoing packets (OUPUT/POSTROUTING?). Netfilter uses the 'rdmark' to retreive from the redirect table the '--to' information (the source.ip before the redirect). When a packet comes back from the remote-proxy the reverse SNAT redirects the packets to the local client, which pass the packet to the local server which sends back to the original client the modified packets... (PS: I don't think the MARK target is suited for that kind of mechanism) (PPS: the user space applications would move as LKM in a second phase) do you (or anyone else) see any other way to do it? > One of your proxies will be listening on 50080 the other on 50443. The first > performing non-transparent/transparent rewrite the other CONNECT > encapsulation. > > By the way the first one is easy to do with Zorp. Its HttpProxy is able to > rewrite server-requests to proxy-requests. > > CONNECT encapsulation is not supported I'm afraid. > > > Have you received any feedback on your TPROXY target? > > not much. > I hope I'll be able to contribute, but I'll first need to better understand what are all the features of Netfilter and how they can interact between each other... In the mean time, if you have any update, i'd like to have a look at it. > > > > Have you heard of any similar HTTPS-real-transp-proxy implementations? > > Zorp supports HTTPS, but it doesn't encapsulate it into CONNECT. It simply > decrypts ongoing traffic, checks HTTP within it, and sends it on > reencrypted. But for this to work you'd need to run Zorp on your firewall > (where it was meant to run) as stated above, I don't have full control on the proxy itself, and as far as https is concerned, it must be transparently tunneled (to avoid m-i-t-m-a problems). > > > > > Have you setup a planning with Rusty/core team about related developpments? > > > > We came up with the current architecture of TPROXY at the Netfilter > Developer Workshop in November. We agreed that it should be part of linux > 2.5 sometimes when its ready. > > -- > Bazsi thanks for your help. > PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 >
