[tor-talk] tor/netfilter: packets without uid

Marsh Ray marsh at extendedsubset.com
Fri May 11 03:52:08 UTC 2012


On 05/10/2012 09:11 PM, johnmurphy323 at Safe-mail.net wrote:
> Hi List,
>
> I am trying to tweak my transparent netfilter setup (Tor Stable,
> Debian Wheezy, GNU/Linux, iptables v1.4.12.2, Kernel 3.2.0-amd64). So
> far, redirection and torification works fine. I have have several
> users, some of them have their TCP traffic forwarded to Tor, some are
> allowed to send packets directly. It works splendid.
>
> There is just one issue. About every once or twice a second there is
> a tcp packet running along my filter (that is the iptables -t filter)
> table that has no associated UID.
>
> This is what they look like:
>
> IN= OUT=eth0 SRC=192.168.178.50 DST=some-target LEN=40 TOS=0x00
> PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=50447 DPT=443 WINDOW=1002
> RES=0x00 ACK URGP=0
>
> This packet is https, most likely generated by my firefox user when I
> was browsing a website. But it gets more interesting. There are lost
> packets, even when I only use Tor. A reverse dns lookup of the target
> ip shows that these are packets send by tor to the first relay.
>
> How is it possible for a packet not to have an associated uid?
> Dropping these packets of course works, but the logging clutters my
> syslog, and after all, why is there this type of leaking in the first
> place?

I'm not a netfilter expert, but it looks this is a pure TCP ACK packet. 
With LEN=40 there's no application data in it. It may have been 
auto-generated by the kernel as a reply to the external packet and never 
tagged with a user for that reason.

Dropping them may result in retransmission. As you noticed, once or 
twice a second until there's some user tagged data going out that can 
transmit the ack.

Just a theory.

- Marsh


More information about the tor-talk mailing list