Thanks for your input, Tim.
You are correct that I have not taken into account the IPs which are not in the consensus.
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 (*and still is*, on one node) flowing in.
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).
This went on for 8 hours on apx1, apx2 is seeing this still.
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.
-- Kenan
On 22 Jul 2017, at 08:00, Matt Traudt <sirmatt at ksu.edu> wrote:
Now, to my observations and the post that was referred to:
/I clearly failed to clarify/ that the "suspicious" traffic which caught my interest was about non-Tor IPs entering the network through my exits.
How do you work out what a non-Tor IP is?
As pastly nicely put it: /> will never be used as a guard by well-behaved tor clients./
Exits won't be used as long-term Guards, but they will be used as Entry nodes (or receive connections that look like client connections) from:
- clients via bridges
- clients with UseEntryGuards disabled, including:
- Single Onion Services (to intro and rend nodes)
- Tor2web (to HSDir, intro and rend nodes)
- clients using them as directory guards or fallback directory mirrors,
- bandwidth authorities,
- Tor relays that aren't in the consensus(es) you're using to work out what a "non-Tor IP" is,
- Tor relays that have an OutboundBindAddress* option, or a route, that binds to an IP address they're not advertising in their descriptor.
(Some of these categories might be excluded by position weights, I haven't checked them all in detail.)
My observations were made using a utility I built using nDPI and sysdig (kernel module).
That is, I have observed about a gigabit of traffic entering my exit nodes originating /from non-Tor IPs/, causing connections to be initiated to middle nodes.
The most likely scenarios responsible for this volume of traffic are:
- clients with UseEntryGuards disabled, including:
- Tor2web (to a rend node using Tor2webRendezvousPoints)
- Tor relays that aren't in the consensus(es) you're using to work out what a "non-Tor IP" is,
- Tor relays that have an OutboundBindAddress* option, or a route, that binds to an IP address they're not advertising in their descriptor.
I have not claimed evidence to "prove" confirmation attacks. I have merely observed nearly a gigabit (on multiple nodes, that is) of inbound traffic entering the network through my exit nodes, which does not seem very reasonable to do unless the goal is attack hidden services.
Proving an attack would be hard: we'd have to rule out all the exceptional cases I listed above one-by-one. And check the process used to identify Tor and non-Tor IPs. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org