Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#3143 closed defect (invalid)

Cannot avoid rogue ExitNodes

Reported by: aa138346 Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version: Tor: 0.2.2.25-alpha
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (15)

comment:1 Changed 8 years ago by Sebastian

In 0.2.2.25, if you set ExcludeExitNodes for the node(s) in question and pair it with strictnodes 1, you should never see that. Are you using StrictNodes?

comment:2 in reply to:  1 Changed 8 years ago by aa138346

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.

comment:3 Changed 8 years ago by Sebastian

How are you determining "it happens"?

comment:4 in reply to:  3 Changed 8 years ago by aa138346

Using torcheck.xenobite.eu, or by sending traffic to a known host and recording the source IP address.

comment:5 Changed 8 years ago by Sebastian

Hrm. It doesn't look to me like 66.249.9.107 is a relay using that IP address for its incoming connections. Please use Vidalia or something else (another controller, logging without safelogging turned on etc) to actually identify the last node in the circuit.

comment:6 Changed 8 years ago by arma

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.

comment:7 Changed 8 years ago by arma

Can you provide more details on the "seem to be hijacking traffic and forcing an exit" part? Is it actually modifying your traffic, or did you just freak out because you couldn't block it the way you thought would work?

comment:8 in reply to:  6 ; Changed 8 years ago by aa138346

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?

comment:9 in reply to:  8 Changed 8 years ago by arma

Keywords: hijack removed
Priority: criticalnormal

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 so we don't lose track of the issue.

comment:10 in reply to:  8 ; Changed 8 years ago by Sebastian

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.

comment:11 in reply to:  10 ; Changed 8 years ago by 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.

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.

comment:12 in reply to:  11 Changed 8 years ago by rransom

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_captcha defaults 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.

comment:13 Changed 8 years ago by rransom

Resolution: invalid
Status: newclosed

comment:14 Changed 7 years ago by nickm

Keywords: tor-client added

comment:15 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.