Re: [tor-relays] why are some exit IPs missing from Exit IP DB?

On 11 Oct 2015, at 13:47, starlight.2015q3@xxxxxxxxxxx wrote:

At 13:29 10/8/2015 -0400, starlight.2015q3@xxxxxxxxxxx wrote:
Occasionally I run into a relay such as

Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4
OR ip 178.33.157.6
exit ip 31.7.58.37

Where the egress/exit IP source address is
not found in the Exit DB, shows up negative
on ExoneraTor. TorCheck complains. . .

Is it perhaps because the exit policy
for the above and similar relays does
not contain a "reject" line for the
alternate IP, as in

reject 178.33.157.6:* # present
reject 31.7.58.37:* # missing

The OR-address "reject" is automatic
and I'm guessing that if one uses
OutboundBindAddress in the config that
would also be included.

Unfortunately not (see below).

But if 'torrc' does not contain the
alternate interface IP(s) does the
'tor' daemon recognize alternate
egress source interfaces or does
one have to configure the "reject"
lines manually?

As of 0.2.7.3, tor blocks the following addresses by default (ExitPolicyRejectPrivate):

* the configured or autodiscovered IPv4 address (Address or resolve_my_address())

* the configured IPv6 address (first IPv6 ORPort entry)

* the publicly routable IPv4 or IPv6 address(es) of every interface on the server, if available.

(Local and private addresses are already blocked by ExitPolicyRejectPrivate.)

Itâs my opinion that this covers the majority of use cases for multihomed, multi-IP, or different internal/external address (that is, NAT or similar) relays.

This change was tracked and merged as #17027: policies_parse_exit_policy_internal should block all IPv4 and IPv6 local

addresses.

https://trac.torproject.org/projects/tor/ticket/17027

This change is being considered for backport to 0.2.6 as a security fix.

The behaviour as of 0.2.7.2-alpha and below was to only block the configured or autodiscovered IPv4 address.

However, a look through the Tor manual page suggests the following additional candidate addresses:

* OutboundBindAddress

* ControlPort / ControlListenAddress

* SOCKSPort / SOCKSListenAddress

* TransPort / TransListenAddress

* NATDPort / NATDListenAddress

* DNSPort / DNSListenAddress

* ORPort / ORListenAddress (IPv4 entries or subsequent IPv6 entries)

* DirPort / DirListenAddress

We could block these by looking at OutboundBindAddressIPv4_/OutboundBindAddressIPv6_ and get_configured_ports().

(Iâve added a note about these changes to issue #17027.)

Iâd also consider the IPv6 address (if available) from Address (if an IPv6 literal [this doesnât work at present] or DNS name), but Address isnât used by Tor to find IPv6 addresses, so Iâm not sure how useful this is.

Have not come across any documentation
on this.

Please see the Tor 0.2.7.3 manual page under âExitPolicyRejectPrivateâ (the version on the Tor website is too old) or Trac bug #17027.

https://trac.torproject.org/projects/tor/ticket/17027

Would it be considered a
bug in the Tor daemon that it does
not gather multi-home source IPs
for "reject" in the exit policy?

Yes (see above).

If a relay is missing an egress IP
"reject" line and has no contact,
would that be a serious misconfiguration
that indicates BadExit should be
assigned?

There may be valid reasons why an operation explicitly wants to allow Tor users to exit to their own server.

In this case, they would have to make sure that local services donât assume that local connections are trusted.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail