Cannot avoid rogue ExitNodes
I am trying to avoid certain Nodes and ExitNodes which seem to be hijacking traffic and forcing an exit.
This really raises my suspicions.
For example, I have noticed that the node:
66.249.9.107 (resolves to selectresponse.com.9.249.66.in-addr.arpa.)
will force itself to be an exit node, despite my attempts to ban it in my configuration file. I have tried using the ExcludeExitNodes and even ExcludeNodes directives, reloading the configuration of course.
I do not understand the way that circuits are built well enough to know if this is something that the client has any control over, both at the time of building the circuit or and after the circuit is built.
I have had noticed this phenomenon with a handful of other ExitNodes as well, and it obviously opens all sorts of problems if these are bad actors.
I have verified this behavior with tor clients (stable and unstable) up to version 0.2.2.25 in both linux and windows.
Trac:
Username: aa138346
Activity
In fact, I am using StrictNodes 1.
The only other directives I am using are:
ExitNodes {us} ExcludeSingleHopRelays 1
So this is the relevant configuration information:
StrictNodes 1 ExitNodes {us} ExcludeSingleHopRelays 1 ExcludeNodes 66.249.9.107 ExcludeExitNodes 66.249.9.107
The reason I am concerned is when I ban other exit nodes, I don't have any problems with those nodes showing up as exit nodes. However, with this specific node, nothing seems to work.
I thought perhaps the ExitNodes {us} line might be causing a priority conflict (include first or exclude first), but it still happens when I take that directive out.
Trac:
Username: aa138346
Replying to aa138346:
ExcludeNodes 66.249.9.107 ExcludeExitNodes 66.249.9.107
The reason I am concerned is when I ban other exit nodes, I don't have any problems with those nodes showing up as exit nodes. However, with this specific node, nothing seems to work.
There is no Tor relay at 66.249.9.107. That's why excluding it doesn't work.
However, there is a Tor relay at 66.249.9.183 (nickname ecksnet) which appears to bind its outbound traffic to 66.249.9.107. So you'd want to exclude the relay by fingerprint (07E9456ED300CABCE2549119FE5B3CC27DA55585) or by its advertised IP address rather than by the IP address that it happens to send its traffic from.
-
I think you got it right, I couldn't block it the way I thought would work.
I was in the process of trying to exclude exit nodes that were modifying traffic, though, like redirecting sorry.google.com to ixquick search, etc. (This exit node wasn't one of them, but I as trying to exclude it for other reasons.)
Would there be a reason why an node would want to advertise a different IP address than its actual one?
Would this be a good feature that the client could check for matching advertised and actual IP address and exclude, something along the lines of RefuseUnknownExits?
Trac:
Username: aa138346 -
Replying to aa138346:
Would there be a reason why an node would want to advertise a different IP address than its actual one?
Plenty of relays do it. The main reason seems to be that they're behind some sort of traffic filter, nat-style, that aggregates outgoing traffic on their network.
Would this be a good feature that the client could check for matching advertised and actual IP address and exclude, something along the lines of RefuseUnknownExits?
I opened #3145 (moved) so we don't lose track of the issue.
Trac:
Priority: critical to normal
Keywords: hijack deleted, N/A added Replying to aa138346:
I was in the process of trying to exclude exit nodes that were modifying traffic, though, like redirecting sorry.google.com to ixquick search, etc. (This exit node wasn't one of them, but I as trying to exclude it for other reasons.)
This is a torbutton feature (it should even ask you about it I believe). I think you might be blocking nodes for no real reason.
-
Replying to Sebastian:
This is a torbutton feature (it should even ask you about it I believe). I think you might be blocking nodes for no real reason.
First, any exit node that is going to redirect my traffic in that manner, I just want to exlude.
Second, I was referencing the sorry.google.com -> ixquick redirect merely as an example. There are plenty of other practical reasons that you might want to exclude exit nodes, for example the exit nodes that are already flagged by google for excessive search submissions. Sometimes, it's a pain to try to find a new exit node that isn't already flagged, and by excluding the nodes you already know are flagged, obviously it increases the chances that you will be able to find a different one that isn't.
Third, torbutton only works for browsers anyways.
Trac:
Username: aa138346 Replying to aa138346:
Replying to Sebastian:
This is a torbutton feature (it should even ask you about it I believe). I think you might be blocking nodes for no real reason.
First, any exit node that is going to redirect my traffic in that manner, I just want to exlude.
He meant that Torbutton can redirect Google CAPTCHAs to another search engine. See Torbutton's ‘Preferences’, under ‘Security Settings’, under ‘Headers’ (this is definitely suboptimally located).
That feature is on by default, but the hidden preference
extensions.torbutton.asked_google_captchadefaults to off so that Torbutton can ask for permission and allow you to turn the redirect off the first time Google redirects you to its CAPTCHA page.mentioned in issue #3145 (moved)
moved to tpo/core/tor#3143 (closed)
mentioned in issue tpo/core/tor#3145 (closed)
