<div dir="ltr"><div>Thanks for your input, Tim.</div><div><br></div><div>You are correct that I have not taken into account the IPs which are not in the consensus.</div><div><br></div><div>My exit nodes are regularly attacked -- what caught my attention was not the fact that an extra gigabit of traffic was flowing in, but rather the way it was (<i>and still is</i>, on one node) flowing in.</div><div><br></div><div>The patterns of the traffic seem unusual, because they are precisely timed windows of traffic: 30 seconds of a about gigabit of traffic, 5 minutes (exactly 302 ± 3 seconds, that is) pause, 15 seconds of a about gigabit of traffic, 3 minutes (181 ± 1 seconds) pause, 60 seconds of a gigabit of traffic, 10 minutes (604 ± 2 seconds).</div><div><br></div><div>This went on for 8 hours on apx1, apx2 is seeing this still.</div><div><br></div><div>I'm very sure that there is a reasonable explanation for this, but I can't see the reason any client would behave like this.</div><div><br></div><div>-- Kenan</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On 22 Jul 2017, at 08:00, Matt Traudt <sirmatt at <a href="http://ksu.edu">ksu.edu</a>> wrote:<br>><br> > Now, to my observations and the post that was referred to:<br>><br> > /I clearly failed to clarify/ that the "suspicious" traffic which caught<br>> my interest was about non-Tor IPs entering the network through my exits.<br>How do you work out what a non-Tor IP is?<br>> As pastly nicely put it: /> will never be used as a guard by<br>> well-behaved tor clients./<br>Exits won't be used as long-term Guards, but they will be used as<br>Entry nodes (or receive connections that look like client connections)<br>from:<br>* clients via bridges<br>* clients with UseEntryGuards disabled, including:<br>  * Single Onion Services (to intro and rend nodes)<br>  * Tor2web (to HSDir, intro and rend nodes)<br>* clients using them as directory guards or fallback directory mirrors,<br>* bandwidth authorities,<br>* Tor relays that aren't in the consensus(es) you're using to work out<br>  what a "non-Tor IP" is,<br>* Tor relays that have an OutboundBindAddress* option, or a route, that<br>  binds to an IP address they're not advertising in their descriptor.<br>(Some of these categories might be excluded by position weights, I<br>haven't checked them all in detail.)<br>> My observations were made using a utility I built using nDPI and sysdig<br>> (kernel module).<br>><br> > That is, I have observed about a gigabit of traffic entering my exit<br>> nodes originating /from non-Tor IPs/, causing connections to be<br>> initiated to middle nodes.<br>The most likely scenarios responsible for this volume of traffic are:<br>* clients with UseEntryGuards disabled, including:<br>   * Tor2web (to a rend node using Tor2webRendezvousPoints)<br>* Tor relays that aren't in the consensus(es) you're using to work out<br>  what a "non-Tor IP" is,<br>* Tor relays that have an OutboundBindAddress* option, or a route, that<br>  binds to an IP address they're not advertising in their descriptor.<br>> I have not claimed evidence to "prove" confirmation attacks. I have<br>> merely observed nearly a gigabit (on multiple nodes, that is) of inbound<br>> traffic entering the network through my exit nodes, which does not seem<br>> very reasonable to do unless the goal is attack hidden services.<br>Proving an attack would be hard: we'd have to rule out all the<br>exceptional cases I listed above one-by-one. And check the process used<br>to identify Tor and non-Tor IPs.<br>T<br>--<br>Tim Wilson-Brown (teor)<br>teor2345 at gmail dot com<br>PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B<br>ricochet:ekmygaiu4rzgsk6n<br>xmpp: teor at torproject dot org<br>------------------------------------------------------------------------</blockquote></div>