NAT not for filtering - problem

NAT not for filtering - problem

[tengaman]

Hello,

recently my Debian system promted this message:
>The "nat" table is not intended for filtering, hence the use of DROP is
>deprecated and will permanently be disabled in the next iptables
>release. Please adjust your scripts.

What im doing in the nat-table is redirecting the traffic to the
tor-programm (www.torproject.org) listening on local port 9040 to form a transparent proxy.
Now, the DROP target makes sure that non-redirected and thus "non-anonymized" packages are
impossible.

To distinguish anonymized traffic from normal traffic I do have a
special user: 'tor-user' (-m -uid-owner tor-user).
The tor programm itself is run by the user 'debian-tor'.

The Problem:
--uid-owner debian-tor does not match the redirected traffic.
Meaning although the traffic is processed by a process owned by a
different user --uid-owner still maches the orignal user of the data.
My sytem seems to lack the --cmd-owner match, was this cut out?

I hope you have any idea.

Sebastian R.

Re: NAT not for filtering - problem

[tengaman]

[-- Attachment #1: mail.1 --]
[-- Type: text/plain, Size: 1708 bytes --]

Hello again,
being more graphic this time:

>--uid-owner debian-tor does not match the redirected traffic.
>Meaning although the traffic is processed by a process owned by a
>different user --uid-owner still maches the orignal user of the data.

I figured out myself, that can't be, because:
After redirecting the traffic the packages are used by the
tor-programm not 'piped through'!
tor generates completely new packages that should be matched by
"--uid-owner 'user of the daemon process'" - am I right?

Original Setup: all tables empty with POLICY ACCEPT
>iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner tor-user -j \
>REDIRECT --to-ports 9040

>iptables -t nat -A OUTPUT -p udp -m owner \
>--uid-owner tor-user -m udp --dport 53 -j REDIRECT --to-ports 53

>iptables -t nat -A OUTPUT -m owner --uid-owner \
>tor-user -j DROP

The funny thing is, it isn't working: I'm able to ping a remote host
although ICMP should be dropped, why is that?
But the transparent-proxy does work!

By the way, the hole concept comes from:
https://wiki.torproject.org/noreply/TheOnionRouter/TransparentProxy?highlight=%2528transparent%2529


Ok, new idea: again all tables empty with POLICY ACCEPT

>iptables -t nat -A OUTPUT -p tcp -m owner \
>--uid-owner tor-user -j REDIRECT --to-ports 9040

>iptables -t nat -A OUTPUT -p udp -m owner \
>--uid-owner tor-user -m udp --dport 53 -j REDIRECT --to-ports 53

>iptables -t filter -A OUTPUT -m owner --uid-owner \
>debian-tor -j ACCEPT

>iptables -t filter -A OUTPUT -m owner --uid-owner \
>debian-tor -j DROP

I don't get any connection with this setup.

I also tried to mark the traffic but - yeah - I don't understand whats
happening - any idea?


regards
Sebastian R.

Re: NAT not for filtering - problem

[tengaman]

My own pondering results in some new, hopefully clearer questions:

How does the REDIRECTed packages look like?
I mean REDIRECT can't simply change the IP-destination-field into
127.0.0.1, because the proxy wouldn't know where to relay it, would it?

Is it true that this REDIRECTed packages, whatever they look like
go through the filter-output chain before being delivered locally to the
daemon-process?

If there exists detailed documentation on this matters please give me a
hint.

regards
Sebastian R.