[help] modern iptables rule for transproxy

[help] modern iptables rule for transproxy

[Peter T. Breuer]

I'd be much obliged if somebody could give me a modern iptables
equivalent for this ipchains rule

   ipchains -A input -p tcp -d 0.0.0.0/0 80 -j REDIRECT 8081

which is intended to redirect OUTGOING packets with port 80 as
destination to port 8081 on localhost, where I have tproxy sitting
waiting to talk to the LAN web proxy and cache.

The tproxy man page doesn't give anything other than ipfw (freebsd)
or ipfwadm or ipchains (or ipnat, whatever that is) rules, but then it
was written in 2000. Perhaps the man page could be updated, with a
suitable note of thanks, when we know what to put in it!

Thanks in advance!

Peter (ptb@cs.bham.ac.uk, ptb@inv.it.uc3m.es)

Re: [help] modern iptables rule for transproxy

[Amos Jeffries]

Peter T. Breuer wrote:
> I'd be much obliged if somebody could give me a modern iptables
> equivalent for this ipchains rule
> 
>    ipchains -A input -p tcp -d 0.0.0.0/0 80 -j REDIRECT 8081

My auto-generated FW has this (with suitable replacements):

iptables -t nat -A PREROUTING -i $LOCAL_IFACE -p tcp -s ! $PROXY_BOX 
--dport 80 -j REDIRECT --to-ports 8081

> 
> which is intended to redirect OUTGOING packets with port 80 as
> destination to port 8081 on localhost, where I have tproxy sitting
> waiting to talk to the LAN web proxy and cache.
> 
> The tproxy man page doesn't give anything other than ipfw (freebsd)
> or ipfwadm or ipchains (or ipnat, whatever that is) rules, but then it
> was written in 2000. Perhaps the man page could be updated, with a
> suitable note of thanks, when we know what to put in it!
> 
> Thanks in advance!
> 
> Peter (ptb@cs.bham.ac.uk, ptb@inv.it.uc3m.es)
> 

Amos
-- 
Please use Squid 2.6STABLE17 or 3.0STABLE1.
There are serious security advisories out on all earlier releases.

Re: [help] modern iptables rule for transproxy

[Peter T. Breuer]

Amos Jeffries wrote:
> Peter T. Breuer wrote:
> > I'd be much obliged if somebody could give me a modern iptables
> > equivalent for this ipchains rule
> > 
> >    ipchains -A input -p tcp -d 0.0.0.0/0 80 -j REDIRECT 8081
> 
> My auto-generated FW has this (with suitable replacements):
> 
> iptables -t nat -A PREROUTING -i $LOCAL_IFACE -p tcp -s ! $PROXY_BOX \
> --dport 80 -j REDIRECT --to-ports 8081

Yes, thanks. I've been trying variants on that for some time, with no
success. Stracing the tproxy daemon on port 8081 shows no sign of
activity at all when I do a

   telnet news.bbc.co.uk 80

for example. Is there a canonical way to debug iptables? I'm sure there
must be. tcpdump shows nothing on port 8081 on any interface I can think
of, but the telnet news.bbc.co.uk 80 gets through! It must be avoiding
the REDIRECT somehow.


