> On 11 Oct 2015, at 13:47, starlight.201...@binnacle.cx wrote: > > At 13:29 10/8/2015 -0400, starlight.201...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
