OUTPUT DNAT AND FILTERING - scenario

Good morning to all.

These days i was thinking about this network scenario:


BROWSER WEB --> PROXY WEB --> INTERNET

1st scenario:

Suppose that the user wants to block connections towards the
web site
x.y.z.w:80

and that the local nat is setup to redirect automatically
all connections
to the port 80 towards the proxy_address:8080

iptables -t nat -A OUTPUT -j DNAT -p tcp --to PROXY_IP:8080

and the user wants to block the site x.y.z.w:80:

iptables -t filter -A OUTPUT -d x.y.z.w:80 -j DROP

This does not really block the traffic towards the
x.y.z.w:80 service
because the FILTER is applied AFTER the address
translation.

Instead the rule

iptables -t filter -A OUTPUT -d PROXY_IP:8080 -j DROP

blocks the traffic towards the proxy web, demonstrating that
the
filter is applied
AFTER the DNAT translation.

I was wondering the reason why this kind of implementation:
while it
could be useful
to drop the traffic towards some specific site/machine also
if behind
a web proxy,
on the other side a workstation administrator would normally
never insert a DNAT
OUTPUT rule to redirect connections to another address and
at the same time
want to block the traffic in that new direction...

Another observation is the following.
If FILTERING was done BEFORE the OUTPUT DNAT an
administrator could

1. block outgoing traffic towards a specific undesired
address;
2. force each connection towards port 80 to be redirected to
PROXY:8080
    with an OUTPUT DNAT rule
3. Guarantee that the unwanted connection be blocked
inserting a DROP rule
    in OUTPUT chain towards the PROXY_IP:8080
    (i.e. one cannot tell his browser web to contact the
proxy
directly to bypass
    the OUTPUT filter... since the check would be done
BEFORE the OUTPUT DNAT)

Finally, my question is very simple:
why doues iptables apply the FILTER rules AFTER the OUTPUT
DNAT and not
before, when the packet still has the original destination
address?

Thanks a lot for any answer.

Giacomo Strangolino, Italy.







-- 
Giacomo S.
http://www.giacomos.it

- - - - - - - - - - - - - - - - - - - - - -

IPFIREwall (http://www.giacomos.it/
ipfire) viene presentato
all'Universita` degli Studi di Udine, il 28 ottobre, in
occasione del
Linux Day 2006:
http://iglu.cc.uniud
.it/linuxday

- - - - - - - - - - - - - - - - - - - - - -

 . ''  `.
:   :'    :
 `.  ` '
    `- Debian GNU/Linux -- The power of freedom
        http://www.debian.org

ons 2007-02-21 klockan 11:55 +0100 skrev Giacomo:

> Finally, my question is very simple:
> why doues iptables apply the FILTER rules AFTER the
OUTPUT DNAT and not
> before, when the packet still has the original
destination address?

Because this is the way iptables is designed.

Simplified packet flow:

mangle -> nat DNAT -> [routing] -> filter -> nat
SNAT -> mangle

To deal with this cleanly within the filter table there is
the conntrack
match allowing you to filter based on connection details
rather than the
packet details.

Regards
Henrik

On Feb 23 2007 01:01, Henrik Nordstrom wrote:
>ons 2007-02-21 klockan 11:55 +0100 skrev Giacomo:
>
>> Finally, my question is very simple:
>> why doues iptables apply the FILTER rules AFTER the
OUTPUT DNAT and not
>> before, when the packet still has the original
destination address?

Why would you need to? If you want to match on the original
addresses use
 -m conntrack --ctorigsrc or --ctorigdst

>Because this is the way iptables is designed.
>
>Simplified packet flow:
>
>mangle -> nat DNAT -> [routing] -> filter ->
nat SNAT -> mangle
>
>To deal with this cleanly within the filter table there
is the conntrack
>match allowing you to filter based on connection details
rather than the
>packet details.
>
>Regards
>Henrik
>

Jan
-- 
ft: http://freshmeat.
net/p/chaostables/