[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Bug: improperly bound listen addresses?

Hi. I have various alias addressing on my interfaces. I mapped
everything to rfc1918 space for this note.

 inet netmask 0xffffff00 broadcast
 inet netmask 0xffffffff broadcast

I fire up a statically compiled tor in a chroot populated with the
minimum required to keep tor quiet:


I exec tor while already under a dedicated non-root user/group.
I use the following addressing options:

 -socksport   9050 -sockslistenaddress
 -controlport 9051 -controllistenaddress
 -orport  9001 -orlistenaddress
 -dirport 9030 -dirlistenaddress

Note that my packet filters have proper holes for Tor.


As you can see, the OR and DIR binds honor the requested use of the
secondary address. Yet the udp and outbound connections bind to the
primary address on the interface.

# before outboundbindaddress
tor      tor      55099    4 tcp4   *:*
tor      tor      55099    5 tcp4   *:*
tor      tor      55099    6 tcp4  *:*
tor      tor      55099    7 tcp4  *:*
tor      tor      55099    8 tcp4
tor      tor      55099   12 tcp4
tor      tor      55099    9 udp4   w.x.y.z:53
tor      tor      55099   11 stream tor[55103]:12
tor      tor      55103    9 udp4   w.x.y.z:53
tor      tor      55103   12 stream tor[55099]:11

So I added this to the config:


Now you can see that this was indeed honored as well. And we are
now left with only the udp binds to deal with. However, I can see
no configuration option to do that.

So that is missing feature #1.

# after outboundbindaddress
tor      tor      82854    4 tcp4   *:*
tor      tor      82854    5 tcp4   *:*
tor      tor      82854    6 tcp4  *:*
tor      tor      82854    7 tcp4  *:*
tor      tor      82854    8 tcp4
tor      tor      82854   12 tcp4
tor      tor      82854    9 udp4   w.x.y.z:53
tor      tor      82854   11 stream tor[82856]:12
tor      tor      82856    9 udp4   w.x.y.z:53
tor      tor      82856   12 stream tor[82854]:11


Now note that _both_before_and_after_ outboundbindaddress, Tor seems
to be confused regarding its socket allocation as noted below.
Therefore it never publishes its descriptor and I have 384kbits
still sitting useless :-) :-(

So that is bug #2.

[n] Tor v0.2.0.30 (r15956) ... (FreeBSD i386)
[n] Configuration file "/.../etc/tor/torrc" not present, using
reasonable defaults.

[n] Opening OR listener on
[n] Opening Directory listener on
[n] Opening Socks listener on
[n] Opening Control listener on

[n] Now checking whether ORPort and DirPort are reachable... (this may take up to 20 minutes
-- look for log messages indicating success)

[w] Your server ( has not managed to confirm
that its ORPort is reachable. Please check your firewalls, ports,
address, /etc/hosts file, etc.
[w] Your server ( has not managed to confirm
that its DirPort is reachable. Please check your firewalls, ports,
address, /etc/hosts file, etc.


Lastly, I think the pairing of:
-<Whatever_function>Port Port
-<Whatever_function>ListenAddress IP[:PORT]

is a bit klunky. In that the pure Port statement is required to
enable the function. But if you also want to bind it somewhere
deterministic you _also_ have to specify the Address IP. And some
functions may be useful to bind more than once in the future. So I
would perhaps see about moving to this style instead:

-<Whatever_function>ListenAddress "{IP|*|#}[:PORT]"

Where '*' means bind to all addresses. And perhaps '#' might refer
to however the current pure Port statement picks its addresses