<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div>On 6 Dec 2017, at 19:13, Scott Bennett <<a href="mailto:bennett@sdf.org">bennett@sdf.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>null <<a href="mailto:null@omuravpn.com">null@omuravpn.com</a>> wrote:</span><br><span></span><br><blockquote type="cite"><span>@ x9p:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span># netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>-F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c | sort</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>| egrep -v ' 1 | 2 | 3 '</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>with this information in hand, double the max of it (mine was 10</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>connections from 188.214.30.0/24):</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> 10 188.214.30</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>--connlimit-mask 24 -j REJECT --reject-with tcp-reset</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Thank you! This was extremely helpful.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>In our case we found a handful of IPs that had *thousands* of</span><br></blockquote><blockquote type="cite"><span>concurrent connections on several of our relays. The offending IPs</span><br></blockquote><blockquote type="cite"><span>were not in the consensus. After restarting the Tor service, these</span><br></blockquote><blockquote type="cite"><span>suspect connections come back rapidly, again across several of our</span><br></blockquote><blockquote type="cite"><span>relays. Since our relays are all in the same declared family, it is</span><br></blockquote><blockquote type="cite"><span>very difficult to see how this traffic is legitimate. If it's valid</span><br></blockquote><span></span><br><span> But it could be legitimate. As has been discussed here previously,</span><br><span>they may be connections from a relay that actually is in the consensus,</span><br><span>but either a) uses an OutboundBindAddress or b) is on a LAN that has</span><br><span>multiple connections to the Internet.</span></div></blockquote><div><br></div><div>Relays try very hard to have at most one connection to each other relay.</div><div>(And only two relays are allowed in the consensus per IPv4 address.)</div><div>Clients try to make one connection to one or two guards.</div><div><br></div><div>So it's far more likely to be a collection of Tor clients in a network with</div><div>only a few public IPv4 addresses. (There are entire countries and large</div><div>networks that only have a few allocated IPv4 addresses.)</div><div><br></div><div>Or, it might be a bug in Tor, a misconfiguration, or a denial of service</div><div>attack. We'd like to know more, so we can find out and fix it.</div><br><blockquote type="cite"><div>(Snip)<br><span> A script similar to the one used to reveal and make available the</span><br><span>otherwise unidentified source IP addresses of exits could be run by the</span><br><span>project to gather the hidden addresses of currently running relays, and</span><br><span>a list of such addresses could be made available on a compromise basis,</span><br><span>e.g., by having a relay at the project that would serve those lists only</span><br><span>over tunneled directory connections *from relays*, were it not for obstinacy.</span><br><span>Such a list could then be included into our packet filters' "free pass"</span><br><span>lists without putting the list up on the project's web site like the exit</span><br><span>list is.</span></div></blockquote><div><br></div><div>Outbound addresses aren't secret, because they are used for connections.</div><div><br></div><div>Anyone is free to volunteer to create and maintain a list of outbound</div><div>relay addresses. It is technically feasible: it requires a few thousand Tor</div><div>connections per day, one via each relay, to a relay that reports the</div><div>remote address of each inbound relay connection.</div><div><br></div><div>It just needs to be done safely, in a way that doesn't collect client</div><div>addresses, and avoids attaching a timestamp or order to relay connections.</div><div><br></div><blockquote type="cite"><div><span>A torrc option to fetch the list whenever updates were available</span><br><span>could default to not fetching the list, so relays whose operators who do</span><br><span>not use packet filter defenses would not automatically fetch the hidden</span><br><span>address list of non-exit relays.</span><br></div></blockquote><div><br></div><div><span style="background-color: rgba(255, 255, 255, 0);">If someone created a list, and showed that it had value to other relay</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">operators, then it might gain support, and be supported by Tor</span><span style="background-color: rgba(255, 255, 255, 0);">,</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">just like other features have:</span></div><div><br></div><div><span style="background-color: rgba(255, 255, 255, 0);">There is an exit_addresses field for relays in Onionoo and Relay Search</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">that gives the outbound exit addresses of every exit (when they differ</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">from the relay address). It gathers addresses using exitmap. (Rather</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">than relays self-reporting, which is unreliable.)</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">There is also a torrc option that has the side effect of making every</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">address on the machine public, even unused addresses, because it</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">blocks them in the exit policy. (ExitPolicyRejectLocalInterfaces, off by</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">default.)</span></div></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Here's how someone could work on this feature:</span></div><div><br></div><div>Create a scanner, publish a list, and show that it has value.</div><div>Or start with a proposal, ask for advice, then create the scanner.</div><div><br></div><div>Try for something independent of Tor, like exitmap, because it will</div><div>be more accurate. (Tor doesn't always know what its outbound address</div><div>is.)</div><div><br></div><div>And try to have list downloads rely on existing Tor features, like onion</div><div>services. They'll be faster to deploy that way.</div><div><br></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">Here's a description of the proposal process:</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><a href="https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt" style="background-color: rgba(255, 255, 255, 0);"><font color="#000000">https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt</font></a></div></div><br><blockquote type="cite"><div><blockquote type="cite"><span>Tor clients, they are behaving very strangely, and in either case we</span><br></blockquote><blockquote type="cite"><span>need to limit their impact. As such we've implemented connlimits by</span><br></blockquote><blockquote type="cite"><span>/24 as suggested (with a much higher limit to err on the side of not</span><br></blockquote><blockquote type="cite"><span>rejecting valid traffic). We can already see that this has improved</span><br></blockquote><blockquote type="cite"><span>our situation.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span> And it will likely get you roundly denounced by tor project members</span><br><span>and certain other individuals on this list. :-(</span></div></blockquote><div><br></div><div>I sketched a proposal like this in another thread just a few days ago.</div><div>I'm happy to work with others to include inbound or outbound connection</div><div>limits in the draft proposal. (My initial proposal had outbound circuit and</div><div>stream limits.)</div><br><blockquote type="cite"><div><span>You will also see your</span><br><span>Fast and HSDir flags come and go at random, depending upon how many</span><br><span>authorities creating testing circuits to reach and test your node(s)</span><br><span>go through a node that used a hidden outbound address as the source</span><br><span>address that fails your filter to connect to your node.</span><br></div></blockquote><div><br></div><div>If you set the connection limit at or above 512 connections per /24, it will</div><div>be impossible for well-behaved consensus relays to go above the limit:</div><div><br></div><div>2 relays per IPv4 * 256 IPv4 addresses per /24 = 512 connections</div><div><br></div><div>Or you could check how many relays are in the most popular /24, and use</div><div>that to work out a limit.</div><br><div><blockquote type="cite">(Snip)</blockquote></div><br><blockquote type="cite"><div><blockquote type="cite"><span>@ Scott Bennett:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite">(Snip)</blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Nonetheless, we're not opposed to disabling HidServDirectoryV2 to rule</span><br></blockquote><blockquote type="cite"><span>it out. However it appears that option is deprecated (on 0.3.1.9).</span><br></blockquote><blockquote type="cite"><span>Enabling it causes this in the log:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> [WARN] Skipping obsolete configuration option 'HidServDirectoryV2'</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It's also no longer listed in the Tor manual</span><br></blockquote><blockquote type="cite"><span>(<a href="https://www.torproject.org/docs/tor-manual.html.en">https://www.torproject.org/docs/tor-manual.html.en</a>). It looks like we</span><br></blockquote><blockquote type="cite"><span>might be able to achieve the same effect with something like this</span><br></blockquote><span></span><br><span> Sigh. My apologies. You are indeed correct on this matter. It had</span><br><span>slipped my mind that tor no longer is distributed with a man page.</span><br></div></blockquote><div><br></div><div>Tor source is distributed with an asciidoc man page.</div><div><br></div><div>It might not be on your system because the packager left it out, or left</div><div>out asciidoc as a build dependency.</div><br><blockquote type="cite"><div><span></span><blockquote type="cite">(Snip)</blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Anyone have any info on why HidServDirectoryV2 is consider obsolete?</span><br></blockquote><span></span><br><span> Not entirely sure, but I *think* I remember reading somewhere that</span><br><span>HS v2 is no longer preferred and has been superseded by HS v3. I hope</span><br><span>someone will confirm/correct this recollection.</span><br></div></blockquote><div><br></div><div>It was removed in 0.2.7 along with the authority option</div><div>VoteOnHidServDirectoriesV2. There's not much information on the ticket:</div><div><br></div><div><a href="https://trac.torproject.org/projects/tor/ticket/16543">https://trac.torproject.org/projects/tor/ticket/16543</a></div><div><br></div><div>In general, we try to remove options that very few people use, because it</div><div>reduces the cost of testing and maintaining Tor.</div><div><br></div><blockquote type="cite"><div><font color="#00afcd">(Snip)</font></div></blockquote><br><div>T</div></body></html>