The tproxy is clearly bound to port 8081

   bind(4, {sa_family=AF_INET, sin_port=htons(8081), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
   listen(4, 128)                          = 0

and is stuck in an accept.

iptables --t nat -L shows

  Chain PREROUTING (policy ACCEPT)
  target     prot opt source               destination
  REDIRECT   tcp  -- !<proxyhost>          anywhere            tcp dpt:www redir ports 8081

and nothing else. The builtins' rules (INPUT, etc.) are all empty.

When I try and talk to port 80 on a distant machine, I ought to be making a
socket which is bound to it with a high local port number. I can see net
traffic from distant port 80s to high ports on my machine with tcpdump,
but no sign of anything stirring on port 8081.


Peter

Re: [help] modern iptables rule for transproxy

[Gonzalo Arana]

On Jan 12, 2008 8:59 AM, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> Amos Jeffries wrote:
> > Peter T. Breuer wrote:
> > > I'd be much obliged if somebody could give me a modern iptables
> > > equivalent for this ipchains rule
> > >
> > >    ipchains -A input -p tcp -d 0.0.0.0/0 80 -j REDIRECT 8081
> >
> > My auto-generated FW has this (with suitable replacements):
> >
> > iptables -t nat -A PREROUTING -i $LOCAL_IFACE -p tcp -s ! $PROXY_BOX \
> > --dport 80 -j REDIRECT --to-ports 8081
>
> Yes, thanks. I've been trying variants on that for some time, with no
> success. Stracing the tproxy daemon on port 8081 shows no sign of
> activity at all when I do a
>
>    telnet news.bbc.co.uk 80
>
> for example. Is there a canonical way to debug iptables? I'm sure there
> must be. tcpdump shows nothing on port 8081 on any interface I can think
> of, but the telnet news.bbc.co.uk 80 gets through! It must be avoiding
> the REDIRECT somehow.
>
>
> The tproxy is clearly bound to port 8081
>
>    bind(4, {sa_family=AF_INET, sin_port=htons(8081), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
>    listen(4, 128)                          = 0
>
> and is stuck in an accept.
>
> iptables --t nat -L shows
>
>   Chain PREROUTING (policy ACCEPT)
>   target     prot opt source               destination
>   REDIRECT   tcp  -- !<proxyhost>          anywhere            tcp dpt:www redir ports 8081
>
> and nothing else. The builtins' rules (INPUT, etc.) are all empty.
>
> When I try and talk to port 80 on a distant machine, I ought to be making a
> socket which is bound to it with a high local port number. I can see net
> traffic from distant port 80s to high ports on my machine with tcpdump,
> but no sign of anything stirring on port 8081.

Perhaps your are running 'telnet news.bbc.co.uk 80' on the same box as
tproxy is running.  If that's the case, telnet's connection may be using
<proxyhost> as source IP address.

HTH,

--

Gonzalo A. Arana

Re: [help] modern iptables rule for transproxy

[James Lay]

On 1/12/08 3:59 AM, "Peter T. Breuer" <ptb@inv.it.uc3m.es> wrote:

> Amos Jeffries wrote:
>> Peter T. Breuer wrote:
>>> I'd be much obliged if somebody could give me a modern iptables
>>> equivalent for this ipchains rule
>>> 
>>>    ipchains -A input -p tcp -d 0.0.0.0/0 80 -j REDIRECT 8081
>> 
>> My auto-generated FW has this (with suitable replacements):
>> 
>> iptables -t nat -A PREROUTING -i $LOCAL_IFACE -p tcp -s ! $PROXY_BOX \
>> --dport 80 -j REDIRECT --to-ports 8081
> 
> Yes, thanks. I've been trying variants on that for some time, with no
> success. Stracing the tproxy daemon on port 8081 shows no sign of
> activity at all when I do a
> 
>    telnet news.bbc.co.uk 80
> 
> for example. Is there a canonical way to debug iptables? I'm sure there
> must be. tcpdump shows nothing on port 8081 on any interface I can think
> of, but the telnet news.bbc.co.uk 80 gets through! It must be avoiding
> the REDIRECT somehow.
> 
> 
> The tproxy is clearly bound to port 8081
> 
>    bind(4, {sa_family=AF_INET, sin_port=htons(8081),
> sin_addr=inet_addr("0.0.0.0")}, 16) = 0
>    listen(4, 128)                          = 0
> 
> and is stuck in an accept.
> 
> iptables --t nat -L shows
> 
>   Chain PREROUTING (policy ACCEPT)
>   target     prot opt source               destination
>   REDIRECT   tcp  -- !<proxyhost>          anywhere            tcp dpt:www
> redir ports 8081
> 
> and nothing else. The builtins' rules (INPUT, etc.) are all empty.
> 
> When I try and talk to port 80 on a distant machine, I ought to be making a
> socket which is bound to it with a high local port number. I can see net
> traffic from distant port 80s to high ports on my machine with tcpdump,
> but no sign of anything stirring on port 8081.

Bridging?

$IPTABLES -t nat -I PREROUTING -m physdev --physdev-in $INTIF -p tcp --dport
80 -j REDIRECT --to-ports 3128

James

Re: [help] modern iptables rule for transproxy

[Peter T. Breuer]

"Gonzalo Arana" wrote:
> On Jan 12, 2008 8:59 AM, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
> > > >    ipchains -A input -p tcp -d 0.0.0.0/0 80 -j REDIRECT 8081

> > > iptables -t nat -A PREROUTING -i $LOCAL_IFACE -p tcp -s ! $PROXY_BOX \
> > > --dport 80 -j REDIRECT --to-ports 8081
> >
> > Yes, thanks. I've been trying variants on that for some time, with no
> > success.

> >   Chain PREROUTING (policy ACCEPT)
> >   target     prot opt source               destination
> >   REDIRECT   tcp  -- !<proxyhost>          anywhere            tcp dpt:www redir ports 8081


> Perhaps your are running 'telnet news.bbc.co.uk 80' on the same box as
> tproxy is running. 

Yes, indeed, that's the whole idea, and the objective, and the problem.
There's no "perhaps" in it! That's the problem description. How to get
outgoing http requests to distant port 80s to be redirected to a proxy
daemon sitting on port 8081 of the LOCAL machine instead.


> If that's the case, telnet's connection may be using
> <proxyhost> as source IP address.

What would be bad about that? And if it is bad, what would one do about
it? I'm puzzled ...

Hmm ...  Why would it be so?  - why should telnet decide to set the
source address on its outgoing packets to that of a distant machine? It
should set the source packet address by looking up the local hostname
(-i), if it does it at all.  Or why should linux decide to do that on
behalf of telnet?  It should set the source address to that of the
outgoing interface.  The redirect rule moves packets that are leaving
to port 80 (on distant machine) via eth0 over to local port 8081
on localhost instead.  That's what the redirect target does:

iptables(8):

   REDIRECT
          This target is only valid in the nat table, in the PREROUTING
          and OUT- PUT chains, and user-defined chains which are only
          called from those chains.  It redirects the packet to the
          machine itself by changing the destination IP to the primary
          ^^^^^^^^^^^^^^^
          address of the incoming interface (locally-generated packets
          are mapped to the 127.0.0.1 address).  It takes one option:

Now, it's in the nat table, so I presume some port or address mangling
goes on.  The man page doesn't say exactly what.  I would suppose
however that a listening socket on local port 8081 which is established
AFTER the rule is put in place would get packets destined at distant
port 80s, and I should see some kind of activity as they are received.

But I don't.

As far as the man page does say, the change that is made by the rule is
that the packet destination address:80 is changed to the address:8081
bound to eth0 locally.  That's what it says.  There can't be a loop
because 8081 != 80.

If I telnet to localhost 8081 I get to talk to the waiting tproxy
daemon. So there's no problem about that. It even works! get http:foo/
HTTP/1.0 works as a command - the tproxy daemon proxies it onward.

What I don't do is get through to the tproxy daemon sitting on localhost
8081 when I telnet out to a distant host on its port 80. I don't know
why. How does one debug iptables?!!!


Thanks for any advice!

Peter

(ps .. please cc: ptb@cs.bham.ac.uk on the reply - I'm not subscribed
directly and news is firewalled - that's why I need proxies!).

Re: [help] modern iptables rule for transproxy

[Philip Craig]

Peter T. Breuer wrote:
> "Gonzalo Arana" wrote:
>> On Jan 12, 2008 8:59 AM, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
>>>>>    ipchains -A input -p tcp -d 0.0.0.0/0 80 -j REDIRECT 8081
> 
>>>> iptables -t nat -A PREROUTING -i $LOCAL_IFACE -p tcp -s ! $PROXY_BOX \
>>>> --dport 80 -j REDIRECT --to-ports 8081
>>> Yes, thanks. I've been trying variants on that for some time, with no
>>> success.
> 
>>>   Chain PREROUTING (policy ACCEPT)
>>>   target     prot opt source               destination
>>>   REDIRECT   tcp  -- !<proxyhost>          anywhere            tcp dpt:www redir ports 8081
> 
> 
>> Perhaps your are running 'telnet news.bbc.co.uk 80' on the same box as
>> tproxy is running. 
> 
> Yes, indeed, that's the whole idea, and the objective, and the problem.
> There's no "perhaps" in it! That's the problem description. How to get
> outgoing http requests to distant port 80s to be redirected to a proxy
> daemon sitting on port 8081 of the LOCAL machine instead.

Then you need the rule in the OUTPUT chain. PREROUTING only sees forwarded
packets.  The problem with this though is that you need some way to stop
connections from the proxy being redirected too.  Maybe you can use the
owner match to specify the uid of the proxy process.  From a quick google,
there are some example rules for tor that do this:
http://wiki.noreply.org/noreply/TheOnionRouter/TransparentProxy
(You want local redirection, not middlebox.)

Note that the ipchains rule you gave is only for forwarded traffic too.
I don't recall whether ipchains supported local redirection.

>> If that's the case, telnet's connection may be using
>> <proxyhost> as source IP address.
> 
> What would be bad about that? And if it is bad, what would one do about
> it? I'm puzzled ...

Because the '-s ! $PROXY_BOX' means the rule will not match packets
that have proxyhost as the source IP address.

> What I don't do is get through to the tproxy daemon sitting on localhost
> 8081 when I telnet out to a distant host on its port 80. I don't know
> why. How does one debug iptables?!!!

Use 'iptables -t nat -L -n' and look at the packet counters to see which
rules are being matched.  (And if the policy counters go up then no
rules were matched.)

Re: [help] modern iptables rule for transproxy

[Peter T. Breuer]

Philip Craig wrote:
> [ptb]
> > There's no "perhaps" in it! That's the problem description. How to get
> > outgoing http requests to distant port 80s to be redirected to a proxy
> > daemon sitting on port 8081 of the LOCAL machine instead.
> 
> Then you need the rule in the OUTPUT chain. PREROUTING only sees forwarded

So PREROUTING = forwarding!  I seeeeee.  Not "before any routing takes
place", as one might naively have supposed from the name :).

Yes, that does it. The following single rule does the job perfectly:

  iptables -t nat -I OUTPUT -p tcp --dport 80 -j REDIRECT --to-port 8081

Thanks!

> packets.  The problem with this though is that you need some way to stop
> connections from the proxy being redirected too. 

The proxy is talking to a remote cache on remote port 3128, so that's not
necessary. So all I need to reroute all http round the firewall is the
following "up" rules in /etc/network/interfaces:

  up start-stop-daemon --start -exec /usr/sbin/tproxy -s 8081 -r tproxy $WEBCACHE 3128 
  up iptables -t nat -I OUTPUT -p tcp --dport 80 -j REDIRECT --to-port 8081 


> Maybe you can use the
> owner match to specify the uid of the proxy process.  From a quick google,

It looks like that works fine too, but it's not required (by definition,
the proxy on local port 8081 can't be emitting to port 80s or it
wouldn't be able to get through the router's firewall either - port 80
outgoing is firewalled but good at the router, and one has to use a
local http proxy/cache to get through; my requirement was to switch my
laptop system universally to using that routing for http packets when I
bring my laptop onto that network).

> there are some example rules for tor that do this:
> http://wiki.noreply.org/noreply/TheOnionRouter/TransparentProxy
> (You want local redirection, not middlebox.)

Thanks!

> Note that the ipchains rule you gave is only for forwarded traffic too.

It used to work.

> I don't recall whether ipchains supported local redirection.

It did. There are notes around saying that that was lost with the change
to iptables. I forget where I saw them now.

> >> If that's the case, telnet's connection may be using
> >> <proxyhost> as source IP address.
> > 
> > What would be bad about that? And if it is bad, what would one do about
> > it? I'm puzzled ...
> 
> Because the '-s ! $PROXY_BOX' means the rule will not match packets
> that have proxyhost as the source IP address.

So telnet's packets would not be redirected as desired. But then there
is no reason why telnet should choose to set src address on outgoing
packets to some machine that it doesn't even know about, is there?


> > 8081 when I telnet out to a distant host on its port 80. I don't know
> > why. How does one debug iptables?!!!
> 
> Use 'iptables -t nat -L -n' and look at the packet counters to see which

It seems I don't have any. I guess that has to be compiled into the
kernel or modules somewhere.

> rules are being matched.  (And if the policy counters go up then no
> rules were matched.)

Thanks!

I was trying things such as

  iptables -t nat -I PREROUTING --dport 80 -j LOG --log-level 4

(I have no idea what number to put for loglevel) without seeing anything
in dmesg. That led me to suspect that packets were not going through
PREROUTING at all. I was too nervous to try using OUTPUT for fear of
provoking a loop .. packets go to output, are redirected, go to output,
are redirected ...

Peter

Re: [help] modern iptables rule for transproxy

[Antonio Augusto (Mancha)]

[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]

(forgot to cc it to the list)

On Jan 18, 2008 3:07 PM, Peter T. Breuer <ptb@inv.it.uc3m.es> wrote:
>
> Philip Craig wrote:
> > [ptb]
> > > There's no "perhaps" in it! That's the problem description. How to get
> > > outgoing http requests to distant port 80s to be redirected to a proxy
> > > daemon sitting on port 8081 of the LOCAL machine instead.
> >
> > Then you need the rule in the OUTPUT chain. PREROUTING only sees forwarded
>
> So PREROUTING = forwarding!  I seeeeee.  Not "before any routing takes
> place", as one might naively have supposed from the name :).
>

Not really... PRETOURINTG occurs before any routing takes place, and
its NOT the same as FORWARD.
 The reason you have to use OUTPUT there is because you want to be
able to redirect connections originating from the localhost. Packets
COMMING from localhost DON'T pass throu the PREROUTING chain.

Attached you will find a figure that i did that represents how packets
traverse the netfilter hooks/chains.
Its in Portuguese, but the chains are in english.
In the figure the two circles the the top are input and output
interfaces (from left to right).
The circle at the bottom is a local process that generates packets,
and the one in the middle represents the routing decision.

Note that packets coming from the localhost (like you said you were
doing), never pass through the prerouting chain.

Hops this made things clearer for you :)

-- 
Informação & Segurança - Informações para sua segurança na rede.
http://info-seg.blogspot.com

[-- Attachment #2: netfilter_flow.jpg --]
[-- Type: image/jpeg, Size: 41164 bytes --]

Re: [help] modern iptables rule for transproxy

[Philip Craig]

Peter T. Breuer wrote:
> So PREROUTING = forwarding!  I seeeeee.  Not "before any routing takes
> place", as one might naively have supposed from the name :).

Actually, forwarded was the wrong term.  PREROUTING only sees externally
originated packets (which includes both forwarded and packets destined for
the local machine).  It is before any routing.  OUTPUT only sees locally
originated packets, and is also before any routing too (in theory,
implementation differs ;-).  External and local packets have different
entry points into the stack, so no routing is needed to distinguish
between them.

>> Because the '-s ! $PROXY_BOX' means the rule will not match packets
>> that have proxyhost as the source IP address.
> 
> So telnet's packets would not be redirected as desired. But then there
> is no reason why telnet should choose to set src address on outgoing
> packets to some machine that it doesn't even know about, is there?

Hrmm, I thought this talking about when you were running telnet on the
same host as the proxy, so its quite likely it will use the same address
as the proxy.

>> Use 'iptables -t nat -L -n' and look at the packet counters to see which
> 
> It seems I don't have any. I guess that has to be compiled into the
> kernel or modules somewhere.

Sorry, typo there.. it was meant to be 'iptables -t nat -L -v'

> (I have no idea what number to put for loglevel) without seeing anything

You can use the level names instead of numbers (eg info, err)