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

Sun Oct 11 10:29:47 UTC 2015

> On 11 Oct 2015, at 13:47, starlight.2015q3 at binnacle.cx wrote:
> 
> At 13:29 10/8/2015 -0400, starlight.2015q3 at binnacle.cx 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 <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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20151011/594bfec0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20151011/594bfec0/attachment-0001.sig>